こんにちは！日々の開発、本当にお疲れ様です。
PHPのプロジェクトを進めていく中で、こんなモヤモヤを感じたことはありませんか？
「あれ、このライブラリって本当にまだ使ってるっけ……？」
「とりあえず便利そうだから`composer require`したけど、結局コードのどこからも呼ばれていない気がする……」
プロジェクトが長期化するにつれて、`composer.json`には使われなくなった依存関係の残骸が溜まりがちです。これが進むと、不要なパッケージのアップデートに時間を奪われたり、脆弱性（セキュリティホール）が混入するリスクを知らぬ間に高めてしまったりと、良いことがありません。
今回は、そんな「使われていない依存関係」を自動で綺麗にスキャンし、あなたのプロジェクトを劇的に軽量化・クリーンアップしてくれる秘密兵器`composer-unused`の使い方を、優しく丁寧にお伝えします。
これをマスターすれば、毎日のメンテナンスが驚くほどスッキリしますよ。一緒に見ていきましょう！
—
1. `composer-unused` とは何か？（なぜ導入すべきなのか）
まず、このツールが何をしてくれるのか、その本質を押さえましょう。
私たちが普段使っている Composer は、「指定されたパッケージをインストールする」ことに関しては天才ですが、「インストールされているけれど、コードのどこからも使われていないパッケージ」を判定するのは苦手です。
そこで登場するのが `composer-unused` です。
このツールは、以下の手順でプロジェクトの裏側を徹底的に解析します。
1. `composer.json` を読み込み、宣言されている依存関係をリストアップする。
2. ソースコード（`src/` や `app/` など）を静的解析し、実際にコード内でどのクラスや関数が使われているかを調べる。
3. 「宣言されているのに、コード内で一度も参照されていないパッケージ」を特定し、赤裸々に暴き出す！
不要なパッケージをごっそり削ぎ落とすことで、セキュリティリスクの低減（攻撃表面積の縮小）、CI/CDパイプラインのビルド時間短縮、そしてコードベースの見通しの良さという計り知れないメリットを手に入れることができます。
—
2. 導入と基礎セットアップ
百聞は一見にしかず。実際にあなたのローカル環境で動かしてみましょう。
今回は、プロジェクト単体に影響を与えないよう、グローバル（あるいはプロジェクトのローカル開発用）に安全にインストールする方法を採用します。
インストール方法
プロジェクトのルートディレクトリで、以下のコマンドを実行してください。Composerのプラグインとして、あるいは独立したツールとして安全に導入できます。
プロジェクトの開発依存関係（dev-dependencies）として安全にインストールします
composer require –dev ilyk/composer-unused
※解説: `–dev` をつけることで、本番環境（プロダクション）のビルドには含まれないように制御します。これがアーキテクトとしての安全第一の鉄則です。
—
3. 精度高い「Hello World」！最初の動作確認と設定
インストールができたら、さっそく解析を走らせてみましょう。
まずは一番シンプルな形でコマンドを実行します。
vendorディレクトリ内にある実行ファイルを直接呼び出します
vendor/bin/composer-unused
実行すると、ターミナルに以下のようなスキャン結果が表示されます（※プロジェクトの状況によって出力は異なります）。
[ComposerUnused]キャンを開始します…
[Info] composer.json とソースコードの照合中…
使用されているパッケージ (Used packages):
- psr/log
- symfony/http-foundation
使用されていないパッケージ (Unused packages):
- nesbot/carbon (注意: 宣言されていますが、コード内で検出されませんでした)
見事に「使っていないパッケージ（例：`nesbot/carbon`）」を特定してくれました！
徹底解説：なぜこの精度が出せるのか？
`composer-unused` は、コード内の `use` 宣言や、完全修飾名（FQCN）をパースしてチェックしています。そのため、「実は文字列として設定ファイルに書いてあるだけ」といったケースで、誤検知（本当は使っているのに「使っていない」と判定されること）が起きることが稀にあります。
そんな誤検知を防ぎ、ツールの精度を100%引き出すために、プロジェクトのルートに設定ファイル `composer-unused.php` を配置しましょう。
以下の設定ファイルをプロジェクトのルートディレクトリに作成してください。
addSource(
Source::fromPath(__DIR__ . ‘/src’)
)
// 【重要】フレームワーク特有のルーティングや設定ファイル等で
// 動的に使われており、静的解析で検知漏れしやすいパッケージを「除外（Ignored）」します
->addNamedPackage(
NamedPackage::fromString(‘nesbot/carbon’) // 例: 日付ライブラリを意図的に除外する場合
);
};
※解説: この設定ファイルを置くことで、ツールが「どこを読んで、どれを無視すべきか」を正確に理解し、プロジェクト固有の事情に合わせた高精度なクリーンアップが可能になります。
—
4. 不要なパッケージを安全に削ぎ落とす実践フロー
使われていないパッケージが判明したら、いよいよ削除のステップです。
ただ闇雲に消すのではなく、以下の安全なフローを習慣づけましょう。
Step 1: 削除候補の最終確認
本当にそのパッケージが不要か、チームメンバーや自分自身の過去のコミット履歴を軽く確認します。
Step 2: Composerでのアンインストール
不要と確信できたら、以下のコマンドで安全に削除します。
例として、不要になったパッケージを削除します
composer remove メンテナンス対象のベンダー名/パッケージ名
※解説: 単に `composer.json` を手動で書き換えるのではなく、必ず `composer remove` コマンドを使いましょう。`composer.lock` の整合性が自動で保たれ、オートローダー（ClassMap）の最適化まで裏側で一括して安全に行ってくれます。
Step 3: 自動テストの実行
パッケージを削除した後は、必ずお使いのテストスイート（PHPUnitやP Pestなど）を走らせてください。
依存関係を削った後に、アプリケーションが壊れていないか最終確認
vendor/bin/phpunit
これでテストがすべてグリーンになれば、安全なクリーンアップの完了です！
—
おわりに
いかがでしたでしょうか？
`composer-unused` を導入・活用することで、長年放置されたPHPプロジェクトでも、まるで新築のようにクリアな依存関係を取り戻すことができます。
「不要なコードやライブラリを持たないこと」は、エンジニアにとって最高の贅沢であり、最大の防御です。
ぜひ今日の開発から取り入れて、スッキリと心地よいコーディングライフを楽しんでくださいね！