0. 要旨
AIエージェント周辺の用語は「同じ階層の部品名」ではなく、脳・職務記述書・技能・道具・通信規格・外部サービス・認証情報が混在しており、大変わかりにくい状況です。
整理すると、AIエージェントは次のような階層構造で捉えると明瞭になります。
ユーザーの自然言語
↓
メインLLM
↓
目的・意図の解釈
↓
Agent / Plugin / Skill / Tool の選択
↓
内部処理 or 外部呼び出し
↓
MCP / API / Browser Use / Computer Use
↓
外部サービス・データ・別モデル
↓
結果の評価・統合
↓
ユーザーへの返答
人間・組織に例えるなら、次の構造です。
AI組織
社長
└─ メインLLM
社長の思考機能
└─ Reasoning
記憶
└─ Memory
部署
└─ Plugin
部長・専門管理職
└─ Agent / Subagent
熟練技能
└─ Skill
業務手順書
└─ Workflow
道具
└─ Tool
道具カタログ・発注仕様書
└─ Tool Definition
取引先接続規格
└─ MCP
取引先の担当窓口
└─ MCP Server / API
会員証・鍵・ログイン情報
└─ Connector
外部組織・外注先
└─ App / SaaS / DB / Image Model / Search Engine
1. 内部用途と外部用途の基本分離
まず、AIエージェントの構成要素は「内部用途」と「外部用途」に分けるべきです。
AI内部
├─ LLM
├─ Reasoning
├─ Prompt / Instruction
├─ Memory
├─ Skill
├─ Workflow
├─ Agent
├─ Subagent
└─ Plugin
境界層
├─ Tool Definition
├─ Tool
├─ Connector
├─ Browser Use
├─ Computer Use
└─ MCP Client
外部層
├─ MCP Server
├─ API
├─ SaaS / App
├─ Database
├─ File System
├─ Search Engine
└─ Other AI Model
この分離をすると、混乱の大部分が消えます。
Plugin、Skill、Agent は主に内部の仕事のまとめ方です。
MCP、Connector、API、Browser Use、Computer Use は外界との接続方法です。
App、SaaS、DB、画像生成モデルなどは外部の目的地・外注先です。
2. LLM と Reasoning の関係
LLM と Reasoning は並列ではありません。
正確には、
Reasoning ⊂ LLM
です。
LLM は大脳全体に近く、その中に言語理解、知識想起、推論、計画、評価、生成が含まれます。Reasoning はその中の「前頭前野的な機能」です。
LLM
├─ 言語理解
├─ 知識想起
├─ 推論
├─ 計画
├─ 評価
└─ 生成
したがって、
LLM = 大脳
Reasoning = 大脳内の前頭前野的機能
と見るのが自然です。
Reasoning を独立部品として扱うより、「LLM の中で目標達成・計画・検証に関わる機能」と捉えた方が構造的に整合します。
3. Tool Definition と Tool の違い
ここが非常に重要です。
Tool Definition はツールそのものではありません。
Tool Definition は、
{
"name": "search_documents",
"description": "契約書・社内規程・稟議書を検索する",
"inputSchema": {
"query": "string"
}
}
のような、AIに向けた「能力の仕様書」です。
人間に例えると、
この部署は契約書検索ができます
この道具は売上データを取得できます
この外注先は画像生成ができます
というカタログです。
一方、Tool は実際に呼び出される能力です。
Tool Definition
↓
LLMが選択
↓
Tool実行
↓
内部処理 or 外部呼び出し
Tool の実体はさまざまです。
Tool
├─ 内部コード
├─ Python / TypeScript スクリプト
├─ Web検索
├─ Browser Use
├─ Computer Use
├─ MCP Server 呼び出し
├─ API 呼び出し
├─ DB検索
├─ 画像生成モデル
└─ 別LLM / Subagent
つまり Tool Definition は「仕様書・発注書・広告文」であり、Tool は「実際の能力」です。
LLM はユーザーの自然言語を解釈し、その意図に近い Tool Definition を選びます。したがって似たような Tool Definition が複数あると、誤って別のツールへルーティングする可能性があります。これは現在のAIエージェント設計における中核的な問題です。
4. Skill の定義
Skill は、単発の道具というより、再利用可能な業務手順・技能パッケージです。
OpenAI Codex の公式ドキュメントでは、Skill は「instructions, resources, optional scripts」を含み、Codex がワークフローを安定して実行するためのタスク特化能力として説明されています。また、Skill は SKILL.md を中心に、任意で scripts、references、assets を含める構造になっています。(OpenAI Developers)
Claude Code の公式ドキュメントでも、Skill は SKILL.md に指示を書き、Claude が関連すると判断したとき、または /skill-name で直接指定されたときに使われるものとして説明されています。さらに、Claude Code の bundled skills は固定ロジックではなく、プロンプトベースでClaudeに詳細指示を与え、Claudeがツールを使って作業を編成するものと説明されています。(Claude API Docs)
したがって、Skill の実体は次の混合物です。
Skill
├─ Prompt / Instruction
├─ Workflow
├─ Examples
├─ References
├─ Templates / Assets
└─ Optional Scripts
人間に例えると、
Skill = 小脳的な熟練技能 + 業務マニュアル
です。
たとえば、
契約書レビューSkill
DCFモデル作成Skill
議事録作成Skill
ピッチデック作成Skill
コードレビューSkill
は、それぞれ「毎回ゼロから考えるより、一定の型で進めるべき仕事」です。
5. Workflow の定義
Workflow は、Skill よりも「手順」に焦点があります。
Workflow
├─ Step 1
├─ Step 2
├─ Step 3
└─ Step 4
たとえば、あなたが提示した pitch-agent には次のような流れがありました。
1. Scope the ask
2. Write the situation overview
3. Pull data
4. Spread the peer set
5. Stand up the sponsor case
6. Build the rest of the model
7. Generate the football field
8. Populate the deck
9. Run deck QC
これは明らかに Workflow です。
Workflow は基本的には「業務手順書」です。
Agent は、その Workflow を読み、必要に応じて Skill や Tool を呼びます。
Agent
↓
Workflowを読む
↓
Skillを呼ぶ
↓
Toolを使う
↓
結果を評価する
6. Agent の定義
Agent は単なるプロンプトではありません。
Agent の本質は、
目的を理解する
↓
計画する
↓
実行する
↓
結果を評価する
↓
必要なら修正する
という フィードバック制御です。
したがって、Agent は次の要素を持ちます。
Agent
├─ Role
├─ Goal
├─ Workflow
├─ Tool Access
├─ Skill Access
├─ Guardrails
├─ Evaluation Criteria
└─ Execution Loop
人間に例えると、Agent は「部長」または「プロジェクトマネージャー」です。
社長 = メインLLM
部長 = Agent
社員 = Skill
道具 = Tool
取引先 = MCP Server / API
ここで重要なのは、Agent = Sub LLM とは限らないという点です。
Agent は次のどちらでも成立します。
パターンA:
メインLLM
↓
Agent用Prompt
↓
同じLLMが役割を演じる
パターンB:
メインLLM
↓
Subagent
↓
別のLLM呼び出し・別コンテキスト・別ツール権限
あなたが提示した pitch-agent 定義を見る限り、そこには model: の明示や、独立した実行プロセスを示す記述はありません。したがって、それ単体からは「サブLLMが入っている」とは断定できません。
より正確には、
pitch-agent = Agent定義ファイル
です。
中身は、
Pitch Agent
├─ Metadata
├─ Role Prompt
├─ Output Contract
├─ Workflow
├─ Guardrails
├─ Tool Permissions
└─ Skill Dependencies
です。
7. Subagent と Multi-Agent
Subagent は、Agent の中でも独立した実行文脈を持つものです。
Claude Code の公式ドキュメントでは、custom subagents は Markdown ファイルと YAML frontmatter で定義され、name、description、tools、model、skills、mcpServers、memory、background、effort などのフィールドを持てます。特に model は sonnet、opus、haiku、inherit などを指定可能で、デフォルトは inherit です。つまり、Subagent は別モデルを使うことも、親と同じモデルを継承することもあります。(Claude API Docs)
OpenAI Codex の公式ドキュメントでは、Codex は specialized agents を parallel に spawn し、その結果を1つのレスポンスに統合できると説明されています。また、Codex は明示的に依頼されたときにのみ subagent を spawn すると書かれています。(OpenAI Developers)
この点について、前の議論の一部は修正が必要です。
「ユーザーが意図的にマルチエージェントを作れない」という一般化は、現在のCodex公式情報とは合いません。正しくは、
製品・画面・権限・設定によって、
ユーザーがSubagent / Multi-Agentをどこまで制御できるかが異なる
です。
Multi-Agent の定義はこうです。
Multi-Agent
= 複数の独立したAgent実行文脈が存在する状態
単に Tool が複数あるだけでは Multi-Agent ではありません。
単一Agent
├─ Tool A
├─ Tool B
└─ Tool C
これは「社長が複数の道具を使っている」状態です。
一方、
Multi-Agent
├─ Research Agent
├─ Finance Agent
├─ Legal Agent
└─ Writer Agent
これは「複数の部長がそれぞれ考えて作業している」状態です。
8. Plugin の定義
Plugin は最も混乱しやすい言葉です。
現在の文脈では、Plugin は単なる外部API呼び出しではなく、配布可能な業務パッケージと見るのが適切です。
Claude Code の公式ドキュメントでは、Plugin system は skills、agents、hooks、MCP servers によって機能拡張する仕組みとして説明されています。(Claude API Docs)
OpenAI Codex の公式ドキュメントでも、Skills は reusable workflows の authoring format、Plugins は reusable skills and apps の installable distribution unit と説明されています。(OpenAI Developers)
つまり Plugin は、
Plugin
├─ Skill
├─ Agent
├─ Hook
├─ MCP Server設定
├─ Tool定義
├─ Prompt
├─ Resources
└─ Optional Scripts
をまとめて配布する単位です。
人間に例えるなら、
Plugin = 部署パッケージ
です。
たとえば、
Legal Plugin
Finance Plugin
Marketing Plugin
Data Plugin
Pitch Plugin
は、それぞれ
法務部
経理部
マーケティング部
データ分析部
投資銀行ピッチ部
に相当します。
部署には、部長、社員、マニュアル、外注先、使用許可された道具、社内ルールが含まれます。Plugin も同じです。
9. MCP、MCP Server、API、Connector の関係
ここも重要です。
MCP はプログラムではありません。
MCP は通信規格です。
Anthropic の公式ドキュメントでは、MCP は AIアプリケーションを外部システムへ接続するためのオープン標準として説明されています。(Claude API Docs)
OpenAI Codex の公式ドキュメントでも、MCP は外部ツールやコンテキストプロバイダーに接続する標準的な方法であり、MCP servers は tools、resources、prompts を公開できると説明されています。(OpenAI Developers)
したがって、
MCP = 規格
MCP Server = 規格を実装したプログラム
API = 外部サービスの窓口
Connector = クライアント側の認証・接続設定
です。
関係はこうです。
LLM / Agent
↓
Tool Definition
↓
MCP Client
↓
Connector
↓
MCP Server
↓
API
↓
External App / DB / Service
Connector は「電話帳」では説明が浅いです。より正確には、
Connector
├─ 接続先
├─ 認証情報
├─ OAuth Token
├─ 権限
├─ 利用者アカウント
├─ 有効/無効設定
└─ 利用可能なスコープ
です。
人間に例えるなら、
Connector = 会員証 + 鍵 + 契約情報 + Cookie + パスワード管理
です。
MCP Server 側は「能力」を公開します。
Connector 側は「このユーザーがその能力を使える状態」を保持します。
10. Prompt・Program・Data・Config の分解
あなたが最も知りたかった「それはプロンプトなのか、プログラムなのか、知識ファイルなのか」は、次のように整理できます。
Agent / Plugin / Skill の中身
├─ Prompt
│ ├─ Role
│ ├─ Instructions
│ ├─ Workflow
│ ├─ Guardrails
│ └─ Output Format
│
├─ Data
│ ├─ Knowledge
│ ├─ References
│ ├─ PDFs
│ ├─ Templates
│ ├─ Examples
│ └─ Assets
│
├─ Config
│ ├─ name
│ ├─ description
│ ├─ tool permissions
│ ├─ model selection
│ ├─ MCP server settings
│ ├─ connector settings
│ └─ invocation rules
│
├─ Program
│ ├─ scripts
│ ├─ hooks
│ ├─ validators
│ ├─ API wrappers
│ └─ MCP server implementations
│
└─ Model Runtime
├─ main LLM
├─ inherited model
└─ separate subagent model
あなたが提示した pitch-agent は、ほぼ次の構成です。
pitch-agent
├─ YAML Frontmatter
│ ├─ name
│ ├─ description
│ └─ tools
│
├─ System Prompt
│ └─ "You are the Pitch Agent..."
│
├─ Output Contract
│ ├─ Excel valuation workbook
│ └─ Pitch deck
│
├─ Workflow
│ ├─ Scope the ask
│ ├─ Pull data
│ ├─ Build model
│ └─ Populate deck
│
├─ Guardrails
│ ├─ No external communications
│ ├─ Cite every number
│ └─ Stop and surface for review
│
└─ Skill Dependencies
├─ sector-overview
├─ comps-analysis
├─ lbo-model
├─ dcf-model
├─ pitch-deck
└─ ib-check-deck
これはプログラム本体というより、宣言的なAgent定義ファイルです。
11. 複数Skillの逐次実行・同時実行
1つのプロンプトで複数Skillを指定した場合、挙動はランタイム次第です。
ただし構造的には、次の4パターンがあります。
パターン1: 逐次実行
/skill1
↓
/skill2
↓
統合
パターン2: 片方のみ実行
/skill1 または /skill2
パターン3: 両方を読み込んで一つの推論で処理
skill1 + skill2 の指示を統合
パターン4: 並列実行
skill1 ─┐
├─ 統合
skill2 ─┘
Skill の列挙だけでは並列実行は保証されません。
並列実行には、
Worker
Subagent
Task Scheduler
Parallel Runtime
のような仕組みが必要です。
Codex については、公式ドキュメント上、subagents を parallel に spawn して結果を集約できるとされています。(OpenAI Developers)
一方、あなたが提示した pitch-agent の定義だけを見る限り、Workflow は番号付きの逐次手順です。したがって、このファイル単体から読み取れるのは、主に逐次オーケストレーションです。
12. Tool選択ミスが起きる理由
Tool、Skill、Agent は、LLM が意味解釈によって選びます。
ユーザー指示
↓
LLMが意味を解釈
↓
Tool / Skill / Agent のdescriptionと照合
↓
最も近いものを選択
したがって、似たような定義があると誤選択が起きます。
悪い例です。
search_document
search_documents
search_file
search_files
境界が曖昧です。
良い例は、担当範囲を明確に分けることです。
search_contracts
契約書、NDA、覚書を検索する。社内規程や議事録には使わない。
search_policies
社内規程、就業規則、稟議ルールを検索する。契約書には使わない。
Tool Definition は単なる仕様書であると同時に、AI向けのルーティング広告文です。
人間の組織で言えば、
法務部: 契約・規制・リスク
経理部: 請求・仕訳・決算
営業部: 顧客・商談・売上予測
と部署名と担当範囲を明示するのと同じです。
13. 最終モデル
最終的に、AIエージェントの全体像は次のように表現できます。
AI Agent System
├─ Core Intelligence
│ ├─ LLM
│ └─ Reasoning
│
├─ Context Layer
│ ├─ Prompt
│ ├─ Instructions
│ ├─ Memory
│ └─ Project Guidance
│
├─ Capability Layer
│ ├─ Skill
│ ├─ Workflow
│ ├─ Agent
│ ├─ Subagent
│ └─ Plugin
│
├─ Interface Layer
│ ├─ Tool Definition
│ ├─ Tool
│ ├─ Browser Use
│ ├─ Computer Use
│ └─ MCP Client
│
├─ Connection Layer
│ ├─ Connector
│ ├─ OAuth
│ ├─ Permissions
│ └─ Auth Tokens
│
├─ Protocol Layer
│ ├─ MCP
│ └─ API
│
└─ External Layer
├─ MCP Server
├─ SaaS
├─ Database
├─ File System
├─ Search Engine
├─ Image Model
└─ Other LLM
組織比喩に置き換えると、こうです。
会社としてのAI
├─ 社長
│ └─ LLM
│
├─ 社長の思考能力
│ └─ Reasoning
│
├─ 記憶・資料室
│ └─ Memory / Knowledge
│
├─ 部署
│ └─ Plugin
│
├─ 部長
│ └─ Agent / Subagent
│
├─ 熟練社員
│ └─ Skill
│
├─ 業務マニュアル
│ └─ Workflow
│
├─ 道具
│ └─ Tool
│
├─ 道具カタログ
│ └─ Tool Definition
│
├─ 会員証・鍵
│ └─ Connector
│
├─ 取引ルール
│ └─ MCP
│
├─ 取引先窓口
│ └─ MCP Server / API
│
└─ 外注先・外部組織
└─ App / SaaS / DB / Model
14. 結論
この議論で到達した中心命題は次です。
AIエージェントとは、LLM単体ではなく、LLMを中心に、Prompt、Memory、Skill、Workflow、Agent、Tool、Connector、MCP、API、外部サービスを階層的に接続した業務遂行システムである。
さらに短く言えば、
LLM = 考える中枢
Skill = 定型能力
Workflow = 手順
Agent = 目的達成の管理職
Plugin = 部署パッケージ
Tool = 実行可能な道具
Tool Definition = 道具の仕様書
Connector = 利用者固有の鍵・認証情報
MCP = 共通通信規格
MCP Server = 能力提供プログラム
API = 外部サービスの窓口
App = 外部組織
Multi-Agent = 複数の管理職が独立文脈で動く組織
この整理の価値は、単に用語を覚えることではありません。
実務上は、
どこまでがPromptか
どこからがProgramか
どこにDataがあるか
どこで認証しているか
どこでLLMが判断しているか
どこで外部システムが動いているか
どこからMulti-Agentになるか
を切り分けられるようになります。
AIエージェントの設計とは、結局のところ「賢い脳を作ること」だけではなく、脳・技能・部署・道具・外注先・契約情報・通信規格をどう組織化するかという問題です。これは技術設計であると同時に、かなり組織設計に近い領域です。
