CakePHPのシステム開発を外注する流れは、業務課題と要件を整理し、委託範囲と契約を決めるところから始まります。そのうえで、見積もりと体制を比べて依頼すると、予算と品質を管理しやすくなります。
発注形態、RFP、契約と開発の進め方の順に、確認する点をまとめます。
▼全体ガイドの記事
・CakePHPのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
CakePHPのシステムを発注・外注する前の全体像
CakePHPは、PHPで業務向けのWebアプリケーションを構築するオープンソースのMVCフレームワークです。
顧客管理や受発注、在庫の業務と相性がよい点が特徴です。予約や会員、申請、管理画面など、繰り返し使う業務システムにも向いています。さらに、ブラウザ向けの画面だけでなく、スマートフォンアプリや外部サービスにデータを返すAPI基盤としても利用できます。
ライセンス費用と開発費用の分け方
CakePHPはオープンソースのため、ライセンス料は開発費の中心になりません。
- 開発工程：要件整理、設計、実装、テスト、インフラ整備の工数
- 移行と連携：データ移行や基幹システム、POS、決済、メールとの連携
- 管理機能：操作ログや権限管理の実装
業務を理解して要件を決める人、設計・実装・テストを担う人、インフラ担当の工数で費用が決まります。さらに、Excelや旧システムからの移行、外部連携、ログや権限管理が加わるほど、必要な工数は増えます。
規約やORMで開発を効率化できても、自社固有の業務ルールや例外処理には別途費用がかかります。そのため、「CakePHPだから数十万円で作れる」と考えるのは危険です。
発注先を選ぶときは、経験年数だけでなく、業務分析からリリース後の保守まで対応できるかも見ておきます。
向いている業務と既存システムの移行の判断
まず、新規開発か既存システムの改修かを分けて、業務に合う方式と調査範囲を決めます。
- 独自業務：入力項目、承認経路、権限、検索、CSV入出力、帳票、API連携を作り込む場合に向いています。
- 標準業務：勤怠や会計はSaaS・パッケージで早く始められる場合があります。
- 既存改修：CakePHP 2・3・4の現行コード、PHP、プラグイン、認証、DB、テストの調査
たとえば、標準部分はSaaSにし、独自性の高い受発注や顧客管理だけをCakePHPで作る方法もあります。
単純なバージョンアップで済むかは、テストの有無も含めて判断します。2026年8月時点の公式対応表では、5.x系とPHP 8系の組み合わせが案内されています。一方で、4.x系のセキュリティサポートは2026年9月10日までとされています（出典: CakePHP公式「Supported Versions」、2026年）。
発注側は、段階移行と再構築のどちらが安全かも、見積もりに含めて比べます。
CakePHPのシステムを外注する発注形態
業務要件が固まっていない企業には、要件定義から伴走できる会社への一括発注か段階発注が適しています。
仕様が明確で、自社にプロジェクト管理者がいる場合は、開発工程だけの請負やラボ型開発も選べます。ただし、体制と要件の確度を見ずに決めると、安く見えた発注が追加費用や手戻りにつながることがあります。
要件定義から運用までの一括外注
業務整理と要件定義から保守まで、一社に委託する形です。
IT担当者が少なく、現場ヒアリングやシステム化の範囲から相談したい場合に向いています。
窓口が一本になり、責任の所在を明確にしやすい一方、発注側にも業務責任者と意思決定者が必要です。
納品物は「ソースコード一式」だけにとどめず、必要な文書も契約に明記します。
- 設計資料：要件定義書、画面一覧、権限表、データ項目定義
- 開発資料：API仕様、テスト仕様書、移行手順書
- 運用資料：運用手順書、問い合わせ窓口、障害時の初動時間
CakePHPやPHPのアップデート方針も、契約前に確かめます。
設計・開発・テストを工程ごとに外注
自社で企画や要件定義を行い、CakePHPの設計・実装・テストだけを委託する形です。
発注側の準備と各工程の条件を先にそろえておくと、委託先を比べやすくなります。
- 発注側の準備：業務や画面仕様、データ項目の整理
- 要件の補完範囲：不足要件を誰が補うか曖昧だと、着手後に追加費用が生じることがあります。
- 工程の完了条件：基本設計は画面遷移図とデータモデルの承認を条件にできます。
- 次工程への引き継ぎ：受入テスト項目の共有と、成果物に不備があった場合の費用・納期の取り決め
ラボ型開発やフリーランスへの委託
継続開発の体制と委託する業務の規模から、ラボ型か個人への委託かを判断します。
- ラボ型：一定期間チームを確保し、優先順位を変えながら継続して開発する形
- 社内担当：ラボ型では、日々の優先順位付けとレビューを担う人が必要です。
- フリーランス：特定機能の改修や小規模保守に有効です。
- 委託先の技術：CakePHP 5・PHP 8系の経験と、レビュー、テスト、バックアップの有無
ラボ型は月額や稼働人数が見えやすい一方、社内担当の負担が前提になる点も見込んでおく必要があります。
新規サービスや継続改善に適した方式です。ただし、個人情報、決済、基幹連携、24時間運用を扱う場合は、代替要員と障害対応の体制を確認します。
契約終了時の引き継ぎ方法も確かめておき、会社の規模だけで委託先を選ばないようにします。
RFPと要件整理の準備範囲
RFPは、開発会社に提案と見積もりを依頼するための資料です。完成した仕様書でなくても構いません。
まず、業務課題、対象ユーザー、現行業務、必要機能を書きます。そのうえで、連携先、納期、予算の考え方、保守の希望をまとめます。こうして条件をそろえると、会社ごとの見積もりや提案の差を比べやすくなります。
現行業務と困りごとの業務フロー
誰が、いつ、どの情報を使い、何を判断しているかを業務フローに書き出します。
入力が紙やExcel、メール、電話、既存システムに分かれていれば、それも洗い出します。
- 入力の問題：二重入力や転記ミス
- 処理の停滞：承認の滞留や月次集計の時間
- 例外業務：担当者しか分からない処理
業務フローがないまま機能名だけを伝えると、会社ごとに想定する範囲が変わり、見積もりを比べられなくなります。
通常業務のほかに、返品や取消、欠品の処理を確かめます。権限外の申請や締め後の修正も対象です。さらに、障害時の手作業を聞き取り、現場の判断とデータの流れを整理します。
業務ごとに「必須」「できれば欲しい」「将来検討」の優先度を付けます。そのうえで、最初のリリース範囲を絞ります。
機能要件と非機能要件の分け方
機能要件には、システムが何をするかを書きます。あわせて、各機能の利用者と完了条件も付けます。
- 業務機能：ログイン、顧客登録、受注、在庫引当、承認
- データ操作：検索、CSV、帳票、メール通知、API連携
- 処理条件：利用者、入力項目、処理ルール、エラー時の動作、権限
画面の数に加えて、画面内の分岐やデータの状態も示すと、工数の見積もりに使える情報になります。
非機能要件には、同時利用者数、応答時間、稼働時間を含めます。さらに、バックアップと障害復旧も入れます。ログ保存期間とデータ保持期間に加えて、セキュリティ、スマートフォン対応、拡張性も整理します。
個人情報を扱う場合は、識別・認証、権限制御、操作記録、不正アクセス防止の内容をRFPに明記します。
委託先の安全管理も記載します（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」、2026年確認）。
RFPに添付する資料
見積もりの前提をそろえるため、業務、システム、予算に関する資料を添付します。
- 業務資料：会社概要、背景、業務フロー、画面一覧、権限一覧
- システム資料：構成図、データ項目、外部連携、移行対象、想定ユーザー数
- 計画と予算：希望スケジュール、予算の上限またはレンジ
- 既存資料の共有条件：閲覧範囲と機密情報の扱いを決めたうえでの、ソースコードや設計書の共有
受入テストの観点は、発注前に書いておきます。「受注登録ができる」という書き方では、合格条件としては不十分です。
締め後の変更制限や在庫不足時の通知、連携失敗時の再送など、合格の状態を示します。これにより、各社の提案や見積もりが同じゴールに向いているかを確認できます。
契約形態と開発の進め方
要件の確度と開発の不確実性に応じて、請負、準委任、ラボ型契約を使い分けます。たとえば、要件定義は準委任、仕様確定後の開発は請負とし、継続改善は準委任とする組み合わせもあります。
契約名称よりも、成果物や責任範囲、変更管理を確かめます。さらに、検収や知的財産、保守条件も見ておきます。
請負契約と準委任契約の違い
成果物と完成条件を固定できるかを基準に、契約ごとの特徴と注意点を見比べます。
- 請負：成果物の完成と検収が前提で、画面やAPI、データ移行、テストなど範囲の明確な工程に向いています。
- 請負の変更：要件変更で追加費用や納期変更が生じるので、変更時の見積もりと承認者、優先順位の下げ方を決めておく。
- 準委任：業務の遂行が前提で、要件定義や技術調査、改善、保守などに適しています。
- 準委任の条件：稼働、報告、単価、責任者、情報管理、権利、引き継ぎの明記
要件定義からリリースまでの工程
CakePHP開発は、要件整理から運用開始まで順に進めます。
- 要件定義：業務フロー、画面、権限、データ、連携、非機能要件、受入条件を固めます。
- 設計：基本設計で画面遷移とデータモデル、詳細設計で処理ルールとAPI仕様を決めます。
- 環境確定：CakePHP、PHP、データベース、認証、ログ、バックアップ、CI/CDの構成の確定
- 開発と確認：顧客登録や受注登録など業務単位での試作品の確認
- テスト：機能、性能、脆弱性、障害復旧、バックアップ復元、データ移行の検証
- リリース：教育、マニュアル、問い合わせ窓口、切り戻し条件、旧システムとの並行稼働期間の決定
試作品は、実データに近いサンプルで確かめます。権限不足や入力エラーも検証の対象です。CSVの文字コードや帳票、APIのタイムアウト、二重登録も確認項目になります。
初期不具合の無償対応期間は、追加開発、更新、監視、バックアップを含む保守契約とは分けて記載します。
CakePHP 4以下から移行する場合は、現行システムの解析とテストの再構築に時間をかけることで、公開後の障害リスクを抑えられます。
契約書に入れるべき安全管理と引き継ぎ条件
顧客、従業員、医療、決済の情報を扱う場合は、委託先の安全管理措置を確かめ、契約に反映します。
- アクセス管理：権限の付与と削除、本番データの開発環境への持ち込み禁止
- 情報と障害対応：秘密情報の保管、脆弱性対応、ログ監視、バックアップ、事故連絡期限
- 委託管理：再委託の報告・承認、監査への協力
ソースコードや設計書のほか、テストコード、CI/CD設定、クラウドアカウントの保有者も決めます。
ドメイン、証明書、外部サービスの契約名義も対象になります。
開発会社のアカウントだけで運用していると、契約終了時に移行できないことがあります。このため、担当者や保守会社が変わる場合を想定し、引き継ぎ手順と費用を確認します。
CakePHPのシステム発注費用と保守費用の相場
CakePHPに限定した公的な価格統計はありません。そのため、以下の金額は、2025〜2026年の業務システム相場と公開案件の規模をもとにした予算検討用のレンジです。
実際の価格は、画面数や業務の複雑さ、連携数で変わります。さらに、移行データ、品質要件、納期、体制も影響します。そこで、特定の金額を正解とせず、同じ条件で複数社から見積もりを取ります。
初期開発費の規模別レンジ
初期費用は、画面数や連携範囲などの条件をそろえて、規模別に見ます。
- 小規模：社内管理、申請、予約システムは100万〜300万円程度です。
- 中規模：部門横断の顧客・販売・在庫・会員システムは500万〜1,500万円程度です。
- 大規模：複数拠点、高可用性、大量データ、複数連携、段階移行を含む場合、1,500万〜5,000万円超の可能性があります。
小規模の目安は、画面10〜20程度で、既存認証を使い、外部連携が少ない場合です。一方で、中規模の想定には権限、帳票、CSV/API連携、データ移行を含みます。
2026年7月公開のSIA株式会社の記事では、小規模ツールは100万〜300万円、中規模は500万〜1,000万円とされています。大規模は1,000万円〜数千万円以上です（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年）。
同記事の人月単価は60万〜200万円程度です（出典: SIA株式会社「システム開発の費用・相場【2026年版】」、2026年）。ただし、CakePHP案件にそのまま当てはまるとは限らず、見積もりを確認する物差しになります。
見積もりの内訳と工数
工程ごとの金額と工数を分けると、見積もりに何の作業が含まれるかを確認できます。
- 見積もり区分：要件定義、設計、実装、テスト、移行、インフラ、教育、リリース、保守への分割
- 要件定義：GeNEE記事では開発費全体の5〜10%が目安です。
- 工程別の例：要件定義150万円以上、設計200万円以上、実装300万円以上
- 公開事例：CakePHPでPOS数百台とAPI連携し、数千万件を集計・表示した案件です。
GeNEEの記事では、試験150万円以上、デプロイメント80万円以上も紹介されています。
前提が異なるため、固定価格ではありません。株式会社GeNEEの2026年4月更新記事（出典: 株式会社GeNEE「システム開発にかかる費用はどのくらい？」、2026年）の金額は、工程の抜け漏れを確かめる材料として使います。
同事例の開発規模は12人月とされています（出典: 株式会社IMT「PHP受託Webシステム開発」、2026年確認）。
SIAの単価を機械的に当てはめると、720万〜2,400万円の参考計算になります。これは公開情報からの推定です。このため、再設計やサーバー移転、テスト、保守、移行の範囲は、個別に確認します。
保守・インフラ費用と初期費用の分け方
保守範囲とクラウド利用料は、初期費用とは分けて、契約前に確かめます。
- 保守作業：障害・問い合わせ、ログ・バックアップ確認、脆弱性対応
- 更新作業：PHP・CakePHP更新、軽微な改修、監視、定例報告
- 保守費の目安：初期開発費の年10〜20%程度。24時間監視、高い復旧目標、頻繁な追加開発で上振れします。
- インフラ利用料：サーバー、DB、メール、ストレージ、監視、バックアップ等
保守範囲は明記し、「保守一式」での契約は避けます（出典: 株式会社GeNEEおよび業務システム相場資料、2026年）。
WAFやログ保管などの費用も対象です。
クラウド費用はアクセス量や保存量で変わるため、月額予算に加えて、想定ユーザー数、ピーク時のアクセス、バックアップ世代、データ保持期間を条件にします。
最後に、従量課金や更新費用も含めた総保有コストで比べます。
委託先の選定とCakePHPの見積もり比較で見るポイント
委託先は、CakePHPの実績数だけでなく、業務分析や移行の経験で評価します。API連携やセキュリティ、テスト、保守の経験も見ます。
サイトにCakePHPと書かれていても、担当者が5.xやPHP 8系を扱えるとは限りません。そのため、類似案件の課題や担当範囲、規模、体制、リリース後の保守、現在の対応可否を確かめます。
類似実績を課題で見る方法
まず、どの業務を何人が使い、どのデータ量や連携を扱ったかを聞きます。開発経験の有無も、その中で確かめます。
たとえば、顧客管理なら権限や重複データ、在庫管理なら引当や棚卸しの経験を確かめます。
予約ならキャンセルや同時受付、会員サービスなら認証や個人情報の扱いが判断材料になります。
既存システムの改修では、ソースコードから現状を読み解く力が重要です。
- 技術上の確認：古いプラグイン、独自認証、テスト不足
- 資料との差：設計書と実装、文字コード、バッチ処理
- データの状態：データ重複や移行時のリスク
課題と解決策を説明できるかを見ます。さらに、実績を示せない場合も、守秘義務の範囲で説明を求めます。
前提条件をそろえた見積もりの比較
金額を比べる前に、各社へ渡す条件と評価軸をそろえます。
- 共通の前提：各社に渡す同じRFP、画面一覧、移行範囲、テスト条件
- 見積もり内訳：工程別工数、担当ロール、単価、期間、成果物、前提、対象外作業、追加費用
- 提案と体制：理解度、質問、リスク指摘、担当経験、連絡方法、レビュー頻度、品質保証
- 契約とリスク：納品物や契約条件の比較と、移行・障害のリスクや代替案の説明の評価
要件定義や移行、性能テスト、管理画面、保守が抜けていると、後から費用が加わる可能性があります。
見積もりを比べる際は、不明点を残して安く見積もる会社より、移行や障害のリスクと代替案を示す会社の方が、最終費用を管理しやすい場合があります。
発注後の失敗を防ぐための意思決定
発注側に責任者がいない、現場の意見が割れる、決裁が遅れる、といった状況は進行を止める要因です。さらに、データ所有者やテスト担当者が決まっていない場合は、開発会社の作業が滞ります。
- 業務責任者：現場の業務内容の決定
- IT責任者と決裁者：技術判断と承認
- 受入テスト担当者：業務上の合格の確認
仕様変更の承認ルートも一本化します。そのうえで、すべての業務を一度に作るのではなく、効果とリスクの大きい業務から段階的に出します。
たとえば、顧客・受注の登録と検索を先に稼働させ、帳票や高度な分析を次の段階に回す方法があります。
認証、データモデル、権限、監査ログ、APIの境界は、後から作り直せないため、初期設計で検討します。
よくある質問
費用、技術選定、RFP、既存システムの移行、保守契約を確かめておくと、初回相談を具体的に進められます。
CakePHPのシステム開発は安くできますか？
ライセンス費用を抑えられても、要件定義、画面開発、移行、連携、テスト、保守の費用は必要です。
SaaSの活用や初回リリース範囲の絞り込み、既存資産の再利用によって、費用を抑えられる可能性があります。ただし、品質や安全管理を削ることは避けます。
RFPを作れない状態でも開発会社に相談できますか？
相談できます。業務課題と作業手順、利用者を書き出し、困りごとや希望時期、予算の考え方を添えれば、整理を始められます。
要件定義から支援できる会社に相談するのも一つの方法です。提案を比べる段階になったら、業務フローや機能一覧をそろえます。
最後に、連携先、移行対象、非機能要件、受入条件もまとめて、同じ前提で見積もれる状態に近づけます。
古いCakePHPのシステムを5.xへ移行できますか？
移行できる可能性はありますが、既存環境と移行作業を調べてから判断します。
- 現状調査：コード、PHP、プラグイン、認証、DB、テスト、外部連携の確認
- 互換性と運用：単なる置き換えではなく、API互換性、独自改修、テスト不足、データ移行、運用手順の確認
- 方式の比較：現状調査と移行方針の見積もり、段階移行と再構築の比較
まとめ
発注時はまず、何を作るかではなく、どの業務課題を誰がどのデータで解決するかを整理します。
発注側は、SaaS、パッケージ、CakePHPのスクラッチ開発、ハイブリッドを比べ、要件の確度と社内体制に合う形を選びます。
発注前にそろえる資料と確認事項
資料と見積もり条件をそろえると、委託先の提案と費用の妥当性を比べやすくなります。
- 要件資料：業務フロー、画面、権限、データ、連携、移行対象、非機能要件
- 運用と受入：受入テスト、希望スケジュール、保守方針
- 見積もり条件：工程、工数、体制、成果物、対象外作業、変更時の扱い、運用費用
金額の根拠とリスクを説明できる委託先を選ぶことで、品質と予算を守る助けになります。
最初の相談で伝える内容
初回相談では、CakePHPを使いたいという希望に加えて、業務と計画の条件を伝えます。
- 業務と利用者：現在の業務、解決したい問題、利用者数
- 既存環境：既存システム、連携先、移行の有無、延命か再構築か
- 計画と運用：希望時期、予算レンジ、リリース後の保守体制
延命か再構築か迷う場合は、現状調査から依頼し、移行リスクを洗い出したうえで発注計画を立てます。
▼全体ガイドの記事
・CakePHPのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。