開発方針を相談する

AI 時代の開発外注ガイド：安く早く作る前に決めるべきこと

AI で実装は速くなった。だからこそ、発注前の設計責任と運用責任が成功率を決める。

この記事の結論

「AI が書くから、開発外注はもっと安くなりますよね」

ここ 1 年で、min's への問い合わせで最も増えた質問です。半分は当たっていて、半分は外れている、というのが率直な答えです。

Cursor、Claude Code、Codex のような AI コーディングツールによって、実装そのもの の時間は確かに圧縮されました。要件が明確で、画面と API の境界が決まっていて、テストの判断軸が言語化されていれば、過去より少ない工数で形になる、という体感です。

一方で、「何を作るか」「誰が使うか」「リリース後に誰が運用するか」 を決める作業は、AI では短縮できません。むしろ、実装が速くなった分、ここの精度の差がプロジェクトの成否に直結するようになりました。

この記事では、これからシステム開発を外注する経営者・事業責任者の方に向けて、AI 時代の開発外注で押さえるべきポイントを、発注前・選定・契約・運用の 4 段階で整理します。受託会社側の視点も含めて書いているので、「どの段階でどこまで自社が決めるべきか」の目安にしてください。

AI で外注のコスト構造は実際どう変わったか

OpenAI が公開している企業利用分析では、AI 活用が「進んでいる」企業と「典型的な」企業の差は、利用回数 (メッセージ数) で説明できる部分は約 36% にすぎず、残りは 「どれだけ複雑な仕事に使えているか」という深さの差 から生まれている、と報告されています (How frontier firms are pulling ahead / OpenAI)。

これは外注開発でも同じ構造です。AI を入れた開発会社が安くなるかは、

によって大きく変わります。後者の体制を持っている会社では、見積もり時の工数感が下がりやすい。一方で、「AI を使っています」と言いつつ、レビューも品質保証も従来通りの会社では、単価は変わらないこともあります。

発注側から見て本当に重要なのは、「自社の発注内容のどの部分が、AI で安くなるはずなのか」を把握しておくこと です。

工程AI で短縮できる度合い備考
要件整理△AI は壁打ち相手にはなるが、業務知識と意思決定は人間
画面設計・ワイヤー○プロトタイプ生成は速い。最終判断は人間
API・データ設計△たたき台は出る。境界と整合性は人間
実装 (フロント)◎大幅に短縮
実装 (バックエンド)○〜◎ドメインがクリアなら大きく短縮
テスト記述○観点抽出は AI、判断は人間
セキュリティ・権限△レビュー補助には使えるが、最終判断は人間
インフラ・デプロイ△テンプレート活用は進むが、運用判断は人間
運用・障害対応△ログ調査の補助、根本解決は人間

「AI で全部安くなる」という期待を持って発注すると、人間の判断が必要な部分の工数を「乗せられている」と感じてしまう ことがあります。実際にはそこに費用が乗っているのが正常で、AI 部分だけ計上されている見積もりの方が、後から人間の判断工程が漏れていたと気づくケースが多くあります。

発注前に決めておく 7 項目

開発会社に相談する前に、自社で揃えておくと見積もり精度が大きく上がる項目を 7 つ整理します。完璧な要件定義書である必要はありません。1 枚にまとまっていれば、相談の質が変わります。

1. 目的: なぜ作るのか

「何を作りたいか」ではなく「なぜ作りたいか」を 1 段落で言語化します。たとえば、

目的が決まっていると、発注先から「もっと安い代替案 (既存 SaaS、Excel + 自動化、AI ツール) でも実現できる」という提案を受けやすくなります。

決めずに進めたときに起きること: 依頼された機能を依頼通りに作るだけになり、的を外したまま完成して使われなくなります。

2. ユーザー: 誰が使うのか

具体的な役割と、その人の日常業務までイメージを揃えます。

ユーザー像が違うと、必要な機能・UI・端末・通知方法がすべて変わります。

決めずに進めたときに起きること: 何度も作り直しが発生し、リリース後に「現場が触らない」状態になります。

3. 業務フロー: いま、どう回しているか

「業務フローを書いてください」と言われて綺麗な図にする必要はありません。

このレベルでよいので、現状を正直に共有する ことが重要です。

決めずに進めたときに起きること: 綺麗に見える要件で発注しても、現場の実態と乖離した設計になり、システムが Excel に戻ります。

4. 画面と機能の優先順位

最初から全機能を入れる必要はありません。

この 4 段階で 1 ページのリストにしておくと、見積もりが「あれもこれも」にならず、段階リリースの計画が立てやすくなります。

決めずに進めたときに起きること: 必要のない機能まで実装され、予算と納期を両方圧迫します。

5. データ: 何を持つか

最低限、「主要なデータ (顧客、注文、商品、予約 …) はどんな項目を持つか」を 1 枚にまとめます。

これがあると、データベース設計に入ったあとの議論が大幅に速くなります。完璧でなくてかまいません。

決めずに進めたときに起きること: 設計途中でデータモデルを変えることになり、既に書いた API・画面・テストすべてに手戻りが入ります。

6. 権限: 誰が何を見られるか

これが一番見落とされがちで、後から効いてきます。

権限を「あとから入れる」のは、ゼロから入れるよりかなり手間のかかる作業になります。発注前に最低限、「役割と見える範囲のマトリクス」を作っておくことを強く勧めます。

決めずに進めたときに起きること: 担当者が触ってはいけない情報を編集できる状態になり、最悪の場合は情報漏えいにつながります。

7. リリース後の運用責任

実は最も忘れられがちな項目です。

これを発注前に決めておかないと、「リリースされたあと、誰が面倒を見るのか」が宙に浮きます。OpenAI が AWS との提携で強調していたのも、エンタープライズで AI 導入が広がるためには「既存のセキュリティ・コンプライアンス・調達・課金・ガバナンスのワークフロー」に乗ることが鍵だ、というポイントでした (OpenAI frontier models and Codex on AWS / OpenAI)。これは外注開発でも同じで、既存の運用体制と整合させて初めて、システムが回り続けます。

決めずに進めたときに起きること: リリース当日にバグが出ても誰も対応せず、顧客対応とシステム改修が両方止まります。

ここまでの 7 項目を揃えるのは、慣れていないと時間がかかります。全部揃ってから相談する必要はありません。 目的とユーザーだけ書いて、残りは相談しながら整理する形で問題ありません。

1 枚設計書のたたき台を一緒に作る相談をする →

見積もり前に用意するとよい資料

発注前のヒアリングを経て見積もり依頼に進むときに、揃えておくと精度が上がる資料を整理します。すべて必要ではありませんが、揃っているほど見積もりのブレが小さくなります。

資料用途
7 項目を 1 〜 2 枚にまとめたもの (1 枚設計書)全体の方向性合わせ
既存業務の画面キャプチャや書類のサンプル現状の課題を共有
既に使っている SaaS の一覧既存システムとの連携範囲を確認
想定する予算レンジ (上下幅は広くてよい)スコープ調整の判断材料
希望リリース時期と、絶対動かせない締め日工程設計と優先順位
社内で開発に関われる人 (PM、現場ヒアリング、テスト)役割分担の確認

「予算は言わない方が高くならないか」と聞かれることがありますが、AI 時代の開発では 「予算レンジを伝えて、その中でできる最大の構成を提案させる」方が、最終的な品質は上がります。 上限が決まっていれば、削るべき機能、手運用で代替する部分、後回しにする機能を、外注先が一緒に整理できます。

内製・外注・ハイブリッドの判断軸

AI で内製のハードルは下がりました。ただし、すべてを内製すべきかというと、現場の感覚では「条件次第」というのが正直なところです。

軸内製が向く外注が向く
業務知識自社が圧倒的に詳しい開発側に蓄積がある領域
改修頻度毎週変更が走る数ヶ月単位で安定
技術領域既存のスキルセットで足りる専門領域 (決済、認証、AI)
体制開発者 2〜3 人を確保できる確保が難しい
セキュリティ業務固有の判断が必要業界標準で十分
採用余地採用できる、または社内で育てられる採用しない方針

実際に多いのは ハイブリッド型 です。

OpenAI のワークスペースエージェントは、「組織が定めた権限の範囲内で、複数人が共有して使える AI エージェント」として設計されています (Introducing workspace agents in ChatGPT / OpenAI)。これは内製・外注を問わず、業務システムを設計するときに「誰が、どこまでの権限で、何を実行できるか」を最初から決めておく という方向に、業界全体が向かっていることの表れでもあります。発注前の体制設計でも、この観点はそのまま使えます。

失敗しない開発会社の使い方

発注後、開発会社を「下請け」として扱うか、「事業パートナー」として扱うかで、成果が大きく変わります。AI 時代に特に重要になっているのは以下の 4 点です。

1. 意思決定の窓口を 1 人決める

複数の関係者から、それぞれ別の優先順位が降ってくる開発は、確実に炎上します。社内で「最終判断する人」を 1 人決め、開発会社にもその窓口を伝える。週次の意思決定をその窓口に集約します。

2. 隔週で「実物」を見るレビューを入れる

進捗報告書ではなく、動いている画面 を見るレビューを 2 週間に 1 回入れます。「いま手元で何ができるか」を画面で見ると、認識のズレがその場で発覚します。動かない理由を聞くのではなく、動くものを見せてもらう、を徹底するのがコツです。

3. 「決めていないこと」を明示する

要件で決まっていないことを、「曖昧なまま開発会社に判断してもらう」と、後で必ず揉めます。決まっていないことを リストにして、誰が、いつまでに、どう決めるか を週次で更新する。これだけで遅延の原因が大幅に減ります。

4. リリース日ではなく、リリース後 30 日に予算を残す

最初の 1 ヶ月は、想定外の不具合と改善要望が出ます。リリースで予算を使い切る計画にしていると、運用に入った瞬間に止まります。全体予算の 15〜25% は、リリース後 30〜90 日のための予備に取っておく のが現場の経験則です。

契約形態と権利関係の基本

最低限押さえておくべき契約形態は以下のとおりです。

契約形態性質向く案件
請負契約成果物の納品に対して支払う仕様が明確で、完成判定がしやすい案件
準委任契約役務の提供に対して支払う仕様変更が前提のスタートアップ案件、改善フェーズ
時間単価 (タイムマテリアル)工数単価 × 時間スコープが流動的な開発、技術顧問契約

スタートアップや新規事業では、要件が動くため 準委任 または 時間単価 をベースに、フェーズごとに契約を切り直す形が現実的です。「請負で固定金額」にすると、要件変更のたびに「追加発注」が発生し、結果として高くつくことが多くあります。

知的財産権の扱いは、契約書で明確にしておきます。

ここを曖昧にしたまま進めると、開発会社を変えるとき、または社内で改修したいときに、必ず詰まります。

まずは「1 枚設計書」と「30 分の相談」から

ここまで読んで「準備が大変そう」と感じた方も多いと思います。実際に、全部揃えてから相談する必要はありません。むしろ揃えすぎると、外注先からの提案の幅が狭まります。

min's では、開発外注を検討している方向けに、30 分の無料相談 を行っています。準備していただきたいのは以下の 3 点だけです。

実現可能性、概算費用、AI で短縮できる範囲、内製と外注の使い分けまで、30 分で整理します。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発を

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。

開発方針を相談する概算見積もりを依頼する