AI の判断を、見ていたデータごと残す。半年後の説明に耐える記録へ

TL;DR

設備の異常検知に AI を入れたあと、誤報が続くことがあります。原因が入力データ側にあるのか AI の判断側にあるのかを切り分けられないと、閾値を鈍らせるか自動判定を止めるくらいしか手がありません。AI の判断と、その判断が参照したデータ。この2つを一組で、後から書き換えれば分かる形で残す。そうすれば、誤報の切り分けも経緯報告も、経路をそのまま示して進められます。

閾値を鈍らせるか、その系統の自動判定を止めるか。誤報が続いたときにこの二択へ追い込まれるのは、記録が足りないからではありません。監視のヒストリアンにも保全管理システムにも日報にも、記録は残っています。足りないのは、AI がその判断を出したとき何を見ていたのか、という接続です。

誤報が出たとき、センサーと AI のどちらを疑うか

AI が何かを判断したとき、その背景にあるデータ（何を見ていたか）を一緒に残しておくことは、車のドライブレコーダーで「そのとき何が起きていたか」を記録しておくのと同じです。後から根拠を見返せれば、誤報の原因が AI の判断ミスなのか、センサーの異常のような入力データ側の問題なのかを見分けられます。

切り分けができれば、次の一手は決まります。センサーの値が異常だったのなら、計測系を点検します。データは正常だったのに判断を誤ったのなら、モデルの側を見直します。対応はまったく異なります。

ところが、AI の判断の記録と入力データが別々に残っていると、この切り分けに手間がかかります。時刻を頼りに突き合わせることになりますが、そのとき参照されたのがどの版のデータだったのか、取り込み後に補正が入っていないかまでは、たいてい追えません。

同じ問題は、誤報以外の場面でも顔を出します。

設備の故障や品質の異常が実際に起きて経緯報告書を書くとき、時系列の各行に「何を根拠にそう動いたか」を書き添えられるかどうかで、報告書の説得力が変わります。受託運転や委託業務で「誰の判断だったのか」が争点になるときも同じです。判断と、その判断が見ていたものが一組で残っていれば、経路をそのまま示せます。

今ある記録に、何が足りないのか

すでにある記録の弱点は、大きく2つです。

ひとつは、記録を作った本人が、後から書き換えられることです。悪意を疑う話ではありません。書き換えが可能な仕組みである以上、「書き換えていない」ことを口頭以外の方法で示す手段がない、という構造上の問題です。

もうひとつは、判断と入力が別々に残っていることです。両方あっても、そのとき実際に参照されたのがどれかは、時刻からの推測になります。

この2つを埋める方法が、AI の判断1件ごとに次の3点をそろえておくことです。

• 判断の内容を、ひとまとまりに固定する
• その判断が参照した入力データを、判断の記録の側に埋め込む
• その固定値を、作成者の側で書き換えられない登録先に登録する

既存の記録を置き換える話ではありません。いま動いている仕組みはそのままに、AI が判断を出した時点で1件ぶんの記録を別に残す、という足し方になります。

データではなく、AI の判断そのものを固定する

はじめに、どちらを固定するかという順序の話をします。

入力データにだけ固定をかけても、示せるのは元のデータと一致しているという事実です。必要ではありますが、半年後に問われるのはデータの一致ではなく、その日の判断がどうであったかという点になります。

そこで、判断そのものを固定します。「この日、この時刻に、こういう判断をした」という内容をひとまとまりにして、その内容からハッシュ値を計算しておく方法です。ハッシュ値は、元の内容から計算される固定長の値で、内容が1文字でも変われば別の値になります。後から判断を書き換えるとハッシュ値が合わなくなるため、「書き換えていない」ことを口頭ではなく照合で示せるようになります。

ただし、そのハッシュ値を判断の記録と同じ場所に置いたままでは、両方を作り直せてしまいます。計算したハッシュ値は、作成者の側で書き換えられない登録先——Lemma ではレジストリ——に登録します。ここまでやって初めて、受け取った側は登録された値と手元の記録を照合するだけで、発行元に問い合わせずに確かめられます。

ハッシュ値もレジストリも、情報システム部門には通じる言葉です。相談の入り口にできます。

「何を見て決めたか」を判断の記録に埋め込む

判断だけを固定しても、何を見て決めたのかという部分は空欄のままです。そこで、判断の記録を作る時点で、その判断が参照した入力データを一緒に埋め込みます。

作業としては、判断が確定した時点で、判断の内容と参照した入力を1件のまとまりとして登録します。人手を挟まず、AI を動かしている仕組みの側から自動で登録する形が基本です。確定した後で入力を後付けすると、そもそも何を見ていたかの証拠になりません。

こうしておくと、確認する側は判断の記録から入力へと遡れます。

AI の判断に「証拠」を紐付ける、2つのやり方

埋め込み方は2種類あります。現場で扱うデータは性質がまちまちなので、両方を混在させて使います。

埋め込み方	確認できること
登録済みのデータを指し示す	公表元のデータと突き合わせて、参照した入力の内容まで確認できる
入力のハッシュ値を併せて残す	参照した入力が、記録の作成後に変更されていないことを確認できる

上の形を使うには、入力データを先に登録しておく必要があります。気象庁の発表のように決まった経路で取り込む外部データは、取り込み処理のなかで登録まで済ませておくのが現実的です。一方、センサーから流れてくる生の値のようにその場で発生するデータは、事前登録が難しいので下の形で残します。この場合、値の控えは自社の記録に残しておきます。控えとハッシュ値が一致すれば、その値が記録した時点から変わっていないことを確かめられます。

どちらの形で残したかは記録上に現れます。報告や監査の場で「この入力は公表値と突き合わせられます」「こちらは記録の非改変までです」と区別して説明できるほうが、実際以上に強く見せるより通りやすいはずです。

震度5強の発表から、点検実施記録まで

災害対応を例に、記録が作られる順と、その記録を確かめる場面を分けて見ていきます。

記録は、出来事が起きるたびに1件ずつ

まとめて後から作るのではなく、その都度登録していきます。

1. 公式発表を取り込む。 気象庁の震源・震度情報を、取得した時点の姿のまま控え、その内容から計算したハッシュ値を、発表元を指し示す情報とともに登録します。取り込み処理に、登録を1段足す形です。

2. AI が判断を出す。 「震度5強の発表を受けて、対象区域の緊急点検を起動する」という判断を、1 の登録を指し示した状態で記録します。

3. 現場が点検を実施する。 実際に点検した記録を、2 の判断を指し示す形で登録します。

この3件が鎖のようにつながります。前の記録のハッシュ値を次の記録に含めるので、途中の1件だけを差し替えると、後ろの記録と合わなくなります。実施記録から遡れば、どの発表を受けて、いつ、何を根拠に起動したのかが一本の経路になります。

もう一例：センサー値を入力にした誤報

冒頭に挙げた異常検知も、形は同じです。振動センサーの値を入力に AI が異常と判断したなら、その時点で、判断の内容と、参照したセンサー値のハッシュ値を1件の記録として登録します。値の控えは自社の記録に残しておきます。

あとで誤報だとわかったとき、開くのはこの1件です。控えとハッシュ値が一致すれば、AI が見ていたのは確かにその値だったと言えます。値が異常だったのなら計測系を、値が正常だったのなら判断側を見ます。切り分けが、記録を開くだけで済みます。

確認が何度でもできると、AI を止めずに済む

登録は出来事ごとに一度で済み、確認は何度でも行えます。ここが効いてくるのは、誤報が出ても運用を止めずに直せるようになるからです。

冒頭に挙げた行き詰まり——原因を切り分けられないので、閾値を鈍らせるか自動判定を落とすしかない——は、判断とその入力が一組で残っていれば起きません。当たるべきところだけを直せます。

同じ経路が、次のような場面でそれぞれ効いてきます。

出動した直後。 「AI は何を見て起動したのか」を現場がその場で確認できます。誤報を疑う場合も、入力まで遡れば計測系と判断のどちらに当たるべきかの見当がつきます。

月次報告のとき。 委託元に出す報告書に確認の導線を添えられます。受け取った側は、原本の追加提出を求めずに自分で判定できます。

事故や異常が起きたあと。 経緯報告書の時系列に、各行の根拠を紐づけられます。「なぜその順で動いたか」を、記録で裏づけながら書けます。

監査のとき。 半年後でも一年後でも、実施記録から公式発表まで同じ経路を辿れます。

この4つが、同じ1本の記録でまかなえます。報告や監査のたびに証跡をかき集める作業がなくなり、「説明できないから任せられない」で止めていた範囲を、判断材料をもって広げていけます。

ここで確かめられるのは、その発表を参照して判断が下されたという接続の部分です。「気象庁が実際にそう発表した」かどうかは、辿った先の記録と発表元の公表物を突き合わせて確認します。

同じ組み立ては、他の業務にもそのまま当てはまります。受託運転や委託保守なら点検・保守・調整の作業イベント、製造の工程なら検査記録や計測値を、それぞれ発生の都度この形で残しておけば、受け取る側が同じように確かめられます。

入力側の記録に証明を重ねる形は、すでに公共インフラでも動いています。住民の活動記録に証明基盤を組み込んだ MizuDAkO の事例です。

受け取った側だけで、確かめられる

この形で残しておくと、記録を受け取った相手は、発行元に問い合わせずに自分で確かめられます。確かめられるのは次の3点です。

• AI が出した判断の内容が、記録された時点から変更されていないこと
• その判断が、どの入力を参照したか
• 参照先が登録済みの入力なら、その登録が存在すること

意味があるのは、報告書を信じてもらう必要がなくなることです。監査でも、事故の経緯報告でも、委託元との整理でも、渡した相手が記録の整合をその場で判定できます。原本の追加提出や、電話での照会を待つ必要がありません。ハッシュ値だけを併せた入力——センサー値のように控えを自社に置くもの——については、その控えを添えれば、受け取った側は同じように照合できます。

記録が扱うのは判断の内容と経路であって、判断の当否そのものを評価するものではありません。そこは現場の領分です。入力についても同様です。登録済みの入力なら公表元まで辿れるところまで、控えを手元に置く入力なら控えとの一致を確かめられるところまでが、記録の役目になります。

「AI は正しい」ではなく「経路は残っている」と言う

AI に判断を任せる範囲は、今後さらに広がっていきます。そのとき現場に求められるのは、「AI は正しい」と信じてもらうことではないはずです。どういう入力を見て、いつ、何を決めたのか。その経路を後から確かめてもらえる状態にしておく。それが、経緯報告や委託元とのやり取りを支える土台になると考えています。

重要インフラや製造業での適用は製造・基幹インフラに、AI 導入全般としての整理は AI 導入（業種横断）にまとめています。