Github Copilotを全社導入した話

こんにちは。テクニカルディレクターのハリーです。

1→10では常日頃、様々な業務改善ツールを導入するための評価・検討をしていますが、つい最近 GitHub Copilot を全社エンジニアに導入し絶賛稼働中ということで、今回はこれをサンプルとして、生成系AIを基盤としたサービスやプラグインを導入していくにあたってどのようなプロセスを経たのかをその肝要なポイントとともにメモ的に残したいと思います。

まず、このようなツールを導入する目的は以下の2つ。

• AIツールに触れて活用することでトレンドの傾向を学び、予測に役立てる
• 管理・開発・デザインといった制作の生産性を高める

我々のような業務においては、まずその有用性を測る前に、新しいテクノロジーに対してどのくらいそれが「新しい概念をもたらし」、そしてそのテクノロジーと「フレンドリーになれるのか」を観測するという特徴があります。

その点、昨今においてGitHub Copilotはエンジニアにとって最も身近なAIとなりうるし、今後あらゆるエンジニアリングのスタイルにまで影響するという点で強い関心を持たざるを得ませんでした。

実際に触ってみると、よさそう！生産性間違いなくアガる！と直感。
機能要件を読んで触ればナルホドと、このツールを活用しないという選択肢はないのではないかと感じました。とはいえ、それだけで即導入ということにはならず、次のステップとして組織に対して以下4点のテーマを提言し議論しました。

• 品質
  • AIにプログラム書いてもらうなんてそれ信用できるの？
    
• 情報セキュリティ
  • 納品プログラムも学習データに使われるんじゃないの？それ情報漏洩？
    
• 著作権
  • AIに書いてもらったコードって著作権どうなるの？
  • 逆にAIに書いてもらったコードって誰かの著作権を侵害してるかもしれないんじゃないの？
    
• 費用対効果
  • 結局、作業効率は上がるの？
  • それによる費用対効果はあるの？

上記の議論に先んじて、社内にて導入ワーキンググループも発足。
まず短期の効果測定を目的とし、定量的な指針を立てた上で任意の先行導入メンバ（10名ほど）を選出、期間を設けて使用してもらった後にアンケートも実施。

だいぶ主観に寄った定量化ではありますが、そこはエンジニア同士の忌憚ない意見の出し合いという信頼値で有意性を出します。

では、先程挙げた4つの議題テーマについて順を追って紐解いていきましょう。

品質について

生成されたコードをまずは信用しないこと、というのはエンジニアとしては守っておきたいスタンスです。

されども、テキパキとコードを補完し、甲斐甲斐しく尽くしてくれているCopilot拝に対して徐々に当初のスタンスは薄れ、愛称なんか付けちゃっておまえがそういうならと、出されたコードを確認することなく採用することもあるかもしれませんね。

このような馴れの心理を想定した上で、「目視によるチェックと、コードの動作チェックは自分自身で行うこと」というルール設定と、ルール運用のためのアクションを検討します。

例えば月に一度程度の利用者による座談会の開催、特に小さな失敗談などを共有することや定期的なコードレビュー会の実施なども有効ですね。

そのようにして効率化を求めるあまり冗長的すぎるコードが増え、結果メンテナンスし難いプログラムになることを定期的なチェック・システムを設けることによって避けたいものです。

次に情報セキュリティです。

情報セキュリティについて

開発環境のコードの情報は、随時OpenAIのサーバーへ送信されていることには常に留意する必要はあるでしょう。 こういうと企業の執行役などは警戒レベルをぐっと上げるのが普通だと思います。そこで、送信された情報は「即時破棄」される旨が、プライバシーポリシーに記載されていることを提示します。

このように送信した情報はどこでどのように扱われるかを確認することが必要です。 また上記のような即時破棄が適用されるのはビジネス版に限っての要件で、他方で個人版は保持されることがあり製品開発や学術研究に使われるとあります。

よって少なくとも社内業務に関して個人版は絶対に使わないこと、が導入検討の審議中であってもまずアナウンスが必要となります。

この辺は企業がどういうところを気にするか、サービス提供元もわかっていると思われ、比較的わかりやすくポリシーが提示されているように思います。

https://docs.github.com/en/site-policy/privacy-policies/github-copilot-for-business-privacy-statement

また、マーケットに対して特定の日まで秘匿する必要がある情報を扱っているWebサイト開発、のようなプロジェクトの場合はどうでしょうか。例えばまだ世に出ていない新製品情報がテキストとしてソースコードに含まれる、とかですね。

この場合チーム内での共有を優先し、正しい理解の元、その扱いに関しては継続議論を促しますが、基本的には上記の通り即時破棄の条項で対応は明らかだとは思います。またクライアントからISMS(情報セキュリティマネジメントシステム)視点での見解を求められた場合にはGitHubが2022年5月にISO/IEC 27001:2013を取得している旨を伝えるのも理解の獲得に効果的かもしれません。

https://github.com/github/roadmap/issues/245

これらの事柄は、ことケースによって扱うセキュリティの性質が異なり議論は当然エンジニア間だけで輪転するわけでもないことを示しています。
プロジェクトに関わる全員が知っておかなければならないということを共有しましょう。

次に著作権です。

著作権とライセンスについて

この辺は解釈が中々はっきりしない領域であり、法的論争は世界中でリアルタイムに起こっているものと捉えています。
そのため、

• 参考1）GitHub、法的論争が続く中、Copilotをビジネス向けにリリース (2023年3月16日)
• 参考2）Microsoft、GitHub、OpenAIが「AIツールによる著作権侵害訴訟」の棄却を裁判所に要請 – GIGAZINE(2023年01月29日)
• 参考3）GitHub Copilot のセキュリティ・ライセンスに関する懸念の調査メモ

という動向もチェックした上で、150文字一致のパブリックコードが存在する候補は提案しないフィルターを有効にしています。 このポリシーは設定によって例外なく社全体のアカウントに適用されます。

最後に生産性について。

生産性について

効果測定とコスト算出から費用対効果を求める必要もありますが、GitHub Copilotサブスクリプションはエンジニア1人あたり月額19USDですので我々規模に当てはめると年間約85万円程度のコスト。

デジタルクリエイションのエンジニアリングにおいては単純な工数実績の値では比較したり測りきれないところもしばしばあり、しばらくは様々な視点から評価する必要があるということで、このあたりペイできるかどうかはもう少し運用を進めてみてということになりますが、前述の実施後アンケートにおいて、すべてのエンジニアが体感的に「作業効率が上がった」という回答を得られています。

以上のような内容を整理し、ワーキンググループ内でガイドラインとして策定した後に、2023年5月から全エンジニアへの配布、勉強会の実施をもって浸透というプロセスを経て施行完了としました。

ガイドラインとリファレンスによって、エンジニア個々人においては品質と情報セキュリティと著作権の扱いについて、自ら説明責任を果たせるようになること、組織においては要請されることを色々な角度から眺めてみて判断することが重要である。という結びで締めたいと思いますが、もう一点。

最後に

今後ますますLLMを基盤とする生成系AIサービス・ツール・プラグインは増え、我々のみならず様々な業種でワークフローを破壊的に変えてしまう可能性がありますし、日々何かしらの情報アップデートがある中で、これらのプロセスの鮮度は落ちて明日にも破棄されるものになるかもしれません。

そう言ってる間にも次々と新しいサービス、すなわち、
AmazonのAIコード支援サービス CodeWhispererであるとか、
エディター上だけではなく包括的な開発支援を行うGitHub Copilot Xであるとか、評価の要請が控えています。

これらを円滑に導入していくため、我々デジタル・クリエイションの現場においては、常に新しいテクノロジーをキャッチアップする感度を高め、是々非々ワークフローからプロジェクトをデザインする仲間を求めています。

応募は👇こちらから ！👇