再現性のあるAIハーネスは、まず「状態設計」で決まる

AIを会話から仕事へ変える6つの保存先｜AIハーネス設計 実装編 #2

前回の記事では、AIハーネスを「AIが継続して働くための運用機構」として捉え直した。
そこでは、Intent / Policy、Spec / Plan、Runtime / Orchestration、Context / Memory、Tools / Skills / MCP、Artifact / State、Eval / Guardrails / Observability という層に分けて見ていった。

ただ、あの記事を出したあとで、私は一つのことをかなり強く感じた。
多くの読者にとって、本当に次に必要なのは、ハーネスをさらに抽象的に語ることではない。
もっと手前の、もっと地味で、しかし本質的な問いに答えることだ。

それは、
「AIの仕事は、どこに残るのか」
という問いである。

いまのAI運用の多くは、まだこの問いに正面から答えられていない。
会話は続く。
応答は賢い。
ツールも呼べる。
だが、翌日になると文脈が薄れる。
別の担当者へ渡すと説明し直しになる。
途中で承認待ちになると、どこから再開すべきか曖昧になる。
テストは通ったのに、なぜその設計になったのかが追えない。
つまり、AIは「その場では働いたように見える」のに、「仕事としては残っていない」のである。

2026年の主要な公式ドキュメントを見ても、この問題はかなり前面に出てきている。
LangGraph は graph state を checkpoints として各 step ごとに保存し、それを threads に束ねる persistence を中核に置いている。
OpenAI Agents SDK は Sessions によって複数 run をまたぐ会話履歴を自動管理し、さらに conversation_id や previous_response_id を使う server-managed conversation state も用意している。
Anthropic 側では、長時間の会話を壊さず続けるために session memory compaction や prompt caching が前面化し、Claude Code / Claude Agent SDK では CLAUDE.md や auto memory、subagents ごとの独立した context window が用意されている。
つまり、最先端の論点はすでに「どう賢く答えさせるか」から、「状態をどう持たせるか」へ移っている。

私はこの変化を、かなり重要だと思っている。
AIハーネスの強さは、プロンプトの長さでは決まらない。
エージェント数でも決まらない。
どこに何を保存し、何を会話から外に逃がし、どの単位で再開可能にし、どの単位で評価に戻すか。
その 状態設計 で決まる。

この記事では、その状態設計をできるだけ実務の言葉で整理したい。
結論から言えば、状態設計とは「どんな memory を持つか」の話ではない。
どんな保存先を持つか の話である。
この視点に立つと、AIは「会話の相手」から「継続可能な仕事の単位」へ変わり始める。

1. なぜ、次に掘るべきは状態設計なのか

AIハーネスの話をすると、つい人は Runtime や Tools の話から入りたくなる。
　どのSDKがよいか。
　どのagent frameworkが強いか。
　MCPで何がつながるか。
　subagent をどう分けるか。
もちろん、どれも大事だ。

だが、現場で最初に壊れるのは、たいていそこではない。
本当に先に壊れるのは、状態である。

例えば、こんな場面を考えてみる。

朝、AIに仕様整理を頼む。
昼、別の作業が割り込む。
夕方に戻ってきた時、AIは「前提」を少し忘れている。
別のagentに実装を委譲したら、元の意図が十分に伝わっていない。
テストが落ちたので原因を見たいが、どの仮定でその実装に進んだのかが残っていない。
修正案を出してもらったが、承認すべき差分と、まだ未確認の仮説が混ざっている。

ここで問題になっているのは、モデルの知能ではない。
作業の状態がどこにも固定されていないこと である。

人間の仕事では、これは比較的当然のこととして理解されている。
　議事録がある。
　WBS がある。
　チケットがある。
　設計書がある。
　差分がある。
　レビュー記録がある。
　テスト結果がある。
つまり人間の仕事は、かなり早い段階から「会話」ではなく「状態」で運ばれている。

AI運用だけが、いまだに会話に寄りすぎている。
そのため、仕事の継続性が弱い。
私は、ここが現在のAI活用の最大の断層の一つだと思っている。

LangGraph が persistence と memory を別に語り、thread-scoped checkpoints を通じて state を再開可能にしているのは、この断層に正面から向き合っているからだ。
OpenAI Agents SDK でも、Sessions によって複数 run 間の会話履歴を保持しつつ、local context は LLM に送られない実行用の状態として分けている。
つまり現在の主要基盤は、すでに「全部を会話に積む」のではなく、「会話状態」と「実行状態」を分け始めている。

この分離が見えてくると、AIハーネスの設計観そのものが変わる。
ハーネスとは、賢い prompt の集合ではない。
また、tool のラッパーでもない。
仕事を継続可能にするために、必要な状態を適切な住所へ配置する設計である。

私は、ここに思考OSの次章があると思っている。
思考OSが解いてきたのは、AIと人の思考をどう同期するかだった。
状態設計が解くのは、
その思考を どう失わず、どう引き継ぎ、どう検証し、どう残すか である。