見積画面の料金計算を直した後、注文確認画面にも同じ変更が必要だったと分かる。こうした修正漏れを防ぐには、似たコードを見つけるだけでなく、画面ごとの計算条件まで確かめる必要があります。ここでは、中小企業の受発注システムを保守する開発者が、Claude Codeを使って料金計算の重複を整理する進め方を紹介します。扱う業務課題は、仕様変更のたびに複数箇所を個別修正する負担です。

以下のシステム、ファイル名、料金ルール、お願い文は、実践方法を説明するための架空の例です。実際の操作結果や導入実績ではありません。読者には、Gitによる差分確認、関数の入出力設計、既存のテスト環境を扱える知識を前提とします。

担当者は普段から、エディターの全文検索、Gitの変更履歴、仕様書、単体テストを利用しているとします。変更依頼を受けたら、関連する関数と呼び出し元を検索し、税率や割引の扱いを仕様書と照合します。その後、見積画面と注文確認画面を個別に修正し、テストと画面確認を経てレビューに回す流れです。既存の道具で探索や検証はできますが、見つかった処理の意味を比較する作業は残ります。



Claude Codeの公式資料では、関連コードの探索、リファクタリング、テスト作成などの開発作業を支援する使い方が紹介されています。（出典: Anthropic「Common workflows」）本稿では、その使い方を料金計算の共通化に応用します。狙うのはコードの行数削減そのものではなく、同じ料金ルールを変更する場所を集約し、変更時に確認すべき範囲を明確にすることです。

架空のリポジトリには、見積用の`quotePricing.ts`と注文確認用の`orderPricing.ts`があるとします。どちらも商品小計から割引後金額と税額を計算しますが、注文確認画面だけは送料も加算します。変数名や処理順の書き方が違うため、単純な文字列検索だけでは、同じルールを実装しているのか判断しにくい状態です。

ここで負担になる工程は、探索、分類、修正、確認に分けられます。探索では、関数名に加えて税率、端数処理、合計金額を表示する箇所までたどります。分類では、見つけた処理を「同じ料金ルール」「画面固有の加算」「表示形式」に分けます。修正では、呼び出し元が必要とする値を壊さずに差し替える必要があります。確認では、計算結果だけでなく、戻り値の型や画面への渡し方も対象になるでしょう。



Claude Codeに補助を求めるのは、候補箇所の列挙、処理の読み比べ、変更案とテスト案の作成です。ただし、二つの式が似ていても、共通化してよいとは限りません。たとえば、見積時点では仮の税額を使い、注文確定時には別の丸め規則を適用する業務なら、その差を消すと不具合になります。正しいルールは人が仕様の責任者に確認します。

| 工程 | AIを使わない場合 | Claude Codeで補助する内容 | 人が残す判断 |
| --- | --- | --- | --- |
| 探索 | 検索結果と呼び出し元を読む | 関連箇所と根拠を整理する | 探索範囲が十分か確認する |
| 分類 | 計算順序と例外を比較する | 共通部分と相違点の候補を示す | 相違が仕様か不具合か決める |
| 修正 | 共通関数と呼び出し側を編集する | 合意した範囲の変更案を作る | 責務と互換性を評価する |
| 検証 | ケースを設計して実行する | テスト案と実行結果を整理する | 期待値と証拠を確認する |

比較では、入力となるコード、仕様、テストと、完成時に求める品質をそろえます。AIを使う場合だけ確認を省略すると、作業量の違いと品質の違いを混同してしまいます。

実践は、Claude Codeを利用できるGit管理下の開発環境で行う想定です。導入や認証の手順、提供プランは扱いません。作業用ブランチを用意し、未コミットの変更を確認して、今回の変更と区別できる状態にします。必要な入力は、対象の二つの計算処理、直接の呼び出し元、料金仕様、既存テスト、プロジェクトで定められた検証方法です。実データや認証情報を使う必要はありません。

操作は、調査、挙動の固定、共通化、人による検証の四段階に分けます。調査時点でコードを編集したくない場合、公式資料では、Claude Codeのplan modeでファイルを読み、編集前に計画を確認できると説明されています。（出典: Anthropic「Common workflows」）以下では、この機能を使って探索と変更案の確認を分ける進め方を提案します。



コピーして使う調査用のお願い文です。ファイル名と仕様の所在は、自分のリポジトリに合わせて置き換えてください。

今回は調査と変更計画だけをお願いします。
quotePricing.tsとorderPricing.ts、その直接の呼び出し元、
関連仕様、既存テストを確認してください。

料金計算の入力、計算順序、端数処理、戻り値、例外を比較し、
判断の根拠となるファイルと箇所を示してください。
共通化できる候補と、画面側に残す候補を分けてください。

仕様と実装が違う場合は、どちらが正しいか推測しないでください。
既存の検証方法と、追加が必要なテストを提案してください。
ファイルは編集せず、不明点を最後にまとめてください。

調査結果を受け取ったら、人が仕様差と探索範囲を確認します。共通化前には、各画面の現在の出力を確かめるテストを用意します。既存挙動を記録するテストと、業務仕様として正しいことを確かめるテストは区別が必要です。現行実装に誤りが見つかった場合は、挙動を維持する共通化と不具合修正を別の変更に分けると、差分の理由を追いやすくなります。

この例では、人が次の架空仕様を確定したとします。金額は円単位の整数で、商品小計に整数の割引率を適用し、割引後金額の小数部分を切り捨てます。その金額に対して税率10％で税額を計算し、税額の小数部分も切り捨てます。注文確認画面では、最後に送料を加算します。これは説明用の計算規則であり、実際の税務処理や自社仕様の正しさを示すものではありません。

共通関数の入力候補は商品小計と割引率、出力候補は割引後金額、税額、税込商品金額です。送料の取得と加算、通貨表記、画面表示は呼び出し側に残す設計を提案します。画面名を引数に渡して内部で条件分岐するより、共通関数の責務を料金計算に絞ったほうが、この例では変更の影響を追いやすいためです。



コピーして使う実装用のお願い文です。調査で合意した対象ファイルと仕様を添えて渡します。

確認済みの変更計画に沿って、対象二画面の料金計算を共通化してください。
割引後金額と税額の計算順序、各段階の切り捨てを維持してください。
送料の取得・加算と表示整形は呼び出し側に残してください。

既存の型、配置規則、テストの書き方に合わせてください。
依存追加、料金仕様の変更、無関係な整形は行わないでください。
不明な入力条件は推測して新しい規則を追加せず、報告してください。

変更後は、確認できたプロジェクトの検証方法を使ってください。
変更ファイル、実行した検証、実際の結果、未実行項目、
残る懸念を分けて報告してください。

期待する成果物の例は、共通計算関数、二つの呼び出し側の差分、共通関数のテスト、画面側の回帰テストです。商品小計1,005円、割引率10％なら、割引後金額は904円、税額は90円、税込商品金額は994円になります。送料500円の注文確認では1,494円です。この数値は架空仕様から求めた期待値であり、Claude Codeの実行結果ではありません。報告がこの形式でも、実際の差分とテストの証拠は別途確認します。

レビューでは、共通関数だけを読んで終わらせないことが大切です。計算式が同じでも、戻り値の項目名が変わったり、入力オブジェクトを書き換えたりすると、呼び出し元に影響します。既存の同期処理に不要な非同期処理が入っていないか、画面側に古い式が残っていないかも確認対象です。変更前の二つの実装と、新しい共通関数、その呼び出し側を対応付けて読みます。

Claude Codeの公式資料では、既存テストの形式に合わせたテスト生成や、境界値・エラー条件のテスト候補を求める使い方が紹介されています。（出典: Anthropic「Common workflows」）ただし、実装と期待値の両方を同じ誤解から作れば、テストは通ってしまいます。料金仕様から期待値を独立に求める作業は、人が担当します。



今回の例なら、割引なし、小計ゼロ、端数が出る割引、税額に端数が出る入力、送料ありと送料なしを確認します。許容する小計や割引率の範囲は既存仕様に従い、負数や範囲外の値について新しい扱いを勝手に追加しません。対象関数のテストに加え、各画面の入力から表示用の金額を作る経路も検証すると、共通関数への置き換え忘れを探せます。

修正を頼む際は、「テストを通してください」だけでは情報が足りません。たとえば「注文確認の送料なしケースで、変更前と変更後の合計が異なります。送料の既定値と呼び出し側の入力を調べ、料金仕様を変えずに原因と最小の修正案を示してください」と具体化します。原因の説明と差分が一致するかも確認しましょう。

承認前には、担当者自身が既存の検証方法でテストや型検査などを実行し、結果を確認します。環境不足で実行できない項目は、未確認として記録します。料金に影響する変更なので、プロジェクトで定めたレビュー担当者が仕様との一致と影響範囲を確認したうえで、通常の取り込み手順へ進めます。

共通化によって期待できるのは、同じルールの変更を複数箇所へ転記する作業と、その修正漏れを探す負担の軽減です。Claude Codeの補助は、関連箇所の比較やテスト候補の整理で役立つ可能性があります。ただし、仕様が曖昧なら質問と確認が増えますし、変更案が広すぎれば差分を絞り直す必要もあります。生成が速いことだけで、保守業務全体が短くなるとは判断できません。

効果を確かめるには、準備、探索、仕様確認、実装、検証、レビュー後の修正を分けて記録します。AIへの説明文を整える時間や、不要な変更を戻す作業も含めてください。比較の単位は、同じ二画面、同じ料金仕様、同じテスト条件、同じレビュー基準です。AIを使わない既存の作業記録がなければ、今回の記録を起点に、条件の近い次回の保守作業と比べる方法が考えられます。



作業時間に加え、仕様の未解決点、レビューで見つかった計算差、差し戻しの理由を残すと、どの工程が改善したかを判断しやすくなります。たとえば、探索は早く終わってもレビューが増えたなら、依頼範囲が広すぎたのか、共通化の境界が曖昧だったのかを見直せます。仕様確認で見つかった不具合は、共通化による効果と区別して記録するとよいでしょう。

共通化後に料金ルールを変更するときも、共通関数だけのテストで完了とはしません。送料などの例外が残る呼び出し元まで、必要な回帰テストを続けます。共通化は確認工程をなくす手段ではなく、変更箇所と検証範囲を整理する手段として位置付けるのが適切です。

最初に選ぶのは、同じ仕様を持つと確認できた二つの計算処理だけで十分です。既存挙動をテストで固定し、Claude Codeには編集を伴わない比較調査から依頼してください。その結果を人が確認してから小さな差分へ進めれば、共通化の妥当性とAIへの依頼方法を、一つのレビューで評価できます。

- Common workflows - Claude Code Docs

資料の取得日時は2026年11月5日07:00 UTCです。取得日時は公開日や機能の提供開始日を示すものではありません。