6月26日、Postmanが「How we really build production-grade AI agents: beyond models, toward data and API quality」と題した記事を公開した。デモでは動くが本番に投入した途端に壊れる——AIエージェント開発の現場で繰り返されるこの失敗の原因は、モデルの性能ではなく、データ品質とAPI品質にある。本番環境での成否を左右するシステム設計の現場知見をまとめた内容だ。
「モデルを良くすれば良くなる」という誤解
Postmanはその原因を明確に指摘する。チームはモデルの賢さに過剰投資し、システムの品質に過少投資している。本番環境でのエージェントの性能は、モデルの能力ではなく、次の3つの連動するシステムによって決まる。
- データ品質（モデルが推論に使う情報の質）
- API品質（エージェントが確実に実行できる操作の質）
- 実行品質（意思決定の検証・観測・制御の仕組み）
エージェントが失敗するとき、「推論できなかった」ケースはまれだ。多くは「APIのスキーマが曖昧だった」「返ってきたデータが古かった」「アクションを検証するガードレールが存在しなかった」というインターフェース上の失敗である。
APIは「統合ポイント」ではなく「エージェントの行動空間」
Postmanがとくに強調するのが、APIをエージェント向けに設計し直すという発想だ。
従来、APIは開発者が叩くものだった。エージェント時代には、APIは自律システムが使うものになる。この前提が変わると、APIに求められる要件も変わる。
いわゆる「エージェント対応API」の条件として、記事は以下を挙げる。
- 意味的に明示的：意図・制約・エッジケースが明確
- 機械解釈可能：型付きの入出力と具体的なサンプル
- 可能な限り決定論的：隠れた副作用を最小化
- 観測可能：すべての呼び出しがトレース・検査できる
- ガバナンス済み：アクセス制御・レート制限・ポリシーが一貫して適用される
Model Context Protocol（MCP）はこの方向性の一例として言及されている。モデルが自然言語の説明からAPIの意図を推測するのではなく、構造化されたケイパビリティを直接公開するアプローチだ。MCPの詳細な仕様については公式ドキュメントも参照されたい。また、Postman自身が提供するAgent Modeも、APIを構造化された形でエージェントに公開するための実装例として位置づけられている。
そして記事の核心をついた一文がある。
「新しいエンジニアがAPIの仕様書だけを見て確実に使えないなら、エージェントにも使えない。モデルを変えても解決しない。」
データ品質：多段推論チェーンでエラーは連鎖する
データの話も同様に具体的だ。マルチステップのエージェントワークフローでは、1つの曖昧なフィールドや欠損した制約が、計画・ツール選択・実行の全段階にわたって連鎖する。
高パフォーマンスなエージェントシステムが備えるデータの特性として、以下が挙げられている。
- サービスをまたいだ正規化されたスキーマ（意味のドリフトなし）
- フィールド名だけでなくリッチなメタデータと説明
- バージョン管理とリネージトラッキング
- NULL値・範囲・信頼度など不確実性の明示的な取り扱い
- 本番のエッジケースを反映した現実的なサンプル
記事はこう整理する。
「学習データの品質はエージェントが何を知っているかを決める。データとAPIの品質は、それが今この瞬間も正しいかどうかを決める。」
ガバナンスと「ヒューマン・イン・ザ・ループ」は妥協ではなく設計原則
「完全自律」を目標にするチームは多いが、Postmanの観察では最も堅牢なシステムは別のパターンを採る。
- 人間が意図と制約を定義する
- エージェントが構造化された実行を行う
- システムが結果を検証する
- 必要に応じて人間が承認・上書きする
これは暫定的な妥協ではなく、安定したアーキテクチャだと記事は言う。現実の環境は常に不完全で変化し続けるため、完全自律のエージェントは脆くなる。人間の監督がモデルでは代替できない適応層として機能する。
ガバナンスの要件として挙げられているのは、意思決定と操作の完全な監査証跡、デバッグのための決定論的リプレイ、実行前のポリシー適用、高インパクトな変更への人間承認など。ガバナンスを省いたチームは「最初の深刻なインシデントのあとに必ずデプロイをロールバックする」と記事は指摘する。AIエージェントのガバナンス設計については、NIST AI RMFなども参考になる。
実践で効果があったパターン
記事が挙げる、スケールでエージェントを展開しているチームに共通するパターンは以下の通りだ。
- 汎用エージェントより、単一の高品質ワークフローから始める。PostmanのAgent Modeは「APIアシスタント」より、厳密なスキーマでAPIテストを生成・検証するモードの方が性能が高い。スコープを絞ることで、データとAPIの品質を管理しやすい単位に収められる。
- APIの改善をエージェント最適化として扱う。一貫性のないパラメータ名を修正する方が、モデルを乗り換えるより効果が大きいケースが多い。エージェントの挙動を変えたいなら、まずAPIのスキーマを見直すのが先決だということだ。
- 評価はプロンプトではなくシステムメトリクスで行う。レイテンシ・成功率・ロールバック頻度・エラー伝播がベンチマークスコアより重要だ。これらのメトリクスは本番の挙動を直接反映するため、モデルの評価スコアより実態に即した判断基準となる。
まとめ
AIエージェント開発で今最もレバレッジが高い作業は、プロンプトエンジニアリングでもモデル選定でもない。データの整理と構造化、APIの明示性・一貫性・機械可読性の向上、すべての実行パスへの観測性とガバナンスの追加——この3点に尽きる。
詳細はHow we really build production-grade AI agents: beyond models, toward data and API qualityを参照していただきたい。
