AI への頼み方は、毎回言葉で指示を書く形から、手順や境界をファイルにして先に置いておく形へ変わった。この変化には、役割を渡して動かし始めた日から、積んだ仕組みを削るまで、数か月の経緯がある。この記事では、その順に、何を作り、どこで壊れ、何を直したかを書く。記憶の仕組みだけは別にまとめたので、そちらは続きの記事に回す。
役割を渡した日
きっかけは、毎回同じような指示を打ち込む代わりに、役割ごとまとめて渡せばよいのではないかと考えたことだった。Claude Code にはサブエージェントという、役割を分けて動かす仕組みがある。進行管理、調査、広報、実装の 4 つを定義し、それぞれに専用の指示書を持たせた。定義には丸 1 日かかったが、全体像を早くつかみたかったので、その日のうちに 4 つとも動かした。指示書が荒削りでも、一通り動かさないと分からないことがあると考えたからである。
動き出してからは、スマホから 10 分の隙間に「この方向で進めておいて」と入力しておくと、帰宅する頃に調査結果や下書きができているようになった。ただ、表面上は機能していても壊れていないとは限らない。数日で次の 3 つが出た。
最初に踏んだ 3 つの失敗
1 つ目は言葉の解釈である。書き手の役割を広報役の部下として配置するよう指示したところ、書き手は広報役の下ではなく、独立した並列の担当として実装された。「配置」を、組織の指揮系統ではなく、システムのデプロイ先の話として処理したためである。AI はこの種の取り違えを、迷いのない口調で返してくる。指示に関係や優先順位が含まれるときは、どの文脈の話かを先に書くか、どう解釈したかを一度言わせてから作業に進ませるようにした。
2 つ目は範囲である。自作の Web アプリを本番に公開する作業を、担当役に「公開しておいて」の一言で任せた。担当役は作業の前に周辺を確認し、仮置き場に放置してあった書きかけの古いコードを、頼んでいないのに作業環境へ引き出して混ぜた。新旧のコードがぶつかり、作業場が一時収拾のつかない状態になった。確定済みの成果物は無事だったが、片づけに時間を取られた。以後は、やってよい操作の境界を先に書き、境界の外が必要になったら実行せず報告するよう添えている。
3 つ目は判断の消失である。役割を並行で動かすと、ある役割が下した判断がどこにも残らず、次のやり取りで同じ問いを最初から考え直すことが起きた。そのたびに答えが少しずつ違い、方針がぶれた。同じ時期に、問題が起きると AI が黙って別のやり方でやり直す動きも問題になった。何が起きたのかを私が追えなくなるためである。そこで、失敗したときは「何が失敗したか」「なぜか」「どう立て直すか」の 3 点を先に報告させ、私が確認してから次に進む決まりにした。いまも運用の中心にある決まりである。
もう 1 件、役割とは別の経路でも失敗している。X への投稿を自動化するために入れたオープンソースのツールが、動作確認では問題なく動いたのに、ソースを読むと投稿文の末尾にクレジット文を強制的に付ける実装を含んでいた。該当箇所を削除して再ビルドし、アクセストークンを再発行した。動いていることと、意図どおりに動いていることは別だと分かった件である。
指示を磨くのをやめて、手順書を置いた
同じ頃、報告書や議事録の下書きを AI に頼むたびに、形式や禁止事項の注文を毎回書き足していた。注文を打つ時間が自分で書く時間とあまり変わらない日があり、配布されているプロンプト集を保存して使い回してみたが、3 日ほどで止まった。誰にでも当てはまる文面なので毎回手直しが要ること、手直しのたびに言い回しが変わって質が揺れること、保存が増えるほど探す時間が増えることが理由である。疲れている日の指示は雑になり、成果が自分の調子に左右される点も変わらなかった。
そこで、注文を入力に溜めるのをやめ、仕事のやり方を 1 枚の手順書にして AI の側に置いた。Claude Code ではこれをスキルと呼び、フォルダと SKILL.md というテキストファイル 1 枚で作る。冒頭の description に「どういう頼まれ方のときに使うか」を書いておくと、該当する場面でだけ AI が読みに来る。中身は、目的、受け取るもの、出す形、出す前の確認の 4 つを文章で書くだけである。出す前の確認に毎回口で言っていた注文をそのまま書くと、AI が読み返してから出すようになり、同じ指摘を繰り返さずに済んだ。
skills/
trouble-report/
SKILL.md ← 冒頭の description が呼び出しの引き金最初に書いた手順書は、3 つ目の失敗から生まれた 3 点セットの報告の型だった。そのあと報告書と議事録の型を足した。指示を書く工程と直す工程がなくなり、体感では作業が 5 分の 1 ほどになった。ストップウォッチで測った数字ではなく、確認と手直しは今も残っている。変わったのは、疲れている日でも出てくるものの質が落ちなくなったことである。
運用では、AI に仕事を任せるとき、手順書のファイルの場所を指定して渡すようにした。手順書を渡されなければ動けない順序にしておくと、手順を飛ばした我流の作業が起きにくい。
ハーネスという名前は、後から知った
ここまで、自分では「役割」と「手順書」と「決まり」を足していただけだった。あとから、エージェントはモデルとハーネスでできているという説明を知った。ハーネスは、モデルを実務につなぐ周辺の一式であり、Claude Code なら CLAUDE.md、スキル、フック、サブエージェント、権限設定、MCP、メモリがその部品に当たる。自分が足してきたものは、すべてこの部品表のどれかに入っていた。
| 運用上の決まり | 実装している部品 |
|---|---|
| 繰り返す仕事は手順書に | スキル（SKILL.md） |
| 役割ごとに触ってよい範囲を分ける | サブエージェントに持たせる道具の制限と、定義に重ねて書く禁止ルール |
| 失敗したら 3 点を先に報告 | CLAUDE.md に運用ルールとして記載 |
| 判断と失敗を後から思い出せるように | メモリと検索（別の記事に書いた） |
| 公開・金銭・外部発信は人が決める | 権限設定、CLAUDE.md の承認ゲート、そして投稿用の接続口をどの役割にも繋がないこと |
最後の行は、ルールで縛るより道具ごと外すほうが強いと分かった例である。調査役には読む道具と検索する道具だけを渡して書き換える道具を持たせず、投稿を実行する役には本文を書き換える道具を持たせていない。直したくなったら制作の工程へ差し戻すしかない順序を、道具の側で作っている。ただし道具の制限だけでは線引きが完結しないので、定義に「既存のファイルを改変しない」といった禁止ルールを重ねている。
順序についても書いておく。設計図を先に描いて部品を当てはめたのではなく、不具合を塞いでいった結果が、あとから部品表に重なって見えただけである。
公式の失敗報告に当てて数えた
Anthropic がマルチエージェントの失敗パターンをまとめた研究記事を公開したので、自分の環境に当てて数えた。数えた時点の環境は、実行プロファイルが 6 つ、手順書が 96 枚、記録した失敗が 78 件だった。
- 同じ規則から同じ答えが出る件は、そのまま起きていた。「一覧のいちばん大きい番号に 1 を足す」という規則から、別々のやり取りが同じ番号を導き、後から処理したほうが先の内容を記録ごと上書きした。論文の例は分岐名の重複で実害がないが、こちらは上書き先が判断の記録そのものだったので、実際に消えた。
- 知っていることに従って動かない件も、そのまま起きていた。月次の点検を回す自動処理が文法の誤りで 47 日間止まっており、止まっているという警告は 12 日間、毎回のやり取りで出ていた。台帳は 78 件あったが、見ても通り過ぎていた。
- 縄張り争いは、78 件の中に 1 件もなかった。6 つの役割のうち、他の役割を起動する手段を持つものが 0 だったためである。互いが見えず起動もできないので、争う状況が作れない。ただし、実験条件が違うので「この構造では起きなかった」までしか言えない。
- 指示を字義どおりに追う性質は、形を変えて出た。承認を求めるページ自体に「一覧と回答は残す」と私が書いていたのに、承認した選択肢のラベルだけを見た処理が、一覧 47 件を丸ごと削除した。
論文の対策は、部分的に重なる複数の報告を比べて嘘を見破るものだったが、こちらは 1 つの作業を 1 つの役割に任せる構造なので、比べる相手がいない。同じ日にも、実測値つきで「完了条件が全部通った」と報告された実装に、検査していない経路の抜けが 2 つあった。見つけたのは矛盾からではなく、すべての経路がどの区分に属するかを自分で数え直したときだった。
積んだものを削った
役割、手順書、決まりを足し続けた結果、やがて毎ターンの読み込みが 6 万から 12 万トークンになっていた。使われていない部品があり、壊れたまま無視されている警告が多く、同じ方針が 4 か所に書かれ、撤回済みの内容も残っていた。そこで、使うものだけ残して削った。段ごとに承認を取りながら進めている。
- 部署単位のプラグインと、組織を広げるための手順を一覧から外した（消してはおらず、パスを指定すれば読める）。
- 起動時に走る夜間のバッチと督促、組織図や採点の自動更新を止めた。
- 要約は毎ターンではなく、セッション終了時と圧縮前だけにした。
- 方針は 1 か所のファイルだけを正とし、CLAUDE.md は変わらない決まりだけに絞った。264 行が 42 行になった。
- 記事の査読ボードを外し、公開前の関門を 3 つに絞った（秘密情報の検査、公開前の dry-run を目で見ること、承認の言葉）。
削る前に影響を調べると、そのまま外せば「公開前の検査がゼロになる」といった重い被害が 5 つ見つかった。それらは計画に戻して避けている。足すときより、削るときのほうが依存関係の調査に手間がかかった。
いまの形
いま残っているのは次のものである。CLAUDE.md は 42 行で、変わらない決まりと、承認なしに公開しないという線だけを持つ。実行プロファイルは 6 つのままで、権限とモデルだけを持ち、手順は持たない。起動するときは手順ファイル（SKILL.md か runbook）のパスを必ず渡す。プラグイン配下の SKILL.md は、止めたものを含めて 105 枚ある。投稿を担当するプロファイルは本文を書き換えず、X の道具も持たない。
指示を毎回上手に書く工夫は、書き手の調子に左右される。手順や境界を環境に置くと、雑な言い方でも同じ形に収まるが、置いたものには読み込みと保守の費用がかかり、積んだ分だけ重くなる。環境に置くほうを選んだうえで、置きすぎた分を後から削った、というのが今の状態である。
この記事は、note に書いた次の 4 本を、一本の経緯として書き直したものである。手順を画面つきで追う場合や、手順書の実物を見たい場合は、元の記事のほうが細かい。