どんな話？
AIの答えを受け取り、担当候補を表示し、人が確認するまでの流れを設計しました。候補と表示先の対応表、「人が確認」と答えを取得できなかった場合をどちらも確認待ち一覧へ送りつつ理由を分ける分岐、アプリ側の問い合わせIDで二重処理を確かめる項目が成果物です。アプリへの接続、担当への保存・通知は未実行。回答の保留、実行失敗、二重処理を分けることで、流れを試す場所も明確になります。
この記事でわかること
- 流れは、入力 → 判断して答えを確かめる → 担当候補の表示 → 人が確認。メール送信、返金、注文変更は含めない
- アプリでは answers の name と choice の値を確認し、自分が用意した担当名へ対応させる。候補が欠けた場合や refusal の場合は確認待ちへ送る
- 試験運用の仮のルール例は、confidence が0.70未満なら確認待ちへ。0.70は公式の推奨値ではなく、0.60・0.70・0.80のどこで誤配送が減るかを比べて決める
- 「人が確認という答えが返った」ことと「答えを取得できなかった」ことは、同じ記録にしない。再試行すべき場所が変わる
- 問い合わせIDはアプリ側の設計で、専用APIが自動で二重処理を防ぐと案内しているわけではない
- 「注文した商品が届きません」は第3話の専用Playgroundで配送、候補確率96%、confidence 95%。アプリ経由の送信と表示は未実行
やることチェックリスト
0/6記事を読みながら、できたものにチェックを付けていけます。チェックはこの端末に残ります。
ぜんぶできた！おつかれさまでした。
くわしい手順と画面の図は、Xの記事にあります。
こんな人に
- 担当名がわかっても、渡す先や確認待ちの置き場所が決まらず止まっている人
- 問い合わせの振り分けを設計したい人
- AIの答えを受け取り、担当候補を表示し、人が確認するまでの流れを知りたい人
この話のTIPS
- コツ画面に出る日本語の表示名と、アプリが扱う識別子が同じとは限りません。
- 注意担当へ渡す操作の途中で応答が途切れた場合は、「渡っていない」と決めつけられません。相手の一覧と処理状態を確認してから、必要な段階だけを再開します。