LLMから順番に考えると、Agent・Tool・Skill・MCPはそんなに難しくない

1. ChatGPT？ GPT？ まずそこを分けよう

生成AIについて調べ始めると、最初からよく似た言葉が出てきます。ChatGPTとGPTです。普段使うだけなら「ChatGPTに聞いた」「GPTに聞いた」のどちらでも大きな問題はありません。しかし、LLM、Tool、Skill、Agent、MCPと仕組みを掘り下げていくと、この2つを同じものとして扱うと話が分からなくなってきます。

最初に結論だけ押さえておきましょう。GPTはモデル、ChatGPTはGPTなどのモデルを利用して機能を提供するサービスです。

1.1 GPTはChatGPTより前からあった

ChatGPTが一般公開されたのは2022年11月30日ですが、GPTはそのとき突然登場したわけではありません。大まかな歴史を並べると次のようになります。

年	出来事
2017	Transformerを提案した論文 Attention Is All You Need が発表
2018	OpenAIが初代GPTを発表
2019	GPT-2
2020	GPT-3
2022	GPT-3.5系列を利用したChatGPTが一般公開
2023	GPT-4、ChatGPT Pluginsなどが登場

ここで注意したいのは、この表を上から下へ一つの製品のバージョンアップとして読まないことです。GPT、GPT-2、GPT-3などはモデル側の歴史です。一方、ChatGPTは、それらの技術の延長上に登場したユーザー向けサービスです。つまり「GPT-3 → GPT-3.5 → ChatGPT」と製品名が変化したわけではありません。

1.2 そもそも「モデル」とは何だろう

モデルについて詳しく考えるのは次章に譲ります。ここでは単純に、GPTのようなモデルは入力を受け取り、それをもとに出力を生成するものと考えてください。

たとえば「Linuxでファイルの一覧を表示するコマンドは？」という入力を与えると、「lsコマンドを使用します」のような出力が返ってきます。内部で単純な質問回答データベースを検索しているわけではありませんが、今のところは「入力 → モデル → 出力」という関係だけ分かれば十分です。

1.3 ではChatGPTとは何なのか

2022年11月に公開されたChatGPTは、GPT-3.5系列のモデルを利用し、人間がチャット形式で指示を与えて回答を受け取れるサービスとして登場しました。

ここで大事なのは、ChatGPTという名前はモデルそのものの名前ではないということです。ユーザーが利用しているChatGPTというサービスの内部で、GPTなどのモデルが利用されています。

この記事では、以降の説明に次の構成図を使います。

図1-1 ChatGPTとLLMの位置関係

図1-1では、①Userが②ChatGPTというサービスを利用し、その内部に③Service / Runtimeと④GPT / LLMが存在するところまでを示しています。⑤以降はまだ登場していないためグレーアウトしています。この番号と位置関係は、以降の章でも基本的に維持します。

1.4 ChatGPTとGPTを分ける必要が出てきた

ChatGPTが登場した当初は、「GPTと会話するためのサービス」くらいの理解でも、それほど困らなかったかもしれません。しかし、Web上の情報へのアクセス、計算、外部サービスの利用など、モデルが文章を生成するだけでは説明できない機能が増えていきました。

たとえばChatGPTに「今日発表されたニュースを調べて」と頼んだとします。GPTというモデル自身がインターネットへアクセスしているのでしょうか。「この計算をPythonでやって」と頼んだ場合、GPTというモデルそのものがOS上でPythonを実行しているのでしょうか。「このメールを送って」と頼んで本当に送信された場合、GPT自身がメールサーバーへ接続しているのでしょうか。

こう考えると、ChatGPTというサービスと、その内部で使われるGPTというモデルを分けて考える必要があることが見えてきます。

1.5 この章で覚えること

この章で押さえておきたいのは、GPT / LLMはModel、ChatGPTはそのModelを利用して機能を提供するServiceという違いです。

では、そのLLM自体は何をしているのでしょうか。次章では④LLMそのものを見ていきます。

2. まずは落ち着いてLLMの話をしよう

LLMは Large Language Model（大規模言語モデル）の略です。文章の作成、要約、翻訳、プログラム生成、推論など、現在ではさまざまな用途に使われていますが、基本的な動作は「入力されたContextをもとに出力を生成する」と考えるところから始められます。

2.1 LLMは何をしているのか

LLMに文字列を入力すると、その入力をもとに出力が生成されます。非常に単純化すると図2-1のようになります。

図2-1 LLMの基本的な入出力

ここで重要なのは、LLMが完成済みの回答をデータベースから検索して返しているわけではないことです。LLMは入力されたContextをもとに次に続くTokenの確率を計算し、Tokenを順番に生成することで出力を作ります。

たとえば「日本の首都は」というContextが与えられたとします。LLMはその後に続くTokenを予測して生成し、生成したTokenを含む新しいContextから、さらに次のTokenを予測します。この処理を繰り返すことで文章が作られていきます。

図2-2 Token生成のイメージ

実際のTokenは必ずしも単語単位ではありませんし、実際の生成処理もこの図より複雑です。ここでは、LLMはContextを受け取り、その続きとなるTokenを生成する処理を繰り返していると理解しておけば十分です。

2.2 それで、なぜ質問に答えられるのか

「次のTokenを予測しているだけなら、なぜ質問に答えたり、プログラムを書いたりできるのか」という疑問が出てきます。その背景を理解するために、少しだけ歴史を振り返ります。

2017年、Googleの研究者らが論文 Attention Is All You Need でTransformerを発表しました。TransformerではAttentionという仕組みを利用して、文章中のToken同士の関係を扱います。2018年にはOpenAIがTransformerを利用したGPTを発表し、大量の文章で事前学習したモデルを個別のタスクへ適用する方法を示しました。その後、GPT-2、GPT-3とモデルが大規模化し、さまざまな文章処理を一つのモデルで扱えることが明らかになっていきます。

さらに、単に文章の続きを生成するだけでは、人間の指示に従う対話システムとしては扱いにくいという問題があります。そこで、指示と望ましい応答の例を使った調整や、人間のフィードバックを利用したRLHF（Reinforcement Learning from Human Feedback）などによって、人間の指示に対して有用な応答を返すようモデルを調整する手法が発展しました。

LLMが学習する大量の文章には、単なる単語の並びだけではなく、概念同士の関係、プログラムの構文、質問と回答、要約や翻訳、論理的な文章の構造など、さまざまなパターンが含まれています。こうしたパターンを大規模なモデルが学習することで、質問への回答、文章作成、翻訳、プログラム生成、推論などに利用できる能力が現れます。ただし、「LLMの中に巨大な知識データベースがあり、そこから答えを検索している」と考えるのは適切ではありません。

2.3 学習と、いま使っているときの処理は別

LLMについて「大量のWebページを読んでいるから、インターネット上の情報を知っている」と説明されることがあります。しかし、ここでは**学習（Training）と推論（Inference）**を分けて考える必要があります。

図2-3 TrainingとInference

Trainingでは大量のデータを使ってモデルのパラメータを調整し、学習済みのLLMを作ります。一方、私たちがLLMを利用するときには、その学習済みモデルへContextを与えてInferenceを行い、出力を生成します。

過去にWeb上の情報を使って学習したことと、いまWebへアクセスして情報を取得することは別です。

2.4 「知っている」と「いま確認した」は違う

たとえばLLMに「東京の10月の気温はどのくらい？」と質問すれば、学習した知識をもとに回答できるかもしれません。しかし、「東京の現在の気温は？」となると話が変わります。

LLMが過去の知識から現在の気温を推測したとしても、それは現在の東京の気温を観測したことにはなりません。同じことは、現在の株価、今日発表されたニュース、運行情報、いまデータベースに登録されている顧客情報などにも当てはまります。

図2-4 LLMと外界

④LLMは与えられたContextからOutputを生成できますが、この図では⑧External Worldとの間に利用可能な接続がありません。LLMが学習によって外界についての知識を持っていることと、現在の外界を観測できることは別です。

2.5 外界を「変える」となると、さらに違う

外界から情報を取得するだけでなく、外界に何かを行いたい場合は、この違いがさらに分かりやすくなります。たとえば「この内容でメールを送って」とLLMへ入力したとします。

LLMはメールの件名や本文を生成できます。しかし、文章を生成することと、実際にメールを送信することは別です。メールを送るためには、メールシステムへ接続し、宛先や本文を渡し、送信処理を実行する必要があります。

同じように、LLMはSQLを書くことはできても、そのSQLをデータベースで実行したことにはなりません。商品の注文内容を作ることはできても、それだけで注文が成立するわけではありません。

2.6 この章で覚えること

④LLMはContextからOutputを生成できます。しかし、現在の外界を観測することと、外界に対して処理を実行することは、それとは別の能力です。

では、そのための「道具」を与えたらどうなるでしょうか。次章では⑦Toolを見ていきます。

3. LLMには「手足」がない ― Toolの登場

LLMから外界の機能を利用できるようにしたらどうでしょうか。ここで登場するのが⑦Toolです。

3.1 Toolは外界に対する「道具」

Toolという言葉はかなり広い意味で使われますが、この記事では外界の情報を取得したり、外界に対して処理を実行したりするために利用できる機能と考えます。

たとえば次のようなものです。

• Webを検索する
• ファイルを読む
• データベースから情報を取得する
• プログラムを実行する
• メールを送る
• データベースを更新する
• 商品を注文する
• 決済を実行する

Toolは、外界を観測するものと外界を操作するものに分けて考えると分かりやすくなります。

図3-1 Toolと外界

Web検索やデータベース参照は主にObservationのためのToolです。メール送信やデータベース更新、決済などは外界に作用するActionのためのToolです。実際には一つのシステムが参照と更新の両方を提供することもありますが、セキュリティを考えるうえでも「読む」と「変える」を区別しておくことは重要です。

3.2 LLMがToolを直接実行するわけではない

「LLMにToolを与える」という表現は分かりやすいのでよく使われますが、実際にToolを実行するのはLLMそのものではありません。

図3-2 Toolを加えた構成

④LLMは「Webを検索したい」「このSQLを実行したい」「この内容でメールを送りたい」といったToolを利用するための情報を出力できます。しかし、その出力を受け取って⑦Toolを呼び出し、結果を受け取るのは③Runtime側の仕事です。

3.3 Function Callingで何が変わったのか

現在のLLMとToolの関係を理解するうえで重要な技術の一つがFunction Callingです。

LLMに利用可能なFunctionとその引数を提示し、必要に応じて「このFunctionを、この引数で呼び出したい」という構造化された出力を生成させます。たとえば天気を取得するFunctionがあるなら、次のような出力です。

{
  "name": "get_weather",
  "arguments": {
    "location": "Tokyo"
  }
}

重要なのは、このJSONを生成しただけでは天気を取得していないということです。これは「get_weatherをTokyoという引数で呼び出したい」というLLMからの出力にすぎません。

図3-3 Tool Callingの基本的な流れ

④LLMは何を調べるべきかを判断し、③Runtimeが⑦Toolを実行し、その結果を再び④LLMへ渡します。

3.4 Toolの結果も、LLMから見ればContext

Toolを使って外界から情報を取得しても、LLMの基本的な動作が変わるわけではありません。RuntimeがToolの結果をContextへ加え、再びLLMへ入力します。

図3-4 Toolを使った後もLLMの基本構造は同じ

外界へアクセスできるようになったからといって、LLMそのものがWebブラウザやメールクライアントになったわけではありません。外界とのやり取りを行う⑦Toolと、それを実行して結果をContextへ戻す③Runtimeが加わったわけです。

3.5 ToolはAPIと何が違うのか

ここで「それってAPIを呼んでいるだけでは？」と思うかもしれません。その理解はかなり近いものです。

Toolの実体は、Web API、ローカル関数、コマンド、データベースアクセス、ファイル操作などさまざまです。Toolという言葉は、それらの実装方式そのものを指すというより、LLMを利用するシステムから呼び出せる**能力（Capability）**として見たときの役割を表しています。

図3-5 Toolと実装方式

利用する側から見れば重要なのは「顧客情報を取得できる」というCapabilityです。その裏側がどのように実装されているかは別の問題として考えられます。この「Capabilityと接続方法を分けて考える」という視点は、後でMCPを考えるときに重要になります。

3.6 Toolを手に入れた。でも、まだ何か足りない

一回のTool呼び出しなら、ここまでの仕組みで実現できます。しかし実際の仕事は、一つのToolを呼んで終わるとは限りません。複数のToolを使い、その結果によって次に何をするかを判断する必要があります。

次章では、その「仕事を進める仕組み」を見ていきます。

4. Toolを渡しただけでは仕事は終わらない ― 計画と実行のループ

4.1 一回のTool呼び出しなら簡単

天気を調べるだけなら、必要なToolは一つです。しかし、たとえば次の依頼ではそうはいきません。

A社との契約内容を確認して、更新可能なら契約期間を1年延長し、担当者へメールで知らせて。

この処理には、顧客の特定、契約の取得、更新可否の確認、契約変更、更新結果の確認、担当者の確認、メール送信など複数の作業があります。さらに、契約が終了済み、承認が必要、A社という名前の顧客が複数存在するなど、それぞれの結果によって次に行う処理も変わります。

4.2 「計画して終わり」ではない

そこで④LLMに、最初に処理のPlanを考えてもらうことにします。

1. 顧客を検索する
2. 契約を取得する
3. 更新可能か判断する
4. 契約を更新する
5. 更新結果を確認する
6. 担当者へメールする

しかし、最初の顧客検索で「A株式会社 東京本社」「A株式会社 大阪支社」「A株式会社 福岡支社」と返ってきたら、そのまま契約取得へ進むことはできません。どのA社なのかを特定する必要があります。

つまりPlanは、最初に一度作れば終わりではありません。Toolを実行した結果を観測し、その結果をもとにPlanを修正する必要があります。

4.3 Plan → Act → Observe → Re-plan

図4-1 Plan・Act・Observe・Re-planのループ

目的に対してPlanを作り、そのPlanに従ってToolを実行し、結果をObservationとして受け取ります。その結果を評価し、必要であればPlanを修正して次のActionを決めます。

ここで重要なのは、Toolの実行結果が再びLLMへ戻ることです。LLMは最初にPlanを作るだけではなく、途中のObservationを受け取り、「この結果なら次に何をするべきか」を継続的に判断します。

4.4 実際にループしているのは誰なのか

ではLLMが自分でループしているのでしょうか。そうではありません。

④LLMはContextを受け取ってOutputを生成します。LLM自身がプログラムのように永続的に動き続け、Toolを呼び出しているわけではありません。ループそのものを制御しているのは③Runtimeです。

図4-2 Runtimeが制御する実行ループ

③Runtimeは現在のStateを保持し、④LLMへ判断を求めます。④LLMが次のActionを出力すると、③Runtimeが⑦Toolを実行します。その結果をObservationとしてStateやContextへ追加し、再び④LLMへ渡します。

つまり、ループを回しているのはRuntime、そのループの中で次に何をするかを考えているのがLLMです。

4.5 Stateが必要になる

処理が複数のステップにまたがると、現在どこまで進んだのかを保持する必要があります。これがStateです。

契約更新なら、顧客、契約ID、現在の終了日、更新可否、契約更新済みか、メール送信済みか、といった情報を途中状態として持つことになります。Toolを実行するたびにStateが変化し、④LLMには、その時点のPlan、State、Observationなど必要な情報をContextとして渡します。

4.6 LLMが決めたことを、そのまま実行してよいのか

ここでセキュリティ上かなり重要な問題が出てきます。④LLMが契約更新や決済をActionとして出力したからといって、③Runtimeが必ずそのまま実行しなければならないわけではありません。

企業システムなら、たとえば次のようなルールをRuntime側で強制できます。

• 参照系Toolは自動実行してよい
• 契約変更は担当者の権限を確認する
• 100万円を超える決済は人間の承認を要求する
• 特定の顧客データは外部サービスへ送信してはいけない
• 本番環境への変更は承認済みの操作だけ許可する

図4-3 LLMとToolの間にある制御点

「LLMに強力な権限を与える」と表現することがありますが、より正確には、LLMの出力に基づいて③Runtimeが強力な権限を行使できる状態と考えたほうが、セキュリティ設計上は分かりやすくなります。

4.7 ここまで来るとAgentらしくなる

Plan、State、Observation、Re-planという要素を全体図へ加えると、Agentらしい構造が見えてきます。

図4-4 Agentの基本構造が見えてきた

第1章では②をChatGPTとしていましたが、ここではより一般化してAgent / Hostとしています。特定のChatGPTというサービスではなく、LLMを使って目的達成のための実行ループを持つシステムとして考え始めたためです。

しかし、同じ仕事をするたびに毎回ゼロからToolの使い方や手順を考える必要があるのでしょうか。次章では、その仕事の進め方を再利用する⑤Skillを見ていきます。

5. 毎回ゼロから仕事のやり方を考えるの？ ― Skillの登場

Toolが外界に対する「道具」なら、その道具を使って仕事を進める方法も再利用したくなります。ここで⑤Skill¹を考えます。

5.1 Toolが道具なら、Skillはレシピ

たとえば料理を考えてみます。包丁、鍋、フライパン、コンロは道具です。しかし、道具をキッチンに並べただけでは料理は完成しません。「材料を切る」「鍋で煮る」「調味料を加える」といった、道具の使い方と順序が必要です。

Agentでも同じように考えられます。

• Tool：外界を観測・操作するための道具
• Skill：Toolなどをどのように使って目的を達成するかというレシピ

たとえば契約変更にsearch_customer、get_contract、update_contract、get_contact、send_mailというToolが用意されているとします。Toolだけを見ても、「契約変更」という仕事をどう進めるべきかは分かりません。

そこで契約変更Skillに、顧客の特定、契約内容の確認、更新可否の判断、契約更新、更新結果の確認、担当者の取得、完了通知という仕事の進め方を持たせます。

5.2 SkillはToolではない

図5-1 SkillとToolの違い

⑦Toolは「顧客を検索できる」「契約を更新できる」「メールを送信できる」といったCapabilityです。一方、⑤Skillは「契約変更という仕事では、これらのToolをどのように組み合わせるか」という知識や手順を提供します。

料理で言えば、包丁を使って切る能力そのものがToolで、カレーを作るために「材料を切り、炒め、水を加えて煮込む」という手順がSkillです。

5.3 Skillがあっても、単なる固定スクリプトとは限らない

Skillを「決められた順番でToolを呼び出すWorkflow」と理解すると、少し狭すぎます。もちろん、完全に手順が固定された処理ならWorkflowとして実装できます。

しかし、実際の仕事では途中の結果によって処理が変わります。契約を確認した結果、更新可能なら更新し、更新不可なら処理を止め、判断できなければ追加情報を取得する、といった分岐があり得ます。

そのためSkillは、必ずしもすべての実行順序を固定する必要はありません。目的、標準的な手順、利用するTool、判断基準、注意事項などを再利用可能な形にしたものとして考えると分かりやすくなります。

5.4 SkillとLLMの役割

Skillが手順を持つからといって、④LLMが不要になるとは限りません。「顧客を特定する」という一つのステップでも、会社名だけで特定できる場合もあれば、同名企業が複数見つかる場合もあります。

Skillは仕事の進め方を示しますが、途中で得られたObservationをどう解釈し、次に何をするかという判断には④LLMを利用できます。

図5-2 Skillを利用した実行ループ

Skillがあるからといって、Plan → Act → Observe → Re-planのループがなくなるわけではありません。Skillは、そのループに**「この仕事は基本的にどう進めるべきか」という再利用可能な知識を与えるもの**と考えられます。

5.5 Skillには何を持たせるのか

Skillの実装方法はシステムによって異なりますが、概念的には次のような情報を持たせることができます。

• Skillの目的
• 利用可能なTool
• 標準的な処理手順
• 判断基準
• 入力・出力の形式
• エラー時の対応
• 人間へ確認すべき条件
• 実行してはいけない条件

ただし、Skillに書いてあることと、システムとして強制されることは分けて考える必要があります。「100万円を超える変更では承認を取る」とSkillに書いてLLMへ指示することと、③Runtimeが100万円を超える更新Toolの実行を実際に拒否することは同じではありません。絶対に守らなければならない制御はRuntime側でも強制できるようにしておく必要があります。

5.6 SkillはAgentなのか

Skillがかなり複雑になると、「これはもうAgentなのでは？」という疑問も出てきます。

この記事では、Skillを仕事の進め方を再利用するための手順・知識として扱います。Skill自身が独立して目的を受け取り、Stateを管理し、状況に応じて自らPlanを変更しながら外界へ作用する実行主体とは限りません。

一方、その処理自体が独立したRuntimeを持ち、目的だけを渡されて、自ら状況を判断しながらToolを選択するようになると、単なるSkillではなくAgentとして考えたほうが分かりやすくなってきます。

5.7 全体図にSkillを加える

図5-3 Skillを加えたAgentの構成

5.8 そのTool、サービスごとに作るの？

ToolとSkillが揃えば、Agentはかなり複雑な仕事を進められるようになります。しかし、同じToolを別のAgentから使いたくなったとき、Agentごとに異なる接続方式へ対応しなければならないのでしょうか。

Toolが「道具」、Skillが「道具の使い方のレシピ」なら、次に欲しくなるのは、その道具を特定のAgent専用品にしないための共通のI/Fです。

次章では⑥MCPを見ていきます。

6. ある種のI/FとしてのMCP ― 道具を特定のAgentから切り離す

MCP（Model Context Protocol）を理解するために、まずAgentとは少し離れたところから「I/F」について考えてみます。

6.1 接続先が増えると、組み合わせも増える

たとえばGitHubを操作する機能をAgentから利用したいとします。GitHubのAPIを呼び出すプログラムを書くこと自体は、それほど不思議な話ではありません。しかし、AgentごとにToolの定義方法や呼び出し方法が異なれば、それぞれに合わせた接続部分が必要になります。

図6-1 Agentごとに接続を実装する

さらにGitHubだけでなく、ファイルシステム、データベース、社内システムなどを利用するようになると、AgentとToolの組み合わせごとに接続方法を考えることになります。

これはAIに限った新しい問題ではありません。コンピュータの世界では昔から、上位の仕組みと下位の仕組みを直接結び付けると、組み合わせが増えたときにつらくなるという問題を、両者の間に共通のI/Fを設けることで解決してきました。

6.2 コンピュータはI/Fを挟んで発展してきた

少しAIから離れてみます。コンピュータには、異なる実装同士を直接依存させないための境界がいくつもあります。

たとえばPCをかなり単純化すると、Applicationが個々のHardwareを直接操作するのではなく、OSやDriver、Firmwareなどの層を介して利用します。PCの歴史ではBIOSやUEFIなども、SoftwareとHardwareの間にある境界の一部を担ってきました。

図6-2 SoftwareとHardwareの間にあるI/F

もちろんOS、Driver、BIOS、UEFIとMCPが技術的に同じという話ではありません。ここで注目したいのは、上位側が下位側の個別実装をすべて直接知るのではなく、その間に一定のI/Fを設けるという設計の考え方です。

Webシステムにも似た構造があります。BrowserやApplicationがServer内部の処理ロジックへ直接依存するのではなく、HTTP上のREST APIなどをI/Fとして利用できます。

図6-3 REST APIをI/Fとした例

Server側の処理ロジックをJavaからPythonへ変更しても、APIの契約が維持されていればClient側まで変更する必要はありません。逆にClientがBrowserからスマートフォンアプリへ変わっても、同じAPIを利用できます。I/Fによって、境界の両側をある程度独立して変更できるわけです。

6.3 MCPもI/Fとして考えてみる

AgentとToolの関係へ戻ります。これまでの図では、③Runtimeから⑦Toolを直接利用していました。

図6-4 RuntimeからToolを直接利用する

これでもAgentは作れます。しかし接続方法がAgentやAIサービスごとに異なれば、同じCapabilityを別のAgentから利用するときに接続部分を作り直す必要があります。そこで、Agent/Host側とCapabilityを提供する側との間に共通のI/Fを設けます。

図6-5 MCPをI/Fとして挟む

これがMCPを理解するための最初のイメージです。MCPはAgentでもLLMでもToolでもありません。Agent/Host側と外部Capabilityを提供する側との接続境界を標準化するProtocolです。

前節のREST APIとは技術的に別物ですが、「上位側を下位側の個別実装へ直接依存させず、その間に共通のI/Fを設ける」という設計上の考え方には共通するものがあります。

6.4 MCPによって何が変わるのか

MCPによって変わるのは、Toolを使えるかどうかではありません。外部機能を呼び出すこと自体は、MCP以前からFunction CallingやAPI Callによって可能でした。

変わるのは、Agent/HostとCapabilityのつながり方です。

MCPがなければ、それぞれのAgent/HostとCapabilityの組み合わせに応じて接続部分を実装することになります。

図6-6 MCP導入前 ― Agent/HostとCapabilityごとの個別接続

Agent/HostとCapabilityが増えるほど、個別の接続も増えていきます。

MCPという共通のI/Fを境界にすると、つながり方が変わります。

図6-7 MCP導入後 ― 共通の接続境界

Agent/Host側もCapability側も、相手ごとの個別方式ではなく、共通のProtocolへ対応できるようになります。これによってCapabilityを特定のAgent専用として作るのではなく、異なるHostから再利用しやすくなります。

ここがMCPの大きな価値です。MCPによって初めて外部機能を呼べるようになったのではなく、外部Capabilityとの接続境界を共通化したことで、そのつながり方が変わったのです。

6.5 MCPは「どこに置くか」を決めるProtocolではない

ここまでの図では⑥MCPを一つの箱として描いていますが、これは説明のための表現です。「MCPというサーバー製品をAgentとToolの間に一台置く」という意味ではありません。

MCPではCapabilityを利用する側をClient、提供する側をServerという論理的な役割として扱いますが、MCP Serverは必ずしも独立したNetwork Serverを意味しません。

図6-8 MCPの役割と配置は別の話
Remote構成ではMCP Serverがネットワーク上のServiceとして存在することがあります。一方、HostがMCP Serverの役割を持つLocal Processを起動して通信する構成や、ClientとServerの役割を同一Process内へ配置する構成も考えられます。

重要なのは、Protocol上のClient / Serverという役割と、ProcessやMachineといった実装上の配置は別の問題だということです。

6.6 MCPでは何を共通化しているのか

MCPでは単にToolを呼び出す通信形式だけでなく、接続した相手がどのようなCapabilityを提供しているかを扱うための仕組みも定義されています。この記事で中心に扱ってきたToolsのほか、ResourcesやPromptsといったものもあります。

• Tools：処理を実行するためのCapability
• Resources：利用可能なデータやContext
• Prompts：再利用可能なPrompt

たとえばToolであれば、利用側は提供されているToolの情報を取得し、その名前や入力形式などを知ったうえで呼び出せます。

図6-9 MCPにおける論理的な役割

つまりMCPは、「このURLをHTTPで呼んでください」という個別の接続方法だけを共通化しているわけではありません。

6.7 MCPがあれば何でもそのまま動くわけではない

I/Fを標準化したからといって、すべてのAgentで完全に同じように利用できるわけではありません。これはREST APIでも同じです。

実際には認証・認可、Userの同意、Host側のUI、利用可能な権限、Secretの管理、実行環境、各Host独自のPolicyなどがあります。MCPに対応したCapabilityだからといって、どのHostへ持っていっても無条件で同じように動作するわけではありません。

したがってMCPによるPortabilityは、「何でもそのまま持ち運べる」という意味ではありません。Capabilityを接続するProtocolが共通化されたことで、Agent/Host固有の接続実装への依存を減らせるという意味で捉えるのが適切です。

6.8 全体図の最後のピースを埋める

これで⑥MCPも全体図に加わりました。

図6-10 ここまでに登場した要素の全体像

MCPを特別なAI技術として考えるより、「境界に共通のI/Fを置き、両側を疎結合にする」というコンピュータシステムで昔から使われてきた設計の延長として見ると、その役割が分かりやすくなります。

7. まとめ ― LLM、Agent、MCPを振り返る

ここまで、ChatGPTとGPTの違いから始めて、LLMに足りないものを一つずつ補いながら、Tool、Runtime、Agent、Skill、MCPまでを見てきました。最後に、この記事で登場した言葉とその役割を整理します。

図7-1 この記事で整理した全体像

この図は、すべてのAgentが必ずこの構成になっているという実装仕様ではありません。製品やFrameworkによって構成や名称は異なります。ここでは、それぞれがどのレイヤの話なのかを整理するための概念図として使っています。

7.1 出てきた言葉のおさらい

用語	この記事での意味
ChatGPT	GPTなどのModelを利用し、Userへ機能を提供するService
GPT / LLM	Contextを受け取り、推論してOutputを生成するModel
Context	Userの入力、会話履歴、Toolの結果など、LLMがその時点の推論に利用する入力情報
Runtime	LLMを呼び出し、Stateを管理し、Toolの実行や処理全体のループを制御する仕組み
State	目的、途中までの処理結果、現在の進行状況など、処理を継続するために保持する状態
Plan	目的を達成するために何をするかという計画
Observation	Toolの実行などによって得られた外界からの情報
Tool	Agent/Hostが外界を観測・操作するために利用するCapability
Skill	Toolなどをどのように使って仕事を進めるかという、再利用可能なレシピ・手順・知識
Agent	LLMやToolなどを利用し、目的に向かって状況を判断しながら処理を進める実行主体
Host	LLM、Skill、Toolなどを利用するための実行環境を提供する側
MCP	Agent/Hostと外部Capabilityとの接続境界を標準化するProtocol
MCP Client	MCPにおいてCapabilityを利用する側の論理的な役割
MCP Server	MCPにおいてCapabilityを提供する側の論理的な役割。独立したNetwork Serverとは限らない
Capability	システムが外部へ提供できる「何ができるか」という能力
External World	Web、Database、File、外部Serviceなど、Agentの外側にある世界

一言でまとめるなら、LLMが考え、Skillが仕事の進め方を与え、Toolが外界に対する手足になり、Runtimeがそれらを使って実行ループを回す。MCPは、その手足を特定のAgent/Hostに密結合させず、共通のI/Fで接続するためのProtocolという関係です。

7.2 LLMを使っていればAgentなのか？

ここまでの整理で重要なのは、「LLMを使っているものをすべてAgentと呼ぶ」という話ではないことです。たとえば内部でLLMを使って文章を分類したり、名称を正規化したり、決められた候補から処理を選択したりするToolを作ることもできます。

従来のシステムでもRule EngineやOptimizerは条件によって処理を選択してきました。LLMを内部で利用したからといって、その瞬間にToolがAgentへ変わるわけではありません。Agentを考えるうえでは、LLMを使っているかどうかだけではなく、目的に対してどこまでActionを選択できるのか、ObservationによってPlanを変更できるのか、利用するToolを選択できるのかといった裁量を見る必要があります。

これは設計だけでなく、セキュリティやガバナンスを考える場合にも重要です。「LLMを使っているか」という分類だけでは、そのシステムが実際に何を判断し、何を実行できるのかは分かりません。どの実行主体が、どのCapabilityを、どの権限で、どこまで自律的に利用できるのかを分けて考える必要があります。

7.3 そして、その先へ

ここまではLLMから始めて、AgentがToolを利用する仕組みと、その接続境界を標準化するMCPまでを見てきました。

では、AgentがToolを使うだけではなく、別のAgentへ仕事そのものを頼むようになったらどうなるのでしょうか。

図7-2 Agentのその先

ToolにCapabilityの実行を依頼するのではなく、別のAgentへ目的やTaskそのものを渡す。そこから先には Agent2Agent（A2A） の世界があります。

Agent同士がつながると何が変わるのか。MCPとは何が違うのか。

それはまた別のお話。

参考資料

• Model Context Protocol - MCP公式ドキュメント
• Attention Is All You Need - Vaswani et al., 2017
• Improving Language Understanding by Generative Pre-Training - Radford et al., 2018
• Training language models to follow instructions with human feedback - Ouyang et al., 2022

1. Skillという言葉はMCPのように単一の標準仕様で意味が定義された用語ではなく、製品やFrameworkによって意味や実装が異なります。本稿では、Toolなどをどのように使って仕事を進めるかという、再利用可能なレシピ・手順・知識をSkillと呼びます。 ↩