LaravelのAI機能が本番運用に入ると、コスト可視化・テスト課金・無断利用・露出・安全対策が急に現実問題になります。
Boost、MCP、AI SDK、Prism、LarAgentまで入れて「よし、動いた」で終わらない。むしろ、そこからが長い。静かに、でも確実に。API請求、CIの実行回数、外部エージェントのアクセス、そしてユーザー入力の“地雷”。そういう運用の話に寄った、ニッチ寄りの5パッケージ(June–July 2026に最近リリース/注目)を整理します。広くはまだ語られていない、という前提の温度感もそのまま。
本番運用後に増える「5つの問い」と、対応するパッケージ
本番トラフィックが乗ると、AI機能は「動くか」より「制御できるか」が論点になります。
ざっくり言うと、悩みは5方向に割れます。コスト、構造、アクセス、露出、セキュリティ。で、対応はこう。
コスト可視化:USAIGE(AI SDKのobservability、run単位で記録)
プロンプト/処理の構造化:Laravel AI Tasks(task classes、実行モード、監査/予算/ダッシュボード)
外部AIエージェント向けの課金アクセス制御:Laravel MPP(Machine Payments Protocol (MPP)、HTTP 402 Payment Required)
AI回答での露出(GEO):Laravel AIGEO(Generative Engine Optimization (GEO)、JSON-LD、llms.txt、feed)
プロンプト防御:Intercept(PromptInjectionGuard / PIIRedactor、prompt injectionとPII対策)
同じ「LaravelのAI」でも、刺さる場所が違う。ここ、混ぜると判断が鈍るやつです。
1. USAIGE:API請求に不意打ちされないためのobservability
USAIGEはLaravel AI SDKにobservabilityを付与し、AIリクエストをrunとして記録してコスト内訳をダッシュボードで可視化します。
本番でいちばん最初に刺さるのが、「今月いくら使った?」問題。hello worldの段階だと雑に流せるけど、トラフィックが乗ると逃げられない。USAIGEは、各AIリクエストをrunとして扱い、token counts、cost、providerとmodel、timing、error statusまで記録してくれます。
軽い統合、というのもポイント。global helpersが2つで、ai_run()で追跡コンテキストを開いて、ai_usage()でSDKレスポンスの消費を記録する、という形。
composer require laraveljutsu/usaige
php artisan migrate
基本形はこう。
$run = ai_run('generate-instagram-caption');
$response = Ai::text('Write a caption for an article about TypeScript 7.0');
$usage = ai_usage($run, $response);
テナント(tenant)や複数クライアントを抱える想定もあり、runにarbitrary metadataを付けられます。こういうの、後から必要になるやつ。
$run = ai_run('generate-report', metadata: [
'tenant_id' => $tenant->id,
'ticket' => 'PROJ-1042',
]);
ダッシュボードは/usaigeに自動登録。feature / user / modelごとの内訳を見られるので、独自の追跡UIを一から作る必要が薄くなります。
なお、composer表記はlaraveljutsu/usaige、リンクはludoguenet/usaigeになっているので、検索/社内共有時は両方の文字列を控えておくのが無難です(事実として併記されている、という意味)。
Package link: https://github.com/ludoguenet/usaige
2. Laravel AI Tasks:プロンプトがControllerに散らばるのを止める
Laravel AI TasksはAI処理をtask classesとして定義し、synchronous/queue/streamingで統一実行しつつ監査・予算・ダッシュボードも提供します。
要するに、AIの仕事を「再利用可能な単位」に畳む。summarizing、ticket classification、content generation……種類が増えると、Controller直書きはすぐ破綻します。Laravel AI TasksはLaravel AI SDKをtransport layerとして使い、その上に運用の部品を積むタイプ。
Reusable task classes:1クラスにprompt、system message、post-processingを束ねる
Three execution modes:synchronous / queued / streaming(chunk callbacks)
Cost tracking and budgets:per-tenant budgetsで月次上限を置ける
Idempotent queued tasks:重複dispatchがdeduplicatedされ、二重実行を避ける
composer require fomvasss/laravel-ai-tasks
task定義例(そのまま)。
namespace App\Ai\Tasks;
use Laravel\Ai\Messages\UserMessage;
use Fomvasss\AiTasks\DTO\AiPayload;
use Fomvasss\AiTasks\DTO\AiResponse;
use Fomvasss\AiTasks\Tasks\AiTask;
class SummarizeTask extends AiTask
{
public function __construct(private readonly string $text) {}
public function modality(): string { return 'text'; }
public function toPayload(): AiPayload
{
return new AiPayload(
modality: $this->modality(),
messages: [new UserMessage("Summarize: {$this->text}")],
systemPrompt: 'Reply in 3 sentences max.',
options: ['temperature' => 0.3],
);
}
public function postprocess(AiResponse $response): AiResponse|array
{
return $response;
}
}
実行は3モード。必要な運用形態に寄せられるのが、現場っぽい。
use Fomvasss\AiTasks\Facades\AI;
// Synchronous
$response = AI::send(new SummarizeTask($text));
// Queued
$runId = AI::queue(new SummarizeTask($text));
// Streaming
$response = AI::stream(new SummarizeTask($text), function (string $chunk) {
echo $chunk;
});
パイプライン内に「異なる種類のAI作業」が複数あるなら、ここで形式を揃える価値が出ます。逆に、単発1種類だけなら、重さを感じる可能性はある。そこはチームの事情。
Package link: https://github.com/fomvasss/laravel-ai-tasks
3. Laravel MPP:他のAIエージェントに「払ってから来て」を言う
Laravel MPPはMachine Payments Protocol (MPP)を実装するmiddlewareで、保護ルートに対しHTTP 402 Payment Requiredとsigned challengeを返して支払い可能なエージェントだけ通します。
ちょっと変わり種。でも、今後重要になりそう、という位置づけは分かる。AIエージェントが他人のAPIを叩きに来る世界だと、運用コストが高いAPIほど「無料で吸われる」リスクが増える。そこでLaravel MPP。
フローは抽象的に見えやすいので、言葉を揃えて書くとこうです:
保護ルートにアクセスが来る
サーバーがHTTP 402 Payment Requiredを返し、signed challengeを提示する
支払い可能なエージェントは、対応するpayment railでチャレンジを満たす
エージェントがリトライし、通る
人間向けチェックアウトではなく、「AIエージェントが読んで自動で払えるpaywall」という説明が近い。
composer require square1/laravel-mpp
php artisan vendor:publish --tag=mpp-config
ルートに価格を付ける最小例。
Route::get('/resource', MyPaidResource::class)
->middleware('mpp:0.50,USD');
1回の支払いで複数回アクセス(例:10 requests)をカバーしたい場合は、controller methodに属性を追加。
#[RequiresPayment(amount: '5.00', currency: 'USD', grants: 10)]
public function report()
{
// ...
}
支払い後はレスポンスにPayment-Session headerが含まれ、quotaが尽きるまで再支払いなしで再利用できます。
まだpreviewで、API may still change。なので「今すぐ本番で固定」と言い切るより、「こういう設計を視野に入れる」用途が合う、という温度感が近いです。
Package link: https://github.com/square1-io/laravel-mpp
4. Laravel AIGEO:GoogleだけでなくAI回答で見つけてもらう(GEO)
Laravel AIGEOはEloquentモデルにGEOプロフィールを付与し、JSON-LDやllms.txt、ai-product-feed.jsonを生成してAIクローラに認識されやすくします。
従来のSEOだけでは足りない、という問題意識がベース。ChatGPT、Gemini、Perplexityに直接聞く動線が増えると、「検索結果に出る」以外の戦いが始まる。Laravel AIGEO(Hitesh Zope)は、GEO(Generative Engine Optimization)の道具をLaravelアプリ内に持ち込み、glue codeを増やしすぎずに整える方向。
やることは割と素直で、対象のEloquentモデルにHasGeoProfile traitを付けて、geoProfile()を実装します。
use Hszope\LaravelAigeo\Traits\HasGeoProfile;
class Article extends Model
{
use HasGeoProfile;
public function geoProfile(): array
{
return [
'name' => $this->title,
'description' => $this->excerpt,
'url' => url("/articles/{$this->slug}"),
'author' => $this->author->name,
'attributes' => [
'Category' => $this->category->name,
],
];
}
}
Blade側はレイアウトにを置く。するとJSON-LDが注入され、LLMがクロール時に読める形になる、という設計。
運用上の“効くところ”はこの3つ。
geo:llms-txt:llms.txtを生成(AIクローラ向けのplain-text index)geo:feed:ai-product-feed.jsonを生成(LLM indexing向け、sitemap/RSSとは別物)GEO scoring dashboard:
/geoで0–100スコア(AI-signal completenessの欠落を監査)
composer require hszope/laravel-aigeo
ファイルとfeedを最新化するために、コマンドをスケジュール。
use Illuminate\Support\Facades\Schedule;
Schedule::command('geo:llms-txt')->daily();
Schedule::command('geo:feed')->daily();
ダッシュボードに出すモデルはconfig/geo.phpで制御できます。
'dashboard' => [
'enabled' => true,
'path' => '/geo',
'middleware' => ['web', 'auth'],
'models' => [
['model' => \App\Models\Article::class, 'label' => 'Articles'],
['model' => \App\Models\Product::class, 'label' => 'Products'],
],
],
注意点はシンプルで、auth middlewareでロックすること。監査データが見えるので、そこを開けっぱなしにしない。
Package link: https://github.com/GitHiteshZope/aigeo
5. Intercept:プロンプトが外部AIプロバイダに届く前のガード
InterceptはLaravel AI SDK向けのprompt middlewareで、prompt injectionやPII流出を検査・書換・拒否してリスクを下げます。
ユーザーが自由入力できるようになった瞬間、リスクが露骨になります。prompt injectionで指示を上書きされる。あるいは、メール、クレカ、API keyみたいな情報が貼られて、そのまま外部モデルへ飛ぶ。Interceptは、HTTP middlewareの発想をプロンプトに持ち込んで、エージェントとプロバイダの間に入ります。
ただし位置づけは明確で、これは防御の一層。既存のアクセス制御、入力検証、監査ログの代替ではありません。ここ、過信すると事故ります。
主役は2つのguard。
PromptInjectionGuardはregular expressionsでよくある操作パターンを検出し、agentの元の指示を上書きしようとする試みをフラグします。
namespace App\Ai\Agents;
use Laravel\Ai\Contracts\Agent;
use Laravel\Ai\Contracts\HasMiddleware;
use PromptPHP\Intercept\InjectionGuard\PromptInjectionGuard;
class ConciergeAgent implements Agent, HasMiddleware
{
public function middleware(): array
{
return [
new PromptInjectionGuard,
];
}
}
一致したときの挙動はaction optionで制御:block / log / warn / sanitize。
PIIRedactorはstructured personal dataを検出して書き換えます。現行バージョンは6種類:email、phone number、credit card(Luhn checkで検証)、IP address、API key、bearer token。
new PIIRedactor(
action: 'redact',
);
そして重要な仕様として、redactやmaskでも、credit cards / API keys / bearer tokensの3つは既定でblock-on-sight扱い(単に伏せるのではなく止める)。まあ、そうなるよね、という設計です。
composer require promptphp/intercept
全エージェントにデフォルトを適用したいなら、configをpublish。
php artisan vendor:publish --tag=intercept-config
2つのguardを組み合わせ、例外処理も含めた例(原文のまま)。
use PromptPHP\Intercept\InjectionGuard\PromptInjectionGuard;
use PromptPHP\Intercept\PIIRedactor\PIIRedactor;
use PromptPHP\Intercept\InjectionGuard\Exceptions\PromptInjectionGuardException;
class ConciergeAgent implements Agent, HasMiddleware
{
public function middleware(): array
{
return [
new PromptInjectionGuard(action: 'block'),
new PIIRedactor(
entities: ['email', 'phone'],
allowedDomains: ['developerawam.com'],
),
];
}
}
try {
$response = ConciergeAgent::prompt($message);
} catch (PromptInjectionGuardException) {
return response()->json([
'message' => 'Sorry, we could not process that message. Please rephrase and try again.',
], 422);
}
執筆時点でversion 0.1.4。まだearly softwareで、PHP 8.4+とlaravel/aiが必要です。成熟パッケージほどの網羅性がないのは自然、ただコンセプトはすでに堅い、という評価はそのまま受け取れる範囲。
Package link: https://github.com/promptphp/intercept
結論:本番では「速く作る」より「壊れずに回す」ための部品が増える
本番運用のLaravel AIでは、USAIGEでコストを可視化し、Laravel AI Tasksで処理を構造化し、Laravel MPPで無断利用を抑え、Laravel AIGEOでAI向け露出を整え、Interceptでprompt injectionとPII流出を減らします。
派手さはないけど、ここを押さえると運用の事故率が下がる。たぶん。で、逆に言うと、どれも「必要になるまで後回しにされがち」な領域です。必要になってから慌てると、移行コストが地味に効く。そういう種類の話でした。
