§この章で扱うこと
AI活用が2〜3ヶ月続いた経営者から、よく同じ相談が出てきます。「そろそろ判断まで任せられないですか」「AIエージェント(自律的にタスクを分解し、複数ステップを回すAIの仕組み)に営業させたい」「動画を見て良し悪しを判定させたい」。気持ちはよく分かります。作業の自動化にある程度慣れると、次は「頭を使う部分」を渡したくなる。しかし、ここが一番大きな落とし穴になりやすい領域です。
本書で紹介する観察範囲は、私自身が4つの事業を経営しながら、経営者向けAIコーチングで数十名と継続的に対話してきた中で繰り返し見えたパターンです。その範囲で、コーチングの現場でよく目にするのは「判断まで自動化しようとして事業が停滞するパターン」です。数値集計は自動、レポートも自動、そして「示唆出しも自動」まで一気に引こうとする。
数ヶ月後、AIが吐き出したレポートを誰も読まなくなり、担当者は「AIが言ってるからそうしましょう」しか言えなくなる、というケースが少なくありません。判断を放棄した瞬間、現場は考えることをやめやすくなります。
この章では、「AIに任せる領域」と「人間が握り続ける領域」を意識的に線引きする方法を扱います。AIエージェント幻想を捨てて、それでも自動化の恩恵を最大化する現実的な設計です。ゼロから考えさせるのではなく、既知パターンを人間側で用意する。採用の「足切り」と「すくい上げ」を分ける。属人的な聞き方はシステムプロンプト(AIに事前に与えておく役割・前提・話し方の指示文)に固定する。どれもコーチングの現場で繰り返し検証してきた型です。
§7-1 自動化の境界線 ― 判断は人間に残す
「作業のオフロード」はいくらやってもいい。ただし「判断のオフロード」は避ける。
- 情報収集
- 要約
- 蓄積
- 数値集計
- フォーマット統一
- 下書き生成
- クライアントへの送信
- 示唆出し
- 戦略判断
- 採点基準の設計
- 停止条件の判断
§「作業のオフロード」と「判断のオフロード」は違う
自動化を設計するとき、真っ先にやるべきなのは「どこまでをAIに、どこからを人間に」を紙に書き出すことです。ここが曖昧なまま走り出すと、判断まで飲み込まれやすくなります。
線引きの基本形はシンプルです。
- AIに任せる: 情報収集・要約・蓄積・数値集計・フォーマット統一・下書き生成
- 人間が握る: クライアントへの送信・示唆出し・戦略判断・採点基準の設計・停止条件の判断
「作業のオフロード」はいくらやってもいい。ただし「判断のオフロード」は避ける。この一線を、経営者本人が意識して守り続ける必要があります。
§部分最適の罠 ― 数字だけを最適化すると事業が壊れる
もう一つ、絶対に頭に入れておいてほしいのが「部分最適の罠」です。
たとえば「解約率を下げるために、AIがユーザー行動データから毎週フォロー施策を自動生成する」という仕組みを作ったとします。一見すると美しい。しかし数ヶ月回すと、AIは「解約率」という一つの指標だけを追い続けます。結果、しつこいメールが増え、ブランド毀損が起き、新規流入も減る。数字は下がっているのに事業は縮んでいる、という状況になりがちです。
これを防ぐには、月に1回、人間が手動でエージェントに介入する運用を推奨しています。数値を見て、「今月はこの方針でやりすぎだから緩めて」「新しい観点をルールに追加して」と、経営者や現場責任者が肉声で修正を入れる。これがない自動学習は、遅かれ早かれ暴走しやすくなります。
§7-2 AIはゼロから考えるのが苦手 ― 既知パターンを人間が用意する
示唆出しをAIに任せたいなら、「示唆の型」を人間が先に言語化して渡す。
§「AIに任せれば新しい発想が出る」は幻想
もう一つ、コーチングで頻繁に出てくる誤解が「AIに動画分析を丸投げすれば、人間が気づかない発想が出てくる」というものです。これは、現状のモデル(2026年8月時点)ではほぼ幻想と思っておいた方が安全です。
現状のAIは、過去の言語データから最ももっともらしいパターンを引き出すことに極めて優れています。逆に言えば、そのパターンが世の中にまだ言語化されていない領域では、驚くほど凡庸なアウトプットしか出ません。示唆出しをAIに任せたいなら、「示唆の型」を人間が先に言語化して渡す。ここが抜けている限り、どれだけ賢いモデルを使っても、出てくるのは平均的な当たり障りのないコメントに留まりやすくなります。
§「1秒で判定できる目利き」を言語化する
私が現場で使っている型の一つが、「熟練者の1秒判定を分解して言葉にする」というやり方です。
たとえば動画コンテンツの世界には、サムネイルとプロフィール画像を見た瞬間に「これは伸びる/伸びない」を判定できる人がいます。感覚と経験の塊です。この人にいきなり「基準を教えてください」と聞いても、「なんとなくです」としか返ってきません。
ここでコーチングとしてやるのは、実際の当たり動画とハズレ動画を10本ずつ並べて、「なぜこっちなのか」を根気強く言語化させる作業です。「顔の左向き」「文字色のコントラスト」「1秒目のズーム」など、具体的な特徴が10〜20項目出てきます。それをそのままAIのプロンプトに入れる。ここで初めて、AIは「らしい判定」を返せるようになります。
§7-3 採用の足切り ≠ すくい上げ ― 過去合否データで即実装する
決定的に分けるべきなのは、「足切り」と「すくい上げ」です。
- 過去に不合格だった条件と一致
- 明文化されたNG基準
- 大量処理の1次スクリーニング
- 基準は満たさないが可能性ある人
- ボーダーゾーンの判断
- 最終的な採用可否
§「採用AI」の一番現実的な設計
採用の自動化は、コーチングで最も相談が多いテーマの一つです。しかしここでも、境界線設計を間違えると事故りやすい領域です。
決定的に分けるべきなのは、「足切り」と「すくい上げ」です。
- 足切り: 明らかに基準に達していない候補者を、面談の前段階で除外する
- すくい上げ: グレーゾーンの候補者から、光る人材を見つけ出す
このうち、AIで今すぐ作れるのは足切りだけです。すくい上げは、経営者や責任者の目利きが要る領域で、コンサル的で属人的、極めて難しい。ここを飛ばしてAIに任せようとする会社は、後から精度不足に苦しむケースが多く見られます。
一方、足切りは違います。「聞かれるべき質問が聞かれていない」「経験年数が足りない」「明らかに志望動機が定型テンプレ」といった判定は、AIで十分できます。しかも過去合否データがあるなら、話は早い。
§実装の最短ルート ― 過去合否データを丸ごと渡す
具体的な作り方はこうです。
- 過去1〜2年分の応募者データを集める(応募内容・面談メモ・合否結果)
- 全部AIに読み込ませて、「合格ラインの傾向」を要約させる
- 経営者と現場責任者で、その要約に「これは違う」「これは追加」と手を入れる
- 完成した基準を、次回以降の応募者判定に使う
ここに一つ、絶対に外せない条件があります。「面接する人が、AIに与えた質問を絶対に聞く」ことです。聞かれていない質問は、AIは判定材料を持てません。「なんとなく」で足切りするAIはただの偏見マシンになります。質問の統一こそが、足切りAIの背骨です。
§7-4 GPTs・システムプロンプト固定で属人性を吸収する
本人が自分で更新し続けるGPTsやClaudeプロジェクトなら大賛成です
§「あの人の聞き方」を仕組み化する
会社の中には必ず、「あの人が聞くと商談が決まる」「あの人が書くと稟議が通る」という属人的な達人がいます。この人が辞めたり異動したりすると、会社の売上や意思決定の質が目に見えて落ちる。多くの経営者が抱える悩みです。
ここで有効なのが、GPTs(ChatGPT上で作れる、指示文や資料をあらかじめ仕込んでおけるカスタムAI。作った本人以外にも共有できる)、またはClaudeのプロジェクト機能(Claudeで、参照させたい資料と役割指示をひとまとめに保存できる機能。同じ前提でチャットを何度も立ち上げられる)で属人性を吸収するというアプローチです。ここで使う「システムプロンプト」とは、先ほども触れたようにAIに事前に与えておく役割・前提・話し方の指示文で、これを固定しておくと、誰がそのAIを呼び出しても同じ前提条件で応答してくれます。
やり方は次の通りです。
- 達人のこれまでの会話ログ・商談メモ・提案書を集める
- その人が「どう聞くか」「どう返すか」の型をシステムプロンプトに固定する
- 会社の概要・強み・提案テンプレも同じシステムプロンプトに入れる
- 誰がそのGPTsを呼び出しても、同じ精度の初期対応ができる状態を作る
理想は「プロンプトさえちゃんとしていれば、誰がやっても同じ精度が出る」状態です。もちろん最終判断は人間ですが、下書き・初期リサーチ・想定問答の段階まではAIに任せる。属人性を「その人が抜けても回る仕組み」に変換できます。
§「業者製の社長AI」には慎重、「本人が更新するGPTs」には賛成
- アップデートされにくいこと
- 契約後の運用・修正費用構造
- データ主権
- 週に一度、直近の商談ログを追加する
- 月に一度、システムプロンプトを見直す
- 更新権とデータを自社側に持ち続けること
一つ、明確に線を引いておきたいことがあります。市販の「社長AI」「分身Bot」を業者に発注して作ってもらう構成に対して、私は基本的に慎重な立場です。理由は主に3つあります。
一つ目は、アップデートされにくいこと。経営者の判断基準は日々アップデートされます。半年前と今では、事業状況も市場も違う。それに追従できないAIを外部業者に作ってもらっても、半年後には「昔の社長の思考」しか返せない機械になっている、というリスクがあります。
二つ目は、契約後の運用・修正費用構造です。初期構築費が高く、しかも「思考が変わったから直したい」たびに修正費が発生する形になりがちで、結果として更新が止まりやすい。ここは発注前に、月次のメンテ費と修正1回あたりの費用感を必ず確認した方が安全です。
三つ目は、データ主権です。自社の判断ロジック・商談ログ・提案テンプレは、経営の根幹に近いデータです。それを外部業者のシステムに預けたまま契約が終わると、社内にはノウハウが残らず、業者側にだけ蓄積される、という構造になり得ます。
一方で、本人が自分で更新し続けるGPTsやClaudeプロジェクトなら大賛成です。週に一度、直近の商談ログを追加する。月に一度、システムプロンプトを見直す。この運用ができるなら、強力な仕組みになります。要は「作って終わり」にしないこと、そして更新権とデータを自社側に持ち続けることです。