【前編】DeepSeek V4をAzureで動かす！中国公式APIを使わない環境構築＆疎通確認ガイド

公開日: 2026年9月12日

皆さん、こんにちは。okamoです。

以前、「過去の記事」にてGitHub CopilotでDeepSeek V4を使う方法を紹介しました。

今回は【前編】として、**マイクロソフトAzure（Azure AI Foundry）内でDeepSeek V4を動かす手順を解説します。

Azureでホストされたマネージドモデルを使うため、プロンプトや送信データが中国のDeepSeek公式APIへ直接送られない点が大きなメリットです（※Azure内において複数国のリージョンで推論処理される点については後述します）。

使用するモデルは、Azure AI Foundryの DeepSeek-V4-Flash-0731 です。AWS BedrockやGCP Vertex AIでは現時点で同モデルが標準提供されていないケースでも、Azureならマネージドで即座にデプロイが可能です。

今回（前編）で行うこと

本手順では、Windows PC上の WSL2（Ubuntu 24.04） からAzureの設定コマンドおよびAPI疎通テストを実行します。

  1. DeepSeek運用の3つの選択肢を比較・整理
  2. Azure AI Foundryに DeepSeek-V4-Flash-0731 をデプロイ
  3. curl コマンドでAzure AIに質問し、応答（疎通）を確認
  4. Pythonサンプルコード（uv環境）で接続確認

※続く【後編】では、このモデルを組み込んだ実践的なアプリケーション・エージェント活用法をご紹介します。

1. DeepSeek V4 運用の三案を比較する

DeepSeek V4を業務で利用する経路は、大きく分けると以下の3パターンがあります。

比較項目A. 自前 GPU PC（オンプレ）B. DeepSeek 公式 API（中国）C. 第三者がホスト（Azure等）★推奨
何をするか自社の専用マシン・GPUでモデルを動かすapi.deepseek.com へリクエスト送信Azure / Cloudflare等のマネージドAPIを呼び出す
運用負荷極めて高い（ハード調達、CUDA、熱・電源、監視）低い低い（クラウド事業者がフルマネージド運用）
データ経路社内閉域（完全ローカル）中国側の公式サーバへ送信Azureの場合：保存は指定リージョン、推論はSKU依存（グローバル）
支払方法機材費・電気代を自社で調達・支払いDeepSeek公式へ直接カード決済等既存のAzureサブスクリプション請求に合算
コスト初期費用大（GPU機材など）、待機中も固定費発生トークン単価は非常に安価ハード不要。公式よりはやや高めだがPoCなら数ドル規模
日本国内閉じ構成次第で可能不可通常は不可（多国リージョンで分散推論）
適した用途完全オフライン・超厳格なデータレジデンシ個人検証、中国へのデータ送信が許容できる場合企業の業務PoC・本番導入（最もバランスが良い）

なぜ「C. 第三者がホスト（Azure）」がおすすめなのか？

  • A（ローカルGPU）の壁: V4 FlashはMoE（Mixture of Experts）構造ですがパラメータ規模は284Bクラスです。個人のノートPCや安価なGPUでは太刀打ちできず、機材調達やCUDA環境の保守だけで膨大な工数がかかります。
  • B（中国公式API）の壁: 社内セキュリティ規定や顧客とのNDAにより「中国サーバへのプロンプト送信が禁止されている」企業では採用できません。
  • C（Azure Foundry）の強み: インフラ管理はMicrosoftに任せつつ、中国公式APIへデータを送らずに利用できます。

2. 【重要】Azureにおけるデータの行き先とSKUの理解

Azureでホストする場合の「データの流れ」について、よくある誤解を整理しておきましょう。

  • 「Azureを使えば日本リージョンだけで完結する？」
    👉 いいえ。 現状の DeepSeek-V4-Flash-0731 は主に GlobalStandard というSKUで提供されており、負荷状況に応じて世界各国のAzureデータセンター（米国・カナダ・欧州・日本・韓国・豪州など）へ動的にルーティングされて推論処理が行われます。
  • 「DeepSeekだから中国へ送られる？」
    👉 送られません。 Microsoftの公式ドキュメントにより、商用AzureのGlobal推論において中国リージョンは含まれず、DeepSeek社やOpenAIなどの外部APIにも送信されないことが明記されています。
  • 「入力データが勝手に学習される？」
    👉 学習には使われません。 プロンプトや生成結果が他社モデルや基盤モデルの学習に再利用されることはありません。

※法務部門やセキュリティ担当者への説明時には、「保存データは指定した米国東部などのgeographyに置かれるが、推論処理はAzureの商用グローバルリージョン間で行われる」という点を共有しておくとスムーズです。

3. 利用料金の目安

従量課金（Serverless）の目安は以下の通りです（※価格は改定される可能性があるため、作業前に公式ポータルでご確認ください）。

  • Azure Foundry DeepSeek-V4 Flash Global:
    入力: 約 $0.19 / 100万トークン、出力: 約 $0.51 / 100万トークン

1回あたり10万トークン入力・2万トークン出力のレポート生成を行っても、1回あたり数セント（数円〜数十円）程度です。PoC（概念実証）段階であれば、月額数ドル〜数十ドル程度で十分に検証可能です。

4. 作業手順（Windows + WSL2 Ubuntu 24.04）

ここからは実際に手を動かして環境構築と疎通確認を行います。

<RESOURCE_GROUP> や <ACCOUNT_NAME> などの < > 表記の部分は、ご自身の環境に合わせた値に置き換えて実行してください。

4.1 WSL（Ubuntu 24.04）を準備する

実行場所: Windowsの管理者 PowerShell

WSLがまだインストールされていない場合は、PowerShellからセットアップします。

wsl --install -d Ubuntu-24.04

インストール後、必要に応じてWindowsを再起動し、Ubuntuを起動します。

wsl -d Ubuntu-24.04

初回起動時はUNIXユーザー名とパスワードの設定を求められます。画面の指示に従って任意のユーザーを作成してください（※パスワード入力時は画面に文字が表示されませんが、正しく入力されています）。

4.2 会社のプロキシ環境を設定する（該当者のみ）

社内ネットワークでプロキシが必要な場合は、Ubuntuのターミナルで以下を設定します（不要な環境ではスキップして4.3へ進んでください）。

export http_proxy="http://<PROXY_HOST>:<PROXY_PORT>"
export https_proxy="http://<PROXY_HOST>:<PROXY_PORT>"
export HTTP_PROXY="$http_proxy"
export HTTPS_PROXY="$https_proxy"
export no_proxy="localhost,127.0.0.1,.local"
export NO_PROXY="$no_proxy"

apt 用のプロキシ設定:

sudo tee /etc/apt/apt.conf.d/95proxy >/dev/null <<EOF
Acquire::http::Proxy "http://<PROXY_HOST>:<PROXY_PORT>";
Acquire::https::Proxy "http://<PROXY_HOST>:<PROXY_PORT>";
EOF

4.3 パッケージ管理ツール uv とサンプルの準備

実行場所: WSLのUbuntu

※もしWSL内で名前解決（DNSエラー）が起きる場合は、echo 'nameserver 8.8.8.8' | sudo tee /etc/resolv.conf を実行してGoogle Public DNSを参照するように設定してください。

Pythonの高速パッケージマネージャー uv をインストールします。

command -v uv >/dev/null || curl -LsSf https://astral.sh/uv/install.sh | sh
source "$HOME/.local/bin/env"
uv --version

続いて、動作確認用のサンプルコードをダウンロードします。

curl -O https://raw.githubusercontent.com/okamoto53515606/azure-deepseek-v4/main/dsv4_wsl_poc_agent.py

4.4 Azure CLI のセットアップとログイン

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login

ブラウザが開かない環境では az login --use-device-code を使用してください。 ログイン後、使用するサブスクリプションを設定します。

az account set --subscription "<ご自身のサブスクリプションID>"
az account show --query '{name:name,id:id,tenantId:tenantId}' --output table

4.5 Azure AI リソースの作成とモデルのデプロイ

リソースグループとAI Servicesアカウントを作成します。リージョンはモデルの提供が豊富な eastus を指定します。

export RG="<RESOURCE_GROUP>"
export LOC="eastus"
export ACCOUNT="<ACCOUNT_NAME>" # 英小文字と数字のみ
export DEPLOY="DeepSeek-V4-Flash-0731"

az group create -n "$RG" -l "$LOC"

az cognitiveservices account create \
  -n "$ACCOUNT" -g "$RG" \
  --custom-domain "$ACCOUNT" \
  --location "$LOC" \
  --kind AIServices \
  --sku S0

⚠️ リソースプロバイダー登録エラーが出た場合
MissingSubscriptionRegistration エラーが出た場合は、Azure Portalの「サブスクリプション」→「リソースプロバイダー」から Microsoft.CognitiveServices を検索し、「登録」を行ってください。

続いてモデルをデプロイします。ポータル画面（Foundryカタログ）からポチポチと作成するか、以下のCLIコマンドでデプロイします。

# モデルのバージョンとフォーマットを取得
export MODEL_VERSION=$(az cognitiveservices account list-models -n "$ACCOUNT" -g "$RG" --query "[?name=='DeepSeek-V4-Flash-0731'].version | [0]" -o tsv)
export MODEL_FORMAT=$(az cognitiveservices account list-models -n "$ACCOUNT" -g "$RG" --query "[?name=='DeepSeek-V4-Flash-0731'].format | [0]" -o tsv)

# デプロイの作成
az cognitiveservices account deployment create \
  -n "$ACCOUNT" -g "$RG" \
  --deployment-name "$DEPLOY" \
  --model-name "DeepSeek-V4-Flash-0731" \
  --model-version "$MODEL_VERSION" \
  --model-format "$MODEL_FORMAT" \
  --sku-capacity 20 \
  --sku-name "GlobalStandard"

デプロイ状況を確認し、provisioningState が Succeeded になっていれば準備完了です。

az cognitiveservices account deployment show \
  -n "$ACCOUNT" -g "$RG" --deployment-name "$DEPLOY" \
  --query '{name:name,provisioningState:properties.provisioningState}' --output table

Azure Portal上の Microsoft Foundry リソース一覧でも、以下のようにデプロイしたリソースの状態が「Succeeded」になっていることが確認できます。

Azure Foundryのリソース一覧画面

4.6 接続環境変数の設定

作成したリソースのエンドポイントURLとAPIキーを取得して環境変数に格納します。

export AZURE_AI_ENDPOINT="$(az cognitiveservices account show -n "$ACCOUNT" -g "$RG" --query properties.endpoint -o tsv | sed 's:/*$::')"
export AZURE_AI_API_KEY="$(az cognitiveservices account keys list -n "$ACCOUNT" -g "$RG" --query key1 -o tsv)"
export AZURE_AI_DEPLOYMENT="$DEPLOY"

echo "endpoint=$AZURE_AI_ENDPOINT"
test -n "$AZURE_AI_API_KEY" && echo "api_key=set"

5. 疎通確認テスト

5.1 curl による基本疎通確認

まずは一番シンプルな curl コマンドで、Azure上のモデルに対してOpenAI互換API形式で直接リクエストを投げてみましょう。

curl -sS --fail-with-body "${AZURE_AI_ENDPOINT}/openai/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "api-key: ${AZURE_AI_API_KEY}" \
  -d "{
    \"model\": \"${AZURE_AI_DEPLOYMENT}\",
    \"messages\": [
      {\"role\": \"user\", \"content\": \"1+1は？数字だけ答えて。\"}
    ],
    \"max_tokens\": 128
  }"

以下のようにターミナルに応答JSONが返ってきて、choices[0].message.content に "2" が含まれていれば疎通成功です！

WSLのcurlによる疎通確認結果

5.2 Python サンプルコードによる疎通確認

次に、Pythonスクリプトから呼び出せるかを確認します。uv を使って素早く依存ライブラリを導入して実行します。

uv init --bare
uv add strands-agents openai
uv run python dsv4_wsl_poc_agent.py --ping-llm

実行結果の末尾に llm_response=2 と出力されれば、Python環境からの呼び出しもバッチリ成功です。

Pythonスクリプトによる疎通確認結果

まとめと次回予告

今回は前編として、DeepSeek V4を自社環境で安全に動かすための選択肢の比較と、Azure AI Foundryへのデプロイ＆WSL2からの疎通確認までを実施しました。

  • 中国公式APIへデータを流さず、マネージドで手軽にDeepSeek V4を利用可能
  • 既存のAzure請求・ガバナンスに乗せられるため企業PoCに最適
  • OpenAI互換APIエンドポイントなので既存ツールやPythonコードの移行も容易

【後編】では、今回疎通確認した環境を使って、アプリケーションを動かす応用例を解説します。

👉 「【後編】Azure上のDeepSeek V4×MCP Toolboxで実践！BigQueryとSQL Serverの自動データ分析＆Wordレポート生成」をみる

タグ: DeepSeek, Azure, OpenAI, WSL, Python, 初心者向け, インフラ
トップページへ