2018年頃からベトナムのオフショア開発において相談が増えてきた分野が「AI開発」です。特にChat GPTが公開された2022年末からは、生成AIブームにより、AIを組み込む開発依頼が多くなっています。
しかし一言でAI開発といっても「アルゴリズムを基礎研究するような内容」から「AI開発の一過程だけ（必要なデータの作成作業）」「既存のAIを組み込んだWebアプリ開発」まで幅広く、オフショア開発に向いていると考えられる分野と、あまり向いていないのではと考えらえる分野があります。
そこで今回は、ベトナムでのオフショア開発を活用してAI開発を考えている企業向けに、どういう分野が向いているのか（親和性があるのか）や、事前にどんなことに気を付けないといけないのかについて紹介します。
1. オフショア開発でAI開発を依頼する前の4つの前提条件
ベトナムでのオフショア開発でAI開発として「AIモデル自体の開発」を考える際に重要なポイントが4つあります。
発注する企業において、
（１）課題の明確化
AIを使ってどのような課題を解決したいのか（開発ゴール）が明確になっていること
（２）AIへの学習データの有無
開発ゴールのために必要なデータがあり、ベトナムのオフショア開発先へ提供できること
（３）自社内でAIの検証・評価ができること
自社内で開発したシステムの検証・評価ができる体制（能力）があること
（４）AI開発の進め方への理解と社内合意
AI開発を行うことについて、一般的な開発プロセスとの違いを自社内で理解ができていること
この4点になります。順を追って詳細を説明します。
（１）課題の明確化
AI開発をオフショアに依頼する前に、まず「何をいつまでにどこまで実現すれば課題解決と言えるのか」を明確にしておくことが最初の第一歩です。
課題が明確であれば、オフショア開発企業側から「ゼロからAIを作る必要があるのか」「既存のAIサービスで解決できるのか」「そもそもAIを使わなくても通常のソフトウェア開発で対応できるのか」といった提案もできます。これは開発費用や期間にも直結する重要なポイントです。
一方、課題が曖昧なまま依頼してしまうと、次の2つの問題が起きます。
開発が前に進まない：
「AIを使って何か面白いことをしたい」といった抽象的な依頼では、オフショア開発企業側も何をすべきかわからず、大きな体制を組む必要が生じて費用だけが膨らみます。
完成しても評価できない：
課題が不明確なまま開発を進めると、出来上がったAIが「課題を解決できているのか」を誰も判断できず、結果として失敗に終わるケースがほとんどです。
オフショア開発企業を探し始める前に、まず社内で課題を整理することが、AI開発を成功に導く出発点となります。
（２）学習データの有無
AIを開発するには、AIに学習させるためのデータが必要です。
文字・数字・画像・動画などさまざまな種類がありますが、確認すべきポイントは「データがあるか」と「そのデータをベトナムへ提供できるか」の2点です。
データがない場合：
まずデータを蓄積するシステムの構築からスタートになります。その分の時間とコストが余分にかかることを念頭に置いておきましょう。ネット上のオープンデータを活用する方法もありますが、利用条件の事前確認が必要です。
データはあるが、外部提供できるか不明な場合：
特に個人データや顧客データを含む場合は注意が必要です。開発が始まる直前に「データを出せない」と発覚するケースは少なくないため、事前に以下を確認しておくことを推奨します。
- 自社サービスの利用規約上、データを外部提供できるか
- 個人情報保護法などの観点から、海外への提供に問題がないか
- 必要に応じて、法務部門への確認を済ませておく
（３）自社内でAIの検証･評価ができること
オフショア開発先からAIモデルが納品された際、「このAIで良い（導入できる）」「まだ不十分（作り直しが必要）」という判断を、自社内でできる必要があります。
納品物には開発企業が実施した試験結果（いわゆる「精度」）が添付されていますが、その数値を見て合否を判断するためには、AIの精度がどのように測られているかを理解しておく必要があります。
AIモデルをテストすると、以下のような数字が出てきます。
- TN：OKを正しくOKと認識した数
- FP：OK を誤って NG と認識した数
- FN：NG を誤って OK と認識した数
- TP：NG を正しく NG と認識した数
AIモデルの評価には、主に2つの指標が使われます。
TP/（FP＋TP）＝ Precision（適合率）：
正常なものを間違えて異常と判断してしまわないかの指標です。例えば検品で正常品を異常品とよく誤認する場合、Precisionが低くなります。
TP/（FN＋TP）＝ Recall（再現率）：
異常なものを見逃してしまわないかの指標です。例えば検品で異常品をよく見逃してしまうようなケースは、Recallが低くなります。
この2つはトレードオフの関係にあります。
- 全てを異常と判定すれば、Recallは上がりますがPrecisionは下がります
- 全てを正常と判定すれば、Precisionは上がりますがRecallは下がります
どちらを重視すべきかは、発注元企業のビジネス内容によって変わります。例えば工場の検品であれば、Recallが重要でしょう。
そしてPrecisionとRecallの値が、それぞれいくつであればAIモデルとして導入できると判断するかが難しい点です。仮に〇〇%と定めることはできたとしても、「その数字であればなぜ課題を解決したと言えるのか」という根拠がはっきりしていないと、AIモデル開発の終わりが見えなくなってしまいます。
（４）AI開発の進め方への理解と社内合意
発注元の企業において、通常のソフトウェア開発と同じようにAI開発を認識していた場合、後日トラブルになるケースがあります。
通常の請負型ソフトウェア開発契約では、事前に仕様を明確に決めて、出来上がったものがその仕様に合致していなかった場合、修正を求めることができます。しかしAIモデルを作って組み込むような場合、全て100%正しく判別できるといった仕様で開発することはそもそも難しく、実現できないケースが多いです。
また前述のとおり、「どう評価するのか」という点についても発注元で理解が必要です。
例えば、自動撮影した写真から熊の頭数を自動で集計するAIを作るとします。この場合、考えられる誤りは以下の2種類です。
見逃し：
熊が写っているのにAIが熊と認識できず、カウントできない
誤検知：
熊以外の動物をAIが熊と誤ってカウントしてしまう
どちらを重視するかは、AIの目的によって変わります。
- 熊の出没検知による人の安全確保が目的の場合 → 見逃しを最小限にすることを優先
- 山奥での生息数調査が目的の場合 → 誤検知を最小限にすることを優先
このように「それぞれの数値がいくつになればAIモデルが完成したと判断できるのか」を発注元として事前に決めておく必要があります。またAIは実際に作ってテストしてみないと結果がわからず、改良を重ねても目標の数値に届かないケースもあります。
それゆえ、請負のように精度を仕様として約束して開発するのではなく、PoC（Proof of Concept：概念実証）という形で、まずは作って試してみることに対する役務提供の契約となるケースが多いです。
AI開発をする場合、以上のような点について発注元での理解が必要となります。
2. オフショアAI開発の得意・不得意分野と線引き
AI開発をベトナムでのオフショア開発で行う場合、得意と考えられる領域と、不得意（リスクが高い）と思われる領域があります。これは、一言で「AI開発」といっても基礎研究から既存AIを組み込んだ開発まで幅広い範囲を指す言葉である為です。
そこでベトナムオフショア開発において、得意･不得意、それぞれの分野について紹介し、そのうえで「できる」「できない」と判断するにあたっての線引きをしてみます。
◯：ベトナムオフショア開発で「得意」とする分野
（１）既存AIを活用したアプリケーション開発
近年OpenAI（ChatGPT）やGoogle（Gemini）など様々なAIが提供されており頻繁にバージョンアップされ機能も追加されているため、独自のAIモデルを作るのではなく、既存のAIをうまく活用するといったケースが多いです。
この既存AIと繋ぎこむことで、AIが組み込まれたWebサービスやスマートフォンアプリの開発と実装は、ベトナムオフショア開発の得意分野となります。
（２）AIモデルのファインチューニングや再学習
AIモデル自体を０から作るのではなく、既存のオープンソースモデル（Llama, Stable Diffusionなど）に対して、独自のデータを読み込ませてAIモデルを再学習やチューニングしていくといったケースです。
ベトナム国内にいるAIエンジニアも人材によってスキルに差がありますが、こういった分野であれば対応可能なエンジニアも多いです。
（３）MLOps（機械学習基盤）の構築・運用
開発したAIモデルを本番環境に配置し実際に利用可能な状態にした後、継続的にAIモデルを再学習させていく、そのためのクラウドインフラ（AWS、GCP、 Azure）の構築や運用といったケースです。
（４）コンピュータビジョン（画像認識・動画解析）の分野
AI技術を用いてコンピュータに人間の視覚機能を持たせて、画像や動画のデータから物体検知、分類、解析を行うといった分野です。製造業の検品（異物･不良品などの判別）や監視カメラの解析などのAIをつくるようなケースです。
日本語特有のニュアンスを考慮するといった言語の壁に依存しない分野となるため、AIモデル開発を進めやすいと考えられます。
×：ベトナムオフショア開発で「不得意」とする分野
高度な専門性、「日本語の深い理解」「日本特有の業務知識」が求められる領域は、ベトナムオフショア開発において不得意（苦手、リスクが高い）と考えられる分野となります。
（１）ゼロからのコアアルゴリズム開発や基礎研究
まったく新しい独自のAIモデルをゼロから設計・開発する、それができる人材となると博士号を持っていて世界的なコンテスト（Kaggle）などで上位に入賞したトップ層のAIリサーチャーが必要となりますが、こういった人材は世界中で奪い合いであり、ベトナムにおいても特にオフショア開発先の企業などから確保するのは難しいです。
（２）高度な日本語ニュアンスが求められる自然言語処理（NLP）AI開発
例えば、
- 生成された日本語の文章が、日本のビジネス習慣や敬語として適切かどうか？
- 日本において法的にグレーとなる表現はないか？
このような日本語及び日本のビジネス環境についての高度な専門性を要求される分野を、そもそも日本語を母国語としていないベトナム人エンジニアで開発する場合、品質の評価や担保が困難となります。
（３）要件や課題があいまいなAI開発
既に見出し1で述べたような、何かAIを使って面白いことをやってみたいというケースです。
このようなケースでは、作るもの自体が決まっていないため、アイデア出しやビジネスモデルを1から考えていくことになります。これをオフショア開発のベトナム人エンジニアと考えて進めていくというのは、コミュニケーションコストだけが膨大となり、向いていないと言えるでしょう。
得意・不得意分野のまとめ
以上で述べた点を踏まえると以下の様な形で線引きできます。
| AI開発において | オフショア向き（できる） | オフショア不向き（できない） |
| 技術面 | 既存技術の組み合わせやシステム実装 | 新しいアルゴリズムの研究や開発 |
| 言語・文化依存 | 画像・数値といった非言語データ | 高度な日本語や日本特有の暗黙知を判断 |
| 要件の明確さ | 課題、仕様やゴールが明確 | 何をすべきか自体を含めて探索していく |
3. AI開発で避けるべきオフショア開発会社の5つの特徴
AI開発といっても、既存AIを活用・連携したアプリケーション開発の場合は、通常のオフショア開発会社を選ぶのと同様の判断となります。
しかし、新しいAIモデルを作る・既存のAIモデルを再学習させたりチューニングしていく、といった開発の場合は注意が必要です。前述のとおり発注元の企業においてもAI開発への理解が必要ですが、仕事を受けるオフショア開発会社側も、事前にそのことを発注元へ説明し、認識を合わせておく必要があります。
これをしていないオフショア開発会社の場合、後々トラブルを生む可能性が高いためです。
例えば以下のようなトラブルです。
- 「AIができた・できていない」という認識のズレ
- 「この予算ではこれ以上できない」「それでは困る」といった費用面での食い違い
よって、こういった事前説明・認識合わせができていないオフショア開発会社への依頼は避けるべきでしょう。
他にも以下のような会社に対しては、AIモデル開発を依頼する場合、注意が必要となります。
（１）AIモデル自体の開発実績の有無
既存AIを活用･連携したアプリケーション開発実績だけをもって、AI開発の実績があるとしてAIモデルを作ることもできると言っている場合は、AIモデル自体の開発実績、AIモデルの学習やファインチューニングの実績、RAG（検索拡張生成）の構築実績など掘り下げて確認していく必要があります。
（２）AIエンジニアの有無
在籍しているエンジニアの肩書がWEB、バックエンド、アプリエンジニアだけでありながら、AIエンジニアがいると言っている場合は、在籍しているというAIエンジニアの過去の開発経験や、大学などでの専攻（数学、統計学、コンピュータサイエンスなど）についても確認した方が良いです。
（３）PoC（概念実証）において、請負型の見積提示
既に述べたようにAI開発の初期段階では、PoC（Proof of Concept：概念実証）という、まずは作って試してみる事に対する役務提供の契約となることが多いです。これは、AIを実際に作ってみないと、精度も含めて分からないためです。
しかし請負型開発の様に、AIを作る（試す）前から精度を仕様として約束した見積もりを出してくる会社であった場合、精度が目標に達しなかった場合の進め方やアプローチ方法などについて確認をした方が良いです。
（４）ブリッジ人材にAI開発にあたっての知識や経験があるか
オフショア開発ですのでAIエンジニアは、日本人ではなく、AIエンジニア自身が日本語で会話をできることは稀です。その際、日本の発注元の担当者とAIエンジニアとの間でのコミュニケーションに入るのが、ブリッジと呼ばれる日本語が話せる人材となります。
しかしこのブリッジ人材にAI開発の知識が無い場合、発注側の意図をAIエンジニアへ正しく伝えることができなかったり、逆にAIエンジニアの説明にある技術的な内容を理解できずに日本語で分かりやすく説明できないという事も発生します。それゆえ、ブリッジ人材のAIに対する知識と経験についても確認をした方が良いです。
（５）セキュリティ対策についての説明や安心感
AIに学習させるデータが機密情報や個人情報といったデータである場合もありますが、それを扱うオフショア開発企業において流出が発生してしまった場合、大きな損害が発生してしまいます。
そのため、ISMS（ISO27001）などの国際的なセキュリティ認証の取得の有無や、データの取り扱いに関するルールの有無（ある場合は、その詳細）などについても確認をしておいた方が良いでしょう。
4. PoC（検証）を設定してAI開発を進める方法
AI開発に限らず、開発においてはいきなり大規模な開発に取り掛かるのではなく、まずは小規模であってもPoC（Proof of Concept：概念実証）を1度やってみることをお勧めしております。
PoCにより実際に動くもの（AIモデル）が出来上がれば、頭の中での想像ではなく、実際にそれを使っての検証ができます。精度という数値データだけでの評価にとどまらず、体感としてどの程度使えそうかも見えてきますし、改善すべき点や、その後のシステム開発・ビジネス展開もよりクリアになっていきます。
具体的な事例で説明します。
「来店客から店員の表情があまりよくないという声が上がっており、売上にも影響していると考えられる。店員が笑顔で接客できるよう改善したいので、笑顔を計測できるAIを作りたい」という相談があったとします。
この場合、最初から店舗で使うシステム全体を作るのではなく、まずは笑顔を計測できるAIモデルが動作して簡単に確認できるところまでをPoCの範囲※とします。
以下のリンクは、実際に弊社が作った顔感情認識AI「MAL FaceEmotion」のデモです。
https://faceemotion-demo.vitalify.asia/
ブラウザ上でAIが動作し、PCのカメラ映像をもとに感情値が変化します。画面に顔が映ったら表情を変えてみると（Happy）の数値が変化します。これを笑顔の計測値だと考えてみてください。なおAIはブラウザ上だけで動作し、画面に映る表情やデータは外部へ送られないためご安心ください。
頭の中でイメージしていた「笑顔の計測」が、実際に試してみることでより具体的になったのではないでしょうか。
このPoCに取り掛かる際は、「どこまで実現できたらPoCが完了したといえるか」というスモールゴールを事前に設定したうえで進めていくことになります。
※PoCではAIモデルだけを作って評価するケースも多いですが、今回はわかりやすいようにブラウザ上で確認できるところまでをPoCとしています。
