AIエージェントの作り方｜サブエージェント4役の実録【2026年】

AIエージェントは、プログラミングなしでも作れます。僕の会社ではClaude Codeのサブエージェントを「軽作業」「日常作業」「深掘り」「検品」の4つの担当として定義し、毎日の実務を振り分けています。定義ファイルの中身、使い分けの基準、並列で回したときの実測、失敗まで公開します。

AIエージェントの作り方とは？プログラミングなしで作れるのか？

作れます。2026年10月時点のClaude Codeでは、サブエージェントの定義はMarkdownファイル1枚です。名前、いつ任せるかの説明、使うモデル、思考の深さを冒頭に書き、その下に担当者としての心得を日本語で書けば動きます。僕の会社にはエンジニアがいませんが、この方法で4つの担当を作りました。

AIエージェントとは、指示を受けたAIが自分で手順を考え、ファイルを読む、調べる、書き換えるといった作業を最後まで進める仕組みのことです。チャットで答えを返すだけのAIとの違いは、作業そのものを任せられる点にあります。

AIエージェントの作り方には、大きく3つの道があります。

僕が選んだのは1つ目です。理由は単純で、すでに毎日使っているClaude Codeの中で完結し、作るのも直すのもテキストの編集だけで済むからです。3つの作り方の比べ方と選び方、無人で回す運用までの全体像はAIエージェントの作り方 完全解説にまとめました。

この記事でいう「サブエージェント」とは、メインの会話から切り出した作業を、別の会話・別のモデル・別の設定で処理させるClaude Codeの機能です。公式ドキュメントは、検索結果やログのように後で見返さない情報でメインの会話が埋まるときに使うもの、と説明しています。サブエージェントは自分専用のコンテキストで作業し、要約だけをメインに返します。

Claude Code自体の始め方はClaude Codeの使い方にまとめています。ここから先は、Claude Codeを使い始めている前提で、担当の作り方に絞って書きます。

サブエージェントの定義ファイルはどこに置き、何を書くのか？

置き場所は2つ覚えれば足ります。全プロジェクト共通の担当は ~/.claude/agents/、特定のプロジェクト専用の担当はそのフォルダの .claude/agents/ です。ファイルの冒頭に「frontmatter」と呼ばれる設定欄を書き、必須は name と description の2つだけです。モデルや思考の深さは任意項目で指定します。

公式ドキュメントで確認できた置き場所と優先順位を表にします（2026年10月1日確認）。

frontmatterとは、Markdownファイルの先頭で --- に挟んで書く設定欄のことで、ここに名前やモデルなどを書きます。主な項目は次の通りです。

effortとは、Claudeが1回の応答にどれだけ考え、どれだけトークンを使うかを決める設定です。詳しくはFable 5.1のeffortの決め方に書きました。

実際に僕が使っている「軽作業」担当の定義ファイルの冒頭はこれだけです。

---
name: light
description: 軽作業プリセット（haiku・effort low）。フォーマット整形、短文の要約・分類・抽出、一覧化、ファイル名や見出しの機械的整備、大量ファイルの機械的処理に使う。最新情報の取得や判断を伴う作業には使わない（medium 以上へ）。
model: haiku
effort: low
---

その下に「判断が必要になったら勝手に決めず、判断が必要な点として列挙して返す」「存在しない事実で埋めない。分からなければ不明と書く」といった心得を4行書いています。空行を含めてファイル全体で13行です。

作り方で一番大事なのは description です。公式ドキュメントにも、Claudeはこの説明を読んで任せる先を決めると書かれています。「何をやる担当か」だけでなく「何をやらせないか」まで書いておくと、振り分けの迷いが減ります。

ファイルは自分で書かなくても構いません。公式ドキュメントでは、Claudeに「こういう担当を ~/.claude/agents/ に作って」と頼む方法が案内されています。以前あった /agents コマンドの作成画面は、v2.1.198から開かなくなりました。僕の4担当も、ルールを渡してClaudeに書かせたものです。

ウラカタはどんな4つの担当を作ったのか？

作ったのは「軽作業」「日常作業」「深掘り」「検品」の4担当です。仕事の重さごとにモデルと思考の深さを固定し、迷ったら日常作業に回します。定型作業に高いモデルを使わない、重要な判断を安いモデルで済ませない、の2点を、担当の定義そのもので守らせる設計です。2026年9月3日に作り、以後この4つで回しています。

この形になるまでには段階がありました。2026年7月10日に、まずClaude Codeの全プロジェクト共通のルールファイルに「重い設計はFable、日常はOpus、定型はSonnet、軽い処理はHaiku」という使い分けを書きました。ただ、この時点ではモデルしか決めていませんでした。

2026年9月にFable 5.1が出て、コストを左右するのは思考の深さ（effort）だと分かりました。そこで9月3日に、モデルとeffortをセットで固定した4つの定義ファイルを作りました。僕の環境では、サブエージェントを呼ぶときにモデルは指定できても、effortを直接は指定できません。だから担当の定義ファイルに書いておく必要があったわけです。

作ってすぐ、同じセッションの中で新しい担当が呼び出し先の一覧に現れ、軽作業担当から応答が返ることを確認しました。設定の再起動などは要りませんでした。

4担当それぞれの心得も短く書いています。

• 軽作業: 判断が要る点は勝手に決めず列挙して返す。出力は指示された形式だけ
• 日常作業: 目的と完了条件を1行で言語化してから着手する。既存ファイルは差分で編集する
• 深掘り: 仮説を立て、最も安く否定できる確認から先にやる。確信度を「確認済み・ほぼ確実・推測」で書き分ける
• 検品: 直さない。指摘に留める。「概ね問題なし」は禁止

ルールを作るうえで1つ決めたことがあります。low（最も浅い設定）は検索や情報取得の回数が減り、記憶で答える傾向が強まると公式が明記しています。なので、最新情報が要る調べ物は軽作業担当に回さず、日常作業以上に回すことにしています。

なぜ作った本人とは別に「検品役」を置くのか？

作った本人が自分の成果物を点検しても、前提を共有しているので同じ見落としを繰り返すからです。サブエージェントは会話の履歴を引き継がずに新しいコンテキストで始まるので、前提を知らない第三者として点検させられます。僕の会社では、検品役が公式の要綱を読み直して、調査の結論を覆したことがあります。

公式ドキュメントによると、通常のサブエージェントは「新しく独立したコンテキストで始まり、それまでの会話履歴や、すでに読んだファイルを見ない」仕組みです。点検役にとっては、この「何も知らない」ことが強みになります。

実例を書きます。2026年8月10日、ある地域で使える補助金を、サブエージェント12体で並列に調べました。市・県・国・所在地の要件・営業での使い道の5方面に分担し、市14制度、県16制度、国15制度、営業側の14制度を走査しています。ツールの実行回数は合計333回でした。

最初の調査では、県のある補助金を「条件次第で使える（△）」と判定していました。公開ページの表現が「県内の事務所等」と緩く読めたからです。ところが抜け漏れの監査を担当したサブエージェントが交付要綱のPDFを読み直し、要件は「県内に登記簿上の本店又は主たる事業所」だと確認しました。判定は△から×に訂正されています。

もしこの監査がなければ、使えない補助金を前提に計画を組むところでした。人間が同じことをやるなら、要綱PDFを1本ずつ開いて条文を確認することになります。その仕事を別の担当に切り出しておくと、作業の抜けがそのまま表に出てきます。

検品役の定義には、次の5つを書いています。

「直さない」は意外に大事です。検品役が自分で直し始めると、直した部分を誰も点検しない状態になります。作る担当と点検する担当を分けたら、修正は作る側に戻す。人間の組織と同じ分け方です。

失敗から仕組みを作る考え方はAI導入の失敗事例7つでも詳しく書いています。

マルチエージェントで並列に回すと、何がどれだけ速くなるのか？

僕の実測では、下書き100本の執筆が約20分で終わりました。2026年7月11日、サブエージェント10体に10テーマずつ割り当て、同じ執筆指示書を読ませて同時に書かせた結果です。並列化で速くなるのは「同じ型で、互いに独立した作業」で、型が先に決まっていることが条件です。

マルチエージェントとは、複数のAIエージェントが役割を分担して1つの仕事を進める構成のことです。Claude Codeでは、メインの会話が指揮役になり、サブエージェントを複数呼び出すとこの形になります。

並列でサブエージェントを動かした実績を、記録が残っているものから並べます。

note100本の詳しい手順はAIで下書き100本を作った実録に書きました。テーマ表の確定が11時54分、100本のファイルが揃ったのが12時14分です。この20分間、僕は見ているだけでした。

いま読んでいただいているこの記事も、同じ仕組みで書いています。記事ごとに執筆担当のサブエージェントを立て、執筆の型と公開方針を書いた指示書、出典の確認ルールを渡して並列で書かせます。数字や仕様は担当が公式ページで確認し、記事の末尾に出典を残します。書き上がった記事は、書いた担当とは別の検品担当が事実・社内の数字・表現を点検します。最初の10本は僕が自分で読んで確認し、11本目以降は検品担当が合格を出したものを自動で公開する流れです。前の章で書いた「作る担当と点検する担当を分ける」を、このメディアそのものにも当てはめています。

並列実行の仕様も、公式ドキュメントで確認できた範囲で押さえておきます。対話型のセッションでは、サブエージェントは既定でバックグラウンドで動くので、担当が走っている間もメインの会話を続けられます。同時に動かせる数は既定で20体までで、環境変数で変えられます。サブエージェントがさらに自分のサブエージェントを呼ぶこともでき、既定ではメインの会話から3階層下までです。僕の10体並列はこの既定値の範囲内なので、設定は何も変えていません。

並列化で失敗しやすいのは、型が決まっていないまま数だけ増やすことです。10体に自由に書かせると、10通りの文体と10通りの品質が返ってきます。note100本が揃ったのは、全員が同じ執筆指示書を読んでいたからです。並列化の前に、まず1本を人間が納得する形で書かせ、その指示を型として固定する。この順番が効きました。

AIエージェントを回して分かった失敗と注意点は？

一番大きな失敗は、高いモデルを指定した担当を量産して、利用枠を想定以上に減らしたことです。公式ドキュメントにも、サブエージェント自身のリクエストはメインの会話と同じ使用量上限にカウントされると書かれています。担当を増やす前に、どの担当にどのモデルを割り当てるかを決めておく必要がありました。

2026年9月28日の調査で、最上位モデルのFableの使用量の正体が分かりました。直近7日のFableの応答3,815回は、100%がワークフロー機能から呼ばれたサブエージェントのものでした。ワークフローとは、複数のサブエージェントを台本に沿って順番に動かす機能のことです。同じ7日間で14回のワークフローが動き、57体の担当が呼ばれていました。

原因は台本の書き方でした。台本の全工程にFableが指定されていたのです。高いモデルが要るのは検証や監査の工程だけで、生成の工程は日常作業のOpusで足ります。直し方は台本の1行を変えるだけで、追加のお金はかかりません。この経緯と料金の話はClaude Codeの料金と上限の実録で詳しく書きました。

ほかにも、回してみて分かった注意点があります。

安全判定で止まったときのやり直し方には、理由があります。公式ドキュメントでは、Fable 5.1の思考の記録は以前のモデルからは読めないとされています。途中経過を別のモデルに引き継ぐより、同じ入力で最初からやり直すほうが確実です。ちなみに2026年9月3日にそれまでの167セッション分のログを機械検索したところ、安全判定で止まった記録は0件でした。マーケティングやWeb制作の実務で当たることはほぼありません。

もう1つ、担当を作り込みすぎないことも大事だと感じています。僕のルールでは、4担当に合わない仕事が出たときだけ個別に担当を足すことにしています。公式ドキュメントでも、全担当の説明文の合計が大きくなりすぎると警告が出る仕様です。担当は増やすほど振り分けも迷いやすくなるので、まず4つで回してみるのがおすすめです。

自社でAIエージェントを作るなら、どこから始めるべきか？

最初に作るのは、作った本人とは別の会話で成果物を点検する「検品役」がおすすめです。次に、毎日発生する軽い作業を安いモデルに回す「軽作業役」を作ります。この2つで、品質の抜けとコストのムダという、AIに仕事を任せたときの典型的な2つの問題に先に手が打てます。

僕の会社でやった順番を、そのまま手順にしました。

1. 1週間分の作業を書き出し、「整形・一覧化」「下書き・修正」「判断・調査」「点検」の4つに分ける
2. 4つのうち、点検の担当を最初に作る。合格基準の書き方と「直さない」ことを心得に入れる
3. 次に軽作業の担当を作り、安いモデルと浅いeffortを指定する
4. 日常の作業は会話で直接やり、型が固まったものから日常作業担当に回す
5. 1週間使ったら、Claude Codeの /usage で消費の内訳を見て、担当ごとのモデルを見直す

定義ファイルは、Claudeに次のように頼めば書いてくれます。「~/.claude/agents/ に verifier という名前の検品担当を作って。成果物を合格基準に照らして点検し、重大・要修正・任意の3段階で指摘を返す。自分では直さない」。できたファイルを読んで、言い回しを自社の言葉に直せば完成です。

担当を「人」として扱うと、設計が楽になります。僕の会社では、担当ごとに任せる仕事と任せない仕事を、新しく入った社員に渡す業務分担表のつもりで書きました。AIに任せる仕事の棚卸しそのものが、業務の見直しにもなります。

社内のルールや過去の判断をAIに毎回読ませる仕組みはClaude Codeで会社を「第二の脳」にするガイドに、担当に読み込ませる手順書の作り方はClaudeのスキルの作り方にまとめています。導入費用を補助金で賄えないかは、デジタル化・AI導入補助金2026の実務ガイドで整理しました。自社の業務に合わせた担当の設計から相談したい場合は、ウラカタのサービス一覧もご覧ください。

まとめ

• AIエージェントはプログラミングなしで作れる。Claude Codeのサブエージェントは、名前と説明を書いたMarkdownファイル1枚で動く
• 置き場所は全プロジェクト共通なら ~/.claude/agents/、プロジェクト専用ならその .claude/agents/。必須項目は name と description だけ
• ウラカタは軽作業（Haiku×low）・日常（Opus×medium）・深掘り（Fable×high）・検品（Fable×high）の4担当で回している
• 検品役は作った本人と別のコンテキストで点検できるのが強み。補助金調査では要綱の読み直しで判定を覆した
• 並列化は型が決まってから。下書き100本は10体並列で約20分だった。高いモデルの担当を量産すると利用枠が一気に減る