開発方針を相談する

AI 内製・外注・ハイブリッド開発、どれを選ぶべきか

AI で内製できる範囲は広がった。だが、すべてを内製すべきとは限らない。

この記事の結論

「AI で内製できるなら、外注の必要なくないですか」

ここ最近、min's にも届く質問です。半分その通りで、半分そうではない、というのが現場の答えです。

OpenAI が公開している企業利用分析では、AI 活用が「進んでいる」企業の差は、利用回数より 「どれだけ複雑な仕事に使えているか」という深さの差 から生まれている、とされています (How frontier firms are pulling ahead / OpenAI)。つまり、AI を渡しただけで成果が出るわけではなく、活用の深さが分かれ目になります。

この記事では、内製・外注・ハイブリッドを選ぶ判断軸を、事業フェーズと体制の両面から、移行ロードマップと契約形態の選択肢まで含めて整理します。

AI で内製できるようになった領域

AI ツールが揃った現在、社内の少人数チームでも対応できるようになった領域があります。

OpenAI も Codex の活用が、「コードを書く職」を超えてアナリスト・マーケター・コーポレートファイナンスといった非エンジニアの仕事にまで広がっている事例を公開しています (Codex for every role, tool, and workflow / OpenAI)。コードを書く能力 = 専門職、という時代ではなくなりました。

「内製できる」と「内製すべき」は別

ここで注意したいのは、「内製できる」と「内製すべき」は別問題 だということです。AI で内製可能になっても、

を考えると、内製しないほうが安いケースも残ります。

外注が向く領域

一方で、AI で内製できるようになっても、外注のほうが安く確実な領域も残っています。

これらは「AI で速く書ける」というよりも、判断と設計に経験値が必要 な領域です。一度しか起きないことが多いので、社内で経験を蓄積するより、頻繁に経験している外部に任せた方が結果的に安い。

ハイブリッドが向いているケース

実際に多いのは、内製と外注を組み合わせるハイブリッド型です。Anthropic が公開している AI ネイティブ・エンジニアリング組織の解説でも、PdM がコードを書き、エンジニアが設計や顧客接点まで担うなど、役割の境界が溶けつつある 変化が紹介されています (Running an AI-native engineering org / Anthropic)。

ハイブリッドの典型的な分担は以下のとおりです。

領域内製外注
顧客接点 (Web 画面、業務画面)◎△
認証・テナント・権限△◎
決済・課金△◎
データ基盤・分析○○
AI 機能の設計・実装△◎
インフラ・デプロイ△○
軽微な改修・運用◎△
大きな機能追加△○
セキュリティレビュー△◎
緊急対応 (障害・脆弱性)○◎

ハイブリッドの典型的な 3 パターン

パターン A: 顧客接点 + 軽微改修を内製、専門領域だけ外注

最も多いパターン。事業を成長させながら、コアでない領域を外部に任せて速度を保ちます。

パターン B: コアを内製、補完を外注

PMF 後、内製比率を上げていくフェーズで増えてくるパターン。

パターン C: 全て外注、技術顧問だけ常駐

社内に開発者を置かない方針の事業会社で見られるパターン。社内には判断軸を持つ顧問だけ置き、実装は外部に任せます。

6 軸での判断基準

内製・外注・ハイブリッドの判断は、以下の 6 軸で考えます。

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

特に 「採用余地」と「改修頻度」 は経営判断に直結します。

採用と教育の現実コスト

「内製すれば安い」と思いがちですが、採用と教育のコスト を見落とすと判断を誤ります。

これらを織り込むと、開発者 1 人を雇うのは年間 1,000〜1,500 万円程度の総コスト感です。外注で年 1,000 万円使うのと、ほぼ同水準。「内製の方が圧倒的に安い」というのは、フルタイムで稼働させ続けられる前提でしか成立しません。

事業フェーズ別の体制

事業フェーズによって、内製と外注の比率は変わっていきます。

フェーズ推奨体制理由
構想〜MVP外注 7 : 内製 3スピード優先、専門領域は丸投げで OK
初期顧客に提供開始外注 5 : 内製 5軽微な改修を内製化、重要パスは外注継続
継続課金・複数社運用外注 4 : 内製 6改善頻度が上がるため内製比率を上げる
複数拠点・全社展開外注 3 : 内製 7内製化、特殊領域だけ外注に残す
安定運用フェーズ外注 2 : 内製 8内製主体、技術顧問やセキュリティだけ外注

内製化シフトのトリガー

「いつ内製にシフトするか」の判断は、以下のいずれかが目安です。

  1. 売上規模: 開発者 2〜3 人を継続雇用できるレベル (年売上 3〜5 億円が目安)
  2. 改修頻度: 軽微改修を週 1 回以上のペースで入れたい
  3. 業務知識の優位性: 内製しないと再現できない競争優位がある
  4. 採用余地: 既に応募者が来ている、または採用できる体制がある
  5. 既存システムの規模: 1 人の理解で回らないコードベースになった

このうち 2 つ以上が当てはまったら、内製化を検討する段階です。

事業上の被害: 早すぎる内製化は、採用コストと教育コストで開発スピードを失います。遅すぎる内製化は、改善速度が落ち、競合に追いつかれます。

ここまでで「自社はどのフェーズか」「どの領域を内製・外注で分けるか」が見えてきたら、次は具体的な体制設計に入ります。min's では、開発体制の壁打ちも受けています。

開発体制の設計を相談する →

契約形態の選択肢

ハイブリッドで外注を使うときの契約形態を整理します。

形態性質向く案件
請負契約成果物単位仕様が明確で、完成判定がしやすい案件
準委任契約役務単位仕様変更が前提のスタートアップ、改善フェーズ
時間単価 (タイムマテリアル)工数 × 時間スコープが流動的、技術顧問契約
月額固定 (Retainer)月額契約、稼働範囲指定継続的な改善、保守
緊急対応契約スポット障害対応、緊急の脆弱性修正

ハイブリッド体制では、複数の契約を組み合わせるのが現実的です。たとえば:

このように分けると、「必要なときだけ必要な専門領域を使う」 ことができます。

min's が支援する 3 つのパターン

min's では、内製・外注・ハイブリッドのどのパターンでも支援できる設計を取っています。

パターン 1: 全外注 (MVP 〜 初期顧客)

構想から本番リリース、運用までフル支援。社内エンジニアが不在 or 確保できない場合に向きます。

パターン 2: ハイブリッド支援 (継続課金フェーズ)

社内エンジニアと並走しながら、認証・決済・AI 機能など専門領域だけ min's が担当。週次でレビューと意思決定。

パターン 3: 技術顧問・スポット (内製主体フェーズ)

社内チームが主体で、min's は月数回のレビュー、アーキテクチャ判断、難所のスポット実装だけを担当。

このパターンの間を、事業フェーズに応じて移動していくのが現実的な進め方です。

体制移行のロードマップ例

ハイブリッド体制から内製化を進めるときのロードマップ例を整理します。

Step 1 (現状): 外注 7 : 内製 3 — MVP 期

Step 2: 外注 5 : 内製 5 — 初期顧客提供

Step 3: 外注 4 : 内製 6 — 継続課金期

Step 4: 外注 2 : 内製 8 — 安定運用期

これは一例で、事業特性によって変わります。重要なのは 「段階的に内製化する」「外注の役割を変えていく」 という発想です。

自社の開発体制について相談したい方へ

min's では、開発体制の設計・壁打ち、フェーズ移行のロードマップ作成を支援しています。

以下のような状態であれば、ご相談ください。

体制設計だけのスポット相談も可能です。

次に読む記事

参考

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

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

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