請求書の更新項目を追加する際、画面上では自社の請求書だけが表示されていても、APIが同じ制約を守っているかは別途確認が必要です。ここでは、複数の企業が利用する業務アプリを保守する開発者が、請求書の詳細取得と更新を対象に、他社データへのアクセスを防ぐチェックを点検する場面を扱います。以下の業務、データ、実装方針は架空の例であり、Claude Codeを使った進め方の提案です。

AIを使わない場合、担当者はエディターでルート定義を探し、認証処理からサービス層、データ取得処理へとコードを追います。既存の認可仕様と照らし合わせ、必要な修正と結合テストを追加し、Gitの差分を別の開発者にレビューしてもらう流れです。コード検索や既存のテスト補助関数は利用できる前提ですが、「どこで所属企業を確定し、どの条件で対象データを絞るか」を関連付ける作業は残ります。

Claude Codeの公式資料では、コードの探索、不具合修正、既存の形式に沿ったテスト生成などの開発ワークフローが案内されています。これらを、認証からデータアクセスまでの経路整理と、修正候補・テスト案の作成に使う構成です。テナント分離を自動で保証する機能として扱うものではありません。（出典: Anthropic「Common workflows」）



実践には、HTTP API、認証と認可の違い、データベース検索、Gitの差分確認、結合テストの知識が必要です。成果物は対象APIの修正差分、回帰テスト、判断根拠を記したレビュー用メモに絞ります。既存の認証基盤を作り直す作業や、アプリ全体の安全性評価まで広げず、一つのデータ境界を追跡できる範囲で進めましょう。

この業務で難しいのは、検索条件に企業IDがあるかを一か所確認することだけではありません。ログイン済み利用者の所属企業がどこで確定し、その値が途中で置き換わらずに検索処理まで届くかを追う必要があります。更新では、読み出した対象の確認だけでなく、実際の更新処理が同じ範囲に制限されているかも調べます。認証が成功していることと、その請求書を操作できることは、分けて判断しなければなりません。

作業を分けると、資料探しでは認可仕様と既存テストを探し、転記ではファイル名・関数名・行番号を調査メモへ集めます。分類では各処理を「所属企業の確定」「入力の受け取り」「対象の検索」「更新」「例外処理」に整理します。その後、仕様との差を判断し、修正とテストの下書きを作る工程へ進みます。呼び出し先が複数に分かれているほど、調査メモとコードを往復する負担が増えやすいでしょう。



Claude Codeには、これらの経路と根拠を一覧にする調査を依頼する案が考えられます。公式資料でも、関連コードの探索や、コードの経路を分析して境界条件・異常入力のテスト候補を提案する使い方が紹介されています。ただし、出力された経路や候補は人がコードと照合する必要があります。（出典: Anthropic「Common workflows」）

たとえば「共通の認可処理がある」という回答だけでは判断材料が足りません。対象ルートが実際にその処理を通るか、そこで得た企業IDがデータアクセスに使われるかまで確認します。既存の設計が共通処理で制御する方式なら、その方式を尊重します。AIに不足箇所を探させる前に、開発者が守るべき境界を説明できる状態にすることが、不要な改修を避ける準備になります。

比較条件は、AIの有無で変えません。同じ開始時点のコード、同じ認可仕様、同じ架空データを使い、対象の詳細取得と更新について同じ合格条件を設けます。「動く修正ができたか」だけで比べると、確認を省いた作業が速く見えてしまいます。レビュー用メモやテスト結果まで含めて、同じ成果物を用意する前提です。

以下は工程の分担案です。Claude Codeへの依頼でまとめられる作業と、開発者が判断する内容を対応させています。

| 工程 | AIを使わない場合 | Claude Codeで補助する内容 | 人が判断する内容 |
| --- | --- | --- | --- |
| 調査 | コード検索と経路の記録 | 関連処理と根拠の整理 | 経路の正しさと調査漏れ |
| 仕様照合 | 実装と認可仕様を比較 | 不一致の候補を抽出 | 正当な例外と期待動作 |
| 改修 | 修正案と差分を作成 | 指定範囲の修正案を作成 | 設計との整合性と影響範囲 |
| テスト | ケース設計と実装 | 既存形式に沿うテスト案 | 期待値と検証の十分性 |
| レビュー | 差分と実行結果を整理 | 根拠と未確認事項を整理 | 承認と残存リスクの扱い |



減らせる可能性があるのは、関連ファイルを探してメモへまとめる往復や、似た構造のテストを繰り返し書く手間です。所属企業をどの情報から確定するか、他社の請求書を指定された場合にどの応答を返すかは、既存の認可仕様に従います。資料に記載がなければ、AIに埋めさせず、仕様の確認事項として扱います。

たとえば、他社データの存在を利用者へ伝えない設計なのか、権限不足を明示する設計なのかによって、期待する応答は変わります。AIの提案が一般的に見えても、そのまま採用する理由にはなりません。省略できるのは判断材料を集める際の一部の繰り返しであり、業務上の権限を決める工程は残ります。この分担を依頼文に書いておくと、修正案を評価する基準もそろえやすくなります。

Claude Codeを利用でき、対象リポジトリで作業できる開発環境があることを前提にします。導入手順や契約条件は本記事の対象に含めません。準備するのは、既存の認可仕様、対象APIのコード、結合テストの実行方法、テスト用データです。実在する顧客情報や本番の認証情報は使わず、企業Aと企業B、それぞれの一般利用者と請求書を用意します。利用者の所属企業は、既存の認証基盤が検証した情報から確定する設計を、この例の前提とします。

操作は四段階に分ける提案です。①認可仕様と合格条件を整理し、②Claude Codeへ読み取り中心の調査を依頼し、③人が調査結果と修正方針を確認し、④対象範囲の修正とテストを依頼します。公式資料では、編集前に計画を確認したい場合、plan modeでファイルを読み取り、承認まで編集せずに計画を提案する使い方が案内されています。（出典: Anthropic「Common workflows」）



コピーして使う調査依頼の例です。角括弧の部分を、実際に存在するパスや対象名へ置き換えます。

請求書の詳細取得と更新について、テナント分離を調査してください。
認可仕様は［仕様ファイル］、対象APIは［対象のルート］です。

今回は編集せず、認証済み利用者の所属企業が確定する箇所から、
検索・更新処理までの経路を追ってください。
各判断の根拠となるファイル名、関数名、行番号を示してください。

入力された企業IDや請求書IDが、処理へどう渡るかも確認してください。
仕様との不一致、確認済みの事実、未確認事項を区別してください。
既存の結合テストと、実行方法の根拠も挙げてください。

調査結果は、「対象ルート→認証処理→サービス→データ取得処理」という経路と、各地点の条件を対応付けたメモにするとレビューしやすいでしょう。これは成果物の形式例であり、実際の調査結果ではありません。経路を人が確認した後、次のように修正範囲を限定します。

確認した方針に沿って、対象APIのテナント分離を修正してください。
既存の認証基盤と認可仕様を維持し、対象外の機能は変更しないでください。

既存形式に沿う結合テストで、正常アクセス、他社データへの参照拒否、
更新拒否、拒否後にデータが変わらないことを確認してください。
実行したテストと結果、実行できなかった確認を分けて報告してください。

テストでは、企業Aの利用者が企業Aの請求書を参照・更新できることを基準にします。同じ利用者で企業Bの請求書IDを指定し、参照と更新が既存仕様に従って拒否されることを確認します。企業B側から企業Aを指定する組み合わせも用意すると、特定の企業やデータだけに依存した修正を見つける助けになります。以下はケース設計の例であり、実行済みの検証結果ではありません。

拒否の応答だけで合格にしないことが、この作業の確認点です。更新リクエストが拒否されても、処理の途中でデータが変わっていれば目的を満たしません。更新前後の保存状態を比較し、対象レコードが変化していないことを確かめます。詳細取得では、他社の請求書の値や関連情報がレスポンスへ混入していないかを調べます。更新値は変更の有無を判別できる架空の値にしておくと、検証の意図が明確になります。



既存の入力形式に企業IDが含まれる場合には、その値を他社へ変えたケースも検討します。企業IDを受け取らないAPIへ、テストのためだけに新しい入力項目を追加する必要はありません。テスト用の認証補助処理が認可そのものを省略していないかも読み、実際に検証したい経路が通っていることを確認します。

人によるレビューでは、差分、テスト、仕様を並べます。テストの期待値が修正コードを追認する内容になっていないか、共通処理の変更が別のAPIへ影響しないか、正常な自社操作を壊していないかが判断対象です。Claude Codeの説明にある行番号も実際のコードと照合します。実行できなかったテストは未確認として残し、認可仕様の解釈が割れた場合は実装の承認前に解決します。対象テストの成功だけで、アプリ全体のテナント分離を保証したとは扱いません。

効果を確かめる際は、準備、調査、修正、テスト実行、レビュー、手戻りを分けて記録します。AIへの依頼文を整える時間や、誤った調査結果を直す時間も含めます。コードを書く工程だけが短くなっても、確認負担が増えれば業務全体の改善にはつながらないためです。本記事では実測していないので、削減時間や改善率は示しません。

同じ対象APIで比較するなら、同じ開始コミットから分けた作業環境と、共通の合格条件を用意する方法が考えられます。入力には同じ認可仕様と架空データを使い、成果物には修正差分、結合テスト、レビュー用メモを求めます。ただし、同じ担当者が二回取り組むと、後の作業には最初の調査で得た知識が影響します。作業順序や既知の情報も記録し、純粋な時間差として断定しない扱いが必要でしょう。



時間と併せて見たいのは、判断に必要な根拠がそろったかです。関連処理の見落とし、仕様の未確定事項、レビューで発覚した修正漏れを記録すれば、どの工程で支援が役立ったかを振り返れます。認可仕様とテストが整っているリポジトリでは、調査結果を照合する基準を用意しやすくなります。仕様が曖昧な場合は、実装よりも確認事項の整理に価値が出る可能性があります。

最初の一歩は、請求書の詳細取得だけを対象に、編集を伴わない経路調査を依頼することです。開発者が認証情報の出所と検索条件を照合できたら、架空の二社データによる参照テストへ進みます。その結果を踏まえて更新処理まで範囲を広げれば、支援の有用性と確認負担を小さな単位で判断できます。採用の基準は生成したコードの量ではなく、同じ品質条件を満たすための調査と修正を、根拠を追える形で進められるかに置きましょう。

- Common workflows - Claude Code Docs

資料の取得日時は2026年11月8日07:00 UTCです。取得日時を公開日や機能の提供開始日として扱ってはいません。