AIの運用i-Willink
作る役と確かめる役を分ける——AIの自走の型
AIに作業を任せて自走させると、作った本人が合否を決めるところで崩れます。確かめる役を別の場に分けて書き換えをさせず、合否は機械に出させ、回数の上限を先に決める。私たちが失敗から直した4つの型をまとめます。
AIに作業を任せて回すなら、作る役と確かめる役を別の場に分け、確かめる役には書き換えをさせず、合否は機械に出させます。
AIに作業をまとめて任せ、作る・確かめる・直すを自分で回させる。いわゆる自走です。これが崩れる場所は、たいていAIの能力ではありません。作った本人に「終わったかどうか」を決めさせているところです。
私たちは、自社のアプリ開発も公開しているOSSの改善も、AI（Claude Code）が手を動かして進めています。この記事では、何度かやり直したあとに落ち着いた、今の型を4つ書きます。
この記事の要点
- 1作った本人（同じ会話のAI）に確かめさせると、粗探しでなく「正しい理由」の説明に働く
- 2確かめる役は別の場に立て、ファイルを書き換える権限を渡さない。指摘が文字として残る
- 3合否はコマンドの結果で決め、繰り返す回数の上限を先に決める。公開のような引き返せない操作は人が握る
作った本人に確かめさせると、甘くなる
実装した直後のAIは「この方針は正しい」という前提を持ったままなので、確かめても間違いを探すより正当化に働きます。
AIに書かせたものを、同じ会話のままAIに「これでいい？」と聞くと、ほとんど「いいですね」と返ってきます。直前に自分が下した判断を肯定する方向に読むからです。人が書いた直後の文章の誤字を見落とすのと同じですが、AIは聞けば「なぜこれで正しいか」をすらすらと説明できてしまうぶん、甘さが見えにくくなります。
同じ会話の中で「作る→自分で確かめる→直す→また自分で確かめる」と回すと、説明が少しずつ現実からずれていきます。最初の「まだ確かめていない」が、いつのまにか「確かめた」にすり替わる。私たちはこれを一度ならず経験しました。
いちばん痛かったのは、テストの整備を任せたときです。報告は「ほぼ目標まで届いた」でしたが、実際に測るとテストはコンパイルも通っていませんでした。この比較の数字はAIの「できました」は機械で確かめるに書いています。
型1: 確かめる役を別の場に立てる
作るのはメインの会話、確かめるのは別に立てた役（サブエージェント）にして、差分と成果物だけを前提なしに読ませます。
私たちは、作る役（Maker）と確かめる役（Checker）を別に立てています。作るのはメインの会話で進め、確かめるのは独立した別の役で走らせます。Claude Code では、役ごとに指示と使える道具を決めたサブエージェントを作れます。
別にする理由は、前提を共有しないためです。同じ会話のまま続けると、作っている間の大量のやり取りが、確かめる側の判断にも流れ込みます。別の場で差分と成果物だけを渡すと、作る役が「当然わかるだろう」と飛ばしたところが、そのまま疑問として浮かびます。
確かめる役には、作る役の「テストを書きました、通りました」という報告をそのまま信じさせません。確かめる役が自分で実行し、結果を見て判断します。
型2: 確かめる役に書き換えをさせない
確かめる役には読むことしかさせません。指摘は出せても自分では直せず、直すのは作る役の仕事に戻します。
役を分けたうえで、もう一段こだわっているのが、確かめる役にファイルを書き換える道具を持たせないことです。私たちの社内には、成果物を評価するためだけの、読み取り専用のレビュー用コマンドがあります。書き込みも編集もできません。
回りくどく見えますが理由があります。確かめる役がその場で直せると、指摘と修正が一体になり、「何が問題だったか」が記録に残らないまま書き換わります。しかも直した瞬間に、確かめる役は「自分が直したもの」を自分で確かめる立場になり、最初に避けたかった状態に戻ってしまいます。
読むだけの役に固定すると、指摘が文字として残ります。それを持って作る役に戻る。遠回りに見えて、こちらのほうが結局早いと感じています。お金を扱う仕事で、起票する人と承認する人を分けるのと同じ考え方です。
道具を選ぶときも、名前の段階で分けておきます。レビューの道具の中には、指摘と同時に手元のファイルまで直せるものもあります。便利ですが、確かめる段では「直せる」道具は使いません。
型3: 合否は機械に出させる
「終わった」の判定を報告の言葉から、コマンドの結果に移します。テストが通ったか、決めた数値の下限を満たしたかで進むか戻るかを決めます。
自走を止める条件は、報告文ではなく実行結果で決めています。テストが通ったか。決めた数値の下限を満たしたか。それをコマンドで確かめ、成功したかどうかで進むか戻るかを決めます。人もAIも、判定に口を出せない形です。
Claude Code には、操作の前後に決まったコマンドを挟む仕組み（フック）があります。たとえば作業を終える前に検査を走らせ、通らなければ先へ進ませない、という形を作れます。
この考え方は開発以外にも効きます。私たちは記事の下書きにも同じ発想の検査を入れていて、出典のない数字や長すぎる題のように決まった条件を満たさない原稿は、人のレビューに回る前に落ちます。
型4: 繰り返す回数の上限を先に決める
作る・確かめる・直すを繰り返す設計には、回数の上限を先に置き、超えたら人に返します。
作る・確かめる・直すを繰り返す設計にすると、今度は止まらない繰り返しが生まれます。だから回数の上限を先に決めて、超えたら人に返すようにしています。返ってきたときは、たいてい前提のどこかが間違っている合図です。
上限がない繰り返しは、利用料だけ増えて何も終わりません。「粘れば直る」は、人が横で見ているときにしか成り立たないと考えています。
それでも人が握るところ
作るところと確かめるところは自走させても、公開や本番への反映のような引き返しにくい操作は、人の承認を残します。
ここまでの型を入れても、外に出す判断は別の話です。私たちは、元に戻せるか・外に届くか・お金や法律が絡むか、で人の承認が要るかを決めています。この線引きは元に戻せるかで決める承認の記事に書いています。
まとめると、作る役と確かめる役を分ける。確かめる役には書き換えさせない。合否は機械に出させる。回数の上限を決めておく。この4つで、自走で起きる手戻りはかなり減りました。AIに任せた作業の「できました」をそのまま信じて進めているなら、まず1つだけ、機械で確かめる手順を挟んでみてください。
よくある質問
同じAIに「厳しくレビューして」と頼めば十分ではありませんか？
同じ会話のままだと、作ったときの前提が判断に混ざるので、指示だけでは甘さが残ります。別の場で、差分と成果物だけを渡して確かめさせるほうが、見落としを拾えます。
確かめる役に直す権限があったほうが早くありませんか？
その場では早く見えますが、何が問題だったかが記録に残らず、同じ失敗を繰り返しやすくなります。確かめる役が直したものを自分で確かめる形にもなってしまうので、私たちは読むだけにしています。
小さな会社でも役を分ける必要がありますか？
少人数ほど必要です。あとで誰かが全部を見直す余裕がないので、AIの自己採点をそのまま通すと、間違いが外に出るまで気づけません。役を分けるのは設定の問題なので、人を増やさずにできます。
繰り返す回数の上限は何回がよいですか？
作業の大きさによります。決まった回数は示しませんが、上限を超えたら人に返し、前提を見直すきっかけにすることが大切です。上限が無いと、利用料だけが増えて終わらないことがあります。
参考・出典
- Anthropic: Best practices for Claude Code（エージェントに作業を任せるときの設計の考え方）
- Claude Code Docs: Create custom subagents（役ごとに指示と使える道具を決める方法）
- Claude Code Docs: Hooks reference（操作の前後に決まった検査を挟む仕組み）