パレート 8:2 — ボットが反復実行の 80% を取り除く
対応の問い合わせを類型別に数えると種類は数十ありますが、実際に来る件数は少数の類型に偏ります。アカウント識別子の照会、ログイン・メール変更、単純な状態確認といった定型問い合わせが件数の大半を占めます。類型の数では 20% にすぎないのに、業務量では 80% を食う、典型的なパレート 8:2 です。
この 20% の類型は答えがすでに決まっており、運用 DB を一度照会すれば終わる仕事です。人が毎回繰り返す理由がなく、まさに人の時間を最も奪う業務でもあります。だから自動化の最初の対象はここです。AI の CS ボットが取り除くのは、この反復実行の 80% です。
CS ボットは反復問い合わせをどう処理するのか
薬局ソフトウェア会社の対応業務でこの構造を回してみました。担当者が社内メッセンジャーのチャンネルでボットを呼ぶと、ボットは運用 DB を照会し、根拠を添えて返信します。たとえば特定の薬局のアカウント ID を尋ねれば照会して知らせ、登録メールの変更依頼が来ればアカウントを識別し、変更可否を確認したうえで手順を案内するか直接処理します。
肝心なのは二つです。第一に、機微な変更は人の確認を経る一方、単純な照会・案内は自動で終えます。第二に、すべての回答に照会した根拠を併記してハルシネーションを抑えます。ボットが賢いからではなく、参照するデータが正確で回答に根拠が付いているから信頼して使えるのです。
次の段階 — AI が新規サービスを自ら企画・開発する
反復実行を取り除いた次は、企画と開発です。AI がドメインのコミュニティの投稿をモニタリングして毎週分析し、何が論点で、どんな未充足ニーズが繰り返されるかをブリーフィングにまとめます。そこで止まらず、繰り返されるニーズを新規サービスや機能として自動企画し、JIRA に課題として登録します。
次は開発です。人が Go と判定した課題について、AI が自動で開発し E2E テストまで行います。つまり『何を作るか』の発掘・企画と、『どう作るか』の実装・検証が、いずれも機械側へ移ります。現在 SH Consulting で構築中の構造です。
人は二か所だけで判断する — HITL
このパイプラインで人が介入する地点はちょうど二つです。一つ目は 2 週間ごとのスプリント会議での Go/Stop 判断です。AI が登録した企画課題のうち、何を実際に作るかを人が選びます。二つ目は開発後の機能テストです。E2E まで通した成果物を人が最後に検収し、出すかどうかを判断します。
この二地点は偶然ではありません。方向を定めること（何を作るか）と、出荷品質に責任を負うこと（出すか）は、人が負うべき判断です。その間の反復労働——モニタリング、分析、企画書作成、コーディング、テスト作成——は機械が担います。これが Human In The Loop（HITL）の設計原則です。
なぜ完全自動ではなく HITL なのか
完全自動化の危険は、誤った方向を速く大量に作り出す点にあります。方向判断と出荷判断を機械に渡すと、間違えたときに戻すコストが大きくなります。二つの人のゲートが、まさにそのリスクを吸収します。AI が悪いアイデアを自ら葬るのではなく、人が Go/Stop で選別するのです。
実行（CS ボット）から企画・開発（自律パイプライン）まで AI に渡すほど、人の仕事は二つの判断地点へ収束します。AX が指すのは、人をパイプラインから押し出すことではなく、反復から解放された人を、判断が必要な場所に正確に残すことです。