aws-sdk-go-v2への移行をClaude Codeで自動化する

はじめに

この記事は、Finatext Advent Calendar 2025 の15日目の記事です。

こんにちはFinatextでエンジニアをしているtoumakidoです。
この記事では、AWS SDK for Goのv1からv2へのバージョン移行をClaude Codeで自動化したことについて紹介します。

AWSは、プログラムからAWSリソースを操作するために、SDK(Software Development Kit)を提供しています。
このアナウンスにある通り、AWS SDK for Go (v1) は2025年7月31日でサポート終了になり、既存でv1を使っている箇所を、v2へ移行する必要があります。
Finatextでは、主要リポジトリの大半は移行が完了してますが、私はまだ残っていた、15個くらいのリポジトリの移行を担当することになりました。
当時ちょうどClaude Codeを使い始めたてで、Slash Command機能で、一発で移行を完了させる専用コマンドを作ってみたので、その過程を紹介したいと思います。

aws-sdk-go-v2で移行する主な項目

移行には色々な項目がありますが、抜粋して以下がメインの移行作業になります。

• コンテキスト伝播の実装

  • v2のメソッドでは第一引数にcontext.Contextを受け取るようになっているため、最初の呼び出し場所から、SDK操作関数までの呼び出しチェーンでcontextを伝搬させる必要があります。

• API呼び出しパターン

  • クライアント初期化方法、メソッドの引数の型や、書き方に変更があります。

• 型システム

  • Enumの使い方が変更されており、*string型で指定していたものが、各サービスのtypesパッケージのtypes.XxxType定数を使うようになります。

コマンド開発

まず最初は、Claude Codeに移行ガイドを読ませながら、雑にコマンドを作ってもらいました。
(モデルはClaude Sonnet 4.5を使用しています。)
そして別途、会話履歴からユーザーの指摘を抽出し、コマンドの内容と照らし合わせて、コマンドの改善案をIssueとして構造化するコマンドを作成しました。

そして以下のサイクルでコマンドの開発と移行実装を同時に進めていきました。

移行コマンド実行
↓
レビューしてClaude Codeに指摘して、修正してもらう
↓
改善点抽出コマンド実行
↓
コマンド改善
↓
繰り返し

これにより、コマンドの精度向上と、エッジケースの対応の追加を継続的にすることができ、5個くらいの移行を終わらせた後、指摘はほぼ不要になりました。
最初のうちは、非推奨の型を使ってしまうケースと、contextの伝播が不完全になるケースが多くあった印象です。
またcontextの問題は改善コマンドだけでは解決しなかったので、その部分は自分でAIと壁打ちしながら修正していきました。

完成したコマンドの概要

AIによる、コマンドの概要が以下です。

1. **移行対象の検出**
   - v1使用箇所をgrep検索
   - TodoWriteで移行計画を作成

2. **移行パターンの分析**
   - ファイルタイプ（handler/service/repository）の特定
   - コンテキスト伝播パターンの識別
   - サービス固有のパターン（Pagination、Enum型など）の検出

3. **コンテキスト伝播フローの設計**
   - コンテキスト初期化ポイントの特定
   - エントリポイントの特定
   - 完全な伝播チェーンのマッピング
   - Phase別タスクの明示的作成

4. **TOP-DOWN順での自動移行実行**
   - **Phase 1**: コンテキスト初期化（init/main/NewXxx）
   - **Phase 2**: コンテキスト受け取り（handler層）
   - **Phase 3**: コンテキスト伝播（Service/Execute*/Process*層）
   - **Phase 4**: コンテキスト伝播（Repository/Helper層）
   - **Phase 5**: 呼び出し箇所の更新と検証
   - 並行タスク: クライアント作成、Pagination、型更新など

5. **依存関係の更新**
   - v2パッケージの取得
   - `go mod tidy`実行
   - サブモジュール対応

6. **検証**
   - ビルド検証
   - コンテキストフロー検証
   - 不適切なコンテキスト使用の検出
   - AWS SDK呼び出し検証

7. **v1依存関係の残存確認**
   - `go mod why`/`go mod graph`で原因特定

8. **移行サマリーのレポート**

コマンドのソースはこちらです

• 移行コマンド
• 改善コマンド

これらは私が担当したリポジトリの移行作業が終わった段階でのコマンドです。
より大きなリポジトリや複雑なものに対しては、処理が多くなりコンテキストを圧迫してしまい、正常に処理されないこともあると思うので、またその都度、改善が必要になるかもしれません。
また効率性や並列実行などによる処理速度の向上など、パフォーマンスに関する改善の余地もまだまだあると思います。

課題

実際、この移行作業において、最も時間が取られるのは動作確認だと思います。
今回、移行対象になったリポジトリは、普段私が開発に関わらないものがほとんどでした。
そんなリポジトリでは、どこでどんな処理を行っているか、どんな外部依存があるのか把握するのはとても大変で、SDKを使った関数に行きつくまでに、外部のデータソース参照でエラーが起きたり、バリデーションに引っかかったりしてしまうことはとても多いです。
現在、データソース参照箇所をモックしたりして、動作確認をスムーズに行うためのコマンドを作っているのですが、精度が低く苦戦しています。

まとめ

AWS SDK for Goの移行専用のコマンドを作り、移行実装とコマンド改善を同時に行っていったことについて紹介しました。
このようにやるべきことがある程度決まっていて、その対象が多いというタスクへのアプローチとして、専用コマンドの作成は、AIによる作業効率化がとても発揮する場面だったなと思いました。
また、最初は簡単にコマンドを作成しつつ、実際にコマンドを使用しながら、改善していくサイクルも、AI初心者の私にとても合っていたと思いました。