成否を分かつ「生成AIインフラ」の勘所 青山氏とNutanix吉瀬氏が語る、生成AIインフラで考慮すべきポイントとは：「LLMを動かせること」はゴールではない

企業が生成AIを活用する上で、ITインフラの観点では、どのような取り組みが必要なのか。生成AI活用の成否を分かつ“生成AIインフラ”のポイントとは何か。「CloudNative Days」Co-Chairの青山真也氏と、ニュータニックス・ジャパンの吉瀬淳一氏が語り合った。

PR／＠IT

印刷

隕九ｋPost

Shareシェア

はてなブックマーク

SharePocket Button

PR

　業界や業種を問わず、急速に進化する生成AI（人工知能）技術を活用しようとする動きが広まっている。業務の効率化や自動化、データ分析、パーソナライズと、生成AI技術の適用範囲は幅広い。どのような目的にせよ、生成AIで価値を創出するには、生成AIを活用するための体制づくりが急務といえるだろう。

　では、企業が生成AIを活用する上で、ITインフラの観点では、どのような取り組みが必要なのか。生成AI活用の成否を分かつ“生成AIインフラ”のポイントとは何か。日本のクラウドネイティブコミュニティーをリードし、クラウドネイティブ技術関連のカンファレンス「CloudNative Days」のCo-Chairを7年間務めている青山真也氏（シニアソフトウェアエンジニア）と、ニュータニックス・ジャパンの吉瀬淳一氏（アドバイザリーソリューションアーキテクト）が語り合った。

※以下、敬称略。

RAGからAIエージェントへ、目まぐるしく変わる生成AIのトレンド

──生成AIの現状を、お二人はどう感じていますか。

青山　生成AIはゲームチェンジャーであり、ITの転換点になる技術だと思っています。CNCF（Cloud Native Computing Foundation）も生成AIを力強く推進していますし、2024年に開催された「KubeCon + CloudNativeCon」でも、話題の多くは生成AIやそれを支えるML（機械学習）基盤についてでした。私の周りでも「GitHub Copilot」を活用した開発や、レビュー、チェック、テストへの活用が進んでいます。ユーザーに提供するサービスとしても、生成AIを用いたテキスト生成や要約などがあり、さまざまなシーンで生成AIを活用していますね。

　企業における生成AIの活用方法としては、自社に適したAIモデルを作るか、既存のモデルをRAG（検索拡張生成）で強化して使うかの2パターンがあり、世の中的には後者が多いという印象ですね。

CloudNative Days Co-Chair／シニアソフトウェアエンジニア 青山真也氏

吉瀬　AIモデルの開発、提供は、ベンダーによる寡占化も進むと感じます。というのも、OpenAIの「o1」や「o3」、DeepSeekの「R1」など生成AIモデルの進化は目まぐるしく、同じ土俵で戦うのが難しいからです。現実的には、多くの企業が最新かつ高性能のAIモデルを利用する側に回ることになると思います。その場合は自社のデータをどう生かすかがポイントになるでしょう。その1つの方法はRAGでしたが、トレンドは目まぐるしく変わっており、今は「AIエージェント」が注目されている状況ですね。

──企業が生成AIを使うようになると、どのような点が課題になるのでしょうか。

吉瀬　企業の資産となるデータをどう守るのか。セキュリティやガバナンスの問題があるでしょう。社内で蓄積されている情報を生成AIで活用する場合に、どのような準備をすればよいのか、はっきりとした正解もありません。顧客情報やAIモデルの管理など、さまざまな検討が始まったばかりです。生成AI活用を見据えている多くの企業は、これからそれを議論、検討しなければいけないフェーズに入るのではないかと考えています。

ニュータニックス・ジャパン アドバイザリーソリューションアーキテクト 吉瀬淳一氏

AI／MLのワークロードにあわせて進化してきたKubernetesが役立つ

──では、生成AI時代のインフラには、どのような取り組みが求められるのでしょうか。

吉瀬　幾つかのチャレンジが必要だと考えます。まずは、次々と登場するAIモデルへの対応です。新しいAIモデルが登場したら、すぐに利用できる環境を整備して提供しなければなりません。生成AIで活用する社内のデータをきれいに整備し、いつでも使える状態にしておく必要もあるでしょう。その上で、セキュリティやガバナンスの確保も求められます。今後、生成AIがどのように進化するにせよ、これらは必須の取り組みになるでしょう。

青山　生成AIインフラに求められる取り組みは、複雑化したシステムをマイクロサービスで柔軟かつ容易に管理できるようにすることと、似ている取り組みだと考えています。つまり、MLやAIワークロードの中で、データソース、データ形式、AIモデルなどが複雑になった際に、それらをうまく管理する仕組みを、プラットフォームとして構築、提供するのです。ただ、クラウドネイティブを中心としたアプリケーションの方法論はまとまりつつある一方、MLや生成AIのプラットフォーム側はまだ正解がなく、泥臭い取り組みが必要になってくると感じます。

吉瀬　Kubernetesは生成AIインフラとしてポイントになるでしょう。Kubernetesは10年の実績があり、生成AIが登場する以前からKubernetesのユースケースの一つとして、AI／MLがありました。AI／MLのためのフレームワークである「Kubeflow」があり、それを活用してMLOps環境を整えることもできる。私もお客さま向けにMLOpsの環境を構築して提供した経験があります。

青山　そうですね。Kubernetesも、AI／MLのワークロードに求められる機能を拡張しています。

吉瀬　MLOpsという観点で見ると、サーバやストレージだけでなく、データサイエンスやデータマネジメント、分散パイプラインなどの知識も必要になります。結局、生成AI向けインフラで大変なのは「コンピュートをどうするか」というより、「データとデータのパイプラインをどうするか」なのです。逆に言えば、クラウドネイティブには、生成AI時代のITインフラに関するナレッジ、経験があり、ITインフラを構成するための部品もそろっているということです。

──生成AIを活用する際の課題に対し、Kubernetesは役立つということですね。

青山　その通りです。GPUを活用するためのスケジューリングなどもできます。

吉瀬　複数のGPUを持つ環境で、このLLM（大規模言語モデル）にはGPUが4個必要、あのLLMにはGPUが1個必要といった際に、GPUリソースを柔軟に割り当てられますし、それぞれエンドポイントを立てて、エンドポイントが増えたときにも素早く対応できます。これをベアメタルでやるのは規模が大きくなればなるほど大変ですが、Kubernetesのようなプラットフォームがあれば効率化できます。

GPUやLLMのサービングをシンプルに実施するNutanix Enterprise AI

──NutanixはKubernetes環境で動く「Nutanix Enterprise AI」（NAI）を提供していますね。

吉瀬　NAIは、オンプレミスやクラウドのKubernetes上で動作し、GPUのスケジューリングやLLMエンドポイントのサービング、データやAPIの管理、ライフサイクル管理、ガバナンスなどの機能を提供します。NAIの管理画面上には、利用できるLLMやGPUが一覧表示されていて、数クリックするだけで、生成AIアプリケーションを開発するためのインフラを簡単にデプロイできますし、これをオンプレミスでも構築できます。

Nutanix Enterprise AIの概要（出典：ニュータニックス・ジャパン提供資料）

　Nutanix Kubernetes Platformはもちろん、「Amazon Elastic Kubernetes Service」（Amazon EKS）、「Azure Kubernetes Service」（AKS）、「Google Kubernetes Engine」（GKE）など、パブリッククラウド各社のプラットフォームでも利用できます。AIモデルとしては「Hugging Face」で提供されている複数のLLMを提供しています。

Nutanix Enterprise AIの管理画面のイメージ（出典：ニュータニックス・ジャパン提供資料）

青山　自社で生成AIモデルを運用している企業のインフラ担当者は今、これらを大変な思いをしながら作り込んでいる状況です。

吉瀬　企業での生成AIの取り組みはこれからですから、インフラも整っていません。生成AIのワークロードをどうプロダクションに持っていくかも、深くは議論されていないでしょう。ただ、生成AIを活用する上では、インフラやデリバリーの仕組みは不可欠です。ソフトウェアだけでなく、GPUをはじめとして、ネットワークやストレージなどのハードウェアの知識、技術も必要です。Nutanixはそれらをプラットフォームとして迅速に提供することで、生成AIの活用を支援します。

──パブリッククラウドベンダーも生成AIのマネージドサービスを提供していますが、それだけで生成AIを活用することは難しいのでしょうか。

吉瀬　もちろんできます。ただ、データ管理やセキュリティがクラウドベンダーに依存することになり、コストコントロールも難しくなる。「ロックインされても構わない」という判断なら全く問題ありません。

青山　オンプレミスとクラウドを使い分けることも重要です。例えば、自社でAIモデルを開発する場合、データをクラウドからオンプレミスに持ってきて取り組んだ方が安価に済みます。クラウドで大量のGPUを利用するのは、多大なコストがかかってしまいます。今後も使い続けるならオンプレミスに持っていた方が、確実に安い。

　推論でも、ユースケースやコストパフォーマンスを見て、オンプレミスかクラウドで進めるのかを決めています。サービスがクラウドで完結するならクラウドを使った方がいいケースが多いですし、特定の条件でカナリアテストやABテストをするなら、別に仕組みを作り込む必要もあります。これらを考慮した判断が重要ですね。

ユーザーが簡単かつ安全に利用できるプラットフォームを作ることが重要

──生成AI向けのインフラを構築、運用する際に注意すべきことはありますか。

青山　そもそもGPUの調達が難しい点は注意すべきです。必要なときにGPUを確保できなければ、事業上のリスクになる可能性もあります。

吉瀬　GPUの利用量がサービスのコストに跳ね返ってきます。チャットbotのようなリクエストが少ないサービスならクラウドの方がいいでしょう。ただ、トークンごとに課金されるのでサービスによっては突然、請求額が先月の10倍になるということも起こり得ます。そこをコントロールするために、いかにオンプレミスに持ち、いかに使わせるかがポイントになります。

──具体的には、どのような機能や要件が求められますか。

吉瀬　GPUのサービングにKubernetesは必須です。RAGを活用するならベクトルデータベースも必要で、例えばマイクロサービスとしてスケールも可能な「Milvus」を利用する場合も、Kubernetesが前提になります。LLMのサービングもVM（仮想マシン）ベースで行うことは現実的ではないでしょう。セキュリティもデータ、ストレージ、APIなどそれぞれの領域で見ていく必要がありますし、その上で、スケーラビリティ、ガバナンス、ライフサイクル管理を検討する必要があるでしょう。もっとも、インフラの考え方の部分は、クラウドネイティブの考え方と大きく変わることはないとも言えます。

青山　事業で生成AIを活用する際には、モデルや学習に何か変更があったときに、それを素早く事業に適用することが求められます。モデルの精度や正答率、満足度に関する指標や、ガードレールのような安全性を確保する仕組みも必要です。取り組み当初は「LLMを動かす」という観点でのインフラ構築かもしれませんが、将来的には、さまざまな指標に基づいて自動化したり、高度化したりできるインフラが必要になります。

　事業目線で、開発者、運用者、社内ユーザーが使いやすく、簡単かつ安全に実現できるプラットフォームに成熟させていくことが重要です。CNCFも、LLM周りの標準化に乗り出そうとしています。それに追随できる仕組みを想定したり、クラウドネイティブを実践したりすることが大切です。

──最後にメッセージを頂けますか。

吉瀬　エンタープライズでの生成AI活用は始まったばかりですが、必要なITインフラはある程度見えています。Nutanixは、NAIを含めた「GPT-in-a Box 2.0」というソリューションも提供しています。誰もが使うものは、わざわざ手作りしなくてもいいように、Nutanixがソリューションとして提供し、お客さまを支援します。

青山　これから生成AIに取り組む企業は不安も多いと思います。コンテナやKubernetesをはじめ、新しいワークロードをカバーし、活用をリードしていくのがクラウドネイティブです。生成AIとクラウドネイティブの両方について取り組みを推進することが、ITインフラにまつわる不安をなくし、事業の成長へとつながるはずです。