行政書士事務所の Web の問い合わせを、許認可・在留手続き・相続などの種類と急ぎの度合いで分類し、担当者に振り分けて初回の返信の下書きを作る

処理の起点を決める

問い合わせの通知メールに「Web問い合わせ」のラベルが付いたことを起点にします。 ラベルは Gmail のフィルタで、通知メールの送信元のアドレスと件名の決まった文字列を条件に付けます。補助者が手でラベルを付ける運用にはしません。 手で付けると、付け忘れた問い合わせがそのまま漏れます。

New Labeled Email を選ぶ理由は、検知できる期間に制限が無いからです。 New Email と New Email Matching Search は1時間とされ、Zapier の側が一時的に止まっていたときに取りこぼす余地があります。問い合わせの取りこぼしは、そのまま相談者を失うことです。

そのかわり、同じスレッドに返信が足されたときにも動きます。 補助者が通知メールに転送やメモの返信を足すと、もう一度 Zap が動きます。Zap の最初の段で、受付台帳を Find Records で引き、同じスレッドの記録があれば止めます。

フィルタの条件は、フォームの通知メールの決まった件名にします。 「【お問い合わせ】〇〇行政書士事務所」のような件名をフォームの側で固定し、フィルタはその件名と送信元の両方で当てます。 どちらか一方だと、迷惑メールや転送が紛れ込みます。

入力データを集める

質を決めるのは、分野の定義の「典型的な書き方」です。 相談者は手続きの名前を書きません。「外国人を雇いたい」「ビザが切れそう」「奥さんを日本に呼びたい」は在留手続き、「店を出したい」「深夜にお酒を出したい」は営業の許可、「会社を作りたい」は法人設立、と相談者の言葉と分野を結ぶ例を並べます。第3章の（a）で補助者の1人に寄っていた読み分けを、ここに書き出します。

分野の選択欄の値も渡しますが、決め手にはしません。 相談者が選んだ分野と本文が食い違うときは、本文を優先し、食い違ったことを記録します。 選択欄だけで振り分けると、「その他」がすべて補助者に戻ってきます。

データの取得方法を決める

データはすべて、トリガーが返す通知メールの中にあります。 フォームの入力欄が「氏名：」「メールアドレス：」「相談の内容：」のように本文に並んでいるので、別のシステムから取ってくるものはありません。

相談者のメールアドレスは、通知メールの送信元ではありません。 通知メールはフォームのシステムから届くので、送信元に返信すると相談者には届きません。本文の「メールアドレス」の欄から写した値を、下書きの宛先に使います。 写せなかったときは下書きを作りません。

AIへ渡す前に整形する

1. 重複の確認 … スレッドIDで受付台帳を引き、記録があれば止めます
2. 本文の切り出し … フォームの通知メールの決まった前置きと末尾の文言を落とし、入力欄の部分だけを渡します
3. 電話番号を渡さない … 分類にも下書きにも電話番号は要りません。受付台帳にだけ残します
4. 相談の分野の選択欄の値を分けて渡す … 本文と選択欄を別の入力として渡し、食い違いを見られるようにします

3番目は、渡す情報を絞るためです。 AI のステップに渡すのは、分類と下書きに要る氏名・メールアドレス・相談の内容・選択欄だけにします。在留手続きの相談では、本文に国籍や在留資格が書かれることがあり、それ自体は分類に要ります。 だからこそ、要らない項目は最初から外します。

AIに処理させる

させるのは2つです。 1つ目のステップで、本文から相談の種類・相談者の別・期限の記載・連絡先を写し出して分類します。2つ目のステップで、分類の結果を受けて初回の返信を下書きします。

期限は「書かれているか」と「原文」だけを写させます。 「来月末」「3月で切れる」のような書き方を日付に直させると、今日の日付の取り違えで1か月ずれた期限が台帳に載ります。 原文のまま担当に見せれば、担当が読み違えることはありません。

売り込みを迷ったら false にするのは、相談を取りこぼさないためです。 売り込みと判断した問い合わせには返信の下書きを作らないので、相談を売り込みに入れる誤りのほうが重いからです。

3行目は誤りやすいところです。 在留手続きや許認可の相談に、AIは親切に必要書類を並べがちです。相談者の事情によって要る書類は変わり、初回の返信で並べた一覧は、そのまま事務所の案内として受け取られます。

指示内容を固定する

1つ目のステップ（Analyze and Return Data）の指示：

あなたは行政書士事務所で、Web の問い合わせを受け付ける補助者です。
問い合わせの本文に書かれていることだけを使って、項目を埋めてください。
推測で埋めないでください。

【相談の種類】下の定義から、主な種類を1つ選んでください。
2つの種類にまたがる場合は、もう1つを sub_type に入れてください。
どれにも当てはまらない、または迷う場合は unclassified にしてください。
相談者が選んだ分野の値と本文が食い違う場合は、本文を優先し、
field_mismatch を true にしてください。
- 許認可：建設業・産業廃棄物・宅地建物取引業・飲食店や深夜酒類・
  風俗営業・運送業などの許可や届出。「店を出したい」「許可の更新」
- 在留手続き：在留資格の取得・変更・更新、家族の呼び寄せ、永住、帰化。
  「外国人を雇いたい」「ビザが切れそう」「家族を日本に呼びたい」
- 相続・遺言：遺産分割協議書、相続人の調査、遺言書の作成の相談
- 法人設立：会社・一般社団法人などの設立
- 売り込み：ホームページ制作・広告・人材紹介などの営業の案内

【期限の記載】
- 手続きの期限、在留期間の満了、許可の有効期間、申請の締切など、
  期限についての記述があれば deadline_stated を yes にし、
  その文を deadline_text にそのまま写してください。
- 日付への言い換えや、残りの日数の計算をしないでください。
- 書かれていなければ none にしてください。

【厳守事項】
- 許可や在留が認められるかの見通しを書かないでください。
- 売り込みかどうか迷う場合は、is_sales を false にしてください。
- reply_to には、本文の「メールアドレス」の欄の値をそのまま写して
  ください。送信元のアドレスを使わないでください。
- evidence に、種類を選んだ根拠の文を本文からそのまま写してください。

【相談者が選んだ分野】{selected_field}
【問い合わせの本文】{body}

2つ目のステップ（初回の返信の下書き）の指示：

行政書士事務所から、Web で問い合わせをくださった方への最初の返信を
書いてください。次のことだけを書いてください。
- 問い合わせのお礼と、内容を受け付けたこと
- 担当する行政書士の名前（{assignee_name}）
- 面談の候補日を3つ（{slot1}、{slot2}、{slot3}）示し、都合を尋ねること
- 面談の前に知りたいこと（下の「確認したいこと」）を2〜3点尋ねること
書かないこと：許可や在留の見通し、報酬の額、必要書類の一覧、
期限に間に合うかどうか。相談の中身に答えないでください。
期限の記載がある場合（{deadline_text}）は、それを受け取ったことに
触れ、面談の日程を優先して調整する旨だけを書いてください。
【相談の種類】{type}　【確認したいこと】{questions_for_type}
【相談者の氏名】{name}

2つ目で「確認したいこと」を種類ごとに外から渡すのは、聞く内容を事務所で決めるためです。 在留手続きなら「現在の在留資格と在留期間の満了日」、許認可なら「事業の所在地と、いま持っている許可」のように、種類ごとに2〜3点を担当の行政書士が決めて Zap に書き込みます。 AIに考えさせると、相談の中身に踏み込む質問が混ざります。

出力形式を固定する

1つ目のステップの出力は、Analyze and Return Data の出力項目として次のように定義します。

項目に分けて受け取る理由の1つ目は、Paths の条件にそのまま使えることです。 分岐は type の値で決まり、AIの文章を読み解く処理を挟まずに済みます。

期限の記載は、分岐とは別に扱います。 deadline_stated が yes なら、どの分岐でも「急ぎ」のラベルを足します。Paths のグループの外で先に判定しておくと、分岐の数を増やさずに済みます。

2つ目は、evidence と field_mismatch で確認が速くなることです。 担当は下書きを開く前に、受付台帳で種類の根拠と、選択欄との食い違いを見られます。

システムへ連携する

返信は下書きまでにし、Send Email は使いません。 担当が確かめて送るので、誤った分類のまま相談者へ出ることがありません。 下書きは事務所の代表アドレスに作るので、担当が席を外していても補助者が送れます。

面談の候補日は、Zap に書き込んだ値を使います。 担当ごとの空きの枠を週に一度更新し、AIには日程を作らせません。 予定表との連携は、運用が落ち着いてから足します。

Zap の大きさにも上限があります。 Zapier の説明では、1つの Zap は分岐の中のステップも含めて全体で100ステップまで、Paths の入れ子は3段までとされています。分野ごとに下書きのステップを分けると数が増えるので、下書きのステップは分岐の外に1つだけ置き、分野ごとの「確認したいこと」を値として渡す形にします。

人が確認する

1. 担当のラベルの付いた下書きを開く … 種類が自分の持ち分か、宛先が相談者のアドレスかを見ます
2. 文面を確かめる … 見通しや報酬に触れていないか、候補日と確認したいことが合っているかを見て、直して送ります
3. フォールバックの問い合わせ … 補助者が読んで担当を決め、下書きを手で作ります
4. 「営業」のラベルの問い合わせ … 補助者が週に一度一覧で見て、相談が紛れていないかを確かめます

4番目を省かないでください。 売り込みに入った相談は、返信が作られないまま残ります。週に一度の見直しで、取りこぼしを拾います。

面談の前の確認は、これまでどおり担当が行います。 相談者の相手方が既存の依頼者でないかといった確認は、受付台帳の分類とは別に、担当が面談の日程を決める前に行います。 この構成は、そのための材料を早く届けるところまでです。

目標は、180件をならして1件3分です。 種類が正しく下書きもそのまま送れる相談は1〜2分で済み、フォールバックと文面を直す相談は数分かかります。3分を大きく超える月は、分野の定義の「典型的な書き方」が足りていません。

例外に対処する

5行目は、在留手続きの相談で起きます。 外国語で書かれた相談に日本語の下書きを返すと、相談者に伝わりません。どの言語で返すかは担当が決めます。

6行目の再送は、返信が遅れたときに起きます。 相談者は返事が来ないと、もう一度フォームから送ってきます。前の受付と別の担当に振り分けると、同じ相談者に2人の行政書士から返事が届きます。 再送の印が付いたら、前の担当に寄せます。

記録を残す

• 通知メールのスレッドID、受信日時、件名
• AI のステップが返した項目の全文（type、deadline_text、evidence など）
• 付けたラベル、担当、下書きを作ったかどうか
• 担当が種類を直した記録 … どの種類からどの種類へ直したか
• 返信を送った日時と、面談につながったかどうか

4つ目が、分野の定義を育てる材料です。 担当が直した種類を月に一度数え、多い組み合わせの「典型的な書き方」を定義に足します。

最後の行は、この構成の効果を見るための記録です。 返信までの時間と面談につながった割合を、導入前と比べます。