Symfony

PHPプロジェクトが持つデータやロジックをAIに公開し、エージェントが自律的に活用できる仕組みを構築したい——そんなニーズに応えるのがMCP（Model Context Protocol）サーバーです。2025年9月にPHP公式SDKがリリースされ、さらにLaravel 12.xでも公式サポートが追加されたことで、PHPエンジニアがMCPサーバーを構築するハードルは大幅に下がりました。 PHPでMCPサーバーを実装するには、大きく3つの選択肢があります。フレームワーク非依存の公式SDK（mcp/sdk）、Laravelエコシステムに統合されたlaravel/mcp、そしてComposerすら使わない**素のPHP（Vanilla PHP）**による最小実装です。プロジェクトの規模や技術スタックに合わせて最適な手段を選べます。 MCPの基本構造をPHP視点で整理する MCPはAnthropicが策定したオープンプロトコルで、AIアプリケーション（クライアント）と外部システム（サーバー）を標準的なインターフェースで接続します。公式サイトでは「AIアプリケーション向けのUSB-Cポート」と表現されています（出典: modelcontextprotocol.io）。 MCPサーバーが提供できる機能は、3つのプリミティブに分類されます。 プリミティブ 役割 PHPでの利用例 Tools LLMが能動的に呼び出す関数 DB検索、API呼び出し、ファイル操作 Resources URIで特定される読み取り専用データ 設定値、ドキュメント、ログ Prompts 再利用可能なプロンプトテンプレート コードレビュー指示、翻訳指示 通信方式（トランスポート）は3種類あり、プロトコルバージョン2025-03-26でStreamable HTTPが導入されました。最新のプロトコルバージョンは2025-11-25で、実験的なTasksプリミティブやOAuth 2.1のRFC 9728準拠などが追加されています（出典: MCP Changelog）。 トランスポート 通信方式 特徴 stdio 標準入出力 ローカル接続向け。Claude Desktop等が直接プロセスを起動 HTTP+SSE HTTP + Server-Sent Events ネットワーク越し通信対応。現在は後方互換のため残存 Streamable HTTP HTTP ストリーミング 再接続可能で新規プロジェクト推奨。ステートレス運用が可能 PHPで選べる3つのMCPパッケージ PHP向けのMCPサーバー実装は複数存在します。主要な3パッケージの違いを整理します。 項目 mcp/sdk（公式SDK） laravel/mcp（Laravel公式） Vanilla PHP（SDKなし） 開発元 Symfony / PHP Foundation / Anthropic Laravel（Taylor Otwell） 自前実装 PHPバージョン 8.1以上 8.2以上 制限なし（推奨8.1+） フレームワーク依存 なし Laravel 11以上 なし インストール composer require mcp/sdk composer require laravel/mcp Composer不要 ツール定義方式 PHP 8 Attributes Artisanスキャフォールド JSON-RPCハンドラ直書き stdio対応 あり あり（Artisanコマンド経由） あり Streamable HTTP あり あり（Webトランスポート） 自前実装が必要 認証機能 なし（自前実装） OAuth 2.1 / Sanctum内蔵 なし 向いているケース フレームワーク非依存で汎用的に使いたい Laravelプロジェクトへの統合 MCPプロトコルの学習、最小構成 コミュニティ発のphp-mcp/serverおよびphp-mcp/laravelも存在しますが、公式SDKのリリース後はメンテナンス体制の観点から上記3パッケージのいずれかを推奨します。 ...

レイヤードアーキテクチャとは — MVCとどう違うのか レイヤードアーキテクチャは、アプリケーションを責務ごとに水平な層（Layer）へ分割する設計手法です。一般的には次の4層で構成されます。 層 責務 依存方向 Presentation HTTPリクエスト・レスポンスの変換、入力バリデーション 下の層のみ参照 Application (UseCase) ユースケース単位のオーケストレーション Domain 層を利用 Domain ビジネスルール、エンティティ、値オブジェクト 外部依存なし Infrastructure DB接続、外部API通信、メール送信 Domain 層のインターフェースを実装 MVCは「リクエスト → Controller → Model → View」というデータフローを定義しますが、「Model」が担う範囲が曖昧です。ORMのクエリビルダ、ビジネスルール、外部API呼び出しが同じModel内に混在し、数千行のFat Modelが生まれる原因になります。 レイヤードアーキテクチャはModelの内部をApplication・Domain・Infrastructureの3層に分解し、それぞれの責務境界を明確にします。MVCを否定するのではなく、MVCの「M」を精緻化する位置づけです。 PHPの言語特性がレイヤード構造に与える影響 PHPでレイヤードアーキテクチャを採用する場合、言語そのものの特性が設計にどう作用するかを把握しておく必要があります。 動的型付けとインターフェース設計 PHPは動的型付け言語ですが、interface・abstract class・type hintを備えています。レイヤードアーキテクチャではDomain層にインターフェース（Repository契約など）を定義し、Infrastructure層で実装する「依存性の逆転」が核になります。 // Domain層: app/Domain/Repository/UserRepositoryInterface.php namespace App\Domain\Repository; use App\Domain\Entity\User; interface UserRepositoryInterface { public function findById(int $id): ?User; public function save(User $user): void; } // Infrastructure層: app/Infrastructure/Persistence/EloquentUserRepository.php namespace App\Infrastructure\Persistence; use App\Domain\Entity\User; use App\Domain\Repository\UserRepositoryInterface; use App\Infrastructure\Persistence\Eloquent\UserModel; class EloquentUserRepository implements UserRepositoryInterface { public function findById(int $id): ?User { $record = UserModel::find($id); if ($record === null) { return null; } return new User($record->id, $record->name, $record->email); } public function save(User $user): void { UserModel::updateOrCreate( ['id' => $user->getId()], ['name' => $user->getName(), 'email' => $user->getEmail()] ); } } PHPのインターフェースはJavaやC#と同等の抽象化機構を提供するため、「依存性の逆転」を言語レベルで実現できます。ただし、型の強制力はコンパイル言語より弱いため、静的解析ツール（PHPStan・Psalm）を併用してレイヤー間の依存違反を検出する運用が有効です。 ...