この章の答え
一つの操作を、画面からモデル・ツール・履歴まで説明できれば地図がつながる。
30日間で増やしてきた部品を、一つの作業へ戻して見ます。大切なのは全ファイルの暗記ではなく、問題が起きたときに、どの境界と状態から調べればよいかを判断できることです。
01|図でつかむ
全体の循環に、Approval・Sandbox・保存・テストの確認点を重ねる。
02|3つのポイントで理解する
1. 入力と実行をつなぐ
ユーザーの操作が要求になり、Session / Turn の処理に渡り、モデルとツールの往復へ進みます。UI、Core、外部サービスをまたぐ場所が、調査の重要な境界です。
2. 状態が次の判断を支える
ツール結果や会話は履歴へ入り、送信用の Context として整えられます。長い作業では Compaction も関わります。どこに何が保存され、今回何を送るかを分けて説明します。
3. 安全性と検証を地図に加える
Approval は実行判断、Sandbox は実行範囲に関わります。成功だけでなく失敗時の回復、実際に到達できる状態、API の契約まで含めると、実用的なエージェントの設計が見えてきます。
03|ソースで確かめる
以下の検索は Codex リポジトリのルートで実行します。最初に対象 commit を記録し、検索結果から定義と呼び出し元を一つずつ開いてください。
git rev-parse --short HEAD
rg -n "ThreadManager|CodexThread|run_turn|ToolRouter" codex-rs
読む入口: codex-rs/core/src/session/turn.rs 。リンク先は照合に使った固定 commit のファイルです。手元の版と異なる場合は、上の検索語から探し直します。
小さく試す
「git status を確認して」という依頼を題材に、入力、モデル要求、ツール実行、結果、履歴、回答を自分で描きます。次にツールが失敗した場合の戻り道を書き加えます。
04|30秒で復習
- 境界を追えば、巨大な実装も分けて読める。
- 状態の寿命と更新点が挙動を決める。
- 観察 → 検索 → 比較 → 検証で地図を更新する。