内製か、購入か ― 自前のAIハーネスへの投資をどう判断するか

生成AIツールを内製するか購入するか。この問いに対して国内でよく見るのは「内製はカスタマイズ性が高いがコストがかかる、購入は早いが柔軟性に欠ける」というメリデメ比較表だ。だがこの表は、今のAI市場の最も重要な前提を織り込んでいない。モデルもツールも、数ヶ月単位で最有力候補が入れ替わるという前提だ。本稿では海外の実装現場の元記事を起点に、内製vs購入という二項対立の外側にある判断基準を示す。

なぜメリデメ表では内製・購入を決められないのか

内製・購入のメリデメ表が機能するのは、比較対象が安定している場合に限られる。ERPやCRMのように製品の世代交代が数年単位の領域なら、今日の比較表は来年も概ね有効だ。

生成AIはそうではない。オープンソース LLM はクローズドモデルにいつ追いつくのか ― 追従期間が世代ごとに半減する SemiAnalysis の時代区分で取り上げたSemiAnalysisの分析によれば、オープンソースモデルが各時代の先行クローズドソースモデルに最初に追いつくまでの期間は、世代ごとに半分になるという。原文で確認できる数字は、推論時代のDeepSeek R1（初期の差は12.1ポイントで、R1-0528が2025年5月に埋めるまで8.5ヶ月）と、エージェント時代のKimi K2.6（Opus 4.5を4.8ヶ月で上回る）・GLM-5.2（GPT-5.2を6ヶ月で上回る）の4.8〜6ヶ月である。ここから本稿は、「どのモデル・どのツールが優れているか」という比較の賞味期限が、稟議から導入完了までのリードタイムより短くなりつつあると読む。

この環境で「A社製品とB社製品と内製案を比較して最良の1つを選ぶ」という意思決定をすると、選定が終わった時点で前提が古くなる。問題は選択肢の中身ではなく、比較表という意思決定の形式そのものにある。

海外の実装現場は何を内製し、何を買っているか

では実際に内製へ踏み切った企業は、何を作っているのか。社内 AI アシスタントは自作すべきか購入すべきか ― Headway が Claude Code SDK で「Eddy」を自社構築した判断基準で取り上げた米Headway（900人規模のメンタルヘルスケア企業）の事例が示唆的だ。同社はセキュリティ・コンプライアンス・ワークフロー要件を満たすベンダー製品が存在しなかったため、Claude Code SDKの上に独自AIアシスタント「Eddy」を構築した。900人のうち650人が日次利用し、3月2日の最初のコミット以来、約26万件の会話を処理している。

注目すべきは内製の中身だ。HeadwayはモデルそのものもコーディングエージェントもAnthropicから「買って」いる。自社で作った中心は、会話ごとに使い捨てるDockerコンテナによる隔離実行環境、Snowflakeへの読み取り専用アクセスといった権限制御、MCPによるFigma・Snowflake連携という、モデルの周囲を固める運用層である。同時に同社は、ベンダーが通常担う信頼性維持や新しいAI能力への追従を自社で背負い続ける代償も明確に認識している。

もう1つの事例として、AIエージェントでエンジニアチームを何人分置き換えられるか ― Codex カスタムエージェントによる「1人企業」の実例で取り上げたMonologue開発者のNaveen Naiduは、Codexという購入したプラットフォームの上に、Webエンジニア・カスタマーサポート・グロース戦略家という自作のカスタムエージェント群を構築している。各エージェントは、専用のAGENTS.mdやスキル、コードベースを持つCodexのプロジェクトである。同記事によれば、それまでは複数のエージェントにまたがる作業のたびにMarkdownファイルと指示を手作業で移していたが、GPT-5.6がコンテキストをよく汲むため、関連情報を別のプロジェクトへ送って新しいタスクを始めさせる指示が一つで済むようになった。

2つの事例に共通するのは、内製と購入が二者択一になっていない点だ。モデルという最も入れ替わりの激しい層は買い、権限設計・ワークフロー統合・エージェントの役割定義という自社固有の運用層——いわゆるハーネス——を作っている。

何を判断基準にすべきか ―「作る力」ではなく「乗り換えられる設計」

この構図を判断基準として言い直すと、問うべきは「自分の組織に作る力があるか」ではなく「モデルやツールを乗り換えたとき、何が生き残る設計になっているか」である。

SemiAnalysis自身が、自社の合成スコアではKimi K3がFable 5を上回るかもしれないが、日常業務ではFableを使い続けたいと明かしている。理由の一部は、AnthropicがClaude CodeやClaude Tagといったハーネスでモデルを製品として仕上げていることで、より大きな理由は、ベンチマークが実際の仕事の完全な代理にならないことだという。本稿はここから、モデルの性能差が数ヶ月で埋まる一方で、権限境界の設計、評価基盤、ワークフローへの統合度は一朝一夕に埋まらないと読む。競争優位の源泉が前者から後者へ移っている、というのが本稿の見立てである。モデル単体の選定に悩んでいるなら、以前Claude と GPT、業務での使い分けをどう決めるかで論じた通り、使い分けの基準づくり自体をハーネスの一部と捉えたほうがよい。

逆に、購入したツールのベンダー固有APIにプロンプト資産や評価データを密結合させてしまえば、それは形式上「購入」でも、実態は乗り換え不能な資産の塊であり、モデル交代のたびに価値が目減りする。内製か購入かというラベルより、次の3点で投資案件を審査するほうが実効性がある。第一に、モデルを差し替えたとき何日で切り替えられる構造か。第二に、プロンプト・評価データ・権限設計はベンダー非依存の形式で自分の組織に残るか。第三に、Headwayが受け入れたような継続的な保守負担を、誰の予算と人員で担うのか。

まとめ: 投資判断の単位はツールではなくハーネス

生成AIの内製化判断は、個別ツールの採否として稟議に載せると必ずメリデメ表の議論に戻ってしまう。投資判断の単位を「このツールを作るか買うか」から「モデルを差し替え可能なまま活用し続けるための自前ハーネスに、いくら投じるか」へ引き上げることが、モデルが数ヶ月単位で入れ替わる市場での唯一の安定した判断軸になる。ハーネス投資の効果測定をどう経営会議に通すかは、生成AIのROIをどう経営会議に通すか ― 海外の実証データと評価軸の作り方で扱った評価軸の設計とあわせて検討してほしい。次の予算サイクルで問うべきは、ツールの比較表ではなく、乗り換え可能性を残す設計に責任を持つ担当と予算を置いているか、その一点である。