少人数チームでCodex Subagentsを使ってコードレビューを分担する方法

少人数チームでCodex Subagentsを使ってコードレビューを分担する方法

大きなプルリクエストが届いたものの、レビューできるのはチームの二人だけ。Codex Subagentsを使えば、変更を読む仕事を独立したスレッドに分けられます。一つは正しさのリスク、二つ目はテスト、三つ目はドキュメントとの一致を調べます。約30〜45分で、チームリーダーが確認できるよう、場所と根拠を付けた指摘一覧を作ることが目標です。Gitリポジトリ、Codexの利用権限、レビュー範囲の明確な変更を用意します。

これは複数の調査を並行して進める方法であり、三つのエージェントに同じファイルを編集させる方法ではありません。OpenAIのSubagentsガイドは、コードの調査、テスト、問題の分類、要約など、読むことが中心の作業から始めるよう勧めています。各サブエージェントは個別にリソースを使うため、単独のセッションよりトークン消費が増える場合があります。

🧰 準備するもの

Codexのデスクトップアプリ、CLI、またはIDE拡張機能でリポジトリを開きます。現行の資料では、これらの画面でサブエージェントのワークフローを利用できますが、スレッドの表示方法は異なります。ターミナルに慣れていなければ、Codex CLIで初めて見るリポジトリを読み、修正し、検証するガイドから始めましょう。

レビュー対象のブランチ、信頼できるテストコマンド、関連資料を決めます。委任前にgit statusを実行し、未コミットの変更を記録してください。

チームには、バグの報告形式と深刻度を判断する共通ルールも必要です。AGENTS.mdに置く方法は、Codexでチームの作業ルールを統一する記事を参照してください。「危なそう」という印象ではなく、具体的な根拠を求めます。エージェントとチャットボットの違いは、AIエージェントの基礎記事で確認できます。

🪜 手順

1. 独立して答えられる問いに分ける

ログインと通知を変更するプルリクエストなら、三つのサブエージェント全員に「全部レビューして修正して」と頼むのは避けます。互いの結果を待たずに調べられる問いを三つ作ります。

  1. 正しさとセキュリティ: ログイン処理が権限確認を飛ばしたり、データを漏らしたり、エラーを誤って扱ったりしないか。
  2. テストと回帰: どのケースがテスト済みで、何が欠けているか。現在のテストで疑わしい問題を実際に検出できるか。
  3. 資料と外部の動作: 変更がAPI、フレームワークの資料、ユーザーの期待と一致するか。

各スレッドには同じ報告形式を指定します。指摘、ファイルと行、根拠、影響、不確実な点です。各スレッドは読むだけにし、メインエージェントは全結果を待ってから統合します。小さな変更ならCodexの単独セッションで十分かもしれません。

2. 明確な依頼で並行作業を始める

CodexのデスクトップアプリやIDEのチャット、または対話型CLIセッションで直接依頼します。角括弧をプロジェクトの情報に置き換えてください。

三つのCodexサブエージェントを使い、[ブランチまたはプルリクエスト]を[ベースブランチ]と比較してレビューしてください。
エージェント1は正しさ、アクセス制御、ユーザーに影響する不具合だけを調べてください。
エージェント2はテストの不足と回帰リスクだけを調べてください。既存のテストを読んだり実行したりできますが、ファイルは編集しないでください。
エージェント3は変更されたコードを[フレームワークまたはAPI]の公式資料とだけ照合してください。資料にアクセスできなければ、その制限を明示してください。
どのエージェントも、コードの編集、コミット、ブランチのプッシュをしないでください。同じファイルに結果を書き込まないでください。
各指摘にはファイルパス、場所、根拠、再確認の方法を付けてください。問題が見つからなければ、確認した範囲と未確認の点を報告してください。
全員の完了を待ち、重複する指摘を統合し、影響の大きさで並べてください。修正案は確認後にだけ提案してください。

OpenAIにも、セキュリティ、テスト不足、保守性を別のエージェントが見る、似たプルリクエストの例があります。CLIでは/agentでスレッドを確認、切り替えできます。デスクトップアプリとIDEでは画面から各サブエージェントのスレッドを開けます。指摘がリリース判断に影響するなら、メインスレッドの結論だけでなく、元のスレッドの根拠も読みます。

3. 権限とリソースの境界を守る

サブエージェントはメインセッションのサンドボックスポリシーを継承します。新しいスレッドを作っても、メインセッションにない権限は付きません。委任前に権限モードと利用可能なツールを確認します。読むだけなら依頼文に「編集しない」と明記し、カスタムエージェントなら読み取り専用にも設定できます。

操作によっては承認が必要です。対話型CLIでは、メインスレッドを見ているときに別のスレッドの承認依頼が表示されることがあります。判断前にスレッド名を確認してください。非対話型の処理では、新たな承認を要する操作が失敗し、エラーがメインの処理に返る場合があります。並行作業を動かすためだけに権限を広げないでください。

各サブエージェントはリソースを使います。作業を細かく分けすぎると費用が増えます。別途設定しなければ、子エージェントは親のモデルと推論の強さを引き継ぎます。

4. 結果を監査の草案として扱う

全スレッドが終わったら、重複した指摘をまとめ、矛盾を示すようメインエージェントに頼みます。一方が「期限切れセッションのテストはない」と言い、他方が別のフォルダーでテストを見つけることもあります。断定的なほうを選ばず、そのテストを開いて条件を読み、必要なら実行し直して結果を記録します。

次の依頼でまとめられます。

[プルリクエスト]について、三つのサブエージェントの結果を統合してください。
各指摘に、影響、ファイルと行、コードまたはテストの根拠、再確認の結果、判断する人を示してください。
推測だけの内容には「未検証」と付け、重複した指摘は削除してください。
まだコードを編集しないでください。最後に、承認前に手作業で確認する三項目を挙げてください。

影響の大きいコードは自分でも開き、関連テストを実行し、差分を確認します。Codex Cloudで検証付きのプルリクエストを作るガイドも、レビュアーに渡す前の照合方法を示しています。承認するかどうかを決めるのはチームです。

5. 検証してから修正を割り当てる

確認できた指摘を一つ選び、修正担当者、問題を示すテスト、変更を許すファイルの範囲を決めます。Codexに修正を任せるなら、レビュー段階とは分けます。コードの各領域には一人か一つのスレッドが責任を持つようにします。同じ作業ツリーで複数のスレッドが同時に編集すると競合し、テストが変化中の状態を読んでしまうことがあります。

修正後はテストを実行し、git diffを見て、重要な部分を別の人に読んでもらいます。テストが不安定なら、未検証であると正確に記録します。

✅ 結果の例

架空のプルリクエストが、新しい端末からログインしたときに通知する機能を追加したとします。三つのサブエージェントが次のように報告しました。

スレッド最初の指摘チームによる検証
正しさとセキュリティアカウント状態を確認する前に通知する経路があるかもしれない。ファイルを開き、ロックされたアカウントでテストする。問題を再現できたので承認前に修正する。
テスト古いセッションが期限切れになった後のログインを試すテストが見当たらない。テスト全体を検索し、該当するケースがないことを確認して追加する。
資料通知APIは一時的なエラーを返す可能性がある。使用中のAPIの公式資料を確認し、再試行の方法を決めて制限を記録する。

これは説明用の例であり、Codexが必ずこう答えるという意味ではありません。役立つ成果は、再現できる問題、根拠のあるテスト不足、チームが決めるべき事項です。

💡 うまく進めるコツ

曖昧な役職ではなく問いを渡す。 「セキュリティの専門家になって」だけでは、調査範囲が不明です。対象、出力形式、情報が足りないときの報告方法を書きます。

指摘の形式を統一する。 ファイル、行、根拠、再現方法、影響、不確実な点がそろうと統合が容易です。繰り返すレビューでは、チームの指示に書き、実際の失敗から改善します。

「見つからなかった」も認める。 サブエージェントは仕事をした証拠として問題を作る必要はありません。調べた範囲とアクセス上の制限を示してもらいます。

効果を測る。 正しい指摘、誤検知、再確認にかかった時間を記録します。改善しなければ、分担方法を変えます。

⚠️ 知っておきたい限界

三つのエージェントによるレビューは、責任を持つ三人の人間のレビューと同じではありません。全員が同じ誤った前提を持ったり、弱いテストを信じたりすることがあります。セキュリティ、データ、ユーザーの動作に関わる指摘は人が検証します。環境やテストデータが違えば結果も変わり得ます。

OpenAIのSubagents資料は、ChatGPT Workのホスト環境とローカルのCodexを区別しています。この記事の対象はリポジトリで作業するCodexです。Claude Codeのコマンドや設定をCodexにそのまま当てはめないでください。

チームの承認なしに、非公開のソースコード、秘密情報、顧客データを外部に送らないでください。調査スレッドが最新の資料を読めないなら、APIの動作を推測せず「資料を未確認」と報告します。

❓ よくある質問

Codexを開くとサブエージェントが自動で現れますか? 現行のCodexはサブエージェントのワークフローに対応していますが、開始方法は画面と適用される指示によって異なります。並行作業を明示的に依頼し、必ず自動で分割されるとは考えないでください。

一つのプルリクエストに何個のサブエージェントを使うべきですか? 本当に独立した問いの数に合わせます。小さなチームなら、ファイルごとに分けるより二つか三つの調査スレッドが管理しやすいでしょう。結果と実際の費用で判断します。

子エージェントには親より強い権限が付きますか? いいえ。メインセッションのサンドボックスポリシーを継承し、ツールや操作にも制限が適用されます。委任前に権限モードを確認してください。

三つのエージェントに同時にコードを編集させたほうが早いですか? 独立した編集を並行できる場合もありますが、競合のリスクが増えます。この記事のレビューでは、先に読んで根拠を報告させ、検証後にファイルの担当者を明確にして修正します。

三つの結論が食い違ったら、どれを選びますか? すぐには選びません。関連するコードとテストを開き、公式資料を確認し、できるだけ問題を再現します。それでも残る不確実性を記録して、レビュアーが判断します。

主な出典: Subagents、Code review、AGENTS.md、OpenAI Learn。確認日: 2026年10月5日。#Codex #Subagents #CodeReview #VibeCoding

他の記事