はじめに:AIエージェント、なんだか難しそう?
AIエージェントの話題を見ていると、「CLAUDE.md」「SubAgents」「Skills」「MCP」といった用語が飛び交っています。
正直、最初は「また新しい概念か…」と思いませんでしたか?
私も同じでした。公式ドキュメントを読んでも、それぞれの役割の違いがいまいちピンとこない。「SubAgentsとSkillsって何が違うの?」「MCPって結局なんなの?」という疑問がずっとありました。
でも、あるツイートを見て考え方が変わりました。
「AIエージェントの設計は、会社組織の設計と同じ」
この視点で見直すと、バラバラに見えていた概念が一気につながったんです。
この記事では、Claude Codeを例に、AIエージェントの構成要素を「会社組織」に置き換えて解説していきます。すでにAIをある程度触っている方なら、「あ、そういうことか」とスッキリするんじゃないかなと思います。
AIエージェント=会社組織という発見

きっかけは、X(旧Twitter)で見かけたこんな図でした。
| AIエージェントの構成要素 | 会社組織での対応 |
|---|---|
| CLAUDE.md | 業務マニュアル・社内規定 |
| SubAgents | 専門部署・担当社員 |
| Skills | 社員が持つスキル・資格 |
| MCP | 業務システム・ツール |
この対応関係、見た瞬間に「なるほど」と思いました。
考えてみれば、会社も一種の「エージェントシステム」ですよね。複数の人間が、それぞれの専門性を活かして、共通のルールのもとで協働している。AIエージェントも同じ構造を持っているわけです。
会社経営や組織マネジメントの知見が、そのままAIエージェント設計に転用できる。これって、けっこう大きな発見じゃないでしょうか。
では、それぞれの要素を詳しく見ていきましょう。
1. CLAUDE.md = 業務マニュアル

役割:プロジェクトの「常識」を定義する
CLAUDE.mdは、Claude Codeがプロジェクトに取り組む際の「業務マニュアル」です。
会社で言えば、新入社員が最初に読む「社内規定」や「業務手順書」に相当します。「うちの会社ではこうする」「このプロジェクトではこのルールで」という暗黙知を、明文化したものですね。
公式ドキュメント(Claude Code Settings)によると、CLAUDE.mdには以下のような情報を記載することが推奨されています。
記載すべき内容:
- 技術スタック(React + TypeScript、Python 3.11など)
- コーディング規約(命名規則、インデントなど)
- ディレクトリ構造の説明
- テスト方針(どんなテストを書くか)
- プロジェクト固有の用語や略語
3つの階層構造
面白いのは、CLAUDE.mdには3つのレベルがあるという点です。
| 階層 | 場所 | 適用範囲 |
|---|---|---|
| グローバル | ~/.claude/ | すべてのプロジェクト |
| プロジェクト | .claude/(プロジェクトルート) | 当該プロジェクトのみ |
| ローカル | 任意のディレクトリ | 特定のディレクトリ配下 |
会社で例えるなら、こんな感じでしょうか。
- グローバル:全社共通の就業規則
- プロジェクト:部署ごとの業務マニュアル
- ローカル:チーム内の申し合わせ事項
この階層構造のおかげで、「基本はこうだけど、このプロジェクトだけ例外」みたいな運用ができます。
注意点:トークン効率を意識する
CLAUDE.mdは毎回読み込まれるため、あまり長くしすぎるとトークンを消費してしまいます。公式ドキュメントでも「簡潔に書くこと」が推奨されています。
業務マニュアルも同じですよね。分厚すぎると誰も読まない。必要な情報を、必要な分だけ。
2. SubAgents = 専門部署・担当社員

役割:専門タスクを独立して処理する
SubAgentsは、Claude Codeの中で動く「専門担当者」です。
会社で言えば、経理部、法務部、デザイン部といった専門部署に相当します。それぞれが独自の専門性を持ち、必要に応じてメインの業務から仕事を引き受ける。
公式ドキュメント(Claude Code Sub-Agents)には、こう書かれています。
サブエージェントは、Claude Codeがタスクを委譲できる事前設定されたAIパーソナリティです。各サブエージェントは特定の目的と専門分野を持ち、メイン会話とは別の独立したコンテキストウィンドウを使用します。
ここで重要なのは「独立したコンテキストウィンドウ」という点です。
独立したコンテキスト=別の部屋で作業する
SubAgentsは、メインのClaude Codeとは別の「部屋」で作業します。
これを会社で考えると、「経理の計算は経理部の部屋で完結する」というイメージです。本社の会議室(メインコンテキスト)を占有しないので、効率的に並行作業ができます。
SubAgentsのメリット:
- メインのコンテキストが汚れない
- 専門タスクに集中できる
- 再利用性が高い(一度作れば他プロジェクトでも使える)
自動委譲と明示的な呼び出し
SubAgentsへのタスク委譲は、2つの方法があります。
- 自動委譲:Claude Codeが「これはあのサブエージェントの担当だな」と判断して自動的に委譲
- 明示的な呼び出し:「test-runnerサブエージェントを使って」と指示して呼び出す
会社で言えば、「これ経理に回しておいて」と明示的に指示する場合と、担当者が「あ、これは経理案件だな」と自分で判断して回す場合の両方がある、という感じですね。
設定ファイルの例
SubAgentsはMarkdownファイルで定義します。
---
name: code-reviewer
description: コード変更後に積極的にレビューを行う専門家
tools: Read, Grep, Glob, Bash
model: sonnet
---
あなたはシニアコードレビュアーです。
コード品質とセキュリティに焦点を当ててレビューしてください。
descriptionフィールドが重要で、ここに「どんな時に使うか」を書いておくと、Claude Codeが自動的に適切なSubAgentを選んでくれます。
📖 関連記事: SubAgentsの独立コンテキストがなぜ重要なのか、「Context Rot(コンテキスト劣化)」という観点から詳しく解説した記事があります。
3. Skills = 社員が持つスキル・資格
役割:必要な時だけ読み込む専門知識
Skillsは、Claude Codeが使える「スキルセット」です。
会社で言えば、社員が持っている資格やスキルに相当します。経理担当者が「簿記2級」を持っている、エンジニアが「AWS認定資格」を持っている、みたいな感じ。
公式ドキュメント(Claude Code Skills)によると、Skillsは必要な時だけ読み込まれるという特徴があります。
SubAgentsとの違い:コンテキストを共有するかどうか
ここがちょっと混乱しやすいポイントです。
| 項目 | SubAgents | Skills |
|---|---|---|
| コンテキスト | 独立(別の部屋で作業) | 共有(同じ部屋で作業) |
| 読み込みタイミング | 呼び出し時に起動 | 必要時に知識を読み込み |
| イメージ | 別の担当者に仕事を渡す | 自分でスキルを使って対応する |
会社で考えると、こうなります。
- SubAgents:「この案件、法務部に相談してきます」(別の人が対応)
- Skills:「法務の知識があるので、私が対応します」(自分が対応)
どちらも「専門性」を扱いますが、誰が作業するかが違うんです。
トークン効率の工夫
Skillsは、最初はnameとdescriptionだけが読み込まれます。実際に使う段階になって初めて、詳細な内容(SKILL.md本文)が読み込まれる仕組みです。
これは人間の記憶とも似ていますよね。「簿記の知識がある」ということは覚えているけど、具体的な仕訳ルールは必要になってから思い出す(参照する)。
📖 Skillsをもっと深く知りたい方へ
- 【図解】Claude CodeのSkills完全ガイド|従来手法との違いとFit&Gap分析 – Skillsの仕組みを図解で詳しく解説
- Anthropic公式「skill-creator」完全ガイド – Skillsを自動生成するツールの使い方
- 【2025年版】ClaudeのCustom Skillsで”めんどくさい仕事”を自動化した話 – 週報作成を15分→5分に短縮した実践例


4. MCP = 業務システム・ツール

役割:外部システムとの標準的な接続方法
MCP(Model Context Protocol)は、AIと外部システムをつなぐ「業務ツール」です。
会社で言えば、Slack、Google Drive、Salesforceといった業務システムに相当します。社員(AIエージェント)がこれらのツールを使って、データを取得したり、アクションを実行したりする。
Anthropicが2024年11月に発表したこのプロトコルは、「AIエージェントが外部システムと連携するための標準規格」として急速に普及しています(Introducing the Model Context Protocol)。
N×M問題の解決
MCPが解決しようとしている問題は、「N×M問題」と呼ばれています。
従来の課題:
- N個のAIアプリケーション
- M個の外部ツール・データソース
- それぞれの組み合わせごとにカスタム連携が必要
- →連携パターンがN×M個になって爆発する
MCPによる解決:
- 標準プロトコルを1つ定義
- AI側もツール側も、この標準に対応すればOK
- →連携パターンがN+M個に削減
会社で例えるなら、「各部署が独自のExcelフォーマットを使っていた状態」から「全社共通のシステムを導入した状態」への移行ですね。
3つのプリミティブ
MCPには、3つの基本機能(プリミティブ)があります。
| プリミティブ | 役割 | 会社での例 |
|---|---|---|
| Tools | AIが実行できる機能 | 「承認ボタンを押す」「メールを送る」 |
| Resources | AIが読み取れるデータ | 「売上データを参照する」「ドキュメントを読む」 |
| Prompts | 定型的な指示テンプレート | 「週次レポートのテンプレート」 |
業界標準になりつつある
MCPは、OpenAIやGoogleも採用を表明しており、2025年12月にはLinux Foundation傘下のAgentic AI Foundation(AAIF)に寄贈されました(Anthropic公式発表)。
これは「業界標準」になりつつあるということです。USBやHTTPのように、「みんながこれに対応していれば、とりあえずつながる」という安心感がありますね。
見落としがちな視点:オーケストレーター(指揮者)

ここまで4つの構成要素を見てきましたが、実は1つ重要な視点が抜けています。
「誰が全体を統括するのか?」
会社で言えば「経営者」や「プロジェクトマネージャー」に相当する存在です。
Human-in-the-Loop:人間による承認
現時点のAIエージェントでは、この「統括役」は基本的に人間が担います。
Claude Codeでも、重要な操作(ファイルの削除、外部APIの呼び出しなど)の前には確認が入ります。これは「Human-in-the-Loop」と呼ばれる設計思想です。
元ツイートでも指摘されていましたが、会社組織で言えば「承認する上司」の役割ですね。
現状の流れ:
- AIが計画を立てる
- 人間が確認・承認する
- AIが実行する
- 結果を人間が確認する
将来的にはAIオーケストレーターも?
ただ、ここは今後変わっていく可能性があります。
複数のAIエージェントを束ねる「AIオーケストレーター」が登場すれば、より自律的なシステムになるでしょう。その場合でも、最終的な責任は人間が持つ、という設計が重要になりそうです。
会社組織の視点で見る:As-Is/To-Be分析
ここで、AIエージェント導入前後を「会社組織の視点」で整理してみましょう。
| 観点 | As-Is(従来のAI活用) | 課題 | To-Be(エージェント設計後) |
|---|---|---|---|
| 知識管理 | 毎回プロンプトで指示 | 同じことを何度も書く | CLAUDE.mdで一元管理 |
| タスク分担 | 1つのセッションで全部 | コンテキストが溢れる | SubAgentsで分業 |
| 専門性 | その都度説明 | 品質にバラつき | Skillsで標準化 |
| ツール連携 | 個別にカスタム実装 | 保守コストが高い | MCPで標準化 |
会社で言えば、「属人的な運用」から「組織的な運用」への移行と同じですね。
解決策の適合性:Fit&Gap分析
「じゃあ、どの要素から取り入れればいいの?」という疑問があると思います。
以下は、よくある課題と解決策の適合性を整理したものです。
| 課題 | CLAUDE.md | SubAgents | Skills | MCP |
|---|---|---|---|---|
| 毎回同じ指示を書くのが面倒 | Fit | Gap | Gap | Gap |
| コンテキストがすぐ溢れる | Gap | Fit | Gap | Gap |
| 特定タスクの品質が安定しない | Fit | Fit | Fit | Gap |
| 外部サービスとの連携が大変 | Gap | Gap | Gap | Fit |
| チームで設定を共有したい | Fit | Fit | Fit | Fit |
まず取り組むなら:
- 個人で使うなら → CLAUDE.md から
- チームで使うなら → CLAUDE.md + SubAgents
- 外部連携が必要なら → MCP
実際に始めるなら
「理屈はわかった。で、どこから手をつければいいの?」
正直、全部を一度に導入するのは大変です。段階的に進めるのがおすすめです。
ステップ1:CLAUDE.mdを書いてみる
まずはプロジェクトのルートに.claude/CLAUDE.mdを作成してみましょう。
最初は簡単な内容でOKです。
# プロジェクト概要
このプロジェクトはReact + TypeScriptで構築されたWebアプリです。
# コーディング規約
- 変数名はcamelCaseを使用
- コンポーネントはPascalCaseを使用
- 関数には必ずJSDocコメントを付ける
# ディレクトリ構造
- src/components/ - UIコンポーネント
- src/hooks/ - カスタムフック
- src/utils/ - ユーティリティ関数
これだけでも、Claude Codeの挙動が変わるのを実感できると思います。
ステップ2:SubAgentsを1つ作ってみる
CLAUDE.mdに慣れたら、SubAgentsを1つ作ってみましょう。
/agentsコマンドを使うと、対話的に作成できます。
最初は「コードレビュアー」や「テストランナー」など、役割が明確なものから始めるのがいいですね。
💡 ヒント: SubAgentsやSkillsを含むプラグインを簡単に導入する方法もあります。
→ Claude Codeプラグインの導入方法|おすすめ5選と管理方法を解説

ステップ3:MCPサーバーを接続してみる
外部連携が必要になったら、MCPサーバーを試してみましょう。
公式で用意されているサーバー(GitHub、Google Drive、Slackなど)から始めると、導入のハードルが低いです。
公式ドキュメント
詳しくは公式ドキュメントを参照してください。
まとめ:会社経営の知見をAIに活かす
AIエージェントの設計は、会社組織の設計と驚くほど似ています。
| AIエージェント | 会社組織 |
|---|---|
| CLAUDE.md | 業務マニュアル |
| SubAgents | 専門部署・担当者 |
| Skills | 社員のスキルセット |
| MCP | 業務システム・ツール |
| オーケストレーター | 経営者・PM |
この視点を持っていると、「どう設計すればいいか」が見えてきます。
- 「うちのチームには経理担当が必要だな」→ SubAgentsを追加
- 「営業ルールを明文化しておこう」→ CLAUDE.mdに追記
- 「Salesforceとの連携が必要」→ MCPサーバーを導入
会社経営やチームマネジメントの経験がある方なら、その知見がそのまま活きるはずです。
AIエージェントは、まだまだ発展途上の技術です。でも、「組織設計」という古くからある知見と組み合わせることで、より効果的に活用できるんじゃないかなと思います。
まずはCLAUDE.mdから、試してみてはいかがでしょうか。
参考資料
- Claude Code 設定ドキュメント – CLAUDE.mdの詳細
- Claude Code サブエージェント – SubAgentsの公式ガイド
- Claude Code スキル – Skillsの公式ガイド
- Introducing the Model Context Protocol – MCP発表記事(Anthropic)
- Model Context Protocol – Wikipedia – MCPの概要と業界動向




コメント