ハーネスも結局はファイルとスクリプトなので、Claudeに作らせられる。ただし順番がある。実測させ、提案を受け、承認し、その後で作らせる。すぐ使える指示例も示す。
DELEGATE · 202602編の五つのファイルを手で作る必要はない。ハーネスの部品はテキストファイルとシェルスクリプトで、それを作ることこそ機械の得意な仕事だ。調べた作業場のハーネスも大半はそう作られた。人が方向を決め、機械がファイルを作り、人が検査した。
ただし順番が命だ。いきなり「ハーネスを作って」と言えば、機械はどこかで見たもっともらしい枠を想像で作る。思い込みのハーネスは思い込みのコードより危険だ。コードのバグは一機能を壊すが、規則のバグは今後の全セッションを誤らせる。定量的な根拠もある。機械が丸ごと自動生成した規則書は性能を逆に3%下げたという測定がある。「コードをきれいに保て」など一般論だけで、場所を取り、情報はないからだ。よい規則はこのリポジトリの失敗経験から取り出したものだけ。だから順番は必ずこうなる。まず何があるか実測させる。次にファイルを作らず表で提案を受ける。人が承認する。その後で作らせる。
DELEGATE · 2026初回構築。「このリポジトリの構造と危険箇所を実測せよ。その根拠から①憲法文書CLAUDE.mdの六十行の草案、②役割・渡す道具・外す道具・モデル等級を記したエージェント名簿を提案せよ。ファイルはまだ作らず、表だけを示せ」。核心は最後の一文だ。提案と実行を分ければ、検査する場所ができる。
検証ゲート。「完了宣言前に型検査・テスト・ビルドを強制するスキルと、プッシュ直前に同じ三段を回して失敗時に遮断するGitフックを作れ。作成後、意図的に型エラーを一つ入れ、フックが本当にプッシュを拒否するか実測し、出力を示せ」。作ったばかりの安全装置をその場で試射させる。「作られたが一度も発動していない装置」が複数の作業場で見つかった後に生まれた規律だ。
移植。「あのプロジェクトの完了検証スキルを、このリポジトリに合わせて移植せよ。ファイル冒頭のコメントに元の出典と変更点を残せ」。調べた作業場のスクリプトには実際にこうした出典表記がある。検証された部品の系譜はそうして続く。
そして全指示に共通の末尾。「作ったと報告するのではなく、動作を実測した出力を付けよ」。この一文で指示の半分を占める。
DELEGATE · 2026ハーネス制作を委任しても、委任してはいけないものが一つ残る。承認だ。調べた最大の作業場では構造として固定されていた。機械がハーネスフォルダを直接直そうとするとフックが止め、専任作業員への委任を強制する。規則文書の更新は提案書フォルダを経由し、利用者の承認なしでは反映されない。檻を作るのは獣でもよい。檻の鍵は人間が持つ。
初心者の検査方法は大げさではない。作られたファイルを自分で開く。最初から最後まで読む。分からない行があれば貼り付けて聞く。「この行は何をする。なければ何が起きる」。答えに納得できなければ消させる。読んで理解した規則だけがあなたの規則だ。理解していない規則は機械の規則で、ハーネスではなく飾りだ。
分量にも承認が要る。機械に任せるとハーネスは簡単に肥大する。一日に作業員十人、スキル三十個を出す程度は造作もない。実測からの教訓は逆を指す。小さく始め、事故のたびに一つ増やせ。04編で見るように、よいハーネスの部品の多くは実際の事故の傷痕だ。傷痕なしに育ったハーネスは体に合わない。
DELEGATE · 2026九つの作業場のハーネス規模はリスクの大きさに従う。金銭を扱う決済サービスはセンサーだけで五十七個。決済の冪等性、返金の原子性、秘密の漏出まで計器が付く。一方、静的な広報サイトでは「ファイル修正直後の型検査」というフック一つがすべてだ。どちらも正しい。ハーネスの費用は実在する。検問が増えるほど一回のコミットが遅くなる。低リスクの場所で過剰なハーネスは、安全ではなく摩擦だ。
最も印象に残った実測は、ある内部ツールの文書の一行だった。「エージェント0個、フック0個。意図的に削除。利用者の決定」。部品がないことと、置かないと決めて記録することは全く違う。後者は、次のセッションの機械が「なぜここにはエージェントがない？作ろう」と誤判断することまで防ぐ。不在を文書にすることもハーネスだ。
だから開始規模はこう決めよ。このリポジトリが壊し得る最も高価なものは何か。金か、評判か、夜の時間か。その答えの大きさだけ作り、残りは事故が請求書を持ってきたときに増築せよ。