技術を使うとき、その内部で何が起きているかを完全に理解している場面は、実際にはそれほど多くない。スマートフォンを一つ操作するだけでも、無線通信、暗号、半導体、オペレーティングシステム、アプリケーション、クラウドサービスまで複数の技術層が連動している。画面上のボタンを押してメッセージを送る利用者が、それぞれの通信規格や暗号方式、サーバー側の処理まで理解している必要はない。それでも、操作に対して期待した結果が返り、失敗した場合にはエラーや未送信という状態が観察できるため、道具として利用できる。
このとき利用者は、内部を何も知らないことだけを根拠に技術を信用しているわけではない。ボタンを押せば画面が変わる、送信すれば相手へ届く、通信に失敗すれば再試行できるといった、入力と結果の対応を経験的に確認している。さらに製品やサービスの側にも、通信規格、試験、エラー処理、監視などが組み込まれている。利用者が内部機構を直接理解していなくても、技術の外側には、その振る舞いが一定の範囲に収まることを確かめる仕組みが存在する。
落合陽一氏は、2026 年 8 月 29 日の note で、ソフトウェア更新中の Vision Pro に表示された進捗バーを出発点として、技術に対する「分からない」の意味が変化してきたと論じている[1]。進捗バーを見ても、利用者には内部でどのファイルが変更され、どの処理が完了し、次に何が実行されるのかまでは分からない。それでも、処理が進んでいること、終了したこと、失敗したことは外部から観察できる。内部過程を逐一追跡できなくても、その処理を利用できるという関係がここにある。
ただし、現在の AI に現れる「分からなさ」は、このような利用者側の知識不足だけでは説明できない。従来のソフトウェアであれば、利用者が内部処理を知らなくても、必要になれば仕様書、ソースコード、設計資料、実行ログをたどり、どの条件分岐によって結果が決まったかを調べられる場合が多い。実装が巨大で人間一人には追い切れないとしても、処理は人間が記述した命令の組み合わせとして存在している。
統計的機械学習では事情が変わる。学習アルゴリズム、モデル構造、目的関数が分かっていても、学習後の多数のパラメーターが特定の入力に対してどの特徴をどの程度利用し、その組み合わせによってなぜ特定の出力へ到達したのかを、人間が読める少数の規則へ還元できるとは限らない。何を計算しているかという形式的な記述が存在することと、その計算が生み出した個別の判断を人間向けの因果説明として理解できることが分離する。
AI エージェントでは、この差がさらに実際の行動へ接続される。モデルが文章を返すだけなら、出力を読んでから採用するかを判断できる。外部のツール、ファイル、ブラウザー、データベースなどを操作するようになると、モデルの出力は次の入力になり、その判断が外部状態を変更し、その変更された状態をもとにさらに次の処理が実行される。一つの回答を理解できるかという問題から、複数段階の行動全体をどのように管理するかという問題へ広がる。
| 分からなさ | 具体的な状態 | 信頼するために必要になるもの |
|---|---|---|
| 利用者が内部を知らない | 仕組みは設計され説明可能だが、利用者自身は詳細を知らない。 | 仕様、製品試験、エラー処理、利用経験などによって期待する振る舞いを確認できる。 |
| 個別の判断理由を簡潔に説明しにくい | モデル構造と学習方法は分かっていても、特定の出力へ至った判断を少数の規則へ還元しにくい。 | 評価データ、失敗分析、頑健性評価などによって振る舞いの範囲を測る必要がある。 |
| AI が外部状態を変更する | 一つの出力が次の操作を生み、複数段階の処理として環境へ作用する。 | 権限、実行結果、監視、停止条件、ロールバックまで含めて行動範囲を制御する必要がある。 |
三つの状態は、同じ「分からない」という言葉で表せても、技術上の意味が異なる。第一の状態では、知識を持つ主体が利用者から専門家へ移っているだけである。第二の状態では、システムを構成した側にも、個別挙動を人間向けの簡潔な規則として説明しきれない部分が残る。第三の状態では、その説明しきれない系が外部へ作用するため、理解の不足が観察上の問題だけではなく、操作上のリスクへ変わる。
ここから生じる問いは、AI がブラックボックスかどうかという二択ではない。内部について何を理解できているかと、実際の振る舞いについて何を確認できているかを分けた上で、どの証拠があればその技術を利用してよいと判断できるのかが問われる。内部説明を完全に得られない場合にも利用するのであれば、「よく分からないが動いている」という状態をそのまま受け入れるのではなく、別の方法で信頼できる範囲を限定しなければならない。
そのために必要になるのが、要求、評価条件、実行結果、監視、停止条件という外部から観察できる証拠である。何を成功とするかを定め、その条件で実際に成功するかを測り、利用中に条件から外れたことを検出し、危険な状態へ進む前に停止できるようにする。内部を理解するという一つの経路だけで信頼性を支えきれないなら、外部から振る舞いを検証する経路を追加する必要がある。
この構造自体は AI の登場によって初めて生まれたものではない。人間は歴史上、原因を十分に説明できるようになる前に、有効な手順を見つけて利用してきた。AI における説明と検証の関係を考えるためには、まず「なぜ効くか」を知ることと、「何をすれば効くか」を知ることが、どのように別々に成立し得るのかを確認する必要がある。
1. 有効な手順は、正しい説明より先に存在できる
原因を科学的に説明できることと、有効な操作を知っていることは、歴史的にも同時に成立してきたわけではない。食品保存は、その時間差を具体的に示す。米国農務省の National Agricultural Library によれば、Nicolas Appert はナポレオン戦争期に、食品を加熱して密閉容器に保存する方法を発展させ、1809 年にフランス政府の懸賞を獲得した[2]。一方、Louis Pasteur が発酵と微生物の関係を本格的に研究し始めたのは 1857 年であり、発酵が生物の働きによることを示す研究はその後に進んだ[3]。
年代を並べると、保存という実用上の成果が、その効果を微生物によって説明する科学より数十年先に成立していたことになる。Appert の方法を利用するためには、食品を加熱し、容器を密閉し、一定の手順を守った場合に保存期間が延びることを確かめられればよかった。微生物が増殖し、それを加熱によって抑制できるという後世の説明を持っていなくても、操作と結果の対応は観察できた。
ここで先行していたのは、単なる思いつきではなく再現可能な操作である。一度だけ食品が腐らなかったのであれば偶然と区別できない。同じ操作を複数の食品や容器に適用し、保存できる例を積み重ねることで、加熱と密閉という操作に実用上の意味が生まれる。現象の原因について正確な理論を持っていなくても、「この条件でこの操作をすると、この結果が得られる」という関係は経験的に評価できる。
一方で、経験的に有効な手順が存在することは、その手順の適用範囲まで理解できていることを意味しない。加熱温度、加熱時間、食品の性質、容器の状態が変われば、同じ結果が得られるとは限らない。原因機構が分からない段階では、どの条件が結果を左右しているかを切り分けにくいため、経験的に成功した範囲の外へ手順を拡張すると失敗する可能性がある。
微生物学による説明が加わると、この弱点を別の方向から補える。食品が腐敗する現象と微生物の活動を結び付けられれば、加熱が何に作用しているのか、密閉がなぜ必要なのか、どの条件では同じ操作が十分でないのかを調べられる。説明は、既に存在する手順を正当化するだけではなく、成功条件と失敗条件を分解し、適用範囲を広げるためにも使われる。
この関係から、技術に含まれる知識を少なくとも二つに分けられる。一つは、どの操作を行えば期待した結果が得られるかという操作に関する知識である。もう一つは、その操作がなぜ結果を生むのかという機構に関する知識である。
| 知識 | 中心となる問い | 確かめ方 | 単独では残る制約 |
|---|---|---|---|
| 操作に関する知識 | 何をすれば期待した結果が得られるかを問う。 | 操作を実行し、結果が再現するかを観察する。 | 条件を変えたときにも同じ結果になる理由までは分からない。 |
| 機構に関する知識 | なぜその操作によって結果が生じるかを問う。 | 観察、対照実験、測定、理論によって原因関係を調べる。 | 説明が存在しても、実際の装置や手順が要求どおり動くことは別途確認する必要がある。 |
二つの知識は競合するものではない。操作に関する知識は、理論が完成する前でも技術を成立させられる。その代わり、確認済みの条件から離れたときの予測には弱い。機構に関する知識は、条件を変えた場合の結果を推測し、失敗原因を分解する手掛かりになる。その代わり、正しい理論を知っているだけでは、具体的な製品や工程が正しく実装されていることまでは保証しない。
たとえば、微生物と加熱の関係を正確に理解していても、実際の製造工程で必要な温度に達していなければ食品保存は失敗する。逆に、原因を十分に説明できなくても、適切な条件を経験的に固定し、その範囲内で再現性を確保できれば技術として利用できる。説明の正しさと手順の正しさが別々の評価を必要とするのは、この二つが異なる失敗経路を持つためである。
この区別を現代の AI へ移すと、「説明できない AI は使えない」と「結果さえ正しければ内部は分からなくてよい」という二つの見方だけでは不十分であることが分かる。AI が要求した結果を生むかという問いは、評価データ、テスト、実環境での実行結果によって調べられる。一方、その結果がなぜ生じたか、条件が変わっても同じ判断規則が維持されるかという問いには、内部解析や追加の実験が必要になる。
ただし、食品保存の経験則と現代の AI には大きな違いもある。保存した食品は、腐敗したかどうかという結果が現実世界から返ってくるため、手順の失敗を比較的直接観察できる。AI では、文章の妥当性、将来予測、画像分類、業務判断など、正解そのものを即座に観察できない課題が多い。さらに評価に使用したデータと実際の利用環境が異なれば、試験時には成功していた手順が運用時には失敗することもある。
そのため、AI において操作の有効性を確認するには、「結果が出た」という事実だけでは足りない。何を正解として評価したのか、どの条件で測ったのか、評価対象に含まれていない条件は何かまで管理する必要がある。経験的に使える手順が理論より先行できるという歴史的事実は、AI でも説明が完成するまで何も利用できないわけではないことを示す。同時に、手順が一度成功しただけでは、その適用範囲まで保証されないことも示している。
この違いをさらに進めると、AI における信頼の焦点は「理由を完全に説明できるか」だけでも、「評価データで高得点を取ったか」だけでもなくなる。予測能力と説明能力を別々に測り、それぞれがどの範囲まで信頼できるかを確認する必要がある。次に見るべきなのは、現代の統計学と機械学習で、この二つがどのように独立した評価軸として分かれてきたかである。
2. 「当たること」と「分かること」は別の評価軸になった
統計学では長く、観測されたデータの背後にある仕組みを確率モデルとして表し、そのモデルのパラメーターを推定する方法が中心的な役割を持ってきた。たとえば、ある要因が結果へどの程度影響するのかを回帰係数として表したり、観測値がどの確率分布から生じたのかを仮定したりする。この方法では、データに適合することだけでなく、モデルの各要素が現象のどの部分を表しているのかを解釈できることにも意味がある。
しかし、データから得たいものが常に現象の説明とは限らない。明日の需要を予測する、画像に写っている物体を分類する、融資申請の不履行確率を推定するといった課題では、未知の入力に対して正しい結果を返せること自体が独立した目的になる。現象を少数の変数と簡潔な関係式で説明できるモデルと、将来の観測値を高い精度で予測できるモデルが同じである保証はない。
Leo Breiman は 2001 年の論文「Statistical Modeling: The Two Cultures」で、この違いを統計学に存在する二つの文化として整理した[4]。一方は、自然がデータを生成する仕組みを何らかの確率モデルとして仮定し、その内部構造を推定する立場である。もう一方は、データ生成機構そのものを明示的にモデル化することを必須とせず、観測された入力から出力を正確に予測する関数を構築する立場である。
二つの違いは、同じデータを扱っていても、何を成功と評価するかに現れる。前者では、仮定したモデルが現象を妥当に表しているか、推定した係数をどのように解釈できるか、仮説がデータによってどこまで支持されるかが重要になる。後者では、学習に使っていないデータへ適用したときに、どれだけ誤差を小さくできるかが中心になる。説明の妥当性と予測の正確さは関係することがあるが、同じ評価指標ではない。
| 観点 | 生成機構をモデル化する立場 | 予測を中心にする立場 |
|---|---|---|
| 中心となる問い | 観測されたデータは、どのような仕組みから生じたのかを問う。 | 未知の入力に対して、どれだけ正確な出力を返せるかを問う。 |
| モデルに求めるもの | 変数やパラメーターと現象との対応を解釈できることが重要になる。 | 内部構造の簡潔さより、未使用データに対する予測性能を優先できる。 |
| 主な評価対象 | モデル仮定、推定値、適合度、推論の妥当性などを評価する。 | 評価データでの誤差、正答率、損失などを測定する。 |
| 典型的な失敗 | 現象を説明しやすいモデルでも、未知データへの予測性能が十分でない場合がある。 | 高い予測性能を得ても、何を根拠として判断したかを人間が理解しにくい場合がある。 |
機械学習は、後者の方法を大規模なデータと計算資源によって発展させた。まず、予測結果と正解との差を数値化する目的関数を定める。次に、訓練データを使って、その値が小さくなるよう多数のパラメーターを調整する。そして、学習に使用していない評価データへ適用し、未知の入力でも同程度の性能を維持できるかを確かめる。この一連の手順では、モデル内部が人間に理解しやすい形を持つことを直接の条件にしなくても、予測性能を改善できる。
ニューラルネットワークでは、この構造が特に明確になる。線形回帰であれば、各係数と入力変数との対応を読み、その符号や大きさを解釈できる場合がある。大規模なニューラルネットワークでは、多数の層とパラメーターを通じて入力が変換され、一つの特徴が一つのパラメーターだけに対応するとは限らない。モデルを構成する数式や計算手順は完全に記述できても、特定の判断を少数の人間向け規則へ置き換えることは難しくなる。
それでも、予測性能そのものは外部から測定できる。たとえば画像分類であれば、評価用画像に対して何件正しく分類したかを数えられる。需要予測であれば、予測値と実測値との差を測れる。モデルの内部表現を人間が読み切れなくても、指定した条件における出力の正確さは数値として比較できる。ここで、「内部を理解できること」と「外部から性能を測れること」が明確に分かれる。
この分離が重要なのは、高い予測性能が説明の正しさを自動的に保証しないからである。評価データで正しい答えを返していても、人間が想定した特徴ではなく、データに偶然含まれている別の相関を利用している可能性がある。反対に、構造が単純で人間に説明しやすいモデルでも、複雑な入力関係を十分に表現できず、未知データでは誤差が大きくなる場合がある。どちらか一方の評価だけで、もう一方まで保証することはできない。
この意味で、機械学習がもたらした変化は、説明を捨てて予測だけを選んだことではない。説明能力と予測能力を別々に測定できるようになり、一方が高くても他方が同じ水準にあるとは限らないことが実践上明確になったことである。モデルが「当たる」という事実は、そのモデルについて分かっていることの一部ではあるが、それだけで「なぜ当たるのか」まで理解したことにはならない。
この区別を AI の信頼性へつなげると、予測性能を確認できるから内部理解は不要だ、という結論にはならない。評価データで測れるのは、あくまで設定した条件における振る舞いである。その条件から外れた入力で何が起きるか、どの特徴へ依存して判断しているか、失敗したときに原因をどこまで特定できるかは別の問いとして残る。
そこで次に必要になるのは、「説明できる」「説明できない」という二値判定を分解することである。モデルの構造を知っていること、学習方法を知っていること、個別出力の理由を説明できること、未知条件での振る舞いを予測できることは、それぞれ異なる。AI の内部について何が既知で、どの部分に不確実性が残るのかを区別しなければ、外部から何を検証すべきかも定められない。
3. ブラックボックスかどうかは二値ではない
AI をブラックボックスと呼ぶと、内部で何が起きているかを人間がまったく知ることのできない装置のように聞こえる。しかし、多くの機械学習システムでは、モデルの構造、各層で実行される計算、学習アルゴリズム、訓練時に最適化した目的関数などは明示的に定義されている。開発者は、どの入力がどの演算を通り、どの形式の出力へ変換されるかという計算過程そのものを記述できる。
それでも、特定の入力に対してなぜ特定の出力になったのかを、人間が理解できる少数の規則へ還元できるとは限らない。たとえばニューラルネットワークが画像を猫と分類した場合、入力された画素が各層を通じてどのように変換されたかは計算として再現できる。しかし、「耳の形を 40%、毛の模様を 30%、輪郭を 30% 見て猫と判断した」といった、人間がそのまま判断規則として理解できる形へ変換できるとは限らない。計算を追跡できることと、判断理由を理解できることは同じではない。
この違いがあるため、「内部が分かるか」という問いは一つの尺度では扱えない。Zachary C. Lipton は、機械学習における interpretability という言葉が、モデルそのものの透明性、個々の構成要素を人間が理解できること、入力と出力の関係を事後的に説明することなど、異なる概念をまとめて指していると整理した[5]。Finale Doshi-Velez と Been Kim も、解釈可能性について共通した定義や評価方法が十分に確立しておらず、何をもって「理解できた」と判定するのか自体が研究上の課題であると指摘している[6]。
この区別を実際の機械学習システムへ当てはめると、内部について分かることはいくつかの層に分かれる。モデルの構造を知っていること、どのデータと目的関数で学習したかを知っていること、特定の出力に影響した要素を分析できること、未知の入力に対する振る舞いを予測できることは、それぞれ別の能力である。
| 観点 | 分かること | それだけでは分からないこと |
|---|---|---|
| モデル構造 | どの演算をどの順序で実行し、入力をどのように出力へ変換するかを記述できる。 | 個別の入力について、なぜその判断になったのかを人間向けの簡潔な規則として説明できるとは限らない。 |
| 学習方法 | どの訓練データ、目的関数、最適化方法によってパラメーターを更新したかを説明できる。 | 学習後のモデルが実際にどの特徴を利用し、未知の場面でどの手掛かりを優先するかまでは決まらない。 |
| 個別説明 | 特定の出力に強く影響した入力要素や内部表現を分析し、判断に関係する手掛かりを示せる場合がある。 | 得られた説明がモデル内部の因果関係を完全に再現していることや、別の入力にも同じ説明が成立することまでは保証しない。 |
| 性能評価 | 定めた評価データと指標の下で、どの程度正答し、どの種類の失敗が発生したかを測定できる。 | 評価条件に含まれない入力や環境でも同じ性能を維持することまでは保証しない。 |
この表の各行は、単純な上位下位関係ではない。モデル構造を完全に記述できても、個別判断の理由を簡潔に説明できるとは限らない。個別の説明を一つ得られても、その説明が将来の入力に対しても成立するとは限らない。評価データで高い性能を確認できても、その性能が未観測の環境へそのまま移るとは限らない。ある段階で得られた知識から、次の段階の知識が自動的に導かれるわけではない。
従来のソフトウェアでは、この距離が比較的小さい場合が多い。ある入力に対して誤った結果が返れば、条件分岐、変数、関数呼び出し、外部 I/O を追跡し、どの処理によって結果が決まったかを特定できる。複雑なシステムでは調査に時間がかかっても、実行された処理は人間が記述した命令列として存在するため、原因をコード上の位置へ結び付けられる場合が多い。
学習済みモデルでは、同じ方法をそのまま適用できない。出力は多数のパラメーターと中間表現の相互作用によって生じるため、特定の誤答を一つの条件分岐や一行のコードへ対応させることが難しい。モデルを作った開発者が計算過程を理解していても、「この誤答はこの一つの規則が間違っていたから起きた」と局所化できない場合がある。モデル規模が大きくなるほど、形式的に記述可能な計算と、人間が利用できる原因説明との距離が広がる。
この距離が信頼性の設計を変える。内部を十分に説明できない部分が残るなら、信頼の根拠を内部解析だけに置くことはできない。代わりに、外部から入力を与え、どの条件で正しく振る舞い、どの条件で失敗するのかを測定する必要がある。失敗例を分類し、利用してよい入力範囲を限定し、条件から外れた場合に検出できる仕組みを用意することで、説明できない部分を運用上の制約で補う。
ただし、外部評価にも限界がある。評価データで高得点を取ったという事実が示すのは、そのデータと評価指標の範囲で結果が良かったということだけである。モデルが人間の想定した特徴を利用しているのか、偶然存在する別の相関を使っているのかまでは、高い正答率だけから判断できない。評価条件と実環境が異なれば、試験では見えなかった依存関係が失敗として現れる可能性もある。
AI のブラックボックス性を考えるときに必要なのは、「分かる」「分からない」という二値分類ではなく、どの層まで理解でき、どこから先を外部評価によって補っているのかを分離することである。その境界が明確であれば、内部理解が不足している部分について、どの評価条件や制約が必要かを設計できる。逆に、この境界を曖昧にしたまま性能だけを見ると、評価データで成功した理由と、実環境でも成功する理由を取り違える。
次に必要になるのは、この取り違えが実際にどのような形で起きるかを確認することである。モデルは評価データ上で正しい結果を返していても、人間が想定した規則ではなく、より簡単な別の手掛かりを利用している場合がある。正答したという結果と、正しい理由で解いたという判断は、ここでも別々に検証しなければならない。
4. 正しい結果が出たことだけでは、正しい方法で解いたとは分からない
モデルが評価データで高い点数を取ったとき、確認できたのは「その評価条件では正しい出力を多く返した」という事実である。そこから直ちに、「課題の本質を理解した」「人間と同じ特徴を使って判断した」「条件が変わっても同じ規則で解ける」とまでは言えない。同じ正解へ到達する方法は一つとは限らず、評価データに含まれる偶然の相関を利用しても、採点上は正答になることがあるためである。
Robert Geirhos らは、深層学習で生じるこの種の現象を shortcut learning という観点から整理した[7]。ここでいう shortcut は、単に計算を効率化する近道ではない。訓練データと評価データでは正解と強く結び付いているため高い性能を得られるが、実際に利用したい環境では安定して成立しない特徴や規則を指す。モデルは与えられた目的関数を小さくするように学習するため、人間が「本質的」と考える特徴と、モデルにとって最も利用しやすい特徴が一致する保証はない。
画像分類を考えると分かりやすい。猫と犬を分類する課題で、人間は耳、顔、体形など対象そのものの特徴を使うことを期待するかもしれない。しかし、訓練画像で猫の写真には室内の背景が多く、犬の写真には屋外の背景が多ければ、背景もラベルを予測する手掛かりになる。対象そのものを見るより背景を利用する方が簡単で、それでも訓練時の損失を十分に減らせるなら、モデルがその相関を利用することは学習手続きから見れば不自然ではない。
この状態が厄介なのは、通常の評価データにも同じ相関が残っている場合である。訓練データと評価データが同じ収集過程から作られていれば、猫と室内、犬と屋外という対応が両方に含まれる可能性がある。その場合、モデルは評価データでも高い正答率を記録するため、点数だけを見ても shortcut を利用していることを検出できない。背景を入れ替えたり、撮影条件を変えたりして初めて、それまでの高得点がどの特徴に依存していたのかが失敗として表面化する。
| 状態 | 評価データで見える結果 | 実際に起きている可能性 | 条件を変えたときの帰結 |
|---|---|---|---|
| 期待した特徴を学習 | 高い正答率を示す。 | 利用環境でも比較的安定する特徴を使って判断している。 | 背景や撮影条件が変わっても性能を維持できる可能性が高い。 |
| shortcut を学習 | 同じように高い正答率を示す。 | 評価データにも残っている偶然の相関を使って判断している。 | 相関が崩れると、それまで観測されなかった誤りが増える可能性がある。 |
二つのモデルは、通常の評価データだけを見れば同じように優秀に見える。それでも、利用条件を変更したときの振る舞いは異なる。正答率という結果から分かるのは、用意した問題に何問正解したかであり、何を根拠として正解したかまでは直接観測できない。この差があるため、評価結果をモデルの判断規則そのものと同一視することはできない。
評価データそのものも固定された基準ではない。Benjamin Recht らは、CIFAR-10 と ImageNet について、元のデータセットが作られた収集・選別過程をできるだけ再現して新しいテストセットを構築し、既存モデルを再評価した。その結果、元のテストセットで測定した場合より精度が低下した[8]。モデルを変更していないにもかかわらず、同じ分類課題を意図して新たに集めたデータへ置き換えただけで測定値が変化したことになる。
この結果は、既存モデルの評価が無意味だったことを示すものではない。元のテストセットに対する性能は、その条件について実際に測定された値である。ただし、その数値を「ImageNet という課題全般に対する固定的な能力」と解釈すると射程を広げすぎる。評価値はモデルだけの属性ではなく、どのデータを選び、どの分布から標本を取り、どの指標で採点したかという評価系との組み合わせによって得られる。
ここには二段階のずれがある。第一に、モデルが高得点を取っても、人間が期待した特徴を学習しているとは限らない。第二に、その高得点自体も、評価データを作った条件が変われば同じ値を維持するとは限らない。モデル内部の判断規則と評価結果の間にずれがあり、さらに評価結果と実際の利用環境の間にもずれが存在する。
第 1 章で見た食品保存の経験則と比較すると、この違いがはっきりする。食品を保存する操作では、保存した対象が腐敗したかどうかという結果が現実世界から継続的に返ってくる。手順を異なる食品や保存期間へ広げれば、その条件で成功するか失敗するかを再び観察できる。原因を十分に説明できない段階でも、実世界との相互作用そのものが手順の適用範囲を試す機会になる。
AI の評価では、現実世界全体を試験することはできない。実際には有限のデータセット、有限の利用シナリオ、有限の評価指標を選び、それらを実環境の代理として使う。画像分類なら収集した画像群、言語モデルなら問題セット、AI エージェントならあらかじめ定義した作業を使って性能を測る。試験に含まれていない入力、環境、失敗条件については、評価値から直接の証拠を得ていない。
この構造を踏まえると、「モデルの精度は 95% である」という表現にも条件が必要になる。それは、あらゆる状況で 95% 正しく動くという意味ではない。特定のデータセットを特定の方法で評価した結果として 95% だったという意味である。対象となる入力分布、データ収集方法、指標、モデルの版が変われば、同じ数値を前提にはできない。
| 確認対象 | 評価から言えること | 評価だけでは言えないこと |
|---|---|---|
| 正答率 | 指定した評価データのうち、どの割合で正答したかを示せる。 | すべての利用環境で同じ割合の正答を維持することまでは示せない。 |
| 判断に使う特徴 | 追加実験によって特定の特徴への依存を調べられる。 | 通常の正答率だけでは、どの特徴を使って正答したかを特定できない。 |
| 未知条件への性能 | 条件を意図的に変更した評価によって頑健性を調べられる。 | 試験していない条件の性能を既存の点数から直接保証することはできない。 |
| 利用可能な範囲 | 複数の評価条件を組み合わせることで、確認済みの範囲を広げられる。 | 有限の試験によって、あらゆる将来入力を網羅することはできない。 |
AI の「手順の点数」は、この意味で一度決めれば終わる固定値ではない。どの入力範囲を対象とし、どの環境を再現し、何を成功と定義し、どの失敗を測定したかという条件と一体で扱う必要がある。モデルに一つの性能値を付けるだけでは、その値が有効な境界が失われる。
検証可能性が必要になる理由もここにある。テストの本数を増やせば無条件に安心できるという話ではない。信頼できる範囲を具体的な評価条件へ結び付け、未確認の範囲を未確認のまま残すために検証が必要になる。条件を変更した評価、失敗例の分析、実環境での監視を組み合わせることで、「どこまで確認済みか」を更新し続けることができる。
この段階まで来ると、検証という言葉自体も分解する必要がある。要求どおりのシステムを作ったことを確かめる作業と、その要求が実際の利用目的に合っていることを確かめる作業は同じではない。また、出力を大量に生成してテストできても、その出力が正しいかを判定する基準がなければ評価は成立しない。次に扱うのは、AI の結果を「確認する」とき、実際には何をどの順序で確かめなければならないかという構造である。
5. 検証とは、ただテストすることではない
AI の振る舞いを外部から確かめるといっても、テストケースを大量に実行して正答率を測れば十分というわけではない。何を正しい結果とするのか、その条件が実際の利用目的を表しているのか、導入後も同じ条件が成立しているのかは、それぞれ別の問いである。これらをすべて「検証」と呼んでしまうと、ある試験に合格したという事実から、本来は確認していない範囲まで信頼を広げやすくなる。
ソフトウェア工学では、この違いを verification と validation という二つの概念で区別する。NASA の Independent Verification and Validation Program は、verification を「製品を正しく作っているか」、validation を「正しい製品を作っているか」という異なる問いとして説明している[9]。前者で確かめるのは、定められた要求や仕様に実装が適合しているかである。後者で確かめるのは、その要求を満たした製品が、実際の利用者や運用環境にとって必要な目的を達成するかである。
両者は似ているように見えて、異なる失敗を検出する。たとえば「問い合わせに 3 秒以内で回答する」「指定された形式の JSON を返す」という要求を AI システムが完全に満たしていれば、その要求について verification は成立する。しかし、利用者が必要としているのが正確な法的判断であり、回答内容に重大な誤りが含まれているなら、システム全体としては利用目的を満たしていない。仕様どおりに作られていることと、仕様そのものが正しいことは別である。
逆方向の失敗もある。実際の業務では十分に有用な回答を返しているように見えても、アクセス権限、個人情報の扱い、出力形式、監査ログなど、仕様で定めた条件を満たしていない場合がある。利用者が目の前の結果だけを見れば成功に見えても、運用条件を含めれば要求違反である。結果の妥当性と実装の適合性は、それぞれ独立して確認しなければならない。
| 段階 | 確かめる問い | AI システムでの例 | 確認を欠いた場合の失敗 |
|---|---|---|---|
| 要求定義 | 何を満たせば成功と判断するのかを定める。 | 正答率だけでなく、禁止事項、応答時間、根拠提示、権限、失敗時の動作を決める。 | テストに合格しても、それが業務上の成功を意味するか判断できない。 |
| Verification | 定めた要求どおりにシステムが作られているかを確認する。 | 入力制限、アクセス権限、出力形式、監査ログ、テスト条件が仕様どおり実装されているかを確認する。 | 有用な出力が得られていても、仕様違反や安全上の欠落を見逃す。 |
| Validation | 要求を満たしたシステムが実際の利用目的にも適合するかを確認する。 | 現実の業務データと利用者を使い、必要な判断や作業を許容できる品質で完了できるかを確認する。 | 仕様どおりに動いていても、現場では役に立たないシステムを導入する可能性がある。 |
| 運用監視 | 導入時に確認した成立条件が現在も維持されているかを確認する。 | 入力分布、モデルの版、外部 API、参照データ、失敗率の変化を継続的に追跡する。 | 導入時には成立していた評価結果を、環境変化後にもそのまま適用してしまう。 |
この順序では、テストは要求と判定基準の間に位置する。テストケースそのものは、「この入力を与えたら何が起きるか」を観察するための手段であり、観測した結果が正しいかどうかをテスト自身が決めてくれるわけではない。期待値が明確な数値計算なら、既知の答えと比較すればよい。しかし、文章要約、設計案、診断支援、コード修正のような課題では、何を正解とするか自体が複数の条件を持つ。
この問題はソフトウェアテストでは test oracle problem として知られている。Earl T. Barr らは、入力を与えてプログラムを実行できても、その出力が正しいかを判定する oracle を常に容易に用意できるわけではないことを体系的に整理している[10]。ここでいう oracle は特別な AI を指す言葉ではなく、観測した出力を期待結果と比較して合否を判定する仕組み全般を指す。
たとえば整数の加算プログラムなら、期待する結果を別の方法で計算して比較できるため、oracle を作ることは容易である。一方、「この契約書を正確に要約したか」「この設計変更が既存要件をすべて維持しているか」「この画像説明に重要な見落としがないか」を判定するには、単一の正解値を置きにくい。原文、仕様書、既存テスト、専門家の判断など、複数の根拠を組み合わせて初めて合否を判断できる場合がある。
| 出力 | 候補の生成 | 正否を判定する oracle の例 | 判定上の制約 |
|---|---|---|---|
| 数値計算 | 計算結果を生成する。 | 既知の数式、参照実装、期待値と比較する。 | 正解が明確なら自動判定しやすい。 |
| コード修正 | 変更後のコードを生成する。 | 既存テスト、追加した回帰テスト、静的解析、要求仕様を使う。 | テストに含まれていない挙動の変更は検出できない。 |
| 文章要約 | 要約文を生成する。 | 原文との事実照合、必須論点、禁止された推測の有無を確認する。 | 表現の良し悪しと事実の正しさを同じ尺度では判定しにくい。 |
| 業務判断 | 分類、推奨、判断候補を生成する。 | 業務規則、過去データ、専門家判断、制度要件と照合する。 | 将来結果が確定するまで正否を観察できない場合がある。 |
生成 AI は、この oracle problem をさらに目立たせる。文章、コード、設計、画像などの候補を生成するコストが大きく下がったため、以前なら人間が一件ずつ作っていた候補を短時間で大量に得られるようになった。しかし、生成量が 10 倍になっても、正解条件の定義や事実確認が自動的に 10 倍速くなるわけではない。生成工程の制約が弱くなるほど、全体の処理能力を決める箇所は評価側へ移る。
コード生成では、この違いが具体的に現れる。AI は短時間で複数の修正案を作れるが、コンパイルが通るだけでは修正の正しさを確認できない。既存テストが通っても、新しい要求を満たしたことまでは分からない。さらに既存テスト自体に抜けがあれば、不要な仕様変更や回帰を含んだコードでも合格する。生成されたコードを信頼するためには、要求に対応したテストが存在すること、そのテストが変更してはならない既存挙動も覆っていること、必要なら人間が差分を確認することまで含めた判定系が必要になる。
文章生成でも構造は同じである。もっともらしい文章を作れることと、記述された事実が一次資料によって確認できることは別である。出典 URL が存在することだけでは、その文献が該当する主張を支えているかは分からない。引用箇所、本文の解釈、そこから導いた一般化を分けて照合しなければならない。AI が文章を高速に増やせるほど、どの文をどの根拠と照合するかという oracle 側の設計がボトルネックになる。
このため、検証可能性は「AI の出力を最後に人間が読んで確認する」という運用だけを意味しない。最終段階の目視に依存すると、生成量が増えた時点で処理能力が頭打ちになる。要求の一部を機械判定できる形式へ落とし込み、テストで判定できる部分は自動化し、参照データと比較できる部分は照合し、意味や責任を伴う部分だけを人間へ残す必要がある。
ここでは、人間を検証工程から外すことが目的ではない。判定方法を分解することが目的である。形式条件はプログラムで確認し、数値条件は計算で比較し、既存仕様は回帰テストで守り、制度上の適否や価値判断は責任を持つ人間が判断する。すべてを一種類の oracle に任せるのではなく、出力の性質に応じて複数の証拠を組み合わせる。
この構造まで含めると、検証可能性とは、単にテストできることではない。何を成功と定義し、その成功をどの観測値で測り、どの oracle で判定し、どの証拠が揃えば採用するかを結び付けられることである。さらに、判定できない部分が残るなら、その部分を未確認として識別し、利用範囲や人間の承認条件へ反映できなければならない。
AI の内部を完全に説明できない場合でも、この評価系があれば、少なくとも確認した振る舞いと確認していない振る舞いを分けられる。逆に、評価系がなければ、モデル内部をどれほど詳しく分析しても、実際の利用目的を満たすかを判断する根拠は不足する。内部理解と外部検証は代替関係ではなく、異なる種類の不確実性を減らすための手段である。
この考え方は、現在の AI ベンチマークにも現れている。単にモデルへ質問して回答文を採点するだけでなく、複数の性質を別々に測ったり、実際のソフトウェアやオペレーティングシステムを操作させ、処理後の外部状態を使って成否を判定したりする評価が作られている。次に見るのは、AI の評価対象が「何を答えたか」から「実際に何を達成したか」へ広がっている構造である。
6. AI の評価は、内部説明から実行結果へ広がっている
AI の性能を測る方法も、モデルの利用形態に合わせて変化している。分類モデルであれば、用意した入力に対して正しいラベルを返した割合を測ることで、主要な能力をある程度表現できる。言語モデルになると、質問応答、要約、推論、コード生成など複数の能力を一つの正答率へまとめることが難しくなる。さらに AI エージェントがソフトウェアやオペレーティングシステムを操作するようになると、評価対象は生成された文章そのものではなく、その文章や判断を使って現実の環境をどの状態へ変えたかまで広がる。
この変化には二つの理由がある。第一に、AI が担う機能が増えるほど、単一の評価指標では異なる種類の失敗を区別できなくなる。あるモデルが高い正答率を持っていても、入力表現が少し変わると性能が低下する、安全上望ましくない内容を生成する、処理コストが大きすぎるといった性質があれば、実際の利用条件では別の評価が必要になる。第二に、AI が外部の道具を操作する場合、回答文の品質と作業結果の正しさが一致するとは限らない。「処理しました」と自然な文章で報告しても、対象ファイルが変更されていなければ作業は完了していない。
この二つの問題に対応するため、AI 評価は、単一の問題集で能力を比較する方法から、複数の条件で性質を測り、さらに実行後の外部状態を確認する方法へ広がっている。その流れを見ると、第 5 章で扱った「何を成功と定義し、どの oracle で判定するか」という構造が、実際の AI ベンチマークにどのように組み込まれているかが分かる。
6.1 一つの正答率では、利用上の性質を表しきれない
Holistic Evaluation of Language Models、通称 HELM は、言語モデルを複数のシナリオと複数の評価指標で比較する枠組みを提示した[11]。従来のベンチマークでは、特定の問題集についてモデルごとの正答率を比較し、一つの順位を作る方法が使われやすかった。HELM は、それだけではモデルの利用上重要な性質を十分に捉えられないという前提から、accuracy だけでなく calibration、robustness、fairness、toxicity、efficiency など異なる観点を同時に扱った。
たとえば、二つのモデルが同じ正答率を示していても、誤答するときの性質が同じとは限らない。一方は多少入力表現を変えても同じ判断を維持するが、もう一方は言い回しが変わっただけで結果が大きく変化するかもしれない。また、平均的な正答率が同じでも、特定の集団や入力カテゴリーで失敗が集中する可能性もある。利用者が必要としているのが安定した業務処理であれば、平均正答率だけではこの差を評価できない。
| 評価観点 | 測ろうとする性質 | 正答率だけでは見えない失敗 |
|---|---|---|
| Accuracy | 与えられた課題に対して、どの程度正しい結果を返すかを測る。 | 同じ正答率を持つモデル間の安定性や失敗分布の違いは分からない。 |
| Calibration | モデルが示す確信度と実際の正答率がどの程度対応しているかを測る。 | 誤っているときにも過度に高い確信を示すモデルを正答率だけでは区別しにくい。 |
| Robustness | 入力条件を変化させても性能が維持されるかを測る。 | 通常条件では高性能でも、表現や分布の変化によって急激に性能を失う場合がある。 |
| Fairness | 入力群や属性によって性能差が偏っていないかを調べる。 | 全体平均が高くても、特定の対象だけ失敗率が高い状態を見落とす。 |
| Efficiency | 要求した性能を得るために必要な計算量や資源を測る。 | 精度が高くても、処理時間や費用の制約を満たさず実運用できない場合がある。 |
ここで起きているのは、評価指標を増やしたというだけの変化ではない。「モデルの性能」という一つの抽象的な属性を測るのではなく、利用判断に必要な性質を分解し、それぞれに異なる測定方法を対応させるようになったという変化である。何を信頼したいのかが異なれば、必要な証拠も変わる。高い正答率を確認した事実から、頑健性、安全性、計算効率まで一括して推定することはできない。
HELM のような評価は、モデルが何を答えたかを測る段階にとどまっている。それでも、評価を一つの数字から複数の条件へ分解することで、「このモデルは優秀である」という曖昧な評価を、「このシナリオではこの性質を確認した」という条件付きの評価へ変えている。検証可能性という観点では、この条件の明示が重要になる。
6.2 コード生成では、文章ではなくリポジトリーの状態を評価できる
AI がコードを生成する場合、評価対象をさらに外側へ移すことができる。SWE-bench は、実在する GitHub issue と、それに対応する実際のソフトウェアリポジトリーを用いて、モデルや AI システムが現実のソフトウェア課題を解決できるかを評価する枠組みである[12]。入力として与えられるのは人工的に作った短いプログラミング問題だけではなく、既存コード、依存関係、複数ファイルにまたがる実装、issue に記述された要求を含む環境である。
この場合、「修正方法を説明できたか」と「実際に修正できたか」を分けられる。AI が原因分析としてもっともらしい文章を生成しても、コードを変更しなければ issue は解決しない。コードを変更しても、構文エラーがあれば実行できない。実行できても既存機能を壊せば修正として不十分である。最終的には、変更後のリポジトリーに対して評価用テストを実行し、要求した振る舞いが成立したかを判定できる。
| 段階 | AI が生成できるもの | 外部から確認できるもの | 失敗例 |
|---|---|---|---|
| 原因分析 | issue とコードを読んで、原因候補や修正方針を文章として提示する。 | 提示された説明が実際の不具合箇所と一致するかをコードやテストで確認する。 | 説明はもっともらしいが、実際の不具合原因とは無関係である。 |
| コード変更 | 対象ファイルを編集し、修正案を実装する。 | 差分、構文、型、依存関係などを確認する。 | 要求した修正以外の挙動まで変更する。 |
| テスト実行 | 変更後のリポジトリーでテストを実行する。 | 修正対象のテストと既存テストが成功するかを確認する。 | 対象 issue は直るが、別の既存機能が回帰する。 |
| 最終判定 | 作業完了を報告する。 | リポジトリーの最終状態と評価テストによって解決成否を判定する。 | AI は完了と報告しているが、要求状態へ到達していない。 |
この構造では、AI の自己申告は評価根拠にならない。「原因を特定した」「修正した」「テストが成功した」という文章を生成する能力と、実際にリポジトリーを要求された状態へ変える能力を分離できる。評価側は AI の説明を信用する必要がなく、変更されたコードとテスト結果という独立した証拠を確認できる。
第 5 章で扱った oracle problem も残る。SWE-bench の評価が成立するのは、対象 issue の解決を判定するためのテストが用意されているからである。そのテストが要求を十分に表していなければ、テストに合格しても本来の問題が完全に解決したとは限らない。外部状態を評価する方法へ進んでも、「何をもって正解とするか」という設計は消えない。
それでも、自然言語による回答だけを比較する場合より、評価できる範囲は広がる。コードの内容、実行可能性、テスト結果という複数の外部証拠を使えるため、モデル内部の推論を完全に理解しなくても、少なくとも要求した変更が実際のソフトウェアへ反映されたかを独立に確認できる。
6.3 AI エージェントでは、計算機そのものが評価対象になる
AI がコード生成からさらに進み、GUI やアプリケーションを操作するようになると、評価対象はリポジトリーから計算機環境全体へ広がる。OSWorld は、Ubuntu、Windows、macOS などの実際の計算機環境と各種アプリケーションを用いて、マルチモーダル AI エージェントが指示された作業を完了できるかを評価するベンチマークである[13]。
たとえば、特定のファイルを編集する、アプリケーションの設定を変更する、表計算ソフトでデータを操作するといった課題では、AI は画面を認識し、次の操作を決め、マウスやキーボードに相当する操作を実行しなければならない。一回の回答で終了するのではなく、現在の画面を観察し、操作し、変化した画面を再び観察するという循環を繰り返す。
このとき、一つ一つの操作が局所的には妥当に見えても、最終的な作業が成功するとは限らない。正しいメニューを開いても、その後に別の項目を選べば失敗する。目的のファイルを編集しても保存しなければ状態は残らない。処理途中で誤ったアプリケーションを操作しても、最後に自然な完了報告を生成することはできる。文章だけを評価すると、このような失敗を見逃す。
OSWorld のような評価では、最終的に計算機が要求された状態へ到達したかを調べることができる。保存されるべきファイルが存在するか、設定値が変更されているか、アプリケーション内の対象データが要求どおりになっているかといった、AI の発話とは独立した状態を判定材料にできる。
| 評価対象 | 言語モデル中心の評価 | エージェント中心の評価 |
|---|---|---|
| 入力 | 質問、文章、問題文などを与える。 | 作業指示に加えて、現在の画面や外部環境の状態を与える。 |
| 出力 | 文章、選択肢、コードなどを生成する。 | 複数段階の操作を実行し、外部環境を変更する。 |
| 主な評価対象 | 生成された回答が正しいかを判定する。 | 処理終了後の外部状態が要求された状態になったかを判定する。 |
| 典型的な失敗 | 事実誤認、誤答、不適切な文章などが生じる。 | 途中操作の誤り、対象の取り違え、保存漏れ、意図しない外部変更などが生じる。 |
| 必要な oracle | 正解データ、参照文書、人間の評価などを使う。 | ファイル、設定、アプリケーション状態などを直接検査する評価手続きを使える。 |
ここでは、AI の能力を測る単位そのものが変わっている。質問への一回答ではなく、「初期状態から目標状態へ到達するまでの一連の行動」が評価単位になる。途中で何を考えたかより、許可された操作の範囲内で最終状態を実現できたかが直接的な判定材料になる。
この違いは、AI エージェントの信頼性を考える上で大きい。言語モデルが誤った文章を生成した場合、通常は人間が読むまで外部状態は変化しない。AI エージェントが誤った操作を実行すれば、ファイル削除、設定変更、データ更新などがその時点で発生する可能性がある。評価対象を発話だけに置いたままでは、行動によって生じる失敗を十分に測れない。
6.4 行動を評価できるほど、外部状態が独立した証拠になる
HELM、SWE-bench、OSWorld を並べると、評価対象が段階的に外側へ広がっている。HELM では、モデルが返した出力について複数の性質を測る。SWE-bench では、出力されたコードによってリポジトリーが要求状態へ変わったかを確認する。OSWorld では、複数の操作を通じて計算機環境そのものが目標状態へ到達したかを確認する。
| 評価枠組み | 主な評価対象 | 外部証拠 | 検証できる範囲 |
|---|---|---|---|
| HELM | 言語モデルが生成した回答の複数の性質を評価する。 | 正解データ、評価指標、シナリオごとの測定値を使う。 | 指定した入力条件で、どの性質がどの程度成立するかを比較できる。 |
| SWE-bench | 実在するソフトウェア課題をコード変更によって解決できるかを評価する。 | 変更後のリポジトリーと評価テストを使う。 | 説明ではなく、実際のコードが要求した挙動を実現したかを確認できる。 |
| OSWorld | AI エージェントが複数段階の操作を通じて作業を完了できるかを評価する。 | ファイル、設定、アプリケーションなど実行後の環境状態を使う。 | 発話ではなく、計算機環境を要求された状態へ変えたかを確認できる。 |
この流れから得られる帰結は、AI が行動主体へ近づくほど、評価における外部状態の価値が大きくなるということである。AI が「正しく処理した」と説明したかどうかではなく、処理結果を AI とは独立した仕組みで確認できるからである。コードならテスト結果、ファイル操作なら保存された内容、データ処理なら処理後のレコード、業務ワークフローなら最終状態を oracle として利用できる。
これは内部説明が不要になるという意味ではない。失敗した理由を分析し、モデルを改善し、未知条件への挙動を予測するには内部分析が役立つ。一方、ある具体的な作業を採用してよいかという判断では、「AI がなぜそう考えたか」とは別に、「要求した結果が実際に成立したか」という証拠を持てる。内部説明と外部状態は、同じ不確実性を測っているわけではない。
6.5 外部状態を測れても、評価系そのものは完全ではない
実行結果を直接確認できるようになると、AI の信頼性が自動的に保証されるわけではない。外部評価にも、何を測るかという設計が残る。コード修正でテストが通っても、テストされていない既存機能が壊れている可能性がある。ファイルが生成されても、内容の事実関係が正しいとは限らない。業務データが所定の状態へ更新されても、その更新自体が業務上妥当だったかは別に確認する必要がある。
評価スクリプトも oracle の一種であり、その oracle が要求を十分に表現しているかという validation が必要になる。たとえば「ファイルが存在すること」だけを成功条件にすれば、空のファイルを作ってもテストには合格できる。「テストスイートが成功すること」だけを条件にすれば、テスト対象外の仕様変更は検出できない。評価を外部化しても、成功条件が粗ければ AI は粗い条件に対して成功するだけである。
このため、外部状態による評価は内部説明の代用品ではなく、信頼性を支える証拠を一種類追加する方法として考える方が正確である。モデル内部の解析は、どの特徴や規則へ依存しているかを調べる。ベンチマークは、指定した条件でどの程度性能を発揮するかを測る。実行後の状態確認は、個別の作業が要求された結果へ到達したかを判定する。それぞれが異なる問いへ答える。
AI が文章を返すだけの段階では、評価も主として文章や正答率へ向いていた。AI がコードを書き、アプリケーションを操作し、複数段階の業務を実行するようになると、評価対象もその行動によって変化した世界へ広げなければならない。AI の説明を信頼して「完了した」と判断するのではなく、AI から独立した外部状態によって完了を確認する構造が必要になる。
ただし、この評価を導入前に一度実施しただけでは、将来の利用まで保証できない。モデルの版、入力データ、外部 API、アプリケーション、業務規則のいずれかが変われば、以前確認した評価条件と現在の運用条件に差が生じる。AI の評価が外部状態へ広がるほど、次に必要になるのは、その検証を導入時の一回限りの試験ではなく、運用中に繰り返す仕組みとして設計することである。
7. 検証は導入前の関門ではなく、運用中のループになる
AI システムが導入前の評価で要求を満たしたとしても、その結果を将来の運用へ無条件に延長することはできない。評価で確認できたのは、特定のモデル、入力データ、外部サービス、評価指標、業務条件を組み合わせた時点での振る舞いだからである。モデルを変更しなくても、利用環境のどれか一つが変われば、導入時に確認した条件と現在の条件の間に差が生じる。
従来のソフトウェアでも、導入後の監視や保守は必要だった。サーバー負荷、依存ライブラリー、外部 API、データベース、利用者数などが変化すれば、以前正常に動いていたシステムでも障害を起こす。AI では、これらに加えて、入力データの分布やモデルの振る舞いそのものが性能へ直接影響する。導入時と同じプログラムを実行していても、入力される内容が変われば精度や失敗の種類が変化し得る。
たとえば、問い合わせ分類 AI を過去 1 年分の問い合わせデータで評価し、十分な精度を確認して導入したとする。その後、新製品が追加されれば、それまで存在しなかった問い合わせが入力される。業務規則が変更されれば、以前は正しかった回答が現在は誤りになる。参照している外部データベースの構造が変われば、モデルの判断自体が適切でも取得結果を誤る可能性がある。導入時の評価値が変化していなくても、その値を得た条件の方が失われている場合がある。
| 変化する対象 | 導入時に確認できた状態 | 運用中に起こり得る変化 | 生じる失敗 |
|---|---|---|---|
| 入力データ | 評価データと同程度の入力について性能を確認している。 | 新しい商品、利用者、文書形式、表現などが追加される。 | 評価時には少なかった入力で誤答が増えても、過去の平均精度からは把握できない。 |
| 業務規則 | 導入時点の規則に基づいて正答条件を定めている。 | 制度、社内ルール、承認条件などが変更される。 | 過去には正解だった回答や処理が、現在の業務では誤りになる。 |
| 外部サービス | 特定の API、データベース、アプリケーションとの接続を確認している。 | API の仕様、返却データ、画面構成、認証方法などが変更される。 | モデルの判断が正しくても、外部操作やデータ取得で失敗する。 |
| モデル | 特定のモデルと版について評価結果を得ている。 | モデル更新、推論設定変更、プロンプト変更などが行われる。 | 同じ入力でも出力傾向や失敗条件が変化する可能性がある。 |
| 利用方法 | 想定した権限と操作範囲で評価している。 | 利用範囲が広がり、新しいツールや業務へ接続される。 | 低リスクだった誤りが、外部状態を変更する重大な失敗へ変わる。 |
この表で共通しているのは、システムそのものが壊れなくても、評価結果の成立条件が壊れるという点である。導入時に 95% の精度を確認していても、その数値はモデルだけに貼り付いた永久的な属性ではない。どのデータを使い、どの時点の業務規則に従い、どの外部環境で測定したかという条件と組み合わせて初めて意味を持つ。
7.1 評価結果には有効な条件がある
第 4 章では、評価データで高得点を取っても、評価条件の外で同じ性能を維持するとは限らないことを確認した。運用では、この問題が時間方向にも広がる。導入時には評価対象と利用環境が十分に近かったとしても、半年後、一年後までその関係が維持される保証はない。システムが同じであっても、周囲の環境が変化すれば、過去の評価結果が現在の利用条件を代表しなくなる。
この違いを明確にするには、性能値と、その性能値が成立した条件を一緒に管理する必要がある。「正答率 95%」だけを記録するのではなく、どのモデルの版を使い、どの評価データに対して、どの時点の正解基準で測定し、どの入力カテゴリーで失敗が多かったかまで残す。そうすれば、運用条件に変更が生じたとき、以前の証拠をそのまま利用できる部分と、再評価が必要な部分を分けられる。
たとえば、モデルを変更せずにプロンプトだけ変更した場合でも、そのプロンプトが出力形式や判断手順へ影響するなら、以前の評価結果を完全には引き継げない。参照データだけを更新した場合も、そのデータが回答内容を決定するなら validation の対象になる。AI システムでは、モデルファイルだけを版管理しても、実際の振る舞いを再現するには情報が不足する場合がある。
| 記録対象 | 記録する理由 | 変更時に確認すること |
|---|---|---|
| モデルと版 | 評価した推論系を特定できるようにする。 | モデル更新後にも既存評価が成立するかを再確認する。 |
| プロンプトと設定 | 同じモデルでも指示や推論設定によって出力が変わるため記録する。 | 変更が評価指標、禁止事項、出力形式へ影響しないかを確認する。 |
| 評価データ | どの入力範囲について性能を確認したのかを特定する。 | 現在の利用入力と評価データの差が拡大していないかを確認する。 |
| 正解基準 | 何を正答として採点したかを再現できるようにする。 | 制度や業務規則の変更によって正解条件が変わっていないかを確認する。 |
| 外部依存 | API、データベース、アプリケーションなど評価時の環境を特定する。 | 外部仕様変更によって処理結果や失敗条件が変わっていないかを確認する。 |
このような記録がなければ、性能低下を発見しても何が変わったのかを切り分けにくい。モデル更新が原因なのか、利用者の入力が変わったのか、参照データが変わったのか、評価基準そのものが古くなったのかを区別できないからである。運用中の検証では、現在の性能を測ることだけでなく、評価条件のどこが変化したかを追跡できることが必要になる。
7.2 リスク管理もライフサイクル全体へ広がる
NIST の「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」は、生成 AI に固有または顕著なリスクを、設計、開発、利用、評価を含むライフサイクル全体で管理するための枠組みとして整理している[14]。この考え方では、導入前の評価で安全性を確認して終了するのではなく、実際の利用を通じて現れる問題も継続的な管理対象になる。
導入前には、想定した入力と失敗条件を使って評価する。しかし、実運用では想定していなかった入力や利用方法が現れる。利用者がどのような指示を与えるか、他のシステムとどのように組み合わせるか、生成物を誰がどの目的で使うかは、実際に運用しなければ分からない部分が残る。事前評価で未知だった失敗が、運用ログやインシデントによって初めて観測されることもある。
その失敗を単発の事故として処理するだけでは、検証の循環にはならない。失敗例を収集し、どの条件で発生したかを分析し、その条件を新しい評価ケースへ追加する必要がある。評価ケースを増やした後、修正したモデルやシステムがそのケースを解決したかを確認し、既存の正常動作を壊していないかも再確認する。この循環によって、運用中に得た知識が次の評価へ戻る。
ソフトウェアの回帰テストと似ているが、AI では「以前失敗した入力を再度試す」だけでは不足する場合がある。入力表現を少し変えた場合にも同じ失敗が起きるのか、同じ種類の別の入力にも弱点が存在するのかを調べる必要がある。一件の誤答を修正するのではなく、その誤答を生んだ失敗条件の範囲を推定し、評価対象を広げなければならない。
7.3 TEVV は一回の試験ではなく、証拠を組み立てる活動になる
NIST は 2026 年 8 月、AI の Test, Evaluation, Verification, Validation を扱う「TEVV-Athlon Framework for Evaluating AI Systems」の初期公開案を公表した[15]。対象には従来型の機械学習システムだけでなく、大規模言語モデル、マルチモーダルモデル、AI エージェントも含まれている。
ここで注目すべきなのは、AI 評価を一種類の共通試験へ集約する方向ではなく、利用目的やリスクに応じて測定対象と評価方法を構成する方向で整理している点である。画像分類モデル、文章生成モデル、計算機を操作する AI エージェントでは、失敗の形が異なる。同じ正答率という指標を適用しても、必要な安全性や利用可能性を同じようには評価できない。
AI エージェントであれば、最終的な作業成功率だけでなく、許可されていない操作を実行しないか、失敗した場合に途中で停止できるか、外部状態を意図せず変更しないかといった観点が加わる。生成 AI であれば、正確性だけでなく、根拠のない情報生成、機密情報の扱い、利用者による誤用なども利用条件によって評価対象になる。何を測るべきかは、AI という技術分類だけでは決まらず、その AI に何を任せるかによって変わる。
| AI の利用形態 | 主な成果物 | 評価する対象 | 運用中に追加して追跡するもの |
|---|---|---|---|
| 分類・予測 | ラベル、数値、確率などを出力する。 | 精度、誤差、カテゴリー別性能、頑健性などを測る。 | 入力分布の変化、カテゴリー別失敗率、正解基準の変更を追跡する。 |
| 文章生成 | 回答、要約、報告書などを生成する。 | 事実性、指示遵守、禁止事項、根拠との一致などを確認する。 | 新しい誤情報パターン、参照データの更新、利用目的の変化を追跡する。 |
| コード生成 | コードや設定変更を生成する。 | テスト、静的解析、要求適合性、既存挙動の維持を確認する。 | 依存ライブラリー、実行環境、既存テスト、要求仕様の変化を追跡する。 |
| AI エージェント | 複数段階の操作によって外部状態を変更する。 | 最終状態、操作権限、途中失敗、安全条件、停止能力を確認する。 | 外部ツールの仕様、許可範囲、異常操作、回復可能性を追跡する。 |
この構造では、TEVV は「AI に合格証を与える試験」というより、特定の利用目的について信頼判断に必要な証拠を組み立てる活動になる。モデル評価、システムテスト、実環境での validation、運用ログ、インシデント分析は、それぞれ異なる証拠を提供する。どれか一つが十分に高得点だから、他の確認を省略できるわけではない。
7.4 検証は要求から再評価までを循環する
運用中の検証を具体的な工程として見ると、要求定義、事前評価、導入、監視、変化検出、再評価という循環になる。最初に何を成功とするかを定め、その要求を評価可能な条件へ落とす。導入後は、その条件が維持されているかを監視し、モデルや環境が変化した場合には、影響する評価を再実行する。
| 工程 | 実施すること | 次の工程へ進む条件 |
|---|---|---|
| 要求定義 | 成功条件、禁止事項、性能条件、権限、失敗時の処理を定める。 | 何を測れば要求を確認できるかが定義されている。 |
| 事前評価 | 想定する入力と環境で性能、失敗条件、安全性を測定する。 | 採用基準を満たし、未確認範囲が許容できる。 |
| 導入 | 評価済みの構成を実際の利用環境へ配置する。 | 評価時との差分を把握し、監視対象を特定できている。 |
| 監視 | 性能、入力傾向、失敗、外部依存、モデルや設定の変更を追跡する。 | 評価結果の成立条件に影響する変化を検出できる。 |
| 変化検出 | 新しい失敗や環境変更が、既存の証拠へ与える影響を判断する。 | どの評価を再実行すべきかを特定できる。 |
| 再評価 | 変更された条件を加えて評価し、利用可能範囲を更新する。 | 新しい証拠をもとに継続利用、制限、停止を判断する。 |
循環の中には、正常時の性能測定だけでなく、失敗したときの処理も含める必要がある。AI エージェントで誤った操作を検出したとき、単にエラーとして記録するだけでは、外部状態の変更を止められない。一定の異常を検出したら追加操作を停止する、権限を限定する、人間の承認を要求する、可能な操作では以前の状態へロールバックするといった制御が必要になる。
この停止条件は、性能評価とは異なる役割を持つ。平均的には高性能な AI でも、許容できない種類の失敗を一度起こせば重大な損害につながる用途がある。その場合、「平均正答率 99%」より、「この操作だけは自動実行しない」「この条件では必ず人間へ戻す」といった境界の方が信頼性へ直接効く。運用設計では、AI が何をできるかだけでなく、どこから先をできないようにするかも評価対象になる。
7.5 信頼の根拠は、過去の合格から現在有効な証拠へ変わる
一回限りの検証では、信頼の根拠は「導入時に試験へ合格した」という過去の出来事になる。しかし、モデル、データ、環境、利用目的が変化するシステムでは、その証拠が現在も有効かを確認しなければならない。以前の評価結果が存在することと、現在の運用条件をその評価結果が支えていることは別である。
たとえば、半年前に実施した評価で高い性能を確認していても、その後にモデルを更新し、プロンプトを変更し、新しい外部ツールへ接続していれば、当時の評価が現在のシステム全体をどこまで支えるかは限定される。変更していない部分については過去の証拠を再利用できるかもしれないが、変更によって影響を受ける部分は新しい証拠が必要になる。
この意味で、検証可能性は製品に一度付与される静的な属性ではない。どの要求について、どの条件で、どの証拠を取得し、その証拠が現在も有効かを追跡できるという運用上の能力である。未知の失敗が見つかれば評価項目を更新し、環境が変われば再評価し、証拠が不足した領域では利用範囲を狭める。この更新を続けることで、AI の振る舞いが変化しても信頼できる境界を維持できる。
内部を完全に説明できない AI を扱うとき、この循環には特に意味がある。内部理解だけでは将来のすべての振る舞いを予測できないため、実際の運用から得られる失敗例や条件変化を評価系へ戻す必要がある。検証が導入前だけで終われば、運用中に得た新しい情報が信頼判断へ反映されない。
AI の信頼性を支えるのは、「このモデルは以前の試験で優秀だった」という評価ではない。現在の利用条件について、何を確認済みとし、何が変化し、どの証拠がまだ有効で、どの部分を再評価する必要があるかを把握できることである。AI が変化する環境の中で使われる以上、検証もまた、要求、評価、監視、再評価を繰り返す動的な仕組みとして維持しなければならない。
ただし、この循環をどれだけ精密に設計しても、すべての用途で外部評価だけが十分になるわけではない。結果を正しく測れることとは別に、判断理由そのものを人間が理解できなければならない場面がある。特に、人の権利や重大な利益に関わる判断では、正答率や運用監視だけでは満たせない要件が残る。次に検討するのは、検証可能性を重視しても説明可能性が不要にならない理由である。
8. 検証可能性は、説明可能性を不要にしない
ここまで見てきたように、AI の内部判断を完全に説明できなくても、要求、評価データ、テスト、実行結果、監視を組み合わせれば、利用できる範囲を外部から限定できる。コード生成であればテスト結果を確認でき、AI エージェントであれば操作後のファイルや設定を検査できる。外部に観察可能な正解条件がある課題では、この方法によって内部理解の不足を補える。
しかし、この構造から「AI は結果だけ確認すればよい」という結論は導けない。外部評価が直接確かめられるのは、あらかじめ成功条件として定義した性質である。正答率を測れば正答率についての証拠が得られ、処理後の状態を検査すればその状態についての証拠が得られる。一方、なぜその判断をしたのか、その判断規則が制度上許容されるのか、判断を受けた人が異議を申し立てられるのかといった性質は、最終結果の正しさだけでは確認できない。
たとえば融資判断を考える。過去データを使った評価で高い予測精度を確認できたとしても、それだけでは個々の申請がなぜ否決されたのかは分からない。さらに、特定の属性を直接使っていなくても、それと強く相関する別の特徴が判断へ影響している可能性がある。平均的な予測性能が高いことと、個別判断の根拠が妥当であることは異なる評価対象である。
医療でも同じ区別が必要になる。診断支援モデルが一定の評価データで高い精度を示していても、ある患者についてなぜその診断候補を提示したのかを医師が検討できなければ、出力を診療判断へ組み込む際の制約になる。モデルの判断と患者の症状、検査結果、既知の医学的知見を照合する必要があるためである。最終的な正誤だけでなく、判断過程を人間が検討できること自体が利用条件になる場面がある。
Cynthia Rudin は、医療や刑事司法など重大な影響を持つ判断では、ブラックボックスモデルへ事後的な説明を付けることに依存するのではなく、可能な場合には最初から解釈可能なモデルを利用すべきだと論じている[16]。この主張が問題にしているのは、単に利用者が AI の仕組みに興味を持つかどうかではない。予測結果そのものに加えて、判断規則を検討できることがシステムに要求される用途が存在するという点である。
ここでは、説明が精度とは別の機能を持つ。ある判断が誤っていた場合、理由を確認できれば、入力データの誤り、判断規則の問題、適用条件の違いを切り分ける手掛かりになる。判断を受けた側から異議が示された場合にも、何を根拠として結果が出たのかを確認できなければ、判断を再検討する手続きそのものが成立しにくい。説明可能性は、モデルを理解するためだけでなく、判断を検査し、訂正し、責任を割り当てるためにも使われる。
| 用途の性質 | 外部検証によって確認しやすいもの | 外部検証だけでは不足しやすいもの | 必要になる追加手段 |
|---|---|---|---|
| 失敗を容易に検出・修正できる作業 | テスト、差分確認、再実行によって個別の失敗を検出できる。 | 大量の失敗が発生した場合の復旧コストや、未検出の失敗までは直接分からない。 | 監視、ロールバック、失敗率の管理によって利用可能な範囲を制御する。 |
| 正解を客観的に判定できる作業 | 外部 oracle によって生成結果を自動的に合否判定できる。 | oracle が実際の利用目的を十分に表しているかは別の問いとして残る。 | 要求との対応を validation し、評価条件そのものを確認する。 |
| 人の権利や重大な利益に関わる判断 | 平均性能、カテゴリー別性能、偏り、再現性などを測定できる。 | 個別判断の理由、異議申立ての根拠、判断規則の妥当性は結果だけでは分からない。 | 説明可能性、人間による再検討、手続き上の保障、責任主体の明確化が必要になる。 |
| 環境を自律的に変更する AI エージェント | 実行結果、監査ログ、操作権限、停止条件によって行動を外部から確認できる。 | そもそもどの目的や操作を AI に許可すべきかは実行結果からは決まらない。 | 目的、権限、承認条件、禁止操作を人間が事前に定義する。 |
この違いを整理すると、外部検証が強く機能するのは、正解条件を観察可能な状態として定義でき、失敗した場合にも結果を検出して戻せる課題である。コード変更であれば、テストに失敗した変更を採用せずに破棄できる。ファイル変換であれば、変換結果を比較して異常があれば元のファイルへ戻せる。このような作業では、AI の内部判断をすべて理解するより、出力と失敗を確実に捕捉する方が直接的な制御になる場合がある。
一方、人に対する判断では、処理後に単純に元へ戻せない場合がある。採用、融資、診断、司法判断などでは、判断を受けた時点で機会や権利へ影響が生じる。また、何を正解とするか自体に制度的な価値判断が含まれるため、単一の oracle を置いて自動的に合否を決めることも難しい。ここでは、平均的な性能だけでなく、判断理由を検討できることや、人間が判断を覆せる手続きまでシステムの要件に含める必要がある。
8.1 説明と検証は、異なる問いへ答える
説明可能性と検証可能性を対立する選択肢として捉えると、この違いを見失う。説明可能性が答えようとするのは、モデルや個別判断がどのような根拠によって成立したのかという問いである。検証可能性が答えようとするのは、定めた条件の下で要求した振る舞いが実際に成立したかという問いである。両者は一部重なるが、同じ証拠を集めているわけではない。
| 観点 | 説明可能性 | 検証可能性 |
|---|---|---|
| 中心となる問い | なぜこの判断や出力になったのかを問う。 | 要求した結果や制約が実際に満たされたかを問う。 |
| 主な対象 | モデル構造、利用した特徴、個別判断の根拠などを調べる。 | 入力、出力、実行結果、失敗条件、外部状態などを測る。 |
| 得られる証拠 | 判断を理解、分析、再検討するための情報を得る。 | 指定した条件でシステムが要求を満たしたかという証拠を得る。 |
| 単独では残る制約 | 判断理由を説明できても、実装や運用が要求どおり動くことまでは保証しない。 | 結果を確認できても、なぜその判断になったか、判断規則が妥当かまでは説明しない。 |
たとえば、単純なルールベースの審査モデルで「年収が基準値を下回ったため否決した」と完全に説明できても、その基準値自体が業務目的や制度要件に適合しているかは validation が必要である。逆に、複雑なモデルについて多数の評価データで公平性や精度を測定できても、個別の否決理由を説明できなければ、異議申立てへの対応には不足する。説明と検証は、一方を高めれば他方が不要になる関係ではない。
8.2 必要な証拠は、失敗したときに何が起きるかで変わる
どの程度の説明可能性を要求すべきかは、AI の技術方式だけでは決まらない。同じモデルでも、候補文の校正に使う場合と、患者の治療方針へ影響する場合では必要な証拠が異なる。違いを生むのは、誤った場合に何が起きるか、誤りを検出できるか、判断を取り消せるか、誰が影響を受けるかという利用条件である。
失敗を即座に検出でき、元の状態へ戻せる作業では、外部検証を中心に制御しやすい。AI がコードを誤って変更しても、テストで検出し、変更を採用しなければ実運用へ影響しない。誤りが検出可能で、採用前に止められ、ロールバック可能であるため、内部説明が不完全でもリスクを外側から抑えられる。
これに対して、誤りをすぐに観察できない判断では事情が変わる。将来の信用リスクを予測するモデルについて、個別判断が正しかったかは結果が確定するまで分からない。しかも一度融資を拒否すれば、後から予測が誤っていたと判明しても失われた機会を完全には戻せない。そのような用途では、事後的な正誤だけに依存せず、判断時点で利用した根拠や規則を検討できることの価値が大きくなる。
| 失敗時の条件 | 検証中心で制御しやすい場合 | 説明や人間判断の必要性が高まる場合 |
|---|---|---|
| 誤りの検出 | 出力直後に自動テストなどで誤りを検出できる。 | 正誤が将来まで確定せず、即座に判定できない。 |
| 結果の取消し | 誤った変更を採用せず、元の状態へ戻せる。 | 判断した時点で人の権利、機会、健康などへ影響が生じる。 |
| 正解条件 | テストや形式条件として明確に定義できる。 | 制度、倫理、個別事情を含み、単一の正解へ還元しにくい。 |
| 責任の所在 | 失敗した成果物を破棄すれば影響を限定できる。 | 誰が判断し、誰が再検討し、誰が説明するかを制度として定める必要がある。 |
この比較から、AI の利用可否をモデル性能だけで決められない理由が見える。技術的に同じ精度のモデルでも、ロールバック可能な作業と不可逆な判断では必要な制御が異なる。評価すべきなのはモデル単体ではなく、AI の出力がどの経路で現実へ作用し、失敗した場合にどのような回復手段が残るかまで含めたシステム全体である。
8.3 高リスク用途では、判断をやり直せる構造も必要になる
人の権利や重大な利益に関わる用途では、説明可能性だけを追加すれば十分というわけでもない。理由を提示できても、その判断を変更する権限を誰も持っていなければ、説明は結果を通知するだけで終わる。判断に異議を申し立て、入力情報の誤りを訂正し、人間が再検討し、必要なら結論を変更できる手続きまで存在して初めて、説明が実際の救済へ接続される。
この点では、技術的な説明と制度上の手続きが結び付く。AI がどの特徴を利用したかを分析できることは技術上の能力である。その説明を誰が確認し、利用者へどこまで提示し、異議があった場合に誰が再判断するかは運用や制度の設計である。モデルだけを改良しても、後者は自動的には成立しない。
高リスク用途に必要なのは、精度、説明、検証、人間の判断を一つにまとめることではなく、それぞれがどの失敗を防ぐのかを明確にすることである。精度評価は平均的な予測能力を測る。偏りの評価は特定の集団へ失敗が集中していないかを調べる。説明は個別判断を検討する材料を提供する。人間による再検討は、AI の判断をそのまま最終決定にしないための経路を作る。
8.4 説明できない部分ほど、外側の制約を明確にする
説明可能性と検証可能性を組み合わせると、AI システムの設計対象をより具体的に分けられる。モデル内部について十分な説明が得られる部分は、その説明を判断や原因分析へ利用できる。外部から明確に成否を測れる部分は、テストや実行結果によって検証できる。どちらでも十分に確認できない部分は、自動化の範囲を狭め、人間の承認や権限制限によって影響を抑える必要がある。
| 確認可能性 | 利用できる主な手段 | 設計上の対応 |
|---|---|---|
| 内部理由を十分に説明できる | モデル構造や判断根拠を分析する。 | 説明を原因分析、判断確認、異議申立てなどへ利用する。 |
| 結果を外部から明確に判定できる | テスト、参照値、実行後の状態を oracle として使う。 | 自動検証とロールバックを組み合わせ、採用前に失敗を除外する。 |
| 理由も結果も完全には確認できない | 限定的な評価と監視によって不確実性を把握する。 | 権限、利用範囲、承認条件を狭め、AI 単独で最終判断させない。 |
この分け方では、「ブラックボックスだから禁止する」「高精度だから自動化する」という一律の判断を避けられる。内部説明が弱くても、外部 oracle が強く、失敗を採用前に検出できる作業なら自動化できる範囲は広い。反対に、高精度であっても正誤をすぐに判定できず、判断が人の権利へ不可逆な影響を及ぼすなら、説明と人間による再検討を残す理由が強くなる。
AI の内部を完全に理解できないという事実から、二つの方向へ進むことができる。一つは、その不確実性を理由として利用を全面的に避ける方向である。もう一つは、確認できない範囲を明示し、外部評価、権限制限、監視、人間の判断によって利用境界を設計する方向である。現実の AI 利用で必要になるのは後者であり、その際にも説明可能性を要求すべき領域は残る。
検証可能性は、説明可能性の代替ではなく、説明だけでは覆えない不確実性を補う。説明可能性も、外部検証の代替ではなく、結果だけでは検討できない判断根拠を扱う。どちらを優先するかを一律に決めるのではなく、何を AI に任せ、失敗した場合に何が起き、どの証拠を使えば採否を判断できるかによって組み合わせを決める必要がある。
この整理をすると、人間に残る役割も明確になる。AI の内部で起きた計算をすべて追跡することが人間の仕事になるわけではない。どこまで説明を要求し、どこを外部検証へ委ね、どの判断だけは人間が引き受けるのかという境界を決めることが必要になる。次に見るのは、AI が生成、分析、実行を高速化するほど、この境界条件を決める仕事がなぜ人間側へ残るのかという点である。
9. 人間に残る仕事は、採用条件を決めることである
AI が文章、コード、設計案、判断候補を高速に生成できるようになると、人間の役割も変化する。以前は人間自身が作業の途中過程を担っていたため、何を考え、どの根拠で判断したかを作業の流れの中で把握しやすかった。AI が途中工程を代行すると、その過程を人間が逐一追跡することは難しくなる。一方で、何を目的とし、どの条件を満たせば結果を採用してよいかという判断までは自動的には消えない。
既稿「AI に任せる前に、人間が残すべき判断」では、AI へ作業を渡す前に、何を問題として扱うのか、どの判断軸を使うのか、どの領域を任せないのかを人間が決める必要を整理した[17]。この順序には理由がある。AI が出力を生成した後で評価基準を考えると、その出力に引きずられて採否条件まで変わる可能性があるからである。何を成功とするかが先に定義されていなければ、生成された候補を評価する oracle も作れない。
たとえば、既存システムを AI で改修する場合、「コードが動くこと」だけを成功条件にすると、既存仕様の変更や互換性の破壊を見逃す可能性がある。先に「既存挙動を維持する」「この機能だけを変更する」「この性能条件を満たす」といった採用条件を定めておけば、AI がどのような実装を生成しても、その条件に照らして採否を判断できる。生成方法と評価基準を分離することで、AI の出力が判断基準そのものを決める状態を避けられる。
9.1 AI が作るのは候補であり、現実へ接続するのは採用判断である
既稿「AI の答えは、採用されたときに責任になる」では、AI が出力した候補と、人間や組織がその候補を採用する判断を分けた[18]。この区別は、AI の内部を完全に説明できない状況ほど重要になる。AI が生成した文章やコードは、それだけでは現実の制度、製品、公開情報、業務処理を変更しない。誰かがそれを正しいと判断し、公開、実行、反映、承認した時点で初めて外部状態へ作用する。
この境界を明確にすると、責任の対象も整理できる。AI が候補を生成したこと自体より、その候補についてどの確認を行い、何を未確認のまま許容し、なぜ採用したかが問われる。AI が内部でどのような推論をしたかを完全に再構成できなくても、採用側は自分が使用した証拠と判断基準を記録できる。
| 段階 | AI が担えるもの | 人間や組織が決めるもの | 境界が曖昧な場合の失敗 |
|---|---|---|---|
| 問題設定 | 与えられた問いを分析し、候補となる論点や方法を提示する。 | 何を解決対象とし、何を対象外とするかを決める。 | AI が扱いやすい問いへ問題そのものが変形される。 |
| 候補生成 | 文章、コード、設計、判断候補などを生成する。 | 候補に必要な制約、禁止事項、要求を事前に定める。 | 生成しやすさが採用条件の代わりになる。 |
| 検証 | テスト実行、比較、検索、形式確認などを補助できる。 | 何を証拠として十分とみなすかを決める。 | 確認できた項目だけで、確認していない部分まで正しいと判断する。 |
| 採用 | 採用候補を提示し、理由を整理できる。 | 残る不確実性を許容して現実へ反映するかを決定する。 | AI の推奨がそのまま組織の意思決定として扱われる。 |
AI の出力と採用判断を分けると、「AI がそう言ったから採用した」という説明では足りないことも明確になる。必要なのは、採用時点で確認可能だった証拠をどこまで調べ、何が未確認で、それでも採用する理由が何だったかである。モデルの説明可能性が不十分な場合でも、採用判断についての説明可能性まで失う必要はない。
9.2 生成能力が増えるほど、検証できる量が制約になる
既稿「この物量の文章を、一体誰が検証できるのか」では、AI によって生成可能な文章量が増えても、一次資料を読み、事実を照合し、反例を探し、誤りを訂正する人間の処理能力は同じ速度では増えないことを論じた[19]。この非対称性は文章だけに限らない。コード、設計書、テストケース、分析結果も、生成する速度と検証する速度が一致するとは限らない。
生成前の工程がボトルネックだった時代には、候補を作ること自体に大きなコストがかかった。そのため、人間が検証できる量よりはるかに多くの候補が短時間で現れる状況は起こりにくかった。AI によって生成コストが下がると、この制約が外れる。候補数を 10 倍、100 倍に増やせても、一次資料、実環境、業務規則との照合能力が同じ比率で増えなければ、未検証の候補だけが蓄積する。
このとき、「AI をもっと使えば処理量が増える」という期待は途中までしか成立しない。全体の処理能力は、最も遅い工程によって制約される。生成が十分に高速になれば、次の制約は検証へ移り、さらに検証を自動化すれば、その oracle を設計する工程や最終的な採否判断が制約になる。
| 工程 | AI によって高速化しやすい部分 | 残りやすい制約 |
|---|---|---|
| 文章生成 | 草稿、要約、比較案を大量に生成できる。 | 出典確認、事実照合、主張と文献の対応確認が残る。 |
| コード生成 | 実装案、修正案、テスト候補を短時間で作れる。 | 既存仕様、互換性、回帰、運用条件の確認が残る。 |
| 設計 | 構成案や代替案を多数提示できる。 | どの制約を優先し、どのトレードオフを受け入れるかの判断が残る。 |
| 調査 | 関連資料や論点候補を広く探索できる。 | 一次情報の確認、情報の信頼性、結論の射程管理が残る。 |
この構造では、人間の仕事を単純に「AI の出力を全部確認すること」と定義すると、生成量が増えた時点で破綻する。必要なのは、すべての候補を同じ密度で読むことではなく、どの部分を機械的に検証でき、どの部分に人間の判断を集中させるかを設計することである。検証可能な条件を先に増やせば、AI が生成する量を増やしても、人間が確認すべき範囲を限定できる。
9.3 ソフトウェア開発では、ボトルネックが実装から仕様選択へ移る
既稿「AI モダナイゼーションはなぜ仕様選択と検証で止まるのか」では、既存システムの解析やコード変換を AI が高速化すると、プロジェクト全体の制約が仕様選択、データ照合、受入試験、移行判断へ移ることを扱った[20]。これは、生成能力と採用条件の関係を具体的に示している。
たとえば、古い言語で書かれたシステムを新しい言語へ変換する場合、AI がソースコードを高速に書き換えられるようになっても、「何を同じ挙動として維持するか」はコードから一意には決まらない。長年運用されたシステムには、仕様書に明記されていない挙動、利用者が依存している例外処理、データ上だけに残る慣行が存在する場合がある。AI が実装を変換できることと、どの挙動を仕様として保存すべきかを判断できることは別である。
さらに、変換後のコードがコンパイルでき、既存テストを通ったとしても、移行成功とは限らない。既存テストがすべての重要な挙動を覆っている保証はなく、本番データの変換や外部システムとの接続も確認する必要がある。技術的な変換速度が上がるほど、プロジェクトの進行を決めるのは、コードを書く能力より、どの証拠が揃えば旧システムを停止してよいかという移行判断になる。
ここで見えているのは、AI が仕事を奪うか残すかという単純な分業論ではない。自動化されやすい工程が高速化すると、全体の制約が自動化されにくい次の工程へ移動するという構造である。実装が速くなれば検証が目立ち、検証を自動化すれば要求定義が目立ち、要求を形式化できても最後にはどのリスクを許容して採用するかという判断が残る。
9.4 人間が決めるのは、AI の外側に置く境界である
第 3 章以降で見てきたように、AI の内部について理解できる範囲には限界がある。第 4 章では高得点と正しい判断規則が一致しない可能性を見た。第 5 章では、正解を判定する oracle 自体を設計しなければならないことを確認した。第 6 章では実行後の外部状態を評価する方法を扱い、第 7 章ではその証拠を運用中に更新し続ける必要を見た。第 8 章では、外部検証だけでは足りず、用途によって説明や人間による再検討が必要になることを整理した。
これらを一つにつなぐと、人間の中心的な役割は、AI の内部処理をすべて理解することではなく、AI の外側に評価可能な境界を作ることだと分かる。何を入力として許可するか、どの操作まで実行させるか、何を成功とするか、どの失敗を許容しないか、どの証拠が揃えば採用するか、どの条件で人間へ処理を戻すかを定義する。
| 境界 | 人間が決める内容 | AI に任せられる内容 |
|---|---|---|
| 目的 | 何を達成し、何を達成対象から外すかを決める。 | 与えられた目的を達成する候補手段を探索する。 |
| 要求 | 維持すべき仕様、禁止事項、性能条件を定める。 | 要求を満たす候補を生成し、評価を補助する。 |
| 権限 | どのデータ、ツール、操作まで AI に許可するかを決める。 | 許可された範囲内で必要な操作を選択する。 |
| 採用条件 | どのテスト、証拠、承認が揃えば結果を受け入れるかを決める。 | 候補を生成し、必要な証拠の収集を支援する。 |
| 停止条件 | どの失敗、不確実性、条件変化で自動処理を止めるかを決める。 | 異常を検出し、定められた条件で処理を停止する。 |
この境界が明確なら、AI の内部を完全に説明できなくても利用範囲を制御できる。逆に、境界がなければ、モデルの説明可能性をどれだけ高めても、どの出力を採用してよいかは決まらない。AI が「この案が最適です」と説明できても、何をもって最適とするかを組織が定めていなければ、その説明を採用判断へ変換できないからである。
9.5 人間に残るのは、未確認事項を受け入れる判断である
現実のシステムでは、あらゆる条件を完全に検証してから利用することはできない。有限のテストでは未知の入力をすべて網羅できず、将来の環境変化も完全には予測できない。説明可能なモデルを使っても、実装、データ、運用上の失敗可能性は残る。最終的には、どこまで確認できたかと、何が未確認かを分けた上で、残る不確実性を許容して利用するかどうかを決めなければならない。
この判断は、AI が高性能になっても消えにくい。AI 自身に「この結果を採用してよいか」と質問することはできるが、その回答もまた AI が生成した候補であり、同じ採用問題の内側にある。採用条件まで AI の出力に任せると、「AI が自分で作った結果を、自分で定めた基準で評価し、自分で採用する」という閉じた構造になる。外部からの検証を成立させるには、少なくとも最終的な評価基準が AI の出力から独立している必要がある。
もちろん、採用判断の一部をルールとして自動化することはできる。全テストに合格したら自動マージする、一定の確信度を下回ったら人間へ戻す、禁止操作を検出したら停止するといった処理である。しかし、それらのルールを採用した理由、閾値をどこに置くか、どの失敗を許容しないかという設計判断は一段外側に残る。自動化を一段進めるたびに、判断が消えるのではなく、より上位の境界条件へ移る。
9.6 「分からなくても使える」を「何でも使える」にしない
本稿の出発点は、内部機構を完全に理解できなくても技術を利用できるという事実だった。食品保存では、有効な手順が科学的説明より先に成立した。機械学習では、予測性能と説明能力が別々の評価軸になった。AI ではさらに、個別判断を簡潔に説明しにくいモデルが外部環境を操作するようになり、内部理解だけでは信頼性を支えきれなくなっている。
しかし、「分からなくても使える」ことから「分からなくても何にでも使ってよい」とは導けない。利用を可能にするのは無理解そのものではなく、理解できない部分の外側に別の証拠を置けることである。正解を客観的に判定できるならテストを使い、実行結果を観察できるなら外部状態を使い、運用条件が変わるなら監視と再評価を行い、判断理由が必要な用途では説明可能性と人間による再検討を残す。
技術を信頼する根拠は、内部を完全に理解しているという一点から、複数の証拠を組み合わせる構造へ移っている。モデルの構造について分かっていること、評価データで確認したこと、実環境で観察したこと、運用中に監視していること、人間が最終的に引き受ける判断を分け、それぞれがどの不確実性を補っているかを明示する必要がある。
進捗バーは、内部で何が起きているかを説明しない。それでも利用者は、処理が進んでいること、終了したこと、失敗したことを外部から観察できる。AI が単なる進捗表示の背後にある処理よりはるかに複雑な判断と行動を担うようになったとき、必要なのは、その内部を分からないまま信じることではない。何が終われば成功なのか、途中で何が起きれば止めるのか、終了後に何を確認すれば採用できるのかを、AI の外側に定義しておくことである。
AI が高度になるほど、人間がすべての途中過程を追跡することは難しくなる。その一方で、何を要求し、何を証拠とし、どこまでを自動化し、どの不確実性を受け入れるかという判断の重要性は下がらない。理解可能性だけで支えきれない部分を検証可能性で補い、それでも残る不確実性について採用条件を決めることが、AI を使う側に残る仕事になる。
参考文献
- 落合陽一, 「#マタギドライヴに至る3部作まとめ 「進捗バーは理由を言わない」 #魔法の世紀 #デジタルネイチャー #マタギドライヴ」（2026-08-29）. https://note.com/ochyai/n/n1def9570b6be
- U.S. Department of Agriculture, National Agricultural Library, “How Did We Can? The Evolution of Home Canning Practices.” https://www.nal.usda.gov/exhibits/ipd/canning/about
- Institut Pasteur, “The early years 1847-1862.” https://www.pasteur.fr/en/about-us/early-years-1847-1862
- Leo Breiman, “Statistical Modeling: The Two Cultures,” Statistical Science, Vol. 16, No. 3, pp. 199-231 (2001). https://projecteuclid.org/journals/statistical-science/volume-16/issue-3/Statistical-Modeling–The-Two-Cultures-with-comments-and-a/10.1214/ss/1009213726.full
- Zachary C. Lipton, “The Mythos of Model Interpretability,” Queue, Vol. 16, No. 3 (2018). https://queue.acm.org/detail.cfm?id=3241340
- Finale Doshi-Velez and Been Kim, “Towards A Rigorous Science of Interpretable Machine Learning” (2017). https://arxiv.org/abs/1702.08608
- Robert Geirhos et al., “Shortcut learning in deep neural networks,” Nature Machine Intelligence, Vol. 2, pp. 665-673 (2020). https://www.nature.com/articles/s42256-020-00257-z
- Benjamin Recht, Rebecca Roelofs, Ludwig Schmidt and Vaishaal Shankar, “Do ImageNet Classifiers Generalize to ImageNet?,” Proceedings of the 36th International Conference on Machine Learning, PMLR 97, pp. 5389-5400 (2019). https://proceedings.mlr.press/v97/recht19a.html
- NASA Independent Verification and Validation Program, “IVV Overview.” https://www.nasa.gov/ivv-overview/
- Earl T. Barr, Mark Harman, Phil McMinn, Muzammil Shahbaz and Shin Yoo, “The Oracle Problem in Software Testing: A Survey,” IEEE Transactions on Software Engineering, Vol. 41, No. 5, pp. 507-525 (2015). https://discovery.ucl.ac.uk/id/eprint/1471263/
- Percy Liang et al., “Holistic Evaluation of Language Models” (2022). https://arxiv.org/abs/2211.09110
- Carlos E. Jimenez et al., “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (2023). https://arxiv.org/abs/2310.06770
- Tianbao Xie et al., “OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments” (2024). https://arxiv.org/abs/2404.07972
- Chloe Autio et al., “Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile,” NIST AI 600-1 (2024). https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- National Institute of Standards and Technology, “The TEVV-Athlon Framework for Evaluating AI Systems,” Initial Public Draft of NIST AI 200-2 (2026). https://www.nist.gov/artificial-intelligence/ai-research/tevv-athlon-framework-evaluating-ai-systems
- Cynthia Rudin, “Stop explaining black box machine learning models for high stakes decisions and use interpretable models instead,” Nature Machine Intelligence, Vol. 1, pp. 206-215 (2019). https://www.nature.com/articles/s42256-019-0048-x
- id774, AI に任せる前に、人間が残すべき判断（2026-06-21）. https://blog.id774.net/entry/2026/06/21/4912/
- id774, AI の答えは、採用されたときに責任になる（2026-06-26）. https://blog.id774.net/entry/2026/06/26/4925/
- id774, この物量の文章を、一体誰が検証できるのか（2026-07-30）. https://blog.id774.net/entry/2026/07/30/5160/
- id774, AI モダナイゼーションはなぜ仕様選択と検証で止まるのか（2026-07-29）. https://blog.id774.net/entry/2026/07/29/5158/