AI駆動開発 2026年7月16日

AIの成果物は「信頼できる顔」で間違える――品質保証を設計で作る10の視点

「このAIの出力、本当に正しいのか」という問いに、多くの現場はまだ明確な答えを持っていない。目で見て問題なさそうなら使う、何かおかしければ差し戻す――そういう運用が主流だと思う。だがその「目で見て問題なさそう」というのが、AIの欠陥に対してはほぼ無力だという話をしたい。

Qiitaで全10回にわたって公開されてきたLLM連載の最終回（@ha-te氏）が、この問いに正面から答えようとしている。個別のクセを解剖した前9回の内容を、品質保証の体系として組み上げた総合編だ。内容の密度が高いので、ここではエッセンスを整理しつつ、実務視点での解釈を加えていく。

AIの成果物が「バグの顔」をしないという問題

従来のソフトウェアQAは、ある前提の上に成立している。「同じ入力には同じ出力が返る」「バグは再現できる」「テストは仕様との照合として機能する」という前提だ。

AIの成果物は、この3つすべてを崩す。

温度パラメータを0にしても、モデル更新やコンテキストのわずかな違いで出力が変わる。ナレッジを2ファイル足しただけでRAGの読まれ方ごと変わることすらある、と記事は指摘している。「再現手順」という概念が根本から成立しにくい環境だ。

さらに厄介なのが、欠陥が欠陥の顔をしていないことだ。従来のバグはクラッシュやエラーとして現れた。AIの欠陥は、ポチョムキン理解（定義は正しいのに適用がずれる）、幻覚のロジック（欠けた根拠がもっともらしく補完される）、陳腐化（自信満々に古い答えを返す）――いずれも「正しい出力と同じ顔」で現れる。

そして欠陥は時間とともに発生する。Context Rot（会話の腐敗）やInstruction Drift（指示の漂流）により、セッションの経過そのものが品質を変える。金曜日に良かったプロンプトが月曜日に劣化していることすらある、という記述は、経験者には刺さるはずだ。

ここから導かれる結論は明快だ。「完成品を検査するだけでは成立しない。生成プロセス・検証方法・時間経過の3方向すべてに設計が要る」。

9つのクセを欠陥分類表として読み直す

連載が解剖してきた9つのクセ――ポチョムキン理解、Lost in the Middle、Context Rot、Sycophancy、Context Handoff、Prompt Distillation、Project化の罠、GPT化の罠、Instruction Drift――は、AI欠陥のタクソノミー（分類体系）として再編できる。

表の「検出の難所」の列を眺めると、共通点が見えてくる。「説明を見ても検出できない」「読んだはずに見える」「連続的で境目がない」「フィードバックが返ってこない」「じわじわ戻るので気づけない」。どれも、人間が成果物を眺めるだけでは構造的にすり抜けられる欠陥だ。

だからAI成果物のQAは、目視レビューの強化ではなく、「検出できる仕組みの設計」の話になる。

品質保証の公理：3つの原理

記事は9回分の議論を3つの原理に集約している。これが以降のQA設計の基盤になる。

原理1：放っておけば、重心に回帰する。 LLMの出力は、放置すると訓練分布の"典型"へ引っ張られる。実務で価値がある情報は「そのプロジェクト固有の、典型から外れた事情」であることが多い。つまり何も設計しなければ、一番重要な情報から順に失われるのがデフォルトだ。

原理2：間違いは、間違いの顔をしない。 LLMは「知らない」と「知っている」を区別する内部フラグを持たず、どんな状態でも確率分布は定義され、必ず何かをもっともらしく出力できる。出力の見た目・自信・流暢さは、正しさの証拠として一切使えない。

原理3：自己申告は、検証にならない。 「理解していますか」→「はい」。「ルールを守れていますか」→「守れています」。「根拠を書いて」→もっともらしい根拠が生成される。生成物による証明は、検証したい対象と同じ病を継承する。結論は「聞くな、測れ」だ。

検証の階層 L0〜L4

3つの原理から、検証手段の信頼性の序列が導かれる。

L0：機械検証。 コードはテストを走らせる。数値は再計算する。形式ルールは正規表現で判定する。機械検証は原理1〜3の影響を一切受けない。重心に引かれず、顔に騙されず、自己申告に依存しない。まず「この成果物のどの部分が機械検証可能か」を仕分けることが第一歩だ。

L1：原典照合。 機械実行できない内容でも、原典が存在するなら照合はできる。成果物に根拠の引用とIDを義務付けておけば「この結論の根拠は原典のどこか」を機械的に遡れる。逆に、引用もIDもない成果物は幻覚のロジックを検出できない成果物だ、という指摘は鋭い。

L2：独立審査。 有効にするための条件が3つある。①生成した本人（同じセッション）に審査させない、②できれば別会社のモデルに審査させる（自己選好バイアスの回避）、③総評を禁止し項目別判定＋原文引用を強制する。Zheng et al. (2023) が報告しているように、LLMには冗長な回答を高く評価する傾向（verbosity bias）や提示順で評価が変わる位置バイアスもあるため、比較対象の順序を入れ替えて複数回試す作法も重要だ。

L3：実測プロファイル。 モデルの仕様書は、使う側が実測して自分で書くもの。カナリア（迎合の強さの定点観測）、ゴールデンタスク（月次回帰テスト）、アブレーション（どの指示が効くかの実証）、ドリフト発生ターンの計測。「このモデルは12ターンで常体が崩れる→10ターン目にアンカー再注入」のように、QAのルールを経験則ではなく実測データから導けるようになる。

L4：人間の判断。 ただし役割が変わる。「毎回の全数目視」から「一度きりの設計検証＋例外処理」へ。人間にしかできないのは、機械検証できない価値判断、L0〜L3の検証系そのものの設計と校正、検証系がフラグを立てた例外の裁定――この3つだ。

AIおじさんとしての見方：「信頼の設計」という発想転換

ここからは私見を混ぜる。

記事の中に「橋の設計者」のアナロジーがある。橋の設計者は鋼材を信頼しない。鋼材の降伏点を実測し、安全係数を掛け、荷重試験をしてから橋を信頼する。AIも同じで、モデルを信頼するのではなく、検証系を組んでその系を信頼するのだ、という話だ。

これは概念としてはわかりやすいが、実務で意識が変わっているチームはまだ少ないと感じている。多くの現場で起きているのは「優秀そうなAIを選んで、出力を目で確認する」というフローだ。それは鋼材の見た目が良さそうだから使う、と言っているに近い。

特に問題だと思うのが、L2独立審査の運用だ。「AIにレビューさせる」という発想自体は広まっているが、同じセッションの同じモデルに自己レビューさせている例が多い。条件Aの「生成した本人に審査させない」という最低ラインすら満たしていないケースが散見される。別会社モデルを使う（条件B）はまだしも、「おおむね良好です」という総評を受け取って安心している（条件Cの違反）のは、むしろレビューをしたという錯覚だけ生んでいる。

判断軸として一つ渡しておくと、L2独立審査の3条件（別セッション・別モデル・項目別判定）をチームが満たしているかどうかで、AI運用の成熟度をざっくり測れる。

実務的な示唆と今後の論点

記事が提示しているDone定義（成果物メタブロック）は、即効性が高い。生成モデルと日付、セッション状態、根拠ID、確信度の高中低、未確認事項の列挙、実施済み検証の記録――このメタ情報を義務付けるだけで、「L0もL1も使えない判断・推奨をそのまま採用する」という最も危険なパターンを防ぎやすくなる。

一方で、次に問題になるのは「検証系の維持コスト」だと見ている。ゴールデンタスクの定期回帰、カナリアの定点観測、実測プロファイルの更新、モデルのバージョンアップごとの再測定――これらは設計するだけでなく、誰かが継続的に回し続けなければならない。記事はその重要性を指摘しているが、組織として誰がその担い手になるのかは別の問題だ。

AIの「品質保証担当」という役割が、開発チームの中に実質的に必要になってくる。テストエンジニアがソフトウェアQAを専門とするように、AI成果物の検証系を設計・維持する人材の必要性は今後高まるはずだ。今はその役割の輪郭がまだ曖昧なまま、開発者やプロダクト担当が兼務している状態が多い。