AIエージェントの状態管理を先に決めるべき理由
AIエージェントが「使えない」と言われる場面の多くは、モデルの賢さではなく、状態の持ち方が決まっていないことにある。
会話は進んでいるように見える。だが、業務は途中で止まる。どこまで終わっていて、次に何をしてよくて、どこで人間に戻すのか。この3点が曖昧なままだと、AIは何度でも同じ場所を回る。
この話は、AIエージェントに「文脈」を渡す技術 — 仕様書の構造がすべてを決める とかなり近い。文脈が弱いと、AIは読んでいるようで読めていない。そして状態が弱いと、AIは進んでいるようで進んでいない。
会話は流れるが、業務は途中で止まる
チャットボットは会話が続けば成立する。質問に答え、要約し、雑談もできる。多少前後しても、相手は文脈を補ってくれる。
だが業務フローは違う。途中で止まる。承認が要る。差し戻しがある。例外処理がある。期限がある。誰かがメールを開けた瞬間に状況が変わることもある。
たとえば、問い合わせ対応をAIに任せるとする。
- 受付済み
- 内容確認中
- 関係者確認待ち
- 下書き作成済み
- 送信待ち
- 送信済み
このくらいの状態が見えていれば、AIは次に何をすべきか判断しやすい。逆に、状態が「対応中」しかないと、毎回どこから再開するかを考え直すことになる。これでは、便利なはずの自動化が、ただの高級な再実行ボタンになる。
状態管理の話は、実はモデル選定の話ではない。どのモデルでも、状態が曖昧なら壊れる。ここを取り違えると、「もっと賢いモデルに替えれば解決する」という雑な結論に流れやすい。
状態は「覚えていること」ではなく「今どこか」
AIエージェントの状態は、メモや履歴のことではない。もっと実務的で、「今どこにいるか」を示す途中経過だ。
人間の仕事でも同じだ。営業メールの下書きができたのか、上長の確認待ちなのか、相手に送る直前なのかで、次の一手は変わる。AIにもその境界が必要になる。
状態を設計するときは、少なくとも次の4つを分けると見やすい。
| 状態 | 持つもの | 持たないもの |
|---|---|---|
| 受付済み | 入力、依頼元、対象案件 | 実行結果 |
| 確認中 | 参照情報、確認観点 | 送信前提の確定文面 |
| 下書き済み | 草案、差分、未確定項目 | 外部送信権限 |
| 送信待ち | 最終案、承認者、送信先 | 自動送信の許可 |
この分離がないと、AIは「下書き」と「確定」を取り違える。しかも厄介なのは、取り違えたことが一見わかりにくいことだ。誤送信は一回で事故になる。だからこそ、状態の名前は曖昧にしてはいけない。
権限の切り方も、ここに絡む。誰が見えるかだけでなく、どの状態なら何をしてよいかを決める必要がある。これは 社内AIエージェントは権限設計から の話と表裏一体だ。
先に決めるのは3点だけでいい
状態管理の設計は、最初から大げさにしなくていい。むしろ最小限で始めた方が崩れにくい。
決めるのはこの3点で足りる。
- 状態名
どの途中経過を区別するかを、名前で固定する。`processing` だけでは粗すぎるなら、`waiting_for_review` まで分ける。
- 遷移条件
何が起きたら次の状態に進むのかを決める。入力が足りない時、エラーの時、承認が来た時、期限切れの時。ここを明示すると、AIが迷いにくい。
- 再開点
失敗したらどこから戻るのかを決める。最初からやり直すのか、確認済みのところまでは維持するのか。再開点がないと、失敗のたびに全体を巻き戻すことになる。
この3点は、仕様書の中でも文章より表の方が強い。理由は単純で、表にすると状態の抜け漏れが見えるからだ。これも前述のコンテキスト設計と同じで、文脈を渡す技術 の延長線上にある。
AIエージェントの要件定義でよくある失敗は、「何をするか」だけを書いて、「どこで止まるか」を書かないことだ。止まる場所がなければ、評価もできない。評価できないなら、改善もできない。
Structured Outputs と checkpoint が効く理由
状態を設計しても、モデルの出力が自由文のままだと最後に崩れる。そこで効くのが、スキーマを先に決めるやり方だ。
OpenAIの Structured Outputs は、モデル出力をJSONスキーマに合わせる考え方を強く後押ししている。要するに、出力を自由作文にしないで、型を先に固定する。これだけで、状態の取り違えや、後段のパース失敗がかなり減る。
さらに、AIエージェントの途中経過を残すには、checkpointer が役に立つ。LangGraphの StateGraph や checkpointing は、グラフの状態を保存し、途中から再開するための土台になる。
ここで大事なのは、モデルに「覚えておいて」と頼むことではない。アプリ側で状態を持ち、モデルにはその時点で必要なコンテキストだけを渡すことだ。
OpenAIの Safety in building agents でも、構造化された出力や明確なデータフローで、モデルに渡る情報と外に出る情報を絞る考え方が示されている。自由入力・自由出力のまま運ぶより、型と境界で守った方が安全だ。
1工程だけ動かしてみる
最初から業務全体を自動化しようとすると、だいたい失敗する。工程が多すぎるからだ。
おすすめは、1工程だけ切り出すことだ。たとえば問い合わせ対応なら、最初は「内容確認中」だけをAIに任せる。営業フォローなら、「メール下書き済み」までに止める。CRM更新なら、「メモ追記」だけを先に動かす。
ここで見るべき指標は、売上や工数削減のような大きな数字だけではない。
- 状態遷移が止まらずに進んだか
- 人間が直した回数は何回か
- 再開時に同じ情報を二度聞いていないか
- どの状態で承認に戻ったか
この手の評価は、AIエージェント要件定義は評価設計から とつながっている。状態管理があるから評価ができるし、評価があるから改善できる。順番を逆にすると、現場はすぐに空振りする。
AIエージェントを「賢い存在」として扱うより、状態が明確な手順機械として扱った方が、実務では安定する。人間の仕事も同じで、途中経過が見えるものほど引き継ぎやすい。AIも例外ではない。
参考
- Structured Outputs | OpenAI API
- Safety in building agents | OpenAI API
- StateGraph | LangGraph.js API Reference
- langgraph-checkpoint | LangGraph.js API Reference
