休みの日に連絡が来た。
「Agentの回答がおかしいんですが、どこを見ればいいですか」
ログの場所を伝えた。
「この警告は問題ないですか」
問題ない。たぶん。
「止めた方がいいですか」
そこは状況による。
結局、ノートPCを開いた。
Agentを自律化していたはずなのに、自分だけは自律できていなかった。
作った本人がいれば動く
開発中は、多少の曖昧さがあっても困らない。
どのログを見るか知っている。検索結果がおかしいときの切り分けも分かる。設定変更の影響も、頭の中に残っている。
問題が起きれば、自分が直せる。
この状態は、PoCでは強い。
判断が速い。説明を書かなくてよい。設計変更もその場でできる。
本番では、その速さがそのまま依存になる。
作った本人しか、次を説明できなかった。
- どの挙動が正常か
- どの警告なら継続してよいか
- どこから人間判断へ戻すか
- 何を変更すると回答品質へ影響するか
- 障害時にどの状態まで戻せるか
Agentより先に、作った人がsingle point of failureになっていた。
手順書はあった
まったく文書化していなかったわけではない。
起動方法、環境変数、デプロイ手順、主要API。READMEには一通り書いてあった。
それでも引き継げなかった。
不足していたのは、操作手順より判断の境界だった。
たとえば、次のようなログが出たとする。
retrieval_count=8
used_evidence=2
conflict_detected=true
final_status=completed
システムはcompletedになっている。
この回答を利用者へ出してよいのか。conflictがあるなら止めるのか。二つの根拠で十分なのか。
コードを読めば処理は分かる。設計者が何を危険と見ていたかは分からない。
READMEだけ育って、運用判断が引き継がれない。
設計意図が自分の記憶に残っていた
実装には、多くの小さな判断が入っている。
このsourceは古くなりやすい。このtoolは失敗しても再試行しない。このケースでは回答よりescalationを優先する。この出力は参考情報で、判断材料としては使わせない。
コードには条件分岐として残っていても、その理由までは残らない。
後から見る人には、消してよい制約に見えることがある。
そして、正しい機能追加で壊れる。
新しい検索先を足す。回答を詳しくする。失敗時にも何か返す。どれも単体では自然な改善だ。
前に守っていた境界が共有されていなければ、善意の変更で抜け落ちる。
壊したのはメンバーではなく、共有されていない自分の記憶だった。
引き継ぐのはコードだけではない
運用へ残すには、少なくとも三つを分けて残す必要があった。
1. いま何が起きているか
- 現在のstate
- 参照したsourceとversion
- missing facts / conflict
- tool callの結果
- 最終遷移
2. どう対処するか
- 再試行してよい失敗
- 人へ戻す状態
- 停止すべき状態
- 変更前に確認する影響範囲
3. なぜその境界にしたか
- principalが負っている責務
- AIへ移していない判断
- 誤答よりabstainを優先する場面
- 失ってはいけない既存の期待
全部を巨大な運用資料へまとめる必要はない。
ログ、runbook、設計判断記録、テストへ分けてもよい。重要なのは、作った本人の頭だけをsource of truthにしないことだった。
「誰でも直せる」は、コードを触れることではない
別のメンバーがデプロイできても、運用できるとは限らない。
異常に気づけるか。影響を判断できるか。必要なら止められるか。変更後に、前の境界が保たれていると確認できるか。
ここまで含めて、作った人以外が扱える必要がある。
Agentの自律性を上げることには時間を使った。自分がいなくても運用できる構造には、後から気づいた。
いやー、きついっす。
本番化は、自分をruntimeから外す作業でもある
PoCでは、自分の判断がruntimeの一部になっていても動く。
本番では、その判断をstate、boundary、runbook、testへ移さないと残らない。
Agentが止まったときに自分を呼ぶ設計は、最初の一歩としてはあり得る。ずっとそれでは、利用が増えるほど自分の負荷も増える。
必要だったのは、完璧なドキュメントではなかった。
誰が見ても現在地が分かり、次の行動と判断の境界を追えることだった。
この失敗を含め、本番投入前に確認したいPrincipal / Artifact / Boundary / Runtime / State / Observabilityの観点を、チェックリスト本にまとめています。