この記事は、Finatext Advent Calendar 2025 の12日目の記事です。
はじめに
はじめまして！Finatext の保険ドメインでフロントエンドエンジニアをやってます Stead といいます。
この記事では、保険ドメインが提供している SaaS 型保険システム Inspire の開発で、Claude Code Action を使ってテスト追加・リファクタの効率を上げた取り組みを紹介します。
Inspireとは
Inspire は SaaS 型デジタル保険システムで、以下のような特徴を備えています。
Inspire紹介ページ から抜粋します。
- 保険商品の新規販売を短期間かつ低コストで実現可能
- 保険加入体験を向上させる UI/UX
- API オープンな設計を活かし、既存システムや外部サービスと連携可能
- 金融サービスの基盤にふさわしい高いクラウドセキュリティ水準
この Inspire の裏側で、現在コアシステムの刷新が進んでいます。
コア刷新プロジェクトの背景
現在 Inspire では、コアシステムを刷新するプロジェクトが進行中です。
新しいコアシステムは、既存とは異なりモジュラーモノリスアーキテクチャを採用したアプリケーションです。
この移行にあたって検討したアーキテクチャなどの詳細は、以下の記事で紹介されています。
ここでは、その新コアシステム開発でのテスト実装を、Claude Code Action でどう補っているかにフォーカスしてご紹介します。
直面していた課題
保険ドメインでは、次のような開発を同時並行で行っています。
- 新しいコアシステムの開発
- 案件要求に合わせた個社領域の開発
- 既存コアシステムの改修・保守
この状況では、次のような問題が起きていました。
- 個別案件からの要望をコアに取り込む機能が増えると、納期優先になりがち
- その結果、テストコードの実装が後回しになりやすい
- 一方で既存システムの改修も頻繁に発生し、新コアに十分なリソースを割きづらい
新機能は増えていく一方で、ユニットテストのカバレッジが上がりづらい状態であり、特段大きな問題は発生していませんが何かしら改善は必要な状況でした。
アプローチ：リスクの低いテストを自動実装する
そこで考えたのが、
アプリの動作に影響を与える可能性が少ない単体テストを、自動で実装させる
というアプローチです。
- 本番の挙動を壊しにくい
- 時間が限られている中では開発者が手を付けづらい細かいテストの実装を機械的に進められる
- UT カバレッジを、少しずつでも確実に底上げできる
こうした観点から、Claude Code Action を使って週次の自動改善フローを組むことにしました。
自動改善フローの全体像
実装したフローは、以下のような構成です。
- 週次で GitHub Actions を cron 実行
- Claude がコードベースを分析し、改善タスクを洗い出す
- イシューを作成
- テスト追加などの改善を実装
- テスト、リント、フォーマットを実行し、問題なければ PR を作成
このフローを設計・運用するうえでの方針と工夫を順に書いていきます。
基本的な実装方針
スコープは「小さなタスク」に限定
- 原則として、テストコードの実装とコメント追加などの小さなタスクだけを対象にしています。
- マージ判断・レビューを容易にし、レビュー担当者の負担を増やさない意図があります。
複雑なタスクは人間がやる前提
- 複雑なリファクタリングや仕様に踏み込む変更は行わせません。
- そのような作業は、開発者がローカルで Sonnet / Opus を使って進めた方が効率が良いと判断しています。
- Claude 実装後に細かい変更を加えたい場合も、ローカルの Claude Code を使う方がやりやすいです。
運用面での工夫
gh コマンド実行権限を絞る
Claude が gh コマンド経由で何でもできてしまうのは怖いので、実行権限をかなり絞っています。
Edit,MultiEdit,Write,Read,Glob,Grep,LS,Bash(git:*),Bash(find:*),Bash(make:*),Bash(go:*),Bash(bun:*),Bash(npm:*),Bash(npx:*),Bash(gh issue comment:*),Bash(gh issue close:*)
- ファイル操作
- Git 操作
- テストやビルドに必要なコマンド
- イシューへのコメント・クローズ
など、必要なものだけを許可しています。
公式 example では gh:* が指定されていますが、権限が広すぎるため採用していません。
イシューを必ず紐づける
Claude Code Action で実装しきれなかった場合に備え、必ずイシューを作成するようにしています。
- 自動化で途中まで行ったタスクの残りを、開発者がローカルで引き継げる
- 「何をしようとしていたか」がイシューに残る
- タスクの可視化にもつながる
モデルは Haiku を採用
今回は Haiku を使っています。
- タスクの難易度を「テスト追加＋軽いリファクタ」程度に抑えている
- その範囲であれば Haiku でも期待する品質のコードが書ける
- Sonnet に比べてコストが安く、週次実行に向いている
もともとは Sonnet で検証していましたが、タスク設計を簡単めにしたことで Haiku に切り替えても問題なく運用できています。
将来的により複雑なリファクタリングも自動化したくなった場合は、Sonnet / Opus も検討しています。
テスト駆動 + スラッシュコマンドの再利用
プロジェクトリポジトリに カスタムスラッシュコマンド があったので、それを活用して TDD ベースの実装プロンプトを作りました。
prompt: |
/tdd-implement
## Context: Auto-Improvement Task
You are implementing an automated code improvement in the whiteberger repository as part of a GitHub Actions workflow.
## Improvement Specification
```json
${{ toJSON(matrix.improvement) }}
```
これにより、
- ローカルの Claude Code と同じスタイルで GitHub Actions 上でも実装できる
- プロンプトを二重管理せずに済む
というメリットがあります。
苦労したこと
権限設定
Claude Code Action を使うにあたり、GitHub Actions および Claude Code Action の権限設定で試行錯誤しました。
特に、
- どのブランチの
allowed_tools設定が参照されるのか - いつその設定が有効になるのか
といった点でハマりました。
以下の記事を参考にしつつ、一度デフォルトブランチに allowed_tools が設定されたワークフローをマージしておく必要がありそう、という結論に至りました。
コマンド実行失敗時にも「完了」扱いになる
テスト駆動開発を指示しているため、Claude は実装中に make コマンド等でテストや lint を走らせようとします。
しかし権限設定の問題などでコマンドが実行できない場合、次のようなエラーが出ます。
Claude requested permissions to use Hoge, but you haven't granted it yet."
この場合でも、Claude は別の手段でタスクをこなそうとし、最終的にテスト実行ができなかったにもかかわらず、タスクを completed として扱ってしまうことがありました。
ワークフローとしては、
- Claude の実装完了後に別ステップでテストを走らせる
- そこで失敗すれば PR は通らない
という構成にしているため、テスト未通過のままマージされることはありません。
ただし GitHub Actions 全体としては失敗ステータスになるので、運用上は少し扱いづらさが残っています。
まとめ
- 新旧コア・個社開発・既存改修が並行する中で、UT のカバレッジが後回しになりがちだった。
- そこで、アプリの挙動に影響しにくいテストや軽微なリファクタを、Claude Code Action で週次自動実装する仕組みを導入した。
- スコープを小さなタスクに限定し、gh 権限の絞り込み・イシュー作成・Haiku 採用・スラッシュコマンド再利用などで、安全かつ低コストな運用を意識している。
- 一方で、権限設定やコマンド実行失敗時の挙動など、まだ調整が必要なポイントもある。
「AI に全部任せる」のではなく、「人が後回しにしがちな小さな改善」を継続的に任せる形は、現場の負担をあまり増やさずに品質を底上げできる手段として手応えを感じています。
Discussion