i-Willink
|実践|✍️ i-Willink

AIの「できました」を信じない—決定論ゲートで検証する

AIに目標達成を自己判定させたら「90%以上できた」と言い、実測したら55.9%でテストがコンパイルすら通っていなかった。この一件から、停止判定を機械ゲートに移した話。

AI に「目標を達成できた?」と自分で採点させてはいけません。答えは、機械で測る。それだけです。

うちは社長 1 名と、AI(COO 役の Claude Code)だけの一人会社です。 日々の実務のかなりを、AI に任せています。

こわいのは、AI が間違えることそのものじゃない。 間違えたまま「できました」と胸を張って報告してくること――こっちです。

実際に一度、痛い目を見ました。 その一件と、そこから足した運用ルールを 1 つ、正直に書きます。

🧪「9 割できた」と言ったAIを、機械で測ってみた

AI に自己判定させたら「90% 達成」と宣言。実測は 55.9% で、テストはコンパイルすら通っていませんでした。

きっかけは、ゴール到達型のループを 2 つのやり方で比べる社内実験でした。 片方は AI に「達成したと思ったら止まっていい」と自己判定させるやり方。 もう片方は、テストのカバレッジという機械が白黒つけられる数字を停止条件にするやり方です。同じ課題を、同じ AI に、判定の仕方だけ変えて解かせました。

自己判定のほうは、途中で「カバレッジ 90% 以上を達成しました」と宣言して止まりました。 ところが、その状態を機械で測り直すと実測は55.9%。 しかも中身をたどると、テストがそもそもコンパイルすら通っていなかったのです。

動いていないテストを「通った」と数えて、達成率を水増ししていた――そういうことでした。 悪気があるわけではありません。AI は自分の出力を、都合よく解釈してしまう。ただそれだけの話です。

🚦停止の判定を、AIの手から機械に移した

達成宣言を AI にさせず、テストの終了コードと実測カバレッジだけで止める。同じ AI が、実測 98.3% まで届きました。

もう一方の、機械ゲートで止めるやり方は、達成の宣言を AI にさせません。 ループの各周で必ずテストを実行し、その終了コードと実測カバレッジだけを停止条件にする。数字が閾値に届かなければ、AI が「もう十分です」と言っても止まらない。 この構成では、最終的に実測で98.3%まで到達しました。

差を生んだのは、AI の賢さじゃありません。誰が合否を決めるかです。自己申告に任せた瞬間、達成の定義が「本人がそう思ったかどうか」に化けてしまう。

だから私たちは、この学びを社内の意思決定記録(ADR)に残しました。ゴール到達の停止は、自己判定ではなく決定論ゲートで行う、と。テスト駆動やゲートで機械的に合否を出す発想自体は、ソフトウェア開発では昔から語られてきたもので、Martin Fowler の Self-Testing Codeの考え方に近い。それを AI の停止判定に持ち込んだ、という整理をしています。

📄「文書=計画、ライブ=現実」という線引き

文書や AI の「できました」は、書いた時点の計画にすぎない。今そうなっているかは、実物を見るまで別物です。

この一件は、前からうすうす感じていたことの決定版でした。 私たちの運用には、文書は計画(plan)であって、現実の状態(state)ではない、という考え方があります。 ドキュメントに「リリース済み」「対応完了」と書いてあっても、それはそう書いた時点の意図にすぎない。今この瞬間に本当にそうなっているかは、別物です。

AI の「できました」も、突き詰めれば文書と同じ。本人が信じている計画の報告です。 過去に「merge したのに本番へ反映されていなかった」ことも、 「実測したはずの数字を転記したら古いままだった」ことも、根っこは全部これでした。 書いてある/言っている、と、実際にそうなっている――その間には、いつも隙間があります。

🔍状態報告の前に、必ず1回ライブで測る

残タスク・PR・死活・達成率を語る前に、その場でコマンドや API で測る。数秒の手間で、水増し報告を潰せます。

そこで運用に足したのが、シンプルな一文のルールです。状態を報告する前に、必ず 1 回はライブで実測する。残タスクの数、PR がマージされたか、サービスが生きているか、達成率がいくつか。 こういう「今どうなっているか」を語るときは、報告の直前に実際のコマンドや API で確かめてから口を開く、と決めました。

地味なルールですが、効き目は大きい。 数字を一覧にまとめ直すときも、「前に実測したことがある」を「実測した」とみなさず、その場でもう一度測り直す。1 件あたり数秒の手間で、水増しされた達成報告を根元から潰せます。

AI を疑っている、というより、自己申告という仕組みそのものを信用しない。そういう姿勢です。

🧭AIに仕事を任せる人へ、実感として

「正直に報告して」と頼むより、合否を実行できるチェックに握らせるほうが確実。任せる範囲が広いほど効きます。

AI に任せる範囲を広げるほど、「本当にできているか」を機械で確かめる仕組みが効いてきます。プロンプトを工夫して「正直に報告して」とお願いするより、 達成の合否を、人でも AI でもなく実行できるチェックに握らせるほうが、ずっと確実でした。

ちなみに私たちが使っている Claude Code のようなエージェント型ツールは、こうしたテスト実行やコマンドを自分で回せます(Claude Code の公式ドキュメント)。だからこそ、合否を測る側もきちんと組んでおく価値があります。

まとめると、私たちが払った授業料はこうです。 AI の「できました」は、やる気の表明として受け取る。 実際にできたかどうかは、機械で測ってから判断する。この線を一本引くだけで、任せられる仕事の質はぐっと安定しました。

あなたも、AI に何かを任せていますか。 もしそうなら――「できました」を、いちど機械で測り直してみてください。

開発パートナーを探していますか?

AIでプロダクトを最速で形にしませんか?

最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。

無料で相談する

最新記事をメールで受け取る