Antigravityはループです。そのエージェントはファイルを編集し、ターミナルコマンドを実行し、出力を読み取り、次に何をすべきかを決定します。では、なぜAPIテストがそのループに入っていないのでしょうか？APIテストはApidogのGUIの裏側にあり、誰かがクリックするのを思い出したときに実行されます。エージェントがそれらに触れることはありません。
解決策は、1つの設定ブロックです。Apidog CLIは、Apidogで構築したテストシナリオをターミナルから直接実行するnpmパッケージ `apidog-cli` です。CLIがインストールされ、Antigravityがその存在を認識すると、エージェントは単体テストを実行するのと同じ方法でApidogシナリオを実行します。コマンドを発行し、終了コードを読み取り、赤色（失敗）であればコードを修正します。
まだCLIをインストールしていない場合は、まずそれを行ってください。AIコーディングエージェントを使ったApidog CLIのインストール方法では、エージェントが入力を行いながら、npmインストール、認証、および最初の実行について説明しています。この記事は、`apidog --version` がバージョン番号を出力し、Apidogアカウントが認証されていることを前提としています。
ここでいうAntigravityとは
Antigravityは、Gemini 3をベースに構築され、2025年後半にリリースされたGoogleのエージェント型開発プラットフォームです。これは、作業を計画し、リポジトリ全体でファイルを編集し、自身のターミナルとブラウザでシェルコマンドを実行するエージェントマネージャーを介してエージェントを実行します。エージェントは主要なインターフェースであり、ローカルマシンで直接動作します。Antigravityを開き、タスクを開始し、エージェントがコマンドを実行して報告するのを見たことがあるなら、あなたは正しい場所にいます。より広範なツアーについては、Google Antigravityとは何か、その使用方法を参照してください。
この区別は重要です。なぜならAntigravityにはプロジェクトルールを学習する独自の方法があり、そのメカニズムによって一度限りの「テストを実行する」が、エージェントが自ら行うものへと変わるからです。
ステップ1: Antigravityにルールファイルを与える
Antigravityは、ワークスペースのルートにある特別な `.agents/` ディレクトリを認識します。Antigravityで自律型開発パイプラインを構築するに関するGoogle自身のコードラボでは、エージェントがそこに置いたファイルをネイティブに認識し、ワークスペースルールが `.agents/rules/` に存在することを示しています。プロジェクトのルールを `.agents/rules/apidog.md` のようなファイルに置いてください。Antigravityはまた、ワークスペースルートにある通常の `AGENTS.md` をクロスツール基盤として読み取ります。これはCodexがApidog CLI用に読み取るのと同じファイルです。もし既に `AGENTS.md` を保持している場合は、二つのファイルを維持する代わりに、そこにApidogブロックを追加してください。
そのルールファイルに短いApidogブロックを記述してください。例えば次のようになります。
## API testing with the Apidog CLI (Apidog CLIによるAPIテスト)
- To test the API, run the Apidog scenario, do not click through the GUI. (APIをテストするには、Apidogシナリオを実行してください。GUIをクリックしてはいけません。)
- Command: apidog run -t <scenario_id> -e <env_id> -r cli (コマンド: apidog run -t <シナリオID> -e <環境ID> -r cli)
- Exit code 0 means every assertion passed. Non-zero means a failure; open the report and fix the code. (終了コード0はすべてのアサーションが成功したことを意味します。0以外は失敗を意味します。レポートを開いてコードを修正してください。)
- The machine is already authenticated via `apidog login`. Never add an --access-token flag and never put a token in this file. (マシンは既に `apidog login` を介して認証されています。--access-tokenフラグを絶対に追加せず、このファイルにトークンを置かないでください。)
これが、CLIをチャットで言及するのではなく、ルールファイルに書き込む理由です。Antigravityはセッション間で教えられたことを記憶しません。ウィンドウを閉じてもう一度開くと、教えられた内容は消えてしまいます。チャットに入力されたシナリオIDはセッションが終了すると消えます。ルールファイルに書き込まれたものは、これ以降、すべてのチームメイトとすべてのAntigravityの実行のためにそこに存在します。
ステップ2: Apidogからコマンドを取得する
シナリオIDと環境IDを推測する必要はありません。Apidogでテストシナリオを開き、CI/CDタブに移動して、生成されたコマンドをコピーしてください。それは次のようになります。
apidog run -t 123456 -e 789012 -r cli
`-t` フラグはテストシナリオID、`-e` は環境ID、そして `-r cli` は結果をインラインで出力するレポーターを選択します。これらの実際のIDをあなたの `.agents/rules/apidog.md` ブロックに貼り付けて、エージェントがApidogが提供した正確なコマンドを実行するようにします。すべてのフラグについては、apidog runコマンドリファレンスを参照してください。
ステップ3: エージェントにテストを実行させる
ブロックを配置したら、Antigravityでタスクを開始します。エージェントは開始時にルールを読み込むため、CLIの存在をすでに知っています。APIに影響を与える変更を加えるか、単にチェックを実行するように依頼します。
Run the Apidog test scenario and tell me the exit code. (Apidogテストシナリオを実行し、終了コードを教えてください。)
エージェントは、ルールファイルから `apidog run` コマンドを自身のターミナルで発行します。プロンプトなしで実行されるかどうかは、あなたのパーミッション設定によります。Antigravityのセキュリティプリセットは、GoogleのAntigravity入門コードラボで説明されているように、エージェントが動作する前にターミナルコマンドとファイルアクセスがあなたによってレビューされるかどうかを決定します。もしプリセットがレビューを要求した場合、プロンプトが表示されたときに `apidog run` コマンドを承認してください。ステージング環境に対する読み取り専用のテストシナリオは、承認しても問題ない安全なワークスペース内コマンドの典型です。エージェントが自律的に進行するように設定している場合は、停止することなくコマンドを実行し、結果を報告します。
実行が進行し、エージェントが要約と終了コードの両方を報告するのを見たいのであって、言い換えられたものではありません。
ステップ4: Antigravity内でレポートを読む
実行が赤色（失敗）になった場合、レポートが答えを持っています。`-r cli` を使用すると、エージェントはターミナルで読み取り可能な詳細を得ます。各リクエスト、各アサーション、そして期待値と実際値でどれが失敗したか。失敗したアサーションは正確なフィールド名やステータスコードを特定し、これは通常、エージェントが修正を見つけるのに十分です。
ブラウザで開いたり、チームメイトに渡したりできるレポートが必要な場合は、HTMLレポーターを追加します。
apidog run -t 123456 -e 789012 -r cli,html
`html` レポーターは、自己完結型のファイルを `./apidog-reports` に書き込みます。エージェントが次のステップを決定するために読み取るインライン出力を引き続き取得できるように、リストに `cli` を残しておいてください。JUnit形式のCIダッシュボードが解析するレポーターを含むすべてのレポーターについては、Apidog CLI完全ガイドとApidog CLIテストレポートの読み方を参照してください。
Antigravity自身のループ内でのテスト
重要なのは、あなたが尋ねるのをやめ、ルールファイルが指示したためにエージェントが自力でシナリオを実行するときに何が起こるかです。
エージェントがチェックアウト応答を構築するハンドラを編集している場面を想像してみてください。そのループは変化します。コードを編集した後、成功を宣言する代わりに、ステージングに対してApidogシナリオを実行し、終了コードを読み取り、それに基づいて行動します。グリーン（成功）なら次に進みます。レッド（失敗）なら、レポートを開き、どのアサーションが失敗したか（ステータスコード、欠落しているフィールド、間違った値）を読み取り、修正を試み、再実行します。APIテストは、エージェントがすでに単体テストを実行しているのと同じ編集-テスト-修正ループの一部となります。あなたは一つの指示を書いただけで、エージェントはそのコマンドを既存の動作に組み込みました。
これは、あらゆるエージェントワークフローを安全にする「委任して検証する」モデルです。Antigravityはコマンドを実行し、結果を読み取ります。あなたはApidogでシナリオを視覚的に作成し続け、エージェントが終了コードを正直に読み取っていることをスポットチェックします。より広範なパターンについては、APIテストにAIエージェントを使用する方法とApidog AIテストハーネスを参照してください。
Antigravityが実際にCLIを実行していることを確認する
エージェントは、実際には達成していない成功を報告することがありますが、Antigravityも例外ではありません。問題を検出する頻度順に3つのチェックを行います。
まず、コマンドが実行されたことを確認します。Antigravityは実行したコマンドとその出力をターミナルに表示します。リテラルの `apidog run ...` の行と、その下の結果を探してください。エージェントがテストを実行したと言っているのにコマンドが表示されない場合、それは実際には行っていないことを要約していることになります。再度実行させ、生出力を表示するよう依頼してください。
次に、重要な終了コードを確認します。直接尋ねてください。
What was the exit code of that apidog run command? (そのapidog runコマンドの終了コードは何でしたか？)
`apidog run` は、すべてのアサーションが成功したときに `0` で終了し、何かが失敗したときに0以外で終了します。この単一の動作により、エージェントまたはパイプラインは、実行をクリーンなゲートとして扱うことができます。エージェントの文章が「テストが合格した」と述べているにもかかわらず、終了コードが0以外の場合、終了コードが正しいです。
第三に、実際のリナリオを使用したことを確認します。「シナリオが見つかりません」というエラーで実行が失敗した場合、エージェントがIDを捏造したか、誤って記憶している可能性があります。あなたのルールファイルと、ApidogがCI/CDタブで生成したコマンドに対して、`-t` と `-e` の値を再確認してください。あなたのルールファイルにあるIDが真実です。
オプション: Apidog MCPサーバーを接続する
ルールファイルから `apidog run` を実行することで、必要なことのほとんどをカバーできます。さらに進むには、MCPサーバーを接続します。
AntigravityはModel Context Protocolをサポートしており、そのMCPサーバーは、Googleの入門コードラボに従い、`$HOME/.gemini/config/mcp_config.json` ファイルに設定されます。そのファイルの `mcpServers` オブジェクトに、`command`、`args`、`env` を持つエントリとしてサーバーを追加し、Antigravityの設定でMCPを更新します。Apidog MCPサーバーはMCPを介してAPI仕様を公開するため、エージェントはコードを書いている最中にスキーマを読み取ることができ、事後に読み取るだけではありません。CLIがテストを実行し、MCPがエージェントに仕様を提供します。
Antigravityが間違った場合
セットアップ中にいくつかの失敗が頻繁に発生します。
ルールファイルを無視する。エージェントが一般的なコマンドを実行するか、まったく実行しない場合、ルールがロードされていない可能性があります。ファイル名が正しく、Antigravityがワークスペースに対して期待する場所に配置されていることを確認し、新しいタスクを開始してルールを再読み込みさせてください。
とにかくアクセストークンを渡してしまう。エージェントが `--access-token` を追加しようとする場合、それは公開されている例から推測しています。マシンは `apidog login` を介して認証されているため、あなたのルールブロックはすでにそうしないように指示しています。その行を強調し、決して実際のトークンをルールファイルに置かないでください。認証が実際にどのように機能するかについては、Apidog CLI認証を参照してください。
フラグを捏造する。「unknown option」エラーは、エージェントがあなたのバージョンにないフラグを推測したことを意味します。`apidog run --help` を実行させて、そこから正確なフラグをコピーするよう指示してください。これは常にインストールされているバージョンに対して正しいです。
失敗した実行を成功と報告する。これは最も費用のかかる問題であり、終了コードルールがあなたのルールファイルと検証ステップにある理由です。要約と終了コードが一致しない場合、終了コードが優先されます。
日常のエージェントからテストされたループへ
これがセットアップです。インストールガイドに従って一度 `apidog-cli` をインストールし、短いApidogブロックをAntigravityのルールファイルに追加するだけで、エージェントはコード編集にすでに使用している同じループ内でAPIテストを実行し、結果を読み取る方法を知るようになります。壊れたエンドポイントは、エージェントが変更作業中である間に捕捉され、デプロイ後ではありません。
GUIの背後にあるテストは人間がクリックしたときに実行されますが、Antigravityが決定するといつでも1行のコマンドが実行されます。あなたはApidogでシナリオを視覚的に構築し続け、エージェントはあなたが監視していない場所でそれらを実行します。Apidogをダウンロードし、1つのシナリオを構築し、その `apidog run` コマンドをルールファイルに記述すると、次の変更でエージェントがそれを認識するのを見ることができます。エージェントがいないパイプラインで同じコマンドを実行する準備ができたら、GitHub ActionsでのApidog CLIがシークレット、レポーター、および終了コードによるゲート処理について説明しています。