受信メールをAIで分類し振り分けるNext.js設計｜情シスの内製構成

受信メールをAIで分類し、担当部署に自動で振り分けるしくみは、Next.js + AI SDKのgenerateObjectとメール受信Webhookを組み合わせれば、数週間規模の最小構成から内製できます。「AIで全部返信する」のではなく、まず仕分けだけを自動化する設計が、現場で使われやすく効果も出やすい進め方です。

こんな状況ではありませんか？

• 問い合わせ用の代表メールアドレスに届いたメールを、担当者が開封して都度どの部署に転送するか判断している
• 繁忙期は振り分けが後回しになり、経理宛のメールに気づくのが翌日になることがある
• 「AIで自動返信」まで一気に作ろうとして、要件が膨らんで着手できずにいる

この記事で分かること

• メール分類が「返信の自動化」より先に着手すべき理由
• Next.js 16 + AI SDK + メール受信Webhookでの最小構成の作り方
• 分類結果をZodスキーマで固定し、誤判定を後工程に持ち越さない設計
• 費用感・導入期間・運用でつまずきやすい失敗パターン

情シス担当者の方へ——代表メールアドレスの一次仕分けを、担当者の勘と経験に頼っている状況を想定し、Next.jsで内製する場合の設計を整理します。

なぜ「自動返信」より先に「分類」から着手すべきか？

分類だけなら誤判定の被害が振り分けミス1件で済みますが、自動返信は誤った内容を相手に送ってしまうリスクを伴うためです。

受信メールのAI活用というと「AIが内容を読んで自動で返信する」という完成形を思い浮かべがちです。しかし、いきなり自動返信まで作ろうとすると、次の2つの課題が同時に降りかかります。

• 送信文面の正確性を担保する仕組み（根拠のない回答を送ってしまうリスクの制御）
• 送信タイミング・宛先の制御（誤送信は取り返しがつかない）

一方、分類・振り分けだけに絞ると、AIが判断を誤っても「本来の担当者に届くのが少し遅れる」程度の被害で済みます。人間が最終確認する工程を残したまま自動化を始められるため、社内の心理的な導入ハードルも下がります。まずは分類の精度を実運用で確認し、そのあとで問い合わせ対応の一次返信をNext.js × AIで自動化する設計のような返信支援に進むのが、失敗の少ない順序だと考えています。

典型的な振り分けパターンをどう分解するか？

「営業・引き合い」「サポート・クレーム」「請求・経理」「採用」の4カテゴリで大半のメールが分類できるのが一般的な傾向です。

分類ロジックを設計する前に、代表メールアドレスに実際にどんな種類のメールが届いているかを棚卸しする必要があります。過去1〜2週間分のメールを見返すと、次のようなカテゴリに整理できることが多いです。

• 営業・引き合い系：サービスへの問い合わせ、見積依頼、資料請求
• サポート・クレーム系：既存顧客からの不具合報告、使い方の質問
• 請求・経理系：請求書送付、支払い確認、契約書のやり取り
• 採用系：応募メール、選考に関する問い合わせ
• その他・スパム系：営業メール、明らかな迷惑メール

最初から全カテゴリを高精度で分類しようとすると検証負荷が跳ね上がります。件数が多く振り分けミスの影響が大きいカテゴリ（サポート・クレーム系など）から対象を絞り、精度を確認しながら広げるのが現実的です。

Next.jsでどう設計するか？最小構成と拡張ステップ

メール受信Webhook・AIによる分類・担当者への通知の3層構成にすれば、Next.jsの最小構成で完結します。

構成は次の3層に分けて考えます。

1. 受信層：代表メールアドレス宛のメールを受け取り、Next.jsのRoute Handlerに転送する
2. 分類層：件名・本文をもとにAIがカテゴリ・緊急度を判定する
3. 振り分け層：判定結果に応じて担当部署へ通知し、確信度が低い場合は人による確認に回す

メールをNext.jsアプリに取り込む部分は、SendGridのInbound Parse Webhookのような、受信メールをmultipart/form-dataでPOSTしてくれるサービスを使うのが定番の構成です（出典: SendGrid Inbound Parse Webhook ドキュメント）。自社でメールサーバーを立てる必要はなく、DNSのMXレコードを向けるだけでNext.js側のエンドポイントにメール内容が届きます。

分類部分はAI SDKのgenerateObjectを使い、出力をZodスキーマで固定するのが実務上の要点です。分類結果が自由記述の文章だと、後続の振り分けロジックでの分岐が不安定になります。

コード例（Route Handlerの骨子、30行程度）：

// app/api/email-triage/route.ts
import { generateObject } from 'ai';
import { anthropic } from '@ai-sdk/anthropic';
import { z } from 'zod';
import { notifyDepartment } from '@/lib/notify';

const TriageSchema = z.object({
  category: z.enum(['sales', 'support', 'billing', 'recruiting', 'other']),
  urgency: z.enum(['high', 'normal', 'low']),
  confidence: z.number().min(0).max(1),
  summary: z.string().max(120),
});

export async function POST(req: Request) {
  const form = await req.formData();
  const subject = String(form.get('subject') ?? '');
  const text = String(form.get('text') ?? '');

  const { object } = await generateObject({
    model: anthropic('claude-sonnet-4-5'),
    schema: TriageSchema,
    prompt: `件名: ${subject}\n本文: ${text}\n上記メールを分類してください。`,
  });

  // 確信度が低い場合は「未分類」として人の確認に回す
  const targetDepartment = object.confidence >= 0.7 ? object.category : 'unclassified';
  await notifyDepartment(targetDepartment, { subject, summary: object.summary, urgency: object.urgency });

  return new Response('OK', { status: 200 });
}

generateObjectはZodスキーマに一致する出力を保証する設計になっているため、分類・データ抽出・フォーム入力補助のような、後続処理が決まったデータ形式を前提にするパイプラインに向いています（出典: Vercel AI SDK 公式ドキュメント）。確信度（confidence）をスキーマに含めて閾値で「未分類」に落とすフォールバックを入れておくと、誤判定をそのまま担当外の部署に送ってしまう事故を防げます。

すでに社内規定を参照して回答するチャットボットのようなAI SDKベースの実装を持っている場合、モデル呼び出しの部分は共通化しやすく、分類用のプロンプトとスキーマを追加する形で拡張できます。

いくらで作れるか？費用感の目安

当社の開発費用は1時間11,000円（税込）が基準です。ヒアリング後、ご依頼に応じて、要件定義・現状調査、相談内容のすり合わせ・仕様合意、開発・移行・公開準備、テスト・受入確認、不確実な作業へのバッファを当社で見積もり、概算をご案内します。お客様が開発工数を推測する必要はありません。

内訳の考え方は次のとおりです。

問い合わせ管理SaaSの自動振り分け機能を使う選択肢もありますが、代表メールアドレス1つに絞った軽量な仕組みなら内製のほうが月額コストを抑えられる場合があります。ただし開発の初期投資とランニングコストのトレードオフでもあり、受信件数が少ない組織では手動振り分けのままのほうが総コストで有利なこともあります。

失敗しやすいパターンと回避策

実装を進める中でつまずきやすいのが次のようなケースです。

• 確信度の閾値を設けずに全件自動振り分けする：誤判定がそのまま担当外の部署に届いてしまう。確信度が低いメールは「未分類」として人の目を通す運用を最初から組み込む
• 添付ファイルやHTMLメールの処理を後回しにする：本文がHTMLタグだらけのまま分類プロンプトに渡すと精度が落ちる。テキスト抽出の前処理を分類の前段に必ず入れる
• カテゴリを最初から細かく設計しすぎる：カテゴリ数が多いほど誤判定も増える。まずは3〜5カテゴリ程度に絞り、実際の分布を見てから細分化を検討する
• 通知の重複や取りこぼしを検証しない：Webhookの再送仕様（SendGridは2xx以外を返すと再送される）を考慮しないと、同じメールが二重通知されることがある。冪等性の確保はServer Actions のセキュリティを Data Access Layer で守るの「外部入力を信用しない」設計と同じ考え方で対応できる

AI駆動開発で何が変わるか？

分類スキーマの設計とテストケースの棚卸しさえ人間が固めれば、Route Handlerの実装自体はAIに下書きさせやすい領域です。

Claude Codeでこの構成を組む場合、Webhookの受信処理やZodスキーマの型定義といった定型的な部分は、AIに任せて素早く形にできます。一方で「どのカテゴリに分けるか」「確信度の閾値をいくつにするか」といった業務判断は、実際のメール分布を見ている人間側で決める必要があります。ここを曖昧にしたまま任せきりにすると、業務フローに合わないカテゴリ分けのまま運用が始まってしまいます。

ゼットリンカーでの進め方

私たちが受託で関わった小規模プロジェクトの範囲では、まず振り分けミスの影響が大きい1〜2カテゴリに絞ってMVPを作り、数週間の短いサイクルで分類精度を確認しながら対象カテゴリを広げていくことが多いです。全カテゴリを一度に対象にするより、小さく動かして精度を確認してから拡張するほうが手戻りが少ないと考えています。

分類結果を確信度つきで扱い、低確信度は人の確認に回すという設計は、見積書・請求書の自動作成をAIで内製する方法のような、金額を扱うため誤りの許容度が低い業務にも応用できる考え方です。

まとめ

受信メールのAI活用は、自動返信より先に分類・振り分けから着手するほうが、誤判定の被害を抑えながら導入できます。確信度が低い判定は人の確認に回すフォールバックを最初から組み込み、カテゴリは3〜5個程度の少数から始めるのが、手戻りの少ない進め方です。代表メールアドレスの一次仕分けに時間を取られている情シス担当者の方は、まず過去1〜2週間分のメールの分布を棚卸しすることから始めてみてください。

自社のメール分布を整理してから相談したいという方には、15分のカジュアル相談（事例・要件未定でもOK／営業はしません）をご用意しています。要件が固まっている方は、ゼットリンカーの無料相談フォームからご相談ください。