Claudeの「エージェント」を分解する —— チャットボットではなく、ループを回す実行環境
Claudeのエージェント機能を、CLI / Agent SDK / Managed Agents / Client SDK の4レイヤーと、サブエージェント・Skills・MCP・Hooksといった構成部品に分解して整理する。設計の中心にあるのは「コンテキストをどう配るか」という問題だった。
チャットとエージェントを分けるもの
Claudeを「賢いチャット相手」として使っている人は多い。だが2026年現在、Anthropicが最も力を入れているのはチャットの側ではなく、エージェントの側だ。
エージェントの定義は、公式ドキュメントの表現を借りればシンプルである。「タスクを完了するために、自分で手順を計画し、ファイルを読み、コマンドを実行し、コードを編集するツールを呼び出すアプリケーション」。要は、モデルが単発で答えを返して終わりではなく、ツール呼び出し → 結果の観測 → 次の判断というループを、タスクが終わるまでモデル自身が回し続ける。
エンジニアにとって重要なのは、この「ループ」は本来自分で実装しなければならないという点だ。Messages APIを直接叩けば、tool_useブロックを受け取り、実行し、tool_resultを詰め直して再送する処理は自前になる。エラー処理、リトライ、コンテキスト溢れへの対処、権限の線引き——地味だが厄介な部分がすべて手元に残る。Claudeのエージェント系プロダクトは、この「harness(ハーネス=実行環境)」をどこまで肩代わりするかで階層化されている、と捉えると全体像が掴みやすい。
4つのレイヤー
現在のラインナップは、抽象度の違いで4段に整理できる。
Claude Code CLI は、ターミナルで対話的に使うインターフェース。日々の開発作業そのもののための入口だ。
Claude Agent SDK は、そのClaude Codeを「ライブラリとして」使えるようにしたもの。エージェントループ、組み込みツール、コンテキスト管理といったClaude Codeの中身が、自分のプロセス内でプログラマブルに動く。提供言語はPythonとTypeScriptのみ。それ以外の言語から同じループを回したい場合は、CLIを-pフラグと--output-format json付きでサブプロセスとして起動する、というのが公式の回答になっている。
Managed Agents は、2026年に公開ベータとして登場した、ホスト型のREST API。サンドボックス、セッション管理、認証、権限のスコープ設定、実行トレースまでAnthropic側が持つ。切断をまたいで状態が保持され、長時間の非同期実行に耐える設計で、エージェントが別のエージェントを呼ぶマルチエージェント連携もリサーチプレビューとして含まれる。課金は通常のトークン単価に加えて、稼働時間あたりのセッション課金が乗る形だ。
Client SDK は最下層。Anthropic APIへの直接アクセスで、ツールループは自分で書く。
「作りたいものがエージェントで、ループを自分で書きたくない」ならAgent SDK、「インフラごと預けたい」ならManaged Agents、という切り分けになる。
部品としてのエージェント
Agent SDKで使える機能を並べると、Claudeのエージェント観がよく見える。
- 組み込みツール — ファイルの読み書き・編集、コマンド実行、Web検索
- サブエージェント — 個別の小タスクに特化したエージェントを分岐生成する
- MCP — Model Context Protocolで外部ツールやデータソースに接続する
- Hooks — エージェントのライフサイクルの要所で任意のコードを差し込む
- Permissions — どのツールを自動実行し、どれに承認を要求するかを制御する
- Sessions — 対話をまたいで文脈を保持し、後から再開・フォークする
- Skills / コマンド / メモリ — プロジェクトの
.claude/とユーザーの~/.claude/から自動でロードされる - Plugins — 上記をまとめてパッケージ化し、ローカルパスから読み込む
このうち、設計思想として面白いのはサブエージェントとSkillsだ。
サブエージェントは、単なる「並列実行」の機能ではない。本質はコンテキストの分離にある。巨大なリポジトリを横断調査させると、探索の過程で読んだ大量のファイル断片がコンテキストを食い潰す。そこを子エージェントに切り出せば、探索の残骸は子の中で燃え尽き、親には結論だけが返る。コンテキストウィンドウを「共有メモリ」ではなく「使い切る資源」として扱う発想だ。
Skillsは、SKILL.mdというMarkdownファイルにノウハウを書いておくと、必要になった時点でエージェントが自分で読み込む仕組み。ポイントは**段階的開示(progressive disclosure)**にある。最初はスキルの名前と一行説明だけが見えていて、タスクに関係すると判断したときに初めて本体を読む。全部をシステムプロンプトに詰め込むのではなく、目次だけ渡して必要な章を自分で開かせる。人間のオンボーディングに近い。
設計対象は「プロンプト」ではなく「コンテキスト」
ここまで見てくると、Claudeのエージェント設計における中心的な関心が浮かび上がる。どの情報を、どのタイミングで、どのコンテキストに入れるかだ。
サブエージェントは分離のため、Skillsは遅延ロードのため、MCPは外部データを必要な分だけ引くため、Sessionsは長期の文脈を保つため。呼び名は違うが、全部が同じ問題を別角度から扱っている。プロンプトを磨き込む作業は、いまや設計作業のごく一部でしかない。
もうひとつ、実務的な注意点を挙げておく。Agent SDKで作った製品にClaude Codeのブランドを流用することは認められていない。「Claude Agent」や「〇〇 Powered by Claude」は使えるが、「Claude Code」を名乗ること、Claude Code風のASCIIアートやUIを模倣することは禁止されている。ライセンスもAnthropicの商用利用規約が適用される。プロダクトに組み込む前に一度目を通しておきたい。
3Dの現場でどう効くか
3D・CG制作のワークフローは、エージェントと相性がいい。アセットの命名規則チェック、大量のテクスチャの一括変換、glTFのバリデーション、Blenderのバッチ処理スクリプト生成、シーングラフの差分検証——「手順は決まっているが数が多い」作業がとにかく多いからだ。
こうした定型ノウハウこそSKILL.mdに落とす価値がある。「このプロジェクトのglTF書き出し規約」を一度書いておけば、以降エージェントはそれを参照して作業する。MCPで社内のアセット管理システムに繋げば、エージェントは実在のアセットを見ながら判断できるようになる。
エージェント化とは、モデルを賢くすることではない。自分たちの手順と文脈を、機械が読める形に書き下す作業だ。そこが済んでいるチームから順に、恩恵を受けることになる。
アイキャッチ: Adobe Stock #138988972

