【実務・中級編】Insomniaで「Request Chaining」を使って複雑なワークフローを自動テストするテクニック – データベース・API管理活用バイブル

【Insomnia極意】Request Chainingで複雑なAPIワークフローを完全自動化する技術

こんにちは。テックリードの私だ。

日々のAPI開発や結合テストで、こんな泥臭い作業に時間を溶かしていないだろうか？

1. 認証エンドポイント（`/auth/login`）を叩いてアクセストークンを目視でコピーする。
2. 次のAPIリクエストの `Authorization` ヘッダーにペーストする。
3. リソースを作成したら生成された `id` を控え、次の詳細取得APIのパスパラメータに手動で埋め込む。

「面倒くさい」「ミスる」「APIの仕様変更のたびにやり直し」──エンジニアの貴重な脳のメモリをこんな単純作業に割くのは今すぐやめよう。

Postmanの影に隠れがちだが、Insomniaの本気は「Request Chaining（リクエストチェイン）」と環境変数・Nunjucksテンプレートエンジンの組み合わせにある。この領域を極めれば、複雑なOAuth2フロー、マスター・ディテール関係のデータ登録、E2EのAPIシナリオテストまで、すべてが「Send」ボタン一撃で完結する。

今回は、現場の生産性を爆発的に引き上げるInsomniaの実践的なアーキテクチャとワークフロー自動化の極意を伝授しよう。

—

1. Request Chainingの核心：Nunjucksタグを使いこなせ

Insomniaの裏側では、環境変数やリクエスト間のデータ受け渡しにテンプレートエンジンである Nunjucks が稼働している。UIのポチポチ操作だけではなく、この仕組みの本質を理解することが自動化の第一歩だ。

Request Chainingの基本概念は極めてシンプルである。

「あるリクエストのレスポンス（JSON等）を、別のリクエストのパラメータやヘッダーに動的にバインドする」

これを実現するのが、Insomniaの入力欄で使える `Ctrl + Space`（またはプロンプト）で呼び出せる 「Tag（タグ）」 の機能だ。

実例：ログインAPIからトークンを自動抽出する設定

最も典型的かつ頻出する「認証トークンの自動引き継ぎ」を例に取ろう。

1. ログインリクエストの準備

名前の例: `POST /api/v1/auth/login`
レスポンスが以下のように返るとする：

{
“status”: “success”,
“data”: {
“token”: “eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…”
}
}

2. 保護されたリクエスト（例: `GET /api/v1/users/me`）の設定

`Authorization` ヘッダー、あるいはBearer Token設定を開く。
値を入力するフィールドで `Ctrl + Space` を押し、「Response > Response Body」 タグを選択する。
設定モーダルで以下を指定する：
Request: 先ほどのログインリクエスト（`POST /api/v1/auth/login`）を指定。
Filter (JSONPath / XPath): レスポンスからトークンを抜き出すパスを指定。JSONPathなら `$.data.token` と記述。
これにより、内部的に以下のようなNunjucksタグが生成される。

{% response ‘body’, ‘req_123456789’, ‘$.data.token’, ‘never’, 60 %}

これで準備完了だ。あなたが最初に `POST /api/v1/auth/login` を一度でも実行していれば、`GET /api/v1/users/me` を叩いた瞬間、Insomniaが自動裏でログインリクエストの最新レスポンスからトークンを抽出し、ヘッダーに挿入してサーバーに飛んでいく。

—

2. 開発スピードを劇的に高める「隠れたキーボードショートカット」

マウス操作でUIをガチャガチャしているうちはプロとは言えない。Insomniaの真のパフォーマンスを引き出すためのキーコンフィグを体に叩き込め。

—

3. 絶対に入れるべき「神プラグイン」

デフォルトのInsomniaも優秀だが、エコシステムを活用することで真の「API管理プラットフォーム」へと進化する。Insomniaの設定画面（Preferences > Plugins）から以下のプラグインを即座に導入せよ。

1. `insomnia-plugin-documenter`

概要: ワンクリックで美しく読みやすいAPIドキュメントを生成・エクスポートする。
現場のメリット: フロントエンドチームやQAチームへの仕様共有コストが劇的に下がる。

2. `insomnia-plugin-env-drop-down`

概要: ヘッダーやフッター部分に現在の環境（Staging, Production等）を視覚的かつ安全に切り替えるドロップダウンを追加。
現場のメリット: 「本番環境に対して誤って破壊的リクエストを投げる」という人災を物理的に防ぐ。

—

4. チーム開発で役立つ設定の共有化ルール（GitOps運用の極意）

Insomniaの資産を個人のローカルPCだけに閉じ込めてはならない。チーム全員で同一のワークフローを共有し、API仕様の変更に追従させるためのベストプラクティスを解説する。

1. Git Sync機能の活用、または手動エクスポートの標準化

Insomniaは公式でGit同期（GitHub, GitLab等との連携）をサポートしている。これを利用して、ワークスペースの設定自体をリポジトリとして管理するのが最もスマートだ。
もしGit Syncを使わない方針のチームであれば、Insomnia Export (v4フォーマット / JSON) をリポジトリの `api/` ディレクトリ等で管理し、API仕様が変わるたびにPull Request経由でレビューするフローを徹底する。

2. 環境変数の「二層分離」ルール

シークレット（本番用APIキーやパスワード）と、非機密情報（ベースURLやテスト用ユーザーID）を明確に分離すること。

Base Environment (共有可能): ローカルやステージングのベースURLなどを定義。
Sub Environment / Private Environment (Git除外推奨): 認証情報のプレースホルダーを定義。

—

5. 実用的な設定ファイル（Insomnia Export JSON）のベストプラクティス構成例

チームメンバーに配布、あるいはGit管理するためのInsomniaエクスポートファイル（JSON）の構造的なベストプラクティスを示す。整理されたフォルダ構造と、Request Chainingを見越した命名規則が鍵となる。

{
“_type”: “export”,
“__export_format”: 4,
“__export_date”: “2026-03-30T00:00:00.000Z”,
“__export_source”: “insomnia.desktop.app:v2026.1.0”,
“resources”: [
{
“_id”: “wrk_workspace_main”,
“_type”: “workspace”,
“name”: “E2E Test Workflow – 決済システム”,
“description”: “注文から決済完了までのシナリオテスト自動化スイート”
},
{
“_id”: “env_base_staging”,
“_type”: “environment”,
“parentId”: “wrk_workspace_main”,
“name”: “Staging Environment”,
“data”: {
“base_url”: “https://staging-api.example.com”,
“test_email”: “qa-automation@example.com”,
“test_password”: “SecurePassword123!”
},
“color”: “#7053c1”
},
{
“_id”: “fld_auth”,
“_type”: “request_group”,
“parentId”: “wrk_workspace_main”,
“name”: “1. 認証フェーズ”,
“environment”: {}
},
{
“_id”: “req_login”,
“_type”: “request”,
“parentId”: “fld_auth”,
“name”: “POST ログインしてトークン取得”,
“method”: “POST”,
“url”: “{{ _.base_url }}/api/v1/auth/login”,
“body”: {
“mimeType”: “application/json”,
“text”: “{\n \”email\”: \”{{ _.test_email }}\”,\n \”password\”: \”{{ _.test_password }}\”\n}”
},
“headers”: [
{ “name”: “Content-Type”, “value”: “application/json” }
]
},
{
“_id”: “fld_orders”,
“_type”: “request_group”,
“parentId”: “wrk_workspace_main”,
“name”: “2. 注文・決済フェーズ (Chaining対象)”,
“environment”: {}
},
{
“_id”: “req_create_order”,
“_type”: “request”,
“parentId”: “fld_orders”,
“name”: “POST 注文作成 (要認証)”,
“method”: “POST”,
“url”: “{{ _.base_url }}/api/v1/orders”,
“body”: {
“mimeType”: “application/json”,
“text”: “{\n \”product_id\”: \”prod_999\”,\n \”quantity\”: 2\n}”
},
“headers”: [
{ “name”: “Content-Type”, “value”: “application/json” },
{
“name”: “Authorization”,
“value”: “Bearer {% response ‘body’, ‘req_login’, ‘$.data.token’, ‘never’, 60 %}”
}
]
},
{
“_id”: “req_get_order”,
“_type”: “request”,
“parentId”: “fld_orders”,
“name”: “GET 注文詳細確認 (Chaining: 注文ID)”,
“method”: “GET”,
“url”: “{{ _.base_url }}/api/v1/orders/{% response ‘body’, ‘req_create_order’, ‘$.data.order_id’, ‘never’, 60 %}”,
“headers”: [
{
“name”: “Authorization”,
“value”: “Bearer {% response ‘body’, ‘req_login’, ‘$.data.token’, ‘never’, 60 %}”
}
]
}
]
}

この構成の美しさとポイント

1. フェーズごとのフォルダ分割 (`request_group`):
APIを叩く順序（1. 認証 -> 2. 注文・決済）を視覚的に表現することで、テストシナリオのメンタルモデルがチーム全体で一致する。
2. 多段Chainingの実現:

`req_login` で取得したトークンを `req_create_order` のヘッダーに引き継ぐ。
さらに、`req_create_order` が返した `order_id` を、次の `req_get_order` のURLパスパラメータに動的に埋め込んでいる（`{% response ‘body’, ‘req_create_order’, ‘$.data.order_id’, … %}`）。

3. ハードコードの完全排除:
環境変数（`{{ _.base_url }}` 等）とレスポンス連携を組み合わせることで、環境移行やデータ構造の変更に対する耐性が圧倒的に高まる。

—

終わりに：ツールを使い倒すエンジニアであれ

APIクライアントは、単なる「CURLのグラフィカルなラッパー」ではない。正しく設計されたワークフローとRequest Chainingを駆使すれば、軽量なE2Eテストハーネスとして機能し、開発・検証のフィードバックループを極限まで加速させる強力な武器となる。

「APIを叩くのに手動で値をコピペする」という無駄な儀式は今日で終わりにしよう。あなたのチームのインフラとワークフローを、プロのアーキテクチャへとアップデートせよ。