Agent on KnightLiブログ

AI用語解説: Agent、MCP、RAG、Token をわかりやすく整理する

Thu, 23 Apr 2026 13:13:40 +0800

AI に触れ始めたばかりのとき、人を遠ざけやすいのはモデルそのものより、会話の中に次々出てくる用語です。Agent、MCP、RAG、AIGC、Token はどれも見覚えはあっても、やさしく説明されないと本当の意味まではつかみにくいものです。

この記事では、よくある入門向けの説明の流れに沿って、AI で頻出する 10 個の用語を覚えやすい形にまとめます。学術的に厳密に説明することよりも、日常的な AI の話題についていける基本イメージを作ることを目的にしています。

10 個の代表的な AI 用語は何を意味するのか

1. Agent: 会話だけでなく実行もする AI

Agent は、実際に作業を進めてくれる AI アシスタントだと考えると分かりやすいです。

普通のチャットボットは、質問すると答えるという形にとどまりがちです。Agent はそこから一歩進み、タスクを分解し、手順を組み立て、ツールを呼び出し、最後に結果を返します。資料整理、調査、文書生成のような依頼でも、助言だけで終わらず、一連の動作をつないで実行することがあります。

だから Agent の本質は、話せるかどうかではなく、動けるかどうかにあります。

2. OpenClaw: PC に常駐する AI アシスタント

ここでの OpenClaw は、PC の中に住む AI アシスタントのようなものとして説明されています。

この種のツールは、デスクトップ操作に近い AI 支援だと考えると分かりやすいです。文字入力を受け取るだけでなく、画面を見たり、ローカルツールを呼び出したり、手順に沿って作業したりすることがあります。一般的な Web チャットと比べると、実際の操作能力がより重視されます。

Agent が実行型 AI という抽象的な概念だとすれば、こうしたデスクトップ型アシスタントは、その考え方の PC 上での具体例だと言えます。

3. Skills: Agent に追加する能力パック

Skills は、Agent の機能モジュールや操作ルールだと捉えられます。

同じ Agent でも、どの Skills を持つかによって得意分野が変わります。文章作成寄りのものもあれば、データ整理向けのものもあり、コード処理に向いたものもあります。スマートフォンのアプリに少し似ていますし、再利用できるワークフロー集にも近いです。

つまり、モデルそのものが急に賢くなったというより、背後にあるルール、ツール、手順が明確になった結果だと言えます。

4. MCP: AI が外部ツールにつながるための共通方式

MCP は Model Context Protocol の略です。

身近な比喩で言えば、AI の世界における Type-C 端子のようなものです。以前はモデルを別々のツールにつなぐたびに個別実装が必要になりがちでしたが、共通プロトコルがあると接続方法を標準化しやすくなります。

多くの人にとって大事なのは、MCP が「モデルが答えられるかどうか」の話ではなく、「モデルが外部ツールや外部リソースに安全かつ安定して接続するにはどうするか」の話だという点です。

5. ガチャ: AI 生成にはランダムさがある

「ガチャ」という表現は、AI 画像生成、動画生成、クリエイティブ用途でよく使われます。

意味はシンプルです。同じプロンプトで、同じ方向性を指定しても、毎回まったく同じ結果になるとは限りません。すごく良い結果が出ることもあれば、明らかに崩れることもあります。そのため、何度も生成して当たりを引く感覚がゲームのガチャにたとえられます。

ここで押さえておきたいのは、AI 生成は固定的な公式ではなく、確率的な揺らぎを含んだプロセスだということです。

6. API: アプリとモデルをつなぐ入口

API は Application Programming Interface の略です。

プログラム同士がやり取りするための標準的な入口だと考えると分かりやすいです。自分のアプリ、スクリプト、エディタからモデルサービスを呼び出すときは、実質的に API を通じてリクエストを送り、結果を受け取っています。

モデルサービスをレストランにたとえるなら:

メニューは API ドキュメント
注文は API リクエスト
厨房から料理が返ってくるのはモデルの応答

そのため、見た目は違うツールでも、裏側では何らかの API を呼んでいることが多いです。

7. マルチモーダル: AI は文字だけを扱うわけではない

マルチモーダル とは、AI が文字の読み書きだけに限られず、複数の種類の情報を扱えることを指します。

たとえば画像を見たり、音声を理解したり、動画を解釈したり、画像を生成したり、リアルタイムの音声や映像のやり取りを支えたりできます。文字しか扱えなかった初期のモデルと比べると、「見る・聞く・話す・書く」に近い能力を併せ持つ方向へ進んでいます。

だからこそ、今の AI 製品は単なるテキスト入力欄だけでは語れなくなっています。

8. RAG: 先に資料を探し、そのうえで答えを作る

RAG は Retrieval-Augmented Generation の略です。

これはとても実務的な課題に向いています。モデルの学習データには時点の限界があり、社内の最新資料、サポート記録、業務ルールを自動では知りません。RAG は、まず指定した資料群から関連情報を探し、その内容を踏まえて回答を生成する考え方です。

価値が出やすい点は主に 3 つあります。

回答が実際の資料に寄りやすくなる
どの資料を根拠にしたか追いやすい
新しい資料を追加すれば知識を更新しやすい

そのため、企業向けナレッジベース、AI カスタマーサポート、社内 Q&A では RAG がよく使われます。

9. AIGC: AI が作るコンテンツ全体を指す言葉

AIGC は AI Generated Content の略です。

これは単独のツール名ではなく、AI が生成したコンテンツ全般を指す総称です。文章、画像、音声、動画などが含まれます。AI ライティング、AI イラスト、AI による短尺動画制作、AI 音声生成などはすべて AIGC の枠で理解できます。

大事なのは、この言葉が特定のモデルではなく、コンテンツの作り方そのものを指していることです。

10. Token: モデルが内容を処理するときの計量単位

Token は、モデルがテキストを処理するときの基本的な計量単位だと考えられます。

これは 1 文字や 1 単語と完全に一致するわけではありませんが、実用上は計算量や課金の共通単位として捉えて問題ありません。入力でも Token を消費し、出力でも Token を消費し、保持しているコンテキストも同じように Token を使います。

だから多くのモデルサービスがコンテキスト長、コスト管理、プロンプト圧縮を強調するのは、結局どれも Token と深く関係しているからです。

Claude Code のマルチエージェント協調: Subagents と Agent Teams はどう使い分けるか

Wed, 22 Apr 2026 21:35:52 +0800

Claude Code でマルチエージェント協調を考えるとき、最も混同しやすいのが Subagents と Agent Teams です。どちらも「複数の Agent を動かして一緒に作業する」ように見えますが、実際には想定している使い方が異なります。簡単に言えば、前者は独立したタスクを切り出して処理するのに向いており、後者は複数の Agent が同じテーマについて継続的に協力し、相互に検証しながら進めるのに向いています。

もし Skill を使ったことがあるなら、まずは次のように理解すると分かりやすいです。

Skill は手順やルールを定義する
Subagent や Agent teammate は実際の作業を行う

つまり重要なのは、どちらが「上位」かではなく、どの種類の協調課題を解きたいのかです。

Subagents: サイドタスクを切り出す

Subagents は、現在のセッションから一時的に送り出す分身に近い存在です。各分身は独自のコンテキストウィンドウを持ち、作業後は結果の要約だけを返します。そのため、メインの会話は大量の中間ログや出力で埋まりにくくなります。

この仕組みには、実務上かなり分かりやすい利点があります。

メインスレッドがきれいなままで、テストログや検索結果、長い出力で汚れにくい
相互依存のない調査や実行タスクを並列化できる
「結果だけ返してくれればよい」タイプの仕事に向いている

元記事では、Claude Code には次の 3 種類の組み込み Subagent があると説明されています。

Explore: 読み取り専用で、コードベースの高速検索に向く
Plan: 読み取り専用で、plan mode 中のバックグラウンド情報収集に向く
General-purpose: 読み書き可能で、探索と編集を組み合わせる仕事に向く

カスタム Subagent

組み込みのものだけでは足りない場合は、自分で Subagent を定義できます。やり方はシンプルで、Markdown ファイルを用意するだけです。

.claude/agents/: 現在のプロジェクトでのみ有効
~/.claude/agents/: すべてのプロジェクトで有効

ファイル形式は次のようになります。

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

ここで特に重要なのは description です。Claude はこの説明を見て、いつこの Subagent を呼ぶべきか判断します。説明が正確であるほど、呼び出しの精度も上がりやすくなります。

ほかにも知っておくと便利な設定項目があります。

tools: 使用できるツールを制限する
model: sonnet、opus、haiku、inherit から選ぶ
permissionMode: 編集権限や権限プロンプトの挙動を制御する
memory: Subagent に対話をまたぐ記憶ディレクトリを与える

一時的にだけ使いたい場合は、CLI 経由で定義することもできます。

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents が向いている場面

Subagents が特に向いているのは、たとえば次のような仕事です。

テストを実行し、数千行のログではなく失敗要約だけをメイン会話に返す
相互依存しない複数モジュールの調査を並列に進める
「問題を見つける」と「修正する」を単純なパイプラインに分ける

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

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

一方で、タスクが何度も往復しながら調整を要する場合、複数段階で大量の文脈を共有する場合、あるいは変更が一つ二つのファイルに集中している場合は、Subagent を立てるよりメイン会話で直接処理したほうが楽なことが多いです。

Agent Teams: 複数の独立セッションで協調する

Agent Teams は別のレイヤーの機能です。1 つのセッション内で分身を出すのではなく、完全に独立した複数の Claude Code インスタンスを起動し、共有タスクリストを中心に協調させます。しかも、メンバー同士が直接メッセージを送り合うこともできます。

そのため、単なるサイドタスク処理というより、本当に小さなチームを作る感覚に近いです。

元記事では、これはまだ実験機能であり、先に有効化が必要だと説明されています。

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

これを settings.json に追加すると、Claude に対して目的に応じた team を組ませることができます。たとえば次のような形です。

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

Agent Teams の構成

Agent Team は主に次の 3 つで構成されます。

Team lead: あなたが使っているメインセッション。編成、割り振り、要約を担当する
Teammates: 複数の独立した Claude Code インスタンス
Task list と Mailbox: 共有タスクリストとメッセージ経路

Subagents との最大の違いは、teammates 同士が直接やり取りできることです。毎回 lead を経由する必要はありません。タスク状態は通常 pending、in progress、completed の間を移り、1 つ終えた teammate は次のタスクを引き取ることもできます。

Agent Teams が向いている場面

複数視点からの検討、結論への異議申し立て、仮説同士の競合、あるいはモジュール単位の並列開発が必要なときは、Agent Teams のほうが適しています。

記事では次のような典型例が挙げられています。

同じ PR を複数 reviewer が並列でレビューし、それぞれ異なる観点を見る
同じ bug に対して複数の Agent が異なる仮説を立て、互いに反証する
フロントエンド、バックエンド、テストが別々の領域を並列で進める

たとえば並列コードレビューでは、次のように指示できます。

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

また、討論型のデバッグでは次のような使い方ができます。

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

この種の仕事に共通しているのは、単に 1 つの答えが欲しいのではなく、複数の Agent が判断を持ち寄り、前提を揺さぶり合いながら、より確かな結論に収束していくことです。

どう使い分けるか

手早く判断したいなら、次のように覚えると分かりやすいです。

結果だけ持ち帰ればよいなら Subagents
議論や相互検証が必要なら Agent Teams

もう少し整理すると、主な違いは次の通りです。

通信方法: Subagents は主にメイン会話へ結果を返すが、Agent Teams はメンバー同士で直接やり取りできる
調整方法: Subagents はメイン会話側のオーケストレーションに依存しやすいが、Agent Teams は共有タスクリストをもとに各メンバーが自律的に動ける
Token コスト: Subagents のほうが軽く、Agent Teams は各 teammate が独立インスタンスのため高くなりやすい
向いている仕事: Subagents は独立性が高く結果志向の仕事向き、Agent Teams は議論や相互検証が重要な仕事向き

実運用で気をつけたいこと

Agent Teams は強力ですが、だからといってすべてのタスクで team を組むべきというわけではありません。記事では特に次のような現実的な注意点が挙げられています。

token 消費が明らかに大きい
複数 teammate が同じファイルを同時に編集すると、上書き競合が起きやすい
teammate が多すぎると調整コストが増え、成果が伸びるとは限らない

そのため、比較的安全な進め方としては次のようになります。

まずは 3〜5 人程度の teammate から始める
モジュールやファイル単位で仕事を分け、編集衝突を避ける
lead が早まって teammate の仕事に手を出し始めたら、先に待つよう明示する

また、現時点の実験版には次のような制約もあります。

/resume と /rewind で in-process teammates を復元できない
タスク状態が遅れて反映され、手動での更新が必要になることがある
1 人の lead が同時に扱える team は 1 つだけ
teammate がさらに子 team を作ることはできない

まとめ

この 2 つの機能は、互いの代替ではありません。解いている協調課題そのものが違います。

目的が「サイドタスクを並列化し、メインの文脈をきれいに保つこと」なら、まずは Subagents を使うのが自然です。目的が「複数の Agent に小さなチームのように協力させ、議論し、相互検証させること」なら、Agent Teams が向いています。

実際のタスクで一度試してみると、違いはかなり早く体感できます。片方は文脈の分離と結果回収に強く、もう片方は多視点での協調と継続的なやり取りに強い、という違いです。