深夜2時17分。Slackの#opsチャンネルにinbound通知が1行だけ届いていました。大阪のとあるメーカー担当者が5ya.ioの問い合わせフォームに「AI Botの導入を検討中なのですが、30分だけ通話できますか」と残していたのです。そのメッセージは営業時間が始まるまでの9時間、返信のないまま放置されていました。その日の朝会で決めました — 自分たちでBotをビルドする、と。
本シリーズは、私たちが自前でビルドしたAIツールの運用ノートです。初回は自社inbound対応Bot。
なぜSaaSチャットボットではなく自前で作ったのか
外部のチャットボットSaaSを2社、1週間ほど比較しました。FAQ対応まではどちらも問題なかったのですが、私たちが受け取るinboundの70%以上は単純な質問ではなく、BoFuの商談リクエストでした。「月10万円台でPoCは可能か」「製造業の事例を見せてほしい」といった決裁者トーンの問い合わせに対しては、事前に設計したフローチャートだけでは応対品質にばらつきが出てしまったのです。
当初はClaude APIを一度叩くだけのスクリプトで十分だと考えていました。ところが実装してみると、別の問題が顔を出します。問い合わせ分類・過去会話の取得・CRMアップデート・社内レビューキュー — これらを1回の呼び出しに詰め込んだ結果、プロンプトは800行を超え、一度の失敗で全工程が連鎖的に崩れる構造になってしまいました。
アーキテクチャ図1枚 — Claude × LangGraph × OpenRouter
4度目の設計案でこの組み合わせに落ち着きました。
- Claude Opus 4.7 — ロングコンテキストとトーンの安定性。決裁者からの問い合わせには、一行返信ではなく4〜6文の重みのある返答が必要です。
- LangGraph — ノードとエッジで状態フローを直接描けるライブラリ。分類・リサーチ・ドラフト・レビューを個別ノードに分割したことで、失敗箇所のみから再開できるようになりました。
- OpenRouter — モデルゲートウェイ。軽い分類タスクはHaiku 4.5、本文生成はOpus 4.7にルーティングすることでコストを抑えました。
コストはモデルの切り替えで大きく動きました。
| モデル | 入力(1Mトークン) | 出力(1Mトークン) |
|---|---|---|
| Claude Opus 4(旧バージョン) | $15 | $75 |
| Claude Opus 4.6 / 4.7 | $5 | $25 |
同じ返信1件あたりのトークン単価が1/3水準まで下がりました。4週目の累積API費用は約1.8万円 — 担当者1人の夜間対応工数に換算すれば、比較すること自体が意味を失う水準でした。
LangGraphグラフ — 5つのノード
グラフの骨格だけ抜き出すと次のようになります。
from langgraph.graph import StateGraph, END
graph = StateGraph(InboundState)
graph.add_node("classify", classify_intent)
graph.add_node("research", fetch_context)
graph.add_node("draft", draft_reply_with_claude)
graph.add_node("review_queue", push_to_slack)
graph.add_node("crm_sync", upsert_to_crm)
graph.set_entry_point("classify")
graph.add_conditional_edges(
"classify",
lambda s: "research" if s["intent"] == "lead" else END,
)
graph.add_edge("research", "draft")
graph.add_edge("draft", "review_queue")
graph.add_edge("review_queue", "crm_sync")
graph.add_edge("crm_sync", END)
ポイントは2つ。1つ目はclassifyノードで単純FAQとリードを切り分け、リードだけを重いパイプラインに流したこと。2つ目はreview_queueノードがBotの返信ドラフトをSlackチャンネルへ投げ、人間が1度レビューしてからでないと送信されない設計にしたこと。自動化の最後の1cmは意図的に人間の手に残した、ということです。4週間の運用を通じて、私たちのチームが「いちばん良かった」と自負している判断でもあります。
4週間の運用 — 数字で見る風景
4月28日から5月25日までの4週間のデータです。
- 処理したinbound:142件(FAQ 89 / リード 53)
- 平均ドラフト生成時間:47秒
- 夜間(22時〜翌9時)の応答率:100%(全件Botドラフト → 翌営業日9時に一括レビュー後送信)
- 人間レビューでの修正発生率:31%
- Botドラフトそのまま送信:69%
修正発生率31%は最初、高く感じられました。ところが1件ずつ中身を見ていくと、その半数近くは「メールの結びの一文を追加」「候補日時を1行補強」といった軽微な手直しでした。トーンや事実関係が崩れたケースは4週間で4件。うち2件はBotが自社価格を勝手に推測して答えたケースで、すぐにプロンプトへ「価格は絶対に直接答えず、無料診断の案内に切り替えること」というガードを組み込みました。正直に言えば、ここは運用ルールでねじ伏せる作業に近く、コード1行できれいに片付く類の問題ではありませんでした。
「応答率100%」と書くと大げさに聞こえますが、要は「深夜に届いた日本の決裁者からの問い合わせが、韓国側の営業時間が始まる時点でレビュー可能なドラフト状態で待機している」という意味です。以前は9時間ぽっかり空いていたその時間帯に、人の手が1度入っている風景に変わりました。
つまずいた2つのポイント、そして運用ルール
ハルシネーションは最後までゼロにはなりませんでした。多言語も課題でした — 日本語で届いた問い合わせに対し、韓国語的な語順が滲んだ返信が2回ありました。私たちはこの2つをコードではなく運用ルールで解きました。「送信前の人間レビュー1回」という最後のノードがそれです。詳しいビルド手法はAIオートメーションサービス紹介ページにシナリオ別にまとめています。
おわりに — Botは人を減らす道具ではない
ある韓国の中小企業の社長がこう仰っていたことがあります。「相談を受けられない夜の時間でも、顧客を逃さなくなった」。私たちの4週間の運用も、結局同じ地点にたどり着きました。Botは人を減らす道具ではなく、人の手が届かない時間帯にリードを取りこぼさないよう支えるインフラに近いものです。
私たち5years+では、韓国・日本の中小企業向けにinboundオートメーションBotを4週間サイクルでビルドしています。自社環境(メッセンジャー・CRM・商品カタログ)に合わせた30分の無料診断を — 無料相談はこちら → 5ya.io/ja/contact から承ります。
次回(第2回)は毛色の異なる自動化を扱います。Runway Gen-4 × Gemini Imageで週5本の広告動画を量産する — 営業Botがリードを受け取るポジションだとすれば、動画パイプラインはそのリードを連れてくるポジション。2つの軸が繋がったとき、ようやく自動化が売上カーブに触れ始めるのです。