GitLab Self-Hostedで実現するコンフィデンシャルAI

開発者はAIコーディングエージェントを使いたがっています。しかしソースコードは規制対象の知的財産であり、外部のAIサービスには送れません。コンプライアンス部門からも、書面でそう伝えられています。よくある逃げ道は、自前のGPUクラスターを立てて自社でモデルを動かすことです。しかしそこには、品薄のハードウェアを買い、運用チームを抱え、それでもフロンティアモデルから数か月遅れ続けるという代償が伴います。結局何も手を打てないまま時間が過ぎ、1年前にAIを導入したチームとの差だけが開いていきます。

GitLab Duo Self-Hostedのモデルプロバイダーとして、Privatemode AIを利用できるようになりました。Privatemodeは最先端のモデルをコンフィデンシャルコンピューティング対応のハードウェア上で動かします。プロンプトもソースコードも生成結果も、推論の最中を含めてエンドツーエンドで暗号化されたままです。設定は、GitLab DuoのAIゲートウェイをPrivatemodeプロキシに向けるだけ。開発者が使えるDuoの機能は、ほかのモデルを使う場合と変わりません。違うのは一点、規制業界の組織にとって最も重要な点です。コードが暗号化された境界の外に出ることはなく、第三者がそれを読むこともできません。

規制業界のチームだけが手にできない生産性

AIによるコーディング支援は、すでに自動補完の域をはるかに超えています。GitLab Duo Agent Platformが担うのは、複数のステップにまたがる作業です。マージリクエストのレビュー、ファイルをまたいだリファクタリング、テストの生成と実行、CIジョブとしてのエージェントフローの実行など、その範囲は広がり続けています。これはチームの開発の進め方そのものを変える変化であり、効果は使うほどに積み上がります。実際に導入したチームは、レビューが速くなり、定型作業にかける時間が減っています。

ただし、これらの機能はどれもプロンプトとソースコードをモデルプロバイダーに送ります。プロプライエタリなコード、規制対象のソフトウェア、機密性の高い知的財産を扱うチームにとっては、それだけで検討の対象から外れてしまいます。

規制業界の組織がセルフホストを選ぶ理由

こうした組織にとって、ソースコードは事業の中核をなす知的財産です。それをどこで処理するかは、利便性の問題ではなく、契約上・業界上・規制上の問題になります。銀行のトレーディングアルゴリズム、医療機器メーカーのファームウェア、防衛関連企業の制御ソフトウェア。これらを外部のAIサービスに送れば、知的財産の保護、データ処理契約、業界規則を一度に破りかねません。

しかも、圧力は複数の方向から同時にかかります。NIS2とデジタルオペレーショナルレジリエンス法（DORA）は、重要インフラと金融サービスに対して、運用のレジリエンスとサードパーティリスクの要求水準を引き上げました。GDPRは、コードやログに含まれる個人データの扱いを規定します。ドイツ金融業界におけるBaFinの監督、調達基準としてのBSI C5、医療データの規則など、業界ごとの制度も独自の制約を課します。加えて欧州では、特定の規制の有無にかかわらず、データ主権を最優先の要件と位置づける組織が少なくありません。

影響が最も大きいのは、金融サービス、ヘルスケア・製薬、防衛、公共部門、重要インフラです。GitLab Self-Hostedは、まさにこうしたコードを信頼された境界の内側にとどめるために存在しています。AIを組み込んだ結果その前提が知らないうちに崩れるようでは、本末転倒です。

なぜAIはセルフホストと相性が悪いのか

AIコーディング支援を導入したいセルフホストのチームには、従来3つの選択肢がありました。ただし、どれも規制業界のユーザーには支払いにくいコストを伴います。

表のとおり、パブリックAI SaaSとVPCはいずれもコードを外部に露出させ、契約上の保証に頼ることになります。自前でスタックを運用すればコードは手元に残りますが、GPUとモデル運用の負担が重くのしかかります。

もう少し率直に書きます。パブリックSaaSは、コードが社外に出る時点で検討対象外です。VPCで隔離したサービスやプライベートクラウドは露出を減らせますが、平文が運用事業者と基盤クラウドに渡ることは変わりません。契約は約束であって、暗号技術による保証ではないのです。自前でモデルを運用すればコードは守れますが、導入にも人材にもコストがかかり、構造的に最良のモデルから遅れていきます。こうして多くの規制業界の組織が、AIの導入を限定的にとどめるか、まったく手をつけないという結論に至ります。

ここで問われるのは、次の点です。ソースコードを境界の外に出さず、自社でLLMスタックも抱えずに、最新のAIコーディングエージェントを開発者に届けるにはどうすればいいのか。答えるには、契約では出せない種類の保証、つまりハードウェアが強制する保証が必要になります。

コンフィデンシャルコンピューティング：アーキテクチャによる答え

コンフィデンシャルコンピューティングは、ハードウェアベースの信頼実行環境（TEE）を使い、処理中のデータを_メモリ上で暗号化したまま_扱う技術です。TEEはCPUやGPU上に設けられた隔離領域で、OSもハイパーバイザーもマシンの運用者も、その中を読み取れません。ここで使われるのは、CPU側のAMD SEVまたはIntel TDXと、GPU側のNVIDIA Confidential Computingの組み合わせです。データは転送中も保存時もAES-256で暗号化され、復号されるのはTEEの_内側だけ_です。

これを「約束」から「保証」に変えるのがリモートアテステーションです。クライアントはデータを送る前に、TEEに対して自分が何者かを証明するよう求めます。ハードウェアは、エンクレーブの中で動いているコードが何であるかを示す、署名付きの暗号学的な証跡を返します。クライアントはそれを既知の正しい値と照合し、確認できてはじめて暗号化チャネルを張り、リクエストを送ります。まず検証、そのあとに送信、という順番です。

この図は、プロンプトがクライアント側で暗号化され、暗号文のまま送られ、サービス運用事業者にもクラウドプロバイダーにも読めないハードウェアTEEの中でだけ復号される流れを示しています。

ここから得られるセキュリティ特性が、この仕組みの核心です。AIサービスの運用事業者も、基盤となるクラウドプロバイダーも、プロンプトも生成結果もコンテキストも見られません。「見ないと約束しているから」ではなく、「ハードウェアが見せないから」です。

Privatemode AI

Privatemode AIを開発しているのは、コンフィデンシャルコンピューティングソフトウェアを専門とするドイツの企業Edgeless Systemsです。NVIDIAはPrivatemodeを「プロンプトを常に暗号化したまま扱う初の生成AIフレームワーク」と紹介しています。

開発者がこの仕組みを意識する場面はありません。PrivatemodeはOpenAI互換のAPIを提供し、アテステーションと暗号化はクライアント側のプロキシが裏側で処理します。標準の/v1 APIに対応したツールやSDKは、そのまま動きます。コーディング向けの現行フラッグシップは256Kコンテキストに対応したKimi K2.6で、Kimi K3やGLMなども近く追加される予定です。

これは実験段階の話ではありません。Privatemodeは、ここまで述べてきたような制約を抱える組織で、すでに本番運用されています。Capgeminiは機密性の高いコーディングを含む規制業界の案件で使い、ドイツ連邦雇用庁は公共部門で運用しています。銀行、保険会社、防衛関連組織も、ソースコードやデータを信頼された境界の外に出せない領域で採用しています。暗号方式はポスト量子安全で、「今のうちに集めて、あとで復号する（harvest now, decrypt later）」型の攻撃にも耐えます。将来のハードウェアで解読するつもりで今日の暗号文を盗んでも、攻撃者の手には何も残りません。

統合の仕組み

GitLab Duo Self-Hostedを使えば、GitLabが管理するゲートウェイではなく、自社が管理するモデルからDuoのAI機能を提供できます。Privatemodeは、その「自社が管理するモデル」として組み込まれます。

流れはシンプルです。GitLab DuoはセルフホストのAIゲートウェイと通信し、AIゲートウェイが推論をOpenAI互換のエンドポイントに転送します。そのエンドポイントの正体が、Privatemodeプロキシです。プロキシは標準の/v1 APIを公開し、Privatemodeサービスとのあいだで暗号化とアテステーションを担います。リクエストが届くと、プロキシはそれが自社ネットワークを出る前に暗号化し、アテステーションでリモートTEEを検証し、そのうえで転送します。復号が行われるのは、コンフィデンシャルコンピューティング環境の中だけです。Duo側では、コード提案、チャット、コードレビュー、エージェントフローのいずれも、開発者から見た使い勝手は変わりません。

sequenceDiagram
    autonumber
    actor Dev as 開発者 /<br>Duo Agent Platform
    participant GW as セルフホストのGitLab<br>AIゲートウェイ
    participant Proxy as Privatemode<br>プロキシ
    participant TEE as リモートTEE<br>(CPU + GPU)

    Dev->>GW: 推論リクエスト（コード提案、<br>チャット、コードレビュー、<br>エージェントフロー）
    GW->>Proxy: OpenAI互換<br>エンドポイントへ<br>リクエストを転送

    rect rgb(255, 244, 214)
        Note over Proxy,TEE: コードを送る前にアテステーションを実施
        Proxy->>TEE: アテステーション証跡を要求
        TEE-->>Proxy: エンクレーブのコードに対する署名付き証跡
        Proxy->>Proxy: 既知の正しい値と証跡を照合
        Proxy->>TEE: 暗号化チャネルを確立（AES-256、ポスト量子安全）
    end

    Proxy->>TEE: 暗号化したリクエストを転送
    Note over TEE: 復号と推論はエンクレーブ<br>の中だけで実行される
    TEE-->>Proxy: 暗号化されたレスポンス
    Proxy-->>GW: 暗号化されたレスポンス
    GW-->>Dev: 生成結果（開発者の<br>使い勝手は変わらない）

シーケンス図が示すのは、GitLab DuoのリクエストがセルフホストのAIゲートウェイからPrivatemodeプロキシに渡り、プロキシがリモートエンクレーブをアテステーションして暗号化チャネルを確立したうえで、信頼実行環境での推論にリクエストを回すまでの流れです。 AIゲートウェイとプロキシは自社で運用します。デプロイ方式は問いません（Linuxパッケージ、Docker、Kubernetesのいずれでも構いません）。手順はバージョンごとにドキュメント化されているので、ここで繰り返すのではなく、PrivatemodeのGitLab Duo統合ガイドをご覧ください。

トレードオフ

ただで手に入るアーキテクチャはありません。技術者の読者には、コストも正直にお伝えします。

ゲートウェイとプロキシは自社で運用します。 これは実際のインフラ作業です。適切なホスト名でAIゲートウェイをデプロイし、アップグレードのたびにイメージのバージョンをGitLabのリリースに合わせ、JWTキーと証明書を設定し、プロキシを到達可能な状態に保つ必要があります。とはいえ、これは通常のインフラ運用の範囲であって、GPUの調達でもモデル運用でもありません。この違いが重要です。コードを守るもう一つの選択肢である自前のLLMスタックは、品薄のGPUを買い、モデルの運用と更新を担うチームを抱え、それでもフロンティアに遅れ続けることを意味します。Privatemodeはホスト型SaaSとしてモデル運用を引き受けるため、手元に残る負担はプロキシとゲートウェイだけです。

汎用のOpenAI互換モデルは、GitLab Duo Self-Hostedではまだ成熟の途上です。 現時点ではベータ機能のため、モデル固有の問題へのサポートはまだ保証されていません。強化はロードマップに入っていますが、いますぐ完全にサポートされた構成が必要なら、そのタイムラインを展開計画に織り込んでください。

アテステーションと暗号化には、多少のオーバーヘッドが伴います。 追加のラウンドトリップと暗号処理のぶん、リクエストごとに時間がかかります。私たちのテストでは実用上の問題にはなっていませんが、統合ガイドでは応答の遅いセルフホストバックエンド向けにAIゲートウェイのタイムアウトを延ばすことを推奨しています。自社のレイテンシ要件に照らして、一度計測しておくと安心です。

信頼する対象はなくなりませんが、その範囲は狭まります。 この保証は、ハードウェアTEEとアテステーションチェーンが健全であることを前提にしています。「運用事業者が覗かないと信じる」よりもはるかに小さく、検証しやすい前提であり、アテステーションの証跡は自分の手で確かめられます。それでもゼロではありません。コンフィデンシャルコンピューティングは信頼の範囲をシリコンまで狭めますが、信頼そのものを消し去るわけではないのです。

実務にとっての意味

• 規制業界の組織にとって： 既存の知的財産保護・データ保護ポリシーを崩さずに、最新のAIコーディングエージェントを使えるようになります。コードはハードウェアで暗号化された境界の内側にとどまり、GPUの購入もモデル運用体制の構築も必要ありません。
• 開発者にとって： GitLab Duoの使い勝手はこれまでどおり、モデルは同等かそれ以上、新しく覚えるツールもありません。モデルの選択はインスタンス側で管理されるため、GitLab Workflow拡張機能を通じたエディタ内のチャットとコード提案も、同じコンフィデンシャルな構成をそのまま引き継ぎます。
• コンプライアンス・セキュリティチームにとって： このアーキテクチャは、コンフィデンシャルコンピューティングとリモートアテステーションへ向かうBSI C5:2026の方向性と合致します。NIS2、DORA、GDPRをめぐる議論には、「使用中のデータが暗号化されている」「実行がアテステーションされている」という具体的な技術的根拠を持ち込めます。もちろん、これだけでコンプライアンスが満たされるわけではありません。コンプライアンスは組織的かつ継続的な取り組みだからです。それでも、AI導入をそもそも止めている「自社のコードが境界の外に出てしまう」という反対理由は、これで取り除けます。

Privatemodeを使ってみる

PrivatemodeをGitLab Duoのセルフホストモデルプロバイダーとして使うには、GitLab Self-Managedのバージョン17.9以降（PremiumまたはUltimate）と、GitLab Duo Enterpriseアドオンが必要です。エージェントフローを使う場合は、さらにGitLab Duo Agent Platform（バージョン18.8以降で一般提供）が必要になります。利用時には、GitLabクレジットのドキュメントに記載されたBYOM（Bring Your Own Model）のルールと係数に従って、GitLabクレジットが消費されます。

さらに詳しく

• Privatemodeのドキュメント
• GitLab Duo統合ガイド
• コーディングアシスタントガイド
• Capgeminiの事例
• NVIDIAソリューションブリーフ