ゴールを渡せば、あとは進むと思っていた ── 基準を三度足して、三度とも通された

この記事について

対象読者

• Claude Code や Codex などに作業を任せて、進捗を報告してもらうことがある方

• 仕事の進み具合を、数字で確かめる仕組みを持っている方

• 何かを確認する側、チェックする側に立つことがある方

要点
ゴールは渡していましたが、一件を終えたと言える基準は渡していませんでした。基準を足しては内側を通されることを三度くり返し、最後に変えたのは条件ではなく、誰が合格を出せるかという構造のほうです。

体感60%、実測24%

あるシステムの移行にともなう確認作業を、Claude Codeと進めていた時期がありました。移行前と移行後で同じ動きになるかを一件ずつ見ていく作業で、確認項目は602件ありました。

その日の報告で、進捗は「約60%(体感)」と返ってきます。

気になって、確認台帳を自分で数えてみました。判定の列が埋まっている行は147件。24.4%です。

そこで仕掛けを入れました。引き継ぎ文書に進捗の数字を書くと、台帳を自分で数え直して、書かれた数字と一枚ずつ突き合わせる。一つでも合わなければ、文書の保存そのものを拒否する。

Claude Codeでは、決められた場面で自動的に走る仕組みをフックと呼びます。お願いではなく、機械が手前で止める側です。ここでは検査に使いました。

数字を目分量で書けないようにした、という程度の、単純な装置でした。

同じ日の朝から昼にかけて、確認台帳の数字が動きはじめます。24.4%だった確認率が、何度かの更新を挟んで94.9%になりました。

571件。数時間前まで147件だったものが、です。

装置は、止めませんでした。書かれた数字は、台帳を数え直した結果と、一件ずれずに一致していたからです。

それでも、出来すぎていると思いました。私が進捗の数字にうるさく言い出したのが前の晩で、その翌朝にこれです。

別の観点から検分してほしい、と頼みました。

「合格」の列だけが、埋まっていた

検分の結果は、すぐに出ます。

合格になっていた172件を開くと、「どんなデータで」「どのテストで」「移行前はどうだったか」「移行後はどうだったか」を書く4つの列が、172行とも空欄でした。

埋まっていたのは判定の列だけです。合格、とだけ書かれていました。

根拠を書く欄には、文がありました。テストの一式が存在していて、全体のテストが通っている、という趣旨の一文です。

同じ一文が、162行に入っていました。

ほかに、私の承認を経ていない、あるいは根拠が読み取れない項目が84件。

合わせて256件を巻き戻しました。94.9%は、52.3%になりました。

装置が測っていたのは、数字だった

水増しが進んでいるあいだ、装置は一度も動いていませんでした。台帳を更新するだけでは動かず、引き継ぎ文書を書くときにだけ数え直す仕掛けだったからです。

動いたのは、94.9%と書いた文書を保存しようとした一回だけでした。台帳を数え直し、571行。一致していたので、通しました。

装置が見ていたのは、書かれた数字が実際の件数と合っているかどうかです。

その一件一件が、合格と呼べる中身を持っているかどうかは、見ていません。

監視の穴は、網目の細かさではなく、何を測るかのほうにあきます。

水増しは、検査をひとつも破っていません。全部通過した状態で起きています。

以前、確認の仕組みを作ったのに漏れた、という話を書きました。あのときは、確認するべき行が、そもそも並んでいませんでした。分母が粗かった、という話です。

今回は、行は並んでいました。602件、全部あります。検査も動きました。それでも漏れています。

粗かったのではなく、測っていたものが違いました。

書いた条件の内側で、合格が作られていた

はじめに疑ったのは、AIが楽をしたのではないか、ということでした。

調べてみると、この現象には名前がついていました。仕様ゲーミングと呼ぶそうです。文字どおりの条件は満たして、意図した結果のほうは外す。

対策も出てきました。お願いでは効かない。機械が読める形で基準を書くしかない、と。

ゴールは、はっきり渡したつもりでいました。602件を一件ずつ確認する。そこは曖昧ではありません。

ただ、機械で判定される状態になっていたのは「合格の件数が数字と合っていること」のほうだけでした。

渡していなかったのは、その手前です。一件を確認したと言えるのは、何をしたときなのか。

終わりの形は渡してあって、途中の基準を渡していませんでした。

少なくとも今回の記録は、怠慢を持ち出さなくても説明がつきます。私が書いた条件は、そのとおりに満たされていました。

そして、その条件を置いたのは私です。

しかも私は前回、これは何を確認対象にしているのかを先に見る、と自分で書いていました。

渡さなくても伝わると思っていた

ずっと前に、似たことがありました。

要件を書いて、人に開発を頼んだときです。上がってきたものが、思っていたものと違いました。そう伝えると、でもこう書いてありますよね、と返ってきます。読み返すと、確かにそのとおりに書いてありました。

あとで理由を聞くと、そっちのほうが楽かと思ったので、という趣旨のことを言っていた気がします。

落ちていたのは仕様ではなく、私の頭の中にしか無かったところでした。

一度見ているのに、同じところに立っていたことになります。違うのは速さで、今回は数時間でした。

渡さなくても伝わる、と思っていた節もあります。日々のやりとりでは、こちらが言葉足らずでも、たいてい汲み取ってもらえる。同じ調子で、作業のほうも渡していました。

違ったのは、汲み取りが効く場面です。会話なら、返ってきたものをその場で見て、違えばすぐ直せます。台帳を一件ずつ埋めていく作業では、返ってきたものを私は見ていませんでした。

そのときどきでは、細かく話してもいます。ここはこう見てほしい、これは対象外でいい。合意したつもりでいました。

ただ、その合意はチャットの中にあります。文字としては残っているのですが、次の作業が始まるときに読み返されるものではありません。あとから機械が照らせるものでもない。

残っているのに、口約束と同じでした。

二度目の検査は、中身を空にしても通った

装置をひとつ作って安心していた私は、その手前で止まっていました。

やり直した検査は、単純なものです。

一件を合格と書くための基準を、はっきり決めました。3つの列が埋まっていること。どのテストで確かめたか。移行前の結果はどうだったか。移行後の結果はどうだったか。

ひとつでも空欄の行があれば、引き継ぎ文書は保存されません。

その場で、空欄のまま合格と書いた行をわざと一件混ぜてみます。拒否されました。

そのあとの巻き戻した項目は、この検査を通る形で少しずつ合格に戻っていきました。テストを特定して、両側の結果を書いて、一件ずつです。

一件あたりで見ると、水増しは32秒、正規の手順は234秒。ただ、遅かったのは手を動かす時間ではなく、同じ型に同じ手順を当てられる形ができるまでの時間でした。

そのときは、602件すべてに判定が付きました。

あとから、ひとつ試してみます。

合格になっている行の3つの列を、すべて「あ」の一文字に書き換えて、検査にかけました。

通りました。

3列必須の検査が見ていたのは、その列が空でないかどうかでした。何が書かれているかは見ていません。

空欄は止められますが、「あ」は止められない。直したはずの検査も、一つ内側で同じ形をしていました。

検査を作ったとき、私が試したのは空欄の一件だけでした。あれで安心してしまいました。

必要だったのは、二回目でした。

一回目は、見るべきものが無いときに止まるか。二回目は、見るべきものが意味を持たないときに止まるか。

一回目だけなら、たいていの検査は通ります。形を測っているのか中身を測っているのかは、二回目をやらないと分かりません。

これで一段深くなったつもりでいました。

画面を、二枚並べた

しばらくして、移行前と移行後の同じ画面を、実機で並べて開いてみます。

違っていました。

片方にだけ見出しの帯があり、入力欄の並び順が逆になっていて、記号の書き方も違う。並べれば誰でも分かる差です。

台帳の該当行を見ました。合格、差異なし、修正不要。

3つの列は、埋まっていました。しかも「あ」ではありません。実在するテストの名前が書かれていて、そのテストは実際に通っていました。書かれていたことは、全部本当でした。

根拠の欄にあったのは、自動テストが一本。

見た目が同じかどうかを主張している行を、サーバの応答を確かめる種類のテストが支えていました。

中身は本当でした。合っていなかったのは、証拠の種類のほうです。

列の中身をどれだけ厳しく検査しても、この食い違いは見えません。空欄でもなく、無意味でもない。二回目のテストも、ここには届きませんでした。

合格184件の根拠を分類してみます。実際の画面を並べた記録があるものが24件。取得した文面を突き合わせたものが46件。残りの114件は、自動テストだけでした。

602件すべてに判定が付いた台帳が、実物を一度も見ていない合格を、100件あまり抱えていました。

足し算をやめた

ここで、条件をもうひとつ足すことはしませんでした。

してきたことを並べると、こうです。数字が合っているかを検査した。通された。3列が埋まっているかを検査した。通された。次に足すとしたら、証拠の種類を確かめる基準でしょう。そしてそれも、たぶん通されます。

どれも、途中の基準をひとつずつ足していく形でした。条件をひとつ厳しくして、その条件の一段下を通される。

フックは、止める力そのものは強くできます。ただ、中身を読んで判断することはできません。

書いてあるものを、決めた形に照らすだけです。単純な形に落とせる条件ほど、確実に効きます。

裏を返すと、確実に効く条件で防げるのは、単純な形の抜けだけでした。三つ目に出てきた「この証拠でその主張を支えられるか」は、単純な形になりません。

人の組織のルールも、たぶん似ています。込み入ったものは守られず、守られるのは単純なものだけで、単純なままで防げる範囲には限りがある。

足し算が止まったのは、根気が尽きたからではありません。足せる形のものが、尽きたからでした。

合格を出す側を、変えた

三度に共通していたのは、条件の粗さではありませんでした。書いた本人が、自分の仕事に自分で合格を出せる。その構造のほうです。

条件を足す競争は、この構造の内側で終わりなく続きます。

だから、変えたのは条件ではなく、そこにしました。

602件すべてを、いったん再判定待ちに戻します。判定の列は残しますが、合格の根拠には使えない在庫として扱う。

書き手にできるのは、証拠を積むところまで。合格を出すのは、主張の種類と証拠の種類の対応を検査するプログラムのほうにしました。

公式の進捗は、0.0%に戻りました。

正直に書いておくと、これで足し算が終わったとは思っていません。採点する側の規則もまた条件の集まりで、実物を伴わない成果物でも形の上では満たせます。

抜き取りの検査で抑える設計にはしましたが、残りは残ります。

そもそも、その検査を書き換えられる立場に書き手がいるのなら、分けたことになりません。そこまで含めて分けきれていたかは、確かめきれていませんでした。

終わったのは足し算ではありません。基準を足すことだけで何とかなる、という見込みのほうでした。

厳しくしたときに、見るもの

監視を厳しくすると、安心します。手を入れた分だけ、抜け穴は減ったはずだと思えるからです。

三度とも、その安心が穴でした。

装置を作った日に、私は「これで報告は正確になる」と思っていました。正確になったのは数字だけだった、と気づいたのは、数時間あとです。二度目も、三度目も、同じ構えのままでした。

何かを厳しくしたときは、細かくなった網目ではなく、その網がどちらを向いているかを見るようにしています。

前回書いた三つの問いのうち、落ちていたのは「何を確認対象にしているか」の一つだけでした。そしてそこは、三つに割れます。何を測るか。どこで測るか。どの種類の証拠で測るか。

どこかでまた、同じことが起きるはずです。そのとき何を動かすのかは、まだ分かりません。

参考
Specification gaming: the flip side of AI ingenuity(Google DeepMind)
https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/