LLMが言う『95%確信』はなぜ信頼できないのか：AIコーディングツールの信頼度スコアを開発ワークフローに統合する
LLMの自己評価による信頼度は確率ではなく言語パターンに近いものです。コード生成でcalibrationが特に低い理由と、信頼度スコアを探索優先度としてのみ使用し、品質ゲートはCI/CD検証に任せるワークフローを説明します。
LLMが「このコードは95%安全です」と言うとき、その数字は確率的根拠ではなく、学習データから学習された言語的パターンに近いものです。特にコード生成ではモデルのcalibrationが大きく低下することが複数の研究で確認されています。したがって開発者はモデルの自己評価を意思決定の基準とせず、探索優先度を決めるシグナルとしてのみ活用し、実際の品質ゲートは静的解析・テスト・CI/CD自動検証に委ねるべきです。
LLMの「確信」はなぜ確率ではないのか
LLMが出力するconfidence scoreは、人が期待するような「正解である確率」ではありません。モデルは次のトークンを予測する際に内部的に様々な確率分布を計算しますが、ユーザーに提示される数字は通常、自然言語で表現された主観的な推定です。例えば「95%確信します」という文は、実際に100回中95回正解するという統計的保証ではなく、学習過程で似た文脈に登場した表現パターンにすぎません。
最近の研究は、LLMのcalibrationがモデル別・ドメイン別に大きく異なり、コード生成では特に低い傾向があることを示しています。モデルが高い確信を示したコード片でも、構文エラーやセキュリティ脆弱性が頻繁に発見されます。これはモデルがコードの意味を理解せず、単に確率的に尤もらしいトークン列を生成しているためです。
AIコーディングツールの「安全です」はなぜ危険なのか
実際の開発現場でAIコーディングアシスタントが「このコードは安全です」「この関数は例外を適切に処理します」と言っても、静的解析ツールがSQLインジェクションや境界条件の欠落をすぐに指摘するケースが多くあります。モデルの高い信頼度スコアは開発者に誤った安心感を与え、レビューをスキップさせてしまう可能性があります。逆に低いスコアでも必ずしも間違ったコードとは限らないため、スコア自体を品質ゲートとして使うと生産性を低下させるだけです。
最近の業界動向も独立した検証の重要性を強調しています。例えばSonarは2026年9月末にエージェンティックコードガバナンスと検証機能を自己管理型インフラ（SonarQube Server）まで拡張すると発表しました。これは企業がAI生成コードを人が逐一確認しなくても、静的解析とポリシーベースのゲートで管理しようとする流れを示しています。
信頼度スコアを探索優先度としてのみ使うワークフロー
開発者はLLMの自己評価を「探索優先度」としてのみ使用することが望ましいです。例えば1つのタスクに対して複数の候補コードを生成させ、モデルが付けたスコアが高い順に静的解析とユニットテストを実行する方式です。これによりスコアを意思決定の基準ではなく、限られた検証リソースをどこに最初に投入するかを決めるシグナルとして活用できます。
実質的な品質ゲートはCI/CDパイプラインの自動検証に委ねるべきです。最低限のゲートとしてコンパイル・lint・ユニットテスト・セキュリティスキャンがあり、コードをマージする前にこれらをすべて通過する必要があります。ここに人が最終レビューを行う段階を設けることで、モデルの過信によるリスクを大幅に減らすことができます。
calibration研究が示す示唆
calibrationとは、モデルが「90%確信する」と言った予測のうち実際に90%が正しいかどうかを示す指標です。多くのベンチマークでLLMのcalibrationは理想的な対角線から大きく外れており、特にコード生成のように構造的な正確性が重要なドメインでは誤差がさらに大きくなります。モデルが学習したコードデータの分布と実際のプロジェクトのコードスタイル・依存関係・ビジネスロジックが異なると、calibrationはさらに悪化します。
MITとSakana AIが最近公開したSIFTフレームワークは、自己改善型コーディングエージェントの評価コストをLLM judgeで削減するアプローチを取っています。これは候補の変更を迅速にフィルタリングするのに有用ですが、LLM judgeも完璧ではないため、最終検証を実際のテスト実行で代替することはできません。結局、信頼度スコアとLLM judgeはどちらも「探索コストの削減」には役立ちますが、「品質保証」の根拠としては不十分です。
結論：信頼はモデルではなくパイプラインから生まれる
バイブコーディングが普及するほど、「モデルが言う確信」を鵜呑みにするミスはより危険になります。LLMの自己評価はcalibrationされていない主観的な推定であるため、開発者はこれを意思決定の基準ではなく探索優先度のシグナルとしてのみ扱うべきです。実際の品質ゲートは静的解析、テスト、CI/CD自動検証が担い、人はモデルの推論と変更履歴を透明にレビューできる必要があります。
こうした文脈でmd-logは、AIが作成した作業・分析を人がWeb・スマートフォン・タブレットで快適にレビューし、保存するたびに不変バージョンとして蓄積してコラボレーション履歴を残すヒューマン・イン・ザ・ループのレビュー・アーカイブレイヤーとして有用です。結局「95%確信」という言葉はモデルの言語的表現にすぎず、本当の信頼はパイプラインの検証ゲートから生まれます。
参考資料
- 国民日報
- OpenAIがGPT-6世代の中間グレードモデルSolをGPT-6.1 Sol ...
- MIT's SIFT cuts coding agent eval costs - venturebeat.com
- Freelander 8 adds valet parking and LLM voice assistant - Automotive World
- Sonar Extends Agentic Code Governance and Verification to Self-Managed Infrastructure - PR Newswire
- How Self-Calibration Makes Quantitative LIBS Possible on Drones - Spectroscopy Online
- LUBIS EDA Launches FormalOS: Infrastructure for Systematic, Scalable Formal Verification - markets.businessinsider.com
- Linux Kernel Drops AI Tag Requirement, Uses Meta AI For Code Reviews - Hackaday
よくある質問
- LLMが言う「95%確信」は実際の精度とどれくらい差がありますか？
- モデルとドメインによって異なりますが、コード生成ではcalibrationが特に低く、95%と言っても実際にはそれよりはるかに低い精度を示すことが多いです。これは確信スコアが確率的根拠ではなく言語的パターンから来るためです。
- AIコーディングツールの信頼度スコアを完全に無視すべきですか？
- 無視するよりも、探索優先度を決めるシグナルとしてのみ活用するのが望ましいです。スコアが高い候補から静的解析とテストを実行する形で、検証リソースを効率的に配分できます。
- コードをマージする前にどのような最低限のゲートを設けるべきですか？
- コンパイル、lint、ユニットテスト、セキュリティスキャンをCI/CDパイプラインで自動実行し、すべて通過したコードのみをマージするように設定します。ここに人の最終レビュー段階を追加するとより安全です。
- LLMのcalibrationがなぜコード生成で特に低いのですか？
- コードは文法構造と意味が厳格で、学習データにないプロジェクト固有の依存関係・スタイル・ビジネスロジックを反映する必要があるためです。モデルが学習した一般的なコードパターンと実際の要件が乖離するほど、確信と精度のずれが大きくなります。
- 最近のツールや研究の中で信頼度問題を緩和する事例はありますか？
- Sonarはエージェンティックコードガバナンスを自己管理型インフラへ拡張し、MITとSakana AIはSIFTでコーディングエージェントの評価コストを下げるアプローチを発表しました。ただしこれらは検証効率を高めるものであり、モデルの自己確信が正確になるという意味ではありません。