Claude の「ツール」と「クライアント」を仕組みから理解する

はじめに

Claude を使ったシステム設計を学ぶなかで、2つの言葉に繰り返しつまずきました。「ツール（Tool）」と「Claude」です。

「ツール」は、Anthropic の公式ドキュメントや学習教材のあちこちに登場し、近くには「Skill」「MCP」「Agent SDK」といった用語が並びます。どれも「Claude に何かをさせる仕組み」に見えるため、私は当初「ツールはこれらをまとめた総称だろう」と考えました。「Claude」も、モデル本体を指すのか、Claude Code やデスクトップアプリを指すのかが文脈によって変わり、理解を妨げます。

本記事では、この2つの言葉を整理します。結論は次のとおりです。

• ツールとは、Claude の API の tool_use（関数呼び出し）という基礎的な仕組みです。MCP・Skill・Agent SDK は、その上に乗る別レイヤーであり、ツールの総称ではありません。
• claude.ai・Claude Code・デスクトップアプリ・自作スクリプトは、すべて同じ「クライアント」という役割です。「Claude」という語が指すもう一方、モデル本体とは役割が分かれています。

両者を理解するには、まず Claude とのやり取りの仕組みを押さえる必要があります。土台から順に説明します。

1. Claude とのやり取りの仕組み

ステートレスなリクエスト-レスポンス

Claude とのやり取りは、突き詰めると2つの登場人物の間で完結します。

• クライアント（アプリ） … リクエストを送る側。
• Claude モデル本体 … Anthropic のサーバー上で動く推論エンジン。Opus・Sonnet・Haiku といった具体的なモデルがこれにあたり、リクエストではどのモデルを使うかを指定します。

両者は、Claude の API（メッセージを送受信する Messages API）を通じてやり取りします。この API はステートレスなリクエスト-レスポンス型です。1回のリクエストに対して1回のレスポンスを返し、サーバー側は前回のやり取りを保持しません。具体的には次の2点です。

• API がクライアントに自発的に応答することはありません。「クライアントが送る → API が1回返す」で1往復が完結します。
• API は過去のやり取りを記憶しません。会話を継続するには、クライアントが毎回、これまでの全履歴（messages 配列）をまとめて送り直します。

会話が続いているように見えるのは、クライアント側が過去のやり取りを保存し、毎回まとめて送り返しているためです。messages 配列には user（利用者の発言）と assistant（Claude の発言）が交互に並びますが、この assistant メッセージは、モデルがリアルタイムに発話しているのではなく、前回モデルが返した文章をクライアントが保存して再送しているものです。

「リクエストを送る → レスポンスが1回返る」という1往復が、すべての基本単位です。ツールもエージェントも、この単位の組み合わせで成り立っています。

なお、この仕組みはコスト面にも関わります。毎回これまでの全履歴を送り直すため、会話が長くなるほど、1回のリクエストで送るトークン量が増えます。履歴はすべて入力トークンとして課金されるので、長い会話ほど1往復あたりのコストと待ち時間が大きくなります。

応答が止まった理由を示す stop_reason

レスポンスには、モデルが応答の生成を止めた理由を示す stop_reason フィールドが必ず含まれます。クライアントはこの値を見て、次に何をすべきかを判断します。例えば値が tool_use ならツールを実行して再送し、end_turn ならそのまま完了します。

次の表は、stop_reason が取りうる主な値です（公式ドキュメント「Stop reasons and fallback」より。ほかに model_context_window_exceeded などもあります）。

ツールを使わない通常のチャットでも流れは同じで、stop_reason: "end_turn" が返り、1往復で完了します。ツールを使う場合も、この「リクエストとレスポンスの1往復」という仕組みは変わりません。違いは、応答が end_turn で終わらず tool_use で返ってきたときに、クライアントがツールを実行してもう一度リクエストを送る、という往復が増える点だけです。

2. ツール（tool_use）の正体

なぜツールが必要なのか

Claude が単体でできるのは、入力をもとに文章（テキスト）を生成することだけです。在庫データベースの照会も、返金処理の実行も、ファイルの読み取りも、それ自体では行えません。外部のデータ取得や処理を実現するには、モデルに「実行させたい関数」を提示させ、実際の実行はクライアント側のプログラムが担う仕組みが必要です。これがツール（tool_use）です。

ツールがしているのは、モデルに「この関数を、この引数で呼びたい」と表明させ、実行は外側のプログラムに任せることです。

ツールの定義は3要素

クライアントは、リクエストの tools フィールドに、使用を許可するツールの一覧を渡します。1つのツールは3要素で定義します。

{
  "name": "lookup_order",
  "description": "注文IDから注文の配送状況を取得する",
  "input_schema": {
    "type": "object",
    "properties": { "order_id": { "type": "string" } },
    "required": ["order_id"]
  }
}

重要なのは description です。モデルは、利用者の発言とこの説明文を照らし合わせ、ツールを呼ぶべきかを自分で判断します。説明が曖昧だと、呼ぶべき場面で呼ばれません。input_schema は引数の形式（JSON Schema）を定め、モデルが渡す引数の構造を保証します。

ツールを使うときのやり取りの中身

カスタマーサポートを例に、ツールを使うときの実際のやり取りを追います。

① クライアント → モデル（ツール定義を付けて質問を送る）

{
  "messages": [
    { "role": "user", "content": "注文12345の状況を教えて" }
  ],
  "tools": [ { "name": "lookup_order", "...": "..." } ]
}

② モデル → クライアント（自分では実行できないため「呼んでほしい」と返す）

{
  "role": "assistant",
  "content": [
    { "type": "text", "text": "確認します。" },
    { "type": "tool_use", "id": "toolu_01",
      "name": "lookup_order", "input": { "order_id": "12345" } }
  ],
  "stop_reason": "tool_use"
}

③ クライアント → モデル（手元で関数を実行し、結果を user ロールで返す）

{
  "role": "user",
  "content": [
    { "type": "tool_result", "tool_use_id": "toolu_01",
      "content": "注文12345は発送済み。追跡番号 XYZ。" }
  ]
}

④ モデル → クライアント（結果を踏まえて最終回答）

{
  "role": "assistant",
  "content": [ { "type": "text", "text": "ご注文12345は発送済みです。追跡番号はXYZです。" } ],
  "stop_reason": "end_turn"
}

往復を図にすると次のとおりです。

押さえておきたい2点

ツールの動きで誤解しやすいのは、次の2点です。

1. 関数を実行するのはモデルではなくクライアントです。モデルは「呼びたい」と表明するだけ（②の tool_use）で、データベースへの照会は外側のプログラムが行います（③）。
2. 実行結果は user ロールのメッセージで返します。Claude の API には tool という専用ロールが存在しないため、ツールの結果も tool_result ブロックとして user メッセージに入れます。他社の API では結果を専用ロールで返す方式もあり、混同しやすい点です。

クライアントツールとサーバーツール

ツールは、コードの実行場所によって2種類に分かれます。

先述の4ステップのループが当てはまるのはクライアントツールです。サーバーツールは Anthropic 側で実行されるため、クライアントは実行の往復を意識せず、結果を受け取るだけで済みます。

3. 「クライアント」とは具体的に何か

ここまで「クライアント」という語を使ってきました。これが具体的に何を指すのかは、もう1つのつまずきの元である「Claude」という語の二重性と直結します。

「Claude」は、2つの別物を指します。

• Claude（モデル本体） … サーバー側の推論エンジン。API の向こう側。
• Claude Code やデスクトップアプリなど … 利用者の環境で動く別のプログラム。これらがクライアントとして API を呼びます。

次のものは、すべて「クライアント（アプリ）」に当てはまります。開発元や形態が違うだけで、API から見ればいずれも同じ「クライアント」という役割です。

• claude.ai … ブラウザで使うチャット。
• Claude デスクトップアプリ … claude.ai と同じチャットを、ブラウザではなくアプリとして使うもの。
• Claude Code … ターミナルで使うコマンドラインツール。
• Claude Cowork … Claude デスクトップアプリのタスク実行機能。ファイル操作などの作業を任せられる。
• 自作スクリプト … SDK や API を直接呼ぶプログラム。Amazon Bedrock や Google Cloud の Gemini Enterprise Agent Platform（旧 Vertex AI）経由で Claude を呼ぶ場合も、呼ぶ側のプログラムがクライアントにあたります。

claude.ai とデスクトップアプリは、同じチャット体験を「ブラウザで使うか、インストールしたアプリで使うか」が違うだけで、どちらも Anthropic 純正のクライアントです。

例えば Claude Code は、モデルから stop_reason: tool_use（例えば「Bash で ls を実行してほしい」）を受け取ると、利用者の PC 上でそのコマンドを実行し、結果を送り返してループを進めます。モデル本体が利用者の PC に触れることはありません。「指示を返すモデル本体」と「手元で実行するクライアント」という役割分担になっています。

クライアントが違えば、ツールの実行場所も違う

クライアントが「手元でツールを実行する」と言っても、その「手元」がどこかはクライアントによって異なります。Claude Code と Claude Cowork を比べてみます。

Claude Code は、手元のシェルでコマンドやファイル操作を直接実行します（実行前に権限の承認を挟みます）。一方 Claude Cowork は、利用者が選んだ作業フォルダだけをマウントした隔離された仮想マシン（VM）の中で実行し、それ以外のホスト上のものには触れません。

インターフェース（CLI かデスクトップか）、実行環境（手元か VM か）、権限の扱いは異なりますが、モデルとのやり取りの骨格（クライアントがリクエストを送る → モデルが content と stop_reason を返す → tool_use ならクライアントがツールを実行 → 結果を再送 → end_turn までループ）は、どちらも同じ Messages API の仕組みに基づいています。「何のツールを、どこで、どの権限で実行するか」は違っても、「モデルとどうやり取りするか」という土台は共通です。

ツールとクライアントという2つの土台が分かれば、その先にある「エージェント」へ進めます。

4. ツールからエージェントへ

ここまでで、ツール（tool_use）を使った1往復が分かりました。AIエージェントとは、この往復をモデル自身の判断で何度も繰り返し、目標を達成するまで処理を進める仕組みです。

動き方は、第2章で見たループの延長線上にあります。stop_reason が tool_use の間、クライアントはツールを実行し、その結果を付けて再びモデルに送ります。モデルは返ってきたツール結果を見て、「次はどのツールを、どんな引数で呼ぶか」「もう十分か」を判断します。これを end_turn が返るまで繰り返すことで、1回の往復では終わらない複数ステップの作業をこなします。

例えば「このリポジトリのバグを直して」という依頼では、何をどの順で行うか、何ファイル読むべきかは、調べてみないと分かりません。エージェントは、まず関連ファイルを検索し、結果を見て怪しいファイルを読み、原因を推測して修正し、テストを実行します。テストが失敗すれば、その出力を手がかりに別の箇所を調べ直し、修正して再びテストします。このように、前のツール結果に応じて次の一手と繰り返し回数を自分で決め、「テストが通った」と判断した時点で終了します。あらかじめ手順を決めておくのではなく、手順そのものをモデルに決めさせる点が、エージェントの特徴です。

対照的な作り方が「ワークフロー」です。手順をコード側で固定し、LLM を決まったステップの一部品として呼びます。手順や回数が途中の結果次第で変わるタスクは、ステップをあらかじめ固定するワークフローでは表現しきれません。エージェントは、何をどの順で行うかの判断自体をモデルに委ねるため、こうした探索的なタスクに向きます。逆に、流れが毎回同じ定型処理であれば、ワークフローのほうが確実で扱いやすいといえます。

Agent SDK：エージェントのループを肩代わりする実行基盤

このエージェントのループ（ツールを実行して再送し、end_turn まで繰り返す）を本格的に作ろうとすると、ループそのものに加えて、ツールの実行、複数ステップの管理、長くなった会話の整理などを、すべて自分で実装する必要があります。

Agent SDK は、この一式をまとめて肩代わりしてくれる実行基盤（ランタイム）です。tool_use ループを自動で回したうえで、次のようなものを最初から備えています。

• 組み込みツール（ファイルの読み書き、コマンド実行、Web 検索など）
• サブエージェント（作業を分担させる仕組み）
• MCP 連携（外部サービスのツールを取り込む）
• コンテキスト管理（会話が長くなったときの自動整理）

API を直接呼ぶ場合（Client SDK）との違いは、このループを「自分で書くか、任せるか」です。

Agent SDK は、もともと Claude Code を動かすために作られた実行基盤です。このエージェントループがコーディング以外の用途にも使えることから、2026年に「Claude Code SDK」から「Agent SDK」へ改名されました。第3章で比べた Claude Code と Claude Cowork は、いずれもこの実行基盤の上に作られたエージェントであり、同じループを別々の環境（手元のシェルと隔離 VM）で回しています。

5. MCP と Skill：ツールと混同しやすいが別物

冒頭で「ツールは MCP や Skill の総称だろう」と考えた、と書きました。Tool・MCP・Skill・Agent SDK が同じ文章に並んで登場すると、どれも似た役割に見えてしまいます。しかし、ここまで見てきたとおり、これらは抽象度（レイヤー）が異なります。レイヤーごとに並べると、次のようになります。

ツール・エージェント・Agent SDK は前章までで見ました。残る MCP と Skill を見ていきます。

MCP：ツールを供給する仕組み

ツールを1つ作るだけなら、ツールの章で見たように tools フィールドに定義を渡すだけで済みます。しかし、複数の AI アプリから複数の外部サービス（Slack、GitHub、社内データベースなど）を使おうとすると、組み合わせの数だけ接続を実装することになります。MCP（Model Context Protocol）は、この「AI アプリと外部サービスをつなぐ部分」を共通規格にして、実装の重複を減らすためのプロトコルです。

MCP を理解する鍵は、「ツールそのもの」ではなく「ツールを供給する仕組み」と捉えることです。MCP に対応したサーバーは、次の3種類を外部に公開できます。

• Tools … モデルが呼べる関数。これが最終的に tool_use として Claude に渡ります。
• Resources … モデルが参照できるデータ（ファイル、ドキュメントなど）。
• Prompts … 定型のプロンプトテンプレート。

このように MCP は、ツールそのものではなく、ツールやデータを標準化された形で Claude に届けるためのプロトコルです。MCP＝ツールの総称ではない、という点がここでの要点です。

Skill：ツールとは別の軸

Skill（エージェントスキル）は、SKILL.md という手順書を中心に、必要なスクリプトやリソースをひとまとめにしたパッケージです。例えば「自社の請求書フォーマットで PDF を作る手順」のような、作業のやり方を Claude に渡します。

Skill は「呼び出す関数」ではありません。ツールが Claude の呼び出す個々の関数であるのに対し、Skill は作業の進め方（手順や知識）をまとめて Claude に渡すものです。Skill が作業を進める過程でツールを使うこともあります（例えばコード実行ツールで PDF を生成する）。Skill とツールは別の軸であり、総称ではなく種類が異なります。

まとめ

本記事の2つの問い「ツールとは何か」「クライアントとは何か」に答えをまとめます。

• ツールは Claude の API の tool_use（関数呼び出し）という最も基本的な仕組みであり、LLM に外部実行の能力を与える仕組みです。Skill や MCP の総称ではありません。
• claude.ai・Claude Code・デスクトップアプリ・自作スクリプトは、すべて同じ「クライアント」という役割です。「Claude」という語が指すモデル本体とは役割が分かれています。
• ツールには、自分の環境で実行するクライアントツールと、Anthropic 側で実行するサーバーツールがあります。
• エージェントとは、このツールのループをモデルが自律的に回して目標を達成する仕組みです。そのループの実行を肩代わりする基盤が Agent SDK で、Claude Code や Claude Cowork はその上に作られています。
• MCP はツールを供給するプロトコル、Skill は手順・知識のパッケージです。いずれもツールという土台の周りに位置づく別レイヤーであり、ツールの総称ではありません。

「ツール」と「Claude」という2つの言葉を整理しておくと、その上に積み上がる概念は、同じ骨格のどの部分を設計するかの違いとして理解できます。同じところでつまずいている方の参考になれば幸いです。

参考（公式ドキュメント）

• Claude API — Tool Use（概要）: https://platform.claude.com/docs/en/agents-and-tools/tool-use/overview
• How tool use works: https://platform.claude.com/docs/en/agents-and-tools/tool-use/how-tool-use-works
• Stop reasons and fallback（stop_reason の値一覧）: https://platform.claude.com/docs/en/api/handling-stop-reasons
• Claude Agent SDK — Overview: https://platform.claude.com/docs/en/agent-sdk/overview
• Agent Skills（Skill の概要）: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Model Context Protocol: https://modelcontextprotocol.io/
• Claude Code — Overview: https://code.claude.com/docs/en/overview
• Get started with Claude Cowork: https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork