私たちは Codex を使い、OpenAI Agents SDK のリポジトリのメンテナンス方法を見直しています。リポジトリ内のスキル、AGENTS.md、GitHub Actions を組み合わせることで、検証、リリース準備、サンプルの統合テスト、PR レビューといった日常の開発作業を、同じ手順で繰り返し実行できるようになりました。比較的シンプルな構成でも、開発が活発な両リポジトリのスループット向上に役立っています。2025 年 12 月 1 日から 2026 年 2 月 28 日までに両リポジトリでマージした PR は計 457 件で、直前の 3 か月間（2025 年 9 月 1 日から 11 月 30 日）の 316 件から増加しました。内訳は Python が 182 件から 226 件、TypeScript が 134 件から 231 件です。
この SDK には Python 版と TypeScript 版があります。エージェントを使ったアプリケーションの構築に必要な基本機能がそろっています。また、Realtime API 上で複数のエージェントやツールを組み合わせ、人間が処理に介入できる音声エージェントも簡潔に実装できます。SDK は広く利用されており、2026 年 3 月 6 日時点の直近 30 日間の集計では、Python パッケージが PyPI で約 1,470 万回、TypeScript パッケージが npm で約 150 万回ダウンロードされました。
構成はシンプルです。
AGENTS.mdに記載したリポジトリの方針.agents/skills/に配置したリポジトリ固有のスキル- 必要に応じて各スキルに含めるスクリプトや参照資料
- 同じワークフローを CI でも実行するための Codex GitHub Action
この構成により、Codex はリポジトリの仕組みや運用方法を毎回同じ前提で把握できるため、繰り返し発生する開発作業の速度と精度が向上します。
公開オープンソースプロジェクトのメンテナーの方は、Codex for OSS をご覧ください。対象となるメンテナーは、Codex を利用できる ChatGPT Pro、API クレジット、Codex Security への条件付きアクセスを申請できます。
リポジトリ内でのワークフロー管理
両リポジトリでは、それぞれに固有の作業手順をスキルにまとめています。スキルは運用に必要な知識をまとめた小さなパッケージで、SKILL.md マニフェストに加えて、必要に応じて scripts/、references/、assets/ を含めます。Codex のカスタマイズに関するドキュメントでは、スキルが反復作業に適している理由を説明しています。詳しい指示やスクリプト、参照資料を用意しておいても、最初からエージェントのコンテキストを圧迫せずに済むためです。
スキルの情報は、次のように段階的に読み込まれます。
- エージェントが最初に確認するのは
nameやdescriptionなどのメタデータ SKILL.mdを読み込むのは、そのスキルを選択したときだけ- 参照資料の読み込みやスクリプトの実行は、必要になったときだけ
両方の SDK リポジトリで、これらのワークフローをコードと一緒に管理しています。
基本構成がわかりやすいのは Python リポジトリです。
code-change-verificationは、コードやビルドの動作が変わったときに、必須のフォーマット、lint、型チェック、テストを実行します。docs-syncは、ドキュメントをコードベースと照合し、記述の抜けや誤り、古くなった情報を見つけます。examples-auto-runは、自動モードでサンプルを実行し、ログを記録して再実行を支援します。final-release-reviewは、前回のリリースタグと現在のリリース候補を比較し、リリースできる状態かを確認します。implementation-strategyは、ランタイムや API に変更を加える前に、互換性を維持する範囲と実装方針を決めます。openai-knowledgeは、公式の Docs MCP ワークフローを通じて、OpenAI API とプラットフォームの最新ドキュメントを取得します。pr-draft-summaryは、作業を引き継ぐ際にブランチ名の候補、PR タイトル、説明文の下書きを用意します。test-coverage-improverは、テストカバレッジを測定し、特にカバーできていない箇所を特定して、効果の大きいテストを提案します。
JavaScript リポジトリも基本構成は同じですが、npm モノレポとリリース手順に合わせて、いくつか固有のスキルを追加しています。
changeset-validationは、changeset の内容とバージョンの引き上げ幅が、実際のパッケージの差分と一致するかを確認します。integration-testsは、パッケージをローカルの Verdaccio レジストリに公開し、サポート対象の各ランタイムでインストールと実行を検証します。pnpm-upgradeは、pnpm ツールチェーンと CI で固定しているバージョンをまとめて更新します。
個々のスキルの種類よりも重要なのは、設計の共通点です。各スキルの役割を絞り、呼び出す条件と出力を具体的に定めています。
特に役立つスキルの中には、作業の合否を判定しないものもあります。docs-sync と test-coverage-improver は、まず調査結果を報告するワークフローです。現在の差分やカバレッジの測定結果を調べ、対応の優先順位を付けたうえで、編集に入る前に承認を求めます。また、Python リポジトリの docs-sync では、自動生成されたリファレンスを手作業で修正せず、生成元の docstring とコメントを正としています。JavaScript 専用の pnpm-upgrade も、対象を絞ったメンテナンスの一例です。広範囲に一括置換をかけず、ローカルの pnpm バージョン、packageManager、ワークフローで固定しているバージョンを一緒に更新します。
ワークフローの必須化
スキルは、どのタイミングで使用を必須とするかをリポジトリで定めると、さらに役立ちます。そのために使うのが AGENTS.md です。
AGENTS.md ガイドでは、このファイルをコードベースと一緒に管理し、エージェントが作業を始める前に適用するリポジトリ単位の指示として説明しています。また、内容は簡潔に保つことを推奨しています。Agents SDK のリポジトリでは、Codex が毎回従うべきルールをここに記載し、特に重要なものを冒頭に置いています。
実際には、両リポジトリとも、どの条件でどのスキルが必須になるかを短いルールで示しています。ランタイムや API を変更する前には $implementation-strategy を呼び出し、互換性を維持する範囲と実装方針を先に決めます。変更が SDK のコード、テスト、サンプル、ビルドの動作に影響する場合は $code-change-verification を呼び出します。JavaScript パッケージの変更がリリース用メタデータに影響する場合は $changeset-validation を、OpenAI API やプラットフォームとの連携に関わる作業では $openai-knowledge を呼び出します。作業が完了し、引き継げる状態になったら $pr-draft-summary を呼び出します。
この構成は、プロジェクトの概要、ビルドとテストのコマンド、コードスタイル、テストの指針、セキュリティ上の注意点など、リポジトリ固有のルールを一か所にまとめるという agents.md の推奨事項にも沿っています。Agents SDK のリポジトリでもこの構成を採用し、日々の作業で特に重要なスキルの呼び出し条件を最初に示しています。簡略化した例を示します。
# AGENTS.md
## Project overview
- Core SDK code lives under `src/agents/` or `packages/*/src/`.
- Tests live under `tests/` or `packages/*/test/`.
- Sample apps and integration surfaces live under `examples/`.
## Mandatory skill usage
- Use `$implementation-strategy` before editing runtime or API changes that may affect compatibility boundaries.
- Run `$code-change-verification` when runtime code, tests, examples, or build/test behavior changes.
- Use `$openai-knowledge` for OpenAI API or platform work.
- Use `$pr-draft-summary` when substantial code work is ready for review.
## Build and test commands
- Python: `make format`, `make lint`, `make typecheck`, `make tests`
- TypeScript: `pnpm i`, `pnpm build`, `pnpm -r build-check`, `pnpm lint`, `pnpm test`
## Compatibility rules
- Preserve positional compatibility for public constructors and dataclass fields.実際のファイルには、この基本構成にリポジトリ固有の内容が加わります。たとえば JavaScript リポジトリには $changeset-validation があり、両リポジトリともランタイム、ドキュメント、リリースに関する詳しい指針を記載しています。全文は openai-agents-python の AGENTS.md と openai-agents-js の AGENTS.md で確認できます。
AGENTS.md には、スキルの呼び出し条件以外も記載できます。Python リポジトリでは、公開 API の互換性に関するルールもここにまとめています。公開コンストラクタのパラメーターやデータクラスのフィールドは、位置によって決まる意味を維持します。省略可能な項目を追加するときはできる限り末尾に置き、順序の変更が避けられない場合は互換性テストを追加します。このように、リリースに欠かせない互換性のルールを、スキルの呼び出し条件と同じ場所に置くのも有効です。
検証ルール
わかりやすい例が $code-change-verification です。
どちらのリポジトリでも、時間のかかる検証を毎回すべて実行するようには求めていません。ルールは「ランタイムのコード、テスト、サンプル、またはビルドやテストの動作が変わったら検証を実行し、すべて通るまで作業を完了扱いにしない」です。
実行条件を設けることで、ドキュメントだけを変更する場合の負担を抑えられます。一方、その条件に該当すれば検証は必須なので、SDK のコード変更はリポジトリ標準の手順で確実に検証されます。
実行する検証手順は、スキル自体に定義しています。
Python リポジトリでは、次のコマンドが必須です。
make format
make lint
make typecheck
make testsJavaScript リポジトリでは、次の順序で実行することまでスキルで定めています。
pnpm i
pnpm build
pnpm -r build-check
pnpm -r -F "@openai/*" dist:check
pnpm lint
pnpm test何をもって「検証済み」とするかをスキルに定義し、AGENTS.md でその基準の適用を必須にしています。
changeset の検証
JavaScript リポジトリでは、パッケージを変更する際にもう一つ必須の手順があります。$changeset-validation で、Changesets を使って検証します。
packages/ 配下または .changeset/ に変更があった場合、モデルの作業はテストの実行だけでは終わりません。適切な changeset を作成または更新し、バージョンの引き上げ幅が妥当かを検証したうえで、changeset の内容が実際の差分と一致することを確認します。
このスキルでは、ファイルの存在を確認するだけでなく、Codex に git の差分を読んで判断するよう求めます。検証ルールを共通のプロンプトにまとめているので、ローカルでの実行と GitHub Actions で同じ判断基準を使えます。リポジトリ固有の方針も定めています。
- ブランチに changeset がすでにあれば、新しく作らず既存のものを使う
- 要約はコミットタイトルにも使えるように、Conventional Commit 形式で 1 行に収める
- バージョン 1.0 より前は、通常の機能追加ではメジャーバージョンの引き上げを避ける。プレビュー限定と明記した追加機能は、既存の動作が変わらなければパッチ変更として扱う
- 必要なバージョンの引き上げ幅を、実際のパッケージの変更内容と照合する
こうして、Codex は自分で作成したリリース用メタデータを検証してから、作業を完了したと報告することになります。
最新ドキュメントの参照
OpenAI API やプラットフォームとの連携に関わる作業では、両リポジトリとも $openai-knowledge の使用を必須としています。
このスキルは、公式の OpenAI Docs MCP を呼び出す薄いラッパーです。モデルの記憶に頼って回答するのではなく、Responses API、ツール、ストリーミング、Realtime、MCP などの最新ドキュメントを OpenAI Developer Documentation MCP サーバーで調べるよう Codex に指示します。
ローカルの Codex 環境に MCP サーバーがまだ設定されていない場合は、スキルがメンテナーに Docs MCP クイックスタートと公式 MCP サーバーのエンドポイントを案内します。
PR の引き継ぎ準備
両リポジトリでは、まとまった変更を終えた段階で $pr-draft-summary を使います。
このスキルを呼び出すのは、タスクが実質的に完了したかレビュー可能な状態にあり、コード、テスト、サンプル、動作に影響するドキュメント、またはビルドやテストの設定に意味のある変更を加えた場合だけです。スキルはブランチ名、作業ツリーの状態、変更ファイル、差分の統計、直近のコミットを自動で収集し、次の内容を出力します。
- ブランチ名の候補
- PR タイトル
- PR 説明文の下書き
出力形式は意図的に固定しています。典型的な出力例を示します。
# Pull Request Draft
## Branch name suggestion
git checkout -b fix/tracing-lazy-init-fork-safety
## Title
fix: #2489 lazily initialize tracing globals to avoid import-time fork hazards
## Description
This pull request fixes import-time tracing side effects that could break fork-based process models by moving tracing bootstrap to lazy, first-use initialization.
It updates tracing setup so initialization happens once on first access while preserving the existing public tracing APIs.
It also adds regression tests for import-time behavior, one-time bootstrap, and custom provider handling.
This pull request resolves #2489.モデルに自身の作業の検証と要約を任せられるようになれば、最後に PR の下書きも任せるのは自然な流れです。引き継ぎの形式がそろい、実装を終えた後に同じような説明文を繰り返し書く手間も減ります。
スキルの選択に役立つ説明文
スキルの description フィールドは、SKILL.md のフロントマターにあり、どのタスクでそのスキルを選ぶかを決める役割があります。
これは文章の好みではなく、スキルの仕組みに関わる話です。Agent Skills 仕様では、name と description を SKILL.md のフロントマターの必須フィールドとしています。仕様が定める段階的な読み込みでは、起動時にすべてのスキルについてこの 2 つのフィールドを読み込みます。SKILL.md の本文や scripts/、references/、assets/ の内容は、後でそのスキルを実際に使うときに初めて読み込みます。
Codex のスキルに関するドキュメントとカスタマイズに関するドキュメントでは、同じ仕組みを Codex の側から説明しています。Codex はまず各スキルのメタデータを見て候補を探し、スキルを選んだときだけ SKILL.md を読み込みます。参照資料の読み込みやスクリプトの実行は、必要になったときだけです。OpenAI API Cookbook のスキル解説でも、ホスト型シェルでの動作が明示されています。OpenAI が最初に読み込むのは各スキルの name、description、パスで、モデルはその情報をもとに SKILL.md の全文をいつ読むかを決めます。SKILL.md のフロントマターの解説では、name と description がスキルの発見と選択に重要だと明記しています。
そのため、Agents SDK のリポジトリでは、Codex がスキルの本文を読む前にどのスキルを使うかを判断する主な手がかりの一つが description です。
code-change-verification の具体例を見てみましょう。
説明が曖昧な例です。
description: Run the mandatory verification stack in the OpenAI Agents JS monorepo.より具体的にした、実際に使っている説明です。
description: Run the mandatory verification stack when changes affect runtime code, tests, or build/test behavior in the OpenAI Agents JS monorepo.短い説明でも、スキルが何をするかは Codex に伝わります。ただし、いつ使うのか、どのような変更が呼び出しの条件になるのか、その変更で検証が必須なのかは判断できません。具体的な説明なら、この 3 点がすべてモデルに伝わります。
pr-draft-summary にも同じ考え方を適用しています。
説明が曖昧な例です。
description: Create a PR title and draft description for a pull request.より具体的にした、実際に使っている説明です。
description: Create a PR title and draft description after substantive code changes are finished. Trigger when wrapping up a moderate-or-larger change (runtime code, tests, build config, docs with behavior impact) and you need the PR-ready summary block with change summary plus PR draft text.ここでも、実際の説明はスキルを選ぶためのメタデータとして機能します。Codex はそこから次のことを読み取れます。
- タスクの終了時に使うスキルであること
- チャットの応答ごとに使うものではなく、まとまった変更が対象であること
- 出力は単なる文章による要約ではなく、PR にそのまま使える形式であること
両リポジトリでの経験から、description は時間をかけて書く価値があります。意図したスキルが安定して選ばれない場合は、コードを追加する前にメタデータを見直してください。
定型処理のスクリプト化
次に考えるのは、どの作業をモデルに任せ、どの処理をスクリプトに移すかです。
次の分担にすると安定します。
- 解釈、比較、結果の報告はモデルに任せる
- 手順と結果が決まっている反復的なシェル操作は
scripts/にまとめる
この分担は公開ドキュメントの指針とも一致しています。Codex のカスタマイズに関するドキュメントでは、スキルを使うと、最初からコンテキストを圧迫することなく、繰り返し実行するワークフローに詳しい指示やスクリプト、参照資料を用意できると説明しています。状況に応じた判断を Codex に任せ、決まった手順が必要になったときだけスクリプトを呼び出す構成に適しています。OpenAI API Cookbook のスキル解説でも、スキルのスクリプトを小さな CLI として設計することを推奨しています。コマンドラインから実行でき、同じ条件なら同じ結果を標準出力に返し、失敗時には使用方法やエラーメッセージを明示し、必要に応じて所定のファイルパスに結果を書き出す設計です。
Agents SDK のリポジトリでは、たとえば次のように、判断力が実際に役立つ作業をモデルに任せています。
- ソースコードを読んで意図された動作を推定する
- ログをその動作と照合する
- リリースの差分に互換性を損なう具体的なリスクがあるか判断する
- メンテナーが次の対応を決められるように結果を説明する
一方、作業に伴う定型処理はスクリプトが担当します。
- リポジトリで必須の検証コマンドを決められた順序で実行する
- サンプルを起動し、サンプルごとのログを収集して、失敗したものを再実行するためのファイルを書き出す
- リリース可否のレビューに先立って、前回のリリースタグを取得する
start、stop、status、logs、tail、collect、rerunなどの補助コマンドを用意し、同じワークフローを繰り返し実行しやすくする
モデルが毎回同じシェル操作の手順を調べ直しているなら、その手順はたいていスクリプトにまとめるのが適切です。状況に応じた判断、選択肢の比較、結果の説明が必要な部分は、モデルに任せます。
統合テストの自動化
両リポジトリで特に効果があったのが、統合テストの自動化です。検証には関連する 2 つの段階があります。まず、両リポジトリでリポジトリ内のサンプルを自動検証します。さらに JavaScript リポジトリでは、公開したパッケージをユーザーと同じ方法でインストールした場合にも正しく動作するかを別途検証します。
この構成を導入する前は、サンプルの検証には手作業が残っていました。サンプルを実行することはできても、最後はログを目で追い、出力が妥当かを人が見て判断することがよくありました。サンプルが一つなら対応できますが、SDK リポジトリが成長してサンプルが増えると、この方法では追いつきません。
最初の段階を担うのは examples-auto-run ですが、スキルより先に開発したのはランナーです。サンプルの検証を自動化するには、まず両リポジトリでサンプルを非対話的に実行できるようにする必要がありました。通常は入力や承認を求めるサンプルも含め、サンプルスクリプトを自動モードで実行できるようにしました。
そのために、次の仕組みを用意しました。
- よくある対話形式のプロンプトに自動で応答する
- ランナーが対応している場合は、HITL、MCP、
apply_patch、シェルの各操作を自動で承認する - 実行環境の追加設定が必要なリアルタイム処理や Next.js アプリのサンプルなど、まだ自動化に適さないものは自動スキップの対象リストで管理する
- サンプルの実行ごとに構造化ログを書き出す
- すべてを最初から実行せずに失敗したサンプルだけを再試行できるよう、再実行用ファイルを生成する
この基盤が整ってから、一連の手順を再利用しやすく、簡単に呼び出せるスキルにまとめました。Python リポジトリでは、examples-auto-run が uv run examples/run_examples.py --auto-mode --write-rerun --main-log ... --logs-dir ... を呼び出します。JavaScript リポジトリでは、ビルドのチェックを行ってから pnpm examples:start-all を自動モードで実行し、サンプルごとのログ記録と再実行に対応します。
検証の精度を高めるため、ランナーはサンプルを実行し、標準出力と標準エラー出力をサンプルごとのログに保存します。その後、スキルは Codex に次の手順でログを一つずつソースコードと照合するよう指示します。
- サンプルのソースコードとコメントを読む
- 意図された処理の流れを推定する
- 対応するログを開く
- 意図された動作と、実際の標準出力および標準エラー出力を比較する
- 代表例を一つ確認するだけで済ませず、実行に成功したすべてのサンプルについて照合する
この方法は、正しい動作をスクリプト内の固定的なアサーションで定義するよりも正確で柔軟です。終了コードは成功を知る手がかりになりますが、実際の API を呼び出したり、ツールを使ったり、構造化出力を生成したりするサンプルでは、それだけでは不十分です。実際の出力を先に記録し、ソースコードと丁寧に照合することで、各サンプルが本来の目的を果たしているかを検証できます。
JavaScript リポジトリには、別の integration-tests スキルが担当する第 2 段階があります。このワークフローでは、リポジトリ内でサンプルのソースを直接実行する検証に加えて、パッケージをローカルの Verdaccio レジストリに公開します。そのうえで、Node.js、Bun、Deno、Cloudflare Workers、Vite を使った React アプリなど、複数の環境でインストールと実行をテストします。これにより、リポジトリ内でサンプルを実行するだけでは見つからない、公開後のパッケージをインストールして実行環境に組み込んだときの不具合を検出できます。
この 2 つのワークフローは、スキル、スクリプト、モデルの判断を組み合わせる利点を示しています。スクリプトが毎回同じ手順で実行して結果を記録し、手作業では手間のかかる各種インストール方法も検証します。Codex はその記録を使い、スクリプトで単純に合否を判定するよりも踏み込んだ照合を行います。
リリース前のチェック
リリース準備でも、同じ分担が役立ちます。
両リポジトリのリリースレビューでは、まず前回のリリースタグを特定し、最新の main との差分を取得します。そのうえで、Codex に次の点を確認するよう求めます。
- 公開 API やユーザーから見た SDK の動作に関する後方互換性の問題
- 想定される動作の小さな変化も含めたリグレッション
- 移行時の注意事項の記載やリリースノートの更新が必要な変更で、それらが漏れていないか
スキルはこれらの調査結果をもとに、全体としてリリース可能かを判定します。
具体例が openai/openai-agents-python#2480 です。レビューでは全体としてリリース可能と判定しつつ、Python 3.9 のサポート終了と、それをリリースノートに明記する必要があることを指摘しています。
Release readiness review (excerpt)
Release call:
🟢 GREEN LIGHT TO SHIP. Minor-version bump includes expected breaking change
(Python 3.9 drop) with no concrete regressions found.
Scope summary:
- 38 files changed (+1450/-789); key areas touched: `src/agents/tool.py`,
`src/agents/extensions/`, `src/agents/realtime/`, `tests/`,
`pyproject.toml`, `uv.lock`.
Python 3.9 support removed
- Risk: 🟡 MODERATE. Users pinned to Python 3.9 will be unable to install the
0.9.0 release.
- Evidence: `pyproject.toml` now sets `requires-python = ">=3.10"` and drops
the Python 3.9 classifier; CI skip logic for 3.9 was removed.
- Action: Ensure release notes clearly call out the Python 3.9 drop and that
packaging metadata remains `>=3.10`.スキルにはリリース可否の判定方法も定めています。レビューは「リリース可能」から始め、差分に実際の問題を示す具体的な根拠がある場合だけ「リリース不可」に切り替えます。不可と判定した場合は、必ずリリースに進むために必要な対応を具体的なチェックリストにします。そのため、判定結果を次の行動につなげやすくなります。リリース可能なら、差分にリリースを妨げる問題は見つかっていません。リリース不可なら、実際に問題があり、次に何をすべきかも明確です。
単に「リリースをレビューしてください」と頼むよりも、この方法は役に立ちます。モデルは具体的な差分に基づいて判断し、対応に結びつく形で結果を説明する必要があるからです。安全にリリースできるなら、その旨を明言します。できないなら、根拠となる箇所と必要な対応を具体的に示します。
CI でのワークフローの実行
ローカルでスキルが役立つようになったら、Codex GitHub Action を使って同じワークフローを CI でも簡単に自動化できます。特に効果的なのは、ローカルのワークフローがすでに安定している場合です。手動で使う過程で、指示の問題を見つけて直し、スクリプトを改善し、実際に起きる例外的なケースを把握できるからです。
公開リポジトリでは、スキルと同じくらい、何をきっかけにワークフローを起動するかが重要です。GitHub Action のセキュリティチェックリストでは、ワークフローを起動できる人を制限し、信頼できるイベントや明示的な承認を優先することを推奨しています。また、PR、コミット、イシュー、コメントに由来するプロンプト入力をサニタイズし、OPENAI_API_KEY を drop-sudo または非特権ユーザーの使用によって保護したうえで、ジョブの最後のステップとして Codex を実行するよう推奨しています。
書き込み可能なワークフローが、信頼できるとは限らない公開の入力を受け取る場合、リスクは主に、スキルの起動条件、入力の処理方法、実行時に付与する権限にあります。
PR レビューでの Codex の活用
両リポジトリの生産性向上を支えているのはスキルだけではありません。Codex による GitHub PR の自動レビューもその一つです。
GitHub PR の自動レビューが利用可能になって以来、両リポジトリのほとんどのコード変更で Codex がレビュアーとして役立っています。特別な場合だけ使うのではなく、通常のレビュー手順に組み込んでいます。
原因を特定しやすいプログラムのバグ、リグレッション、テストの不足については、今では実務上、必須のレビューを Codex に任せられるだけの信頼性があります。同じ観点で繰り返しコードの正しさを確認できるため、小さな修正や日常的な改善を進めるうえで大きなボトルネックが一つ解消されました。
一方、別の種類の変更では、開発者同士のレビューが今も重要です。
主な論点が「このコードは正しいか」ではなく、「妥当な選択肢が複数ある中でどれを選び、どうリリースするか」である場合、人によるレビューが欠かせません。たとえば、次のような場合です。
- API やアーキテクチャの変更で、合理的な設計が複数あり、メンテナーが明示的に選ぶ必要がある場合
- ユーザーが製品に期待する動作、後方互換性の保証、ロールアウト方針に影響する動作変更
- 命名、移行、リリースの告知について、ユーザーやコントリビューターに最も伝わりやすい選択肢を見極める必要がある場合
- 作業範囲や実施順序、今回リリースするものと後に回すものの区別など、メンテナー間やチーム間で合意が必要な変更
こうした場合にも Codex は役立ちますが、人が直接議論し、判断を下すことには引き続き価値があります。
AGENTS.md には、この役割分担も記載できます。コードの正しさをレビューする際に何を重視するかをリポジトリ側で示せば、Codex はその指針を一貫して適用できます。
この分担も、開発のスループット向上に大きく貢献しました。リスクの低い変更のたびに、定型的なレビューや検証のためにレビュアーの手が空くのを待つ必要がなくなりました。その分、メンテナーは背景を踏まえた判断が特に重要なレビューに集中できます。結果として、積み残していたバグの修正や小規模な機能改善を以前よりもずっと速く進められるようになりました。
まとめ
OpenAI Agents SDK のリポジトリでは、普段の開発手順に組み込むことで、スキルが最も効果を発揮します。
AGENTS.md で必須のワークフローを Codex に伝え、description で各ワークフローをいつ選ぶかを示します。手順が決まっている処理は scripts/ が担い、状況に応じた判断はモデルが担います。ローカルでワークフローが安定したら、Codex GitHub Action を使って同じ手順を CI でも実行できます。
この構成により、両リポジトリで日々の開発手順が明確になり、作業の確実性も高まりました。検証、リリースレビュー、PR の引き継ぎを毎回同じ手順で進められるため、小さな改善をより早くリリースできるようになっています。