ローカルLLM・Bedrock・パブリックAI、どう使い分けるか — 判断基準は3つ

生成AIの相談でいちばん多いのは、実は「ChatGPTに社内データを入れて大丈夫なのか」という質問です。答えは「何を、どこまで出すかによる」なのですが、これでは実務は前に進みません。選択肢を3つに整理し、判断基準を3つに絞って、現場でそのまま使える形にしました。当社はAmazon BedrockでのAI基盤構築と、Mac StudioでのローカルLLM構築の両方を手がけているので、どれかに寄せるポジショントークなしで書きます。

01選択肢は3つ — まず1枚で

「どれが優秀か」という比較にはあまり意味がありません。モデルの性能差は年々縮まっており、2025年にApache 2.0で公開されたgpt-ossのように、ローカルで動くモデルもすでに実用水準です。決め手は性能ではなく、次の3つです。

02基準1：データをどこまで出せるか

最初に整理するのはモデルではなくデータです。社内のデータを3段階に分けます。

• 外部SaaSに出せる — 公開情報、一般的な文書ドラフト。→ パブリックAIの法人プランで十分
• 自社クラウド内なら置ける — 社内文書、顧客データの大半。→ Bedrock。入出力が学習に使われず、PrivateLinkでインターネットに出さずに使える
• 契約・規制上、外に出せない — 製造ノウハウ、特定業種の規制対象データ、取引先との守秘契約に触れるもの。→ ローカルLLM

03基準2：統制と証跡をどこまで求めるか

「誰が・いつ・何をAIに聞いたか」を説明できる必要があるか、という問いです。監査対応がある業務、職務分離が求められる環境では、AIの利用ログも証跡の一部になります。

ここはBedrockの強みがはっきり出るところです。既存のAWS基盤と同じIAMで権限を管理し、CloudTrailで操作証跡を残し、CloudWatchで利用量を監視する——つまりすでに運用している統制の仕組みにAIがそのまま乗ります。パブリックAIの法人プランにも監査ログはありますが、自社基盤の統制と別枠になるため、管理が二重になりがちです。ローカルLLMは統制を完全に自社設計できる反面、ログ基盤も認証もすべて自前で整備することになります。

04基準3：コスト構造 — 席か、従量か、固定か

3択はコストの効き方がまったく違います。

• 席課金（パブリックAI） — 使う人数に比例。少人数で幅広い用途に使うなら最安
• トークン従量（Bedrock） — 処理量に比例。アプリ組み込みで利用量が変動する用途に合う。使わない月は費用も減る
• 固定費（ローカルLLM） — 初期投資後は処理量が増えても費用がほぼ増えない。定常的に大量処理する用途では、どこかで従量課金を逆転する

目安として、「毎日・大量・同じ種類の処理」が見えているならローカルの固定費が効き始めます。逆に、利用が読めない段階でハードウェアを買うのは順序が逆です。まず従量で始めて、利用パターンが固まってからローカル化を検討する方が失敗しません。

05判断フロー

06現実解は「組み合わせ」

ここまで読むと気づかれると思いますが、まともに検討した会社ほど、着地は1択ではなく組み合わせになります。典型的なパターンはこうです。

• 全社の汎用利用 — パブリックAIの法人プラン（文書作成、調査、アイデア出し）
• 業務システムへの組み込み — Bedrock（社内文書RAG、問い合わせ対応、既存AWS基盤との統制統合）
• 機密領域 — ローカルLLM（外に出せないデータの要約・検索・分析）

2026年時点のローカルLLM界隈でも、「日常はローカル、高度なタスクはクラウド」というハイブリッド運用のパターンも増えつつあります。重要なのは、この線引きを誰かが設計として決めておくことです。線引きがないまま各部署が個別にAIを使い始めると、シャドーAI（管理外のAI利用）が増え、いちばん避けたかった「機密データがどこかのSaaSに入っている」状態が起きます。

—まとめ

ローカルLLM・Bedrock・パブリックAIは競合ではなく、データの機密度と統制要件で使い分ける道具です。判断基準は3つ——データをどこまで出せるか、統制と証跡をどこまで求めるか、コストは席・従量・固定のどれが合うか。そして実務の着地はほぼ確実に組み合わせになります。まずデータの分類から始めてください。そこが決まれば、残りの判断は驚くほど速く進みます。