メインコンテンツへスキップ
見出し画像

Opus 5.5に"最後まで"任せる技術──定義ファイル1枚で、迷わない部下をつくる

    鈴木章裕

    「AIに頼むと途中までは速い。でも最後の2割は、結局自分で手を動かしている」。そう感じている経営者の方は多いと思います。9月23日、私は自分のClaude Codeの司令塔をOpus 5.5に切り替えました。使い込んで分かったのは、このモデルの持ち味が文章のうまさより「長い仕事を完走させる力」にあること。そして完走させるには、依頼文と、部下役のAIを定義したファイルの両方を書き直す必要があることでした。自分の環境で見つけた穴と、そのまま使える雛形12本をお渡しします。

    画像

    この図は、中央上に司令塔のOpus 5.5（決める・検証する）を置き、下に3つの部下（Sonnet＝作る、Haiku＝さばく、Explore＝探す）を並べたものです。部下から司令塔へ戻るのは「要約」だけです。右上の赤枠のFableは、最難関の判断のときだけ相談する切り札で、点線でつないであります。

    Opus 5.5は「書くAI」から「最後までやるAI」になった

    まず前提をそろえます。Claude Codeは、AIがパソコンの中でファイルを読み書きし、コマンドを実行しながら作業を進められる開発ツールです。チャット画面で文章を返すだけのAIと違い、「作って、動かして、結果を見て、直す」ところまで自分で回せます。

    Opus 5.5について公開されている評価を見ると、伸びが目立つのは長時間のコーディング、CAD（設計図を扱うソフト）まわりの推論、ツールを使った検証です。画像を見て3Dモデルを組み立てるコードを書く評価で、ツールありの一致度が0.962だったという報告もあります。数字そのものより、「見て、コードを書き、結果を確認して直す」ループを長く回せるようになった、と読むのが実務的だと私は考えています。

    何週間分と見積もられていたコード移行を約9.5時間で終えた、新しいアルゴリズムの検証を約15時間走らせ切った、という報告が公開されています。どちらも「一問一答」ではなく「一晩かけて最後までやる」仕事です。

    用途を整理すると、私の見立てでは次の4領域に強みが出ます。

    画像

    図は、4つの領域を四象限に置いたものです。左上が開発・移行・調査、右上が設計・ものづくり、左下が動画・資料・Web、右下がバックオフィスです。各マスの下の小さな一行（テスト全通過まで／開けるファイルまで／コードで動きを制御／矛盾チェック）が、それぞれの領域で「どこまで任せるか」の目安です。中央の赤い「完走」の円は、4つに共通する強みを表しています。

    一方で、定型作業まで全部Opus 5.5に回す必要はありません。決まった手順の変換や整形は、より安いSonnetやHaikuで十分です。判断が続く仕事だけをOpusに寄せる。この線引きが、後半で話す「部下の定義ファイル」の話につながっていきます。

    9月23日、司令塔をOpus 5.5に替えた

    私の環境の話をします。私は自分のClaude Codeを、3層の体制で動かしています。9月23日に組み替えた現在の形はこうです。

    司令塔はOpus 5.5。設計、タスクの分解、判断、最終確認を受け持ちます。実作業の主力はSonnet。コードを書く、文章の下書きを作る、調査をまとめる。軽い作業はHaiku。テストを回す、ログを数える、ファイルを探す。そして最上位のFable 5.1は、最も難しい判断のときだけ呼ぶ「切り札」にしました。切り札は読み取り専用の相談役で、ファイルは一切書かせません。この体制は10月23日に見直す予定です。

    切り替えた理由は単純で、司令塔に求めるものが「一番賢いこと」から「長い仕事を途中で投げ出さず、部下に割り振り、結果を検証して締めること」に変わったからです。毎日の業務で、朝に投げた仕事が夕方に終わっている状態を作りたかった。その役にはOpus 5.5の性格が合っていました。

    体制を作るにあたって、過去の失敗から決めていたルールがいくつかあります。

    ひとつは、部下に仕事を渡すときは必ずモデルを明示すること。7月に、委譲のときモデル指定を書き忘れたことがありました。1万字の記事を書かせたのに、仕上がりの質がはっきり落ちた。原因は、指定がなければ既定の設定任せになることを、私が意識していなかったことでした。今の設定では、未指定だと司令塔と同じ高いモデルに落ちます。質が落ちても費用が膨らんでも困るので、以来、委譲の指示には必ず「sonnetで」「haikuで」と書いています。

    もうひとつは、部下がさらに部下を呼ぶ「孫請け」を禁止したこと。7月末から、環境変数（CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1）で呼び出しの深さを1段に固定しています。孫請けを許すと、どのモデルで何が動いたのか、あとから追えなくなるからです。

    そして3つめが、書いた本人に同じ文脈のまま合格を出させないこと。作る係と見る係は、別のAIにする。私はこれを運用ルールとして守ってきたつもりでした。

    自作の部下の定義も、それなりに整えていました。実作業の主力は「sonnet-worker」、軽作業は「haiku-runner」。haiku-runnerの説明文には「判断を伴う作業には使わない」と書いてあります。切り札の「fable-arbiter」は、使えるツールを5つに絞ってあります。読む・探す・調べる系（Read, Grep, Glob, WebFetch, WebSearch）だけです。司令塔が切り替わっても、部下の側は準備ができている、と思っていたわけです。

    体制を組み替えてから数日、朝に投げた仕事が夕方にはレビュー待ちまで進んでいて、報告を読んで判定するだけで一日が回る日が増えてきて、正直なところ自分の環境はもう十分に整っていると思い込みかけていました。

    33本の定義ファイルを開いて、手が止まった

    9月の終わり、Opus 5.5の活用法やサブエージェント（部下役のAI）の設計について書かれた資料を4本、まとめて読む機会がありました。その中の一文に目が止まりました。レビュー担当には、書き込みの権限を渡さない。

    当たり前の話です。私も同じことを運用ルールにしています。ただ、ふと気になりました。それは「ルールに書いてある」のか、それとも「権限として設定してある」のか。

    確かめるために、自分の定義ファイルの置き場所（~/.claude/agents/）を開きました。定義ファイルは33本ありました。1本ずつ、使えるツールを指定する「tools」という行を探していきます。

    tools行でツールを絞っていたのは、33本のうち4本だけでした。

    残りの29本は、tools行がありません。書いていないと、その部下は司令塔と同じツールを全部引き継ぎます。レビュー役の何本かは、使わせないツールを並べる欄でWriteとEditだけを外していました。ただ、コマンドを実行するBashは残ったままです。コマンドが打てれば、ファイルは書き換えられます。「見る係」のつもりの部下が、設定の上では手を動かせる状態でした。

    画像

    図は、33個のマスを並べ、ツールを絞っていた4本だけを赤（鍵が閉まった状態）で示したものです。残り29本の灰色のマスは鍵が開いたまま、つまり全ツールを継承している状態です。色付きの少なさがそのまま、ルールを権限で裏打ちできていた割合だと見てください。

    ここ、うまく言葉にできないのですが、ショックだったのは穴があったことそのものより、「自分はこのルールを守っている」と信じていた根拠が、AIの行儀のよさだけだったことでした。見る係が勝手にファイルを直さなかったのは、設定で完全に止めていたからというより、たまたまそう振る舞っていたからでした。運用ルールとして書いた文章は、守られているあいだは目に見えません。破られて初めて、設定がなかったことに気づく。その順番で痛い目を見ずに済んだのは、運がよかっただけだと思います。

    もう一つ、数字を測りました。33本の説明文（description）を全部合わせると、ファイル容量で約7KBありました。この説明文は、司令塔が「どの部下に仕事を振るか」を決めるときに毎回読む部分です。資料には、全エージェントの説明文の合計が約15,000トークンを超えると起動時に警告が出る、という報告もありました。私の環境はそこまでは行っていません。ただ、判断の材料として毎回読まれる文章が長いほど、振り分けの精度も落ちやすくなります。

    振り返ると、私は「依頼文」は何度も磨いてきたのに、「部下の定義」は作ったまま放置していました。司令塔を賢いモデルに替えれば全体が良くなる、という発想でいたのです。実際には、司令塔が賢くなるほど、部下に渡す権限の粗さが目立つようになります。長い仕事を最後まで任せるなら、途中で誰が何をできるのかを、文章ではなく設定で決めておかなければいけない。

    そこで、全部を一度に書き直すのはやめて、まず棚卸しから始めることにしました。どの定義にtoolsがないか、説明文が長すぎるものはどれか、モデル指定が抜けているものはどれか。これをAIに洗い出させて、見る係から順に絞っていく。その棚卸しに使う依頼文は、記事の後半（P12）に載せています。

    見て・書いて・確かめて・直す。4つの領域での渡し方

    Opus 5.5に長い仕事を任せるとき、中心にあるのは1つのループです。

    画像

    図は、「見る→書く→確かめる→直す」の4つを時計回りの矢印で結び、中央に「完了条件を満たすまで回す」と置いたものです。ループを抜ける出口は右側の赤い矢印1本だけで、その先が「完了」の旗です。人間が決めるのは出口の条件で、ループの回し方はAIに任せる、という構図で読んでください。

    このループを前提に、4つの領域ごとの渡し方を見ていきます。

    1. 開発・移行・調査

    ポイントは「移行して」と頼まず、完了条件を渡すことです。決済の仕組みを新しい部品に全部置き換え、古い部品を消し、テストが全部通るところまで一括で任せた、という報告もあります。社内システムの入れ替えを外部に頼んでいる会社なら、開発会社への発注文としても使えます。

    あなたはこのリポジトリの移行担当です。
【ここに移行内容：例）全サービスの旧APIクライアントを新クライアントへ置き換える】

完了条件:
- 対象のすべての呼び出し箇所が新しい仕組みに置き換わっている
- 旧実装のファイルと設定は削除されている
- 既存のテストがすべて通る（テストコマンド:【ここにコマンド】）

進め方:
- まず影響範囲を一覧にし、TASKS.md に書いてから着手する
- 1サービス終わるごとにテストを回し、結果を TASKS.md に追記する

人間に戻す条件（これ以外は確認なしで進めてよい）:
- 原因が特定できないテスト失敗が2回続いた
- 外部サービスの契約や料金に関わる設定を変える必要が出た

最後の報告形式:
- 変更したサービス一覧／削除したファイル一覧／テスト結果／未解決の問題

    2. 設計・建築・ものづくり

    図面、写真、仕様書を渡して「開けるファイルまで」頼むと強い領域です。賃貸物件の図面をCADデータに起こし、3Dの完成予想図にしてWebで共有した、という事例が公開されています。実在する部品だけで大きなロボットを設計し、141ページ・237工程の組立書と部品の発注リストまで作ったという報告もありました。工務店や製造業の方は、手元の図面1枚から試せます。

    あなたは設計データの作成担当です。
添付した【ここに材料：図面の画像／現場写真／仕様書】をもとに、次のファイルを作ってください。

作るもの:
- 【ここに形式：例）DXF形式の平面図】
- 【ここに形式：例）完成予想のパース画像3枚（正面・斜め・室内）】

完了条件:
- 指定の形式で、手元のソフト【ここにソフト名】で実際に開けること
- 寸法は図面の数値と一致していること（読み取れない寸法は推定値と明記）

確認のしかた:
- 作ったファイルを自分で読み込み直し、主要寸法5か所を図面と照合した表を添える

人間に戻す条件:
- 図面の数字が読めない、または図面同士で矛盾している箇所がある

報告の形: 作ったファイルの場所／寸法の照合表／推定で埋めた箇所の一覧

    3. 動画・資料・Web

    コードで絵と動きを制御する使い方です。クリックすると根拠が開く資料、数値を動かすと再計算される提案書、HTMLで書いたモーション動画などが作れます。社内説明の資料を「読む資料」から「触れる資料」に変えたいときに使ってください。

    あなたはインタラクティブ資料の制作担当です。
【ここにテーマ：例）来期の採用計画と人件費の試算】を、ブラウザで開ける1枚のHTMLにしてください。

必ず入れる仕掛け:
- 【ここに変数：例）採用人数・平均年収】をスライダーで動かすと、合計額とグラフが再計算される
- 各数字の横に「根拠」ボタンを置き、クリックで出典と計算式が開く

デザイン指定:
- 色は【ここに色：例）紺と白の2色＋強調に朱色1色】
- 書体は【ここに書体】、ボタンは角丸4px
- 禁止事項：影の多用、グラデーション、絵文字

完了条件:
- スマートフォン幅でも崩れない
- 初期値で計算した合計額が【ここに検算値】と一致する

報告の形: HTMLの場所／検算の結果／スマートフォン幅での確認結果

    4. バックオフィス

    記帳や税務資料の下ごしらえ、請求書の突き合わせ、調査結果を「社外に出してよいファイル」まで仕上げる作業などです。ここは定型部分をSonnetに、判断が続く照合だけをOpusに回すと費用が抑えられます。経理担当の方が月末に使う想定の依頼文です。

    あなたは経理の照合担当です。最終判断はしません。
フォルダ【ここにフォルダ名】の請求書・見積書・発注書をすべて読み、次の矛盾を洗い出してください。

チェック項目:
- 同じ取引で金額が書類ごとに違う
- 日付の順序がおかしい（発注日より前の請求日など）
- 税率・税額の計算が合わない
- 宛名や社名の表記ゆれ

出力形式（表）:
| ファイル名 | 該当箇所 | 何と何が食い違うか | 深刻度（高/中/低） |

注意:
- 読み取れなかった書類は「未確認」として別表に残す
- 修正や書類の作成はしない。指摘だけを返す

    依頼文は「完了状態」と「戻す条件」で書く

    4つの雛形に共通する骨組みを、6つの型に整理しておきます。

    画像

    図は、依頼文の型を番号つきの6枚のカードに並べたものです。1〜3（完了状態・戻す条件・途中の追加指示）が依頼を出す前後に決めること、4〜6（分割・TASKS.md・止める問題だけ再レビュー）が長い仕事の途中と終わりに効くことです。1と2が空のまま4〜6だけ整えても機能しない、という順番で見てください。

    一つずつ補足します。

    1つめは、完了状態を書くこと。「よく考えて」「丁寧に」といった言葉は、Opus 5.5には要りません。代わりに「何がそろったら終わりか」を書きます。テストが全部通る、ファイルが開ける、表の数字が検算値と一致する。確かめられる形で書くほど、ループの出口がはっきりします。

    2つめは、途中で人間に戻す条件を先に決めること。これが決まっていないと、AIは迷うたびに止まって質問してくるか、逆に止まるべきところで進んでしまいます。「この2つが起きたら戻して、それ以外は進めてよい」と書くと、夜のあいだも止まらずに進みます。

    3つめは、実行中の追加指示を前提にすること。長い仕事の途中で様子を見て、「その方針で、ついでにここも」と声をかけるのは普通の使い方です。

    4つめは、大きな仕事をサブエージェントに分けること。5つめは、長い案件の進捗をTASKS.mdというファイルに残すこと。6つめは、終わったら「マージ（本番への取り込み）を止めるほどの問題だけ」を別の目で再レビューすること。この3つは次の章以降で詳しく扱います。

    この6点を、いちばん気軽に試せる形にしたのが次の依頼文です。社内で半年止まっている仕事を1つ選び、材料と完成条件と戻す条件だけを書いて渡してください。

    あなたは、止まっている仕事を最後まで仕上げる担当です。
途中で「よく考えて」とは言いません。以下の3つだけを守ってください。

【材料】（読んでよいもの）
- 【ここにファイル・フォルダ・URL】
- 【ここに過去のメモや議事録】

【完成条件】（これがそろったら終わり）
- 【ここに成果物：例）社内向けの手順書（Word形式・A4で5枚以内）】
- 【ここに確認方法：例）手順どおりに操作して、最後の画面まで到達できる】

【人間に戻す条件】（これが起きたら作業を止めて報告）
- 材料の中で、事実が食い違っている箇所を見つけた
- 【ここに条件：例）社外の人に連絡が必要になった】

報告の形:
1. できたもの（ファイルの場所）
2. 完成条件をどう確かめたか
3. 確認できなかったこと

    長い仕事は、TASKS.mdと「止める問題だけ」の再レビューで締める

    何時間もかかる仕事を任せると、進捗がチャットの中だけに残る状態がいちばん危険です。会話が長くなるとAIは古いやりとりを要約して詰め直すので、途中の決めごとが抜け落ちることがあります。そこで、進捗は必ずファイルに書かせます。

    画像

    図は、中央にTASKS.mdのチェックリストを置き、左に「チャットだけ→消える」、右に「翌日もそこから再開」を並べたものです。赤く塗った「原因不明の失敗 2件」の行が、人間に戻す条件に当たった箇所です。AIが途中で入れ替わっても、次の担当はファイルを読めば続きから始められる、という点を見てください。

    リポジトリ（プログラム一式の保管場所）やフォルダの一番上に置く雛形です。最初の依頼で「これを作ってから着手して」と伝えます。

    # TASKS.md

## ゴール（完了条件）
- 【ここに完了条件を1〜3行で】

## 人間に戻す条件
- 【ここに条件】

## 進捗
| # | タスク | 担当 | 状態 | メモ |
|---|---|---|---|---|
| 1 | 【ここにタスク】 | explore | 完了 | 影響範囲は12ファイル |
| 2 | 【ここにタスク】 | implement | 作業中 | |
| 3 | 【ここにタスク】 | review | 未着手 | |

## 決めたこと（あとから変えない）
- 【ここに決定事項と日付】

## 確認できなかったこと
- 【ここに未確認事項と理由】

    仕事が終わったら、もう一度だけレビューをかけます。「全部見直して」と頼むと、好みの指摘が大量に出て、読むだけで疲れます。頼むのは、取り込みを止めるほどの問題だけ。作った担当とは別の部下に渡してください。

    あなたは読み取り専用のレビュー担当です。ファイルは編集しないでください。
対象: 【ここにブランチ名 または 変更ファイルの一覧】

指摘してよいのは、本番に取り込むのを止めるべき問題だけです。
- 動作が壊れる、データが消える、セキュリティ上の穴になる
- 完了条件（【ここに完了条件】）を満たしていない
書き方の好み、命名、細かい整理の提案は書かないでください。

出力形式:
- 判定: 取り込んでよい / 止めるべき
- 止めるべき理由（ある場合のみ）: ファイル名・行・何が起きるか・根拠
- 確認できなかった範囲

    サブエージェントは、権限と並列のために分ける

    ここで、サブエージェントという言葉をあらためて説明します。メインの会話の中から起動する、別の作業机を持った部下のことです。机を分けると、部下ごとに「触ってよい道具」と「使うモデル」を変えられます。長い仕事を任せるうえで効いてくるのは、この点です。

    画像

    図は、左にメインの机、右に3つのサブエージェントの机を置き、点線（別コンテキスト）で分けたものです。資料が散らかるのはサブの机だけで、メインの机に届くのは「要約」の1枚ずつ。メインの机には「指示」と「最終判断」のはんこだけが残ります。

    分かれるもの、分かれないものを整理しておきます。会話の記憶は分かれます。メインは指示と最終判断を、部下はそのタスクだけを覚えます。使える道具は、メインから引き継ぐことも、絞ることもできます。モデルも部下ごとに選べるので、探索は安いモデルで済ませられます。一方、費用は同じ利用枠に加算されます。

    使いどころは3つです。1つめは、権限を制限すること（レビュー担当に書き込みを渡さない）。2つめは、並列化。外部とのつなぎ口（API）、データベース、画面の3か所を同時に調べさせる、といった使い方です。3つめに、メインの会話に探索の途中経過を持ち込まないことがあります。

    Claude Codeには最初から3種類の部下が組み込まれています。読み取り専用で探し物をする「Explore」、計画モードで調査をする「Plan」、調べて直すまでやる「General-purpose」です。自然な文で「認証の流れをサブエージェントで調べて」と頼めば、適した部下が選ばれます。

    編成の基本は、親が司令塔、部下が作業、親が検証。そして階層は親と並列の部下の2層までにとどめます。私が深さを1段に固定しているのもこのためです。

    調査を並列で頼むときの依頼文です。システム全体の点検や、外部から引き継いだ仕組みの棚卸しに使えます。「確認できなかったこと」を必ず残させるのが肝心で、これがないと「問題なし」と「見ていない」の区別がつきません。

    あなたは監査の取りまとめ役です。
このリポジトリの【ここに観点：例）個人情報の取り扱い】を、サービス単位で監査してください。

進め方:
- サービスごとにサブエージェントを1つずつ並列で起動する（モデルは sonnet を指定）
- 各サブエージェントは読み取り専用。ファイルの編集は禁止
- 各サブエージェントは次の3点を返す
  1. 見つかった問題（ファイル名・行・根拠）
  2. 調べた範囲（読んだファイルの一覧）
  3. 確認できなかったことと、その理由

対象サービス:
- 【ここにサービス名1】
- 【ここにサービス名2】
- 【ここにサービス名3】

親（あなた）の仕事:
- 各報告の根拠を実際のファイルで1件ずつ確かめ、裏が取れたものだけを一覧表にする
- 一覧表の下に「確認できなかったこと」をサービスごとにまとめて残す

    定義ファイル1枚の解剖と、置き場所の優先順位

    毎回同じ役割を頼むなら、部下を定義ファイルにしておきます。定義ファイルは、冒頭の設定欄（YAMLフロントマターと呼ばれる、---で挟んだ部分）と、その下の本文でできています。本文は、その部下専用の指示書として読まれます。親の指示は引き継がれないので、必要なことは本文に書き切ります。

    画像

    図は、定義ファイル1枚に引き出し線をつけて、各項目の役割を書き込んだものです。上半分のフロントマター（name・description・tools・model・permissionMode）が設定欄、下半分が「本文＝専用の指示書」です。赤で強調した「使える道具（tools）」が、今回私が見落としていた行です。上が権限、下が仕事の中身という分担で読んでください。

    主な項目を並べます。

    - name：部下の名前。識別に使われるのはファイル名ではなく、この値です

    - description：どんなときにこの部下を呼ぶか。司令塔が振り分けに使うので、短く具体的に

    - tools：使ってよいツール。書かなければ全部引き継ぎます

    - disallowedTools：使わせないツール。ここで細かい条件を書いても、ツールごと外れる点に注意

    - model：sonnet、opus、haiku、fable、inherit（親と同じ）など

    - permissionMode：確認なしで編集してよいか、計画だけにするかなどの動き方

    - maxTurns：往復の上限。上限に達すると途中結果を返し、あとから再開できます

    - skills：起動時に読み込ませる手順書

    - hooks：その部下の中だけで動く自動処理

    - memory：記憶を残す範囲

    - effort：どれだけ深く考えるか

    - isolation：worktreeと書くと、作業用の別コピーの上で作業します

    - omitClaudeMd：プロジェクトの共通ルール（CLAUDE.md）を読ませない

    項目名は大文字小文字を区別した書き方（camelCase）で書く必要があり、知らない項目は黙って無視されます。書いたのに効かない、というときはまず綴りを疑ってください。

    次に、置き場所です。

    画像

    図は、定義ファイルの置き場所を1〜5の段で示したものです。上から、組織の管理設定、起動時のコマンド指定（--agents）、プロジェクトの.claude/agents/、個人の~/.claude/agents/、プラグインの順です。左の矢印のとおり、同じnameの部下が複数あると上の段が勝ちます。赤枠のプロジェクト用が、ふだん一番よく使う置き場所です。

    たとえば個人の置き場所に「reviewer」を作っていても、プロジェクト側に同じnameの定義があれば、そのプロジェクトではプロジェクト側が使われます。最近の版では/agentsコマンドで作成画面が開かなくなったという報告もあり、Claudeに作らせるか、ファイルを直接置くのが確実です。

    読み取り専用のレビュー担当の完成形です。プロジェクトの.claude/agents/reviewer.mdとして保存すれば、そのまま使えます。

    ---
name: reviewer
description: 変更差分のレビュー専用。実装が終わった後に、取り込みを止めるべき問題だけを指摘する。編集はしない。
tools: Read, Glob, Grep
model: sonnet
permissionMode: plan
effort: high
omitClaudeMd: true
---

あなたは読み取り専用のレビュー担当です。ファイルの編集・作成・コマンド実行はできませんし、してはいけません。

## 見る観点
- 動作が壊れる、データが消える、セキュリティ上の穴になる変更
- 依頼時に渡された完了条件を満たしていない箇所
- 【ここにプロジェクト固有の観点：例）金額計算は必ず整数で扱う】

## 見ないもの
- 書き方の好み、命名、コメントの有無

## 返す形式
- 判定: 取り込んでよい / 止めるべき
- 指摘: ファイル名・行・何が起きるか・根拠
- 確認できなかった範囲

    実装担当の完成形です。作業用の別コピーで動かし、孫請けを禁止し、往復の上限を決めておきます。

    ---
name: implementer
description: 仕様とTASKS.mdに沿ってコードを書き、テストを通すまで進める実装担当。レビューはしない。
tools: Read, Write, Edit, Glob, Grep, Bash
disallowedTools: Agent
model: sonnet
maxTurns: 40
isolation: worktree
memory: project
---

あなたは実装担当です。レビューと最終判断は別の担当が行います。

## 着手前
- TASKS.md を読み、自分の担当タスクを確認する
- 完了条件が書かれていなければ、作業せずに親へ戻す

## 作業中
- 1タスク終わるごとにテスト（【ここにテストコマンド】）を実行する
- 結果と判断の理由を TASKS.md のメモ欄に追記する

## 人間に戻す条件
- 原因の分からないテスト失敗が2回続いた
- 【ここに条件：例）データベースの構造を変える必要が出た】

## 返す形式
- 変更したファイル一覧／テスト結果／TASKS.md の更新箇所

    ポイントは、実装担当にはAgent（部下を呼ぶツール）を持たせないことです。これで孫請けが設定の上でも起きなくなります。

    探す係にもルールを渡す。Explore向けhook

    役割ごとに、渡す権限を整理するとこうなります。

    画像

    図は、3つの係を横に並べ、使えるツールを✓と✗で示した比較表です。探す係（Haiku）と見る係（Sonnet）はRead・Grep・Globだけで、EditとWriteには赤い✗が付いています。作る係だけがEdit・Write・Bashを持ちます。探す係と見る係は道具が同じでも、渡している指示書の中身が違う点を見てください。

    組み込みのExploreは、軽く速く動くように、プロジェクトの共通ルール（CLAUDE.md）を読まずに起動します。つまり、CLAUDE.mdに「秘密情報のファイルは開かない」と書いていても、Exploreには届きません。

    組み込みのExploreの設定欄を直接書き換えることはできないので、道は2つです。1つは、Claude Codeの設定ファイル（settings.json）に、Exploreが起動したときだけ動く自動処理（hook）を登録すること。もう1つは、同じ「Explore」という名前で自分の定義を作って上書きし、その設定欄にhookを書くことです。

    画像

    図は、Exploreの仕事を左から右への時間軸で描き、hookが割り込める3つの地点を示したものです。起動の瞬間（SubagentStart）はルールの注入、ツールを使う直前（PreToolUse・赤い手）は危険な操作の阻止、終了時（SubagentStop）は結果の検査と保存です。下の注記のとおり、組み込みExploreはCLAUDE.mdを読まないので、ルールは起動時に注入するしかありません。

    押さえておきたい仕組みは3つです。

    - 起動時の追加指示は、SubagentStartのhookが返すadditionalContext（追加の文脈）で渡すのが本命です

    - ツールを使う直前のhook（PreToolUse）は、Exploreの中でもメインの会話でも同じものが動きます。中で「今動いているのはExploreか」を確かめて分岐させます

    - PreToolUseのhookが終了コード2で終わると、そのツールの実行は止まり、エラー文がAIに返ります

    プロジェクトのフォルダで実行すると、この3つがそろう手順です。jq（JSONを扱う小さな道具）が入っている前提です。

    # 1) Explore 起動時に、読んではいけない場所と返し方のルールを注入する
mkdir -p .claude/hooks .claude/agents
cat > .claude/hooks/explore_context.sh <<'EOF'
#!/usr/bin/env bash
cat <<'JSON'
{"hookSpecificOutput":{"hookEventName":"SubagentStart","additionalContext":"【Explore向けルール】.env や鍵ファイルなど秘密情報は開かない。結果のファイルパスは必ず絶対パスで返す。【ここに追加ルール】"}}
JSON
EOF

# 2) Explore の中でだけ、削除・移動・push を止める（終了コード2で拒否）
cat > .claude/hooks/explore_guard.sh <<'EOF'
#!/usr/bin/env bash
input="$(cat)"
agent="$(echo "$input" | jq -r '.agent_type // empty')"
cmd="$(echo "$input" | jq -r '.tool_input.command // empty')"
if [ "$agent" = "Explore" ] && echo "$cmd" | grep -Eq '(^|[;&| ])(rm|mv|git push)( |$)'; then
  echo "Explore では削除・移動・push はできません: $cmd" >&2
  exit 2
fi
exit 0
EOF
chmod +x .claude/hooks/*.sh

# 3) 探索だけ安いモデルに替えたい場合は、同じ名前で上書きする（任意）
cat > .claude/agents/explore.md <<'EOF'
---
name: Explore
description: 読み取り専用の探索。ファイルの場所と中身の要約を返す。
tools: Read, Glob, Grep
model: haiku
effort: low
---
探した結果は、絶対パスと要約だけを返してください。
EOF

# 4) .claude/settings.json の "hooks" に次を追記する（既存の hooks がある場合は中身をマージ）
cat <<'EOF'
"SubagentStart": [
  { "matcher": "Explore", "hooks": [ { "type": "command", "command": "bash .claude/hooks/explore_context.sh" } ] }
],
"PreToolUse": [
  { "matcher": "Bash", "hooks": [ { "type": "command", "command": "bash .claude/hooks/explore_guard.sh" } ] }
]
EOF

    SubagentStartのmatcherは大文字始まりの「Explore」で固定です。PreToolUseのmatcherはツール名なので、部下の名前ではなく「Bash」と書き、中で部下の種類を見て分けます。組み込みのExploreとPlanは使い切りで、あとから再開するための番号を返しません。探索を途中から再開したい場合は、カスタム定義かGeneral-purposeを使ってください。Exploreそのものを止めたいときは、拒否リスト（permissions.deny）を使います。settings.jsonのここにAgent(Explore)を入れてください。

    向き・不向きと、やりがちな失敗

    向いているのは、成果物がファイルや動くデモになる仕事、途中で検証ができる仕事、仕様を文章で書ける仕事です。

    向いていないのは、まず現場の一次情報がない記事。取材や体験がないまま書かせると、それらしいけれど中身のない文章になります。次に、法務や税務の最終判断。下ごしらえまでは任せられても、最後の判断は専門家と人間が持つべきです。そして、描画そのものに時間がかかる3D。5分の動画を書き出すのに十数時間かかったという報告もあり、AIが賢くても計算の重さは変わりません。

    やりがちな失敗も並べておきます。

    - 探索まで全部Opusで回して、費用だけが膨らむ

    - descriptionを長文にして、振り分けが迷う

    - 部下に最終判断まで任せ、親が検証しない

    - 進捗をチャットの中だけに残し、会話が長くなって決めごとが消える

    - サブエージェントと、別に立ち上げたバックグラウンドのセッションを混同する

    - toolsを書かず、見る係に書き込み権限を渡したままにする

    最後の1つは、私自身が33本中29本でやっていた失敗です。まずは今ある定義を棚卸しするところから始めてください。次の依頼文は、定義ファイルを読んで一覧にするだけで、何も書き換えません。

    あなたは読み取り専用の監査担当です。ファイルは編集しないでください。
~/.claude/agents/ と .claude/agents/ にある定義ファイル（.md）をすべて読み、次の表を作ってください。

| name | 置き場所 | tools の有無 | model の指定 | description の文字数 | 役割の推定（探す/作る/見る/その他） |

そのうえで、次に当てはまるものを別表で指摘してください。
1. tools が未設定で、役割が「見る」または「探す」の定義（書き込み権限の渡しすぎ）
2. model が未指定の定義（親と同じ高いモデルに落ちる可能性）
3. description が【ここに上限：例）200字】を超える定義
4. 同じ name が複数の置き場所にある定義（どれが勝つかも書く）

最後に、全 description の合計文字数と、直す優先順位の上位5件を理由つきで示してください。

    ルールを「約束」から「設定」へ移す

    33本の棚卸しを始めてから、朝の確認のしかたを変えようとしています。

    これまでは、見る係が本当に見るだけだったか、作る係が決めた範囲を越えなかったかを、会話のログをたどって確かめていました。ルールが文章の約束でしかない以上、守られたかどうかは結果を読んで確かめるしかなかったからです。

    権限を定義ファイルに書き込めば、この確認は要らなくなります。見る係はそもそも書けない。作る係は部下を呼べない。そうなれば、朝に見るのはTASKS.mdの差分と、見る係が返した判定だけで済みます。今はその形に切り替えている途中です。

    画像

    図は、左に以前の夜（大量のやり取りとログを読み返して疲れている姿）、右に目指す朝（コーヒーを片手に、タブレットの「差分」と「止める問題 0件」だけを見る姿）を並べたビフォーアフターです。人間の仕事が「疑って読む」から「決める」に移る点を見てください。

    余談ですが、部下に名前をつけると、不思議と定義を見直す気になります。

    Opus 5.5のような長く走れるモデルが出てきて、AIに任せられる仕事の距離は確実に伸びました。ただ、距離が伸びるほど、走り出す前に決めておくことの価値が上がります。どこがゴールか、どこで止まって人間に戻すか、途中で誰が何に触れてよいか。前の2つは依頼文に、最後の1つは定義ファイルに書きます。私の場合、33本のうち4本しかできていなかったのは3つめでした。

    もし今日1つだけ試すなら、社内で止まっている仕事を1つ選び、材料と完成条件と戻す条件の3行を書いて渡してみてください。そして明日は、自分の部下の定義ファイルを開いて、tools行があるかどうかを数えてみてください。数字が出た瞬間に、次に何を直せばよいかが見えてくるはずです。

    ▶ 30 問で自社の経営課題を診断する（無料・3 分）

    あわせて読みたい

    Opus 5.5でゲームを作ってみた

    https://note.com/comix_ceo162230/n/n01291478cdd2

    CLAUDE.mdを削ったら、AIが指示を守りはじめた。──Claude CodeとCodex、9月の使い分けは「決める人・作るAI・見るAI」

    https://note.com/comix_ceo162230/n/n176892d48c6a

    AIは「やっておいて」では動かない。人も同じだった。

    https://note.com/comix_ceo162230/n/n1f776c33a824

    自己紹介

    株式会社コミクス代表取締役の鈴木章裕です。営業の叩き上げで25年、会社を創業して18年、これまでのお取引は1,825社になりました。いまは「生成AI活用顧問」として、経営者の隣でAIの選び方から現場への定着までを伴走しています。自社でもClaude CodeとCodexを毎日使い、社長の仕事をどこまでAIに渡せるかを実験し続けています。フルマラソン完走71回、100kmウルトラマラソン完走17回。「続けること」がいちばんの武器だと思っています。

    ▶ 鈴木章裕の自己紹介ページはこちら

    鈴木章裕

    株式会社コミクス 代表取締役

     
     
     

    鈴木章裕

     
     
    AI活用のご相談→ https://www.comix.co.jp/contact/ 株式会社コミクス代表取締役。生成AI活用支援実績304社（2026年9月末現在）。営業・資料作成の効率化、AIエージェント導入を支援。何から始めるか迷っている段階でもご相談ください。

    あなたへのおすすめ