AI を活用した分析ツールには、あまり語られない失敗モードがあり、私たちはそれに直に遭遇しました。
同じリポジトリを2回提出する――同じコミット、同じ入力、同じすべて――のであれば、同じスコアが得られるはずです。実行のたびにスコアが変わるなら、それは監査（audit）ではありません。単なるランダムサンプルです。
テストの初期段階で、同一の入力に対して連続実行した場合にスコアのばらつきが発生することを観測しました。小さなばらつきではありません。意味のある変動です――コードベースのリスク解釈を、完全に変えてしまうほどに。ある実行では1つのカテゴリに収まっていたスコアが、次の実行では別のカテゴリに移るのは、それを最も必要とする人々にとっては役に立たないどころか悪い状態です。たとえば、投資家向け資料を準備する創業者、監査エビデンスを構築するコンプライアンス担当、リメディエーション（是正措置）の判断を行う CTO です。
これは LLM ベース分析における構造的な問題であり、実装上のバグではありません。そして構造的な原因があります。
ばらつきが生まれる理由
大規模言語モデル（LLM）はデフォルトで確率的（probabilistic）です。出力を生成する際、確率分布からサンプリングします。「temperature」設定は、導入されるランダムさの度合いを制御します。temperature が高いほど、より創造的で、より多様な出力になります。temperature が低いほど、より一貫性があり、より決定論的な出力になります。
文章作成、アイデア出し、ブレインストーミングのような創造的なタスクでは temperature は機能です。セキュリティ分析、コンプライアンスの対応付け、アーキテクチャ評価では temperature は負債になります。
temperature が 0 以外の値で動作する LLM は、同じコードに対して連続実行すると、わずかに異なる検出結果を生成します。異なる検出結果はスコアリングモデルに渡されます。結果として、異なるスコアが出ます。同じコードベースが、コードについて何も変わっていないにもかかわらず、月曜日に見たものとは火曜日には別の姿に見えてしまうのです。
修正内容と必要なもの
temperature を 0 に設定すると、サンプリングによるランダムさがなくなります。同じ入力なら、モデルは同じ出力を生成します。ここが出発点です。
ただし、temperature 単体では解決できない第2の層のばらつきがあります。それは「信頼度（confidence）による重み付け（finding confidence weighting）」の部分です。複数の独立したモデルが同じコードを分析すると、境界的なケースでは異なる結論に至る可能性があります。これらの相違がどのように解決されるかが最終スコアを左右します。そして、その解決が一貫しないなら、ばらつきは別の入口から再び戻ってきます。
IntentGuard は、検出ごとに最大4つの独立した AI モデルを使ってコンセンサス（合意）パイプラインを用います。スコアリングモデルを決定論的にするには、コンセンサスロジック自体も決定論的である必要があります。同じモデル投票の集合が、常に同じ信頼度付きの結果を生み出さなければなりません。
私たちは、基盤として CVSS v3.1 から導出した重大度スコアリングを使用します。CVSS は、この目的のために特別に設計された業界標準です。つまり、再現可能で定量化可能なリスクスコアであり、同じ証拠が与えられた2人のアナリストが、同じやり方で同じ値を計算できるものです。LLM が生成した検出結果を CVSS 由来のスコアにマッピングすることで、スコアリングモデルに決定論的なアンカー（基準点）が与えられます。同じ証拠なら、毎回同じ推論（deduction）になります。
重要性がユーザーによってどれだけ異なるか
素早いチェックを実行する開発者にとっては、スコアの一貫性はあると便利（nice-to-have）です。しかし、IntentGuard が作られているユースケースでは、これは譲れません。ポートフォリオ企業に対して技術的デューデリジェンスを行う VC は、目にするスコアが「その特定の実行でたまたまそのようになったコードの状態」ではなく、「コードベースの実際の状態を反映している」ことを知る必要があります。監査エビデンスを構築するコンプライアンス担当には、再現可能で、説明可能（defensible）な検出結果が必要です。投資家向け資料を準備する創業者は、昨日とは別の読み方になり得る「テクニカル・レディネス・スコア」を提示するわけにはいきません。
決定論的なスコアリングが、分析ツールを「魔法の8ボール」から切り離します。
今パスしているテスト
私たちが自分たちに課したゲートはシンプルでした。同じリポジトリを、同一の入力で連続して3回提出し、3回すべてでスコアが同一であることを確認する。
そのゲートは今、通過しています。368 件の自動テスト――決定論性のチェックを含む――がすべてグリーンです。
ヨハネスブルグから公開して IntentGuard を構築しました。マルチモデルの AI パイプラインにおける決定論的な分析について考えたことがあるなら――アプローチに賛同しているか、ギャップが見えているかにかかわらず――ぜひコメントで聞かせてください。
ここで語られているコンセプトは私自身のものです。この投稿のプレゼンテーションおよび体裁の整形は、AI テキストエディタによって強化されています。
Olebeng · Founder, IntentGuard · intentguard.dev
