TL;DR: AIエージェントは、エンタープライズソフトウェアからUIを静かに剥ぎ取っています。APIとMCPを介して公開されるデータレイヤーが、新しいプロダクトサーフェスになりつつあります。APIチームが今四半期に行うべき5つの変更点と、まだ誰も解決していない1つの問題点。
かつて、ユーザーインターフェースはB2Bソフトウェアにおける最も深い参入障壁でした。営業担当者はSalesforceで、サポートチームはZendeskで、調達チームはSAPで仕事をしていました。アクセス頻度、筋肉の記憶、フォームを通じてすべての入力を強制することでデータ衛生を徹底するインターフェースのあり方、それが参入障壁でした。その過程で保存されたのがデータでした。
その時代は終わりを告げています。AIエージェントは、ブラウザを開くことなく、APIを通じてエンタープライズデータを直接読み書きできるようになりました。Salesforceはすでに、データレイヤーをエージェントに公開するヘッドレス製品を発表しています。他のシステム・オブ・レコードも、数年遅れではなく、数週間遅れで追随しています。UIがもはや参入障壁ではないのなら、APIがそれになります。これはAPIがどうあるべきかを変えることになります。
「ヘッドレスソフトウェア」が実際に意味すること
ヘッドレスソフトウェアとは、APIを通じてデータレイヤーを公開し、エージェントが直接読み書きできるようにするエンタープライズソフトウェアです。UIがなくなるわけではありません。UIが唯一の入り口ではなくなるだけです。
これは「APIファースト」（設計手法）や「ヘッドレスCMS」（コンテンツアーキテクチャ）とは異なります。これらはソフトウェアの構築方法を説明するものです。ヘッドレスソフトウェアは、消費者のシフトを説明します。データを読み書きするものが、ブラウザを持った人間ではなくなったのです。それは、MCPアクセスと目的を持ったエージェントです。
LLMが監視なしでツールを計画・選択できるようになったこと、MCPがエージェントが外部システムを発見する方法を標準化したこと、そしてデータ抽出が非常に安価になり、APIを囲い込んでもその下のものを保護できなくなったこと、これら3つの要素が同時に可能になりました。
APIが、開発者が一度クライアントを作成し、そのクライアントを人が毎日使用することを前提に設計されている場合、やるべき作業があります。
もはや通用しない5つの定着要因
歴史的に、エンタープライズシステムを定着させてきた5つの要因がありました。それぞれをエージェントの視点で見ると、そのほとんどが崩壊します。
アクセス頻度は、筋肉の記憶を通じてユーザーを縛り付けていました。営業担当者は何年もの間、1日に8回Salesforceにログインしていました。エージェントには筋肉がなく、ツールを切り替えるコストは設定ファイルを編集するコストでしかありません。
読み書きワークフローは、データが常に動いているため、移行を危険なものにしていました。エージェントは機械の速度で読み書きします。コントラクトが安定している限り、APIの背後にあるデータベースが何であっても気にしません。
文書化されていないSOPとは、「10万ドルを超える取引にはVPの承認が必要」といった、誰も書き留めていないルールです。エージェントがこれをナビゲートするのは依然として困難であり、既存企業に息抜きの余地を与えています。しかし、ワークフローを実行するすべてのエージェントはルールを学習し、ルールはどこかに読み取り可能な形でエンコードされていきます。
内部の習慣ループ、つまりチームの日常業務がエージェントを介して流れるようになると、チーム全員が共有するツールを中心に形成されていた朝会のようなものも解消されます。
コンプライアンスの重要性は、依然として残っています。規制リスクは、人間がデータを移動させたかエージェントが移動させたかを問いません。監査証跡は依然として存在する必要があります。これについては後ほど説明します。
5つの参入障壁のうち4つが弱まっています。5つ目は、新たな防御力が生まれる接点です。
APIチームが今四半期に行うべき5つの変更点
APIが新しいプロダクトサーフェスであるなら、何が変わる必要があるでしょうか。
1. APIを配管ではなく、プロダクトサーフェスとして扱う
「フロントエンドが呼び出すため」に存在するRESTエンドポイントと、エージェントが推論し、呼び出すことを選択するRESTエンドポイントは、異なる成果物です。前者は一貫性がなく、文書化されておらず、今四半期にUIが必要としたものによって形成される可能性があります。後者はそうではありません。
AIエージェント向けにAPIを設計する場合、コントラクトがインターフェースである必要があります。これは、記述的な名前、予測可能な形状、コンテキストによって3つの異なる意味を持つ多重定義されたフィールドがないこと、モデルがアクションを起こせる言語で何が間違っていたかを伝えるエラーレスポンスを意味します。「400 Bad Request」では不十分です。「400: 必須フィールドcustomer_idがありません。この請求書が属する顧客のIDを渡してください」であれば十分です。
最終テスト：有能なエージェントが、OpenAPI仕様とフィールド記述書のみで、あなたのAPIを正確に呼び出すことができるか？エンドポイントが何をするかを理解するために古いUIのソースも読む必要があるなら、APIはまだ配管に過ぎません。
2. RESTとGraphQLに加えてMCPを出荷する
RESTは、エージェントがAPIの存在を知った後でそれを呼び出す方法です。MCPは、そもそもAPIが何ができるかを発見する方法です。MCPサーバーのないREST APIは、robots.txtやサイトマップのないウェブサイトのようなものです。技術的には呼び出し可能ですが、それに到達したいシステムにとっては実質的に見えません。
これは既存のAPIサーフェスを置き換える問題ではありません。RESTを維持してください。GraphQLがあるならそれも維持してください。Anthropic MCP仕様がコントラクトをカバーし、Apidogがそれに関連して行われるべきテストとドキュメント作業をカバーする、エージェントがすでに話しているプロトコルを通じて同じ機能を提供する第三のダイアレクトとしてMCPを追加してください。
MCPとは何か、そしてAPIチームにとってなぜ重要なのかについて基本的な情報を知りたい場合は、私たちの詳細な解説をご覧ください。
3. CRUDオブジェクトではなく、意図と成果を中心にスキーマを再設計する
Salesforceのデータモデルには、機会、リード、アカウント、連絡先があります。エージェントはこれらの名詞では考えません。エージェントは目標で考えます。「解約寸前のアカウントをすべて見つける」「昨日のクローズドディールに対する提案書を作成する」「夜間にP0チケットを開いたアカウントをエスカレートする」などです。
次世代のシステム・オブ・レコードは、2000年代初頭からモデリングしてきたCRUDオブジェクトではなく、タスク、意図、スレッド、ポリシー、成果を中心に構築されるでしょう。
これは、スキーマを一晩で書き換えることを意味するわけではありません。その上にレイヤーを追加することを意味します。「このリードは購入する」という情報を取得し、エージェントが3つの別々の書き込みを強制される代わりに、適切な機会＋活動＋タスクレコードを返す/intents/captureエンドポイントなどです。意図がAPIになり、CRUDは実装の詳細になります。
AIエージェントに対応するためのAPIに関するウォークスルーで、これらのパターンについてさらに詳しく説明しています。
4. エージェントのIDとスコープ付き権限を解決する
これはまだ誰も完全に解決していない問題であり、この後別のセクションを設けて説明します。簡単に言うと、すべてのエージェント呼び出しには、ユーザーのものではないIDと、ユーザーのものではない権限にスコープされたIDが必要であり、別個の行動クラスとして監査される必要があります。「アリスがボタンをクリックした」と「アリスのエージェントが彼女に代わって午前3時に彼女が寝ている間にボタンをクリックした」の違いをAPIが区別できない場合、問題があります。
現在のパターンについては、MCPセキュリティポリシーを参照してください。
5. 監査証跡とクローズドループフィードバックを備えたアクションレイヤーを構築する
新しい防御力はレコードを保存することにはありません。それはアクションを実行し、結果を把握し、そのフィードバックを利用して将来の意思決定を改善することにあります。CRMデータを保持するSaaS製品は、UIを備えたデータベースです。代わりにアクションを実行し、何が起こったかを観察し、時間をかけてそのアクションが改善されるSaaS製品は、まったく別のものです。
APIチームにとって、これは3つの変更を意味します。アクションエンドポイントには、エージェントが何が起こったかを学習できるように、結果のコールバックまたはウェブフックが必要です。すべてのアクションは再生可能でなければなりません。そうでないと、エージェントが何をしたかをデバッグできません。そして、すべてのアクションには、入力、出力、エージェントのID、そして可能であれば推論のトレースを含む監査行が必要です。
データを失うことなくエージェントワークフローをテストするは、この変化の運用版です。
未解決の部分：エージェントの権限付与
エージェント対応ソフトウェアのギャップの中で、これは最も未解決で最も重要なものです。どのエージェントが、誰に代わって、どのような監査可能性で何を行うことを許可されているのでしょうか？
2026年時点での正直な答えは、ほとんど誰もこれをうまく実装していないということです。OAuthは委任されたユーザーアクセス用に構築されており、エージェント用ではありません。RBACは人間の役割用に構築されました。監査ログはユーザーが何をしたかを追跡するために構築されたものであり、どのユーザーのエージェントがどのようなポリシーの下で何をしたかを追跡するためではありません。
標準が確立される前から、現在機能している4つのパターンが出現しています。
- エージェントのIDごとのスコープ付きトークン。ユーザーのセッショントークンを、ユーザーに代わって動作するエージェントのために再利用しないでください。ユーザーの全権限よりも狭い場合でも、別途のスコープを持つ別のトークンを発行し、それを独立してローテーションさせます。トークンが漏洩した場合、ユーザーではなくエージェントを失効させます。
- すべてのリクエストに委任メタデータを含める。すべてのAPI呼び出しには、
X-Acting-On-Behalf-Of: user_idおよびX-Agent-Identity: agent_name@versionのようなヘッダーを含めるべきです。2つの追加ヘッダーだけで、エンドポイントロジックには変更がなく、監査のストーリーが10倍良くなります。 - エージェントアクションの追加専用監査ログ。エージェントアクションは、ユーザーアクションとは別の監査テーブルに属します。クエリパターンが異なります。コンプライアンスチームは、人間の活動をスクロールすることなく「今週エージェントは何をしたか」という質問に答えたいと思うでしょう。
- コードとしてのポリシー。各エージェントクラスが何を行うことを許可されているかを、バージョン管理された設定ファイルで宣言します。「カスタマーサポートエージェントは請求書を読み取り、最大50ドルまで払い戻すことができるが、アカウントを削除することはできない。」これをチェックインし、テストし、差分を確認します。権限ポリシーはWikiページではなく、ビルド成果物であるべきです。
これらはいずれも完成した標準ではありません。しかし、これらすべては今すぐ出荷可能です。
Apidogが貢献できること
APIをプロダクトとして扱うなら、設計、コントラクト、モック、MCP、テスト、監査を1か所で処理できるワークベンチが必要です。これこそが、私たちがApidogを構築した目的であり、これら5つの変化は、Apidogがすでにサポートしている作業と明確に一致します。
- 変化1（APIをプロダクトとして）：スキーマファースト設計と自動生成されたドキュメントにより、コントラクトがエージェントが読む単一の真実の情報源となります。
- 変化2（RESTと並行してMCPを）：出荷前にMCPサーバーを検証するための専用のMCPサーバーテストツール。
- 変化3（意図に基づいたAPI）：動的レスポンスを伴うモックにより、バックエンドが存在する前に意図エンドポイントをプロトタイプ化し、エージェントクライアントにそれを呼び出させることができます。
- 変化4（権限付与）：エージェントトークンとユーザートークンを分離するための環境管理と、ポリシー強制のためのアサーションテスト。
- 変化5（アクションレイヤー＋監査）：4月に出荷されたAI Agent DebuggerおよびA2A Debuggerにより、エージェント駆動のAPI呼び出しをエンドツーエンドでトレース、リプレイ、アサートできます。
まだ試したことがない場合は、Apidogをダウンロードして、既存のOpenAPI仕様を実行してみてください。モックサーバーだけでも、通常は移行費用を賄うことができます。
賭け
APIチームが今すぐ行うべき賭けは単純です。API自体がプロダクトです。それが配管であるなら、それはコモディティです。それがエージェントが推論し、選択し、信頼し、行動する表面であるなら、それが参入障壁となります。
今四半期に出荷するチームは、5年前に構築されたものとはまったく異なるAPIサーフェスを持つことになるでしょう。待機するチームは、主要な顧客がエージェント統合が「正しく機能しなかった」理由を尋ねた後、2027年に期限に追われてそれを書き直すことになるでしょう。