この記事は、OpenAI Agents SDK のリポジトリ（Python 版と TypeScript 版の 2 つ）のメンテナー自身による、それらを保守するために OpenAI Codex をどう使っているかについての直接の報告である。その構成はシンプルだと説明されている。リポジトリのポリシーは AGENTS.md に、リポジトリローカルの Agent Skills は .agents/skills/ に置き（スキルの中には任意でスクリプトやリファレンスを含められる）、同じワークフローを CI で実行すべき場合には Codex GitHub Action を使う。記事の主張は、これによって Codex がリポジトリの仕組みについて安定したコンテキストを得られ、検証、リリース準備、サンプルの結合テスト、PR レビューといった繰り返し発生する作業の速度と正確性が向上するというものである。
記事はこの構成を開発スループットの向上と結びつけている。2025 年 12 月 1 日から 2026 年 2 月 28 日までの間に、2 つのリポジトリでは 457 件の PR がマージされ、その前の 3 か月の 316 件から増加した。記事はこの増加をスキルと Codex による自動 PR レビューの両方によるものとしており、統制された比較として示しているわけではない。
記事の大部分は具体的なスキル（code-change-verification、docs-sync、examples-auto-run、final-release-review、implementation-strategy、openai-knowledge、pr-draft-summary など）を順に紹介し、そこから、モデルの判断がどこにふさわしく、どこからスクリプトに任せるべきかについての一般的な教訓を引き出している。
要点
- 各スキルは、狭い契約、明確なトリガー、具体的な出力を持つよう意図されている。記事は、スキルの正確な一覧よりもこのパターンのほうが重要だと述べている。
- 最も有用なスキルのいくつかは、厳格なゲートではなくレポート優先型である。
docs-syncとtest-coverage-improverは差分やカバレッジの成果物を調べて優先順位を付け、編集する前に承認を求める。 AGENTS.mdは、冒頭近くに置いた短い if/then ルールによってスキルの使用を必須にするために使われている。たとえば、ランタイムコード、テスト、サンプル、ビルドの挙動が変わったときは$code-change-verificationを実行し、それが通るまで作業を完了扱いにしない、といったものである。記事は、この条件付きルールによってドキュメントのみの作業を軽量に保てると説明している。- 記事は役割分担を次のようにまとめている。スキルはリポジトリにとっての「検証済み」の定義をコード化し、
AGENTS.mdはその定義を強制可能にする。 - スキルの
descriptionフィールドは、スタイル上の選択ではなくルーティング契約の一部だと説明されている。エージェントがスキルを読み込む前に目にするのは名前と説明だからである。記事の助言は、ルーティングが当てにならないと感じたら、コードを追加する前にメタデータを直せ、というものである。 - 推奨される分担は、解釈、比較、報告はモデルに任せ、決定的で繰り返し行うシェル作業は
scripts/に入れるというものである。モデルが毎回同じシェルの手順を再発見しなければならないなら、その手順はスクリプトにすべきだとされる。 - サンプルの検証では、ランナーがサンプルを非対話的に実行してサンプルごとのログを残し、その後 Codex が各ログをそのサンプルのソースと比較して、意図どおりに振る舞ったかどうかを判断する。記事は、これが固定のスクリプトレベルのアサーションや終了コードよりも正確で柔軟だと論じている。
- リリースレビューのスキルは、前回のリリースタグと
mainの差分を取り、「リリースして安全」という前提から出発し、具体的な証拠がある場合にのみブロック判定に切り替える。ブロック判定のたびに、ブロックを解除するための具体的なチェックリストが付く。 - 公開リポジトリでの CI については、特に信頼できない入力を受け取る書き込み可能なワークフローの場合、トリガーの設計、入力の扱い、実行時の権限がスキルそのものと同じくらい重要だと記事は述べている。
- メンテナーの報告によれば、単純なバグ、リグレッション、テストの欠落については、Codex を必須のレビュー経路として頼ることは、実際上いまや十分に安全である。一方で、複数の妥当な選択肢の間で選ぶ判断、すなわち API やアーキテクチャの設計、互換性の約束に影響する挙動の変更、命名や移行に関する判断、メンテナー間での合意が必要な作業については、人間によるレビューが依然として不可欠である。
背景
この記事は OpenAI が自社の SDK とツールについて書いたものであり、スループットの数値は 2 つのリポジトリでの導入前後の件数であって、統制された測定ではない。description によるルーティング、段階的な読み込み、スクリプトについての教訓は、この wiki にあるスキルに関する他の記事と並ぶものであり（段階的開示（Progressive Disclosure） を参照）、機械でチェックされる正しさと人間による設計判断を分けるその考え方は、レビューのボトルネックに対する 1 つの答えとなっている。