住民からのごみの分け方・出し方の問い合わせに、分別辞典と収集日程を根拠にチャットで答え、辞典に無い品目は担当課へ回す

処理の起点を決める

住民がチャット窓口に最初の一文を書いたことを起点にします。 公式サイトのごみのページと、分別辞典のPDFのページにチャットの入口を置きます。辞典を探しに来た人が、そのまま聞ける場所に置くのが要点です。

電話を受けた職員は、庁内の同じ画面を開いて、住民から聞いた言葉をそのまま打ちます。住民向けと職員向けで仕組みを分けません。 分けると、辞典の更新がどちらか一方にしか届かない期間ができます。

会話の履歴はプログラムの側で持ち、毎回の要求にその会話のやり取りだけを入れます。 会話ごとに識別子を振り、30分で区切ります。

入力データを集める

質を決めるのは、分別辞典の別名の列です。 住民は「ホッカイロ」「使い捨てカイロ」「カイロ」と言います。辞典の見出しが1つでも、別名に言い方を並べておけば、プログラムの照合で引けます。 別名の列が空のままでは、AI が言い換えても辞典に届きません。

更新日の列は、回答に添えるために持ちます。 区分の変更があった品目は、古い冊子を見た住民と食い違います。「この案内は何月何日時点の辞典です」と書ければ、食い違いの理由を住民が自分で読めます。

基準日を AI に渡さず、プログラムの時計から取るのも意図してのことです。 「次の収集日」を計算する関数に基準日を入れ、日付の計算はすべてプログラムが行います。

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

データは3つの関数で取ります。AI が呼べるのはこの3つだけで、すべて読み取りのみです。

lookup_item の照合はプログラムが行います。 品目名と別名の完全一致、読みの一致、部分一致の順に引き、どの段階で一致したかを「一致の種類」として返します。 AI はこの値を見て、完全一致なら答え、部分一致なら住民に確かめます。

関数の説明文には上限があります。 ツールと関数の説明は、現在1,024文字に制限されているとされています。引数の書き方の注意は説明文に短く書き、長い規則はシステムメッセージの側に置きます。

関数の定義は、たとえば次のように書きます。

{
  "type": "function",
  "function": {
    "name": "lookup_item",
    "description": "市の分別辞典から品目を探す。住民の言い方を、辞典の見出しに近い一般的な品目名に直して渡す。材質や大きさが分かっていれば含める。",
    "strict": true,
    "parameters": {
      "type": "object",
      "properties": {
        "query": { "type": "string", "description": "品目名。例: 使い捨てカイロ、プラスチック製のかご" },
        "material": { "type": ["string", "null"], "enum": ["plastic", "metal", "wood", "glass", "cloth", "paper", "mixed", null] }
      },
      "required": ["query", "material"],
      "additionalProperties": false
    }
  }
}

material を省略可能にせず、null を許す形で必須にしています。 構造化出力では、すべてのフィールドを必須にし、additionalProperties を false にする必要があるとされ、省略可能な項目は null との共用体で表すとされています。

AIへ渡す前に整形する

1. 発言の長さの確認 … 1回の発言が長すぎるものは切り詰め、品目名と町名の部分だけを渡します
2. 個人情報の除去 … 住民が氏名、番地、電話番号を書いた場合は、プログラムの側で伏せ字にしてから渡します。収集日の計算に要るのは町名（丁目まで）だけです
3. 町名の正規化 … 全角と半角、「丁目」と数字の書き方をそろえてから対応表を引きます
4. 辞典の表の検査 … 毎朝、区分の列が空の行、別名が他の品目と重複している行を洗い出し、担当課へ知らせます
5. 収集日程の検査 … 休みと振替の表が、向こう60日分そろっているかを毎朝確かめます。足りなければ、次の収集日を答えない設定に切り替えます
6. 関数の結果の整形 … 候補の行は、AI に要る列だけに絞って返します

2番目を軽く見ないでください。 住民は親切に「○○町3丁目5番の山田です」と書きます。番地と氏名は回答にまったく要らないので、渡さないのが一番安全です。

AIに処理させる

させるのは、住民の言葉を関数の引数に直すこと、足りない条件を聞き返すこと、関数が返した行だけで回答文を作ることの3つです。

1行目がいちばん起きやすい失敗です。 辞典に「電動歯ブラシ」が無いとき、AI は「電気製品なので小型家電の回収へ」と答えたくなります。その答えが合っているかどうかではなく、辞典に根拠が無いことが問題です。

家電4品目は、辞典の側に行を持たせます。 環境省の説明では、家庭用エアコン、テレビ、電気冷蔵庫・電気冷凍庫、電気洗濯機・衣類乾燥機が家電リサイクル法の対象で、消費者は廃棄するときに収集運搬料金とリサイクル料金を支払い、小売業者には引取りが義務付けられているとされています。市の案内の文面は辞典の行に書き、AI にはその行を返させるだけにします。

指示内容を固定する

あなたは市の清掃担当課の案内係です。住民からの、ごみの分け方・出し方・
収集日の質問に答えます。

【使ってよい情報】
- lookup_item、resolve_district、get_next_collection の3つの関数が
  返した結果だけを使ってください。
- 自分の知識で、ごみの区分、出し方、収集日を答えないでください。
- 提供された関数以外を使おうとしないでください。

【進め方】
1. 品目の名前が分かったら lookup_item を呼んでください。住民の言い方は、
   一般的な品目名に直してから渡してください。
2. 結果の match_type が exact なら、その行で答えてください。
3. 候補が複数あるときは、候補どうしで違う点（材質・大きさ・電池の有無）
   だけを、1回に1つ質問してください。区分名を住民に選ばせないでください。
4. 収集日を聞かれたら、町名を確かめて resolve_district を呼び、
   get_next_collection で次の収集日を取ってください。
   日付を自分で計算しないでください。
5. 関数に渡す値を推測しないでください。品目や町名があいまいなら、
   住民に聞き返してください。

【答えてはいけないこと】
- lookup_item の結果が0件のときは、区分を答えないでください。
  似た品目から推して答えないでください。status を escalated にし、
  「担当課で確認して連絡します」と伝えてください。
- 同じ品目で2回聞き返しても1つに決まらないときも escalated にしてください。
- 粗大ごみの申込み方法や手数料、事業所のごみ、不法投棄の通報は
  out_of_scope にし、案内先の窓口だけを伝えてください。
- 住民が氏名や番地を書いても、回答に繰り返さないでください。

【回答の書き方】
- 区分、出し方、注意、次の収集日の順に、短く書いてください。
- 使った辞典の行の item_id と updated_at を必ず sources に入れてください。
- 結果に書かれていないことを付け足さないでください。

「関数に渡す値を推測しない」を明記しているのは、公式の案内に沿ったものです。 Microsoft Learn では、関数で使う値を推測せず、要求があいまいなら明確化を求めるようシステムメッセージで指示する例が示されています。町名が無いまま、ありそうな地区で収集日を引かれると、住民は誤った曜日にごみを出します。

出力形式を固定する

最終の回答は、構造化出力で次の形の JSON にします。

{
  "status": "answered | clarifying | escalated | out_of_scope",
  "reply_text": "",
  "items": [
    {
      "query": "",
      "item_id": "",
      "item_name": "",
      "category": "",
      "how_to": "",
      "note": "",
      "updated_at": ""
    }
  ],
  "collection": {
    "district": "",
    "category": "",
    "next_dates": []
  },
  "question": "",
  "escalation": {
    "item_words": "",
    "reason": "not_in_dictionary | unresolved_after_two_questions | district_not_found"
  },
  "sources": []
}

1つ目の理由は、status で後段の処理を分けられることです。 answered はそのまま住民に表示し、escalated は引き継ぎの一覧に1行を足し、out_of_scope は窓口の案内を添えます。文の中身を読まずに、値だけで分岐できます。

2つ目は、回答文と根拠を別の欄に置けることです。 reply_text は住民向けの文、items と sources は辞典の行です。抜き取りで確かめるとき、文と行を並べて読めば、行に無いことを書いていないかがすぐ分かります。

3つ目は、escalation.reason で担当課の仕事が分かれることです。 not_in_dictionary は辞典に足す品目の候補、district_not_found は町名の対応表の不備です。同じ「答えられなかった」でも、直す先が違います。

構造化出力は、指定した JSON スキーマに従って応答させる機能で、有効な JSON だけを保証していた従来の JSON モードとは違い、スキーマへの準拠まで求められるとされています。スキーマは最大100個のオブジェクトプロパティ、最大5レベルの入れ子までとされており、この形はその範囲に収まります。

並列の関数呼び出しは使いません。 構造化出力は並列関数呼び出しではサポートされず、使う場合は parallel_tool_calls を false にするとされています。品目を引いてから地区を引く順番が決まっているので、並列にする利点もありません。

システムへ連携する

辞典への書き込みは、この構成からは行いません。 AI にも関数にも、辞典を書き換える経路を持たせません。区分を決めて辞典に足すのは、担当課の職員が表を直す作業です。 関数は読み取りだけの権限で動かします。

モデルが返した関数呼び出しは、実行する前にプログラムが検証します。 呼ぶ関数の名前が3つのどれかか、引数が型どおりかを見ます。Microsoft Learn でも、モデルが生成した関数呼び出しを常に確認すること、関数には必要最小限のアクセス権だけを与えることが勧められており、データベースへの問い合わせなら読み取り専用のアクセス権にする例が挙げられています。

JSON の読み込みの失敗にも備えます。 関数呼び出しの JSON 応答が常に有効とは限らないため、エラーを処理するロジックを足す必要があるとされています。読めなかったときは同じ要求を1回だけやり直し、それでも読めなければ escalated にします。

人が確認する

人が見るのは、escalated の引き継ぎと、抜き取りの記録だけです。 answered の回答を1件ずつ承認する設計にはしません。承認を挟むと、住民は答えを待つことになり、電話のほうが早くなります。

1. 引き継ぎの一覧を毎朝見る … not_in_dictionary の品目について、区分を決めて住民に折り返します。折り返しの期限は、受け付けた翌開庁日までとします
2. 決めた区分を辞典に足す … 品目名と、住民が使った言い方を別名に入れます。次に同じ品目を聞かれたとき、引き継ぎにならずに答えられます
3. 週に一度、50件を抜き取って読む … reply_text と items を並べ、行に無いことを書いていないかを見ます
4. 誤りを見つけたら記録する … どの会話の、どの文が、辞典のどの行と食い違ったかを残します

2番目を省かないでください。 折り返しだけで終えると、同じ品目がまた引き継ぎになります。引き継ぎの件数が月を追って減っていくかどうかが、辞典の整備が進んでいるかの目安です。

3番目の抜き取りで見るのは、根拠の外に出ていないかです。 関数の結果に無いことを付け足していれば、指示を直します。

例外に対処する

上の3行が大半を占めます。 どれも AI の問題ではなく、辞典と対応表の穴の問題です。 引き継ぎの理由を数えれば、どこを直せばよいかが分かります。

記録を残す

• 会話の識別子、受け付けた日時、入口（住民のチャット／職員の画面）
• 住民の発言（伏せ字にした後のもの）と、AI の回答（reply_text）
• 呼んだ関数の名前、引数、返った結果
• 最終の JSON（status、items、collection、escalation、sources）
• そのとき参照した辞典の行の更新日
• 引き継ぎの処理（折り返した日時、決めた区分、辞典に足した日）
• 抜き取りの結果と、誤りの記録

3つ目の関数の記録が、いちばん役に立ちます。 誤った案内が見つかったとき、AI が言い換えを誤ったのか、辞典の行が誤っていたのか、日程の表が古かったのかを、呼んだ引数と返った結果で切り分けられます。