Laravel Auditor：AIエージェントに監査メソッドを注入する設計
Laravel Newsが報じたPunyapal Shah氏によるLaravel Auditorは、開発者が既に使っているAIエージェントにLaravelアプリケーションの監査を委譲するための新しいパッケージである。AIエージェントに監査を任せると、実際のバグ、スタイル論を高severityに偽装した指摘、実在しない脆弱性が混ざり合うという運用上の問題に対する具体的な解を提示する。dev依存として導入する構成であり、監査ロジック自体はパッケージに内包されない。
既存エージェントを「監査モード」へ切り替える設計思想
本パッケージの介入範囲は、エージェント側へ注入する三点セット（スキル定義、ガイドライン、読み取り専用ツール群）に限定される。エージェントはDiscover → Scope → Verify → Reportの四工程を順に踏むが、この手順はパッケージ側が規定する。各工程で何を収集し、何を報告するかはスキル側に明示されており、エージェントの自由度を意図的に絞っている。
対応エージェントはClaude Code、Codex、Cursor、Copilot、Gemini CLI、Junie、Zed、opencodeの8種。実行要件はPHP 8.3以上、Laravel 12または13である。stdio型MCPサーバーの登録は単一のArtisanコマンドで完結する。
監査中にソースが書き換えられる経路は設計上存在しない。発見と報告に徹し、修正判断は人間側に残すという役割分離が明確である。コードベースへの副作用リスクを排除することで、CI上でも安全に渡せる設計となっている。
MCPサーバーによる構造化ファクト収集
監査精度を担保する中核は、MCPサーバー経由で公開されるコレクタ群である。project_info、routes、models、migrations、database_schema、dependencies、configuration、policies_authorization、jobs_events_schedules、tests、subsystemsの11ツールが、それぞれ決定論的な構造化データを返す。
ソース全文を返すのではなくファクトのみを返す点が重要である。生のソースダンプを返した場合、エージェントは「コンテキストに含まれる全テキスト」を根拠に推論を行う余地が生まれ、誤検知や過剰な推測の原因となる。構造化データを返すことで、コンテキスト消費のボトルネックを抑え、エージェントが事実と推定を混同する余地を狭める。
routes {uri: "api"}のようなフィルタ記法も定義されている。エージェントは特定ルートグループの情報をピンポイントで取得でき、無駄な依存関係走査を回避できる。Laravel Boostを既に導入済みの環境では、追加設定なくBoost側のMCPサーバーへコレクタが登録される。既存MCP基盤への統合コストはほぼゼロである。
ルールカタログは0.1.x時点で6領域（security、performance、architecture、database、testing、Laravel conventions）にわたる75ルールを備える。--applicableフラグは、未インストールのComposerパッケージに紐づく条件付きルールを自動で除外する。プロジェクト構成に適合しないルールを事前にフィルタできる点は、誤検知率の抑制に直結する。
所見はrule ID、severity（critical〜info）、confidence、ファイルと行の根拠、修正案の各フィールドで構造化されて記録される。severityとconfidenceが分離されている点は重要で、深刻度と確度を一括りにしないことでレビュー時のトリアージが容易になる。出力フォーマットはSARIFに対応しており、ローカル生成ファイルをそのままPRのCode Scanningへ取り込める。CI基盤側にSARIF対応の取り込み口がある場合、追加のグルーコードを書かずに監査ループへ統合できる。
導入前に確認すべき点
現時点では早期開発段階のパッケージである。CIへの組み込みを視野に入れる前に、現場で確認すべき点を以下に整理する。
- 監査対象がLaravel 12または13であること。PHP 8.3未満ではcomposer install段階で失敗する。バージョン要件はcomposer.json側の宣言で早期に判明する。
- 日常的に利用しているエージェントが対応表に含まれているか。サポート対象はリポジトリ側で明示されている。
- SARIF出力の取り込み先が確保されているか。GitHub Code Scanning等と連携させる前提なら、出力スキーマと閾値設計を事前に検証する必要がある。SARIFインライン表示の前提条件として、リポジトリのActions権限を確認しておくと運用開始時の手戻りを避けられる。
--applicableの挙動がComposer依存の更新サイクルに追随するか。依存構成の変化に応じて除外ルールが正しく更新されるか、運用設計と併せて確認する。- ルールカタログが早期開発段階である点を踏まえ、CIブロックの閾値は保守的に設定する。criticalのみをfail条件にし、warning以下はレビュー補助として扱う構成が妥当と判断する。
- 既存の静的解析ツールと役割が重複しないか確認する。出力ファイルを並列に評価する前提で段階的に導入するのが現実的である。
ソースコードとドキュメントはGitHub上で公開されている。監査ルールの妥当性は実プロジェクトでの並行検証で評価するのが妥当である。
seoTitle: Laravel AuditorでAIエージェントに監査を任せる新パッケージ
metaDescription: Laravel AuditorはAIエージェントに監査手順を注入する新パッケージ。75ルールとMCP経由で構造化データを収集する設計。