はじめに
開発効率を上げるために生成AIを導入したいが、セキュリティ部門の承認が得られないという課題は、多くの開発現場で直面する壁です。特に金融、医療、製造業といった、知的財産や顧客情報の保護が極めて重要な業界において、この問題は深刻な影響を及ぼします。エンジニアが個人のスマートフォンでChatGPTを使用し、コードを貼り付けるなど、安全ではない方法でAIを利用するリスクも顕在化しています。
この記事では、金融機関など厳格なセキュリティが求められる現場の事例を参考に、コンプライアンス要件を満たしつつ、生成AIを安全に活用するための実践的なアプローチについて解説します。多くの企業では「ソースコードは社外に出せない」という条件下で、GitHub CopilotなどのSaaS製品の導入を断念するケースが少なくありません。
しかし、オープンソースのVSCode拡張機能「Continue」と自社ホスティングのローカルLLMを組み合わせることで、完全閉域網でのAIコーディング環境を構築することが可能です。
本記事では、初期設定における技術的なハードルや、SaaS版に比べて精度が劣る点など、実運用におけるネガティブな側面も含めて論理的に解説します。コンプライアンスの壁を乗り越え、プロジェクトにAIを導入するためのヒントとしてご活用ください。
1. プロジェクト背景：「ソースコードは社外持ち出し禁止」の壁
厳格な開発環境とセキュリティ要件の現実
金融機関や大規模エンタープライズ企業における開発環境は、一般的なWeb系スタートアップとは全く異なり、極めて堅牢な統制下に置かれることが一般的です。
多くの組織では、開発者が日常的に使用する端末はVDI（仮想デスクトップ基盤）上に集約されており、インターネットへの直接接続は厳しく制限されています。外部のリポジトリ（GitHub.comなど）へのアクセスはもちろん、許可されたホワイトリスト以外のドメインへの通信はファイアウォールで完全に遮断される仕様が標準的です。
こうした組織のセキュリティポリシーには、業界特有の譲れない以下のような厳格な要件が存在します。
- ソースコードの外部保存禁止: 自社のデータセンター（オンプレミス）または、厳密に管理された専用VPC（仮想プライベートクラウド）以外にコードを保存・複製してはならない。
- 第三者へのデータ送信禁止: コード解析やデバッグ目的であっても、外部ベンダーが管理するサーバーに生データを送信することは認められない。
- SaaS利用の原則禁止: 監査ログが自社で完全にコントロールできない、あるいはデータ主権が保証されないSaaSの利用は、特例を除き認めない。
この「閉じた環境」の中で、開発チームは数十年にわたり運用されてきたCOBOL資産や、それをJavaなどへ移行したレガシーコードの保守・改修という難題に立ち向かう必要があります。
現場からの悲鳴：レガシーコード解析の限界
現場のエンジニアたちを最も苦しめているのは、複雑化したレガシーコードの解析という課題です。
長年の改修でスパゲッティ化したロジック、更新されず実態と乖離したドキュメント、そして当時の担当者が既に退職しているという状況は、多くのプロジェクトで共通して見られます。特に新卒や中途入社の若手エンジニアにとって、このブラックボックス化したコードを理解することは困難を極め、生産性の低下を招く要因となっています。
「AIにこのコードを解説させたい」——現場からそんな切実なニーズが上がるのは必然と言えるでしょう。生成AIを活用し、複雑な関数を要約したり、テストコードを自動生成したりできれば、開発効率は劇的に改善するはずです。しかし、前述のセキュリティ要件が巨大な壁として立ちはだかります。
「隠れAI利用（Shadow AI）」のリスク顕在化
公式に安全なAIツールが提供されない状況下では、組織にとって最も恐ろしいリスクが顕在化しやすくなります。いわゆる「Shadow AI（隠れAI利用）」の問題です。
厳しいセキュリティ監視下であっても、以下のようなケースが報告されることは珍しくありません。エンジニアが、VDI画面上に表示された機密性の高いソースコードを目視で確認しながら、手元の私物スマートフォンでChatGPTなどのクラウド型生成AIサービスに入力してしまうのです。
エンジニアに悪意があるケースは稀です。ただ純粋に、最新のAIモデルが提供する高度なコーディング能力や推論能力を活用し、「この難解なコードを一瞬で理解したい」という効率化への焦りが招く行動と言えます。特に最新モデルではプログラミングスキルが飛躍的に向上しており、その利便性は抗いがたいものがあります。
しかし、これはセキュリティの観点からは致命的です。一般的なクラウド型AIサービスの無料版や個人向けプランでは、入力されたデータがAIモデルの学習に再利用される可能性があります。もしそのコードの中に、ハードコーディングされた認証キーや、顧客ID、口座番号などの機密情報が含まれていたらどうなるでしょうか。
世界中のユーザーが利用するAIモデルを通じて、自社の機密情報が予期せぬ形で漏洩する——これは厳格な管理が求められる企業にとって、決して許容できないシナリオです。
「単に禁止するだけでは、隠れて使う流れは止められない」。そう認識した上で、エンジニアの利便性と厳格なセキュリティを両立させる、安全な代替手段の構築を検討する必要があります。
2. 選定フェーズ：メジャーなSaaS型AIが不採用になった理由
比較検討した4つの選択肢
導入検討の現場では、市場で主要な以下の4つの選択肢が慎重に比較検討されることが一般的です。
- GitHub Copilot Business / Enterprise:
業界のデファクトスタンダードです。最新版ではOpenAIやAnthropic、Google等の多様なAIモデルから用途に合わせて選択可能になるなど、機能拡張が続いています。 - Tabnine Enterprise:
オンプレミス環境やVPC内へのデプロイに対応しており、セキュリティ重視の企業で採用実績があります。 - Amazon Q Developer (旧 CodeWhisperer):
AWS環境との親和性が高く、AWS上での開発において強力な支援機能を提供します。 - Continue (OSS) + Local LLM:
IDEの拡張機能として動作し、接続先を自社でホスティングするLLM（ローカルLLM）に自由に設定できるオープンソースソリューションです。
セキュリティチェックシートでの脱落ポイント
機能面だけで見れば、GitHub Copilotは非常に強力です。最新のアップデートにより、コンテキスト理解の精度やIDEとの統合（Adaptive Paste機能など）が飛躍的に向上しています。しかし、厳格なセキュリティ基準に照らし合わせた結果、採用が見送られるケースが多々あります。
最大の障壁となるのは、「データレジデンシー（データの所在）」と「推論時の通信経路」です。
Copilotのビジネス向けプランには「コードスニペットを学習データとして使用しない」という設定が存在します。しかし、法務・セキュリティ部門の見解としては、これだけでは不十分と判断されることが少なくありません。
「たとえ学習に使われない設定であっても、推論（コード補完の生成）を行うためには、コードの断片を外部サーバーへ送信する必要がある。暗号化されているとはいえ、社外のサーバーで処理が行われる以上、メモリ上にデータが展開される瞬間があり、これは『社外への持ち出し』に該当する」という論理です。
Amazon Q Developerについても同様で、パブリックなエンドポイントへデータを送信するSaaS型のアーキテクチャである以上、「完全閉域網内での完結」という要件を満たすことは困難です。
「学習データへの流用なし」だけでは不十分だった理由
もう一つの決定的な要因は、監査ログの完全性と自社管理です。
SaaS型ツールの場合、ログの仕様や保存期間はベンダーのポリシーに依存します。エンタープライズ環境で求められるのは、以下のレベルの透明性とコントロールです。
- 完全なプロンプトとレスポンスの記録: 「いつ、誰が、どのコードに対して、どんな指示を出し、AIが何を返したか」の全文記録。
- リアルタイム監視: ログを自社のSIEM（Splunk等）へ即時に取り込み、機密情報の入力などをリアルタイムで検知すること。
- 仕様変更の影響を受けない自律性: ベンダー側の都合でログフォーマットや保存期間が変更されないこと。
SaaSのAPI経由でのログ取得では、タイムラグが発生したり、将来的に取得項目が制限されたりするリスクを排除できません。特に規制産業では、「ベンダーのログ保存期間が終了したため確認できない」という事態は許されません。
結果として、データが自社の管理下から一切外に出ない「完全オンプレミス（または自社VPC内）」での運用が可能であり、かつログの取得・管理も自社で完全にコントロールできるOSS「Continue」と自社ホスティングLLMの組み合わせが、有力な解決策として浮上します。
3. 解決策の決定：OSS拡張機能「Continue」×社内ホスティングLLM
なぜ「Continue」だったのか：ベンダーロックインの回避
「Continue」は、VSCodeやJetBrainsのIDEに対応したオープンソースのAIコーディング拡張機能です。このツールの最大の特徴は、接続先のLLMを自由に構成できる点にあります。
商用APIだけでなく、Ollama、Llama.cpp、vLLM、Text Generation Inference (TGI) といったローカル/セルフホスト型の推論サーバーともシームレスに接続できます。
セキュリティ要件の厳しい組織において、導入の決め手となるのは主に以下の3点です。
- 通信経路の透明性: OSSであるため、コードの中身を確認でき、意図しないサーバーへの通信が発生していないことを検証できる。
- プロバイダの柔軟性: LlamaモデルやQwenシリーズといったように、バックエンドのモデルをベンダーに依存せず自由に切り替えられる。
- 完全なログ制御: 拡張機能側の設定で、リクエスト送信前に独自の処理（フック）を挟むことができ、ログ収集やフィルタリングをクライアントサイドで実装できる。
アーキテクチャ図解：VSCodeから社内推論サーバへの接続
データ流出を防ぐための推奨システム構成例は以下の通りです。
- 開発者端末 (VDI): VSCodeに「Continue」拡張機能をインストール。
- API Gateway: 社内ネットワーク内に設置。認証・認可、レートリミット、ログ収集を一元管理。
- 推論クラスター (GPUサーバ): 社内データセンターの隔離されたゾーンに設置。NVIDIA A100 GPU等を搭載し、vLLMを用いてモデルをサービング。
この構成では、開発者がVSCodeでコード補完を求めた際、リクエストはインターネットに出ることなく、社内の専用線を通り、Gatewayを経由して推論サーバに届きます。レスポンスも同じ経路で戻るため、完全な閉域網内での運用が可能になります。
使用モデルの選定（CodeLlama vs StarCoder）
モデル選定においては、コストと精度のバランスが重要なプロジェクト課題となります。SaaS型のような超大規模モデルを自社で運用するには莫大なインフラコストがかかります。そこで、コーディングに特化した中規模モデルの活用が現実的な選択肢となります。
特に日本語の指示に対する理解度とコード生成能力を両立させるため、以下のようなモデルの併用が効果的です。
- チャット用: Qwenシリーズの最新モデルなど。多言語対応に優れ、日本語での指示出しにもスムーズに応答するモデルを選定します。
- コード補完（FIM）用: StarCoderシリーズ。高速なインフィル（途中挿入）が可能で、補完のレイテンシが低い特化型モデルが適しています。
これらをContinueのconfig.jsonで使い分ける設定を行うことで、チャットと補完それぞれの特性に合わせた最適なユーザー体験を実現できます。
参考リンク
4. 導入の壁と突破口：情報セキュリティ部をどう説得したか
PII（個人情報）フィルタリングの自社実装
技術的な構成が決まっても、セキュリティ部門の承認を得るプロセスが必要です。現場で最も懸念されるのは、「エンジニアが誤って顧客データをプロンプトに含めてしまう事故」です。
これに対する有効なアプローチとして、API Gateway層とContinueのプリプロセス層の2段階でPII（個人識別情報）フィルタリングを実装する手法があります。
具体的には、クレジットカード番号、電話番号、メールアドレス、マイナンバーなどのパターンにマッチする正規表現フィルターを稼働させます。もしプロンプト内にこれらのパターンが検出された場合、リクエストはAIに送信される前にブロックされ、警告が表示される仕組みです。
「AIが判断するのではなく、ルールベースで機械的に止める」という確実性が、セキュリティ担当者を納得させる重要な要素となります。
監査ログの取得要件と実装方法
次に求められる要件が、「全対話履歴の永続保存」です。
Continueには標準でセッション履歴をローカルに保存する機能がありますが、これでは管理者が横断的に監査できません。そこで、API Gatewayにて全てのリクエストボディ（プロンプト）とレスポンスボディ（生成コード）をキャプチャし、非同期でログ基盤（Splunk等）へ転送する仕組みを構築することが推奨されます。
これにより、万が一情報漏洩の疑いが生じた際、特定のエンジニアがいつどんなコードを生成させたかを正確に追跡できる体制が整います。
利用ガイドラインの策定と誓約書プロセス
技術的な制御に加え、運用ルールの整備も不可欠です。
- 生成コードの検証義務: 「AIが生成したコードには脆弱性が含まれている可能性がある」という前提に立ち、人間がレビューし、既存の静的解析ツール（SonarQube等）を通すことを推奨します。
- 機密情報の入力禁止: フィルタリングはあるものの、固有名詞やプロジェクト固有の機密パラメータは入力しないよう注意喚起を行います。
利用希望者には、これらのガイドラインを理解したことを示す誓約書への署名を求め、署名済みユーザーのIDのみGatewayで許可するという運用を徹底することが効果的です。
5. 導入効果と現場の反応：安心安全なAI活用の実態
定量効果：定型コード記述時間の削減
導入後の現場からは、様々なフィードバックが寄せられる傾向にあります。
ローカルモデルでは、複雑な論理推論や、曖昧な指示からの意図汲み取り能力でSaaS版の大規模モデルに劣る場面があるのは事実です。
しかし、定型コードの生成や、単体テストの作成、エラーログの解説といったタスクでは十分な効果を発揮します。実際の計測でも、単体テスト記述やドキュメント作成にかかる時間が明確に削減されるケースが多く報告されています。
定性効果：若手エンジニアのコード理解度向上
また、若手エンジニアのスキルアップにつながる側面もあります。
Continueには「@Codebase」という機能があり、プロジェクト内のファイルをRAG（検索拡張生成）のソースとして活用できます。これにより、「このプロジェクトの共通エラーハンドリングはどう実装すべき？」といった、文脈依存の質問にもある程度答えられるようになり、コード理解のスピードが向上します。
予期せぬ効果：シャドーITの抑制と心理的安全性
「会社公認のAIがある」という安心感が得られることも大きな利点です。
この心理的安全性の向上は、自社構築を行う大きな意義と言えます。結果として、リスクを伴う個人的なAI利用（シャドーIT）の抑制にも直結します。
6. 担当者からの提言：エンタープライズAI導入の要諦
「完璧な精度」より「制御可能なリスク」を選ぶ勇気
エンタープライズにおけるAI導入は、単なる「機能の比較」ではなく「リスクの許容範囲の設計」であることが重要です。
セキュリティ要件の厳しい組織でAI導入を検討しているなら、機能比較表の「精度の高さ」だけでなく、それを使える状態にするための社内コストや運用負荷も総合的に評価する必要があります。
多少精度が落ちても、データフローが完全に可視化され、自社でリスクをコントロールできる「Continue + ローカルLLM」のような構成の方が、結果として早く現場に価値を届けられる可能性が高いと言えます。
スモールスタート時のパイロットチームの選び方
導入初期は全社展開せず、リテラシーの高い特定のチームに限定したスモールスタートを推奨します。新しい技術に寛容で、かつ生成されたコードの良し悪しを自分で判断できるエンジニア中心のチームから始めることが成功の鍵となります。
そうしたチームは、モデルの不出来な点も含めて建設的なフィードバックを提供し、プロンプトのコツを共に探求してくれます。最初にAIへの過度な期待を持つビジネス寄りのチームに展開してしまうと、評価が低くなるリスクがあるため注意が必要です。
今後の展望：独自モデルのファインチューニング
導入後の次のステップとして、社内のコード資産を使ってローカルモデルをファインチューニング（追加学習）するアプローチも有効です。社内固有のフレームワークや命名規則を学習させることで、汎用モデルが抱える精度の課題を克服し、よりプロジェクトに最適化されたAIアシスタントへと進化させることが期待できます。
まとめ
「ソースコードを外に出せない」という制約があっても、AI活用を諦める必要はありません。自社のガバナンス要件に合わせてアーキテクチャを設計することで、安全かつ効果的にAIを導入できます。
VSCode拡張機能「Continue」とローカルLLMの組み合わせは、セキュリティと利便性のバランスを取るための現実的で強力な選択肢となります。SaaSの導入を検討するだけでなく、コンテナの立ち上げとGPUの選定も視野に入れてみてはいかがでしょうか。
コメント