生成AI能力の構築における一般的な技術的落とし穴が、厳しい経験から明らかになり、それらを克服するための実証済みの戦略が示されています。
生成AI時代における成長は、まさに古典的な「二歩進んで一歩下がる」ケースのように見えます。企業が生成AI特有の複雑さに取り組むにつれて、最初の進展が逆戻りややり直しにつながり、場合によっては開発を完全に停止させる恐れがあります。
フラストレーションと遅延の原因は多くあり、十分な人材不足から継続的なデータ品質の問題に至るまで様々です。しかし、私たちが2年間にわたり150社以上の企業と生成AIプログラムで密接に連携してきた経験から、構築の過程でほぼ必ず表面化する2つの障害が明らかになりました。
1. イノベーションの失敗（Failure to innovate）
プロセス上の制約、焦点の欠如、およびイノベーションを押しつぶすやり直しのサイクル。
価値のある問題を解決できるはずのチームが、実験の再作成に詰まったり、コンプライアンスチームを待ったりしています。コンプライアンスチーム自体も、開発のペースについていくのに苦労しています。私たちの経験では、生成AIにおけるチームの「イノベーション」時間の約30%から50%が、ソリューションをコンプライアンスに適合させること、または組織のコンプライアンス要件が固まり実用的になるのを待つことに費やされています。チームは重要でない問題に取り組み、作業を重複させ、再利用できず、真の価値を引き出すのにしばしば失敗する使い捨てのソリューションを作成しています。
2. スケールの失敗（Failure to scale）
スケールを阻害するリスク懸念とコスト超過。
真の価値の可能性を示す数少ないソリューションについて、企業はプロトタイプから本番環境への溝を越えることにほとんど失敗しています。生成AIアプリケーションをスケールする際のセキュリティとリスクの懸念（評判リスクを含む）は個別に対処され、克服するには大きすぎ、費用がかかりすぎます。
多くの場合、これらの問題は、企業がパイロットから運用規模に移行しようとする際に順番に発生しますが、一部のケースでは、企業はこれらの障害に同時に遭遇することがあります。残念ながら、これらは単一のアプリケーションだけでなく、生成AIプログラム全体を迅速に頓挫させる可能性があります。不正確な結果やハルシネーションに伴うリスクと労力はプロセスの一部ですが、時期尚早の失敗（ブランドと矛盾するメッセージングからポリシー違反に至る例があります）は、適切な準備やテストプロセスに慣れていないエグゼクティブの間で過度の懸念を引き起こす可能性があります。場合によっては、これらの不十分なテスト結果が、組織に生成AIプログラム全体を中止させることにつながり、イノベーションを妨げ、新しいスキルと能力の開発を停止させ、最終的に企業が目指していた意図された価値の獲得からさらに遠ざけてしまいます。
順番に発生するか同時であるかにかかわらず、これらの問題は、多くの場合、速く進むことと慎重に進むことのトレードオフに帰着する反応です。経験は、これが誤った選択であることを示しました。企業は、プラットフォームを意図的に構築することで、リスクを管理しながらイノベーションを可能にすることができます。プラットフォームとは、検証されたサービス（例：倫理的なプロンプト分析、大規模言語モデル[LLM]オブザーバビリティ、事前に承認されたプロンプトのライブラリ、マルチクラウド自動化、アクセス制御）と、見つけやすく、使用しやすく（そして再利用しやすい）資産（例：アプリケーションパターン、再利用可能なコード、トレーニング資料）の集中化されたセットです。これらの機能を単一のプラットフォームに統合することで、製品がコンプライアンス要件をはるかに効率的に満たすことが保証され、私たちの経験では、これにより通常必要とされる非本質的な作業の30%から50%を実質的に排除するのに役立ちます。
業界を超えた企業のために数十の生成AIソリューションを構築してきた私たちの経験から、最も成功している生成AIプラットフォームには3つのコアコンポーネントが含まれていることが示されています。
1. セルフサービスポータル（A self-service portal）
イノベーションとスケールの両方をサポートするには、ビジネス全体の数十、さらには数百ものチームがツールとサービスに簡単に、かつ安全にアクセスできる分散型生成AI能力が必要です。安全でコンプライアンスに準拠したセルフサービスポータルは、次の2つの方法でこの必要性を満たすことができます。
開発者の実現（Developer enablement）：効果的であるためには、このポータルとその基盤となるインフラストラクチャ（例：OpsLevel、Cortex、Port）は、すべての検証済み生成AI製品と能力への単一のアクセスポイントを提供する必要があります。この方法により、開発者は既存のアプリケーションパターンをインスタンス化し、セキュリティとスケールについて事前に構成された承認済み能力を使用して、数分以内に特定のソリューションの開発を開始できます。ポータルのウェブインターフェースは、生成AI製品をプロビジョニングおよびデプロイするためのシンプルなポイントアンドクリックプロセスなどのユーザー設計原則を取り入れ、さらに、開発者が自身の能力を向上させることを可能にするために、すべての生成AIトピック（例：新しいリソースのデプロイ方法、既存のアプリケーションの活用方法）に関するドキュメントと学習モジュールの整理されたライブラリを提供するべきです。最高のポータルは、組織全体で開発者がコンテンツと能力（新しいライブラリやアプリケーションパターンの改善など）に貢献できる貢献モデルを可能にします。
管理サービスへのアクセス（Access to management services）：この一元化されたポータルは、オブザーバビリティや分析ダッシュボードなどの生成AI管理サービスへのアクセス、ならびにコスト超過を防ぐための組み込みの予算管理とレポート機能も提供できます。データアクセス制御に従うこと、ガバナンスと承認プロセスを追跡すること、およびアプリケーションの現在の状態を理解することを容易にすることで、企業は何百ものアプリケーションを自信を持って運用できます。これらの制御は、環境に合わせて調整でき（例：一時的なサンドボックスには低い予算、大量テストアカウントには高い予算）、AIゲートウェイのコストガバナンスコンポーネントと統合されると、チームとITリーダーが進行中の開発コストを監視できるようになります。
2. 生成AIサービスを再利用するためのオープンアーキテクチャ（An open architecture to reuse gen AI services）
テクノロジーにおけるスケールの鍵は、再利用を最大化することです。再利用を可能にするには、再利用可能なサービスと能力を統合し、簡単に交換できるオープンなモジュラーアーキテクチャの開発に依存します。このオープンアーキテクチャのアプローチは、総所有コスト（TCO）を劇的に削減することもできます。
主要な企業は、2つの再利用可能な能力のセットの開発に焦点を当てています。一般的な原型（ナレッジ管理、顧客チャットボット、エージェントワークフローなど）のための完全な生成AIアプリケーションパターンとデータ製品（例：RAGやGraphRAG）、およびほとんどの生成AIアプリケーションで使用される共通ライブラリ（例：チャンキングと埋め込み、データのリランキング、プロンプトのエンリッチメント、意図の分類）です。これらのコア能力の多くは、サービスとして提供できます。
すべての生成AIサービスを単一のプロバイダーに頼ろうとするのは魅力的ですが、そのアプローチはしばしば裏目に出ます。なぜなら、そのプロバイダーの能力が企業のすべての特定のニーズに適しているとは限らず、ベストインクラスの能力へのアクセスを制限するからです。技術が急速に進歩しているため、それらを構築するよりも、プロバイダーが提供するサービスを利用する方が理にかなっています（企業の独自の優位性に直接関連する能力を構築する場合は例外です）。このため、生成AIプラットフォームは、オープンアーキテクチャを通じて、統合、構成、およびアクセスを可能にすることに焦点を当てる必要があります（図を参照）。
オープンアーキテクチャの核となる構成要素は、インフラストラクチャ・アズ・コードとポリシー・アズ・コードの組み合わせであり、これによりコアでの変更を容易に行い、プラットフォーム上で動作するソリューションが迅速かつ容易に採用できるようになります。プラットフォームが提供するライブラリとコンポーネントサービスは、生成AIサービスへの呼び出しを調整するために、明確で標準化された一連のAPIによってサポートされるべきです。
3. 自動化された責任あるAIのガードレール（Automated, responsible AI guardrails）
リスクを軽減し、継続的なコンプライアンスを管理し、コストの透明性を提供するために、生成AIプラットフォームは自動化されたガバナンスのガードレールを実装する必要があります。一つの例として、ソフトウェア開発ライフサイクルやソリューション運用の特定のポイントで自動的にトリガーされ、責任あるAIのためにコードをレビューするマイクロサービスを持つことが挙げられます。これらのガードレールは、データポリシー違反（入力データにおける個人識別情報[PII]の使用など）を防ぐためにLLMのプロンプトと応答を自動的に監査し、LLM出力のコンプライアンスを検証し（すなわち、ハルシネーション、データ漏洩、倫理的バイアスを検出する）、コストへの影響（LLM推論やベクトルデータベースクエリなど）を追跡し、コストを個々のソリューションに帰属させる機能を提供する必要があります。正しく行われた場合、プラットフォームは、ユーザーが特定のLLM応答を元のソースデータに遡って追跡できるデータパイプラインを使用して、データ準備（キュレーション、ストレージ、リスク制御など）の自動化を支援できます。
このアプローチは、コンプライアンスとより効果的なコスト管理を保証し、アプリケーションチームがセキュリティとスケールの詳細に対処するのではなく、製品とサービスの構築に時間を費やすのを助けることで、ユースケースの安全な実装を加速します。ある大手石油・ガス会社の場合、このアプローチにより、新しいアプリケーション開発のための新しい生成AI環境のプロビジョニングが、6週間以上かかっていたものが、専用の完全に機能する生成AIイノベーションサンドボックスが1日未満で利用可能になるまで加速されました。さらに、レビューチームがアプリケーションが承認された共有サービスを使用していることを迅速に検証できるため、生成AIプラットフォームは承認プロセスを最大90%加速させます。
これらのガードレールを実装する最も効果的な方法の1つは、チームとアプリケーションがLLMモデルにアクセスするために使用することを義務付けられた一元化されたAIゲートウェイサービスを通じて行うことです。このAIゲートウェイは、ポリシーに基づいて承認されたLLMモデルへのアクセスを管理し（例えば、ユーザーとデータ分類に合わせたアクセス制御を、開発、テスト、本番などのアプリケーションの環境と組み合わせる）、コスト帰属を提供し（例えば、部門ごとの基盤モデルコストのレポート）、その後の分析のためにすべてのLLMプロンプトと応答をログに記録します。
理想的なAIゲートウェイは、さまざまなツールやソリューション（すなわち、ミドルウェア）がリクエストの処理方法を自動的に調整できるようにする柔軟なシステムを使用します。これには、リクエストをさまざまなセキュリティやポリシーフィルターを経由してルーティングするオプションが含まれ、必要な場合には例外を許可します。例えば、ある企業にはPIIなどの機密情報にアクセスする必要がある人事向けの生成AIツールがありました。この場合、ゲートウェイはその特定のツールに対してPIIフィルターを一時的にオフにすることを許可しつつ、他のツールに対する保護を維持しました。
ハルシネーションや倫理的バイアスといった生成AI特有の問題を管理するために、AIゲートウェイはリクエストと応答の監査ログを保持し、これを使用して並列モデルでそのような問題を検出し、関連チームに通知を提供したり、モデルを自動的に修正する能力をサポートしたりすることができます。
この種のユニークなプラットフォームの実装には、規律と時間が必要です。しかし、時間の経過に伴う価値とスピードの観点からの見返りはそれを補って余りあり、いくつかのソリューションを展開した後には損益分岐点に達することがよくあります。このプラットフォームベースのアプローチは、イノベーションの加速、大規模な運用、一般的だが致命的な技術的落とし穴の回避、そして企業が生成AIの可能性を捉えることを可能にするために不可欠です。
免責事項
記事は、一般的な情報提供のみを目的としてのみ作成したものであり、投資家に対する有価証券の売買の推奨や勧誘を目的としたものではありません。また、記事は信頼できると判断した資料およびデータ等により作成しておりますが、その正確性および完全性について保証するものではありません。また、将来の投資成果や市場環境も保証されません。最終的な投資決定は、投資家ご自身の判断でなされますようお願いします。
