AIで成果は増えた。自分は何を学んだのか　#3

件数による評価と学習時間

　対応件数は今日増えても、次の担当者が記録を使えるかは交代後にわかります。件数だけで評価すれば、比較や振り返りの時間を減らしていても気づきにくいです。仕事を割り振る人は確認の時間も予定に入れ、評価する人は以前の見落としを次の仕事で防げたかを見ます。

　文章作成を速くしたとき、書きながら考えていた時間まで一緒に減る場合があります。空いた時間へ次の作成だけを入れれば、採用理由を確かめる機会は戻りません。

　手放した作業には、書きながら考えていた時間が含まれています。

　採用理由を説明しないまま仕事を終えると、次の担当者にも「なぜそうしたか」が伝わりません。その人も結果だけを見て同じ案を採れば、確かめていない条件が次の仕事へ持ち越されます。AIを開く前に目的と採用条件を書き、作成後に結果と比べる時間を取れば、この繰り返しを変えられる可能性があります。次の仕事で、同じ条件の見落としや調べ直しが減ったかを確かめます。

AIの反論と採用前の確認

　採用理由を確かめないまま次の仕事へ進む繰り返しには、AIの二つの使い方が関わります。一つはこちらの前提に沿った答えを反論より先に受け取る使い方です。「この設計でいいと思う？」と賛同を求める形で聞けば、前提に沿った理由が返りやすいです。

　違和感や誰かの「それ、おかしくない？」という反論は、設計で見落とした条件に気づくきっかけになります。ただし、反論が返るだけでは調整ループになりません。AIが提案した設計なら、想定する負荷や障害と、実際に確かめた条件を比べます。不足を確認して設計を修正し、同じ基準でもう一度確かめるところまでが一周です。

　「反論して」「前提の穴を挙げて」と頼み、他者や実データとも比べればAIの応答をこの確認に使えます。反論がもっともらしいかと、現実に不足があったかも分けます。なぜなら、根拠を確かめずに賛成案から反対案へ乗り換えても、採用理由をたどれない構造は残るからです。

　もう一つは依頼の範囲を越えた提案まで、確かめずに受け入れる使い方です。「ついでにここも直しておきました」「この設定も変えておくと安全です」。一つ受け入れるたびに、依頼者が検証していない変更が増えます。それが積み重なると、不具合が起きたときに原因候補も増え、切り分けに時間がかかります。提案そのものが悪いのではありません。問題は依頼の範囲を確かめないまま、検証していない変更を次々に受け入れる手順の方です。

　賛成する理由が増えても、確かめた事実が増えたとは限りません。反論の検討と差分の確認を採用前の手順にすれば、同じAIを調整ループへ組み込めます。採用と保留は、目標と確認結果から決めます。

共同作業の条件になったAI

　AIは使わない。そう決めた人にも、AIが承認した成果物は届きます。一度だけ使うときは道具でも、承認の手順や評価基準へ組み込まれれば、AIは環境の一部になります。個人の道具選びでは済みません。

　作業手順を組織の標準にすると、一人の見落としが複数の成果物で繰り返される場合があります。前提の抜けや確認不足もそのまま再利用されるためです。

　一方、失敗への対応として生まれた手順は、その失敗を知らなければ守る理由を説明できません。別の仕組みで防げるようになっても外せず、確認する仕事が増え続けます。手順とともに次の4つを共有します。

• 元の失敗
• 有効な条件
• 未確認点
• 止める条件

　共有の形にも二つあります。詳しい人に毎回頼んで代わりにやってもらう形は、その人が親切でも頼む人が増えるほど待ちが生まれます。手順やひな型を自分で取り出せる形にすれば、同じ依頼を毎回引き受ける仕事を減らせます。

　たとえば、AIが成果物を自動で確認し、「問題なし」なら次の工程へ送る仕組みを考えます。その判定が進行条件になれば、AIを使わない人のところにも、AIが「問題なし」と判定した成果物が届きます。採用と差し戻しの実績を次の判定基準にも使うなら、以前の判定が次に何を通すかにも影響します。AIを使うかどうかという個人の選択だけでなく、その判定を採用や次の基準へどう反映するかが、共同作業の条件になります。

　AIの判定が変わっても採用や差し戻しが変わらないなら、実際に次へ進める条件が別にないかを調べます。判定の精度と、その判定が仕事の進み方へ及ぼす影響は分けて確かめる必要があります。

　「人間も確認済み」。その表示だけでは安心できません。同じ入力と基準で作成と確認を閉じれば、二度とも同じ点を見落とすことがあります。確認していない項目を「問題なし」と表示する仕組みは、確認しない仕組みより悪いです。未確認は未確認のまま表示し、次へ送らず保留にできる手順が必要です。

　作る役と確かめる役を分けるなら、両者が参照する証拠も分けます。確かめる側は元の要件を読み、実際の挙動や利用者の反応と比べます。テストがすべて通っても書かれていない要件までは保証しません。検査した項目と未確認の項目を残します。問題が見つかったときに止めて戻す人も決めます。

　確かめる側が作る側と同じ説明だけを読んでいないかを見ます。実際の挙動や利用者の反応と比べ、見つかった不足を次の受け入れ条件へ反映します。

　AIに次の工程への引き渡しや手順の変更まで任せるなら、仕組みを管理する人が、AIに任せる範囲と元の手順へ戻す条件を決めます。変更履歴を残し、何をもとに引き渡しや変更を決めたかも確かめます。こうした条件や記録がなければ、成果物の誤りを直しても同じ誤りが次も見逃されます。実行中に確認不足が見つかったら記録を判断担当者へ送り、次の自動実行を保留するか、確認項目を直すか決めてもらいます。

　AIは案や反論を示せます。しかし、利用者の待ち時間と運用担当の確認時間のどちらを先に減らすかは、出力だけでは決まりません。採用前に異常を調べる人、途中で止める人、元へ戻せる人を決めます。利用者から苦情が届いたときに手順を変えられる人も必要です。最後に謝る人だけを決めても、問題が続く間に止めることはできません。

今回のまとめ

　完成しても説明できない。こなしても初めての条件では判断できない。解決しても次の担当者が一から調べ直す。完成件数だけではどれも見逃します。空いた時間の一部をテスト環境と記録に戻します。

　次の担当者には実行手順と一緒に、採用理由、未確認点、止める条件も渡します。以前と条件が変わったとき、その人が一から調べ直さずに判断できるか。そこまで確かめて初めて、今回の経験が次の仕事に役立ったとわかります。