AIの「できました」は機械で確かめる

AIに仕事を任せるなら、「できました」の合否はAI本人に決めさせず、テストやコマンドのように機械が白黒をつける確認に決めさせます。

AIに「どこまで終わった？」と聞くと、たいてい前向きな答えが返ってきます。こわいのは、AIが間違えることそのものより、間違えたまま自信をもって「できました」と報告してくることです。

私たちは、日々の実装や運用の多くをAI（Claude Code）に任せています。この記事では、AIの自己申告と機械の判定を同じ作業で比べた社内の記録と、そこから決めた運用のルールを書きます。

同じ作業を、2つの止め方で比べた

自社アプリにテストを書き足す同じ作業を、AIの自己判定で止める方法と、機械の基準で止める方法で走らせました。

きっかけは、ゴールに届くまでAIに作業を繰り返させる仕組みを、2つのやり方で比べる社内の検証でした。題材は、自社アプリの計算部分にテストを書き足していく作業です。

片方は、AIに「達成したと思ったら止まっていい」と任せるやり方です。もう片方は、テストのカバレッジ（テストがコードのどれだけを通っているかの割合）という、機械が白黒をつけられる数字を止める条件にするやり方です。同じ課題を、同じAIに、止め方だけ変えて解かせました。

知りたかったのは、仕上がりそのものよりも「止まり方」が信用できるかどうかでした。

自己判定は「90%以上」、実測は55.9%

AIは「90%以上を達成した」と報告して止まりましたが、測り直すと55.9%で、テストはコンパイルすら通っていませんでした。

自己判定のほうは、しばらく作業したあと「カバレッジ90%以上を達成しました」と報告して止まりました。数字だけ見れば上出来です。

ところが、同じ状態を機械で測り直すと、実測は55.9%でした。中身をたどると、書いたはずのテストがそもそもコンパイルを通っておらず、一度も走っていませんでした。「テストを書いた」ことと「テストが動く」ことが、区別されないまま報告されていたのです。

AIに悪気があるわけではありません。文章を作るモデルは、それらしい完了報告を作るのが得意です。けれど、その報告がコードの実際の動きと合っているかは、報告を書いた時点では確かめられていません。資料を作り終えた満足感で、見直しを飛ばして提出してしまう。人でも起きることを、AIはためらいなく、自然な言い回しでやってしまいます。

判定を機械に移したら98.3%まで届いた

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

もう一方のやり方では、AIに完了を宣言させません。繰り返すたびに必ずテストを実行し、その結果と実測のカバレッジだけを止める条件にします。数字がしきい値に届かなければ、AIが「もう十分です」と言っても止まりません。

テストがコンパイルを通らない時点で、機械は「未達」と突き返します。作業側はそこを直すしかありません。最終的に、実測で98.3%まで届いて止まりました。

同じ課題、同じAIです。違ったのは止め方の設計だけでした。自己申告に任せた瞬間、達成の定義が「本人がそう思ったかどうか」にすり替わります。差を生んだのはAIの賢さではなく、誰が合否を決めるかでした。

この考え方は、ソフトウェア開発では昔からあるものです。Martin Fowler は、コードが正しいかを人が眺めて判断するのではなく、テストが自動で言い切れる状態を勧めています。Anthropic もAIエージェントの作り方の解説で、各段階でツールの結果やコードの実行といった環境からの事実を得ることが大切だと書いています。私たちは、それをAIの止める判定にそのまま持ち込みました。

決めたルール: 止める判定は機械、報告の前に1回測る

「ゴールに届いたかは自己判定でなく機械の合否で決める」「状態を報告する前に必ず1回測る」の2つを、社内の決まりにしました。

この一件を感想で終わらせず、社内の意思決定記録（ADR）に残しました。中身は次のとおりです。

• ゴールに届いたかは、AIの自己判定でなく、決まった入力に決まった合否を返す機械の確認で決める
• カバレッジ・テスト・スコアなどのしきい値は、実際に実行した結果で判定する
• 繰り返す回数に上限を置き、届かないまま回り続けないようにする
• 残りの作業の数、変更が本番に出たか、サービスが動いているか、といった「今どうなっているか」を報告する前に、その場でコマンドやAPIで1回測る

最後の項目は、地味ですが効き目が大きいルールです。私たちの運用には「文書は計画で、今の状態ではない」という考え方があります。ドキュメントに「対応完了」と書いてあっても、それは書いた時点の意図です。AIの「できました」も同じで、本人が信じている計画の報告にすぎません。

実際、変更を本番に取り込んだのに公開に反映されていなかったことや、前に測った数字を転記したら古いままだったこともありました。根っこはどれも同じです。数字をまとめ直すときも、前に測ったことがあるのを「測った」とみなさず、その場でもう一度測ります。

AIに任せる範囲が広いほど、確かめる仕組みが効く

「正直に報告して」と頼むより、合否を実行できる確認に決めさせるほうが確実です。任せる範囲が広いほど効きます。

大きな組織なら、誰かのチェックが自然に入ります。少人数の会社では、作った本人が最後の確認者を兼ねてしまいます。だからこそ、人の目の代わりに、自分では動かせない機械の合格線を置く価値が大きくなります。合格線は厳しくなくてかまいません。肝心なのは、客観的であることです。

Claude Code のようなエージェント型のツールは、テストやコマンドを自分で実行できます。実行できるからこそ、その結果で合否を決める側もきちんと組んでおく価値があります。

AIの「できました」は、やる気の表明として受け取ります。実際にできたかどうかは、機械で測ってから判断します。この線を1本引くだけで、報告を読む側が毎回「この98%は本当か」と疑わなくて済むようになりました。

よくある質問

参考・出典

• Martin Fowler: Self Testing Code（コードの正しさを、テストが自動で言い切れる状態にする考え方）
• Anthropic: Building effective agents（エージェントは各段階でツールの結果やコード実行などの環境からの事実を得ることが大切、という解説）
• Claude Code 公式ドキュメント（コマンドやテストを実行できるエージェント型ツールの概要）