top of page
logo.png

エディタAIを「国内完結」で使う― Azureで諦めた“推論の国内完結”を、AWS Bedrock で取り戻すまで

  • takeshiohno
  • 7月14日
  • 読了時間: 7分

社内のコードとログを海外のLLM SaaSに送らずに、エディタでAIコーディングを使いたい。 この当たり前の要望が、実は技術的にかなり難しいという話と、それを2つのクラウドで実測して白黒つけた記録です。


生成AIをコーディング業務に組み込むとき、多くの企業が最初にぶつかる壁が 「入力したコードや社内ログが、海外のデータセンターで処理されるのではないか」という懸念です。 いわゆるデータ越境リスク。契約や規約で「学習には使わない」と書かれていても、 物理的にどのリージョンで推論(inference)が実行されるかは別問題として残ります。

私たちはこのテーマに対して、2つのクラウド上で検証リポジトリを作り、 「書類上できるはず」を一切信用せず、すべて実測で判定するという方針で取り組みました。 本記事はその2つのリポジトリ ― Azure版の editor-openai-foundry と、 AWS Bedrock版の editor-claude-bedrock ― をたどりながら、推論の国内完結がどこまで実現できるのかを整理します。


この記事で答えること

  • 「保管は国内」と「処理も国内」はまったく別の話であること

  • Azure AI Foundry では、なぜ“推論の国内完結”を断念したのか

  • AWS Bedrock の jp. プロファイル × Claude Opus 4.8 で、それをどう取り戻したか

  • 実測しないと絶対に分からなかった、公式ドキュメントとのズレ


1. 「保管が国内」だけでは足りない

データの所在を考えるとき、区別すべきは2つあります。

区分

意味

見落としがちな点

保管（at rest）

データがディスクに置かれる場所

多くのサービスで国内に固定でき、比較的守りやすい

推論（inference）

実際にモデルが計算を行う場所

ここが国外に出うる。「国内完結」を名乗るときの本当の焦点

「データは日本のリージョンに保存されます」という説明は、たいてい保管の話です。 しかし推論、つまりプロンプトが実際に処理される場所は、負荷分散や可用性のために別リージョンへ回されることがあります。 私たちが達成したかったのは、この推論まで含めて東京・大阪の外に出さない状態でした。


2. Azure編 ― 実測の末に“推論の国内完結”を断念する

最初の挑戦が editor-openai-foundry です。 Azure AI Foundry（kind: AIServices）を japaneast に立て、 社員が Zed / VS Code などのエディタから API キーで Azure OpenAI を呼べる、という社内基盤を目指しました。 用途はコーディングエージェントとログ解析。Bicep でインフラを、Azure Functions でキーローテやコスト上限を実装しています。

Azure OpenAI には、推論がどこで走るかで3つの選択肢（SKU）があります。保管はどの選択肢でも常に日本ですが、 処理範囲が違います。

SKU

推論が走る範囲

国内完結

regional Standard

japaneast に固定

◎ 完全に国内

DataZone Standard

APAC 圏内（米国は含まない）

△ 国外だがアジア圏内

Global Standard

全世界（米国を含む）

✕ 採用せず

狙いは当然、いちばん左の regional でした。ところが実測すると、壁が次々に現れます。

  • regional対応のチャットモデルが軒並み“廃止予定”。 regional で動かせるチャットモデル（gpt-4o / gpt-4.1-mini）はどちらも deprecating 状態で、 新規デプロイがプリフライトで弾かれる（“in deprecating state and cannot be used for new deployments”）。 非推奨でない国内完結チャットモデルが存在しないという状態でした。

  • Codex系はエディタから使えない。 gpt-5.3-codex は Responses API 専用（chatCompletion: false）で、 Chat Completions を使うエディタからは呼べない。結果、実務では gpt-5.2 を採用。

  • 非OpenAIモデル（DeepSeek等）は Global でしか現れない。 越境させない方針と真っ向から衝突するため、これらの導入フェーズは保留に。


Azure編の結論: 保管は日本に固定できたものの、推論の国内完結（regional）は現時点で構成不可能。 やむなく DataZone（APAC処理）で運用開始。「アジア圏内には収まるが、日本の外には出る」という妥協点でした。

そしてもうひとつ、この過程で得た最大の教訓が ―― 公式の提供表と実環境の乖離を4回踏んだという事実です。 「表ではできることになっている」を信じて設計すると、デプロイの直前で足元をすくわれる。 この経験が、次の Bedrock 検証の方針をまるごと決めることになります。


3. Bedrock編 ― jp. プロファイル × Claude Opus 4.8

次に取り組んだのが、姉妹リポジトリ editor-claude-bedrock です。 鍵になったのは、AWS Bedrock の 日本国内クロスリージョン推論プロファイル（jp. プロファイル）。 これは推論先を東京 + 大阪の2リージョンに閉じる仕組みで、Azure で届かなかった regional 相当を狙えます。 モデルは Claude Opus 4.8 を前提としました。

Azure版の教訓をそのまま引き継ぎ、この PoC では次の3点だけを実測で白黒つけることにしました。

検証項目

実測結果（2026-07-14）

jp. に Opus 4.8 が実在するか

✅ OK ― jp.anthropic.claude-opus-4-8（東京+大阪）

jp. 指定で推論が本当に国内に閉じるか

✅ OK ― CloudTrail の inferenceRegion=ap-northeast-1 を確認

エディタ/CLI から API キーで実際に動くか

✅ OK ― Claude Code（CLI・VS Code拡張）/ Zed で直結

さらに、統制の強さが Azure 版とは根本的に違いました。 Azure では「-apac という deployment 名で利用者に認識させる」という 運用規約しか手段がなかったのに対し、Bedrock では IAM ポリシーで技術的に強制できます。

  • 迂回防止: jp. 以外のプロファイル（global./apac.）やモデル直叩きを IAM で拒否。us-east-1 など他リージョンへの回り込みも明示 Deny。

  • 事後監査: CloudTrail の inferenceRegion で、実際に処理されたリージョンを1件ずつ確認できる。

  • コスト: Opus 4.8 は $5 / $25（入力/出力・per 1M）。jp. は +10% で実効 $5.5 / $27.5。国内完結のプレミアムは1割、という具体的な値が出ました。

Bedrock編の結論: Azure で断念した「推論の国内完結」を、Opus 4.8 × jp. プロファイルで達成。 しかも越境防止を規約でなく IAM で強制し、CloudTrail で裏取りできる。統制の質まで一段上がりました。


4. 実測しないと絶対に分からなかったこと

ここが、この2つのリポジトリを通じて最も伝えたい部分です。 「書類上できるはず」を疑う方針は、Bedrock でも何度も報われました。


① OpenAI互換エンドポイントに Claude は“いない”

当初は「OpenAI互換 API に直結すれば既存エディタがそのまま使える」と踏んでいました。 しかし実測すると、Bedrock の /openai/v1 のカタログは gpt-oss 系専用で、 Claude は model_not_found。管理者権限で叩いても同じ ―― つまり権限の問題ではなく、 OpenAI互換 × Claude という組み合わせが今の AWS に存在しないのでした。


② では詰みかというと、詰まなかった

ネイティブ Bedrock 対応のクライアントなら直結できる、と分かりました。 Claude Code（CLI・VS Code拡張）と Zed（ネイティブ Bedrock プロバイダ）で、 チャットもエージェント作業も成立。当初想定していた LiteLLM のような変換プロキシは不要でした。 「互換」を狙うより、素直に対応クライアントを選ぶほうが早かったわけです。


③ 「今動いた」は「使える」の証明にならない

最も厄介だったのが、AWS の権限執行が非同期だったこと。 全 Claude モデルには Marketplace 契約が必要ですが、契約なしでも最初の数十分〜半日は通ってしまい、 後から AccessDenied に変わる（Opus で約40分、Haiku で半日のズレを実測）。 加えて Anthropic の use case フォーム提出も必須で、しかも Converse API は未提出でも通るのに InvokeModel 系は 404 で拒否という執行の不整合までありました。 疎通確認を Converse だけで済ませていたら、確実に誤判定していたところです。

これらはすべて、公式ドキュメントを読むだけでは決して見えません。 手を動かし、CloudTrail のログを1件ずつ確認して初めて白黒がつきました。 両リポジトリの README と docs/ には、 この「踏んだ罠」がそのまま記録として残してあります。


5. まとめ ― 越境リスクへの現実的な答え

観点

Azure（editor-openai-foundry）

Bedrock（editor-claude-bedrock）

推論の国内完結

△ DataZone（APAC）止まり

◎ 東京+大阪に限定

越境防止の手段

deployment名の運用規約のみ

IAMで強制 + CloudTrailで監査

主なモデル

gpt-5.2（APAC）

Claude Opus 4.8（国内完結）

追加コスト

―

国内完結プレミアム +10%

生成AIの越境リスクは、「使わない」か「目をつぶって使う」かの二択ではありません。 どのリージョンで処理されるかを技術的に固定し、それを監査で証明するという第三の道が、 少なくとも Claude Opus 4.8 × Bedrock jp. プロファイルでは成立します。 国内完結のコストは、モデル単価の1割増し。この数字を根拠付きで示せることに意味があります。

そして何より、この2つのプロジェクトが残した一番の資産は結論そのものではなく、 「公式の表を信じず、すべて実測で白黒つける」という進め方だと考えています。 クラウドの生成AI基盤は動きが速く、昨日の正解が今日は変わります。 だからこそ、自分たちの環境で手を動かして確かめた記録にこそ価値がある ―― それが今回の一番の学びでした。


リポジトリ（いずれも公開・MITライセンス）

🔷 Azure版 ― github.com/Challenge-Consulting-Firm/editor-openai-foundryAzure AI Foundry で社内エディタAI基盤を構築。推論の国内完結を実測した記録。

🟠 AWS Bedrock版 ― github.com/Challenge-Consulting-Firm/editor-claude-bedrockjp. プロファイル × Claude Opus 4.8 で国内完結を達成した PoC。


※ 本記事の実測値・制約はいずれも 2026-07 時点・ap-northeast-1/3 での検証結果です。 クラウド各社のモデル提供状況は頻繁に変わるため、導入時は最新の提供状況をご確認ください。

コメント

bottom of page