ApidogでHARファイルをインポートする方法 (キャプチャしたトラフィックをエンドポイントに変換)

ブラウザでアプリがリクエストを送信するのを見たことがあるでしょう。それは機能し、データはネットワークタブに表示されます。今度は、URL、ヘッダー、JSONボディを手動で再入力することなく、その同じ呼び出しを、保存、モック、テストできる文書化されたエンドポイントとして扱いたいと考えているかもしれません。

「目に見えるトラフィック」と「再利用可能なエンドポイント」の間のギャップを埋めるのがHARファイルです。ブラウザはすでに、すべてのリクエストとレスポンスを記録しています。その記録をエクスポートし、Apidogに渡せば、キャプチャされた各呼び出しがプロジェクト内の実際のエンドポイントになります。このガイドでは、Chrome DevToolsでHARをキャプチャし、適切なオプションでインポートし、生成されたエンドポイントを整理してリストを役立つ状態に保つまでの全手順を説明します。キャプチャワークフローについてより広く知りたい場合は、Apidogを使用したパケットキャプチャツールに関するガイドが関連情報を提供します。

Apidogを無料でダウンロードして、同じ画面で一緒に試すことができます。

HARファイルとは何か、そしてキャプチャされたトラフィックを保持する価値がある理由

HARはHTTPアーカイブの略です。Apidogのドキュメントによると、`.har`ファイルは「ウェブブラウザとサイトとのインタラクションをログに記録するために使用されるJSON形式のファイルです。ブラウザとサーバー間で送信されたウェブリクエスト、レスポンス、ヘッダー、およびその他のデータを記録します。」

簡単に言えば、HARファイルはブラウジングセッションの完全な記録です。すべてのGET、すべてのPOST、リクエストヘッダー、レスポンスボディ、タイミングが含まれています。JSON形式であるため、扱いやすく、メールで送信したり、バグレポートに添付したり、読み取り方を知っているツールにフィードしたりできます。

最後の部分がここで重要になります。キャプチャされたセッションは、APIが実際にどのように動作するかを示す記録であり、仕様がどうあるべきかを述べているものではありません。その記録をエンドポイントに変換すると、いくつかのものを無料で手に入れることができます。

実際のリクエスト形式。 アプリが送信した正確なURL、クエリパラメーター、ヘッダー、ボディであり、推測ではありません。
実際のレスポンス。 サーバーが返したステータスコードとペイロードで、モックまたはテストアサーションとして使用できます。
ドキュメントの出発点。 ドキュメント化されていない内部APIが、アノテーションを付けられる名前付きエンドポイントのセットになります。

これは、OpenAPI仕様がないサービスを引き継いだ場合、サードパーティのウィジェットがバックエンドとどのように通信するかをリバースエンジニアリングする場合、またはバグをトリガーした正確な呼び出しでバグを再現したい場合に便利です。

ステップ1：ブラウザのDevToolsでHARをキャプチャする

キャプチャはApidogではなく、ブラウザで行われます。ChromeとEdgeはどちらも同じDevToolsを使用するため、手順は同じです。注文履歴ページの背後にあるトラフィックをキャプチャしたいとしましょう。

記録したいページを開きます。APIがセッションを必要とする場合は、HARにもそれらのリクエストが含まれるため、最初にログインしてください。
開発者ツールを開きます。WindowsおよびLinuxでは`F12`または`Ctrl+Shift+I`、Macでは`Cmd+Opt+I`を押します。
**Network**タブに切り替えます。ここでは、DevToolsがページが行うすべてのリクエストを一覧表示します。
ページを更新するか、トラフィックをキャプチャしたいアクションをクリックします。注文履歴ビューを読み込むと、`/api/orders`、`/api/orders/{id}`、その他ページが必要とする呼び出しが発行されます。それぞれが1行として表示されます。
任意のリクエスト行を右クリックし、**Save all as HAR with content**を選択します。場所を選び、たとえば`order-history.har`としてファイルを保存します。メニューの表現がわかりにくい場合は、Chrome DevTools Networkリファレンスに同じキャプチャとエクスポートのフローが記載されています。

この「with content」の部分が重要です。これは、DevToolsにリクエストメタデータだけでなく、レスポンスボディも含むように指示します。これがないと、インポートされたエンドポイントにはリクエストの形状しかなく、例となるレスポンスがありません。

ブラウザを離れる前の簡単な健全性チェック：`.har`ファイルをテキストエディタで開くと、読み取り可能なJSONであることがわかります。各エントリが`request`と`response`オブジェクトを持つ`entries`配列が表示されます。これがApidogが読み取る構造です。

一つ覚えておくべきことがあります。ページの読み込みはAPI呼び出しだけでなく、画像、スタイルシート、スクリプトも取得し、それらのすべてがHARに含まれます。ブラウザでそれらをフィルタリングする必要はありません。Apidogには、インポート時にそれらを破棄するスイッチが用意されており、次に説明します。

ステップ2：HARをApidogにインポートする

ファイルを保存したら、Apidogに移動します。インポーターは1箇所にあります。

プロジェクトを開き、**Settings > Import Data > Manual**に進みます。
形式として**HAR**を選択します。
保存したばかりの`order-history.har`のような`.har`ファイルをアップロードします。

確認する前に、Apidogは3つのインポートオプションを表示します。これらは結果のクリーンさを左右するため、クリックして進む前にそれぞれのオプションを理解しておく価値があります。

オプション1：BaseURLの処理方法

キャプチャされたすべてのリクエストには、`https://api.shop.example.com/v1/orders/123`のような完全なURLがあります。ホスト部分をどうするかについて、2つの選択肢があります。

ハードコード は、BaseURLを各エンドポイントのパス内に保持します。すべてのエンドポイントが完全な`https://api.shop.example.com`プレフィックスを持ちます。
削除 (推奨) は、BaseURLを削除し、エンドポイントパスが`/v1/orders/123`になるようにします。その後、ホストは環境変数を通じてグローバルに管理されます。

特別な理由がない限り、**削除**オプションを選択してください。これが推奨設定であるのには理由があります。ベースURLが環境変数に存在する場合、環境を切り替えるだけで、エンドポイント自体を編集することなく、同じエンドポイントを本番環境、ステージング環境、またはローカルサーバーに向けることができます。ハードコーディングは、すべてのエンドポイントをキャプチャ元のホストに固定してしまうため、異なるサーバーに対してテストする必要が生じた瞬間に面倒になります。

オプション2：静的リソースの除外

これは、煩雑なエンドポイントリストを回避するためのスイッチです。**Static Resource**オプションを**Exclude**に設定すると、キャプチャされた画像、CSS、JavaScriptファイルをスキップするようにApidogに指示します。1回のページロードで数十ものファイルが生成されることがありますが、それらのどれもドキュメント化したいAPIエンドポイントではありません。

ほとんどすべてのインポートで**Exclude**をオンにしてください。フィルタリング後に残るのは、実際のAPIトラフィック、つまり`logo.png`のリクエストではなく、`/api/orders`などへのJSON呼び出しです。

オプション3：エンドポイントごとのテストケース生成

3つ目のオプションは**Endpoint Case Generation**です。これを**ON**にすると、Apidogはインポート時に各エンドポイントのデフォルトテストケースを作成します。テストケースとは、キャプチャされた値がすでに記入された状態で、保存され、実行可能なエンドポイントの呼び出しのことです。

これは後で報われる小さなステップです。これらのエンドポイントをテストすることが目標であれば、エンドポイントごとに準備されたケースがあれば、ゼロから構築するのではなく、すぐに実行できます。今のところドキュメントだけが必要な場合は、オフにして後でケースを追加することもできます。

インポートを確認します。ApidogはHARを読み取り、オプションを適用し、キャプチャされたブラウザのインタラクションをプロジェクト内のAPIエンドポイントに変換します。エンドポイントツリーを開くと、それらがグループ化され、準備されているのがわかります。

注文呼び出しを例として、インポートされたエンドポイントがどのようなものかを示すおおよその例を以下に示します。

GET /v1/orders/123
Host: api.shop.example.com
Authorization: Bearer <token-from-capture>
Accept: application/json

そして、Apidogがそれと一緒に保存するキャプチャされたレスポンスは以下の通りです。

{
  "id": 123,
  "status": "shipped",
  "total": 48.5,
  "currency": "USD",
  "items": [
    { "sku": "TSHIRT-BLK-M", "qty": 2, "price": 19.25 }
  ],
  "createdAt": "2026-07-14T09:31:00Z"
}

このレスポンスはサーバーが返した実際のデータであり、モックやテストアサーションの確固たる基盤となります。

ステップ3：生成されたエンドポイントをクリーンアップする

HARインポートは迅速な最初のステップであり、完成したAPI定義ではありません。キャプチャされたトラフィックは本質的に雑然としているため、結果を整理するために数分間時間を取る必要があります。

ノイズを削減する。 **Static Resource**を**Exclude**に設定しても、分析ピング、ヘルスチェック、または関心のないサードパーティの呼び出しが見つかる場合があります。使用しないエンドポイントは削除して、ツリーが実際のAPIを反映するようにしてください。
名前変更とグループ化。 キャプチャされたエンドポイントはパスに基づいて命名されますが、これは機能的ではあるものの平坦です。明確な名前（`/v1/orders/123`の代わりに「IDで注文を取得」など）を付け、APIの構造に一致するフォルダーに整理してください。
パスパラメーターの修正。 `/v1/orders/123`のキャプチャはリテラルパスとしてインポートされます。もし`123`が本当に注文IDであれば、そのセグメントが`{orderId}`パスパラメーターになるようにエンドポイントを編集してください。この1つの変更で、単一のキャプチャされた呼び出しが、任意の注文で機能する再利用可能なエンドポイントに変わります。
共有する前に秘密情報を削除する。 これは忘れがちです。HARはそのセッション中に有効だった認証トークンをキャプチャし、それがヘッダーに含まれてしまいます。プロジェクトをコミットしたりチームメイトと共有したりする前に、トークンを環境変数に移動し、キャプチャされた認証情報を例から削除してください。Stripeのドキュメントでも、本番キーを共有アーティファクトに漏洩させないことの重要性が指摘されており、HARはまさにそれらを漏洩させやすいアーティファクトです。
ボディの健全性チェック。 データが期待される場所でボディが空の場合、「with content」なしでエクスポートした可能性が高いです。**Save all as HAR with content**を使用して再キャプチャし、再インポートしてください。

エンドポイントが整理されれば、Apidogの他のエンドポイントと同じように機能します。それらをドキュメント化し、各レスポンスからモックを生成し、テストを構築できます。ここからはApidogでテストシナリオを作成するガイドが自然な続きとなり、これらのエンドポイントから型付きクライアントコードが必要な場合は、Apidogでクライアントコードを生成する方法を参照してください。

バリエーションと正直な制限

いくつか頻繁に発生する状況があります。

自動レコーダーはまだありません

Apidogがプロキシのようにバックグラウンドでトラフィックをリアルタイムで記録することを期待するかもしれません。しかし、それはありませんし、その点については正直に述べておく価値があります。ドキュメントには明確に記載されています：「Apidogは現在、自動記録エンドポイント機能をサポートしていませんが、将来的にサポートする計画があります。」

したがって、今日サポートされているパスは、このガイドで説明されているとおりです。ブラウザのDevToolsでキャプチャし、HARをエクスポートしてインポートします。ドキュメントに記載されている推奨フローは、ブラウザでエンドポイントを実行中にDevToolsを開き、終了時にHARをエクスポートし、Apidogにワンクリックでインポートした後、テストシナリオを作成し、再生のためにすべてのリクエストをインポートするというものです。これは手動のキャプチャステップに続くワンクリックインポートであり、ライブレコーダーではありません。自動記録機能が提供される際には、このセクションは変更されますが、それを待つ必要はありません。

Apidogブラウザ拡張機能は別のツールです

Apidogブラウザ拡張機能がありますが、これがHARトラフィックをキャプチャすると誤解しがちです。しかし、そうではありません。この拡張機能は、デスクトップクライアントを開かずに、ブラウザでApidogのAPIテストとデバッグを直接使用できるようにするものです。リクエストを実行するためのものであり、記録するためのものではありません。

HARのキャプチャは、あくまでブラウザ自身のDevToolsから行われます。拡張機能をテストに使用する場合、ブラウザがCookie、Host、Origin、Content-Lengthなどの特定のヘッダーをブロックしたり、GETまたはHEADリクエストでボディを送信しなかったり、ローカルコードやマシンの背後にあるデータベースに到達できなかったりといった制限を課すことを知っておいてください。インポート用のトラフィックをキャプチャするには、DevToolsとHARエクスポートを使用してください。完全なヘッダー制御が必要なより高度なデバッグには、Apidogデスクトップクライアントにはそのようなブラウザによる制限はありません。

他の形式も同じ方法でインポートできます

HARは、同じ**Settings > Import Data > Manual**画面が受け入れるいくつかの形式の1つです。すでにOpenAPIまたはSwaggerファイルがある場合、仕様は意図的に構造化されているため、それをインポートするとキャプチャよりもクリーンな結果が得られます。Swagger APIドキュメントをApidogに移行する方法に関するウォークスルーでその方法を説明しており、Postmanから移行する場合は、Postman環境とコレクションの移行ガイドも同様です。実際の仕様が存在せず、キャプチャされたトラフィックが手元にある最良の記録である場合にHARを使用してください。

Apidog CLIでワークフローを自動化する

HARのインポートはGUIのステップである必要はありません。Apidog CLIにはHARファイルを直接読み込む`import`コマンドがあり、これはサーバーでキャプチャが行われる場合、パイプラインでインポートをスクリプト化する場合、またはAIコーディングエージェントにキャプチャをエンドポイントに変換させる場合に最適です。

npm install -g apidog-cli
apidog login --with-token <YOUR_ACCESS_TOKEN>

# Turn a captured HAR into endpoints in your project
apidog import --project <PROJECT_ID> --format har --file ./capture.har

`--format`フラグは`openapi`、`postman`、`wsdl`、`insomnia`なども受け入れるため、1つのコマンドでほとんどのインポート元をカバーできます。エンドポイントが存在し、それらをテストシナリオに保存したら、そのシナリオをCIでヘッドレス実行します。

apidog run --access-token $APIDOG_ACCESS_TOKEN \
  -t <SCENARIO_ID> -e <ENV_ID> -r cli

ここで`-t`は保存されたテストシナリオID、`-e`は環境ID（BaseURLを保持する環境変数と同じもの）、`-r`はレポーターを選択し、`cli`はコンソール出力用です。Apidogでテストシナリオを作成するガイドでシナリオを構築し、Apidog CLI CI/CDガイドに従って両方のコマンドをパイプラインに組み込みます。

よくある質問

どのブラウザがHARファイルをエクスポートできますか？

DevToolsを備えたChromiumベースのブラウザであればどれでも同じ方法でエクスポートできます。そのため、ChromeとEdgeはどちらも**Network**タブと**Save all as HAR with content**メニュー項目を使用します。Apidogのドキュメントでは、特にChromeとEdgeのパスについて説明しています。他のブラウザには独自のエクスポートメニューがありますが、ラベルが異なる場合があるため、お使いのブラウザのDevToolsの表記に合わせてください。

インポートされたエンドポイントリストが膨大です。何が問題だったのでしょうか？

おそらく**Static Resource**がすべてを含むように設定されたままでした。ページロードでは画像、CSS、スクリプトが読み込まれ、それらすべてがHARに含まれます。**Static Resource**オプションを**Exclude**に設定してファイルを再インポートすると、リストは実際のAPI呼び出しに絞り込まれます。後で手動で残りを削除することもできます。

BaseURLにはハードコードと削除のどちらを選択すべきですか？

ほとんどすべての場合で**削除 (推奨)**を選択してください。これにより、ホストが各エンドポイントパスから分離され、環境変数を通じてグローバルに管理できるようになります。これにより、エンドポイントを編集することなく、本番環境、ステージング環境、ローカル環境を切り替えることができます。Apidogでのテストシナリオが実行時に読み取るのはこの設定です。完全なURLを各パスに焼き付けたい場合にのみ**ハードコード**を選択してください。

HARには認証トークンが含まれますか？

はい、それが注意点です。HARはセッション中に送信された実際のヘッダーを記録するため、有効だったベアラートークンやCookieもファイルに含まれます。HARは秘密情報として扱ってください。公開の課題に貼り付けたりせず、インポート後には認証情報を環境変数に移動し、プロジェクトを共有する前に保存された例からそれらを削除してください。

GUIをスキップしてコマンドラインからHARをインポートできますか？

はい。Apidog CLIの`apidog import --project--format har --file`コマンドは、アプリを開くことなくHARをプロジェクトにインポートします。これは、サーバー上でキャプチャが行われる場合やCIジョブ内で使用する場合に最適です。GUIは、一度限りのキャプチャに対してインタラクティブなインポートオプション（BaseURL処理、静的リソースフィルタリング）を提供するため、状況に応じて選択してください。スクリプト化されたインポートやエージェント主導のインポートにはCLI、インポートを手動で調整したい場合はGUIです。インポート後、`apidog run`はそれらのエンドポイントから作成したテストシナリオを再生します。

まとめ

HARファイルは、目に見えるトラフィックと再利用可能なエンドポイントを結びつける架け橋です。ブラウザのDevToolsで**Save all as HAR with content**を使用してセッションをキャプチャし、**Settings > Import Data > Manual**を通じて、BaseURLに**Remove**、**Static Resource**を**Exclude**に設定してインポートし、その後、数分かけて名前の変更、パラメーター化、秘密情報の削除を行います。これにより、ドキュメント化、モック、テストが可能な動作するエンドポイントのセットが手に入ります。

次のキャプチャを実際のエンドポイントに変える準備はできましたか？Apidogをダウンロードして無料で試してみてください。クレジットカードは不要です。