AI実行基盤の選び方 — SaaS・自社構築・アプライアンスの比較

「どのAIモデルを使うか」の議論は、もう選定の半分でしかありません。AIエージェントが手元のファイルを読み、コマンドを実行し、コードを書き換えるようになった今、そのエージェントをどこで動かすか、つまり実行基盤の選択が、機密の扱い・監査・運用の成否を左右します。AI実行基盤を3つの類型に整理し、選定の考え方をまとめます。

なぜ「実行基盤」が論点になるのか

チャット型の生成AIなら、ブラウザで開いて使うだけでした。しかしエージェント型のAIは違います。

• ファイルに触れる — リポジトリ・ドキュメント・データを読み書きする
• 実行する — コマンドやツールを動かし、結果を見て次の行動を決める
• 継続する — 長時間動き続け、人が見ていない間も作業する

つまりエージェントは「Webサービス」ではなく実行環境を持つ存在です。その環境がどこにあり、何に触れられて、誰が記録を持つのか。この設計を後回しにすると、エージェント・APIキー・コードが各自のPCに散在し、後から統制を効かせるのが難しくなります（この問題はAIコーディングエージェントを社員PCで動かすリスクと代替策で詳しく扱います）。

3つの類型

AIエージェントの実行基盤は、大きく3つに分かれます。

① SaaS型 — 速さを買う

クラウド上に開発環境ごと用意され、ブラウザから使うタイプです。導入が速く、運用も事業者任せにできます。一方で、コードやデータを事業者の環境に置くことになるため、機密の扱いは契約と規約の確認問題になります。「外部サーバーへの送信自体が不可」という機密区分には適用できません。

② 自社構築 — 自由を取り、運用を背負う

コンテナ基盤や仮想化でエージェント用の実行環境を自前で組む選択です。要件に合わせて自由に設計できる反面、環境の分離設計・権限管理・監査ログ・アップデートのすべてが自社の仕事になります。作る力より、維持する力が問われます。専任の基盤チームを持てる組織でなければ、時間とともに「動いているが誰も全体を知らない」状態になりがちです。

③ アプライアンス — 設計済みの箱を置く

実行環境・統制・監査が設計済みの専用機を社内に置く選択です。機密データを社内に留めたまま、基盤構築の手間なくエージェント環境を配れます。設置すれば終わりではなく、利用者・権限・対象データの設計は必要です。自由度は製品の設計範囲に制約されるため、製品の設計思想が自社の要件と合うかが選定の中心になります。

生成AI基盤の選定で見るべき4軸

類型を選ぶ前に、自社の要件を4つの軸で言語化しておくと判断がぶれません。

1. 賢さ — 最新のクラウドAIが必須か。ローカルLLMの賢さで足りる業務はどれか（ローカルLLMとは何か）
2. 機密 — 「外部に送信してよい情報」と「だめな情報」の線引きはあるか。後者をAIに扱わせたいか
3. 運用負荷 — 実行基盤の面倒を見る人員を確保できるか。「各自のPC任せ」は運用負荷ゼロではなく、見えない運用負荷であることに注意
4. 監査 — 「誰が・どの環境で・AIに何をさせたか」を聞かれたとき、記録で答えられる必要があるか（AIセッションの監査ログ）

現実解は「分ける」

4軸で要件を洗うと、多くの企業で矛盾が見つかります。「最新のクラウドAIの賢さが欲しい」と「機密は外に出せない」は、単一の基盤では両立しないからです。

だから現実解は、単一のAI・単一のルールで統一することではなく、同じ管理境界の中に用途別の実行環境を持たせることです。機密に触れない仕事はクラウドAIの賢さを使い、機密に触れる仕事は社内に閉じた環境で行う。この使い分けを個人の注意力ではなく構造で実現できるか、が基盤選定の最後の問いになります（詳しくはクラウドLLMとローカルLLMの使い分け）。

まとめ

• エージェント型AIは実行環境を持つ。「どのAIか」と同じ重みで「どこで動かすか」を選定する
• 類型はSaaS型・自社構築・アプライアンスの3つ。速さ・自由・統制のどれを優先するかで向きが変わる
• 判断軸は賢さ・機密・運用負荷・監査の4つ。「各自のPC任せ」は見えない運用負荷である
• 単一の環境で全要件は満たせない。同じ管理境界の中に、機密用と通常用の実行環境を分けて持つのが現実解

3類型でいえば③にあたるのがHoko（矛）です。クラウドAIを使う通常ルームと、箱内のローカルLLMで完結する機密ルームを、ひとつの管理境界の中で分けて持つAIエージェント実行アプライアンスで、その構成が2つのルームです。