はじめに：なぜ今、この比較が必要なのか
「オフショア開発は本当に費用対効果がいいのか」
この問いは、長い間「人件費が安い＝お得」という図式で語られてきました。確かに、ベトナム・フィリピンなどの人月単価は日本の約半分、フィリピンでは3分の1程度です。ただし、かつて言われていた「1/3〜1/5」というコスト差は、円安や現地の人件費高騰により縮小しています。インドや中国に至っては、日本とほぼ同等かそれ以上になるケースも増えています。
しかし2025-2026年を境に、状況が変わりました。
GitHub Copilot、Cursor、Claude Code、DevinといったAI駆動開発ツールが実用レベルに達し、「少数精鋭の生産性を上げる」という選択肢が現実的になったのです。
つまり、開発リソースの選択肢として：
- オフショア開発：安価な人的リソースを海外に求める
- AI駆動開発：AIツールで少数精鋭の生産性を上げる
どちらも「開発コストを下げたい」「リソース不足を補いたい」という同じ課題への解です。であれば、比較する意味がある。
本記事では、6つの代表的なパターンでシミュレーションを行い、どの状況でどちらが優勢かを分析します。最終的にどちらかに偏る結果になったとしても、それはシミュレーションの結果として受け入れます。
[📦 商品リンク: moshimo-card-pc0As]
[📦 商品リンク: moshimo-card-HD5Yl]
比較フレームワークの設計
状況を分ける変数
| 変数 | 選択肢 |
|---|---|
| プロジェクト規模 | 小（1-3人月）・中（10-30人月）・大（100人月〜） |
| 仕様の安定性 | 明確・固定 / 曖昧・変動的 |
| ドメイン知識 | 汎用的（EC、CRMなど）/ 専門的（医療、金融規制など） |
| 技術スタック | メジャー / ニッチ |
| 期間 | 短期（〜3ヶ月）/ 長期（1年〜） |
| 国内チームの状況 | 高スキル少数 / 中スキル / リソース自体が不足 |
評価軸
- 総コスト
- 開発スピード
- 品質・バグ率
- 仕様変更への対応力
- リスク（失敗確率・最悪ケース）
- ナレッジの内部蓄積
代表的な6パターン
| # | パターン名 | 規模 | 仕様 | ドメイン | 技術 | 期間 | 国内チーム |
|---|---|---|---|---|---|---|---|
| A | スタートアップMVP | 小 | 変動 | 汎用 | メジャー | 短期 | 高スキル少数 |
| B | 中規模Webサービス新規 | 中 | やや変動 | 汎用 | メジャー | 中期 | 中スキル |
| C | 大企業の基幹システム刷新 | 大 | 明確 | 専門的 | メジャー | 長期 | 中スキル |
| D | レガシーマイグレーション | 中 | 明確 | 汎用 | ニッチ | 中期 | 高スキル少数 |
| E | 保守フェーズの継続開発 | 小 | 変動 | 専門的 | メジャー | 長期 | リソース不足 |
| F | 短期の大量実装（キャンペーンLP等） | 中 | 明確 | 汎用 | メジャー | 短期 | リソース不足 |
現実によくある状況を網羅したつもりです。では順番にシミュレーションしていきます。
パターンA：スタートアップMVP
状況設定
- 規模：小（1-3人月相当）
- 仕様：変動的（作りながら考える）
- ドメイン：汎用（EC、SaaS等）
- 技術：メジャー（React、Node.js等）
- 期間：短期（2-3ヶ月）
- 国内チーム：高スキルエンジニア1-2名
オフショア開発の場合
コスト試算
オフショア2-3名 × 3ヶ月 × 40万円 = 240-360万円
ブリッジSE or PM工数：+100万円程度
合計：350-460万円
想定される展開
初期の仕様伝達に2-3週間かかります。「作りながら考える」というMVP特有のやり方はオフショアが苦手とするところです。仕様変更のたびに再説明コストが発生し、時差があるとフィードバックループが1日単位になってしまいます。
創業者の頭の中にある暗黙知——「このボタン、やっぱりここじゃなくてここに」「この機能、ユーザーテストしたら不要だった」といった判断を、リアルタイムで伝えるのは困難です。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | △ | 規模が小さいと固定コストの比率が重い |
| スピード | × | 仕様変動への対応で遅延しやすい |
| 品質 | △ | レビューが追いつかないリスク |
| 変更対応力 | × | 最大の弱点 |
| リスク | △ | 最悪、作り直しになる |
| ナレッジ蓄積 | × | 社外に出てしまう |
AI駆動開発の場合
コスト試算
国内高スキル1名 × 3ヶ月 × 100万円 = 300万円
AIツール（Cursor/Claude等）：月2-5万円 × 3ヶ月 = 6-15万円
合計：306-315万円
想定される展開
創業者・エンジニアが直接AIと対話しながらプロトタイプを作ります。「これ違う、こっちにして」が即座に反映可能。汎用ドメイン × メジャー技術はAIの得意領域です。
正直なところ、1人で2-3人分の実装速度が出る可能性があります。MVPフェーズでは「速く試して捨てる」サイクルが重要なので、このスピード感は決定的な差になります。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ○ | 少人数で完結、ツール代は誤差 |
| スピード | ◎ | 意思決定者が直接実装に関与 |
| 品質 | ○ | ただしAI出力のレビュー能力が必要 |
| 変更対応力 | ◎ | 最大の強み |
| リスク | ○ | 人依存だが、規模が小さいので許容範囲 |
| ナレッジ蓄積 | ◎ | すべて社内に残る |
結論
AI駆動開発が明確に優勢
理由：
- 小規模・短期では、オフショアの立ち上げコストが相対的に重すぎる
- 仕様変動が前提のMVPでは、コミュニケーション遅延が致命的
- 高スキル人材がいるなら、AIで増幅した方が効率的
パターンB：中規模Webサービス新規
状況設定
- 規模：中（10-30人月相当）
- 仕様：やや変動（大枠は決まっているが詳細は開発中に固まる）
- ドメイン：汎用（BtoB SaaS、社内ツール等）
- 技術：メジャー（React、Python、AWS等）
- 期間：中期（6-12ヶ月）
- 国内チーム：中スキルエンジニア数名
オフショア開発の場合
コスト試算
オフショア5-6名 × 8ヶ月 × 40万円 = 1,600-1,920万円
ブリッジSE 1名 × 8ヶ月 × 80万円 = 640万円
国内PM・設計者 1名 × 8ヶ月 × 100万円 = 800万円
合計：約3,000-3,400万円
想定される展開
規模が出てきたのでオフショアの単価メリットが効き始めます。ただし、ブリッジSEの質に大きく依存します。
「やや変動」の仕様をどこまで吸収できるかが勝負です。設計フェーズを国内で固めてから実装を投げる、というウォーターフォール寄りの進行になりがちです。並列化できる反面、調整コストも増えます。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ○ | スケールメリットが出る |
| スピード | △ | 並列化できるが、調整コストも増 |
| 品質 | △ | ブリッジSE・レビュー体制次第 |
| 変更対応力 | △ | 対応可能だが追加コスト発生 |
| リスク | △ | ベンダー選定失敗のリスクあり |
| ナレッジ蓄積 | × | 設計は残るが実装知識が外に出る |
AI駆動開発の場合
コスト試算
国内中スキル3名 × 8ヶ月 × 70万円 = 1,680万円
AIツール：月5万円 × 3名 × 8ヶ月 = 120万円
シニアエンジニア（レビュー・設計支援）0.5名 × 8ヶ月 × 120万円 = 480万円
合計：約2,280万円
想定される展開
中スキルエンジニアがAIを使いこなせるかが最大の変数です。使いこなせれば1人1.5-2人分の生産性が出ますが、使いこなせないと「AIに振り回される」状態になります。
ここが難しいところです。シニアがレビューと方向修正を担う体制が必要になります。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ◎ | オフショアより安くなる可能性 |
| スピード | ○ | AI活用度合いに依存 |
| 品質 | △ | 中スキル×AIは品質ばらつきリスク |
| 変更対応力 | ○ | オフショアよりは柔軟 |
| リスク | △ | チームのAI習熟度が未知数 |
| ナレッジ蓄積 | ◎ | すべて内部に残る |
結論
条件付きでAI駆動がやや優勢
ただし分岐点があります：
| 条件 | 優勢 |
|---|---|
| 国内チームがAIツールに習熟している or 学習意欲が高い | AI駆動 |
| 国内チームがAIに懐疑的 or 習熟に時間がかかりそう | オフショア |
| 信頼できるオフショアベンダーと既存関係がある | オフショア |
| 初めてのオフショア利用 | AI駆動 |
ポイント：中スキルチームの場合、「AIを使う能力」自体がボトルネックになりうる。オフショアはその点、マネジメントさえできれば回る。ここが判断の分かれ目です。
パターンC：大企業の基幹システム刷新
状況設定
- 規模：大（100人月〜）
- 仕様：明確（RFPや要件定義書が整備されている）
- ドメイン：専門的（金融、医療、製造業の業務知識が必要）
- 技術：メジャー（Java、.NET、Oracle等）
- 期間：長期（1.5-3年）
- 国内チーム：中スキルエンジニア複数名
オフショア開発の場合
コスト試算
オフショア15-20名 × 24ヶ月 × 40万円 = 14,400-19,200万円
ブリッジSE 3名 × 24ヶ月 × 80万円 = 5,760万円
国内PM・アーキテクト 3名 × 24ヶ月 × 120万円 = 8,640万円
合計：約2.9-3.4億円
想定される展開
これはオフショア開発の「王道パターン」です。仕様が明確なので、詳細設計→実装→テストの分業が成立します。大手ベンダーなら同業界の実績・ドメイン知識を持っている可能性もあります。
長期なのでチーム習熟が進みます。ただし専門ドメインの暗黙知伝達には時間がかかります。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ◎ | スケールメリット最大化 |
| スピード | ○ | 人海戦術で並列化可能 |
| 品質 | ○ | 仕様明確＋長期で安定しやすい |
| 変更対応力 | △ | 変更管理プロセスが重くなる |
| リスク | △ | ベンダーロックイン、途中離脱リスク |
| ナレッジ蓄積 | × | 実装の大部分が社外 |
AI駆動開発の場合
コスト試算
国内中スキル8名 × 24ヶ月 × 70万円 = 13,440万円
シニア・アーキテクト 3名 × 24ヶ月 × 120万円 = 8,640万円
AIツール：月5万円 × 11名 × 24ヶ月 = 1,320万円
合計：約2.3億円
想定される展開
計算上は安くなりますが、現実的な問題があります。
そもそも11名の国内エンジニアを24ヶ月確保できるのか？専門ドメイン（金融規制、医療法令等）はAIの学習データが限定的です。基幹システム特有の「既存システムとの整合性」「社内政治」はAIでは解決できません。
正直ここで詰まりました。AIが生成したコードを大規模に統合管理する知見がまだ成熟していない、という現実があります。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ○ | 数字上は安いが、採用コスト未算入 |
| スピード | △ | 人数が限られる分、並列化に限界 |
| 品質 | △ | 大規模AI生成コードの品質管理が未知数 |
| 変更対応力 | ○ | 内製なので調整は早い |
| リスク | × | 人材確保リスク、AI活用の組織能力リスク |
| ナレッジ蓄積 | ◎ | すべて内部に残る |
結論
オフショア開発が優勢
理由：
| 要因 | 影響 |
|---|---|
| 規模の壁 | 100人月超を国内AI駆動で回すのは採用市場的に困難 |
| 仕様の安定性 | オフショアの弱点（変更対応）が問題になりにくい |
| 専門ドメイン | 金融・医療等のドメイン知識はAIより経験者の方が信頼性高い |
| 組織の現実 | 大企業はオフショアの発注・管理ノウハウを既に持っていることが多い |
ただし将来の変数として、専門ドメイン向けのAIモデル・RAGが成熟すれば逆転の可能性はあります。国内エンジニア不足が深刻化すれば、どちらも選べない可能性もありますが。
パターンD：レガシーマイグレーション
状況設定
- 規模：中（10-30人月相当）
- 仕様：明確（既存システムの動作が正解）
- ドメイン：汎用
- 技術：ニッチ（COBOL、VB6、古いJava、独自フレームワーク等）
- 期間：中期（6-12ヶ月）
- 国内チーム：高スキルエンジニア少数
オフショア開発の場合
コスト試算
オフショア5名 × 10ヶ月 × 40万円 = 2,000万円
ブリッジSE 1名 × 10ヶ月 × 80万円 = 800万円
国内PM・アーキテクト 1名 × 10ヶ月 × 120万円 = 1,200万円
合計：約4,000万円
想定される展開
ニッチ技術（COBOL等）を扱えるオフショアベンダーは限られます。見つかったとしても単価が上がります（40万→60万円等）。
「既存の動作を完全再現」は仕様書がない部分でハマりやすい。現行システムの暗黙仕様を伝達するコミュニケーションコストが膨大になります。テスト工程で「動作が違う」の往復が頻発するリスクがあります。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | △ | ニッチ技術で単価メリット薄れる |
| スピード | △ | 暗黙仕様の確認で遅延しがち |
| 品質 | × | 「なぜか本番で動かない」リスク高 |
| 変更対応力 | ○ | 仕様は明確なので変更自体は少ない |
| リスク | × | ベンダー選定難、移行失敗リスク |
| ナレッジ蓄積 | × | 新システムの知識が外に |
AI駆動開発の場合
コスト試算
国内高スキル2名 × 10ヶ月 × 100万円 = 2,000万円
AIツール：月5万円 × 2名 × 10ヶ月 = 100万円
合計：約2,100万円
想定される展開
ここが意外なのですが、AIはレガシーコードの読解・変換が得意です。
COBOL→Java、VB6→C#等の変換はAIの学習データに含まれています。「このCOBOLの処理、何やってる？」をAIに聞けます。高スキルエンジニアがAI出力をレビュー・修正する体制で、現行システムを熟知した社内メンバーと直接連携できます。
AIが特に強いポイント
- 古いコードのドキュメント化
- パターン的なコード変換の自動化
- テストケース生成（既存動作からの逆算）
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ◎ | 半額近くになる可能性 |
| スピード | ○ | 変換作業の自動化で短縮 |
| 品質 | ○ | 高スキルがレビューすれば担保可能 |
| 変更対応力 | ◎ | 内製なので即座に対応 |
| リスク | △ | AI変換の精度検証は必要 |
| ナレッジ蓄積 | ◎ | 新旧両方の知識が社内に残る |
結論
AI駆動開発が優勢
理由：
| 要因 | 影響 |
|---|---|
| AIのレガシー読解力 | COBOLやVB6の解析・変換はAIの得意領域 |
| ニッチ技術の人材市場 | オフショアでも国内でもレガシー人材は希少。AIで補完する方が現実的 |
| 暗黙仕様の壁 | 現行を知る社内メンバーと直接連携できるAI駆動が有利 |
| コスト差 | 約半額の差は大きい |
注意点として、高スキルエンジニアがいることが前提です。AI変換結果の検証工程は省略できません。超大規模（数百万行）だとAI駆動でも限界があります。
補足：このパターンは「AIが人間より得意な領域」の典型例です。古いコードを読んで理解する作業は人間には苦痛ですが、AIには苦痛という概念がありません。
パターンE：保守フェーズの継続開発
状況設定
- 規模：小（1-3人月/月 程度の継続的な作業）
- 仕様：変動的（障害対応、機能追加要望がランダムに発生）
- ドメイン：専門的（業界特有のルール・用語がある）
- 技術：メジャー
- 期間：長期（1年以上の継続契約）
- 国内チーム：リソース不足（本業で手一杯）
オフショア開発の場合
コスト試算（年間）
オフショア2名 × 12ヶ月 × 40万円 = 960万円
ブリッジSE 0.5名 × 12ヶ月 × 80万円 = 480万円
国内窓口 0.3名 × 12ヶ月 × 100万円 = 360万円
合計：約1,800万円/年
想定される展開
専属チームを置けるので、ドメイン知識が徐々に蓄積されます。長期契約なので関係性が安定します。
ただし「急ぎの障害対応」で時差が痛い。「この画面のここ、ちょっと直して」レベルの依頼でも仕様書化が必要です。変動的な仕様に対して、毎回説明コストが発生します。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ○ | 固定で人を確保できる安心感 |
| スピード | × | 小さな変更でもリードタイム長い |
| 品質 | △ | 長期で安定するが、専門ドメインの理解に限界 |
| 変更対応力 | × | 保守の本質は変更対応なのに弱い |
| リスク | △ | 担当者離脱で知識喪失 |
| ナレッジ蓄積 | × | ベンダー側に蓄積、引き継ぎ困難 |
AI駆動開発の場合
コスト試算（年間）
国内エンジニア1名（兼務0.5相当）× 12ヶ月 × 50万円 = 600万円
AIツール：月5万円 × 12ヶ月 = 60万円
シニアのスポット支援：年100万円
合計：約760万円/年
想定される展開
「本業で手一杯」な人がAIで生産性を上げて保守を兼務します。小さな修正はAIに書かせて、レビューだけ人間がやります。
障害対応では「このエラーログの原因は？」とAIに聞ける即応性があります。専門ドメインの知識はRAG（社内ドキュメント検索）で補完可能です。「ちょっとした修正」が本当に「ちょっと」で済むようになります。
AIが特に強いポイント
- 既存コードベースの理解（「この関数何してる？」）
- 小規模な修正の高速化
- 障害調査の補助
- ドキュメント・コメントの自動生成
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ◎ | 半額以下 |
| スピード | ◎ | 即日対応が可能 |
| 品質 | ○ | レビューできる人がいれば問題なし |
| 変更対応力 | ◎ | 保守との相性抜群 |
| リスク | △ | 兼務者の負荷管理が必要 |
| ナレッジ蓄積 | ◎ | すべて社内、AIとのやり取りも記録に残る |
結論
AI駆動開発が明確に優勢
理由：
| 要因 | 影響 |
|---|---|
| 保守の性質 | 小さな変更が頻発する保守は、AIの「即座に対応」が活きる |
| コスト構造 | オフショアの固定費（ブリッジSE等）が重荷。AI駆動は変動費に近い |
| 専門ドメイン問題 | RAGや社内ドキュメント連携で解決可能になってきた |
| リソース不足の解決法 | 「人を増やす」より「1人の生産性を上げる」方が現実的 |
このパターンの本質：保守フェーズは「予測不能な小タスクの連続」です。これに対してオフショアは「まとまった作業を計画的に発注する」モデルなので、根本的に相性が悪い。AI駆動は「その場で即対応」ができるので、保守の性質と合致します。
注意点として、兼務者が燃え尽きないようにする配慮は必要です。重大障害時のエスカレーション先は別途確保すべきです。
パターンF：短期の大量実装（キャンペーンLP等）
状況設定
- 規模：中（10-30人月相当）
- 仕様：明確（デザインカンプ、ワイヤーフレームが揃っている）
- ドメイン：汎用（LP、イベントサイト、定型ページ等）
- 技術：メジャー（HTML/CSS、React、WordPress等）
- 期間：短期（1-3ヶ月）
- 国内チーム：リソース不足（他案件で埋まっている）
オフショア開発の場合
コスト試算
オフショア8名 × 2ヶ月 × 40万円 = 640万円
ブリッジSE 1名 × 2ヶ月 × 80万円 = 160万円
国内ディレクション 0.5名 × 2ヶ月 × 100万円 = 100万円
合計：約900万円
想定される展開
これはオフショアの得意パターンです。仕様明確×大量×定型作業。デザインカンプ通りに量産する作業は指示が出しやすい。人海戦術で並列化できます。
短期だがキックオフ・環境構築で最初の1-2週間は立ち上がりが遅い。「このLP、やっぱりこう変えて」への対応はやや遅れます。
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ○ | 人数投入でスケールできる |
| スピード | ○ | 並列化で短期集中に対応可能 |
| 品質 | ○ | 定型作業なので安定しやすい |
| 変更対応力 | △ | 仕様明確前提なので変更は苦手 |
| リスク | ○ | この種の案件は実績豊富なベンダー多い |
| ナレッジ蓄積 | × | 使い捨て的な作業なので問題になりにくい |
AI駆動開発の場合
コスト試算
国内エンジニア2名 × 2ヶ月 × 80万円 = 320万円
AIツール：月5万円 × 2名 × 2ヶ月 = 20万円
合計：約340万円
想定される展開
LP量産はAIの最も得意な領域の一つです。「このデザインカンプをHTML/CSSにして」が一発で出ます。1人で5-10人分の実装速度が現実的に出ます。
ただし「リソース不足」が前提なので、その2名を確保できるかが問題です。確保できれば圧倒的なコストパフォーマンスです。
AIが特に強いポイント
- デザインからコードへの変換
- 類似ページの量産（テンプレート化→バリエーション生成）
- レスポンシブ対応の自動化
- 微修正の即時反映
評価
| 軸 | 評価 | コメント |
|---|---|---|
| 総コスト | ◎ | 1/3以下になる可能性 |
| スピード | ◎ | 量産速度はAIが圧倒的 |
| 品質 | ○ | 定型作業なのでAI出力も安定 |
| 変更対応力 | ◎ | 「やっぱりここ変えて」に即対応 |
| リスク | △ | 2名に依存、体調不良等で詰むリスク |
| ナレッジ蓄積 | ○ | そもそも蓄積の必要性が低い |
結論
AI駆動開発が優勢、ただし人材確保が条件
| 条件 | 優勢 |
|---|---|
| 国内で2名程度確保できる | AI駆動（圧倒的コスト差） |
| 国内で誰も確保できない | オフショア（やむを得ず） |
| 急な仕様変更が多発しそう | AI駆動 |
| 完全に仕様FIXで変更なし | どちらでも可（コストでAI有利） |
このパターンの本質：LP量産のような「定型×大量×短期」は、かつてはオフショアの独壇場でした。しかしAIによるコード生成が実用レベルになった今、「人を増やす」より「AIで増幅する」方が効率的になった領域です。
現実的な判断ポイント：本当に人が確保できないなら、オフショアは有効な選択肢です。ただし「オフショアに出す準備工数」と「社内の誰かがAIで回す工数」を比較すべきです。意外と後者の方が早いことが多いです。
総括：比較表とパターン分析
全パターン結論一覧
| パターン | 状況 | 結論 | 優勢度 |
|---|---|---|---|
| A | スタートアップMVP | AI駆動 | 明確 |
| B | 中規模Webサービス新規 | AI駆動（条件付き） | やや |
| C | 大企業の基幹システム刷新 | オフショア | 明確 |
| D | レガシーマイグレーション | AI駆動 | 明確 |
| E | 保守フェーズの継続開発 | AI駆動 | 明確 |
| F | 短期の大量実装 | AI駆動（条件付き） | 優勢 |
スコア：AI駆動 5勝、オフショア 1勝
評価軸別の傾向
graph TD
A[開発リソース選択] --> B{規模は？}
B -->|小〜中| C[AI駆動が優勢]
B -->|大規模| D{仕様は？}
D -->|明確| E[オフショア優勢]
D -->|変動| F[AI駆動優勢]
決定要因マトリクス
この条件なら → こちらを選ぶ
| 条件 | 推奨 |
|---|---|
| 規模が100人月超 | オフショア |
| 規模が30人月以下 | AI駆動 |
| 仕様が変動的・アジャイル的 | AI駆動 |
| 仕様が完全に明確・ウォーターフォール | どちらでも可 |
| 国内に高スキル人材がいる | AI駆動 |
| 国内に人材が全くいない | オフショア |
| 専門ドメイン（金融・医療等）で規模大 | オフショア |
| 専門ドメインだが規模小〜中 | AI駆動（RAG活用） |
| 短期で即応性が必要 | AI駆動 |
| 長期で安定したリソースが必要 | 条件次第 |
| レガシー技術が絡む | AI駆動 |
| 保守・運用フェーズ | AI駆動 |
構造的な示唆
オフショアが優勢になる条件は限定的になりつつある
オフショアが勝てる領域
┌─────────────────────────────────────┐
│ 大規模 × 仕様明確 × 長期 × 人材不足 │
└─────────────────────────────────────┘
↑
この交差点のみ
AI駆動が構造的に有利な理由
- コミュニケーションコストがゼロ：言語・時差・文化の壁がない
- 即応性：「今すぐ」に対応できる
- スケールの方向が違う：人を増やすのではなく、1人を増幅する
- ナレッジが必ず内部に残る：外注の構造的弱点を持たない
オフショアの残された強み
- 純粋な人数の壁：100人月超はまだAI駆動では現実的に回せない
- 採用市場の現実：国内エンジニアが確保できないケースは存在する
- 既存関係の価値：信頼できるベンダーとの関係は資産
エンジニア視点での問題提起：疲弊の構図
ここまで経営視点で分析してきましたが、重要な視点が抜け落ちています。
AI駆動開発の「裏側」
経営視点で見えているもの
オフショア：10人 × 40万円 = 400万円/月
AI駆動：2人 × 100万円 + ツール代 = 210万円/月
→ 「半額で済む、素晴らしい」
エンジニア視点で見えるもの
オフショア：10人で分担 → 1人あたり10%の責任
AI駆動：2人で全部 → 1人あたり50%の責任
→ 「仕事量5倍、給料2倍にもならない」
構造的な問題
「生産性が上がった分、仕事が増える」パターン
| フェーズ | 起きること |
|---|---|
| 導入初期 | AIで楽になった、早く終わる |
| 経営が気づく | あれ、この人数で回るじゃん |
| 次のサイクル | じゃあもう1案件追加で |
| 結果 | 生産性向上分が「余裕」ではなく「追加タスク」に吸収される |
「代わりがいない」リスク
- オフショア10人なら1人抜けても9人でカバー
- AI駆動2人で1人倒れたら崩壊
- 休暇が取れない、プレッシャーが常にかかる
「AIがあるんだからできるでしょ」圧力
- 見積もりが「AI前提」で圧縮される
- 「AIで書けばすぐでしょ」という非エンジニアからの誤解
- 断る理由が説明しにくい
これは「分配」の問題
AI駆動開発で生まれた利益をどう分けるか：
| 分配先 | 取り分 |
|---|---|
| 経営・株主 | コスト削減分の大部分 |
| エンジニア | 少しの昇給、大量の追加業務 |
| AI企業 | サブスク収益 |
エンジニアが疲弊する構図は、この分配が不公平になるリスクを指しています。
持続可能な運用モデル
「効率化の果実」をどう使うか
AI駆動で生まれた余剰時間
│
├─ 短期思考：もっとタスクを詰め込む → 疲弊、摩耗
│
└─ 長期思考：半分は探索・学習に回す → 深化、持続可能性
なぜ「探索の時間」がビジネス価値になるか
エンジニアは「今できること」だけで価値を測れません。
| 時間の使い方 | 短期的価値 | 長期的価値 |
|---|---|---|
| タスク消化 | 高い | 減衰する |
| 新技術の学習 | ゼロ | 複利で増える |
| 実験・失敗 | マイナス | 突然変異的な発見 |
| 言語化・発信 | ゼロ | 採用力、ブランド |
AIは「既知の作業」を効率化します。でも「次に何をすべきか」を発見するのは、探索の時間から生まれます。
短期最適化に走った組織 vs 探索を残した組織
短期最適化に走った組織
- AIで効率化 → 全部タスクに充てる → 速く回る
- でも1-2年後、誰も新しいことを知らない
- 市場が変わったときに対応できない
- 「AIに使われる組織」になる
探索を残した組織
- AIで効率化 → 半分はタスク、半分は探索
- 短期的には「遊んでる」ように見える
- でも1-2年後、次の武器を持っている
- 「AIを使いこなす組織」になる
これは「投資」の問題
経営視点で言い換えると：
余剰時間の50%を探索に回す
= 人的資本への再投資
= R&D費用と同じ性質
設備投資や研究開発費は「今期の利益を減らして将来に賭ける」行為として認められています。人の時間も同じはずですが、なぜか「遊んでる」「サボり」に見えてしまう。
具体的な運用モデル
AI駆動開発の「健全な運用モデル」
| 項目 | 配分 |
|---|---|
| タスク消化 | 50-60% |
| 学習・スキルアップ | 20-25% |
| 実験・プロトタイプ | 10-15% |
| 余白（予備、休息） | 10% |
この配分をチームや経営と握っておくことが重要です。
最終評価の修正
この視点を入れると、AI駆動開発の評価に条件が付きます：
| 運用モデル | 短期評価 | 中長期評価 |
|---|---|---|
| AI駆動 × 短期最適化（全部タスク） | ◎ | × 疲弊・離職・摩耗 |
| AI駆動 × 探索時間を確保 | ○ | ◎ 深化・持続・次の武器 |
| オフショア | △ | ○ 良くも悪くも安定 |
つまり「AI駆動が優勢」という結論は、健全な運用が前提です。搾取モデルで回すなら持続可能性に疑問符が付きます。
振り返り
分析結果のまとめ
6つのパターンでシミュレーションした結果：
- AI駆動開発が優勢：5パターン
- オフショア開発が優勢：1パターン
AI駆動が優勢だったパターン
- 小規模・短期・仕様変動的なプロジェクト
- レガシーマイグレーション
- 保守フェーズの継続開発
- 短期の大量実装（条件付き）
オフショアが優勢だったパターン
- 大規模・長期・仕様明確・専門ドメインのプロジェクト
構造的な違い
AI駆動開発の特徴
- コミュニケーションコストがゼロ
- 即応性が高い
- スケールは「1人を増幅する」方向
- ナレッジが内部に蓄積される
オフショア開発の特徴
- 大規模な人数を確保できる
- 仕様が明確な場合に効率的
- コミュニケーションコストが存在する
- ナレッジが外部に流出する
見えてきた課題
エンジニア視点の問題
AI駆動開発で生まれた余剰時間をどう使うかで、結果が分岐する：
| 運用モデル | 短期 | 中長期 |
|---|---|---|
| 全部タスクに充てる | 高効率 | 疲弊・離職・摩耗 |
| 半分を探索に回す | やや低効率 | 深化・持続・次の武器 |
時間配分の例
- タスク消化：50-60%
- 学習・スキルアップ：20-25%
- 実験・プロトタイプ：10-15%
- 余白（予備、休息）：10%
判断フレームワーク
2026年時点での基本的な流れ
国内に高スキル人材が確保できるか？
│
├─ YES → AI駆動を検討
│ （規模に応じて人数調整）
│
└─ NO → 規模を確認
│
├─ 大規模 → オフショア
│
└─ 小〜中規模 → 採用努力 or フリーランス + AI駆動
それでも困難な場合はオフショア
主な変数
- プロジェクト規模
- 仕様の安定性
- ドメインの専門性
- 人材確保の可否
- 組織の運用方針
今後の変化の可能性
- AIツールの進化により「高スキル」の定義が変わる可能性
- 中スキルエンジニアでもAI駆動で成果を出せる環境が整う可能性
- オフショアの優位領域がさらに狭まる可能性
- 専門ドメイン向けのAIモデルが成熟すれば構図が変わる可能性
この分析は2026年2月時点のものであり、今後の技術進化や市場環境の変化により、結論が変わる可能性があります。