作る役と確かめる役を分ける——AIの自走開発を安全に回す型

🪞自己採点は、かならず甘くなる

作った本人が合否を出すと、達成の判定が「感触」になります。

いちばん痛かったのは、テストの整備を任せたときです。返ってきた報告は「ほぼ目標まで到達しました」。それらしい数字も添えられていました。信じて先に進み、あとで実際にコマンドを走らせたら、テストがそもそもコンパイルすら通っていませんでした。到達どころか、動いていなかった。

これはAIが嘘をついたという話ではないと思っています。人間でも同じです。自分が書いたものを自分で評価すれば、書いた時の意図が判定に混ざる。「ここはこういう狙いだから、まあ通っているはず」と。判定を作業者から引き剥がさないと、この混入は消えません。

✂️型①: 確かめる役に、書き込み権限を渡さない

レビューする側が直せると、指摘が出る前に手が動いてしまいます。

いま私たちは、作る役（Maker）と確かめる役（Checker）を別のセッションに分けています。ポイントは分けること自体より、確かめる役にファイルを書き換える権限を与えていないことです。読むことしかできない。

なぜそうするか。同じ相手に「直しながら見て」と頼むと、指摘が言葉として残らないまま修正が入ります。すると何が問題だったのかが記録に残らず、同じ失敗をまた踏む。読むだけの役に固定すると、指摘がテキストとして残ります。それを持って作る役に戻る。遠回りに見えて、こちらのほうが早いという実感があります。

銀行や経理の世界では、起票する人と承認する人を分けるのが当たり前です。ここでやっているのは、その考え方をそのまま開発に持ってきただけです。

⚙️型②: 合否は、機械が判定する

「終わった」の判定を言葉から、コマンドの結果に移します。

自走を止める条件は、報告文ではなく実行結果で決めています。テストが通ったか。指定した数値の下限を満たしたか。それをコマンドで確かめて、成功したかどうかで進むか戻るかを決める。人もAIも判定に口を出せない形にします。

地味ですが、これがいちばん効きました。さきほどのテストの件も、機械で測る手順を挟んでいれば、報告を読んだ時点で「まだ通っていない」と分かったはずです。実際、いまは通らないまま次に進めません。

ついでに言うと、この考え方は開発以外にも効きます。私たちは記事や発信の下書きにも同じ発想の検査を入れていて、決まった条件を満たさない原稿は人のレビューに回る前に落ちます。

🛑型③: 試行の上限を先に決めておく

直らないものは、いつまでも回しても直りません。

作る→確かめる→直す、を繰り返す設計にすると、今度は止まらないループが生まれます。だから回数の上限を先に決めて、超えたら自動で人に返すようにしています。返ってきたときは、たいてい前提のどこかが間違っている合図です。

上限がないループは、コストだけ増えて何も終わりません。「粘れば直る」は、人が横で見ているときにだけ成り立つ話だと思っています。

🧭それでも人が握るところ

自走できる範囲は「引き返せるか」で決めています。

ここまでの型を入れても、公開や本番反映のような引き返しにくい操作は人の承認を残しています。作るところと確かめるところは自走できても、外に出す判断は別レイヤーの話です。この線引きについては別の記事で書いているので、興味があればそちらもどうぞ。

まとめます。作る役と確かめる役を分ける。確かめる役には書かせない。合否は機械に出させる。回数の上限を決めておく。この4つだけで、自走ループの事故はかなり減りました。

もし今、AIに任せた作業の「できました」をそのまま信じて進めているなら——まず一つだけ、機械で確かめる手順を挟んでみてください。おそらく最初の1回で、何かが見つかります。

📚参考・出典

本文の型は私たちが自社の開発運用で使っているものです。ここで触れた「役割を分ける」「権限を絞る」といった仕組みを実際に組むときの一次資料を挙げます。

• Anthropic: Best practices for Claude Code（エージェントに作業を任せる際の設計指針）
• Claude Code Docs: Create custom subagents（役割ごとに使えるツールを制限する方法）
• Claude Code Docs: Hooks reference（コマンドの実行前後に機械的な検査を挟む仕組み）