PHPにおけるAIエージェント・エコシステム：シンプルなOpenAI呼び出しからマルチエージェント基盤へ

Dev.to / 2026/5/31

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsTools & Practical UsageModels & Research

共有:

要点

過去2年で、PHPの中にAIエージェント開発のためのエコシステムが急速に形成され、単なるOpenAI API呼び出しから、メモリ・ツール・ワークフロー・オブザーバビリティを備えたマルチエージェント・システムへと発展しています。
AIエージェントの勢いは歴史的にLangChain、LangGraph、CrewAI、AutoGenのようなPythonプロジェクトに大きくありましたが、PHPでも並行してスタックが構築され、現在はより高い抽象度を扱えるようになってきています。
初期のPHP実装では、プロバイダーSDKの上に機能を手作業で組み立てる必要がありましたが、いまではモデルクライアントからマルチエージェントのオーケストレーション基盤まで、利用可能なツールが幅広く整っています。
この記事では、生産環境で求められる要件（複数モデル対応、プロバイダー切り替え、構造化出力、外部ツール呼び出し、コンテキスト／メモリ管理、トレーシング、多段ワークフローなど）が拡大しており、それがPHP向けの専門ライブラリ需要を押し上げている点を強調しています。
全体として、PHPのエコシステムが「モデル呼び出しの試作」から「エージェント基盤」へ移行していることは、成熟が加速していること、そして保守しやすく本番対応しやすいエージェント設計へと重心が移っていることを示しています。

過去2年間で、PHPエコシステム内におけるAI開発をめぐって、まるごと一つの産業が立ち上がりました。

かつてLLMの統合は、OpenAIのAPIを呼び出す数行のコードを書くようなものに見えていましたが、今日では開発者たちは、メモリ、ツール、ワークフロー、オブザーバビリティ、さらには専門性の異なるエージェントのチームまで備えた、フルフェッジのエージェントシステムを構築しています。

通常、人々がAI開発について語るときは、まずPythonの話になります。そしてそれには十分な理由があります。エコシステムには面白いプロジェクトがぎっしり詰まっています。LangChain、LangGraph、CrewAI、AutoGen——これまでの盛り上がりの大部分は、かなり長い間そこにありました。
しかし並行して、PHPでもまた別の興味深い物語が進行していました。

そしてそれは、私を本当にうれしくさせます。

ほんの数年前、PHP開発者は、プロバイダのSDKの上にすべてを手作業で組み上げる必要がありました。ですが今日では、既に、さまざまな抽象化レベルのツールが揃った完全なエコシステムがあります。モデルクライアントから始まり、マルチエージェントシステムを管理するためのプラットフォームに至るまでです。

この領域が今日どのように見えるのか、眺めてみましょう。

単一のモデルリクエストからフルフェッジのエージェントへ

歴史的には、すべて同じところから始まりました。
ほとんどすべてのAIプロジェクトは、だいたい次のようなものだったのです。

$response = $client->chat()->create([
    'model' => 'gpt-5',
    'messages' => [
        [
            'role' => 'user',
            'content' => 'Analyze the customer request'
        ]
    ]
]);

プロトタイプなら、これで十分すぎるほどです。

しかし、システムが実際にビジネス上の価値を提供し始めると、追加の要件が次々と現れます。

複数モデルへの対応
プロバイダを素早く切り替えられること
構造化された出力
外部ツールの呼び出し
メモリ管理
コンテキスト管理
リクエストのトレース
マルチステップ処理のオーケストレーション

ある時点で、LLMの周りを取り囲むコードが、ビジネスロジックそのものよりも場所を取っていると気づきます。

まさにそれが、PHPで特化したAIライブラリが現れ始めた理由です。
少し単純化すると、現代のエコシステムは3つの層に分けられます。

AI SDK
エージェントフレームワーク
エージェントプラットフォーム

層が上がるごとに、より多くのインフラ作業を担うようになります。

PHPにおける現代のAI開発エコシステムは、大まかに3つのレベルに分けることができます。SDKがモデルとのやり取りの問題を解決し、フレームワークがエージェントの構築を助け、プラットフォームがエージェント全体のインフラを管理します。

レベル1：AI SDK

ここが土台です。

AI SDKは、1つの問題を解決します。モデルとやり取りすることを便利にすることです。

エージェントを管理したり、ワークフローをオーケストレーションしたりはしません。責任は、リクエストを送ってレスポンスを受け取るところまでです。

OpenAI PHP

リポジトリ：https://github.com/openai-php/client
ステータス：アクティブ

PHP向けの公式OpenAIクライアントです。

本質的に、追加の抽象化なしでOpenAIプラットフォームと直接やり取りする最もストレートな方法、つまり低レベルSDKです。

以下へのアクセスを提供します。

Responses API
Chat Completions
Embeddings
Audio API
Image Generation
Fine-Tuning
Files API

典型的な例は、これ以上ないほどシンプルです。

$response = $client->responses()->create([
    'model' => 'gpt-5',
    'input' => 'Create a short summary of the customer request'
]);

echo $response->outputText;

このアプローチの利点は明白です。完全なコントロールが得られます。

デメリットも同様に明白です。

複数のモデルやプロバイダに対応する必要が生じた瞬間、必要な抽象化をすべて自分で作ることになります。

Prism

リポジトリ：https://github.com/prism-php/prism
ステータス：アクティブ

OpenAI PHPが単一のプラットフォームへアクセスすることに焦点を当てているのに対し、Prismは別の目標を念頭に作られました。複数のプロバイダに対する統一されたインターフェースを提供することです。
これはマルチプロバイダ向けのAI SDKです。
発想はシンプルです。ビジネスロジックは特定のモデルに依存すべきではない。
今日使うのがGPTで明日使うのがClaudeで、来月使うのがGemini——アプリケーションはその違いに気づく必要がありません。
例：
Prism::text()
->using('openai', 'gpt-5')
->withPrompt('Hello')
->generate();
モデルの切り替えは文字通り1行の変更だけです：
Prism::text()
->using('anthropic', 'claude')
->withPrompt('Hello')
->generate();
Prismは、追加機能のおかげで特に役立ちます。
構造化された出力
自由形式のテキストをパースする代わりに、期待する出力の構造を事前に定義できます。
たとえば：
class SentimentResult
{
public string $sentiment;
public int $score;
}
するとモデルは、厳密に定義された形式でデータを返します。
本番システムでは、生成されたテキストに対して正規表現を適用するよりもはるかに信頼性が高いです。
ツール
Prismはツール呼び出しをサポートします。
言い換えると、モデルがCRM、データベース、または外部APIを問い合わせる必要があるかどうかを、自分で判断できるということです。
これは「チャットボット」から「エージェント」への移行が始まる、まさにその地点です。
Embeddings
ほぼすべての現代的なRAGプロジェクトは、遅かれ早かれEmbeddingsを使うことになります。
Prismは、選択したプロバイダに関係なく、統一されたインターフェースを通じてそれらを生成できます。

Laravel AI
返却形式: {"translated": "翻訳されたHTML"}

Repository: https://github.com/laravel/ai
Status: アクティブ
おそらく、ここ数か月で現れた中でも最も興味深いプレイヤーでしょう。
Laravel AIは、人工知能に対して、Laravelがデータベース、キュー、インフラに対して行ったことを目指しています。
ここでの主なアイデアは、モデル対応ではありません。
主なアイデアは、AIをLaravelアプリケーションの自然な一部にすることです。
コードの感触は、すぐに馴染み深く感じられます：
$response = AI::chat()
->model('gpt-5')
->prompt('Create a short summary of the customer request')
->send();
しかし、真の価値はさらに深いところにあります。
AIは以下と自動的に統合します：
Queues（キュー）
Events（イベント）
サービスコンテナ
Logging（ログ記録）
Configuration（設定）
The scheduler（スケジューラ）

その結果、LLMはRedisやPostgreSQLと同じような、単なるもう一つのインフラ依存として感じられ始めます。

レベル2：エージェントフレームワーク
そして、ここから本当に面白いことが始まります。
なぜなら、モデルへのリクエストはまだエージェントではないからです。
たとえば、カスタマーサポートシステムを想像してみてください。
メッセージが届きます：
返金についてすでに3回連絡しました。誰も返信してくれません。
次に何が起こるでしょう？
実際には、システムには通常次のようなことが必要になります：
感情（センチメント）の判定
緊急度の評価
顧客情報の取得
サポート履歴の確認
返信の準備
結果の保存
すべてのアクションのログ記録

サービスを手作業で何十個も書くこともできます。
あるいは、エージェントフレームワークを使うこともできます。
実際のシステムでは、エージェントが単独で働くことはほとんどありません。通常は、コーディネータが現れて、専門化されたエージェントにタスクを分配し、その後それらの結果を1つの返信にまとめます。

Neuron AI
Repository: https://github.com/neuron-core/neuron-ai
Status: アクティブ
今日の時点で、これはPHPにおける最も成熟したエージェントフレームワークの一つです。
そのアプローチは本質的に別物です。
リクエストを記述するのではなく、開発者はエージェントを記述します：
$agent = Agent::make()
->name('SupportAgent')
->instructions('You are a customer support specialist');
その後、エージェントはタスクを受け取ります：
$result = $agent->run(
'Analyze the customer email'
);
一見すると、シンプルに見えます。
しかし、内部ではまったく別のインフラが現れます：
Memory（メモリ）
Workflows（ワークフロー）
Tools（ツール）
RAG（Retrieval-Augmented Generation：検索拡張生成）
Multi-agent systems（マルチエージェントシステム）
Observability（可観測性）
そしてそれ以上

哲学的には、このプロジェクトはPythonの世界のLangGraphと驚くほどよく似ています。
なぜメモリが重要になったのか
従来のLLMは次のように動作します：
リクエスト → レスポンス
一方、エージェントは別の形で動作します：
リクエスト
↓
メモリ
↓
ツール
↓
LLM
↓
結果
メモリにより、エージェントは過去のアクションや蓄積された文脈を考慮できます。
それがなければ、長時間にわたるビジネスプロセスは不可能です。
マルチエージェントシステム
また、ここ数か月のもう一つのトレンドは、ユニバーサルなエージェントからの移行です。
ますます多くのチームが専門的な役割を採用しています：
コーディネータ
|
+-- CRMエージェント
|
+-- 感情（センチメント）エージェント
|
+-- 返信エージェント
このアプローチは、実際のチームの構造によく似ています。
各エージェントは自分の領域を担当します。

LarAgent
Repository: https://github.com/maestroerror/laragent
Status: アクティブ
Neuron AIがユニバーサルなエージェントフレームワークを目指すのに対して、LarAgentは主にLaravel開発者に焦点を当てています。
Laravelの馴染み深い思想は、すぐに感じ取れます：
class SupportAgent extends Agent
{
protected string $instructions =
'You are a support specialist';
}
最小限のインフラコードと、最大限のLaravel統合。
多くのチームにとって、これはエージェント作業を始める最速の方法になるかもしれません。

PapiAI
Repository: https://github.com/papi-ai/papi-core
Status: アクティブ
比較的若いプロジェクトで、強い型付けとプロバイダ非依存性を重視しています。
アーキテクチャ的には、現代のPHP開発の実践をAIの世界に持ち込もうとする試みのように感じられます。
主要な焦点領域には以下が含まれます：
Types（型）
Contracts（契約）
Middleware（ミドルウェア）
Tools（ツール）
Structured responses（構造化されたレスポンス）

AIツールが徐々に、従来のPHPフレームワークのアーキテクチャ原則を継承していく様子を見るのは、とても興味深いです。

Atlas
Repository: https://github.com/atlas-php/atlas
Status: アクティブ
新世代のエージェントソリューションの別の代表例です。
このプロジェクトは、現代的な要件を見据えて構築されています：
Voice interfaces（音声インターフェース）
Multimodality（マルチモーダル）
Agents（エージェント）
Tools（ツール）
Tracing（トレーシング）
Monitoring（監視）

Atlasはまだ成熟した市場プレイヤーと呼ぶには早いものの、エコシステムがどちらの方向へ向かっているかをはっきり示しています。

レベル3：エージェントプラットフォーム
ある規模に達すると、新たな問題が出てきます。
課題はもはやエージェントを作ることではありません。
課題は、数十のエージェントを管理することになります。
疑問が生まれ始めます：
誰がタスクのルーティングを担当するのか？
レスポンスの品質はどう追跡するのか？
変更をどうテストするのか？
メモリをどう管理するのか？
失敗の根本原因をどう理解するのか？

ここでエージェントプラットフォームが登場します。

PromptlyAgent
Repository: https://github.com/promptlyagentai/promptlyagent
Status: アクティブ
このプロジェクトは、複雑なエージェントエコシステムの構築に焦点を当てています。
主な重点は以下です：
Visual orchestration（ビジュアルオーケストレーション）
Multi-agent workflows（マルチエージェントのワークフロー）
Tool integration（ツール統合）
Agent management（エージェント管理）

本質的には、個々のコンポーネントをプログラミングすることから、AIインフラ全体を管理することへの転換を意味しています。

Vizra ADK
Repository: https://github.com/vizra-ai/vizra-adk
Status: アクティブ
Laravelエコシステムからの、もう一つ興味深いプロジェクトです。
ほぼエージェントライフサイクル全体をカバーしています：
Development（開発）
Testing（テスト）
Memory（メモリ）
Workflows（ワークフロー）
Observability（可観測性）
Sub-agent interaction（サブエージェント間の相互作用）

業界のトレンドを見ると、このようなソリューションは徐々に次の抽象化レイヤーになりつつあります。

市場が向かっている先
興味深いことに、PHPは今、数年前のPythonとほぼまったく同じ道をたどっています。
進化の様子は次のように見えます：
ほぼすべてのAIプロジェクトは、同様の進化を経ます。まずは単純なモデル呼び出しから始まり、次にツールと構造化された出力が追加され、そして最終的には相互に作用するエージェントのネットワークへと成長します。皆が最初は単純なモデルリクエストから始めます。
Prism::text()
->using('anthropic', 'claude')
->withPrompt('Привет')
->generate();
その次にツールが来ます。
次にメモリです。
その次にワークフローです。
その後、専門化されたエージェントが必然的になっていきます。
そして最後に、「このすべてのインフラをどうにかして管理する必要がある」という現実に気づきます。
そのため、オーケストレーションやエージェント管理のプラットフォームは、現在SDKそのものよりも速く進化しています。

結論
数年前は、PHPにおけるAIに関する会話は、通常「OpenAIを呼び出すためにどのHTTPクライアントを使うべきか」という議論で終わっていました。
しかし、今日の状況はまったく別物に見えます。
エコシステムには、ほぼすべての複雑さのレベルに対するソリューションがすでに揃っています：
OpenAI PHPとPrism（モデルとのやり取り）
Laravel AI（Laravelアプリケーション内での深いAI統合）
Neuron AI、LarAgent、PapiAI、Atlas（エージェントの構築）
PromptlyAgentとVizra ADK（複雑なエージェントシステムの管理）

そして、これが始まりにすぎないように思えます。
開発者が一度 API、サービス、キューを設計したことがあるなら、今後の数年でますますエージェント、彼らのメモリ、ツール、そしてそれらが互いにどのようにやり取りするかを設計することになるでしょう。
すでに、単一のモデル呼び出しが徐々に新しい「関数」へと変わりつつあり、一方でエージェントが新しい「サービス」になりつつあることが明らかになってきています。
そのため、PHP AIエコシステムの能力を理解することは、次世代のAIプロダクトを構築することを計画するあらゆるバックエンドエンジニアにとって、不可欠なスキルになりつつあります。
これらの変化に備えていますか？
もしPHPにおけるAIに興味があるなら、私の無料の書籍「AI for PHP Developers: Intuitively and Practically」を通じて、このトピックをさらに深掘りできます。