AIモデルをどこで動かす？ 外部API・自社クラウド・ローカル実行の比べ方と選び方
AI機能の実行先は、外部API・自社管理のクラウド・ローカル実行の3つに大別できます。先に結論を書くと、扱うデータに保存や越境の制約がなく、利用量がまだ読めない段階では外部APIが最も合理的です。自社クラウドは契約・ネットワーク経路・ログを自社の管理下に置きたいとき、ローカル実行は外部通信を遮断する必要があるときや、同じ処理を大量に回して単価を下げたいときに効いてきます。3つは排他ではなく、用途ごとに使い分けるのが現実的です。
3方式は「どこで推論するか」より「誰が何を管理するか」で分かれる
比較を始める前に、言葉の指す範囲を揃えておきます。
- 外部API：モデル提供元が運用するエンドポイントを呼ぶ方式。自社はAPIキーとアプリケーションだけを持ちます。
- 自社管理のクラウド：さらに2タイプに分かれます。(1) クラウド事業者のマネージドAI基盤（Amazon Bedrock、Azure の AI サービス、Vertex AI など）を自社アカウント内から使う形。(2) 自社VPC内のGPUインスタンスに、公開されている重みのモデルを vLLM などの推論サーバで載せる形。(1)はモデル運用を任せられ、(2)はモデルと実行環境の両方を自社で抱えます。
- ローカル実行：社内サーバーや業務端末でモデルを動かす方式。Ollama や llama.cpp、LM Studio などが入口になります。
「クラウドか、ローカルか」という二分法だと、(1)と(2)の差が消えてしまいます。運用負荷も費用構造もこの2つではまったく違うため、4択に近い粒度で考えたほうが判断を誤りません。
データの扱いやすさ：「学習に使わない」と「保存しない」は別の約束
外部APIの検討でまず確認されるのが「入力が学習に使われるか」ですが、主要な商用APIでは既定で学習に使わないことが明示されています。OpenAIは企業向けプライバシーの説明で、既定で顧客のビジネスデータをモデルの学習に使わない一方、サービス提供と不正利用の特定のためにAPIの入出力を最大30日間保持する場合があるとしています。条件を満たす組織はゼロデータ保持を選べますが、これは申請と承認が前提です。
Amazon Bedrock も、プロンプトと応答をAWSのモデル学習に使わず、サードパーティのモデルプロバイダーに配布しないと公式ドキュメントに明記しています。加えてデータ保持の扱いをアカウント側で設定する仕組みがありますが、選べる範囲はモデルごとに異なります。使いたいモデルが自社の保持要件を満たすかは、モデル単位で確認する必要があります。
つまり「学習に使われない」は、どこに・いつまで・誰が見える形でデータが残るかについては何も保証していません。社内規程で委託先への保存自体を禁じているなら、学習ポリシーだけを根拠に稟議を通すことはできません。
個人データを扱う場合は、さらに個人情報保護法の論点が加わります。個人情報保護委員会のQ&Aでは、外国にある事業者が外国に設置・運営するサーバに個人データを保存する場合でも、その事業者が保存された個人データを取り扱わないこととなっているときは、外国にある第三者への提供（法28条1項）に該当しないとされています。ここでいう「取り扱わないこととなっている場合」とは、契約条項でその旨が定められ、適切にアクセス制御が行われている場合等です。逆に、その事業者が個人データを取り扱っている場合は、サーバが国内にあっても外国にある第三者への提供に該当します。
この整理には実務上の含みが2つあります。第一に、リージョンを東京に寄せただけでは判断は終わりません。契約条項とアクセス制御の実態が要件になります。第二に、該当しない場合でも外国で個人データを取り扱うことに変わりはないため、当該外国の制度等を把握したうえで安全管理措置を講じ、その内容を本人の知り得る状態に置く必要があります。
ローカル実行はこの論点の多くを消せます。データが社内から出ないため、越境移転も委託先の保存期間も問題になりません。その代わり、端末やサーバーの管理、プロンプトと応答のログ管理、モデルファイルの更新は完全に自社責任になります。「外に出さない」は「管理しなくてよい」ではありません。
運用負荷：止まったときに誰が直せるか
外部APIの運用負荷は低いものの、ゼロではありません。モデルのバージョン更新や提供終了に追随する作業、レート制限への対処、障害時のフォールバック先の用意が必要です。自社でモデルを固定できない以上、出力が静かに変わるリスクを前提に、評価用のテストセットを持っておくことが実質的な必須要件になります。
自社クラウドでマネージドAI基盤を使う場合は、IAMやネットワーク設計、ログ基盤の設計が加わります。一方、自前GPUでオープンウェイトモデルを動かす場合は負荷が一段上がります。GPUの在庫確保、推論サーバのチューニング、同時リクエスト数に応じたスケール、モデル更新時の再検証まで、すべて自社の運用チームの仕事です。アクセスが時間帯で大きく振れるWebサービスでは、オートスケールの設計が品質とコストの両方を左右します。
ローカル実行は、単体での検証は簡単ですが、複数人が同時に使う段階で性質が変わります。デスクトップ向けのツールは同時実行をあまり想定しておらず、業務利用に耐えるスループットを出すなら結局はvLLMなどの推論サーバと認証の仕組みが必要になります。「ノートPCで動いたから社内展開できる」とはなりません。
費用：従量課金と固定費、どちらの形が自社に合うか
3方式は、費用が発生する形がそもそも違います。
- 外部API：初期費用ゼロ、トークン量に比例する純粋な従量課金。使わなければ払いません。反面、想定外に使われると請求が伸びるため、プロジェクト単位の上限設定と使用量監視が前提になります。
- 自社クラウドのGPU：GPUを確保している時間に対して課金されます。推論していないアイドル時間にも料金が発生するため、稼働率が低いほど単価は悪化します。同じH100クラスでも、ハイパースケーラーのオンデマンドと専業GPUクラウド、マーケットプレイスでは時間単価に数倍の開きがあり、どの提供形態を選ぶかで試算が変わります。
- ローカル実行：ハードウェアの初期投資と電力・保守が中心で、推論自体の追加費用はほぼ発生しません。ただしGPUのVRAM容量が、動かせるモデルの上限をそのまま決めます。重みに必要なメモリはおおよそ「パラメータ数×量子化ビット数÷8」で、これにKVキャッシュと実行時のオーバーヘッドが乗ります。4bit量子化の8Bクラスなら数GB台、70Bクラスなら数十GB規模が目安で、買える機材が使えるモデルの品質を縛る構造です。
判断の軸は単価ではなく損益分岐点です。「月間トークン量×API単価」と「GPU時間単価×確保時間＋運用工数」を並べます。1日数時間しか動かない社内ツールなら、GPUを確保し続けるほうが高くつくことがほとんどです。逆に、定型の分類や要約を24時間流し続けるようなバッチ処理は、自社GPUやローカル実行の固定費が効いてきます。なお、外部APIでも即時性が不要な処理をバッチ用のエンドポイントに回せば単価は下がります。自前化を検討する前に、この余地を使い切ったかを確認する価値があります。
要件から候補を絞る5ステップ
- 扱うデータを分類する：公開情報、社内限りの情報、個人データ、要配慮情報のどれが入力に乗るかを機能単位で書き出します。機能ごとに答えが変わるので、システム全体で1つに決めようとしないことが重要です。
- 消える選択肢を先に消す：越境移転の可否、委託先での保存可否、監査ログの提出要件、業界規制を確認します。「委託先に一切データを残さない」が契約上の要件なら、ゼロデータ保持の申請が通るか、あるいは自社環境しか選べないかがこの時点で決まります。
- 必要な品質を実測する：自社の実データで評価セットを作り、外部APIの上位モデルと、ローカルで動く規模のモデルの両方を同じ条件で測ります。品質が足りないモデルは、どれだけ安全でも選択肢になりません。
- トラフィックと稼働パターンを見積もる：1日あたりのリクエスト数、平均入出力トークン数、ピークの偏り、即時性の要否を出します。ここまで揃って初めて費用の比較ができます。
- 運用の担い手を決める：GPUの監視、モデル更新、インシデント対応を誰が担うかを決めます。担当が決まらない構成は、技術的に可能でも選ぶべきではありません。
進め方としては、要件が固まっていない段階では外部APIで作り、使われ方と費用の実測値を得てから移行を検討するのが無駄が少ない順序です。その際、アプリケーション側でモデル呼び出しを薄い層に閉じ込めておくと、後から実行先を差し替えやすくなります。多くの推論サーバがOpenAI互換のインターフェースを備えているため、この層を意識して設計するだけで、将来の選択肢を保ったまま先に進められます。
まず手を付けること
最初にやるべきは実行基盤の比較検討ではなく、入力されるデータの分類と、社内規程・契約上の禁止条件の洗い出しです。この2つが決まれば候補は多くの場合2つ以下に絞れます。そのうえで自社データで品質を測り、実測したトラフィックで費用を比べれば、感覚ではなく数字で実行先を決められます。
出典
この記事に関連するchot Inc.の支援
chot Inc.は日本初のVercel公式パートナーとして、Next.jsを中心としたWebサイト・Webアプリケーションの開発を支援しています。Vercelの導入・契約・運用の見直しはVercel公式パートナー開発支援で、Next.jsによる新規開発や既存システムからの技術移行はモダンWeb開発で紹介しています。
