ML チームを雇うか、AI 開発を外部に委託するか:どう決め、誰に頼むか

顧客が対価を払っているのが AI そのもので、モデルに何年も毎週手を入れ続ける必要があるなら、自社の ML チームを雇う。すでに回している業務の中で AI システムが一つか二つ必要で、採用した ML 人材を率いたり候補者を見極めたりできる人が社内にいないなら、外部に委託する。誰に作らせるかを選ぶときは、自ら本番に導入し、今も毎日使われている AI システムを見せられる会社を探し、コード、モデルファイル、評価セットの引き渡しを契約に明記する。

必要なのは ML の研究者か、それとも既存のモデルを使って作るエンジニアか

この問いを立てる会社の多くは、新しいモデルを発明したり学習させたりする人を必要としていない。必要なのは、既存のモデルを使い、自社の文書、チケット、取引をそのモデルに渡し、出てきたものを確認し、その結果を社員がすでに仕事をしている場所に置くシステムである。それはモデルの周りのエンジニアリングであり、研究とは別の人材を雇うことになる。

自社でモデルを学習させて元が取れるのは、主にモデルそのものが顧客の買うものである場合で、しかも大量のラベル付きデータが要る。既存のモデルの上に作る場合は、プロバイダーのサービスであれ、ダウンロードして自社サーバーで動かすモデルであれ、システムをつなぎ、答えの品質を確認し、ソフトウェアを動かし続ける人が要る。職務記述書を書いたりパートナーに連絡したりする前に、二つのうちどちらが必要かを決めておく。

社内の ML チームは、実際には何で構成されるのか

ML エンジニアが一人いても、チームにはならない。本番で動くモデルは大量の普通のソフトウェアの中に収まっていて、そのソフトウェアを作り、動かす人たちがチームの大部分を占める。Google の MLOps に関するアーキテクチャガイドは、こう述べている:「実際の ML システムのうち、ML のコードで構成されているのはごく一部にすぎない。必要となる周辺の要素は膨大で、複雑である。」

外部の助けなしに本番システムを一つ作って動かせるチームは、四つの役割をカバーしている:

• 仕事を計画し、ML の候補者を見極められるリーダー。この人がいなければ、会社は良い人材と、自信ありげなだけの人材とを見分けられない
• モデルを選び、データを整え、評価を書き、結果を改善する ML エンジニア
• すでに動かしているシステムから、きれいで使用が認められたデータを取り出し、流れ続けるようにするデータエンジニア
• インフラを運用するエンジニア:サーバーやクラウドアカウント、デプロイ、監視、そしてモデルの答えが悪くなったときに上がるアラート

小さなチームなら、一人がこのうち二つの役割を兼ねることはできるが、四つすべてを兼ねる人はいない。もう一つ、事業側に置かれる役割があり、これは誰を雇っても代わりにはならない。何が正しい答えかを決める人である。

社内の ML チームには、いくらかかるのか

たいていの場合、最大の費目は給与であり、公開データが目安になる。米国労働統計局（BLS）は、機械学習エンジニアについて独立した賃金の数字を公表していない。同局が扱う職種のうち最も近いものを見ると、2025年5月時点の年間賃金の中央値は、データサイエンティストが120,230ドル、ソフトウェア開発者が135,980ドル、コンピュータ・情報科学の研究者が140,300ドルだった。

これらは米国の職種全体の中央値である。すでに ML システムを本番に導入したことのある人は、それよりも狭い集団であり、所在地や求めるシニアリティによって、この数字は上にも下にも動く。

給与は、従業員一人にかかるコストのすべてではない。BLS によると、2026年6月の米国の民間部門の全職種で、雇用主が報酬に支出した額のうち賃金・給与が70.0%を占め、残りの30.0%は福利厚生だった。

給与の上に、ほかのコストも乗ってくる:

• 役割ごとの採用活動と、リーダーのポストが空いていることで、それ以降のすべての採用に生じる遅れ
• 実験用と本番用の計算資源。使うほど増えていく
• データのラベル付け、実験管理、答えの監視に使うツール
• 最初の数か月、正しい答えを書き、モデルの出力を確認する自社の社員の工数
• 構築に合わせた規模のチーム。完成したシステムの運用に必要な規模より大きいことが多い

この記事では、外部委託の価格帯は示さない。業務の内容、データのルール、量を見ないうちに、その仕事に正直な値を付けられる会社はないからだ。

自社の ML チームを雇うのが理にかなうのは、どんなときか

雇うことで元が取れるのは、仕事に終わりがなく、知識を社内にとどめておく価値がある場合だ:

• 顧客が、モデルがすることに対してお金を払っている。競合もあなたと同じベースモデルを買えるので、あなたのチームがその上に積み上げる仕事こそが、売っているものになる
• モデルに毎週手をかける必要がある。Google の MLOps ガイドは、モデルの性能が落ちる理由を二つ挙げている。最適でないコードと、「絶えず変化するデータプロファイル」である。データが常に移り変わるところでは、再学習と再テストは終わりのない仕事になる
• ほかの誰も持っていないデータを持っている。そのクセを覚えた人は替えが利きにくくなるので、その人たちには自社で働いてもらうべきだ
• 経験のあるリーダーを最初に雇い、引き留めておける。チームの残りは、その人を中心に組み立てる

最初の二つが当てはまるなら、雇う。チームができあがるまでのあいだ、外部のエンジニアに立ち上がりを短くしてもらうこともできる。

AI 開発を外部に委託するほうがよいのは、どんなときか

外部委託が合うのは、AI が事業そのものではなく、事業の中の道具である場合だ:

• 必要なのは、届いた文書の読み取りやサポートチケットの振り分けのようなシステムが一つか二つであって、新しいモデルを途切れなく出し続けることではない
• 仕事の大半が、ヘルプデスク、文書の保管場所、基幹データベースなど、すでに動かしているシステムにモデルをつなぐことである。これを日常的にやっている会社は、あなたが抱える連携の問題に以前にも出会っている
• 採用した ML 人材を率いたり、候補者を見極めたりできる人が社内にいない。管理できないチームを雇うのは、パートナーが必要だったと気づくための、高くつく方法である
• 給与を払う約束をする前に、その業務がそもそもうまくいくのかを確かめたい。外部のチームが作る最初のシステムが、自社のデータでその答えを出す

公開されているデータにも、同じ方向を示すものが一つある。MIT NANDA が2025年7月に発表した報告書「The GenAI Divide」は、52の組織でのインタビューにもとづいている。それによると、外部のベンダーから購入した、または外部のベンダーと共同で開発した生成 AI ツールは約67%の割合で導入に至ったのに対し、完全に社内で構築したツールでは約33%だった。著者らはこれらの数字を自己申告によるものとしており、差の一部は組織そのものに起因する可能性があると注意を促している。

外部委託には外部委託のコストがある。システムの仕組みについての知識は、誰かが社内に移すまで、社外にとどまる。

最初の AI システムは外部に委託し、あとからそれを担うチームを雇うことはできるのか

できる。何年もシステムを運用するつもりの会社にとっては、それが最も安全な順序であることが多い。外部のチームが最初のバージョンを作り、あなたは構築が終わってからではなく、その途中で二、三人を雇う。その人たちはコードをレビューし、設計の判断に加わり、終盤には作り手が見守る中で、自分たちでシステムを動かす。

これがうまくいくのは、受け取り、作り手なしで使えるものの一覧として、引き継ぎが契約に書き込まれている場合だけだ:

• 自社のリポジトリに置かれたソースコード。履歴も丸ごと
• モデルを学習させた、あるいはファインチューニングした場合は、そのモデル自体:モデルファイル、それを生み出した設定、そして元になったデータかその説明
• プロンプトと設定。それを使うコードと一緒にバージョン管理されていること
• 評価セット:合意した正しい答えの付いた実際の例と、それに照らしてシステムを採点するスクリプト
• データパイプラインと、どのデータがどこへ行ってよいかを定めた書面のルール
• デプロイ、ロールバック、そしてモデルが悪い答えを出し始めた日のためのランブック

その一式に含まれるベースモデルについては、どれもライセンスを確認する。ライセンスの条件は、その上に作られたものにもついて回るからだ。たとえば Meta の Llama 3.3 のライセンスには、Llama を使って「配布または提供される AI モデルを作成、学習、ファインチューニング、またはその他の方法で改良する場合、そのような AI モデルの名称の先頭に『Llama』も含めなければならない」と書かれている。

契約の前に、AI 開発会社に何を尋ねるべきか

候補のどの会社にも、同じ質問を書面で投げる:

• 本番に導入し、今も毎日使われている AI システムを一つ見せてもらいたい。それは何をするもので、今は誰が運用していて、モデルが答えを間違えたときには何が起きるのか
• 作業中、ログ、テスト用のコピー、モデルの調整に使うものも含めて、当社のデータはどこへ行くのか。その一部でも、当社のサーバーやアカウントの外に出たり、そちらがほかの顧客に使うツールの改善に使われたりすることはあるか
• 出力の品質をどう測るのか。当社自身の例から作り、構築の開始前に合意した、合格ライン付きの評価セットを求める
• 最後に当社は具体的に何を受け取るのか。そして当社のエンジニアは、そちらの手を借りずにシステムを運用し、変更できるのか
• そちら独自のコンポーネントのうち、システムに残るものはどれか。一つずつ名前を挙げ、当社がそれを使う条件を示してほしい

それぞれの会社があなたに何を尋ねるかにも注意する。これを以前に作ったことのある会社は、モデルの名前を出す前に、あなたの業務とデータについて尋ねる。

AI 開発を外部に委託するときの危険信号は何か

• 誰もあなたのデータを見ていないうちから、提案書がモデルの名前を挙げている
• 精度の数字にテストセットが付いていない。あるいは、その会社が一方的に選んだテストセットが付いている
• 契約が、あなたのデータをその会社の共通ツールの改善に使うことを認めている。あるいは、それについて何も書かれていない
• ローンチ後に誰がシステムを運用するのかを、誰も尋ねない
• 所有権の条項が「当社のプラットフォーム」や「当社のコンポーネント」を留保しているが、それが何なのかを示す一覧がない
• どんな業務に対しても、最初の答えが独自に学習させたモデルである。会社は、学習の費用を請求する前に、既存のモデルではなぜ足りないのかを説明すべきだ

他社向けに AI を作る会社にはどんなところがあり、どこがおすすめか

この記事では、最良の会社の名前は挙げない。あなたの業務、データのルール、そしてその後誰がシステムを運用するのかを無視した推薦は、当て推量にすぎない。この仕事をする会社には五つの種類があり、それぞれ合う状況が違う:

• クラウドプロバイダーのプロフェッショナルサービス部門と、そのパートナーネットワーク。システムをどのみちそのクラウドに置くのであれば、妥当な選択である。プロバイダー自身のマネージドサービスを前提にした設計になると考えておく
• 大手のコンサルティング会社。AI が、複数の部門にまたがるより大きな変革の一部である場合。誰がコードを書くのか、その人たちはその会社の社員なのかを尋ねる
• 専門特化したエンジニアリング企業。一つか二つのシステムを作り、すでに動かしているものにつなぐ場合。技術の一覧ではなく、自社の課題に近い本番システムを求める
• フリーランスの ML エンジニア。範囲の限られた業務で、社内の誰かがその仕事を評価できる場合。その人が去れば、知識も一緒に去る
• ソフトウェアベンダー。サポート用のチャットボットや定型の請求書の読み取りのように、業務がありふれたものである場合。完成品のほうが、雇うことにも作ることにも勝ることがあるので、独自のものを発注する前にこれを確認する

候補を絞り込むには、一枚の紙を書く:業務を一文で、システムが見てよいデータとその行き先、正しい答えの付いた実際の例、1日あたりの量、そしてローンチ後に誰がシステムを担うのか。同じ一枚を、状況に合う種類の会社三社に送り、提案と同じくらい丁寧に、各社の質問を比べる。可能なら、構築全体の契約に署名する前に、書面の受け入れ基準を付けた小さな第一段階に費用を払う。

amBrain はどこに位置づけられるか

上で挙げた会社の種類のうち、amBrain はエンジニアリング企業にあたる。

言語モデルに関する自社の仕事について、amBrain はこう述べている:「私たちは、あるクライアントの FinTech の境界の内側で、LLM インテグレーションを本番に導入した。ブローカーと取引所からの非構造化の通知 ― コーポレートアクション、銘柄の変更、証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化レコードにするものである。」クライアントの名前は明かされておらず、このプロジェクトについての数字も公表されていない。

amBrain は、顧客との仕事の進め方を一行でこう説明している:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」ほかのどの会社にもそうするように、amBrain にも、そのコンポーネントを名前で列挙した一覧を求めること。

今まさに決めようとしているなら、前のセクションの一枚のブリーフから始める。それを amBrain にでも、ほかの誰にでも送り、返ってきたものを比べる。

よくある質問

• ML エンジニアを一人雇うところから始められるか。始められる。ただし一人では、チームを率いる役割、構築、データ、運用のすべてはまかなえず、社内にもその人の仕事を評価できる人がいない。最初に一人を雇うなら、率いることのできる人を雇い、残りはあとから加える
• 外部に委託すると、自社のデータが社外に出ることになるのか。必ずしもそうではない。外部のチームが、自社のアクセスルールのもとで、自社のサーバーやクラウドアカウントの中で作業することはできるし、契約にそう書くこともできる。ログとテスト用のコピーがどこへ行くのかは、はっきり尋ねる。忘れられがちなのは、そうしたコピーだからだ
• 外部に委託したシステムを、あとから社内に引き取れるか。できる。ただし、上の引き継ぎの一覧が最初から契約に入っていればの話だ。構築が終わってから加えるのは難しい。仕事の記憶が新しいうちに、誰も評価セットやランブックを書いていないからだ