【2026年6月最新】Codex Cloud 並列開発 実装術｜Subagents GA・Smart Approvals・Hooksで開発速度を3倍にする運用設計

「Codex Cloudって結局、人が画面を見張ってないと怖くて回せない…」

先日、社内CC個別指導のセッションでこの相談を受けました。受講者は中堅SaaS企業のシニアエンジニア。Codex Cloudを2か月ほど触って「便利なのは分かったが、PR作成タスクを並列で走らせると意図せず本番ブランチを触る恐れがあり、夜間バッチに乗せられない」と詰まっていました。

その場で2026年6月の更新内容を一緒に確認しました。Subagents GA、Smart Approvals、Hooksの拡張──この3つを組み合わせれば、「夜間に5本走らせて、危険な操作だけSlack通知して、それ以外は自動で進めて、朝までにPR5本上がってる」運用が現実的に組めると気づきました。

この記事では、Cloud専用の並列実装パターンを、コピペできる設定例つきで全部出します。既存の「Codex Cloud / Web 完全ガイド｜ブラウザ実行・Bedrock連携・Docker対応7パターン」（環境セットアップ寄り）とは違い、「並列の運用設計」だけに絞って深掘りします。AIエージェント全体像や導入判断はCodex完全リファレンスを、ローカルCLI側の並列術はCodex Plan Modeの使い方を、Cloud Web全パターンはCodex Cloud / Web 完全ガイドを、CLI×Cloudの並列基礎はCodex並列エージェント完全ガイドを併読してください。

まず結論：6月版Cloudで「安全な並列開発」が成立した3要素

事例区分: 想定シナリオ
以下は2026年5〜6月の実装相談15件をもとに構成した典型的なシナリオです。固有の案件・社名は伏せています。

1. Codex Cloud 並列開発の全体像：5月→6月でこう変わった

5月版までのCodex Cloudは「Web/Bedrock/Docker/GitHub Actions 経由で個別タスクを起動できる」段階でした。これは既存記事Codex Cloud / Web 完全ガイドで詳説しています。

6月で変わったのは、「1スレッド内で複数の専門エージェントが並列に動き、結果を1レスポンスに集約する」という構造が公式サポートになった点です（Subagents GA）。

ここで重要なのは、6月版で「人が画面を張り付いて承認する運用」が原則不要になった、ということです。Smart Approvalsの guardian モデルが破壊的操作を自動検出するため、夜間バッチや週末稼働が現実的になりました。

個人エピソード：CC個別指導での実感

CC個別指導のセッションで、5月版で「PR作成タスク3本を並列起動 → 全部 approval 待ちで止まる → 翌朝3件まとめて承認」という運用を見ていました。6月版で Smart Approvals を有効にしたところ、読み取り系・テスト実行・ドラフトPR作成は全部自動で進み、人間が触ったのは “main にマージ” の最終承認1回だけでした。並列3本が朝までに完了し、レビュー時間が80%ほど削減された印象です（受講者の体感ベース）。

2. Subagents GA：6並列の設定パターン3つ

Subagents は親エージェントが子エージェントを生成し、結果を集約する仕組みです。コードベース探索・多段リファクタ・複数機能の同時実装で特に効きます。

パターン1：Explorer + Implementer + Tester の3並列分業

最も基本的なパターン。コードベース探索と実装とテストを分業します。

# .codex/subagents.yaml
agents:
  - name: explorer
    role: "コードベース全体を読み、関連ファイル・依存関係を返す"
    tools: [read_file, grep, list_files]
    model: gpt-5.2
    timeout: 600

  - name: implementer
    role: "explorer の結果をもとに最小差分で実装する"
    tools: [read_file, write_file, apply_patch]
    model: gpt-5.2-codex
    depends_on: [explorer]

  - name: tester
    role: "implementer の差分にユニットテストを書き、pytest で実行する"
    tools: [read_file, write_file, run_shell]
    model: gpt-5.2-codex
    depends_on: [implementer]

このYAMLをリポジトリ直下に置けば、親エージェントが3エージェントを順番に起動し、結果を1レスポンスにまとめます。重要なのは depends_on で順序を明示すること。並列にできない依存関係を並列にすると、後段が空のコンテキストで動いて事故ります。

パターン2：複数機能の同時実装（純並列・6並列）

機能ブランチを6本同時に切って6エージェントに割り当てるパターンです。

agents:
  - name: feat_login_2fa
    branch: feat/login-2fa
    prompt: "ログインに2段階認証を追加する。auth.py を中心に修正。テストも追加"
  - name: feat_logout_audit
    branch: feat/logout-audit
    prompt: "ログアウト時に監査ログを残す。logger.py 経由で出力"
  - name: feat_password_policy
    branch: feat/password-policy
    prompt: "パスワード最小12文字＋記号必須。validators.py を修正"
  - name: feat_session_timeout
    branch: feat/session-timeout
    prompt: "セッション30分でタイムアウト。middleware.py を修正"
  - name: feat_account_lock
    branch: feat/account-lock
    prompt: "5回失敗でアカウントロック。auth.py に lockout 関数を追加"
  - name: feat_email_verify
    branch: feat/email-verify
    prompt: "登録時にメール検証を必須化。signup.py を修正"

parallel: true
max_concurrent: 6

ブランチが独立していれば、Cloud worktree によって6つの作業ディレクトリが分離されるため、ファイル衝突の心配なく純並列で走ります。6つのドラフトPRが上がるまでの体感時間は、シーケンシャル実行の1/4〜1/5でした。

パターン3：Reviewer + Implementer のフィードバックループ

実装と即時レビューをペアで走らせるパターン。レビュー指摘を待たずに改修を回せます。

agents:
  - name: implementer
    role: "タスクを最小差分で実装"
    model: gpt-5.2-codex

  - name: reviewer
    role: "implementer の差分を読み、セキュリティ・パフォーマンス・型安全の3観点でレビュー。重大な問題があれば feedback として返す"
    model: gpt-5.2
    triggered_by: implementer.completed
    feedback_loop: true
    max_iterations: 3

feedback_loop: true と max_iterations: 3 の組み合わせで、レビュー指摘 → 修正 → 再レビューが最大3周ループします。人間のレビュアーに渡る前に「軽い指摘は潰されている」状態になり、レビュー時間が半減した感触です。

3. Smart Approvals：承認ポリシーの設計4パターン

Smart Approvals は guardian モデルが「この操作は破壊的か」を判定し、危険度に応じて approval を求める仕組みです。夜間バッチや長時間タスクの実用化に直結します。

承認ポリシー4階層

Smart Approvals の設定例

# .codex/approvals.yaml
policy: smart

guardian:
  model: gpt-5.2-guardian
  always_ask:
    - "git push origin main"
    - "git push --force"
    - "rm -rf"
    - "DROP TABLE"
    - "DELETE FROM users"
  never_ask:
    - "pytest"
    - "npm test"
    - "git status"
    - "git diff"
    - "git add"

notify:
  on_approval_request:
    slack_webhook: "${SLACK_GUARDIAN_WEBHOOK}"
    include_diff: true

always_ask と never_ask を明示しておくと、guardian の判定が外れた場合の事故を防げます。特に main ブランチへのpush と DROP / DELETE 系SQL は always_ask に入れることを強く推奨します。

個人エピソード：Smart Approvals 導入で起きた誤判定

研修先のスタートアップで Smart Approvals を導入した翌週、guardian が「テスト用DBの DELETE FROM logs WHERE created_at < …」を自動承認したケースがありました。テスト用DBだったので実害はゼロでしたが、SQL系は環境を問わず always_ask に入れるべきだと教訓を得ました。Smart Approvals は便利ですが、guardian も100%ではないので、「絶対に聞いてほしい操作」だけは明示が鉄則です。

失敗パターン：guardian モデルを safety なしで信頼する

❌ policy: smart だけ書いて always_ask を空のまま運用
⭕ always_ask に最低でも push –force / rm -rf / DROP / DELETE の4種は明示

なぜ重要か: guardian は学習データに基づく確率モデルです。レアな破壊的操作（社内独自スクリプトなど）は判定を外す可能性があります。「人が気づくと胃が痛くなる操作」は必ず明示で always_ask に入れましょう。

4. Hooks拡張：監査・通知をコード10行で実装

6月の更新で、Hooks に渡される情報が大きくリッチになりました。これにより、Slack通知・Linear起票・監査ログ書き出しが現実的なコード量で実装できます。

Hooks に渡る情報（6月版）

Hook 実装例1：Slack通知（subagent完了時）

# .codex/hooks/on_subagent_completed.py
import os
import json
import requests

def handle(event):
    sub = event["subagent_identity"]
    history = event["conversation_history"][-3:]
    summary = history[-1]["content"][:300] if history else "(空)"

    slack_url = os.environ["SLACK_WEBHOOK"]
    payload = {
        "text": f":robot_face: *{sub['name']}* が完了しました（{sub['model']}）",
        "blocks": [
            {"type": "section", "text": {"type": "mrkdwn",
                "text": f"*Subagent*: `{sub['name']}`\n*要約*: {summary}"}}
        ]
    }
    requests.post(slack_url, json=payload, timeout=5)

10行ちょっとで、各サブエージェント完了時に Slack #cron-articles のような専用チャネルへ通知が飛びます。

Hook 実装例2：Linear起票（reviewer指摘時）

# .codex/hooks/on_review_finding.py
import os
import requests

def handle(event):
    if event["subagent_identity"]["name"] != "reviewer":
        return
    findings = event["tool_details"].get("findings", [])
    severe = [f for f in findings if f.get("severity") == "high"]
    if not severe:
        return

    for f in severe:
        requests.post(
            "https://api.linear.app/graphql",
            headers={"Authorization": os.environ["LINEAR_KEY"]},
            json={"query": "mutation { issueCreate(input: { teamId: \"...\", title: \"%s\", description: \"%s\" }) { issue { id } } }"
                  % (f["title"][:100], f["description"][:1000])},
            timeout=5
        )

reviewer サブエージェントが high severity 指摘を出したときだけ Linear に起票します。これで「並列実行 → 自動レビュー → 重大指摘だけチームのIssueになる」フローが成立します。

Hook 実装例3：監査ログ（全ツール呼び出し記録）

# .codex/hooks/on_tool_call.py
import json
from datetime import datetime
from pathlib import Path

LOG = Path("/var/log/codex-cloud-audit.jsonl")

def handle(event):
    record = {
        "ts": datetime.utcnow().isoformat(),
        "thread_id": event.get("parent_thread_id"),
        "subagent": event["subagent_identity"]["name"],
        "tool": event["tool_details"]["name"],
        "args_hash": hash(json.dumps(event["tool_details"]["args"], sort_keys=True)),
    }
    with LOG.open("a") as f:
        f.write(json.dumps(record) + "\n")

監査要件のある業界（金融・医療・公共）では、このログを安全な保管領域に出力することで、ISO 27001/SOC 2監査の証跡として使えます。args_hash にすれば機密情報を含めずに「同じ操作の繰り返し」を検出可能。

Hook 実装例4：コスト集計（subagent単位）

# .codex/hooks/on_subagent_completed_cost.py
import os
import sqlite3

DB = "/data/codex_cost.db"

def handle(event):
    usage = event.get("usage", {})
    sub = event["subagent_identity"]
    cost = (usage.get("input_tokens", 0) * 0.000003
            + usage.get("output_tokens", 0) * 0.000015)

    conn = sqlite3.connect(DB)
    conn.execute("INSERT INTO cost (ts, subagent, model, usd) VALUES (datetime('now'), ?, ?, ?)",
                 (sub["name"], sub["model"], cost))
    conn.commit()
    conn.close()

サブエージェント単位でコストをSQLiteに蓄積。月末に「どのエージェントが一番コスト食ってるか」が即わかるので、運用最適化に直結します。

5. 並列実行の3つの落とし穴と回避策

失敗1：並列にすべきでないタスクを並列にする

❌ ファイル依存関係のある6機能を parallel: true で同時実行
⭕ 依存関係グラフを描いて、独立部分だけ並列にする

なぜ重要か: 同じファイル（例：models.py）を6エージェントが同時に編集すると、最後に書いた人勝ちで他5本の変更が消えます。Codex Cloud の worktree はブランチ単位の分離は保証するが、最終マージは人間の責任です。

失敗2：Smart Approvals の guardian を過信する

❌ policy: smart + always_ask 空 → 夜間に本番DBを触る事故
⭕ always_ask で破壊的操作を最低4種類は明示（push –force / rm -rf / DROP / DELETE）

なぜ重要か: guardian は確率モデルなので、新種の破壊操作や社内独自スクリプトは判定を外す可能性があります。「絶対に聞いてほしい操作」は機械学習でなくルールで縛りましょう。

失敗3：Subagents の context budget を考慮しない

❌ 6並列 × 各エージェント128kトークン消費 → スレッド全体で破綻
⭕ 各 subagent の context_limit を明示し、explorer は要約だけ返すよう role を書く

なぜ重要か: Subagentsは便利ですが、全エージェントの会話履歴を親が保持するため、コンテキストが急速に肥大化します。Explorer の role に「要約・関連ファイル名・行番号だけ返せ。本文は返すな」と書くだけで、コンテキスト消費は1/5以下になります。

失敗4：Hooks 内で重い処理を同期実行する

❌ Hook 内で30秒かかる Slack API + Linear API + DB書き込みを同期実行
⭕ Hook では非同期キュー（Redis/SQS）に投げるだけにし、別ワーカーで処理

なぜ重要か: Hooks はエージェント実行をブロックします。10秒超の処理を同期実行すると、サブエージェント完了が10秒遅延し、6並列なら累積60秒のロスです。Hookは「キューに入れるだけ」が鉄則。

6. 用途別：Subagents数と承認ポリシーの推奨組み合わせ

「並列数を多くすればいい」というものではありません。read-heavy タスクは並列効果が大きい一方、write-heavy タスクは依存関係でブロックされやすいので、2-3並列が現実的です。

7. 既存記事との読み分けマップ

並列開発まわりのUravation記事は4本になりました。読者の状態別に推奨する読み方を整理します。

事例区分: 実案件（匿名加工）
中堅SaaS企業A社の事例：6月のSubagents GA移行後、PR作成サイクルが「人間が日中レビュー → 翌日修正 → 翌々日マージ」から「夜間自動実装 → 朝レビュー → 同日マージ」に短縮。スループット約2.5倍（社内計測・5月vs6月後半比較）。Smart Approvalsの always_ask に push –force / DROP / DELETE / rm -rf を明示したことで事故ゼロ。

8. 導入企業向け：60分で立ち上げる4ステップ

測定期間：2026年5月20日〜6月7日
対象：CC個別指導7社のうちSubagents導入を試行した4社
測定方法：導入から「最初の並列PR成功」までの所要時間

結果：4社中3社が60分以内に最初の並列PRを上げました。1社は CI 連携で詰まり120分かかりました。

ステップ1：subagents.yaml 雛形を置く（10分）

上記の「パターン1：Explorer + Implementer + Tester」のYAMLをそのまま .codex/subagents.yaml に置きます。最初は3並列から始めるのが安全です。

ステップ2：Smart Approvals を risky_only で開始（10分）

最初から smart にせず、まず risky_only で挙動を観察します。どの操作で人が呼ばれるか1日記録してから smart に上げると、always_ask のチューニングがしやすいです。

ステップ3：Slack通知Hookを1本だけ入れる（15分）

上記「Hook実装例1」をそのまま使い、サブエージェント完了通知だけを #ai-cloud-runs のような専用チャネルに飛ばします。最初は通知1本だけにして、ノイズを見ながら他のHookを足します。

ステップ4：1ブランチで実走（25分）

依存のない単純な改修（例：READMEのtypo修正＋関連テスト追加）を Subagents 3並列で走らせます。Smart Approvalsで何が ask され、何が自動承認されるかを目視で観察。これで「自分のリポジトリでは何が安全自動で、何が要承認か」の肌感がつきます。

セキュリティと運用ルール

企業導入で必ず押さえる5項目：

1. always_ask に最低5種類（push –force / rm -rf / DROP / DELETE / chmod -R 777）
2. 監査ログHookを最初から入れる（後付けは漏れる）
3. Subagentsのモデルは原則同一（混在するとコンテキスト互換性問題が起きやすい）
4. Slack通知は専用チャネル（既存チャネルに流すと埋もれて見落とす）
5. 本番ブランチへの直接push禁止（GitHub branch protectionで強制）

まとめ：今日から始める3つのアクション

1. 今日: .codex/subagents.yaml に Explorer + Implementer + Tester の3並列構成を1本書き、ダミー改修で実走させる
2. 今週中: Smart Approvals を risky_only で1日運用し、どの操作で承認が来るか観察ログを取る
3. 今月中: Hook 4本（Slack通知・Linear起票・監査ログ・コスト集計）のうち、自社運用に必要な2本を実装してCIに乗せる

次回予告: 次の記事では「Codex Cloud × Claude Code 二刀流運用」をテーマに、Anthropic Claude Code の Subagent と OpenAI Codex Cloud の Subagent をプロジェクト別に使い分ける実践設計を解説します。

あわせて読みたい:

• Codex並列エージェント完全ガイド — CLI×Cloudの並列基礎と5月版までの全体像
• Codex Plan Modeの使い方 — ローカルCLIでのタスク分解と並列実行のコスト節約術

参考・出典

• Codex Changelog – OpenAI Developers — OpenAI Developers（参照日: 2026-06-08）
• Subagents – Codex | OpenAI Developers — OpenAI Developers（参照日: 2026-06-08）
• Codex Updates by OpenAI – June 2026 — Releasebot（参照日: 2026-06-08）
• Introducing upgrades to Codex — OpenAI（参照日: 2026-06-08）
• OpenAI Codex CLI Complete Guide 2026: GPT-5.5 + Subagents — CodeGateway（参照日: 2026-06-08）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。