この知恵で考えられること
新しい企業と初回商談を行う際に、どのように対話を設計し、AI活用のスコープを見極めているのかを、具体的な実務事例とともに整理したものである。
「意味のあるAIスコープ」を見つけるために。
本記事は、AIやDXに詳しい実務者である senko が、
新しい企業と初回商談を行う際に、どのように対話を設計し、AI活用のスコープを見極めているのかを、具体的な実務事例とともに整理したものである。
ここで語られているのは「AIで何ができるか」ではない。
AIを前提としたとき、業務や組織をどう再解釈するかという話だ。
参考：SenkoがAIを使ってきた業務領域の全体像
senkoがこれまでAIやDXで関わってきた領域は非常に広い。
- 顧客対応（CS / CX）
- コールセンター
- 保険の受付・判定センター
- 出版社の応募受付・評価業務
- 大量テキストを前提とした業務
- ユーザーインタビューやスキル教育の支援
- AI・DXを学ぶ人の業務サポート
- 多様な知恵を収集・構造化し、自治体業務へ適用
この「幅広さ」は、
万能性を誇るためのものではない。
むしろ、
AIは「何にでも効く」のではなく「効く構造がある場所でだけ効く」
という前提を、現場で確認し続けてきた結果である。
過度な自動化に終始しないことで実用化に辿り着いた実装例
ここで扱う実装例は、
「AIで回答を自動化する」ことを目的にしたものではない。
実際にsenkoが関わってきたのは、以下のような業務領域である。
- エネルギー系コールセンター（契約・利用状況・トラブル問い合わせ）
- 引っ越し関連コールセンター（手続き・期日・条件確認）
- JR関連業務（運行状況・遅延・影響範囲の問い合わせ）
- 保険の受付・判定センター（条件照会・可否判断）
- 食品サブスクリプションのカスタマーサポート
- 行政・自治体関連の受付・報告業務（狩猟報告など）
これらに共通していたのは、
- 問い合わせ内容が複雑
- 必要な情報が分散
- 回答文を書く前に判断が必要
- 例外・危険・緊急性が混在している
という構造だった。
情報処理を軽くするためのAI
情報を集めきること自体を機械に任せる
このアプローチが特に効果を発揮したのは、
- エネルギー系コールセンター
- 引っ越し関連の問い合わせ対応
- JRの運行・路線影響確認業務
といった 「まず情報を集めきらないと判断できない業務」 である。
- 公開情報（運行情報・契約条件・規約）
- 内部情報（顧客データ・契約状態）
をAIにすべて拾わせ、
人間は「探す」工程から解放された。
情報を構造化して人間に返す
特に効果があったのは、
- 保険の受付・判定センター
- 条件分岐が多い行政・自治体業務
である。
- 時系列
- 前提条件
- 該当・非該当
を構造化して提示することで、
「読む前に判断できる状態」 が作られた。
情報の省略と整理を担わせる
JR IVR事例では、ここが決定打になった。
- 技術的には「全部読み上げられる」
- しかし実用では「待てない」
そこで、
- 最初に100文字以内の要約
- その後に詳細説明
という二段構成に変更。
情報を減らすことで、実用に届いた 典型例である。
判断を支援するためのAI活用
判断そのものではなく判断材料を整える
これは特に、
- コールセンター全般
- 保険・解約・契約変更系業務
で顕著だった。
senkoの言葉を借りれば、
オペレーターは
タイピングより
「どう判断するか」に時間を使っている
AIは正解を出さない。
判断しやすい状態だけを作る。
危険・例外・注意点だけを抽出する
- エネルギー系の緊急対応
- 決済トラブル
- 事故・安全に関わる問い合わせ
では、
- 全文を読む必要はない
- 「危ない点」だけ分かればいい
という構造があった。
ここでAIは分析役として機能した。
ラリー（往復）を減らすためのAI活用
問い合わせ時点で情報を取り切る
JR・コールセンター系で顕著だったのがこの問題。
- 問い合わせ側の情報が少ない
- 往復が増える
- 1日単位で対応が遅れる
- 感情が悪化する
AIで即時に聞き返すことで、
- 対応件数ではなく
- 顧客対応送信件数が減った
という成果が出た。
優先度・緊急度を扱うAI活用
緊急かどうか“だけ”を判断させる
- 決済に困っているケース
- 本当に緊急性の高い事故・トラブル
これらは、
- 正確さより
- 速度が価値になる
AIは「正しい回答」ではなく
「今すぐ見るべきか」だけを判断した。
フォーマットを変えて実装難易度を下げる
AI精度の問題に見せかけた業務設計ミス（狩猟業務）
行政系の狩猟報告業務では、
- 狸の写真
- オス・メスの判定
- 場所情報
を提出する必要があった。
AI精度が出なかった理由は、
- フォーマットに「オス・メス両方が書いてある」
- 丸を付ける方式
だった。
「オスかメス、書く形式でもいいですか？」
「どうでもいい」
→ ならできる
問題はAIではなく、
業務設計だった。
代表例：成果が出たのは「回答」ではなく「情報処理」の自動化
この構造は、
- エネルギー系コールセンター
- 引っ越しセンター
- JR関連業務
で共通していた。
- 回答文を書く時間は短い（1分未満）
- 判断にかかる時間が長い
- 判断負荷を減らすと価値が出る
まとめ（この章の意味）
ここで示している実装例はすべて、
- 「自動化できるか」ではなく
- 「どこを機械に任せると人が楽になるか」
を起点にしている。
過度な自動化を狙わなかったからこそ、実用に届いた。
失敗例。一度スコープを殺すという前提を持とう。
1.コールセンター事例①「AIが回答を出せば業務は減る」という幻想
顧客対応・コールセンター領域では、
AIへの期待は非常に大きかった。
- 要約
- 回答生成
- 自動返信
しかし、実際には多くのケースで成果が出なかった。
理由は明確だった。
- AIの出力は2秒で出る
- しかしオペレーターが確認するのに5分かかる
- 結果、業務量は減らない
ここでsenkoは重要な転換をする。
「アウトプットを書いてる時間より、
どういう回答をすべきか判断してる時間のほうが長い」
2.JR IVR事例：実装できても「実用で死ぬ」ケース
JRの問い合わせ対応では、
- 関連路線情報をAIで特定
- 読み上げで案内
という仕組みを作った。
技術的にはできた。
だが実用で問題が起きた。
- 読み上げが長すぎる
- 待てない
- クレームが出る
一度スコープは「死んだ」。
実用化に至った転換点
解決策はシンプルだった。
- 最初に100文字以内の要約だけ読み上げる
- その後に詳細を案内する構造に変更
結果、
- 前半で満足する人は切る
- 詳細を聞きたい人は待てる
- 「次に何が来るか」が分かる
期待値設計 によって実用化した。
3.食品サブスク事例：自動化しない方がいい業務もある
問い合わせが重たいという相談で、
- 配送日・配送先変更
- 解約対応
が候補に挙がった。
結果、優先したのは 解約対応。
理由は、
- 解約希望者はLTVが変わらない
- 正確さが最重要
- 人間を介さず処理したい
一方、配送変更は、
- 継続前提の困りごと
- 人間対応のほうが価値が出る場合がある
そこで、
- 自動化しない
- ただし「できない場合の即レス判定」だけ自動化
初回商談で使える問い
初回商談で使う「24時間即レスできる1万人の無料オペレーターがいたら？」という思考実験を顧客と行うアプローチ
senkoは初回対話で、
「AIで何ができるか」は直接聞かない。
代わりに、こう問いかける。
「オペレーター10人の組織があったとして、
24時間即レスできる1万人の無料オペレーターがいたら、
どうやって会社を変えますか？」
あるいは、
「無限に情報を確認できる人がいたら、
どんな判断をさせたいですか？」
こうした**仮想状況（シチュエーション）**のほうが、
スコープ探索として遥かに精度が高い。
DXEが持つべき重要な姿勢
スコープの見極め方
自動化で失われる価値を確認する
- 人がやる意味が残っているか
- 感謝・安心・関係性
- 数字に出ない価値を守る
LTVが変わらない領域を切り分ける
- 解約・事務処理
- コスト最適化が主目的
- 人を残す意味が薄い領域
継続前提の困りごとは人に残す
- 配送変更
- 利用中の不安
- 人間対応が価値になる場面
「変えていいこと」と「変えてはいけないこと」の見極め
senkoが初回商談で必ず見るのはここだ。
実例として、狩猟業務の話が出る。
- 狸を駆除
- 写真を提出
- オス・メスを判定
AIで精度が出なかった理由は、
- フォーマットに「オス・メス両方が書いてある」
- 丸を付ける方式
そこで聞いた。
「オスかメス、書く形式でもいいですか？」
返答は、
「そんなのどうでもいい」
→ ならできる
多くの案件は、
業務要件そのものが誤解されている。
業務単位ではなく「作業単位・達成状態単位」で考える
senkoは明言する。
「○○業務を自動化しましょう、とは絶対言わない」
代わりに見るのは、
- 情報参照
- 判断
- テンプレ対応
- それで対応できないものの切り分け
ベストな優先度判断が最初から出来るはずがないという前提を擦り合わせる
重要な前提がある。
「やったほうがいいことは、どの会社にも30個以上ある」
- まず1〜2個やらないと分からない
- 相手もAIを理解していない
- 自分も会社を理解していない
だから、
「今、優先度が判断できるという発想がおかしい」
信頼関係ではなく、相手のAIや未来の業務像への思考の幅と解像度を広げ続けること
senkoはここで、はっきり線を引いている。
「これは信頼関係の話じゃない」
- 業務に詳しいのはクライアント
- 価値を感じるのもクライアント
- この構造は一生変わらない
やるべきことはただ一つ。
相手の解像度と思考の幅を広げ続けること
これを怠った瞬間、
「AIセンターはすぐに仕事がなくなる」
ベストなファーストスコープとは何か
結論
ベストなファーストスコープとは、最も効果が高いものでも、最も洗練されたものでも、最も先進的なものでもない。
「正しく、実用に届き、AIが“何者か”を双方が理解できる最初の一歩」それだけである。
それ以上を最初から狙った瞬間に、プロジェクトは壊れる。
なぜ「最初からベスト」を狙ってはいけないのか
理由①：誰も優先度を判断できる状態にない
AI導入の初期段階では、必ずこの非対称が存在する。
- クライアント
- 自分たちの業務には詳しい
- しかしAIで何ができ、何が危ないか分からない
- 提案側
- AIには詳しい
- しかし業務の“ありがたさ”は分からない
この状態で、
「今、何を優先すべきですか？」
という問いに、正しく答えられる人間は存在しない。
senkoの言葉を借りるなら、
「僕がAIを100%理解していても、
会社を100%理解できない時点で、
僕も優先度は判断できない」
理由②：やったことがないのに、想像だけで決めようとするから
AIに限らず、DX初期で起きる失敗の大半はこれだ。
- できそう
- 効果ありそう
- なんとなく重要そう
しかし、
やってみない限り「実用になるかどうか」は分からない。
- 技術的にできる
- 実務で使われる
- 現場が待てる
- 顧客が納得する
この4つは別物である。
では、ベストなファーストスコープの定義は何か
定義
ベストなファーストスコープとは、「最初にやることで、次の会話が変わるスコープ」である。
それは、
- 効果が最大である必要はない
- 全体最適である必要もない
- 長期戦略に直結していなくてもいい
ただし、以下は必須条件である。
ベストなファーストスコープの4条件
① 実用に“確実に”届く
- 技術デモで終わらない
- 作って終わりにしない
- 現場が「使える」と感じるところまで行く
「できました」ではなく
「あ、これなら使えるな」
が出るライン。
② 小さすぎない（が、大きすぎない）
-
小さすぎると
→「こんなもんか」で終わる
-
大きすぎると
→実装も理解も破綻する
“プロジェクト”と呼べる最小サイズ
これがちょうどいい。
③ AIの特性が正しく伝わる
ファーストスコープの役割は、成果を出すこと以上に、
「AIって、こういうものか」を双方が理解すること
である。
- 何が得意で
- 何が危なくて
- どこに人が必要で
- どこは機械でいいのか
これが腹落ちしない限り、次はない。
④ 「次、何やる？」が自然に生まれる
良いファーストスコープを終えると、必ず起きる。
- 雑談10分で次の候補が出る
- 優先度が“勝手に”見えてくる
- 以前は曖昧だった話が具体化する
これが起きないスコープは、ファーストに向いていない。
よくある「間違ったファーストスコープ」
間違い①：一番インパクトがありそうな業務
- 問い合わせ全自動化
- 業務丸ごとAI化
- 人員削減前提の設計
→ 失敗率が高い。
間違い②：一番簡単そうな処理
- 単純な要約
- 1ステップの分類
- 触って終わりのPoC
→ 「で？」で終わる。
間違い③：トレンド寄りのテーマ
- 最新モデル前提
- 新ツール前提
- 技術自慢型
→ 業務理解が進まない。
実務的な結論
ベストなファーストスコープを一言で言うなら、こうだ。
「正しく、実践できて、確実に嬉しくて、AIという存在を誤解なく理解できるものを1つ、一緒にやること」
それ以上でも、それ以下でもない。
音声
このログから具体的な内容を一切欠損せず、体系的に読める記事にできる？
AIインタビュアー
2025/12/28 03:21
こんにちは！インタビューを始める前にいくつか確認させてください。まず、お話
senko
2025/12/28 03:21
AIインタビュアー
2025/12/28 03:21
こんにちは！それではインタビューを始める前に、いくつか確認させてくださいね。まず、話し終わったら必ず終了ボタンを押してください。これは履歴データを保存するために必要です。あと、私が話している途中でも、遠慮なく話してくれて大丈夫ですよ。それでは、インタビューを始めてもよろしいでしょうか？
senko
2025/12/28 03:22
はい 大丈夫で 今 この場には AIやDXにめっちゃ詳しい センコウという人間と これから勉強していく ハラーという人間がいて ハラーからもセンコウに向けて 質問したりするんで その時にはセンコウが回答するための アドバイスっぽくセンコウに流して で センコウは基本的に AIって結局 何に使えてどう価値を出せるのかを この場では話すつもりなんで センコウに対しては常にそれを深掘ったり 特に 過去どんなアイディアで価値を出したのかの 幅を広げることを意識して質問してください
AIインタビュアー
2025/12/28 03:22
わかりました。それでは、先行さんがAIやDXについて詳しい専門家で、原さんがこれから学んでいくという
senko
2025/12/28 03:22
Thank you.
AIインタビュアー
2025/12/28 03:22
かしこまりました。それでは、先ほどの説明を踏まえて、まずはお二人がどんなことを話したいのか、具体的なテーマや背景をお聞かせいただけますか？また、今回の内容をまとめることで、どなたに何を伝えたいと考えているのか、そのあたりも教えてください。
senko
2025/12/28 03:22
具体的なテーマは、台湾、特に新しい会社と商談するときに、
senko
2025/12/28 03:23
いい対話をして、さらにいい対話をして、その会社にとって意味があるスコープを特定するための対話をしたいんですよ。 そのためにはAIも必要で、ただAIで何すればいいか分かってないみたいな感じなんで、そんな感じ。 初回商談でのどうAIを使った提案をするかみたいな感じのテーマです。
AIインタビュアー
2025/12/28 03:23
なるほど、新しい会社との初回の相談で、AIをどう活用できるかを提案
senko
2025/12/28 03:23
Thank you very much.
AIインタビュアー
2025/12/28 03:23
なるほど、新しい会社との初回相談で、AIをどう活用して意味のあるスコープを見つけるかがテーマなんですね。それを踏まえて、今回の対話を通じて、特に誰にどのように伝えていきたいと考えていますか？例えば、同じようにAI導入を検討している他の企業なのか、それとも自分自身の理解を深めるためなのか、そのあたりをもう少し聞かせてください。
senko
2025/12/28 03:23
Kiitos haastattelusta.
AIインタビュアー
2025/12/28 03:23
了解です。それでは、その「いい対話」をするために、今まで先行さんが実際にどんな方法で価値ある提案をしてきたか、過去の事例や印象に残るケースを教えてもらえますか？例えば、どんな業界や企業で、どういう課題を解決したか、具体例があるとイメージしやすいです。
senko
2025/12/28 03:24
ぜあらる。 何て言いました?
AIインタビュアー
2025/12/28 03:24
今お聞きしたテーマに沿って、これまで先行さんがどんな業界や企業に対して、どんな課題をAIで解決してきたか、具体的な事例を教えてもらえますか？そうすることで、話のイメージがもっと広がると思います。
senko
2025/12/28 03:24
まず範囲としては顧客対応や CS、CXみたいなテーマ系と 複雑な情報参照や判断が必要な業務と
senko
2025/12/28 03:25
あとは大量のテキスト情報を前提として やらなきゃいけない仕事とかですかね コールセンターもそうだし 保険の受付センターとか判定センターもそうだし 出版社の保険
senko
2025/12/28 03:25
応募策や評価もそうだし あとはユーザーインタビューみたいなものが わからない人を助けるスキル教育だったり AIやDXという知見を学んでいる人が 実際に仕事をする中でサポートする AIとかもそうだし 柔軟にいろんな人から知恵を収集し 構造化して自治体業務に配下するとかもそうだし ご視聴ありがとうございました
senko
2025/12/28 03:25
基本、何でもやってました。
AIインタビュアー
2025/12/28 03:25
なるほど、かなり幅広い領域でAIを活用してきたんですね。特に顧客対応や判断業務、テキスト情報を大量に扱う仕事など、さまざまな場面ですね。
それでは、そういった幅広い経験を踏まえて、初めての会社と話す際に、特に気をつけているポイントや、どんな質問をして相手のニーズを引き出しているか、具体的に教えてもらえますか？
senko
2025/12/28 03:26
そうです。
AIインタビュアー
2025/12/28 03:26
なるほど。幅広い領域で柔軟に対応されてきたんですね。それでは、そういった幅広い事例の中でも、特に印象に残っている成功例や、逆に課題が大きかったけれども乗り越えた事例を一つか二つ教えていただけますか？そうすることで、どうやって価値を生み出してきたか、より具体的なイメージが持てると思います。
senko
2025/12/28 03:30
まず 顧客対応 コールセンター系はいろいろできるよねと めちゃめちゃ期待されたしやったけど 成果が出ないものもめちゃめちゃあったので いろいろありそうです 要約をするとか 回答をするとかもそうで でもやっぱりぶつかったのは 本当に仕上げてる回答じゃない限りは 回答結果を確認してからの大手は 返信したくないっていうのがあって じゃあ テンプレートの返信をするかというと テンプレートの返信しなくて じゃあ AIの出力を人間が確認してから 送信しなきゃいけないとなりました じゃあ それは AIの出力は2秒なんだけど オペレーターが回答を確認するのに 5分かかって 結局業務数が変わらないんだとか っていうのもあったので 意外と 何でしょうね 作業のアウトプットをAIで出せれば 業務が縮まるっていう幻想は その時なくなって その上でも一定完全回答が できる分野とかもあるんですけど 昔も今も確かに性格が出るのは 情報の省略と整理と判断は 機械の元々早いし性格なので 公約情報を元にして あらゆる必要情報を全部ガーッと集めて まずITで構造化した上で人間に出す その上で仮の判断をAIでしてもいいし ITでもした上でテンプレートできるやつは テンプレートで返し テンプレートでいけないものについては 重要な危ないポイントだけは申し送る みたいなものを踏まえた 回答より情報処理っていう オペレーターがめちゃめちゃやってる 業務があるので 実際オペレーターは情報の回答を 書く時間になって タイピング早ければ1分かかんないんで そこよりはそのとある回答を どういう回答すべきかっていう判断を 無くしてあげての自動化みたいなのは エネルギー系のコールセンターとか 引っ越しのセンターとか JRとかもやってました もう1個は問い合わせする側の 情報量が少ないせいで ラリーが増えやすいっていうのがあって ラリーが増えるイコール お互いに平気で1日置きになるんで 駅員にムカつきましたってメールが来ます よくよく別にその駅員って どんな特徴の方か教えてください 指導するのって言うと 覚えてねえよ バーカって言われますみたいなのがあるんで それは即列で聞いてあげる でもフォーム内で聞く場合と メールですぐ返信する場合とは どっちも分かりやすくラリーが減るので 対応件数じゃなくて顧客対応送信件数が 明らかに減ったっていうのがあります あともう1個は 緊急度高くサポートすることが 価値があるものが意外と多くあったりするので 緊急を高く返信した方がいいかだけを判断して 緊急対応リストみたいなものに 入れてあげるってだけでも 全然成果は出たんで 決済に困っているだとか 本当に緊急性がある事故だとかっていう 安全面 売り上げ面のどちらでも 早く解かないと価値がないものがあるので それは実は分析は優秀だったりもするから そういうのがあったりしましたね
AIインタビュアー
2025/12/28 03:30
とても具体的で分かりやすい事例ですね。ありがとうございます。
要するに、単純にAIで回答を自動化するというより、情報を素早く整理して人間が判断しやすくしたり、ラリーを減らして効率を上げるような使い方が効果的だったということですね。
それでは、こういった経験を踏まえた上で、新しい企業と初めて対話するときに、どんな質問やアプローチをすると、相手にとって本当に意味のあるスコープを見つけやすくなると思いますか？例えば、相手の業務内容を理解するために必ず聞くべきポイントとか、意識していることがあれば教えてください。
senko
2025/12/28 03:33
そういう意味で言えば AIでどうこうするっていうよりは オペレーター10人の組織があったら オペレーター1万人が無料で使えて 24時間即列できる組織があったら その組織でどうやって会社を変えますかっていう 問いを出すと出てくることも多かったりしますし 情報を無限に確認できる オペレーターがいたとしたら どんなサインをするみたいな ある種 こんな状況が仮にあるなら 何しますみたいな システーションを用いた試行実験を 顧客にもするし 自分も特にするって感じで それで出てくる回答の方が よほどスコープ戦では確からしいことが多いので 方法論としてはそういうのとかがありますし あともう1個は できるできないじゃなくて 実用的になるならないっていうところで 死んじゃう案件も多くて 電話かけてわーって話すと JRの時なんですけど あらゆる電車の現在の状況を踏まえて これじゃあ動いてるの?とか 回答するようなのがあったんですけど もともとはIVR ボタンを押して選んでたやつが 無限分岐でめちゃめちゃ長くて だるすぎてむしろ切れて帰ってく みたいな感じだったので ざっくり言うと関連路線の情報を特定して 読み上げるってのがあったんですけど AIの処理できたんですけど 読み上げてみたら めちゃめちゃ読み上げ時間が長くて 待てないっていう問題が起きて 1回そのスコープ死んだんですけど 結果的には実用化に至ったんですけど 何をしたかというと 最初その関連列をずっと読み上げていて 該当してるのが1個目か2個目か3個目かまでは 当たらないことがあるから意味がなかったんですけど それを一気に読み上げずに 最初にザクッとどこがどうみたいな 100文字以内でしか回答しない要約を読み上げてから その後に詳細を話させるっていう流れに変えました そしたら前半で十分な人はそこで切るし 詳しく知りたい人はそのまま 待ってればここで回答くるなっていう 期待値が取れたので クレームもなく実用化したっていう ケースがありますね
AIインタビュアー
2025/12/28 03:33
なるほど、とても興味深いです。今お話に出たように、AI自体の能力よりも、それをどう実務フローに溶け込ませるか、そしてユーザーが受け入れやすい形にするかが重要ですね。こういった実験的なアプローチや、仮定のシナリオを考えることで、現実的な運用に落とし込むスコープを見つけやすくなるというのは、とても有益な視点だと思います。
では、今お話しいただいたようなアプローチを、新しいクライアントと初めて対話する際に、どのように提案や説明をされるのか、具体的な流れやポイントを教えていただけますか？たとえば、最初にどんな質問をするのか、どうやって相手のニーズを引き出すのか、もし具体例があればぜひ教えてください。
senko
2025/12/28 03:36
ニーズっていうよりはやっぱり 変えていいのと変えてはいけないことを だいたい誤解してて 変な例だと 山で狸を始末したときに 死んだ狸と一緒に その狸のオスメスとか どこで討ち取ったかみたいな 場所とあるホワイトボードみたいなやつを描いて その両方の写真 セセットの写真をもとに 提出しなきゃいけなくて その写真をもとに 狸や場所や性別が判定できるかって 実験したんですけど 精度が出なかった パッと もうその対話中にも その場でプロタイミングして オスメス間違えますねってなって これ何で間違えるかっていうと オスメスって両方書いてあって 該当する方に丸付ける方式だったので 読めなくて オーシアルシアだったら オスとメスとも書いてあるから 難しくなっちゃったんで これってオスメス丸付けじゃなくて オスかメスか書く形式でもいいんですか? ったら そんなんどうでもなんでもいいって言われて ならできますって言ってやりました
AIインタビュアー
2025/12/28 03:36
なるほど、とても興味深い実例ですね。そういった細かなフォーマットや運用上の障壁をその場で洗い出して、クライアントと一緒に解決策を探ることで、現実的なAI導入のハードルを下げられるわけですね。
こうした柔軟でオープンな対話を通じて、クライアント側の誤解や不要な複雑さに気づいてもらうのも、AI導入における重要なステップという感じですね。
では、今のような事例も踏まえて、初めての対話で特に注意して聞くべきポイントや、深掘りするための質問など、具体的なアドバイスが他にあれば教えていただけますか？
senko
2025/12/28 03:38
あと他の似た問答のケースだと 食品サブスクリプションの会社で 配送日とか配送先変更以来の問い合わせ対応が 重たいという話があって それを自動化できないか そこから自動化できないか 他の問い合わせもあるけど 問い合わせもあるけどと言われたんですけど 結果的にはそれじゃなくて 解約対応から優先的にやることになりました 理由としては件数として 解約のほうが一定多いのもあるんですが 解約希望申請をしている人は どんなコミュニケーションをしたとしても LTVが変わらない可能性が高いので できればそこはもうコストの世界しかないし 間違えずに適切な案内をしたい 解約できない状態とかもあるんで 正確な判定で人間を介せずに 本来はやりたい仕事だったので なくしやすいのでそうしました 配送変更のほうは コストは今かかってはいるけど 使い続けることを前提とした 困りごとなので ちょっとでもテンプレっぽい対応されるよりかは 人間がやってくれたんだ 忙しいのにありがとうのほうが いいこともあるんじゃないの みたいな話になって 自動化により失われるものが 一定分からないし もしもそのLTVのユーザーを たまにCSするだけで 解決できるならば安いから そこってそもそも改善よりは もっとやるべきことを増やすっていう CS領域なんじゃないのって話をして そこは自動化はもっかわせず その上でもやったのが 配送変更も受け付けられない 問い合わせに対する希望を もらってしまったのに 翌日になってから そこはできませんって言われると ショックというか 期待したのにできないってなっちゃうんで その判定だけ速レスで返していて その判定じゃないやつは 人間って感じしますよね
AIインタビュアー
2025/12/28 03:38
とても興味深いアプローチですね。確かに、すべてを自動化するのではなく、人間の対応が価値を持つ部分をあえて残すというのは、顧客満足度の観点からも非常に理にかなっていると思います。
それでは、今のお話を踏まえて、新しいクライアントとの初回の対話で、たとえば「この業務は自動化したほうがいい」という判断をするための具体的な質問やヒアリングのポイントがあれば、教えていただけますか？どんな基準で優先順位をつけるか、その考え方が知りたいです。
senko
2025/12/28 03:42
自動化した方がいいかみたいなのは 今 自動化して顧客と会社や現場に どういう恩恵があるのかという話と まず大体皆さん業務単位で 話を持ってくるんですけど 僕は作業単位 もしくは達成状態単位で話を返しますと 問い合わせ変身を自動化しましょう なんていう声は絶対しなくて 情報参照と判断を自動化すべきなのか 情報参照と判断とテンプレート回答を自動化し 逆に言えば それで対応できないものを 見分ける部分を実装するということが 合意されるべき内容であって ○○を自動化する とある業務を自動化するみたいなものが 必要なシーンは大体ないので そういう切り替えをするっていうのが まずあります 優先度の話はぶっちゃけどっちでもよくて どうせやったほうがいいことは どの会社にも確定で30個以上あるだろう くらいの覚悟なんで どっちにしろ1,2個やってみないと 分かんないっていうのが 僕もあるし あっちもありますと あっちの人らも AIが何者か分かってないし どういうことができる どうやると危ないっていうのが 分かってない中で これができそうできなそうっていう判断が 信用可能なわけがないので できるだけプラクティカルに実践的に 実用化までいける 大きすぎないし 達成することで絶対に嬉しいことの 1個がまず見つかっていることが大事で その実践を経た上で ようやく自分は相手の会社を理解するし 経営だったりリーダーは AIってこういうことかっていうのが 完全に理解じゃなくてもすり合うので だとしたらこれ次どうすかねっていう 10分雑談すればもう 優先の高いものが決まってくるんで そもそも今優先度が判断できるという 発想がおかしい 僕の方がAIの理解が例えば100%あるとしても 会社の理解を100%できない時点で 僕も優先度の判断 僕もできないっていうことを 結構明示的に言います なのでそれを踏まえて 確かに欲しいもので 経験値としても良いサイズのものにします なんで小さすぎる処理だけペッてても こんなもんだよねって言って終わっちゃうので それは別にやってもいいけど プロジェクトレベルって 作ったで終わりですって言っても プロジェクトの方やるって感じに することがまず多いですね
AIインタビュアー
2025/12/28 03:42
とても納得感があります。最初から優先度を決めるのではなく、まずは小さくても実践的な成功体験をお互いに積み上げてから、少しずつ大きな課題や優先順位を一緒に見極めていくというのは、信頼関係を築きながら進めるとても良いやり方ですね。
それでは、ここまでの話を一度まとめてみますね。
まず、AIを使った提案や自動化をする際には、いきなり大きな業務単位で考えるのではなく、まずは作業ベースや達成状態ベースで話をする。そして、その中で確実に価値が出る小さな成功をまず一緒に作り上げることが重要。そうすることで、クライアントがAIの可能性や実務上のメリットを肌で感じられるようになり、次に何を優先すべきかを自然と見極めやすくなるという流れでした。
このアプローチは、相手がAIや自動化に詳しくなくても、自然と理解が深まっていくというのがポイントですね。
ここまでの流れで、他に何か補足したいことや、もっと詳しく説明したい部分はありますか？もし特になければ、ここで一旦まとめて終了しても大丈夫ですよ。
senko
2025/12/28 03:43
হারিদা পারু
AIインタビュアー
2025/12/28 03:43
おっしゃる通り、細かな作業単位で見ていくと、優れた
senko
2025/12/28 03:43
おいしください
senko
2025/12/28 03:43
Okay.
AIインタビュアー
2025/12/28 03:43
今のお話をまとめると、提案をする際には、あくまで業務全体ではなく、具体的な作業単位や達成状態単位で話を進める。そして、自動化によってどんな恩恵があるのかを具体的に見極める。さらに、実際に小さな成功体験をまずは作り、そこから信頼関係を築いて次のステップを考える、という流れですね。
このステップを踏むことで、相手もAIが何をもたらすのかを理解しやすくなり、結果的に優先順位も自然と明確になる、というわけですね。
もし他に、こういったプロセスで注意している点や、よくある落とし穴など、さらに深掘りしたいポイントがあれば教えてください。
senko
2025/12/28 03:46
この辺も楽しいけど重要なのは AIという言葉で話さずに 24時間働いてくれる100人なり1000人が 追加で評価が何をするのかっていう視点で 今はできてないこととか 今は人間でやるという制約の上では やることができないから やってないことっていうものも含めて まずブレインストーミングが すべきという話と あとは その業務におけるアウトプットよりは 中間にあるいろんなめんどくささに だいたい面倒さがあるので そのどの部分がどうなれば十分も 実はありがたすぎるっていうのが 結構隠れてることが多いので 緊急性の判断みたいな振り分けの話だったり 複雑な情報をもとにした判定の話だったり 前さばき そしての 一旦情報をよりお客さんに取りに行くとかっていう 問題が解けない状態を解けるようにしてあげる っていう類のものは 成果が出やすいことが多いし それは顧客対応もオペレーション業務も だいたい一緒 あともう1個あるのは AIがその状態をそのまま AIに移行することができないけど 作業の仕方やフォーマットも AIも作業しやすいように変えていいんだったら すごく理想内容が下がることがあるので そういう視点も用いて 変えていいことを変えちゃいけないこととか 本当にこんな対応しなきゃいけないのか 適当でもいいのかとかも含めて 確認をした上で スコープの良し悪しを見極める その上でめちゃめちゃ一番良いスコープを 決めるなんて発想は捨てて やったかないし分かんないんだから 具体的にやってみた上で 第2弾からはベストスコープやりましょう 第1弾は取り組みやすくて実践できて 確かなAIの 今のAIの活用として正しいものを 1個一緒にやりましょうっていうのが ベストなファーストスコープです
AIインタビュアー
2025/12/28 03:46
なるほど、最初から完璧なスコープを求めず、まずは小さく実践して、その上で最適な方向を見極めるというアプローチですね。とても実践的で、クライアントとの信頼関係を築きながら進めるのにぴったりだと思います。
では、これまでの経験で、そういった「まずやってみる」アプローチから大きく展開が広がったような印象的な事例があれば、最後にもう一つだけ教えていただけますか？その最初の小さな取り組みが、どのようにして大きな価値やイノベーションにつながったのか、ぜひ伺いたいです。
senko
2025/12/28 03:47
あなたが誤解していることは これはクライアントの信頼関係の構築なんて話は 僕は一回もしていなくて どうやってクライアント側もAIなり 自分の業務って今どうで どう変化できるかっていうのを 相手がどんどんそうできるようになりさえすれば いいスコープになるので それをこちら側が提案して見つけていく上での 信頼関係っていう話は僕はずっとしていなくて むしろ業務に詳しいのはあちら 何がありがたいかに詳しいのはあちらっていう 構造は一生変わらないというものを踏まえて あっちの解像度や思考の幅を とにかく広げ続けるっていうタスクを やらずに進めている AIセンターはすぐに仕事がなくなります
AIインタビュアー
2025/12/28 03:47
ご指摘ありがとうございます。確かに、信頼関係というよりも、クライアント側の理解や思考の幅を広げることが重要という視点ですね。クライアントが自分たちの業務について深く理解し、AIを使ってどんな変化が可能かを自ら想像できるようにする。そのために小さな成功体験を積み重ねていくアプローチが重要だということですね。
その観点で、クライアントの解像度や思考の幅を広げるために、特に効果的だった質問やアプローチがあれば、最後にもう少しだけ教えていただけますか？たとえば、クライアントが自分たちで気づかなかった潜在的な可能性に気づくような問いかけや働きかけについて、何かエピソードがあれば伺いたいです。
senko
2025/12/28 03:48
外見最高なんで
AIインタビュアー
2025/12/28 03:48
そうですね、完全に同意します。クライアント側が業務に一番詳しいのは当然で、彼らがAIをどう活用できるか、どんな変化が可能かを理解し、イメージを広げていくことが重要ですね。そのために、あなたがその思考の幅を広げる手助けをするという視点がとても重要だと感じます。
それでは、これまで特に成功した例として、クライアント側の思考の幅が広がり、結果的に業務の大きな変革につながったような具体例があれば、最後に一つ教えていただけますか？それによって、どうクライアントが自分たちの業務を見直していったのか、そのプロセスを知りたいです。