モノレポをAIで修正する｜共有パッケージの影響範囲を確認

パッケージと利用側を対応付ける

最初にアプリ、共有パッケージ、設定、生成物を分け、対象機能がどこから呼ばれるかを確認します。npm workspaces等の構成があっても、それだけで業務上の依存や実行順がすべて分かるとは限りません。架空の例では共有の金額表示関数をWebと管理画面が使う構成を考えます。対象ファイルだけを見て変更せず、呼び出し元と仕様の違いを調べてください。似た名前の別関数を無条件に共通化せず、同じ契約を期待する利用側かを先に確認することが出発点です。

読む範囲と書く範囲を分ける

AIが判断するために必要な利用側を読むことと、その利用側を書き換えることは別です。対象関数、型、呼び出し元、テストを調査し、編集予定を短く出してもらいます。CursorやClaude Codeで原因を探し、Aider等で既知のファイルへ限定する構成も考えられますが、製品名だけで範囲が守られるとは判断しません。差分をGitで読み、関係のないパッケージへ整形や依存更新が混ざったら分けます。必要な参照を消して狭く見せるより、理解した上で編集を限定することを重視します。

• AIへ渡すコードの文脈を絞る｜必要な情報と送信範囲

共有の変更は互換性から順序を決める

共有型の必須項目を増やす場合、どのアプリをいつ公開するかを確認します。すべてが同時に切り替わる前提を勝手に置かず、必要なら追加、利用側の変更、古い項目の整理へ分けます。Kiro等で計画を作る場合も、タスクを並列にできるかは実際の依存へ基づいて判断します。型が通ることだけでなく、未指定時や既存データの読込みが成立するかを見てください。一つのアプリが新しい実装でも、別の利用側が以前の契約を必要とする期間があるなら、その条件を変更計画へ残します。

架空の例：通貨表示の任意設定

架空の共有関数へ、末尾の小数を表示するか選べる任意設定を加えます。設定なしなら以前と同じ結果、設定ありなら合意した見本を返す条件を作ります。Webと管理画面で異なる既存入力を用意し、片方だけ通る変更になっていないかを確認します。丸めや通貨の意味をAIが新しく決めるのではなく、担当者が確認した期待値を使ってください。この演習は特定製品の能力を測ったものではありません。小さな共有変更が両方の利用側へ与える影響を、差分と結果から説明する課題です。

• AIで既存コードをリファクタリングする｜挙動を守る比較手順

検証対象をコマンドへ落とす

対象パッケージのテストだけでなく、利用側の型検査と必要なビルドも確認候補へ入れます。npmの公式資料ではワークスペースを指定する実行が案内されていますが、スクリプトの中身が本当に必要な検証かは各プロジェクトで確認します。存在しないスクリプトを無視する設定を、検証済みの証拠にしないでください。ロックファイルが変わった場合は理由を調べ、共通の依存更新が不要に混ざっていないかを読みます。結果には実行した対象と未確認の対象を残し、成功した一部分を全体の確認として説明しません。

並行作業と引き継ぎを整理する

複数エージェントを使う場合は、同じ共有ファイルとロックファイルの担当を一つに決めます。独立した作業でも最後に統合した差分で確認が必要です。利用量の追加より先に、担当の重複や何度も同じ全体調査をしていないかを見直します。引き継ぎでは、依存の見取り図、変更理由、必要な実行順、確認コマンド、残る互換条件を残してください。契約やモデルが変わっても普通のGitとテストで保守できる状態を作ると、元の会話を知らない担当者も次の変更を計画できます。

• 依存更新後の不具合をAIで調べる｜再現条件と変更範囲