
ステップ3最大の罠は、ループが信頼を得る前に体数を増やすことだ。
第13回から第17回まで、あなたはループの起動方式、Claudeが別のClaudeを起動する構造、疑う役の組織化、自分で文脈を取りに行く仕組み、そしてコストの規律を見てきた。どれも、ステップ3を支える部品だ。
だが部品が揃っていることと、その部品を安心して使えることは別の話だ。罠の正体は機能の使い方の間違いではない。ループがまだ信頼を得ていないうちに、体数を増やしてしまうことにある。
信頼は、宣言して手に入るものではない。段階を踏んで積み上げるものだ。今回はその積み上げ方と、飛ばしたときに何が起きるかを扱う。この講座で最大の分量を占めるこの部の、最後の回になる。
罠の正体: 信頼を得る前に体数を増やす
この罠には、共通した型がある。
注意
ステップ3最大の罠
「もう何回も動いているから大丈夫」という感覚が、実際の検証に裏付けられているかを確かめないまま、体数だけを増やしていく。これがステップ3でいちばん起きやすい事故の型だ。
回数を重ねたことと、信頼できることは違う。同じ間違いを100回繰り返しても気づかれなければ、それは信頼の証ではなく、検証が機能していない証拠になる。
Cat Wuは、許可プロンプトについて重要な警告を残している(要旨)。人間が許可プロンプトのほぼすべてを承認するようになった状態では、そのプロンプト自体がもう意味を失っているという指摘だ。これは体数を増やす場面でも同じ形で起きる。「いつも問題ないから」と承認し続けている状態は、信頼しているのではなく、慣れているだけのことがある。慣れと信頼は、見た目が似ていても中身が違う。
信頼の錯覚と、本物の信頼
信頼に見えるものと、本物の信頼は違う。
- 何度も動いているから、たぶん大丈夫だと感じている
- 承認プロンプトをほぼ機械的に通している
- 失敗したときにどこで気づくかが決まっていない
- 何が起きたら失敗と判定するか、基準が明文化されている
- 検証ループが実際に機能していることを、独立した確認で示せる
- 失敗したときに、どこで・どう気づくかの仕組みがある
見分け方はひとつだけだ。「なぜ信頼できるのか」を、感覚ではなく仕組みで説明できるか。説明できないなら、それはまだ信頼ではなく、慣れによる楽観だと考えたほうがいい。
実際の利用データも、この見分け方を裏づけている。Anthropicが自社の利用データを計測した調査によると、セッション数50未満の新規ユーザーでは、確認をすべて自動で通すフルオート承認を使う人は約20パーセントにとどまる。これが750セッション以上を重ねた熟練ユーザーになると、40パーセントを超える。ここだけを見ると、慣れて承認が形骸化しているようにも読める。だが同じ調査では、作業を人間が途中で止める中断率も、新規ユーザーの約5パーセントから熟練ユーザーの約9パーセントへと、逆に上がっている。ただ慣れて機械的にYesを押しているだけなら、この数字は下がるはずだ。実際には逆に、任せる範囲を広げながら、介入する回数も増やしている。これが、本物の信頼が仕組みとして機能している状態の実例になる。
段階的に信頼をつくる手順
人材育成には、新人への権限委譲を段階的に進める考え方がある。最初は直接の監視下でしか任せられない業務も、経験を積むにつれて間接監視下、そして単独で任せられる段階に上がっていく。信頼は一足飛びに手渡すものではなく、確認された範囲だけ、少しずつ広げていくものだという発想だ。
ループの信頼づくりも同じ構造で組み立てられる。
この順番を守れば、体数を増やす頃にはすでに信頼の裏付けがある状態になっている。逆に、順番を飛ばして最初から大きな規模で回すと、失敗が起きたときにどこで何が壊れたのかを追えなくなる。
「let the model cook」の前提
「モデルに任せきる」が許されるのは、前提が整ってからだ。チームのテックリードであるSid Bidasariaは、あるところまで来たら任せきる姿勢についてこう表現している。
“We absolutely love deleting code. ...let the model cook.”
筆者訳コードを消すのが心底好きだ。……モデルに好きにやらせよう。
「モデルに好きにやらせる」という姿勢は、ステップ3の完成形として魅力的に見える。だが、この言葉だけを切り取って真似ると、順番を間違える。「let the model cook」が成立するのは、その前に段階的な信頼づくりが済んでいるチームだからだ。前提を飛ばして結論だけを輸入すると、罠にはまる。
任せきるといっても、安全策そのものを手放すわけではない。同じAnthropicの調査では、実際のツール呼び出しの80パーセントに何らかの安全策(権限確認や承認要件)が組み込まれ、73パーセントはhuman-in-the-loopの要素を含んでいる。取り消しの効かない不可逆な操作(顧客へのメール送信など)に関わるものは、全体のわずか0.8パーセントにとどまる。「let the model cook」が指しているのは、この0.8パーセントまで無防備にすることではない。残りの大半では手を放しつつ、消せない一部にだけ人の目を残す、という配分の話だ。
事故が起きるとどうなるか
実際に、順番を飛ばした現場で何が起きたか。
体数を先に増やした結果
ある業務改善プロジェクトで、1体のループが数日間問題なく動いたことを理由に、確認を挟まずに10体規模に拡大した。表面上は順調に見えたが、実際には自己検証の仕組みが1体分の設計のままで、10体分の相互作用は検証されていなかった。
数日後、複数のループが同じリソースに同時に書き込み、片方の変更がもう片方に上書きされる不具合が起きた。気づいたのは、被害が広がってからだった。
原因は機能の不具合ではなく、信頼の裏付けがないまま規模を拡大したという順番の誤りにあった。
よくある誤解と罠
- 回数で信頼を測る: 100回動いたことは、100回検証されたことと同じではない。検証の仕組みそのものを確認する
- 承認の習慣を信頼と混同する: ほぼ自動的に承認している状態は、慣れであって信頼ではない。承認の基準を言葉にできるかを定期的に確認する
- 成功事例の結論だけを輸入する: 「モデルに任せきる」という結論は、そこに至るまでの段階的な積み上げがあって初めて成立する。結論だけを真似ると前提が抜け落ちる
ステップ3卒業条件
次の段(ステップ4・意図で舵を取る段階)に進む前に、次のすべてに答えられる状態を目指す。
- ループが失敗したとき、どこで・どうやって気づくかを仕組みとして説明できる
- 体数を増やした判断が、回数の実績ではなく検証の裏付けに基づいていると言える
- 承認プロンプトをほぼ機械的に通している場面があれば、それに気づき、許可設計を見直せる
- 疑う役(敵対的検証)が、少なくとも重要な仕事について独立に機能している
- コストと規模を、感覚ではなく実際の数字で把握できている
このうちどれか1つでも自信を持って答えられないなら、まだ体数を増やす段階ではない。曖昧なまま進めると、次の段では被害の規模も大きくなる。
今日のまとめ
- ステップ3最大の罠は、ループが信頼を得る前に体数を増やすこと。回数と信頼は別物
- 信頼は宣言でなく、1件の確認・自己検証・小さなループ・疑う役・段階的な権限拡大を経て積み上がる
- 「モデルに任せきる」という結論は、その前提となる段階的な積み上げがあって初めて成立する
明日のアクション
今動かしている、または動かそうとしているループやエージェントを1つ選び、ステップ3卒業条件の5項目に照らして、答えられるものと答えられないものを仕分けてください。
答えられない項目があれば、それを埋めるまでは体数を増やさないと決めます。仕組みで説明できない信頼は、信頼ではなく楽観です。
次回、第19回からは第5部。意図で舵を取り、例外だけを監視するステップ4の風景に入ります。