AIに開発を最後まで任せる

なぜ要るか

ここまでは、頼んで待って、確認して、また頼む形でした。AIが動いている間、こちらは見ています。

これを外します。頼んだら席を立てる状態にします。

そのために必要なのは、賢い指示ではありません。終わったかどうかを機械が判断できる形です。ここを外すと、任せた仕事は必ず途中で迷子になります。

使う道具: なし（ここまでで作った確認の仕組み）

AIプロンプト

この術の作業をAIへ任せるときは、これをそのまま貼ってください。

6-2 の checkDeck に、power が負の数の札を弾く検査を足して。
足したら、わざと負の数の札を入れて起動が止まることを確認して、元に戻して。
npm test が通ることを確認したら、変更点を3行で報告して止まって。
途中で判断に迷ったら、進めずに質問して止まって。

最初の1行は、自分が任せたい作業に置き換えてください。後半3行はそのまま残します。

任せられるかは「終わりの決め方」で決まります

まず区別します。

任せられる仕事	任せられない仕事
終わりが機械で判定できる	終わりが人の感覚で決まる
例: テストが通る、ファイルができる	例: 「かっこよくなったら」

「面白くなるまで直して」は任せられません。 判定できないので、いつまでも終わりません。

だから任せるときは、終わりを言葉ではなく条件で渡します。

claude -p "6-6 の測定で、弱い順に出したときの勝率が45〜55%に収まるまで、
配る枚数を1枚ずつ変えて測り直して。
条件を満たしたら、その枚数と測定結果を報告して止まって。
30分試して収まらなければ、そこまでの結果を報告して止まって。"

決めているのはこの3つです。

決めること	上の例では
成功の条件	勝率が45〜55%に収まる
打ち切りの条件	30分試しても収まらない
報告すること	枚数と測定結果

打ち切りの条件が一番忘れられます。 これが無いと、終わらない作業を延々と続けます。6-6で無限ループの話をしたのと同じ構造です。

見本ゲームの作業で書くなら、こうなります。5-5の紋を足す仕事の終わりの条件は、門・蔵・井の3つの紋が index.html に線だけのインラインSVGで入っていて、色が currentColor になっていて、画像ファイルが1枚も増えていないこと。文字を探すだけ、ファイルの数を数えるだけで判定できます。「和風でいい感じになったら」では判定できませんが、この形なら席を外せます。

完了は「成果物の存在」で判定します

ここが実務でいちばん痛い教訓です。僕は完了の判定を間違えて、半日溶かしました。

長い処理を任せるとき、完了をどう判定するかには2通りあります。

判定のしかた	結果
処理が終わったか（プロセスの有無で見る）	失敗した
成果物ができたか（ファイルの有無で見る）	正しい

プロセスというのは、いま動いている処理そのもののことです。「プロセスの有無で見る」とは、その処理がまだ動いているかを一覧から探して判定するやり方です。

上を選ぶと、こうなります。

処理の名前で「まだ動いているか」を探す
その探すコマンド自体が、探している名前を含んでいる
自分を見つけて「まだ動いている」と誤判定する
終わっているのに待ち続ける

僕はこれで、終わった処理を待ち続けるのと、後続の処理が自分自身を待つのを両方やりました。

正しいのは単純です。

# 成果物ができたかで判定する
until [ -f out/model.glb ]; do sleep 10; done
echo "できた"

読み方はこうです。until は「そうなるまでくり返す」、[ -f 〇〇 ] は「〇〇というファイルがあるか」、sleep 10 は「10秒待つ」。つまり成果物のファイルができるまで、10秒おきに見に行き続けます。

「動いているか」ではなく「できたか」を見る。 これだけで、待ち合わせの事故はほぼ消えます。

並列にすると壊れるものがあります

任せる量を増やすとき、同時に走らせたくなります。 ここに罠があります。同時に走らせることを並列と呼びます。1つずつ順番に走らせるより速く終わりますが、行き先が重なると事故になります。

同じ場所へ書き込む作業は、同時に走らせると壊れます。

同時に走らせて良いもの	駄目なもの
検索・読み取り	依存パッケージの入れ直し
別のフォルダでの作業	同じ生成物への書き出し
	同じ設定ファイルの書き換え

依存パッケージというのは、そのプログラムが動くために必要な外部の部品のことです。入れ直すと、置き場のフォルダを丸ごと作り替えます。

僕はこれで一度、依存パッケージの入れ直しを2つ同時に走らせて失敗しました。同じフォルダを2つのプロセスが同時に入れ替えて、途中で止まりました。

しかもこの失敗は、アプリの不具合に見えます。 原因が「同時に走らせたこと」だと気づくまで時間がかかります。

だから決めておきます。

読むだけ → 並列でよい
書くもの → 1つずつ

途中で止まったときに戻れるようにする

任せる前に、必ずこれをやります。

git add . && git commit -m "任せる前の状態"

1-4でGitを入れたのは、この日のためです。

任せると、こちらが見ていない間に大きく変わります。気に入らなければ捨てられる状態にしてから渡してください。

そして作業単位を小さく切ります。 「6章を全部作って」ではなく「6-1のデータ化だけやって」。理由は2つです。

途中で違う方向へ行ったとき、戻す量が少ない
終わりの条件を書きやすい

席を外す前のチェック

僕が実際に確認していることです。

確認	理由
直前の状態をcommitしたか	捨てて戻せる
成功の条件を書いたか	終われる
打ち切りの条件を書いたか	終わらない事態を防ぐ
確認コマンドを渡したか	自分で判定できる
書き込みが同時に走らないか	壊れない

5つとも1行で済みます。 これを飛ばして任せると、戻ってきたときに「何が起きたか分からない」状態に出会います。

やってみる

小さい仕事を1つ選ぶ

30分で終わる規模にしてください。最初から大きく任せないでください。

終わりの条件を書いて渡す

git add . && git commit -m "任せる前の状態"

claude -p "6-2 の checkDeck に、power が負の数の札を弾く検査を足して。
足したら、わざと負の数の札を入れて起動が止まることを確認して、元に戻して。
npm test が通ることを確認したら、変更点を3行で報告して止まって。
途中で判断に迷ったら、進めずに質問して止まって。"

最後の1行が効きます。 迷ったまま進まれるのが一番困るので、止まる許可を先に出しておきます。

席を外す

ここが目的です。見ていないと不安なうちは、まだ条件の書き方が足りていません。
戻ってきたら、報告ではなく成果物を見る
```
git diff
npm test
```
git diff は、前回保存した状態からどこが変わったかを全部見せるコマンドです。npm test はテストを走らせます。この2つで、実際に何が起きたかが分かります。

報告文を信じないでください。 差分とテストの結果が事実です。
気に入らなければ捨てる
```
git checkout .
```
git checkout . は、最後に保存した時点まで変更を全部捨てて戻すコマンドです。任せる前にcommitしておいたので、これで元の状態へ帰れます。

捨てる練習をしておくと、任せるのが怖くなくなります。

保存する

git add .
git commit -m "データの検査を足した"
git push

つまずきどころ

戻ってきたら関係ない場所まで変わっていた

作業単位が大きすぎます。「これ以外は触らないで」を明示してください。 6-2でも同じことを書きました。

終わったのか終わっていないのか分からない

終わりの条件が判定できない形になっています。「良くなるまで」ではなく「テストが通るまで」に置き換えてください。

待っているのに何も進んでいない

処理が止まっているのか、待ち合わせが誤判定しているのかを切り分けてください。成果物のファイルがあるかどうかを見るのが一番速いです。

同時に走らせたら失敗した

書き込み先が重なっています。1つずつに直してください。これはアプリの不具合ではなく、走らせ方の問題です。

任せた結果が信用できない

7-2と7-3で作った確認が足りていません。任せる量は、確認できる量までしか増やせません。 先に見張りを増やしてください。

怖くて任せられない

commitしてから渡してください。捨てられる状態なら、失敗は損になりません。

Windows の場合

until [ -f ... ] の待ち合わせは PowerShell だとこうです。

while (-not (Test-Path "out/model.glb")) { Start-Sleep -Seconds 10 }

考え方は同じで、成果物の有無で判定します。

次の一歩

30分で終わる仕事を1つ、条件を書いて任せて、席を外してください。

戻ってきて git diff と npm test を見る。この一往復を1回やると、任せられる範囲の感覚が掴めます。

1人に任せられるようになりました。次は担当を分けて、複数の持ち場を同時に回します！