neuron-ai を採用する前に確認すべきこと：PHP 8.1 でエージェントを組むための設計と制約
The Agentic Framework of the PHP ecosystem to build production-ready AI driven applications. Connect components (LLMs, Tools, vector DBs, memory) to agents that interact with your data and UI.
ひと目でわかる
- これは何？
- PHP のエージェントフレームワーク neuron-ai は、LLM・ツール・メモリ・ベクター DB を Agent クラスに束ね、Workflow と human-in-the-loop まで一貫して扱う。MIT ライセンスで配布される 3.x 系の実装を、ドキュメントと README から読み解く。
- 誰に向いている？
- 既存の PHP アプリケーションにエージェント機能を足したい、あるいは Workflow と human-in-the-loop を最初から前提にした設計を組みたいチームには候補になる。逆に Python 側にすでにエージェント基盤があり、PHP は API を返すだけの層でよいなら、ここで新しい抽象を覚える理由は薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に PHP です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
neuron-ai が埋めようとしている穴は PHP 側の空白地帯
README は、これから作るアプリケーションは「エージェントとして生まれる」という前提から書き出されている。つまり Web アプリに AI 機能を後付けするのではなく、エージェントがアーキテクチャそのものになるという立場だ。そのために必要になる基礎として README が挙げるのは、チェックポイント付きのイベント駆動ワークフロー、human-in-the-loop の割り込み、マルチエージェントの編成、AG-UI や Vercel AI SDK プロトコルでのストリーミング、MCP、非同期実行である。
問題は、この一式が PHP 側にまとまって存在しないことだ。README は「PHP エコシステムでは、この基礎の組が一か所に存在する」と主張し、それぞれをドキュメントの章立てに対応させている。対象読者は、Laravel や Symfony で業務システムを書いてきた PHP 開発者で、Python に処理を逃がさずにエージェント機能を実装したい層になる。逆に、すでに Python でエージェントを運用しているチームが PHP 側にも同じものを立てる理由は、この README からは読み取れない。
Agent クラスを継承するという設計判断
中心にあるのは Agent クラスで、これを継承して使う。README の例では DataAnalystAgent が Agent を extends し、provider() と instructions() の 2 つを protected メソッドとして実装する。provider() は AIProviderInterface を返し、例では Anthropic を new Anthropic(key: 'ANTHROPIC_API_KEY', model: 'ANTHROPIC_MODEL') として組み立てる。instructions() は文字列を返すだけで、ここに役割を書く。
この形の意味は、メモリ、ツール、RAG といった仕組みを Agent 側が引き受ける点にある。README は「このクラスはメモリ、ツール、RAG に至るまで、いくつかの高度な機構を自動で管理する」と説明している。会話の記憶はこの層で保持されるため、chat() に UserMessage を渡すだけで文脈が続く。README の例では、名前を伝えた次の呼び出しで名前を返している。
設定をメソッドとして書く方式なので、DI コンテナや設定ファイルとどう接続するかは開発者側の設計になる。ここはドキュメントが示す範囲では自由度が高く、逆に言えば規約が弱い。
導入は composer と make:agent の 2 コマンドから
導入手順は README に明示されている。まず composer require neuron-core/neuron-ai を実行する。次に vendor/bin/neuron make:agent DataAnalystAgent で Agent の雛形を生成する。生成されたクラスに provider() と instructions() を書き、最後に DataAnalystAgent::make() でインスタンス化して chat() に UserMessage を渡す。
環境変数として README に出てくるのは、Anthropic の key と model、そして監視用の INSPECTOR_INGESTION_KEY である。監視を使う場合、README は「アプリケーションの環境ファイルに INSPECTOR_INGESTION_KEY を設定すれば、Inspector のダッシュボードでエージェントの実行タイムラインが見える」としている。監視基盤が Inspector 前提で書かれている点は、後述するように採用判断の分かれ目になる。
要件として README が挙げるのは PHP ^8.1 のみで、拡張モジュールや外部ミドルウェアの指定はこの抜粋には出てこない。ベクター DB を使う場合の個別要件は、この材料からは確認できない。
Workflow と human-in-the-loop が同じ抽象に乗っている
README が繰り返し述べるのは、getting started で最初のエージェントを動かす Workflow が、そのまま状態・ループ・人間の承認を含むマルチエージェント構成を本番で動かす Workflow でもあるという点だ。学習した内容がそのまま次のプロジェクトで使える、という主張である。
実務的に効くのは human-in-the-loop の位置づけだ。エージェントの実行を途中で止めて人間の承認を挟む処理は、多くの場合アプリケーション側に独自実装が生える。それがフレームワークの一章として用意されているなら、承認待ちの状態をどう保持するかという設計をゼロから決めずに済む。ただし、この抜粋には承認フローの具体的な API や永続化の方式までは書かれていない。チェックポイント付きイベント駆動とだけ述べられており、状態をどこに保存するのかは docs.neuron-ai.dev の workflow 章を確認する必要がある。ここは README だけでは判断できない部分だ。
MCP とストリーミングは対応プロトコルを選ぶ話になる
README は MCP コネクタと、AG-UI および Vercel AI SDK プロトコルでのストリーミングを機能として挙げている。ストリーミングは「Stream Adapters」としてドキュメントの章が割り当てられており、UI 側のプロトコルに合わせてアダプタを選ぶ形だと読み取れる。
ここで注意したいのは、これらが抽象化ではなくプロトコルへの適合だという点だ。AG-UI や Vercel AI SDK のプロトコルに乗るということは、フロントエンドの実装がある程度その形に寄るということでもある。独自の UI を持っていて、トークンを独自の WebSocket メッセージとして流したい場合、アダプタがそのまま使えるかは別途確認が要る。MCP についても、接続するサーバー側の実装が前提になる。README の範囲では、どの MCP サーバーが動作確認済みかは分からない。
機能一覧として読むと充実して見えるが、実際の採用判断では「自分の UI と MCP サーバーがこの適合リストに入るか」を先に確かめるほうが早い。
監視が Inspector 前提である点は賛否が分かれる
README の Monitoring 章は、AI エージェントが確率的な存在であることを正面から認めている。同じ入力でも同じ出力にならないため、再現性、バージョニング、デバッグが実際の問題になる。複数の LLM 呼び出し、ツール使用、外部メモリへのアクセスが絡むと、何をなぜしたのかを追う必要が出てくる。この問題設定自体は妥当だ。
ただし解決策として README が示すのは Inspector への送信である。INSPECTOR_INGESTION_KEY を設定すれば実行タイムラインが見える、という流れで、自前の OpenTelemetry バックエンドや既存の APM にどう流すかは、この抜粋からは読み取れない。すでに Datadog や New Relic で運用を統一している組織にとっては、監視のためだけに別サービスを足す判断が必要になる。ここは採用の障壁になりうる箇所で、README が「最良の方法は Inspector だ」と書いている以上、他の選択肢の情報は公式ドキュメント側で探すことになる。
もう一点、この章は README 全体の中で最も説明的で、逆に具体的な API が最も少ない。計測を自分で仕込みたい開発者にとっては物足りない。
向かないケースと、代わりに検討する構成
このフレームワークが向かないのは、まず PHP 8.1 未満で動いているアプリケーションだ。要件が ^8.1 と明記されているため、そこは交渉の余地がない。次に、エージェントをバッチ処理として一度だけ走らせればよく、会話の記憶もツール呼び出しも不要な場合。Agent クラスを継承して provider() と instructions() を書くより、HTTP クライアントで API を直接叩くほうが短く済む。
もうひとつの対照は、Python 側にすでにエージェント基盤がある構成だ。その場合、PHP 側は API を公開してキューに積むだけの層に留め、推論とツール実行は Python に任せる設計のほうが、状態管理の二重化を避けられる。neuron-ai を選ぶという判断は、PHP プロセスの中でエージェントのループを回し、その状態も PHP 側で持ちたいという意思表示になる。
Workflow と human-in-the-loop を必要としないなら、このフレームワークの主要な価値の一部は使われないまま残る。逆にそこが要件の中心なら、同じ抽象が最初から最後まで使える点が効いてくる。
MIT ライセンスと 3.x 系の更新頻度
ライセンスは MIT で、リポジトリはアーカイブされていない。デフォルトブランチは 3.x で、直近のリリースは 3.16.12、3.16.11、3.16.10 と、2026 年 9 月に数日間隔で並んでいる。パッチ番号が細かく上がる運用で、破壊的変更はマイナー側に寄せられていると推測できるが、これはリリース番号の並びからの推測であって、互換性ポリシーを明記した記述はこの材料にはない。
MIT なので、ソースを改変して自社サービスに組み込むことも、商用利用も許される。ただしライセンス文の保持は条件になる。ここから先は法的判断ではなく実務上の注意だが、同梱の依存パッケージのライセンスは別々に確認する必要がある。
更新コストの面では、3.x 系の中で追従する限りは composer update で済む範囲に見える。問題は 3.x から次に移るタイミングで、Workflow や Agent の抽象に手を入れていれば影響範囲が読めないことだ。この点は公式ドキュメントのアップグレードガイドの有無を確認してから判断したい。
編集部の結論
既存の PHP アプリケーションにエージェント機能を足したい、あるいは Workflow と human-in-the-loop を最初から前提にした設計を組みたいチームには候補になる。逆に Python 側にすでにエージェント基盤があり、PHP は API を返すだけの層でよいなら、ここで新しい抽象を覚える理由は薄い。導入前に確認するのは 3 点で、PHP が ^8.1 を満たすこと、composer require neuron-core/neuron-ai で入る依存が既存のフレームワークと衝突しないこと、そして監視を Inspector に寄せるなら INSPECTOR_INGESTION_KEY を環境変数として管理できることだ。
コミュニティノート