「全部内製したいが人がいない。全部外注すると高いしブラックボックスになる」――中堅企業の開発体制は、この板挟みのなかで揺れています。 内製は知見が残るがコストと採用が重く、外注は速いが任せきりにすると中身が見えなくなります。前回の第24回で「採用かAIか」を5年スパンのコストで比較したのに続き、本記事では**「SIer・オフショア・内製の3つを、どう組み合わせるか」**という、もう一段上の体制設計を扱います。
連載「バイブコーディング危機」は、AIに自社システムを書かせる中堅企業の急増と、そこで起きるリスク（脆弱性・データ消失・属人化・法令違反など）、そして防衛策を整理してきました。本記事の第25回は、その締めくくりに近い「開発リソースの配分」というテーマです。AIコーディング支援も、ここでは3つのリソースに次ぐ「第4の選択肢」ではなく、3つのリソースそれぞれの中に組み込まれる道具として位置づけます。
本記事では、3つの開発リソースの特性、5つの業務領域×3リソースのマトリクス、コスト試算の考え方、現状から目指す姿への移行ロードマップ、リスク移転と契約の設計、陥りやすい失敗5パターンを、経済産業省のDXレポート・IPAのDX白書を一次ソースに整理します。結論を先に言えば、**「領域ごとに担い手を変え、止まると困るところは堅く、変化が速いところは内製で機動的に」**というのが、中堅企業のハイブリッド設計の基本方針です。
目次
なぜ「全部内製」も「全部外注」も失敗するのか
中堅企業がシステム開発体制を考えるとき、「内製にするか、外注にするか」という二択で議論が始まりがちです。しかし、どちらか一方に振り切ると、それぞれ別の問題が起きます。
「全部内製」の落とし穴
すべてを社内で開発しようとすると、前回の第24回で見たとおり、**人件費が重く、IT人材の構造的な不足（2030年に最大約79万人不足の試算）**のなかで必要な人材を採れない問題に直面します（経済産業省: IT人材需給に関する調査）。さらに、少人数の内製チームに業務が集中すると、特定の担当者しか触れないシステムが生まれ、退職時にブラックボックス化します（連載第8回参照）。
「全部外注」の落とし穴
逆にすべてを外注すると、コストが膨らむうえに、システムの中身が社内で把握できなくなり、ベンダーへの依存（ベンダーロックイン）が固定化します。経済産業省の「DXレポート」は、ベンダー任せの構造が、レガシーシステムの温存やDXの足かせになっていると繰り返し指摘してきました（経済産業省: DXレポート）。任せきりにすると、改修のたびに見積もりと納期に振り回され、自社のペースで事業を変えられなくなります。
だから「領域で分ける」
この板挟みを解く鍵が、「業務領域ごとに担い手を変える」ハイブリッド設計です。すべてを同じリソースでまかなおうとせず、領域の性質（止まると困るか、変化が速いか、専門性が要るか）に応じて、内製・SIer・オフショアを使い分けます。IPAの「DX白書」も、内製と外部活用を組み合わせた体制への移行を、DX推進の方向性として示しています（IPA: DX白書）。
要点：内製と外注は対立軸ではなく、配分の問題です。「どちらか」ではなく「どの領域を、どの割合で」と問い直すことが、中堅企業の体制設計の出発点になります。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
3つの開発リソースの特性を整理する
ハイブリッド設計の前提として、3つの開発リソースの特性を整理します。
内製（社内エンジニア・情シス）
-
強み：知見が社内に残る。業務理解が深く、変化に機動的に対応できる
-
弱み：採用と人件費が重い。少人数だと属人化しやすい
-
向いている領域：事業の中核で変化が速い領域、競争力の源泉になる領域
SIer（国内システムインテグレーター）
-
強み：実績と体制があり、品質・法令準拠・保守の安定性が高い。大規模・基幹系に強い
-
弱み：コストが高い。スピードは内製に劣ることがある。任せきりだとロックインに
-
向いている領域：止まると困る基幹システム、高い信頼性・コンプライアンスが必要な領域
オフショア（海外開発委託）
-
強み：コストを抑えやすい。一定規模の開発力を確保しやすい
-
弱み：コミュニケーション・品質管理・時差・言語の壁。仕様伝達の精度が成否を分ける
-
向いている領域：仕様が明確で量産的な開発、検証・テスト工程の一部
| リソース | コスト | スピード | 品質安定性 | 知見の社内蓄積 |
|---|---|---|---|---|
| 内製 | 高（固定費） | 高 | 人材次第 | 高 |
| SIer | 高 | 中 | 高 | 低〜中 |
| オフショア | 低〜中 | 中 | 管理体制次第 | 低 |
この表のとおり、1つのリソースで全条件を満たすものはありません。だからこそ、領域ごとの使い分けが必要になります。
5つの業務領域 × 3リソースのマトリクス
中堅企業のシステムを、性質の異なる5つの業務領域に分け、それぞれに適したリソースを割り当てます。以下は典型的な配分例で、自社の事業特性に合わせて調整してください。
領域1：基幹システム（会計・販売・在庫など）
止まると事業が止まる領域です。SIerまたは信頼できる専門ベンダーを主軸にし、内製は窓口・要件定義・保守調整を担います。連載第4回で扱った江崎グリコの事例のように、基幹システムの停止は財務インパクトが甚大なため、安さより信頼性を優先します。
領域2：顧客向けサービス（自社プロダクト・ECなど）
事業の競争力に直結し、変化が速い領域です。内製を主軸にし、足りない開発力をオフショアやSIerで補います。ここを外注に丸投げすると、改修のたびにスピードが落ち、競争力を失います。
領域3：社内業務効率化ツール
影響範囲が限定的で、失敗してもやり直せる領域です。内製（社員＋AI活用）を主軸に、速く回します。AIコーディング支援が最も効果を発揮する領域でもあります。
領域4：保守・運用・定型開発
仕様が明確で量産的な作業です。オフショアやSIerの保守契約を活用し、内製の手を空けます。ただし、本連載で見たセキュリティ・ログ・バックアップの観点（第9回・第11回・第21回）を委託先にも適用させます。
領域5：セキュリティ・ガバナンス設計
専門性が高く、AIや一般的な外注では代替しにくい領域です。外部CTO・セキュリティ顧問（連載第14回）を活用し、内製チームと協働します。認可・認証・監査の設計は、ここに含まれます。
| 業務領域 | 主軸リソース | 補完リソース | AI活用の度合い |
|---|---|---|---|
| 基幹システム | SIer・専門ベンダー | 内製（要件・調整） | 低 |
| 顧客向けサービス | 内製 | オフショア・SIer | 中 |
| 社内効率化ツール | 内製＋AI | ― | 高 |
| 保守・定型開発 | オフショア・SIer | 内製（監督） | 中 |
| セキュリティ設計 | 外部顧問 | 内製 | 低 |
このマトリクスの考え方は、「止まると困る領域は堅く、変化が速い領域は機動的に、専門性が要る領域は専門家に」という、シンプルな原則に集約されます。
AI活用は「リソースの中」に組み込む
ここで重要なのは、AIコーディング支援を「内製・SIer・オフショアに次ぐ第4のリソース」と考えないことです。AIは、3つのリソースそれぞれが使う道具として組み込みます。
内製でのAI活用
社内エンジニアや情シスがAIを使い、社内効率化ツールや試作を速く回します。前回見たGitHubの研究が示す約55%の速度向上は、おもにこの領域で効きます。ただし、生成物の検査（連載第11回）とCI/CDのガバナンス（連載第12回）は必須です。
SIer・オフショアでのAI活用
委託先がAIを使う場合、「AI生成コードをどう検査し、誰が品質に責任を持つか」を契約で明確にする必要があります。委託したからといって、AIの脆弱性リスク（本連載で繰り返し見たとおり）が消えるわけではありません。むしろ、外部が作ったAI生成コードこそ、受け入れ時の検査を徹底すべきです。
AIを「どこで使うか」も配分の一部
AI活用の度合いは、領域によって変えます。失敗してよい社内ツールでは積極的に、止まると困る基幹システムやセキュリティ設計では慎重に。AIをどこに、どこまで使うかも、ハイブリッド設計の一部として設計します。
要点：AIは万能の代替リソースではなく、各担い手が使う道具です。「誰が使い、誰が検査し、誰が責任を持つか」を領域ごとに決めることが、AI活用を安全に組み込む条件になります。
コスト試算の考え方
ハイブリッド設計のコストは、領域ごとの配分で大きく変わります。ここでは、金額そのものより「試算の考え方」を示します。
固定費と変動費を分けて考える
-
内製：人件費は固定費。稼働の有無にかかわらず発生します
-
SIer・オフショア：プロジェクト単位・保守契約は変動費にしやすい
中堅企業は、事業の波に合わせて変動費の比率を調整できるよう、内製（固定費）を「止めたくない中核」に絞り、外注（変動費）で繁閑を吸収する設計が向きます。
「安く見える」オフショアの隠れコスト
オフショアは単価が安く見えますが、仕様伝達・品質管理・手戻りのコストが隠れています。仕様が曖昧なまま委託すると、安かったはずが手戻りで割高になります。仕様を明確にできる領域（保守・定型開発）に限定するのが、コストを読みやすくするコツです。
5年スパンで比べる
前回の第24回と同じく、初期費用ではなく5年スパンの総コストで比べます。内製は固定費が重いものの知見が残り、外注は安く見えてもロックインや手戻りで膨らむことがあります。コストだけでなく「5年後に自社に何が残るか」を併せて評価してください。
移行ロードマップ（12〜18ヶ月）
現状が「全部外注」または「属人的な内製」に偏っている場合、ハイブリッド体制への移行は段階的に進めます。
フェーズ1（〜3ヶ月）：現状の棚卸し
まず、自社のシステムを5つの業務領域に分類し、いまそれぞれを誰が担っているか、ドキュメントはあるか、止まると困る度合いはどれくらいかを棚卸しします。連載第23回（IT棚卸し）の手法がそのまま使えます。シャドーIT（把握されていないシステム）もここで洗い出します。
フェーズ2（〜6ヶ月）：中核領域の内製化準備
事業の競争力に直結する領域（顧客向けサービスなど）を特定し、内製の核となる人材（採用1名＋外部CTO顧問）を確保します。同時に、外注している中核領域のドキュメントとソースコードを社内に引き取り、ロックインを緩めます。
フェーズ3（〜12ヶ月）：領域ごとの配分実行
マトリクスに沿って、領域ごとに担い手を再配置します。基幹はSIer・専門ベンダー、保守はオフショア・SIer、社内ツールは内製＋AI、セキュリティは外部顧問へ。一度に全部を動かさず、影響の小さい領域から順に移します。
フェーズ4（〜18ヶ月）：ガバナンスの定着
CI/CD・セキュリティスキャン・ログ監査・認可設計（連載第3回・第11回・第12回・第21回）を、内製・外注を問わず全領域に適用します。委託先にも同じ基準を求める契約に更新します。
| フェーズ | 期間 | 主な作業 |
|---|---|---|
| 1. 棚卸し | 〜3ヶ月 | 5領域に分類・現状把握・シャドーIT発見 |
| 2. 中核準備 | 〜6ヶ月 | 内製の核確保・ロックイン緩和 |
| 3. 配分実行 | 〜12ヶ月 | 領域ごとに担い手を再配置 |
| 4. 定着 | 〜18ヶ月 | 全領域にガバナンス適用 |
リスク移転と契約の設計
ハイブリッド体制では、複数の担い手が関わるため、「誰が何に責任を持つか」を契約で明確にすることが、リスク管理の要になります。
委託契約に必ず入れたい4項目
-
品質基準と検査責任：AI生成コードを含め、納品物をどう検査し、誰が品質に責任を持つか
-
ソースコードとドキュメントの帰属：成果物が自社に帰属し、引き継ぎ可能な状態で納品されること（ロックイン防止）
-
セキュリティ要件：本連載で扱ったスキャン・ログ・認可・バックアップの基準を委託先にも適用すること
-
インシデント時の責任分担：事故が起きたときの連絡・対応・賠償の取り決め
「丸投げ」を避ける運用
契約を結んでも、丸投げにすると中身が見えなくなります。内製チームが各委託先の窓口・監督を担い、定例で進捗と品質を確認する運用が前提です。これは、内製の核を「開発者」だけでなく「外部を束ねる司令塔」として位置づける考え方でもあります。
法令準拠の責任は最終的に自社にある
外注したからといって、電子帳簿保存法・特商法・個人情報保護法などの法令準拠の責任（連載第7回参照）が委託先に移るわけではありません。最終的な法的責任は発注した自社にあることを前提に、委託先の成果物が法令に適合しているかを自社で確認する体制が必要です。
陥りやすい失敗5パターン
ハイブリッド体制の設計・運用で、中堅企業が陥りやすい失敗を5つ挙げます。
1. 領域を分けずに同じリソースに丸投げする
「とりあえず1社に全部」とすると、得意・不得意を無視した配分になり、コストと品質の両方で損をします。領域ごとに担い手を変えるのが基本です。
2. 中核領域を外注に出してしまう
事業の競争力に直結する領域を外注すると、改修のたびにスピードが落ち、競争力を失います。中核は内製で握るのが原則です。
3. オフショアに曖昧な仕様で委託する
仕様が曖昧なまま安さだけでオフショアに出すと、手戻りで割高になります。オフショアは仕様が明確な領域に限定します。
4. 委託先のAI生成コードを検査しない
「プロに任せたから大丈夫」と検査を省くと、外部が作ったAI生成コードの脆弱性をそのまま受け入れることになります。受け入れ検査を契約に入れます。
5. 窓口・監督を置かずに丸投げする
契約だけ結んで監督を置かないと、中身が見えなくなりロックインが進みます。内製チームを司令塔として配置します。
実務判断のポイント
この記事を読むべきなのは、経営者、情シス、業務責任者、発注担当です。単に情報を把握するだけでなく、要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。SIer × オフショア × 内製 ハイブリッド設計 2026｜中堅100〜1,000名企業の最適配分と移行ロードマップ｜バイブコーディング危機 第25回に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOが提供できる価値は、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる。 ことです。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問（FAQ 10問）
Q1. 内製と外注、結局どちらを主軸にすべきでしょうか？
A. 領域によって変えるのが答えです。事業の競争力に直結し変化が速い領域は内製、止まると困る基幹は信頼できるSIer・ベンダー、仕様が明確な保守はオフショア、というように使い分けてください。
Q2. 情シスが1〜3名しかいません。それでもハイブリッドは可能でしょうか？
A. 可能です。むしろ少人数だからこそ、内製を中核領域に絞り、それ以外を外注で補うハイブリッドが有効です。内製チームは「開発者」兼「外部を束ねる司令塔」として位置づけます。
Q3. オフショアは品質が不安です。どう管理すればよいでしょうか？
A. 仕様を明確にできる領域（保守・定型開発・テスト）に限定し、品質基準と検査責任を契約に明記してください。仕様が曖昧なまま委託すると、安さが手戻りで相殺されます。
Q4. ベンダーロックインを避けるにはどうすればよいでしょうか？
A. ソースコードとドキュメントが自社に帰属し、引き継ぎ可能な状態で納品される契約にすること、内製チームが窓口・監督を担うこと、中核領域を外注に丸投げしないことが基本です。
Q5. AI活用は、内製・外注のどちらで使うべきでしょうか？
A. AIは特定のリソースに紐づくものではなく、各担い手が使う道具です。失敗してよい社内ツールでは積極的に、止まると困る基幹やセキュリティ設計では慎重に、と領域ごとに度合いを変えてください。
Q6. 委託先がAIでコードを書いた場合、品質は誰の責任でしょうか？
A. 契約で明確にすべき事項です。受け入れ時の検査責任を発注側・受注側のどちらが持つかを定め、外部が作ったAI生成コードこそ、納品時のスキャン・レビューを徹底してください。
Q7. 移行にはどのくらい時間がかかりますか？
A. 現状の偏りや規模によりますが、棚卸しから定着まで12〜18ヶ月を目安に、影響の小さい領域から段階的に進めるのが現実的です。一度に全部を動かすと混乱します。
Q8. コストはハイブリッドにすると上がりませんか？
A. 単純な合計では複雑に見えますが、内製（固定費）を中核に絞り、外注（変動費）で繁閑を吸収する設計にすれば、事業の波に合わせてコストを調整しやすくなります。5年スパンで比較してください。
Q9. 外注に出せば、法令準拠の責任も移せますか？
A. いいえ。電子帳簿保存法・特商法・個人情報保護法などの最終的な責任は、発注した自社にあります。委託先の成果物が法令に適合しているかを自社で確認する体制が必要です（連載第7回参照）。
Q10. まず何から始めればよいでしょうか？
A. 自社のシステムを5つの業務領域に分類し、いまそれぞれを誰が担っているかを棚卸しすることから始めてください（連載第23回の手法が使えます）。現状が見えれば、どの領域をどう再配置すべきかが判断できます。
参考一次ソース
まとめ
-
「全部内製」も「全部外注」も別々の問題を生みます。内製は人材難と属人化、外注はコストとベンダーロックインです
-
内製・SIer・オフショアは、それぞれコスト・スピード・品質・知見蓄積の特性が異なり、1つで全条件を満たすものはありません
-
5つの業務領域（基幹／顧客向け／社内ツール／保守／セキュリティ）ごとに担い手を変えるのがハイブリッド設計の基本です
-
AIは第4のリソースではなく、各担い手が使う道具として、領域ごとに度合いを変えて組み込みます
-
コストは5年スパンで、内製（固定費）を中核に絞り、外注（変動費）で繁閑を吸収する設計が中堅企業に向きます
-
移行は棚卸し → 中核準備 → 配分実行 → 定着の12〜18ヶ月で、影響の小さい領域から段階的に進めます
-
契約には品質基準・成果物帰属・セキュリティ要件・責任分担を入れ、丸投げを避けて内製チームが司令塔を担います。法令準拠の最終責任は発注側にあります
「どちらか」ではなく「どの領域を、誰に、どの割合で」。この問い方が、限られた人材と予算のなかで、中堅企業がスピードと安定性を両立する体制を作る鍵になります。
開発体制のハイブリッド設計を相談したい方へ
GXOのバイブコーディング監査 + 開発体制（内製・外注）設計支援サービスでは、中堅企業向けに次のようなご相談を承っています。
-
業務領域の棚卸しと分類：自社システムを5領域に整理し、現状の担い手とリスクを可視化
-
ハイブリッド配分の設計：領域ごとの内製・SIer・オフショア・AI活用の最適配分
-
移行ロードマップの策定：12〜18ヶ月の段階的な体制移行計画
-
委託契約のレビュー：品質基準・成果物帰属・セキュリティ要件・責任分担の整備
-
AI活用ガバナンスの組み込み：各領域でのAI利用ルールと受け入れ検査の設計
関連記事
著者: GXO株式会社 初回公開: 2026 年 6 月 14 日 最終更新: 2026 年 6 月 14 日 連載: バイブコーディング危機 第 25 回（全 30 回予定 / 第 5 週・経営判断編）
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
