Codex、CI、Apidog APIテストを活用した独自のソフトウェアファクトリー構築方法

Gergely Orosz氏が作成したOpenAIの内部ソフトウェア工場の図が今週、話題になっています。ビルダーが成果を提出し、Codexがコードを書き、専門のレビューエージェントのチームがリスクについて議論し、エージェントが自分で構築したダッシュボードを見ながらデプロイを監視するというものです。これは、OpenAIのエンジニアにとって最も重要な部分においては、インストールできない内部ツールの説明でもあります。

Perf Factory、Sevbot、そして自己構築ダッシュボードを備えたエージェントによるデプロイは、OpenAI独自の可観測性スタック上で動作し、購入できるCodex製品の一部ではありません。今週構築できるのは、より小さなループですが、それでも実用的な作業を行うものです。ビルダーが成果を課題として定義し、Codexがブランチを操作し、CIが変更が実際に動作するかをチェックし、1つまたは2つのレビューエージェントがそれを確認し、人間がリスクのあるものを出荷前に承認してフラグの裏に隠すというものです。この全体は、元の図が見過ごしている1つの詳細にかかっています。「CIがパスする」というのは、CIが正しいものをチェックしている場合にのみ意味があります。APIの場合、それはAPI自体をテストするということであり、それを呼び出すコードだけではありません。

ボタン

この図が正しい点（そしてコピーできない点）

Pragmatic Engineerの記事の公開部分では、Codexが「目標に到達するまで一連のコード変更を行い、ソフトウェアが意図したとおりに動作するか検証する」というコアなループが説明されています。リスクの低い領域は自動承認され、リスクの高い変更はAIによるレビューが増えるか、人間の承認が必須になります。この「提案、検証、リスクティアによるレビュー」という構造は移植可能です。チームは何年もの間、プルリクエストボットやCIゲートを使ってこれを近似してきました。エージェントはループを速くし、監視を少なくするだけです。

移植できないのは、その周りの内部機構です。Perf Factoryはアラートとダッシュボードをふるいにかけてレイテンシの回帰を見つけ、修正案を提案します。Sevbotはインシデントを調査し、Slackで質問に答えますが、それ自体は緩和策を実行しません。エージェントによるデプロイは、変更が本番環境に投入されるのを監視し、OpenAIの内部テレメトリスタックを使用して独自のモニタリングを構築します。これら3つは、外部のCodex製品には出荷されていません。出荷されたのは、デスクトップアプリ、長時間実行されるタスク用の/goalコマンド、そして自分で設定するロールプラグインとスキルです。OpenAIのCodex製品ページでは、実際に利用できるものがカバーされています。

今週実行できる5段階のループ

縮小版は次のようになります。

ビルダーは成果を課題として提出します。タスクリストではなく、最終状態の説明です。「注文は合計金額を減額するオプションの割引コードを持つことができます。」この同じGitHub issueをSharklyのエージェントに渡すのが、既に出荷されている統合です。issueがタスクになり、実行結果は別の調整チケットではなくPRとして返されます。現在、10人までの組織は無料で利用できます。
Codexは/goalを使ってブランチを操作します。/goalコマンドがCodexとClaude Codeの自律的な実行をどのように駆動するかで説明されているように、エージェントに目標を与え、目標が達成されるまで自律的に反復させます。
CIはビルド、単体テスト、APIテストシナリオを実行します。これは、ほとんどのチームがスキップするか、不完全にしか構築しないステップです。
1つまたは2つのレビューエージェントが差分をチェックし、人間が低リスクを超えるすべてのものをレビューします。AIコードレビューツールは、人間がPRを開く前に多くの問題を発見できます。Sharklyでは、この部分で「リリース準備完了」が機能します。人間がそのステータスからタスクを移動させないと、何も完了にはなりません。また、コードを書いたエージェントと同じクルーに別のレビューエージェントを配置することもできます。
機能フラグの裏でデプロイします。これにより、誤ったマージがインシデントではなく、トグルで切り替えられるようになります。

ステップ3は、ループが機能するか、嘘をつくかのどちらかになる場所です。

CIがコードだけでなくAPIをテストしなければならない理由

Codexのコードレビューの仕組みで説明されているCodex自身のレビュー機能は、差分を読み取り、明白な問題を指摘します。サービスを実行して、それが何を返すかをチェックするわけではありません。単体テストは、エージェントが作成または保持した場合、コードが意図したことを行っていることを主に検証しますが、これはAPIが契約で約束したことを行っていることを検証するのとは異なります。ハンドラーを編集するエージェントは、すべての単体テストに合格しながら、すべてのクライアントが依存するレスポンスを静かに破壊する可能性があります。

注文APIを実行しているとします。POST /api/ordersは注文を作成し、そのレコードを返します。GET /api/orders/{id}はIDで1つを取得します。これら両方に対してOpenAPI仕様を保持しており、それに対してApidogテストシナリオを構築しています。注文を作成し、それを取得して、単体テストでは通常チェックされない4つのことを確認します。

ステータスコード。POST /api/ordersは201を返し、200や、バリデーションのエッジケースで静かに500を返すことはありません。
OpenAPI仕様に対するレスポンススキーマ。total_amountフィールドは数値のままであり、statusは定義した列挙値の1つのままであり、クライアントが依存するフィールドが静かに消滅したり名前が変更されたりすることはありません。
認証失敗。有効なトークンなしのリクエストは401を返し、空のボディを持つ200を返すことはありません。これは驚くほど一般的な回帰です。
レイテンシしきい値。シナリオは、レスポンスが設定された制限内で返されることをアサートします。これにより、ハンドラー内で一括処理されていないデータベース呼び出しを追加する変更が、顧客が気づく前に検出されます。

これらはまさに、ハンドラーレベルのリファクタリングがすべての単体テストに合格しながらも静かに壊す可能性があるチェックです。なぜなら、単体テストは通常、APIシナリオが実際に実行する境界をモックするからです。

パイプラインへの組み込み

CodexでApidog CLIを使用する方法に従った場合、これらのシナリオのCLIバージョンはすでにローカルで実行しているはずです。同じコマンドがCIで実行されます。ビルド、単体テストの実行、そしてApidogシナリオの実行を行うGitHub Actionsジョブは次のようになります。

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  build-test-verify:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install dependencies
        run: npm ci

      - name: Build and run unit tests
        run: npm run build && npm test

      - name: Install Apidog CLI
        run: npm install -g apidog-cli

      - name: Run orders API test scenario
        env:
          APIDOG_ACCESS_TOKEN: ${{ secrets.APIDOG_ACCESS_TOKEN }}
        run: |
          apidog run \
            --access-token $APIDOG_ACCESS_TOKEN \
            -t 88214 \
            -e 3301 \
            -r cli,junit

      - name: Upload Apidog reports
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: apidog-reports
          path: apidog-reports/

-tと-eの値は、あなたが考案したプレースホルダーではなく、Apidogからの実際のシナリオIDと環境IDです。apidog runコマンドのリファレンスはすべてのフラグをカバーし、Apidog CLIテストレポートはジョブがアップロードするJUnit出力を説明しています。apidog runは、アサーションが失敗すると非ゼロで終了するため、GitHub Actionsは、失敗した単体テストと同じようにジョブを失敗とマークします。

エージェントのプロンプトの例

/goalのポイントは、成果と終了条件を記述し、Codexが各ステップの承認なしに反復することです。割引コードの例では、適切なプロンプトは次のようになります。

/goal POST /api/orders にオプションの `discount_code` フィールドを追加します。
プロモーションサービスに対してそれを検証し、レスポンスの `total_amount` に
割引を適用します。既存のレスポンスフィールドの名前を変更したり削除したりしないでください。
完了する前に `npm test` と `apidog run --access-token $APIDOG_ACCESS_TOKEN -t 88214 -e 3301
-r cli` を実行してください。両方とも0で終了する必要があります。
Apidogの実行が失敗した場合は、失敗したアサーションを読み取り、テストではなくハンドラーを修正してください。

最後の行が重要です。チェックを緑色にしようとするエージェントは、バグではなくアサーションを編集することがあります。ループのどちら側を修正すべきかを明示的に伝えることで、テストシナリオが真実の源として保たれ、回避すべき障害とはなりません。

エージェントが契約を破った場合

Codexは割引フィールドを追加し、その過程で、近くで読んだファイルでの慣例に従ってtotal_amountをtotalAmountに改名します。単体テストはまだパスします。割引の計算はチェックしますが、フィールド名はチェックしません。ビルドは成功します。その後、ApidogシナリオがCIで実行され、OpenAPI仕様に対してレスポンスを検証し、失敗します。仕様はtotal_amountとありますが、レスポンスにはtotalAmountがあり、スキーマアサーションがすぐにそれを検出します。

CIは非ゼロの終了を報告し、JUnit出力の失敗したスキーマアサーションを指します。Codexはその失敗を読み取り、名前の変更が原因であることを確認し、割引ロジックを保持したまま元に戻します。シナリオがパスし、ビルドが緑色になり、プルリクエストは「パス」という言葉の背後にある実際の保証付きでレビューに進みます。APIレベルのチェックがなければ、その名前の変更は出荷され、total_amountを解析するすべてのクライアントが次のリリースで壊れることになります。

仕様に基づいてリスクを段階的に分類する

低リスクと見なされるものの漠然とした感覚の代わりに、リスク分類をOpenAPIの差分に結びつけます。デフォルト値を持つオプションフィールドを追加する変更は、テストが合格すれば自動マージの候補になります。フィールドを削除したり、名前を変更したり、ステータスコードを変更したりする変更は、差分の残りの部分がどうであれ、決して低リスクではありません。その単一のルールは、専門のレビューエージェントが指摘するであろうほとんどのものをキャッチします。ルールが指摘するものはすべて、マージ前に人間のレビュー担当者またはAIコードレビューツールによる2回目のパスにルーティングします。

機能フラグの裏で出荷し、闇に葬らない

変更がCIとレビューを通過したら、すべてのユーザーに直接ではなく、機能フラグの裏でデプロイします。これはOpenAIのエージェントによるデプロイステップの安価な代替手段です。ロールアウトを監視したり、独自のダッシュボードを構築したりするエージェントはいません。トラフィックの5%から開始するフラグと、100%に切り替える前にエラー率をチェックする人がいれば、内部ツールなしでほとんどの安全性を確保できます。問題がある場合は、プレッシャーの下でマージをロールバックするのではなく、フラグをオフにするだけです。

すでに存在する足場

すべての5つのステップをゼロから構築する必要はありません。orchflowsは、Orosz氏のスレッドへの返信で登場したオープンソースプロジェクトです。Claude CodeとCodex用のMITライセンスの/software-factoryコマンドであり、少数の再利用可能なスキルを中心に構築されています。これは出発点となる足場であり、上記のCIやレビューのステップの代替ではありません。それでも、独自のテストシナリオとリスクルールをこれに設定する必要があります。

構築をスキップすべきもの

Perf Factory、Sevbot、または自己構築ダッシュボードを備えたエージェントによるデプロイを再現しようとしないでください。これらは、ほとんどのチームが実行していないテレメトリに接続されたOpenAIの内部システムです。OpenAIの人間は依然として成果を定義し、高リスクの変更を承認し、インシデントの緩和を承認し、オンコールを維持しています。OpenAIが述べたように、「オンコール業務は過去のものではありません」。良いエンジニアリング規律にすぎないループの部分をコピーしてください。マージする前に検証し、実際に変更された内容によってリスクを段階的に分類し、明らかに安全でないものについては人間を関与させ続けることです。

ループを実行する

CIステップから始めましょう。それが他のすべてのステップを信頼できるものにします。Apidogで注文APIテストシナリオを構築し、ステータスコード、スキーマ、認証、レイテンシ予算をカバーします。CLIを使ってパイプラインに組み込み、/goalを実際の課題に向け、Codexにエージェントの言葉を信用するのではなく、実際にAPIの動作をアサートするチェックに対して反復させます。Apidogをダウンロードして最初のシナリオを構築し、ループが自らその価値を証明したら、レビュー担当者とフラグのステップを追加してください。