AI 推論パターン
AI と機械学習の機能は、あらゆる規模の企業でイノベーションと効率性を推進する上でますます重要視されるようになっているため、組織はアプリケーション開発者にそれらの機能へのアクセスを提供する最適な方法を決定する必要があります。 多くの場合、AI 推論サービスが使用されます。これは、「AI モデルを呼び出して、特定の入力に基づいて出力を生成するサービス」(分類の予測やテキストの生成など) であり、最も一般的には、他のアプリケーション コードからの API 呼び出しに応答して使用されます。
これらの推論サービスは、さまざまな方法で構築および使用できます (単一の組織内でも)。 これらのサービスは、完全に社内で開発されることもあれば、SaaS として利用されることもあり、オープンソース プロジェクトを活用し、オープン モデルまたは商用モデルを使用することもあります。 これらは、より広範なデータ サイエンスとモデル作成の取り組みをサポートする、完全に機能する「機械学習プラットフォーム」の一部として提供される場合もあれば、モデルを呼び出すための API エンドポイントのみを提供する場合もあります。 これらは、プライベート データ センター、パブリック クラウド、コロケーション施設、またはこれらの組み合わせで実行される可能性があります。 大規模な組織では、AI 推論に複数のオプションに依存する可能性が高くなります (特に、この分野での組織の成熟度が低い場合)。 すべての人に当てはまる万能のアプローチはありませんが、いくつかの共通パターンが浮かび上がってきています。
パターンの概要
ここでは、3 つの広範な AI 推論の消費パターンと、それぞれの長所と短所を検討します。
- SaaS としての AI 推論- アプリケーションは外部の専用 AI 推論サービス プロバイダーに接続します。
- クラウド管理 AI 推論– アプリケーションは、パブリック クラウドで実行されている完全に管理された AI 推論サービスに接続します。
- 自己管理型 AI 推論- アプリケーションは、一元化されたサービスの一部として、またはアプリケーション レベルで直接、組織自体によって管理される AI 推論を使用します。
重要な決定ポイント
次の運用パターン間のトレードオフを評価する際には、いくつかの重要な要素に留意する必要があります。
運用上の考慮事項
- スケーラビリティ– 誰が責任を持ち、時間の経過とともに容量のニーズが変化するにつれて、特定のオプションをどの程度適切にスケールアップおよびスケールダウンしますか? 規模の制限や容量の上限はありますか?
- コスト– 一見すると、完全に管理されたサービスはより高価に思えるかもしれませんが、総所有コスト (特殊なハードウェアや人員を含む) を考慮すると、決定が不明確になる可能性があります。 容量が増減すると運用コストはどのように変化しますか? コストに下限はありますか?
- メンテナンス/サポート– 推論サービスのメンテナンスの責任者は誰ですか? 組織では、この分野の専門知識を持つ従業員を雇用したり、コンサルタントに報酬を支払ったりする必要がありますか? それとも、マネージド サービスの提供の方が理にかなっているでしょうか?
開発上の考慮事項
- ワークロード統合の容易さ- AI サービスを消費ワークロードとどれだけ早く統合できるか? サービス提供は、想定される使用パターン (オフライン/バッチ推論など) および動作環境で機能しますか?
- 俊敏性- アプリケーション全体をビジネス要件の変化に合わせてどれだけ迅速に適応できるか。 アーキテクチャのどの側面がより定着しており、変更が難しいでしょうか?
パフォーマンスに関する考慮事項
- パフォーマンス– サービスの物理的な場所 (サービス コンシューマーに対する相対位置) と推論のレイテンシは、ユース ケースにとって重要ですか?
- ハードウェアの可用性– サービスには特別なハードウェア要件がありますか? ある場合、予想される需要を満たす能力がありますか (オンプレミスとクラウド環境の両方に適用可能)?
データの考慮事項
- データ漏洩- 機密データが推論サービスに送信されたり、推論結果に含まれたりする懸念はありますか? もしそうなら、交通を検査し、ガードレールを設置することはできますか?
- データ ガバナンス– アプリケーション データは地理的にどこに(どのように) 送信されますか? 直接的な制御は組織内に留まりますか、それとも第三者に送信されますか? データの取り扱い方法に適用される特別な規制やコンプライアンス ポリシーはありますか?
SaaS パターン
組織は、推論用の AI モデルのホスティングに重点を置く専用の SaaS プロバイダー (OpenAI や Cohere など) のサービスを利用することを選択できます。 この場合、組織のインフラストラクチャ (プライベート データ センター、コロケーション、パブリック クラウドなど) 上で実行されるワークロードは、SaaS プロバイダーによって公開された API を活用します。 このパターンでは、モデルのホスティングに必要なインフラストラクチャの運用に伴う負担はすべて SaaS プロバイダーに課せられ、稼働開始までにかかる時間は非常に短くなります。 ただし、これらの利点は制御を犠牲にして得られるものであり、このパターンはここで取り上げるパターンの中で最も「柔軟性」が低いものとなります。 同様に、このモデルでは機密データに対する制御は通常最も低く、サービスへの接続には通常パブリック インターネットが使用され、外部の SaaS ベンダーが厳格な規制コンプライアンスの懸念に対処できる可能性は低くなります。
最適な用途
- 市場投入までの時間: 迅速なプロトタイピング、MVP リリース。
- 社内に AI 推論の専門知識や経験がほとんどない組織。
- 重大または厳格なデータ セキュリティ/ガバナンスのニーズがないアプリケーション。
強み
- 市場投入までの時間が短い: シンプルな運用モデルにより、統合時間が短縮されます。
- 専門のサービスプロバイダーは、推論のスケーリングの課題に対処するための十分な設備を備えています。
- 特殊なハードウェアや人員への投資は必要ありません。
課題
- アプリのワークロードと同じ場所に配置されたサービスに関する遅延と接続性に関する懸念。
- データのプライバシー、ガバナンス、セキュリティに関する懸念は、外部の SaaS プロバイダーに依存します (または互換性がない可能性があります)。
- 大規模になると、運用コストがセルフホスティング モデルよりも高くなる可能性があります。
- カスタム モデルのホスティングおよびモデルのカスタマイズ サービスはサポートされない可能性があります。
クラウド管理パターン
このパターンでは、組織はパブリック クラウド プロバイダー (Azure OpenAI、Google Vertex、AWS Bedrock など) が提供するマネージド サービスを活用します。 最初のパターンと同様に、AI モデルの展開、スケーリング、保守の運用上の負担は、消費組織ではなくクラウド プロバイダーにかかってきます。 このパターンと上記の SaaS パターンの主な違いは、この場合、推論 API エンドポイントは通常プライベート ネットワーク経由でアクセス可能であり、AI コンシューマー ワークロードを AI モデル サービス (同じゾーン、リージョンなど) と共存できることです。 その結果、データは通常、パブリック インターネットを通過せず、レイテンシが低くなる可能性が高く、これらのサービスに接続するためのメカニズムは、他のクラウド プロバイダーが管理するサービス (サービス アカウント、アクセス ポリシー、ネットワーク ACL など) と同様になります。 マルチクラウド ネットワーキングを活用する組織は、ワークロードと AI 推論サービスが異なるクラウドでホストされている場合でも、同様のメリットの一部を実現できる可能性があります。
最適な用途
- 既にパブリック クラウドに投資している組織。
- 他のクラウド管理サービスで実行されている、または他のクラウド管理サービスに接続するアプリケーション。
強み
- 多くの組織は、自社のワークロードを他のクラウド プロバイダーが管理するサービス (データベース、オブジェクト ストアなど) に接続することにすでに慣れています。
- モデルの実行と拡張に関する運用とインフラストラクチャの負担は、主にクラウド プロバイダーにかかってきます。
- レイテンシーに関する懸念や一部のデータ プライバシーに関する懸念は、対処しやすくなる可能性があります。
課題
- マルチ/ハイブリッド クラウド アプリケーションでは、接続とセキュリティ保護に追加の労力が必要です。
- クラウド管理サービスと API の一貫性が欠如していると、ベンダー ロックインが発生する可能性があります。
- 広範なパブリック クラウドを導入していない組織は困難に直面する可能性があります。
- 大規模になると、運用コストがセルフホスティング モデルよりも高くなる可能性があります。
- カスタム モデルのホスティングおよびモデルのカスタマイズ サービスはサポートされない可能性があります。
自己管理パターン
セルフマネージド モデルについては、まず AI モデル推論が集中型の「共有サービス」として実行されるケースについて説明し、次に集中型サービスが存在せず、運用上の懸念が個々のアプリケーション チームに委ねられているケースを検討します。
自己管理型、共有サービス
セルフマネージド パターンの「共有サービス」バリアントでは、組織には、推論インフラストラクチャ、その上で実行されるモデル、それに接続するために使用される API、および推論サービス ライフサイクルのすべての運用面の保守を担当する専任チームが存在する場合があります。 他のパターンと同様に、AI アプリケーションのワークロードは API 呼び出しを通じて推論サービスを利用します。 モデル提供インフラストラクチャは、プライベート データ センター、パブリック クラウド、またはコロケーション施設で実行される可能性があります。 推論サービスの運用を担当するチームは、セルフホスト型機械学習プラットフォーム (Anyscale Ray や MLFlow など) を活用できます。 あるいは、Hugging Face のText Generation Inference サーバーや社内で開発されたソフトウェアなど、より焦点を絞った推論サービス ツールに依存する場合もあります。 自己管理型推論では、組織は自らトレーニングしたモデルか、ローカルで実行できるモデルの使用に制限されます (そのため、SaaS 指向のサービスからの独自のモデルは選択肢にならない可能性があります)。
最適な用途
- 豊富なインフラストラクチャ管理経験を持つ成熟した組織。
- 自己管理型サービスの TCO を正当化する、推論要件が厳しい組織。
- 最も厳格なデータ プライバシーとコンプライアンス要件を備えたアプリケーション。
強み
- 組織は推論サービスのあらゆる側面を完全に制御できます。
- データ プライバシーの課題は、通常、セルフホスト モデルを使用すると最も簡単に対処できます。
- 大規模な場合のコストは、クラウド管理または SaaS ベースの推論サービスよりも効率的である可能性があります。
課題
- 組織は推論サービスのあらゆる側面を完全に制御します (継続的なメンテナンス、開発、スケーラビリティの懸念に加えて、大規模なインフラストラクチャと人員への投資が必要になる可能性があります)。
- 通常、推論のニーズが最小限で、データ プライバシーに関する懸念が最小限の組織では、コスト効率が良くありません。
- SaaS またはクラウド管理サービスとして利用できるクローズド/独自のモデルにはアクセスできません。
共有サービスではなく、自己管理型
アプリケーションが使用する AI 推論サービスの実行を担当する中央チームを持たない組織は、セルフマネージド パターンのもう 1 つのバリエーションです。 このバージョンでは、個々のアプリケーション チームは、アプリケーション ワークロード用に割り当てられた同じインフラストラクチャ上でモデルを実行する可能性があります。 これらのモデルに API 経由でアクセスするか、「オフライン」方式で直接使用するかを選択できます。 このパターンを使用すると、開発者は「共有サービス」自己管理モデルと同じ利点の一部をより小規模で実現できる可能性があります。
最適な用途
- バッチ処理とオフライン推論を必要とするアプリケーション。
- 推論の消費量は非常に少ないが、データのプライバシーとコンプライアンスの要件が厳しい組織。
強み
- アプリケーション開発者にとって最も柔軟性が高く、ワークロードとの統合の幅広い可能性を実現します。
- 小規模でデータ プライバシーとレイテンシーの目標を達成できます。
- 場合によっては、説明した他のモデルよりもコスト効率が高くなる可能性があります (大量の消費要件がある単一チームなど)。
課題
- モデル ライフサイクルの運用上の負担は、個々のアプリケーション チームにかかっています。
- 組織の AI 推論の消費が増加するにつれて、規模の経済を活用できなくなります (一貫性の欠如、非効率的なリソース利用など)。
パターンのトレードオフの概要
AI アプリとモデル推論サービスのセキュリティ保護
AI アプリケーションは、本質的には他の最新のアプリとよく似ています。ユーザー向けコンポーネントとバックエンド コンポーネントを組み合わせて構築されており、多くの場合、外部データ ストアに依存し、API 呼び出しを多用します。 これらのアプリケーションは、すべての最新アプリに共通する同じセキュリティ上の課題を継承しており、同じ方法で同じ保護を適用する必要があります (AuthNZ、DDoS 保護、WAF、安全な開発プラクティスなど)。 ただし、AI アプリ、特に生成 AI を活用したアプリには、他のアプリケーションには当てはまらない可能性のある多くの固有の懸念事項も存在します (たとえば、 OWASP Top 10 For LLMsを参照してください)。 これらのモデルの一般的に予測不可能な性質は、特にモデルに大きな権限が与えられるユースケースでは、新たな問題を引き起こす可能性があります。
幸いなことに、上で説明したパターンでは、AI モデル推論による API 駆動型のインタラクションへの依存度が高いため、多くの組織はすでにこれらの新しいセキュリティ対策を実装する態勢が整っています。 たとえば、従来のレート制限、認証、承認、トラフィック管理機能を提供している API ゲートウェイは、コスト管理に役立つトークンベースのレート制限をサポートするように拡張できます (SaaS/プロバイダー管理サービスへのアプリ レベルでの送信、またはセルフマネージド推論サービスの前での保護としての受信 RBAC 承認のいずれか)。 同様に、SQL インジェクションや XSS のチェックなどの従来の Web アプリケーション ファイアウォール (WAF) サービスを現在実行しているインフラストラクチャは、プロンプト インジェクションや同様の攻撃に対する保護を追加するのに適した場所である可能性があります。 最新の可観測性のプラクティスのほとんどは、API 駆動型 AI 推論固有のユースケースに直接適用でき、チームはこの分野の既存のツールとプラクティスを有効活用できるはずです。
結論
AI を活用したアプリケーションや推論サービスを取り巻く話題は確かに新しいものですが、それらを導入し保護する際に適用される基本原則は、かなり前から存在しています。 組織は、他のテクノロジーを利用する場合と同様に、特定のユースケース、利用可能なリソース、および長期目標に基づいて、AI 機能を最大限に活用する方法を決定する際にトレードオフを検討する必要があります。 同様に、AI (特に生成 AI) のユースケースでは新しいセキュリティ上の課題がいくつか発生しますが、他の最新アプリケーションと共通のニーズと API 駆動型モデル相互作用への大きな依存により、既存のパターン、プラクティス、ツールを使用および拡張する絶好の機会が生まれます。 セルフホスト型でもマネージド サービスでも、開発者が特定のビジネス要件を満たす安全でスケーラブルかつ高性能なソリューションにアクセスできるようにすることは、AI 投資の価値と影響を最大化するために重要です。