はじめに
こんにちは！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再現手順 |