はじめに
お久しぶりです！レセプトの開発マネージャのMasakiです。
前回（Cline + GitHub Copilot編）の続きです。背景と対象読者層は以下をご覧ください。
今回は、大規模開発プロジェクトの中盤における「複雑なビジネスロジックの大規模実装」と「小〜中規模の改修」を、Claude Codeを中心にどう進めたかを振り返ります。
この記事で伝えたいこと
- 大規模・複雑なロジックの完全自走は難しい（2025年5月当時）：コンテキスト量と難易度のバランス見極めが重要
- AIは設計の壁打ちと局所的リファクタに寄せる：大規模・複雑なロジックでは人間中心でコーディング、Claude Codeは特定メソッドの抽出・改善が無難
- 小～中規模の既存改修は“良いコンテキストの渡し方”が肝：設計を整え、必要最小限の情報を渡せば実装まで一気に進む
- 人間の理解は前提：業務ドメイン理解・現行システム理解・あるべき設計の知識が不可欠
-
Claude Code GitHub Actionsはレビュー特化が吉：
CLAUDE.md基準のレビューやプロンプト工夫で人間のレビューを効率化（Copilotレビューとの差別化）
ClineからClaude Codeへ乗り換えた背景
2025年5月当時、MaxプランでClaude Codeが定額利用可能になり話題に。Claude Sonnet 4.0 / Claude Opus 4.0の登場で、Claude Codeも一般公開となり、性能向上とともに注目度が高まりました。このタイミングでClineからClaude Codeへ切り替え、実務活用を模索しました。
タスク1：最も複雑なビジネスロジックの大規模改修
RehabCloudレセプトの根幹ともいえる、請求書の作成ロジックについて、既存の処理方式に1つ新たな処理方式を加えるという改修を行う必要がありました。
以下のリンクの計算方式を１本実装することに近いです。
これだけ聞くとそれほどでもなさそうですが、すべて新規実装ではなく、既存のプロダクトに対しての改修であるため、具体的には全体だと50ファイルほどに影響、新規実装や改修含めて実装だけでも1ヶ月ほどはかかると見込まれていた作業でした。
課題に対するアプローチ
フェーズごと開発フロー
既存のソースコードを調査
計画セッション用に既存ソースコードのエントリーポイントを伝えて、関連する機能のコードを読み込ませて、既存仕様をマークダウンファイルで出力しました。
計画
既存仕様のマークダウンファイル、および今回の変更点やサンプルコードをコンテキストとして渡して、TOBEを仕様書のマークダウンファイルとして出力しました。
ただ、出力した仕様書のマークダウンファイルは、8ファイル分相当となり、かなり膨大でした。
実装
まず愚直に8ファイル分のマークダウン仕様を渡して実装を依頼しましたが、期待していた品質が出ず、仕様の抜け漏れも目立ちました。
Claude Codeの完全自走は諦め、生成物はプロトタイプと割り切り、基本は自分で実装しつつ良い部分だけ取り込みました。
実装中は、暫定で書いたコードの関数抽出などのリファクタリングや、把握済み範囲のメソッド実装をClaude Codeへ依頼するなど、アシスタントとして活用。Devinも使えましたが、コーディングの相棒としてはローカルのターミナルにいるClaude Codeへ依頼する方が都合が良かったです。
結果として、実装だけで1ヶ月かかる見込みだったところ、プロトタイプ作成から約2週間でブラッシュアップして動く状態に到達しました。
今でも使えそうな学び
- 調査→計画→実装の流れは有効。ただしAIへ渡すコンテキストは最小限に
- エージェントの自走が厳しければ、方針転換（自分が書く・範囲を絞って渡す）を素早く行う
タスク2：小〜中規模の改修
小〜中規模は、だいたい1メソッド〜2クラスを新規作成する規模感と定義します。
さきほどのビジネスロジック追加に伴う、他影響機能の修正がメインです。
課題に対するアプローチ
既存のソースコードを調査
ここは従来どおり自分で実施しています。修正規模が大きくなく当たりも付いていたため、調査段階ではClaude Codeは使用していません。
この段階で、何をどうやって直すかをだいたい自分の頭の中で決めています。
計画
Claude CodeへPlanモード＋ultrathinkとともに、修正対象コードと修正方針を明確に伝えます。提案された修正計画は、そのまま承認せず、想定どおりの計画が出るまでラリーして磨き込みます。
実装
修正計画を承認すれば実装は速いです。打ち合わせ前にClaude Codeへ承認しておくと、戻ってきた頃には完了していることも。テストも、DBなど重い依存がなければ、観点とサンプルがあれば高確率で仕上がります。
今でも使えそうな学び
- すでに影響箇所や修正箇所がわかっているのであれば調査フェーズは不要、そのまま計画、実装を行うべし
- 計画はMaxプランなら
ultrathink一択。範囲が広い場合は計画をMarkdownで保存しておくとやり直しが楽 - モデルはSonnet 4で十分な場面が多い。Opusは本件規模では必須ではない
- 修正計画の磨き込みで、もし分からない点があれば、自分が理解できるまで質問を繰り返す。計画時に分からないことがあるなら、実装も正誤判断がつかなくなる
- AIエージェントのテストコードで網羅できるように、設計すべし。DBなど依存性の高いテストは極力やめる、責務を分けてテストしやすい、保守しやすい設計を心がける。
余談：Claude Code GitHub Actions
弊社では、現在は試行期間を経てすでに導入済み。ここでは試行期間中のTIPSを記載する。
Claude Code GitHub Actions
PRレビューだけではなく、issueやブランチをチェックアウトしPR上でコメントして自走させることが可能。
Issueでの動作
@claudeでPRを作成させると、リポジトリのデフォルトブランチからPRを作成する。
PRでの動作
該当ブランチへ直接変更をpushする。
手元でgit checkout -bしてpushしただけのPR上で@claudeでコメントすると、そのブランチ上で修正作業を実施させることは可能
弊社での運用
issueやPRの作成については、現状非推奨としています。
理由は、初回の仮実装までは良いのですが、何度も修正させようとコメントすると、Claude自身の誤ったコメントに引きずられて同じ間違いを繰り返してしまうためです。
推奨は、基本的にはPRレビューとPR内でのコメント対応のみ。
別作業でブランチ切り替えやコンテキストスイッチもあるため、コメントアウトの修正や変数名の見直しなど“サクッと直せるもの”での活用が中心です。すべてのPRに反応するとコストがかかるので、@メンションで呼び出す運用にしています。
終わりに
以上、2025年5月～7月頃にClaude Codeを実務で活用した経験をお話ししました。
今回のポイントをまとめると
- 大規模タスク：調査・計画・実装の3段階に分けて進める。今だとSerena MCPとの組み合わせで調査精度が向上するはず
- 小〜中規模タスク：影響箇所が明確なら調査は不要。計画の磨き込みが成功の鍵
- 共通のコツ：AIが理解しやすい設計を心がけると、人間にも読みやすいコードになる
- GitHub Actions：PRレビューや軽微な修正には有効だが、複雑な作業は避けるのが無難
タスク規模別適用戦略
Claude Codeは特に計画フェーズでの威力を発揮します。ultrathinkを活用した計画の磨き込みと、テストしやすい設計を意識することで、AIエージェントを効果的に活用できると感じています。
次回予告
次回は、今まで触れてこなかったDevinの活用例について、まとめたいと思います。お楽しみに！
Discussion