投稿日
実践で学ぶGitHub Copilot:ユーザーインタビュー vol.2
もくじ
TISでは、生成AIを活用した開発を推進しており、その一環としてGitHub Copilotの利用を進めています。
本記事は「実践で学ぶGitHub Copilot」と題し、開発現場でのGitHub Copilotの活用方法について、ユーザーインタビュー形式でお届けします。第一弾はこちらです。
インタビュー
今回は、IT基盤技術企画部のインフラエンジニアである櫻井さんに以下の観点でお話を伺いしました。
- GitHub Copilotの利用方法
- GitHub Copilotの利用による効率の変化
- GitHub Copilotを最大限活用する方法
インタビューは、生成AI活用促進チームの宮下と山田が進行します。
サマリ
- GitHub Copilotの導入により、最大80%の作業時間が削減
- GitHub Copilotとインフラコーディング(IaC)の相性がいい
- アプリとインフラ領域問わずGitHub Copilotを利用することを推奨
インタビュースタート
GitHub Copilotの利用状況
山田:担当されている業務領域とGitHub Copilotの利用状況を教えてください。
櫻井さん(以下、櫻井):社内のWebサービスを提供するプロジェクトで、AWS基盤上に社員が利用するWebサイトを構築し、アプリ・インフラ両面での運用や保守開発を担当しています。
GitHub Copilotは部門全体で14名が利用しており、私は以下のシーンで利用しています。
- 基盤運用に必要な処理について、AWS LambdaをPythonでコーディングする
- Terratest¹を用いてテストを自動化する
- AWS CloudFormationやTerraformでインフラを実装する
- 課題が発生した際の対処方法などを相談して、アドバイスをもらう
| 項目 | 内容 |
| 主な担当業務 | アプリ・インフラ両面での運用や保守開発 |
| GitHub Copilotの主な利用用途 | AWS Lambda, Terratest, IaC²でインフラを実装, 課題に対してのアドバイスをもらう |
| GitHub Copilotの利用開始時期 | 2024/2~ |
| 利用者数 | 部門全体で14名 (2024.6月点) |
| 使用エディタ | Visual Studio Code |
| 作業時間の削減 | 実装者:最大80% 有識者:最大90% |
1. Terratest:インフラコードに対してテストを書くオープンソースの Go ライブラリであり、Go言語でのプログラミングが必要
2. IaC:Infrastructure as Codeの略称。ITインフラストラクチャをコードで管理・自動化する手法。例)AWS CloudFormation, Terraform
GitHub Copilotの利用によって効率が向上した具体的なエピソード
山田:GitHub Copilotを利用することで効率が向上したことを教えてください。
櫻井:「アプリケーションコーディングでの活用」「インフラコーディングでの活用」「課題解決」の3つに分けてお話しします。
アプリケーションコーディングでの活用
櫻井:私はインフラエンジニアで、シェルスクリプト以外のコーディング経験は新人研修以来ほとんどありません。しかし、今の時代はインフラエンジニアにもある程度のコーディングスキルが求められます。特に、AWS LambdaをPythonなどで書くことが当然とされています。
これまではAWS LambdaをPythonで実装する際、既存のコードを参考にしたり、インターネットで検索したり有識者に相談しながら対応していました。しかし、GitHub Copilotを使うようになってからは、コードの理解を深めながら正確かつスピーディーにコードを作成できるようになりました。
例えば、A関数とB関数内で同じようなコードが繰り返し書かれていたとき、これらを一つの関数にまとめることでコードの可読性と保守性が向上するという提案を受けました。他にも、各関数内で環境変数を取得する処理を一箇所にまとめるとコードの見通しが良くなると教えてくれました。
これらの提案のおかげで、コードの品質が向上しました。
また、昨年度はインフラテスト自動化においてTerratestを利用する機会があり、まったく触れたことのないGo言語でコーディングをする必要がありました。初めて触れる言語にもかかわらず、GitHub Copilotを利用することでコード作成やテストはほぼ自分とGitHub Copilotだけでスムーズに行うことができました。GitHub Copilotがなければ対応できなかったか、有識者に多くの時間を割いてもらう必要があったと思います。
その結果、有識者にはアプリとしてスマートな書き方や課題があったときに相談する程度で済み、お互いの作業工数が削減されました。
インフラコーディングでの活用
櫻井:GitHub Copilotが文脈を読み取り、私がこれから書く内容を予測して提案してくれたことに驚きました。
特に印象的だったのは、TerraformでAWS CodePipelineのコーディングをしていた時です。パイプラインの最後に、処理が成功したか失敗したかを通知することは必須ではありませんが、一般的によく行われます。その際も通知処理を最後に記載するつもりでした。
通知処理より前の処理は全て書き終わって「さあ、これから通知処理を書こう」と思ったら、GitHub Copilotがメール通知の処理を自動で提案してくれました。さらにその提案された通知メッセージもこれまでの処理を意識したものになっており、実際にそれを利用しました。
また、AWS CloudFormationのコーディングでも、少し書き始めるだけで次のコードを提案してくれます。
その結果、作業が非常にスムーズになりました。以前は公式ドキュメントを見ながら項目や値を確認していましたが、現在はGitHub Copilotで全体を書き上げてから公式ドキュメントをチェックするようになりました。

山田:提案内容が期待値と異なる場合はどのように対応されていますか?
櫻井:もちろんすべてが期待通りとはいきません。期待値と異なる場合は、手動で提案内容を書き換えます。
書き換えた直後から、GitHub Copilotが変更内容に合わせてプロパティや値を提案してくれるのでとても便利です。
課題解決
櫻井:実現したいことをGitHub Copilot Chatに相談すると、自分では思いつかなかったアイディアをくれます。
例えば、冗長なファイル構成のコードを一つにまとめる提案が欲しいと伝えれば、具体的な方法を提示してくれます。
既存のコードを読み込んだ上での提案の為、修正もスムーズに行えました。³

実際に、ログファイルをGitHub Copilotに読み込ませて課題と調査項目を教えてもらったこともあります。抽象度の高い内容から具体的な内容まで幅広く教えてもらえるので便利です。


GitHub Copilotの導入による工数の変化
山田:GitHub Copilotの導入によって具体的な工数の変化はありますか?
櫻井:コーディングが苦手な私にとっては大きな変化がありました。
インフラ領域のコーディングでは25%~50%、未経験言語でのアプリ領域のコーディングでは60%~80%は削減されました。
それに伴って、有識者への確認や相談の工数も最大90%は削減されました。
生成AIとコーディングを組み合わせた勉強会
山田:先日、生成AIを利用した開発や実装の効率化について部内で勉強会を実施されたと伺いました。実施された背景や参加者の反応はどうでしたか?
櫻井:部門として「生成AIを知る・利用する」という雰囲気がありました。部内勉強会でテーマを募集したところ、「生成AI」が非常に人気でした。その中でも特に「生成AIを利用した開発や実装の効率化」に関心が集まりました。そこでワーキンググループを作り、各種ツールを試して結果を共有し、より良い使い方を模索しました。参加者のレベルは様々でしたが、「GitHub Copilotの使い方」を学び、実装の効率化に向けた勉強会が実現しました。
参加者の反応
櫻井:勉強会はオンラインで行い、開催中のチャットや質疑応答は盛り上がりました。勉強会後にアンケートを取ったところ「参考となる情報があった」と回答した方が75%でした。チャットやアンケートの一部回答は下記のとおりです。
- 単独作業に比べてコード作成速度が段違いですね
- 複数のファイルに分割されているもの全般を見て、とあるコードの変更(diff)が他に影響していないとかチェックしてくれると漏れを防げていいなと
- 一から作る手間が省けたり、問題点を洗い出せるなどの情報が参考になった
- 最初大枠を作るようなところだけでも効率が上げられそう

GitHub Copilotを最大限に活用するためのアドバイス
山田:これからGitHub Copilotを利用する方に向けてアドバイスをお願いします。
櫻井:まずは副操縦士(copilot)として使ってみる、ということが重要だと思います。
当然ですが、たまに間違ったことを言ってきますので、全部を信じず、自分でもチェックすることが必要です。
回答内容に違和感を抱いたらエビデンスとともに問いを投げかけることが必要です。
山田:GitHub Copilotを利用する上で気を付けていることはありますか?
櫻井:コードの基本的なところは押さえて、「間違っていそうだな」「なんか怪しいな?」と気づけるだけの知識や経験は必要かと思います。
また、セキュリティ上好ましくない情報はマスキング後に質問するなど利用する上での注意点もあります。
GitHub Copilotは非常に便利なツールですが、最終的には自分の判断が大切です。適切に活用することで、開発効率が大幅に向上しますので、ぜひ挑戦してみてください。
山田:レビュアーへのアドバイスはありますか?
櫻井:実際に有識者の方からいただいたアドバイスです。
「GitHub Copilotが生成するコードは機械的でややトリッキーで読み解くのに時間がかかる場合がありました。実装と同じくレビューでも自分なりの基準を持って対応することが大切だと感じます。」
レビュー時にもGitHub Copilotを有効活用できるようにしていきたいと考えています。
インタビューを終えて
インフラエンジニアと聞くと、コーディングをあまり連想しないかもしれませんが、GitHub Copilotを活用することで業務の幅が広がり、生産性が向上すると思いました。特にインフラコーディングで、GitHub Copilotの利用が効果的であることが明らかになりました。インフラエンジニアの皆さんも、GitHub Copilotの導入を検討してみてはいかがでしょうか。櫻井さん、インタビューへのご協力ありがとうございました。
3. GitHub Copilotのアイコンは、以下ライセンスに基づいて利用しています。↩︎
MIT License
Copyright ©2022 Iconduck
以下に定める条件に従い、本ソフトウェアおよび関連文書のファイル(以下「ソフトウェア」)の複製を取得するすべての人に対し、ソフトウェアを無制限に扱うことを無償で許可します。これには、ソフトウェアの複製を使用、複写、変更、結合、掲載、頒布、サブライセンス、および/または販売する権利、およびソフトウェアを提供する相手に同じことを許可する権利も無制限に含まれます。
上記の著作権表示および本許諾表示を、ソフトウェアのすべての複製または重要な部分に記載するものとします。
ソフトウェアは「現状のまま」で、明示であるか暗黙であるかを問わず、何らの保証もなく提供されます。ここでいう保証とは、商品性、特定の目的への適合性、および権利非侵害についての保証も含みますが、それに限定されるものではありません。 作者または著作権者は、契約行為、不法行為、またはそれ以外であろうと、ソフトウェアに起因または関連し、あるいはソフトウェアの使用またはその他の扱いによって生じる一切の請求、損害、その他の義務について何らの責任も負わないものとします。
