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

プロローグ — 「もう 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 はクライアント + モック + ドキュメント + 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 の本当の価値。

機能

• HTTP/REST クライアント(Postman/Insomnia と同等)
• gRPC クライアント(2024 年追加)
• GraphQL
• WebSocket / SSE
• スクリプト(pre-request・post-response、JavaScript)
• 環境変数(per-environment .bru ファイル)
• シークレット管理(.env.local、git ignore)
• CLI(bru run)— CI でコレクション実行
• OpenAPI import / export

弱点

• チーム共有機能が git に縛られる — git を使わないと魅力が半減
• gRPC はまだ Postman/Kreya に及ばない
• デザインモード(仕様優先設計)は弱い — Stoplight/Apidog の領域
• クラウド同期が必要なチームには別途有料オプションが必要

誰に向くか

• git ベースのワークフローが定着したエンジニアリングチーム
• API コレクションをコードのように PR でレビューしたいチーム
• データの外部クラウド露出がコンプライアンス問題になる会社
• 個人開発者が軽く使うにも十分

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 はその後:

• Local Vault モード — ローカルにすべてのデータを保存
• Open source ライセンス維持(Apache 2.0)
• gRPC、GraphQL、WebSocket の強化
• Insomnia AI — Postbot への対抗

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

2026 年現在の評価

• 単一ツールとしての完成度は依然高い
• Kong Gateway / Konnect を使うチームには自然な選択
• ただし file-based git ワークフローは Bruno に劣る
• 「また強制的にクラウドへ?」という懸念が完全には消えていない

誰に向くか

• Kong Konnect / Kong Gateway 利用チーム
• Postman は重いが Bruno の git-only モデルは負担に感じる個人開発者
• 複数プロトコル(REST + gRPC + GraphQL + WebSocket)を 1 ツールで扱いたいチーム

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

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

2023 年の信頼危機

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

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

• Bruno ユーザーが爆増
• Insomnia の回帰
• Hoppscotch のセルフホスト
• Yaak・Apidog の新規参入

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

Postbot — AI 機能への本気度

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

• 自然言語からリクエスト生成(「GitHub API から自分の repo 一覧を取得して」)
• テスト自動生成(レスポンスを見て assert 文を作成)
• レスポンス説明(「この JSON は何を意味する?」)
• デバッグ補助(なぜ 401 になったか)

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

機能の幅は依然最強

• REST・GraphQL・gRPC・WebSocket・SOAP
• Mock サーバー
• Public API Network(マーケットプレイス)
• Monitor(スケジュールされたコレクション実行)
• Newman CLI(CI でコレクション実行)
• Postman Flows(visual ワークフロー)
• Postman Live Collaboration(リアルタイム協業)
• Postman Insights(organization-wide API 分析)

弱点

• デスクトップアプリが重い(Electron、時に GB 単位の RAM)
• クラウドデフォルトとコレクション同期がコンプライアンス摩擦
• 価格 — チーム料金が他ツールに比べ高い
• git diff フレンドリーさが弱い

誰に向くか

• 最も幅広い機能が必要な大規模チーム(REST + gRPC + Mock + Monitor を 1 箇所に)
• Public API Network に自社 API を公開したい会社
• すでに Postman を標準として使っており移行コストが大きい組織

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

機能

• REST、GraphQL、WebSocket、SSE、MQTT、gRPC
• 環境変数、コレクション
• pre-request / test スクリプト
• チーム同期(Hoppscotch Cloud またはセルフホスト)
• Hoppscotch Agent(CORS 回避用デスクトップエージェント)

弱点

• 機能の幅は Postman/Insomnia より狭い
• デスクトップアプリはあるが web 優先設計なのでときに違和感
• チーム協業はクラウド/セルフホストインフラが必要
• gRPC は比較的最近追加、安定性に差

誰に向くか

• OSS 絶対主義者、セルフホストがポリシーの組織
• 軽いクライアントを 1 つ素早く使いたい個人開発者
• ブラウザで同僚にリンクで即共有したいとき
• インド/東南アジアの会社(コミュニティが厚い)

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:

• 依然として OpenAPI デザインのための最も完成度の高いビジュアルエディタの 1 つ
• Spectral(OpenAPI linter)は依然事実上の標準 — Redocly、Bruno、GitHub Action などどこでも使われる
• Prism(mock サーバー)も依然標準
• だが新機能ペースは Scalar/Apidog のような新進勢力に後れを取る

誰に向くか

• 非開発者の PM/デザイナーが OpenAPI スペックを一緒に編集するチーム
• エンタープライズの SmartBear ライセンスが既にある組織
• Spectral / Prism はツールに関わらずほぼすべてのチームに推奨

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

誰に向くか

• 新 API の公開ドキュメントを綺麗に作りたいチーム
• Swagger UI のデザインが息苦しいチーム
• ドキュメントから直接 API を呼んでもらいたいチーム

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

特徴

• 3 ペインレイアウトが OpenAPI ドキュメントの事実上の標準に
• 大きなスペック(100+ endpoint)もよく耐える
• Stripe、Docker、Twilio など大型 API ドキュメントが Redoc または Redoc 派生を使う
• 無料 Redoc は Live リクエスト未対応(Redocly 有料のみ)

誰に向くか

• 大きな OpenAPI スペック(数百 endpoint)の静的ドキュメントが必要なチーム
• Stripe スタイルのクラシックな 3 ペインレイアウトを望むチーム
• 商用 Redocly CLI で multi-spec dev portal を作りたい会社

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

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

なぜまだ使われているか

• 開発環境のデフォルト — FastAPI の /docs、NestJS の @nestjs/swagger など
• try-it-out ボタンが最も馴染みのあるパターン
• すべてのバックエンドフレームワークが自動マウント
• Apache 2.0

弱点

• 2014 年のデザインのまま
• 大きなスペックで遅くなる
• 検索が弱い
• モバイル/タブレットフレンドリーさが低い

誰に向くか

• 内部開発/デバッグ用ドキュメント(Scalar に乗り換えるほどのメリットがないとき)
• フレームワークがデフォルトで敷いたものをそのまま使うチーム

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

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

Mintlify

• 2022 年開始、2024 年に急成長
• MDX ベースのドキュメント
• OpenAPI 自動 import、自動 API ページ生成
• フルテキスト検索(AI チャット UI 込み)
• GitHub 連携 — repo の markdown/MDX 変更が自動反映
• 有料(スタートアップ/エンタープライズプラン)
• Stripe、OpenAI、Anthropic などが使用

ReadMe.com

• より古い強者(2014 年開始)
• API reference、guides、changelog、検索を 1 箇所に
• Try-it コンソールが強力
• Metrics — どの endpoint がよく呼ばれているか追跡
• Developer Dashboard — 外部開発者ごとの key 管理
• API 使用分析 — ダッシュボードで呼び出し量推移

Mintlify vs ReadMe

誰に向くか

• 外部開発者が使う公開 API を持つ会社
• ドキュメントを GitHub PR で管理したいチーム(Mintlify)
• 外部開発者ごとの API キー/使用量を dashboard で管理したいチーム(ReadMe)

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

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

Buf が成し遂げたこと

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

• buf build — .proto を素早くコンパイル
• buf lint — Protobuf スタイル/Best practice 検査
• buf breaking — スキーマ互換性破壊の自動検出(CI 必須)
• buf format — .proto フォーマッタ
• buf generate — protoc-gen-* プラグインを yaml 設定で実行
• Buf Schema Registry(BSR) — Protobuf の npm/pypi 相当

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 クライアントが綺麗。

誰に向くか

• Protobuf/gRPC を本番で使うすべてのチーム — 事実上必須
• スキーマを複数チームで共有する会社(BSR で依存関係管理)

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 クライアント。単純な呼び出しだけでなく:

• ストリーミング(server-side、client-side、bidirectional)
• Protobuf import(BSR/local)
• 環境変数、コレクション、スクリプト
• REST/GraphQL もサポート(すべてのプロトコルを 1 箇所に)

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

Postman / Insomnia / Bruno の gRPC サポート

• Postman gRPC — reflection、.proto import、streaming すべて可、最も幅広い
• Insomnia gRPC — Kong が強化した領域、よく動く
• Bruno gRPC — 2024 年追加、基本は動くが streaming UX はまだ粗い

誰に向くか

• gRPCurl — デバッグ・CI スクリプト・ad-hoc 呼び出し
• Kreya — gRPC を毎日触るバックエンド開発者
• Postman/Insomnia — gRPC と REST を 1 ツールでまとめたいチーム

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

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

Apidog(中国発)

• 1 ツールでデザイン + クライアント + Mock + ドキュメント + 自動化
• Stoplight + Postman + Mintlify を合わせた野心
• 無料ティアが寛容
• AI 機能(自然言語で endpoint デザイン)
• 弱点: UI がやや雑然、一部の翻訳が滑らかでない
• 誰に: 1 ツールで完結させたく、Postman 価格が負担なチーム

Yaak(Rust ベース)

• Bruno に似た file-based 思想
• Rust + Tauri で作られており Electron より軽い
• 1 人がフルタイムで作っているインディーツール
• 清潔な UI、速い起動
• 弱点: 機能の幅はまだ狭い
• 誰に: Bruno でも重いと感じる個人開発者、Rust エコシステムのファン

Bambda

• JavaScript ベース API クライアント
• WebSocket・SSE・gRPC すべて可
• AI 機能を強調
• まだユーザーベースは小さい
• 誰に: 新規に始める小チームが実験的に試す価値あり

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 利用組織では強力。

限界

• 自然言語が曖昧だと AI が誤推測 — 結局人が修正
• レスポンス説明は助かるが、セキュリティ情報を外部モデルへ送るリスク(エンタープライズは self-hosted オプションが必要)
• テスト生成は出発点としては良いがドメインロジックは人が補強

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

Toss(韓国)

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

• API デザイン review 文化(PR で OpenAPI 変更を受ける)
• 韓国語/英語の二重ドキュメント
• changelog と deprecation ポリシーが明示的
• SDK が複数言語で自動生成(OpenAPI generator の変形)

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

メルカリ(日本)

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

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

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

最後にまとめ。

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

• クライアント: Bruno(git フレンドリー)または Hoppscotch(ブラウザで即)
• ドキュメント: Scalar(綺麗)またはフレームワーク default の Swagger UI
• gRPC: gRPCurl
• AI: なくてもいい(または ChatGPT/Claude desktop)

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

• クライアント: Bruno + git(PR レビュー)、補助に Hoppscotch
• デザイン: OpenAPI を直接書く + Spectral lint(Bruno と一緒にコミット)
• ドキュメント: Scalar セルフホスト、外部公開時は Mintlify
• gRPC: Buf + Kreya、または Postman gRPC
• AI: ChatGPT/Claude で補助(ツール内蔵は任意)

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

• クライアント: Postman(最も完成度高い)または Insomnia(Kong 利用時)
• デザイン: Stoplight Studio(PM/デザイナー協業)または Apidog
• ドキュメント: ReadMe(外部開発者 dashboard 必要時)または Mintlify(モダン UX)
• gRPC: Buf BSR + Postman gRPC
• AI: Postbot または Insomnia AI(組織 context を活用)
• コンプライアンス: セルフホストオプション(Hoppscotch、Insomnia Local Vault、Bruno)を検討

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

• デザイン: OpenAPI/Protobuf を git で source of truth に
• クライアント: 内部的に Bruno + 外部公開の try-it は Scalar/Redoc
• ドキュメント: 自社ドメインにホスト(Redocly enterprise、Mintlify enterprise、または自社構築)
• gRPC: Buf + Connect(ブラウザ互換)
• マーケットプレイス: 自社 dev portal + 拡張時に RapidAPI

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

• クライアント: Bruno + git(最も自然)
• デザイン: OpenAPI をコードのそばに(openapi.yaml のようなファイル)
• ドキュメント: Scalar セルフホストまたはフレームワーク default
• gRPC: Buf + Kreya/gRPCurl
• AI: 社内 LLM ポリシーに従う

OSS 絶対主義者

• クライアント: Hoppscotch(セルフホスト)または Bruno
• ドキュメント: Redoc + Spectral + Prism
• gRPC: Buf(Apache 2.0)+ gRPCurl
• マーケットプレイス: 別途 dev portal を自前運営

まとめ

5 年間の変化サマリー

• クライアント: Postman 独占 → Bruno/Insomnia/Hoppscotch の多極化
• データ所有: クラウドデフォルト → ローカル/git オプションが再び重要
• ドキュメント: Swagger UI 独占 → Scalar/Redoc/Mintlify が世代交代
• gRPC: ツール混乱 → Buf が事実上の標準
• AI: 付加機能 → ほぼすべてのツールのデフォルト
• コンプライアンス: 無頓着 → セルフホスト/ローカルモードが selection criteria

アンチパターン 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

• Bruno — Opensource API client
• Bruno GitHub — usebruno/bruno
• Bruno Series A announcement (2024)
• Insomnia — Kong
• Insomnia 8 controversy — GitHub issues
• Postman
• Postman Scratch Pad announcement
• Postbot — AI in Postman
• Hoppscotch
• Hoppscotch GitHub — hoppscotch/hoppscotch
• Stoplight
• SmartBear acquires Stoplight
• Spectral — OpenAPI linter
• Prism — mock server
• Scalar
• Scalar GitHub — scalar/scalar
• Redoc GitHub — Redocly/redoc
• Redocly
• Swagger UI
• Mintlify
• ReadMe.com
• Buf
• Buf Schema Registry
• Buf Connect
• gRPCurl — fullstorydev/grpcurl
• Kreya
• Apidog
• Yaak
• RapidAPI Hub
• Kong Konnect
• TossPayments API Docs
• Toss Tech blog
• Mercari Engineering blog
• OpenAPI Initiative
• JSON Schema