※この記事は、2026年8月時点でAIと一緒に作っている試験段階の自分用ツールを、読み取り専用で棚卸しした結果をまとめたものです。まだ日常運用には入っておらず、利用データの蓄積や定期的な振り返りも始めていません。対象分野や個別のロジックには触れず、AI開発で何を確認すべきかに絞っています。
しばらく前から、AIに手伝ってもらいながら自分用の判断支援ツールを作っています。
機能を追加する。
テストを増やす。
入力や出力の記録を残す。
未確認の情報を勝手に採用しないようにする。
何か問題が起きた時に止められるようにする。
AIとやり取りしながら、こうした仕組みを少しずつ増やしてきました。
最近、そのツール全体を一度棚卸ししてもらいました。
今回は新しい機能を作るのではなく、コード、設定、文書、テスト、保存済みの記録を読み取り専用で確認する作業です。
その結果、安全に試すための仕組みや、後から追跡するための証拠はかなり増えていました。
ただ、このツールが実際に役立つか判断できるだけの利用記録は、まだありませんでした。
これは、価値を測る基準が弱かっただけではありません。
そもそも試験的に作っている途中で、一定期間使い、データを蓄積し、結果を振り返る段階まで進んでいなかったからです。
テストが増えても、利用データがなければ「役に立ったか」はまだ判断できない。
テストが通ることと、役に立つことは同じではありませんでした。
「作れた」「壊れにくい」「役に立った」は別だった
今回の棚卸しで、自分の中ではツールの評価を三つに分けた方がよいと思いました。
- 作れた
- 壊れにくく、安全に動かせた
- 実際に役に立った
「作れた」は比較的分かりやすいです。
必要なデータを読み込み、処理し、結果を表示できる。
エラーが出ても修正できる。
欲しかった機能が画面上で動く。
AIコーディングでは、まずここまで進む速度がかなり上がりました。
次の「壊れにくく、安全に動かせた」には、別の確認が必要です。
同じ条件で同じ結果を出せるか。
使った入力や設定を後から追えるか。
未確認の情報を自動で採用しないか。
失敗した時に、どこで止まったか分かるか。
変更後も以前の機能が壊れていないか。
このためにテスト、記録、停止条件、確認手順を増やしてきました。
ここまでは、技術的な安全性や再現性を確かめる材料になります。
しかし、「実際に役に立ったか」は、さらに別でした。
テストが証明していたのは、主に技術的な約束だった
テストが増えると、どうしても前へ進んでいる実感があります。
確認項目が通る。
失敗時には止まる。
保存した記録も読み直せる。
AIからも「安全境界が整っています」「再現性があります」といった評価が返ってきます。
もちろん、これは大事です。
テストがなければ、機能を追加するたびに別の場所が壊れても気づけません。
判断支援ツールなら、どの情報を使ったのか追えない状態も困ります。
ただ、これらが確認しているのは、主にツール内部の約束です。
入力を正しく扱ったか。
決めたルールどおりに動いたか。
危険な状態で止まったか。
後から同じ条件を確認できるか。
一方、人間側で本当に知りたいのは別のことです。
ツールを使う前より判断が速くなったのか。
確認漏れが減ったのか。
情報を並べたことで迷いが減ったのか。
逆に、情報量が増えて余計に迷うようになっていないか。
見送るべき場面で、無理に結論を出さずに済んだのか。
ここは、テストが何件通ったかだけでは分かりません。
試験段階では「安全に測る仕組み」が先に育っていた
今回の棚卸しで見えたのは、安全に測る仕組みは育っているのに、役立ったかを判断するための利用データはまだ蓄積していないという現在地です。
試験段階なので、これは順番として間違っていたわけではありません。
本格的に使う前に、安全に試せる状態を作る必要はあります。
自分としては、かなり慎重に作っているつもりでした。
AIが勝手に判断を確定しないようにする。
確認前の情報を混ぜない。
後付けで都合のよい説明にならないよう、判断時点の記録を残す。
失敗した処理を成功扱いしない。
こうした仕組みは必要ですし、今後も外すつもりはありません。
ただ、棚卸しをしないまま進めていれば、安全策や機能をさらに追加し、利用結果を残す工程が後回しになっていた可能性はあります。
正直、ここまで確認項目を増やしたのに、まだ別の宿題があるのかとは思いました。
それでも、利用者が自分一人のツールでさえ、「何が良くなれば次の段階へ進めるのか」が決まっていなければ、試験結果を判断できません。
安全に動くけれど、見る項目が多すぎて時間がかかるかもしれない。
記録は詳しいけれど、実際の判断には使わない情報が多いかもしれない。
説明は増えたけれど、結論を決める時の迷いは減っていないかもしれない。
技術的に立派になることと、利用者の負担が減ることは別でした。
AIを使うほど、追加できるものが増えすぎる
このずれは、AIと一緒に開発しているから起きやすい面もあると思います。
以前なら時間がかかりすぎて諦めていた機能でも、AIへ頼めば形にできます。
テストケースも増やせます。
文書も作れます。
監査項目やログも追加できます。
そのため、「追加できるか」だけで考えると、やることが際限なく増えます。
しかも、機能数、テスト数、文書数は数えやすい。
一方で、迷いが減ったか、確認が楽になったか、見落としが減ったかは、普段の使い方を見ないと分かりません。
数えやすい技術側の成果ばかりが増え、測りにくい利用者側の価値が後回しになる。
今回の自分は、技術側の準備を進める一方、利用結果を測る段階にはまだ入っていない状態でした。
次の機能より先に、使った前後の変化を見たい
今後は、新しい機能を増やす前に、試験運用で少なくとも次の点を記録したいと考えています。
- 一回の判断にかかる時間は短くなったか
- 最後まで確認せずに見落とした項目は減ったか
- 出力を見た後、自分の次の行動を決めやすくなったか
- 情報が多すぎて、逆に迷う場面は増えていないか
- 判断できない時に、無理に進まず止まれるようになったか
まだ利用データがないため、最初から厳密な数値目標を作れるとは限りません。
まずは、使う前後の時間を記録したり、迷った場所を短く残したり、一定件数がたまったところで振り返ったりするだけでも違うと思います。
AIに「この機能を追加して」と頼む前に、「これを追加すると、利用者の何が良くなるのか」と聞き直すこともできます。
その答えが出ないなら、今すぐ追加しなくてもよい機能かもしれません。
安全性を確認した次に、利用者価値を確認する
以前、AIでコードを書く速度が上がっても、設計から改善までの全工程が速くならなければ、仕事全体の生産性は上がらないと書きました。
また、判断支援ツールを実践投入する前に、結論だけでなく判断理由を追えるようにしたいとも書きました。
今回の棚卸しは、そのもう一つ先へ進む前の現在地確認です。
工程を整えた。
判断理由も追えるようにした。
テストや安全策も増やした。
それでも、利用者の判断が改善したかは、試験運用の記録を蓄積してから別に確認しなければならない。
「作れた」の次に「安全に動く」を見る。
「安全に動く」の次に「役に立った」を見る。
この三つを分けるだけでも、次に何を作るべきかはかなり変わりそうです。
まとめ
AIに作らせた試験段階のツールを棚卸しすると、コード、テスト、処理記録、安全境界はかなり増えていました。
それらは、ツールが決めた約束どおりに動くことや、失敗を追跡できることを確かめる材料になります。
ただ、まだ日常的な利用データを蓄積し、振り返っていないため、人間の判断が速くなったか、見落としが減ったか、迷いが減ったかまでは判断できません。
テストが増えたことを、役に立った証拠だと思い込まない。
一方で、利用価値を急ぐあまり、安全性や再現性を軽視もしない。
作れた、壊れにくい、役に立った。
AIとツールを育てるなら、この三つを別々に確認する必要がありそうです。
自分の次の課題は、機能をもう一つ増やすことではなく、試験運用のデータをため、実際に使った時の変化を振り返れるようにすることになりました。
コメント