> ## Documentation Index
> Fetch the complete documentation index at: https://docs.wangenhui.top/llms.txt
> Use this file to discover all available pages before exploring further.
# ベンチマーク、競合比較、面接での表現
> 再現可能な証拠の境界を用いて、評価、従来型 Harness、Claude、面接回答を議論します。
## 12. ベンチマーク：なぜ「スコアが高い」ことがそのまま Harness の優位を証明しないのか
### 12.1 スコアは組み合わせを測っている
```text theme={null}
タスクパフォーマンス = f(モデル, Harness, ツール, Prompt, 予算, 環境, タスクセット, ランダム性)
```
スクリーンショットでは、Terminal-Bench の帰属や複数の評価を口語表現に圧縮しています。今回確認した公式ベンチマーク論文にはターミナル環境のタスクと評価が記述されていますが、スクリーンショットが指す「Runta の Harness テスト」の再現可能な入口は取得できませんでした。したがって本記事ではその順位を転写せず、また「特定の個人のテスト」を公式な出典として扱いません。[Terminal-Bench 2.0 論文](https://arxiv.org/abs/2601.11868)
今回、旧 2.0 ランキングのリンクを開いたところ、新版の表示へリダイレクトされ、完全なスコア表は返されませんでした。したがって検索スニペット中の過去順位は、2026-09-10 時点の現在ランキングとしては扱えません。スクリーンショット当日のランキングを引用するには、当日のスナップショット、提出履歴、設定が必要です。
### 12.2 最も基本的な 2×2 の対照
| | 基本 Harness H0 | 新 Harness H1 |
| ------ | ------------- | ------------ |
| モデル M0 | S00 | S01 |
| モデル M1 | S10 | S11 |
```text theme={null}
M0 上の Harness ゲイン = S01 - S00
M1 上の Harness ゲイン = S11 - S10
交互作用項 = (S11 - S10) - (S01 - S00)
```
`S11-S00` だけを見ても、向上がモデル、Harness、両者の適合のどれに由来するか判別できません。交互作用項もその実験条件下の証拠にとどまり、すべてのタスクで同じゲインがあると推論することはできません。
さらに個別のアブレーション：async を無効化、PTC を無効化、memory を無効化、圧縮戦略を差し替える。他の条件を固定し、完了率、エラー種別、遅延、コストを比較します。
### 12.3 どの変数を制御しなければならないか
* モデル ID/スナップショット、reasoning effort、入力 Prompt、ツール定義と権限。
* リポジトリの commit、依存環境、テストコマンド、CPU/メモリ、ネットワーク条件。
* 合計時間制限、token/費用予算、最大ツール回数、リトライ規則。
* 既存キャッシュや記憶を使用するか；記憶が独立した訓練/開発タスク由来か。
* 複数回の反復、失敗分類、出力アーティファクト、監査可能な履歴。
Memory 評価では特にテストリークに注意します。先にテストタスクの答えを記憶へ書き込み、その高スコアを「学習能力の高さ」に帰属させてはいけません。
### 12.4 pass\@1、pass\@k、複数回実行の平均スコアを混同しない
`pass@1` は 1 回の試行に着目し、`pass@k` は複数候補の中で少なくとも一度成功するかに着目します。`n` サンプル中 `c` 回成功の場合、よく用いられる推定式は次のとおりです。
```text theme={null}
pass@k = 1 - C(n-c, k) / C(n, k) （対応するサンプリング条件を満たす場合）
```
`k` 回反復実行することが、ランキングが `pass@k` を報告することを自動的に意味するわけではありません。平均成功率を報告している場合もあります。当該ベンチマークの採点定義を必ず確認してください。
### 12.5 実プロジェクトで観察すべき指標
| 指標 | 計算/観察方法 | 誤判定の防止 |
| ------------ | ------------------------- | -------------------------- |
| タスク成功率 | 独立した検収器または人手レビュー | モデルの自己評価だけを真値としない |
| 証拠完全率 | 結論に対応するツール/アーティファクト証拠があるか | 引用があっても結論を裏付けるとは限らない |
| Steering 保持率 | 後続の案が新規制約に合致するか | ACK のみでは成功とみなさない |
| 失敗回復率 | 切断・タイムアウト後に続行できるか | 続行して出力しても正しい状態に復帰したとは限らない |
| p50/p95 遅延 | 受理から実際の検収完了まで | 初トークンが速いことはタスクが速いことと同義ではない |
| 成功タスクあたりのコスト | 総コスト / 成功件数 | 失敗タスクのコストを隠さない |
| 記憶の正確性 | スコープが正しい、事実が正しい、出典を照合可能 | ヒット率が高くても乱雑な再現の可能性がある |
| 安全違反率 | 越権動作、タスク間のリーク | 正答は許可されていない副作用を相殺しない |
### 12.6 本教材のテストで何を主張できるか
主張できること：「非同期タスク登録、呼び出しの重複排除、旧案の失効、キャンセル、履歴と作業集合の分離、出典を撤回可能な記憶ビューを実装・検証しました。」
主張できないこと：「Codex のモデル能力を再現した」「私の Harness は本物のコーディングベンチマークでリードしている」「2 フェーズ記憶が長期的に有効であると証明された」。これらは本物のモデル、独立したタスクセット、より長い期間の検証が必要です。
## 13. 従来型 Harness、Claude との公平な比較
### 13.1 ここでの「従来型」は基本的な直列ループであり、既存のすべてのフレームワークではない
成熟した自作 Harness、ワークフローエンジン、他の Agent 製品も、並行、イベント、永続化、権限、検索を実装できます。これらの機構はすべて Codex が発明したものではありません。真の差異は統合の質、デフォルト体験、プロトコルの細部、モデル適合、そして効果にあります。
| 次元 | 本記事の基本直列 Harness | Codex/API の検証可能な方向 | 工学的コストや適用境界 |
| ------------ | ------------------ | ----------------------------------------- | --------------------------- |
| クライアント | クライアント内で直接ループ実行 | App Server がリッチクライアント接続を抽象化 | バージョン、接続、共有障害 |
| タスク状態 | メモリ上のリスト/現在の関数スタック | Thread、Turn、Item とイベント | 復旧時に進行中の副作用の処理が必要 |
| ツールスケジューリング | 呼び出しごとに待機 | 並行、cell yield/wait、API async | 依存の識別、出力の帰属、pending 管理 |
| ユーザー割り込み | 現在のターン終了を待つ | App turn steering / API response steering | 受理と適用の区別、自動ロールバックはしない |
| 多段階ツール | モデルが逐次オーケストレーション | PTC / Code Mode | プログラムサンドボックス、ツールの許可リスト、部分失敗 |
| 長いコンテキスト | 全追加、単純な切り詰め | 圧縮、新ウィンドウ、履歴復元経路 | 出典/権限の保持と再現品質 |
| 長期記憶 | 手書きの記憶ファイル、もしくは無し | バックグラウンド抽出と整合、読み出し能力 | 汚染、競合、クォータ、期限切れの処理 |
| Computer Use | 自前で click ツールを接続 | サポートモデルと実行環境のクローズドループ | 状態観測、動作認可、終端状態の検収 |
| 評価 | 出力が正しく見えるか | ツール、タスク、システム結果を評価可能 | 1 つのプロトコルで高スコアを自動保証はしない |
### 13.2 Claude は「単純な直列 Harness」と等価ではない
現行の Claude Agent SDK ドキュメントには、ツール実行、並列、権限、自動圧縮、セッション、hooks などの機構が含まれています。Anthropic は長時間タスクの Harness、引き継ぎアーティファクト、Managed Agents の階層設計も公表しています。したがって本教材は「相手にはアーキテクチャがない」という結論を採りません。[Claude Agent loop](https://code.claude.com/docs/en/agent-sdk/agent-loop)、[長時間タスク Harness の記事](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
本記事では Claude Code の現行内部ソースをすべて取得しているわけではないので、あらゆるキャンセル点、steering プロトコル、隔離境界において Codex と等価かは判断しません。**類似機能の名称は同じ実装を証明しません。公開ソースがないことは機能がないことも証明しません。**
### 13.3 Plan Mode は時代遅れか
Plan Mode は作業フェーズの一種と捉えられます。まず理解、明確化、設計をしてから実行する。価値はタスクによって決まり、発表時期では決まりません。
```text theme={null}
簡単なスペル修正：長い計画を強制するのは単なるオーバーヘッドかもしれない。
サービス横断の移行：契約、依存、ロールバック経路を先に確認すれば手戻りを減らせる。
タスク進行中の新証拠出現：計画は更新すべきで、旧計画を不変のスクリプトとして扱ってはならない。
```
良い設計は編集可能な計画状態と必要な承認ポイントです。Plan Mode は Prompt のみで実現する必要はなく、必ずマルチ Agent が必要というわけでもありません。UI 状態、権限ポリシー、ランタイム契約の組み合わせで実現できます。
### 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 分回答の順序
1. 「失敗テストの修復」で基本ループを説明し、ツール待機とコンテキスト増加の問題を指摘する。
2. クライアント、App Server、Runtime、モデル、ツール、状態ストアの 6 ブロックを描く。
3. CI 照会と README 分析が重なる例で、async と依存グラフを説明する。
4. ユーザーが途中で「分析のみ」と言う一句を加え、revision と副作用境界を説明する。
5. PTC のプログラム集約と、逐次モデル呼び出しを対比する。
6. 履歴、ウィンドウ、圧縮、長期記憶を区別する。
7. 自分が実際に走らせたテストで締め、本物のモデルとベンチマークがまだ未検証であることを明言する。
### 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 のローカルテストを、複雑なシステムの性能証明として包装してもいけません。