GitHub Copilot AgentにAWS SDKのバージョンアップを任せたらCI/CD環境整備の重要性を感じた話

こんにちは、かたいなかです。最近、GitHub Copilot Agent(Claude Sonnet 4)を使って、開発環境用DBを作成するためのスクリプトのAWS SDKのバージョンアップを行いました。

コードの修正は爆速で終わったのですが、動作確認待ちが長引いてしまい、なかなか本番適用できない状態が続いてしまいました。

その時の反省や気づきについてまとめます。

TL;DR

GitHub Copilot Agent(Claude Sonnet 4)を使って、本番DBをもとに個人情報をマスクしてステージングDBを作成するスクリプトのAWS SDKバージョンアップを任せたらいい感じにコードを修正してくれた
Pull Requestを作るところまではサクサクだったが、動作確認を行うのが大変だったため、リリースまでに時間がかかってしまった
動作確認やレビューが効率化された、人間もAIもボトルネックで詰まることなく開発できる環境が今後どんどん大事になるかも？

経緯

今回対象にするアプリケーションは、本番DBから個人情報をマスクしてステージングDBを作成するスクリプト(通称 マスキング )です。

本番AWSアカウントのRDSからスナップショットを取得し、スナップショットから立ち上げたDBで個人情報をマスクする処理を行い、ステージングDBと置き換えるというのが一連の処理の流れです。

このスクリプトは作られてから数年が経過して、RDSの操作に使用しているAWS SDKのバージョンが古くなっており、バージョンアップが行えていない状態でした。

GitHub CopilotのAIモデルとしてClaude Sonnet 4が使えるようになったされた頃、検証を兼ねて本番DBをもとに個人情報をマスクしてステージングDBを作成するスクリプトのAWS SDKバージョンアップ作業を任せてみました。すると、想像以上にいい感じにバージョンアップ作業を行ってくれました。

具体的には、以下のような指示を与えることで、ほぼすべての作業をCopilot Agentが行ってくれました。

プロンプト: AWS SDKのバージョンアップを行いたいので、必要作業をupgrade.mdに列挙して
一度コンテキストをリセット
プロンプト: upgrade.mdの内容に従ってGitHub Copilot AgentにAWS SDKのバージョンアップ作業を行って

「コードの変更をAIが爆速でやってくれた！最高！」と終われればよかったのですが、そうはなりませんでした。

動作確認が怖い…

このスクリプトは変更も少ないスクリプトのため、動作確認の仕組みを整えるのが後回しにされており、以下のように動作確認が大変面倒な状態になっていました。

テスト実行に失敗するとステージングDBがない状態になってしまう
実行に成功してもステージングDBに繋がらない時間が10分ほど発生する

そのため、動作確認するにはとてもハードルが高くなってしまっていました。

特に、AIにほぼすべての修正をお任せしたこともあり、失敗時にステージングDBがなくなってしまうことが恐く、実行をためらってしまいました。

結果的に、もともと急ぎで対応が必要なタイプのタスクではなかったこともあり、Pull Requestを作ったまま、動作確認するのが数週間先延ばしになってしまいました・・・

どうしたか

当該スクリプトをステージング環境に影響を与えずに動作確認が行えるように修正しました。

具体的には、処理の最後の既存のDBと置き換える処理を行わないモードを追加し、これを開発用の環境として動かすことにしました。

このスクリプトは、時刻を指定して動かしているのですが、開発用の環境ではArgo Workflowのコンソールから手動で起動することにしました。

その後、準備した環境で動作確認を行い、無事にリリースすることができました。

まとめと今回のことで感じたこと

GitHub Copilot Agent(Claude Sonnet 4)を使ってAWS SDKのバージョンアップ作業を任せることで、コードの修正作業を爆速で終えることができました。しかし、動作確認の仕組みが整っていなかったため、せっかく素早く行えたコードの変更をデプロイするのに時間がかかってしまいました。

今回は動作確認の方法が整っていなかったという基本的なところにつまづきがあったのですが、今回のことをもとに考えていくと、開発者体験の向上が行えるように開発基盤を整理することは、これから更に必要とされていくのではないかと感じます。

今までも開発人数が多くなってきた場合などで、動作確認用の環境などが取り合いになってしまい、動作確認待ちが発生してしまうことはよくありました。しかし、生成AIによるコーディングの効率化や自動化が進むと、少ない開発人数でもたくさんのPull Requestが上がってくる状態になることも考えられ、動作確認がボトルネックとなりやすくなってしまうかもしれません。

今後は、Pull Requestごとに独立して動作確認ができるプレビュー環境のような仕組みの重要性も上がってくるのかもしれませんね。

人間も生成AIも、ボトルネックで止まらずに気持ちよく開発できるCI/CD環境を作っていきたいところです。