Model-as-a-Service とは
Model-as-a-Service (MaaS) は、AI モデルを共有リソースとして提供し、組織内のユーザーがオンデマンドでアクセスできるようにするアプローチです。MaaS は、アプリケーション・プログラミング・インタフェース (API) エンドポイントの形ですぐに使える AI 基盤を提供し、プライベートかつ高速な AI を大規模に活用できるよう支援します。
多くの組織が AI を活用したいと考えていますが、エンタープライズ向けのプライベートモデルを利用する段階で、ほとんどの組織が行き詰まってしまいます。
Hugging Face のようなパブリックソースから入手できる事前トレーニング済みの AI モデルは、より利用しやすくなってきています。また、大規模 GPU (グラフィックス・プロセッシング・ユニット) などの適切なハードウェアがあれば、モデルの稼働は実現可能な目標だと思えるでしょう。しかし、問題があります。モデルが稼働したら、誰がそれを使用できるのでしょうか？そして、誰がそれを拡張できるのでしょうか？
プライベート AI モデルを拡張するには、単一のモデルインスタンスを複数のユーザーと複数のアプリケーションが同時に利用できるようにする必要があります。そうでなければ、モデルを利用できるのはそれを作成したユーザーのみとなり、非常に非効率的です。
そこで役立つのが MaaS です。
Model-as-a-Service では、データに対するコントロールを損なうことなく、1 つの組織内の複数のチームやアプリケーション全体で、プライベートに共有されるモデルにアクセスできます。
Model-as-a-Service の機能とは
組織が AI を導入し始める際、使いやすいツールやインタフェースから始めるのが一般的です。しかし利用が拡大するにつれて、「いくつかのモデルを試す」ことから「AI を大規模に運用する」ことに重点が置かれるようになっていきます。実稼働を開始したときのモデルは少数でも、時間の経過とともに、言語モデル、画像モデル、音声モデルなど、さまざまな種類のモデルを運用するようになります。さらに、複数のバージョンやユースケースを扱うことも珍しくありません。
つまり、「職人」的なアプローチ (すべてを手動で行う) から「工場」的なアプローチ (モデルを効率的かつ一貫して管理する) への移行が必要になります。
このすべてを信頼性が高くスケーラブルな方法で管理することが、Model-as-a-Service の核心です。
検索拡張生成 (RAG)、エージェント型 AI、コーディングアシスタントなどの AI パターンを検証するのにパブリック AI プロバイダーは必要ありません。プライベート AI モデルは、エンドユーザーの利便性に影響を与えることなく、これらのツールを駆動できます。
Model-as-a-Service は、Mistral、Llama、DeepSeek など、公開されている大規模言語モデル (LLM) の利用を支援することを目的としています。また、事前トレーニング済みの基盤モデルに限定されるものではありません。MaaS は、ファインチューニング済みのモデルだけでなくゼロから構築された予測型 AI モデルまでも、すべてを同一の完全にサポートされたプラットフォーム上で提供できます。
典型的な MaaS 実装では、IT チームや AI プラットフォーム・エンジニアリング・チームが、開発者やビジネスユーザーなどの内部顧客向けに API エンドポイントを通じて AI モデルを提供します。一般に、MaaS 環境はチーム間や運用間の統合を単純化するために、API ゲートウェイを備えたハイブリッドクラウド AI プラットフォーム上に構築されます。MaaS の主要コンポーネントには、モデル、スケーラブルな AI プラットフォーム、AI オーケストレーション・システム、API 管理などがあります。これらすべての要素により、Model-as-a-Service はスケーラブルな AI 戦略をサポートできるようになります。
AI テクノロジーの導入に関する 4 つのキーポイント
Model-as-a-Service でできること
包括的な MaaS ソリューションは、AI の統合を容易にします。時間と費用を節約し、AI 戦略のコントロールを維持できるようにします。MaaS は、以下の特性によって定義されます。
アクセス性と拡張性：多くの場合、組織は AI 戦略のコントロールを維持するためにプライベート AI を構築します。しかし、使いにくければ誰も導入しません。プライベート AI を成功させるには、公開されている AI サービス (OpenAI、OpenRouter、Gemini など) と同様に使いやすいものであることが必要です。MaaS は AI の専門家でない人でもアクセスできるようにするべきです。そうすることで、適切な拡張が可能になります。また、日常業務に統合できるだけでなく、組織全体の運用に拡張できるようにするべきです。
追跡可能かつ調整可能：Model-as-a-Service の利用者、利用量、利用目的を把握することは重要です。これにより、利用状況を報告 (ショーバック) するか、それに課金 (チャージバック) するかを選択できます。利用状況を追跡できない場合、各チーム間でのコスト、容量、公平性の管理が困難になります。
透明性とセキュリティ：プライベート AI モデルを最大限に活用するには、独自のエンタープライズデータが不可欠です。また、データの送信先を規定する厳格なルールの遵守も不可欠です。MaaS を利用することで、このモデルを組織独自のものとし、データに対する完全なコントロールを維持できます。透明性を提供しない「ブラックボックス」モデルには注意が必要です。説明可能性と追跡可能性は、AI モデルを理解し、効率を向上させ、倫理的な AI ベストプラクティスを維持するのに役立ちます。
LLMaaS と MaaS の違い
Large Language Model-as-a-Service (LLMaaS) は、複雑な言語処理などの LLM 機能に特化した MaaS の一種です。
LLM はディープラーニング・モデルであり、さまざまな言語を理解してコミュニケーションできるように大量のデータを処理するよう構築されています。LLM は生成 AI に使用され、チャットボットの作成に広く活用されています。また、今日の先進的な AI ユースケースの多く、たとえば RAG、エージェント型 AI、コーディングアシスタントなどの中核にもなっています。
LLMaaS と比べて、MaaS はテクノロジーに依存しない特性を持っています。新たなモデルが次々と登場する中、MaaS は適応することができます。この柔軟性により、モデルの変更や入れ替わりが発生しても、モデル提供やアクセス機能の安定性を維持できます。
Model-as-a-Service を選ぶ理由
MaaS を導入するメリットは、リソースを自らコントロールできる点にあります。予算や AI スキルが不足しているチームでも、独自の条件で独自のモデルを構築し、トレーニングし、提供することができます。
インフラストラクチャと GPU の管理にはコストがかかります。プライベート AI プロバイダーになることで、AI サービスの断片化がもたらす複雑性を回避し、インフラストラクチャのコストを抑えることができます。
MaaS の具体的なメリットは以下のとおりです。
- 価値実現までの時間の短縮：MaaS により、基盤となるインフラストラクチャの管理ではなく、アプリケーションの構築やビジネス上の課題の解決に集中できるため、デプロイメントとイノベーションの迅速化につながります。
- 効率化とコスト削減： AI インフラストラクチャが一元化されているため、複数の AI サービスではなく、単一のソースから作業できます。これにより、作業の重複、過剰な支出、リソースの無秩序な分散を回避できます。
- 時間管理の向上：GPU の管理には、熟練した専門家と予算が必要です。MaaS を活用すれば、AI チームは時間のかかる反復作業ではなく、モデルの管理や提供といった職務に専念できます。
- プライバシーとセキュリティ：プライベート AI プロバイダーとして AI モデルを自らホストすることで、一般公開されているインフラストラクチャの利用を回避できます。データが第三者に公開されないため、既存のセキュリティポリシーに基づいたデータ保護とガバナンスの維持が容易になります。
Model-as-a-Service を自社で構築する際に考慮すべき点
プロバイダーが提供する既成の MaaS ソリューションを利用できますが、独自に構築することもできます。社内のチームが社内用の MaaS ソリューションを開発し、配布・運用化することも可能です。
自社のニーズに合ったモデルサービスを作成することは重要ですが、それは自社で開発する際の多くの考慮事項のうちの、最初のステップに過ぎません。開発を始める前に検討すべき要素としては、他に以下のようなものがあります。
- データ収集プロセス：トレーニングデータが高品質であることをどのように保証するのか。個人データをどのように保護するか。
- リソース管理：MaaS と GPU の作成、構築、管理は誰が担当するのか。
- 信頼できるインフラストラクチャ： お使いのインフラストラクチャは、新しい AI モデルをサポートできるほど信頼性の高いものか。モデルの作成後、そのメリットを享受できるリソースはあるか。
開発を始める前にこれらの質問に答えておくことが、成功するための基盤を築くのに役立つでしょう。
MaaS とソブリン AI
ソブリン AI は、レンタルする AI から所有する AI への移行を表すものです。つまり、テクノロジーを自社で所有し、データをローカルに保ち、企業の価値観や法的要件を AI システムに反映させることです。
MaaS では、プロバイダーがモデルを変更したり、アクセスを遮断したりしても、ユーザー側にできることはありません。ソブリン AI とは、他社サービスへの依存から脱却し、自社所有へ移行することです。
ソブリン AI を追求するにあたり、自社の現在地と次にどこに進むべきかを理解するために、主権における成熟度を把握しておくことが重要です。
ゼロ主権： ほとんどの企業はここからスタートして MaaS を使用します。モデルを十分に理解していないまま使用し、処理のために国外にデータを送信している段階です。このシナリオでは、ユーザーはあくまでテナントであり、プロバイダーがサービスを打ち切ると、AI も消滅します。
部分的主権：中間地点であるこの段階では、オープンウェイト・モデルを使用し、リージョン内のインフラストラクチャ上でそれらをホストしています。ユーザーは、モデルの知識を形成する方法と、コードを所有する方法を理解しています。このシナリオでは、NVIDIA 製のチップや、海外拠点のクラウドプロバイダーを利用しているケースがほとんどです。つまり、外部ハードウェアに依存しています。
完全な主権：AI は国内の拠点に置かれ、自社所有のハードウェア上で動いています。ローカルデータで学習し、国内の電力で動作します。
AI 推論を重視すべき理由
MaaS は、モデルへのアクセスを容易にするために極めて役立つツールです。しかし、推論がうまく機能していないなら、MaaS を使用しても、求める動作をしないモデルにアクセスしているだけです。
推論は生成 AI の中核です。しかし、モデルが必要とするデータとメモリーが増えてくると、ハードウェアとアクセラレーターはそれに対応しきれなくなります。そして、エンタープライズレベルの戦略を実行するために巨大なモデルが必要になると、状況が複雑になる可能性があります。つまり AI 戦略の成否は、推論機能をサポートするハードウェアとソフトウェアによって決まることになります。
推論機能に信頼性があれば、MaaS のような有用なツールやシステムに投資して、推論能力をさらに強化することができます。
Red Hat でできること
Red Hat® AI は、 vLLM 搭載のサーバーを通じて、高速で柔軟かつ効率的な推論を行うように構築されています。モデルをデータと確実に接続し、専用エージェントのカスタマイズと開発を単一のプラットフォームで行うことができます。オープンソースを基盤として構築された当社の製品により、あらゆる規模で AI ワークフローをエンドツーエンドで完全に制御することができます。
また、Red Hat AI ポートフォリオに Red Hat AI Enterprise が追加されました。これは、AI 推論、エージェント型 AI ワークフロー、AI 対応アプリケーションをあらゆるインフラストラクチャ上でデプロイ、管理、スケーリングするための統合 AI プラットフォームです。
Artificial Intelligence (AI)
See how our platforms free customers to run AI workloads and models anywhere
