この記事では、Apidogの主要な概念について説明する。他の類似製品（Postmanなど）とは異なる概念が多いため、これらの定義と違いを理解することで、Apidogのワークフローをより深く理解できる。設計優先 & リクエスト優先#
ApidogのAPI管理モジュールには、インターフェースの左下隅で切り替え可能な2つのモードがあります：「設計優先」と「リクエスト優先」です。どちらのモードも似たような機能を提供しますが、インターフェースが異なり、異なるチームのワークフローに対応しています。設計優先は、Apidogが推奨するモードで、設計優先アプローチを採用するチームに適しています。このモードでは、チームはまずAPIの仕様を決定し、その後、API仕様に基づいて開発とテストを進めます。一方、リクエスト優先は、最初にAPI仕様を定義しないチームに最適です。これらのチームは通常、バックエンド開発に集中し、コードを完成させた後にAPI仕様を作成し、テストやクライアント側の作業を開始します。他の人が開発したAPIを呼び出す必要があるが、ドキュメントがない場合も、リクエスト優先モードを使用するべきです。API#
Apidogは API ファーストの製品で、すべては API の定義から始まる。API の中で最も重要な要素が API だ。Apidogのメイン画面では、API がディレクトリ形式でグループ化された基本要素として表示される。各 API に対して、「定義の編集」、プレビュー、API 仕様に基づくリクエストの送信、そしてリクエストを API ケースとして保存することができる。この構造は Postman とは大きく異なり、OAS（API 仕様）をベースに拡張した形に近い。つまり、デバッグやリクエストの保存が直接できる API 仕様という考え方だ。Postmanでは、基本要素はリクエストで、リクエストは API 仕様とは本質的に切り離されている。そのため、API 仕様が変更されると、すべてのリクエストとスクリプトを書き直す必要がある。一方、Apidogでは、すべての API ケース（Postmanでいうリクエスト）は API 仕様に基づいている。API 仕様が変更されると、API ケースも自然に変更され、それに基づくすべてのテストシナリオや CI/CD も自動または手動で更新できる。これは開発チームが API を管理・更新する上で非常に便利な仕組みだ。Request#
テストシナリオ#
複数のリクエストをまとめて送信する必要がある場合（Postman Collectionの実行に相当）、テストシナリオを使用する。Apidogにおける環境は、Postmanの環境と同様に、多数の変数を含む設定単位。環境を切り替えることで、同じ環境変数セットに対して異なる値を利用できる。ただし、Apidogではさらに重要な概念としてBase URLが導入されている。ApidogにおけるBase URLは、APIリクエストアドレスの基礎部分を指す。APIのパスと組み合わせることで、完全なリクエストURLが構成される。各環境ごとに複数のBase URLを 設定でき、サービスやマイクロサービスごとのAPI管理に対応している。この仕組みはOpenAPI（Swagger）仕様に準拠しており、APIパスは通常「/」から始まり、Base URLとAPIパスを結合することで完全なリクエストURLが生成される。そのため、毎回フルのリクエストURLを記述する必要はなく、APIパス（例：/user）のみを入力すれば、APIが属するモジュールに応じて、現在の環境で設定された該当モジュールのBase URLが自動的に付加される。例えば、プロジェクト内に3つのモジュール（サービス）があり、「Prod Env」環境でそれぞれのBase URLが以下のように設定されているとする。ユーザーサービス：https://user.example.com
注文サービス：https://order.example.com
商品サービス：https://product.example.com
https://user.example.com/user/{id}
https://order.example.com/order/{id}
https://product.example.com/product/{id}
{{BaseUrl}}を手動で 記述したり、環境を複製したりする必要はない。ApidogはAPIが属するモジュールを自動判別し、現在の環境で設定された該当モジュールのBase URLを付加して、完全なリクエストURLを生成する。モジュール#
Apidogプロジェクト内では、モジュールを使ってAPIを論理的に整理できる。モジュールは技術アーキテクチャにおける「サービス」に相当し、マイクロサービスなどのシナリオでAPI管理を効率化するための単位。各モジュールには、関連するAPI、コンポーネント（schemas、responses、Security Schemeなど）、およびBase URL（環境ごとに1つ）が含まれており、独立したSwagger/OpenAPI仕様ファイルとして扱える。データのインポートやエクスポート時、多くのフォーマット（Apidog形式を除く）はモジュール単位で操作される。これはOAS（OpenAPI仕様）により近い運用となり、標準準拠や他ツールとの連携が容易になる。新規プロジェクト作成時、デフォルトで1つのモジュールが用意される。1つの環境で複数のBase URLが必要な場合は、追加でモジュールを作成すればよい。モジュール内のすべてのAPIは、そのモジュールのBase URLを利用してリクエストが実行される。プロジェクト#
Apidogのプロジェクトは、モジュール（APIおよびコンポーネント）、環境、テストシナリオなどで構成され、コラボレーションの基本単位となる。1つのプロジェクトには複数のAPI仕様を含めることができる。Postmanと比較すると、ApidogのプロジェクトはPostmanのWorkspaceに相当し、ApidogのモジュールはPostmanのCollectionフォルダに対応する。また、ApidogのチームはPostmanのチームと同様の役割を持つ。 Modified at 2025-07-18 10:30:25
