はじめに
この記事はNTTコムウェア Advent Calendar 2024 10日目の記事です。
自己紹介
NTTコムウェア コーポレート革新本部技術革新統括部の小西です。1年ぶりです。去年も弊社のアドベントカレンダーに参加しましてZabbix関連の記事を書きました(興味のある方はこちらからお願いします)。
最近は(も)色々とやっているのですが、仕事上のメイントピックはやはりタイトルの通りでGitHub Copilotの全社導入の任務に参画することになり邁進している...という辺りです。
プライベートの方は全くIT系とは毛色の違う話題ですが、バイクに熱を注いでいます。特に安全運転競技に注力していて、コーススラロームは大好物です。ようやく大会でも賞状もらえるくらいにはなってきたのでこれからも頑張っていきます。
ITエンジニアとバイクの親和性は高い...特に安全運転競技～モトジムカーナくらいの領域だと殊更に性に合う人が多いんじゃないのかなと思っています。何気に練習へ行くと一定数の同業者に会います(笑)
安全運転競技大会ITエンジニア部門...どうですかね。微妙か...。
(閑話休題)
この記事でお伝えしたいこと
今まさに
- GitHub Copilotの全社展開を仰せつかったものの横やりが多くて困った方
- GitHub Copilotを使ってみたいけど社内規則が厳しくてどうしたものかお悩みの方
- GitHub Copilotを会社に導入してやるぞと気合い入りまくりの方
に向けて、大体ツッコミが入るであろう「セキュリティは大丈夫なのか？」や「著作権は大丈夫なのか？」という懸念に対する1つの解をお伝えします。
GitHub Copilot全社導入の背景
無茶ぶりスタートの導入期
(導入期超初期には初日の記事の著者にも多大なる協力をいただいていることを勝手に宣伝します)
全社導入となる前にはすでに先行で一部の事業部においてトライアル利用がされている状況でした。そこで一定程度の効果が見込まれること、またNTTグループ全体としてAI活用を推進していくという方向性もはまって、全社導入に向けた検討を開始することになりました。
状況的には、色々なITベンダでLLM活用を推進した話題が流行っていたので(例えばこれ)、超特急で使えるようにしろというオーダーになり、実際検討開始から3ヶ月もかからず社内で利用開始となります。
他方で、この手のツールになるとガバナンス部門も黙っていないわけで、導入初期にはあの手この手でリスクアセスメントをしました。よし、やろうと言ってもなかなかそうはいかないのがやはり大きい組織です。
(無論、そういう営みがあってこそ安全な環境は成り立つので今となっては感謝していますがその当時は泣きながら「これも説明しなきゃいけないの！？」となってました(笑))
いずれにしても、こういう状況に直面する人は決して少なくなく、そういった障壁の結果断念したケースもあれば辛い社内調整の時期を乗り越えて導入となった例...様々な事例を聞きました。弊社の場合は「導入となった例」です。みんな頑張りました...。
弊社の状況
弊社に限らず、日本の大企業あるあるだと思いますが新しいツール、殊更クラウド利用することになるとやはり「ツンツン」されます。
- ソースコードは社外流出しないのか
- LLMを使うことで著作権侵害やOSSライセンス違反は発生しないのか
特に上記2点はどこでも必ず説明しないといけない話題になるかと思います。
Qiitaで情報収集をされるITエンジニア諸氏からするとビックリするかもしれませんが、弊社の場合だと仮にPrivateリポジトリであってもGitHub リポジトリの導入推進とはならずプライベートクラウドに構築したGitLabをリポジトリとして活用する前提もあります。
(この辺りは将来的にアップデートしたい領域かもしれません)
本題
ソースコードは社外流出しない、IDEで使うのであれば
おことわり
ソースコードが社外に保管される状況そのものを「リスク」として認識した話題であって、GitHub社に渡ることを必ずしもリスクと認識しているわけではない点、申し添えます。
GitHub Copilotを扱うとき、当然ソースコードをプロンプトに入力するシーンは多々あるかと思います(あるいは暗黙的に「入力されている」こともあるものです)。
そうしたときにそのソースコードはどこに送信されてどのように処理されるのかは必ず気になる話題かと思います(→詳細な話は後半に回します)。
まず、解になる根拠情報をポイントします。
- GitHub は Business および Enterprise ユーザーの Copilot データをどのくらいの期間保持しますか?
- チャットとコード補完のために IDE 経由でアクセスします
- プロンプトと提案: 保持されません
- ユーザーエンゲージメントデータ: 2 年間保存されます
- フィードバック データ: 本来の目的に必要な期間保存されます
- 他のすべての GitHub Copilot は以下にアクセスして使用します
- プロンプトと提案: 28 日間保持されます
- ユーザーエンゲージメントデータ: 2 年間保存されます
- フィードバック データ: 本来の目的に必要な期間保存されます
引用元:https://resources.github.com/ja/copilot-trust-center/
ここで重要なのは「プロンプトと提案」です。これがまさに「入力するソースコード」であり、「提案されるソースコード」です。
...としたときにいきなりタイトルの伏線を回収しますが「IDE経由でアクセス」のときには保持されない一方で、それ以外は28日間保持されると明記されています。
28日間の保持について理解が得られなそうなときのアクション
端的に言えばIDEからのみ使えるようにしてあげれば良いです。
Organizationのsettings⚙>Copilot>policiesから
- Copilot in github.com:Disabled
- Copilot Chat in the IDE:Enabled
- Copilot Chat in GitHub Mobile:Disabled
- Copilot in the CLI:Disabled
それぞれが何者なのか詳細な説明は省きますが、これで一旦は「IDEからの利用のみ」許容された状態になるので、このEnterpriseないしはOrganizationとして払い出されたGitHub Copilotを利用するときにはプロンプトと提案(≒ソースコード)が保持されない状態になったと説明がつきます。
その他
結局コードはどう取り扱われているのか
Copilot Chatを利用していると一定程度の過去の文脈を理解して会話できている印象を受けるはずです。その点で「結局保持しているタイミングがあるのでは？」と思われる方もいるかもしれませんが、そうではないです。
結論としてはプロンプトに過去のやり取りも載せて送っているので覚えているようにふるまっている恰好になっています。
下記のような環境で検証しました。
Fiddlerの説明は省略しますが、簡単にいえばリバースプロキシとして動作して暗号化通信の内容も復号して通信内容を確認できる便利なツールです。
チャット1回目
チャット1回目時点の通信内容
チャット2回目
チャット2回目時点の通信内容
...(ﾉ∀`)ｱﾁｬｰ。後半で出てくる話題の先取りしちゃったので3回目...
チャット3回目
チャット3回目の通信内容
ここから分かることは下記です。
- 毎回毎回のプロンプト送信ごとに下記も送信しています
- GitHub Copilotとしてやるべきことの定義や制約
- 今入力したプロンプト
- その前の話題のプロンプト
この処理の中でやり取りされる内容の保管については下記のような言及がされています。
- セキュアな送信と暗号化
- プロンプトは、GitHub の Azure テナントからレスポンスを返すために十分な時間のみ維持され、その後直ちに破棄されます。プロンプトが保存されることは一切ありません。すべての処理は一時的であり、メモリ内で実行されます
引用元:https://resources.github.com/ja/copilot-trust-center/
IDEに限定した場合に利用可能なIDE
2024年12月3日時点では下記のIDEが利用可能です。
- Vim/NeoVim
- Visual Studio Code
- Visual Studio
- Xcode
- JetBrains IDE
- Azure Data Studio
先日のGitHub Universe RecapではEclipse用も開発するって言ったような云々...
著作権侵害やOSSライセンス違反にはどう立ち向かうか
次の話題です。
LLM製品あるあるですが、結局のところ膨大な情報を学習させたのがLLMである以上「著作権は大丈夫なのか？」というのはしばしばツッコまれる話題かと思われます。
先に結論を述べると「一定程度の抑止はできる設定があるので活用する」「GitHub Copilotの動き方を冷静に考えて適切に使う」の2点が重要なポイントになります。
注意
今回取り上げる設定をすれば絶対に著作権侵害のリスクがないものではないです。その点で抑止するために設定して、検査やガバナンスルールは別途検討されることを推奨します。
制約事項
今回取り上げる設定は2024年12月3日現在、IDEではVisual Studio Codeにおいてのみ有効に機能します。
GitHub Copilotの機能
GitHub Copilotには「パブリックコードと一致するコードの提案をブロック」する機能があります。まずはそれを有効化して対策を取ります。
制約事項
パブリックコードの範囲はGitHub上のリポジトリに登録されているソースコードを根拠にします。その観点で、厳密に全てのケースでブロックする機能ではないです。
Organizationのsettings⚙>Copilot>policiesから
- Suggestions matching public code (duplication detection filter):Blocked
に設定します。
上記の設定をすると仮にパブリックコードに一致するサジェストが生成されたときには下記のような表示になり、ブロックされます。
パブリックコードフィルタは絶対ではない
前述の通り、パブリックコードフィルタはあくまでGitHubソースコードリポジトリ上の一致を検出する機能です。
その点で少しGitHub Copilotの動きについても検討します。
GitHub Copilotは世の中のコードを切り貼りしているわけではない
もらったプロンプトに対してそれっぽい一致のあるコードを引っ張ってきて貼り付ける...というような動きではないのです。
ざっくりですが下記の通り動作します。
コード提案を生成するために、Copilot 拡張機能はエディターでコードを調べることから始めます。カーソルの直前と直後の行に焦点を当てますが、エディターで開いている他のファイルや、関連するコンテキストを特定するためのリポジトリの URL やファイル パスなどの情報も含まれます。その情報は Copilot のモデルに送信され、次に何が起こる可能性が高いかを確率的に判断し、提案を生成します。
引用元:https://resources.github.com/ja/copilot-trust-center/
ちょっと何言っているのか難しいのでもう少しかみ砕くと...
GitHub Copilotは、エディターでコードを書くとき、カーソルの前後のコードや、プロジェクト全体の情報を参考にします。そのデータをCopilotのAIに送ると、「次にどういうコードが必要か」を予測して提案してくれる仕組みです。例えば、関数を書き始めたら、その続きを自動で補完してくれるようなイメージです。
ということになります。
ここで重要なのは...
エディターでコードを書くとき、カーソルの前後のコードや、プロジェクト全体の情報を参考にします
という部分になります。
一般的に、GitHub Copilot界隈(そんな言い方する？公式の中の人やらのこと)では隣接ファイルとか隣接タブとかって言い方をしますが、そのときに開いているファイルも実はGitHub Copilotは見ています。
その観点で、ワークディレクトリ(プロジェクトディレクトリ)に他社の著作コードがある場合には一定程度の侵害リスクはあるといえます。
あまりそのようなシチュエーションはないかもしれませんが、とはいえ、リスク認識をしておく必要はある前提で社内のガバナンスルールは整備しました。
いずれにしても、センシティブな案件などでは一致するコードの可能性を特定して評価するためのコードスキャンの導入をユーザーに推奨するものではあります。
補足：パブリックコードと一致しやすいシチュエーション
(1) コードエディタ内に Copilot のモデルが提案を合成するためのコンテキストがほとんどない、もしくは全くない、または (2) 一致する提案が一般的なアプローチやメソッドを表しているという 2 つの状況で高くなります
引用元:https://resources.github.com/ja/copilot-trust-center/
と述べられています。
まとめ
- IDEからの利用に限定すればコードが意図せず社外に保存されている状況を回避できる可能性が高い
- パブリックコードフィルタは絶対ではないものの活用することでリスクを低減できる
今後について
日々新しい機能もリリースされておりまして、キャッチアップで精一杯な面は否めません。とはいえ、全社的に導入を推進していくことでITエンジニアにとって働きやすい環境を作る一要素になれば良いなと思っています。
公式でも触れていますが
GitHub Copilot が開発者に取って代わることは期待していません。むしろ、GitHub Copilot が開発者と提携して開発者の機能を強化し、開発者の生産性を高め、手作業を減らし、興味深い作業に集中できるようにすることを期待しています
引用元:https://resources.github.com/ja/copilot-trust-center/
とあるように、こういったツールを導入することでITエンジニアの数を減らして開発費を安くするだけの目的で導入を推進しているわけではない点を強調しておきます。
その上で...実際、何に対してどれくらい役に立っているのか？の分析にも取り組んでいます。
Copilot Metrics APIを活用して利用状況の可視化を開始しました。来年のアドベントカレンダーまでには何かそれで話題が書ければ嬉しいなぁと思います...頑張ります。
現時点では、ありがちな「生成AIを導入した結果、生産性がn%(n=50だとか60だとか...)改善するので原価を安く...」のような話に安易に飛びつくのも、個人的な意見としては危険だと考えます。
薄っすらと見えてきている事実として生産性の向上率はプロジェクトの性質などに大きく依存します。
無論、効果測定をするために極度に最適化した条件下では50%60%...という数字が出ることもあるでしょうが、全てには当てはまらないはずです。そういった意味で「生成AIを導入すると70%も生産性が向上します！」というような不誠実なトークに飛びつかないだけで救われるITエンジニアが一定数いる...という点は併せて申し添えます(なんて硬い表現をしてみたものの、たぶん1度はそういう話題に直面して本当にみんな困っちゃいますよね(笑)実際、なくはない話で私も「参ったな」となってます)。
おわりに
導入初期で、まだまだこれからが本番かなと思います。とはいえ、実際に使ってみてこの数か月の中でもかなり精度や機能が改善されていることを肌で感じられています。さらなる活用を推進すべく、新機能のキャッチアップや分析は今後も継続して実施していきます。
また、効果を最大限に発揮させるためのドキュメントの整備(マニュアルではなくて、LLMツールが扱いやすい設計ドキュメントなどです)などの泥臭い活動が必要になる気がしています。そういった変革への第一歩でしかなく、ITエンジニアの本質的な仕事ってなにか？みたいな領域に踏み込んでいくことになるのかなぁ...と考えています。
同じようなミッションを推進している他企業の方々ともぜひ情報交換など実施していければ良いなと思っています。ぜひご連絡ください。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。