※この記事は、2026年8月にAIと一緒に作っている個人用の判断支援ツールを、実データで試した時の運用メモです。対象分野や個別の判断内容は伏せ、試験記録の残し方に絞って書いています。
しばらく前から、AIに手伝ってもらいながら、自分用の判断支援ツールを作っています。
データを読み込む。
条件ごとに評価する。
結果と判断理由を残す。
テスト用のデータでは動くところまで来たため、今回は実際のデータを使う試験へ進みました。
ここまで来ると、気になるのはツールの判断が当たるかどうかです。
ただ、実際に試してみると、その前に決めておかないといけないことがありました。
何回か実行した時、どの実行を正式な試験記録にするのか。
ここが曖昧なままだと、後で判明した現実の結果と見比べてから、一番都合のよい実行を選べてしまいます。
そこで今回は、失敗した1回目も消さず、最初に技術的な成功条件を満たした2回目を、現実の結果が判明する前に正式記録として固定しました。
ここで先に固定した中には、ツールが出した判断も含まれています。見ていないのは、その判断が正しかったかを後で照合するための現実側の結果です。
1回目は、判断内容を見る前に失敗した
最初の実行では、時刻情報の扱いに問題が見つかりました。
ツールが出した判断が良かった、悪かったという段階ではありません。
必要な時刻情報が、事前に決めていた条件を満たしていなかったため、技術的な失敗として止めました。
この時、単に設定を直してやり直すだけなら難しくありません。
失敗したファイルを消す。
問題を直す。
もう一度実行する。
二回目が動けば、そちらだけを残す。
開発中なら、これでよい場面も多いと思います。
ただ、今回は実データを使った試験です。
失敗した事実まで消してしまうと、後から見た時に、最初から問題なく動いたように見えてしまいます。
そのため、一回目は失敗として記録へ残しました。
再実行することより、あとから選べることが怖かった
失敗した後に修正して、もう一度試すこと自体が悪いわけではありません。
今回も、二回目の実行へ進んでいます。
問題になるのは、複数の実行結果と、後で判明した現実の結果を見比べてから、どれを正式な記録にするか決められる状態です。
たとえば、三回実行して、最も良く見えたものだけを採用する。
悪かった実行は、設定ミスや一時的な不具合として除外する。
良かった実行は、ツール本来の結果として残す。
これを無意識に繰り返すと、試験結果は少しずつ自分に都合のよい形へ寄っていきます。
しかも、AIに実装や確認を任せていると、やり直す理由も作りやすいです。
この入力が怪しい。
この条件は想定外だった。
もう一度実行した方が正確かもしれない。
それぞれの説明には、もっともらしい理由があります。
だからこそ、正解が分かってから人間が選ぶのではなく、どの実行を正式記録にするかを先にルール化する必要があると感じました。
最初に成功条件を満たした実行を固定した
二回目の実行では、事前に決めていた技術的な条件を満たしました。
ここでいう成功は、ツールの判断が正しかったという意味ではありません。
必要なデータがそろっている。
時刻情報が条件内にある。
入力と出力の対応を確認できる。
重複や欠損など、事前確認の項目を通っている。
まずは、試験対象として成立する状態になったという意味です。
そこで、二回目を正式な試験記録として固定しました。
その時に残したのは、画面に出た結論だけではありません。
- どの入力を使ったか
- いつ実行したか
- 事前確認を通ったか
- 監査用の記録が一致しているか
- どの実行が最初の技術的成功だったか
こうした情報も一緒に残しました。
ファイルには、内容が変わっていないか後から確認するための識別情報も付けています。
これで絶対に改変できなくなるわけではありません。
ただ、あとから別の実行へ差し替えれば、記録のつながりが変わります。
少なくとも、何も残さずファイル名だけを同じにするよりは、後から確認しやすくなりました。
失敗記録は、ツールの弱さを知るためにも必要だった
一回目の失敗は、判断精度とは直接関係ありません。
だから、精度だけを見たいなら除外してもよさそうに見えます。
でも、実際に使うツールとして考えると、時刻情報の不整合で止まったことも性能の一部です。
どれだけ判断ロジックが優秀でも、必要な時間内にデータをそろえられない。
入力の状態によって止まる。
確認に時間がかかり、正式な記録を残せない。
そうした問題が多ければ、実運用では使いにくいはずです。
成功した時の精度だけでなく、予定した日にどのくらい安定して試験を成立させられたかも見ないといけません。
失敗した一回目を残したことで、判断内容とは別の弱点も記録できました。
「正式記録にした」は、正しさの証明ではない
今回、二回目の実行を固定できました。
ただし、これはツールが完成したという話ではありません。
判断が正しいことを証明したわけでもありません。
実データを使った試験を、あとから選び直しにくい形で始められただけです。
以前、AIに検証まで任せたのに、「100%合格」という表示が間違っていたことがありました。
その時は、生成側と検証側が同じ勘違いを共有していました。
別の時には、AIに作らせた判断ツールが、自分でも理由を説明しにくいブラックボックスになっていました。
そこで、入力、判断条件、理由、時刻を後から追えるようにしたいと考えました。
今回は、そのさらに次の段階です。
確認項目を増やすだけではなく、現実の結果が判明する前に、どの実行を確認対象にするかを固定する。
これでようやく、後から精度や失敗原因を比べるための土台ができた気がします。
AIに試験まで任せるなら、人間側の逃げ道も先に塞いでおきたい
AIにツールを作ってもらうと、修正も再実行も速くなります。
失敗しても、その場で原因を聞き、コードを直し、もう一度試せます。
これは大きな利点です。
一方で、速くやり直せるほど、「もう一回だけ試す」が簡単になります。
その再実行が必要な修正なのか。
後で分かった結果に合わなかったためのやり直しなのか。
後からでは、自分でも区別しにくくなるかもしれません。
だから今回は、AI側へ厳しいルールを足すだけでなく、人間側にも選び直しにくい順番を置きました。
- 技術的な成功条件を先に決める
- 失敗した実行も消さない
- 最初に条件を満たした実行を固定する
- その後で現実の結果と照合する
AIが出した判断を疑うことは大事です。
ただ、それと同じくらい、判断を評価する自分が、正解を知ってから都合のよい試行を選ばない仕組みも必要でした。
今回固定できたのは、良い結果ではありません。
あとから都合よく変えにくい、最初の正式な試験記録です。
まずはこの記録を積み重ねてから、ツールが本当に使えるのかを判断したいと思います。
コメント