はじめに

こんにちは！AgVentureLabの藁谷です。
セキュリティ要件で GitHub Copilot は使えない…。
でも、VSCodeでのAIによるコーディング支援はやっぱり欲しい──そんな現場、ありますよね。

GitHub Copilot を使えないガバナンス環境でも、社内ネットワーク ↔ Azure テナントだけで閉じた推論実行を実現できれば、VS Code から安全にコーディング支援を受けられるのではないかと考えました。

この記事では、GenieAI → Azure Functions（プロキシ/監査） → Azure AI Foundry（Responses / Agent） の構成で、

外部（インターネット・第三者クラウド）へコード/プロンプトを出さない
送受信先・ログ・保持期間を自社で統制できる
Private Endpoint / VNet 統合で閉域

を実現する方法と、 いわゆるJTCが見る観点（データ取扱・法務・監査・運用） に対する“対策→根拠”を具体的に整理します。

目次

背景と課題（なぜ Copilot を使えないのか）
GitHub Copilot for Azure なら自組織サブスクリプションで利用可能なのか
代替案としてのAzure AI Foundry
ここまでのまとめ
Genie AIとAzure AI Foundryエージェントのアンマッチ
アンマッチ解消のためAzure Functionsをプロキシ兼変換レイヤーとして利用
アーキテクチャイメージ
動作の確認
課題
まとめ
（おまけ）ガバナンスとセキュリティチェックリストとリスク解決案
参考リンク

背景と課題（なぜ Copilot を使えないのか）

GitHub Copilotは、GitHubが提供するAIペアプログラマ機能で、OpenAIの最新GPT系モデル（GPT‑4.1/4oなど） を用途に応じて活用します。

利用時には、入力したコード断片やコメント（プロンプト）がGitHubのクラウド（米国を含むMicrosoft管理環境）へ送信され、モデルが推論処理を行い、結果を返す流れです。

禁止される主な理由

１. コードやプロンプトが外部送信される
プライバシー声明によれば、以下のようにGitHub Copilotで推論に用いるコード断片やプロンプトは"個人データも含み"送信される。
既定では学習利用は行われないが、送信そのものがリスクと見なされる組織もある。

ユーザーコンテンツとファイル:当社のサービスを使用する場合、コード、入力、テキスト、ドキュメント、画像、フィードバックなど、お客様が提供する情報の一部として含まれる個人データを収集します。

２. ライセンス・権利関係の懸念
提案コードがOSS由来の可能性がある。
一致回避設定（public code matching）を有効化することで、既知OSSコードの提案を抑止可能。

３. 外部インターネット接続制限
金融・医療・官公庁などで発生しがちな、インターネット接続不可とされている環境(閉域網)では利用不可。

４. ログの所在・保持期間が不明確
サーバー側で保持されるデータの保存期間や管理方法は組織の管理外となりリスクラインへの説明がつかない場合もある。

余談：GitHub Copilotを含むコーディングAIの動向

・2025年3月: GPT‑4o がコード補完で一般提供開始
・2025年8月: Copilot Chat で GPT‑4o 廃止 → GPT‑4.1 推奨へ
・エージェントモードを利用した、プロンプトのみで実装を行う「Vibe Coding」なども登場
・「動けば良し」から「仕様駆動開発（kiroなど）」へシフトする流れも話題に

GitHub Copilot for Azure なら自組織サブスクリプションで利用可能なのか

GitHub Copilot for Azure とは

・Azure CLI / Bicep / ARM テンプレートなど、Azure リソースの管理・デプロイに関わるコード補完を強化
・Azure サブスクリプション情報を参照して、利用中のリソースに即した提案が可能
・Microsoft Graph API や management.azure.com への連携アクセスを伴うケースもある
上記のようにAzure リソースを前提にした便利な補完が得られる拡張機能となっています。
では、前述のような問題はこの拡張機能で解消できるのでしょうか。無印のGitHub Copilotと比較してみましょう。

通信先と管理主体の比較

種類	通信先	管理主体	特徴
通常の Copilot	`https://api.githubcopilot.com` （copilot-proxy.githubusercontent.com は2024/2/1廃止）	GitHub	エディタ内コード送信、推論処理
Copilot for Azure	`https://api.githubcopilot.microsoft.com/`	Microsoft	Azureテナント情報利用、Graph連携可能

共通点：
・推論はパブリック環境で実行され、自社サブスクリプション内ではない。
・パブリック環境利用のため、インターネット接続が必須。

結論

認証統合やリソース接続は便利
しかし データ主権や閉域利用の課題は未解消
Azureそのものと、自組織サブスクリプションがもっている情報を利用可能にする拡張であって、ガバナンスに関する機能ではない。

代替案としてのAzure AI Foundry

上記のような問題点があることから、AgVentureLabではコーディングに限らず、いわゆるAIチャットとしてのOpenAI社Chat-GPTの利用が制限されています。
そのため、自組織サブスクリプション内でデプロイしたAIモデルを利用した専用chat-GPTを構築、利用しています。
こちらはプロンプトやログも自組織で管理する環境に閉じておりコントロールが可能です。プロンプトの外部送信リスクや監査への対応が可能となっています。
その際に利用しているサービスがAzure AI Foundryです。

ここにヒントを得て、VSCodeの拡張機能からAIモデルのエンドポイントを指定できれば解決するじゃないか！というのが今回の要旨です。

VSCodeで安全なAIモデルを利用できる拡張機能「Genie AI」

そこで、我々のチームが利用しているサービスがGenie AIです。
GenieAIについては過去に以下のような記事を書いていますが、情報は古いので利用方法の参考までに
重要なこととしては自組織サブスクリプションで作成したChat-GPTモデルをエンドポイントとして指定できる点です。

これはエージェント機能がつく前のGitHub Copilotのように利用可能なもので、
・エージェントモード利用なし
・インラインサジェストなし
・ワークスペース情報の自動取得なし
という課題があります。
特にワークスペースの情報参照ができない点は、不便に感じることが多かったように思います。

実際、開発者の中にはAzure AI Foundryのチャットプレイグラウンドにてコード生成し、VSCodeにコピペする方が早いとして、利用しなくなるケースも出てきました。
同様に、Azure AI Foundryではエージェントを自分で作成することができるため、検索処理が可能なエージェントを作成しプレイグラウンドから触る→GenieAIを使わなくなるという動きもありました。

Azure AI Foundryで作成したエージェントをGenie AIで使えないか

この後は、Azure AI Foundry上で作成したエージェントをエンドポイントとして利用することで、VSCodeからセキュアに自組織専用のエージェントを利用する方法を検討します。

ここまでのまとめ

GitHub Copilot(for Azure含む)ではデータ主権や閉域網利用の観点で利用が制限されることがある。
これはOpenAI社のChat-GPT利用するときと似たような考え方。
一方Azure AI Foundryを用いることでセキュアにChat-GPTの組織内利用が可能。
同じ仕組みを使ってコーディングサポートAIを作成したい。

Azure AI Foundryでの懸念解消

Azure AI Foundryは、Azureサブスクリプション内で生成AIのエンドポイントを構築し、Private EndpointやVNet統合で閉域化できます。
これにより、Copilotの課題の多くを軽減できます。

懸念項目	Foundryによる解消度	補足・残存リスク
コードやプロンプトの外部送信	高	データ送信先をAzure内に限定可能。閉域化すれば外部送信ゼロ
OSS由来コードリスク	中	モデル学習データの完全制御は不可。社内RAGに限定すれば低減可能
閉域網での利用	高	Private Endpoint / Vnet統合対応
ログ管理	高	Azure Monitor(Application Insights等)で保存先・期間を自社管理可能

参考：
・Private LinkでAzure AI Foundryを閉域化

Genie AIとAzure AI Foundryエージェントのアンマッチ

ではどのようにしてコーディングサポートAIを作成すれば良いでしょうか。
実は、単純にGenie AIのエンドポイントを作成したエージェントとしても全くうまくいきません。
これはリクエスト/レスポンスのモデルの違いが原因です。AIによると以下のように大きく仕様が異なります。

項目	Chat Completions モデル(GenieAIが想定するモデル)	Agent モデル（Azure AI Foundry エージェントのモデル）
会話の状態管理	ステートレス（履歴を毎回送信）	ステートフル（サーバ側でスレッドを保持）
API形式	`messages[]` 配列でやりとり	`thread` / `run` / `responses` を用いる
ユースケース	単発QA、短い補完リクエスト	業務フロー全体、マルチターン対話、タスク実行
拡張性	会話以外はクライアント実装に依存	ツール連携（HTTP/RAG/関数呼び出し）を統合可能
利点	軽量・高速・シンプル	状態保持・複雑な処理・業務特化が可能
制約	長い履歴は送信コスト増、状態は持てない	構成・管理がやや重い、GenieAIからは直接使えない
Azureでの位置付け	Azure OpenAI Service の `chat/completions`	Azure AI Foundry のエージェント（Responses/Assistants API）

実際に入出力の形式を見ても、構造が異なっていることがわかります。

A) Chat Completions モデル（GenieAI）

リクエスト

POST https://EndpointURL/openai/deployments/gpt-4o/chat/completions?api-version=2025-04-01-preview

{
  "messages": [
    { "role": "system", "content": "You are a helpful coding assistant." },
    { "role": "user", "content": "配列を逆順にするJavaコードを書いて" }
  ],
  "temperature": 0.2
}

レスポンス

{
  "id": "chatcmpl-abc123",
  "model": "gpt-4o",
  "choices": [
    {
      "index": 0,
      "message": { "role": "assistant", "content": "public class ReverseArray { /* ... */ }" },
      "finish_reason": "stop"
    }
  ]
}

B) Agent モデル（Foundryエージェント）

リクエスト(スレッド生成+プロンプト送信+実行) ※実際は段階的に実施できる

POST https://EndpointURL/openai/threads/runs?api-version=2025-04-01-preview

{
  "assistant_id": "asst_123",
  "thread": {
    "messages": [
      { "role": "user", "content": "配列を逆順にするJavaコードを書いて" }
    ]
  }
}

レスポンス（JSON）

{
  "id": "run_456",
  "object": "thread.run",
  "status": "completed",
  "thread_id": "thread_789",
  "assistant_id": "asst_123"
}

メッセージ取得リクエスト

GET https://EndpointURL/openai/threads/thread_789?api-version=2025-04-01-preview

{
  "id": "thread_789",
  "messages": [
    { "id": "msg_user", "role": "user", "content": "配列を逆順にするJavaコードを書いて" },
    { "id": "msg_assistant", "role": "assistant", "content": "public class ReverseArray { ... }" }
  ]
}

やり取りする形式が違うため、直接Genie AIとFoundryエージェントを繋ぐことはできないことがわかりました。

アンマッチ解消のためAzure Functionsをプロキシ兼変換レイヤーとして利用

そこで、変換レイヤーとしてFunctions利用します。
このFunctionsは以下のような責任を持たせます。

・エージェントを呼び出しに必要なKeyを取得
・Chat Completions モデルを受け取りAgent モデルに変換する
・Foundryのスレッドを作成してプロンプトを送信し、特定のエージェントに実行させる
・実行結果をChat Completions モデルに変換してリターン

また、中継の処理をFunctionsに持たせることにより、入力プロンプトやスレッドIDなど、 監査ログとして必要な情報を選択してAzure Monitorに保持させることが可能 です。

アーキテクチャイメージ

これまでの検討をもとに、イメージを起こしました。

[VSCode + GenieAI拡張] → [Azure Functions] → [AI Foundry Agent Endpoint] → [モデル応答]

VS Code + GenieAI：Copilotの代替として、任意のエンドポイントにコード生成リクエストを送信可能
- 設定キー：genieai.azure.url にAzure OpenAIまたはFunctions経由URLを指定可
Azure Functions：GenieAIとAI Foundry間のプロキシ兼変換レイヤーとする
AI Foundry Agent：組織仕様の会話やコード生成ロジックを持つエージェント

動作の確認

今回動作の確認として、Foundryで作成した"bing検索"可能なエージェントを作成しました。
これでリアルタイム情報を取得できれば、エージェントとの疎通が可能と判断します。
・GPT-4oのエンドポイント

想定通り、最新情報の取得はできず、一般的な回答が返ってきます。

・作成したFunctionsのエンドポイント

日付情報やQiitaの記事の検索をしてくれました！
どうやらこの構成でFoundryで作成したエージェントがGenieAIで利用できるようですね！

課題

GenieAIは ステートレス（single-turn）
解決案１.Azure Table Storage で最小限の要約をTTL付きで保持し、前後文脈を橋渡し
解決案２.ユーザの特定にFunctionsのURLパラメータを利用し、ユーザごとのStrageに格納した会話履歴を利用
Agentモードは利用不可 → コード編集機能を持つ拡張機能を同様の手法でチューニング？
RAGやツール呼び出しを活用には Foundry 側の機能理解とスキルが必要

まとめ

GitHub Copilotはセキュリティ・ガバナンス上の懸念で利用不可な環境がある
Copilot for Azureも閉域化は不可
GenieAI + Functions + Azure AI Foundry で閉域網・監査対応のコーディングAIが実現可能
監査ログ・保持期間・マスキングなど“組織にあった”運用設計を取り込み可能
Single-turn制約は Table Storage 等で暫定解消

（おまけ）ガバナンスとセキュリティチェックリストとリスク解決案

リスクごとの対策案をAIが作ってくれたので参考までに。
実際には精査して実用に耐えられるか確認が必要ですが、叩き台にはなりそうだと感じました。

リスク/懸念	対策	実装ポイント	監査・証跡
コード/プロンプトが第三者クラウドに送られる	送信先を Functions → Foundryに限定	GenieAIのエンドポイントを社内指定URLに固定、FunctionsをVNet統合	NSG/UDR、AppGWログ、Functions監査
モデルへの学習利用	学習利用オプトアウト	Foundry設定 + Functionsで禁止ヘッダ	設定スナップショット、KQLレポート
地域・データ主権	東日本/西日本リージョン明示	IaCで Location 固定	IaC Git履歴、Azure Policy レポート
ログ所在・保持期間	App Insights / Log Analytics 自社管理	保持期間設定、アクセス制御	KQL 抽出テンプレ、月次エクスポート
機密情報誤送信	FunctionsでDLP検知→ブロック	秘密鍵・個人番号など検知	ブロック件数ダッシュボード
OSS由来コード混入	ライセンスLint運用	SPDX検査、差し戻しルール	月次レポート
権限の過剰付与	Managed Identity + 最小権限	RBAC/Secrets廃止	PIM記録、Access Review
監査要求	相関IDで全段追跡	FunctionsでID付与	KQL再現手順

参考リンク