クラウドベースの AI モデルとローカル AI モデルを選択する

アプリ開発者が AI 機能を統合しようとしている場合、Microsoft Windows は、ローカルのオンデバイス処理とスケーラブルなクラウドベースのソリューションの両方をサポートする包括的で柔軟なプラットフォームを提供します。

クラウドベースの AI モデルとローカル AI モデルの選択は、特定のニーズと優先順位によって異なります。 多くの運用アプリでは、ハイブリッド戦略を使用します。まず、ローカル Windows AI API またはローカル モデルを試してから、モデルがインストールされていない場合、デバイスがサポートされていない場合、ユーザーがモデルのダウンロードに同意しない場合、またはタスクにより大きなモデルが必要な場合は、クラウド エンドポイントにフォールバックします。

次の要素を検討する必要があります。

  • データのプライバシー、コンプライアンス、セキュリティ
  • リソースの可用性
  • アクセシビリティとコラボレーション
  • 費用
  • メンテナンスと更新
  • パフォーマンスと待機時間
  • スケーラビリティ
  • 接続の要件
  • モデルのサイズと複雑さ
  • ツールと関連エコシステム
  • カスタマイズと制御

アプリ開発者の主な決定要因

  • データのプライバシー、コンプライアンス、セキュリティ

    • ローカル、オンプレミス: データはデバイス上に残っているため、モデルをローカルで実行すると、セキュリティとプライバシーに関する利点が得られます。データ セキュリティはユーザーにかかっています。 開発者は、更新プログラムを管理し、互換性を確保し、セキュリティの脆弱性を監視する責任を負います。

    • 雲： クラウド プロバイダーは堅牢なセキュリティ対策を提供しますが、データをクラウドに転送する必要があるため、場合によっては、ビジネスまたは App Service の保守担当者のデータ プライバシーの問題が発生する可能性があります。 クラウドにデータを送信するには、データの性質とアプリが動作するリージョンに応じて、GDPR や HIPAA などのデータ保護規則にも準拠する必要があります。 クラウド プロバイダーは通常、セキュリティ更新プログラムとメンテナンスを処理しますが、ユーザーは、セキュリティで保護された API とデータ処理のベスト プラクティスに従っていることを確認する必要があります。

  • リソースの可用性

    • ローカル、オンプレミス: モデルの実行は、CPU、GPU、NPU、メモリ、ストレージ容量など、使用されているデバイスで使用可能なリソースによって異なります。 これは、デバイスに高いコンピューティング能力または十分なストレージがない場合に制限される可能性があります。 Phiなどの小さな言語モデル (SLB) は、デバイスでのローカル使用に適しています。 Copilot+ PC では 、 Microsoft Foundry on Windowsでサポートされるすぐに使用できる AI 機能を備えた組み込みのモデルが提供されます。

    • 雲：Azure AI サービスなどのクラウド プラットフォームは、スケーラブルなリソースを提供します。 必要な量のコンピューティング能力またはストレージを使用でき、使用した分だけ支払うことができます。 OpenAI 言語モデルのような大規模な言語モデル (LLM) は、より多くのリソースを必要としますが、より強力です。

  • アクセシビリティとコラボレーション

    • ローカル、オンプレミス: モデルとデータは、手動で共有しない限り、デバイスでのみアクセスできます。 これにより、モデル データのコラボレーションがより困難になる可能性があります。

    • 雲： モデルとデータは、インターネット接続を使用してどこからでもアクセスできます。 これは、コラボレーション シナリオに適している場合があります。

  • 費用

    • ローカル、オンプレミス: デバイス ハードウェアへの初期投資を超える追加コストは発生しません。

    • 雲： クラウド プラットフォームは従量課金制モデルで動作しますが、使用されるリソースと使用期間に基づいてコストが蓄積される可能性があります。

  • メンテナンスと更新

    • ローカル、オンプレミス: ユーザーは、システムの保守と更新プログラムのインストールを担当します。

    • 雲： メンテナンス、システム更新プログラム、および新機能の更新プログラムはクラウド サービス プロバイダーによって処理されるため、ユーザーのメンテナンスオーバーヘッドが軽減されます。

  • パフォーマンスと待機時間

    • ローカル、オンプレミス: データをネットワーク経由で送信する必要がないため、モデルをローカルで実行すると待機時間が短縮されます。 ただし、パフォーマンスはデバイスのハードウェア機能によって制限されます。

    • 雲： クラウドベースのモデルは強力なハードウェアを利用できますが、ネットワーク通信のために待機時間が発生する可能性があります。 パフォーマンスは、ユーザーのインターネット接続とクラウド サービスの応答時間によって異なる場合があります。

  • スケーラビリティ

    • ローカル、オンプレミス: ローカル デバイスでモデルをスケーリングするには、ハードウェアの大幅なアップグレードや、より多くのデバイスの追加が必要になる場合があり、コストと時間がかかる場合があります。

    • 雲： クラウド プラットフォームは簡単なスケーラビリティを提供し、物理的なハードウェアの変更を必要とせずに、必要に応じてリソースをすばやく調整できます。

  • 接続の要件

    • ローカル、オンプレミス: ローカル デバイスでは、モデルを実行するためにインターネット接続は必要ありません。これは、接続が制限された環境で役立つ可能性があります。

    • 雲： クラウドベースのモデルでは、アクセスに安定したインターネット接続が必要であり、ネットワークの問題の影響を受ける可能性があります。

  • ランタイムの可用性とフォールバック

    • ローカル、オンプレミス: ローカル AI 機能は、ハードウェア、 Windows バージョン、 Windows App SDK のバージョン、リージョン、およびオプションのモデルがインストールされているかどうかによって異なります。 ローカル AI 機能を呼び出す前に、その準備状態を確認し、必要なモデルのダウンロードまたは同意フローをユーザーに案内します。 Windows AI API の場合、「Windows AI API の使用を開始する」と個々の API のページに記載されている、API 固有の準備状況パターンを使用します。

    • クラウド: クラウド エンドポイントは、ローカル モデルの準備ができていないか、現在のデバイスでサポートされていない場合にフォールバックを提供できます。 プライバシーに依存するシナリオでフォールバックを自動、ユーザー制御、または無効にするかどうかを決定します。 データがデバイスから離れるタイミングが UI で説明されていることを確認します。

  • モデルのサイズと複雑さ

    • ローカル、オンプレミス: ローカル デバイスでは、ハードウェアの制約により実行できるモデルのサイズと複雑さに制限がある場合があります。 Phiなどの小さいモデルは、ローカル実行に適しています。

    • 雲： クラウド プラットフォームは、スケーラブルなインフラストラクチャにより、OpenAI によって提供されるモデルなど、より大規模で複雑なモデルを処理できます。

  • ツールと関連するエコシステム

    • ローカル、オンプレミス:Microsoft FoundryMicrosoft Foundry on Windows、Windows ML、Foundry Localなどのローカル AI ソリューションは、Windows App SDK や ONNX Runtime と統合されるため、開発者は外部の依存関係を最小限に抑えて、デスクトップ アプリまたはエッジ アプリにモデルを直接埋め込むことができます。

    • 雲：Microsoft Foundry、Azure AI サービス、Azure OpenAI Service などのクラウド AI ソリューションは、AI アプリケーションを構築するための包括的な API と SDK のセットを提供します。 これらのサービスは、 Azure DevOps、GitHub Copilot、セマンティック カーネル、およびその他の Azure サービスとシームレスに統合するように設計されており、エンドツーエンドのオーケストレーション、モデルのデプロイ、大規模な監視が可能になります。

  • カスタマイズと制御

    • ローカル、オンプレミス: ローカル モデルは、高度な専門知識を必要とせずに、すぐに使用できます。 Microsoft Foundry on Windows には、使用できる Phi Silica などのモデルが用意されています。 または、 Windows ML を使用すると、開発者は ONNX Runtime でトレーニングされたカスタム モデルなどのカスタム モデルを Windows デバイスで直接実行できます。 これにより、モデルとその動作を高度に制御できるため、特定のユース ケースに基づいて微調整と最適化が可能になります。 Foundry Local また、開発者は Windows デバイス上でモデルをローカルで実行できるため、モデルとその動作を高度に制御できます。

    • 雲： クラウドベースのモデルには、すぐに使用できるオプションとカスタマイズ可能なオプションの両方も用意されているため、開発者は事前トレーニング済みの機能を活用しながら、特定のニーズに合わせてモデルを調整できます。 Microsoft Foundry は、エンタープライズ AI 運用、モデル ビルダー、およびアプリケーション開発のための統合 Azure サービスとしてのプラットフォーム オファリングです。 この基盤は、運用グレードのインフラストラクチャとわかりやすいインターフェイスを組み合わせたものです。これにより、開発者はインフラストラクチャを管理するのではなく、アプリケーションの構築に集中できます。

クラウド AI サンプル

クラウドベースのソリューションが Windows アプリのシナリオに適している場合は、以下のチュートリアルに興味があるかもしれません。

多くの API を使用して、クラウドベースのモデルにアクセスして、 Windows アプリの AI 機能を活用できます。これらのモデルがカスタマイズされているか、すぐに使用できるかに関係なく。 クラウドベースのモデルを使用すると、リソースを集中的に使用するタスクをクラウドに委任することで、アプリを合理化し続けることができます。 Microsoft または OpenAI によって提供されるクラウドベースの AI ベースの API を追加するのに役立つリソースをいくつか次に示します。

  • WinUI 3/ Windows App SDK デスクトップアプリに OpenAI チャットGPTの完了を追加する: クラウドベースの OpenAI ChatGPT 完了機能を WinUI 3/ Windows App SDK デスクトップアプリに統合する方法を解説するチュートリアルです。

  • WinUI 3/ Windows に DALL-E を追加するApp SDK デスクトップ アプリ: クラウドベースの OpenAI DALL-E イメージ生成機能を WinUI 3/ Windows App SDK デスクトップ アプリに統合する方法に関するチュートリアルです。

  • Azure OpenAI サービス: Windows アプリで、GPT-4、GPT-4 Turbo with Vision、GPT-3.5-Turbo、DALLE-3、Embeddings モデル シリーズなどの OpenAI モデルにアクセスし、 Azureのセキュリティとエンタープライズ機能を追加する場合は、この Azure OpenAI ドキュメントのガイダンスを参照してください。

  • Azure AI サービス: Azure は、REST API とクライアント ライブラリ SDK を通じて一般的な開発言語で利用できる AI サービスのスイート全体を提供します。 詳細については、各サービスのドキュメントを参照してください。 これらのクラウドベースのサービスは、開発者や組織が、すぐに使用できる事前構築済みのカスタマイズ可能な API とモデルを使用して、インテリジェントで最先端の市場対応の責任あるアプリケーションを迅速に作成するのに役立ちます。 アプリケーションの例には、会話、検索、監視、翻訳、音声、ビジョン、意思決定のための自然言語処理が含まれます。

ハイブリッド ローカル/クラウド パスを設計する

アプリでローカル推論を利用する必要があるが、サポートされていないデバイスで、またはローカル モデルの準備が整う前に便利なエクスペリエンスを提供する場合は、ハイブリッド パスを使用します。

  1. 最初にローカル機能を選択します。 シナリオに一致する Windows AI API から始めるか、特定のモデルを実行する必要がある場合 Windows ML/ Foundry Local を使用します。
  2. 使用する前に準備状況を確認してください。 起動時または機能が表示される前に、ローカル機能の準備状態を照会します。 この機能がサポートされていない、インストールされていない、またはダウンロードが必要であることを API が報告する場合は、それを盲目的に呼び出さないでください。
  3. ローカル モデルをダウンロードする必要がある場合は、同意を求めます。 一部のローカル モデルは省略可能であり、数 GB にすることができます。 ダウンロード サイズ、モデルが必要な理由、アプリを使用せずに続行できるかどうかを説明します。
  4. クラウド フォールバックを定義します。 ローカル モデルの準備ができていない場合は、ユーザーと組織がデバイスからのデータの送信を許可した場合にのみ、クラウド エンドポイントを呼び出します。 アプリの残りの部分が推論の実行場所に依存しないように、ローカル パスとクラウド パスを同じアプリ レベルの抽象化の背後に保持します。
  5. 動作を監視可能な状態に保ちます。 使用されたパス、準備エラー、モデルダウンロードの結果、クラウド フォールバック エラーをログに記録します。ただし、組織がそのデータ処理を承認していない限り、プロンプト、トークン、機密コンテンツをログに記録しません。

ハイブリッドフォールバック決定フロー

このフローを開始点として使用します。

  1. ユーザーが AI 機能を開始したら、ローカル AI 機能がタスクに適合するかどうかを確認します。
  2. タスクに適したローカル機能がない場合は、クラウド AI または別のサービスを使用します。
  3. ローカル機能がタスクに適合する場合は、現在のデバイスで機能の準備ができているかどうかを確認します。
  4. ローカル機能の準備ができたら、ローカル推論を実行します。
  5. ローカル機能でモデルのダウンロードが必要な場合は、ダウンロードを開始する前にユーザーの同意を求めます。
  6. ユーザーが同意した場合は、モデルをダウンロードまたは準備してから、ローカル推論を再試行します。
  7. ユーザーが同意しない場合、またはローカル機能がサポートされていない場合は、シナリオでクラウド フォールバックが許可されているかどうかを確認します。
  8. クラウド フォールバックが許可されている場合は、クラウド パスを使用します。
  9. クラウド フォールバックが許可されていない場合は、デバイス、モデル、またはポリシーの要件について説明し、機能を無効または非表示にします。

タスクの複雑さによるルーティング

ローカル モデルが使用できない場合にのみローカルからクラウドにフォールバックするだけでなく、多くのアプリでは、各要求をそれに最も適したモデル、つまり軽量で適切に限定されたタスク用の Phi Silica のような小さなオンデバイス モデルと、より深い推論、より広範な知識、またはより大きなコンテキスト ウィンドウを必要とするタスク用の大規模なクラウドベース モデルにルーティングすることで、コスト、待機時間、品質が向上します。

次のようなタスクに対してローカル モデルを優先します。

  • 短い 1 ターンの分類または意図の検出 (たとえば、サポート メッセージをカテゴリにルーティングする)
  • ローカル モデルのコンテキスト ウィンドウ内に快適に収まる、適切に構造化された短いテキストの書き換え、要約、または再フォーマット
  • 短くてクリーンな入力から構造化データ (テーブルやキー フィールドなど) を抽出する
  • ユーザーが簡単に回答を検証または修正できる、リスクの低い会話型の応答
  • タスクがオフラインで動作する必要があるシナリオ、またはデバイスにデータを保持することが要件であるシナリオ

次のようなタスクに対してクラウドベースのモデルを優先します。

  • 複数のツール呼び出しを連結する複数ステップの推論、計画、またはタスク
  • ローカル モデルのコンテキスト ウィンドウを超える長いドキュメントまたは複数ターンのシナリオ
  • ローカル モデルの機能を超える広範な一般知識、または取得機能や他の最新データ ソースを提供するクラウド サービスからの最新情報を必要とするタスク
  • 高い精度基準が求められ、最も強力な使用可能なモデルが必要で、ネットワークの待ち時間とコストを許容できるシナリオ
  • 複雑なコード生成、イメージ生成、またはその他の出力は、より大きな特殊化されたモデルによってより適切に提供されます

実装ガイド:

  1. モデルを選択する前に、タスクを分類してください。 事後にモデル出力からタスクの難易度を推測しようとするのではなく、機能または UI のエントリ ポイント、入力の長さ、または軽量のローカル分類ステップなど、制御可能な単純で明示的なシグナルを使用します。
  2. クラウドに接続されたルーティングに適した場合は、決定モデルを使用します。 Microsoft-Decision-1 などの意思決定モデルは、要求を分類し、品質、待機時間、コスト、信頼度の要件に基づいてローカル モデル、クラウド モデル、ツール、または人間のレビュー パスにルーティングするのに役立ちます。
  3. 単純として分類したタスクにはローカル モデルから開始し、他のローカル AI 機能と同じように、呼び出す前にその準備状況（ハイブリッド フォールバック決定フローを参照）を確認します。
  4. 最初にローカル推論を試み、低品質の結果を破棄するのではなく、高度として分類したタスクのクラウド パスに直接ルーティングします。これにより、ローカル モデルに適していない要求に対するローカル コンピューティングと待機時間の消費が回避されます。
  5. ユーザーがエスカレートできる ローカル応答が要求に完全に応答しない場合は、サイレント エラーではなく、クラウド モデルに対して同じ要求を再試行する明確な方法を提供してください。
  6. ローカル モデルの改善に合わせて、ルーティング規則を見直します。 現在クラウドを必要とするタスクは、モデルの更新後には小さなオンデバイス モデルでも十分対応できるようになる可能性があります。分類ロジックは 1 か所にまとめておくことで、簡単に調整できます。

ローカル対応の詳細については、Windows AI APIs、Windows AI APIs の使用を開始する、Foundry Local、およびWindows MLを参照してください。

  • 最終更新: