生成AIの活用が広がる中、事業部門から情報システム部門（以下、情シス）へ「AIを業務に使いたい」という相談が寄せられる場面は確実に増えています。
一方で、情シスの立場ではこんな疑問もあるのではないでしょうか。
-
AI基盤って、クラウドとオンプレどっちがいいの？
-
AI基盤って、結局GPUサーバーを置く話？
AIは今、単に“使う”段階から、業務を横断して“働く”段階、さらに現場や設備を“動かす”段階へ進みつつあります。
こうした変化に伴って変わり始めているのが、AIそのものだけでなく、それを支える基盤に求められる要件です。
今回は、AI基盤をどこにどう配置すべきか、その判断軸をまだ整理しきれていない情シスの方に向けて、ネットワンシステムズでプラットフォーム系商材を担当する島田に素朴な疑問をぶつけ、Q&A形式で整理してみました。
今回のインタビュイー
ネットワンシステムズ株式会社
ビジネス開発本部 プロダクトマネジメント部 第２チーム
ロードバランサーの技術主幹を経験後、営業部門にてエンタープライズ案件を担当。現在は技術的・営業的な知見を活かし、マーケティング部門でプラットフォーム系商材を担当。
このブログでわかる３つのポイント
- クラウドかオンプレか――判断のための3つの軸（データ・リアルタイム性・ガバナンス）
- GPUだけではない――ネットワーク×セキュリティ×オブザーバビリティが性能を決める理由
- AI基盤を後戻りなく設計する考え方――セキュリティとオブザーバビリティを最初から組み込む方法
- ライター：奥村 尚子
- Collaboration分野でのプリセールスやワークスタイル変革支援を経て、現在はマーケティング部門にてプラットフォーム系商材を中心としたデジタルマーケティング施策の企画・推進に従事。
目次
Q1. AI基盤でオンプレも選択肢になるのはどんなとき？
---まず素朴な疑問なんですが、AI基盤って、最初はクラウドの方が始めやすいですよね。GPUリソースも必要に応じて追加できるし、生成AIのサービスもすぐ試せます。では、どんなときにオンプレも選択肢として考える必要が出てくるんでしょうか。
島田：まず結論から言うと、AI基盤の構築をクラウドかオンプレかで検討するとき、最初に見るべき軸は大きく3つあります。
1つ目がデータ、2つ目がリアルタイム性、3つ目がガバナンスです。
1つ目のデータは、機密情報や個人情報、設計情報、研究開発データのように「外に出したくない」「出せない」ものを扱うかどうかです。AIの精度を上げるために社内文書や業務データを活用するほど、この論点は重くなります。クラウドでも構築は可能ですが、データ主権や業界規制などを考えると、自社管理下で扱いたいという判断は自然です。
2つ目のリアルタイム性ですが、これは単にチャットの応答速度が少し速いかという話ではありません。AIがエージェントとして複数システムを横断したり、製造設備やロボットを制御するフィジカルAIへ進化すると、応答時間や通信品質が業務品質そのものに直結します。さらに大規模推論ではGPU間通信やネットワーク帯域が性能を左右するため、オンプレやエッジが有力な選択肢になるケースがあります。
3つ目のガバナンスですが、生成AIは便利な一方で、「誰が、どのデータを使い、どのモデルで、どのような結果を得たのか」を説明できることが求められます。特に機密性の高いデータを扱う組織や企業では、利用履歴や参照データ、モデルのバージョン管理まで含めた厳格な統制が重要になります。クラウドでもこうしたガバナンスを実現することは可能ですが、自社独自の監査要件や運用ルールを細かく適用したい場合には、クラウド事業者の提供範囲に依存しないオンプレミス環境が有力な選択肢となります。
Q2. AI基盤の話は情シスだけの話ではない？
---今のお話を聞くと、AI基盤は単なるITインフラの話ではなさそうですね。経営課題や事業戦略とも関わるテーマになってきているのでしょうか。
島田：はい、まさにそこが重要です。AI基盤は、もう「サーバーをどう置くか」という情シスだけの話ではありません。業務継続、顧客体験、競争優位に直結する経営テーマになっています。
たとえば、AIの利用が進むと、データセンター内だけでなく、社員の端末、拠点、店舗、工場、デバイスまで含めてトラフィックが増えます。あるメーカーの調査でも、AI関連トラフィックは過去12か月で大きく増え、今後3年でさらに大幅に伸びる見込みです。対応が遅れると、単にITが苦しくなるだけでなく、業務スピードやサービス品質に影響します。
さらに、エージェント型AIは業務システムを横断して動きますし、フィジカルAIは現場設備やOT領域にも関わってきます。つまり、AI基盤の議論は、情シスだけでなく、事業部門、セキュリティ、監査に加え、場合によっては工場や店舗などの現場も含めて進めるべきなんです。
Q3. とはいえ、まずはクラウドから始めた方がよいのでは？
---とはいえ、「まずはクラウドで」と考える情シス担当者は多いですよね？実際、将来的な要件がまだ固まっていない段階では、まずはクラウドが有力な選択肢だと思いますが、どう考えればよいのでしょうか。
島田：その考え方は非常に自然ですし、私も最初の検証段階ではクラウドが有力だと思います。すぐに使い始められて、初期投資を抑えやすく、モデルやサービスの比較もしやすいからです。PoCやユースケース探索には向いています。
ただし、気をつけたいのは、「始める場所」と「最終的に置く場所」は必ずしも同じではないという点です。PoCの時点では、少量データ・限定利用・ゆるい運用でも回ります。でも本番になると、利用部門が増え、社内データ連携が始まり、監査、セキュリティ、性能要件が一気に厳しくなります。
ですので、「まずはクラウドで試す」は良いのですが、最初から将来オンプレやハイブリッドへ拡張できる前提で設計することが大切です。具体的には、どのデータをどこに置くか、推論をどこで動かすか、ログをどう残すかを、PoCの時点で最低限整理しておくと後戻りしにくくなります。
Q4. オンプレAI基盤を本格検討すべき判断ポイントは？
---情シスとしては、どのような条件がそろったら「オンプレAI基盤を本格的に検討すべき」と判断すればよいのかを詳しく知りたいです。特に、機密性の高いデータをクラウドで扱えるか、応答遅延の要件が厳しいか、監査や証跡管理の要件をクラウドで満たせるかといった観点は、どのように見極めればよいのでしょうか。
島田：判断ポイントは、先ほどの3軸をもう少し具体化すると整理しやすいです。
まずデータです。顧客情報、人事情報、設計図面、医療・金融データ、研究情報のように機密性が高いものを扱う場合は、クラウド利用規約だけでなく、保存場所、再学習への利用有無、外部送信範囲、暗号化、リージョン、委託先まで確認する必要があります。
そこを自社のポリシーで十分にコントロールしきれない場合は、オンプレミス環境に加えて、データやAI基盤を自国・自組織の管理下で運用する「ソブリンAI」の考え方が注目されるようになっています。
次にリアルタイム性です。一般的な社内問い合わせであれば、多少の遅延は許容できます。しかし、AIエージェントが複数システムを横断して処理する場合や、製造・物流・設備制御のようにリアルタイム性が必要な場合は、応答時間だけでなく揺らぎも問題になります。そういう要件では、オンプレやエッジに近い配置が有利です。
最後にガバナンスです。プロンプトとレスポンスの保存、参照元データ、利用者、モデルバージョン、処理経路、権限の継承などをどこまで追えるか。これを監査部門や法務部門が求める粒度で実現できるかが重要です。SaaS型のAIサービスでは十分な証跡を取れないケースもあるので、要件が厳しい企業ではオンプレやハイブリッドを改めて検討するケースが増えています。
さらに最近では、コストも重要な判断材料になっています。生成AIは利用量に応じてトークン課金されるサービスが多く、PoCや一部利用では問題にならなくても、全社員利用やAIエージェントの本格活用が進むとコストが大きく増加することがあります。利用量が継続的に多くなることが見込まれる場合には、クラウドの従量課金とオンプレミスの設備投資を比較しながら検討する企業も増えています。
要するに、機密データ・リアルタイム性・ガバナンスに加え、大規模利用時のコストまで含めて検討した結果、オンプレやハイブリッドを改めて評価する企業が増えているということです。
Q5. オンプレAI基盤とは、GPUサーバーを社内に置く話？
---正直なところ、オンプレAI基盤という言葉を聞くと、「GPUサーバーを社内に置く話かな」というイメージがありました。でも、ここまでのお話を聞くと、それだけではなさそうです。オンプレAI基盤の実体はどう捉えるのが正しいのでしょうか。
島田：そのイメージは半分正しくて、半分足りません。AI基盤にGPUはもちろん重要です。ただ、GPUサーバーを置けばAI基盤になるわけではないんです。
実際には、AI基盤は少なくとも、コンピュート、ネットワーク、セキュリティ、オブザーバビリティ、ストレージ、オーケストレーション、運用管理までを含めて考える必要があります。学習・推論の性能はGPUだけでは決まらず、GPU間通信、データ供給、モデル実行基盤、ライフサイクル管理が全部かみ合って初めて出ます。
たとえば、どれだけ高性能なGPUを用意しても、データが十分に供給されなかったり、セキュリティや運用管理が不十分だったりすれば、AIは期待どおりの性能や価値を発揮できません。
オンプレAI基盤とは、社内にGPUサーバーを置く話というより、AIを安定して本番運用するためのフルスタックをどう設計するかという話ですね。
Q6. AI基盤の性能はGPUだけで決まるわけではない？
---GPUが重要なのは理解できました。ただ、最近のAI基盤の話ではネットワークの重要性もよく耳にします。GPUの性能が高ければ十分というわけではないのでしょうか。なぜAI基盤ではネットワークがそこまで重要になるのでしょうか。
島田：その通りです。AI基盤ではGPUの性能が注目されがちですが、実際にはGPUをどれだけ効率よく連携させられるかが非常に重要です。
例えば大規模なAIモデルの学習では、数十台から数百台のGPUが同時にデータをやり取りしながら処理を行います。このときネットワークの帯域が不足すると、GPU同士のデータ交換が追いつかず、高価なGPUが待ち状態になってしまいます。
また、推論の世界でもAIエージェントが複数のシステムやデータソースを横断して処理するケースが増えています。そのため、単にGPU性能だけでなく、データを迅速かつ安定して届けるネットワーク基盤がこれまで以上に重要になっています。
つまりAI基盤では、「GPUが計算する」、「ストレージがデータを保持する」、「ネットワークがデータを運ぶ」という役割があり、いずれか一つが不足すると全体性能が大きく低下します。だからこそ現在のAI基盤では、GPUだけでなく、高速・低遅延なネットワークを含めて全体最適で設計することが重要なのです。
Q7. 拠点やキャンパスネットワークまで見直しが必要？
---AI基盤の性能にはネットワークが重要だということが分かりました。ただ、それはデータセンター内の話だけでしょうか。社員が利用する生成AIやAIエージェントの普及を考えると、拠点やキャンパスネットワークまで見直す必要があるのでしょうか。
島田：必要になるケースはかなり多いです。AIの通信は、もうデータセンター内だけでは完結しません。社員が使う生成AI、拠点業務で使うAIアシスタント、工場・店舗の映像解析、エッジ推論など、利用が広がるほどキャンパスやブランチ側にも負荷がかかります。
実際、AI利用の拡大で、帯域不足や可視化不足を課題として挙げる企業は増えています。特に厳しいのは、何にどれだけ使われているか見えないままトラフィックだけ増えることです。シャドーAIのように、情シスが把握しない形でAIサービスが使われると、性能面でもセキュリティ面でも問題が出やすい。
さらに、フィジカルAIのように現場でリアルタイム制御を伴う用途では、エッジまで安全につながるネットワークが前提になります。ですから、AI基盤の設計では、データセンターだけでなく、キャンパス、ブランチ、エッジまで含めたネットワークの再設計を視野に入れるべきです。
Q8. AI基盤では、なぜ「オブザーバビリティ」が重要になる？
---AI利用が広がると、データセンターだけでなくキャンパスや拠点、エッジまで含めて管理しなければならないことが分かりました。一方で最近は「オブザーバビリティ」も重要だと聞きます。なぜAI基盤では、そこまでオブザーバビリティが重要になるのでしょうか。
島田：AI基盤では、従来のシステム以上に「何が起きているのかを見える化すること」が重要になります。
従来のITシステムであれば、サーバーやネットワークの稼働状況を監視していれば、ある程度は問題の切り分けができました。しかしAIでは、それだけでは十分ではありません。たとえば、
-
GPU利用率は高いのに応答が遅い
- モデルの回答品質が急に落ちた
- RAGの検索結果が期待と違う
- AIエージェントの処理が途中で止まる
といった問題が発生します。
このとき原因は、GPUなのか、ネットワークなのか、ストレージなのか、モデルなのか、あるいはベクトルDBやオーケストレーションなのか、一見しただけでは分かりません。
つまりAI基盤では、「システムが動いているか」だけでなく、「AIが期待どおりに動いているか」まで見える必要があるんです。
さらに本番利用が進むと、性能だけでなく、コストや品質も継続的に管理する必要があります。どのモデルが使われているのか、どれだけのリソースを消費しているのか、回答品質に問題はないのかを把握できなければ、安定運用は難しくなります。
だから最近は、インフラ監視だけでなく、AIの実行経路やモデルの挙動、利用状況まで含めて可視化するオブザーバビリティが重視されています。
AI基盤では、コンピュート・ネットワーク・セキュリティを運用するために、それらを横断的に可視化するオブザーバビリティの重要性が高まっているということです。
Q9. AIのセキュリティは、従来のセキュリティと何が違う？
---AI基盤のオブザーバビリティが重要なのは分かりました。一方で、AIのセキュリティは従来のITシステムのセキュリティと何が違うのでしょうか。
島田：大きな違いは、守る対象がサーバーやネットワークだけではなく、モデルやデータ、そしてAIの挙動そのものにまで広がることです。
従来のITシステムでは、不正アクセスやマルウェア、情報漏えいといった脅威への対策が主なテーマでした。もちろん、これらはAI環境でも引き続き重要です。しかしAIでは、プロンプトによる不正な誘導や学習データの汚染、信頼できないモデルの利用など、AI特有のリスクも考慮しなければなりません。
加えてAIでは、SecurityだけでなくSafetyも重要になります。
-
Security は、AIやデータを攻撃や不正利用から守ること
- Safety は、AIが意図しない振る舞いや不適切な回答をしないようにすること
を指します。
例えば、システム自体は正常に動いていても、AIが誤った回答を返したり、業務ルールに反する判断をしたりすることがあります。これは従来のITセキュリティだけでは防ぎきれない領域です。
また、多くのAIは社内文書や業務システムと接続されて利用されます。そのため、誰が利用したのか、どのデータを参照したのか、どのモデルを使い、どのような結果を生成したのかを継続的に把握できることも重要になります。
つまりAI時代のセキュリティでは、単にシステムへの攻撃を防ぐだけでは十分ではありません。システムを保護するSecurityと、AIを安全かつ適切に動作させるSafetyの両方を実現することが求められるのです。
だからこそ最近は、従来のITセキュリティ対策に加えて、モデルの評価やガードレールの設定、運用中の挙動監視、利用状況の可視化などを組み合わせながら、AI全体の信頼性を継続的に管理する取り組みが重視されています。AIを業務基盤として活用する時代だからこそ、SecurityとSafetyを一体で考えることが重要になっているということです。
Q10. AI基盤を後戻りなく設計するには、情シスは何を重視すべき？
---ここまでのお話を踏まえると、論点は単純な「クラウドかオンプレか」の二択ではなく、本番運用まで見据えて全体をどう設計するかにありそうです。PoC止まりにしないために、情シスはどのような観点でAI基盤を設計・判断すべきなのでしょうか。
島田：一番大切なのは、最初にユースケースを整理することです。
どのデータを扱うのか、どの程度の応答速度が求められるのか、どこまでの監査やガバナンスが必要なのか。こうした業務要件を整理すると、クラウドが適しているのか、オンプレミスが適しているのか、あるいはエッジで処理すべきなのかが見えてきます。最初から全社一律で決める必要はなく、用途に応じて使い分けるハイブリッドな考え方が現実的です。
次に重要なのは、AI基盤を単なるGPU調達プロジェクトにしないことです。ここまでお話ししてきたように、AIの本番運用ではコンピュートだけでなく、ネットワーク、セキュリティ、オブザーバビリティが欠かせません。
さらに見落とされがちなのがコスト管理です。PoCの段階では大きな問題にならなくても、利用者数の増加やAIエージェントの活用拡大によって、推論回数やトークン消費量は想像以上に増えていきます。クラウドの従量課金で運用するのか、一定規模以上はオンプレミスで処理するのかを含めて、将来の利用量まで見据えて設計することが重要です。
PoCでは問題なく動いていたとしても、利用者やデータ量が増えた途端に性能、運用、ガバナンス、コストの課題が表面化するケースは少なくありません。だからこそ、これらを最初から前提として設計することが重要です。
そして、PoCから本番、さらに全社展開まで見据えるのであれば、運用の標準化と再現性も欠かせません。検証済みのリファレンスアーキテクチャやテンプレート化された運用、ライフサイクル管理の仕組みを整えておくことで、環境や拠点が増えても安定した運用を継続しやすくなります。
要するに、後戻りなく進めるには、「クラウドかオンプレか」を先に決めるのではなく、業務要件、運用要件、ガバナンス要件、コスト要件を整理した上で、コンピュート、ネットワーク、セキュリティ、オブザーバビリティを統合的に設計することが重要です。それが結果的に、PoCで終わらず、継続的に価値を生み出せるAI基盤につながるのだと思います。
まとめ
島田：AI基盤を考えるときに、よく「クラウドかオンプレか」という二択になりがちですが、実際にはもっと立体的に見る必要があります。判断軸は、データ、リアルタイム性、ガバナンスです。この3つの要件が厳しくなければクラウドが始めやすいですし、厳しくなるほどオンプレやハイブリッドの価値が高まります。
また、オンプレAI基盤はGPUサーバーを置く話ではありません。ネットワーク、セキュリティ、オブザーバビリティ、ストレージ、Kubernetes、運用管理まで含めた統合設計が必要です。特にこれからは、生成AIだけでなく、エージェント型AI、フィジカルAIへと広がるので、データセンターだけでなくキャンパスやエッジまで視野に入れた設計が重要になります。
PoCを成功させること自体はそれほど難しくありません。難しいのは、それを安全に、安定的に、本番で拡張できる形にすることです。だからこそ情シスには、目先の実装だけでなく、本番運用まで見据えたアーキテクチャの設計者としての役割が求められていると思います。
おわりに
AI活用がPoCから本番へ進む今、情シスに求められる役割はますます大きくなっています。そしてこれからのAI導入では、モデル選定だけでなく、データの置き場所、推論基盤、ネットワーク、セキュリティ、オブザーバビリティ、運用設計まで含めた全体最適が重要になります。 具体的にイメージしたい方は、弊社の「Innovation Showcase」にぜひお越しください。Innovation ShowcaseではフィジカルAIのユースケースやデモを通じて、プライベートAI基盤の活用イメージをご紹介しています。
「クラウドだけで十分なのか」「どこからオンプレやエッジを考えるべきか」といったテーマでお悩みの方は、ぜひ一度ご相談ください。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
組織・製品等の名称は執筆時点のものです。
