01
なぜ作るのか
HOPEの電話面接・候補者評価・日程調整を、曖昧な依頼から人の面接まで一つの流れとしてSMBへ提供するため。
スクロール・スワイプ・矢印キー
Blucor
SMB alpha 実顧客エビデンス · 2026年8月
HOPEの機能を、
一つの採用体験へ。
AI電話面接や日程調整という既存の強みの間にある、曖昧な依頼・顧客フィードバック・基準改善・再選定をつなぐSMB alpha。
顧客事例は匿名化採用成功2社・停滞2社alpha検討用ワーキングメモ
Daveへの回答
HOPEの強い機能はすでにある。ボトルネックは、その前後と機能の間が切れていることだった。
02
成功とは何か
曖昧な依頼から、実フィードバックによる改善を経て、人の面接設定までBlucorの手作業なしで到達すること。
03
今できない理由
既存機能の間にある、メール解釈、基準更新、再選定、承認、状態の引き継ぎがまだ人に依存している。
04
最低限の体験
曖昧な依頼→候補者→自由記述フィードバック→承認済み改善→より合う候補者→面接設定、の一周。
誰の、どんな問題を解くか
顧客は、採用ソフトを操作するための採用チームを持っていない。
対象は、HR担当が1人、あるいは採用を経営者・現場責任者・事務担当が兼務するSMB。JD作成や構造化面接が得意とは限らず、会社を運営しながら採用も進めている。
「この仕事ができる人が欲しい」という短い依頼が、プロダクトの正常な入力であるべき。4社に共通した現実
このalphaが重要な理由
- 人が1社ずつ担当するモデルではSMB対応を拡大できない。
- 顧客が最も忙しい時ほど、確認・追跡・日程調整が必要になる。
- 採用スピードが遅れると、候補者は他社へ移る。
- 10月の大きな開発前に、AIの提案へ顧客が無理なく対応できるUI/UXを実顧客で学べる。
現在のフローと停止点
機能は存在する。しかし、機能の間をつなぐクリティカルパスが人手である。
人が手動で対応01 · 曖昧な依頼
フォローメールや打ち合わせで、求人開始に必要な勤務地・雇用条件・選考工程などを顧客から回収する。
既存のHOPE機能02 · 検索・AI選考
求人、候補者探索、履歴書評価、AI電話面接はすでに実行可能。
Enterprise · 機能実装済み／未利用03 · 顧客の反応
顧客feedbackを受け取る機能は実装済みだが、Enterprise顧客にはまだ使われていない。
人が手動で対応04 · 基準の更新
人が必須条件と希望条件を分け、質問・評価基準を書き換える。
人が手動で対応05 · 再実行
既存候補者の再評価や、新しい候補者の探索開始を人が指示する。
人が手動で対応06 · 選択の解釈
顧客の「面接したい」という返信を、人が次の処理へ転送する。
Enterprise · 実装済み／未利用07 · 人の面接調整
機能は作ったが、UI/UX上の課題が原因の可能性があり、Enterprise顧客には使われていない。
人が手動で対応08 · 再び学習
人の面接結果を次の検索へ反映するまで、また人がつなぎ直す。
失敗するのはAIが誰も見つけられないからではない。メール、判断、カレンダーのどこかで「次の行動の所有者」が消えるからである。
人が実際に担っていた価値
人の8つの仕事は、採用フローの4つのhandoffを成立させるために行われていた。
Phase 1 · 依頼 → 求人開始
曖昧な依頼を動かせる状態にする
1
不足情報を抽出
正式JDを要求せず、開始に必要な情報だけを聞く。
Phase 2 · 候補者提示 → Feedback
顧客の反応を判断へ変える
2
自由記述を解釈
短い不採用理由を、具体的な不一致へ変換。
3
変更か過学習か判断
一人の印象か、繰り返す重要シグナルかを判別。
Phase 3 · 基準改善 → 次候補者
学びを次の実行へ反映する
4
基準へ反映
JD、質問、評価、レポートを同じ理解へ更新。
5
再検索・再評価
新規だけでなく、既存候補者も更新基準で見直す。
Phase 4 · 候補者選択 → 人の面接
選ばれた候補者を止めずに進める
6
候補者の熱量を維持
顧客が忙しくても候補者を待たせない。
7
人の面接日程を調整
空き時間、確認、リマインド、再調整を処理。
8全フェーズを横断 · 状態を記憶
メール、ATS、SMS、通話、カレンダーをまたいで、誰が何を判断し、次に何をするかを人が保持していた。
4社の実顧客エビデンス
同じ採用ループで、人がつなげた2社は採用、人が追いつかなかった2社は停滞した。
事例A · 採用成功
地域リサイクル事業者
整備士。人が不採用理由を診断し、基準更新と次候補者の面接を同日で進め、オファー承諾。
事例B · 採用成功
老舗製造業グループ
技術職。JDと現場実態のズレを継続修正し、候補者を素早く面接へつなぎ採用。
事例C · 採用に至らず
産業部品ディストリビューター
営業職。顧客は契約・支払い・改善フィードバックまでしたが、次の候補者提示が遅れた。
事例D · 採用に至らず
複数都市の専門工事会社
施工職。基準改善はできたが、メールと手動日程調整で候補者のスピードを失った。
検証済み：このループを人がうまく運用すれば、面接と採用につながる。
未検証：AIで同じループを動かしたとき、顧客が迷わず確認・修正・承認できるUI/UXを作れるか。Wizard-of-Ozの正しい解釈
未検証：AIで同じループを動かしたとき、顧客が迷わず確認・修正・承認できるUI/UXを作れるか。Wizard-of-Ozの正しい解釈
事例A · 採用成功 · 最初の要望と途中のプロセス
整備士を探し始め、最初の不採用から「本当に必要な整備力」が明確になった。
顧客・採用体制
地域リサイクル事業者。HR担当は1人。専門判断は現場責任者と経営責任者。
募集職種
産業・移動機械整備士。約3カ月未充足。
最初の要望・不足情報
機械「整備経験」が曖昧。勤務地、雇用形態、開始時期、シフト、AI後の選考工程も不足。
最終結果
オファー承諾
広い「整備経験」で検索開始
操作、補助、軽整備、独立修理の差が明文化されていなかった。
候補者を不採用
機械の操作経験が中心で、独力の故障診断・修理が不足。
4つの判別質問
不足スキル、必要レベル、整備の定義、面接前の必須3項目を確認。
顧客が新基準を承認
重機整備3〜5年、電気図面、油圧、独立した故障診断と修理。
自由記述から「変更前／変更後」の基準差分を作り、顧客が確認・承認できる体験が必要。
事例A · 改善後の進捗と結果
基準を同日で改善し、すでにいた有力候補者を止めずに人の面接へ進めた。
採用候補者をAI面接
後のフィードバックより前に、強い整備経験を持つ候補者はパイプラインにいた。
別候補者が不採用
顧客から現場経験と独立性の不足を取得。
基準と質問を更新
現場責任者への診断質問を選考基準へ反映。
人面接の日程を設定
担当者の空き時間を得て、候補者へすぐ連絡。
人による面接
6年以上の重機整備、油圧、空圧、電気系統を確認。
オファー承諾
長期間空いていたポジションが決定。
人が行ったのは、不採用理由の回収、基準更新、Hiring Managerの空き時間取得、候補者連絡、リマインド、例外処理。AIで置き換えるべきなのは、この接続とスピード。結果を生んだ手動対応
因果関係：不採用フィードバックが採用候補者を発見したのではない。改善を進めながら、既存の有力候補者を止めなかったことが採用につながった。
事例A · 原文エビデンス · Email
人は「違った」を、次の選考で使える具体的な基準へ変換した。
Blucor担当 → 顧客HR不採用翌日
“What specifically was missing from [Candidate A]’s skillset for this role?”
“How far below your expected maintenance level was he? … D. Able to independently troubleshoot and repair”
“If you had to give us the top three ‘must-confirm’ maintenance skills before sending a candidate onsite, what would they be?”
顧客HR → Blucor担当現場責任者・経営責任者の回答
“no real maintenance background”
“wouldn’t necessarily be able to be put on a job without help to explain how to complete the task”
“1. 3-5 Years Hands on experience … 2. General understanding in Electrical Schematics. 3. General understanding in Hydraulics.”
顧客HR → Blucor担当改善後
“[Candidate B] arrived for his interview today and management felt pretty strongly about this candidate.”
“The offer has been extended to [Candidate B] and he has accepted.”
この会話が要求するUI/UXDesign input
- 「何が足りなかったか」だけでなく、期待レベルとmust-confirmを会話で深掘る。
- 回答を、変更前／変更後の選考基準と質問案へ自動変換する。
- 顧客が差分を承認したら、再評価・候補者連絡・日程調整を同じ状態のまま続ける。
人の価値：曖昧な不採用理由を診断し、実行可能な採用基準へ変え、次の候補者を止めなかった。
出典：実際のメール。氏名・会社名・連絡先のみ匿名化。英語の綴り・文法・語順は原文のまま。
事例B · 採用成功 · 最初の要望と途中のプロセス
文書上の技術職と、工場で本当に必要な仕事の違いが、候補者面接から見えてきた。
顧客・採用体制
老舗製造業グループ。HR窓口はあるが、真の基準は複数のHiring Managerに分散。
募集職種
機械、MES、制御エンジニア。
最初の要望・不足情報
経験年数、現場比率、既存設備の実態、CAD、勤務・時間外・visa条件が文書と不一致。
最終結果
オファー承諾
3年経験でも対象
実態はおおむね6年以上を期待。
先端ロボティクス
実際は既存設備の診断・改善が中心。
SCADA・MESが抽象的
履歴書は強くても、主体的な具体例が不足。
CAD・現場経験が不足
デスク寄り、または技術軸が異なる候補者。
コミュニケーションリスク
一方的に話し、協働スタイルが不明。
一件ごとに質問を増やさない
同じ不足が複数人で続くまで待ち、最小限の基準だけを更新。
事例B · 改善後の進捗と結果
人が学びを各システムへ反映し、有力候補者を約1カ月で採用へつないだ。
求人文書を補正
経験水準、現場比率、既存設備、勤務条件を実態へ合わせた。
AI質問を編集
必要な証拠を短く聞き、面接を無制限に長くしなかった。
再評価・再生成
過去候補者を見直し、更新理由を反映したレポートを再生成。
ATSとfeedbackを接続
顧客が使うシステムへ候補者状態を反映。
AI面接 → video → onsite
10年以上の設備設計・故障対応・CAD・現場経験。
オファー承諾
評価から人の面接までのhandoffを止めずに進行。
学習は「選択的」「累積的」「実行可能」であること。顧客には、AIが提案する小さな変更を理解し、迷わず承認できるUI/UXが必要。事例Bのプロダクト要件
因果関係：初期の職種調整は採用候補者の発見前。一部の後半feedbackは候補者がすでにパイプラインへ入った後であり、全feedbackが発見を生んだとは主張しない。
事例B · 原文エビデンス · Circleback + Email
人は具体性を学びながら、一件の違和感だけで質問を増やさなかった。
顧客HR · Feedback meeting候補者面接後
“Her resume looked really good. … But once we started digging into her exact experience, she wasn't really able to give us detailed examples.”
“What production problems did you fix? Give us an example. … Okay, well, give us an example of a problem.”
“Again, they're looking for specificity. They want the candidate to provide a specific example.”
顧客HR · Feedback meeting質問を増やす判断
“If I see a consistent theme emerging where we miss … then I'll add a question. Otherwise … does it make sense to change this question or do we keep it the same?”
Blucor担当 → 顧客HR更新後の承認依頼
“Based on the feedback from the hiring manager, I updated the interview questions and evaluation criteria for the two positions.”
“We also ran simulation tests … Could you please review them?”
この会話が要求するUI/UXDesign input
- 自由記述を「具体例不足」「現場経験」「技術軸」などの反復シグナルに束ねる。
- 単発の印象か、複数候補者に共通するgapかを根拠付きで表示する。
- 質問案と評価基準の差分、想定される再評価結果を見せ、承認を一手にする。
人の価値：Hiring Managerの発言を蓄積し、質問の長さと選考精度のトレードオフを判断した。
出典：実際のCircleback transcriptとメール。氏名・会社名・候補者名のみ匿名化。英語は原文のまま。
事例C · 採用に至らず · 最初の要望から停滞まで
顧客は契約・支払い・改善feedbackまで行ったが、次の適合候補者を出せなかった。
顧客・採用体制
産業部品ディストリビューター。HR責任者が窓口となり、候補者を継続的に催促。
募集職種
Outside Sales Representative。
最初の要望・不足情報
B2B営業に加え、部品・ベアリング・コンベヤー・ギア・モーター等の現場製品経験が必要。
最終結果
採用に至らず
候補者を推薦
営業、CRM、顧客管理は強いが、直接のコンベヤー経験にgap。
顧客が具体的に修正
「もっと現場寄りの産業製品経験が必要」と返信。
顧客が次候補者を催促
改善結果が見えない。
人が謝罪・約束
翌週に2〜3名提示すると回答。
追加の手動確認
より詳しい基準を得るため複数回フォロー。
次の適合候補者を出せず
需要とfeedbackがあっても熱量が低下。
問題は顧客の協力不足ではない。botメールへの返信が、即時の基準更新と再検索を起こさなかったこと。
事例C · 本来必要だった体験
顧客の1つの返信から確認案を提示し、承認後すぐに再評価・再検索すべきだった。
01
産業分野の現場営業は必須か
絶対条件なのか、強い希望条件なのかを区別する。
02
どの隣接製品なら認めるか
部品、ベアリング、モーター、駆動系などの代替範囲を定義する。
03
どの流通・技術営業経験が転用可能か
直接経験がなくても、顧客・製品・現場構造が近いケースを判断する。
04
新規開拓と既存深耕のどちらが重要か
一般的な「営業経験」の中から、本当に必要な営業モーションを特定する。
AIが確認案を会話で提示 → 顧客が修正または承認 → 過去候補者を即再評価 → 48時間以内に更新候補者を提示。このUI/UXがあれば、人がメールを見つけて考えるまで待たずに済んだ。必要だった改善ループ
事例C · 原文エビデンス · Email
顧客の一通には、基準更新に必要な情報がすでに入っていた。
顧客HR → HOPEのレポートメール候補者提示後
“Doesn’t seem like a good fit.”
“We’re looking for industrial sales type like parts, bearings, conveyor belts, gears, motor boxes, etc.”
“Education and customer accounts seem fine but we need someone that’s more in the field.”
この返信に含まれていた構造AIが抽出できる内容
- 維持：学歴、顧客アカウント管理。
- 強化：産業部品カテゴリーの直接経験。
- 強化：デスク中心ではなく、現場での営業活動。
- 確認が必要：列挙製品は必須か、隣接製品まで許容するか。
Blucor担当 → 顧客HR7日後の手動返信
“We have tightened the screening criteria to prioritize candidates with more direct field and industrial sales experience…”
“We will do our best to have 2-3 more candidates ready … next week.”
約束は人が書いたが、その後の検索・可視化・期限管理をプロダクトが所有しなかった。
この会話が要求するUI/UXDesign input
- メール返信を即座にフィードバック意図として認識する。
- 変更案を短い会話で確認し、ワンクリック承認で再検索を開始する。
- 48時間の期限、検索中の件数、該当者ゼロの理由も顧客へ自動報告する。
失敗点：価値仮説ではなく、返信から実行までの所有権とスピード。
出典：実際のメール。氏名・会社名・候補者名・連絡先のみ匿名化。英語は原文のまま。
事例D · 採用に至らず · 最初の要望と基準改善
専任採用担当のいない会社で、直接経験に偏った基準は改善できた。
顧客・採用体制
複数都市の専門工事会社。専任採用担当なし。経営・現場・事務が兼務。
募集職種
13件の設備施工職。
最初の要望・不足情報
直接の特殊設備経験を必須化。開始日、福利厚生、雇用区分、通知、研修も不足。
最終結果
pause・採用に至らず
直接経験を必須化
隣接経験の強い候補者でもAIが不採用。
溶接・修理・工具・建設
仕事へ転用可能な現場能力があった。
隣接職種を必須条件へ
直接経験は優遇、特定メーカー経験は加点へ。
顧客が承認
基準改善の会話そのものは成功。
この「見落とした転用可能性 → AIの変更案 → 顧客の修正・承認」はalphaで再現すべき体験。
事例D · 24時間以内に採用担当のように動く必要があった
顧客が「面接したい」と返信しても、それが自動で面接アクションにならなかった。
24h
必要な応答速度
顧客・候補者への返信は1日以内でなければ、熱量と空き時間が失われる。
2名
他社オファーへ流出
適格候補者2名が、プロセス中に別の仕事を受けた。
1名
数時間で離職
1名は勤務開始後わずか数時間で退職し、常時パイプラインが必要だった。
可変
pause／resume
顧客は採用量に応じ、最初から作り直さず募集を止めたり再開したかった。
「面接に最適」「電話する価値あり」
採用意思がbotメールへ到着。
人が別担当へ転送
気づく・理解する・ルーティングする工程が必要。
候補者の電話番号を再依頼
情報と次の行動が届かず、顧客が催促。
当初の日程が失効
謝罪して再開した時には、元の面接候補日は使えなかった。
事例D · HOPEにある機能と、まだ人がマニュアルで担った部分
AI電話面接はある。しかし顧客の選択から人の面接までの運用は、人がマニュアルで対応していた。
HOPEに存在AI電話面接
候補者へのスクリーニング通話とレポート。
人がマニュアルで対応顧客の選択を解釈
botメールの「面接したい」を人が読み、転送。
人がマニュアルで対応人の面接日程調整
顧客と候補者の空き時間を人が回収し、候補日を確定。
人がマニュアルで対応SMS・リマインド
候補者への確認、SMS通知、リマインドを人が送信。
人がマニュアルで対応通話開始・監視
call transferを起動し、Call Historyを確認。
人がマニュアルで対応例外回復
遅刻、無断欠席、返信停止、再調整を追跡。
人がマニュアルで対応結果を状態へ反映
顧客・候補者・社内の進捗を同期。
人がマニュアルで対応次の候補者へ続ける
職種・都市ごとに同じループを再開。
問題はAI電話面接ができないことではない。顧客の選択、候補者の返信、日程調整、SMS、通話、結果更新を、人がマニュアルでつないでいたこと。顧客は後に別職種で戻っており、需要は残っていた。事例Dの結論
事例D · 原文エビデンス · Circleback + Email
「誰を採るか」より前に、「採用の次の一手をする時間がない」が問題だった。
経営者 · Feedback meeting専任採用担当なし
“I'm overwhelmed with what I need. I know who I need.”
“You want to know the truth? I don't even have the time to call those people.”
経営者 → HOPEのレポートメール候補者選択
“This person is perfect to interview.”
“short list him to call!”
Blucor担当 → 顧客手動の日程確認
“Will you be the one conducting the phone interview next, or will it be [Interviewer B]?”
“It would be helpful if you could let us know the preferred date/time for the call and the phone number to use.”
顧客： “[Interviewer A] will conduct the first interview on Wednesday. Then if we like them we will set up a follow up interview … on Thursday.”
この会話が要求するUI/UXDesign input
- 「perfect to interview」をコメントではなく、面接開始のintentとして扱う。
- 面接担当者・連絡先・空き時間を一度保持し、毎回メールで聞き直さない。
- 候補者へ候補日を送り、確定・リマインド・再調整・結果更新まで自動で続ける。
人の価値：顧客の短い意思表示を、担当者確認・候補者連絡・日程確定という複数の実務へ展開した。
出典：実際のCircleback transcriptとメール。氏名・会社名・候補者名・連絡先のみ匿名化。英語は原文のまま。
4社の横断比較
職種は違っても、成功と停滞を分けた構造は同じだった。
| 比較軸 | A・リサイクル | B・製造業 | C・産業部品 | D・専門工事 |
|---|---|---|---|---|
| 結果 | 採用成功 | 採用成功 | 採用に至らず | 採用に至らず |
| 最初の曖昧さ | 機械操作と独立した整備 | デスクと現場、経験年数、既存設備 | 一般営業と産業製品の現場営業 | 直接経験と隣接職種 |
| 有用な反応 | 現場責任者が真の整備力を定義 | 複数面接から現場での具体性が判明 | 必要な製品カテゴリーを明示 | 転用可能な経験モデルを承認 |
| 人の対応 | 診断・更新・連絡・日程調整 | 継続調整・質問編集・再評価・ATS連携 | 解釈が遅れ、次の候補者を出せず | 基準は改善、通信と面接運用は手動 |
| 結果を分けた点 | 次の行動が常に所有された | 学びが全工程へ反映された | 返信が即時の実行を起こさなかった | 面接意思が自動で面接にならなかった |
成功パターン · HOPEの機能を一つの体験にする条件
フィードバックが判断になり、判断がシステム変更になり、変更が候補者への行動になる。しかも速い。
State
現在の真実を知る
求人の現行版、各基準の根拠、候補者の段階、未回答、空き時間、約束した次の行動を保持する。
Judgment
何を変えるべきか判断する
必須と希望、一度の印象と一貫したシグナル、自動処理と承認が必要な例外を分ける。
Agency
次の行動を実行する
質問、更新、再評価、検索、連絡、日程調整、リマインド、再調整、報告を待たずに行う。
HOPEにはAI電話面接や日程調整などの実行機能がある。alphaで追加するのは、その間で文脈を保持し、適切な変更案を示し、顧客が迷わず応答できる接続レイヤー。接続レイヤー = State + Judgment + Agency + usable UI/UX
人とAIの責任境界
「Blucorの手作業ゼロ」と「顧客のコントロール」は両立できる。
常にAIが自動実行
低リスクの運用
- メール・SMS返信の理解
- 事実確認の追加質問
- 既存候補者の再評価
- 空き時間の回収
- 承認済み範囲の日程調整
- リマインド、状態更新、進捗報告
顧客のワンクリック承認
基準と会社の表現
- must-have／希望条件の変更
- AI面接質問の追加・削除
- 求人文言の重要な変更
- 候補者への重要な説明
- 変更前後と変更理由を差分表示
例外としてエスカレーション
高リスク・矛盾・反復失敗
- Hiring Manager間の矛盾
- 差別につながる採用条件
- 報酬など重要条件の変更
- 法務・契約リスク
- 日程調整の繰り返し失敗
alphaの成功は「人が裏で隠れて処理した」状態ではない。通常フローでは、AIの確認・変更案・次の行動を顧客が迷わず理解して応答でき、例外だけが明示的に見える状態である。
最小限で一貫したalpha体験
広い採用システムではなく、学びのある1周を完成させる。
01 · 受け取る
顧客が不完全なJDまたは短いメールを送る。
02 · 確認する
AIが、行動を妨げる不足情報だけを会話で聞く。
03 · 承認する
顧客が求人と選考基準をワンクリックで承認。
04 · 実行する
AIが求人公開、sourcing、screening、レポートを進める。
05 · 学ぶ
顧客が候補者へ自由記述でフィードバック。
06 · 改善する
AIが採用基準の差分を提示し、承認を得る。
07 · 戻す
1〜2日で再評価・再検索した候補者を提示。
08 · 面接へつなぐ
顧客が選んだら、人による面接を自動調整。
プロダクトの約束：不完全な依頼を渡し、普通の言葉で修正すれば、採用プロセスが止まらず進む。
Alphaのスコープ
主要な部品はすでにある。作るべきものは「接続部分」である。
すでに存在する機能
- 求人セットアップ・公開
- 候補者探索
- 履歴書選考
- AI電話選考
- 候補者レポート
- SMS送受信
- 一部の通話接続
- 候補者ステータス管理
不足している接続部分
- 顧客からのメール返信を理解する
- 不足情報だけを追加質問する
- 自由記述を構造化する
- 基準差分を提示し承認を得る
- 過去候補者を再評価する
- 更新後に自動で再検索する
- 両者の空き時間を回収する
- 日程調整・変更・通知・無断欠席対応
- 全チャネルで状態を維持する
Alphaの中心成功基準
不完全な依頼から始まり、実際のフィードバックと基準改善を1回以上経て、顧客が選んだ候補者との人の面接を設定する。クリティカルパス上のBlucor手作業はゼロ。
≤1日
依頼 → 承認済み求人
顧客の現実的な時間負担で検索を開始。
数分
feedback → 基準差分
面接の記憶が新しい間に変更案を提示。
≤48h
承認 → 更新候補者
既存候補者の再評価または新しい候補者。
≤24h
選択 → 面接設定
空き時間、確認、通知をAIが処理。
0回
通常フローの人手
メール転送、基準編集、日程催促、リマインドを手動で行わない。
2社+
実顧客で再現
異なるSMBの実職種で、ループ全体を少なくとも2回完了。
採用結果の位置づけ
オファーは極めて重要。ただしalpha唯一の合否条件にはしない。
Alphaの合格条件
人の面接設定まで自律運用
解釈、承認された学習、実行、状態管理、スピードという、プロダクトが制御できる価値を直接検証する。
＋
北極星指標／ストレッチ目標
少なくとも1件のオファー
できれば承諾または入社まで。品質の強い証拠だが、報酬、採用枠、顧客判断、身元・経歴確認、競合オファーにも左右される。
AIが通常運用
連絡、事実確認、日程、通知、再調整、状態更新。
顧客が重要変更を承認
基準、質問、求人文言は変更前後の差分を確認。
例外だけを人へ
矛盾、差別・法務リスク、重要条件変更、反復失敗。
10月の大きな開発へつなぐalpha
少人数HRの実顧客2社で、狭いループを最後まで運用する。
1
適切な職種を選ぶ
緊急性があり、意思決定者が1人以上参加し、候補者プールがあり、自由記述feedbackを返せる実案件。
2
全ハンドオフを計測
返信時間、承認、AI行動、例外、人の介入、候補者待機時間、面接完了を記録。
3
10月へ判断材料を渡す
どの判断を自動化でき、どれを軽い承認にし、どの稀な例外だけ専門家へ渡すべきかを決める。
HOPEを作り直すのではない。すでにある強い機能を、止まらない一つの採用ループへつなぐ。
4社の事例は、人が間をつなげれば価値が生まれることを示している。alphaで証明するのは、AIが提案する確認・基準変更・次の行動へ、顧客が迷わず対応できるUI/UXを作れるかである。