営業パイプライン（見込み顧客へのアプローチから成約に至るまでの進捗プロセス）の管理において、Walkersではメール・議事録・予定表から商談の進み具合を読み取り、案件を管理する表の更新や候補作成をAIと連携プログラムで進める運用を設計してきました（※本稿の運用内容は2026年9月13日時点の社内台帳記録に基づくものであり、2026年10月9日時点の稼働状況を保証するものではありません）。システムが自動でステータス（進捗段階）を進めてよい条件は客観的な証跡がある場合に限定し、契約の締結や失注の判定、金額や作業範囲に関わる決裁などの重要判断は人が行っていました。
案件の更新候補、どこまでAIに任せているか
以前は、担当者がメールの受信箱と議事録、予定表を一つずつ見比べて、案件がどこまで進んだかを頭の中で整理し、案件を管理する表に手で反映していました。件数が増えるほど、この見比べ作業そのものが時間を取り、更新が数日遅れることも珍しくありませんでした。忙しい時期にこの確認が後回しになると、実際には話が進んでいる案件が表の上では止まって見えるという、地味だが厄介なずれも起きていました。
Walkersでは、情報源からの読み取りと更新候補の整理をAIに任せています。具体的には、メールの本文・議事録の内容・予定表の会議予定を横断的に確認し、クライアント名や提案・見積もりに関わるやり取りを拾い上げたうえで、案件管理表の更新案を作成します。あらかじめ定めた確定条件を満たす遷移はプログラムが自動で反映し、それ以外の判断や提案は担当者が確認して反映可否を決める役割分担にしています。営業のAI活用全般については別記事でも扱っていますが、本記事ではWalkers自身の実践に絞って記録します。
仕組みの全体像
読み取りと更新処理は、性格の異なる複数のバッチ処理が役割分担して動いていました。AIによる解析・候補作成、ルールに基づく書き込み、人による決裁を明確に切り分けています。なお、社内提示資料によって18時の処理が原本管理表への直接更新を含むか候補集約にとどまるか、あるいは1回あたりの更新件数上限（最大5件）がどこまで適用されるかといった細部の記述が異なっており、運用変更があったと断定せず未確認事項として扱っています（2026年9月13日時点の記録であり、2026年10月9日時点の実稼働は未確認です）。毎朝の点検全体の仕組みは毎朝の定期点検の記事でも紹介していますが、台帳で確認された工程分担の枠組みは次のとおりです。
| 工程 | 主に確認する情報源・判定手段 | 担当主体 | 頻度（JST） |
|---|---|---|---|
| 日程確定案件のステータス自動前進 | 先方の返信＋会議URL送信済みかを照合 | 自動判定プログラム | 毎朝9:00枠内（先行） |
| 案件管理表のステータス更新・候補抽出 | メールの文言・客観的証跡の照合（明確な根拠がある場合） | AI＋連携プログラム | 毎朝9:00枠内（後続） |
| 商談化以降の一段階前進の判定 | メールやり取りを根拠にした軽量AIモデルの確信度判定 | 軽量AIモデル | 都度実行 |
| 案件管理表の状況確認・更新処理 | メール・議事録・予定表・社内資料を横断確認（※原本直接更新か候補集約かは確認資料により異なる） | AI＋連携プログラム | 毎日18:00 |
| 営業通知スレッド（関連する投稿の連なり）への返信・同期 | 定型フォーマットで文面を組み立ててチャットへ投稿 | 連携プログラム | 15分ごと |
| 契約・失注・金額や作業範囲の意思決定 | 提示された根拠に基づくビジネス判断 | 人 | 都度 |
毎朝9時の枠内では、まず日程確定の機械判定が先に走り、その後に残りの案件を対象とした確証ベースの更新や候補作成が続きます。通知同期や最終決裁は、機械的な処理結果を人に届け、重要事項の意思決定を確実に委ねるためのステップです。
「自動で進めてよい遷移」と「人の確認が要る遷移」の線引き
遷移（ステータスの変更）のうち、人手を介さず自動で進める個別処理として設計した代表的なパターンは次の2種類です。ひとつは、日程調整の段階（社内表記「日調中」）から、初回打ち合わせ前の段階（「初回mtg前」）への前進です。先方からの返信があり、かつ自社から会議URLを送信済みという2つの条件がそろった案件を自動前進の対象としていました。提示記録で確認された設計では、返信の有無に加えて会議URLの送信完了を判定条件に使用しており、返信があってもURL未送付の再調整中案件は自動では動かさないルールにしていました（※自社で使用した判定条件の記録であり、その後の日程変更や取消を含めた確定を保証するものではありません）。
もうひとつは、初回打ち合わせ終了後から先方検討段階への一段階前進です。こちらはメールのやり取りを根拠に軽量AIモデルが判定し、モデル側の出力する確信度が高い案件に絞って処理対象としています（※モデルの確信度スコアであり、実測正答率100%を意味するものではありません）。複数段階を一気に飛び越える処理や、ステータスを戻す処理、失注や不採用への変更は、この自動前進処理には含めていません。
これら2種類の個別自動前進処理以外にも、メールのメッセージIDや具体的な記述など客観的な証跡が明示できるステータス変更については、手順に沿ってAPI経由で直接更新されます（※運用記録台帳には1回の実行につき最大5件更新という上限の記載がありますが、現行の全手順で一律に上限が適用されているかは資料上確認されていません）。一方で、契約の締結・失注や不採用の判定・金額や作業範囲に関わる決裁といった「ビジネス上の意思決定そのもの」は、最初から自動化の対象から外しており、人が決定します。決定済みの客観的証跡を管理表へ記録・同期する処理と、意思決定そのものを明確に切り分けています。
- 商談の進捗に関する客観的証跡（メール・議事録・予定表）を確認 判定対象の分類 読み取った情報から、変更対象となるステータスや判断内容の種類を判別します。
- 返信あり ＋ 会議URL送信済み（日程確定） プログラムによる自動前進 「日調中」から「初回mtg前」へ1段階のみ自動更新します。
- 初回打合せ完了 ＋ 軽量AIの高確信度判定 モデル判定による自動前進 「初回mtg後」から「先方検討中」へ1段階のみ自動更新します。
- 客観的証跡あり（メッセージID・記述照合） 証跡に基づく直接更新／候補提示 明確な証跡があれば更新を実行し、判定が分かれる案件は候補として提示します。
- 契約締結・失注判断・金額・作業範囲の決裁 人が直接意思決定（自動化対象外） ビジネス判断そのものは人が行い、決定済みの事実記録のみをシステムが扱います。
- 客観的な根拠が不足している場合 更新なし（現状維持） 推測ではステータスを進めず、現状の進捗段階を維持します。
2026年9月13日時点の運用記録に基づく分岐です。個別自動前進の2種類に加え、客観的証跡に基づく更新も行われていました（10月9日時点の実稼働や適用範囲は未確認）。契約や失注などの重要意思決定そのものは自動化から除外されています。
正常に見えていた失敗6件と、どう直したか
自動化は仕組みを作った瞬間がゴールではありません。Walkersでもこれまでに何度も失敗を経験し、その都度直してきました。営業パイプラインの運用に関わるものを、起きた順に記録します。
- 2026-07-07〜09（通知不足による放置）: AIを動かすための認証情報が切れ、自動更新が起動直後に停止しました。「止まったことを知らせる」通知も同じ認証に依存していたため、誰にも気づかれないまま数日間、停止状態が放置されました。対策として、認証を再設定したうえで、AIの認証に依存しない別経路のチャット通知を追加しました。
- 2026-07-14（取得範囲の不足）: メール検索の仕組みが、やり取りの先頭側5通しか返さない仕様だと気づかずに判定していました。直近の返信状況を見落とすリスクがあったため、状況確認時は必ずスレッド全体のメッセージを取得して判定するルールに変更しました。
- 2026-08-04（成果物の未更新）: 案件表の定期処理が、対話モードのように「実行してよいですか」と質問だけを返して終了し、ファイルが一切更新されないまま処理が終了する事象が発生しました。対策としてプロンプトを厳格化し、対象ファイルの更新時刻が処理開始時刻より古ければ失敗と検知する仕組みを追加しました（※ただし更新時刻の確認だけでは、内容の正確さや「更新不要だった正常実行」までは判定できないため、定期的な確認を併用しています）。
- 2026-08-04（リトライの無限ループ）: 通知返信処理が文章読み取りエラーのたびに同一データを再処理し、15分おきにAI呼び出しを繰り返しました。対策として、3回連続で失敗した場合は処理を停止し、データを退避して人へエスカレーションする仕組みを導入しました。
- 2026-08-16（文脈の誤認）: 未返信通知で「漏れ」と報告した3件がすべて誤検知でした（自社の外部協力者を顧客と誤認、儀礼的な結び文への過剰反応、別スレッド回答済みの見落とし）。対策として協力者除外リストを導入しました（※儀礼文のニュアンスや別スレッド回答の完全な自動識別には限界があるため、最終確認は人が行います）。
- 2026-08-19〜21（マスタ不整合による欠落）: 案件管理表のステータス定義が変更された際、旧定義で完全一致検索を行ったため、レポートから営業データが欠落し進行件数が過小集計されました。対策として、実行時に実在する選択肢と照合して未知の名称を警告する検知機構を追加しました（※検知機構の追加であり、過去データの自動再集計が保証されるわけではありません）。
これらの失敗は、「通知不足による放置」「成果物が更新されない空振り」「誤った判定結果の出力」というパターンに分かれます。プログラムがエラーコードを吐かずに終了してしまう検知しにくい失敗への備えが不可欠です。
人に残った判断
定常的な進捗更新をシステムで補助する一方で、重要な判断や例外対応は意図的に人の手元に残しています。客観的な事実確認は機械的に進め、ビジネス上の責任が伴う意思決定は人が引き受ける構造です。
- 客観的証跡が揃わない曖昧な進捗変化や、確証が不十分な更新候補は、内容を確認したうえで人が反映可否を判断します。
- 契約の締結、失注や不採用の確定、金額やスコープ（作業範囲）の決裁といった「意思決定そのもの」は、最初から自動化の対象に含めず人が判断します（システムは決定済みの事実記録のみを扱います）。
- 顧客へのメール送信は下書き生成までを自動化し、内容の確認と最終送信は担当者が行います。
- 議事録を自動で集めるための会議ツールの権限や設定変更は、人が管理します。
- 処理が3回連続で失敗して退避されたデータのエラー原因調査とリカバリーは、人が対応します。
- 案件管理表のステータス定義や選択肢自体の設計変更・統廃合は人が実施します。
設計の原則
何度かの失敗を経て、Walkersでは次のような原則を積み重ねてきました。
- 確証がなければ更新しない: 文脈の推測だけでステータスを変えず、メールや議事録に客観的な証跡がある情報のみを反映対象にします。
- 個別自動前進は明確なシグナルと1段階限定: 日程確定の自動前進処理では、返信の有無だけでなく会議URL送信済みという社内運用上の明確な条件を組み合わせます。前進も許可された1段階（1ホップ）に絞り、複数段階のジャンプや失注への自動変更は行いません。
- スレッド全通の確認: メールの送受信判定では、最新の数通だけでなくスレッド全体のメッセージを網羅的に確認したうえで最終状況を判定します（※本文全体の取得量を絞る最適化とは別に、メッセージの往復履歴の確認漏れを防ぎます）。
- 書き込み手順の統一: チャット通知やステータス更新は、認証とログが管理された所定の連携手順を経由させ、AIモデルが非管理な形で直接書き込むことを防ぎます。
「確証がないものは自動で進めない」という一線が、AIに任せる範囲の境界線になっています。
中小企業が案件の進捗管理をAIに任せる前に決めること
同じ仕組みをゼロから作る必要はありません。まず着手するなら、次の順番が現実的です。
- 対象を1つの業務、たとえば案件の進捗管理だけに絞ります。
- 「どんな条件がそろったら自動で進めてよいか」を、Walkersの「返信＋会議URL送信」のように具体的な言葉で決めます。条件を曖昧にしたまま自動化すると、Walkersが経験したような誤検知や取りこぼしが起きやすくなります。条件を決める際は、「ほぼ確実に正しいと言える組み合わせ」だけを対象にし、迷う条件は最初から自動化の対象に含めないのが安全です。
- 契約・失注・金額に関わる判断は、最初から自動化の対象に含めないと決めておきます。
- 通知の仕組みが止まっていること自体に気づけるよう、通知経路を1つに頼りきらない設計にします。
既存のCRMやSFAを使い続けるべきか、自社の運用に合わせて作り替えるべきかで迷う場合は、Salesforce・HubSpotのどこを内製するかも参考にしてください。
よくある質問
営業パイプラインをAIが毎日更新するとは、具体的にどういうことですか？
メール・議事録・予定表を読み取り、案件を管理する表の更新や候補作成をAIと連携プログラムで行う仕組みです（2026年9月13日時点の社内記録に基づく運用）。確定条件を満たす個別自動前進や、メッセージID等の客観的証跡が確認できる案件の更新を行い、契約や失注などの重要意思決定は人が行っていました。
ステータスを間違って進めてしまうことはないのですか？
誤更新が完全にゼロになるわけではありません。過去にもマスタの選択肢変更による欠落や、協力者の誤認といった失敗を経験しています。そのため、個別自動前進の条件を「返信＋会議URL送付」など客観的証跡が揃う1段階のみに限定し、根拠付き更新においても客観的証跡を必須とし、失注や契約などの重要意思決定は除外しています。また、誤りが発生した際も検知できるよう警告やログ確認を組み合わせています。
自動化していて失敗したことはありますか？
あります。認証切れで通知ごと止まった、メール検索の仕様に気づかず取りこぼした、更新されないまま「成功」扱いになったなど、無音の失敗を繰り返し経験し、その都度対策してきました。
中小企業が同じ仕組みを作るには何から始めればよいですか？
対象を絞り、AIが自動で進めてよい条件と人が判断する条件を先に言葉にしたうえで、更新の根拠を必ず記録に残す設計にすることをおすすめします。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。1社ごとに専用の環境を用意し、AI活用を伴走するFDE型の仕組みについては、FDE-NOAHをご覧ください。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。
