8月18日、Postmanが「4 Infrastructure Layers Every Production AI Agent Needs」と題した記事を公開した。この記事では、本番環境でAIエージェントを安定稼働させるために必要な4つのインフラ層について詳しく紹介されている。

「デモは動く。本番は壊れる」の正体

AIエージェントを構築したことがあるチームなら、この経験に心当たりがあるはずだ。デモでは正しいAPIを呼び出し、納得感のある回答が返ってくる。ところが実システム・実データに投入した瞬間、モデルとは無関係な理由で崩壊する。

• 社内に似た名前のサービスが十数個あり、どれが正しいエンドポイントか判断できない
• 6ヶ月前に変更されたエンドポイントを、古い参照情報をもとに呼び続ける
• タスクに不要な権限を持つ認証情報が設定ファイルに平文で置かれている
• 先週エージェントが何をしたか、今月いくらかかっているか、誰も把握していない

Postmanはこれを「モデルの問題ではなく、インフラの問題」と整理する。人間の開発者向けには20年かけてAPI基盤を整備してきた。今度はエージェントがAPIを呼ぶ側になっており、その下のインフラが追いついていない、というのが記事の出発点だ。

4つのインフラ層

Layer 1（最重要）：エージェントが推論できる「記録の源泉」

最も地味で、最も軽視されやすく、最も他の層が依存している土台がこれだ。

人間なら「あのSlackスレッド見た？」「◯◯さんに聞けばわかる」でルーティングできる。エージェントにはそれができない。APIの所在が構造化されていなければ、「見つけられない」か「自信満々に間違ったAPIを使う」かのどちらかになる。

Postmanはこの状態を「コンテキスト債務（context debt）」と呼び、解決策としてContext Graphを提供する。組織内の全API・サービス・契約・依存関係をリアルタイムで更新し続けるライブインデックスで、「どの決済APIが正規で、誰がオーナーで、変更したら何が壊れるか」を常に一意に返せる。

外部ツールとの接続は**Postman MCP Server**経由で実現する。Model Context Protocol（MCP）に対応しており、Claude CodeやCursorなどのツールから組織のAPIカタログを直接参照できる。ソースコードはGitHubで公開されている。

この層がなければ、残りの3層は「間違ったAPIに対して、型付きで、スコープ済みで、可観測な呼び出し」をするだけになる。

Layer 2：機械が読めるAPIの発見可能性

人間向けに書かれたAPI仕様（散文的な説明、緩いスキーマ、暗黙の推論を前提とした記述）は、モデルには構造的に不透明だ。エージェントはパラメータを推測し、存在しないフィールドをハルシネーションし、理解できていないスキーマに対してリトライを繰り返す。

人間スケールのリクエスト量なら単なる手間だが、1ワークフローで数百回呼び出すエージェントスケールでは信頼性の問題に直結する。

この層の解決策として記事が挙げるのが**Fern**だ。PostmanのプロダクトではなくサードパーティのOSSツールだが、記事ではこの層の実装例として紹介されている。APIサーフェスを型付きの機械可読フォーマットと強く型付けされたSDKに変換することで、モデルが散文から推測するのではなく直接パースできるようにする。MCPの仕様自体が「ツール定義は自由テキストではなく構造化・発見可能でなければならない」という設計になっているのも、同じ問題意識からだ。

Layer 3：委任・動的アイデンティティのためのアクセス制御

従来のAPIゲートウェイと認証情報管理は、人間型のトラフィックを前提に設計されている。既知のクライアント、予測可能なアクセスパターン、デプロイ時に一度スコープを決めてほぼ変更しない認証情報——エージェントシステムはこの3つの前提をすべて同時に破る。

問題の深刻さについて、記事は**GitGuardianの「State of Secrets Sprawl」報告書のデータを引用している。AIアシスト開発のコミットにおけるハードコードされたシークレットの漏洩率は、人間のみの開発の2倍超に達している**というものだ。

Postmanの解法は2つのコンポーネントで構成される：

• Fabric Gateway：自社クラウド内にデプロイするコントロールプレーン。モデル・MCPサーバー・エージェント・内部APIを横断してトラフィックのルーティングとポリシー適用を行う
• Postman Passport：認証情報レイヤー。実際のAPIキーを配布する代わりに「クレデンシャル参照（credential reference）」を発行する。これは特定のアイデンティティに紐付いたトークンで、対応する秘密鍵なしには無効だ。実際のAPIキーはVPC内に留まり、エージェントの推論層やログには一切触れない

認証情報が漏洩した後にキーをローテーションするのではなく、漏洩しても悪用できない設計にする、というアプローチだ。エージェントは深夜3時に誰も監視していない状態でプロンプトインジェクションにさらされる可能性があり、その前提でのセキュリティ設計が求められる。

Layer 4：エージェントを含む「チーム」の運用管理

最初の3層が揃っても、現在何台のエージェントが動いているか、そのコンピュートコストが見合っているか、半年前に構築されたエージェントがいつ壊れたか——誰も把握できない、という問題が残る。

同じエージェントを3チームが独立して作り直す事態も起きる。エージェントにはオンコール当番が存在しないからだ。

Postmanはこの問題に**Astro**で対応する。こちらもPostman製品ではなく、記事が参照するサードパーティのプラットフォームだ。エージェントのデプロイ・パフォーマンス追跡・コスト可視化・共有レジストリ・再利用可能なブループリントを一元管理する。ベンチマークスコアではなく本番での実際の挙動に基づいたチューニングと、エージェント・モデル・チーム別のコスト内訳を提供する。

4層の対応関係

どこから始めるか

記事の著者は優先順位を明確に示している。

まず Layer 1（記録の源泉）から始める。最も地味で最もスキップされやすいが、他の3層がすべてこれを前提にしている。

次は Layer 3（アクセス制御）を Layer 2（発見可能性）や Layer 4（運用管理）より優先する。APIサーフェスがわかりにくければエージェントは遅くなるだけだが、認証情報が漏洩すれば本番インシデントになる。コストの非対称性が理由だ。

どのプラットフォームを採用するにしても、まずModel Context Protocolの仕様を把握しておくことを記事は勧めている。特定ベンダーに依存しないオープンスタンダードであるためだ。

詳細は4 Infrastructure Layers Every Production AI Agent Needsを参照していただきたい。