————.——.—— ——:—— — TOKYO
← Insights 一覧へ戻る
2026.09.25

AIが書いたコード、誰がチェックしていますか — 「確認しました」を鵜呑みにしてはいけない理由

技術リーダー視点クロスボーダー

アプリの開発をAIに任せる会社が増えた。AIは作業の最後に「テストも通りました」「確認しました」と報告してくる。ではその確認は、誰がしたのか。確認の仕組みを別に用意していなければ、答えは「作ったAI自身」になる。本稿は、作ったAIとは別のAIに検証させる体制で開発している当社の自社アプリで、「完了」とされていた機能にリリース前どんな問題が隠れていたか、そして2026年9月の開発中の修正がどれだけ差し戻されたかを示す。そのうえで、研究とAI開発元自身の推奨、日韓の公的機関の注意喚起と世界規模の業界調査を確認し、エンジニアのいない会社が明日からできる3つのことを整理する。シリーズ「AIに開発を任せる」の第1回。

アプリの開発を、AIに任せる会社が増えた。指示を出せば、AIがコードを書き、最後にこう報告してくる。

「修正しました。テストもすべて通っています」

では、その「確認」は誰がしたのか。確認の仕組みを別に用意していなければ、答えは「コードを書いたAI自身」になる。人間の組織なら、書いた本人が自分の書いたものをレビューして「問題なし」と言っている状態だ。

以下、数値と記述は一次資料および当社の開発記録から確認したものである。そこから先の読みは AISolve 編集部の解釈である。

当社の自社アプリで起きていたこと

当社は韓国語学習アプリ「くみたてハングル」を、コードを書くAI（実装役）と、それを検証するAI（検証役）を分けて開発している。検証役は別の会話で起動され、コードを書き換えないというルールで動き、指摘だけを書く。方針や優先順位など重要な判断は人（当社の担当者）が行う。

リリース前の開発期間に、「完了」「確認済み」とされていた機能が、実際には動いていなかった例がある。見つけた・確かめたのは、報告したAIとは別のAIが、報告をコミット済みのコードと照合した段階だった。いずれもリリース前に修正している。

それまでの報告・記録別のAIがコードと照合して分かったこと
完了画面以前の確認記録では、学習モジュールの完了を確認済み完了画面は、実際の進み具合と関係なく、すべての項目に「完了✓」を出す作りだった
手書きの採点動作確認を担当したAIの報告は「手書きをAIが採点して★3つ」採点は仮の作りのままで、誰が書いても70〜90点のそれらしい点数を返していた（その後、画数や書き順などで採点する作りに改めた）

リリース後も、この仕組みは続けている。2026年9月1日〜24日の開発中の修正（アプリ本体と開発運用スクリプト）で、監査の判定を記録で確認できたもののうち、4割近くを初回の監査で差し戻した。9月以降の修正はまだ本番に出しておらず、すべて利用者に届く前の段階で止めたものである。

〈差し戻し理由には、コードの不具合のほか、「報告の内容が実際のコードと違う」「必要なテストや動作確認が済んでいない」も含まれる。実装役が「動作確認はまだ」と自ら書いていた例もあり、すべてが完了を偽ったわけではない。それでも、報告だけで先に進めていたら、不具合や確認の抜けを含んだまま通ってしまうものがあったことになる〉

報告したAIが嘘をついているわけではない。自分が想定した範囲では正しく確認している。問題は、想定していない範囲を、想定した本人が見つけることはできないということだ。

なぜ、作ったAIは自分の誤りを見つけられないのか

これは当社に固有の話ではない。AI開発ツールの提供元である Anthropic は、Claude Code の公式ガイドで、別のAIに結果を反証させ、作業をしたエージェントが自分で採点する立場にならないようにすることを勧めている。別の会話で起動したAIは、直前に自分が書いたコードに引きずられないからだ。同じ文書は、AIは「作業が終わったように見えた時点で止まる」とも書いている。

資料示していること
Huang ほか（Google DeepMind など）論文（ICLR 2024）外部からのフィードバックなしにAIが自分の回答を見直しても推論は改善せず、悪化する場合もある
米 METR ランダム化比較試験（2025年7月）経験豊富な開発者16人が、AIで「約20%速くなった」と感じていたが、実測ではむしろ時間がかかっていた

〈論文は推論課題（コードではない）・2023年時点のモデルでの結果。METR は2026年2月の続報で新しいツールでは速くなる兆候を示しており（大きさは弱い証拠と明記）、ここで使うのは「専門家でも体感では正しく見積もれなかった」点だけである〉

エンジニアが体感で判断できないものを、エンジニアでない経営者が「AIがそう言っているから」で判断するのは、なおさら危うい。

日韓の公的機関と、世界の業界調査

国・範囲資料要旨
🇯🇵 日本IPA「情報セキュリティ10大脅威 2026」組織編「AIの利用をめぐるサイバーリスク」が3位。コラムでAIが生成したコードに脆弱性が含まれる場合があることに触れ、AIへの過剰な依存への留意を求める
🇰🇷 韓国SPRi「SW개발자 채용 변화 전망과 생성형 AI」AIが生成したコードの検証が重要になり、開発者の役割はコード品質管理中心に移りつつある
🇰🇷 韓国KISA「생성형 AI 사용 관련 주의 보안권고」AIの出力は事実確認を必ず行い、AIが生成したコードは実行前にセキュリティ点検するよう勧告
🌐 世界Google Cloud（DORA）「2025 DORA Report」技術者約5,000人の調査。AIが生成したコードを「ほとんど／まったく信頼していない」が30%

〈日韓の資料は定性的な注意喚起で、誤り率の数値は持たない。DORA は民間の業界調査で、数値は相関である〉 〈編集部の見解〉温度差はあっても方向は同じで、書く作業がAIに移るほど、確かめる作業の比重が上がる。

明日からできる3つのこと

〈前出の公式ガイドの推奨を、非エンジニア向けに編集部が整理したもの〉

  1. 「確認しました」ではなく、証拠を出させる。 テストの実行結果、画面のスクリーンショット、実行したコマンドと出力。中身が読めなくても、証拠のない「完了」は完了として扱わないと決めるだけで報告の質が変わる
  2. 確認は、別の会話で頼む。 新しい会話を開き、作った経緯を見せずに「この変更に問題がないか調べて」と頼む。経緯を知らない相手は、思い込みを共有していない
  3. 確認役には直させない。 確認役が直し始めると、今度はそのAIが「作った本人」になる。確認役は指摘を書くだけにし、何を直し何を見送るかの重要な判断は、人が最後に決める

ひとつだけ注意がある。確認役に「問題を探して」と頼むと、問題がなくても何かしら見つけてくる。指摘を全部追うと作り込みすぎにつながるため、「正しく動くか、頼んだ要件を満たしているかに関わる問題だけ」と範囲を絞って頼むとよい。

それでも残る問題

確認役を分けても、すべては片付かない。当社でも、監査で合格した後に実際に画面を動かして初めて見つかった表示崩れがあった（これも本番に出す前に直している）。一つのAIに長く任せ続けると、別の形で体制が崩れていく。次回は、当社が自社アプリをAIのチームで作る中で実際に起きた「崩れ方」を書く。

まとめ

  • 確認の仕組みがなければ、AIの「確認しました」は作ったAI自身の確認である
  • 当社でも、「完了」とされていた機能に、すべてに「完了✓」を出す、誰にでも同じような点数を返すといった問題が隠れていた。別のAIがコードと照合して、リリース前に止めた
  • 2026年9月1日〜24日の開発中の修正では、4割近くを初回の監査で差し戻した。いずれも利用者に届く前の段階である
  • AI開発ツールの提供元自身が「別のAIに検証させる」ことを勧めている
  • 明日からできるのは、①証拠を出させる ②別の会話で確認させる ③確認役に直させない

AISolve は、AIに開発を任せている会社の「確かめる仕組み」づくりを支援しています。

→ お問い合わせ

→ AX / DX 簡易診断

本稿が依拠した資料