6つのAIエージェントアーキテクチャとそれぞれに必要な制御機能

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
7月20日、CIO.comはBernard Aceituno氏による以下の記事を公開しました。 AIエージェントアーキテクチャの6つの分類この記事では、3年間にわたる数百もの企業導入事例を凝縮し、CIOがひと目で理解すべき6つのアーキタイプを提示しています。この分類の優れた点は、階層構造を設けていないことです。6つのどれが優れているというわけではなく、課題の性質に合わせて適切なアーキタイプを選択するスキルが重要となります。記事は、プラットフォームの世界に携わる者への宿題とも言える次の一文で締めくくられています。「導入、ガバナンス、信頼――これらはアーキテクチャが適切に適合して初めて容易になる」(本稿で引用する唯一の箇所です)。6つのアーキタイプはそれぞれ、 異なる 適合の仕方を持ち、共有する制御ポイントも異なります。本稿では、アプリケーションの完全なランタイムではなく、各アーキタイプを支えるモデルとツールのトラフィックに焦点を当て、TrueFoundry AI Gateway、MCP Gateway、およびAgent Harnessの文書化された機能にマッピングします。各タイプについて、その定義、制御機能の適用箇所、および設定の前提条件をセクションごとに解説します。最後に6つの比較表を掲載し、議論を締めくくる4つ目の診断的な問いを提示します。
タイプ1:会話型アシスタント
概要
思考を整理したいときに利用するチャットベースのパートナーであり、多くの企業が最初に出会うアーキタイプです。適切に構築されれば、常に最新の情報を提供し、ユーザーごとの記憶を保持し、ユーザーに代わってツールを操作し、すべての主張に根拠を提示するため、ユーザーから高く評価されると記事では報告されています。Deloitteの State of AI in the Enterprise 調査によると、組織の38%がAIイニシアチブを通じてすでに顧客関係の強化という成果を得ていると回答しています。記事の例では、グローバルな法律事務所のスタッフが、文書管理システムで1時間かけて調べる代わりに、事務所の過去の判例に基づいた根拠付きの回答からリサーチを開始するケースや、ウェルスマネージャーの顧客が日曜日にポートフォリオに関する確実な回答を得るケースなどが紹介されています。企業を建物に例えるなら、これは受付です。24時間眠らず、情報源を明示し、ロビーにいる誰もが対話できる。これこそが運用の要点です。

TrueFoundryの役割
最大の懸念は会話のインターフェースそのものです。ユーザーは自由に入力し、モデルはそれに応答し、利用人数に応じてトラフィックも増大します。これを制御する手段は、リクエスト経路の両端にあります。 llm_inputガードレール は、PII(個人情報)および機密情報の検出をミューテートモードで実行します。貼り付けられた認証情報は編集(マスキング)された上でリクエストが継続されるため、ユーザーが承認された経路を回避することを防ぎます(これは当社の ゲートウェイ対アプリケーションでのPII分析に関する議論の通りです。なお、TrueFoundryが管理するPII/PHIの組み込み機能は、TrueFoundryホスト型ゲートウェイ向けに文書化されています(セルフホスト型およびハイブリッド型デプロイメントでは、独自のキーまたは外部プロバイダーを利用する代替手段を設定してください)。また、 llm_outputチェック は、非ストリーミングパスにおいて完了したレスポンスを検査できます。このアーキタイプでは特に、文書化された境界が重要となります。出力ガードレールには完全なレスポンスが必要であるため、以下の場合にはスキップされます。 stream: true が設定されている場合。一方、入力ガードレールはストリーミングモードに関係なく実行されます(ガードレールのドキュメント)。会話型アシスタントはストリーミングを行う可能性が最も高いワークロードの一つであるため、ストリーミングを行うアシスタントには、意図的に選択された出力安全戦略が必要です。具体的には、機密性の高いリクエストには非ストリーミングパスを使用する、クライアント側でストリーミングされた完全なレスポンスをバッファリングして検証してから表示する(トークンごとの表示を諦めることを許容する)、あるいは入力のみのガードレールを採用し、ストリーム後の検証は配信後の検知として理解する、といった方法です。実行モデルは、このアーキタイプのレイテンシ予算に合わせて設計されています。入力検証は 並行して モデル呼び出しと同時に実行されます。モデルの実行中に検証が失敗した場合、ゲートウェイは実行中のリクエストをキャンセルするため、破棄されるはずのレスポンスに対して料金が発生することはありません(同ドキュメント参照)。フック周辺については、チーム単位の 予算 による利用状況の管理や、 セマンティックキャッシング が有効です。アシスタントへのトラフィックには、繰り返しや意味的に類似した質問が含まれることが多いため、鮮度やレスポンスの多様性に関する要件が許す限り、キャッシングはレイテンシ対策であると同時にコスト削減の手段となります。

種類2:トリガー型ワークフロー
概要
バックグラウンドで静かに実行されるパターンです。メールの受信、チケットの作成、フォルダへのファイル保存などをトリガーとして、エージェントが推論と決定論的なプロセスを組み合わせて実行します。ユーザーが直接目にするものではないため、ユーザーによる導入作業は不要です。例えば、保険会社の担当者は、リスク項目が抽出され分類済みの状態で届くアンダーライティング(引受審査)用インボックスを確認するだけで済みます。また、プライベート・エクイティ企業では、届いたCIM(企業概要書)が自動的にスクリーニングされ、メモが作成され、担当者がファイルを開く前に案件管理システムへ登録されます。これは、アップグレードされた企業向けのメール室のようなものです。誰もそこを訪れることはありませんが、誰もがそれに依存しており、その利点は、IT部門が数十年にわたって運用してきた監査や変更管理プロセスにきれいに適合することにあります。

TrueFoundryの役割
一見穏やかに見えるこのアーキタイプですが、その裏には厳しい脅威モデルが潜んでいます。このモデルは、 無人環境で 、 信頼できない入力に対して実行されます。受信するすべてのメール、添付ファイル、アップロードされたファイルは、プロンプトインジェクションのペイロードとなる可能性があります。つまり、ワークフローが読み取るべきコンテンツそのものに命令が隠されているのです。これこそが、当社の ゲートウェイ・インジェクション防御ガイド で詳述している攻撃クラスです。防御策として、モデルが読み取る前にトリガーペイロードをスクリーニングする入力側のガードレールを設けています。これはTrueFoundryホスト型ゲートウェイに組み込まれたプロンプトインジェクション対策、またはセルフホスト型やハイブリッド環境向けの代替手段としてドキュメント化されています。 ツール制限 により、ワークフローの書き込み領域を最小限に抑え(MCPゲートウェイのドキュメントを参照)、さらに レート制限 を設けることで、メール爆弾が何千もの自律実行へと発展するのを防ぎます。監査のしやすさという観点は、このプラットフォームでも維持されており、その仕組みは明確です。ゲートウェイを経由するすべてのリクエストは、ログ設定に関係なく、コスト、トークン使用量、レイテンシ、リクエストメタデータといったトレース情報を記録します。 ログ設定 は、リクエストおよびレスポンスの ボディ を保存するかどうか、また保存する場合にどの機密情報をマスキングするかを個別に制御します。チームは、必要な監査証跡と保持が許可されているコンテンツの両方を定義する必要があります。
タイプ3:自律型エージェント(サブエージェントを含む)
概要
タスクを与えられると、自ら手順を計画し、サブエージェントを呼び出します。この手法が真価を発揮するのは、マルチソースのリサーチ、複雑なシステム横断的な検索、詳細な調査など、プロセスにおいて あらかじめ手順が決まっていないものの、使用可能なツールは明確である場合です。コンサルティングファームの例では、独自のデータベース、過去の案件アーカイブ、ライセンスされた市場データ、公開資料の中からどのサブエージェントに相談すべきかを自ら判断して初期段階のエンゲージメントをスコープし、根拠と論理を添えた構造化されたブリーフィングを作成します。テクノロジー企業の例では、本番環境のインシデント調査において、仮説を立て、監視システム、ログ、デプロイメントシステムを追跡し、エンジニアが納得できる根本原因の要約を導き出します。適切な例えは「運び屋」ではなく「探偵」です。あなたが指定するのは「事件」と「権限の範囲」であり、その「経路」ではありません。

TrueFoundryの役割
「経路は発見されるもの」という考え方は、コストと影響範囲に関するステートメントです。経路はワークフロー定義によって静的に制限されないため、トークン数やツールの実行順序は予測しにくくなりますが、制御によって予測可能にできます。拘束手段として、 予算 およびレート制限を指令の厳格な境界線とし、サブエージェントごとの ツールスコープ をMCPレジストリを通じて設定します。さらに、CedarやOPAのポリシーガードレールを利用することで、各サブエージェントがどのツールにアクセスできるかを「デフォルト拒否」の原則に基づいてきめ細かく制御可能です(ガードレールのドキュメント)。また、 Agent Harness におけるステップレベルのトレースは、発見された経路をレビュー可能なものへと変える手段です。ここで重要なのは、これらが 実行トレース であるという点です。モデルの呼び出し、サブエージェントのターン、ツールの起動、タイミング、コスト、結果など、観測可能なアクションの運用監査証跡であり、モデルの隠れた思考プロセスへのアクセスではありません。ここで非常に重要な詳細として、ガードレールは すべてのツール呼び出しを個別に評価 します。つまり、5つのツールを呼び出すエージェントには5回の独立したチェックが行われるため、自律性が監視を上回ることはありません。

タイプ4:マルチエージェントチーム
概要
それぞれが独自の役割とツールセットを持つ複数の専門エージェントが、共通のプロトコルを通じて連携する仕組み。本コラムでは、これがエンタープライズ品質を向上させる次なる波であると論じています。Databricksの AIエージェントの現状 レポートによると、マルチエージェントシステムの利用は4か月足らずで327%増加しました。これは全人口を対象とした測定ではなく、同社のデータインテリジェンスプラットフォームを利用する2万以上の組織から得られたプラットフォームテレメトリに基づいています。その代表的な手法が 提案者・批評家ループです。一方のモデルが生成を行い、もう一方のモデル(異なるプロンプトや異なるプロバイダーが使用されることが多い)が明確な基準に基づいて評価します。これはニュース編集部が記者と編集者をペアにするのと同様の仕組みです。本コラムで取り上げた銀行では、ドラフト作成、ブランドコンプライアンス、法域開示を行うエージェントを運用しており、意見の相違が生じた場合は条項にフラグを立てて人間に報告します。また、ある製薬会社では、医学文献に対して検索、読み取り、批評、要約を行うエージェントを運用しており、批評家エージェントによるチェックを経ることで、メディカルアフェアーズチームが成果物を信頼し、実務に活用できるようになっています。

TrueFoundryの役割
チーム構成は、単一エージェントが持っていたもの(アイデンティティ、ツールの範囲、トークンの流れ)を増幅させます。さらに、本コラムで価格面以外で強調している重要な点があります。それは、批評家が 異なるプロバイダーのモデル である場合、独自のスタックにおいては、2つ目の統合、2つ目の認証情報、2つ目のログ記録パスが必要になるという点です。ゲートウェイは、こうしたプロバイダー固有の接続や認証情報の煩雑な処理の多くを排除します。OpenAI互換の統合APIにより、ドラフト作成モデルと批評モデルを単一のスキーマの背後に配置できます(ゲートウェイのドキュメント参照)。ただし、このゲートウェイはループ自体を実装するものではありません。オーケストレーション(ターンの順序付け、批評家の評価基準の構築、役割間での状態保持、意見の相違の処理、修正・停止・エスカレーションの判断)は、依然としてアプリケーションやエージェントハーネス側が担う必要があります。また、リクエストスキーマが共通化されても、プロバイダー間で意味的な互換性が完全に保証されるわけではありません。増幅されるリスクは帰属の問題であり、ドキュメント化されたモデルでも明確にされています。個々のエージェントの帰属を特定するには、個別に登録された エージェントID 独立して管理される各ロール用。MCPゲートウェイまたはエージェントゲートウェイに接続する際、すべてのエージェントが提示しなければならないエージェントごとのプリンシパルです。A 仮想アカウント対照的に、サービスやアプリケーションを表すもので、エージェントレベルの識別が不要な場合に適しています。複数のエージェントに1つの仮想アカウントを割り当てると、それらは単一のゲートウェイ呼び出し元として統合されます。IDは以下を明らかにします。 そのエージェントが何者であるか関連するエージェント登録とスコープ設定されたゲートウェイポリシーによって、誰がそのエージェントを呼び出せるか、誰の代理として行動できるか、どのダウンストリームツールやサービスにアクセスできるかが定義されます(ドキュメントにある通り、そのページの機能の一部は順次展開中です)。ロールがエージェント間で大規模に連携する場合、プロトコル層のガバナンスが私たちの検討対象となります。 マルチエージェントA2A分析。ロール間を流れるツール呼び出しは、他の呼び出しと同様に、呼び出し前後のフックを通過します。つまり、ホップごとの検査が行われます。
種類5:ヒューマン・イン・ザ・ループ(HITL)エージェント
概要
このコラムは、自律性に関する議論を明確に修正するものです。実用的な目標は「最大限の自律性」ではなく「選択的な自動化」にあります。エージェントが機械的な80%の作業を処理し、重要な局面では人間の判断が介在します。ムーディーズによる 600人のリスクおよびコンプライアンス専門家を対象としたグローバル調査では、42%が人間の監視は必須であると回答しました。同社のヘルスケアシステムの例では、臨床エビデンスを収集して事前承認申請書を作成し、看護ケースマネージャーが既存のワークフローツール内で数秒のうちに承認、編集、または却下を行います。また、不動産管理者のエージェントは、入居者からの空調設備の緊急事態を解析し、業者を特定して作業指示書を作成します。その後、人間がSlackで承認して初めて作業が開始され、エージェントが業者へのメール送信や入居者へのフォローアップを行い、一連のプロセスを完了させます。このコラムの経験上、懐疑的なチームを熱心な支持者に変えるのは、このアーキタイプです。

TrueFoundryの役割
これは、最も直接的な製品プリミティブを持つアーキタイプです。Agent Harnessは、HITLの核となるメカニズムを実装しています。機密性の高いツール呼び出しを一時停止し、ツール名と引数を表示し、明示的な許可または拒否があった場合にのみ再開します(ヒューマン・イン・ザ・ループのドキュメント)。これは機密性の高い操作に対してのみ設定されます。誰がリクエストを受け取るか、どこに表示されるか、どれくらい待機するか、タイムアウト後にどうなるかといった周辺のレビュー体験はワークフロー設計の範疇であり、承認は認可を置き換えるものではなく、補完するものです。設計上のリスクは人間工学にあります。数分かかるゲートは回避され、すべてにゲートを設けるとノイズになります。そのため、タスクに応じてアクセス権を付与・制限する「タスク型アクセス(Task-shaped access)」という規律が重要であり、これは私たちの TBAC分析 で展開しているモデルです。組み込みのガードレールカタログがゲートの機械的なスクリーンを提供するため、人間の注意は判断に集中できます。ツール前のフックに接続された場合、文書化された SQLサニタイザー は、ダウンストリームツールが実行する前にDROP、TRUNCATE、およびWHERE句のないDELETEをブロックできます。また、 コード安全性リンター は、同様に設定されたフック上で危険なシェルパターンを検知します(ガードレールのドキュメント) — ガードレールが存在するだけでは何もインターセプトされません。フックがアタッチされることで機能します。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.













.webp)



.png)
.png)

.png)
.png)
.png)
.png)
.png)
.png)
.png)

.png)
.png)





