Prompt、Skill、Agent、Tool、MCPの違いを一度で整理する

Prompt、Skill、Agent、Tool、MCPは同じAIの話題で並べられがちですが、同じものの別名ではありません。長いプロンプトをSkillと呼んだり、MCP ServerにつないだだけでAgentになったと考えたり、関数を一度呼び出すチャットボットまで自律型システムとして扱ったりすると、設計の境界が崩れます。

その結果、本来は再利用できる手順として管理すべき内容を毎回書き直し、反対に、実行ループへ任せるべき仕事を何十回もの手動対話へ分解することになります。

この記事では、各概念が何を担当するのか、どう組み合わさるのか、そして具体的な仕事にどの層を使うべきかを整理します。

概念の確認日：2026-08-28
注記：SkillやAgentの製品上の定義はベンダーごとに異なる場合があります。本文では、複数プラットフォームを比較しやすい実務的な定義を採用します。

先に結論：5つは別の役割を持つ

まずは、次の5行で捉えると混乱しにくくなります。

• Prompt：今回の対話でモデルへ渡す指示とコンテキスト。
• Skill：特定種類の仕事を再利用可能・発見可能・保守可能にした作業パッケージ。
• Tool：検索、ファイル読取、DB照会、メール送信など、実際に実行できる1つの能力。
• MCP：AIアプリと外部コンテキスト／能力を接続するオープンプロトコル。ToolだけでなくResourcesやPromptsも扱える。
• Agent：目標に向けて判断し、行動を選び、結果を観察し、停止条件まで処理を進める実行システム。

よくある組み合わせは次の通りです。

Promptで今回の目標を伝え、Agentが適切なSkillを選び、Toolを直接またはMCP経由で利用し、結果を確認しながら完了・失敗・人の判断が必要な地点まで進めます。

ただし、これは必須の技術スタックではありません。AgentはSkillなしでも動き、Toolは通常のAPIで直接統合でき、MCPは一般的なチャットアプリからも利用できます。区別すべきなのは、指示、手順、操作、接続、実行主体です。

四半期レポートで全体の流れを見る

「社内データを使ってQ3のプロダクト運用レポートを作成し、成長率、継続率、主要機能の利用状況を分析して、経営層がそのまま読める文書にしてほしい」と依頼したとします。

この依頼文が Prompt です。会話に貼った情報だけを基に文章を生成するなら、まだ1回のモデル呼び出しにすぎない可能性があります。

実行能力を持つ Agent は、必要なデータ、採用する指標定義、不足情報、検収条件まで判断します。「四半期運用レポート」の Skill があれば、承認済みの指標、分析順序、文書テンプレート、品質チェックを読み込みます。

次に複数の Tool を使います。データウェアハウスを照会し、前四半期のレポートを読み、指標を計算し、最終文書へ書き込みます。Toolはアプリへ直接統合することも、MCP Serverから公開することもできます。

大量の過去資料から関連部分を探す必要があれば、RAG が検索を担当します。最後にAgentがSkillの検収項目と照合し、必要な修正を行ってから成果物を返します。

Prompt：今回、何をしてほしいのか

Promptは、モデルへ渡す指示、質問、例、コンテキストです。1文でも、役割・背景データ・制約・出力形式を含む長い依頼書でも構いません。長さで分類は変わらず、2,000語の指示でもPromptのままです。

代表的なものは2種類あります。

• System Prompt：役割、優先順位、境界、基本動作を設定する。「認証情報を開示しない」などの基礎ルールを含む。
• User Prompt：今回の具体的な仕事を伝える。「3製品を比較し、調達案を出す」など。

Promptは、探索段階や一度きりの仕事に向いています。手順が固まっていないうちは、まずPromptで試す方が速くて安価です。一方、同じ要件を毎回渡す必要があり、人によって表現が変わり、長文化すると指示同士が衝突しやすくなります。

判断基準は単純です。次の同種タスクでも同じ説明を貼り直す必要があるか。必要なら、その内容はまだPrompt層にあります。

Skill：同じ種類の仕事を今後どう進めるか

Skillは「保存した長いPrompt」と同義ではありません。どの仕事で使うかをシステムが発見でき、必要なときに詳細手順を読み、スクリプト、テンプレート、参考資料、検収基準を追加で開ける再利用パッケージです。

Agent Skills仕様では、Skillは最低限 SKILL.md を含むディレクトリです。必要に応じて scripts/、references/、assets/ を追加できます。メタデータで候補を発見し、採用時に完全な手順を読み、補助資料は必要になった時点で読み込む「段階的開示」が前提です。

実務で使えるSkillには、通常次の内容があります。

• いつ起動し、どの状況では使わないか;
• 最初に読むべき一次情報;
• 作業の標準順序;
• 利用できるToolやスクリプト;
• 成果物の品質基準;
• データ不足、失敗、高リスク操作への対処。

なお、すべての製品がSkillを同じ意味で使うわけではありません。保存プロンプト、ショートカット、専用ToolをSkillと呼ぶ製品もあります。設計を議論するときは、再利用可能な作業パッケージを指すのか、特定製品の機能名を指すのかを明確にしましょう。

Tool：具体的な操作を1つ実行する

Toolは、モデルやAgentが実行を要求できる能力です。通常は明確な名前、入力、結果があります。

• search_web(query)：Webを検索する;
• read_file(path)：ファイルを読む;
• query_sales(start_date, end_date)：売上データを照会する;
• send_email(to, subject, body)：メールを送る;
• run_tests(scope)：テストを実行する。

Toolが答えるのは「この1ステップを実行できるか」です。仕事全体の計画は通常持ちません。メール送信Toolはメッセージを送れますが、誰に送るべきか、文面が規程に合うか、送信によって目標を達成したかまでは判断しません。

Toolは必ずしも無状態・無害ではありません。天気情報の取得は読取専用でも、注文作成、ファイル削除、通知送信は外部状態を変えます。実運用では権限、リスク、再試行可能性、確認条件を明示する必要があります。

Function Calling：Toolを使うための仕組みの1つ

Function Callingでは、モデルが構造化されたTool呼び出し要求を生成します。アプリが引数を検証して関数を実行し、結果をモデルへ返します。OpenAIのFunction Callingガイドも、モデルとアプリ側関数の複数段階のやり取りとして説明しています。

これはTool利用の重要な基盤ですが、Function Calling対応だけでAgentになるわけではありません。固定関数を1回呼び、その結果を返すだけなら、Tool対応アシスタントに近い設計です。Agentと呼べるかは、目標に向けた複数ステップの判断、環境からのフィードバック、経路修正があるかで判断します。

MCP：接続を標準化するが、判断は代行しない

MCPはModel Context Protocolの略です。MCP 2026-07-28仕様は、LLMアプリが外部データや能力へ接続するためのオープンプロトコルで、Host、Client、Server間の通信と能力発見を定義します。

「AIのUSB-C」という比喩は入口として便利ですが、2点を補う必要があります。

1. MCPはTool専用ではない。 ServerはResourcesやPromptsも公開でき、現行仕様にはSkills over MCPなどの任意拡張もある。
2. MCPは業務判断を提供しない。 能力を見つけて利用可能にするが、目標、実行順序、検収条件を自動決定するものではない。

つまり、MCP Serverへ接続したことは標準的な統合経路ができたという意味です。システム全体がAgentかどうかは、その周囲にあるモデル、指示、編成、権限、状態、フィードバックループで決まります。

逆に、Agentの構築にMCPは必須ではありません。APIやローカル関数を直接統合できます。複数の互換クライアントから同じ能力を発見・再利用したい場合、MCPの価値が大きくなります。

Agent：目標に向けて処理を閉じる

Agentは新しい種類のモデルではありません。モデルに指示、コンテキスト、状態、Tool、実行ループを組み合わせた、稼働中のシステムです。

実用的なAgentは通常、次の循環を持ちます。

1. 目標と制約を理解する;
2. 次の行動を選ぶ;
3. SkillまたはToolを選択する;
4. 実行して現実の結果を観察する;
5. 続行、修正、人への確認、停止を決める。

Agentに業界共通の唯一の定義はありません。実務上分かりやすい境界は、AnthropicのBuilding Effective Agentsにあります。Workflowは事前定義されたコード経路でモデルとToolを動かし、Agentはモデル自身が処理とTool利用を動的に決定します。

次の3問で、Agentらしさを確認できます。

• 中間ステップを現場情報からモデルが選ぶか、それともすべて固定されているか;
• Toolの結果やエラーを見て次の行動を変えるか;
• 成功、失敗、権限要求に対する停止条件があるか。

質問へ答えるだけのチャットボットは通常この条件を満たしません。単一関数を呼ぶアシスタントは一部を満たす場合があります。テスト失敗を読み、コードを修正し、再実行してさらに調整するシステムは、より明確にAgentへ近づきます。

RAG、Workflow、Memory、Multi-Agentの位置づけ

これらは前の5概念と並べられますが、別の設計問題に答えます。

RAG：回答の根拠を探す

RAG（Retrieval-Augmented Generation）は、生成前に文書ストアや検索システムから関連情報を取得します。「何を根拠にするか」を解決しますが、作業手順全体は定義しません。

ナレッジベースは参考図書、Skillは作業指示書です。Skillが「分析前に最新規程を検索する」と定め、RAGが該当箇所を取得する、という組み合わせが可能です。

Workflow：決まった手順を安定して動かす

Workflowは事前定義された処理経路です。手順が安定し、分岐が既知で、監査性が必要な仕事に向きます。「請求書受領 → 項目抽出 → 税番号確認 → 会計システム登録 → 経理通知」はWorkflow向きです。

Agentは、目標は明確でも経路を列挙できない仕事に向きます。成熟したシステムでは、Agentが状況を判断し、確定した区間をWorkflowが安定実行する構成がよく使われます。

Memory：ステップや会話をまたいで状態を残す

Memoryは「何を覚えておくか」を扱います。タスク状態、ユーザー設定、過去の判断、長期事実などです。Memoryは自動的にSkillにはなりません。「このユーザーは簡潔な報告を好む」は状態であり、「四半期報告の承認済み手順と検収表」は作業標準です。

Multi-Agent：複数の実行主体を編成する

Multi-Agentは、調査、執筆、レビューなどを複数Agentへ分担し、調整役が統合する構成です。仕事を明確に分割でき、並列化や専門化の効果が調整コストを上回るときに有効です。

曖昧な依頼を複数Agentへそのまま配っても、品質が自動的に上がるわけではありません。

比較表：定義、役割、よくある誤用

タスク別：どの層を選ぶか

一度きりで、人が簡単に確認できる

Promptから始めます。メール1通の書き直し、コードの説明、1回の会議アジェンダ作成なら、手順が未確定な段階で大きな仕組みを作る必要はありません。

同じ仕事が繰り返され、品質と手順を揃えたい

安定した部分をSkillにします。週次分析、ブログ公開、契約レビュー、障害振り返りでは、起動条件、一次情報、標準手順、境界、検収項目を明文化します。

リアルタイム情報を読む、または外部状態を変える

Toolを用意します。在庫確認、ファイル読取、テスト実行、チケット作成、通知送信には実行能力が必要です。書込、削除、決済、外部送信には最小権限と確認を設定します。

同じ外部能力を複数のAIアプリから使いたい

MCPを検討します。Tool、Resource、Promptテンプレートを共通の接続面から公開できます。小さな単一アプリだけなら、関数やAPIの直接統合が簡単な場合もあります。

目標は明確だが、中間経路が結果によって変わる

Agentを使います。「失敗テストの原因を特定して修正する」は、変更ファイル数や試行回数を事前に決められません。権限、予算、タイムアウト、停止条件を必ず与えます。

手順が固定され、監査性と予測可能性が重要

Workflowを優先します。すでに決まった処理をモデルに毎回再判断させる必要はありません。本当に意味判断が必要な節だけAgentへ渡します。

5つのよくある誤解

長いPromptはSkillになる

なりません。境界は長さではなく、適用範囲、発見方法、保守可能な構造、再利用資源、品質基準があるかです。

MCPへ接続すればAgentになる

なりません。MCPは統合を、Agentは判断と完了までの実行を扱います。MCP Serverにつながったチャットボットは、外部情報へアクセスできるチャットボットのままかもしれません。

Toolを呼べれば必ずAgentである

必ずしもそうではありません。固定Toolを1回呼んで返すだけでは、継続観察、修正、停止判断がありません。Agentの部品ではあっても、完全な実行ループとは限りません。

RAGでSkillを置き換えられる

置き換えられません。RAGは経費規程の内容を取得します。Skillは、どの条項を確認し、例外をどう扱い、結論をどう記録するかを定めます。

AgentはWorkflowより常に高度である

違います。固定的で高リスク、監査重視の処理にはWorkflowの予測可能性が向きます。経路が不確実な仕事ではAgentの判断が役立ちます。複雑さはラベルではなく成果のために選びます。

Promptから実働システムへ育てる順序

一気に万能Agentを作るより、段階的に進める方が安定します。

1. **Promptで仕事を成立させる。**価値があるか確認し、人が実際にどう進めるか観察する。
2. **繰り返す指示を特定する。**毎回必要な手順、制約、形式、検収項目を記録する。
3. **Skillへ整理する。**安定した手順、資料、テンプレート、スクリプトを保守可能な形へまとめる。
4. **Toolを追加する。**実データの読取と外部操作を、明確で小さな能力にする。
5. **必要ならMCPを採用する。**複数クライアントでの再利用や共通管理が必要なときに接続を標準化する。
6. **動的判断だけAgentへ任せる。**環境フィードバックによって変わる経路だけを委ねる。
7. **評価とログで改善する。**完了率、人への引継ぎ地点、Toolエラー、コスト、リスクを追う。

ここまで進むと、AIは一度きりの文章生成から、繰り返し成果を届ける作業システムへ変わります。

最後に覚える関係

最短で覚えるなら、レストランに置き換えられます。

• Promptは、今回の注文とアレルギー情報;
• Skillは、繰り返し使えるレシピと盛り付け基準;
• Toolは、包丁、コンロ、レジ、発注システム;
• MCPは、厨房設備やシステムの共通接続規格;
• Agentは、注文を理解し、レシピを選び、設備を使い、料理を確認し、作り直すか判断する料理人;
• RAGは、旬の食材や仕入先情報を調べる検索プロセス;
• Workflowは、厨房で固定化された生産ライン。

大切なのは、最も先進的に聞こえる略語を選ぶことではありません。不足しているのが、今回の指示、再利用できる手順、実行能力、接続規格、根拠となる知識、目標を完了まで運ぶ実行主体のどれかを見極めることです。

References

• FamilyPro ChatGPT 製品ページ
• FamilyPro Grok 製品ページ
• Agent Skills仕様：ディレクトリ構造、SKILL.md、段階的開示
• Model Context Protocol 2026-07-28仕様
• OpenAI Function Callingガイド
• Anthropic：Building Effective Agents