オフショア開発とは？メリット・デメリットと失敗を避ける判断表

オフショア開発とは、システムやアプリの開発を海外の企業やエンジニアに委託することです。最大の利点は人件費の差による開発費の削減と、国内で採りにくい人数の確保です。一方で、発注者がオフショアを避ける理由ははっきりしていて、品質、コミュニケーション、セキュリティ、契約の4つに集約できます。どれも「海外だから」起きるのではなく、仕様を文書で渡しきれない案件や、個人データ・技術情報を相手に渡す案件で表に出ます。

結論から言うと、オフショアに出すかは「仕様を文書で渡せるか」と「渡すデータや技術の機密性」の2つの軸で決められます。向くのは「仕様を文書で渡せて、渡すデータの機密性が低い案件」です。仕様が固まっていない案件や、本番の個人データを扱わせないと進まない案件は、国内で主導するか、渡すものを減らす設計を先にしてから出すほうが安全です。この記事では、その判断を表と図にまとめ、単価差がブリッジSE込みでどれだけ残るか、どこで失敗しやすいか、最初の打ち合わせで何を聞くかまでを順に整理します。

本記事の情報について: 単価は2026年10月1日にオフショア開発.com（オフショア企業の紹介サービス）の公開ページで確認した値です。法令の説明は個人情報保護委員会と経済産業省の公開資料に基づきます。実際の契約前には社内の法務や専門家に確認してください。

状況別の読み分け早見表

いまの状況に近い行から読み始めてください。

オフショア開発とは

オフショア開発とは、システム開発やアプリ開発の業務を海外の開発会社や海外子会社に委託する開発の進め方です。委託先として多いのはベトナム、フィリピン、インド、中国、バングラデシュ、ミャンマーなどのアジアの国々で、目的は国内より低い人件費での開発と、人数の確保です。

オフショア開発.comは、オフショア開発の目的が近年は「コスト削減」だけでなく、「リソース確保」「開発スピード」「技術力補完」へ広がっていると説明しています（オフショア開発白書2025年版の概要ページ）。同じページには、白書の目次として「平均コスト削減率は大幅改善—31〜50%削減が主流に」という項目が載っています。これは同社が集めた回答の傾向で、どの案件でもその割合で下がるという意味ではありません。

ブリッジSEを挟む体制が基本

オフショア開発では、日本側の発注担当と海外の開発チームのあいだに「ブリッジSE」を置く体制が一般的です。オフショア開発.comはブリッジSEを、日本企業と海外の開発チームのあいだに立ち、言語・文化・商習慣の違いを越えてプロジェクトを進める技術者で、単なる通訳ではなく品質や進捗の管理も担う「橋渡し役」と説明しています（同社のベトナム人月単価ページ）。

情報は「日本側の担当者 → ブリッジSE → 現地のリーダー → 実装する人」と段を踏んで伝わります。段が増えるほど、言葉の置き換えと解釈が重なります。後で説明する品質とコミュニケーションの問題の多くは、この段数から生まれます。

ニアショア開発・ラボ型開発との違い

よく並べて比べられる言葉との違いを表にまとめます。ラボ型開発は委託先の「場所」ではなく「契約の形」の名前なので、オフショアとも国内とも組み合わさります。

ニアショアの地域別の単価や、オフショア・フリーランス・内製との比べ方はニアショア開発の記事、ラボ型の契約条項の確認点はラボ型開発の記事で詳しく扱っています。

オフショア開発のメリット

オフショア開発のメリットは、開発費の削減、人数と技術の確保、チーム規模の調整しやすさ、継続による業務知識の蓄積の4つです。いずれも「同じ仕事を、より多くの人数で、より安く回せる」ことが土台にあります。

開発費を下げられる

最も大きいのは人件費の差です。オフショア開発.comの国別単価ページでは、2026年版のプログラマーの人月単価がベトナム40.1万円、インド37.5万円、フィリピン37.2万円、バングラデシュ33.8万円、ミャンマー27.5万円、中国58.3万円です（1人月あたり、出典は同社の白書2025年版）。国内の単価は会社・役割・地域で幅が大きいため、自社が受け取っている国内の見積もりと並べて差を見るのが確実です。国内の見積もりの単価の読み方は人月単価の記事で整理しています。

ただし、単価の差がそのまま総額の差になるわけではありません。ブリッジSEの費用と、発注側で仕様を書いたり確認したりする工数が加わるためです。この点は後の「単価差は実際にどれだけ残るか」で試算します。

国内で採りにくい人数と技術を確保できる

国内のIT人材は不足が続くと見込まれています。経済産業省の委託調査「IT人材需給に関する調査」（2019年3月）は、IT需要の伸びが高い場合に2030年の需給ギャップが約79万人（78.7万人）、中位の場合で約45万人（44.9万人）になると試算しました（調査報告書PDF）。いずれも生産性の上昇率を年0.7%と置いた場合の値で、2019年時点の推計のため、その後の生成AIの普及などは織り込まれていません。それでも、国内だけで必要な人数をそろえにくいと感じる企業がオフショアを検討する背景にはなっています。

オフショアなら、すでに稼働している開発会社の人員を使えるため、国内で一から採用するより早くチームを組めます。英語で仕事をするチームを選べば、海外向けのサービスや英語の技術資料が中心の開発にも人を当てやすくなります。

チームの人数を増減しやすい

開発の山に合わせて人数を増やし、落ち着いたら減らす調整がしやすいのも利点です。自社で採用した場合のように固定費として抱え続ける必要がありません。ただし、契約で人数変更の予告期間や最低契約期間が決まっていることが多いので、増減できる範囲は契約前に確認します。

継続すると業務知識がたまる

同じ委託先と長く続けると、チームに自社の業務や設計の背景がたまり、指示の量が減っていきます。オフショア開発.comの白書2025年版の目次には「活用期間は長期化傾向—10年以上継続企業が最多に」という項目があり、長く続けて使う企業が多いことがうかがえます。最初の数か月は仕様の説明や確認の負担が大きいため、短期の単発案件だけで向き不向きを判断しないことが大切です。

オフショア開発のデメリット：発注者が避ける4つの理由

オフショア開発のデメリットは、品質、コミュニケーション、セキュリティ、契約の4つに集約できます。オフショア開発.comの白書2025年版の目次でも、発注企業がオフショア開発企業に感じた課題として「コミュニケーション力」と「品質管理」が引き続き上位に挙がっています。ここでは、それぞれがなぜ起きるのかと、出す前に確認することを並べます。

品質：書いていないことは作られない

品質の問題の多くは、技術力ではなく「何を作るか」の伝わり方から起きます。国内の開発会社なら業務の常識で補ってくれる部分も、オフショアでは書いていなければ作られないと考えたほうが安全です。たとえば「一覧画面を作る」とだけ書くと、並べ替え、絞り込み、件数が多いときのページ分けが入らないまま納品されることがあります。

対策は、仕様の粒度と受け入れの基準を先にそろえることです。画面ごとの項目と動き、入力の制約、エラーのときの表示、性能の目安を文書にし、何が満たされれば受け入れるかを発注側が決めます。受け入れテストの観点を委託先に任せきりにすると、委託先が想定した範囲だけがテストされます。

オフショアに渡す仕様書で抜けやすいのは、次のような「国内なら言わなくても通じる」部分です。

• 一覧画面の並べ替え・絞り込み・ページ分けの有無と、初期表示の並び順
• 入力欄の必須・任意、文字数、全角と半角、日付や金額の表記
• エラーが起きたときに画面に出す文言と、入力した内容を残すかどうか
• 権限ごとに見える項目・押せるボタンの違い
• 祝日、締め日、和暦など、日本の業務に固有の決まりごと
• 「何件までなら何秒以内に表示する」といった性能の目安

この粒度で書けない部分は、仕様がまだ固まっていない部分です。そこは無理に出さず、後の判断表のように国内で固めてから出すほうが手戻りを減らせます。

コミュニケーション：伝言の段数と時差

日本と主な委託先の時差は、フィリピンと中国が1時間、ベトナムが2時間、ミャンマーが2時間半、バングラデシュが3時間、インドが3時間半です。時差自体は大きくありませんが、日本の午後に出した質問が相手の終業後に届き、翌日まで止まる、ということが重なります。そこに「担当者 → ブリッジSE → 現地リーダー → 実装者」の段数が加わると、ひとつの確認に1〜2日かかることもあります。

白書2025年版の目次には、成功のポイントとして「コミュニケーション」と「ブリッジSEの能力」が挙がっています。ブリッジSEの日本語力だけで選ばず、技術の話をそのまま実装者と交わせるか、問題が起きたときに早く報告が上がる仕組みがあるかを確認します。報告の形式を最初に決めておくと、悪い知らせが納期直前まで見えない事態を避けられます。たとえば次のような頻度と中身に分けておくと、時差があっても確認が止まりにくくなります。

「止まっていること」を毎日書く欄を作っておくのがポイントです。質問をためこんで週1回の会議でまとめて出す形にすると、時差と合わせて最大でほぼ1週間止まります。

セキュリティ：個人データと技術情報を国外に出す扱い

セキュリティは、オフショアを避ける理由のなかで最も「手続き」の話になる部分です。押さえておきたいのは次の3点です。

1つ目は個人データです。個人情報保護委員会の「個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）」は、個人データを外国にある第三者に提供する場合、原則としてあらかじめ本人の同意が必要だと説明しています（法第28条第1項）。例外は、提供先が日本と同等の水準と認められた国（同ガイドラインではEUと英国）にある場合や、提供先が基準に適合する体制を整備している場合などです。後者の方法として、同ガイドラインは「外国にある事業者に個人データの取扱いを委託する場合」の契約・確認書・覚書等を例に挙げています。そのうえで、体制整備を根拠に提供した場合は、提供先での保護措置の実施状況や相手国の制度を定期的に確認し、支障が生じたら必要かつ適切な措置を取り、基準に沿った取扱いを続けてもらうことの確保が難しくなったら提供を止める必要があります（規則第18条、ガイドライン本文PDF）。テスト用の偽データやマスキングしたデータで開発を進め、本番の個人データを委託先に渡さない設計にできれば、この負担そのものを小さくできます。

2つ目は委託先を経由した攻撃です。IPAの「情報セキュリティ10大脅威 2026」の組織向けでは、「サプライチェーンや委託先を狙った攻撃」が2位に入っています（IPAの発表ページ）。国内の委託先でも同じリスクはありますが、海外の委託先では現地での監査や立ち入りがしにくく、アカウントや開発環境の管理状況を目で確かめる手段が限られます。開発環境への接続方法、退職者のアカウントを止める手順、ソースコードの保管場所を契約前に聞いておきます。

3つ目は技術情報の国外への提供です。経済産業省は、軍事転用が可能な貨物や技術が懸念のある相手に渡るのを防ぐため、外国為替及び外国貿易法に基づく安全保障貿易管理を行っています（安全保障貿易管理の概要）。一般的な業務システムやWebサービスの開発で問題になることは多くありませんが、暗号や制御、センサーなどの技術を含む案件では、委託先に渡す設計情報やソースコードが規制対象に当たらないかを確認する必要があります。同省は、規制対象かどうかの判定（該非判定）は行っていないと明記しているため（安全保障貿易管理のトップページ）、判断は自社の輸出管理の担当部署や専門家と行います。

契約：準拠法・権利・再委託・終わり方

契約は、問題が起きたときに初めて差が出る部分です。海外の会社と直接契約する場合、どの国の法律で解釈するか（準拠法）、争いになったらどこで解決するか（裁判所か仲裁か）を決めておかないと、トラブル時の話し合いの土台がありません。日本法人を窓口にして、その日本法人と国内の契約を結ぶ形にすると、この点の負担は小さくなります。

権利と納品物も明記します。作ったプログラムの著作権がどちらに帰属するか、ソースコード・設計書・テストの記録・開発環境の設定を何として受け取るかを書いておかないと、委託先を変えるときや社内に引き取るときに困ります。保守の委託先を変えるときに必要な資料の具体例は保守会社の変更の記事にまとめています。

再委託も確認が要ります。窓口の会社から別の会社へ仕事が流れていると、誰がコードを書き、誰がデータに触れるかが見えなくなります。再委託を認めるか、認める場合は事前に通知・承諾を求めるかを契約に入れます。最後に、契約を終えるときの引き継ぎの範囲と期間、アカウントとデータの削除の確認方法も決めておくと、終わり方で揉めにくくなります。

契約書を受け取ったら、少なくとも次の項目が書かれているかを確かめます。

単価差は実際にどれだけ残るか

オフショアの単価差は、ブリッジSEの費用と発注側の工数を足すと小さくなります。見積もりを比べるときは、プログラマーの単価だけでなく、チーム全体の月額と、発注側で必要になる時間をそろえて比べるのが基本です。

国別の人月単価

オフショア開発.comの国別単価ページ（最終更新2026年2月13日）に載っている、職種別の人月単価です。括弧内は同ページに記載の前年比です。

出典: ベトナム・フィリピン・インド・中国の各単価ページ（バングラデシュとミャンマーは各ページの他国比較表）。1人月あたり。

単価以外で国を比べるときは、使う言語と時差を先に見ます。日本語で進めたい場合は、日本語を話すブリッジSEを置けるかどうかが国より会社で決まるため、候補の会社ごとに担当者と面談して確かめます。英語で進められる社内体制があるなら、英語が公用語のひとつであるフィリピンやインドの会社も候補に入り、ブリッジSEを介さずに直接話せる範囲が広がります。中国は単価が6か国のなかで最も高く、前年比でも大きく上がっているため、単価差を目的にする場合は他国と比べたうえで選ぶのが現実的です。

前年比の振れ幅が大きい国がありますが、同ページは変動の理由を示していません。為替や回答した企業の構成が年ごとに変わる可能性もあるため、1年分の数字だけで「この国は安くなった」と決めず、実際の見積もりで確かめます。また、ブリッジSEの単価はプログラマーより高く、バングラデシュではプログラマーの2倍を超えています。ブリッジSEを何人、どの期間入れるかで総額が大きく変わります。

ベトナムが選ばれやすい理由と注意点

日本からの委託先として最も名前が挙がりやすいのはベトナムです。白書2025年版の目次には「ベトナム人気は継続も、選択肢の多様化が進む一年に」「ベトナム：安定的な上昇と信頼性の維持」という項目があります。上の表でもベトナムは、プログラマーの単価は6か国で2番目に高いものの前年比+1.8%、ブリッジSEは前年比±0%で、白書の見出しのとおり大きな上下は見られません。単価の動きが小さい状態が続くなら、複数年の予算を組みやすい点で発注側の利点になります。一方で、国の傾向は個々の会社の品質を保証しません。ベトナムに決めた後も、後で説明する質問で会社ごとに確かめる必要があります。

ブリッジSEと発注側の工数を足して比べる

ベトナムでプログラマー4人とブリッジSE1人のチームを組む場合を、上の表の単価で試算します。

プログラマーの単価だけを見ると40.1万円ですが、実際に手を動かす4人でチーム全体の費用を割ると、1人あたり約54.9万円で、プログラマーの単価の約1.37倍になります。現地のPMを別に置く見積もりなら、さらにPMの単価が加わります。

ここに発注側の工数が乗ります。仕様書を細かく書く時間、質問への回答、週次の確認、受け入れテストは、国内に頼む場合より増えるのが普通です。社内の担当者が週に何時間をこの仕事に使うかを見積もり、その人の社内での時間単価を掛けて足すと、国内の見積もりと同じ土台で比べられます。たとえば、仮に担当者が週8時間を使い、社内の時間単価を5,000円と置くと、月4週で16万円（8時間 × 5,000円 × 4週）がチームの月額に上乗せされる計算です。数字は仮置きなので、自社の実際の値に置き換えてください。この仮置きで足し合わせると、チーム全体は月235.4万円（219.4万円 + 16万円）、実装者1人あたり約58.9万円となり、プログラマーの単価40.1万円との差はさらに広がります。複数社の見積もりを同じ条件にそろえる手順は開発会社の見積もり比較の記事で、規模別の相場の見方は受託開発の見積もり相場の記事で解説しています。

オフショア開発に向く案件・向かない案件の判断表

オフショアに出すかどうかは、「仕様を文書で渡しきれるか」と「委託先に渡すデータや技術の機密性」の2つで決めると判断がぶれにくくなります。前者が品質とコミュニケーションの問題の起きやすさを、後者がセキュリティと契約の手間の大きさを左右するからです。

図の4つの区分を、判断の目安と例とともに表にします。

工程ごとに分けて出す

迷ったときは、案件全体ではなく工程や機能に分けて考えます。たとえば、要件定義と設計は国内で行い、仕様が固まった画面の実装とテストだけをオフショアに出す、という分け方は珍しくありません。全部を出すか全く出さないかの二択にしないことで、単価差と管理の負担の釣り合いを取りやすくなります。

工程ごとの分け方の目安は次のとおりです。

本番の個人データを渡さずに進めるには、開発とテストに使うデータを最初から分けておきます。項目の形だけを本物に合わせた架空のデータを用意する、本番のデータを使う場合は氏名や連絡先を置き換えてから渡す、委託先には本番環境へのアクセス権を付けず、本番への反映は国内側が行う、といった分け方が基本です。こうしておくと、先に説明した外国にある第三者への個人データの提供に当たる場面そのものを減らせます。

オフショア開発でよくある失敗と回避策

オフショア開発の失敗は、技術力よりも、仕様の渡し方と管理の仕組みの不足から起きることがほとんどです。よくある5つの形と、事前にできる回避策をまとめます。

伝言の段数による行き違いは「コミュニケーション」の節、開発環境やアカウントの管理は「セキュリティ」の節と、後の「最初の打ち合わせで聞くこと」も参考にしてください。どの失敗にも共通して効くのは、最初から大きな案件を出さず、1〜2か月で終わる小さな案件で委託先の仕様の読み方、報告の質、納期の守り方を確かめてから広げることです。オフショアに限らない開発の失敗の型はシステム開発の失敗事例の記事にまとめています。

オフショアから国内に切り替えるときの準備

すでにオフショアで進めていて、品質や進み具合の問題から国内に切り替えたい場合は、まず手元に何があるかを確かめます。切り替えが難しくなるのは、コードそのものより、コードの背景が委託先の頭のなかにしかない状態です。

• ソースコードの最新版が、自社の管理するリポジトリにあるか
• 設計書・仕様書が、実際に動いているコードと合っているか。合っていない部分はどこか
• テストの記録と、自動で動くテストがどれだけあるか
• 開発環境と本番環境の構成、使っているクラウドや外部サービスのアカウントの持ち主は誰か
• 委託先が持っている権限（リポジトリ、サーバー、外部サービス）の一覧と、外す手順

これらがそろっていない場合は、契約の残り期間のうちに引き継ぎの資料を作ってもらう作業を委託範囲に入れます。引き継ぎを受ける国内の会社には、そろった資料を見せたうえで、作り直すか直して使い続けるかの判断を求めると、見積もりの前提がはっきりします。

オフショア開発の進め方

オフショア開発は、検討から定常の運用まで、おおむね次の5つの段階で進めます。各段階の終わりに「次へ進んでよいか」を確かめることで、大きな案件をいきなり出す失敗を避けられます。

契約形態の選び方：請負とラボ型

オフショア開発の契約は、成果物の完成を約束する「請負」と、一定期間チームを確保する「ラボ型」（準委任の一種）に大きく分かれます。どちらが安いかではなく、仕様がどこまで固まっているかと、発注側に開発を指揮できる人がいるかで選びます。

白書2025年版の目次では、契約形態について「ラボ契約は微減も、SES契約が急伸」という項目と、「請負契約は安定的に推移、要件明確な案件で根強いニーズ」という項目が並んでいます。SESは、技術者の作業時間を提供する契約で、準委任として結ばれることが多い形です。アジャイルで少しずつ作る場合の契約と進め方はアジャイル開発の外注の記事で詳しく扱っています。

委託先を選ぶときに最初の打ち合わせで聞くこと

委託先を選ぶときは、実績の数よりも、自社の案件でどう進めるかを具体的に答えられるかを見ます。最初の打ち合わせで次の8つを聞き、答え方で判断します。

1. 似た業種・規模の案件で、最初の1か月に何をしましたか。発注側には何を用意してもらいましたか
2. ブリッジSEは誰が担当しますか。その人は実装者と同じ技術の話ができますか。面談できますか
3. 実装者と日本側が直接話す場はありますか。質問への返答はどれくらいの時間を目安にしていますか
4. コードレビューとテストはどのように行いますか。受け入れテストの観点は誰が作りますか
5. 開発環境への接続方法、アカウントの付け外し、ソースコードとデータの保管場所はどうなっていますか
6. 再委託はありますか。ある場合、どの会社にどの作業を出しますか
7. 契約はどの国の会社と結びますか。準拠法と、争いになったときの解決方法はどう書かれていますか
8. 契約を終えるとき、ソースコード・設計書・テストの記録・環境の設定をどの形で受け取れますか

質問1と4に、会社紹介の資料をなぞるだけの答えしか返ってこない場合や、質問5と6に「NDAを結んでいるので大丈夫です」という答えしか返ってこない場合は、慎重に考えたほうがよいサインです。委託先の評価の観点をもう少し広く知りたい場合は開発パートナーの選び方の記事も参考になります。

オフショア・国内開発・AIを使った開発の比べ方

オフショアを検討する理由が「国内では高い」「人が足りない」であれば、比べる相手は国内の開発会社だけではありません。AIのコーディング支援を使って少人数の国内チームで進める方法も、比べる候補に入ります。ただし、AIでどれだけ速くなるかは仕事の種類で大きく変わります。

GitHubは2022年に、95人の開発者を2つのグループに分け、JavaScriptでHTTPサーバーを書く課題の所要時間を比べた実験を公表しました。当時のGitHub Copilotを使ったグループは平均1時間11分、使わなかったグループは平均2時間41分で、55%速く終えたと報告しています（GitHubのブログ）。一方、AI研究機関のMETRが2025年に公表した実験（2025年2〜6月、当時のAIツールを使用）では、大規模なオープンソースの開発に長く関わってきた16人の開発者が、自分のリポジトリの実際の課題246件に取り組んだところ、AIの利用を許可した課題のほうが19%長くかかりました（METRの報告）。ただしMETRは2026年2月に続報を出し、元の結果は現在のAIの影響を反映していないとしています。続報では、2026年初めの開発者はより速くなっている可能性が高い一方、新しい実験は参加者の偏りが大きく、どれだけ速くなったかは測りきれていないと補足しています（METRの続報）。どれだけ速くなるかは、作るものの新しさや規模、使う時期のツールで変わるため、自社の案件で小さく試して確かめるのが確実です。

3つの進め方を比べると、次のようになります。

比べるときは、オフショアの委託先にも国内の開発会社にも同じ提案依頼書を渡し、同じ条件で見積もってもらいます。そのうえで、見積もりの総額に発注側の工数を足し、さらに「仕様が変わったときにいくら増えるか」「途中で委託先を変えるときに何が残るか」を並べると、単価だけでは見えない差が分かります。どの進め方も万能ではないので、工程ごとに組み合わせる前提で比べるのが現実的です。

koromoは国内でAIを使った開発と技術相談を行っている会社で、オフショア企業の紹介はしていません。そのため、オフショアと比べる立場にある点を踏まえて読んでください。Claude Code などのAIコーディングツールを開発に組み込む方法はAIコーディングで開発を速める記事で紹介しています。

相談をおすすめしたいのは、仕様が固まりきっていない新規開発で、オフショアの単価に魅力を感じつつ管理の負担に不安がある場合や、個人データを扱う案件でどこまでを外に出せるか整理したい場合です。反対に、仕様が固まっていて量の多い実装を安く進めたい場合は、オフショアの委託先に直接相談するほうが早く、まだkoromoへの相談は必要ありません。

よくある質問

オフショアに出すかどうかは、国や単価の比較から入るより、自社の案件を工程と機能に分け、どこを文書で渡せて、どこに機密性の高い情報があるかを書き出すところから始めると判断が早くなります。その整理ができれば、オフショアの委託先にも国内の開発会社にも、同じ条件で見積もりを依頼できます。