※この記事は、2026年8月時点でAIと一緒に自作ツールを育てている途中の運用メモです。ツールはまだ実践投入前で、今回書いているのは完成報告ではなく、先に直したい部分を整理した記録です。
しばらく前から、AIに手伝ってもらいながら自分用の判断支援ツールを作っています。
最初は小さな機能から始めました。
必要なデータを読み込む。
条件ごとに評価する。
結果を並べる。
うまく動かなければ、AIにエラーを見てもらって直す。
これを繰り返していると、自分だけでは作れなかったものが少しずつ形になっていきます。
ところが最近、かなりまずいことに気づきました。
作らせた本人なのに、半分くらい何をしているのか分からなくなってきた。
一応、結果は出ます。
ファイルも動きます。
AIに聞けば、仕組みの説明も返ってきます。
それでも、その結論がどのデータを使い、どの条件で加点・減点され、なぜその順番になったのかを自分で説明できるかと言われると怪しい。
この状態で実践投入するのは、さすがにまずいと思いました。
動くところまで来ても、実践投入できるとは限らなかった
AIにツールを作ってもらうと、「動いた」が一つの大きな区切りになります。
エラーが消えた。
入力したファイルを読めた。
結果が画面に表示された。
テストも通った。
ここまで来ると、かなり完成へ近づいたように見えます。
以前、自分はAI生成コードを受け入れる前に、目的、入出力、変更箇所、テスト、未確認事項、危険、戻し方を見る「検査工程」が必要だと書きました。
その考えは今も変わっていません。
ただ、今回困ったのは、その検査を通した後の話です。
ツールそのものが動いても、実際に出てきた一つ一つの判断を後から追えなければ、運用中に違和感が出た時に原因を探せません。
コードを受け入れてよいか確認することと、そのツールが毎回なぜその結論を出したのか確認できることは、別の問題でした。
まず、入力から結論までの地図を一枚にしたい
今の自分が最初に必要だと思っているのは、詳しいコード解説より、入力から結論までの処理を一枚で見られる地図です。
何を入力するのか。
どの段階でデータを整えるのか。
何を基準に評価するのか。
複数の評価をどこでまとめるのか。
最終的に何を出力するのか。
この流れが見えれば、少なくとも「今どこの処理を見ているのか」が分かります。
コードを一行ずつ理解できなくても、処理の順番と役割が分かれば、AIへ質問する場所も絞れます。
逆に、この地図がないまま機能を追加すると、似た処理が別の場所に増えたり、昔の評価と新しい評価が混ざったりしても気づきにくい。
新機能を足す前に、まず現在地を説明できる形へ戻したいと思っています。
結論だけでなく、判断理由も一緒に出したい
次に必要なのが、結論ごとの判断理由です。
今のツールは、最終的な評価や並び順を出せます。
しかし、結論だけを見ても、それが妥当なのか判断しにくい。
そこで、結果と一緒に、
- どの条件がプラスに働いたのか
- どの条件がマイナスに働いたのか
- どの情報が不足していたのか
- どの条件同士が競合したのか
を出せるようにしたいと考えています。
ここで欲しいのは、別の生成AIが後から作った、もっともらしい説明文ではありません。
実際の計算や判定で使ったデータとルールから、そのまま理由を出すことです。
後付けの説明では、内部の処理が間違っていても、文章だけきれいに整ってしまう可能性があります。
判断に使ったものと、説明に使うものを分けない。
ここはかなり大事だと思っています。
結果が分かる前の入力と出力を保存したい
判断理由を出せるようにしても、その時点の記録が残っていなければ、後から正しく検証できません。
結果を知った後なら、いくらでも「こう考えればよかった」と説明できます。
でも、それでは本当にツールが判断できていたのか、結果に合わせて説明を作り直しただけなのか分からない。
だから、実践投入するなら、少なくとも次のものを判断した時点で保存したいです。
- 入力したデータ
- 使用したルールや設定
- 出力した結論
- 結論ごとの判断理由
- 判断した日時
これが残っていれば、後から結果と照らした時に、その時点で何が見えていて、何が見えていなかったのかを確認できます。
AIに評価を頼む時も同じで、結果を知る前の回答を残しておかないと、振り返りがかなり曖昧になります。
外れた時に、原因を分けられるようにしたい
ツールを実際に使えば、当然うまくいかない場面も出ると思います。
その時に「外れたから精度が低い」で終わると、次に何を直せばよいか分かりません。
入力データが足りなかったのか。
データの読み取りを間違えたのか。
評価ルールが弱かったのか。
複数の評価をまとめる方法が悪かったのか。
想定外の条件だったのか。
あるいは、判断としては妥当でも結果だけがついてこなかったのか。
原因を分けられれば、直すべき場所も変わります。
データ不足なら入力を見直す。
読み取りミスなら処理を直す。
ルールが弱いなら評価方法を見直す。
想定外なら、無理に正解扱いせず未対応として残す。
ここまでできて、ようやく「使いながら改善する」に入れる気がします。
判断理由が見えることは、正しいことの証明ではない
注意したいのは、理由が表示されれば安全になるわけではないことです。
間違ったデータを使っていれば、理由も間違います。
評価ルールそのものがずれていれば、筋の通った間違いが出てきます。
AIに説明文を作らせれば、実際には使っていない理由まで補ってしまう可能性もあります。
だから、判断理由は正しさの証明ではありません。
それでも、結論しか出ない状態よりは、どこを疑えばよいか分かります。
説明できるようにする目的は、ツールを無条件で信用するためではなく、人間が違和感を持った時に止めて確認できるようにすることです。
新機能を増やす前に、自分で説明できる状態へ戻したい
AIを使うと、機能を増やす速度はかなり上がります。
思いついたことを伝えれば、設計案が出て、コードが増え、テストまで進む。
便利だからこそ、自分の理解が追いつかないまま先へ進みやすい。
今回の自分は、まさにその状態でした。
まだ欲しい機能はあります。
精度も上げたいです。
ただ、その前に、
- 入力から結論までの処理図を作る
- 結論ごとの判断理由を出す
- 結果が分かる前の入力と出力を保存する
- 結果後に、外れた原因を分けて確認する
この四つを優先したいと思っています。
AIに作らせたツールを完全に理解できるようになるまで使わない、では先へ進めません。
一方で、動いたからそのまま使うのも怖い。
今の自分に必要なのは、その間にある「判断を後から追える状態」なのだと思います。
まずは新機能を増やすより、自分で説明し、疑い、直せるところまで戻す。
実践投入は、その後です。
コメント