オフショア開発の進め方

こんにちは。ベトナムオフショア開発協会運営事務局です。

「オフショア先のエンジニアも、日々ChatGPTやCopilotのようなAIツールを使っているはず。顧客の仕様書やソースコードの扱いは大丈夫だろうか」——そんな声を、発注担当者の方からよく耳にするようになりました。

生成AIはもはや開発現場に欠かせないツールです。禁止しようとしても、現場では既に日常的に使われています。今回は、「厳格なルールを作って縛る」という話ではなく、オフショア開発ならではの事情を踏まえて「こういうことをやっておくと安心だと思います」という視点で、いくつかの工夫をご紹介します。

オフショア開発の現場で今、何が起きているか

ベトナムをはじめとするオフショア先のエンジニアも、ChatGPT、GitHub Copilot、Claude Codeといったツールを日常的に活用しています。コード生成、バグ修正、ドキュメント作成……生産性向上のためにAIを使うのは、もはや世界共通の当たり前になっています。

問題は「使っているかどうか」ではなく、「何を、どこまで入力しているか」が発注側から見えにくいという点にあります。

なぜオフショアだと少し気にかけたほうがいいのか

オフショア開発では、日々のやり取りがブリッジSE経由になることが多く、現場のエンジニア一人ひとりがどのツールをどう使っているかまで、発注側が直接把握するのは簡単ではありません。

加えて、次のような事情もあります。

• 委託先の国によって、個人情報保護やAI規制に関する法制度・意識に差があること
• 既存のNDA（秘密保持契約）の多くが、「第三者への開示」は想定していても「生成AIへの入力」までは触れていないケースが多いこと
• 納期のプレッシャーの中で、現場が効率化のためにAIツールへ気軽に情報を入力してしまう場面があり得ること

「言わなくても分かるはず」という前提は、オフショア開発においては少し危ういかもしれません。

想定しておきたいリスク

具体的には、次のようなことが起こり得ます。

機密情報・顧客データの漏洩

ソースコードや設計書、顧客の個人情報を無料版の生成AIツールに入力すると、そのデータが学習に利用されたり、意図せず外部に出てしまったりする可能性があります。

生成物の著作権・帰属があいまいになる

AIが生成したコードやドキュメントについて、権利関係がはっきりしないまま納品されることがあります。後になって「誰のものか」で揉める原因になりかねません。

契約上の取り決めと食い違う

業界によっては、顧客との契約で「生成AIの利用は事前申告制」といった条項が定められていることもあります。オフショア先がその存在を知らずに使っていると、話が食い違ってしまいます。

では、実際に何をしておくとよいのでしょうか。難しく考えず、次のようなことから始めてみることをおすすめします。

01使ってよいAIツールを、あらかじめ伝えておく

法人契約でオプトアウト設定（入力データを学習に使わない設定）ができるツールを案内しておくと、現場も安心して使えますし、発注側も余計な心配をしなくて済みます。

02「これは入力しないでほしい」を具体的に伝える

「個人情報」「未公開の仕様書」「本番環境の認証情報」など、抽象的な注意喚起ではなく、具体例を挙げて伝えると、現場のエンジニアにも伝わりやすくなります。

03NDAや契約書の文言を、一度見直してみる

既存のNDAに「生成AIサービスへの入力」も第三者提供に準ずる行為として触れておくと、あとで「そんな話は聞いていない」というすれ違いを防げます。難しい改定ではなく、一文追記するだけでも効果があります。

関連記事：ベトナムオフショア開発の秘密保持契約書で確認すべきポイント｜NDAひな形を公開

04キックオフ時だけでなく、折に触れて伝え続ける

一度説明して終わりにせず、プロジェクトの節目節目で軽くリマインドするくらいがちょうどよいと思います。言語や文化の違いがある分、「一度伝えたから大丈夫」とは考えないほうが安心です。

05たまに様子を聞いてみる

月次の定例会などのついでに、「AIツールはどんな感じで使っていますか？」と軽く聞いてみるだけでも、実態を把握するきっかけになります。監視というよりは、対話の延長として取り入れるとよいでしょう。

まとめ

生成AIの活用は、もはやオフショア開発においても止められない流れです。だからといって身構えすぎる必要はなく、「使ってよいツールを伝える」「入力してほしくない情報を具体的に共有する」「契約書に一文加える」「時々様子を聞く」といった、できるところから少しずつ取り入れていくことが、これからのオフショア開発とのつきあい方として現実的だと思います。