MENU
  1. ホーム
  2. 生成AI
  3. LLMの進化（API・Calling・MCP）～「考える頭脳」+「外の世界とつながる手足」～

LLMの進化（API・Calling・MCP）～「考える頭脳」+「外の世界とつながる手足」～

生成AI
項目LLM単体APITool CallingMCP
役割・たとえ考える頭脳（図書館に閉じ籠った状態）電話（外部へ問い合わせる手段）リモコン（特定のボタン操作）USBハブ / 神経系インフラ（共通接続基盤）
イメージ頭の中だけで完結店に電話して在庫を聞く決まった機能のボタンを押すデバイスをまとめて自動認識
自律性なし（文章生成のみ）低（人間が接続先を指定）中（LLMが関数を選択）高（ツールを自分で発見・判断）
状態管理文脈のみなし（一回切り）なしあり（記憶や経過の共有）
接続形式完結1対1（直接つなぐ）1対1（関数呼び出し）複数・網羅的（共通ルールで統合）
技術的特徴確率による言葉の予測HTTP通信 / JSONデータ関数の定義と選択JSON-RPC / 自己紹介機能
得意な場面翻訳・要約・アイデア出しシンプルなデータの取得決まった定型作業の実行複雑な複数ツールの連携
拡張性なし低い中程度高い（AI時代のOS的役割）

まず結論から言います。

LLMは「考える頭脳」
API・Tool Calling・MCPは 「外の世界とつながる手足」

LLM単体では、実は「文章を作るだけ」の存在です。

① まずLLMとは何か？

■ LLMの正体

LLM（Large Language Model）は

👉 大量の文章を学習して、次に来る言葉を予測する仕組み

例：

「今日はとても____」

→ 「寒い」「暑い」などを確率で予測

■ できること

  • 文章作成
  • 要約
  • 翻訳
  • アイデア出し

■ できないこと

  • 最新の天気を調べる
  • データベースを直接見る
  • メールを送る
  • 計算を正確に行う

👉 外の世界にアクセスできない

② LLM単体の限界

LLMは

👉 頭の中だけで考えている状態

イメージ：

  • 図書館の中に閉じ込められている
  • インターネットに出られない
  • 手足がない

だから、

「東京の今の気温は？」

と聞かれても、
推測で答えてしまうことがある。

③ APIとの関係

■ 役割分担

役割担当
考えるLLM
データ取得API

■ 流れ

  1. ユーザーが質問
  2. LLMが「天気APIが必要」と判断
  3. プログラムがAPIを呼ぶ
  4. データをLLMに渡す
  5. LLMが文章にまとめる

👉 LLMは司令塔

ただし、

APIは人間が設計して呼び出す。

👉 LLMはまだ「自律的」ではない。

④ Tool Callingとの関係

ここからLLMが少し進化します。

■ 何が違う？

LLMが

👉 どの関数を使うか自分で選べる

■ 流れ

  1. ユーザー「東京の天気は？」
  2. LLMが判断
    → get_weather関数を使う
  3. プログラムが実行
  4. 結果をLLMへ
  5. LLMが文章生成

👉 LLMがボタンを選ぶ

ただし：

  • 使える関数は事前に決まっている
  • 毎回定義が必要

⑤ MCPとの関係

ここで構造が大きく変わります。

■ MCPでは

LLMは

👉 ツールを自分で発見できる

■ 何が起きている？

MCPでは

  • ツールが自己紹介する
  • LLMが内容を読む
  • 文脈を理解して選ぶ
  • 会話を覚えながら連携する

■ イメージ

段階LLMの状態
単体頭だけ
API連携頭＋電話
Tool Calling頭＋リモコン
MCP頭＋神経ネットワーク

👉 LLMがエージェント化する

🔵 本質的な関係

LLMは中心

APIもTool CallingもMCPも

👉 LLMを拡張するための仕組み

🔴 技術的な整理

項目通常LLM+API+Tool+MCP
外部データ取得×○○◎
関数選択×人間LLMLLM
状態管理文脈のみなしなしあり
自律性低低中高

🎯 一番大事な理解

LLMは「脳」

APIは「通信」

Tool Callingは「操作」

MCPは「神経系インフラ」

🔥 さらに踏み込むと

通常のLLMは

👉 確率モデル

API連携後は

👉 外部データ統合型システム

MCPになると

👉 自律エージェント基盤

まとめ（超重要）

  • LLM単体では外の世界に触れない
  • APIは人間主導の接続
  • Tool CallingはLLMが関数選択
  • MCPはLLMが自律的に連携

「中学生でも分かる＋技術の中身まで」やさしく解説

① API（エーピーアイ）

■ まずイメージ

👉 電話でお店に問い合わせる仕組み

■ たとえ話

コンビニに電話して

「おにぎりありますか？」

と聞くイメージ。

  • 店ごとに電話番号が違う
  • 毎回かけ直す
  • 会話はその場限り

👉 一対一のやり取り

■ 技術の中身

APIは

👉 インターネットで決まった形式のデータを送る仕組み

基本構造

部品役割たとえ
URL住所電話番号
HTTP通信方法話し方
JSONデータの箱メモ用紙

実際の動き

① 住所にアクセスする

GET https://example.com/users/1

② サーバーがデータを返す

{
  "name": "Taro",
  "age": 15
}

👉 お願い → 返事 → 終わり

■ 技術ポイント

  • 毎回お願いし直す（記憶しない）
  • 接続先を人間が指定
  • 基本は一対一

👉 シンプルな通信ルール

② Tool Calling

■ まずイメージ

👉 AIがリモコンのボタンを押す仕組み

■ たとえ話

テレビのリモコンには

  • 電源ボタン
  • 音量ボタン
  • チャンネルボタン

👉 押せるボタンは最初から決まっている

AIは

「天気を知りたい」
→ 天気ボタンを押す

■ 技術の中身

① 先に「使えるボタン（関数）」を定義する

{
  "name": "get_weather",
  "parameters": {
    "city": "string"
  }
}

② ユーザーが
「東京の天気は？」

③ AIが判断して

{
  "function_call": {
    "name": "get_weather",
    "arguments": { "city": "Tokyo" }
  }
}

④ 実際のプログラムが動く

■ 技術ポイント

  • AIは「どのボタンを押すか」だけ決める
  • 実際に動くのは外のプログラム
  • 毎回ボタン一覧を教える必要がある

👉 決まった作業をさせるのに向いている

③ MCP（Model Context Protocol）

■ まずイメージ

👉 USBハブのような仕組み

たとえ話

パソコンにUSBハブをつなぐと

  • マウス
  • キーボード
  • モニター
  • SDカード

全部まとめて接続できる。

しかもパソコンが

「これはマウスだな」
と自動で判断する。

👉 まとめて接続＋自動判断

■ 技術の中身

MCPは

👉 AIとツールを共通ルールでつなぐ仕組み

① JSON-RPCという通信方式

例：

{
  "jsonrpc": "2.0",
  "method": "get_weather",
  "params": { "city": "Tokyo" },
  "id": 1
}
  • method = 呼び出す機能
  • params = 必要な情報
  • id = 通信番号

👉 APIよりも「関数呼び出し」に近い

② 状態を覚えられる

APIは基本：

お願い → 返事 → 終わり

MCPは：

  • 会話を覚える
  • 途中経過を共有できる
  • 継続的にやり取りできる

👉 記憶しながら動ける

③ ツールが自己紹介できる

ツールが

「私は天気を調べられます」
「私は計算ができます」

と宣言する。

AIが読んで選ぶ。

👉 自分で探して使える

🔵 ３つの違いを超シンプル比較

種類たとえ特徴向いている場面
API電話直接つなぐ一対一
Tool Callingリモコンボタン操作決まった作業
MCPUSBハブまとめて接続複雑連携

🎯 本質的な違い

API

👉 人が全部指定する通信ルール

Tool Calling

👉 AIが決まった関数を選ぶ仕組み

MCP

👉 AI時代の共通インフラ

🔴 技術レベルでの違い

観点APITool CallingMCP
状態管理なしなしあり
自律性低い少しある高い
接続数1対11対1複数
拡張性低い中高い

🔥 さらに一歩深く

  • API = 通信のルール
  • Tool Calling = AIの操作機能
  • MCP = AI用のOSのような土台
生成AI