以下の内容はhttps://tech.kickflow.co.jp/entry/2026/04/01/110522より取得しました。


OpenAPIドキュメントツールScalarのすすめ

こんにちは、CTOの小林です。

新規事業で開発者向けAPIを提供することになり、APIドキュメントのツール選定をすることになりました。

kickflowではRedocly社が提供するOSS版のRedocをGitHub Pagesでホストして使っています。

developer.kickflow.com

Redocに大きな不満があるわけではないのですが、新規事業は技術スタックもチーム体制もkickflowとは異なるので、改めてゼロベースで選定し直すことにしました。

結論から言うと Scalar API Referenceを採用した ので、比較検討の過程と採用理由を書いていきます。

そもそもOpenAPIドキュメントツールとは

REST APIの仕様を記述するフォーマットとして、OpenAPI Specification(旧Swagger Specification)がデファクトスタンダードになっています。YAML/JSONで書かれたOpenAPIファイルを読み込ませると、人間が読めるインタラクティブなドキュメントを生成してくれるのがOpenAPIドキュメントツールです。

代表的なOSSとしてはSmartBear社のSwagger UI、Redocly社のRedoc、Scalar社のScalar API Referenceなどがあり、いずれもOpenAPI 3.x系に対応しています。各社ともOSSのドキュメントツール単体に加えて、API設計・管理を含む有料プラットフォームも提供していますが、今回はOSSとして使うことを前提に比較しました。

比較候補: Swagger UI / Redoc / Scalar API Reference

Swagger UI — みんな知ってるあの画面

github.com

Swagger UIはSmartBear社がOSSで提供しているOpenAPIドキュメントツールです。有料プラットフォームのSwaggerHubとは別製品で、Swagger UI単体はApache 2.0ライセンスで無料で使えます。

良い点:

  • おそらく世界でもっとも広く使われているOpenAPIドキュメントUI。情報が豊富
  • 「Try it out」ボタンでAPIリクエストを実際に送れる
  • セットアップが簡単で、ほとんどのフレームワークがデフォルトで対応している

つらい点:

  • UIのルック&フィールが古い。内部的にはメジャーバージョンアップを重ねているものの、見た目の基本構成は初期から大きく変わっておらず、2025年の目で見ると厳しい
  • エンドポイントが増えるとページが縦に長くなり、見通しが悪くなる
  • OSS標準ではコードスニペット生成がない。開発者は自分でcurlやSDKのコードを組み立てる必要がある
  • カスタマイズの自由度が低い。テーマを変えるにもかなりの手間がかかる

FastAPIやASP.NET CoreなどSwagger UIがデフォルトで組み込まれているフレームワークではそのまま使う合理性がありますが、ゼロから選定するケースであえてSwagger UIを新規採用する積極的な理由は少ないと思います。

Redoc — Stripe風3パネルの定番

github.com

kickflowで使っているのがRedocです。Redocly社が提供するOSS(MITライセンス)で、Stripe風の3パネルレイアウトが見やすく、FastAPI・Djangoなど多くのフレームワークが標準でビルトインサポートしています。

なお、Redocly社はRedocのほかに有料SaaSも提供しており、そちらではTry It機能やDev Portal構築が可能ですが、今回はOSS版のRedocだけを評価対象としています。

kickflowではCIでOpenAPIファイルをRedocの静的HTMLと一緒にGitHub Pagesにデプロイしており、運用コストはほぼゼロです。

kickflowで使っていて良いと感じる点:

  • 3パネルレイアウトが見やすい。左にナビゲーション、中央にドキュメント、右にリクエスト/レスポンスの例。情報の視認性が高い
  • 静的HTMLとして生成できるので、GitHub Pagesとの相性が良い
  • OSS版でも見た目の品質が高く、外部に公開しても恥ずかしくない

新規事業で改めて評価して気になった点:

  • OSS版のRedocにはTry Itがない。 ドキュメントを読んでいるときに「このエンドポイント、ちょっと叩いてみたい」ができない。read-onlyなので、開発者は別途PostmanやcurlでAPIを叩く必要がある
    • Try Itを使うにはRedocly社の有料SaaSが必要で、OSSや無料の範囲では手に入らない
  • UIが新興ツールと比べるとやや世代の古さを感じる(かもしれない)

Redocは安定した良いツールです。kickflowでは現時点では継続利用する予定です。ただ、OSS版でTry Itがないのは物足りないポイントでした。

Scalar API Reference — 新世代のOSSファーストドキュメントUI

github.com

Scalar社が2023年からOSSで提供しているドキュメントツールです(MITライセンス)。GitHubでのスター数は急速に伸びており、この記事の執筆時点(2026年3月)で1.4万を超えています。Hono、Nitroなどモダンなフレームワークが次々とScalar API Referenceに対応しており、勢いがあります。有名なサービスだと、SupabaseやZoomがAPIドキュメントに採用しています。

Scalar社はScalar API Referenceのほかにも、デスクトップ版のScalar API Client(Postman的なHTTPクライアント、こちらもMITライセンス)やOpenAPI管理のScalar Registry、SDK生成のScalar SDKsなどを提供しており、OpenAPIを軸としたツールチェーン全体をOSSファーストで展開しています。

良い点:

  • OSSでTry Itが使える。 ドキュメント上からAPIリクエストを送れる。Redocでは有料SaaS版でしか使えない機能が、Scalar API Referenceでは無料で手に入る
  • UIがモダン。 ダークモードデフォルト、外部の開発者に見せるドキュメントとしての見栄えが良い
  • コードスニペット生成が強い。 各エンドポイントに対して、curl / JavaScript / Python / Go / PHP / Ruby / Java / C# などのコードを自動生成してくれる。Swagger UIやRedocのOSS版では標準で提供されていない機能
  • 統合が豊富。 Nuxt、Next、Hono、Laravel、Rails、Rust……30以上のフレームワーク統合
  • カスタマイズが自由。 テーマ、カスタムCSS/JS、すべてOSS版で制限なく使える

気になる点:

  • 2023年登場でまだ若く、利用実績が他の選択肢に比べると少ない
  • 情報が英語中心で、日本語の情報はまだ少ない

比較まとめ

Swagger UI Redoc Scalar API Reference
提供元 SmartBear Redocly Scalar
ライセンス Apache 2.0 MIT MIT
Try It(API実行)
コードスニペット生成 ❌(標準機能としては非搭載)
UIのモダンさ やや古さを感じる 十分実用的 非常にモダン
フレームワーク統合 多い 多い 非常に多い
カスタムCSS/テーマ 手間がかかる 可能 容易

決め手

最終的にScalar API Referenceを選んだ決め手は3つです。

  1. OSSでTry Itが使える。 外部開発者にAPIを触ってもらう前提なので、ドキュメント上でリクエストを投げられることは必須要件でした。OSSの範囲でこれができるのはSwagger UIとScalar API Referenceだけです
  2. コードスニペット生成。 開発者がドキュメントを見て「じゃあ実装するか」となったとき、コピペできるコードが目の前にあるのは地味に便利です。curl、fetch、axios、requests……どの言語/ライブラリでもワンクリックで生成されます
  3. UIの第一印象が良い。 新規事業では、APIドキュメントが外部開発者にとっての「プロダクトの顔」になります。Scalar API Referenceのモダンさはそのまま開発者体験の質に直結します

OSS版Scalar API Referenceの使い方

ここからは実際の導入方法を紹介します。Scalar API Referenceは30以上のフレームワーク統合を提供していますが、ここでは最も簡単にHTMLファイル1つで動かす方法を紹介します。以下のようなHTMLファイルを1つ作るだけで動きます。

<!doctype html>
<html>
  <head>
    <title>API Reference</title>
    <meta charset="utf-8" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1" />
  </head>
  <body>
    <div id="app"></div>
    <!-- Load the Script -->
    <script src="https://cdn.jsdelivr.net/npm/@scalar/api-reference"></script>
    <!-- Initialize the API Reference -->
    <script>
      Scalar.createApiReference('#app', {
        // The URL of the OpenAPI/Swagger document
        url: 'https://registry.scalar.com/@scalar/apis/galaxy?format=json',
        // Avoid CORS issues
        proxyUrl: 'https://proxy.scalar.com',
      })
    </script>
  </body>
</html>

これだけでOpenAPIファイルを読み込んだインタラクティブなAPIリファレンスが表示されます。

その他のフレームワークについては公式のIntegrationsページを参照してください。

実際の利用例

SupabaseやZoomのAPIドキュメントで採用されています。SupabaseのAPIドキュメントがまっさらな状態のScalar API Referenceなので、参考にしてみてください。

Zoom

developers.zoom.us

Supabase

api.supabase.com

まとめ

OSSまたは無料でAPIドキュメントツールを選ぶなら、2025年時点ではScalar API Referenceがもっともバランスの良い選択肢だと思います。

  • Swagger UIはTry Itがあるが、UIが古い
  • Redocは美しいが、OSS版にTry Itがない
  • Scalar API ReferenceはUIがモダンで、OSSでもTry It・コードスニペット生成・テーマカスタマイズがフル機能で使える

今回の新規事業のように「ゼロから選び直す」「外部開発者向けのAPIドキュメント」という条件であれば、Scalar API Referenceを第一候補にすることを個人的にはおすすめします。HTMLファイル1つから試せるので、まずは触ってみてください。

careers.kickflow.co.jp




以上の内容はhttps://tech.kickflow.co.jp/entry/2026/04/01/110522より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14