社内APIをChatGPTやClaudeなどのAIエージェント（人間の代わりに判断・操作を行うAIの実行単位）から呼び出せるようにしたいという相談は、業務システムの現場でも増えています。ここでは既存のREST APIをエージェント経由で使わせる際に発生しやすい技術的な落とし穴を、保守運用の観点から整理します。
背景にあるのはMCP（Model Context Protocol、AIエージェントが外部ツールやAPIを呼び出すための共通規格）の普及です。Anthropicが提唱し、Claude・ChatGPT・Le Chatなど主要なアシスタントが対応を進めています。ユーティリティAPI群を提供するApyHubというサービスが、自社APIをMCPサーバー化して公開registryに登録した経験から、共通して起きる3つの問題を報告しています。
何が起きているのか
最初に押さえておきたいのは「二重管理問題」です。
APIをMCP経由でエージェントに公開しようとすると、既存のREST APIの仕様（リクエスト・レスポンス・認証方式）とは別に、MCPサーバー用の定義をもう一つ手で書く必要が出てきます。
エンドポイントを1つ変更すると、REST側とMCP側の両方を更新しなければなりません。片方を更新し忘れると、エージェントがリリース後に初めて壊れたコールを送ってきて発覚する、という事故が起こります。
これは目新しい問題ではありません。SOAP時代のWSDLとドキュメントの不整合、GraphQLのスキーマとリゾルバのズレなど、インターフェース定義を二重に持つシステムには常に付きまとう保守コストです。MCP導入はこの古典的な問題を新しい形で再演していると理解すると見通しが良くなります。
3つの利用パターンを切り分ける
「AIエージェントからのAPI利用」と一括りにすると対策を誤ります。実際には呼び出し元が誰かで性質が大きく異なります。
パターン1: 自分たちのコーディングエージェントが自分のAPIをデバッグする
ChatアプリのCheckout処理が400エラーを返し、Claude Codeにデバッグを依頼する場面を想像してください。従来はエラーログやcurlコマンドを人間がコピペし、エージェントは推測でヘッダーやトークンの在り処を聞き返します。
理想は、リポジトリ内に既にあるAPIリクエスト定義をエージェントがそのまま実行できることです。ApyHubではVoidenというオープンソースのAPIツールを使い、Markdownファイルとして保存されたリクエストをエージェントが直接叩けるようにしています。これにより実際のエンドポイントを呼び、実際のレスポンスから欠けているヘッダーを自力で特定できるようになります。
このパターンは開発環境内で完結し、信頼境界（trust boundary、どこまでを信頼して権限を渡すかの範囲）が狭いため比較的リスクは低めです。ただし本番用の認証情報が開発環境に残っている場合は、この前提が崩れる点に注意が必要です。
パターン2: 社外・他チームのエージェントが特定の1エンドポイントだけ呼ぶ
サポート用アシスタントが返金処理だけ実行できるようにしたい、というケースです。これまでの一般的な対応は、SDKを選定し、入力スキーマを再定義し、認証を組み、シークレット管理を別途構築し、専用のMCPサーバーをホスティングするというものでした。
この結果、既存APIとは別の「もう一つのコードベース」が生まれ、フィールド名がリネームされてもMCP側の定義が追随せず、静かにドリフト（仕様のズレ）していきます。
対策として有効なのは、既にテスト済みのリクエスト定義そのものを「ツール」としてマークし、エージェントが変更できる値（例: 注文ID)のみを明示的に許可する方式です。シークレットは環境変数側に残し、明示的にマークしない限り何も公開されない、という opt-in（オプトイン、明示的に許可したものだけ有効にする方式）を既定にするのが安全側の判断です。
さらに一歩進んだ運用として「テストが通っている間だけツールを有効にする」というルールがあります。テストが赤くなった瞬間にエージェントからのアクセスを止める、という考え方です。フレーキー（不安定で時々失敗する）なテストがあると煩わしくなりますが、検証されていないエンドポイントをエージェントに叩かせるリスクと比べれば妥当な選択と言えます。
パターン3: 自社または他社のMCPサーバーそのものをテストする
MCPサーバーをリリース前に検証したい、あるいは他社（例: Notion）のMCPサーバーを使う前に挙動を確認したいというケースです。従来はInspector（MCPの動作確認用ツール）タブを開いてクリックし、JSONを目で読んで閉じる、という手作業に依存していました。
これをREST APIのテストと同じ扱いにする、つまりMCP呼び出しをファイルに保存し、アサーション（期待値の検証）を書いてCI（継続的インテグレーション、コード変更時に自動テストを実行する仕組み）に組み込む、というのが現実的な対策です。
自社の状況を確認する具体的な手順
実際に手を動かして確認できるポイントを挙げます。
- 現在AIエージェントから呼ばれているAPIエンドポイントの一覧を、アクセスログのUser-AgentやクライアントIDから洗い出す
- MCPサーバーを自作している場合、そのリポジトリと本体APIのリポジトリが別管理になっていないか確認する
- MCP用の定義とREST用の定義を、CIの同一パイプラインで整合性チェックしているか確認する（片方だけ更新されるリリースがないか）
- 返金やデータ削除など不可逆な操作をエージェントに公開している場合、その操作のテストカバレッジが十分か確認する
- 本番のシークレットが開発用エージェントの実行環境に混在していないか確認する
# エージェント経由のアクセスをログから粗く確認する例
grep -i "claude\|gpt\|mcp" access.log | awk '{print $7}' | sort | uniq -c | sort -rnまとめ
AIエージェントからのAPI呼び出しは、社内デバッグ用・社外連携用・サーバー検証用の3つに分けて対策を考えると整理しやすくなります。
二重管理を避けるには、既存のREST定義やテストをそのままMCPのツール定義として再利用する発想が有効です。手で二重に書く運用は、変更のたびに片方を忘れるリスクを常に抱えます。
返金処理のような不可逆操作を公開する場合は、opt-inを基本にし、テストが通っている間だけ有効にする運用を検討する価値があります。
まずは自社のAPIアクセスログを確認し、エージェント経由の呼び出しがどのエンドポイントに集中しているかを把握するところから始めてみてください。