12. ベンチマーク：なぜ「スコアが高い」ことがそのまま Harness の優位を証明しないのか
12.1 スコアは組み合わせを測っている
12.2 最も基本的な 2×2 の対照
S11-S00 だけを見ても、向上がモデル、Harness、両者の適合のどれに由来するか判別できません。交互作用項もその実験条件下の証拠にとどまり、すべてのタスクで同じゲインがあると推論することはできません。
さらに個別のアブレーション：async を無効化、PTC を無効化、memory を無効化、圧縮戦略を差し替える。他の条件を固定し、完了率、エラー種別、遅延、コストを比較します。
12.3 どの変数を制御しなければならないか
- モデル ID/スナップショット、reasoning effort、入力 Prompt、ツール定義と権限。
- リポジトリの commit、依存環境、テストコマンド、CPU/メモリ、ネットワーク条件。
- 合計時間制限、token/費用予算、最大ツール回数、リトライ規則。
- 既存キャッシュや記憶を使用するか；記憶が独立した訓練/開発タスク由来か。
- 複数回の反復、失敗分類、出力アーティファクト、監査可能な履歴。
12.4 pass@1、pass@k、複数回実行の平均スコアを混同しない
pass@1 は 1 回の試行に着目し、pass@k は複数候補の中で少なくとも一度成功するかに着目します。n サンプル中 c 回成功の場合、よく用いられる推定式は次のとおりです。
k 回反復実行することが、ランキングが pass@k を報告することを自動的に意味するわけではありません。平均成功率を報告している場合もあります。当該ベンチマークの採点定義を必ず確認してください。
12.5 実プロジェクトで観察すべき指標
12.6 本教材のテストで何を主張できるか
主張できること：「非同期タスク登録、呼び出しの重複排除、旧案の失効、キャンセル、履歴と作業集合の分離、出典を撤回可能な記憶ビューを実装・検証しました。」 主張できないこと：「Codex のモデル能力を再現した」「私の Harness は本物のコーディングベンチマークでリードしている」「2 フェーズ記憶が長期的に有効であると証明された」。これらは本物のモデル、独立したタスクセット、より長い期間の検証が必要です。13. 従来型 Harness、Claude との公平な比較
13.1 ここでの「従来型」は基本的な直列ループであり、既存のすべてのフレームワークではない
成熟した自作 Harness、ワークフローエンジン、他の Agent 製品も、並行、イベント、永続化、権限、検索を実装できます。これらの機構はすべて Codex が発明したものではありません。真の差異は統合の質、デフォルト体験、プロトコルの細部、モデル適合、そして効果にあります。13.2 Claude は「単純な直列 Harness」と等価ではない
現行の Claude Agent SDK ドキュメントには、ツール実行、並列、権限、自動圧縮、セッション、hooks などの機構が含まれています。Anthropic は長時間タスクの Harness、引き継ぎアーティファクト、Managed Agents の階層設計も公表しています。したがって本教材は「相手にはアーキテクチャがない」という結論を採りません。Claude Agent loop、長時間タスク Harness の記事 本記事では Claude Code の現行内部ソースをすべて取得しているわけではないので、あらゆるキャンセル点、steering プロトコル、隔離境界において Codex と等価かは判断しません。類似機能の名称は同じ実装を証明しません。公開ソースがないことは機能がないことも証明しません。13.3 Plan Mode は時代遅れか
Plan Mode は作業フェーズの一種と捉えられます。まず理解、明確化、設計をしてから実行する。価値はタスクによって決まり、発表時期では決まりません。13.4 どのような場合に最初から複雑なホストを作る価値がないか
制御されたツールが 1 つだけで、タスクが数秒で完了し、永続セッションが不要なら、明快な関数呼び出しループで十分かもしれません。 長時間のツール待機、複数クライアントの協調、復旧要件、履歴のウィンドウ超過、あるいは安全隔離といった実際の痛点が現れて初めて、タスクレジストリ、イベントログ、ウィンドウ管理、永続化を段階的に加えるべきです。複雑なシステムが新たに増やす障害モードは、節約されるトークンより高くつくことがあります。14. 面接での表現：どうすれば具体的で信頼できる説明になるか
14.1 90 秒の回答テンプレート
Codex を研究する価値があると感じるのは、コーディング Agent を「モデル + ツールループ」から、持続的なインタラクションが可能な実行システムへと押し上げた点です。第 1 層は App Server で、thread、turn、item などのプロトコルによりクライアントと実行ホストを分離します。第 2 層はスケジューリングで、遅いツールは pending にでき、モデルは依存のない作業を続け、明確な call ID を使って結果を回収します。第 3 層は実行中の調整で、steering は更新の受理と適用を区別し、完了済みの副作用は取り消しません。第 4 層はコンテキストと記憶で、現在の作業集合、完全な履歴、長期の経験を分けて管理します。PTC はコードにバッチのツールオーケストレーションと決定的計算を担わせます。これらの利益は成功率、遅延、コスト、回復力で検証すべきで、ブランドや 1 つのランキングからアーキテクチャの優劣を直接推論することはできません。
14.2 5 分回答の順序
- 「失敗テストの修復」で基本ループを説明し、ツール待機とコンテキスト増加の問題を指摘する。
- クライアント、App Server、Runtime、モデル、ツール、状態ストアの 6 ブロックを描く。
- CI 照会と README 分析が重なる例で、async と依存グラフを説明する。
- ユーザーが途中で「分析のみ」と言う一句を加え、revision と副作用境界を説明する。
- PTC のプログラム集約と、逐次モデル呼び出しを対比する。
- 履歴、ウィンドウ、圧縮、長期記憶を区別する。
- 自分が実際に走らせたテストで締め、本物のモデルとベンチマークがまだ未検証であることを明言する。
14.3 頻出する追加質問と回答のポイント
Q1：Harness と Agent Framework の関係は？ Framework は構築ツール、Harness は戦略とモデル相互作用を実際に担う実行システムです。フレームワークで Harness を書けますし、フレームワークに依存しなくても構いません。要はループ、状態、権限、結果検証がどこにあるかです。 Q2：App Server は CLI を HTTP サービスに包んだだけ？ HTTP に包むだけでは、スレッド状態、双方向承認、イベント、復旧、ツールライフサイクルは自動的には得られません。App Server の価値は伝送プロトコルだけではなく、実行契約と状態セマンティクスです。 Q3：なぜタスクごとにプロセスを起動しないのか？ そうすることも可能で、隔離を重視する場合は特に有効です。共有ホストは主に再利用と統一管理の代わりに、隔離と共有障害のコストを負います。メモリ、起動遅延、障害影響範囲を測定すべきです。 Q4：asyncio.gather は Astra の非同期推論と等価か？
等価ではありません。gather はアプリケーションが並行してコルーチンを走らせることを示すだけで、結果が返らない間にモデルが継続できるかはモデルとプロトコル次第です。教材のローカル demo は前者と pending 管理のみを示しています。
Q5：ユーザーがタスクを停止した後もなぜ操作が発生するのか？
生成ストリームだけを止めていて、ツールや子プロセスをキャンセルしていない可能性があります。動作が既にリモートへコミット済みの場合もあります。キャンセルの伝播、子プロセスグループ、リモートタスクハンドル、コミット時刻を追跡する必要があります。
Q6：ツールの exactly once はどう保証する？
ネットワークリクエスト単独で普遍的に保証することはできません。より一般的なのは、少なくとも 1 回配送 + 冪等キー、実行ログ、結果キャッシュです。外部サービスも冪等または突き合わせをサポートする必要があります。ローカル辞書による重複排除は現在のプロセスの生存期間内でのみ有効です。
Q7：なぜ expectedTurnId があるのか？
クライアントが古いビューに基づいて新しいメッセージを誤ったターンに投入するのを防ぐためで、並行制御の一種の防御であり、インターフェースの見栄えのためではありません。
Q8：steering は生成中の推論を書き換えるのか？
確認できるのはサーバー側が更新を受理し、後続レスポンスに接続することであり、サンプリング済みのトークンや内部推論状態が現場で書き換えられたと断言してはいけません。既に発出した文章や実行済みの動作は依然として存在します。
Q9：PTC は必ずトークンを節約するのか？
必ずではありません。データが多く圧縮可能な場合には利益が明らかですが、一度きりの単純な呼び出しでは、プログラム生成・実行・エラーハンドリングのオーバーヘッドで相殺される可能性があります。タスク形態ごとに測る必要があります。
Q10：モデルのコードをサンドボックスとして Node vm で実行してよいか？
言語コンテキストの分離は安全実行環境と等価ではありません。OS/プロセス/コンテナなどの隔離、リソース予算、ツール権限を明確に定めるべきです。本教材では Node vm を安全なサンドボックスと称していません。
Q11：MCP は PTC に置き換えられるのか？
通常、同じレイヤーではありません。MCP はサービスへの接続、PTC は呼び出しのオーケストレーションです。プログラム内のあるツール呼び出しが MCP 経由で完結してもまったく問題ありません。
Q12：コンテキストがウィンドウ切り替え後もなぜ継続できるのか？
環境がリセットされていないためです。目標、メモ、永続履歴、必要時の検索が接続情報を提供できます。ただし主要な制約とツールのペアリングを確認する必要があり、メッセージ配列を空にするだけではいけません。
Q13：圧縮は無損失か？
そう主張してよい性質ではありません。API の不透明な圧縮項目はタスク継続のために設計されており、可逆的な原文アーカイブとして扱ってはいけません。原文が必要なら履歴出典を保持してください。
Q14：ウィンドウ切り替えは sliding-window attention と同じか？
同じではありません。前者はアプリケーション層のコンテキスト選択で、後者はモデルの注意範囲の設計です。名前が似ていても実装が同じとは限りません。
Q15：Memory と RAG の関係は？
RAG は検索してコンテキストを供給する方法で、Memory は経験から再利用可能な情報を形成する機構です。Memory は RAG で読み出せますが、書き込み、整合、競合、失効、削除の戦略も必要です。
Q16：プロジェクト横断の記憶汚染をどう防ぐか？
記憶のキーに project/workspace スコープを持たせます。読み出しではまず認可とフィルタを行い、その後ランキングします。ユーザー横断で検索してからモデルに「言わないで」と依存してはいけません。
Q17：dreaming でモデルは使うほど賢くなるのか？
外部記憶は今後の重複探索を減らせるかもしれませんが、重みの自動訓練ではありません。有効性は後続タスクの利益と誤りの継承で測るべきで、ファイル更新をモデル能力の永続的な向上と同一視してはいけません。
Q18：モデルが「テスト通過」と言った場合、どう判断するか？
実際のテスト結果、終了コード、対応するコードバージョンを読み、カバーしている受入要件と照合します。要約の生成、コマンドの完了、実際の正しさは別の証拠層です。
Q19：Code Mode で部分失敗をどう保持するか？
読み取り集約は allSettled を使い、結果を partial とマークし失敗リストを保持できます。書き込み操作では冪等、トランザクション、あるいは補償が必要で、Promise の集約でロールバックを実現することはできません。
Q20：新 Harness が旧より優れていることを証明するには、どのような実験が必要か？
モデル、ツール、タスク、予算を固定してペア実験を行い、複数回実行して信頼区間を報告し、機能アブレーションを実施します。本物の成功率が最重要指標で、同時にコスト、遅延、違反率も報告します。
14.4 実際に語れるプロジェクト経験
本記事の演習を終えたら、次のように語れます。Python asyncio による教材用 Agent Runtime を作りました。ツール実行を同期呼び出しから pending job registry に切り出し、thread、turn、call ID で結果を隔離し、ユーザーの変更には revision 検証を導入しました。イベントログの再生と SQLite による履歴/記憶の階層化も実装しました。並行、キャンセル、タイムアウト、呼び出しの重複排除、旧案の拒否、出典の撤回をテストで検証しました。さらにローカルの Codex App Server の初期化プロトコルへの接続も検証しました。モデルレベルの async、PTC、steering の API 接続コードは準備済みですが、実際の API を用いたエンドツーエンド評価はこれからです。「Codex と同等の本番級インフラを開発担当した」とは書かないでください。本記事 demo のローカルテストを、複雑なシステムの性能証明として包装してもいけません。