GitHub Copilot vs プライベートコーディングアシスタント

先月の間に、3つの異なるチームと同じ会話を繰り返してきた。どれも同じように始まった。誰かが4月24日のGitHub Copilotのポリシー更新を転送し、1年間静かだったSlackのスレッドが突然動き出した。まだCopilotを使い続けるべきか。移行すべきか。セルフホストすべきか。このカテゴリで「プライベート」とは何を意味するのか。

Doraです。数週間前に、ポリシー変更そのものについて書きました——何が変わったのか、誰が適用外なのか、チームが何を見直すべきか。今回の記事はその次の問いです。Copilotの設定を見直した後、ホスト型アシスタントを使い続けるか、プライベートまたはセルフホスト型に移行するかを、どう判断するか。どちらを選ぶべきかは言いません。私が観察してきたチームが使っている判断基準と、それぞれがどこで静かに崩れるかを整理します。

これはエンタープライズ向けの調達ガイドではありません。私はツールのユーザーであり、CISOではありません。しかし「ホスト型 vs プライベート」という問いは、もはや抽象的な話ではなく、開発者が毎週行うワークフローの意思決定に現れています。

今チームが検討している2つの方向性

現在2つの陣営がある。どちらも間違っていない。それぞれ異なるものを最適化している。

ポリシー制御でCopilotを使い続ける

最初の陣営は言う。Copilot BusinessあるいはCopilot Enterpriseはすでにデータの懸念に対処している。4月24日の変更が適用されるのは、個人プランであるCopilot Free、Pro、Pro+のみだ。GitHubのCopilotプランドキュメントによれば、GitHubはCopilot BusinessまたはCopilot Enterpriseのデータをモデルのトレーニングに使用しておらず、その契約上のコミットメントは4月24日以前から変わっていない。チームがBusinessまたはEnterpriseシートを使っているなら、ポリシー更新はデータのリスクを変えない。変わったのは、職場のラップトップで個人アカウントをどれだけ注意して使う必要があるかという点だ。

この陣営に有利な証拠が増えている。GitHubは最近、米国とEUのデータレジデンシーおよびFedRAMP認定モデルを提供開始し、管理者はCopilot設定からデータレジデント対応またはFedRAMP準拠のモデルに組織を制限できるようになった。「コードのトレーニングに使われているか」ではなく「推論はどこで行われているか」という懸念に対して有効だ。

論拠はシンプルだ。CopilotはIDEとの深い統合、最大のユーザーベース、強力なマルチファイルコンテキストを持っている。移行コストは現実のものだ。リスクが契約上対処されているなら、なぜスタックを壊す必要があるのか。

プライベートまたはセルフホスト型コーディングアシスタントへの移行

2番目の陣営は、契約を最終的な答えとして受け入れない。彼らの問いは構造的なものだ。Copilot Businessでさえ、推論はMicrosoftのインフラで実行され、モデルはサードパーティが運営し、データフローはまた更新される可能性のあるベンダーポリシーに支配されている。彼らの見方では、4月24日の変更は「ポリシーは変わる」という証拠だった。

そのためプライベートデプロイメントを見ている。いくつかの形がある。

ベンダー管理のプライベートデプロイメント — TabnineやCodeiumのようなアシスタントは、モデルを自社インフラ内で実行するVPC、オンプレミス、またはエアギャップデプロイメントを提供している。規制産業のエンタープライズ顧客のほとんどはこのパスを選ぶ。
セルフホスト型モデルと組み合わせたオープンソースアシスタント — 例えば、Continue.devにOllamaとコード特化のオープンウェイトモデルを組み合わせる。Continueは単一のAIプロバイダーに縛られておらず、自分のハードウェアで完全にローカルに動作するモデルをサポートしている。
エンタープライズプラットフォームを通じたBYOモデル設定 — アシスタントを自分のLLMエンドポイントに向けることができる。

ここでの仮説は「Copilotが悪い」ではない。「長期的なガバナンスの姿勢が、1つのベンダーの契約文言に依存すべきではない」というものだ。

本当の判断基準

ここが、私が見てきたほとんどのチームが行き詰まる部分だ。「ホスト型 vs プライベート」という会話を始めて、フレーミングが間違っていたために決断せずに終わる。実際の決断は2つの問いに宿っており、両方ともセキュリティの問いになる前にワークフローの問いだ。

データガバナンスとコンプライアンス

コードを2つではなく3つのバケツに分けよう。

ベンダーのトレーニングが真に問題にならないコード（オープンソースへの貢献、マーケティングサイトのコード、開発ツール）。
独自だが規制対象でないコード（内部ツール、ほとんどの企業でのほとんどのプロダクトコード）。
規制されたデータフローに触れるコード（金融、医療、防衛、公共部門——明示的なデータ取り扱いルールがあるもの全て）。

バケツ1はどのティアでも問題ない。バケツ3は4月24日以前からチームをエンタープライズ契約に向けて押し出していた。曖昧なのはバケツ2だ——そして、ほとんどのチームにとって最大のバケツがこれだ。

バケツ2の場合、問いは「契約上の適用除外で十分か」だ。最低限のバー：BusinessまたはEnterpriseティアを必須とし、AIの許容使用ポリシーにその要件を文書化する。プライベートデプロイメントにさらに進むかどうかは、監査人、法務チーム、またはエンタープライズ顧客が何を証明するよう求めるかによる。「Copilot Businessを使用しており、ここに契約条項があります」という答えがステークホルダーに受け入れられるなら、おそらく問題ない。「では推論はどこで行われていますか」と聞かれるなら、別の話になる。

開発者体験とメンテナンスコスト

これが「作るか買うか」の議論が通常スキップする部分だ。そしてこれが、決断が6ヶ月後も生き残るかどうかを決める部分だ。

ホスト型アシスタントはここで本当の優位性を持っている。Copilotはモデルを更新し、機能を提供し、開発者には見えないインフラの仕事を吸収する。ほとんどの開発者調査でAIツールの採用率は70%以上——そのほとんどのワークフローがホスト型ツールで動いているのは、ホスト型ツールが開発者の継続的な運用作業をゼロにするからだ。

セルフホスト型アシスタントはそれを逆転させる。Continue.devにOllamaとコード特化モデルを組み合わせたワークフローは、うまく機能するのを見てきた——しかしそれには、モデル選択、GPUやハードウェアの予算、バージョン更新、ローカルモデルとフロンティアホスト型モデルの能力差を担当する人がチームに必要だ。そのギャップは現実だ。ローカルモデルはかなりの距離を縮めてきた。複雑なマルチファイル推論では、ホスト型フロンティアモデルがまだ先を行っている。

ベンダー管理のプライベートデプロイメントはその間を取る。セルフホスティングのプライバシー姿勢と、ベンダーからの継続的なモデル更新の両方を得られる。コストは、より高いシート価格と初期のより多い調達作業だ。規制産業のチームにとって、それは多くの人が受け入れるトレードオフだ。非規制産業のチームにとっては、多くの場合その価値はない。

チームにオプションを比較するよう求められたとき、私が繰り返し戻ってくる5つの次元：

体感速度 — 実際にタイピングしたときに提案がどれだけ速く表示されるか
ワークフローとの適合性 — 既存のIDE、リポジトリ、レビュープロセスとどれだけうまく統合されるか
モデルカバレッジ vs. 選択コスト — モデル選択の自由があるか、そして選択が評価のオーバーヘッドを生むか
コストの予測可能性 — シートごとの固定費 vs. 使用量ベース vs. セルフホスト型インフラコスト
スケールでのパフォーマンス — 10人の開発者が同時にアクセスしたとき、またはコードベースが一定のサイズを超えたときに何が起きるか

ホスト型ツールはデフォルトで最初の3つで勝る。プライベートデプロイメントは使用量が安定していればコスト予測可能性で勝る。スケールでのパフォーマンスは、デプロイメントの設定方法に完全に依存する。

Copilotがまだ理にかなっているとき、そうでないとき

ここで、Copilotと私自身の限界について正直にならなければならない。

Copilotがまだ理にかなっているのは、チームがBusinessまたはEnterpriseティアを使用していてコードがバケツ1またはバケツ2に該当する場合、監査人や顧客が契約上のデータコミットメントを十分と受け入れる場合、開発者がGitHubエコシステムに深く統合されておりCopilotがリポジトリ、プルリクエスト、イシューから引き出すコンテキストが重要な場合、そしてモデルインフラを運用する人員や意欲がない場合だ。

Copilotが理にかなわなくなるのは、コードがバケツ3に該当し、コンプライアンスフレームワークが実証可能なデータ分離を要求する場合、エンタープライズ顧客がそのデータをサードパーティのAI推論に通さないよう契約上要求しており、コードがそのデータに触れる場合、またはすでに他の理由でプライベートモデルインフラに投資しており、その上にコーディングアシスタントを追加することがゼロからではなく増分的な作業である場合だ。

私が言わないのは、一方が未来であって他方はそうではないということだ。ほとんどの開発者は2〜3つのツールに落ち着く——よくあるスタックは、重いエージェント1つ、インライン補完ツール1つ、柔軟性のためのオープンソースオプション1つだ。チームレベルでは「ホスト型 vs プライベート」はますます偽りの二項対立になっている。異なるコードパスに対して異なるポリシーで両方のツールを運用しているチームも多い。

よくある質問

すべてのチームに今すぐプライベートコーディングアシスタントが必要か？

いいえ。4月24日のポリシー変更は個人向けCopilotプランに影響した。チームがBusinessまたはEnterpriseティアを使用しており、コードが規制カテゴリに入らないなら、契約上の適用除外は以前と同じだ。プライベートデプロイメントを真剣に評価すべきチームは、「監査人またはエンタープライズ顧客が何を要求するか」という問いへの答えがすでに契約文言を超えて進んでいるチームだ。

セルフホスティングのトレードオフは何か？

3つの現実がある。モデル品質——ローカルのオープンウェイトモデルは多くの差を縮めてきたが、複雑な推論ではフロンティアのホスト型モデルにまだ遅れている。運用コスト——誰かがインフラ、モデル選択、更新を担当しなければならない。ハードウェア——許容できる速度でのローカル推論には相応のGPUが必要だ。

メリットも現実だ：データの外部流出がゼロ、スケールでのコスト予測可能性、チームが使用するモデルへの完全な制御。

チームはガバナンスと速度をどう比較すべきか？

抽象的に比較しないこと。特定のコードパスに対して比較する。「開発者はマーケティングサイトのリポジトリでホスト型アシスタントを使えるか」は、「開発者は支払いサービスでホスト型アシスタントを使えるか」とは別の問いだ。私が見てきたほとんどのチームは差別化ポリシーに落ち着く——ほとんどのリポジトリでホスト型アシスタントを許可し、特定の機密リポジトリのリストにはプライベートデプロイメントまたはAIアシスタンスなし。単一ポリシーよりも設定が難しい。しかし、リスクがコードベース全体でどのように実際に分布しているかについて、より正直だ。

ツール選択の再評価を促すのは何か？

注目すべき3つのシグナルがある。データへのリスクに大きく影響するベンダーポリシーの変更——4月24日がその一つだった。新しいコンプライアンス義務——SOC 2監査、顧客契約条項、地域のデータ保護規則。チーム内部のワークフロー変更——エンジニアリングが開発者5人から25人になったとき、シートごとのホスト型価格 vs セルフホスト型インフラのコスト動態が逆転する。

これらのどれも起きていないなら、既存の決断はおそらくまだ有効だ。

まとめ

「GitHub Copilot vs プライベートコーディングアシスタント」への正直な答えは、1つの答えではないということだ。何かが変わるたびに再び問い直す問いだ——コード、顧客、ベンダーのポリシー、チームの規模。4月24日のポリシー変更は問いを緊急に感じさせた。ほとんどのチームにとって、そうではない。決断が最初から永続的ではなかったことを思い出させるものだ。

私はミックスを使い続けている。ほとんどの作業にはホスト型、自分のマシンから出したくないコードにはローカル型、顧客契約が要求する1つのチームのコンテキストではベンダー管理のプライベートデプロイメント。これは機能する設定であって、推奨ではない。コードのミックスが違ったり、異なる義務があったりするなら、あなたにとっての正解は違って見えるだろう。

私のデータはそこで終わる。自分自身の監査を実行してほしい。数週間前に書いたポリシーレビューは合理的な出発点だ。その後の決断はあなた次第だ。

続く。

以前の記事：