Next.js
Firebase毎朝メールを開くと、問い合わせフォームからの通知が10件、20件と溜まっている。内容を読み、過去の対応履歴を探し、文面を考えて返信する。この繰り返しが、気づけば午前中の大半を占めている——そんな状況に心当たりのある方は少なくないのではないかと思います。
とくに情シスや現場責任者の方にとって、問い合わせ対応は「誰かがやらなければならないが、本来やりたい業務ではない」タスクの代表格かもしれません。かといって人を増やす余裕があるわけでもなく、外注すれば自社の文脈が伝わりにくい。
私たちゼットリンカーでも、この課題に向き合うなかで「一次返信の下書きをAIに任せる」という設計を試行してきました。本記事では、Next.js 16とOpenAI APIを使った一次返信の自動化について、設計の考え方と注意点をお伝えします。
一次返信の自動化で何が変わるか？
問い合わせ対応の業務を分解すると、大きく3つのフェーズに分かれます。
- 受信・分類: 問い合わせ内容を読み、カテゴリや緊急度を判断する
- 一次返信: 受け付けた旨の連絡と、初期対応の案内を送る
- 本対応: 調査・回答・フォローアップを行う
このうち、もっとも定型化しやすいのが「一次返信」です。ここをAIで下書き生成できるようにすると、担当者が毎回ゼロから文面を組み立てる時間が減ります。
ただし、一次返信の自動化は「対応品質を上げる」というよりも「対応開始までの時間を縮める」施策だという点は強調しておきたいです。品質を担保するのは、あくまで最終的に確認する人間の目です。
Next.js × OpenAI API での設計パターン
全体の流れ
問い合わせ受信（Firebaseに保存）
↓
管理画面で一覧表示
↓
担当者が「下書き生成」ボタンを押す
↓
Route HandlerがOpenAI APIを呼び出し
↓
ストリーミングで下書きを返却
↓
担当者が確認・修正して送信
ポイントは、問い合わせが届いた瞬間に自動で返信するのではなく、担当者のアクションをトリガーにしていることです。
Route Handlerでの実装
// app/api/draft-reply/route.ts
import { NextRequest } from "next/server";
import OpenAI from "openai";
const openai = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
});
export async function POST(request: NextRequest) {
const { inquiryContent, category } = await request.json();
const stream = await openai.chat.completions.create({
model: "gpt-5.6-luna",
stream: true,
messages: [
{
role: "system",
content: `あなたは企業の問い合わせ対応担当です。
丁寧だが簡潔に一次返信の下書きを作成してください。
回答の確約はせず「確認のうえ改めてご連絡します」と案内してください。
カテゴリ: ${category}`,
},
{ role: "user", content: inquiryContent },
],
});
const encoder = new TextEncoder();
const readable = new ReadableStream({
async start(controller) {
for await (const chunk of stream) {
const text = chunk.choices[0]?.delta?.content || "";
controller.enqueue(encoder.encode(text));
}
controller.close();
},
});
return new Response(readable, {
headers: { "Content-Type": "text/plain; charset=utf-8" },
});
}
モデルには、2026年7月時点のOpenAI現行世代であるGPT-5.6のうち、分類や軽量な下書き生成に向いた低コストティアの gpt-5.6-luna を指定しています（OpenAI公式発表）。一次返信の下書きが目的であれば、上位ティア（Sol / Terra）を使う必要はありません。Sol・Terra・Luna 3ティアの性能差と使い分けの考え方は、GPT-5.6のティア構成とPoC設計の解説で詳しく整理しています。
ストリーミングにする理由は、生成中の文章がリアルタイムで画面に表示されるため、担当者が「動いているのか？」と不安にならない点にあります。
「全自動」ではなく「下書き生成 + 人間の確認」が現実的
AIによる返信自動化と聞くと、「問い合わせが届いたら即座にAIが返信する」構成を想像されるかもしれません。技術的にはそれも可能ですが、私たちはあえてそうしていません。
理由はいくつかあります。
- 誤回答のリスク: 大規模言語モデルは、もっともらしいが事実と異なる回答を生成することがあります
- 文脈の読み違い: 「この顧客は先月も似た問い合わせをしていた」といった社内の文脈はAIには見えません
- トーンの問題: クレーム性の高い問い合わせに対して定型的な返信を送ると逆効果になることがあります
こうした理由から、「AIが下書きを生成し、人間が確認・修正してから送信する」というワークフローが、現時点では現実的な落とし所だと考えています。この「AIは下書きまで、確定は人」という型は問い合わせ対応に限らず、見積書・請求書の作成のような金額を扱う業務にもそのまま応用できます。
導入時に気をつけること
個人情報の扱い
問い合わせには氏名、メールアドレス、電話番号が含まれます。これらをそのままOpenAI APIに送信することには慎重な判断が必要です。対策としては、送信前に個人情報をマスキングする、問い合わせの「本文」だけを送り連絡先情報は送らない、社内ポリシーとしてAPI送信範囲を明文化する、といった方法が考えられます。
コスト感覚
一次返信の下書き生成であれば、1件あたりのAPI費用は数円程度です。月に数百件の問い合わせがあっても、API費用としてはそこまで大きな額にはなりにくいと思います。
まとめ
問い合わせの一次返信は、多くの現場で「誰かが手作業で対応し続けている」タスクです。ここにAIを組み合わせることで、返信までの時間を短縮し、担当者の負担を減らすことができます。ただし、AIによる全自動返信はリスクが大きい。「下書き生成 + 人間の確認」という設計が、現時点でもっとも堅実な選択です。まずは小さく始めて、自社の問い合わせ内容に合わせてプロンプトを育てていくアプローチが現実的です。
なお、こうした問い合わせ対応の自動化を実際にシステムとして発注する際は、機能を詰め込みすぎず段階的に見積もりを組み立てることが費用対効果を高めるポイントです。適正な見積もりの立て方についてはNext.jsシステム開発の見積もりを適正化する5つの観点で詳しく解説しています。