こんにちは、かつコーチです。
「LaravelにAIを組み込みたいけど、何から手をつければいいか分からない」。
そんな相談を最近よく受けます。
この記事では、LaravelアプリにLLM（大規模言語モデル。文章を理解し、文章で応答するAI）を導入する意味と、代表的な活用パターンを整理します。
さらに、これから全15本でお届けするシリーズ全体の見取り図もお見せします。
読み終える頃には、自分のアプリにどのパターンが合いそうか、イメージが掴めるはずです。
LLM導入とは？
専門用語の整理
まず用語を揃えておきます。
LLM（Large Language Model）とは、大量の文章データを学習し、人間のような自然な文章を生成できるAIモデルのことです。
OpenAIのGPTシリーズやAnthropicのClaudeシリーズが代表例です。
API連携とは、外部サービスの機能を自分のアプリから呼び出す仕組みのことです。
LLMの場合、LaravelアプリからOpenAIやAnthropicのサーバーにHTTPリクエストを送り、応答を受け取ります。
なぜLaravelにLLMが必要なのか
Laravelは日本国内でも受託・自社開発を問わず広く使われているフレームワークです。
そこにLLMを組み込むことで、これまで人手に頼っていた作業を自動化できます。
たとえば、問い合わせフォームの一次対応、大量の社内文書からの情報検索、レビュー文の自動要約などです。
これらは「文章を理解して、文章で返す」という作業なので、LLMが最も得意とする領域です。
私が最初にLLMをLaravelアプリに組み込んだのは、社内の問い合わせ管理システムでした。
それまでは担当者が一件ずつ内容を読んで振り分けていたのですが、LLMに一次分類をさせるだけで、対応時間が体感で半分近くになりました。
LLM導入で解決できる典型的な課題
問い合わせ対応の自動化
サポート窓口に届く質問の多くは、実はFAQで解決できる内容です。
LLMにFAQデータを渡し、ユーザーの質問に対して自動応答させることで、担当者の負担を減らせます。
社内文書検索
社内マニュアルや議事録が増えてくると、キーワード検索だけでは欲しい情報にたどり着けなくなります。
後述するRAG（検索拡張生成）を使うと、自然な言葉で質問して、根拠となる文書付きで回答を得られます。
コンテンツ生成・レビュー・要約
ブログの下書き生成、商品レビューの要約、長文議事録の3行まとめなど、文章を「短くする」「増やす」作業もLLMの得意分野です。
人間は最終チェックに専念できるようになります。
Laravelアプリに組み込む代表的なパターン
パターン1：チャット機能
Webサイトにチャットウィジェットを設置し、ユーザーの質問にリアルタイムで応答するパターンです。
LaravelのコントローラーからLLMのAPIを呼び出し、レスポンスを画面に表示します。
// app/Http/Controllers/ChatController.php
public function ask(Request $request)
{
$answer = Ai::make()
->prompt($request->input('question'))
->generate();
return response()->json(['answer' => $answer->text]);
}
パターン2：バックグラウンドでの自動処理
ユーザーを待たせたくない処理は、Laravelのキュー（処理を非同期で順番に実行する仕組み）に投げます。
たとえば「新規投稿を要約してSlackに通知する」といった処理は、キュージョブとして実装すると相性が良いです。
// app/Jobs/SummarizePost.php
public function handle(): void
{
$summary = Ai::make()
->prompt("次の文章を3行で要約してください: {$this->post->body}")
->generate();
$this->post->update(['summary' => $summary->text]);
}
パターン3：RAGによる検索拡張
RAG（Retrieval-Augmented Generation）とは、「カンニングペーパーを渡してから質問に答えてもらう」仕組みです。
社内文書などを事前に検索し、関連する部分だけをLLMに渡すことで、正確で根拠のある回答を引き出せます。
このパターンはシリーズ後半で、embedding（文章の意味を数値化した地図上の座標）の解説とあわせて詳しく扱います。
つまずきやすいポイント
Before：とりあえずAPIを叩いてみた結果
最初にAPIを直接叩いて試したとき、レスポンスが返ってくるまで数秒〜十数秒かかることに驚きました。
同期処理のコントローラーでそのまま実装したところ、Webサーバーのタイムアウト設定に引っかかり、504エラーが頻発しました。
Gateway Timeout: The server didn't respond in time.
After：非同期処理に切り替えて解決
原因は、LLMのレスポンス時間を考慮せずに同期処理で実装していたことでした。
チャットのようにリアルタイム性が必要な場合はストリーミング応答、そうでない場合はキュージョブに逃がすことで解決しました。
この「同期か非同期か」の見極めは、これから紹介する全パターンで共通して重要な設計判断になります。
応用・一歩先の使い方
慣れてきたら、複数のLLMプロバイダーを使い分けることも検討してみましょう。
簡単な分類タスクは軽量で安価なモデル、複雑な文章生成は高性能なモデルというように、コストと精度のバランスを取れます。
また、ユーザーごとの会話履歴を保存し、文脈を踏まえた応答をさせる「メモリ」機能も、シリーズ後半で扱う予定です。
まとめ
この記事のポイント
- LLMは「問い合わせ対応」「文書検索」「コンテンツ生成・要約」などの課題解決に向いている
- Laravelへの組み込みは「チャット」「バックグラウンド処理」「RAG」の3パターンが代表的
- 同期処理でLLM呼び出しを実装するとタイムアウトしやすいので注意する
- このシリーズは全15本でLaravel×LLMの基礎から応用までを扱う
コメント