9月21日、Vinoth Govindarajan（OpenAI）が「The Agent Harness: Control Planes, Invariants, and Approval Boundaries for Production AI Agents」と題した講演をInfoQで公開した。本番環境のAIエージェントが陥る「静かな失敗」を防ぐための設計原則——Agent Harnessについて詳しく解説されている。
「クラッシュよりタチが悪い」失敗がある
Vinoth Govindarajan氏はOpenAIのコアデータ・AIインフラチームに所属し、UberやAppleでの分散システム開発を経て現職に至る。この発表は、大量のGitHub Issueを読み込んだ末に生まれたものだと冒頭で明かしている。
発表が最初に取り上げるのは、「ユーザーには成功に見えるが、裏では記録が消えている」という障害の形だ。
具体的には、エージェントがユーザーに「次のターンで覚えておきます」と返答したにもかかわらず、そのターンのコンテキストが永続ストレージに書き込まれず、次の会話では記憶がない——という状況。赤いエラー画面は出ない。ログは健全に見える。オペレーターには異変が分からない。
「クラッシュは少なくとも境界を与えてくれる。止まったのが見える。サイレントな成功はそれより悪い。チャンネルはSuccessと言い、ユーザーは何かが起きたと思うが、システムは記憶の穴を持って走り続ける」
これは発表中のケーススタディとして登場するプロジェクト（以下、OpenClaw）で実際に確認された障害の形だ。TelegramデリバリーとCLIバックエンドのパスが分岐し、ユーザー向けの配信ログには記録されたが、次のターンが参照するコンテキストレコードには書き込まれなかった。
3つの問いに答えられるか
ChatGPTが「質問と回答」のツールだったとき、評価軸は「モデルが正しく答えたか」だけだった。エージェントがアクションを実行するシステムになると、問いは変わる。ここで氏が言及する「Codex」とは、OpenAIのコード生成・実行エージェント（Codex）を指しており、単なる補完モデルではなく、自律的にツールを呼び出して作業を完遂するシステムの代表例として挙げられている。エージェントがアクションを実行するシステムになると、問いは変わるのだ。
Govindarajan氏は本番エージェントに対して問うべき3つの問いを挙げる：
- Who owned the state?（誰がその状態を所有しているか） — どのメモリパイプライン、どのワークフローが事実の源泉であるか
- Who committed first?（どちらが先にコミットしたか） — トランスクリプトなのか、セッションなのか、ワークフローレコードなのか
- Who can show what happened?（何が起きたかを誰が示せるか） — モデルが意図したことでも、エージェントが言ったことでもなく、ユーザー可視のエッジが何を永続化したか
「これらはモデルの問いではなく、プロダクションの問いだ」と氏は言い切る。
なお、こうした問題意識は分散システム設計の文脈では古くから議論されており、Two Generals ProblemやExactly-once deliveryの研究と地続きだ。エージェントの登場がこれらの既知の問題を、確率的な振る舞いをもつコンポーネントの周囲に再配置した、というのが氏の基本的な立場である。
Agent Harnessとは何か
発表の中心概念がAgent Harness（エージェントハーネス）だ。「ハーネス」とは自動車でいうステアリング・ブレーキ・ダッシュボード・ブラックボックスに相当する制御系全体を指す。
「強力なエンジンにブレーキがない車は自律性ではなく、加速の良い負債だ」
発表の本番契約（Production Contract）はシンプルな一文で表される：
「モデルが提案し、ハーネスがコミットし、レシートがそれを証明する」
ハーネスの構造（Blueprint）は以下の要素からなる：
- イベント入口（Webhook、タイマー、チャット、外部システム）
- コントロールプレーン（イベントをセッションキーにマップ）
- セッションレーン（コミットパスごとに単一ライター）
- グローバルスロットル（システム全体の保護）
- ランタイム（ツール・モデルの呼び出し）
- 監査トレイル（実行レシートとして残る）
Approval Boundariesとは何か
タイトルに含まれるApproval Boundaries（承認境界）は、ハーネス設計において特に重要な概念として発表中で位置づけられている。
エージェントが自律的にアクションを実行できる範囲が広がるほど、「人間が介入すべき境界はどこか」を明示的に設計しなければならない。Approval Boundariesとは、エージェントが単独でコミットしてよい操作と、人間の確認・承認を経なければならない操作を明確に区切る設計上の境界線だ。
氏はこの境界を「コントロールプレーンの一部として静的に定義すべき」と主張する。つまり、モデルが動的に判断する問題ではなく、システム設計の段階でハーネスに組み込む問題だという立場だ。承認が必要な操作のリストを実行時に確率的なモデルへ委ねることは、それ自体がリスクになる。
「エージェントが『これは承認不要だ』と判断できるなら、境界はすでに形骸化している」
Approval Boundariesの設計は、OpenAIがUsage PoliciesやPreparedness Frameworkで示す安全設計の考え方とも整合しており、モデルの能力が上がるほどその重要性は増す。
原則1：状態を所有する（Own the State）
ランタイムはターン間でステートレスが基本だ。毎ターン、セッショントランスクリプト・セッション状態・メモリサマリー・ポリシーとツールを組み立て直す。このアセンブリのどこかが欠ければ、モデルは正しく答えているように見えながら、不完全な現実の上で推論している。
「ストレージ」と「状態所有権」は別物だと氏は強調する。バイトが保存されている場所がストレージ。リカバリの境界が状態所有権だ。
- カレンダーイベントの事実 → カレンダーシステムが所有
- サポートステータス → チケッティングシステムが所有
- ユーザー設定 → メモリが所有
- 会話ターン → トランスクリプトログが所有
発表のケーススタディで登場する「ハートビート障害」も同じ構造を持つ。内部の生存確認トークン（HEARTBEAT_OK）がユーザー向けデリバリーキューを経由してしまい、内部制御シグナルが「未配信の作業」として分類された。64時間後にユーザーがバグ報告して発覚した。修正はモデルを賢くすることではなく、ステートマシンを厳格にすることだった。状態所有権が曖昧なとき、障害は正しい場所に分類されずに蓄積する——これが氏の診断だ。
原則2：変更に順序をつける（Order the Mutation）
エージェントでは複数のイベントが同時に届く——ユーザーの修正、Webhookリプレイ、ハートビート、サブエージェントの完了、ツール結果。それぞれは有効なイベントだが、無効な順序で交錯する。
発表のケーススタディでは、2つのプロセスが同一の状態をload→modify→saveするパターンで動作し、後から書いた側が前の書き込みを上書きした。どちらの書き込みも論理的に正しいが、直列化（シリアライズ）がなかった。この種の問題は分散システムではLost Update問題として古くから知られており、エージェント設計がこれを再発見している形だ。
解法は「同一プロセスの書き込みはキューで直列化し、クロスプロセスの書き込みはロックで保護する」だ。ポイントは並行性を排除しないことだと氏は強調する。
- 読み取りは並行してよい
- サブタスクのファンアウトは問題ない
- 複数セッションの並列実行も問題ない
- 不変条件は「1つのミュータブルな状態に対して1つのコミットパス」だけだ
「書き込みが直列化されていなければ、エージェントは忘れっぽく感じる。ユーザー体験は順序付けの機能だ」——氏のこの一言は、インフラの設計判断がそのままプロダクト品質に直結することを端的に表している。直列化の欠如は、ユーザーから見れば「このエージェントは信用できない」という印象に変換されるのだ。
なぜ今これが重要か
氏が強調するのは、「これらの障害モードは新しくない」という点だ。べき等性（Idempotency）、リトライ、ロック、順序付け、状態境界は分散システムエンジニアが既知の問題だ。エージェントが変えたのは、障害がどこに座るかだ。
- モデルはツールを動的に選択するため、確率的プランナーの周囲に障害が生じる
- コンテキストはターンごとに異なる形で再構築される
- イベントはユーザー、タイマー、Webhook、サブエージェントから同時に届く
「ハーネスは、使い慣れた信頼性の懸念を、非決定的な振る舞いへの明示的な境界に変える」——これがAgent Harnessの役割だ。OpenAIが公開しているOpenAI Agents SDKにおいても、トレーシングや状態管理の仕組みはハーネス的な発想で設計されており、本発表の議論はその実装上の動機とも対応している。
詳細はThe Agent Harness: Control Planes, Invariants, and Approval Boundaries for Production AI Agentsを参照していただきたい。
