前回、「評価スコアをLLMに出させない設計」という記事を書きました。スコア算出から生成AIを排除し、境界値をどちらに倒すかまで仕様に書き切る——いわゆる決定論的な設計の話です。

今回はその続きです。スコアを決定論にした。だが、それだけでは足りなかった、という話をします。

スコアが決定論でも、所見が勘なら片肺

診断レポートには、スコアの他に人間が書く「所見」が載ります。専門家として、数字の背景や優先施策への補足を書く部分です。

ここで私は立ち止まりました。同じスコアに対して、書き手の気分や記憶で違うコメントが付くなら、成果物全体の再現性は担保されない。 監査の場で「なぜこの指摘なのか」と聞かれて、「経験上そう感じたからです」では答えになりません。

スコア算出だけ厳密にして満足するのは、片肺です。読み手が受け取るのはレポート全体であって、算出エンジンの内部ではないからです。

人間側に置いた規律——レビュー観点チェックリスト

そこで私は、専門家レビューを書くときのチェックリストを運営標準として定義しました。

見る単位は、ITGC 5領域 × 3観点です。

5領域＝アクセス管理／資産管理／変更管理／運用管理／統制環境。それぞれに対して：

(a) スコアが実務感と乖離した領域はないか——あれば「数字の背景」として1行注記する
(b) 最優先の2〜3施策に、その会社の規模・フェーズ固有の補足を付ける——一般論を個別に翻訳する1文ずつ
(c) 監査対話で最初に聞かれそうな点を1〜2点、予告する

これに加えて、文体の規律を2つ置いています。

1つ目：合否語を使わない。 「不足」ではなく「引き上げ対象」と書く。製品側のラベルもこの語で統一しています。

2つ目：全コメントは設問番号に遡れる形で書く。根拠なきコメント禁止。 これが本記事の芯です。

「設問番号に遡れる」が効く理由

読み手（監査法人や経営）が「なぜこの指摘か」と聞いたとき、「Q7とQ18の回答がこうだったから」と答えられる。指摘の根拠が、診断の入力データまで一本の線で辿れる状態です。

具体的には、こう変わります。

書けないコメント：「ログ管理が弱いので強化を推奨します」——書き手が何を見てそう思ったのかが、どこにも紐づいていない
書けるコメント：「Q7（ログの集約）とQ18（保存期間・改ざん防止）がいずれも低いため、まず保存期間の引き上げを優先対象とします」

前者は、後から誰も再現できません。読み手が「なぜ」と聞いたときに、返せるのは書き手の記憶だけです。後者は、監査の場で同じ問いを受けても、診断の入力まで一本で辿れます。書き手が変わっても、同じ回答からは同じ根拠が指せる。

逆に言うと、設問に紐づけられないコメントは書けない。書き手が「言いたいこと」を思いついても、根拠になる回答が無ければ落とすことになります。

これは書き手にとって明確な制約です。ただ、同時に品質の下限を作っています。属人性は完全には消えません——同じ根拠から書く一文にも、書き手の色は出ます。しかし「根拠が無い指摘」は、この規律の下では構造的に混入しない。属人性を消すのではなく、属人性が入り込める範囲を「根拠の上での表現」に限定する、という設計です。

スコア算出における決定論と、やっていることは同じです。機械には「同じ入力なら同じ出力」を要求し、人間には「すべての出力に遡れる入力」を要求する。向きが違うだけで、原理は一つです。

機械側でも、同じ原理が破れかけた

ここまで書くと、「機械側は仕様で固めたから安泰、問題は人間側」と読めるかもしれません。実際は違いました。機械側でも、同じ原理が破れかけた実例があります。

2026年7月30日、私が2枚の帳票を並べて説明しようとした時に見つけました。経営サマリーと推移レポートで、同じ「総合スコア」という名前の数字が、わずかにずれていたのです。片方は小数2桁、片方は整数。

原因を追うと、帳票を生成する側のコードが、算出エンジンの確定済み総合スコアを受け取らず、自分で平均を計算し直していました。しかも機能別スコアを整数に丸めてから平均する、二重丸めです。

誤解のないように書くと、算出そのものは同一で、差は表示上の丸めだけです。誤りというより、精度の不一致です。ただ、読み手から見れば「同じ名前の数字が帳票によって違う」——それだけで、「この数字は信用できるのか」という問いを招きます。

是正の方針は決めました。表示のための再計算をやめ、算出エンジンの確定値をそのまま渡す。ただし、実装はまだ入れていません。技術的には今すぐ変えられます。それでも待っているのは、すでに配布した資料の数字と、これから生成される数字が、作業の途中で食い違う状態を作りたくないからです。切り替えるなら、両方が同時に変わるタイミングでやる。

このとき出た一言が、そのまま教訓になっています。

「表示のための再計算は、決定論を売る製品の中で最も置いておきたくない種類のコードだ。」

算出エンジンをどれだけ固めても、その下流に「気を利かせて計算し直すコード」が1箇所あれば、読み手に届く数字の一意性は崩れます。決定論は、算出だけでは守れないのです。

そして、いつ直すかを決める基準も、結局は読み手の側にありました。直すこと自体より、読み手の手元にある数字と食い違わせないことのほうが先にくる。この判断のしかたも、決定論を「読み手に対して持つ性質」として扱うということだと思っています。

余談ですが、物差し側も同じ思想で固めています。スコアの重み付けは methodology_version という設定として外に出し、DBで凍結しています。物差しが動くと、四半期をまたいだ推移が比較できなくなるからです。算出・表示・物差し、どの層が動いても再現性は壊れる。決定論は一枚岩ではなく、層ごとに守るものでした。

結論：「決定論」は算出の性質ではなく、成果物の性質

この一連から得た結論はこうです。

「決定論」とは、算出アルゴリズムの性質ではなく、成果物が読み手に対して持つ性質である。

算出は、同じ入力から同じ数字を出す
表示は、確定値を再計算せずそのまま渡す
物差しは、凍結して推移の比較可能性を守る
人間の所見は、すべて設問番号に遡れる形で書く

このどれか一つが欠けても、読み手にとっての「この数字・この指摘はなぜこうなのか」に答えられなくなります。機械にも人間にも同じ規律を掛けて、初めて成立する。機械側を固めた前回の話は、その半分だったということです。

この設計は、IT統制の現在地を継続的に測る診断サービス SecuROI の運営標準として運用しているものです。