OpenAPI(API 仕様の単一の正)
公式サイトOpenAPI(API 仕様の単一の正)とは
OpenAPIは、WebのAPIが「どのURLに、どんなデータを送ると、どんなデータが返るか」を、人にも機械にも読める形式で記述するための標準規格です。この記述から、閲覧用の仕様書、画面側でAPIを呼び出すコード、テスト用の模擬サーバーなどを自動生成できます。APIの仕様書を文書として別に管理すると、実装と食い違ったまま放置されがちですが、OpenAPIを仕様の「単一の正」として扱うことで、仕様と実装とドキュメントを一致させ続ける運用が可能になります。
弊社が採用する理由
弊社では、画面とサーバーを分けて開発するWebシステムで、APIの仕様をOpenAPIで管理し、これを唯一の正として扱っています。Laravelで作るサーバーでは、コードの型や入力チェックからOpenAPIの仕様を生成するツールを使い、実装と仕様が乖離しないようにしています。生成した仕様からは、Orvalというツールで画面側のAPI呼び出しコードとTypeScriptの型を自動生成し、Next.jsやReactの画面から利用します。これにより、サーバー側で項目を追加・変更すると、画面側のどこに影響するかが型チェックで即座にわかります。スマートフォンアプリや外部システムと連携する案件では、仕様書をOpenAPIから生成して共有できるため、要件定義や基本設計の成果物としても機能します。担当者が変わっても仕様が実装から自動的に得られる点は、長期の保守で大きな安心材料になります。
向いている案件
- 画面とサーバーを分けて開発するWebシステム
- スマートフォンアプリや外部システムと連携するAPIの開発
- 複数の開発者・開発会社の間でAPI仕様を共有する必要がある案件
- 仕様書と実装を一致させ続けたい長期運用のシステム
保守・移行の観点
OpenAPIの仕様は実装から生成する運用にしておくと、仕様書の更新忘れを防げます。逆に手書きで管理する場合は、実装との突き合わせを継続的インテグレーションで自動検証する仕組みが必要です。APIの変更で既存の呼び出し側が壊れないよう、項目の削除や型の変更は互換性を保ちながら段階的に行い、仕様の版管理と変更履歴を残します。画面側のコード生成はビルドの一部に組み込み、生成物を手で編集しない運用を徹底すると、更新時の混乱を避けられます。
組み合わせて使う技術
よくあるご質問
API仕様書は納品物に含まれますか?
はい。OpenAPIの仕様と、そこから生成した閲覧用の仕様書を納品物に含めています。実装から生成しているため、納品時点の実装と一致した内容になります。
既存のAPIにも後からOpenAPIを導入できますか?
可能です。既存のコードから仕様を生成するツールや、通信内容から仕様を起こす方法があります。まず現状のAPIの数と構成を確認し、段階的に整備する進め方をご提案します。
OpenAPIで書けば外部の開発会社にもAPIを渡せますか?
OpenAPIは業界標準の形式なので、多くの開発会社やツールがそのまま読み込めます。スマートフォンアプリの開発を別の会社が担当する場合の連携にも適しています。
関連するサービス
関連する開発ガイド
- 要件定義とは何をすることか — 発注前に整理したい5つのこと要件定義はシステムで何を実現するかを合意する工程です。発注前に整理したい目的と成功条件、現状業務の流れ、利用者と権限、扱うデータ、やらないことの5つを、想定例を交えて解説します。
- 他社が作ったシステムの引き継ぎ・保守を依頼するときのチェックリスト前の開発会社が作ったシステムの保守を別の会社に引き継ぐときの手順を、資料・アカウント・ソースコード・環境の棚卸しから調査、リスク整理、保守範囲の合意、移行まで、確認項目の表とともに解説します。
- 検収(受け入れテスト)で確認すべきことWebシステムの検収で発注側が確認すべきことを、検収条件の確認、テスト項目の作成、ステージングでの実施、不具合の記録と切り分け、検収書の作成の手順で解説し、契約不適合責任との関係も整理します。
監修: Unlogical Systems合同会社(杉並区・西荻窪)公開