Claude 2026年4月22日の公式ブログ解説: 本番システムに届くエージェントとMCP

Claude は 2026年4月22日(水) に、公式ブログ「Building agents that reach production systems with MCP」を公開しました。この記事は、新しい単発機能の発表というより、本番環境で動くAIエージェントが外部システムにどう接続すべきかを整理した設計ガイドです。直接API呼び出し、CLI、Model Context Protocol (MCP) の違いを比較し、クラウド上で継続稼働するエージェントにはどのようなMCPサーバー設計、認証、コンテキスト効率化、skills連携が必要になるかを説明しています。

何が発表されたのか

• Claude公式ブログが、本番エージェントの外部システム接続パターンとして API、CLI、MCP を比較した。
• MCPは、Claude、ChatGPT、Cursor、VS Codeなど複数クライアントにまたがる共通レイヤーとして位置づけられている。
• リモートMCPサーバー、意図ベースのtool設計、code orchestration、MCP Apps、elicitation、OAuth / CIMD、Vaults などの実装パターンが整理された。
• MCPクライアント側では、tool search と programmatic tool calling によるコンテキスト節約が重要とされている。
• MCPサーバーと skills は競合ではなく補完関係で、pluginとして束ねる、またはMCPサーバーからskillsを配布する方向性が示された。

今回のブログ記事で語られていること

この記事の中心は、「エージェントが本当に業務で役に立つには、チャット画面の中だけで賢いだけでは足りず、実際のデータ、業務アプリ、開発基盤、認証されたクラウドサービスに安全につながる必要がある」という問題意識です。Claude はまず、外部システム連携の方法を3つに分けています。直接API呼び出しは、1つのエージェントが少数のサービスに接続する段階では始めやすいものの、エージェントとサービスの組み合わせが増えると、認証、tool説明、例外処理が組み合わせごとに増えていきます。CLIは、既存の開発者ツールを使えるためローカル環境やコンテナでは強い一方で、Web、モバイル、クラウドホスト型のエージェントにそのまま広げにくく、認証もローカルの資格情報に寄りがちです。

そこで記事は、MCPを「本番エージェント向けの共通レイヤー」として説明します。MCPサーバーがシステムの機能、認証、発見可能性、意味づけを標準化して公開すれば、複数のクライアントが同じ連携を利用できるようになります。特に本番エージェントはクラウド上で継続的に動き、接続先もSaaS、データ基盤、チケット管理、インフラ基盤のようなクラウド上のシステムになるため、リモートMCPサーバーを前提に設計することが重要だとされています。

サーバー設計では、APIエンドポイントをそのまま大量のtoolに写すのではなく、ユーザーの意図に沿った少数のtoolにまとめることが推奨されています。たとえば、複数の低レベル操作をエージェントに組み立てさせるより、会話スレッドから課題を作るような目的単位のtoolを用意するほうが、呼び出し回数も失敗点も減らせます。一方で、Cloudflare、AWS、Kubernetesのように操作面が非常に広いシステムでは、すべてを個別toolにするのではなく、エージェントが短いコードを書き、サーバー側のサンドボックスでAPI操作を実行するcode orchestration型の設計も示されています。

また、MCP Apps、elicitation、form mode、URL modeのように、単にテキストを返すだけでなく、フォーム、ダッシュボード、OAuth、支払い、確認操作を会話の流れに組み込むための仕組みも紹介されています。認証では、OAuthとCIMDによるクライアント登録、Claude Managed AgentsのVaultsによるトークン管理が取り上げられ、クラウド上のエージェントがユーザーの資格情報を安全に再利用する設計が焦点になっています。

クライアント側では、全tool定義を最初からコンテキストへ詰め込むのではなく、tool searchで必要なtoolだけを探して読み込むこと、toolの結果をそのままモデルに戻さずコード実行環境で集約・フィルタしてから最終結果だけ渡すことが重要とされています。最後に、MCPは外部システムへの接続を担い、skillsはそのシステムをどう使って仕事を進めるかの手順知識を担う、という補完関係が説明されています。

誰に影響があるか

この内容は、ClaudeやMCPを使う開発者だけでなく、社内ツール、SaaS連携、データ基盤、IT運用、セキュリティレビューを担当するチームにも関係します。特に、自社システムをAIエージェントから操作可能にしたいSaaSベンダー、社内業務アプリをエージェント化したい情報システム部門、Claude CodeやClaude Managed Agentsを業務プロセスに組み込む開発組織は、MCPサーバーを単なるAPIラッパーとして作るべきではない、という点を押さえる必要があります。

実務での読みどころ

一番重要なのは、MCPを「とりあえず流行っているプロトコル」として見るのではなく、エージェント連携の保守性、移植性、認証、コンテキスト効率をまとめて扱う設計単位として見ることです。API、CLI、MCPは置き換え関係ではなく、用途ごとに共存します。APIは基盤、CLIはローカル開発や運用、MCPはクラウド上の本番エージェント連携、という分担で考えると分かりやすくなります。

また、MCPサーバーを作る場合は、既存APIの全エンドポイントを機械的に公開するのではなく、エージェントが実際に達成したいタスクからtoolを設計するべきです。tool数が増えるほど高機能に見えますが、モデルにとっては選択肢が増え、説明文が長くなり、コンテキストを圧迫します。運用チームは、toolの粒度、危険操作の確認、OAuthの権限範囲、監査ログ、トークン保管、ユーザーごとの認可境界をセットでレビューする必要があります。

チームが確認したいこと

1. 既存のエージェント連携が、直接API呼び出し、CLI、MCPのどれに依存しているか棚卸しする。
2. 本番運用したい連携は、ローカルCLI前提ではなくリモートMCPサーバーとして成立するか確認する。
3. MCP toolをAPIエンドポイント単位ではなく、業務上の意図やタスク単位で再設計できないか検討する。
4. OAuth、CIMD、Vaults相当の仕組み、監査ログ、権限分離、トークン更新の責任範囲を確認する。
5. tool searchやprogrammatic tool callingのようなコンテキスト削減策を、複数MCPサーバー利用時の標準設計に入れる。
6. MCPサーバーだけでなく、skillsやpluginとして運用手順・業務知識を配布する設計も検討する。

まとめ

今回のClaude公式ブログは、MCPを「エージェントにtoolをつなぐ仕組み」としてだけでなく、本番エージェントがクラウド上の業務システムに安全かつ継続的に届くための設計レイヤーとして位置づけています。AIエージェントの価値は、外部システムとの接続品質に大きく左右されます。MCPサーバーを作るチームは、toolの数よりも意図の明確さ、認証の標準化、コンテキスト効率、skillsとの組み合わせを重視して設計するのがよさそうです。