「つなぐだけ」の時代の終わり。Function calling と MCP で変わる接続設計

Function calling（ファンクションコーリング）とMCP（Model Context Protocol）の登場で、AIは「質問に答える」存在から「システムを操作する」存在に変わりました。技術的な変化は単純ですが、これに対応した接続設計をしないと、権限管理・監査・障害対応で後から大きな手戻りが発生します。

Function callingは2023年6月13日、OpenAIがGPT-3.5-turboとGPT-4で発表しました。開発者が関数シグネチャを記述しておくと、モデルが「いつその関数を呼ぶべきか」を判断し、準拠したJSONを返す仕組みです。「自然言語 → 構造化されたツール呼び出し」という変換が実現し、外部API呼び出し・データベースクエリ・社内システムとの連携が初めて安定的に実装できるようになりました。

Function callingが「1対1の接続」を実現したとすれば、次の課題は接続の数でした。M個のAIモデルとN個のツールが存在すると、素朴な統合ではMN通りの実装が必要になります。2024年11月25日、AnthropicはこのM×N問題を解決するためにオープン標準「MCP（Model Context Protocol）」を発表しました。MCPはAIアシスタントとデータが存在するシステムを繋ぐ共通プロトコルで、ローンチ時の初期採用はBlockとApolloで、Zed・Replit・Codeium・Sourcegraphが対応を表明、Google Drive・Slack・GitHub・Git・PostgreSQL向け公式サーバーが同時提供されました。その後の採用は急速に広がります。2025年3月にOpenAIがAgents SDK（Python）でMCPをネイティブサポートし、同年5月のGoogle I/OではGemini SDKのMCPネイティブサポートが発表されました。9月にはChatGPTデベロッパーモードベータでMCPクライアント機能が追加され、12月にはGoogle Cloudが全サービスへの統一MCPエンドポイントを提供しています。ISO・W3Cなどの公式標準化機関による正式な標準化手続きの完了は2026年4月時点では未確認ですが、主要プロバイダー全社が実装しており、業界では事実上の標準（de facto standard）として扱われています。

Function callingやMCPで外部システムを接続するとき、実装より先に設計で決めるべき事項が4点あります。後から入れると設計の全面見直しが必要になるものです。第一に、権限の最小化です。AIエージェントに与えるツール権限は、タスクに必要な最小限に絞ります。「読み取れるが書き込めない」「書き込めるが外部送信はできない」という粒度での分離が、セキュリティリスクを抑える基本です。MCPサーバーの設計段階でスコープを明示してください。第二に、冪等性（Idempotency）の確認です。同じ操作を複数回実行しても結果が変わらない（冪等な）ツールかどうかを事前に確認します。エージェントはリトライ・ループ・エラー回復の過程で同一ツールを複数回呼ぶことがあります。注文処理・送金・メール送信などは冪等でないことが多く、重複実行に備えた設計が必要です。第三に、監査ログの設計です。どのタイミングにどのツールが呼ばれ、どんな入出力があったかを記録します。AIエージェントは推論の過程が外から見えにくいため、ツール呼び出しのログが唯一の追跡可能な証拠になります。ログのフォーマットと保存場所を設計の初期段階で決めてください。第四に、失敗時の戻し（ロールバック）の定義です。複数のツールを連鎖的に呼ぶフローでは、途中でエラーが起きたときに整合性を保てる設計が求められます。「どこで止まっても元に戻せるか」を確認してから接続を本番に出してください。

この4点を後から入れるのは困難です。接続先の権限とデータフローを確認せずに繋ぎ始めた場合、後工程での修正コストが最も高くなります。

参考

支援内容とご相談

課題整理からシステム実装、人材育成まで。AIXの支援内容をご紹介します。ご相談はお問い合わせフォームから受け付けています。

お問い合わせ ↗事業紹介を見る ↗