合同会社ムジンケイカクプロ
NEW
llms.txtの書き方・完全ガイド｜国内外のベストプラクティスまとめAnthropicがCode w/ Claudeで解説：MCPの真の実力とClaude Agent SDKの全貌【公式動画2本まとめ】Claudeが繋がらない・エラーが出たときに最初に確認するページ
Claude Code

AnthropicがCode w/ Claudeで解説：MCPの真の実力とClaude Agent SDKの全貌【公式動画2本まとめ】

投稿日 ｜ 更新日

AnthropicがCode w/ Claudeシリーズで公開している動画の中に、日本語で紹介されることがほとんどない重要なセッションが2本ある。MCPの共同設計者David Soria Parrによる「MCP 201」と、Thariq ShihiparによるClaude Agent SDKのフルワークショップだ。どちらもAnthropicのスタッフが自社の設計思想を直接語る内容で、ドキュメントを読むだけでは気づきにくい核心が凝縮されている。本記事でその内容を日本語でまとめる。

動画①：MCP 201 | Code w/ Claude（26分30秒）

  • 登壇者： David Soria Parra（Anthropic Member of Technical Staff、MCPの共同設計者）
  • 発表： Code w/ Claude、2025年5月22日、San Francisco
  • 動画： https://www.youtube.com/watch?v=HNzH5Us1Rvg

MCPとは何か（おさらい）

MCP（Model Context Protocol）は、AIアシスタントと外部ツール・データソースを接続するためのオープンな標準プロトコルだ。USB-Cがデバイスと周辺機器を統一ポートでつなぐように、MCPはどのLLMクライアントとどのサービスもつなぐ「共通言語」として設計されている。

多くの人がMCPを「ツール呼び出しの仕組み」として理解しているが、David Soria Parrがこの動画で強調するのは「それだけではない」という点だ。MCPには5つのプリミティブ（基本構成要素）があり、Toolsはそのひとつにすぎない。

最近、MCPを題材にした書籍も見かけるようになったので、MCPを学べる媒体は増えてきたように思います。

5つのプリミティブ：全体像

プリミティブ（基本と翻訳していいと思っていますが）は「サーバー側3つ」と「クライアント側2つ」に大別される。重要な切り口は「誰が実行を決定するか」という点だ。

プリミティブ 主体 役割
Prompts ユーザーが決める AIとのやり取りのテンプレート
Resources アプリケーションが決める 生データをAIに提供する
Tools AIモデルが決める 具体的なアクションを実行する
Sampling サーバーがクライアントに要求 逆方向のAI推論リクエスト
Roots サーバーがクライアントに要求 作業ディレクトリの問い合わせ

サーバー側プリミティブ①：Tools（ツール）- 基本にして最重要

Toolsは最も広く使われているプリミティブで、MCPサーバーが「LLMが呼び出せる関数」を公開する仕組みだ。たとえば search_database(query) や send_email(to, subject, body) のような関数を定義すると、AIが必要に応じてそれを呼び出してアクションを実行する。

決定主体はAIモデル自身。 会話の流れの中でAIが「この操作が必要だ」と判断した瞬間に自動で呼び出される。ユーザーが直接指示を出すわけではない。

現在ほとんどのMCP実装はToolsだけを使っているが、ここからが本題だ。

サーバー側プリミティブ②：Prompts（プロンプト）- 見落とされがちな強力機能

Promptsはあまり知られていないが、MCPサーバーが「プロンプトテンプレート」を公開できる機能だ。

決定主体はユーザー。 スラッシュコマンド（/）やアットマーク（@）などで、ユーザーが能動的に呼び出す。

たとえば、コードレビュー用MCPサーバーが以下のようなプロンプトを提供できる。

  • review_security(code) ： セキュリティ観点でコードをレビューするプロンプト
  • summarize_pr(diff) ： PRの差分を受け取り要約を生成するプロンプト

ユーザーがスラッシュコマンドでこれらを呼び出すと、サーバーが返したプロンプトがそのままLLMへ送信される。

PromptsとToolsの違い：

Prompts Tools
誰が使うか ユーザーが能動的に選ぶ AIが自動で呼び出す
何をするか 対話を開始・ガイドするテンプレート 実際に何かを実行するアクション
使い方 /コマンド や @メンション 会話の流れでAIが自律的に実行

たとえばチャットアプリのMCPサーバーの場合、「何が新着か教えて」という定型文をユーザーが呼び出すのがPrompts、その依頼を受けてAIが裏側でスレッドを検索・読み取るのがToolsという使い分けになる。

Promptsの価値は「ワークフローをサーバー側で管理できる点」にある。 クライアントのUIを変えなくても、サーバー側でプロンプトを更新すれば全ユーザーに即座に反映できる。チームや製品で一貫したAI操作手順を管理したい場合に特に強力だ。

サーバー側プリミティブ③：Resources（リソース）- データをAIのコンテキストに注入

決定主体はアプリケーション。 アプリが「このデータをAIに見せる」と判断して使う。

ResourcesはMCPサーバーが「データやファイル」をAIに提供する仕組みだ。Toolsがアクションを実行する機能なのに対し、Resourcesはコンテキストを提供する機能として区別される。

提供できるデータには2種類ある。

  • text： テキストファイル、ログ、設定ファイル、APIのレスポンスなど
  • blob： 画像、PDF、バイナリデータなど

たとえば開発ツール向けのMCPサーバーが以下のリソースを公開するイメージだ。

  • file://project/README.md ： プロジェクトのREADME
  • log://app/error ： アプリケーションのエラーログ（リアルタイム）
  • db://users/schema ： データベーススキーマの定義

Resourcesにはサブスクリプション機能もあり、リソースが更新されたときにクライアントへ通知を送ることができる。ログ監視や設定変更の検知など、リアルタイム性が必要なユースケースで有効だ。

ToolsがAIに「何かをさせる」機能だとすれば、Resourcesは「AIに何かを見せる」機能といえる。

クライアント側プリミティブ④：Sampling（サンプリング）- 逆方向のAI通信

Samplingは最も高度なプリミティブで、MCPサーバーがLLMへ推論をリクエストできる「逆方向の通信」を実現する。

通常のMCPの流れはこうだ。

ユーザー → LLMクライアント → MCPサーバー（ツール実行）

Samplingを使うと、サーバー側からクライアント経由でLLMへ処理を依頼できる。

MCPサーバー → LLMクライアント → LLM（推論） → MCPサーバー（結果受け取り）

Samplingの3つのメリット

① セキュリティ・プライバシー・コストの一元管理

通常、サーバー側でAIモデルを動かそうとすると、サーバー独自のAPIキーが必要になる。Samplingを使えば、サーバーはクライアントが既に設定しているモデルやサブスクリプションをそのまま利用できる。ユーザーは個別のサーバーに認証情報を渡す必要がなく、信頼しているクライアント（Claude Desktopなど）を通じてすべてのAI処理を管理できる。

② サーバー開発の簡素化

サーバーの開発者は、クライアントがどのモデルを設定しているかを気にする必要がない。「要約してほしい」という要求をクライアントに投げるだけで、クライアント側で最適なモデルを使った回答が得られる。

③ 高度な連携（チェイニング）とエージェント化

複数のMCPサーバーが連鎖するような複雑な動作を可能にする。あるサーバーがツールを実行している最中に、さらに別のサーバーの機能を呼び出し、その過程でAIの判断が必要になった場合でも、リクエストをクライアントまで「バブルアップ（吸い上げ）」させて処理できる。

バブルアップの仕組み

「バブルアップ」とは、MCPサーバーがAI処理を必要としたとき、そのリクエストを上位のクライアントまで吸い上げて、クライアント側で実行させる仕組みだ。

たとえばあるサーバーが処理中に「この内容を要約してほしい」という状況になったとする。このとき、サーバーが勝手に外部のAIを呼び出すのではなく、「要約してほしい」というリクエストを一番上のクライアントまで戻す（バブルアップさせる）のだ。

これにより、コスト・プライバシー・モデル選択のすべてをクライアント側で一元管理したまま、複雑なエージェント機能を動かせる。

SamplingによるMCPエージェント

Samplingが可能にするのが「MCPエージェント」だ。複数のMCPサーバーを連鎖（チェイニング）させ、Samplingを介してAIモデルと再帰的にやり取りすることで、より複雑で自律的なタスクを遂行できる仕組みを指す。

単なるツール呼び出しを超えて、サーバーとAIモデルが何度もやり取りを繰り返す再帰的な構造が生まれ、これがエージェントのような高度な振る舞いを実現する。

クライアント側プリミティブ⑤：Roots（ルーツ）- 作業範囲の明示

RootsはMCPクライアントがサーバーに「使っていいディレクトリ範囲」を伝える仕組みだ。たとえばClaude Desktopが ~/projects/myapp をルートとして宣言すると、MCPサーバーはその範囲内でのみファイルアクセスを行う。

VS CodeやIDEでどのプロジェクトが開かれているかをGit操作サーバーが知ることで、適切な場所でコマンドを実行できるようになるといった場面で活躍する。ローカルのファイルシステムを扱うMCPサーバーで、スコープを明示的に制限するための機能として重要だ。

MCPの将来像：ローカルからWebへ

動画の後半でDavidが語るのが「MCP on the Web」のビジョンだ。

現在 のMCPはローカル環境（stdio接続）で使われることが多いが、今後はHTTPSベースでMCPサーバーをWebに公開できるようにする計画が進んでいる。重要な要素がOAuth 2.1による認証フローだ。WebベースのMCPサーバーを誰でも安全に利用できるようにするために、標準的な認可プロトコルで接続を保護する設計になっている。

近い将来 には以下の機能が導入される予定だ。

  • Elicitation（エリシテーション：入力の要請）： MCPサーバーがタスク実行の途中でユーザーに直接「入力を求める」機能。AIが自律的に動く中で判断に迷った場合や、ユーザーの明示的な選択が必要な場面で使われる。例えば「修正候補のPRが3つあります。どれに対して作業を続けますか？」のような問いかけが可能になる。
  • 非同期タスク： 数分から数時間に及ぶ長時間タスクのためのプリミティブ。エージェントが裏側でじっくり作業し、完了後に結果を報告する形態を実現する。

さらに先の構想 として、公式レジストリの構築がある。MCPサーバーを検索・公開するための中央レジストリが整備されれば、エージェントが自分に必要なサーバーをレジストリから動的にダウンロード・インストールして機能を拡張できるようになる。AIが自らツールを拡張する、真の自律型エージェントの土台だ。

MCPエコシステムはToolsの実装から始まり、Prompts・Resources・Samplingが普及し、最終的にWebで誰でも公開・利用できるサービスの生態系へと進化する。Davidはこの道筋を明確に描いている。

動画②：Claude Agent SDK フルワークショップ

  • 登壇者： Thariq Shihipar（Anthropic）
  • 発表： 2026年1月公開
  • 動画： https://www.youtube.com/watch?v=TqC1qOfiVcQ

Claude Code SDK → Claude Agent SDKへの改名

Claude Agent SDKはもともと「Claude Code SDK」という名称だった。Claude Codeのコア部分（エージェントループ・ツール群・コンテキスト管理）をライブラリとして外部から利用できるようにしたものだ。

改名の背景にはAnthropicの内部での実績がある。Anthropic自身がClaude Codeをコーディング以外の用途でも使うようになっていた。リサーチ調査、動画制作、会議のメモ取りなど、非コーディングタスクへの応用が広がった結果、「これはコーディングエージェントではなく汎用エージェント基盤だ」という認識に変わった。それを名前に反映したのが「Claude Agent SDK」だ。

設計思想：「エージェントにコンピューターを与える」

Claude Agent SDKの根本的な設計思想はシンプルだ。エージェントに、人間のプログラマーが使うのと同じツールを与える。

多くのAIエージェントフレームワークはAPIの呼び出しを中心に設計されている。しかしAnthropicが気づいたのは、LLMに「コンピューター上で直接作業させる」ほうが本質的に強力だという点だ。ファイルシステムへのアクセス、シェルコマンドの実行、コードの書き換えと実行。これらを与えると、AIはプログラマーと同じ方法で問題を解決できるようになる。

この思想はコーディング以外にも適用できる。CSVを読んでグラフを生成する、Webを検索して情報を収集する、Slackのメッセージを解析してタスクを整理する。すべて「コンピューターを持つエージェント」が自然にできることだ。

Built-inツール一覧

SDKにはすぐ使えるツールが組み込まれている。

ツール 用途
Read 任意のファイルを読む
Write 新規ファイルを作成する
Edit 既存ファイルを精密に編集する
Bash シェルコマンド・スクリプト・gitを実行する
Glob パターンでファイルを検索する
Grep 正規表現でファイル内容を検索する
WebSearch Webを検索する
WebFetch Webページを取得・パースする
AskUserQuestion ユーザーへの確認・選択肢の提示

エージェントループの3フェーズ

Claude Agent SDKで構築するエージェントはすべて同じ基本ループを持つ。「コンテキスト収集 → アクション実行 → 検証」を繰り返すサイクルだ。

フェーズ1：コンテキスト収集（Gather Context）

エージェントが作業を開始する前に、必要な情報を集める段階だ。

エージェントサーチ（Agentic Search）

LLMが grep や tail などのBashコマンドを使って、大量のファイルから必要な部分だけを引き出す方法だ。ログファイルや設定ファイルなど、大きなデータを丸ごとコンテキストに載せるのではなく、必要な行だけを抽出する。フォルダとファイルの構造自体が「コンテキストのエンジニアリング」になるという考え方だ。

セマンティック検索（Semantic Search）

ベクトルデータベースを使った意味的な検索。エージェントサーチより高速だが、精度が落ち、メンテナンスコストも高い。Thariqは「まずエージェントサーチから始めて、速度が足りない場合だけセマンティック検索を追加する」ことを推奨している。

サブエージェント（Subagents）

複数のサブエージェントを並列で走らせる仕組みだ。メリットは2つある。

  1. 並列化： 複数のタスクを同時に処理してスループットを上げる
  2. コンテキスト分離： サブエージェントは独自のコンテキストウィンドウを持ち、大量の情報から必要な部分だけをオーケストレーターに返す

たとえばメールエージェントを作るなら、複数の検索サブエージェントを並列起動して、それぞれが異なるクエリでメール履歴を検索し、関連する抜粋だけを返すといった設計が可能だ。

コンパクション（Compaction）

長時間稼働するエージェントでコンテキストの上限に近づいたとき、自動で過去のやり取りを要約・圧縮する機能だ。Claude Codeの /compact スラッシュコマンドを基盤にしており、エージェントが途中でコンテキスト切れを起こさないようにする。

フェーズ2：アクション実行（Take Action）

カスタムTools

エージェントの「主な行動」を関数として定義する。fetchInbox や sendReply のように、エージェントが頻繁に取るアクションをToolとして用意する。Toolsはコンテキストウィンドウ内で目立つ位置に表示されるため、AIが優先的に選択する傾向がある。

Bash（汎用操作）

特定のツールに収まらない柔軟な操作はBashで対応する。たとえばメールの添付ファイルをダウンロードしてPDFをテキストに変換し、その中から必要な情報を検索するといった複合的な処理をシェルスクリプトとして実行できる。

コード生成

Claude Agent SDKはコード生成が得意だ。Pythonスクリプトを書いてExcelを生成する、HTML/CSSをコードで出力するなど、「コードとして表現できる処理」はすべてエージェントの武器になる。Claude.aiのファイル生成機能（Excel・PowerPoint・Word）はこのコード生成を活用している。

MCP連携

MCPサーバーを通じてSlack・GitHub・Google Drive・Asanaなどの外部サービスに接続できる。認証やAPI呼び出しはMCPが処理するため、エージェントは search_slack_messages や get_asana_tasks のように関数を呼ぶだけでいい。

フェーズ3：検証（Verify）

自分の出力を確認・改善できるエージェントは根本的に信頼性が高い。

ルールベースのフィードバック

TypeScriptのlintやユニットテストのように、明確な基準を用意して「どのルールが失敗したか」を詳細にフィードバックする方法。Thariqは「JavaScriptよりTypeScriptを生成してlintする方が精度が高い」と言及している。

視覚的フィードバック（Visual Feedback）

HTMLのレンダリング結果をPlaywright経由でスクリーンショットを撮り、LLMに見せて視覚的な問題を確認させる。レイアウト・スタイル・コンテンツ階層が意図通りかをAI自身が検証できる。

LLMアズアジャッジ（LLM as a Judge）

別のLLMに出力の品質を評価させる方法。レイテンシが上がるため万能ではないが、ファジーなルールでの品質チェックに使える。たとえばメールエージェントが生成したドラフトのトーンを、別のサブエージェントが評価して改善指示を出す設計だ。

構築できるエージェントの例

Thariqはこれらの設計原則を使って構築できるエージェントの例として4種類を挙げている。

Finance Agent（ファイナンスエージェント）

ポートフォリオの状況と目標を理解し、外部APIにアクセスして投資判断の材料を集め、計算コードを実行して分析レポートを生成する。

Personal Assistant Agent（パーソナルアシスタント）

旅行予約・カレンダー管理・アポイント調整・ブリーフ作成など。複数のデータソースをまたいでコンテキストを追跡し、継続的に支援する。

Customer Support Agent（カスタマーサポート）

曖昧さが高い問い合わせに対して、ユーザーデータを収集・確認し、外部APIと連携して回答し、必要に応じて人間にエスカレーションする。

Deep Research Agent（ディープリサーチ）

大量のドキュメントコレクションを横断的に検索・分析・統合し、詳細なレポートを自動生成する。

テストと改善のサイクル

Thariqは「エージェントが失敗するケースを見たとき、自分がそのエージェントだったらと想像してほしい」と言う。必要なツールはあるか、検索APIが使いやすいか、失敗を修正する方法があるか。この問いかけがエージェントを改善する出発点だ。

まとめ：MCPとAgent SDKが描く世界

2本の動画を通じて見えてくるのは、AnthropicがMCPとAgent SDKを「セット」として捉えているという点だ。

MCPが5つのプリミティブ（Tools・Prompts・Resources・Sampling・Roots）によって外部サービスとの接続を標準化し、Agent SDKがそのMCPを活用するエージェントの実行基盤を提供する。エージェントはMCPを通じてSlackにも、データベースにも、ブラウザにも接続できる。そして自分でコードを書き、実行し、結果を検証しながら仕事を進める。

日本ではまだ「MCPはツール呼び出しの仕組み」「Claude Codeはコーディングツール」という理解が主流だが、Anthropicが描いているのはそれよりずっと広い世界だ。SamplingのバブルアップとElicitationが組み合わさり、非同期タスクと公式レジストリが整備されたとき、AIエージェントが自律的にツールを揃えて長時間のタスクをこなす時代が来る。

その設計思想を学ぶ最良の場所は、AnthropicのCode w/ Claudeシリーズにある。

参照動画