# Laravel REST API開発｜設計・実装・外注手順

- 公開日: 2026-08-07
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/laravel-rest-api-development

Laravel REST API開発を成功させるには、実装前にAPI仕様、認証・認可、エラー、重複送信、性能、テスト、運用監視を受入条件まで決めることが重要です。外注ではコード量ではなく、成果物と責任範囲を比較してください。本記事では設計から発注・検収までを解説します。

## Laravel REST API開発で最初に決める設計基準

Laravelは、PHPでWebシステムを開発するためのフレームワーク（＝開発に必要な機能をまとめた土台）です。REST APIとは、ユーザー、商品、注文などの業務データをURLで表し、取得・登録・更新・削除するための連携窓口を指します。

Laravelを採用すること自体よりも重要なのは、実装前に「誰が、何のデータへ、どの条件でアクセスできるか」を決めることです。発注時は、APIの本数だけでなく、業務ルールやセキュリティ、運用まで仕様に含めます。

### APIの利用目的と利用者を明確にする

同じLaravel REST APIでも、利用者によって必要な設計は変わります。まず、APIを利用するクライアント（＝APIへ接続するアプリやシステム）を整理してください。

- 自社のWeb画面からのみ利用する
- iOS・Androidアプリから利用する
- 取引先や加盟店へ公開する
- 社内の複数システムから利用する
- バッチ処理や外部サービスから自動実行する

外部企業へ公開するAPIでは、仕様変更の事前通知、利用企業ごとの権限、アクセス回数制限、障害時の連絡方法まで必要です。一方、社内限定APIでも、利用システムが増えると変更による影響が広がるため、仕様書と互換性管理は省略できません。

発注前には、少なくとも次の項目を決めます。

|設計項目|決める内容|発注者が確認するポイント|
|---|---|---|
|業務リソース|ユーザー、商品、注文など、APIで扱うデータ|画面操作ではなく業務上の単位で整理されているか|
|エンドポイント|APIへアクセスするURLと処理の組み合わせ|一覧・詳細・登録・更新・削除が過不足なく定義されているか|
|利用者と権限|誰がどのデータを操作できるか|他社・他部署・他ユーザーのデータを閲覧できないか|
|入力・出力|必須項目、型、上限値、返却項目|画面や連携先が必要とするデータが含まれているか|
|エラー|失敗条件、エラーコード、利用者向けメッセージ|原因を判別でき、機密情報を表示しないか|
|互換性|既存利用者を壊さずに変更する方法|破壊的変更の基準と移行期間が決まっているか|
|非機能要件|性能、可用性、ログ、監視、バックアップ|想定件数や応答時間が数値で示されているか|

### URL、操作、ステータスコードを統一する

エンドポイント（＝APIの個別の接続先）は、画面名ではなく「注文」「顧客」などのリソースを中心に設計します。HTTPメソッドとは、取得・登録・更新・削除といった操作を表す区分です。一般的には、取得にGET、登録にPOST、更新にPATCHまたはPUT、削除にDELETEを使用します。

発注者が細かな命名規則を指定する必要はありません。ただし、開発会社からエンドポイント一覧を提出してもらい、同じ種類の操作でルールが統一されているかを確認してください。

ステータスコード（＝処理結果を表す3桁の番号）も、クライアント側の制御に影響します。代表的な扱いは次のとおりです。

|コード|意味|受入時に確認する例|
|---|---|---|
|200|取得・更新などの成功|必要なデータが定義した形式で返る|
|201|新規登録の成功|登録されたデータや識別子を確認できる|
|204|返却データのない成功|削除後などに不要な本文が返らない|
|401|認証されていない|無効な認証情報でアクセスできない|
|403|権限がない|ログイン済みでも対象データを操作できない|
|404|対象が存在しない|存在しないIDで適切に失敗する|
|409|競合している|重複登録や同時更新の競合を判別できる|
|422|入力条件を満たさない|項目ごとの入力エラーを確認できる|
|429|アクセス回数の超過|一定回数を超えた利用を制限できる|
|500番台|サーバー側の問題|内部情報を表示せず、監視へ通知される|

外部公開APIや複数のアプリが長期間利用するAPIでは、`/api/v1`のようなバージョン表記を検討します。ただし、変更のたびに番号を増やすのではなく、既存クライアントが動かなくなる変更を「破壊的変更」と定義し、その場合に限って新バージョンを用意する運用が現実的です。

### Laravel内の役割分担を設計する

保守性を高めるには、1つの処理へすべての責任を詰め込まないことが重要です。Laravelでは、次のような役割分担が代表的です。

|構成要素|役割|発注者が確認したいこと|
|---|---|---|
|Controller|リクエストを受け、処理結果を返す窓口|複雑な業務処理が集中していないか|
|Form Request|入力値を検証する仕組み|必須、上限、形式、重複などが検証されるか|
|Policy|データ単位の権限を判定する仕組み|ログイン確認だけでなく所有者や所属を確認するか|
|Service層|複数の処理にまたがる業務ルールをまとめる層|料金計算、在庫確保などが再利用可能になっているか|
|API Resource|返却するデータ形式を整える仕組み|不要な個人情報や内部項目が露出しないか|
|トランザクション|複数のデータ更新を一体として成功・取消する仕組み|途中失敗で一部のデータだけが残らないか|
|キュー|時間のかかる処理を後から実行する仕組み|メールや外部連携がAPI応答を過度に遅くしないか|

小規模なCRUD（＝データの登録・参照・更新・削除が中心の処理）で、すべての層を形式的に増やす必要はありません。一方、注文、決済、在庫、請求などが関係するシステムでは、役割を分離しないと改修時の影響範囲が読みづらくなります。開発会社には構成要素の数ではなく、「なぜその分け方にするのか」を説明してもらいましょう。

API仕様は、OpenAPI（＝APIのURL、入力、出力、エラーを機械的に記述する標準形式）などで文書化すると、フロントエンド開発やテストとの認識差を減らせます。依頼内容の整理から必要な場合は、[RFPの作り方｜システム開発の依頼準備](https://www.geek-bridge.com/column/system-development-rfp-creation-guide)も参考にしてください。

## Laravel REST API開発の手順・期間・成果物

Laravel REST API開発は、要件定義（＝作るものを決める工程）、API設計、実装、テスト、リリースの順に進めます。小規模なら2〜4か月、中規模なら4〜8か月、複雑な外部連携や高い可用性が必要な案件では8〜12か月以上が一般的な目安です。

工程は一部並行するため、各期間の合計がそのまま全体期間になるとは限りません。

|工程|一般的な期間の目安|主な作業|主な成果物|
|---|---:|---|---|
|事前調査|1〜3週間|現行業務、既存システム、データ、接続先の確認|調査結果、課題一覧、概算見積もり|
|要件定義|2〜5週間|利用者、機能、権限、性能、運用条件の決定|要件定義書、業務フロー、責任範囲表|
|API・DB設計|2〜6週間|エンドポイント、データ構造、エラー、認証の設計|API仕様書、データ設計書、権限表|
|実装・単体テスト|4〜12週間以上|Laravelでの実装、入力検証、認可、自動テスト|ソースコード、単体テスト結果|
|結合・受入テスト|2〜6週間|画面や外部システムとの連携、性能、障害系の確認|テスト仕様書、結果、課題管理表|
|リリース準備|1〜2週間|移行、監視、切り戻し、運用手順の確認|リリース手順書、監視設計、運用手順書|

### 1. 調査と要件定義

最初に、APIを呼び出す画面や外部システム、現在のデータ量、将来の増加量、個人情報の有無を整理します。既存システムへ追加する場合は、LaravelやPHPのバージョン、データベース、外部ライブラリ、ソースコード、テストの有無も確認が必要です。

発注者側では、次の情報を準備すると見積もりの精度が上がります。

- APIを利用する画面、アプリ、外部システム
- 利用者の種類と人数
- 取り扱うデータと閲覧・更新権限
- 1日あたりの処理件数、ピーク時のアクセス数
- 外部連携先の仕様書と検証環境
- 現行データの形式、件数、品質
- 希望納期と、納期を変更できない理由
- 本番稼働後の問い合わせ・障害対応体制

### 2. API仕様とデータ構造の設計

入力・出力の項目だけでなく、入力不備、権限不足、対象なし、重複送信、外部サービス停止などの失敗条件を設計します。正常系だけを先に作ると、テスト工程で例外処理が追加され、見積もりと納期が膨らみやすくなります。

API仕様書には、少なくとも次を含めます。

- URLとHTTPメソッド
- 利用できる権限
- 必須・任意の入力項目
- 成功時の返却項目
- エラー条件とステータスコード
- 一覧の並び順、検索条件、最大取得件数
- APIバージョンと廃止ルール
- 重複送信や同時更新の扱い
- アクセス回数制限

### 3. 実装と自動テスト

実装では、入力検証、業務ルール、データ更新、出力整形を分け、変更の影響を限定します。注文と注文明細のように複数データを同時更新する場合は、トランザクションによって一部だけ保存される状態を防ぎます。

決済や外部サービス連携では、タイムアウトや再送も想定します。冪等性とは、同じリクエストが複数回来ても処理結果が重複しない性質です。注文登録や決済APIでは、受付キーを使って二重登録を防ぐなどの設計が欠かせません。

### 4. 結合テスト・受入テスト

開発会社内のテストだけでなく、実際のWeb画面、スマホアプリ、外部システムから接続して確認します。発注者が行う受入テストでは、技術的な正しさだけでなく、業務上の結果が正しいかを確認してください。

例えば、注文APIであれば、在庫不足、価格改定の境界日時、権限の異なる利用者、同時注文、外部決済の失敗なども対象です。本番に近いデータ量で性能を確認しなければ、少量のテストデータでは問題が見つからない場合があります。

### 5. リリースと運用引き継ぎ

本番反映では、データ移行、停止時間、切り戻し条件、監視方法を決めます。CI/CD（＝テストや本番反映を自動化する仕組み）を導入する場合も、誰が承認し、失敗時に誰が戻すかという運用ルールが必要です。

ソースコードだけを納品物にすると、運用開始後の調査や別会社への引き継ぎが困難です。API仕様書、環境構築手順、テスト、監視項目、リリース手順も契約上の成果物に含めましょう。

## Laravel REST API開発の費用相場と見積もり

Laravel REST API開発の費用は、APIの本数だけでは決まりません。一般的な目安として、限定的な社内APIは100万〜300万円、中規模の業務・Webサービス向けAPIは300万〜800万円、決済や複数の外部連携を含む大規模開発は800万〜2,000万円以上です。

以下は、バックエンドAPIを中心とした税別の概算です。Web画面やスマホアプリ、クラウド利用料、大規模なデータ移行、継続保守は別費用になる場合があります。

|規模|費用の目安|期間の目安|想定する内容|
|---|---:|---:|---|
|小規模・検証用|100万〜300万円|2〜4か月|5〜15前後の単純なAPI、限定利用、基本的な認証とテスト|
|中規模|300万〜800万円|4〜8か月|20〜50前後のAPI、複数権限、業務ルール、外部連携、運用監視|
|大規模・高難度|800万〜2,000万円以上|8〜12か月以上|決済、複数組織、高負荷、複雑な権限、移行、高度な監査要件|

エンドポイント数は規模を把握する補助指標にすぎません。1本の注文登録APIに在庫、価格、割引、決済、通知が含まれる場合、単純なマスタ参照APIを複数作るよりも工数が大きくなります。

### 費用を左右する主な要因

- 業務ルールと例外条件の複雑さ
- 利用者、部署、企業ごとの権限パターン
- 決済、会計、物流などの外部サービス連携
- 既存データの移行・クレンジング
- 同時アクセス数と求める応答速度
- 個人情報、金融情報などのセキュリティ要件
- API仕様書や運用手順書の作成範囲
- 自動テスト、性能テスト、セキュリティテストの範囲
- 夜間・休日対応や障害時の復旧条件
- 既存Laravelシステムの調査と改修難易度

発注のご相談を受ける開発会社の立場から見ると、「APIだけなので安く短期間で作れるはず」という認識は、発注者と開発会社の間でずれやすい点です。画面がなくても、認証、権限、データ整合性、エラー、外部連携、テスト、監視は必要です。特に複数のアプリから共通利用されるAPIは、変更の影響が大きいため、設計とテストの比重が高くなります。

### 見積書で確認する項目

見積書は総額だけでなく、次の作業が含まれているかを確認します。

|見積項目|確認する内容|
|---|---|
|要件定義・API設計|権限、エラー、非機能要件まで対象か|
|既存調査|ソースコード、DB、インフラ、外部ライブラリを調査するか|
|実装|対象エンドポイントと業務ルールが特定されているか|
|テスト|正常系だけでなく、権限、例外、重複、性能を含むか|
|環境構築|開発・検証・本番のどこまで担当するか|
|データ移行|移行プログラム、リハーサル、結果確認を含むか|
|ドキュメント|API仕様書、テスト結果、運用・リリース手順が納品されるか|
|プロジェクト管理|会議、課題管理、進捗報告の工数が含まれるか|
|保証・保守|無償修正の条件、期間、稼働後の対応範囲|

「一式」とだけ書かれた見積もりは、後から対象外が判明しやすくなります。各社へ同じ前提条件を渡したうえで、除外事項と仮定も提出してもらってください。比較方法は[システム開発の相見積もり｜取り方と比較方法](https://www.geek-bridge.com/column/system-development-quote-comparison-guide)で詳しく解説しています。

契約方式も確認が必要です。請負契約は、合意した成果物の完成を目的とする契約です。要件が固まっている開発に向きます。準委任契約は、一定期間の業務遂行を依頼する契約で、調査しながら仕様を決める場合に向きます。

|契約方式|向いている状況|注意点|
|---|---|---|
|請負契約|仕様と検収条件が明確|仕様変更が追加費用や納期変更になりやすい|
|準委任契約|不確実性が高く、優先順位を変えながら進める|完成物や予算上限を別途管理する必要がある|
|段階契約|調査・要件定義後に開発を再見積もりする|初期見積もりだけで総額を確定できない|

既存システムの品質や外部連携仕様が不明な場合は、調査・要件定義だけを先に契約し、その成果を使って開発費を再見積もりする方法が現実的です。

## 安全性・保守性の受入基準と開発会社の選び方

開発会社を選ぶときは、Laravelの実装経験だけでなく、API設計、セキュリティ、テスト、運用まで具体的に説明できるかを確認します。「Laravelを使える」と「長期運用できるAPIを設計できる」は同じではありません。

### 認証・認可を分けて確認する

認証は「誰であるか」を確認する仕組み、認可は「その人が何をしてよいか」を判定する仕組みです。ログイン済みでも、別企業の注文を閲覧できてはいけません。

Laravelでは、SPA（＝Webブラウザ上で動くアプリ）やモバイルアプリの比較的シンプルな認証にSanctumが候補になります。第三者のサービスへOAuth 2.0（＝利用者の許可に基づき限定的なアクセス権を渡す標準方式）を提供する場合はPassportが候補です。製品名だけで決めず、利用者、接続元、トークンの有効期限、失効方法に基づいて選びます。

最低限のセキュリティ確認項目は次のとおりです。

- 未認証のアクセスを拒否する
- 他ユーザー・他組織のデータを拒否する
- 管理者だけが使える操作を制限する
- パスワード、トークン、決済情報をログへ出さない
- 一定回数を超えるアクセスを制限する
- 予期しないエラーで内部情報を表示しない
- 依存ライブラリの脆弱性を継続確認する
- LaravelとPHPのサポート期間を踏まえた更新計画を持つ
- 重要操作について誰がいつ実行したかを記録する

### テストと検収条件を具体化する

「テスト済み」という表現だけでは範囲が分かりません。自動テストの対象、手動確認する項目、発注者が受け入れる条件を一覧化します。

|テスト領域|確認する内容|
|---|---|
|正常系|登録・取得・更新・削除が仕様どおり動く|
|入力検証|必須、文字数、数値範囲、形式、重複を検知する|
|認証・認可|未認証、権限不足、他組織からのアクセスを拒否する|
|データ整合性|途中失敗時に不完全なデータが残らない|
|冪等性|同じ登録・決済依頼が再送されても二重処理されない|
|外部連携|タイムアウト、エラー、再試行時の動作が決まっている|
|性能|想定データ量と同時アクセス数で応答条件を満たす|
|互換性|既存アプリがAPI変更後も動作する|
|運用|エラー、処理遅延、キュー失敗を検知・追跡できる|

一覧APIでは、無制限にデータを返さず、ページネーション（＝結果を一定件数ごとに分割する仕組み）と最大取得件数を設定します。性能条件は「高速であること」ではなく、「同時利用者数、データ件数、対象API、応答時間の目標」をセットで定義してください。

### 開発会社への質問リスト

候補会社との商談では、次の質問に対して具体的な回答があるかを確認します。

- API仕様はどの形式で作成・更新しますか
- 認証とデータ単位の認可をどう分けますか
- 重複送信や同時更新をどのように扱いますか
- 自動テストの対象と、対象外になる部分は何ですか
- 性能テストはどのデータ量・アクセス数で行いますか
- LaravelやPHPのアップデートをどう計画しますか
- 障害発生時にログからリクエストを追跡できますか
- 外部サービス停止時の再試行や復旧方法はどうしますか
- API仕様書と実装のずれをどう防ぎますか
- 別会社へ引き継ぐ場合に何を納品できますか

回答が技術用語だけで終わらず、事業上のリスクや費用とのバランスまで説明されるかが重要です。高度な構成を無条件で提案する会社より、利用規模に合わせて必要な対策を選べる会社のほうが、過剰投資を避けやすくなります。

### よくある失敗と回避策

|よくある失敗|起こる問題|回避策|
|---|---|---|
|画面の操作だけでAPIを決める|別アプリから再利用しにくい|業務リソースと利用者を基準に設計する|
|正常系だけを見積もる|例外処理が追加費用になる|エラー条件と外部障害を要件に含める|
|認証だけ実装する|他人・他社のデータへアクセスされる|データ単位の認可テストを受入条件にする|
|API本数だけで金額を比較する|複雑さや品質範囲を比較できない|業務ルール、テスト、成果物を揃えて比較する|
|仕様書を納品対象にしない|改修や引き継ぎが難しくなる|API仕様書の形式と更新責任を契約に記載する|
|リリース後の監視を決めない|障害や処理遅延の発見が遅れる|監視項目、通知先、一次対応者を決める|
|最新版への追随計画がない|保守切れや脆弱性対応が遅れる|Laravel・PHPの更新方針を保守契約に含める|

APIの設計、既存Laravelシステムの調査、見積もり整理から支援が必要な場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)をご利用ください。

## まとめ

- Laravel REST API開発では、実装前に利用者、権限、入力・出力、エラー、性能、運用条件を決めます
- API仕様書には正常系だけでなく、権限不足、重複送信、外部障害、互換性も含めます
- 小規模開発は100万〜300万円・2〜4か月、中規模は300万〜800万円・4〜8か月が一般的な目安です
- 見積もりはAPI本数や総額だけでなく、設計、テスト、環境、文書、保守の範囲を比較します
- 受入テストでは認証・認可、データ整合性、冪等性、性能、監視まで確認します
- 開発会社はLaravel経験だけでなく、設計意図と事業上のリスクを説明できるかで選びます
- API仕様書、自動テスト、リリース手順、監視設計を成果物として明確にします

## よくある質問

### Laravel REST APIを外注する前に何を決めるべきですか？

APIの利用者、接続元、対象データ、権限、入力・出力、エラー条件、性能、運用体制を整理します。すべての技術仕様を決める必要はありませんが、業務ルールと受入条件は発注者側で確認できる状態にしてください。

### Laravel REST API開発の費用と期間はどの程度ですか？

一般的な目安は、小規模で100万〜300万円・2〜4か月、中規模で300万〜800万円・4〜8か月です。決済、複雑な権限、高負荷、データ移行、複数の外部連携がある場合は800万〜2,000万円以上、8〜12か月以上になることがあります。

### Laravel SanctumとPassportはどう選びますか？

自社SPA、モバイルアプリ、シンプルなAPIトークン認証ではSanctumが候補です。第三者クライアントへOAuth 2.0の認可フローを提供する場合はPassportを検討します。利用者、接続元、トークンの有効期限、失効方法に基づいて選定してください。

### APIのURLにバージョン番号は必要ですか？

必須ではありませんが、外部公開APIや複数クライアントが長期間利用するAPIでは、`/api/v1`のような表記が互換性管理に役立ちます。番号だけでなく、破壊的変更の基準、旧版の提供期間、廃止の通知方法も決めることが重要です。

### Laravel REST APIの検収で必要な成果物は何ですか？

API仕様書、ソースコード、自動テストと結果、環境構築手順、リリース・切り戻し手順、監視項目、運用手順を基本とします。外部連携やデータ移行がある場合は、連携テスト結果と移行結果も成果物に含めてください。