前回の記事[
1]では、「Hybrid by Design」という考え方をもとに、テクノロジー選定やシステム構築「場当たり的に積み上げる」のではなく、企業戦略に沿って計画的に設計されたハイブリッド環境を構築することの重要性を紹介しました。本稿では、その思想をさらに一歩進め、近年多くの企業が直面している「生成AIを本番でどう使いこなすか」というテーマに焦点を当てます。AI活用を単なる実験やPoC (Proof of Concept、実証実験) で終わらせず、業務の一部として定着させるために必要なリファレンス・アーキテクチャーを、「Hybrid by Design」の視点から整理します。
企業をとりまく生成AI環境の現状
この1〜2年、生成AIを活用したPoCは多くの企業で急速に進みました。部門やチームがそれぞれ自らの業務に合わせて生成AIツールを試し、業務効率化を狙った小規模な検証が並行して行われています。このように現場主導でPoCを進めるアプローチは、生成AIの初期導入期としては合理的な選択でした。過度なガバナンスをかけず、各部門が自由に試行できたことで、「生成AIで何ができるのか」「どの業務に適用できるのか」を短期間で把握できた企業も少なくありません。いわば、「試しながら学ぶ段階」として多くの成果が得られた時期だと言えます。
しかし、PoCが増えれば増えるほど、社内の環境は複雑化します。図1は、そうした状況を表しています。企業内では複数のプラットフォーム上にLLM (Large Language Models、大規模言語モデル) が配置され、それぞれのモデルを利用するアプリケーションも、Webブラウザ、専用アプリなど多様に存在しています。さらに、RAG (Retrieval-Augmented Generation) やチューニングに使うデータも部門ごとのデータベースやクラウド・ ストレージに分散しており、モデル・アプリ・データがそれぞれ独立して運用されており、全体最適化が難しいのが現状です。
こうした構成は、個々の部門が迅速に成果を出すうえでは一定の合理性があります。しかし、PoCを本番環境へと展開する段階になると、「どのアプリがどのモデルを利用しているのか」「どのデータを参照しているのか」といった全体像の把握が難しくなり、管理や拡張の障壁となります。この傾向は個別の企業に限らず、ガートナーも同様に生成AIが本番導入に進まない理由として「不十分なリスク管理」と「コストの増大」を主要因に挙げています[2]。将来の本格展開フェーズでは、こうした状況を整理し、モデル・アプリ・データといった要素をどう統合的に設計・管理していくかが鍵になります。
図1. 企業におけるLLM活用の現状 ― 部門ごとに独立した利用の広がり
現場で顕在化する3つの構造的課題
生成AIの活用を全社レベルで進める段階に入ると、多くの企業で共通して浮かび上がるのが、モデル・アプリ・データという3つの要素が適切に設計・管理されないまま個別に運用されていることです。
ここでは、それぞれの観点から現場で生じている典型的な課題を整理します。
- 生成AIモデル管理 ― 利用状況の可視化と制御の欠如
複数のLLMを業務で活用するケースが増えるなかで、「どのモデルが、どの部門で、どのような目的で使われているのか」を把握できていない企業が多く見られます。APIを通じたモデル呼び出しの履歴や利用量が集約されておらず、コストやパフォーマンスの全体像が見えない状態です。また、モデルごとの精度や出力内容の妥当性を定期的に検証するプロセスも整備されていないことが多く、意図しない回答や偏りが発生しても、原因を特定できないリスクがあります。これらは単にガバナンスの問題ではなく、「モデルの利用をどのように管理・制御するか」というアーキテクチャー 上の設計課題です。アクセス経路、利用上限、評価結果を一元的に扱う仕組みがなければ、安全性とコスト効率を両立させることは困難です。
- 業務アプリケーション管理 ― 個別最適の罠
生成AIを活用する業務アプリケーションは、部門単位で個々に開発・運用されてきました。それぞれの現場で目的に合わせた最適な仕組みを素早く構築できた一方で、結果として、同様の機能を持つアプリケーションが複数存在し、保守や更新の手間が分散しています。また、プロンプトもプロジェクトごとに個別管理されており、再利用や標準化が進まないまま増えていく傾向があります 本来、アプリケーションの稼働環境やプロンプトを一元的に管理できれば、ナレッジやノウハウの共有が容易になり、開発・保守コストの最適化につながります。しかし現状では、アプリ単位の独立した運用が障壁となり、全社的な展開スピードを下げる要因にもなっています。
- AIデータ管理 ― 更新性と追跡性の課題
生成AIの活用を継続的に高めていくためには、チューニング・ データやRAG用データの品質と更新性を保つことが不可欠です。しかし現場では、これらのデータが部門単位で個別に蓄積され、差分管理や履歴追跡の仕組みが整っていないケースが多く見られます。たとえば、RAGで利用する社内ドキュメントが更新されず、古い情報を基に回答が生成されるといった課題や、ユーザーからのフィードバックがチューニング・ データに反映されないといった問題が発生しています。こうした状況を防ぐには、RAGやチューニング用のデータセットを統合的に管理し、更新履歴・評価データ・差分情報を追跡できる仕組みが必要です。データの信頼性と透明性が担保されてはじめて、生成AIを安心して業務に適用できる状態が整うといえます。
生成AIモデル管理、業務アプリ管理、AIデータ管理を実現するアーキテクチャー
ここまで整理した課題に対する解決策を図2に示します。本アーキテクチャー は、生成AIモデル、業務アプリケーション、AIデータという3つの領域を統合的に設計・管理することで、分散化したAI活用を持続的かつ安全に運用するためのアーキテクチャーといえます。
図2. AIゲートウェイを中核とした企業AIアーキテクチャー
- 生成AIモデル管理
生成AIモデルはあえて単一の環境に閉じずマルチクラウド環境で柔軟に利用できるように設計します。そのうえで、各モデルへのアクセスはAIゲートウェイを経由して一元的に制御します。AIゲートウェイは、すべてのモデル呼び出しを統合的に管理し、利用状況やコストの可視化、アクセス制御、セキュリティー・ フィルタリングを全社統一の基準で適用します。これにより、各部門が自由に生成AIモデルを選択しつつも、企業全体としては統制の取れた利用が可能になります。
- 業務アプリケーション管理
部門ごとに個別開発されていたアプリケーション群を、共通レイヤー上で整理・統合します。プロンプトやUIフレームワーク、ロジックなどを共通化することで、同種アプリの重複開発を防ぎ、運用・保守コストを抑制します。また、アプリケーション層を統一することで、どのアプリがどのモデルを利用しているかが自動的にトレース可能となり、新しいモデルへの切り替えや影響範囲の分析も容易になります。これは、PoCから本番展開への移行を大幅に加速させる効果をもたらします。
- AIデータ管理
学習データやRAG用データが部門ごとに分散していた状態を見直し、統合されたデータ基盤に集約します。データソースを統合的に管理することで、チューニング履歴や更新差分、RAG対象情報を体系的に追跡可能にします。これにより、回答精度の改善サイクルを継続的に回しながら、安全かつ透明性の高いデータ利用を実現します。
このように、モデル・アプリ・データの3領域を統合的に設計することで、企業は次のような成果を同時に実現できます。
- コスト最適化：利用の重複を削減し、リソース配分を最適化
- セキュリティー強化：統一基準のアクセス制御と監査が可能
- 視化の向上：利用状況や依存関係を俯瞰的に把握
- 再利用性の向上：プロンプト・モデル・データを横断的に再利用
- 展開スピードの加速：PoCから本番への移行を容易に
本アーキテクチャー は、単なる技術構成ではなく、企業が生成AIを「試す」段階から「使いこなす」段階へ進むための「Hybrid by Design」 を体現した構造的アプローチと位置づけられます。
AI活用のアーキテクチャー進化：AI by DefaultからAI by Designへ
図3は、これまでご説明してきた考え方の背景にある「AI活用のあり方の違い」を、2つの構図で比較しています。
図3. 「AI by Default」 から 「AI by Design」 へ
AI by Default：積み上げによる複雑化
左側は、多くの企業が現在直面している「AI by Default」の状態です。アプリごとに個別にLLMへ接続しており、利用経路・認証方式・セキュリティー 基準がそれぞれ異なります。このため、誰がどのモデルをどのように利用しているのかを把握できず、モデルの切り替えやガバナンスの強化が困難になります。結果としてAI活用が属人化し、全社的な拡張や再利用が難しくなる構造です。
AI by Design：意図を持った設計による統制
右側の「AI by Design」は、同じマルチクラウド環境を前提にしながらも、すべてのアプリケーションがAIゲートウェイを経由してモデルにアクセスする構成です。アプリケーション側から見れば、接続先を意識せずにLLMを利用でき、モデルの追加・切り替えもアプリ改修なしで行えます。一方、運用側ではAIゲートウェイを通じて利用量やコストの可視化、アクセス権限・セキュリティ統制の一元化を実現でき、柔軟性とガバナンスを両立できます。
「AI by Default」 が現場主導の拡散フェーズだとすれば、「AI by Design」 は企業全体でAIを持続的に活用するための構造化フェーズです。生成AIを「試す」段階から「使いこなす」「拡張する」段階へと進むためには、このようなアーキテクチャー レベルでの整理と設計が不可欠です。
統合AI基盤：リファレンス・アーキテクチャー
前章で紹介した「AI by Design」は、AI活用を属人的なPoC段階から脱し、企業全体で持続的に運用できる形へと進化させるための設計思想でした。この章では、その思想を実装レベルにまで落とし込み、私たちのプロジェクト経験をもとに整理した統合AI基盤アーキテクチャー を紹介します (図4)。
図4. 統合AI基盤：リファレンス・アーキテクチャー
このアーキテクチャー は、大きく8つのレイヤーから構成されています。それぞれのレイヤーは、生成AIアプリケーションを安心・安全・迅速に展開するために必要な機能を担い、全体としては「AIを企業インフラとして運用するためのリファレンス・アーキテクチャー 」を示しています。
最大の特徴は、これら8つのレイヤーが疎結合に設計されている点です。そのため、お客様はすべての機能を一度に導入する必要はありません。たとえば、まずは「AIゲートウェイ」でガバナンスを確立し、次に「AIモデル基盤」や「データ基盤」へと拡張していくといった、課題解決の優先度に応じた段階的導入が可能です。これにより、変化の早いAI技術環境の中でも、柔軟かつ持続的な進化を実現できます。
アプリケーションとエージェント ― 多様化する利用ニーズに対応
最上位層には、ユーザーが直接利用する生成AIアプリケーションが配置されます。FAQ、RAG、文書要約などの業務アプリを共通基盤上で実行し、プロンプトやアプリ資産を一元管理します。この共通化により、アプリ開発の再利用性と保守効率を大きく高めることができます。
また、AIエージェント共通基盤を組み合わせることで、個々のアプリを越えたタスク実行―たとえば「対話による問い合わせ対応」から「自動レポート作成」「外部システムとの連携」まで― をエージェントが自律的に連携・遂行できるようになります。
AIゲートウェイ ― 「AI by Design」を体現する中核
この構造の中心に位置するのがAIゲートウェイです。すべてのモデル・アクセス をゲートウェイ経由に統一することで、認証、アクセス制御、コスト可視化、ガードレール適用、監査ログ管理などを一元的に行います。これにより、「誰が・どのモデルを・どのように使っているのか」を正確に把握でき、セキュリティー とコンプライアンスを担保しながら、複数クラウドやオンプレ 環境を横断してAIを安全に活用できます。まさに、AI by Designの理念を最も具体的に体現する層です。
AIモデル管理とMCP基盤 ― モデルを運用資産へ高める
AIゲートウェイの背後には、複数のクラウド上に分散する外部LLMが存在します。一方で、オンプレ環境に おいて独自に運用されるモデル群を統括するのが、AIモデル管理基盤です。この基盤では、LLMの実行、管理、チューニングを行います。外部の汎用LLMとは異なり、機密性の高いデータや業務特化の要件に対応するため、企業内での安全なモデル運用を実現します。また、特化型のSLM (Small Language Model) を活用することで、業務ごとに最適化された軽量モデルを効率的に展開できます。チューニング環境を備えており、ドメイン知識の反映や精度向上を継続的に行うことが可能です。
また、Anthropicが提唱する MCP (Model Context Protocol) [3]のサーバー群を MCPサーバー基盤上で実行することで、エージェントは社内外のシステムやツールを、標準インターフェースを介して安全に呼び出せるようになります。
データとガバナンス ― AIの信頼性を支える
AIの性能と信頼性を支えるのはデータです。AIデータ基盤では、文書データ、構造化データ、ナレッジグラフなどを統合的に管理し、RAGやチューニングで利用されるデータの品質・履歴・更新性を確保します。
さらに、その下層にはAIセキュリティー/AIガバナンス基盤を配置。リスクアセスメント、トレーサビリティ、説明責任を実装し、AIの全ライフサイクルを通じて透明性を維持します。
おわりに ― 持続可能なAI活用に向けて
生成AIをめぐる技術は、いまも日々進化を続けています。数か月前に最適だったモデルやAPIが、今日には別の選択肢に置き換わることも珍しくありません。こうした変化の速い環境において重要なのは、特定のモデルやクラウドに依存せず、変化そのものを前提に設計された柔軟な基盤を持つことです。本稿で紹介したリファレンス・アーキテクチャは、まさにそのための指針です。AIゲートウェイを中心に、アプリケーション、モデル、データを疎結合に統合することで、新しい技術を容易に取り込みながら、ガバナンスとセキュリティを維持することができます。「Hybrid by Design」 とは、単に複数環境を「つなぐ」ことではなく、将来の変化を見据えて「設計する」ことを意味します。
このアーキテクチャー は、特定の製品やプラットフォームに依存しません。各レイヤーはOSS、 IBM製品群、さらには他社のクラウドサービスを組み合わせて構成できます。重要なのは「何を使うか」ではなく、「どう設計し、どう連携させるか」です。「Hybrid by Design」 の思想は、まさにこの「選択と統合の自由」 を前提としています。
企業がこのアーキテクチャーを自社のエンタープライズAI基盤として定着させたとき、生成AIは一過性のブームではなく、事業を支える持続的な能力へと変わっていきます。「Hybrid by Design」 が示すのは、単なる技術構成ではありません。それは、AIを信頼できる企業インフラとして根付かせるための設計思想であり、次の変化を恐れず受け入れ、進化し続けるためのアーキテクチャー です。この考え方こそが、AI時代の企業が持つべき新しい競争力の源泉になると私達は考えています。
参考文献
[1]IBM：Hybrid by Design : 新しいIT戦略施策の策定アプローチ「Hybrid by Design」とは，https://community.ibm.com/community/user/japan/blogs/provision-ibm1/2025/07/14/vol101-004-computing
[2] Gartner：Gartner Predicts 30% of Generative AI Projects Will Be Abandoned After Proof of Concept By End of 2025，https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025
[3] Anthropic：Introducing the Model Context Protocol, https://www.anthropic.com/news/model-context-protocol
IBM、IBM ロゴは、米国やその他の国における International Business Machines Corporation の商標または登録商標です。
他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リスト
については、https://www.ibm.com/legal/copyright-trademark をご覧ください。
ProVision 一覧はこちらから