AIエージェントが報酬を得るまで仕事を拒否したらどうなるか

ソフトウェア開発におけるAIエージェントの活用が急速に進んでいます。しかし、組織がこれらのローカルAIエージェントを大規模に導入すると、ガバナンスとコストの新たな課題が浮き彫りになります。本稿では、その問題と解決策としての集中プラットフォームの必要性を探ります。

ローカルAIエージェントの限界

現在、多くのAIエージェントは開発者のラップトップ上で動作し、孤立した単一エージェントループを形成しています。これは小規模では有効ですが、複数のチームと製品を持つ組織では機能しません。LLMは確率的であるため、たとえ10%の失敗率でも、大規模な反復で一部のチームがグローバルビジネスルールを迂回するコードを出荷し、アーキテクチャの乖離を引き起こします。また、これらのチェックはローカルで実行されるため、CTOやプリンシパルエンジニアは集中可観測性を失い、品質保証が困難になります。

コスト管理と内部経済

ローカル実行はコスト制御も難しくします。タスクに最適なモデルを動的に選択できないため、組織はすべての呼び出しにプレミアムを支払うことになります。集中キャッシュやインテリジェントルーティングがないため、コストは開発者数に比例して増加します。さらに、あるチームが開発した効率的なAIスキルが他チームに採用された場合、実行コストを誰が負担するのかという問題が生じます。分散モデルでは答えが出せません。

未来のプラットフォーム：A2AとAP2

これらの課題を解決するには、ローカルのブラックボックスから集中サービスへの移行が必要です。真のAIエージェントプラットフォームは、クエリを動的に処理し、モデル最適化とキャッシュでコストを制御し、部門間チャージバックのための財務台帳とアーキテクチャコンプライアンスのための監査ログを維持します。

著者は、オーケストレーションとガバナンスのためのAgent-2-Agent (A2A)プロトコルと、内部経済を処理するAgent Payment Protocol (AP2)という2つのオープンスタンダードを用いたデモを提供しています。例として、プロダクトマネージャーがローカルAIアーキテクト「Winston」を使って新アプリを設計する場面を考えます。Winstonは汎用的なアーキテクチャ知識はあるものの、組織のコンテキストを知りません。毎日5万通のトランザクションメールを送信する必要がある場合、WinstonはA2Aプロトコルを介して集中エンタープライズアーキテクチャサービスに問い合わせます。このサービスは組織の標準と再利用可能な部品の脳として機能し、自動応答します。Winstonはリクエストとともに予算上限（ceiling_credits）を送信し、AP2プロトコルによる課金をトリガーします。

このようにして、組織はAIの効率性を活用しつつ、ガバナンス、コスト管理、内部経済のバランスを取ることができます。このシフトにより、大企業は混乱を招くことなくAI駆動開発を実現できるでしょう。