オフショア開発は"AIに殺される"のか？ ― 2026年、その意義を再定義する

Last updated at 2026-03-14Posted at 2026-03-14

Devin月額$20。それでもオフショアは必要か？

月曜10時、オフショアチームとの週次進捗会議。5件依頼したチケットのうち3件が「仕様確認待ち」。PMが補足すると「確認して明日回答します」。翌日届いた回答には新たな質問が3つ ―― このサイクルに覚えがあるなら、本記事はあなたのために書いた。

2025年4月、AIソフトウェアエンジニア「Devin」が月額$500から**$20**に値下げされた。ベトナムPG単価は月額約39万円（offshore-kaihatsu.com 2026年版）。130倍の価格差だ。

項目	Devin (AI)	オフショアPG
月額	$20〜500	約39万円
稼働	24時間365日	8時間 x 20日
立ち上がり	ほぼゼロ	数ヶ月
並列処理	8エージェント同時	1人1タスク

実績もある。Devinを2ヶ月試用し、約30万円で197件のPRをマージした企業がある（Findy Tech Blog）。DeNAは全社員2,000名にDevin Enterpriseを導入。PerlからGoへの6,000行の移行を、Devin 80%・Claude Code 15%・人間 5%の体制で6ヶ月→1ヶ月に短縮した（DeNA Engineering Blog）。モノタロウはPR全体の14%をDevinが作成（CodeZine）。ZOZOはAIのみのレビュー通過率72.0%を達成した（ZOZO TECH BLOG）。

この価格差を前に、オフショアに「コード量産」を求め続ける合理性はあるだろうか。

答えはNo。だが、オフショアが不要になるわけでもない。

本記事では、オフショアの新しい主戦場をApplied AIエンジニアと呼ぶ。最先端のAI技術を研究し、OSSやSaaS、AIツールを組み合わせて「使える仕組み」を構築するエンジニアだ。

なぜオフショアは死なないのか

理由は単純だ。日本にはエンジニアが足りない。

経産省の試算では2030年に最大79万人のIT人材が不足する。AIの出力をレビューする人材、AIエージェントのガバナンスを構築する人材、要件を定義してAIに橋渡しする人材。全てを国内で賄うのは不可能だ。

同時に、AIは万能ではない。想定シナリオを一つ挙げる。PMがDevinに決済機能の改修を指示し、30分で完動するコードが出てきた。だが法務チェックで止まった。特定商取引法の「最終確認画面での表示要件」を満たしていなかったのだ。AIは「動くコード」を書けるが、「法的に正しいか」は判断できない。

つまり、オフショアの存在意義は消えない。だが役割が根本から変わる。

2つの構造変化

【従来】日本PM → ブリッジSE → オフショア5〜10人（フルスクラッチ開発）
【2026】日本FDSE/GTM → オフショアApplied AIエンジニア（AI研究+組み合わせ）+ AIエージェント群

第一の変化：AIが定型業務を食う。 CRUDアプリの量産、テスト作成、ドキュメント生成。ジュニアに任せていた仕事はAIに吸収される。ChatGPT登場後1年でジュニア開発者の求人比率は16.3%減少した（Northeastern University研究）。オフショアの「量で稼ぐ」モデルは崩壊する。

第二の変化：フルスクラッチが死ぬ。 OSSやSaaSが充実した今、ゼロから作るよりも組み合わせる方がQCD全てで優れている。フレームワークがアプリ開発を変えたように、生成AIがエンジニアの役割を変える。

バイブコーディングで非エンジニアでもアプリが作れる時代に、「コードを書けること」自体の価値は急落した。では何が求められるのか。

オフショアに求められる「3つの力」

1. 組み合わせ力（Applied AIエンジニア）

OSSやSaaS、AIツールを最適に組み合わせて仕組みを構築する力だ。この力を活かすには、日本側との連携が前提になる。ここで登場するのがFDSEとGTMエンジニアだ。

FDSE（Forward Deployed Software Engineer） は、Palantir/OpenAIが先駆けた「前線配備型エンジニア」。通常のエンジニアとの違いは、技術力に加えて顧客のドメイン知識とビジネス理解が求められる点だ。顧客の業務を深く理解し、「このシステムは法的にここが問題」「この業務フローはこう変えるべき」といった判断を技術的な要件に翻訳する。日本ではLayerXが2025年7月にFDE職を設立し、AI Shift（サイバーエージェントグループ）も正式に職種化した。

GTMエンジニア（Go-To-Market Engineer） は、AI駆動の市場投入の仕組みを構築するエンジニア。「この技術をどう製品化し、どう顧客に届けるか」を設計する。HubSpot + Claude + 独自RAG + Slack Agentを組み合わせた営業自動化パイプラインの構想など、ビジネスとテクノロジーの交差点に立つ役割だ。

棲み分けはこうなる。日本側のFDSEが顧客の業務課題を深く理解して要件に落とし込み、GTMエンジニアが市場投入の構想・アーキテクチャを検討する。オフショアのApplied AIエンジニアがそれを受け取り、高い技術力で研究・実験・実装を担う。

実際のワークフロー例を想定してみる。 ある製造業の顧客から「工場の品質検査レポートを自動生成したい」という相談が来たケースだ。

1. 日本側FDSEが工場を訪問し、現場の検査フローを理解する
   → 「検査員は目視で不良品を判定し、Excelに手入力している」と把握

2. FDSEが要件を技術言語に翻訳する
   → 「画像認識で不良品を検出し、結果をRAGで過去事例と照合し、
      日本語のレポートを自動生成する仕組みが必要」

3. GTMエンジニアが市場投入を設計する
   → 「同業他社にも展開できるよう、業種テンプレートとして
      パッケージ化する。月額SaaSモデルで提供」

4. オフショアのApplied AIエンジニアが研究・実装する
   → 画像認識モデルの比較検証（YOLO vs Vision API vs 自社学習モデル）
   → RAGパイプラインの構築（LangChain + ベクトルDB）
   → レポート生成テンプレートの開発
   → Terraformモジュールでインフラをパッケージ化

5. オフショアのQAが品質を担保する
   → 不良品判定の精度テスト、個人情報マスキングの検証、
      非エンジニアが操作する際の安全性テスト

6. 日本側に納品。FDSEが顧客への導入を伴走する

Applied AIエンジニアの仕事は具体的には4つの領域がある。

AI技術の研究と適用。 日本側から「社内文書を横断検索できるようにしたい」と要件が来る。Applied AIエンジニアはLangChainとベクトルDBを比較検証し、RAGパイプラインのプロトタイプを数日で構築する。どのモデルが精度・コスト・レイテンシのバランスで最適か、実験で見極める。モダナイゼーション。 古いNode.js 14から20への移行、PerlからGoへの変換、jQuery依存のフロントエンドのReact化。レガシー環境からモダン環境への切り替えは、AIドリブンで劇的に効率化できる。変換ツールの選定、変換ルール・ロジックの設計、移行プロセスそのものの仕組み化。DeNAのPerl→Go移行（Devin 80%で6ヶ月→1ヶ月）はまさにこの好例だ。Applied AIエンジニアは「1回限りの移行作業」ではなく、「他プロジェクトでも再利用できる移行フレームワーク」を構築する。

バイブコーディング環境の整備。 非エンジニアがDevinやClaude Codeで安全に開発できる環境を作る。例えば、社内で使うSlack Botの雛形をテンプレート化し、非エンジニアが「顧客問い合わせの自動分類Bot」を自然言語の指示だけで作れるようにする。ただし本番DBへのアクセスはガードレールでブロックし、デプロイにはCI/CDパイプライン経由の承認を必須にする。「誰でも作れるが、壊せない」環境の設計だ。

共通基盤のパッケージ化。 成功した実験やモダナイゼーションの結果を、Terraformモジュール、GitHub Actionsテンプレート、Guardrails設定ファイルとして標準化する。make deploy 一発でインフラ構築からアプリデプロイまで完了する状態を目指す。

2. ギーク力（独自技術の創出）

競プロレベルのコーディングスキルで、市場にない独自ライブラリやコンポーネントを開発できる力。OSSの上に乗るだけでなく、OSSそのものを生み出せるエンジニアはAIには代替できない。

例えば、自社の業務ドメインに特化した高速な全文検索ライブラリを独自開発する。ElasticsearchやMeilisearchでは対応できない日本語の複合語分割ロジックを自前で実装し、既存OSSの10倍のクエリ速度を実現する。あるいは、社内専用のAIエージェントフレームワークを設計し、OpenClawやLangChainでは実現できないセキュリティ要件を満たすアーキテクチャを構築する。こうした「市場にないもの」を生み出せる人材が、競合との技術的差別化を実現する。

3. 品質の番人力（QA + ガバナンス）

AIが書いたコードを磨き、AIが使われる環境の安全を担保する力。3つの領域がある。

コード最適化。 バイブコーディングで非エンジニアが作ったコードは動くが、変数名が data1 data2 だったり、エラーハンドリングが欠落していたりする。これをリファクタリングし、テストカバレッジを補完し、本番運用に耐えるコードに仕上げる。

AIユーザー目線テスト。 非エンジニアがDevinを使うシーンが増えている今、新しいテスト観点が必要だ。例えば、営業職が「全顧客の売上データをCSVでエクスポートして」とDevinに指示したとき、個人情報保護の観点から適切にマスキングされるか。「本番DBのデータを修正して」と指示したとき、ステージング環境にリダイレクトされるか。プロンプトの揺れやAIの非決定的な出力を考慮したテスト設計が求められる。

ガバナンス構築。 75%のCISOが社内に未承認AIエージェントを発見している（2026 CISO AI Risk Report）。OpenClawのサプライチェーン攻撃（1,184件の悪意あるパッケージ、Dark Reading）やClaude Codeの脆弱性（CVE-2025-59536）など、実際のインシデントも発生。OPA等によるポリシー定義、human-in-the-loop承認フロー、Zero Trust適用の設計・構築を担う

package agent.policy
default allow = false

allow {
    input.action == "db_write"
    input.environment == "production"
    input.human_approved == true
}

allow {
    input.action == "db_write"
    input.environment == "staging"
}

allow {
    input.action == "external_api_call"
    input.rate_count < 100
}

本番環境への変更はSlackに承認リクエストが飛び、シニアエンジニアの承認までブロックされる。

Gartnerはエージェンティック AIプロジェクトの40%以上が2027年末までにキャンセルされると予測している（Gartner 2025年6月）。ガバナンスを設計できる人材は世界的に不足しており、「このチームがいないと運用できない」と選ばれるポジションになる。

この転換は既に始まっている

業界全体がこの方向に動いている。FPT Softwareは2025年8月にAI-firstプラットフォーム「FleziPT」を発表し$30M規模のMoUを締結（FPT Software公式）。Infosysは全従業員の84%以上をAI対応にスキルアップし「Agentic AI Foundry」を設立。フィリピンのBPO企業は計$25MをAI人材育成に投資している。

日本のIT人材不足は構造的問題であり、FDSE/GTMの確保すら容易ではない。だからこそ、高い技術力を持つオフショアのApplied AIエンジニアが支えるからこそ、日本側は少ない人員でも回せる。「安い手を動かす人」から「AIを操る専門集団」へ。転換は待ったなしだ。

まとめ ― 3つのキーメッセージ

1. 「安いから」「ゼロから作れるから」の時代は終わった。
Devinは月額$20。フルスクラッチはOSS/SaaSの組み合わせに取って代わられる。市場はより低コスト・高品質・短納期を求めている。

2. オフショアの存在意義はむしろ大きくなる。
日本のIT人材不足は構造的問題だ。Applied AIエンジニア、FDSE、GTMの全てを国内で賄うのは不可能。高いAI技術力を持つオフショアが「組み合わせ力」「ギーク力」「品質の番人力」を武器にすれば、不可欠なパートナーになる。

3. 「AIエージェントを作る側」に進化できるかが分岐点。
コードを書く集団から、AIソリューションの研究者・構築者へ。モダナイゼーションの仕組み化、バイブコーディング環境の整備、ガバナンスの設計。それはもはや「オフショア」ではなく「AIソリューションパートナー」と呼ぶべき存在だ。

これから始めるアクション

EM・PM向け:

オフショアへの発注内容を「Devinで代替可能か」で○△×に仕分ける
オフショアパートナーに「AI活用の実績・計画」をヒアリングする。回答がなければパートナー見直しのシグナル
Devin（$20プラン）を2週間トライアルする
オフショアチームに「AIエージェントを作る側」の役割を打診する

エンジニア向け:

Devinで担当リポジトリのテスト生成を試す
OWASPの「Agentic Apps Top 10」を読む（30分で読める）
オフショアチームと共同でAIエージェント構築プロジェクトを立ち上げる。「発注」ではなく「一緒に作る」

参考ソース

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up