金融事業会社における GitHub Copilot 導入の道のり（中巻/リスク編）

本稿はJCB Advent Calendar 2024の１２月５日の記事です。

アーキテクトチームの長沼です。

JDEPでは、開発にGitHub Copilot Business（以下、特段の記載ない場合は「Copilot」と省略）を導入しています。
この導入の取組について、2024年11月6日に行われた Microsoft Developer Dayで、「金融事業会社におけるGitHub Copilot導入の道のり - JCBのPoC〜活用」と題して登壇させていただきました。

発表内容は次の３部構成となっており、当日は時間の関係で十分に説明できなかった部分も含めて、それぞれ記事で振り返ろうと思います。興味持って頂けたら最後までお付き合いいただけると嬉しいです。

上巻/背景編： GitHub Copilotを導入するに至った背景
中巻/リスク編： GitHub Copilotを利用するうえでのリスク検討
下巻/効果編： GitHub Copilotの効果

前回の上巻に引き続き、本記事では中巻として、JDEPでGitHub Copilot導入に際して行ったリスク検討のうち、生成AIの文脈で議論されることが多い以下の点について紹介します。

正確性
機密情報
知的財産（自社知財保護・他者知財侵害）

なお引用の条項ほか引用文は、登壇時点（2024年11月）のものです。
本記事には規約・約款など契約に関する記述が含まれますが、法的な解釈や契約の適用を保証するものではありません。また契約・購入方法により、必ずしも本記事記載の内容が適用されるとは限りません。
Copilot導入にあたっては必ず最新の契約内容や条件を確認してください。

正確性

生成AIについて一般に言われることですが、ハルシネーションや学習情報が古い等の理由から、生成AIによる提案は必ずしも正しいとは限りません。コードの提案においては、例えば処理に対する関数の提案は合っているものの、中に入れる変数の一部に誤りが含まれる、といったことも珍しくありません。
生成AIの利用においては、こうした正確性に対するリスクに備える必要があります。

しかし誤りが含まれるという点に注目してみれば、生成AIの提案も人による開発も誤りの可能性があるという点では変わりません。
そしてソフトウェア開発では、一般に開発したコードに対して誤り（バグ）があることを前提に多層チェックします。

JDEPの例で考えれば、Copilotの利用有無に関わらず、上図のように少なくとも以下のタイミングでテストを行います。

開発者がコード開発時に実装が正しいかの確認やコミット前のテストを実行します。
コードレポジトリにコミットされたあと、コミットやマージに合わせたCIによるテストや有識者による承認レビューを行います。
検証環境にデプロイされたあと、スプリントレビューやシステムテスト（ST）・ユーザアクセプタンステスト（UAT）等により、より上位すなわち要件通りに実装されているか確認します。

よって生成AIによる誤り混入（正確性）に対するリスクは、そもそもソフトウェア開発では誤りがあることを前提にチェックする仕組みができていることから、前提となる要件や設計が正しく実施されていれば、利用によるリスクは低いと考えます。

機密情報

次に機密情報に対するリスク、すなわち入力された情報が直接的または再学習により間接的に外部に漏洩するリスクもあります。この点については、JDEPのシステム構成による対策と、Copilotの仕様により、リスクを低減できると考えます。

JDEPのシステム構成による対策

JDEPでは、業務情報や個人情報を取り扱う本番環境と、これらの情報が存在しない開発環境を分離しています。
このため開発環境から直接本番環境にアクセスはできず、高機密な情報がCopilotを経由して流出する可能性はありません。

一方で、開発環境でも当然アプリケーション及びその他のコードや、場合によってはTokenやSecretを取り扱うこともあります。このため本対策のみで機密情報の漏洩リスクは十分でない可能性もあります。

GitHub Copilotの仕様

GitHub Copilot Businessの仕様として、以下のような記述（2024年11月時点）があり、送信経路上での暗号化と提案後に削除され提案以外で利用されないことが保証されます¹。

GitHub Copilotは、暗号化されたプロンプトをお客様からGitHubに送信して提案を行います。以下で詳述する場合を除き、プロンプトは、これらの提案をリアルタイムで生成するためにのみ送信され、提案が生成されると削除されるものとし、他の目的のためには使用されません。プロンプトは送信中に暗号化され、許可なく保存されません。

加えてCopilotでは、登壇時点（2024年11月）でPreview機能かつBusinessとEnterpriseプラン限定となりますが、Content Exclusionという機能があります。この機能により、ディレクトリ名やファイル名など条件に合致したファイルをCopilotのサーバ側へ送らないようにする設定を利用者側で行うこともできます。

こうした利用者側での対応とCopilotの仕様により、機密情報の取り扱いリスクも低減できると考えます。

知的財産

知的財産（自社知財保護と他者知財侵害）に対するリスクについても考える必要があります。

GitHub CopilotのTerms

この観点で、GitHub CopilotのTerms（該当部の抜粋を下図）を見てみます。

すると提案を含めたコードの所有と責任が利用者側にある、と読めます。
このため自社権利保護の観点はリスク低と整理できる²反面、他者権利侵害については引き続き利用者側で対応の必要があると分かります。

他者権利侵害の観点でTermsを読み進めると、緩和策としてフィルタ機能（Public Code除外）が推奨されています。
この機能を有効にすると、パブリックコードに一定長以上合致するような提案を除外できます。

加えてJDEPでは、EMU（Enterprise Managed Users）というクローズドな環境でGitHubを利用しています。
このEMU環境を利用することで、EMUに属する全Organizationに対してPublic Code除外の適用ポリシーを一元管理・制御できるため、管理側でガバナンスを効かせることもできます。

さらに読み進めると、契約方法（購入方法）によっては、第三者請求に対する防御を受けることができるともあります。

GitHub Copilot利用における他者知財侵害に対する課題

こうしたTermsや設定および第三者請求に対する防御があるから知的財産権のリスクも大丈夫…とは必ずしも言えません。
具体的には、以下のようなリスクは引き続き残ったままとなります。

仮に第三者請求に対する防御条項があったとしても、補償金額や範囲が明示されているわけではありません。
例えば仮にCopilotの提案を利用したアプリケーションが権利侵害で提供できなくなったとして、開発にかかった費用全額が補償されるとは限りません。さらに、これによって生じる会社（アプリケーション提供）側が被る機会損失により発生した損害まで補償されるかも分かりません。
また、そもそもCopilotが行った提案によるものであることを示すエビデンスや証明³も難しい可能性が考えられます。
Public Code除外機能でも、100%除外できるとは限らず、引き続き他者知財が混入するリスクは残り続けます。

このように考えていくと、どうしてもCopilotの利用は難しい、と結論になってしまいます。
しかし、Copilot（を含めた生成AI）は、詳しくは次の記事（下巻/効果編）でも触れますが高い開発効率化効果があり、また開発者体験としても多くの場合に良い影響を与えます（開発者の福利厚生に繋がります）。
よって「Copilotは使えない」ではなく、「使う」ための対応を検討すべきと考えます。この考えに基づいてJDEPで行った対応を次節で紹介します。

【補足】他者権利侵害に対する課題

他者知財侵害に対する課題は、理想的にはもう一段階分解してそれぞれの課題に対策することが重要だと考えます。
Copilotを利用した開発において、他者知財の侵害は少なくとも以下２つのケースで発生します。

開発者自身が主体的に他者知財を侵害するケース
（例えば、GitHub上で公開される他者のソースコードのコピー＆ペーストや他者特許技術を実装し侵害するケース、意図的な指示によりCopilotに他者知財を提案させ侵害するケース）
生成AIにより提案されたコードを開発者が採用した結果、受動的に他者知財を侵害するケース
（例えば、生成AIのトレーニングデータに内包される他者知的財産が提案され、採用することで意図せず侵害するケース）

前者は生成AI以前から発生している問題であり、本来は生成AI利用による問題とは切り離して考えるべき問題です。
一方で後者は、開発者自身が生成AIに内包される他者知財の把握が難しいと考えられることから、生成AI固有の問題と言えます。
よって生成AI以前からある対策のみでは後者の問題を解決することは難しく、少なくとも後者の問題への対応を考える必要があります。

JDEPにおける対応

他者知財侵害のリスクを低減しながらCopilotを利用するため、次の２つの取組を行いました。

リスクを評価し、低いところから使い始める（下図左側）
個々の開発者がリスクを理解し、適切に利用する（下図右側）

なお両取組とも、他者の知的財産を尊重し侵害しないことを前提としたうえで、それでも前述のように発生しうるリスクの管理・備えとして行うものです。他者知財の侵害を前提とした取組・検討ではありません。

リスク評価

JDEPのシステム構成に照らして各構成要素のリスクを評価し、リスクが低いところからCopilotを利用し始めることで、リスクを低減しつつ開発効率化も実現できると考えます。
また知的財産権は特許権・実用新案権、意匠権、著作権、など複数の権利で構成されるため、それぞれの権利の特性を踏まえてリスクを評価することも重要です。

例えば、上図左側に対して特許権について評価すると、次のように考えることができます。

Clientは、業務固有の処理（技術的な進歩性や新規性が含まれやすい処理）があり、また外部に公開され顕現性も高いため、Copilot利用に伴う知財侵害のリスクが最も高いと言えます。
Serverは、業務固有の処理は含まれるものの外部公開は限定的で稼働場所がクローズドな内部稼働のため、リスクはあるもののClientほどは高くないと言えます。
構築・運用スクリプトや設定ファイル等は、一般的な処理が多く固有な処理も含まれにくく、また顕現性も低いため比較的リスクが低いと言えます。
同じくテストケースも顕現性が低いことに加え、設計に対して作成するものであるため固有の処理が含まれる可能性は低く、同じくリスクが低いと言えます。

以上のような評価から、図中水色や次点で黄色に示した箇所はリスクが低く、Copilotが利用しやすいコンポーネントと見ることができます。
一方で赤色のコンポーネントはリスクが高く、より慎重な利用が求められます。

このようにリスクを評価し、利用しやすい場所から利用していくことで効率化や知見蓄積を行い、可能であれば適用範囲の拡大を検討していくことが良い導入と考えます。
なお、このほかの評価観点として、開発規模などアプリケーション毎にリスクを評価し、Copilotを利用するアプリケーションを検討する方法も選択肢の1つと考えます。いずれも適用対象の特性に応じて評価していくことになります。

開発者のリスク理解

ところで、これまで述べたリスク評価はあくまで管理・推進側によるものです。
真にリスクを低減するためには、より具体・現場に近いところ、すなわち開発者それぞれが知的財産の理解やリスクを理解し、実際の開発で意識することが重要と考えます。

これを実現すべくJDEPでは、上図右側のように開発チームごとに自チームでの開発に合わせた形で利用ルールを定める活動を推進しています。
このように開発チーム自らがルールをアウトプットし、見直し、ルールを自ら守っていき、管理推進側と開発利用側がお互いに理解・協力して生成AIを利用していくことが、こうした技術の導入には重要と考えます。

おわりに

今回は、JDEPで行ったGitHub Copilotのリスクに関する検討の内容を紹介しました。
これまで述べたような評価検討・取組を通し、許容できる範囲までリスクを低減しつつ、Copilotを活用していくことが重要と考えます。
このリスク評価も踏まえて行った効果評価について、次の記事（下巻/効果編）で紹介していきますので、本記事に興味もって頂けたらそちらもご一読ください。

最後となりましたが、JCBでは我々と一緒に働きたいという人材を募集しています。詳しい募集要項等については採用ページをご覧下さい。

本文および図表中では、「™」、「®」を明記しておりません。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。