AIの未来を語る前に、私は月曜日の営業を変えたい
孫正義氏の講演から考える、HDGの経営と組織の次の一歩
AIの新しいニュースを見ると、私はまず、次のモデルは何ができるのかと考えます。
今まで難しかった分析ができるようになるのか。複数の仕事を任せられるのか。私の考えを、もっと深く理解してくれるのか。経営者としても、一人の利用者としても、その進歩には強い関心があります。
しかし、AIとの対話を重ねるほど、別の問いも大きくなってきました。
AIが賢くなることと、私たちの会社が強くなることは、同じなのだろうか。
画面の中には、良い分析や整った提案が次々に出てきます。それでも、営業担当者が次に何をすべきか分からなければ、顧客との会話は変わりません。調べる時間が短くなっても、確認や承認の順番が曖昧なら、仕事は途中で止まります。
社長である私だけが多くの情報を扱えるようになり、すべての判断が以前にも増して私に集まるのなら、便利さの裏側で、会社の弱点を大きくしている可能性さえあります。
孫正義氏の「SoftBank World 2026 特別講演」をきっかけに、私はAIの未来を、もう一度HDGの日常業務に引き寄せて考えました。
壮大な話を聞いたからこそ、最後は小さな問いに戻りたい。
来週の月曜日、私たちの営業は、何を一つ変えるのか。
1．未来の数字を、そのまま自社の戦略にしない
2026年7月14日の講演で、孫氏は2040年を見据え、AIが世界GDPの約20％を担い、100兆個のAIエージェントや10億台のヒューマノイドが活動する将来像を示しました。これらは孫氏の予測であり、実現が確定した数字ではありません。公式講演レポート
私にとって重要だったのは、この数字をそのまま信じるか、否定するかだけではありません。将来の姿を具体的に描き、そこから現在の選択を考えるという、経営者としての姿勢でした。
「AIが重要になる」という言葉だけでは、会社の仕事は変わりません。どの顧客に、どんな価値を届ける会社になりたいのか。そのとき、人とシステムはそれぞれ何を担うのか。そこまで考えて初めて、今整えるべき情報や、今試すべき業務が見えてきます。
講演では、AIを支えるインフラと電力、サイバー防御、人の経験や思考をAIで広げる可能性にも触れています。また、投資が生産性や収益にどれだけ結び付いたかを見る「Return on AI」を示し、短期だけでなく数年単位で捉える視点を提示しました。ソフトバンクニュースの講演レポート
ただし、長期で考えることは、途中の検証を省くことではないはずです。未来への期待が大きいほど、目の前で何が起きているかを丁寧に確かめる必要があります。
私が受け取ったのは、「未来を描く」「今の仕事を組み直す」「生まれた価値を確かめる」という三つの課題です。
ここから先は、講演の要約ではありません。北海道開発グループ（HDG）で何を変えたいかという、私自身の考えです。
2．HDGが持つ経験を、会社全体で使えるようにする
講演の終盤で、孫氏は、それぞれの企業が持つ業界知識、経験、データを生かし、自分たちの得意分野でAIを活用するよう呼びかけています。元動画・約57分以降
この話は、HDGにとって身近なものです。
私たちが扱うのは、商品の名前と価格だけではありません。どのような売場に向いているのか。誰が、どんな場面で買うのか。どの時期に提案すると話が進みやすいのか。供給側には、どのような準備や制約があるのか。
北海道の商品を国内外へ届ける仕事には、商品そのものの魅力と、それを商売として成立させるための細かな判断の両方が必要です。
しかし、経験は持っているだけでは会社の力になりません。
担当者が知っていても、他の人が必要なときに使えなければ、その知識は個人の中にとどまります。過去の注文が残っていても、なぜその注文が入ったかが分からなければ、次の提案を考える材料としては不十分です。
私がAIに期待したいのは、経験を短い説明文にまとめることだけではありません。次の担当者が必要な場面で、過去の経緯や確認事項にたどり着けるようにすることです。
そのためには、商品、顧客、注文、やり取りを結び付ける必要があります。同時に、事実と担当者の見立て、確定した条件と未確認の情報を分けなければなりません。
経験を生かすとは、過去の判断を無条件に繰り返すことではない。判断の背景を残し、今の状況に当てはまるかを確かめられるようにすることなのだと思います。
3．再発注予測は、注文を決める答えではない
HDGで具体化したい取り組みの一つが、「再発注予測から提案、そして予約受注へつなぐ営業」です。
言葉だけなら、AIが次の注文を予測し、そのまま受注を作る仕組みに聞こえるかもしれません。しかし、私が最初に目指すのは、そこまでを一度に自動化することではありません。
注文履歴から、次に確認したい顧客と商品を見つける。その候補を営業担当者が確認し、顧客との会話につなげる。必要性と供給条件が合い、顧客と合意できたものを注文へ進める。その間にある判断を、きちんと残したいと考えています。
目指す流れは、次のとおりです。
受注履歴の確認 → 再発注候補の抽出 → 営業担当者の確認 → 顧客への提案 → 条件の合意 → 予約受注
例えば、ここからは説明のための架空の例です。ある小売店が、同じ商品をおおむね毎月注文しているとします。前回の注文から時間が経っていれば、次の補充について確認する候補にはなります。
けれども、それだけで「もう在庫がなくなる」とは言えません。実際の販売量を把握していなければ、顧客の在庫は分かりません。前回だけ大きな催事があり、通常より多く仕入れた可能性もあります。
この場合、最初の問いは「次も同じ数量で注文してください」ではなく、「その後の販売状況と、次の売場の予定はいかがでしょうか」です。
顧客から情報が返ってきて初めて、補充するのか、時期をずらすのか、別の商品を組み合わせるのかを考えられます。
予測の価値は、未来を言い当てたように見せることではありません。確認すべき相手を見落とさず、必要な会話を少し早く始められることにあります。
注文を待つ営業から、需要を一緒に考える営業へ。その変化を、小さく始めたいのです。
4．データの量より、数字の意味をそろえる
今回、実際にSCMのデータを確認し、試算を進める中で、私は「計算できること」と「顧客に約束できること」の違いを強く意識しました。
画面に数量があっても、それが個数なのか、ケース数なのか、別の販売単位なのかによって意味は変わります。注文日、出荷日、売上計上日も、営業のタイミングを考えるうえでは同じ日付ではありません。
顧客名が似ていても、実際の売場や補充の判断者が同じとは限りません。同じ商品でも、荷姿が変わっていれば、以前の数量と単純に比較できない場合があります。
人はこうした違いを、経験で補いながら仕事をしています。しかし、仕組みに任せる範囲を広げるなら、暗黙の前提を明らかにしなければなりません。
私が整えたいのは、まず次の確認です。
- 同じ顧客、同じ納品先、同じ商品として比較してよいか。
- 数量と日付の意味がそろっているか。
- キャンセルや返品、特別な催事の注文を区別できるか。
- すでに受けている注文が、次の需要を満たしていないか。
- 顧客の販売状況や在庫について、分かっていることは何か。
- 供給条件は、いつ、誰が確認したものか。
分からない情報を、AIにもっともらしく埋めてもらうつもりはありません。分からないものは、分からないまま確認事項として扱う。その方が、営業担当者は何を聞けばよいかを判断できます。
定期的な注文が少ない商品や、注文間隔にばらつきが大きい商品は、無理に同じ予測方法へ入れない。候補を出せないことも、適切な処理として認めたいと思います。
最初から精密な予測を競うよりも、どの情報がそろえば判断できるかを、現場と共有する。その土台ができなければ、計算を高度にしても、顧客への提案は安心して任せられません。
5．MCPで「つながること」と、「任せられること」を分ける
今回の検討では、MCPを通じてSCMなどの情報を確認し、AIによる整理や判断支援につなげることにも関心を持ちました。
MCPは、AIアプリケーションと外部の情報や機能をつなぐための共通の仕組みです。公式資料でも、対象は情報交換のためのプロトコルであり、AIがその情報をどう扱うかまで一律に決めるものではないと説明されています。MCP公式資料
だから、MCPでデータが読めることと、そのデータから出した結論が正しいことは、分けて考える必要があります。操作する機能が存在することと、その操作を任せてよいことも別です。
私がHDGで採りたい設計は、「参照」「判断」「実行」を分けることです。これはMCPが自動的に用意してくれる仕組みではなく、私たち自身が設ける業務上の境界です。
参照の段階では、必要な受注履歴や商品情報を読み、どこから、いつ取得したかを残します。判断の段階では、候補を挙げた根拠と、足りない情報を整理します。実行の段階では、必要な確認や承認が完了したものだけを、許可された範囲で処理します。
この区別があれば、「AIがそう言った」という一言で、判断の責任が曖昧になることを防げます。
例えば、古いデータしか取れなかったなら、その日付を表示して確認を求める。顧客に送る価格の根拠が未確認なら、提案を止める。担当者や送信先を特定できないなら、推測で通知しない。
さらに、社内文書や外部から届いた文章に書かれている指示を、そのままシステム操作の許可として扱わないようにしたいと考えています。情報として読むことと、命令として従うことを区別するためです。
つながる範囲を増やすだけでなく、止まる条件を決める。これも、AIを仕事に組み込むための重要な設計です。
6．毎日確認しても、毎日全員に通知する必要はない
営業担当者へSlackで毎朝知らせれば、行動が増えるのではないか。私も最初は、その分かりやすさに期待しました。
しかし、同じ一覧が毎日届き、誰もが自分の担当分を探し、まだ変わっていない案件を何度も読むのであれば、便利さより負担が大きくなるかもしれません。
そこで分けたいのが、「システムが確認する頻度」と「人に通知する頻度」です。
毎日データを確認することには意味があります。一方で、人に知らせるのは、初めて対応が必要になったとき、重要な条件が変わったとき、確認期限が近づいたときなど、次の行動に影響する場合を中心にしたい。
今回の初期設計でも、最初の社内確認を送り、その後は重要な変化がある場合に追加で知らせる考え方を採っています。同じ依頼を毎日繰り返すことを目的にはしていません。
営業数字を持つメンバー全員を対象に考えることと、全員に同じ情報を送ることも違います。既存顧客の担当、新規開拓の担当、店舗の運営では、確認すべきことが異なります。本人に必要な案件だけを、その役割に合う形で届けたいと考えています。
通知に必要なのは、長い分析よりも、「何の案件か」「なぜ今確認するのか」「何が未確認か」「次に何をしてほしいか」「根拠はどこにあるか」です。
通知後の状態も重要です。未確認なのか、顧客へ確認中なのか、時期を変更したのか、今回は見送るのか。担当者が判断した理由が残れば、同じ案件を最初から調べ直す必要が減ります。
返信がない場合も、単純に意欲の問題と決めつけるべきではありません。担当が違う、依頼が曖昧、確認先から返事がないなど、運用側に原因がある可能性があります。
私が減らしたいのは、社員が考える時間ではなく、何から確かめればよいのかと迷う時間です。
7．予約受注は、先に数字を作るための仕組みではない
再発注の可能性が見つかったからといって、それが注文になったわけではありません。顧客が関心を示したことと、条件に合意したことも同じではありません。
この違いは、予約受注を考えるときに特に大切です。
社内で期待している数量を、顧客が約束した数量のように扱わない。検討中の案件と、条件を確認した注文を混ぜない。仕入先に供給を確かめる前に、確定した納期を伝えない。
私が考える運用では、対象商品、数量と単位、価格条件、希望納期や納品先、変更が生じた場合の扱いなどを、顧客と確認してから次の段階へ進めます。同時に、こちらがその約束を履行できるかを、必要な担当者が確かめます。
顧客からの回答が保留なら、案件は保留です。条件の一部しか確認できていないなら、未確認の箇所を残します。AIが欠けた条件を推測し、完成した注文のように見せることは避けなければなりません。
このように進められれば、将来的には、顧客の販売計画と供給側の準備を早めにつなげられる可能性があります。ただし、欠品が減る、在庫が減る、利益が増えるといった効果は、これから検証するものであり、現時点の成果ではありません。
無理な先行受注を増やせば、かえって調整や在庫の負担を増やすことも考えられます。注文の数だけでなく、その約束が顧客と供給側の双方にとって無理のないものかを見なければなりません。
目指したいのは、早く数字を確保することではなく、需要を早く理解し、約束の質を上げることです。
8．社長の経験を、社員が使える判断条件にする
この取り組みを考えるほど、最後に問われるのは、私自身の仕事の仕方だと感じます。
AIが毎日たくさんの報告を作り、私がそれを読んで全員へ指示する。その形でも、一時的には処理できる量が増えるかもしれません。しかし、私がすべての案件を選び、判断し、承認する構造が変わらなければ、会社は私の時間に制約され続けます。
社長の能力を広げることと、組織の能力を広げることは、必ずしも同じではありません。
私が整理すべきなのは、個別案件への答えだけでなく、答えを出すときに見ている条件です。
なぜその顧客を優先するのか。数量が大きくても進めないのは、どんな場合か。利益だけでなく、供給の安定性や継続性をどう考えるのか。何が分かれば担当者が決めてよく、どこから別の確認が必要になるのか。
こうした条件が共有されれば、社員は社長の回答を待つだけでなく、自分で事実を集め、判断の理由を説明できます。AIにも、候補を出す範囲と、止めて確認を求める範囲を伝えられます。
ただし、判断条件を文章にすることは、すべての仕事を硬直した規則にすることではありません。現場には、規則だけでは扱い切れない事情があります。
だからこそ、例外を認める人、例外を認めた理由、後で見直す時点を残したい。結果が想定と違ったときも、担当者のせいにする前に、条件や前提のどこが不足していたかを確認したいと思います。
私の経験を、私を再現する仕組みに閉じ込めるのではなく、私がいない場面でも考えを進められる材料にする。それが、経営者として取り組むべき変化なのだと思います。
9．社員に求めるのは、AIの答えを転送することではない
AI活用を進めるとき、「社員は何をすればよいのか」という問いを避けては通れません。
私が期待したいのは、AIが作った文章をそのまま顧客へ送ることではありません。顧客の状況を確かめ、提案に足りない条件を見つけ、自分たちが引き受ける約束を理解したうえで対話することです。
顧客が本当に困っているのは、商品の不足なのか、売場の見せ方なのか、販売時期なのか。追加注文を勧めるよりも、次の販売機会を一緒に考えた方がよいのか。こうした問いに向き合う時間を増やしたいと考えています。
そのためには、会社側も準備が必要です。「AIを使って」と伝えるだけでは足りません。どの情報を使ってよいか、何を確認するか、迷ったら誰に相談するか、誤りを見つけたときどう直すかを示す必要があります。
担当者が候補を見送り、その理由を残した場合も、私はそれを単純な未達成とは見たくありません。すでに需要が満たされていた、提案する時期ではなかった、供給条件が合わなかったという確認は、不要な営業や約束を避けるための成果でもあります。
また、通知への返信速度だけで、社員の能力や貢献を決めるべきではありません。今回の試行は、社内の業務確認を支援するものであり、社員の雇用や処遇を判断するためのものではありません。
AIを導入する目的を、社員を細かく監視することに置き換えない。必要な情報を届け、適切な範囲で判断できるようにし、顧客に向き合う仕事を支える。その目的を、運用が始まった後も見失わないようにしたいと思います。
10．AIの利用回数ではなく、仕事の変化を測る
講演にあった「Return on AI」という視点を、HDGではどう具体化すればよいのか。
私は、最初から一つの大きな数字にまとめるより、仕事が進む段階ごとに見る方がよいと考えています。
まず、抽出した候補は、担当者が確認する価値のあるものだったか。次に、確認から顧客との会話や提案につながったか。その先で、条件の合意や受注につながったか。さらに、履行に無理がなく、粗利益や時間の使い方にどのような違いが出たかを確かめたい。
通知が届いたことと、仕事が進んだことを分ける。提案が増えたことと、顧客にとって有効だったことも分ける。注文が増えても、対応費用や調整の負担が大きく増えたなら、その理由を見る必要があります。
費用には、AIの利用料だけでなく、仕組みの整備、情報の確認、誤りの修正、継続運用にかかる人の時間も含めて考えたいと思います。現場に新しい作業を増やしながら、見かけの処理速度だけを成果にしてはいけません。
効果の比較も、慎重に進める必要があります。もともと注文が入りやすい顧客を優先したなら、受注率が高くても、その差をすべてAIの効果とは言えません。季節や催事、担当者の活動の違いもあります。
将来の評価方法としては、条件の近い案件や従来の進め方と比較し、数値と担当者の感想を合わせて見たいと考えています。これは今後の設計案であり、比較実験をすでに実施したという意味ではありません。
期待どおりでなければ、対象を狭める、情報を整える、通知内容を変える、場合によっては止める。その判断も、最初から選択肢に入れておきたいと思います。
継続する理由は、AIを導入したからではなく、顧客と会社の仕事に価値が残るからであるべきです。
11．小さな試行で、広げてよい条件を見つける
2026年9月5日時点で、この取り組みは、設計と試算を行い、翌週からの社内確認を試行する準備まで進めた段階です。
まだ配信の成功も、顧客への提案効果も、予約受注の増加も確認していません。営業の自動化が完成したという報告ではなく、これから何を確かめるかを整理している段階です。
最初の試行は、社内の確認に限定します。顧客に自動で提案を送ったり、AIが注文を登録したりするところからは始めません。
まずは、必要な担当者に、必要な確認が届くか。担当者が内容を理解できるか。未確認の情報を補えるか。通知や確認によって、かえって余計な手間が増えていないかを見ます。
その先に、データの意味をそろえ、候補の出し方を見直し、担当者が提案の下書きを使える段階があります。さらに進むには、顧客との合意をどのように記録し、誰が何を確認すれば受注へ移せるかを定める必要があります。
ただし、これは今後の進め方の案です。順番に並べたからといって、各段階の実装が完了しているわけではありません。
対象者を広げる場合も、担当範囲や通知先を確かめ、必要な情報だけが届くようにすることが前提です。対象に含める方針と、本人への配信準備が完了したことは区別し、不明な場合は止めて確認します。
小さく始めるのは、将来を小さく考えているからではありません。実際の仕事から学び、広げてよい部分と、まだ人が支えるべき部分を見極めるためです。
試行の中で、当初の考えを変える必要も出てくるでしょう。その変更を、失敗を隠す作業ではなく、設計を良くするための学びとして残したいと思います。
12．未来への意思を、月曜日の仕事に落とす
AIの未来を聞くと、技術の進歩の速さに圧倒されます。もっと学ばなければ、もっと使わなければという気持ちにもなります。
けれども、経営者として私が答えるべきなのは、どれだけ多くのAIを試したかという問いだけではありません。
HDGは、顧客にどのような価値を届ける会社でありたいのか。社員が何に時間を使えるようにしたいのか。会社が成長しても、何を一人の経験や記憶に頼り続けないようにするのか。
私の答えは、まだ完成していません。ただ、進みたい方向はあります。
北海道の商品を世界へ届ける仕事を、注文を受けて処理するだけでなく、顧客の需要を理解し、一緒に次の販売を考える仕事へ育てたい。
社員が情報を探し回る時間や、社長の判断を待つ時間を減らし、自分の責任と権限の中で、顧客に向き合えるようにしたい。
そして、私自身の経験を、自分だけが使える能力で終わらせず、会社の中で確かめ、共有し、更新できるものにしたい。
そのための最初の一歩は、大きな宣言でなくてもよいと思います。一つの案件について、事実をそろえ、次に確認することを決め、適切な担当者へ届ける。その結果を見て、次の仕組みを直す。
予測は、確認につながってこそ意味がある。確認は、顧客との対話につながってこそ価値がある。そして、対話から生まれた約束は、きちんと果たして初めて信頼になる。
AIの未来を語ることと、月曜日の営業を変えることを、別々にしない。
孫正義氏の講演をきっかけに、私が自分へ問い直したいのは、その一点です。