Insights·2026-07-11

HITL: AI が企画・開発までやるのに、なぜ人は残るのか

AI の業務自動化は反復実行を超え、新規サービスの企画・開発へ広がります。AI の CS ボットは、問い合わせの種類では 20% でも実際の業務量では 80% を占める反復問い合わせ(パレート 8:2)を根拠付きで自動処理します。さらに、コミュニティの声をモニタリングして AI が新規サービスを自動企画・開発するパイプラインでは、人は『Go/Stop の決定』と『機能テスト』の二つの判断地点にだけ残ります。このように人を自動化のループ内に残して判断させる仕組みを HITL(Human In The Loop)と呼びます。実行から企画まで機械が担い、人の仕事は判断へ収束します。

前の記事の続きコールセンターはコスト部門か、新規事業の源泉か

パレート 8:2 — ボットが反復実行の 80% を取り除く

対応の問い合わせを類型別に数えると種類は数十ありますが、実際に来る件数は少数の類型に偏ります。アカウント識別子の照会、ログイン・メール変更、単純な状態確認といった定型問い合わせが件数の大半を占めます。類型の数では 20% にすぎないのに、業務量では 80% を食う、典型的なパレート 8:2 です。

この 20% の類型は答えがすでに決まっており、運用 DB を一度照会すれば終わる仕事です。人が毎回繰り返す理由がなく、まさに人の時間を最も奪う業務でもあります。だから自動化の最初の対象はここです。AI の CS ボットが取り除くのは、この反復実行の 80% です。

重要なのは類型と件数を分けることです。類型が多いから自動化が難しいのではなく、件数が集中する少数の類型だけ渡しても人の負荷は大きく減ります。だから自動化の対象を選ぶときは「最も難しい問い合わせ」ではなく「最も頻繁に繰り返される、答えの決まった問い合わせ」から見ます。

CS ボットは反復問い合わせをどう処理するのか

PillDoc CS ボットが Slack スレッドで運用 DB を照会し、根拠を添えて薬局アカウントの問い合わせに答える画面(個人情報マスキング)
AI CS ボットの実際の応対画面——薬局名・氏名・メールなどの個人情報はマスキング。

薬局ソフトウェア会社の対応業務でこの構造を回してみました。担当者が社内メッセンジャーのチャンネルでボットを呼ぶと、ボットは運用 DB を照会し、根拠を添えて返信します。たとえば特定の薬局のアカウント ID を尋ねれば照会して知らせ、登録メールの変更依頼が来ればアカウントを識別し、変更可否を確認したうえで手順を案内するか直接処理します。

肝心なのは二つです。第一に、機微な変更は人の確認を経る一方、単純な照会・案内は自動で終えます。第二に、すべての回答に照会した根拠を併記してハルシネーションを抑えます。ボットが賢いからではなく、参照するデータが正確で回答に根拠が付いているから信頼して使えるのです。

実際の画面を見ると流れが明確です。担当者がボットをメンションして薬局アカウントを尋ね、ボットは運用 DB からアカウントを見つけ根拠付きで答えます。登録メールを変更する要請では、アカウントを識別し、事業者番号・薬局名で対象を絞って正確なアカウントを見つけ、変更を試みて結果を再確認します。人がやっていた照会・照合・確認を順に踏むわけです。

次の段階 — AI が新規サービスを自ら企画・開発する

ReportBot が薬剤師コミュニティの日次ブリーフィングをインサイト・課題・機会の項目に自動整理した画面
コミュニティ監視ボットの自動ブリーフィング——未充足ニーズを「機会」として抽出。

反復実行を取り除いた次は、企画と開発です。AI がドメインのコミュニティの投稿をモニタリングして毎週分析し、何が論点で、どんな未充足ニーズが繰り返されるかをブリーフィングにまとめます。そこで止まらず、繰り返されるニーズを新規サービスや機能として自動企画し、JIRA に課題として登録します。

次は開発です。人が Go と判定した課題について、AI が自動で開発し E2E テストまで行います。つまり『何を作るか』の発掘・企画と、『どう作るか』の実装・検証が、いずれも機械側へ移ります。現在 SH Consulting で構築中の構造です。

ブリーフィングは単なる要約ではありません。繰り返される不満や回避要請を「機会」項目として抽出し、同じニーズが一定の頻度を超えれば新機能・新サービスの候補へ昇格させます。市場調査をやり直す代わりに、すでにコミュニティに積み上がった声をプロダクトのバックログの入力へ直結させるのです。

人は二か所だけで判断する — HITL

コミュニティブリーフィングから始まる HITL 自律開発パイプラインの図——モニタリング・企画・JIRA・開発・E2E は AI 自動、2 週間スプリントの Go/Stop と機能テストは人の判断
Slack コミュニティブリーフィングからリリースまで——AI 自動ステップと二つの人(HITL)判断地点。

このパイプラインで人が介入する地点はちょうど二つです。一つ目は 2 週間ごとのスプリント会議での Go/Stop 判断です。AI が登録した企画課題のうち、何を実際に作るかを人が選びます。二つ目は開発後の機能テストです。E2E まで通した成果物を人が最後に検収し、出すかどうかを判断します。

この二地点は偶然ではありません。方向を定めること(何を作るか)と、出荷品質に責任を負うこと(出すか)は、人が負うべき判断です。その間の反復労働——モニタリング、分析、企画書作成、コーディング、テスト作成——は機械が担います。これが Human In The Loop(HITL)の設計原則です。

二つのゲートは性格が異なります。前の Go/Stop は「作る価値があるか」という方向の判断、後の機能テストは「このままユーザーに出してよいか」という品質と責任の判断です。一方は入口を絞り、一方は出口を守ります。その間の実行はすべて機械の担当です。

なぜ完全自動ではなく HITL なのか

完全自動化の危険は、誤った方向を速く大量に作り出す点にあります。方向判断と出荷判断を機械に渡すと、間違えたときに戻すコストが大きくなります。二つの人のゲートが、まさにそのリスクを吸収します。AI が悪いアイデアを自ら葬るのではなく、人が Go/Stop で選別するのです。

実行(CS ボット)から企画・開発(自律パイプライン)まで AI に渡すほど、人の仕事は二つの判断地点へ収束します。AX が指すのは、人をパイプラインから押し出すことではなく、反復から解放された人を、判断が必要な場所に正確に残すことです。

この構造は結局、人の役割を変える営みです。反復実行から手を引く代わりに、何を作るかを決め、出てきた結果に責任を負う判断に時間を使います。AX の目標が人を置き換えることではなく、組織が自ら進化するようにすることなら、HITL はその目標を自動化パイプラインの中に構造として刻み込む方法です。

出典: SH Consulting 고객지원 봇·자율개발 파이프라인 구축 사례를 정리