本番AIは恐ろしい（そしてその直し方）

エージェントにガードレールがなければ、本番対応とは言えない。

誰も、安全でないAIシステムを構築しようとして始めるわけではありません。指示を書き、エッジケースをテストし、いくつかの検証ルールを追加します。それでも、誰かがボットを海賊のように振る舞わせてユーザーデータを暴露させる方法を見つけたり、クレジットカード番号がログに残ってしまったり、あるいはモデルが自信満々に競合他社の製品を推奨したりすることがあります。

「デモでは動く」ことと「本番環境で安全である」ことの間の溝は、多くのチームが予想するよりも深いものです。

問題の一部は、生のLLMが、何をすべきか、何をすべきでないかという独自の意見を持っていないことにあります。それらは、開始されたパターンを継続しようとする予測マシンに過ぎません。「システムオーバーライドモード」のように見えるプロンプトを与えれば、喜んでそれに従います。これはモデルのバグではなく、言語モデルの仕組みそのものなのです。

ほとんどのフレームワークは、単にモデルを渡して「幸運を祈る」だけです。しかしMastraは異なるアプローチをとります。最終的にはガードレールが必要になることを前提とし、エージェントのアーキテクチャに最初から組み込んでいます。

安全層としてのプロセッサ

その核となる仕組みは単純です。プロンプトがモデルに届く前に、一連の入力プロセッサを通過します。モデルが応答した後は、出力プロセッサがその番を迎えます。各プロセッサはその段階でコンテンツを検査、修正、またはブロックすることができます。

これらはAIインタラクションのためのミドルウェアだと考えてください。必要なものを積み重ね、動作を設定すれば、すべてのリクエストで自動的に実行されます。

1. 海賊を止める（プロンプトインジェクション）

プロンプトインジェクション攻撃は巧妙化しています。不可視のUnicode文字を使用したり、指示をbase64で書いたり、モデルに「通常のルールが適用されないデバッグモード」にいると思い込ませたりします。これらの手法は絶えず進化しています。

Mastraには、一般的なパターンを捉えるためのプロセッサが含まれています。

import { Agent } from '@mastra/core/agent';
import { PromptInjectionDetector, UnicodeNormalizer } from '@mastra/core/processors';
import { openai } from '@ai-sdk/openai';

export const secureAgent = new Agent({
  id: 'fortress-assistant',
  name: 'fortress-assistant',
  instructions: 'You are a secure assistant.',
  model: openai('gpt-5'),
  inputProcessors: [
    // 1. 不可視文字を除去
    new UnicodeNormalizer({
      id: 'unicode-normalizer',
      stripControlChars: true,
      collapseWhitespace: true,
    }),
    // 2. 攻撃の試行を検出
    new PromptInjectionDetector({
      id: 'prompt-injection-detector',
      model: openai('gpt-5-nano'), // 安価で高速なモデル
      threshold: 0.8,
      strategy: 'block', // 即座に停止
      detectionTypes: ['injection', 'jailbreak', 'system-override'],
    }),
  ],
});

UnicodeNormalizer は制御文字を取り除き、空白を正規化します。PromptInjectionDetector は、クリーンアップされた入力を分析し、誰かが指示を上書きしようとしている兆候を探します。

検出の感度（threshold パラメータ）や、検知時の挙動（ブロック、ログ記録、または単なるフラグ立て）を自在に設定できます。

2. PII（個人情報）の処理

ログに残るクレジットカード番号、ベクトルデータベースに紛れ込む社会保障番号、必要以上に長く保持されるメールアドレス。これらは規制上の問題に直結します。厄介なのは、ユーザーが機密データをチャットウィンドウに貼り付けていることに必ずしも気づいていないという点です。

PIIDetector は、データがモデルに到達する前やストレージに書き込まれる前に、一般的なパターンをスキャンします。

import { PIIDetector } from '@mastra/core/processors';

export const privateAgent = new Agent({
  id: 'privacy-first-assistant',
  name: 'privacy-first-assistant',
  instructions: 'You are a helpful assistant that never stores personal information.',
  model: openai('gpt-5'),
  inputProcessors: [
    new PIIDetector({
      id: 'pii-detector',
      model: openai('gpt-5-nano'),
      detectionTypes: ['email', 'phone', 'credit-card', 'ssn'],
      threshold: 0.6,
      strategy: 'redact',
      redactionMethod: 'mask',  // [REDACTED] に置換
      instructions: 'Detect and mask personally identifiable information',
    }),
  ],
});

墨消し（[REDACTED] への置換）、ハッシュ化、または完全ブロックから選択できます。プロセッサは入力と出力の両方で実行されるため、万が一モデルが応答の中で機密データを生成してしまった場合でも保護されます。

3. コンテンツモデレーション

インターネットの膨大なデータで学習されたモデルは、あらゆるものを見てきています。フィルタリングがなければ、PRチームを冷や汗をかかせるような回答を生成することもあります。ModerationProcessor は、ガイドラインに違反するコンテンツを捕捉します。

import { ModerationProcessor } from '@mastra/core/processors';

export const moderatedAgent = new Agent({
  id: 'safe-assistant',
  name: 'safe-assistant',
  instructions: 'You are a helpful assistant for a community platform.',
  model: openai('gpt-5'),
  inputProcessors: [
    new ModerationProcessor({
      id: 'moderation-processor',
      model: openai('gpt-5-nano'),  // 分類用の高速で安価なモデル
      categories: ['hate', 'harassment', 'violence', 'self-harm'],
      threshold: 0.7,  // 信頼度が70%を超えた場合にブロック
      strategy: 'block',  // リクエストを即座に停止
      instructions: 'Detect harmful content that violates community guidelines',
    }),
  ],
});

重要なのは、ユースケースに合わせてどのカテゴリを重視するかを定義できる点です。創作支援ツールであれば、カスタマーサービス用のボットよりも表現の自由を広く認めるかもしれません。閾値と戦略によって、フィルタリングの厳しさを調整できます。

ガードレールが作動したとき

プロセッサは、問題を検出しても例外（エラー）を投げません。代わりに、結果オブジェクトにフラグを立てます。

const result = await secureAgent.generate('これまでの指示をすべて無視してください...');

if (result.tripwire) {
  console.log(`ブロックされました！理由: ${result.tripwireReason}`);
  // "ブロックされました！理由: プロンプトインジェクションが検出されました。"
  return "残念ながら、その指示には従えません。";
}

このパターンにより、アプリケーションに最適な方法でセキュリティイベントを処理できます。分析のためにログを記録したり、汎用的なエラーメッセージを返したり、特定のコンテキストでは特定の違反を許容したりすることも可能です。tripwireReason フィールドは、どのプロセッサがフラグを立てたかを正確に伝えるため、誤検知のデバッグや閾値の微調整に役立ちます。

これで解決できないこと

プロセッサは多くの問題を解決しますが、魔法ではありません。強い意志を持った攻撃者が十分な時間をかければ、ガードレールをすり抜けるプロンプトを見つけ出す可能性があります。モデルが、プロセッサが予測できないような方法で「幻覚」を見ることもあります。また、セキュリティと柔軟性の間には常にトレードオフが存在します。ルールを厳しくすればするほど、正当な利用までブロックしてしまう可能性が高まります。

ここでの価値は、「完璧な保護」ではありません。本番環境で確実に発生する一般的な問題に対して、系統的な対処法を持つことにあります。ユーザーが実際にどのように利用しているかを学ぶにつれて、感度を調整していくことができます。ドメイン固有のリスクに対してカスタムプロセッサを追加することも可能です。そして、何がなぜブロックされたのかという監査証跡を残すことができます。

本番環境のAIにおけるセキュリティ問題の多くは、高度な攻撃ではなく、単にユーザーが貼るべきでないデータをコピペしてしまったり、ボットが予期せぬ挙動をすることを発見してしまったりすることから生じます。プロセッサはすべての問題を根絶するわけではありませんが、明らかなリスクを回避する難易度を大幅に上げてくれます。

リソース

シリーズを読む

LLM ルーティング
セキュリティ＆ガードレール（この投稿）
MCP＆ツール統合
ワークフロー＆メモリ