一部のチームはトラフィックをクラウドに送信できません。サードパーティサービスへの発信呼び出しをブロックする企業ファイアウォールの背後にいるのかもしれません。コンプライアンス規則により、リクエストおよびレスポンスデータがあなたが管理するマシン上に留まる必要があるとされているのかもしれません。あるいは、環境全体がエアギャップされており、イントラネットから何も出ることが許されないのかもしれません。これらのいずれの場合でも、モックデータ自体がフェイクであっても、他者のインフラストラクチャ上にあるホストされたモックURLは選択肢になりません。
Apidogはこれをセルフホスト型ランナーで解決します。リクエストがApidogのクラウドモックに送信される代わりに、あなたが所有するサーバーに小さなプログラムをデプロイし、そのプログラムが自身のネットワーク内からモックレスポンスを返します。デザインはこれまで通りApidogプロジェクト内に存在し、提供（サービング）のみがあなたのハードウェア上で行われます。このガイドでは、ランナーとは何か、クラウドモックよりもランナーを選択すべき場合、ドキュメントからの設定方法、そして人々が混乱する一つの違い「ランナーはCLIではない」について説明します。チームがなぜ自社のボックスでモックを実行するのかという全体像を知りたい場合は、セルフホスト型APIモックサーバーに関するガイドが一般的なケースをカバーしており、OpenAPI Initiativeはこれらのモックが生成される仕様について説明しています。ぜひ試してみたいですか？まずApidogをダウンロードしてください。
セルフホスト型ランナーとは
Apidogセルフホスト型ランナーは、スタンドアロンサーバーにホストする自動化されたプログラムです。正式名称は「General Runner」で、スケジュールされた自動テストの実行、APIドキュメントのインポート、モックレスポンスの返却という3つの役割を果たします。この記事で扱うのは3番目の役割です。
ここが重要なポイントです。General Runnerをデプロイし、そのServer Hostを設定すると、プロジェクト内に「Runner Mock」という新しい環境が自動的に表示されます。その環境を通じて送信されるリクエストは、Apidogのクラウドモックからではなく、セルフホスト型ランナーからモックレスポンスを受け取ります。同じモックデザイン、同じ生成データですが、提供（サービング）を行うマシンが異なります。あなたのトラフィックがネットワークを離れることはありません。
これはクラウドモックのセルフホスト版です。チームがインターネットに接続でき、それに反対する規則がない場合、Apidogクラウドモックはデプロイするものがないため、よりシンプルです。以下のいずれかに当てはまる場合は、ランナーを利用してください。
- 外部ホストへのアウトバウンドトラフィックがブロックされているか、厳しく監査されている場合。
- コンプライアンスポリシーにより、リクエストデータが内部インフラストラクチャに留まる必要がある場合。
- 環境がエアギャップされており、クラウドエンドポイントに全く到達できない場合。
- モックのレイテンシをパブリックインターネット経由ではなく、自身のLAN内で測定したい場合。
上記のいずれにも当てはまらない場合、追加のDockerホストは不要なオーバーヘッドです。サーバーをプロビジョニングする前に、自分がどの状況にいるのか正直に判断してください。
プランと権限に関する注意点です。Apidogのドキュメントには、General Runnerやセルフホスト型モックに対する明示的な無料版と有料版の区分が記載されておらず、価格も示されていないため、このガイドでそれらを作成することはありません。設定にはチームまたはプロジェクトの管理者権限が必要です。ランナーのデプロイはチームリソース内で行われ、管理者のみがこれらの設定を開くことができるためです。リソースパネルが表示されない場合は、それが理由です。
始める前に必要なもの
ランナーはDockerコンテナとして提供されるため、ホストするサーバーにはDockerがインストールされている必要があります。ドキュメントでは最小バージョン20.10.0を要求し、20.10.13以降を推奨しています。現在のバージョンを確認してください：
docker --version
また、それを実行する場所も必要です。チームのApidogクライアントとApidogサービスの両方からアクセスできるLinux、macOS、またはWindowsマシンです。イントラネット上では通常、安定したIPまたはホスト名を持つ内部サーバーを意味します。これが必要な前提条件のすべてです。Docker、ホスト、およびチームに対する管理者権限。その他すべてはApidog内で設定します。
General Runnerをデプロイする
デプロイコマンドはApidog内から自動生成され、トークンが含まれているため、手書きする必要はありません。その流れは以下の通りです。
コマンドを生成する
Apidogホームを開き、チームを選択し、右側のサイドバーで「リソース」をクリックして「General Runnerをデプロイ」を選択します。いくつかの項目を設定するポップアップが表示されます。
- サーバーOS: Linux、macOS、またはWindows。これにより生成されるコマンドがホストと一致します。
- Dockerイメージ: General、Slim、またはCustomから選択します。GeneralにはNode.js 18、Java 21、Python 3、PHP 8がプリインストールされています。SlimはNode.js 18のみで、より小さなイメージです。Customはテストスクリプト用の追加ランタイムが必要な場合に独自のDockerfileを提供できます。
- 公開ポート: `-p`パラメータで設定します。例えば `-p 80:4524` は、ホストのポート80をランナーの内部ポートにマッピングします。
- マウントデータディレクトリ: `-v`パラメータで設定し、ランナーのデータが再起動後もホスト上に保持されるようにします。
完了したら、生成されたコマンドをコピーします。重要です：コマンドにはトークンが埋め込まれているため、データセキュリティの理由から一度しか表示されません。紛失した場合、古いものを復元するのではなく、新しいものを生成することになります。すぐにキャプチャしてください。
サーバーで実行する
コマンドをサーバーのターミナルに貼り付けます。インストールが自動的に開始され、イメージがプルされます。完了したコマンドはおおよそ次のようになります（あなたのものは異なり、実際のトークンが含まれます）：
docker run -d \
--name apidog-runner \
-p 80:4524 \
-v /opt/apidog-runner/data:/app/data \
apidog/runner:latest \
--token <YOUR_GENERATED_TOKEN>
コンテナが起動していることを確認します：
docker ps
ランナーコンテナがポートマッピングとともにリストに表示されるはずです。UIを確認したい場合は、Docker DesktopのようなDockerクライアントでも同じ情報が表示されます。
登録されたことを確認する
Apidogに戻り、「チームリソース」を開き、「General Runner」を開きます。更新ボタンをクリックします。ランナーは「Started」のステータスでデプロイ済みと表示されるはずです。最初は表示されない場合、更新ボタンが解決策です。しばらく待ってから再度クリックしてください。
ランナーのステータスには、知っておくべき3つの状態があります。
- Started（開始済み）: 有効になっており、Apidogと通信し、タスクを処理しています。これが望ましい状態です。
- Stopped（停止済み）: Apidog内で誰かが手動で停止しました。デプロイされたままですが、タスクは処理しません。
- Offline（オフライン）: Apidogへの接続を失ったため、何も処理できません。コンテナとネットワークパスを確認してください。
Runner Mockを有効にする
ランナーをデプロイすると、エージェントが利用可能になります。あと1ステップで、モックトラフィックをそれに向けます。
チームリソースでGeneral Runnerを開き、「Server Host」フィールドを見つけます。ランナーに到達可能なアドレスを入力します。単純なHTTP設定では、ローカルテストの場合は `http://127.0.0.1:80`、共有イントラネットホストの場合は `http://runner.internal.example.com:80` のように、公開したホストとポートになります。TLS終端プロキシの背後では `https://runner.example.com:443` のようになります。HTTPSについては後ほど詳しく説明します。
Server Hostが設定されると、Apidogはあなたのプロジェクト用にRunner Mock環境を自動的に設定します。確認してください：プロジェクトを開き、「環境管理」に進み、環境リストにRunner Mockが表示されていることを確認します。手動で作成したわけではありません。Server Hostを設定したことで表示されるようになったのです。
セルフホスト型モック経由でリクエストを送信する
さあ、使ってみましょう。例えば、社内受注管理APIのプロジェクトにエンドポイント `GET /orders/{orderId}` があるとします。そのエンドポイントを開き、上部にある環境ドロップダウンでクラウド環境の代わりにRunner Mockを選択します。リクエストを送信します。
レスポンスはあなたのランナーから返されます。Apidogはスキーマからモックデータを生成するため、適切に定義された`Order`スキーマは、空のプレースホルダーではなく現実的な値を返します。
curl http://runner.internal.example.com:80/orders/10583
{
"orderId": 10583,
"customerEmail": "amelia.turner@example.com",
"status": "shipped",
"total": 148.5,
"currency": "USD",
"createdAt": "2026-07-14T09:32:11Z"
}
このJSONは決してパブリックインターネットに触れませんでした。ランナーがエンドポイントのスキーマからそれを構築し、あなたのネットワーク内から提供しました。上記の`customerEmail`値のようなフィールドを意識した生成は、Apidogがスキーマの型とフィールド名を読み取ることで実現されます。これは、スマートモックによる現実的なモックデータの自動生成に関する補足記事で説明されているのと同じエンジンです。特定のリクエストが何を返すかを正確に制御したい場合は、エンドポイントにモックの期待値を追加します。ランナーはクラウドモックと同じ方法でその期待値を提供します。良いモックレスポンスを構築する仕組みは、サーバーがApidogのものであってもあなたのものであっても同じです。ホストだけが変わるのです。APIモッキングの背後にある一般的な概念は変わりなく適用されます。
HTTPS、データマウント、その他の実世界の詳細
`http://127.0.0.1`でのテスト実行は簡単です。共有イントラネット展開には、チームに展開する前に知っておくべきいくつかの注意点があります。
HTTPSにはリバースプロキシが必要
ランナーにはHTTPS証明書の組み込みサポートがなく、自動証明書プロビジョニングも行いません。TLS証明書をフェッチしたり管理したりすることはありません。`https://`が必要な場合は、ランナーの前面にあるリバースプロキシ（例えば、あなたの証明書を持つNginx）でTLSを終端し、そのプロキシのHTTPS URLをServer Hostに指定します。プロキシがない場合は、`http://host:port`を使用してください。Server Hostを`https://`に設定して、ランナーが直接TLSに応答することを期待しないでください。それはできません。
ポート4524でランナーの前面に立つ最小限のNginxブロックは次のようになります。
server {
listen 443 ssl;
server_name runner.example.com;
ssl_certificate /etc/ssl/certs/runner.example.com.pem;
ssl_certificate_key /etc/ssl/private/runner.example.com.key;
location / {
proxy_pass http://127.0.0.1:4524;
proxy_set_header Host $host;
}
}
その後、Server Hostは `https://runner.example.com:443` となります。TLS終端がチームにとって新しい場合は、HTTPSに関するMDNガイドが良い復習になります。
ファイルマウントはパス固有
モックやテストに追加のファイルが必要な場合、ランナーはコンテナ内の固定パスにそれらを期待するため、そこにマウントしてください。
- 外部プログラムは `/app/external-programs/` に配置します。
- データベース接続設定は `/app/database/database-connections.json` に配置します。
- SSLクライアント証明書は `/app/ssl/ssl-client-cert-list.json` に配置します。
これらを `-v` マウントを通じて設定し、再起動後も保持されるようにします。
再デプロイとアップグレードの動作
新しいランナーバージョンがリリースされると、「アップグレード」オプションが表示され、「その他のアクション」の下で「再デプロイ」が可能です。どちらも、新しいコンテナが起動する間、実行中のコンテナを停止します。安心できる点として、Apidogクライアント内の既存のスケジュールされたタスクは再デプロイやアップグレードの影響を受けないため、コンテナが再起動する間だけライブサービングが中断されるだけで、設定が失われることはありません。
Apidog CLIでワークフローを自動化する
混乱を避けるための明確な区別を説明します。ランナーはモックを提供し、スケジュールされたタスクを実行できる長寿命のエージェントである一方、Apidog CLIはCI用のワンショットテストランナーです。これらは異なるツールです。CLIはモックサーバーを提供、開始、またはホストすることはできません。`apidog run mock` や `apidog mock serve` というコマンドはありません。CLIの `apidog run` はテストシナリオ、テストシナリオフォルダ、テストスイートを実行し、その `mock` コマンドグループはデータとしてのモック期待値に対してCRUD操作を行うだけです。モックの提供はランナーの仕事であり、CLIの仕事ではありません。
したがって、この2つは次のように連携します。CLIやCursor、Claude Code、CodexなどのAIコーディングエージェントは、プロジェクト内のエンドポイントとスキーマを作成および更新でき、これにより仕様が進化してもモック出力が正確に保たれます。セルフホスト型モックがフロントエンド作業のブロックを解除したら、同じプロジェクトのテストシナリオをCIで単一のコマンドでヘッドレスに実行し、モックが記述した契約に対して実際のバックエンドを検証します。
apidog run -t <scenario_id> -e <env_id> -r html,cli
この単一のコマンドで、ライブバックエンドに対してシナリオを実行し、HTMLとCLIレポートを書き出します。Node.js v16以降では `npm install -g apidog-cli` でインストールします。Apidog CLIインストールガイドでは `apidog login` とトークンの設定について説明しています。すべてのプッシュでテストを実行するには、Apidog CLI CI/CDガイドに従ってパイプラインに組み込みます。CLIからのAPIモッキングに関する記事では、なぜターミナルがモック定義を管理するがホストしないのかを正確に説明しています。
よくある質問
チームがインターネットにアクセスできる場合でも、セルフホスト型ランナーが必要ですか？
おそらく必要ありません。クラウドモックは何もデプロイする必要がなく、よりシンプルな方法です。アウトバウンドトラフィックがブロックされているか監査されている場合、コンプライアンス規則によりデータが内部インフラストラクチャに保持される必要がある場合、または環境がエアギャップされている場合にランナーを選択してください。まずホスト型アプローチとマネージド型アプローチを比較している場合は、Apidogクラウドモックの解説がこのガイドの自然な補足となります。
Apidog CLIはセルフホスト型モックサーバーを起動できますか？
いいえ、できません。CLIは `apidog run` でテストを実行し、`mock` コマンドグループでモックの期待値をデータとして管理します。モックトラフィックの提供はGeneral Runnerまたはクラウドモックによって行われ、CLIではありません。ターミナルコマンドを1つ入力してポートで実行中のモックを取得したいと考えていた場合、それはランナーの仕事であり、上記で説明したようにGUIを通じて設定します。
ランナーは単独でHTTPSをサポートしていますか？
証明書を同梱したり、自動的にプロビジョニングしたりすることはありません。TLSを終端するためにNginxのようなリバースプロキシを前面に配置し、プロキシの `https://` URLをServer Hostに指定してください。プロキシがない場合は `http://host:port` を使用してください。
コマンドを実行したのにランナーが表示されないのはなぜですか？
チームリソースを開き、General Runnerに移動して、更新ボタンをクリックしてください。登録には少し時間がかかる場合があります。それでも表示されない場合は、`docker ps` でコンテナが実行されていることと、ホストがApidogから到達可能であることを確認してください。「Offline」ステータスは接続が切断されたことを意味します。「Started」が望ましい状態です。
複数のチームが1つのランナーを共有してグローバルモックサービスを提供できますか？
ランナーはあなたがデプロイしたチームに登録され、そのRunner Mock環境はプロジェクトごとに表示されます。モック環境を共有する分散型チームを運営している場合、グローバルチーム間でモック環境を共有するに関するガイドのパターンが、いくつのランナーをどこに立ち上げるかを決定するのに役立ちます。
まとめ
General Runnerを使用したセルフホスト型モッキングでは、モックデザインは常にApidogプロジェクト内に維持されつつ、リクエストデータはあなたが管理するインフラストラクチャに保持されます。1つのDockerコンテナをデプロイし、Server Hostを設定するだけで、Runner Mock環境が残りの処理を行います。クラウドが利用できない場合はこれを利用し、そうでない場合はクラウドモックを使用してください。自身のネットワーク上でモックを実行する準備はできましたか？Apidogをダウンロードし、ランナーをデプロイして、イントラネットから1パケットも出さずに最初のRunner Mockレスポンスを提供しましょう。