AI を使用して構築する前に、ホストするプラットフォームを選択する必要があります。この選択は、AI システムの速度、費用、スケーラビリティ、信頼性に影響します。選択肢は次のとおりです:
- クライアントサイド AI: ブラウザで直接実行されます。つまり、データはユーザーのデバイス上にプライベートな状態で保持され、ネットワーク レイテンシも発生しません。ただし、クライアントサイド AI が適切に機能するには、非常に具体的で明確に定義されたユースケースが必要です。
- サーバーサイド AI: クラウドで実行されます。機能とスケーラビリティは高いですが、レイテンシとコストの面では高くなります。
各オプションにはトレードオフがあり、適切な設定はユースケース、チームのスキル、リソースによって異なります。たとえば、ユーザーが個人情報（PII）を管理する必要なく個人的な質問をできるように、ローカルで実行される要約ツールを提供できます。ただし、カスタマー サポート エージェントは、リソースの大規模なデータベースにアクセスできるクラウドベースのモデルを使用することで、より有用な回答を提供できます。
このモジュールでは、次の方法について学習します。
- クライアントサイド AI とサーバーサイド AI のトレードオフを比較します。
- プラットフォームをユースケースとチームの能力に合わせます。
- クライアントとサーバーで AI を提供するハイブリッド システムを設計して、プロダクトの成長に合わせて拡張します。
オプションを確認する
デプロイでは、AI プラットフォームを 2 つの主な軸で考えます。以下を選択できます。
- モデルの実行場所: クライアントサイドで実行されているか、サーバーサイドで実行されているか。
- カスタマイズ性: モデルの知識と機能をどの程度制御できるか。モデルを制御できる場合（モデルの重みを変更できる場合）、特定の要件を満たすようにモデルの動作をカスタマイズできます。
クライアントサイド AI
クライアントサイド AI はブラウザで実行され、計算はユーザーのデバイスでローカルに行われます。推論時のコンピューティングを提供する必要がなく、データはユーザーのマシンに残ります。これにより、高速でプライベートな、軽量でインタラクティブなエクスペリエンスに適した状態になります。
ただし、クライアントサイド モデルは通常かなり小さいため、機能とパフォーマンスが制限される可能性があります。毒性検出や感情分析など、高度に専門化されたタスクに最適です。多くの場合、これらは出力空間が制限された予測 AI タスクです。
主なオプションは次の 2 つです。
- 組み込みの AI: Google Chrome や Microsoft Edge などのブラウザに AI モデルが統合されています。これらは JavaScript 呼び出しを通じてアクセスでき、設定やホスティングは必要ありません。モデルがダウンロードされると、そのモデルを使用するすべてのウェブサイトから呼び出すことができます。
- カスタムモデル: Transformers.js や MediaPipe などのクライアントサイド ライブラリを使用して、モデルをアプリケーションに統合できます。つまり、モデルの重みを制御できます。ただし、ウェブサイトのすべてのユーザーがカスタムモデルをダウンロードする必要があることも意味します。ウェブサイトのコンテキストでは、最小の AI モデルでも大規模です。
サーバーサイド AI
サーバーサイド AI では、ウェブ アプリケーションが API を呼び出して AI モデルに入力を送信し、出力を受け取ります。この設定は、より大規模で複雑なモデルをサポートし、ユーザーのハードウェアに依存しません。
サーバーサイド AI には次の 2 つのカテゴリがあります。
- マネージド サービス: Gemini 3 や GPT-5 など、サードパーティによってデータセンターでホストされるモデルです。モデルのオーナーは、モデルにアクセスするための API を提供します。つまり、最小限の設定で最先端のモデルを使用できます。高速プロトタイピング、自由回答形式の会話、汎用的な推論に最適です。ただし、マネージド サービスでのスケーリングは費用がかかる場合があります。
- セルフホスト モデル: Gemma や Llama などのオープンウェイト モデルを、独自のインフラストラクチャまたは Vertex AI や Hugging Face Inference などのマネージド コンテナにデプロイできます。このアプローチでは、モデル作成者が行った事前トレーニングのメリットを享受しながら、モデル、ファインチューニング データ、パフォーマンスを制御できます。
最初のプラットフォームを選択する
AI プラットフォームのアーキテクチャ上の特性を確認し、トレードオフを分析して、初期設定を決定します。
アーキテクチャ要件を定義する
どの意思決定にも妥協が必要です。AI プラットフォームの費用と価値を定義する主な特性は次のとおりです。
- モデルの能力: チューニングなしで、幅広いユーザーとタスクに対してモデルがどの程度適切に機能するか。多くの場合、これはモデルサイズと相関関係があります。
- カスタマイズ性: モデルの動作とアーキテクチャをファインチューニング、変更、制御できる範囲。
- 精度: モデルの予測または生成の全体的な品質と信頼性。
- プライバシー: ユーザーデータがローカルに保存され、ユーザーの管理下にある度合い。
- 固定費: 使用量に関係なく AI システムを運用するために必要な定期的な費用（インフラストラクチャのプロビジョニングとメンテナンスなど）。
- リクエストあたりの費用: 各受信リクエストの追加費用。
- 互換性: フォールバック ロジックなしで、ブラウザ、デバイス、環境全体でアプローチがどの程度機能するか。
- ユーザーの利便性: AI システムを使用するために、モデルのダウンロードなどの追加の手順が必要かどうか。
- デベロッパーの利便性: ほとんどのデベロッパーが、専門的な AI の知識なしでモデルをデプロイ、統合、保守できる速さと容易さ。
次の表に、各プラットフォームの各基準に対するパフォーマンスの推定値の例を示します。1 が最小、5 が最大です。
| 基準 | お客様 | サーバー | ||
| 組み込み AI またはオンデバイス | カスタムモデル | マネージド サービス | セルフホスト型モデル | |
| モデルの電力 |
モデルのパワーが 2 つ星の理由組み込みのオンデバイス AI は、オープンエンドの会話や推論ではなく、ナローでタスク固有の機能に最適化された小さなプリロード済みブラウザ モデルを使用します。 |
モデルのパワーが 3 つ星の理由カスタム クライアントサイド ライブラリは組み込み AI よりも柔軟性が高いですが、ダウンロード サイズ、メモリ上限、ユーザーのハードウェアによる制約は受けます。 |
モデルの電力の評価が 4 つ星なのはなぜですか？マネージド サービスとセルフホスティングを使用すると、複雑な推論、長いコンテキスト処理、幅広いタスクを処理できる大規模な最先端モデルにアクセスできます。 |
|
| カスタマイズ性 |
カスタマイズ性が 1 つ星の理由組み込みモデルでは、モデルの重みやトレーニング データにアクセスできません。動作をカスタマイズする主な方法は、プロンプト エンジニアリングです。 |
カスタマイズ性が 5 つ星の理由このオプションを使用すると、モデルの選択と重みを制御できます。多くのクライアントサイド ライブラリでは、モデルのファインチューニングとトレーニングも可能です。 |
カスタマイズ性が 1 つ星の理由マネージド サービスは強力なモデルを公開しますが、内部動作の制御は最小限に抑えられます。通常、カスタマイズはプロンプトと入力コンテキストに限定されます。 |
カスタマイズの評価が 5 つ星の理由セルフホスト モデルでは、モデルの重み、トレーニング データ、ファインチューニング、デプロイ構成を完全に制御できます。 |
| 正確さ |
正確性が 2 つ星の理由組み込みモデルの精度は、範囲が明確なタスクには十分ですが、モデルサイズと一般化が制限されているため、複雑な入力や微妙な入力に対する信頼性が低下します。 |
精度が 3 つ星の理由カスタム クライアントサイド モデルの精度は、モデル選択プロセスで向上させることができます。ただし、モデルサイズ、量子化、クライアント ハードウェアの変動性によって制限されます。 |
正確性で 5 つ星の評価を受けたのはなぜですか？マネージド サービスは通常、比較的高い精度を提供します。これは、大規模なモデル、広範なトレーニング データ、プロバイダによる継続的な改善の恩恵を受けているためです。 |
精度が 4 つ星の理由精度は高くなる可能性がありますが、選択したモデルとチューニングの労力によって異なります。パフォーマンスがマネージド サービスに遅れる可能性があります。 |
| ネットワーク レイテンシ |
ネットワーク レイテンシが 5 つ星の理由処理はユーザーのデバイス上で直接行われます。 |
ネットワーク遅延の評価が 2 つ星なのはなぜですか？サーバーとの往復が発生します。 |
||
| プライバシー |
プライバシーが 5 つ星の理由ユーザーデータはデフォルトでデバイスに残るため、データ漏洩のリスクが最小限に抑えられ、プライバシー コンプライアンスが簡素化されます。 |
プライバシーが 2 つ星なのはなぜですか？ユーザー入力は外部サーバーに送信されるため、データ漏洩のリスクとコンプライアンス要件が増加します。ただし、Private AI Compute など、プライバシーに関する問題を軽減するための具体的なソリューションがあります。 |
プライバシーの評価が 3 つ星なのはなぜですか？データは組織の管理下に置かれますが、ユーザーのデバイスから離れるため、安全な取り扱いとコンプライアンス対策が必要です。 |
|
| 固定費用 |
固定費が 5 つ星の理由モデルはユーザーの既存のデバイスで実行されるため、追加のインフラストラクチャ費用は発生しません。 |
固定費が 5 つ星の理由ほとんどの API は使用量に基づいて課金されるため、固定費は発生しません。 |
固定費が 2 つ星の理由固定費には、インフラストラクチャ、メンテナンス、運用オーバーヘッドが含まれます。 |
|
| リクエスト単価 |
リクエスト単価が 5 つ星の理由推論はユーザーのデバイスで実行されるため、リクエストごとの費用は発生しません。 |
リクエストあたりの費用が 2 つ星なのはなぜですか？マネージド サービスは、リクエストごとの料金設定になっている傾向があります。特にトラフィック量が多い場合、スケーリングの費用が大きくなる可能性があります。 |
リクエストあたりの費用が 3 つ星の理由リクエストごとの直接的な費用はありません。リクエストごとの実質的な費用は、インフラストラクチャの使用率によって異なります。 |
|
| 互換性 |
互換性が 2 つ星の理由利用できるかどうかはブラウザとデバイスによって異なり、サポートされていない環境ではフォールバックが必要です。 |
互換性が 1 つ星の理由互換性はハードウェアの機能とランタイム サポートに依存するため、デバイス間のリーチが制限されます。 |
互換性が 5 つ星の理由サーバーサイド プラットフォームは、推論がサーバーサイドで行われ、クライアントが API を使用するだけなので、すべてのユーザーに対して幅広く互換性があります。 |
|
| ユーザーの利便性 |
ユーザーの利便性が 3 つ星の理由一般的に、利用可能になるとシームレスに動作しますが、組み込み AI では初期モデルのダウンロードとブラウザのサポートが必要です。 |
ユーザーの利便性が 2 つ星の理由ダウンロードやサポートされていないハードウェアが原因で遅延が発生することがあります。 |
ユーザーの利便性が 4 つ星の理由ダウンロードやデバイスの要件がなく、すぐに使用できるため、スムーズなユーザー エクスペリエンスを提供できます。ただし、ネットワーク接続が遅い場合は遅延が発生することがあります。 |
|
| デベロッパーの利便性 |
デベロッパーの利便性が 5 つ星の理由組み込みの AI は、設定が最小限で、インフラストラクチャが不要で、AI の専門知識がほとんど必要ないため、簡単に統合して維持できます。 |
デベロッパーの利便性が 2 つ星の理由モデル、ランタイム、パフォーマンスの最適化、デバイス間の互換性の管理が必要です。 |
デベロッパーの利便性が 4 つ星の理由マネージド サービスは、デプロイとスケーリングを簡素化します。ただし、API 統合、費用管理、プロンプト エンジニアリングは引き続き必要です。 |
デベロッパーの利便性が 1 つ星の理由カスタム サーバーサイド デプロイには、インフラストラクチャ、モデル管理、モニタリング、最適化に関する高度な専門知識が必要です。 |
| メンテナンスの労力 |
メンテナンスの労力が 4 つ星の理由ブラウザはモデルの更新と最適化を処理しますが、デベロッパーは利用可能状況の変化に対応する必要があります。 |
メンテナンスの労力が 2 つ星の理由ブラウザやデバイスの進化に合わせて、モデル、パフォーマンス チューニング、互換性を継続的に更新する必要があります。 |
メンテナンスの労力が 5 つ星の理由メンテナンスはプロバイダによって処理されます。 |
メンテナンスの労力が 2 つ星の理由モデルの更新、インフラストラクチャ管理、スケーリング、セキュリティなど、継続的なメンテナンスが必要です。 |
トレードオフを分析する
意思決定プロセスを説明するために、中規模の e コマース プラットフォームである Example Shoppe に別の機能を追加します。営業時間外のカスタマー サービスの費用を削減したいと考えているため、注文、返品、商品に関するユーザーの質問に回答する AI 搭載アシスタントを構築することにしました。
機会とソリューションを特徴とする AI システムのブループリントの全体像を確認できます。
ユースケースの要件とビジネスまたはチームの制約という 2 つの観点からシナリオを分析します。
| 要件 | 分析 | 基準 | 影響 |
| 高精度と汎用性 | お客様から、注文、商品、返品に関するさまざまな複雑な質問が寄せられます。 | モデルのパワー、精度 | 大規模言語モデル（LLM）が必要です。 |
| データの具体性 | 会社のデータ、製品、ポリシーに固有の質問に回答する必要があります。 | カスタマイズ可能 | RAG などのデータ取り込みは必要ですが、モデルのファインチューニングは必要ありません。 |
| 要件 | 分析 | 基準 | 影響 |
| ユーザーベース | 数十万人のユーザー。 | スケーラビリティ、互換性 | 信頼性の高い高トラフィックを処理するアーキテクチャが必要。 |
| リリース後の重点事項 | チームはバージョン 1 のリリース後に他のプロジェクトに移動します。 | メンテナンス作業 | 継続的なメンテナンスが最小限で済むソリューションが必要。 |
| チームの専門知識 | ウェブ デベロッパーとしてのスキルは高いが、AI/ML の専門知識は限られている | デベロッパーの利便性 | ソリューションは、特別な AI スキルがなくても簡単にデプロイして統合できる必要があります。 |
基準の優先順位付けが完了したら、トレードオフの推定表を参照して、最優先の基準に合致するプラットフォームを特定します。
| 優先順位の高い条件 | プラットフォームの受賞者 |
| モデルのパワー | サーバーサイド |
| カスタマイズ可能 | サーバーサイド: セルフホスト型モデル |
| デベロッパーの利便性 | サーバーサイド: マネージド サービス |
| メンテナンス作業 | サーバーサイド: マネージド サービス |
| 互換性とスケーラビリティ | サーバーサイド |
この内訳から、サーバーサイド AI と、おそらくマネージド サービスを使用する必要があることがわかります。これは、複雑な顧客の質問に対応するための汎用性の高いモデルです。インフラストラクチャ、モデルの品質、稼働時間をプロバイダにオフロードすることで、メンテナンスと開発の労力を最小限に抑えます。
カスタマイズ性は制限されますが、モデル エンジニアリングの経験が少ないウェブ開発チームにとっては、価値のあるトレードオフです。
検索拡張生成（RAG）の設定は、推論時にモデルに関連するコンテキストを提供するために役立ちます。
ハイブリッド AI
成熟した AI システムは、単一のプラットフォームや 1 つのモデルで実行されることはほとんどありません。代わりに、AI ワークロードを分散してトレードオフを最適化します。
ハイブリッド AI の機会を見つける
リリース後は、実際のデータとフィードバックに基づいて要件を絞り込む必要があります。この例では、数か月待って結果を分析し、次のことがわかりました。
- リクエストの約 80% は繰り返しです（「注文した商品が届かない」、「「返品するにはどうすればよいですか？」）。これらのリクエストをマネージド サービスに送信すると、オーバーヘッドと費用が大幅に増加します。
- リクエストの 20% のみで、より深い推論とオープンエンドのインタラクティブな会話が必要です。
軽量のローカルモデルは、ユーザー入力を分類し、「返品ポリシーは？」などのルーティン クエリに回答できます。複雑な質問、まれな質問、曖昧な質問はサーバーサイド モデルにルーティングできます。
サーバーサイドとクライアントサイドの両方の AI を実装することで、必要に応じて強力な推論にアクセスしながら、費用とレイテンシを削減できます。
ワークロードを分散する
Example Shoppe のハイブリッド システムを構築するには、まずデフォルトのシステムを定義します。この場合は、クライアントサイドから始めることをおすすめします。アプリケーションは、次の 2 つの場合にサーバーサイド AI にルーティングする必要があります。
- 互換性に基づくフォールバック: ユーザーのデバイスまたはブラウザがリクエストを処理できない場合は、サーバーにフォールバックする必要があります。
- 能力ベースのエスカレーション: 事前定義された基準で定義されているように、リクエストがクライアントサイド モデルにとって複雑すぎる場合や、オープンエンドの場合、より大きなサーバーサイド モデルにエスカレーションする必要があります。モデルを使用してリクエストを一般的なものと分類し、クライアントサイドでタスクを実行するか、一般的でないものと分類して、サーバーサイド システムにリクエストを送信できます。たとえば、クライアントサイド モデルが、質問が別の通貨での払い戻しなど、一般的でない問題に関連していると判断した場合です。
柔軟性が高まると複雑さが増す
2 つのプラットフォーム間でワークロードを分散すると、柔軟性が高まりますが、複雑さも増します。
- オーケストレーション: 2 つの実行環境は、より多くの可動部分を意味します。ルーティング、再試行、フォールバックのロジックが必要です。
- バージョン管理: プラットフォーム間で同じモデルを使用する場合は、両方の環境で互換性を維持する必要があります。
- プロンプト エンジニアリングとコンテキスト エンジニアリング: 各プラットフォームで異なるモデルを使用する場合は、それぞれに対してプロンプト エンジニアリングを行う必要があります。
- モニタリング: ログと指標が分割され、統合に余分な労力がかかります。
- セキュリティ: 2 つの攻撃対象領域を維持しています。ローカル エンドポイントとクラウド エンドポイントの両方を強化する必要があります。
これも考慮すべきトレードオフです。チームが小規模な場合や、重要でない機能を構築している場合は、この複雑さを追加したくないことがあります。
要点
プラットフォームの選択は進化する可能性があります。ユースケースから始め、チームの経験とリソースに合わせて、プロダクトと AI の成熟度を高めながら反復処理を行います。ユーザーにとって適切な速度、プライバシー、制御のバランスを見つけ、柔軟性のあるシステムを構築することが課題となります。これにより、変化する要件に対応し、今後のプラットフォームとモデルの更新を活用できます。
リソース
- プラットフォームとモデルの選択は相互に依存しているため、モデルの選択について詳しくお読みください。
- ハイブリッド AI とクライアントサイド AI でクラウドの限界を超える方法をご覧ください
理解度を確認する
アプリケーションの AI プラットフォームを選択する際の 2 つの主な考慮事項は何ですか？
Gemini Pro などのサーバーサイドのマネージド サービスがプラットフォームに最適な選択肢となるのは、どのような場合ですか？
ハイブリッド AI システムを実装する主なメリットは何ですか？