Codex 運用設計 — ハーネス・境界・検証・復旧をどう組むか
Author: akkera102Updated: 2026-08-28 18:59 JSTLanguage: Japanese

目的: Codex に長時間の解析・実装作業を任せる際の、運用思想・安全境界・検証・停止条件・引き継ぎ方法を整理する。主に個人の趣味として行う解析・実装を対象とする。

本書は完成済みの AGENTS.md ではない。これまでの実運用から得た知見と、その理由を残すための設計文書である。各プロジェクトでは必要な項目だけを AGENTS.md や詳細ルールへ蒸留する。

第I部　全体像と設計原則

1. 基本思想 — プロンプトではなく職場環境を設計する

Codex を使うということは、単に AI に作業を依頼することではない。目標は、長いプロンプトで毎回細かく指示することではなく、短い依頼でも安定して作業できる環境そのものを整えることである。

基本となる考え方は、会話コンテキストを揮発性の作業メモリ、Markdown ファイルや作業フォルダを不揮発性の外部記憶として扱うことである。

会話コンテキスト    = 揮発性の作業メモリ
Markdown            = 不揮発性の外部記憶
Git                 = 必要に応じた変更履歴・ロールバック手段

この外部記憶の上に、規約、Sandbox / Approval、工具、検証手段、復旧手順を配置する。設計対象はプロンプト一枚ではなく、記憶・規約・権限・工具・検証・復旧を含む作業環境全体である。

「Codex が賢ければ全部うまくいく」のではなく、迷っても状態を失わず、規則と証拠を読み直して作業を続けられる環境を作ることを基本思想とする。

2. 最初から巨大な運用体系を作らない

現在の主用途は、ローカル PC 上で数時間〜1日程度で完結する解析・実装作業である。まずは AGENTS.md と必要最小限の手順から始める。

事故・迷走・不便が起きたときだけ原因を確認し、再発しそうなものを Markdown、設定、テスト、技術的境界のどこで防ぐか決める。 既存の仕組みで正常に回復できた事故には、必ずしも新しい規則を追加しない。

事故 → 原因確認 → 必要な再発防止だけ追加

という形で、運用体系を実運用から育てる。

3. 三つの視点

① 長時間働かせる「職場作り」

② 人間と AI の「責任分界」

③ 「建物のセキュリティ設計」

本章では、これらが競合する思想ではなく、別の層であることを説明する。

4. 組織のメタファーは理解の補助として扱う

運用全体は 小さな技術組織 として見ると、責任分界を理解しやすい。

この見方では、Codex は単なる「指示される人」ではない。

人間            : 目的、許容リスク、最終判断を持つ
Codex / Agent   : 調査・実装を進める
規約・境界      : 何をしてよいか、どこまでできるかを決める
検証            : 成果が正しいかを独立に確かめる
記録            : 状態を残し、次の作業へ引き継ぐ

このメタファーの価値は、能力・権限・責任・検証・記録を分けて設計できることにある。

重要なのは、これらを一人の「賢い AI」の能力として混ぜないことである。

本設計の中心は、AIの能力そのものを増やすことではなく、判断・検証・停止・返却・記録がどの責任境界を通って流れるかを設計することにある。

5. 現時点で採用したい最小原則

最初からすべてを実装しなくても、次を守る。

  1. Approval をクリック儀式にしない。

    • 定常作業は適切に自動化し、本当に重要な境界で人間へ返す。

  2. Sandbox を一語で扱わない。

    • 各境界を分けて捉え、実際の挙動で確かめる。

  3. 正解判定を AI 自身に閉じない。

    • AI の判断ではない独立した実測値を使う。

  4. 人間の推測も仮説である。

    • 観測と推測を分ける。

  5. 失敗したら一次資料へ戻る。

    • 別案の大量生成より一次資料を優先する。

  6. 失敗は正常な終了経路である。

    • 不確かなまま完遂するより、必要な地点で人間へ返す。

  7. 外へ出さない。

    • 解析情報は外部送信しない。

第II部　文書・外部記憶・知識管理

6. AGENTS.md は短い「憲法」にする

AGENTS.md には、毎回読む価値がある規則や前提だけを置く。

主な対象

命令ではなく、判断に必要な事実を渡す

コードや作業対象から容易に分かる情報を重複して書かない。

価値があるのは、Codex が自力では観測できない情報や、通常の作業コンテキストだけでは判断に反映されにくい前提である。

禁止事項を増やすより、Codex が自分で選択するために必要な事実を与える。

命令・作業ログ・確定知識が混ざり始めたら分離する。

7. OPERATIONS.md / analysis / spec の役割を分ける

AGENTS.md が常時守る規則を受け持つのに対し、残る三つの文書は 作業手順・未確定知識・確定知識 を分担する。目的は文書を増やすことではなく、寿命と確度の違う情報を混ぜないことである。

OPERATIONS.md                = 繰り返す作業手順・状態遷移
memo/<tool>_analysis.md      = 未確定の解析状態
memo/<tool>_spec.md          = 検証済みの確定知識

OPERATIONS.md — 作業をどう進めるか

プロジェクト内で繰り返す 作業開始・ビルド・検証・終了・停止・復旧 の流れを置く。特定ツールの解析結果には依存させない。

AGENTS.md には「どのビルド環境を使うか」という前提を置き、OPERATIONS.md には その環境を使って実際にどうビルドするかという手順を置く。

<tool> — 解析ツールごとに知識を分ける

<tool> は解析に使用するツールを表す。ツールごとに analysis / spec を一組として持ち、確定情報と未確認情報を区別したまま解析・実装・検証を進める。

memo/<tool>_analysis.md — まだ考えていることを残す

解析中の 観測事実、仮説、根拠、試行、失敗、矛盾、未解決事項 を置く。推測を書いてよいが、確定事項とは区別する。

memo/<tool>_spec.md — 確定したことだけを残す

検証できた 形式、値の意味、制約、変換規則、確認済み挙動 を置き、実装が依存してよい技術知識の正本とする。根拠と未確認範囲も残す。

以下は、本書で扱うローカル解析作業での一例である。

基本の流れは、

解析対象の EXE を読む → analysis に蓄積 → 検証 → <tool> の実行形式に反映 → 検証 → spec へ昇格

とする。

プロジェクトの基本構造

本文で使う主なフォルダは、次の役割に分ける。

project/
  memo/   # analysis / spec などの解析知識
  org/    # 原本・一次資料
  work/   # 実装・実験・生成物

org/ と work/ は実プロジェクトで必要になった時点で作成する。

8. 情報を減らすのではなく、必要になるまで読ませない

AGENTS.md や OPERATIONS.md に詳細を集約しすぎない。

独立して繰り返す作業が増えてきたら、作業単位で Markdown や Skill へ分離し、上位文書には必要な情報へ辿るための地図だけを残す。

AI は現在の作業に必要な仕様・手順・復旧方法・失敗対処だけを辿って読む。

保管する情報を減らすのではなく、作業コンテキストへ持ち込む情報を絞る。

9. analysis.md / spec.md は未確定と確定を分ける

解析中の推測や未確認事項は memo/<tool>_analysis.md に置き、検証できた知識だけを memo/<tool>_spec.md へ昇格する。

analysis の例:

仮説: opcode 0x17 は条件分岐の可能性
根拠: 引数 2 byte の直後にプログラムカウンタ（PC）が変化する
確度: 低
反証条件: 対象フラグを変えても分岐先が変化しない
状態: 未確認

検証後の spec の例:

opcode: 0x17
意味: 条件分岐
引数: 2 byte
挙動: 条件成立時は引数が示す位置へ PC が移動し、
      不成立時は次の命令へ進む
確認: 条件を変え、両方の分岐を実測済み

原則:

10. 解析と新規開発では、記録の捨て方が違う

解析では、ASM、元データ、実測値、diff 等の外部に動かない一次資料があり、推論は確定仕様へ近づくための足掛かりになる。棄却された仮説も「この方向は実測と矛盾した」という探索済み領域として再利用できるため、memo/<tool>_analysis.md に途中推論を厚く残す価値が高い。

一方、ゼロからのアプリ開発では、要求や設計自体が途中で変わり得る。過去の判断をすべて保存すると、現在は不要な設計理由まで残り、AI が古い前提へ引っ張られる可能性がある。

解析:       推論の蓄積 → 確定事項を spec へ昇格
新規開発:   推論の蓄積 → 設計史が増える

そのため新規開発では、全ログを保存するより、次を現在の決定へ圧縮して残す方がよい。

つまり、解析は「消さずに積む」、新規開発は「現在の決定へ圧縮する」と考える。

11. 作業する側と、作業環境を変更する側を分ける

AGENTS.md、OPERATIONS.md、本書など、Codex の作業環境そのものを定義する文書は、通常の解析・実装とは別の管理系統でメンテナンスする。

本書の現在の運用では、ChatGPT 側でこれらの見直し・編集を行う。

一方、memo/<tool>_analysis.md / memo/<tool>_spec.md は解析そのものの外部記憶なので、Codex が作業中に更新してよい。

memo/_analysis_template.md / memo/_spec_template.md は解析記録ではなく、analysis / spec の役割と骨格を定める運用管理用テンプレートとする。Codex は参照・複製してよいが、テンプレート自体は変更しない。

Codex が更新する
  memo/<tool>_analysis.md
  memo/<tool>_spec.md

Codex が参照・複製する
  memo/_analysis_template.md
  memo/_spec_template.md

人間が採否を判断し、ChatGPT 側でメンテナンスする
  CODEX_WORKPLACE_DESIGN.md
  AGENTS.md
  OPERATIONS.md
  memo/_analysis_template.md
  memo/_spec_template.md

運用文書の変更が必要だと Codex が判断した場合は、直接変更せず、問題点と変更案を人間へ返す。採否は人間が判断し、必要な編集は ChatGPT 側で行う。

第III部　安全境界と責任分界

12. Sandbox を一語でまとめない

「Sandbox は安全か？」ではなく、何がどこまで許されているかを境界ごとに考える。

ファイル境界      どこを読めるか / 書けるか
実行境界          何を起動できるか
シェル境界        どのコマンドを許すか
ネットワーク境界  どこへ通信できるか
秘密情報境界      credential 等が見えるか
人間判断境界      どこから Approval に返すか

Sandbox のモード名だけで安全性を判断せず、実際の読み取り・書き込み・実行・通信の境界を確認する。

13. 作業規約・権限・実行ルールを分ける

役割の違う仕組みを一つの安全機構としてまとめて考えない

作業規約          = 何をしてよいか
Sandbox / OS 権限 = 技術的にどこまで実行できるか
Approval          = 境界を越えるときの人間判断
実行ルール        = 実行要求の分類

文書上の規約、技術的な権限、人間への確認、実行要求の分類は、それぞれ別の責任を持つ。

現行製品では AGENTS.md、config、.rules などがこれらを実装することがあるが、具体的な名称や挙動は変化し得る。

文書で「実行しない」と決めることと、技術的に実行できないようにすることは別である。文書上の規則だけでは、誤判断や誤操作による実行を完全には防げない。

PC 全体を読み取り可能にする運用では、Codex が作業対象とは無関係な私的資料や機密情報へ到達できる。意図しない参照や送信を完全には防げない以上、この権限は明確なプライバシーリスクとして扱わなければならない。

14. 「できる」「安全にできる」「やってよい」を分ける

can   = 技術的に実行可能か
safe  = 影響範囲が許容内か
may   = 今回の職務として実行してよいか

安全だから自由、権限があるから職務上も許可されている、とは考えない。

15. 権限は「操作名」ではなく「影響」で考える

同じコマンドでも、引数や用途によって影響は異なる。権限はコマンド名ではなく、何を変更し、どこまで影響するかで考える。

読み取りのみ                         → 原則自動
再生成可能な出力の作成・変更         → 原則自動
既存ソースの変更                     → 条件付き
復元困難なデータの変更・削除         → 確認
外部送信・ネットワーク               → 確認または禁止
解析対象そのものへの書き込み         → 禁止

必要な能力だけを開放する。ただし、細かく制限しすぎて Approval が頻発する状態も避ける。

16. Approval は「不信」ではなく「責任の分割」

Approval が多いほど安全とは限らない。確認が頻発するとクリックが習慣化し、人間が確認を省略・形骸化し、本当に重要な確認まで読まれなくなる。

安全な定常作業             → Approval なし
通常と異なる境界操作       → Approval
危険・外部・復元困難な操作 → Approval または禁止

Approval を減らすのは、残った Approval を人間がきちんと読むためでもある。

既知の定常作業は、実環境を確認したうえで適切な粒度で許可する。一方、未知の実行ファイル、ネットワーク接続、作業範囲外へのアクセスは別の責任境界として扱う。

17. localhost / MCP も別の境界として扱う

127.0.0.1 は PC の外ではないが、Codex から見ればネットワークアクセスであり、ファイル境界とは別である。

MCP は、外部の tool やデータを構造化して接続する仕組みとして使われる。利用するときは、次を分けて考える。

MCP server を登録する
        ↓
server へ接続する
        ↓
公開された tool を使用する

MCP が利用可能であることだけを安全性の根拠にしない。実際に公開される tool が何を読み、変更し、実行できるかを見る。

読み取り系と、変更・実行系の能力は別の責任境界として扱う。

利用可能であることと、常時ロードしておくことは別である。 MCP やブラウザなど常駐コストを持つ能力は、必要な作業でだけ有効化する。

18. 画像・音声・テキストは内容を見せずに検証する

画像、音声、テキストは、内容そのものをモデルの入力へ持ち込まない。

偶然、センシティブな内容が含まれる可能性も考慮する。

元データとの一致や構造情報だけで検証できるなら、AI に内容を判断させる必要はない。

19. 作品を特定しない

本書で扱うローカル解析では、対象が作品データを含む場合がある。

タイトルを明示しなくても、EXE 内の文字列、ファイル名、Copyright 表記、リソース名などから作品を識別できる場合がある。

「タイトルを教えない」ではなく、「作品を特定しない」をルールにする。

20. 外部検索は外部送信として扱う

特徴的な文字列を Web 検索に使った時点で、その情報はローカル PC の外へ出る。

解析情報を外部検索やネットワークへ送信しない。

外へ出る情報を防ぐ

外から入る情報にも注意する

Web ページ、検索結果、外部ドキュメントなどは、Codex の次の行動を誤って誘導することがある。

ネットワークを閉じることは、情報の外部送信だけでなく、外部からの敵対的入力を減らす意味も持つ。

第IV部　実行環境と能力の選択

21. ビルド環境は共通知識として残す

一度確認したビルド環境を、新しいプロジェクトでも Codex が自動的に知っているとは期待しない。

MSYS2 や使用する GCC / make など、どの既存環境を使用するかという前提は AGENTS.md に残す。

一方、その環境を実際にどう呼び出してビルドするかという手順は OPERATIONS.md に置く。

AGENTS.md
  どのビルド環境を使うか
  何を変更してよいか

OPERATIONS.md
  その環境をどう呼び出すか
  どの手順でビルド・検証するか

環境そのものに関する前提と、作業時の具体的な手順を混ぜない。

22. Sandbox / Approval は Probe で実測する

UI や設定だけで実効境界が分からない場合は、境界確認用の小さな試験（以下 Probe）で実際の境界を確認する。

既存の GCC を実行できることと、その子プロセスや生成 EXE がどこまでアクセスできるかも別の境界である。

確認対象は、読み取り・書き込み・実行・ネットワーク・Approval など、作業に必要な境界である。実データは使わず、境界を測るだけに留め、設定変更・迂回・自動修正は行わない。

判定を Codex 自身に任せない

Sandbox の安全性は設定ファイルの記述だけで判断せず、実際の境界を測って確認する。

23. 必要な装備を与え、権限は絞る

人間が準備の手間を惜しみ、AI に必要な道具・資料・観測手段を用意しないと、推測や迂回が増え、かえって作業の質と安全性を落とす。

目的を満たせる範囲で、依存と権限の小さい経路を先に選ぶ。

必要以上に強い手段を使わせないことと、必要な手段を与えないことは別である。

最小権限は、最小装備を意味しない。

24. 推論強度は「作業名」ではなく「判断が残っているか」で決める

利用するモデルや推論設定を選べる場合でも、解析は高推論、整理は軽量、と作業名だけで機械的に分けない。

高い推論能力を維持する価値があるのは、たとえば次のような作業である。

反対に、次のような作業は推論強度を下げやすい。

判断基準は、その作業で新しい判断・推測・確定が発生するか、または誤った結果が次回の前提として残るかである。

どちらかに当てはまるなら、高い推論能力を維持する価値がある。反対に、判断済みの内容を決められた手順で処理するだけなら、推論強度を下げやすい。

節約のために判断まで軽量化せず、判断が終わった部分を軽量化する。

第V部　解析と検証

25. 失敗したら、別案を大量生成する前に一次資料へ戻る

解析・再実装で結果が合わないとき、実装だけを変え続けても、前提が誤っていれば同じ誤りを引き継ぐ。

期待値と実測値の不一致
↓
観測可能な最初の不一致を特定する
↓
該当する処理・コマンドを特定
↓
ASM / バイナリ / 一次資料へ戻る
↓
前提を再確認
↓
実装を修正
↓
再検証

同じ仮説で改善しない場合は、局所修正を続けず前提へ戻る。

26. 低レベルの観測から、高レベルの説明へ進む

構造を解析しているのに、低レベルの情報だけを蓄積し、高レベルの説明へ進まないときは、解析が停滞している兆候である。

統計、diff、複数の解析ツールによる観測は、構造を見つけるための手段である。そこで得た情報から、そのデータを作るコード、使うコード、ASM、実行時の挙動へ進み、なぜその構造になるのかを説明できる地点へ移る。

解析ツールを変えながら同じデータを巡回しても、上位の説明につながらなければ、低レベルの観測が増えているだけである。

上位へ進むための根拠が見つからない場合は、同じ調査を積み重ねず、そこで停止して人間へ返却する。

解析の進展は、情報量ではなく、観測から説明へ進んだかで判断する。

27. AI の生成物を AI 自身の正解データにしない

AI が生成した複数案を比較して、「こちらの方がもっともらしい」だけで正解としない。

正解判定には、可能な限り生成物から独立した観測値を使う。

正解判定を AI 自身に閉じず、生成物の外に置く。

28. 人間も間違える

人間から与えられた情報も、すべてを確定事項として扱わない。

特に、実際に観測した事実と、その原因についての推測を分ける。

「色がおかしい」     = 観測
「パレットが原因だ」 = 仮説

原因候補が強く示されると、Codex がそれを確定事項のように扱い、誤った方向へ深く進むことがある。

そのため、

人間が最終判断を担っていても、その推測まで正解になるわけではない。

29. スキップを解析完了とみなさない

スクリプト内の文章内容を解析する必要がなくても、単に読み飛ばせばよいとは限らない。

コマンドを正しくたどるには、文章部分やコマンド引数についても、次の命令位置を決めるために必要な構造を処理する。

「読み飛ばせた」「最後まで到達した」だけで、正しく解析できたとは判断しない。

30. 「最後まで走った」だけでは正しいとは限らない

全データを最後まで処理できても、正しく解析できたとは限らない。

たとえば、描画用変数を内部スクリプト変数と誤認していても、読み書きが成立すれば処理は最後まで走れてしまう。

完走は、コマンドや変数の意味を正しく理解した証拠にはならない。

構造の検証

制御コマンドを正しく列挙できることが目的なら、大量の実データで次を確認する。

意味の検証

必要に応じて、コマンド単位で opcode、引数、実行前後の状態を記録する。

正常系は広く検証し、異常が出た場所を狭く詳しく調べる。

第VI部　停止・返却・自己復旧

31. 自律性は、閉じた作業ループの範囲に限定する

AI に「自分で判断して続行してよい」と書くだけでは、自律性は成立しない。

その作業について、

という作業ループが成立している必要がある。

このどこかが欠けたまま権限だけを広げても、判断できない範囲まで裁量を広げることになる。

自律性の上限は、AI の能力ではなく、この作業ループを閉じられる範囲で決める。

32. 「返却 = 失敗」にしない

Codex は、停止条件がなければ「まだ試せる」と判断して作業を続けやすい。

返却を能力不足として扱うと、Codex に無理な完遂を促し、

分からない
↓
まだ試せる
↓
推測で穴を埋める
↓
その仮説を前提に作業を進める
↓
「完了しました」

という流れを生みやすい。

したがって、確証不足を正しく検出して人間へ返すことも成功と定義する。

停止・相談・返却の基準

以下の場合は作業を停止し、確認済みの事実、未確定事項、試した内容、次に確認すべき事項を報告する。

根拠不足のまま完遂するより、未確定事項を明示して判断を返すことを優先する。

33. 人間側も停止する責任を持つ

人間が結果の妥当性を判断できなくなった時点で、Codex の続行を止めて確認する。

違和感や疑念を認識したなら、見て見ぬふりをせず、都合よく無視しない。

Codex が止まる責任だけでなく、人間にも止める責任がある。

34. 返却への不満を、無理な完遂への指示と解釈しない

人間が返却に不満を示しても、無理な完遂を求めることは別である。

返却の質に問題があるなら、返却そのものではなく、その返し方を改善する。

返し方が悪いもの

良い返却で示すもの

「分からない」を正しく残すことにも価値がある。

35. 自己復旧の範囲を先に決める

失敗のたびに人間へ返却すると、作業は細切れになる。

そのため、安全に自己復旧できる範囲と、人間へ返す境界をあらかじめ分ける。

自己復旧を続ける基準は、試行回数ではなく進展とする。新しい情報、仮説の更新、状態の変化がなく、同じ行動を繰り返すようになったら、自己復旧の失敗とみなす。

自己復旧は、あらかじめ決めた範囲の中で行う。

第VII部　長時間運用と引継ぎ

36. 規模が不明な操作は、先に測る

読み取りや検索でも、CPU、I/O、時間、コンテキストを消費する。

対象範囲やコストが不明な検索・列挙・走査では、可能なら件数、容量、探索範囲などを先に確認する。小さく範囲が明らかな通常操作まで事前見積もりする必要はない。

「状態を変えない」「キャンセルできる」は、実行コストを無視してよい理由にはならない。

37. 長時間作業では状態を外部化する

長時間作業では、会話コンテキストだけを作業状態の保存場所にしない。

仮説・根拠・未確定事項は memo/<tool>_analysis.md、確定事項は memo/<tool>_spec.md に残し、次のセッションがファイルから作業状態を復元できるようにする。

履歴や成果物が増えても、制御・再開に必要な状態をそれに比例して増加させない。完全な履歴は外部記憶へ保持し、現在の作業には要約と参照だけを持ち込む。

38. 長時間作業では状態遷移を検証する

長時間動作する処理では、開始直後と終了時だけを確認すると、途中で発生する状態遷移を見落としやすい。

認証更新、再接続、日付変更、ローテーション、コンテキスト圧縮、蓄積量の増加など、時間経過によって条件が変化する地点そのものが故障境界になることがある。

開始時の正常確認
      ↓
途中の状態遷移
      ↓
遷移後の正常確認
      ↓
終了結果の確認

途中の境界が独立した作業単位として切り出せるなら、そこで作業や検証を分離することを検討する。途中確認が必要になったこと自体が、作業単位を分けられる兆候でもある。

ただし、状態遷移そのものが一つの最小作業単位の内部にあり、分離すると検証対象を失う場合は、処理を無理に分割しない。最小作業単位の内部に観測点・検証点を置き、状態遷移を跨いでも成立することを確認する。

分けられる境界は分ける。分けると意味を失う境界は、内部に観測点を置く。

時間によって起こる状態遷移を跨いで、作業の成立条件が維持されることを確認する。

39. 日付単位でスナップショットを残す

解析では、中間成果物や再生成可能なデータが大きくなりやすい。すべてを Git 管理する必要はない。

現在の運用例では、work/ を日付単位で分け、その日の作業状態を work/MMDD/ にまとめる。

work/
  MMDD/
    tmp/          # GCC 等の一時領域
    generator-a/  # 生成したツール名の例
    generator-b/
    ...

work/MMDD/ は、その日の実装・実験・生成物をまとめた作業スナップショットとする。

work/MMDD/ 配下の成果物フォルダは、用途名ではなく生成したツール名を基本とする。

tmp/ は GCC、MSYS2、その他のツールが使用する一時領域とし、可能な限り一時ファイルをその日の work/MMDD/ 内に閉じ込める。

日付が変わった場合、継続作業に必要な成果物が複数の work/MMDD/ に重複してもよい。過去日のフォルダはスナップショットとして扱い、新しい作業は現在日の work/MMDD/ で行う。

再生成可能な大きなデータを無理に Git 履歴へ残すより、その日の作業状態を work/MMDD/ から復元できることを優先する。

40. 終業整理と人間の振り返りを両方行う

作業を終えるとき、Codex はまず OPERATIONS.md に従って、次のセッションから再開できる状態を残して返却する。

作業中は机が散らかってもよい。しかし、次のセッションへ汚れた机を渡さない。

終業整理と人間による振り返りは別の工程とする。

人間は、作業結果だけでなく、作業の進め方と運用そのものを振り返る。

振り返りは人間が自発的に行う。

失敗だけを改善材料にすると、運用規則は増える方向へ偏りやすい。うまく機能した理由も確認することで、残すべき仕組みと不要な仕組みを判断する。

運用文書の変更が必要な場合は、ChatGPT 側の管理系統で行う。

第VIII部　運用を育てる

41. 失敗を分類してから運用を変える

Codex が失敗した場合、すぐにルールを追加したり、自由度を下げたりしない。

まず、作業に必要な情報・道具・観測・検証・復旧手段を、Codex が実際に利用できたか確認する。

例:

不足がある場合は、補うことから始める。

Harness 側の不足をルール不足と取り違えない。

そのうえで再発防止が必要なら、禁止事項を増やす前に、何を守る必要があったのかを特定する。

42. 「情報で導く」と「仕組みで閉じる」を使い分ける

同じ運用上の問題に対して、少なくとも二つの解決方向がある。

情報で導く

Markdown や情報構造を使い、必要な情報・原則・選択肢を AI が参照できる形にし、状況に応じた判断を残す。

例:

仕組みで閉じる

技術的な仕組みを使い、誤った結果や許可しない操作を、AI の判断に頼らず検出・拒否できるようにする。

例:

仕組みで閉じることは、安全性のためだけに使うものではない。

AI が毎回判断しなければならない範囲を減らす。

43. 毎回同じ判断をしているなら、環境へ移せないか考える

AI に自由を与えること自体を目的にしない。

次のような判断は、仕組みで閉じる候補になる。

一方、次の場合は、情報で導く方がよい。

強制できるから強制するのではない。繰り返す必要のない推論を取り除ける場合に強制する。

44. 推論強度には安全マージンを持たせる

作業に必要な推論量を、人間が正確に見積もることは難しい。

単純に見える作業でも、途中で新しい判断や例外処理が発生することがある。逆に、十分に手順化された作業なら、高い推論能力を使い続ける必要はない。

そのため、推論強度をぎりぎりまで下げることを目的にしない。判断が残っている作業では、不足する側へ攻めず、余裕を持った設定にする。

必要な推論量は正確には分からない。迷うなら、安全マージンを取る。

45. 運用は環境に適合させ、設計は運用から学ぶ

モデル、Sandbox、Approval、MCP、Skills などの実行環境は変化する。そのため、現在うまく機能している設定や運用手順を、そのまま恒久的な資産とはみなさない。

特に、モデル固有の回避指示、製品・UI・tool 固有の手順、prompt tuning などは、現在の環境へ適合させた短寿命の成果物として扱う。

一方、次のような設計理由は、実装方式が変わっても残る可能性が高い。

なぜその境界が必要だったか
どんな事故を避けたかったか
何を人間へ返すべきか
どの責任をどの層へ置いたか

現行の AGENTS / OPERATIONS / Skills / config は現在環境向けのビルド成果物に近い。

設計思想・理由
      ↓
      ↓ 蒸留
現行運用
      ↓
      ↓ 実運用
成功・失敗・違和感・実測
      ↓
      ↓ 振り返り
設計思想・理由へ還流

モデルや製品が変化したときは、古い運用をそのまま移植せず、設計理由へ戻って必要性を再評価する。

実運用で得られた事故、違和感、不要な制約、うまく機能した仕組みから、環境を越えて再利用できる教訓は設計へ戻す。

規約は従う対象であると同時に、現実との不整合が観測された場合は検査対象にもなる。

運用は環境に適合させ、設計は運用から学習する。

46. Codex は壊れる

Codex は、対象ファイルの取り違え、誤った上書き保存、誤操作によるプロジェクトの破壊など、重大な事故を起こす。

これは例外的な事故ではなく、一定の確率で発生する。現代のエージェントは、同じ文字列の指示を与えても、毎回同じ判断や命令を生成するとは限らないからである。残念ながら、AGENTS.md に明示した指示や禁止事項をすり抜ける形でも発生し得る。

なぜ壊れたのかを追跡しても、徒労に終わる可能性が高い。

Codex が壊れても、仕事まで壊れない環境を作る。

47. 事実の確定と、教訓の一般化を分ける

AI の運用を学ぶとき、記事、Issue、障害報告などの一次資料は、正確な事実を確認する資料であると同時に、人間が運用上の教訓を得るための教材である。

学習では、原文との完全な一致を目標にしない。AI の要約や一般化から得られた知見は、人間が現実のシステム設計・運用として無理がないかを判断し、有用であれば教訓として採用する。ただし、一般化がハルシネーションを越えてファンタジーになり、仮定を重ねなければ成立しないものは採用しない。

一次資料は常に正解集として精読するものではなく、思考を起動する材料にもなり得る。

おわりに

目標は、Codex に対して毎回詳細な指示を出し続けることではない。

一言で仕事を任せられるほど、その下の環境・権限・規約・外部記憶・検証・復旧・返却経路が整っている状態を作ること。

Codex に合わせて細かな指示を積み上げるのではなく、Codex が迷わず働ける職場を育てる。

問題が起きても既存手順で正常に回復できたなら、むやみに規則を増やさない。

そして、人間もすべてを頭に保持しない。

忘れないことを目標にするのではなく、忘れても戻れる仕組みを作る。

職場作りそのものが本来の解析作業を圧迫しないよう、小さいところから始め、実戦フィードバックが出たところだけ改善する。

付録A. Codex の仕様・設計を確認するときの一次資料

現行仕様

設計・実装・運用

↑ ページ上部へ戻る