Baptiste Parravicini氏は、テクノロジー投資家であり、世界有数のAPIカンファレンスシリーズであるapidaysの共同創業者兼CEOである。
10年以上にわたり、API（Application Programming Interface）はデジタルイノベーションの基盤として機能してきた。APIは企業がシステムを接続し、プラットフォームを構築し、デジタル製品の提供を加速することを可能にしてきた。しかし、ほとんどのAPIは、非常に特定の利用者、すなわち人間の開発者を念頭に置いて設計されていた。
開発者はドキュメントを読み、ワークフローを解釈し、意図的にAPIリクエストを構築する。高度に自動化された環境においても、統合パターンは依然としてこの人間中心のモデルを反映している。したがって、エンジニアは事前定義されたロジックに従ってAPIを呼び出すアプリケーションを構築し、それらのアプリケーションは開発時に設定された境界内で動作する。
しかし、AIエージェントの急速な台頭が、このパラダイムを変え始めている。
APIの使用方法の再定義
AIエージェントは、単に事前に決められた指示を実行するスクリプトではない。むしろ、目標を解釈し、利用可能なツールを評価し、異なるシステム間で複数のAPI呼び出しを調整することができる。単一のリクエストを実行するのではなく、エージェントは、特定の目的を達成するために複数のAPIへの問い合わせ、複数のサービスからの情報収集、プラットフォーム間でのアクション調整が必要であると判断する可能性がある。
この変化は微妙だが重要である。APIはもはや、開発者が構築したアプリケーションによってのみ利用されるものではない。APIは今や、いつ、どのようにそれらのAPIと相互作用するかを自律的に判断できるシステムによってアクセスされるようになっている。
新たな調整レイヤーの出現
いくつかの新興アプローチが、AIシステムがAPIとどのように相互作用すべきかを定義することで、この変化に対処しようとしている。
今日最も話題になっている展開の1つは、モデルコンテキストプロトコル（MCP）のようなプロトコルの出現と、エージェントがAPIと相互作用する方法を標準化するより広範な取り組みである。しかし、私が各種カンファレンスで見ている限り、この議論はやや誤った枠組みで行われている。
これらのプロトコルは、APIを即座に""エージェント対応""にするクリーンな抽象化レイヤーとして提示されることが多い。実際には、それらは解決策というよりも、強制的な機能である。それらは、現在のAPI設計におけるギャップを露呈させる。
例えば、MCPは、エージェントが機能を発見し相互作用するための、より構造化された機械可読な方法を導入する。これは方向性として重要である。しかし、基盤となるAPIにおける明確性、一貫性、意図の必要性を取り除くものではない。実際には、基準を引き上げるものである。
同様に、エージェント間（A2A）およびエージェント対人間（A2H）の相互作用に関する新興パターンは、全く新しいシステムを定義することよりも、以前は暗黙的であったか、アプリケーション層で処理されていた調整を形式化することに関するものである。
実際に起こっていることは次のとおりである。私たちは、実行（API）と調整（エージェントとプロトコル）を分離し始めている。その調整レイヤーは現実のものだが、まだ初期段階であり、ほとんどの物語が示唆するよりも脆弱である。私が見る限り、それは制御された環境ではうまく機能するが、APIが一貫性がなく、不十分に記述されているか、発見のために設計されていない場合、すぐに破綻する。
したがって、これらのプロトコルは重要であるが、近道ではない。それらは増幅器である。優れたAPI設計と劣悪なAPI設計の両方を増幅するものである。
APIは依然として基盤である
私は、APIがデジタル機能とデータが公開される主要なメカニズムであり続けると考えている。変化しているのは、自律システムが関与する場合に、それらの機能がどのように発見され、調整され、統制されるかである。
実際、私は、AIエージェントの台頭が、適切に設計されたAPIの重要性を高める可能性が高いと考えている。開発者がAPIと相互作用する場合、彼らは曖昧なドキュメントを解釈し、予期しない応答をトラブルシューティングし、それに応じて実装を調整することができる。
しかし、自律型エージェントは、構造化されたシグナルと予測可能な動作に大きく依存している。APIに明確な意図、一貫した命名規則、または信頼できる応答が欠けている場合、自動化されたワークフローはその機能を誤って解釈したり、意図しないリクエストを生成したりする可能性がある。設計が不十分なAPIは、マシン速度でリクエストを生成できるシステムによってアクセスされる場合、運用上のリスクをもたらす。
組織にとって、これはAPIの明確性、一貫性、ガバナンスにより重点を置くことを意味する。
マシン駆動型相互作用のガバナンス
APIガバナンスは、既知の利用者、予測可能な使用、事前定義されたワークフローを中心に構築されていた。エージェントはこれら3つすべてを破壊する。現在、動的なクライアント、非決定論的な呼び出しパターン、創発的なワークフローが存在する。
これにより、新たなリスク領域が生まれる。1つの誤解は、ID・アクセス管理で十分だというものである。真の課題は、意図と説明責任である。エージェントがAPI呼び出しを連鎖させ、ビジネス成果をトリガーする場合、次のことを知る必要がある。
- 誰がそれを開始したか
- どのような文脈の下で
- どの決定に基づいて
それがなければ、ガバナンスはなく、リスクエクスポージャーがあるだけである。
完全な自律性は、ほとんどの企業における目標ではない。代わりに、私たちは、高リスクアクションに対する人間のチェックポイントを伴う、制限された自律性を目にしている。
API成熟度の次の段階への準備
今、リーダーシップチームが犯している1つの間違いがあるとすれば、それはAIエージェントをフロントエンドのイノベーションとして扱い、API設計の問題として扱っていないことである。コパイロットやチャットインターフェースには多くの焦点が当てられているが、APIが自律的な使用をサポートできるかどうかについてはほとんど注目されていない。
そして、そこで物事は破綻する。エージェントは開発者のように振る舞わない。彼らは曖昧さを解決したり、意図された経路に従ったりしない。彼らは探索し、組み合わせ、APIを誤用する。
したがって、真の問題は""私たちはエージェントの準備ができているか""ではない。""私たちのAPIは、予測不可能なマシン駆動型の使用に対して回復力があるか""である。
調整レイヤーは出現するだろうが、それはどこでも機能するわけではない。それは、適切に統制されたプラットフォームと標準化されたエコシステムでのみ成功する。逆に、断片化されたシステムと一貫性のないAPIでは苦戦するだろう。
私たちは、意図的な消費から動的な探索へと移行している。これはすでに、API設計における弱点を露呈している。勝者は、エージェントを最も速く採用する者ではなく、強固なAPI基盤を持つ者となるだろう。
API経済の次の段階
言い換えれば、エージェントはAPIを置き換えるのではなく、ストレステストを行う。単一のリクエストの代わりに、彼らは次のことを行う。
• エンドポイントを連鎖させる
• 再試行し、調査する
• サービスを組み合わせる
新しいインターフェースを超えて、それは新しい行動パターンである。私は、ほとんどの組織がこの変化の規模をまだ過小評価していると見ている。
