あなたは既にAIコーディングエージェントを使用しています。それはファイルを編集し、テストを実行し、ターミナル出力を読み取ります。では、なぜ今、npmコマンドをタブからコピーして一つずつ貼り付けるといった手作業でコマンドラインツールをインストールしようとしているのでしょうか？
その必要はありません。Apidog CLIは、`apidog-cli`という名前のnpmパッケージで、Apidogで作成したAPIテストシナリオをターミナルから直接実行します。インストールは短いシェルコマンドのシーケンス、認証ステップ、そして最初の実行で完了します。これこそ、Claude Code、Cursor、Windsurf、またはエージェントモードのGitHub Copilotのようなエージェントがうまくこなす機械的な作業です。あなたは目標を説明し、エージェントが実際のコマンドを実行し、あなたはその作業を確認するだけです。
このガイドでは、そのワークフローをエンドツーエンドで示します。エージェントに渡す正確なプロンプト、エージェントが実行するコマンド、そしてエージェントの言うことを鵜呑みにするのではなく、各ステップを検証する方法をご覧いただけます。最後に得られる成果は、セットアップに値するものです。CLIがインストールされ認証されると、エージェントは自身のループ内またはCI内でApidogテストを自分で実行し、その合否結果を読み取ることができます。これに沿って進めるには、少なくとも1つのプロジェクトを持つApidogアカウントが必要です。まだApidogをお持ちでない場合は、まずダウンロードしてください。
エージェントにインストールを任せる理由
エージェントがインストールコマンドを実行しても、コマンド自体は何も変わりません。自分で入力する`npm install -g apidog-cli@latest`と同じです。変わるのは、誰が入力し、誰が出力を読むかです。
エージェントがこれに優れているのは、3つの具体的な理由があります。コマンドを実行し、終了ステータスと表示されたテキストを読み取り、実際に見たものから次のステップを決定できるため、「コマンドが見つかりません」がコピー＆ペーストのループのように行き詰まることがありません。既にシェル、Nodeのバージョン、PATHを目の前にしているため、汎用的なものではなく、あなたのマシンに合わせて修正を適応させます。そして、Nodeの確認、インストール後のバージョンの検証、認証の確認といった退屈な部分を、あなたが各行を監視することなく実行します。
開始前に必要なもの
CLIはnpmパッケージとして提供されるため、唯一のシステム依存はNode.jsランタイムです。以下の3つの条件を満たす必要があります。
- Node.jsとnpmがインストールされていること。パッケージはnpmを介してインストールされ、Node上で実行されます。現在のLTSリリースは、すべての開発者マシンにとって安全な選択です。
- プロジェクトアクセス権を持つApidogアカウント。CLIは独自のテストを保存しません。Apidogプロジェクトにアクセスし、そこに存在するシナリオを実行するため、少なくとも1つのプロジェクトを見ることができるアカウントが必要です。
- 実行するテストシナリオがあること。ランナーはシナリオを実行し、個別のリクエストではありません。Apidogアプリで最初に作成してください：いくつかのリクエストを連携させ、アサーションを追加し、保存します。レスポンスに対するチェックの記述に慣れていない場合は、APIアサーション：実践ガイドで詳しく解説しています。
また、シェルコマンドを実行する権限を持つAIコーディングエージェントも必要です。Claude Code、Cursorのエージェント、WindsurfのCascade、GitHub Copilotのエージェントモードはすべてこれに該当します。開始前に確認すべき唯一のことは、エージェントがコマンドを提案するだけでなく、ターミナルで実行することを許可されているかということです。コマンドを貼り付けるようにしか出力できない場合でも、このガイドに従うことはできますが、Enterキーを押すのはあなた自身になります。
ステップ1：エージェントに環境をチェックさせる
まず、エージェントにNodeが存在するかどうかを確認させ、そもそもインストール可能かどうかを把握させます。次のようなプロンプトが有効です。
このマシンにNode.jsとnpmがインストールされているか確認してください。`node -v`と`npm -v`を実行し、バージョンを教えてください。どちらかが不足している場合は、自分でNodeをインストールしようとせず、その旨を報告してください。
エージェントは以下を実行します。
node -v
npm -v
エージェントは2つのバージョン番号を報告するはずです。あなたのチェック：エージェントが表示するバージョンを読み取ってください。Nodeがインストールされていると主張しているのにバージョン文字列が表示されない場合は、生のコマンド出力を貼り付けるように要求してください。プロンプトに「自分でNodeをインストールしようとしないでください」と記載する理由は、ランタイムのインストールはより大きな、マシン固有の決定であり、盲目的に任せるべきではないからです。Nodeが不足している場合は、nodejs.orgから自分でインストールし、その後続行してください。
ステップ2：エージェントにCLIをインストールさせる
Nodeが確認されたら、インストールを委任します。
https://apidog.com/apidog-cli-installation-guide.md を読み、指示に従ってください。
エージェントはインストールコマンドを実行します。
`-g`フラグは、`apidog`バイナリを単一プロジェクトの`node_modules`ではなく、グローバルなPATHに配置します。`@latest`タグは最新の公開バージョンをプルします。これは最初のインストールで望ましいものです。npmが完了すると、バイナリは`apidog`という名前になるため、ここからのすべてのコマンドは`apidog`で始まります。
その後、エージェントは検証を行います。
apidog --version
apidog --help
あなたのチェック：これはプロセス全体で最も重要な検証です。なぜなら、エージェントが成功を主張したが実際には達成できなかったという最も起こりやすい場所だからです。`apidog --version`が実際のバージョン番号を出力したことを確認してください。「コマンドが見つかりません」をエージェントが見過ごしていないことを確認してください。`--help`の出力には、`apidog run`とそのオプションがリストされているはずです。バイナリとそれに関連するランタイムが両方とも解決されることを自分で確認したい場合は、エージェントに以下を実行させ、結果を貼り付けるように依頼してください。
node -v && apidog --version && which node && which apidog
すべての行がバージョンまたはパスを返した場合、インストールはクリーンです。エージェントが問題を報告する場合、最も一般的な原因はグローバルなbinディレクトリがPATH上にないことです。この問題については、最後のトラブルシューティングセクションで説明します。
エージェントがグローバルパッケージを変更することを望まない場合は、代わりに`npx`を使用するように指示してください。`npx apidog-cli --version`はパッケージをフェッチして実行し、PATHに何も残しません。これは共有マシンや一時的なCIランナーに適しています。日常的に使用するマシンでは、グローバルインストールの方が繰り返し呼び出しが簡単で高速です。
ステップ3：エージェントに認証させますが、トークンはあなたが扱います
CLIはあなたのアカウントからシナリオを実行するため、許可されていることを証明する必要があります。これをアクセストークンで行います。これは完全に委任しない唯一のステップです。なぜなら、トークンは秘密情報であり、チャットのトランスクリプト、ログファイル、またはエージェントがエコーする可能性のある場所に貼り付けたくないからです。
まず、自分でトークンを生成してください。Apidogアプリまたはウェブコンソールを開き、ユーザーアバターをクリックして**アカウント設定**、次に**APIアクセストークン**に移動し、新しいものを生成します。安全な場所にコピーし、パスワードのように扱ってください。なぜなら、それを持っている人は誰でもあなたとしてシナリオを実行できるからです。
次に、プロンプトにトークンを一切入れずにエージェントに指示します。
トークンがこのチャットに残らないように、Apidog CLIの認証は自分で行います。実行すべき正確な`apidog login`コマンドを教えてください。私が実行したことを確認した後、`apidog whoami`を実行してCLIが認証されているか検証し、その結果を見せてください。
あなたのターミナルでログインコマンドを実行します。
apidog login --with-token YOUR_ACCESS_TOKEN
エージェントに検証を実行させます。
apidog whoami
あなたのチェック：`apidog whoami`はあなたのアカウント名を表示するはずです。表示されれば認証は設定されています。トークンを手元に置いておく理由は、単なる運用上の衛生管理です。エージェントのコンテキストウィンドウに入ったトークンは、ログや保存されたトランスクリプトに残る可能性があります。ログインコマンドはそれをローカルマシンに保存するため、エージェントは後でテストを実行するために生文字列を見る必要はありません。CIの場合も同じですが、より厳格であり、最後のセクションで説明します。
ステップ4：エージェントに最初のテスト実行を行わせる
「インストール済み」から「実際に実行された」状態へ移行しましょう。コアコマンドは`apidog run`で、シナリオIDを指定して実行します。
正しいコマンドを得る最もクリーンな方法は、Apidogにそれを構築させることです。Apidogでテストシナリオを開き、CI/CDタブに切り替え、コマンドラインオプションを選択すると、ApidogはシナリオID、環境ID、アクセストークンが既に記入された完全な`apidog run`コマンドを生成します。それをコピーすれば、確実に有効な開始点が得られます。次のような形式になります。
apidog run --access-token YOUR_ACCESS_TOKEN -t 605067 -e 1629989 -n 1 -r cli
各部分の機能は次のとおりです。`--access-token`は実行を認証します。`-t`はテストシナリオをIDで指定します（`605067`はプレースホルダーであり、あなたのものとは異なります）。`-e`は開発環境やステージング環境など、実行対象の環境を選択します。`-n 1`はシナリオを1回実行します。`-r cli`は読みやすいレポートをターミナルに出力します。
既にログインしているので、トークンなしでエージェントにIDを渡し、実行させることができます。
Apidog CLIで私のApidogテストシナリオを実行してください。既に認証済みなので、アクセストークンは渡さないでください。`apidog run -t 605067 -e 1629989 -n 1 -r cli`を使用してください。全出力を見せて、終了コードを教えてください。
エージェントはシナリオを実行し、ステップバイステップの実行結果と概要を報告します。あなたのチェック：終了コードを明示的に要求してください。なぜなら、それがダウンストリームのすべてが依存する信号だからです。`apidog run`は、すべてのアサーションが成功したときに`0`を返し、何らかの失敗があったときに非ゼロのコードを返します。この単一の動作により、パイプラインまたはエージェントは、追加の配線なしに実行をクリーンな成功または失敗のゲートとして扱うことができます。エージェントが「テストは合格しました」と言っているのに終了コードが非ゼロだった場合、それは間違っています。コードを信頼し、説明を信頼しないでください。
異なるレポート形式やより多くの反復が必要ですか？エージェントに`apidog run --help`を実行させてください。これにより、他のレポーターやデータ駆動の反復オプションを含む、ランナーがサポートするすべてのフラグが表示されます。すべてのフラグ参照とCIの例については、完全なApidog CLIガイドでそれぞれ詳しく説明されています。
その効果：エージェントが自分でテストを実行できるようになる
セットアップに価値があるのは、ここからです。CLIがインストールされ認証されると、Apidogテストの実行は、エージェントがいつでも発行し、その結果を読み取ることができる単一のシェルコマンドになります。これにより、APIテストがエージェントの通常のループに組み込まれます。
エージェントがエンドポイントに触れるハンドラーを変更する場面を想像してください。コードを編集して勝利を宣言するのではなく、エージェントは影響を受ける環境に対してApidogシナリオを実行し、終了コードを読み取り、それに基づいて行動することができます。グリーンであれば次のステップに進み、レッドであればレポートで失敗しているアサーションを読み取り、修正を試みます。テストは、エージェントが既にユニットテストを実行しているのと同じように、エージェントのフィードバックループの一部となります。このパターンのより広い視点については、AIエージェントをAPIテストに活用する方法で、その適合性と不適合性について解説しています。
これはCIにも直接適用されます。CIではエージェントは存在しません。コマンドがローカルで機能することを確認したら、エージェントにプッシュごとに実行するパイプラインステップを作成させることができます。そのメカニズム、秘密情報、レポーター、終了コードによるゲート処理については、GitHub ActionsにおけるApidog CLIで説明されています。
シェルコマンドの実行よりも深いエージェント統合を望むなら、Apidogの2つの機能がエージェントをAPI仕様とシナリオに直接接続します。Apidog MCPサーバーは、Model Context Protocolを介してAIコーディングツールにAPI仕様を公開し、エージェントがコーディング中にスキーマを読み取れるようにします。また、Claude SkillsとApidog CLIは、CLIワークフローを再利用可能なスキルとしてパッケージ化し、テスト実行ステップをClaudeが独自に利用できるようにします。どちらも、あなたが今セットアップした`apidog-cli`の上に構築されています。
委任されたインストールからテストされたループへ
これが全体の道のりです。Nodeの確認、エージェントによるnpmコマンド1つでの`apidog-cli`のインストール、`apidog --version`での検証、手元で管理するトークンでの認証、そして終了コードを確認しながらエージェントによる最初の`apidog run`の実行。数分の「委任と検証」作業で、あなたのアージェントはAPIテストを自分で実行できるようになります。
これが重要である理由は、他のテストゲートが重要であるのと同じですが、さらに一つ加わります。GUIの裏に閉じ込められたテストは、人間がクリックしたときにのみ実行されます。しかし、ワンラインコマンドはプッシュごとに実行されます。そして、そのコマンドがあなたのコーディングエージェントの手に届くようになれば、あなた自身がまだレビューしていない変更に対しても、エージェント自身の「編集-テスト-修正」ループ内で実行されるようになります。あなたは引き続きApidogで視覚的にシナリオを作成し、あなたのパイプラインとエージェントの両方が、人間が監視していないところでそれらを実行します。
ここから、同じコマンドをCIに指定してGitHub ActionsにおけるApidog CLIで利用したり、Apidog CLIの完全ガイドで全てのフラグの参照を読んだりできます。