第1回で「捉え方」を、第2回で「判断」を扱ってきました。全3回の最終回となる本稿は、第2回の最後で予告した、まだ蓋を開けていなかった箱――「モデルをどう調達するか」を扱います。トークン課金には変動費と固定費という二つの経済形態があり、その選択は「どう作るか」とも「何を作るか」とも独立した、第三の判断です。

【第1回・第2回のふりかえり】
第1回では、AI-assisted（道具の足し算）とAI-native（プロセスの再設計）は構造が違うことを見ました。第2回では、成果物にはNon-AI型／AI組込み型／Agentic型の三つの形があり、開発時費用は開発プロセス軸が、稼働時費用は成果物軸が決めることを整理しました。そのどちらの場面にも「トークン課金」が顔を出しました。では――そのAIは、誰のインフラで動くのでしょうか。

本稿の結論三つを先にお伝えします。

「AIを導入する」という判断を、前2回で二つに分解しました。どう作るか（開発プロセス）、何を作るか（成果物）。本稿はそこに三つ目を足します――その中で動くAIモデルを、どう調達するか。この三つ目は、前の二つが決まった後に自動的に決まるものではありません。どの成果物形態でも、どの開発プロセスでも、クラウドAPIとローカルLLMのどちらも選べる。つまり独立した判断です。そして費用構造を扱った第2回の議論は、実はこの軸を決めて初めて完結します。

モデル調達という第三の軸

調達の選択肢は、大きく二つの経済形態に分かれます。フロンティア各社のモデルをAPI経由で使う変動費型と、オープンなモデルを自組織のインフラで動かす固定費型（ローカルLLM）です。

変動費か固定費か、という経理の違いは入口にすぎません。本当の分かれ目は、モデルの運命を誰が握るかです。API型では、モデルがいつ更新され、挙動がどう変わり、いつ提供終了になるかを、提供者が決めます。品質も価格も他律です。ローカル型では、モデルのライフサイクル――選定、更新、回帰テスト、引退――を自分が背負う代わりに、その全てを自分で決められます。第2回の軸4（技術リスク）で触れた、モデル更新で作業指示書が崩れた私たちの実例も、更新の時期と内容を他律で迎えたことが引き金でした。なお、この「モデルの運命を誰が握るか」という問いを、データ・基盤・モデル・運用の全体でどう設計するかという論点はAI主権と呼ばれ、その統制権を自組織側に確立するアプローチがPrivate AIです。

三形態との相性 ―― きれいに非対称

調達軸は成果物三形態と独立に選べますが、相性は均等ではありません。ここに、この軸のいちばん面白い構造があります。

AI組込み型×ローカルLLM ―― 構造的な最適点

ローカルLLMが最もきれいにはまるのは、AI組込み型です。理由が三つ重なります。

Agentic型×ローカルLLM ―― リスクの転化

Agentic型では、話が反転します。財務的には、青天井問題が解決するように見えます――容量が物理的な上限になるため、第2回で述べた「上限を設ける設計」がハードウェアで実現されるからです。しかし、多段推論の予測不能性そのものは消えません。読めなさは、費用の問題から、レイテンシ・スループット・処理待ちの詰まりという運用の問題に姿を変えるだけです。加えて、Agentic型は処理の流れの判断自体をモデルに委ねるため、フロンティアモデルとの推論力の差が最も痛い場所でもあります。

判断式は「高頻度×狭タスク×閉域要件」です。この三つの条件が揃うほど、ローカルLLMに分があります。逆に、低頻度で、タスクが広く、データの制約もないワークロードなら、API型が素直な選択です。ワークロードごとに、この式に当てはめて考えます。

盲点 ―― 開発そのものが、最大のAIワークロード

ここまで稼働時、つまり成果物の話をしてきました。しかし調達軸が最初に効いてくるのは、実は開発プロセスの側です。第1回で見た通り、AI-native開発では複数のエージェントが開発期間中ずっと回り続けます。つまり、開発そのものが「稼働時AI」化する――組織にとって最大のAIワークロードが、作っているシステムではなく、作っている行為の側に現れるのです。

ここに、二つの圧力が同時にかかります。一つは費用。第2回の社内検証で述べた通り、開発時のAI利用料は従来の感覚では収まらない規模になりえます。もう一つは流出です。AI-native開発は、その構造上、コードベース全体と業務文脈を、外部モデルに継続的に渡し続けます。コードは多くの企業にとって虎の子であり、こちらは費用と違って、予算では解決できません。開発側ローカルLLMの検討は、この二重の圧力から始まります。

ただし、正直に線を引いておきます。開発ワークロードの中身は一様ではありません。計画や生成の中核となる重い推論は、フロンティアモデルとの品質差が大きく、当面ローカルに寄せにくいのが実情です。現実解は、コード補完・埋め込み・定型的な検証のような高頻度×低難度の呼び出しをローカルに逃がし、重い判断はフロンティアに残す――変動費の“裾野”を固定費化するハイブリッドです。前章の判断式（高頻度×狭タスク×閉域要件）が、開発側にもそのまま効いていることに気づかれると思います。

代償を知る ―― 無償の選択肢はない

第2回で「Agentic型はランニングコストを引き受ける覚悟が必要」と述べました。調達にも、同じ構図があります。API型は、変動費と他律を引き受ける覚悟。ローカル型は、運用を引き受ける覚悟。どちらを選んでも、何かを引き受けます。両者の代償を並べて比べます。

そして、覚悟には見返りがあります。ただしそれは、特化モデルそのものではありません。ファインチューニングで作り込んだモデルそのものは、いずれ次世代の汎用モデルに追いつかれ、追い越されていきます。しかし、残るものがあります――データです。業務を考え尽くして構造化した教師データと評価データ、そして人間の修正が蓄積し続ける運用ループ。振り返れば、フロンティアAIを生んだのは、公開ウェブと、私たち一人ひとりが消費者として無料サービスと引き換えに渡してきたデータの集積でした。データが最も価値ある原資であることは、フロンティアモデルの存在自体が証明しています。一方で、企業の業務データ――判断の理由、失敗の記録、文書化されない現場のルール――は、その中に入っていません。世界最高のモデルも、あなたの組織の仕事はまだ知らない。モデルを運用し続ける組織だけが、この未開拓の原資を教師データとして蓄積し、より良い基盤モデルが登場するたびに、その上で自社仕様を作り直せます。覚悟の見返りは、特化モデルという製品ではなく、いつでも特化をやり直せるデータという資産です。

まとめ ―― 連載を閉じるにあたって

第3回の要点は三つです。

連載を通じて渡したかったのは、三つの問いです。どう作るか（従来型／AI-assisted／AI-native）。何を作るか（Non-AI型／AI組込み型／Agentic型）。そして、その中のAIをどう調達するか（変動費／固定費）。この三つは独立に判断でき、領域ごと・ワークロードごとに異なる答えがありえます。全社一律の正解を探すのではなく、この三つの問いに自社の言葉で答えを持つこと――それが、AIを開発に取り入れるときにマネジメント層が握るべき勘所だと、私たちは考えています。

最後に、連載の根底にある姿勢を、もう一度共有させてください。AIについては、自分自身と自組織でまず使い込み、自分たちなりの理解を深めることが、判断の前提だと考えています。机上で考えるだけでは実感できないことが多く、技術がもたらす変化は手を動かして体感する必要があります。調達の判断も同じで、計測し、小さく動かしてみて初めて、自社の“裾野”が見えてきます。知って、使って、それから選ぶ――全3回を通じて、この順序を推奨して、連載を閉じます。

編集注記

本稿は、技術の詳細ではなくマネジメントの判断に効く観点に絞って構成しています。GPU構成やモデル選定、ファインチューニングの手法といった技術的な深掘りは、あえて割愛しました。文中の各社の動向・製品名・時期は執筆時点（2026年7月時点）のものです。