成功の表示と、残されたフォルダー
処理は正常に終了した。エラーの出力もない。それでも、削除したはずのフォルダーは残っていた。
10月5日、JCが社内で共有した検証記録には、AIに仕事を任せる難しさが凝縮されている。コマンドが返す終了コードと、依頼した仕事の達成は、同じものではない。そこで示された注意は明快だった。「終了コードだけで効果を判定しないでください。」記録には、再試行後に実際の削除を確認したことも記されている。
終了コードが伝えるのは、その処理がどう終わったかだ。利用者が知りたいのは、望んだ状態になったかどうかである。この間にある距離を埋めずに、AIが「完了しました」と答えると、確認の負担は静かに人間へ戻ってくる。
これは、モデルの回答をもっと正確にするだけで解ける問題だろうか。JCが社内の要件を整理した別の設計案は、視点をモデルの外側へ移す。推論を支えるだけでなく、仕事が始まり、中断し、引き継がれ、終わるまでを扱う実行・対話の仕組みを設計するという考え方だ。
会話の外に、仕事を置く
AIとの会話には、依頼と返答が順番に並ぶ。だが、一つの仕事が一つの会話で完結するとは限らない。外部の処理を待つ間に接続が切れることもあれば、担当が変わり、前の経緯をもう一度読む必要が生じることもある。
構想の核にあるのは、こうした仕事の状態を会話の記憶だけに預けないことだ。依頼の単位を定め、その目的、担当、進行状況、確認すべき条件をひとまとまりにする。さらに、何が起きたかを後からたどれる形で残す。技術的には、タスクを包む情報の枠と、継続して保存されるイベントの記録に相当する。
たとえば「処理を依頼した」「結果が返った」「対象の状態を確かめた」は、別々の出来事として扱える。同じ「実行済み」にまとめなければ、中断から再開するとき、どこまで済み、どこが未確認なのかを見分けやすい。
ただし、記録があれば再実行してよいわけではない。外部への操作がすでに成立している場合、繰り返すことで重複が起きる。記録を残す設計と、同じ仕事を二度行わない設計は、あわせて考える必要がある。
完了には、根拠が要る
この考え方を完了判定へ広げると、「うまくいった」という文章は、結論だけでは足りなくなる。何を確かめ、その結果がどこに残っているのか。完了を支える証拠が必要になる。
フォルダーの例なら、操作後に対象の有無を確かめることが、その一つだ。文書の更新なら、更新先に意図した内容があるかを読む。処理を呼び出せたことと、利用者が求めた変化を確認できたことを分ける。その区別を、モデルの気配りだけに任せず、仕事の流れに組み込む。
担当を明確にすることにも意味がある。複数のエージェントが作業を分担するとき、個々の返答がそろっただけでは、依頼全体を閉じてよいとは限らない。誰が未解決の点を拾い、最後の確認を引き受けるのか。仕事の所有者を定めるとは、その役割を曖昧にしないことでもある。
ここでいう証拠は、絶対的な正しさの保証ではない。確認した時点から外部の状態が変わることも、確認方法そのものが不十分なこともある。だから、確認できた事実と、そこから推測したことを分けて残す必要がある。
人に戻す場所を、先に決める
信頼性を高めるために、あらゆる操作のたびに人へ確認を求めれば、エージェントは仕事を進められなくなる。一方、曖昧さを無視して進めれば、誤った前提の上で次の操作が積み重なる。
設計上の焦点は、不確かな状態を消すことではなく、扱える状態にすることだ。結果は返ったが効果を確かめられない。必要な権限がない。次の操作は取り消しにくい。こうした違いを残し、どの条件で人の判断を求めるかを決める。
人が介入する画面にも、その違いが表れる。単に「続けますか」と聞くより、何を試し、何が分かり、何がまだ分からないのかを示すほうが、判断の材料になる。記録は機械の再開を助けるだけでなく、人が仕事を引き取るためにも使われる。
もちろん、細かな記録と確認には代償がある。保存する情報が増え、検証のための処理や待ち時間も増える。機密情報をどこまで残すかも決めなければならない。取り消せる小さな操作と、影響の大きな操作に同じ重さの手続きを課すべきか。信頼性の設計は、そうした配分の問題でもある。
モデルの外側が、使い心地を決める
これは、検証で見えた問題と向き合うための設計構想だ。仕組み全体の実装状況と効果は、この共有資料だけでは確認できない。
それでも、問いの置き方は重要だ。AIが仕事を任されるためには、次の一手を考える能力に加えて、前の一手が現実に何を変えたかを確かめる仕組みが要る。
今後この構想を評価するなら、正常に動く場面だけでは足りない。途中で止まった仕事を再開できるか。重複した依頼を見分けられるか。証拠が足りないときに、完了と報告せず立ち止まれるか。そうした場面で、設計の価値が見えてくる。
利用者が欲しいのは、流暢な完了報告だけではない。何が終わり、何が残っているのかを、確かめられることだ。エージェントの信頼は、その境界を丁寧に引くところから始まる。
SOURCES & EDITORIAL NOTE
10月5日の検証記録 / 実行・対話の仕組みに関する共有構想
参照リンクは社内Slackへのアクセス権が必要です。
共有資料で確認できる事実と構想を起点に、設計上の意味と課題を編集上の考察として加えています。図は説明のための概念図です。実装済みの機能、検証済みの性能を示すものではありません。インタビューによる発言は含みません。
