https://tech.spacely.co.jp/entry/2026/03/04/113220

はじめに

こんにちは、株式会社Spacelyでバックエンドエンジニアをしているtoshichanappです。普段はRailsアプリケーションの運用・保守を担当しています。

Spacelyでは「Claude Code」を本格的に開発フローに導入しています。今年の2ヶ月間でマージされたtoshichanappのPRは119件です。 AI支援が特に威力を発揮したのは「やるべきだとわかっていたが後回しにしていた改善」でした。テストの高速化、Terraformの整理、管理画面の細かい改善、パフォーマンスチューニング、CI/CDの更新。いずれも緊急度は低いが重要度は高い、いわゆる「重要だが緊急でない」タスクです。

本記事では、AIの助けで実際に進んだ5つのテーマを具体的に紹介します。なお、本記事自体もClaude Codeに該当PRの内容を参照させながら執筆しています。

Claude Codeとの協働スタイル

Claude Codeは、Anthropic社が提供するターミナルベースのAIコーディングツールです。エディタのプラグインではなく、CLIとして動作します。ファイルの読み書き、シェルコマンドの実行、Gitの操作まで一通りの開発作業をAIが実行できます。

筆者が採用した基本ワークフローは以下の通りです。

人間が方針を決定 — CSからの要望、CIの計測データ、技術負債の棚卸し
AIがコードベースを分析 — 関連ファイルの検索、パターンの抽出
AIがドラフトを生成 — コード変更、テスト修正、コミットメッセージ作成
CodeRabbitが自動レビュー — PR作成時に不具合・改善点を事前検出
人間がレビュー・修正 — エッジケースの補完、ビジネスロジックの確認

基本的にClaude CodeのPlan Modeでまず実装方針を提示させ、内容を確認してから実装に進むようにしています。AIに丸投げするのではなく、「何をどう変えるか」のプランを人間が承認するステップを挟むことで、意図しない変更を防いでいます。

AIの最大の強みはパターン認識 × 大量ファイルへの一貫した適用です。「このパターンに該当する箇所を全ファイルから探して、すべて同じルールで書き換える」という作業は、人間が手作業でやると見落としやミスが避けられません。AIはコードベース全体をスキャンし、一貫したルールで機械的に適用できます。

一方で、方針の決定は常に人間が行います。「何を改善するか」「どの順序で進めるか」「どこまでやるか」はCIの計測データやCS（カスタマーサクセス）チームからの要望をもとに判断しています。AIは優秀な実行者ですが、目的地を決めるのはあくまで人間の仕事です。

レビュー体制: CodeRabbitの活用

AI支援でPR数が増えると、コードレビューがボトルネックになるリスクがあります。この課題に対して、AIコードレビューツール「CodeRabbit」を併用しています。

PRを作成するとCodeRabbitが自動でレビューを行い、ロジックの不整合や潜在的な不具合を指摘します。指摘内容を確認・修正した上でチームメンバーにレビューを依頼するため、人間のレビュアーは本質的な設計判断やビジネスロジックの確認に集中できます。

コード生成はClaude Code、レビューはCodeRabbitと、開発フローの複数段階にAIを組み込むことで、PR数が増加してもチーム全体のレビュー負荷を抑えられています。

テーマ1: Railsテスト高速化

テスト高速化は「やらなきゃ」と思いつつ後回しにしがちでした。数百ファイルのspecを手作業で分析・修正する工数を考えると、つい目の前の機能開発を優先してしまいます。

取り組んだのは、FactoryBotのcreateをbuild_stubbedに移行してDB書き込みを削減する作業、巨大なspecファイルのアクション別分割、CI上でランダムに失敗するFlakyテストの修正の3つです。いずれも数百ファイルを対象にした分析と修正が必要で、AIにコードベース全体をスキャンさせてパターンを洗い出すことで効率的に進められました。

PRの並列作業: サブエージェントとgit worktree

テスト高速化では、specの種類ごと（decorator、mailer、service、model等）にPRを分けて進めました。この際に活用したのがClaude Codeのサブエージェント（並列実行機能）とgit worktreeです。

git worktreeで作業ディレクトリを複数作成し、それぞれのworktreeでサブエージェントに別のPRの作業を並列で進めさせました。たとえば、decorator specのbuild_stubbed移行をあるworktreeで進めている間に、別のworktreeではmailer specの移行を同時に実行できます。PRごとに独立したブランチとディレクトリで作業するため、変更が競合する心配もありません。

この並列作業のおかげで、順番に1PRずつ作成する場合と比べて大幅に作業時間を短縮できました。テスト高速化のように「方針は同じだが対象ファイルが異なるPRを複数作る」タスクでは、サブエージェントとworktreeの組み合わせが効果的でした。

テーマ2: Terraformリファクタ + 不要リソース削除

Terraformの設定ファイルは「動いているから触らない」になりがちです。ハードコードされたARNは気になるけど直す優先度は低い。使われていないリソース定義も「消して大丈夫か」の確認が面倒で放置される。AIにコードベース全体をスキャンさせることで、こうした整理を一気に進めました。

取り組んだのは、Terraform設定内に散在するハードコードARN/リソースIDのdata source参照への置き換え、data sourceの依存解決を整理するlocals導入、そして役目を終えたリソース定義の削除です。

ハードコードARNの置き換えでは、環境ごとにIDが異なるためコピー&ペーストによる設定ミスのリスクがありました。data sourceで動的に参照する形に統一しています。

# Before: ハードコードされたARN
resource "aws_ecs_task_definition" "web" {
  execution_role_arn = "arn:aws:iam::123456789012:role/ecsTaskExecutionRole"
}

# After: data sourceで動的に参照
data "aws_iam_role" "ecs_task_execution" {
  name = "ecsTaskExecutionRole"
}

resource "aws_ecs_task_definition" "web" {
  execution_role_arn = data.aws_iam_role.ecs_task_execution.arn
}

不要リソースの削除では、MySQL 8.0移行後に残存していた5.7パラメータグループ、新機能に移行済みリソース定義（Lambda、IAMロール、EventBridgeルール等）を整理しました。いずれも.tfファイルからリソースブロックを消してterraform planで影響を確認するという手順自体は明確ですが、「本当に使われていないか」の確認が面倒で放置されがちでした。

Terraformの設定は宣言的で機械的なパターンが多く、AIによる一括検出・一括置換が効果的な領域でした。全ての.tfファイルをスキャンしてハードコードパターンを機械的に検出させ、不要リソースの削除では他リソースからの参照がないことをAIに確認させた上でterraform planで影響範囲を検証しています。

テーマ3: 管理画面大量改善

管理画面の改善も後回しになりがちでした。CSチームから「この画面で部分一致検索したい」「ここにリンクがほしい」といった要望は日々届きますが、一つ一つは小さい改善で、プロダクトの機能開発と比べると優先度が上がりにくい。結果として要望リストが溜まっていきます。

AIを活用することで、2ヶ月で31件のPRをマージし、溜まっていた要望を一気に消化しました。改善内容は検索条件の部分一致化、一覧画面のカラム追加やリンク化、ユーザー一括論理削除やCSVフォーマット指定といった新機能の追加など多岐にわたります。

ActiveAdminのDSLはパターンが明確で、AIとの相性が良い領域でした。全リソースに一貫して適用すべき変更をAIに任せ、CSからの個別要望に基づくカスタマイズは人間が方針を決めてAIに実装させるという分担で、31件のPRを効率的に作成できました。

なお、31件のPRの中にはマージ後にRevertしたものもあります。AIが生成した検索設定に誤りがあり本番で動作しなかったケースで、Revert→原因調査→再適用という流れで対処しました。大量のPRを効率的に出す流れの中でも、AIの出力は人間が書いたコードと同じレベルでレビューすることが重要です。

テーマ4: パフォーマンス改善

パフォーマンス改善も手が回っていませんでした。N+1クエリの存在は認識しているが、調査・修正・検証のサイクルに時間がかかる。バッチ処理の最適化は既存ロジックとの比較検証が必要で、慎重に進めざるを得ない。AIに調査と初期実装を任せることで、こうした改善を着実に進められました。

N+1クエリ修正

Datadog APMで遅いと把握していたエンドポイントのN+1クエリを修正しました。AIにコントローラからjbuilderテンプレート、モデルの関連定義までを横断的に分析させたところ、5箇所のN+1が特定されました。修正自体はincludesの追加ですが、ネストした関連まで含めてどの関連をeager loadすべきかを判断するにはビュー全体の走査が必要で、AIによる網羅的な分析が効果的でした。

レポートバッチ最適化

内部で利用状況レポートを生成する処理で、1社ずつSQLを発行する実装になっていました。企業数の増加に伴い処理時間が伸びており、バッチSQLで一括取得する方式への移行が必要でした。

しかし、レポート生成ロジックは複雑で、安易に書き換えると数値の不整合が発生するリスクがあります。そこでPlan Modeで移行方針を丁寧に詰めました。 AIに既存ロジックを分析させた上で、比較検証→切り替え→旧コード削除の3ステップに分割する計画を立てさせ、内容を確認してからPR単位の実装に進みました。

# Step 1: 比較検証用rakeタスク — 新旧の結果を並行実行し、差分を検出
namespace :company_report do
  task compare: :environment do
    Company.find_each do |company|
      old_result = CompanyReport.from_company(company)
      new_result = CompanyReportV2.from_company(company)
      if old_result != new_result
        puts "Mismatch: Company##{company.id}"
        puts diff(old_result, new_result)
      end
    end
  end
end

比較検証: 上記のようなrakeタスクで新旧の結果を突き合わせ、不一致箇所を洗い出し
切り替え: 不一致の原因を修正した上で、バッチ版実装に切り替え
旧コード削除: 旧実装を削除し、V2に統合。調査用のoneshot rakeタスクも削除

計画が明確だったおかげで、AIが各ステップをそれぞれ独立したPRとして実装・分割するところまで一貫して進めてくれました。不一致原因の調査でも、旧ロジックの暗黙的な条件分岐をAIに追跡させることで見落としがちなエッジケースを発見でき、移行全体をスムーズに完了できました。

いずれも、人間がDatadog APMで「どこが遅いか」を特定し、AIが「なぜ遅いか」のコード分析と修正ドラフトを担当するという分担がうまく機能しました。

テーマ5: CI/CD改善

CIの設定ファイルやビルドパイプラインの更新も「動いているから」と放置しがちでした。orbsのバージョンが古い、キャッシュ戦略が最適でない、セットアップスクリプトが非推奨のツールに依存しているなど、ビルド時間やCI安定性に直結する課題が溜まっていました。

具体的には、CircleCIのアセットキャッシュをブランチベースからコンテンツベースに変更してキャッシュヒット率を改善したほか、GitHub Actionsでは各環境で重複していたECSデプロイのReusable WorkflowをComposite Actionに統合しました。あわせて、CircleCI orbsの一括更新やMySQLセットアップアクションの移行も実施しています。

AIには既存のワークフローファイルを横断的に分析させ、重複パターンや非推奨設定を特定させました。特にComposite Action統合では、複数環境のワークフローの差分を分析させ、共通化可能な部分と環境固有の部分を切り分けるドラフトを生成させています。

AIと協働する上で学んだこと

方向性は人間が決め、実行速度はAIが加速する。「何を改善するか」はCIデータやCSの要望から人間が判断し、「どうやって一貫して適用するか」をAIに任せる。この分担がうまくいったとき、2ヶ月で119PRマージという結果に繋がりました。

「後回し」を片付ける力

2ヶ月の実践で最も実感したのは、AIが得意なのは「パターンの認識と大量適用」だということです。 ActiveAdminの検索プレディケート変更、FactoryBotのcreate → build_stubbed移行、TerraformのハードコードARN検出、CI設定の非推奨パターン検出。いずれも「明確なルールを多数のファイルに一貫して適用する」作業であり、AIの特性と完全に合致していました。

これらの改善が後回しになっていた理由は「面倒だから」に尽きます。1ファイルずつ確認し、1つずつPRを出す。その作業の繰り返しが人間にとっては億劫です。AIはその繰り返しを苦にしません。「やるべきだとわかっていた改善」に対する実行コストが劇的に下がった結果、2ヶ月で一気に片付けることができました。

80-90%正しいコードを生成 → 人間がエッジケースを補完

AIが生成するコードの精度は高いですが、完璧ではありません。体感では80-90%はそのまま使えますが、残り10-20%にエッジケースの考慮漏れやプロジェクト固有のビジネスロジックとの不整合があります。ゼロから書く場合と比較すれば、8割のドラフトが自動生成されるだけで生産性は大きく向上します。ただし、「AIが書いたから大丈夫」という油断は禁物で、通常のコードレビューと同等以上の注意を払う必要があります。 ActiveAdminの改善で発生したRevertは良い教訓になりました。AIが生成したRansackの検索パス設定に誤りがあり、本番環境で検索が動作しませんでした。大量のPRを効率的に出す流れの中で、つい確認が甘くなるリスクがあります。AIの出力も、人間が書いたコードと同じレベルでレビューする。 これは徹底すべき鉄則です。

Spacely では、Rails / Sidekiq を中心としたバックエンド開発、Terraform によるインフラ管理、AIツールを活用した開発効率の改善に取り組んでいます。今回の記事のような、技術的な課題を一つずつ改善していく仕事に興味がある方と、一緒により良いプロダクトを作っていけたら嬉しいです。

採用ページ