下書き承認フローとオペレーター体験の設計

はじめに

AIが良い下書きを作れても、それをオペレーターが使いにくければ意味がありません。むしろ「AIの下書きを直すより自分で書いたほうが早い」と思われた瞬間に、システムは使われなくなります。

だからこそ、下書きをどう届け、どうレビューし、どう送信するかという運用設計が、システムの成否を分けます。この記事では、AIの下書きを人が安心して使えるようにするための、承認フローとオペレーター体験の設計を解説します。

下書きをどこに置くか

メール送信ではなくノートに添付

生成した下書きは、顧客へのメールとして送るのではなく、HubSpotのチケットにノート（社内メモ）として添付します。オペレーターがチケットを開くと、そこに下書きが待っている状態です。

この一手間が重要で、「AIが用意した案」と「実際に送るメール」を明確に分けられます。ノートである限り顧客の目には触れないので、安心して手を入れられます。最終的な送信は、オペレーターが下書きを見ながら自分の操作で行います。

「送信は人」を仕組みで担保する

システム側にメール送信機能を持たせない、という設計判断もしています。技術的に送れないようにしておけば、「うっかり自動送信してしまった」という事故が構造的に起こりません。

ヒューマンインザループ（人を必ず介在させる設計）は、運用ルールで守ろうとすると必ず綻びます。仕組みとして送信経路を人に限定しておくのが確実です。

レビューしやすい下書きの形

「直しやすさ」を優先する

下書きの理想は、完璧な文章ではなく直しやすい文章です。多少そっけなくても、事実が正確で構成が整っていれば、オペレーターは数秒で自分の言葉に整えられます。逆に凝った表現で埋め尽くされていると、どこを直せばいいか判断するのに時間がかかります。

そのため下書きは、過剰に装飾せず、要点が追える素直な文章になるよう設計しています。人が最後に「味付け」する余地を残しておく感覚です。

根拠を添えて確認を助ける

オペレーターがまず確認したいのは「この下書きの内容は正しいか」です。そこで下書きには、参照した注文情報や過去チケットといった根拠が分かる形で情報を添えます。

「〇月〇日ご注文の△△」と書かれていれば、オペレーターは受注管理システムを開き直さなくても、その場で事実確認ができます。確認のための往復を減らすことが、レビュー時間の短縮に直結します。

自信のない箇所は正直に示す

AIが確証を持てない部分——たとえば商品名の照合が曖昧なときや、複数の注文が該当しうるとき——は、無理に断定せず「要確認」が分かる形で残します。自信のなさを隠して断定されるより、正直に示してくれたほうが、オペレーターは安心してレビューできます。

運用を支える裏側の設計

非同期処理と再実行

下書きの生成はQStashというキューサービス経由で非同期に処理します。AIの生成には時間がかかることがあるため、チケットを受け取ったら順番に確実に処理する構成にしています。

処理に失敗したチケットや、内容を作り直したいチケットは、管理画面から再実行できます。「うまく下書きが出なかった」ときに手動で作り直せる逃げ道があると、運用の安心感がまるで違います。

管理画面での確認と制御

管理画面では、対象チケットの一覧や処理状況を確認できます。どのチケットに下書きが付いたか、どれが未処理か、どれが失敗したかを把握でき、必要に応じて個別に再実行をかけられます。

全自動のブラックボックスにせず、運用者が状況を見て手を入れられる余地を残すことが、実運用では効いてきますよね。

まとめ

AIの下書きを実運用に乗せる鍵は、生成の精度だけでなく、人が安心して使える運用設計にあります。

• 下書きはノートに添付し、送信経路を人に限定して事故を構造的に防ぐ
• 完璧さより「直しやすさ」と「根拠の見えやすさ」を優先する
• 自信のない箇所は正直に示し、AIと分担できる信頼感を作る
• 非同期処理・再実行・管理画面で、運用者が手を入れられる余地を残す

この運用設計は、顧客文脈の注入と意図の分類があってこそ活きます。仕組み全体の狙いはハブ記事で解説しているので、あわせてご覧ください。