LabHub

ブログ

API 設計 & テストツール 2026 — Bruno / Insomnia / Postman / Hoppscotch / Scalar / Mintlify / Buf 徹底比較

2026-05-16 · 30 分で読めます · #api-design#api-testing#bruno#insomnia#postman#hoppscotch#stoplight#scalar#redoc#swagger-ui#mintlify#buf#grpc#protobuf#openapi#deep-dive#japanese

한국어English日本語

プロローグ — 「もう Postman は使えない」が増えた

2025 年のある会社の Slack で見たメッセージ。「Postman の新バージョンでログインが強制されて、コレクションがクラウドに自動同期されたから、セキュリティチームに止められた。何かおすすめは?」

返信が 50 件以上ついた。Bruno、Hoppscotch、Insomnia(旧版)、Yaak、Apidog。代替は山ほどあった。5 年前なら「Postman 以外に何がある?」という問い自体が違和感だったが、2026 年は逆だ。Postman を使わないのがデフォルトになったチームが増えた。

これは単に一社のポリシー変更によるものではない。API ツール市場そのものが再編された。Postman → Insomnia → Bruno と続く「脱クラウド・脱アカウント・脱ロックイン」の流れ。OpenAPI ビューアが Swagger UI から Redoc、Scalar へ世代交代した流れ。ドキュメントは ReadMe・Mintlify が OpenAPI スペック一本で SaaS サイトを生成する流れ。gRPC は Buf が事実上の標準ツールチェーンになった流れ。そしてすべてに AI が入る — Postbot・Insomnia AI は自然言語からリクエストを生成し、レスポンスを説明する。

本稿は 2026 年 5 月時点の API 設計・テストツール地図を描く。クライアント、ドキュメント、デザイン、モック、gRPC の 4 分類に分けて整理し、最後に「あなたのチームには何が合うか」を答える。

1 章 · 2026 年 API ツール地図 — 4 分類で見る風景

まず全体像。API ツールは大抵 1 つのカテゴリに綺麗には収まらないが、コアの価値提案で分けると 4 つの塊になる。

分類ツール用途
クライアント(リクエスト送信)Postman, Insomnia, Bruno, Hoppscotch, Yaak, Apidogcurl の代替、コレクション管理、自動化
ドキュメント / ビューアSwagger UI, Redoc, Scalar, RapiDocOpenAPI を人が読むサイトに
デザイン / 仕様Stoplight Studio, Bruno(デザインモード), Apidogコードより前に API を設計、mock 生成
ドキュメント SaaSReadMe, Mintlify, Bump.sh, Redoclyホスト型開発者ポータル、changelog、検索
gRPC / ProtobufBuf, gRPCurl, Kreya, BloomRPC(deprecated), Postman gRPCProtobuf 設計、gRPC 呼び出し
マーケットプレイスRapidAPI, Postman Public API Network外部 API 発見、ゲートウェイ
AI アシストPostbot, Insomnia AI, Apidog AI自然言語でリクエスト生成、レスポンス説明

分類が綺麗でない理由は、ツール同士が重なるから。Postman はクライアント + モック + ドキュメント + gRPC + AI 全部やる。Bruno はクライアント + 簡易デザイン + コレクション同期(git)に絞る。Apidog はデザイン + クライアント + ドキュメント + モックを一箇所で。

ツールを選ぶときは 2 つを見る。

  1. コア価値はどこか(リクエスト送信? 仕様デザイン? ドキュメント?)
  2. データ所有権はどこか(ローカルファイル? クラウド? git?)

2 が 2026 年の分かれ目だ。Postman 事件が呼んだ「私のデータは私のファイルシステムに」運動が、Bruno、Yaak、file-based Insomnia オプションを生んだ。クラウド依存を減らすのが市場の明確な方向。

2 章 · Bruno — file-based の勝者

最も急成長したツール。2021 年に始まり、2024 年に Series A を獲得。一行要約: すべてのコレクションがただのファイルで、git にそのまま入る。

なぜ急速に定着したか

核心の差別化は 1 つ: コレクション = ファイルツリー。Postman はコレクションを JSON 1 個にまとめて、その JSON がクラウドに同期される。Bruno はコレクションをディレクトリ、各リクエストを .bru ファイルとして保存する。

my-api/
  bruno.json
  environments/
    dev.bru
    prod.bru
  users/
    list-users.bru
    create-user.bru
  orders/
    get-order.bru

各 .bru ファイルは人が読めるテキスト。

meta {
  name: List Users
  type: http
  seq: 1
}

get {
  url: {{baseUrl}}/users
  body: none
  auth: bearer
}

auth:bearer {
  token: {{authToken}}
}

なぜこれが重要か。git diff が意味を持つ。PR レビューで「このリクエストにヘッダーが 1 つ追加された」が一目で分かる。Postman の JSON で同じ変更を見るには、JSON 1 塊の diff を見るしかない。コード変更と同じように API コレクション変更もレビューになる。

副次効果: ブランチを切ってマージできる。PR でコレクション変更を受けられる。CI でコレクション一貫性を検査できる。これが file-based の本当の価値。

機能

弱点

誰に向くか

Bruno のメッセージ: 「コレクションはコードだ。git があるのになぜ別の SaaS が必要なのか」

3 章 · Insomnia(Kong)— 二度の信頼危機

Insomnia はかつて Postman 代替として愛された。軽く、綺麗で、ローカルでよく動いた。2019 年に Kong に買収され、その後の動きが分かれた。

2023 年の危機 — Insomnia 8 のログイン強制

2023 年 8 月の Insomnia 8 リリースが大きな論争を呼んだ。新版が事実上ログインを強制し、ローカルデータを新しいクラウド同期モデルに移行しようとした。一部ユーザーには同意なしにデータがクラウドにアップされたように見えた。

コミュニティは爆発した。GitHub Issue には数百のコメントがつき、多くのユーザーが Insomnia 7.x にダウングレードするか、Bruno へ移った。Kong は謝罪し、Scratch Pad モード(アカウントなしで使える)を追加し、データ移行方式を変えると発表した。

2024-2025 年の回復試み

Kong はその後:

依然として強いツールだ。特に Kong Konnect ゲートウェイとの統合は他のクライアントが追いつけない。だが一度失った信頼はゆっくりとしか戻らない。

2026 年現在の評価

誰に向くか

4 章 · Postman — 巨人の影と AI への賭け

Postman は依然として最大の会社だ。2,500 万人以上のユーザー、Series E 後の評価額 56 億ドル(2021 年時点)。だが市場の空気は明らかに変わった。

2023 年の信頼危機

2023 年 5 月、Postman v10 で Scratch Pad の今後の廃止計画が判明した — つまり、アカウントなしで使えるモードを段階的に縮小しようとした。加えて、コレクションが基本的に Postman クラウドに保存されることが再び問題になった。

エンタープライズのセキュリティチームは「顧客の API キーとペイロードが外部 SaaS に保存される」という理由で使用禁止を出し、多くのチームが代替を探した。結果:

Postman は結局 Scratch Pad を維持することにし、ローカルコレクションオプションを再強化した。だが「デフォルトはクラウド」という印象は残った。

Postbot — AI 機能への本気度

Postman が素早く賭けた領域が AI だ。Postbot:

GPT-5/Claude 4.x 時代に AI 機能は差別化より基本装備に近いが、Postman はコレクション・履歴・環境という巨大な context を持っているため、レスポンス品質は他ツールのスタンドアロン AI より一枚上手。

機能の幅は依然最強

弱点

誰に向くか

5 章 · Hoppscotch — 完全 OSS、セルフホストフレンドリー

Hoppscotch はインド発の OSS API クライアント。2019 年開始(当時の名前は Postwoman、商標問題で改名)。コア: 完全に OSS、ブラウザで即実行、セルフホスト可能。

差別化

  1. PWA / web 優先 — ブラウザで今すぐ使える(hoppscotch.io)。インストール不要。
  2. Apache 2.0 OSS — コアが本当に開かれており、セルフホスト可能
  3. Docker 一行でセルフホスト — エンタープライズが自社インフラに乗せる
  4. 速い — Vue ベース、軽い
  5. ローカル保存 — デフォルトはブラウザ IndexedDB

機能

弱点

誰に向くか

6 章 · Stoplight Studio(SmartBear)— デザイン優先陣営の停滞

Stoplight Studio はかつて API デザイン優先(コードより OpenAPI スペック先)の代表格だった。ビジュアルエディタで OpenAPI スペックを作り、mock サーバーを自動生成し、ドキュメントをホスト。2023 年 SmartBear に買収された。

買収後の停滞

SmartBear は Swagger UI(本家)、SoapUI、ReadyAPI など API ツールのポートフォリオを持つ会社。Stoplight 買収は自然だったが、買収後 Stoplight Studio の開発速度は明らかに落ちた。コミュニティは「Stoplight も結局 SmartBear のエンタープライズ販売ツールになるのか?」と懸念した。

2026 年現在の Stoplight Studio:

誰に向くか

7 章 · Scalar — モダン OpenAPI ビューアの新星

Scalar は 2023 年に登場し、OpenAPI ビューア市場を揺さぶった新進。2024 年にシード、2025 年により大きなラウンド。コア: Swagger UI は不細工すぎる、Redoc は静的すぎる。私たちが作り直す。

なぜ急速に定着したか

  1. デザイン品質 — 2026 年のデザイントレンドに合う清潔感
  2. ダークモード、キーボードショートカット、検索 — Postman 並みの UX
  3. Live リクエスト — ドキュメントから直接 API を呼べる
  4. Vue/React/Hono/Express 統合 — コードに 1 行追加で自動マウント
  5. OSS(MIT) — セルフホストフレンドリー

使用パターン

// Hono の例
import { apiReference } from '@scalar/hono-api-reference'

app.get(
  '/reference',
  apiReference({
    spec: { url: '/openapi.json' },
  })
)

これだけ。バックエンドに 1 行追加で /reference から Scalar UI で OpenAPI を見られる。

Scalar vs Redoc vs Swagger UI

項目Swagger UIRedocScalar
デザイン2014 年風清潔だが静的モダン
Live リクエストありなし(Redocly 有料機能)あり
ダークモード部分的ありあり
統合 1 行ありありあり
セルフホスト可可(CLI 別)可
検索弱い良い非常に良い
基本ライセンスApache 2.0MITMIT

誰に向くか

8 章 · Redoc / Redocly — OSS ビューア + 商用 CLI

Redoc は長らく最も清潔な OpenAPI ビューアとして評価されてきた。2024 年以降、Redocly(商用会社)は CLI・linter・ポータルなど有料ツールを強化。

2 つの枝

  1. Redoc(OSS、MIT) — 単一ページ OpenAPI ビューア
  2. Redocly CLI(商用) — multi-spec ポータル、linter、bundle、OAS-to-website

特徴

誰に向くか

9 章 · Swagger UI — クラシック、まだ生きている

本家。2011 年開始、SmartBear が買収し OpenAPI Initiative に寄贈。ほぼすべてのバックエンドフレームワークが 1 行で Swagger UI をマウントできる(FastAPI、Spring、NestJS、Express など)。

なぜまだ使われているか

弱点

誰に向くか

10 章 · Mintlify / ReadMe.com — ドキュメント SaaS の二強

このカテゴリは「OpenAPI スペック 1 本からフルスタック開発者ポータルを引き出す」という約束だ。

Mintlify

ReadMe.com

Mintlify vs ReadMe

項目MintlifyReadMe
デザインモダン/ミニマルより豊富、やや重い
MDX フレンドリー非常に良いOK
AI 検索強力強力
外部開発者 dashboard弱い強い
API metrics弱い強い
価格スタートアップ向きエンタープライズ向き

誰に向くか

11 章 · Buf — Protobuf/gRPC エコシステムの標準

REST 陣営が揺らぐ間に、gRPC/Protobuf 陣営には事実上の標準が定着した。Buf。

Buf が成し遂げたこと

Protobuf は強力だがツールが散らかっていた — protoc は難しく、依存関係管理がなく、linting がなかった。Buf は次を 1 箇所にまとめた。

CI で最も役立つもの

# .github/workflows/proto.yml
- run: buf lint
- run: buf breaking --against '.git#branch=main'

この 2 行で「スタイル違反」と「既存クライアントを壊す変更」を PR で自動ブロック。Protobuf を本番で使うすべてのチームが有効にすべきセーフティネット。

Buf Connect

Buf が作った RPC プロトコル。gRPC、gRPC-Web、Connect protocol を 1 コードベースでサポート。ブラウザから fetch で gRPC を呼べる。TypeScript/Go/Kotlin クライアントが綺麗。

誰に向くか

12 章 · gRPCurl / Kreya — gRPC クライアント

gRPC 呼び出し自体は別のツールが必要(HTTP の curl のように)。

gRPCurl — CLI

grpcurl -d '{"name": "world"}' localhost:50051 helloworld.Greeter/SayHello

curl の gRPC 版。サーバー reflection を有効にすればスキーマを自動取得。CI スクリプト、デバッグ、ad-hoc 呼び出しに使う。公式 grpc プロジェクトではなく fullstorydev がメンテ。

Kreya

GUI gRPC クライアント。単純な呼び出しだけでなく:

Postman/Insomnia も gRPC をサポートするが、gRPC 専用ツールの精度が必要なら Kreya のほうが一般的にスムーズ。

Postman / Insomnia / Bruno の gRPC サポート

誰に向くか

13 章 · Apidog / Yaak / Bambda — 新進 3 種

ここ 2 年で登場した新ツール。3 つとも「Postman の重さ vs Bruno の git-only」の隙間を狙う。

Apidog(中国発)

Yaak(Rust ベース)

Bambda

14 章 · AI 統合 — Postbot, Insomnia AI

2026 年にはほぼすべてのツールが AI 機能を載せる。本当の価値はどこにあるか。

よくできる領域

  1. リクエスト生成 — 「GitHub API から organization の repo 一覧を取得」 → リクエストが自動作成
  2. レスポンス説明 — レスポンス JSON を見て各フィールドが何を意味するか説明
  3. テスト自動作成 — レスポンスを見て assert 文を生成(status code、schema など)
  4. OpenAPI デザイン補助 — 自然言語の description から schema の素案
  5. エラーデバッグ — 401/403/500 を見て可能性のある原因を列挙

Postbot の強み

Postman は巨大なコレクション + 履歴 + 環境変数を context として持つ。AI が「あなたのコレクションの他のリクエストと同じスタイルで」新リクエストを作れる。他ツールのスタンドアロン AI はこの社内 context がないため一般的な応答になる。

Insomnia AI の強み

Kong Konnect と統合 — Kong が知っている API カタログとポリシーを AI が理解する。Konnect 利用組織では強力。

限界

15 章 · 韓国 / 日本 — Toss、メルカリ

Toss(韓国)

Toss は API デザインを非常に真剣に扱う会社として知られる。外部公開 API は docs.tosspayments.com で見られ、自社ドキュメントシステムは綺麗なデザインと一貫した語彙で有名。内部的には:

技術ブログ toss.tech に API デザイン関連の投稿がよく上がる。

メルカリ(日本)

メルカリは日本の大型マーケットプレイス。内部的に gRPC を広範に使い、Protobuf スキーマガバナンスシステムを自社構築した事例で有名。engineering.mercari.com ブログに Buf 導入、Connect protocol 採用などの記事がある。外部公開 API は小さめだが、内部マイクロサービス通信のためのツール採用が早い。

もう 1 つの日本の事例: LINE は自社の API ツールエコシステム(LY corp.)を持ち、SmartBear ReadyAPI を広範に使うエンタープライズも多い。

16 章 · 誰が何を選ぶべきか

最後にまとめ。

個人開発者 / 小さなサイドプロジェクト

小さなエンジニアリングチーム(5-20 人)

大組織 / エンタープライズ

API 優先企業(製品が API、Stripe・Twilio 級)

閉鎖型(すべての API が社内用)

OSS 絶対主義者

まとめ

5 年間の変化サマリー

アンチパターン 10 個

  1. 「大きなツールが安全」と Postman を無条件採用 — コンプライアンス摩擦を遅れて発見
  2. データ所有ポリシーなしに SaaS API クライアントを標準化 — セキュリティチームに止められる
  3. コレクションを git に上げない — PR レビューが不可能
  4. OpenAPI スペックなしでコードだけ — ドキュメントは常にコードからずれる
  5. Spectral / Buf breaking なしで運用 — 互換性破壊を人が発見
  6. Swagger UI そのまま外部公開 — デザインが会社の印象を削る
  7. AI レスポンスをそのまま信頼 — assert 文が誤って生成
  8. gRPC を Postman の中だけで — gRPC 専用ツールの精度が必要なときに追いつけない
  9. mock サーバーなしで frontend 開始 — backend 待ちで sprint 遅延
  10. ドキュメントを人が手書き — 1 週間後にコードからずれる

次回予告

次回候補: OpenAPI 3.1 深掘り — JSON Schema 統合と webhook、Connect protocol vs gRPC vs REST — 2026 年の選択、API モッキングツール比較 — Prism、MSW、WireMock。

「API ツールはコードのツールではなく、API を作る人々の間の合意のツールだ。合意が清潔ならツールも軽い。」

— API 設計 & テストツール 2026、終わり。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます