![devlog [開発部門ブログ]](https://devlog.neton.co.jp/wp-content/uploads/2022/06/logo.png){kind=logo}
こんにちは。ネットオン開発Sec.リーダーのたけむらです。
今年に入ってからAIの話題が尽きませんね。
ネットオンではGitHub Copilotを導入しました。
前から気にはなっていたのですが、リスク報告があったりとなかなか声を上げられませんでした。
本エントリでは、導入までに検討した課題と、それらへの対策を紹介したいと思います。
導入を検討しているみなさまのご参考になればと思います。
目次
GitHub Copilot とはなにか？
GitHubが提供しているクラウド型人工知能ツールであり、プログラミングにまつわる各種作業を支援してくれます。コーディング時にAIがコードを提案する機能があり、開発者はよりコードを書くことに集中できるという優れものです。
GitHub Copilot 導入の目的
ネットオンでは少し前にTypeScriptを導入しました。これまではPHPでの開発が主で、まだTypeScriptに慣れていないメンバーもいますし、そのまた逆もしかりです。ユーザーへより多くの価値を素早く届ける体制作りを進める中で、コーディングの効率化と品質向上を目的としてGitHub Copilotの導入を検討しました。
導入する上での課題
GitHub Copilotを試験導入する上での課題として次の3点がありました。
- セキュリティリスク
- ライセンス侵害のリスク
- 費用対効果の測り方・本導入の判断基準
何かを利用したいと声を上げたとき、承認に至るまでに必ず乗り越えなければならないもの。現場の目線では最も頭が痛い部分ではないでしょうか。（ただ使ってみたいだけなのに！）
セキュリティリスク
一つは組織であれば必ずぶち当たる壁、自社のソースコードが学習データに利用されてしまい、情報漏洩につながることが懸念点としてあがりました。
また、AIが提案するコードをそのまま使ってしまうことにより、脆弱性のある実装になってしまうことも、どのように回避するのかを問われました。
ライセンス侵害のリスク
GitHub Copilotは、GitHub上のソースコードが学習データとして使われており、プログラム中の文脈を推論することによって提案が行われます。
この学習データが曲者で、パブリックリポジトリのコードをそのまま使ってしまうことにより、予期せぬ著作権侵害を引き起こしてしまうことも懸念として挙げられます。
費用対効果の測り方・本導入の判断基準
継続利用する場合、試験運用期間にパフォーマンスがあがったのかどうか根拠のあるレポートが必要でした。
幸いにも試験運用に関しては予算を確保してもらえ、「やってみたら？」ぐらいのノリで試せたのは嬉しい限りでした。
しかしながら、開発体験の向上が成果に繋がったかどうかを客観的に数字で証明するのが難しく、頭を抱えました。
当社は、開発環境を良くすれば効率も上がるだろうという暗黙知を比較的得られやすい文化があるので、アンケートを取ることにしました（というやり方で逃げることにしました）。
懸念がどうしても拭えないなら・・・
客観的な数値は、ルーティン作業の時間を削減できたなどの成果を謳うことが最も理解を得られやすいと思います。しかし開発作業はルーティンではありませんし、毎回やることが異なるため、単純な比較ができません。
そんな場合は後述するライセンス侵害のリスクを逆手に取るアプローチがいいのではないかと思います。
GitHub Copilot for Businessの利用
GitHub Copilot は、個人アカウント用とOrganizationアカウント用の２つが利用できます。
Copilot for Business を使用すると、Organization の GitHub Copilot へのアクセスを一元管理できます。
GitHub Copilot for Business について
Copilot for Businessを利用することで「テレメトリ」つまり自社のソースコードが学習データに利用されることを防止できます。また「パブリック コードに一致する候補をブロックする」機能により、ライセンス侵害を引き起こすような提案を低減できるでしょう。
GitHub for BusinessではOrganization全体にこれらの設定を制御できます。
脆弱性の混入や意図せぬライセンス侵害に関しては、GitHub Copilotを使うから発生するわけではなく、そもそもプログラマが自己の責任においてコードレビューやテストで品質を担保する意識を持つことが重要です。
それでもライセンス侵害を引き起こしてしまった場合、GitHub Copilotは第三者からの損害賠償に対して補償してくれるそうです。（上記設定を正しく設定していれば、ですが）
GitHub Copilot Product Specific Terms – 2023 06 20 – FINAL
General Terms December 2022 website
導入提案への根拠としてありがたい話ですね。
使ってみた振り返り
お待ちかねのレポートです。まずは、エンジニア全員での導入はせず、一部のエンジニアで試験導入した結果です。
Copilotの機能を利用していますか？
試験運用なのでその通りなのですが、全員が利用していると回答してくれました。
使ってみてどうですか？
入社して間もないメンバーもいたので、ソースコードの妥当性が判断できないという回答もありましたが、それはエンジニアとしてAIの提案を判断しようとしていることなのでとても良いと思いました。
基本的に肯定的な意見が多く、わざわざ調べる必要がなったことで開発の集中力が途切れないという点、ペアプロ相手として利用できそうだという意見がありました。
簡単な実装ならコメントを書くだけで代わりにプログラミングしてくれるため、業務ロジックに集中できるというのも実感として効率化が図れていそうです。
今後も使い続けたいと思いますか？
肯定的な意見とは裏腹に意外だったのですが、使いたくない、どっちでも良いよが一定数いたことです。理由を深掘りしていくと・・・。
理由を教えてください
使いこなせてないからという理由で費用面を気にしていただいている方、実装に慣れたら保管機能で乗り切れる猛者、補完機能が邪魔という理由でした。
補完のタイミングなどは設定で変更できますし、費用も気にせず使っていただきたかったりすると、やはりほぼ前向きな意見が多いように思いました。
便利だと思った機能は何ですか？
最後に便利だと思った機能については、はやりCopilot（副操縦士）というべきか、サジェスト、予測機能が優れているようですね。
現在どうしているか
これまでの結果を受けて、現在はエンジニア全員がGitHub Copilotを利用している状態です。今後はデザイナーさんのコーディングでも活用できると考え、予算確保に向かっています。
GitHub Copilotの今後
どんどん発展していくと思います。まだプレビュー版ですが、GitHub Copilot Xも発表されました。
プルリクの作成やCLI操作にもAIを利用でき、驚くような開発体験を提供し続けてくれると期待しています。
最近の発表で一番驚いたのは、code referencingという機能で、開発中のコードがパブリックリポジトリ上のコードと一致すると、教えてくれるようになります。
え・・・「ライセンス侵害の危険性があるから導入できない」という理由を払拭するために対応を考えたのに。
逆に「無意識にライセンス侵害しているかもしれないから、導入したほうが安心」という説明に切り替えできますね。これぞ逆転の発想・・・GitHubさんすごいですね。
code referencingがあれば懸念を安心に変てしまえるぐらいのインパクトがあるので、導入の提案がよりやりやすくなるのではないでしょうか。
それでは、よきAIライフを楽しんでいきましょう！
参考文献
GitHub Copilot 導入して1ヶ月経ったので振り返ってみた
調査：GitHub Copilotが開発者の生産性と満足度に与える影響を数値化
