AIに修正を頼むと、短時間で多くのファイルが変わります。困るのは、その変更を人が確認する時間です。名前をそろえた行と、料金計算を変えた行が同じ差分に並ぶと、見た目の変更に埋もれた一文字を見落としやすくなります。
は、変更前後のコードを解析し、関数の名前変更、処理の変更、呼び出し先の直し忘れなどを整理する道具です。2026年10月1日5時15分（日本時間）に公開されたv0.1.0を、Apple SiliconのMacで試しました。この記事では、自作した小さなの送料計算を使い、実際に出た分類と、その分類だけでは分からないことを紹介します。
今回は基本の解析だけを実行しました。による要約、外部サービスへの送信、開発エージェントの会話履歴の読み取りは使っていません。大規模な開発案件や、すべての対応言語での精度を測った結果ではありません。確認日は2026年10月1日です。
1. AIの変更を確認する前段で、読む順番を作る
普段のの差分は、どの行が増減したかを教えてくれます。Perspicaは、その前後のコードを構文として読み、どの関数や呼び出しが変わったかを追加で整理します。基本解析にモデルやキーは不要です。AIが作った変更にも、人が書いた変更にも使えます。
公式READMEでは、TypeScript・JavaScript、Python、Rust、Go、Java、Cを意味の解析対象としています。ほかの言語のファイルも行単位の差分として表示する設計です。配布物はmacOS、Linux、Windows向けがあり、ソースはで公開されています。今回はmacOSのarm64版だけを動作確認しました。
役に立つ場面は、改名や整理の多い修正を確認するときです。「担当者が確認すべき部分」を狭める補助として使い、その後に型検査、テスト、業務条件との照合を続けます。レビューを終えたと自動判断する道具として導入すると、解析の範囲を超える使い方になります。
2. 送料計算に三つの変更を作って比べた
検証には「合計5,000円以上なら送料0円、それ未満なら500円」という架空の処理を用意しました。基準ファイルの checkout は、商品合計に送料を足して返します。実在する店舗の仕様ではなく、境界の変更を見つけやすくする教材です。
export function shippingFee(total: number): number { return total >= 5000 ? 0 : 500;}
export function checkout(total: number): number { return total + shippingFee(total);}ここから、関数と呼び出し側の両方を改名した版、比較演算子だけを変えた版、関数だけを改名して呼び出し側を残した版を作りました。入力四ファイルと観測結果の抜粋は、練習用資料をダウンロードできます。Perspica本体は含めていません。
| 変更例 | v0.1.0で観測した内容 | 人が確認する点 |
|---|---|---|
shippingFee を deliveryFee に統一 | 改名を検出し、変更4行を機械的な変更として分類 | 呼び出し側まで直っているか |
>= 5000 を > 5000 に変更 | shippingFee の処理変更。変更2行のうち機械的な変更は0行 | ちょうど5,000円の注文をどう扱うか |
| 定義だけ改名し、呼び出しは旧名 | 旧名 shippingFee の参照が6行目に残ると検出 | 該当箇所を修正して型検査を通す |
改名だけの例にも、結果の logic_changes には呼び出し側の checkout が「本体変更」として残りました。一方、差分行の分類はすべて改名扱いでした。つまり「処理変更という欄が一つでもあれば動作が変わった」と単純に読めるわけではありません。どの分類が、どのコードの変化を指しているかを合わせて見る必要があります。
3. 一文字の違いは、業務ルールで確かめる
比較演算子の例では、Perspicaは処理が変わった関数を示しました。ただし、それが意図した仕様なのか、不具合なのかまでは決めていません。「5,000円以上」という依頼なら元の >= が必要ですし、「5,000円を超えたら」に改定したのであれば > が合っています。
別途TypeScriptをコンパイルし、Node.jsで確認したところ、合計5,000円の入力に対し、元の checkout は5,000を返し、演算子変更後は5,500を返しました。また4,999・5,000・5,001の三入力では、関数名だけをそろえた版と元の版の結果が一致しました。これは教材に対する動作確認であり、Perspicaが業務仕様の正しさまで保証したという意味ではありません。
呼び出し側を残した版は、Perspicaでも旧名参照が検出され、TypeScriptの型検査でも shippingFee が見つからないエラーになりました。二つの道具は違う角度から同じ修正漏れを示します。AIに追加修正を頼むときも、「警告を消して」だけでなく、残った呼び出しと、守るべき境界条件を渡す方が確認しやすくなります。
4. まず二つのファイルで、基本解析だけを試す
導入は公式リリース一覧から自分のとに合う配布物を選ぶ方法があります。今回使ったのはv0.1.0の perspica-aarch64-apple-darwin.tar.gz です。配布ページには確認用の SHA256SUMS があり、取得した圧縮ファイルのハッシュが公開値と一致することを確認してから実行しました。以後は実行ファイルにパスが通っている前提です。
教材を展開したフォルダーで、次の二つのコマンドを実行します。最初にバージョンを確認し、次に基準ファイルと、呼び出しを直し忘れた版を比較します。--no-sessions は開発エージェントの会話履歴を読み取らない設定です。
perspica --versionperspica before.ts missed-caller.ts --json --no-sessions > result.json出力は形式です。今回の確認では、cross_file.broken_references に旧名の参照が一件ありました。results の中には改名や処理変更などの分類が入ります。最初は文章要約を追加せず、入力した二ファイルと、この結果を対応させて読んでみてください。
自分の変更をまとめて読む段階では、perspica --staged --no-sessions でGitにステージした変更を対象にできます。対象を絞ると、自分が今レビューしている修正と、まだ途中の別作業を混ぜにくくなります。今回の実測は二ファイル比較のみなので、複数ファイルをまたぐ大規模な修正も同じ精度で読めるとは断定していません。
5. 終了コード0は「変更が安全」の意味ではない
三つの比較コマンドは、いずれも終了コード0で終わりました。呼び出しが壊れている例でも0です。これは今回の解析処理が完了したことを示していて、コードが正しいことを示してはいません。自動検査に組み込む場合は、結果のどの項目を失敗条件にするかを別に決める必要があります。
機械的な変更として折り畳まれた行も、最初から読む必要がないとは限りません。名前の変更によって外部から使う呼び出し方法が変わる場合や、解析対象外の設定ファイルと連動する場合もあります。既存の型検査やテストを残し、利用者に見える仕様が変わる箇所を人が確認する役割は引き続き必要です。
追加の要約機能では、-s や画面のAnalyze操作からモデルによる分析を使う設計です。公式説明ではコードの変更情報などがモデルへ渡され、自分の作業については会話履歴も利用する場合があります。社内コードを使うなら、まず基本解析で必要なことが足りるかを見て、追加分析を使うときに送信先と対象範囲を確認してください。今回、追加分析の精度や費用は測っていません。
コードを書く速度だけでなく、確認する手間も見直したいチームには、小さな修正で試す価値があります。大切なのは「何行を隠せたか」だけで評価せず、実際に確認すべき変更へたどり着けたか、修正後の型検査と業務テストまで終えられたかを見ることです。まずは教材の三例で表示の意味を覚え、普段の修正へ一つずつ広げるのが始めやすいでしょう。