Amazon Web Services ブログ

エンタープライズにおける Amazon Bedrock による生成 AI のオペレーティングモデル

本記事は、2025 年 1 月 29 日に公開された Generative AI operating models in enterprise organizations with Amazon Bedrock を翻訳したものです。


生成 AI は、お客様や従業員のエクスペリエンスを向上させる革新的なアプリケーションの創出を可能にし、革命をもたらします。インテリジェントなドキュメントの処理、翻訳や要約、カスタマーサポートのエージェントを支援する柔軟で洞察に富んだ応答、パーソナライズされたマーケティングコンテンツ、画像やコードの生成などは、生成 AI を使用したユースケースの一例であり、実運用されているものです。

大規模な組織では、複数の事業部門 (LOB) が存在し、中央で管理する組織が存在することが多く、Amazon Web Services (AWS) のマルチアカウント戦略と共に AWS Organizations を適用するのが一般的です。ランディングゾーンを導入して、セキュアなアカウント作成を自動化し、ログ、監視、監査など、アカウント全体にわたる管理を合理化します。 LOB は独自のアカウントやワークロードを運用しますが、Cloud Center of Excellence (CCoE) などの統括チームが、アイデンティティ、ガードレール、アクセスポリシーを管理しています。

生成 AI の導入が進むにつれ、企業は生成 AI のオペレーティングモデルを確立していく必要が生じてきます。オペレーティングモデルは、事業運営を駆動する組織設計、コアプロセス、テクノロジー、役割や責任、ガバナンス体制、そして財務モデルを確立するものです。

本記事では、適用可能な生成 AI のオペレーティングモデルを考察します。

オペレーティングモデルのパターン

俊敏性、ガバナンス、統制などの優先事項に応じて異なる生成 AI のオペレーティングモデルを採用することができます。生成 AI のガバナンスとは、この技術の責任ある開発、導入、利用を促進するフレームワーク、ポリシー、プロセスを意味します。 リスクを軽減し、説明責任を果たし、生成 AI システムと倫理原則や組織目標との整合性を図るためのさまざまな方策を包含するものです。次の図に示すように、3 つの代表的なオペレーティングモデルのパターンは、分散型 (Decentralized) 、中央集権型 (Centralized) 、そして連携型 (Federated) です。

分散型モデル

分散型では、生成 AI の開発や導入は、各 LOB が独自に主導し管理します。LOB は、それぞれの AWS アカウントの AI のワークフロー、モデル、そしてデータを独自に管理します。

これにより、各 LOB はニーズに応じた生成 AI のソリューションを迅速に試行し導入することができるため、市場投入までの時間が短縮され、俊敏性を高めることができます。しかし分散型であっても多くの場合は、LOB は全社的なガバナンス管理と整合性を図り、本番環境への導入にあたっては CCoE チームの承認を得る必要があります。アクセスポリシー、モデルのリスク管理、データプライバシー、コンプライアンス体制などについて、グローバルなエンタープライズの基準に則る必要があるため、ガバナンスが複雑になりえます。

中央集権型モデル

中央集権型では、生成 AI に関連する取り組みは生成 AI/ML を統括するチームが行い、全社にわたる AI のワークフロー、モデル、そしてデータをエンドツーエンドで導入から管理まで行います。

LOB は、AI に関するニーズを統括するチームに伝え、迅速性や市場投入までの時間はトレードオフとなりますが、より強力なトップダウン型のガバナンスを実現します。中央集権型では、市場投入までの時間がボトルネックとなる可能性があるため、LOBからのニーズに効率的に対応できるよう、チームに十分な人員や自動されたプロセスを適切に導入する必要があります。チームの規模を拡大できない場合、中央集権型のアプローチのメリットはガバナンスですが、デメリットの方が大きくなる可能性があります。

連携型モデル

連携型は、生成 AI のプロセスのうち主要なアクティビティを中央の生成 AI/ML プラットフォームチームが管理することで、バランスを取るものです。

LOB が AI のユースケースを開発する一方で、中央のチームがガードレール、モデルのリスク管理、データプライバシー、そしてコンプライアンス体制を整備します。これにより、LOB の迅速なイノベーションを実現しながら、中央がガバナンス領域を監視することができます。

生成 AI のアーキテクチャのコンポーネント

オペレーティングモデルのパターンについて説明する前に、このセクションでは、アーキテクチャで使用されるコンポーネントと AWS のサービスの概要について簡単に説明します。

大規模言語モデル (LLM)

大規模言語モデル (LLM) は、数十億のパラメータを含み、膨大なデータで事前学習された大規模な ML モデルです。LLM は、ハルシネーション、つまり LLM が確信を持って回答しているものの、実際には不正確な回答を提供するということが起こる可能性があります。さらに、LLM の学習に使用したデータが古くなっている可能性もあり、不正確な回答につながることがあります。LLM が不正確な情報を提供する可能性を軽減する 1 つの方法は、Retrieval Augmented Generation (RAG) と呼ばれる技術を使用することです。RAG は、ナレッジの検索とテキスト生成モデルを組み合わせた高度な自然言語処理技術です。RAG は、事前学習済みの言語モデルと検索ベースのアプローチを組み合わせ、より情報量が多く正確な応答を生成します。RAG を設定するには、関連するソースドキュメントをモデルに提供するベクトルデータベースが必要です。RAG を使用すると、関連するドキュメントのセグメントやその他のテキストが検索され、LLM に共有され、コンテンツの品質と関連性を高めた的確な応答が生成されます。

Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった AI 業界をリードする企業が提供する高性能な基盤モデル (FM) を、単一の API を使用して選択できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任あるAIを備えた生成 AI アプリケーションを構築するために必要な機能も幅広く備えています。

Amazon SageMaker JumpStart では、AI21 Labs、Cohere、LightOn などのサードパーティプロバイダーの独自 FM へのアクセスを提供します。さらにAmazon SageMaker JumpStart は、Hugging Face などのサードパーティソースからのオープンソース FM の導入や管理も行えます。

データソース、埋め込み、ベクトルストア

コンテキストや関連情報を提供する組織固有のデータは、通常、内部データベース、データレイク、非構造化データリポジトリ、またはドキュメントストアに存在し、これらを総称して組織データソースまたは独自データストアと呼ばれます。

ベクトルストアは、効率的な最近傍探索アルゴリズムと適切なインデックスにより、大量のベクトルを保存し、検索するためのシステムです。 組織のデータの埋め込み(ベクトル形式でのデータの数学的表現)だけでなく、データの生のテキストもチャンク単位で含まれます。これらのベクトルは、専用の埋め込み生成 LLM によって生成され、組織のテキストチャンクを処理して数値表現(ベクトル)を作成し、ベクトルストアにテキストチャンクと共に保存されます。ベクトルストアや埋め込みについて詳しく知りたい場合は、「生成 AI アプリケーションでベクトルデータベースが果たす役割」を参照ください。

Amazon Bedrock Knowledge Bases を使用すると、Amazon Bedrock の FM を企業のデータに安全に接続して RAG を実現できます。Amazon Bedrock Knowledge Bases は、さまざまなサポート対象のデータソースからのデータ取り込みを容易にし、データのチャンク処理、パース処理、埋め込みを管理し、ベクトルストアに追加します。これらの機能が提供されるため、Amazon Bedrock Knowledge Bases は、RAG を使用して強力な会話型 AI システムを構築するための、フルマネージド型のサーバーレスの選択肢として考えることができます。

ガードレール

コンテンツフィルタリングのメカニズムは、望ましくない有害なコンテンツを最小限に抑えることで、アプリケーションの要件や責任ある AI のポリシーに準拠し、ユーザーと AI のやり取りを制御するためのセーフガードとして実装されています。ガードレールは、ユーザーからの入力と FM からの出力を確認し、安全性が確保されていないトピックをフィルタリングもしくは拒否したり、個人を特定できる情報 (PII) を削除したりすることで、生成 AI のアプリケーションにおけるコンテンツの安全性とプライバシーを強化することができます。

Amazon Bedrock Guardrails は、Amazon Bedrock の機能であり、セーフガードを講じるために使用できます。貴社のポリシーに基づいて、何を条件とするかを決定します。これらのセーフガードは、フレームワークに依存しません。特定のユースケースに合わせて構成を変更した複数のガードレールを作成できます。Amazon Bedrock Guardrails の詳細については、「Guardrails for Amazon Bedrock は、お客様のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードの実装に役立ちます」、「新しい安全フィルターとプライバシーコントロールを備えた Amazon Bedrock のガードレールが利用可能になりました」を参照してください。

オペレーティングモデルのアーキテクチャ

このセクションでは、3 種類のオペレーティングモデルについて概要を説明します。

分散型モデル

分散型モデルでは、LOB が AWS アカウントを所有し管理します。各 LOB はそれぞれの AWS アカウントで生成 AI のコンポーネント、共通機能、アプリケーション、Amazon Bedrock の構成を設定し管理します。このモデルでは LOB が Amazon Bedrock の機能を活用しながら独自の要件に応じて生成 AI のソリューションをカスタマイズすることができます。

このモデルでは、LOB は LLM やガードレールなどのコアコンポーネントを設定し、Amazon Bedrock のサービスアカウント (図中の “Amazon Bedrock Service Account”)  でホスティング、処理、そしてインターフェイスのエンドポイントのプロビジョニングといったことを管理します。そのエンドポイントを通じて、LOB は Amazon Bedrock のサービスにアクセスし、やりとりできます。

LOB は、Amazon CloudWatch Logs および AWS CloudTrail を使用してニーズに合わせてログの取得、分析、監査を行い、アカウントで構成した Amazon Bedrock のサービスの監視や監査を行います。Amazon Bedrock のコストや利用状況は、LOB の AWS アカウントに記録されます。分散型モデルを採用することで、LOB は生成 AI のソリューションを分散型の構成で管理しながら、Amazon Bedrock のスケーラビリティ、信頼性、セキュリティのメリットを享受できます。
次の図は、分散型モデルのアーキテクチャを示しています。

中央集権型モデル

中央の AWS アカウントが、再利用可能なエージェント、プロンプトフロー、共有ライブラリといった生成 AI のコア機能の構成や管理を行う中心的なハブとして機能します。 LOB チームは中央のチームに事業固有の要件やユースケースを提供し、中央のアカウントで要件に沿うように生成 AI のコンポーネントを統合しオーケストレーションします。

生成 AI のソリューションの設定やオーケストレーションは、中央のアカウントで保持されます。しかし一般的には、LOB 固有のリソースやサービスとの連携が必要になり、それを容易にするために、中央のアカウントは LOB の AWS アカウントの API ゲートウェイやその他の連携ポイントを利用します。連携ポイントを通じて、中央の生成 AI のオーケストレーションと、 LOB の業務に特化したアプリケーション、データソース、サービスとの間で、安全で統制されたやりとりが可能になります。この中央集権型のオペレーションモデルは、組織全体における生成 AI のソリューションの共通化、ガバナンス、スケーラビリティを促進します。

中央のチームは、共通の標準、ベストプラクティス、組織のポリシーを順守しながら、生成 AI のコンポーネントの効率的な共有や再利用を可能にします。さらに、LLM やガードレールといった Amazon Bedrock のコアコンポーネントについては、Amazon Bedrock のサービスアカウントで AWS がホストや処理を担い、安全でスケーラブルでハイパフォーマンスな実行環境を確保します。この中央集権型モデルでは、Amazon Bedrock の監視や監査は中央のアカウントで実行できるため、生成 AI のすべてのアクティビティや構成の包括的な監視、監査、分析が可能になります。Amazon CloudWatch Logs は、組織全体における生成 AI のオペレーションの包括的な可視化を実現します。

生成 AI のソリューションの設定やオーケストレーションを中央のアカウントに集約し、同時に LOB 固有のリソースとの安全なインテグレーションを可能にすることで、このオペレーティングモデルは生成 AI の運用における標準化、ガバナンス、集中管理を促進します。AWS のマネージドのインフラストラクチャやサービスのスケーラビリティ、信頼性、セキュリティ、一元化された監視の機能を活用しながら、LOB 固有の要件やユースケースとの統合も可能にします。
以下は、中央集権型オペレーションモデルのアーキテクチャです。

連携型モデル

連携型モデルでは、Amazon Bedrock により、LOB チームがそれぞれの AWS アカウントで、生成 AI の共通機能を開発し、コントリビューションできる協働的なアプローチが可能になります。再利用可能なエージェント、プロンプトフロー、共有ライブラリなどの共通機能を、専任チームまたは CCoE が管理する中央の AWS アカウントに移行することができます。

中央の AWS アカウントは、生成 AI の共通的なコンポーネントを統合しオーケストレートするためのハブとして機能し、アクショングループやプロンプトフローの統一されたプラットフォームとなります。生成 AI のソリューションの設定やオーケストレーションは、LOB の AWS アカウントで保持されますが、LOB は中央のアカウントの Amazon Bedrock エージェント、プロンプトフロー、そしてその他の共有コンポーネントを使用することができます。
この連携型モデルにより、LOB は生成 AI のソリューションの主導権を維持し、中央で管理されるコンポーネントを再利用するといったメリットを享受しながら、特定の事業要件に合わせてカスタマイズすることができます。中央のアカウントは、生成 AI の共有コンポーネントの共通化、ガバナンス、スケーラビリティを維持し、組織全体のコラボレーションや標準化を促進します。

Payment Card Industry (PCI)、PII、General Data Protection Regulation (GDPR)Health Insurance Portability and Accountability Act (HIPAA) に関連するような機密データは、LOB の AWS アカウントで保持される傾向があります。このアプローチでは、LOB がベクトルストアでセンシティブなビジネスデータを管理できるようにし、適切なガバナンスやセキュリティ対策なく中央のチームや CCoE がアクセスできないようにすることができます。

連携型モデルは、分散型の開発、中央集権型の連携、中央集権型の監視を組み合わせたものです。このオペレーティングモデルは、コラボレーション、再利用性、標準化を促進すると同時に、LOB が 生成 AI のソリューションを管理できるようにします。AWS のマネージドインフラストラクチャとサービスのスケーラビリティ、信頼性、セキュリティ、中央でのモニタリング機能を使用し、自律性とガバナンスの調和のとれたバランスを促進します。
以下は、連携型オペレーションモデルのアーキテクチャです。

コスト管理

全社的に Amazon Bedrock の利用状況や、LOB 毎のコストを分析したい場合があるかもしれません。各 LOB の AWS アカウントの基盤モデルのコストや利用状況を追跡するに、LOB 毎のモデルの呼び出しを記録するソリューションを実装できます。

Amazon Bedrock は現在、推論プロファイルを使用したモデル呼び出しのリソースをサポートしています。推論プロファイルを定義して、Amazon Bedrock の利用状況のメトリクスを追跡したり、モデル呼び出しのリクエストを監視したり、スループットを向上させるためにモデル呼び出しのリクエストを複数の AWS リージョンにルーティングしたりすることができます。

推論プロファイルには 2 つのタイプがあります。Amazon Bedrock にあらかじめ定義されているクロスリージョン推論プロファイルは、モデルのリクエストをルーティングできる複数の AWS リージョンを含んでいます。もう 1 つはアプリケーション推論プロファイルで、これはオンデマンドのモデル呼び出しのリクエストを送信する際に、コストとモデルの使用状況を追跡するためにユーザーが作成するものです。コスト配分タグなどのカスタムタグをアプリケーション推論プロファイルに添付することができます。プロンプトを送信する際には、推論プロファイル ID または Amazon リソース名 (ARN) を含めることができます。この機能により、さまざまな LOB、コストセンター、もしくはアプリケーションのコストの追跡や監視をすることができます。アプリケーション推論プロファイルの詳細については、「Amazon Bedrock を使用した生成 AI のコストと使用状況の追跡、配分、管理」を参照してください。

結論

生成 AI のオペレーティングモデルは中央集権型モデルから始めることが多いですが、生成 AI の技術開発の急速な発展、俊敏性の必要性、そして価値を迅速に獲得したいという要求の高まりにより、連携型モデルへと向かっていく傾向があります。

連携型のオペレーティングモデルでは、LOB は専門知識や事業課題を精通しているといった利点を活かして、生成 AI のソリューションを用いたイノベーションや実験を進めていくための自由度を獲得することができます。 データアクセスの方針、モデルのリスク管理、コンプライアンスの監視といった AI のワークフローにおける重要な要素は、中央のクラウドガバナンスチームによって管理されます。LOB が開発し、成功を収めた生成 AI ソリューションは、中央のチームによって全社的な再利用が推進され、展開されます。

この連携型モデルは、ドメインの問題に最も精通している LOB からのイノベーションを加速させると同時に、中央のチームは、組織のポリシーに準拠したソリューションを管理、強化、拡張し、それらを効率的に他の関連する事業分野に展開することができます。

このオペレーティングモデルを維持するために多くの場合、LOB と協働するビジネスオーナーを擁した専任のプロダクトチームを設置します。このチームは、LOB の変化するニーズに対応し、LLM やその他の生成 AI 技術の急速な進歩に遅れを取らないよう、生成 AI のサービスの継続的な進化、リファクタリング、強化を担当していきます。

連携型モデルは、完全に分散化された取り組みの場合に生ずるリスクを軽減しながら、過度に中央集権化されたアプローチで生ずるボトルネックを最小限に抑えるといったバランスをとるものです。 中央のチームの調整によってビジネスの俊敏性を向上させ、AI の状況が進化する中で、イノベーションのゴール、リスクの許容、迅速な価値の創出といったニーズに応じ、かつコンプライアンスに準拠しながら品質の高い生成 AI の機能の実現を加速することができます。

企業が生成 AI による革命を活用する場合、Amazon Bedrock は、組織のニーズに合わせた柔軟なオペレーティングモデルを構築する理想的な基盤となります。中央集権型、分散型、連携型のいずれのアプローチから始める場合でも、AWS は生成 AI のライフサイクル全体をサポートする包括的なサービスを提供しています。
Amazon Bedrock を試して、組織に適したオペレーティングモデルをどのように実装していくか、フィードバックをお寄せください。


著者について

Martin Tunstall は、AWS のプリンシパルソリューションアーキテクトです。金融業界で 30 年以上の経験を持ち、グローバルな金融および保険業界のお客様が Amazon Web Services (AWS) の可能性を最大限に引き出せるよう支援しています。
.

.

Yashar Araghi は、AWS のシニアソリューションアーキテクトです。インフラおよびアプリケーションのセキュリティソリューションの設計と構築で 20 年以上の経験があります。政府、教育、金融、エネルギー、インフラなど、さまざまな業界のお客さまと仕事をしてきました。AWS での過去 6 年間では、お客様が AWS で安全で信頼性が高く、パフォーマンスに優れ、コスト最適化されたクラウドソリューションの設計、構築、運用できるよう支援してきました。

.

翻訳者について

川口賢太郎 (Kentaro Kawaguchi) と白木文香 (Ayaka Shiraki) は、AWS プロフェッショナルサービスのシニア CS&O アドバイザリーコンサルタントとシニア PT でアドバイザリーコンサルタント、デジタル戦略立案とそれに即した組織の変革に注力しています。CCoEAI CoE などの xCoE の組成支援などに従事しています。