AIの進化に伴い、経済安全保障や機微データとの連携が深まる中、生成AIを支えるシステム基盤においても、データの所在や管理体制があらためて注目されています。特に、「重要インフラ15分野」をはじめ、自治体・公共・社会インフラ領域では、高い機密性やガバナンスが求められる環境において、AI基盤の選択が重要なテーマとなっています。

こうした中、ソフトバンクでは、Microsoft Azure 上で構築していた生成AI環境を対象に、ソブリン性を備えたクラウド基盤「Cloud PF Type A」上で同等の構成を実現できるかを検証しました。

本記事では、移行検証の担当者へのインタビューを通じ、移行検証の目的や考慮した点、そして技術的な気付きについてご紹介します。

検証の目的や背景

Microsoft Azure 上で構築していた生成AIサービス環境を、ソブリン性を備えたクラウド基盤「Cloud PF Type A」へ移行する検証を実施した担当者にインタビューをしました。

Cloud PF Type A上での検証を実施した背景を教えてください。

藤田：今回の検証の背景には、生成AIサービスを提供する基盤として、AIモデルの性能だけでなく、データの所在や運用体制、管理主体まで含めて検討する必要性が高まっていることがあります。

ソフトバンクの生成AI SaaSサービスは、これまでMicrosoft Azure 上で開発・運用してきました。一方で、生成AIの活用領域が広がるにつれて、自治体、公共、社会インフラ、機微情報を扱う企業などから、データの所在や運用体制、クラウド基盤のソブリン性に関する要件が高まってきています。

そこで、ソブリン性を備えたクラウド基盤であるCloud PF Type A上でも、ソフトバンクの生成AI SaaSサービスを実用的に稼働できるのかを検証しました。

同じアプリケーション環境をMicrosoft Azure とCloud PF Type Aのそれぞれに構築し、各クラウド上で独立して稼働させることを前提に、Cloud PF Type A上でも同等のサービス提供が可能かを確認する検証です。

そのため、アプリケーション、RAG構成、LLM連携、ベクトル検索、監視・運用などの観点で、Cloud PF Type A上に生成AIサービス基盤を構築できるかを確認しました。

生成AIサービスでは、ユーザーの質問、参照するナレッジ、LLMへの入力、生成された回答など、扱う情報の性質が非常に重要です。それには、ソブリン性を備えた基盤上でどのようにサービスを構成できるかを、早い段階で技術的に見極める必要があると考えました。

移行検証で確認したかった3つのポイント

藤田：具体的には、WebアプリケーションをOracle Kubernetes Engine (OKE^※1) 上で実行し、ナレッジデータをOCI Object Storageで管理し、認証・認可、ログ、監視、RAG構成をCloud PF Type A上でどのように成立させるかを検証しました。

回答生成については、OCI Generative AIを通して、Sarashina^※2を利用する構成としています。また、RAGのベクトル検索にはAutonomous Databaseを利用し、ナレッジを参照した回答生成が可能かを確認しました。

特に確認したかったポイント1つ目は、アプリケーション展開の実現性です。クラウド基盤が変わると、データベース、ストレージ、生成AI API、認証、ネットワークなど、バックエンドの構成要素も変わります。そのため、既存アプリケーションのコードベースを活用しながら、Cloud PF Type A上のバックエンドサービスに対応できるかを確認しました。

2つ目は、RAG構成の再現性です。生成AIサービスでは、LLMに直接質問を投げるだけではなく、社内文書や業務ナレッジを検索し、その検索結果をプロンプトに組み込んで回答を生成します。今回の検証では、Object Storage、Embedding、Autonomous Databaseによるベクトル検索、Sarashinaによる回答生成までの一連の流れが、Cloud PF Type A上で成立するかを確認しました。

3つ目は、クラウドごとのバックエンド差分を、アプリケーション設計上どのように吸収するかです。Azure 環境とCloud PF Type A環境はそれぞれ独立して稼働しますが、同じアプリケーションを各クラウドへ展開するには、データベース、ストレージ、LLM、RAG関連処理などの差分に対応する必要があります。そのため、クラウド固有の実装をアプリケーション本体から切り離し、環境ごとに適切なバックエンドを利用できる構成にすることも重要な検証ポイントでした。

Cloud PF Type A上に構築した生成AIサービス環境のアーキテクチャー

今回の検証では、Cloud PF Type A上に以下のような生成AIサービス環境を構築しました。

Azure 環境からCloud PF Type A上への展開検証ステップ

Cloud PF Type A上への展開検証は、大きく5つのステップで進めました。

藤田：最初に行ったのは、依存関係の整理です。既存のAzure 環境で、アプリケーションがどのクラウドサービス、API、データベース、ストレージ、認証、ネットワーク設定に依存しているかを洗い出しました。生成AIサービスの場合、LLM、Embedding、ベクトル検索、ナレッジ管理、ログ出力など複数の要素が連携しているため、まずは全体像を正確に把握することが重要でした。

次に、Cloud PF Type A上で再構成する対象の整理を行いました。どの機能をCloud PF Type A上に構築し、どの部分を共通化し、どの部分をクラウドごとに切り替えられるようにするかを整理しました。

3つ目が、アプリケーション展開です。コンテナ化されたWebアプリケーションをOKE上で動作させ、接続先、環境変数、認証情報、バックエンドサービスとの連携部分をCloud PF Type A向けに調整しました。特に、データベースやストレージ、生成AI APIなど、バックエンドの実装差分をアプリケーション側で吸収できるようにする必要がありました。

4つ目が、データ設計とRAGデータ作成方式の設計です。Cloud PF Type A上でRAGを成立させるために、ドキュメントをどのように管理し、どの単位で分割し、どのようにベクトル化し、Autonomous Databaseへ登録・利用するかを設計する必要がありました。

最後に、動作確認を行いました。ユーザーが質問を入力し、ベクトル検索で関連情報を取得し、その検索結果をLLMに渡して回答を生成する一連のフローを確認しました。併せて、ナレッジ登録、アプリケーションの起動、バックエンド連携、ログ出力、監視、エラー時の挙動なども確認しました。

展開検証で直面した技術的な課題

「特に苦労したのは、アプリケーション移行に伴うバックエンド差分への対応」だったと振り返ります。

藤田：生成AIサービス基盤では、データベースやストレージ、生成AIサービス、認証機能など複数のコンポーネントが連携します。しかし、クラウド基盤が変わると、同じ役割を持つサービスであっても設計思想やAPI、制約条件が異なるため、別のクラウド環境上で同等の性能を発揮させるのには各サービスの特性に応じた設計上の調整が必要になります。

今回の検証では、Azure 環境で利用していた構成をCloud PF Type A上で再現するにあたり、バックエンドサービスとの連携方法やRAG構成、LLM連携方式などを見直す必要がありました。また、課金体系やリソース管理の考え方もクラウドごとに異なるため、アーキテクチャ全体を再評価することが求められました。

こうした検証を通じて、単に利用するサービスを置き換えるだけではなく、アプリケーション設計やRAG設計、コスト設計、運用設計まで含めて再検討する必要があることが分かりました。

次章では、今回の検証を通じて見えてきた技術的な論点について紹介します。

移行検証から見えてきた5つの技術的論点

今回の検証を通じて、生成AI基盤をCloud PF Type A上に展開するには、単に利用するクラウドサービスを置き換えるだけでは不十分だと分かり、その理由を5つの論点にまとめました。

技術的論点① クラウドサービス差分の吸収

特に大きな論点は、クラウドサービス固有の差異をどこで吸収するかです。データベース、ストレージ、LLM、Embedding、ベクトル検索などは、それぞれのクラウドで似た機能を持っていても、設計思想や制約、API、データの扱い方が異なります。

Azure 環境とCloud PF Type A環境は、それぞれ独立したアプリケーション環境として稼働します。ただし、同じアプリケーションを両方のクラウドで展開可能にするためには、クラウド固有の仕様にアプリケーション本体が強く依存しすぎない設計が必要です。そのため、抽象化レイヤーを設け、クラウドごとの差分をアプリケーション本体から切り離すことが重要だと分かりました。

技術的論点② RAG構成の標準化

2つ目の論点は、RAG構成の標準化です。RAGは、ベクトルデータベースを用意すれば成立するものではありません。ドキュメントの格納、チャンク分割、Embedding、メタデータ管理、ベクトル登録、検索、プロンプトへの組み込みまで、一連の処理が必要です。さらに、これらの処理はクラウドサービスに依存しやすいため、RAGデータの作成方法と利用方法を標準化しておくことが重要だと感じました。

技術的論点③ LLM変更への対応

3つ目は、LLM変更に伴うアプリケーション設計と品質評価です。OpenAI系のモデルからSarashinaへ変更したことで、プロンプト設計、出力形式、回答の粒度、エラー時の挙動などをあらためて確認する必要がありました。LLMを差し替えられる構成にしておくことは重要ですが、実際にはモデルごとの特性を踏まえた調整や評価が欠かせません。

技術的論点④ コスト・テナント設計

4つ目は、課金体系やリソース制限を踏まえたアーキテクチャー設計です。SaaSとして提供する場合、テナントごとにリソースをどこまで分けるかが重要になります。しかし、クラウドによって課金単位やリソース作成数の制限が異なるため、単純に同じ粒度でリソースを分離できるとは限りません。コスト、管理性、拡張性のバランスを踏まえて、テナント分離の粒度を設計する必要があると分かりました。

技術的論点⑤ 運用監視設計

5つ目は、各クラウド環境を独立して運用するための設計です。Azure 環境とCloud PF Type A環境はそれぞれ独立して稼働するため、環境ごとにログ、監視、障害調査、運用手順を整備する必要があります。特に、Cloud PF Type A上で本番運用を見据える場合、アプリケーション、データベース、LLM、RAG処理、監視基盤のどこで問題が発生しているのかを切り分けられる設計が重要になります。

藤田：今回の検証を通じて、生成AI基盤の展開では、LLMやインフラだけでなく、アプリケーション設計、RAG設計、コスト設計、テナント設計、運用設計を一体で考えることが重要だと実感しました。今後の検証への展望

藤田、今後の検証について次のように展望します。

藤田：次の検証では、より本番運用に近い観点を深掘りしていきたいと考えています。

まずは、性能・負荷検証です。今回の検証では、Cloud PF Type A上で生成AIサービスの基本的な構成が成立するかを中心に確認しました。今後は、同時アクセス数、質問数、ナレッジ量、ベクトル検索件数が増えた場合に、応答時間や安定性がどう変化するかを確認していきます。OKE、Autonomous Database、OCI Generative AI、アプリケーションの各レイヤーで、どこがボトルネックになるかを把握することが重要です。

次に、回答品質の検証です。LLMを変更した場合、同じ質問でも回答内容や表現、情報の拾い方が変わる可能性があります。そのため、Azure 上の既存構成とCloud PF Type A上の構成で、同じ質問に対してどのような検索結果・回答結果になるかを比較し、業務利用に耐えられる品質を確認していきたいです。

3つ目は、RAGデータ作成・利用方式の高度化です。ドキュメントのチャンク分割、メタデータ設計、Embedding、検索条件、プロンプトへの組み込み方によって、回答品質は大きく変わります。今後は、ナレッジ登録から回答生成までの流れをより安定化させ、Cloud PF Type A上でも安定して利用できるRAGデータ作成・利用方式を検討していきます。

4つ目は、コストとリソース設計の検証です。Cloud PF Type A上でSaaSとしてを提供する場合、課金体系やリソース作成数の制限を踏まえた設計が必要です。テナントごとにリソースを分けるのか、共通基盤として集約するのか、どの粒度で分離するのが現実的なのかを、コストと運用性の両面から検証していきたいです。

5つ目は、運用・監視設計の検証です。Cloud PF Type A環境を独立したアプリケーション環境として運用するために、ログ、メトリクス、トレース、アラートをどのように整理するかを検討します。障害時にどのレイヤーで問題が起きているのかを素早く把握できるように、監視項目や運用手順を整備していきます。

最後に、複数クラウドへの展開を見据えたアプリケーション設計の検証です。今回、抽象化レイヤーを設けることで、クラウドごとの差分を一定程度吸収できる見通しが得られました。今後は、データベース、ストレージ、LLM、RAG関連処理などをより疎結合にし、クラウド基盤が変わってもアプリケーション本体への影響を最小化できる設計を検討していきます。

今回の検証では、Cloud PF Type A上でも生成AIサービス環境を構成できる見通しを得ることができました。今後は、性能、回答品質、RAG設計、コスト、運用性、複数クラウドへの展開性をさらに検証し、より安定して提供できる生成AI基盤として成熟させていきたいと考えています。

生成AIの活用が広がる中、AIモデルの選定だけでなく、そのAIを支える基盤のあり方も重要な検討事項となります。本記事が、生成AIサービス環境を検討する際の参考になれば幸いです。

関連記事

関連資料

関連サービス

関連セミナー・イベント

同じカテゴリーの記事をみる