RAGパイプラインの信頼性を担保する：ガードレール設計とマルチエージェントオーケストレーションの実装パターン

はじめに：LLMアプリケーションにおける「信頼性」の再定義

LLMアプリケーションの開発において、「信頼性」の定義が変容しつつある。かつてはモデルのベンチマークスコアやファインチューニングによる精度向上が主眼だった。しかし、プロダクトとして外部ユーザーに公開する段階になると、信頼性の軸は「答える正しさ」から「不正な入力を拒否できるか」「ハルシネーションを検知して抑制できるか」という防御力へとシフトする。これはモデルの能力を前提とした設計から、パイプライン全体の制御構造に依存する設計へのパラダイムシフトである。

この転換の背景には、プロンプトインジェクション攻撃の複雑化と、マルチエージェント構成における状態管理の難化がある。単一モデルの出力を検証するだけでは、エージェント間での情報伝播によって脆弱性が増幅される可能性がある。設計段階でガードレールの設置位置やエージェント間の境界を定義しておかないと、運用後に発見した時点でアーキテクチャの変更コストが膨大になるリスクがある。

本記事では、Google Developer ExpertであるRobina Mirbahar氏が公開したオープンソースのブラウザゲーム「Prompt Paws」が示すアーキテクチャパターンを分析する。同ゲームはHTML5 CanvasとWebAudioを用いて、APIキーやサインアップ不要でブラウザ上で完全にクライアントサイド動作する（開発者による解説記事）。RAG、ガードレール、コンテキストキャッシング、ツール呼び出し、マルチエージェントオーケストレーションという5つの概念を、7つのロボットキャットキッチンステーションとして可視化している（GitHubリポジトリ）。

ゲームという文脈は、実務のRAGパイプライン設計に直接転用できるわけではない。しかし、各コンポーネント間のデータフローや制約条件を直感的に理解できる点において、設計判断のトレードオフを評価する際の参照枠として有用である。本記事では、このゲームから抽出したパターンを実務のRAGパイプライン設計に適用する方法論として整理し、シニアエンジニアが自社プロダクトで判断材料として使える形に落とし込む。

前提知識：プロンプトインジェクションとガードレールの必要性

意味的インジェクションという新しい攻撃面

LLMがユーザープロンプトを直接処理する構成では、入力に埋め込まれた悪意ある指示がモデルの行動を操作するリスクが常に存在する。Prompt Pawsではこの攻撃を「スパイシーなプロンプトインジェクション（🌶️）」として可視化し、ガードレールで除去するルールを定義している（開発者による解説記事）。これはゲーム内の演出ではなく、実務でも同様の問題が起きていることを示すメタファーである。

従来のルールベースフィルタリング（キーワードマッチングや正規表現）では、意味レベルで巧妙に偽装されたインジェクションに対応できない。例えば、システムプロンプトの構造を模倣した指示文や、多言語を混在させて検知を回避する手法など、静的なパターンマッチングでは捕捉しきれない可能性がある。そのため、軽量なLLMによる意味的検証や、構文解析を用いた指示文の意図分類をガードレールに組み込むことが検討される。

ガードレールの設置位置とトレードオフ

ガードレールは「モデルの出力を検証する」という受動的な役割だけでなく、入力段階で不正な指示を除去・変換する「安全弁」として機能する必要がある。設置位置によって、レイテンシ・防御力・実装コストのバランスが変化する。入力前に置くほど防御力が高い傾向にあるが、レイテンシの増大と誤検知による正当なリクエストのブロック（偽陽性）のリスクも高まる。逆に出力後に置くだけでは、一度モデルが処理してしまった有害な内容が応答に含まれる可能性がある。

実務では、リスク許容度に応じて複数段階にガードレールを配置するレイヤード防御が現実的な設計である。ただし、各段階で追加される処理コストの積み上がりが全体のレイテンシに与える影響を、設計時に定量的に評価しておくことが重要である。

設置位置	レイテンシ影響	防御力	実装コスト
入力前	高い（全リクエストに適用）	最も高い	中（ルール設計が複雑）
中間処理（RAG検索前後）	中（検索結果にのみ適用）	中（文脈依存の検知）	高（文脈理解が必要）
出力後	低い（生成完了後にのみ）	低い（事後対応）	低（パターンマッチで実現可能）

特に注意すべきは、中間処理段階のガードレールである。RAG検索で取得したチャンクの中にインジェクションペイロードが混入しているケース（間接的プロンプトインジェクション）には、入力前・出力後どちらのガードレールでも捕捉しきれない可能性がある。検索結果を「データ」として扱うのではなく、「潜在的に信頼できない入力」として再検証する設計が求められる。この設計判断は、マルチエージェント構成ではさらに重要になる。エージェントAからエージェントBへのデータ受け渡し時に、受信側が送信側の出力を再度検証する責任を負う必要があるからだ。

RAGパイプラインにおける文脈管理とキャッシング戦略

コンテキストウィンドウの制約とノイズ問題

RAGパイプラインにおいて、ベクターDBからの検索結果をそのままLLMのコンテキストに投入すると、2つの問題が生じる。第一に、コンテキストウィンドウの制限により、関連性の高いチャンクが切り捨てられる。第二に、関連性の低いチャンクが混入することで、モデルの注意が分散し、ハルシネーションの確率が上昇する可能性がある。Prompt Pawsでは、このハルシネーションを「👻」として可視化し、RAGによる事実参照で防ぐルールを定義している（開発者による解説記事）。

対策として、検索結果のランキング後にリランク処理を挟み、上位N件だけをコンテキストに含める手法が一般的である。しかし、Nの値は固定にすべきではない場合が多い。クエリの複雑度やドメインの特性に応じて動的に調整する設計が、精度とコストのバランスを最適化する可能性がある。例えば、事実確認系のクエリでは少ないチャンクで十分だが、総合的な要約を要求される場合では、より多くの文脈が必要になる。

コンテキストキャッシングの設計判断

頻出するクエリパターンや静的な知識ベースに対して、毎回ベクター検索とLLM呼び出しを行うのは計算コストの無駄である。コンテキストキャッシングは、この繰り返し処理を回避するための重要な最適化手法である。ただし、キャッシュの設計で最も難しいのはTTL（Time To Live）の設定と、データ更新時の無効化ロジックである。

静的な知識（例えば会社のポリシー文書やAPIの仕様書）に対しては、比較的長いTTLを設定し、文書更新時に明示的にキャッシュを無効化するイベント駆動型の設計が有効である。一方、動的なデータ（例えばリアルタイムの在庫情報やユーザーの直近の操作履歴）に対しては、短いTTLかキャッシュを全く使わない方が安全である場合がある。stale dataが混入すると、ガードレールでは検知できない「正しい形式の誤った回答」が生成されるため、データ鮮度とキャッシュ有効性のトレードオフを設計時に明確にする必要がある。

動的な検索結果と静的なキャッシュを組み合わせるハイブリッド構成では、以下の判断基準を適用すると実務的に機能する可能性がある。静的な知識（更新頻度が週単位以下）はキャッシュし、動的なデータ（更新頻度が分単位以上）はリアルタイム検索に回す。境界が曖昧なケース（例えば月次で更新される統計データ）では、キャッシュのTTLを更新周期より短く設定し、最悪ケースでも一定期間以上のstale dataが混入しないようにする。

flowchart TD
    A["ユーザークエリ"] --> B{"キャッシュヒット?"}
    B -->|"Yes"| C["キャッシュからコンテキスト取得"]
    B -->|"No"| D["ベクターDB検索"]
    D --> E["リランキング・上位N件抽出"]
    E --> F["コンテキストアセンブリ"]
    C --> F
    F --> G["LLM呼び出し"]
    G --> H["出力ガードレール検証"]
    H --> I["応答返却"]
    H -->|"ブロック"| J["エラー応答・ログ記録"]

このフローにおいて、キャッシュヒット時にリランキングをスキップできるかどうかがレイテンシの大きな分岐点になる。静的な知識に対しては、検索結果の順序が安定しているため、キャッシュ時にリランキング済みの結果を保存しておけば、ヒット時はそのままコンテキストに投入できる可能性がある。ただし、この最適化は「検索インデックスの再構築時にキャッシュを全無効化する」前提で成立する。インデックス再構築を忘れたままキャッシュを有効な状態にしておくと、古いチャンクがコンテキストに混入するリスクがある。運用上のチェックリストに「インデックス再構築 → キャッシュ全無効化」の順を明記しておくことが、この種の事故を防ぐ最小限の保険である。

マルチエージェントオーケストレーション：役割分担と境界設計

単一のLLMコールでは処理しきれない複雑なタスクを分解し、複数のエージェントに並列または直列で処理させるのがマルチエージェントオーケストレーションの基本的な考え方である。Prompt Pawsでは7つのロボットキャットキッチンステーションが、高速LLM、コンテキストキャッシュ、入力ガードレール、RAGベクターDBといった実世界のAIエンジニアリングコンポーネントに対応しており、各ステーションが独立した責務を担う構造になっている（GitHubリポジトリ）。

メッセージパッシングと共有メモリの使い分け

エージェント間のデータ受け渡しには、メッセージパッシング（非同期イベント）と共有メモリ（状態ストア）の2つの方式がある。メッセージパッシングはエージェント間の結合を低く保てるが、順序保証や再送ロジックを自前で実装する必要がある。一方、共有メモリは読み書きが単純だが、競合状態が発生しやすく、ロック機構やバージョン管理が不可欠になる。

実務では、「一度だけ書く」データ（例: 検索結果のキャッシュキー）には共有メモリを、「複数回更新される」状態（例: 会話履歴）にはメッセージパッシングを組み合わせるケースが多い。どちらか一方に統一しようとすると、不要な同期コストかデータ整合性の問題のいずれかが生じる可能性がある。境界を引く判断基準は、書き込み頻度と読み取り者数である。

DAGによるワークフロー定義

エージェント間の依存関係が循環すると、デッドロックや無限ループのリスクがある。これを防ぐため、ワークフロー全体を有向非巡回グラフ（DAG）として定義するのが実践的なアプローチである。オーケストレーターがトポロジカル順序に従ってエージェントを起動すれば、各ノードが「入力に依存する全ノードが完了している」ことを構造的に保証できる可能性がある。

flowchart TD
    A["オーケストレーター"] --> B["入力ガードレール"]
    A --> C["RAG検索"]
    A --> D["コンテキストキャッシュ"]
    C --> E["LLM推論"]
    D --> E
    E --> F["出力ガードレール"]
    F --> G["応答返却"]

このフローでは、入力ガードレールとRAG検索が並列で実行可能であり、両者の出力がLLM推論の入力として収束する。DAGの構造を明示的に定義しておくことで、後からエージェントを追加・削除しても依存関係の破綻を静的に検出しやすくなる。単一障害点を排除するためには、オーケストレーター自体を冗長化するか、ステートレスな設計にして障害時に別インスタンスへフェイルオーバーさせる構成を検討する。

リアルタイム検証：アーキテクチャリンターの活用

設計段階での脆弱性検出

開発環境において、エージェントの構成や設定を検証する「アーキテクチャリンター」のようなツールを活用することで、配置したステーションの潜在的な問題（ガードレール不足など）を早期に発見できる。これはデプロイ後の監視ツールではなく、開発者がエージェントを設計・実装した段階で、定義されたポリシーとの照合を行い、不足しているガードレールや不適切な依存関係を指摘する仕組みである。

このアプローチの価値は、脆弱性の発見を「デプロイ後のインシデント対応」から「設計・実装段階」へ引き上げることにある。ガードレールが欠落したエージェントを本番に投入してから問題が発覚するのと、設計時に即座に警告されるのとでは、修正コストが大幅に異なる。特にマルチエージェント構成では、1つのエージェントのガードレール欠落が下流の複数のエージェントに波及するため、早期検出の効果が単一エージェント構成より大きくなる傾向がある。

Policy as Code による検証ルールの外部化

リンターが参照するポリシーをコードとして管理することで、バージョン管理とレビュープロセスに組み込める。「入力ガードレールが未設定のエージェントは配置を拒否する」「RAG検索エージェントは必ずコンテキストキャッシュとペアで配置する」のようなルールを宣言的に記述し、構成ファイルに対して静的解析を適用する。これにより、ルールの変更がプルリクエストのレビューで確認され、意図しない緩和が本番に持ち込まれるのを防げる。

静的解析と動的なランタイムチェックを組み合わせることで、設計時の構造的な問題と実行時の挙動の異常をそれぞれ捕捉できる。この「シフトレフト」な品質保証のアプローチは、CI/CDパイプラインに組み込むことで、プルリクエストのレビュー段階で自動検証が可能になる。

sequenceDiagram
    participant Dev as 開発者
    participant Orch as オーケストレーター
    participant Agent as エージェント
    participant Linter as リンター
    Dev->>Orch: エージェント配置リクエスト
    Orch->>Agent: 配置処理の開始
    Orch->>Linter: 構成ポリシーの検証
    Linter-->>Orch: 警告: 入力ガードレール未設定
    Orch-->>Dev: 配置拒否・修正指示の返却

実装パターン：クライアントサイドでの完全動作とセキュリティ

ブラウザ上で完全にクライアントサイドで動作するプロトタイプやPoC（概念実証）では、HTML5 CanvasとWebAudioを使用し、APIキーやサインアップ不要でRAGやマルチエージェントの動作を体感できるケースがある。この設計は、導入障壁を下げる点で有効であるが、サーバーインフラの準備や認証情報の管理が不要な反面、セキュリティ上の制約も生じる。

クライアントサイドとサーバーサイドの責任分界点

実務のプロダクトに適用する際には、クライアントサイド完結の設計をそのまま持ち込むべきではない。機密情報（APIキー、ユーザーデータ）の扱いやスケーラビリティの観点から、どこをクライアントに残し、どこをサーバーサイドに移すかの分界点を明確にする必要がある。APIキーをクライアントに埋め込む設計は、PoCでは許容範囲でも、本番では情報漏洩のリスクとして不適切である。

一般的には、UI層（Canvas描画、音声再生）とAIロジック（LLM呼び出し、RAG検索、ガードレール検証）を疎結合に保つ設計がメンテナンス性の面で有利になる。UI層はWeb Workerで処理をオフロードしつつ、AIロジックはサーバーサイドのAPIとして提供するという構成が、セキュリティとスケーラビリティの両立に繋がる。分界点を「データの機密度」ではなく「処理の性質（同期/非同期、CPU/GPU依存）」で引くと、後からの移行コストが低くなる。

オープンソースコードベースからの設計パターン抽出

オープンソースのプロジェクトをフォークして新しいモデルのステーションを追加できる場合がある。このコードベースから得られるのは、モジュールごとの依存関係の管理方法や、拡張性を意識した設計パターンである。各ステーションが独立したインターフェースをもち、オーケストレーターを通じてのみ通信するという構造は、自社のビジネスロジックにカスタムエージェントを追加する際の参照実装として活用できる。特に、ステーションの追加が既存ステーションのコード変更を伴わない「オープンクローズ」な設計になっている点は、大規模なエージェント群を維持する際の保守性の観点で重要である。

トレードオフ分析：ガードレールのオーバーヘッドと精度

ガードレールをパイプラインに追加することは、レイテンシの増大と推論コストの上昇を伴う。特にマルチエージェント構成では、各エージェントの出力に対して個別に検証を行う場合、検証コストがエージェント数に比例して積み重なる。このため、「どこにどの強度のガードレールを置くか」という設計判断が、システムの全体性能を左右する。

ガードレール強度とコストの関係

ガードレールの強度を上げた場合、検知精度は向上するが、偽陽性（False Positive）の増加が避けられない。ユーザーが正当な質問をしても「不適切な指示」と判定されてブロックされるケースが発生し、ユーザー体験を損なう。許容される誤検知率とビジネス要件（例：医療・金融領域では厳格に、一般コンテンツでは緩めに）のバランスを、設計段階で明示的に決める必要がある。

一方、軽量なオープンウェイトモデルによる事前フィルタリングを組み合わせることで、高コストな大規模モデルでの検証を必要とするリクエストのみにガードレールを適用できる。この「2段構え」のアプローチでは、第一段階で明らかな異常を除去し、第二段階で意味的な検証を行うことで、全体のコストを抑制しつつ防御力を維持する。

さらに、前述のコンテキストキャッシングとの相乗効果も無視できない。ガードレールが検証済みの出力をキャッシュに格納した場合、同一パターンが繰り返し発生するクエリに対しては再検証を省略できる。データ更新時の無効化ロジックが正しく機能していることが前提だが、高頻度クエリが支配的なワークロードでは、ガードレール適用時の追加負荷を大幅に相殺できる可能性がある。

ガードレール強度	レイテンシ影響	偽陽性率	向いている場面
ルールベース（正規表現・キーワード）	ほぼなし	低	明らかな有害パターン除去
軽量LLMによる事前フィルタ	数十ms程度増加	中	意味的なインジェクション検知
出力後の一貫性チェック	LLM呼び出し1回分増加	高	ハルシネーション防止・事実照合
マルチエージェント相互検証	エージェント数に比例	高	高信頼性が要求される領域

実際の設計では、この表の各段を単独で使うのではなく、リスクレベルに応じて組み合わせる。入力段階ではルールベースで粗く絞り、中間処理で軽量LLMによる意味的検証を行い、出力段階ではRAGによる事実照合でハルシネーションを検知する、という多層防御が現実的な落としどころである。

実装手順：既存コードベースからの拡張とカスタマイズ

オープンソースのプロジェクトを参照実装として活用する際の、具体的な手順と注意点を解説する。

モジュール構造の理解

各ステーションは、高速LLM、コンテキストキャッシュ、入力ガードレール、RAGベクターDBなどの実世界のAIエンジニアリングコンポーネントに対応している場合がある。まず、各ステーションが公開しているインターフェース（入力・出力のデータ形式）と、オーケストレーターとの通信プロトコルを把握する。この理解ができていれば、自社のビジネスロジックに合わせたカスタムエージェントを、既存ステーションのコードを変更せずに追加できる可能性がある。

カスタムステーションの実装時に重要なのは、ステーション内部の状態管理をローカルに閉じることである。ステーション間で共有メモリを直接参照すると、並行実行時の競合条件が発生し、デバッグが困難になる。オーケストレーターを介した明示的なメッセージパッシングに統一することで、ステーション間の結合度を下げ、単体テストの書きやすさを保てる。

ガードレールルールの外部化とデプロイ管理

ガードレールの判定ルール（ブロック対象のパターン、許容閾値など）は、コードにハードコードせず外部の構成ファイルとして管理する。これにより、デプロイ後にルールを変更する場合の再ビルド・再デプロイが不要になり、インシデント発生時の対応速度が向上する。構成ファイルのバージョン管理はGitで行い、変更履歴の追跡とロールバックの容易さを確保する。

テスト環境での動作確認では、アーキテクチャリンターのようなリアルタイムの検証ツールを活用する。ステーションの配置を変更した直後に、ガードレールの不足や未検証パスの存在を即座に警告されることで、デプロイ前に脆弱性を発見できる可能性がある。CI/CDパイプラインにこのリンターを組み込むことで、構成ファイルのプッシュ時に自動検証が走ることになる。

運用と監視：ハルシネーション検知と継続的改善

RAGパイプラインでは、ハルシネーションを防ぐためにRAGを使用するルールが明示されている場合がある。実務のRAGパイプラインでも同様に、出力後の一貫性チェックがハルシネーション検知の最終防衛線となる。RAGによる事実参照は「モデルが参照すべき文脈を与える」ことだが、モデルがその文脈を無視して出力を生成するケースは依然として発生する。そのため、出力と参照文脈の整合性を検証するステップを、ガードレールの最終段に置く設計が有効である。

ブロックログの分析とルール調整

ガードレールによってブロックされたリクエストは、すべて構造化ログとして記録する。記録項目としては、ブロックされた理由（どのルールに該当したか）、元の入力テキスト、ブロック時刻、関連するセッションIDが最低限必要である。このログを定期的に分析することで、以下のような改善サイクルが回せる。

偽陽性の特定：正当なクエリがブロックされたケースを抽出し、ルールの閾値を調整する。
新規攻撃パターンの発見：既存ルールでは検知できないインジェクションパターンが現れた場合、ルールセットに追加する。
モデル更新時の影響評価：モデルのバージョンアップにより、従来は問題なかった出力がガードレールに引っかかるようになった場合の対応。

フォールバック戦略

マルチエージェント構成では、あるエージェントがタイムアウトしたりエラーを返したりした場合、全体のレスポンスが阻害される。フォールバック戦略として、以下を設計時に決めておくべきである。

どのエージェントの障害が「クリティカル」で、どの障害が「デグラデーションで許容できる」か。
デグラデーション時の代替パス（例：RAG検索が失敗した場合は、キャッシュのみで応答し「参考情報の鮮度が古い可能性があります」と付記する）。
ユーザーへのエラーメッセージの粒度。内部のエージェント名や技術的な詳細を暴露せず、再試行を促す一般的なメッセージに留める。

モデルのバージョンアップに伴う互換性テストは、ガードレールルールの回帰テストとして位置づける。新しいモデルの出力分布は古いモデルと異なるため、従来は通っていた出力が新たにブロックされる、あるいは逆にブロックされるべき出力が通過する、という変化が起きる。アップグレード前に、既存のテストケースセット（正常系・異常系）を新しいモデルで実行し、ガードレールの判定結果に大きな乖離がないことを確認するプロセスを確立しておく。

まとめ：実務への適用と今後の展望

ゲーム開発という文脈から抽出したパターンは、実務のRAGパイプライン設計において、直感的で堅牢なガードレールとオーケストレーションの設計指針として参考になる。Prompt Pawsが示す「7つのステーションが独立したコンポーネントとして連携する」という構造は、実世界のマイクロサービス設計やイベント駆動アーキテクチャと類似した問題意識を共有していると考えられる。

シニアエンジニアとして重要なのは、特定のツールやフレームワークの選定ではなく、その背後にある設計判断の理由とトレードオフを理解することである。なぜガードレールをその位置に置くのか、なぜエージェント間の通信をメッセージパッシングに統一するのか、なぜコンテキストキャッシュのTTLをその値に設定するのか。これらの「なぜ」をチーム内で共有できているかどうかで、システムがスケールした際の保守性が向上する可能性がある。

Prompt Pawsのようなオープンソースプロジェクトは、最新のAIエンジニアリングのベストプラクティスを学ぶための教材となり得る。ゲームとして遊ぶことで、抽象的なアーキテクチャ概念が具体的な操作感覚として定着し、設計判断の直感を養う助けになる。本記事で示したガードレールの多層防御、マルチエージェントの境界設計、リアルタイム検証の活用パターンを、自社のプロダクトに適用するための一助として検討してほしい。

参考

本記事は海外の技術トレンド「I Built a Cozy 60 FPS AI Agent Bakery Game (Built with Gemma 4 & Antigravity) to Teach RAG, Guardrails & Multi-Agent Orchestration」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。