※この記事は、2026年7月に自分のローカル環境で試したAI運用の記録です。
最近、AIに長い文字起こしを読ませて、あとで使えそうな候補メモへ変換する仕組みを試しています。
ただ要約するだけではなく、元データ、生成したメモ、処理結果を記録した一覧、検証用の処理まで残す形です。
ここまで用意すれば、かなり安全に回せると思っていました。
実際、最初の試験結果はきれいでした。
生成されたメモには「全文を分析した」と書かれている。
処理結果の一覧には success と記録されている。
検証処理も「100%合格」と表示している。
これだけ並ぶと、さすがに大丈夫そうに見えます。
ところが、別の監査で元データと生成処理、検証処理を照らし合わせてもらうと、全文処理を証明できていないことが分かりました。
今回は、AIが間違えたというだけの話ではありません。
生成側と検証側が同じ勘違いをしていたため、チェックする仕組みまで間違った成功判定を出していた。
これ、かなり危ないなと思いました。
成功を示す表示は、きれいにそろっていた
今回作ろうとしていたのは、長い文字起こしをAIに読ませて、再利用しやすい候補メモへ変換する流れです。
大まかには、次のような形でした。
- 元の文字起こしを読む
- 要点や不確実な点を候補メモへまとめる
- どのファイルを処理したか記録する
- 必要な項目や出典がそろっているか検証する
いきなり大量処理へ進まず、まず2件で試しました。
生成された候補メモは、それぞれ元資料に合わせた内容になっていました。
見出しもある。
出典への参照もある。
タイムスタンプらしき記録もある。
処理結果も成功になっている。
さらに検証用の処理を動かすと、ハッシュ、文字数、必要な見出し、タイムスタンプ、内容の違いまで確認したうえで、100%合格したように表示されました。
人間から見ると、かなり安心しやすい状態です。
少なくとも自分は、ここまで数字と確認項目が並んでいたら、そのまま次の件数を増やしたくなります。
元データへ戻ると、全文処理を証明できなかった
念のため、別の監査で元の文字起こしと生成・検証処理を確認してもらいました。
すると、最初の成功判定とは違う結果が出ました。
生成された候補メモで確認できた最後の参照時刻を、元の文字起こしの終端と比べると、処理範囲の上限は2件で約47%と56%でした。
これは「実際に47%と56%だけ読んだ」と断定できる数字ではありません。
ただ、少なくとも「全文を処理した」という主張を、その候補メモから証明できる状態ではありませんでした。
もう一つ大きかったのが、処理文字数の扱いです。
自分が確認したかったのは、元の文字起こしを何文字AIへ渡し、どこまで処理したかでした。
ところが記録されていた処理文字数は、AIが読んだ入力の長さではなく、生成後の候補メモの長さでした。
入力と出力は、どちらも文字数で表せます。
しかし意味は全く違います。
出力が3,000文字あることは、5万文字の元データを全部読んだ証拠にはなりません。
ここを同じ数字として扱ってしまうと、見た目だけは立派な処理記録ができてしまいます。
検証処理は、間違った数字を正しく確認していた
では、なぜ検証処理は100%合格を出したのか。
検証そのものが何もしていなかったわけではありません。
元ファイルが存在するか。
ファイルのハッシュが一致するか。
必要な見出しがあるか。
候補メモに指定した言葉が含まれているか。
こうした確認は実際に行っていました。
問題は、確認している対象です。
たとえば処理文字数については、「元データを何文字読んだか」ではなく、「生成された候補メモの長さと記録上の数字が一致するか」を確認していました。
タイムスタンプについても、元の文字起こしにその時刻が本当に存在するかではなく、候補メモの中にタイムスタンプらしい記号があるかを見ていました。
つまり、決められた形式になっているかは確認していた。
しかし、全文を読んだかどうかは確認していなかった。
検証処理は壊れていたというより、間違った問いにきちんと答えていたのだと思います。
その結果、「形式がそろっている」を「内容まで正しく処理できた」に読み替えてしまいました。
生成側と検証側が同じ前提だと、自己採点になる
AIに何かを作らせる時、別のAIや検証処理にもチェックさせれば安心できるように感じます。
自分も、生成と検証を分ければ一段安全になると思っていました。
ただ、担当を二つに分けるだけでは足りませんでした。
生成側が「この数字を処理文字数と呼ぶ」と決める。
検証側も、その数字を同じ意味だと思って確認する。
すると、両方が一致しているので合格になります。
でも、最初の定義が間違っていれば、二つの処理が同意しても正しくはなりません。
学校のテストで、自分が書いた答えを自分の解答例と照らして丸を付けているようなものです。
見た目はダブルチェックでも、実際には自己採点に近い。
ここで大事なのは、別のAIを使えば必ず正しくなる、という話ではないと思います。
同じ指示、同じ中間結果、同じ思い込みを引き継げば、別のAIでも同じ結論になる可能性があります。
必要なのは、生成側の申告を前提にせず、元データへ戻って別経路で計算し直すことでした。
「100%」の前に、何を100%確認したのかを見る
今回いちばん反省したのは、100%という数字の強さです。
100% valid。
全件成功。
エラーなし。
こうした表示が出ると、確認が終わった気になります。
でも、本当に見るべきなのは数字そのものではありません。
何を分母にした100%なのか。
元データの全範囲なのか。
必要項目の存在なのか。
ファイル形式なのか。
検証処理が確認できる範囲だけなのか。
今回の100%は、検証処理に書かれていた条件を全部通った、という意味でした。
その条件が、こちらの知りたかった「全文を処理したか」と一致していなかった。
数字が間違っていたというより、100%の対象がズレていたわけです。
次からは、入力範囲と出力を分けて残す
この試験は、そのまま件数を増やさずに止めました。
失敗したファイルも削除していません。
どこで成功に見えたのかを後から確認できるように、試験結果として残しています。
次に試す時は、少なくとも次の項目を分けて記録するつもりです。
- 元データ全体の文字数と行数
- 実際に処理へ渡した文字範囲
- 処理した入力文字数
- 生成された出力文字数
- 元データに実在する参照位置
- 全体に対する処理範囲
そして、最初から複数件を回しません。
まず1件だけで、先頭から末尾まで範囲が途切れていないか確認する。
検証側では、生成側が書いた数字をそのまま使わず、元データから計算し直す。
そこで一致してから、少しずつ件数を増やす。
自動化としては遠回りに見えますが、間違った成功判定のまま大量処理するよりは、たぶんずっと早いです。
AIの検証結果にも、受け入れ検査が必要だった
これまで自分は、AIが作った成果物には確認できる証拠を付けてもらった方がいいと考えていました。
その考え自体は変わっていません。
ただ今回は、その一段先が必要だと分かりました。
証拠があるか。
検証処理を通ったか。
成功と表示されたか。
それだけではなく、その検証は自分が知りたかったことを本当に確認しているのか。
AIに検証まで任せるなら、検証結果を受け取って終わりではなく、検証器の問いも一度は確認する必要があります。
特に最初の試験では、きれいな100%より、rawへ戻れることの方が大事なのかもしれません。
生成側と検証側が同じ間違いをしても、元データまで同じ間違いをするわけではありません。
だから、最後に戻れる場所だけは残しておきたいと思います。
コメント