Chrome検証ツールのCopy as cURL活用ガイド｜リクエスト再現と認証情報の安全な扱い

Chromeの検証ツール（DevTools）にある「Copy as cURL」は、ブラウザが送ったネットワークリクエストを、ヘッダーやCookieを含めてそのままcurlコマンドへ変換する機能です。本記事では、基本操作に加えて、cURL・PowerShell・fetch・HARという各コピー形式の使い分け、Windowsで動かないときの対処、Cookieや認証トークンを安全に扱う方法、そして再現に失敗する原因の切り分けまでを実務目線で整理します。手作業でリクエストを組み立てる手間を省き、デバッグやAPIテスト、バグ報告を速くするための判断材料が得られます。

まとめ：用途で選ぶコピー形式と認証情報を漏らさない共有ルール

形式は用途で選びます。ターミナルやPostman・Insomniaへ持ち込むならCopy as cURL、ブラウザのコンソールやNode.jsで再実行するならCopy as fetch系、Windowsでそのまま動かしたいならCopy as PowerShellが基本です。複数リクエストをまとめて記録・共有するならCopy all as HARを使い、社外や第三者に渡す場合は機密を除外する「HAR (sanitized)」を選びます。

もう一つの要点は安全性です。生成されるコマンドにはCookie・Authorizationヘッダー・APIキーがそのまま含まれます。バグ報告やチャットに貼る前に該当値をプレースホルダへ置き換え、公開リポジトリには貼らない運用を徹底してください。再現できないときは、まず認証情報の期限切れとCSRFトークンを疑うのが最短ルートです。

Copy as cURLが解決するブラウザ通信の再現とデバッグの手間

Copy as cURLは、ネットワークパネルに記録された任意のリクエストを、コマンドラインで実行可能な形に書き出す機能です。まずは何を解決する道具なのかを押さえます。

Copy as cURLの定義とネットワークパネルでの位置づけ

Copy as cURLは、DevToolsのNetworkパネルに表示された1件のリクエストを右クリックし、ヘッダー・メソッド・ボディを保ったままcurlコマンドへ変換してクリップボードへ書き出す機能です。対象はドキュメント取得だけでなく、XHRやFetchで飛ぶAPI通信も含まれます。ブラウザが実際に送った内容を「そのまま」写し取れる点が、目視でヘッダーを確認する作業との違いです。

右クリックメニューからcURLコマンドを取得する基本操作

対象リクエストの行を右クリックし、「Copy（コピー）」→「Copy as cURL（cURLとしてコピー）」を選ぶだけで取得できます。あとはターミナルへ貼り付けて実行すれば、ブラウザと同じ条件でレスポンスを確認できます。日本語UIでは「コピー」配下にメニューが並ぶため、メソッドやヘッダーを手で書き写す必要はありません。

コピーされるコマンドに含まれるヘッダー・Cookieの中身

出力には-Hで各リクエストヘッダーが列挙され、CookieやAuthorization、User-Agent、sec-ch-uaなどが含まれます。POSTであればボディも--data-raw等で再現されます。Cookieを外して実行すると応答が空になる、といった切り分けができるのは、認証状態まで丸ごとコピーされているためです。

フロントエンド改修なしで同一通信を再現できる利点

本来なら一部のパラメータだけ変えて試すには、フロントのコードを書き換えて再読み込みする必要があります。Copy as cURLならコピーしたコマンドを編集して再送するだけで済むため、バックエンドの挙動確認を画面操作から切り離せます。数分に一度しか飛ばないリクエストを何度も叩きたい、といった場面でも有効です。

手作業でcurlを書く場合との作業量・正確性の比較

手書きでは、認証ヘッダーやCookie、Content-Typeを1つずつ転記する必要があり、写し漏れが再現失敗の温床になります。Copy as cURLは送信時の全ヘッダーを機械的に書き出すため、写経ミスがなく、再現の精度が安定します。違いはヘッダー1〜2個ではなく、十数個のヘッダーを取りこぼさず再現できるかどうかに表れます。

cURL・PowerShell・fetch・HARの違いと用途別の使い分け基準

DevToolsのコピーメニューには複数の形式があり、貼り付け先の環境で選ぶのが原則です。形式ごとの役割を整理します。

Copy as cURL：ターミナルとAPIクライアント向けの汎用形式

Copy as cURLはシェルで実行できる汎用形式で、PostmanやInsomniaへのインポート、チームへの再現手順の共有、バグ報告への添付に向きます。ツールやOSをまたいで通用する移植性の高さが選ぶ理由です。

Copy as PowerShell：Windowsネイティブ環境向けの形式

Copy as PowerShellはInvoke-WebRequest系のコマンドを生成し、追加ツールを入れずにWindows標準のPowerShellで実行できます。後述するシングルクォートの問題を避けたいWindowsユーザーの第一候補です。

Copy as fetch：ブラウザコンソールで再実行できるJS形式

Copy as fetchはJavaScriptのfetch()呼び出しを生成します。ブラウザのコンソールに貼ればその場で再実行でき、フロントのコード中のAjax呼び出しの下書きとしても使えます。ブラウザ文脈で動くため、Cookieはcredentials設定経由で送られます。

Copy as fetch (Node.js)：Cookieを明示的に含むサーバー向け形式

Copy as fetch (Node.js)はサーバーサイドのNode.jsで動かす前提のfetch()を生成します。ブラウザのCookieストアが無い環境向けに、Cookieなどをヘッダーとしてコードへ明示的に書き出す点がブラウザ向けfetchとの差です。スクリプトに組み込んで定期実行したい場合に向きます。

Copy all as HAR（sanitized/with sensitive data）の選択基準

一括コピーにはCopy all as HARがあり、フィルタした全リクエストをHAR形式で書き出します。「sanitized」はCookie・Set-Cookie・Authorizationといった機密ヘッダーを除外するため、社外共有や添付に適します。自分の手元で完全な再現が要るときだけ「with sensitive data」を選ぶ、という基準が安全です。

用途・実行場所・機密情報で選ぶ形式の早見表

形式選びは「どこで実行するか」と「機密をどう扱うか」で決まります。代表的な使い分けを次の表に整理します。

迷ったら、自分の手元で動かすなら実行環境に合う形式、他者に渡すならsanitizedかマスキング後のcURL、と覚えておくと選択がぶれません。

Windows・macOS・Linuxで変わるcURL出力とシェル別の実行可否

同じCopy as cURLでも、貼り付けるシェルによって動く・動かないが分かれます。OSとシェルの相性を押さえます。

シングルクォート前提のPOSIXシェル向け出力の特徴

Copy as cURLが生成するコマンドは、URLやヘッダー値をシングルクォートで囲むPOSIXシェル（bash・zsh等）前提の書式です。macOSやLinuxのターミナルではこの書式がそのまま通り、改行を含む長いヘッダー列も問題なく解釈されます。

cmd.exeでシングルクォートが解釈されない問題と回避策

Windowsのcmd.exeはシングルクォートを文字列の区切りとして扱わないため、POSIX書式のcURLを貼り付けるとエラーや想定外の挙動になります。回避策は、ダブルクォートへ手で置換するか、後述のPowerShell形式やbash系シェルを使うことです。

WindowsでPowerShell形式かWSL・Git Bashを選ぶ判断基準

追加インストールを避けたいならCopy as PowerShell、curl本来のオプションをそのまま使いたいならWSLやGit Bashといったbash系シェルが向きます。curlコマンドの記述例を他環境と共有する予定があるなら、移植性の高いPOSIX書式をbash系で実行する方が後工程が楽になります。

macOS・Linuxでそのまま実行できる条件と注意点

macOS・Linuxでは標準のcurlが入っていれば貼り付けて即実行できます。注意点は、コピー時のCookieやトークンが既に失効していないか、社内ネットワーク向けのプロキシ設定が必要でないか、の2点です。プロキシ配下では-xや--noproxyの追加が要る場合があります。

行継続記号やエスケープがシェルで異なる点の確認

POSIXシェルでは行末のバックスラッシュで行を継続しますが、PowerShellではバッククォートが継続記号になるなど、シェルごとに記法が異なります。形式を取り違えると「途中で切れたコマンド」として失敗するため、貼り付け先のシェルに合った形式を選ぶことが確実です。

目的のリクエストを取りこぼさず取得するネットワークパネル操作手順

そもそも目的のリクエストが一覧に残っていなければコピーできません。確実に捕捉するための準備と手順を示します。

F12・右クリック検証・メニューからのDevTools起動方法

DevToolsはF12キー、ページ上の右クリック「検証」、またはメニューの「その他のツール」→「デベロッパーツール」から開けます。macOSではCommand+Option+Iでも起動できます。どの方法でも開く画面は同じです。

記録を始める前に開いておくNetworkタブの準備

取得したい通信が発生する「前」にNetworkタブを開いておくのが基本です。多くの通信はページ読み込み時に集中するため、先にタブを開いてから対象ページへ遷移・操作すると、リクエストが履歴に残ります。

Preserve logでページ遷移後もリクエストを残す設定

NetworkパネルのPreserve logを有効にしないと、ページ遷移やリダイレクトのたびに記録がクリアされます。ログイン後に飛ぶリクエストや、リダイレクトを挟むリクエストを追うときは、操作前にこのチェックを入れておくと取りこぼしを防げます。

Fetch・XHRフィルタで目的のAPI通信を素早く絞り込む方法

画像やCSSに紛れて目的のAPI通信が見つけにくいときは、フィルタのFetch/XHRを選ぶと非同期通信だけに絞り込めます。さらに検索欄にURLの一部やレスポンスに含まれる文字列を入れると、該当リクエストを1件まで特定しやすくなります。

取得したリクエストが正しいか応答内容で確認する手順

コピー前に、対象リクエストのResponseタブやPreviewタブで応答内容を確認し、目的のデータが返っているかを照合します。狙いと違うリクエストをコピーすると、以降の再現作業がすべて無駄になるため、応答の中身で当たりを付けてからコピーするのが堅実です。

Cookie・認証トークンを含むコマンドを安全に共有する実務ルール

Copy as cURLの利便性の裏返しが、機密情報の取り扱いです。漏洩を防ぐ運用を具体的に決めておきます。

コピーしたコマンドに残る認証トークン・APIキーの危険性

生成されたコマンドには、ログインセッションのCookie、Authorization: Bearerのトークン、APIキーがそのまま含まれます。これを無防備に共有すると、受け取った相手が本人になりすましてAPIを叩ける状態になります。コマンドは「認証情報そのもの」だと捉えて扱う必要があります。

バグ報告やチャットに貼る前のマスキングの具体例

共有時は、トークンやCookieの値を<TOKEN>や<COOKIE>といったプレースホルダへ置換し、個人情報を含むボディも伏せます。再現に不要なヘッダーは削り、URLのクエリに含まれるセッション識別子も確認します。値を残したまま貼るのではなく、置き換えてから貼るのを既定の手順にします。

HAR（sanitized）で機密ヘッダーを除外する使い方

複数リクエストをまとめて渡すなら、Copy all as HAR (sanitized)を使うと、Cookie・Set-Cookie・Authorizationが自動で除外されます。手作業のマスキング漏れを避けられるため、社外やサポート窓口へHARを送る際の既定の選択肢になります。

公開リポジトリ・社外への貼り付けを避ける運用ルール

GitHubのIssueやPull Request、外部の質問サイトに生のコマンドを貼るのは避けます。トークンやAPIキーをコードと一緒に管理する考え方は、GitHubのAPIトークンの発行と権限管理の考え方が参考になります。公開範囲を一段見誤るだけで漏洩につながる前提で運用します。

トークンの失効・ローテーションを前提にした取り扱い

万一コマンドが外部に出た場合に備え、トークンは失効・再発行できる設計にしておきます。共有後は速やかにローテーションする、有効期限の短いトークンを使う、といった運用で、漏洩時の被害範囲を時間で区切れます。

コピーしたcURLが再現に失敗する典型原因と切り分けの進め方

「コピーしたのに同じ応答が返らない」は頻出のつまずきです。原因を上から順に切り分けます。

期限切れトークン・セッションによる401・403の見分け方

実行して401や403が返る場合、まず認証情報の期限切れを疑います。コピー時点では有効でも、数分後には失効するトークンは珍しくありません。ログインし直して新しいリクエストを取り直すと再現する場合は、これが原因です。

CSRFトークンやワンタイム値で再現できないケース

POSTで419や検証エラーが返るときは、ボディやヘッダーにCSRFトークン・ワンタイム値が含まれている可能性があります。これらは一度きり有効なため、過去のリクエストをそのまま再送しても弾かれます。直前に発行された値を取り直して差し替える必要があります。

multipart/form-dataが–data-binaryに変換される際の崩れ

ファイルアップロードなどのmultipart/form-data通信は、Copy as cURLが境界文字列ごと--data-binaryへ書き出すため、そのままでは再現が崩れやすい部分です。curl公式も、この変換が苦手だと指摘しています。-Fでフィールドを組み直すか、ファイルを実体で指定し直すと安定します。

文字化け・エンコードずれが起きたときの確認点

日本語を含むボディやクエリで文字化けが起きるときは、Content-Typeの文字コード指定とシェルのエンコードを確認します。コピー元と実行環境でエンコードが食い違うと、サーバー側で別の値として解釈されます。UTF-8で揃っているかを最初に点検します。

curlのエラーコードから原因を絞り込む手順

通信自体が確立しない場合は、HTTPステータスではなくcurl自体の終了コードを手掛かりにします。SSL証明書・名前解決・タイムアウトなど、終了コードごとに原因が分類されます。一方、サーバーからエラー応答が返る場合は、返ってきたHTTPステータスコードの意味から切り分けると速く、各コードの意味と確認方法はHTTPステータスコードの一覧と確認方法が参考になります。ステータスとexit codeのどちらの問題かを先に分けるのが要点です。

Postman取り込み・バグ報告・スクレイピングでの実務的な活用シーン

Copy as cURLは単発の確認だけでなく、開発フローの各所で効きます。代表的な活用シーンを挙げます。

PostmanやInsomniaにcURLを取り込んでテストする流れ

PostmanやInsomniaはcURLコマンドのインポートに対応しており、貼り付けるだけでメソッド・ヘッダー・ボディが展開されます。ブラウザで成立した通信をAPIクライアントへ持ち込めば、パラメータを変えながら反復テストする土台がすぐ整います。

バグ報告に再現可能なリクエストを添えるメリット

「自分の環境だけで起きる不具合」は、ヘッダーやCookieの組み合わせが原因のことがあります。マスキングしたcURLを報告に添えると、受け手が同じ条件を再現でき、原因の特定が早まります。文章だけの報告より、再現性のある一次情報を渡せる点が利点です。

既存のAjaxをFetch APIへ置き換える下書きとしての活用

Copy as fetchで得たコードは、既存のXHRベースの呼び出しをfetch()へ置き換える際のたたき台になります。実際に飛んでいるヘッダー構成を出発点にできるため、ゼロから書くより漏れが少なく、移行の初稿を素早く作れます。

Webスクレイピングで実通信を再現する際の使いどころ

ログインや動的トークンを要するページのスクレイピングでは、ブラウザの実通信をcURLで写し取ると、必要なヘッダー構成を把握しやすくなります。ただし対象サイトの利用規約やrobots、認証情報の扱いを順守する前提での利用に限られます。

APIクライアント連携時に押さえる対象APIの仕様確認

取り込んだリクエストを起点にテストを広げるなら、対象APIの仕様も併せて確認しておくと手戻りが減ります。仕様の記述方式を整理したOpenAPIとSwaggerの違いを押さえておくと、エンドポイントやパラメータの全体像を踏まえた検証ができます。

Copy as cURLに関するよくある質問

Copy as cURLを使い始めるときに迷いやすい点を、用途別の判断とトラブル対処の観点でまとめます。

Copy as cURLとCopy as fetchはどちらを使うべきですか？

ターミナルで再実行したい、PostmanやInsomniaへ取り込みたい、他者へ移植性の高い形で共有したいならCopy as cURLです。ブラウザのコンソールやNode.jsスクリプトでJavaScriptとして動かしたい場合はCopy as fetch系を選びます。実行場所がシェルかJS文脈か、で決めるのが簡単です。

WindowsでコピーしたcURLが動かないのはなぜですか？

Copy as cURLの出力はシングルクォート前提のPOSIXシェル書式で、Windowsのcmd.exeはシングルクォートを区切りとして扱わないためです。Copy as PowerShellを選ぶか、WSLやGit Bashなどbash系シェルで実行すると解決します。

コピーしたcURLをそのまま社外に共有しても安全ですか？

安全ではありません。コマンドにはCookieや認証トークン、APIキーがそのまま含まれます。共有前に該当値をプレースホルダへ置換するか、複数件なら機密を除外するHAR (sanitized)を使い、共有後はトークンのローテーションを検討してください。

ページ遷移するとリクエストが消えるのを防ぐには？

NetworkパネルのPreserve logを有効にします。これを入れておくと、ページ遷移やリダイレクトをまたいでも記録が保持されます。ログイン直後やリダイレクトを挟む通信を追うときは、操作前に設定しておくのが確実です。

コピーしたcURLを実行しても元の応答が再現できないのはなぜですか？

多くは認証情報の期限切れか、CSRFトークン・ワンタイム値が一度きり有効なことが原因です。次にmultipartの--data-binary変換による崩れ、エンコードずれを疑います。通信自体が確立しない場合はcurlの終了コードから原因を分類して切り分けます。

関連記事

• JavaScriptでAPIを扱う基礎：Copy as fetchで得たコードを実装に落とし込む際の前提知識として役立ちます。
• FastAPIとSwaggerでのAPI動作確認：取り込んだリクエストをサーバー側の仕様と突き合わせて検証する場面を補完します。