最近、AIによるリファクタリングが優秀すぎて、「PhpStormを使うメリットって実は Inspect Code（静的解析） だけなのでは？」と感じることが増えました。そうなると、「CIでPHPStanを回しているなら、PhpStormのInspect Codeはもう不要なのでは？」という疑問も自然と湧いてきます。
しかし、日々レガシーコードやバージョンアップと戦うなかで、ぼくの肌感は少し違います。「PHPStanのレベルを6〜9に上げるよりも、PhpStormのWeak warningを潰したほうが、はるかに実利が多い」ということです。
特にPHPのバージョンアップを控えている時期は、移行の地雷（Weak warning）がない「きれいな状態」を維持しておくことが、AIを味方につけて安全にリファクタを進める大前提になります。
今回は、迷いがちな「PHPStan」と「PhpStormのInspect Code」の役割の境界線について、自分なりの整理をまとめてみました。
コンパイル言語
コンパイル言語では、「言語としての正しさ」の防衛ラインがコンパイラによって強制されます。
- コンパイル（言語の成立）
- テスト（仕様の成立）
モダンPHPの世界
PHP（動的型付け）には強制的なコンパイルがありません。そのため、複数のツールを組み合わせて「擬似的なコンパイラ（防衛ライン）」をレイヤー状に構築する必要があります。
- PHPStan ～Level 5（基礎的な言語の成立）
「そもそも存在しないメソッドを呼んでいないか」「文法的に破綻していないか」という、コンパイル言語でいう最低限のビルドが通る状態を作ります。 - PHPStan Level 6～（Array Shapesの世界）
PHP特有の「なんでも入る連想配列」に対して、PHPDocという外部ギブスをはめて無理やり静的型付け言語の挙動を模倣するフェーズです。ここを過剰に頑張るくらいなら、DTOという本物の型（クラス）に昇華させた方が実利が高くなります。 - PhpStorm Inspect（未来の防衛と コードの匂い）
PHPStanが「現在の型パズル」に集中するのに対し、PhpStormは「PHPという言語の進化（バージョンアップ）にコードが追いついているか」「ランタイムで不穏な挙動をしないか」という、一歩進んだ実務的なリスクを検知します。 - テスト（仕様の成立）
型がどれだけ綺麗（＝言語として成立）になっても、「仕様（ビジネスロジック）が正しいか」はテストコード（あるいはGolden Master）にしか担保できません。
まとめ：エンジニアとAIが戦うための「防衛ライン」の引き方
動的型付けのPHPだからこそ、ツールごとの役割を理解して、どこに投資するかを見極めるのが重要です。
- 「PHPStanのレベルを上げる作業」は程々にする レベル6を超えたあたりのArray Shapes埋めは、ただの「型パズル」になりがちです。そこに時間を溶かす必要はありません。
- 「実利を取る作業」に投資する PHPStanレベル5で最低限の治安を維持したら、そこにとどまらない。そのArray Shapesを設計図にして、AIにDTO（データ転送オブジェクト）やドメインプリミティブへ昇華させます。
- PhpStormのInspectで未来の地雷（Weak warning）を炙り出す 未来のバージョンアップで踏む地雷をピンポイントで潰し、AIが動きやすい「素直なコード」を維持します。
結論として、ぼくたちが強化すべき防衛ラインは「過剰な型のパズル」ではなく、「未来への安全性」です。
PHPStanレベル5達成のために書いたArray Shapesは、いわば次のリファクタリングのための「踏み台（仕様書）」です。そこに満足してとどまるのではなく、それを参考にDTOやドメインプリミティブを定義し、本物の型安全へ移行していく。その過程で、PhpStormのInspectを使って次期バージョンアップの障害（Weak warning）を先回りで潰していく。
ツールに振り回されて消耗するのではなく、それぞれの強みを活かして、AIと共にスマートにコードの治安を維持していきたいですね。
