7月27日、InfoQが「An Evolutionary Architecture Pattern for Managing AI's Pace of Change」と題した記事を公開した。エージェント型AIがもたらす「変化速度の非対称性」という根本課題に対し、「AIゲートウェイ」というアーキテクチャパターンで変化の速い部分を一箇所に集約する設計手法を詳しく紹介している。従来のAPIゲートウェイでは対処できない理由、policy-as-configによる実装例、そして集約によるSPOFリスクという現実的なトレードオフまで踏み込んでいる点が読みどころだ。
従来のAPIゲートウェイでは足りない理由
エンタープライズシステムは「安定性」を前提に設計されている。コアビジネスプラットフォームやインテグレーション層は、数年単位でゆっくり変化する。一方、AIエコシステムは年に何度も大型アップデートが入り、MCP（Model Context Protocol）やA2A（Agent-to-Agent）プロトコルといった新しい標準も続々と登場している。MCPはAIモデルが外部ツールやデータソースと接続するための標準プロトコル、A2AはエージェントどうしがHTTP上で相互通信するためのプロトコルだ。
この変化速度の非対称性が問題の本質だ。
「ではAPIゲートウェイで一括管理すればいいのでは」と考えるのは自然だが、記事はこの発想に明確にNOを突きつける。エージェント型AIは、従来のAPIゲートウェイが前提としていた3つの仮定をすべて破るからだ。
決定論的な動作の仮定：同じ入力に同じ出力が返ることを前提にAPIゲートウェイは設計されている。しかしエージェントは同じプロンプトでも異なる推論パスをたどり、異なるツールを選ぶ。インシデント調査が根本的に難しくなる。
失敗はスキーマレベルで起きるという仮定：APIゲートウェイは不正なトークンや欠損パラメータを検出するのは得意だが、エージェントの失敗は「意味的」だ。リクエスト自体は正しくフォーマットされており、認証も通っている。しかし「そもそもこのアクションを実行すべきではなかった」という判断は、従来のゲートウェイには不可能だ。プロンプトインジェクション、コンテキストポイズニング、ツール悪用といった攻撃手法はここから生まれる。
クライアントがアクションを事前に決定しているという仮定：通常のAPIではクライアントが実行内容を決めてリクエストを送る。エージェントはゴールを解釈し、自分でアクションを決定する。ユーザーの意図とシステムの動作の間に「間接性」が生まれ、ポリシー準拠の確認がアーキテクチャ上の課題になる。
AIゲートウェイ：変化を「一箇所に集める」パターン
記事が提案するのは、AIゲートウェイを「進化の継ぎ目（evolutionary seam）」として設計するパターンだ。最も変化の速いコンポーネント群——ガードレール、モデルルーティング、エージェントのアイデンティティ管理、アクションポリシー、監査——を一つのコントロールプレーンに集約し、その背後にある既存システムを安定させる。
/filters:no_upscale()/articles/evolutionary-architecture-pattern/en/resources/228figure-1-1784798614140.jpg)
図1：エンタープライズシステムとAIエコシステムの間の「継ぎ目」としてのAIゲートウェイ
このゲートウェイが担う機能は大きく4つに分かれる。
モデルルーティング
モデルの性能・価格・ランキングは常に変動する。最上位モデル、低コストモデル、ファインチューニング済みモデル、セルフホスト型モデルを使い分けるニーズに対し、ゲートウェイが吸収することでアプリケーション側を変更せずにモデルの入れ替えやプロバイダーフェイルオーバーが実現できる。
セキュリティ（ゼロトラスト適用）
- アイデンティティと認可：人間やサービスに対する認可の仕組みは成熟しているが、エージェントが他のエージェントに代わって行動する「委任権限（delegated authority）」はまだ不安定だ。委任チェーンをゲートウェイが保持することで、標準が改訂されても追随コストを下げられる。
- アクションポリシー：NIST SP 800-207に基づくゼロトラストをエージェントのアクションに適用し、操作ごとに最小権限チェックを行う。プロンプトインジェクションで乗っ取られたトークンが通過しても、「乗っ取られた後のアクション」を止められる。
- コンテンツガード：インジェクション検出（入力方向）と情報漏洩・有害コンテンツ検出（出力方向）を双方向で実施。回避手法は常に進化するため、各アプリに分散させると更新が遅くなる。ゲートウェイに集約することで、攻撃の進化に即時対応できる。
セマンティックログと監査
通常のログは「呼び出しが発生した」という事実しか記録しない。エージェントの非決定論的な動作を追跡するには「リクエスト→決定→アクション」という流れを記録するセマンティックログが必要だ。EU AI Actの施行で監査要件は今後さらに厳しくなる。ゲートウェイに集約すれば、保持期間の変更や新たな規制要件への対応も「N個のアプリを変更する」のではなく「1つのプレーンを変更する」だけで済む。また、生のプロンプトテキストを保存すること自体がAI Act上のリスクになるため、ゲートウェイでPIIをハッシュ化してから保存する設計も自然に実現できる。
policy-as-configによる実装
記事では「policy-as-config」というパターンを強調している。ガードレール・セグメンテーション・ルーティングルールをバージョン管理されたコンフィグとして宣言し、PRレビューを経てデプロイする。アプリケーションとは独立して変更できるこの仕組みは、OPA（Open Policy Agent）の宣言的モデルと同じ発想だ。
# code-review-agentのゲートウェイポリシー例
agent: code-review-agent
authorization:
allow:
- repo.read
- pr.comment
- static_scan.run
deny:
- repo.push
- pr.merge
- secrets.read
tools:
- github-mcp
- static_scan
guardrails:
input:
- prompt_injection_filter
output:
- secret_redaction
routing:
default: gpt-4o
fallback: self-hosted-slm
observability:
logging: semantic
セキュリティチームがポリシーを所有し、プラットフォームチームがゲートウェイを所有するという責任分担も明確になる。CSA ATF（Cloud Security Alliance Agentic Trust Framework）もこのpolicy-as-configへの移行を推奨している。
実装例としては、kgateway、Portkey、LiteLLMがすでにこのパターンの一部を実装している。
このパターンが「常に正解」ではない
記事は過度な適用に対して明確に警告している。レイテンシの増加、集約によるSPOF（単一障害点）リスク、運用オーバーヘッドは実際のコストだ。単一チーム・単一LLMの用途であれば、アプリケーション内のガードレールで十分な場合も多い。
このパターンが効果を発揮するのは、複数チームが複数モデル・複数エージェントを扱うエンタープライズ環境だ。プラットフォームエンジニアリングが成熟した組織は先行投資として導入できるが、そうでない組織はインシデント発生後に慌てて構築することになり、より高いコストを払うことになると記事は指摘している。
詳細はAn Evolutionary Architecture Pattern for Managing AI's Pace of Changeを参照していただきたい。
