営業日報を書かずに作る｜カレンダーと案件記録から自動で下書きし、営業が足すのは1行だけにする

営業日報は、多くの会社で「書く側も読む側も、あまり価値を感じていないのに続いている」仕事の代表です。営業担当者は1日15分から30分を使って書き、上司は数十人ぶんを流し読みする。それでいて、翌週の行動が変わることはほとんどありません。

この状態を、様式を作り直したりテンプレートを配ったりして改善しようとすると、たいてい失敗します。問題は書き方ではなく、すでにどこかに記録されている情報を、もう一度手で書かせていることだからです。この記事では、日報を書く時間をほぼゼロにして、上司が本当に見たい情報だけを残す仕組みを、設計図から順に説明します。

ムダの現状：書く時間と、読まれない時間

営業日報にかかっている時間を、両側から数えてみてください。

書く側は、1人1日15分から30分。営業が10人いれば、1日で2時間半から5時間、月20営業日で50時間から100時間が消えています。読む側は、上司が1人あたり1分ずつ目を通しても10分、これが毎日です。

そして、書かれている内容の大半は、すでにどこかにあります。訪問先はカレンダーに入っている。商談の結果は顧客管理のシステムか、受注の記録にある。移動のルートは経路検索の履歴にある。日報は、別の場所にある情報を人が転記して作っている文書です。

日報が本当に果たしている役割は、2つだけ

ただし、日報が完全に無意味かというと、そうではありません。よく聞くと、上司が日報で見ているのは次の2つに集約されます。

1つは、止まっている案件の発見です。先週も今週も動いていない案件、あるいは提案から2週間たっても返事がない案件。これを早く見つけたい。もう1つは、営業が困っている場所の把握です。同じ質問を何度も受けている、競合の名前が頻繁に出る、値下げの話が増えている。こうした兆候を拾いたい。

この2つは、自動で集めた情報だけでは分かりません。だから日報をゼロにはしない。ただし、書かせるのは1行だけにするというのが、この記事の設計です。

機械に渡せる部分と、人に残す部分

表の最後の行が、この仕組みで唯一、営業に書かせる部分です。ここだけは自動化できません。そして、ここが上司にとって最も価値のある情報でもあります。

スキームの全体図：集めて、下書きして、1行だけ足す

この仕組みで最も見落とされるのが、下の注意書きの1つ目です。自動化の仕組みを足しても、従来の日報の様式をそのまま残してしまうと、営業の負担は1ミリも減りません。様式から項目を削るところまでを、同じ作業として扱ってください。

必要なツールと費用（2026年9月22日時点）

生成AIは、この仕組みの必須要素ではありません。集めた情報を箇条書きで並べるだけでも、日報としては十分に機能します。AIを足すのは、箇条書きが定着してからにしてください。最初からAIを組み込むと、動かなかったときに原因が切り分けられません。

導入手順：上司が見たい3項目を決めるところから

Step 1：上司に「何を見ているか」を聞く

最初にやるのは、様式の設計でも実装でもありません。日報を読んでいる上司に、実際に何を見ているかを聞くことです。

聞き方にコツがあります。「何が必要ですか」と聞くと、念のため全部、という答えが返ってきます。そうではなく、過去1か月の日報を一緒に開いて、どこを読んだかを指してもらう。この聞き方をすると、実際に見ている場所は3つ程度に収まります。

多くの場合、次のような答えになります。

逆に、日報の様式には載っているのに誰も読んでいない項目も見つかります。移動時間、天気、所感、明日の予定。これらをこの段階で削る合意を取ってください。後から削ろうとすると、必ず「念のため残しましょう」になります。

Step 2：元データの場所を確定する

3項目が決まったら、それぞれがどこから取れるかを確定します。ここで多くの場合、元データが揃っていないことが判明します。案件の最終更新日が分からない、カレンダーに予定を入れていない人がいる、といった状態です。

この場合、日報の自動化より先に、元データを揃える話になります。ただし全部を揃える必要はありません。3項目に必要な範囲だけです。案件の状態を追いたいなら、必要なのは次の4列だけです。

金額や確度の列を最初から持たせないでください。入力の負担が跳ね上がり、結局は空欄のまま放置されます。段階が動いたときだけ1クリックで更新できる状態を先に作り、金額は受注が見えてから足します。

Step 3：下書きを自動で作る

次のApps Scriptは、その日のカレンダーの予定と、案件シートの更新状況から、担当者ごとの日報の下書きを作ります。

var STALE_DAYS = 14;
function buildDrafts() {
  var ss = SpreadsheetApp.getActiveSpreadsheet();
  var members = ss.getSheetByName('担当者').getDataRange().getValues().slice(1);
  var deals = ss.getSheetByName('案件').getDataRange().getValues().slice(1);
  var today = new Date();
  var out = [];
  for (var i = 0; i < members.length; i++) {
    var name = members[i][0];
    var mail = members[i][1];
    if (!mail) continue;
    var visits = visitsOf(mail, today);
    var stale = staleDeals(deals, name, today);
    out.push([stamp(today), name, visits.join(' / '), stale.join(' / '), '']);
  }
  writeDrafts(ss, out);
}
function visitsOf(mail, day) {
  var cal = CalendarApp.getCalendarById(mail);
  if (!cal) return [];
  var s = new Date(day.getFullYear(), day.getMonth(), day.getDate());
  var e = new Date(s.getTime() + 86400000);
  var events = cal.getEvents(s, e);
  var list = [];
  for (var i = 0; i < events.length; i++) {
    var t = events[i].getTitle();
    if (t.indexOf('社内') === 0) continue;
    list.push(Utilities.formatDate(events[i].getStartTime(), 'JST', 'HH:mm') + ' ' + t);
  }
  return list;
}
function staleDeals(deals, name, today) {
  var list = [];
  for (var i = 0; i < deals.length; i++) {
    if (deals[i][1] !== name) continue;
    if (deals[i][2] === '受注' || deals[i][2] === '失注') continue;
    var last = deals[i][3];
    if (!last) continue;
    var days = Math.floor((today - new Date(last)) / 86400000);
    if (days >= STALE_DAYS) list.push(deals[i][0] + '(' + days + '日)');
  }
  return list;
}
function stamp(d) {
  return Utilities.formatDate(d, 'JST', 'yyyy/MM/dd');
}
function writeDrafts(ss, out) {
  if (out.length === 0) return;
  var sh = ss.getSheetByName('日報');
  sh.getRange(sh.getLastRow() + 1, 1, out.length, 5).setValues(out);
}

出力される列は、日付、担当者、その日の訪問、止まっている案件、そして空欄の5つです。5列目が、営業が1行だけ書く欄になります。

トリガーは平日の17時に設定します。営業が帰社する前後に下書きが届いている状態にすると、その場で1行足して終われます。翌朝に回すと、前日のことを思い出す時間が発生するので、必ずその日のうちに届けてください。

コードで決めている3つの除外

上のコードには、意図的な除外が3つ入っています。実際に運用してから必ず問題になる箇所なので、それぞれの理由を書いておきます。

1つ目は、件名が「社内」で始まる予定を集計から外していることです。定例会議や研修まで訪問として数えると、件数が実態から離れます。接頭辞で判定しているのは、既存の予定の入れ方を変えずに済ませるためです。自社で別の言葉を使っているなら、そこを書き換えてください。

2つ目は、段階が「受注」または「失注」の案件を、止まっている判定から外していることです。この2つは動かないのが正常な状態で、除外しないと一覧が終わった案件で埋まります。

3つ目は、最終更新日が空の案件を飛ばしていることです。運用の初期には空欄が多く残るため、ここで止まらない作りにしています。ただし空欄のまま放置すると永久に検出されないので、最終更新日が空の件数も、別途カウントして上司に見せるようにしてください。これを見ないと、運用の穴に気づけません。

上司側の見方も、同じ日に決める

下書きが自動で届くようになると、日報は蓄積されていきます。ここで上司が従来どおり全員ぶんを開いて読むなら、上司側の時間は減りません。

上司が見るのは2か所だけにします。止まっている案件が出ている行と、1行の欄に何か書かれている行です。この2つの条件に当てはまる行だけを抽出した表を用意すれば、10人ぶんでも数分で終わります。

抽出は、日報シートの別タブに絞り込みの式を置くだけで足ります。上司が毎朝そのタブを開く、という運用まで決めてから始めてください。仕組みを作っただけで運用を決めないと、上司は結局すべてを開きます。

Step 4：1行の書き方を、例で示す

「困っていることを1行で」と言っても、最初は何を書けばよいか分かりません。3つの例を配ってください。

たとえば「A社の決裁が部長で止まっている。役員の同席が要るかもしれない」「同じ製品の在庫の質問を今週3件受けた」「B社で競合の名前が初めて出た」。この粒度です。評価されるための文章ではなく、上司への申し送りだと伝わる例にしてください。

書くことがない日は「特になし」で構わないと、最初に明言します。ここを曖昧にすると、書くことを探す時間が発生し、元の日報と変わらなくなります。

逆に、書いてほしくないものも例で示してください。「本日も1日ありがとうございました」のような挨拶、「明日も頑張ります」のような決意、そして訪問先の一覧の再掲です。特に3つ目は、自動で入っている情報をもう一度書く行為なので、この仕組みの目的と正面から矛盾します。

最初の2週間は、上司が1行の書き方にだけ短く反応してください。内容への評価ではなく、「それは私に言ってくれて助かる」という種類の反応です。ここで反応が無いと、3週目から「特になし」が増え、1か月で形骸化します。

Step 5：従来の様式を、同じ日に廃止する

新しい仕組みを始める日に、従来の日報の様式を止めます。並行期間を作らないでください。両方を書かせる期間があると、営業から見れば負担が増えただけで、新しい仕組みへの評価が定まる前に嫌われます。

止める日を決めたら、上司の側にも約束してもらうことがあります。削った項目について、後から個別に聞かないことです。移動時間を様式から削ったのに、上司が「今日はどこを回った」と個別に聞き始めると、営業は結局それに備えてメモを取ります。削ったなら、聞かない。ここまでを合意にしてください。

現場の合意の取り方：監視ではないと示す順番

この仕組みは、カレンダーや案件の更新を機械が見に行きます。そのため、伝え方を間違えると「行動を監視される」という受け取られ方をします。

取得する範囲を、コードより先に見せる

いちばん効くのは、何を取得して何を取得しないかを、実装の前に文書で配ることです。

カレンダーから取るのは、開始時刻と件名だけ。件名が「社内」で始まる予定は集計しない。参加者や場所、本文は取得しない。案件シートから取るのは、案件名、担当、段階、最終更新日だけ。この程度の粒度で書けば、A4で1枚に収まります。

そして、取得しないと書いたものは、実際に取得しないでください。後から「あると便利だから」と範囲を広げると、一度の信頼喪失で仕組み全体が止まります。広げたくなったら、改めて説明してから広げます。

説明は、上司から先に

順番は、上司、営業の順です。上司が内容を知らないまま営業への説明を聞くと、質問に答えられません。そして上司には、削った項目を後から個別に聞かない約束を、この場で取ってください。

営業への説明では、書く時間がどれだけ減るかを具体的な分数で示します。「1日20分が2分になる」と言えるなら、そう言う。曖昧に「効率化します」と言うと、また何か増やされると受け取られます。

失敗パターンと限界：顧客情報をAIに渡す線引き

日報には、顧客の個人情報が入る

日報の内容をAIに要約させたり、傾向を分析させたりする場合、渡す情報に顧客の氏名、担当者名、連絡先、商談の内容が含まれます。ここは個人情報保護法の枠組みで整理してから設計してください。

法第17条は、個人情報を取り扱うにあたって利用目的をできる限り特定しなければならないと定めています。第18条は、あらかじめ本人の同意を得ないで、特定された利用目的の達成に必要な範囲を超えて個人情報を取り扱ってはならないとしています。自社が顧客に対して公表している利用目的の文言を、まず確認してください。

外部のサービスで処理する場合は、委託の扱いも関わります。法第27条は、原則としてあらかじめ本人の同意を得ないで個人データを第三者に提供してはならないと定めたうえで、利用目的の達成に必要な範囲内において個人データの取扱いの全部または一部を委託することに伴って当該個人データが提供される場合は、提供を受ける者を第三者に該当しないものとする旨を定めています。

ただし委託なら自由というわけではありません。法第25条は、個人データの取扱いを委託する場合には、委託された個人データの安全管理が図られるよう、委託を受けた者に対する必要かつ適切な監督を行わなければならないと定めています。契約するサービスの規約は、営業資料の要約ではなく原文を、確認日を控えて読んでください。

設計で減らせる範囲は、先に減らす

法令の確認とは別に、渡す情報そのものを減らせます。傾向の分析に必要なのは「どの段階で止まりやすいか」であって、顧客の氏名ではありません。

AIに渡す前に、顧客名を記号に置き換える処理を入れてください。1行の申し送りについても、固有名詞を含むものはAIに渡さず、人が読む運用に留めるという切り分けが現実的です。集計はAI、個別の中身は人という線を引くと、扱いがはっきりします。

この仕組みが向かない場合

日報が評価制度に組み込まれている場合、この仕組みだけでは変えられません。日報の量や内容が人事評価の材料になっているなら、先に評価制度の側を見直す話になります。仕組みだけ変えると、営業は評価のために別の場所で同じ文章を書き始めます。

また、カレンダーに予定を入れる習慣がない組織では、元データが集まりません。この場合は日報の自動化より先に、カレンダーを使う運用を定着させるほうが順序として正しくなります。ただし、それを「日報のため」と説明すると反発が出ます。予定の共有そのものの利点で説明してください。

効果の測り方

2つ目の「1行が書かれた率」は、この仕組みが生きているかを示す数字です。ただし、100%を目指さないでください。特になしを許容すると決めた以上、7割前後で安定していれば健全です。逆に100%に近い場合は、書くことを探す圧力がかかっている可能性があります。

3つ目が、上司側の効果です。従来の日報では、止まった案件に気づくのが2週間後、3週間後になっていたはずです。ここが短くなっていなければ、自動判定の日数の設定を見直してください。

まとめ

営業日報のムダは、書き方ではなく、すでに別の場所にある情報を人が転記していることから生まれています。訪問先はカレンダーに、商談の段階は案件の記録にあります。

進め方は、上司に過去1か月の日報を開いてもらい、実際に読んでいる場所を指してもらうところから始めます。3項目に絞り、それ以外は様式から削る。元データは、案件名・担当・段階・最終更新日の4列だけ先に揃える。カレンダーと案件シートから下書きを自動で作り、平日17時に本人へ届ける。営業が書くのは、困っていることの1行だけ。

合意は、取得する範囲を実装の前に文書で配ることで取ります。取得しないと書いたものは取得しない。削った項目は後から個別に聞かない。評価には使わない。そして、日報の内容をAIに渡すなら、利用目的の範囲と委託先の監督を先に確認し、顧客名は置き換えてから渡す。ここまで揃えて、日報は書くものから届くものに変わります。

よくある質問

顧客管理のシステムを使っていない場合でも始められますか

始められます。案件の記録に必要なのは、案件名、担当、段階、最終更新日の4列だけなので、スプレッドシートで足ります。むしろ、システムの導入を先にすると、日報の話が止まります。4列のシートで3か月回してから、必要なら移行を検討してください。

1行の欄に何も書かれない日が続いたら、どうすればよいですか

まず、上司がその1行に反応しているかを確認してください。書いても何も返ってこない状態が続くと、営業は書かなくなります。反応の形は、返信でも次の面談での一言でも構いません。読まれていると分かることが、書き続ける条件です。

訪問件数を個人別に見てはいけませんか

見ること自体は妨げませんが、この仕組みの導入時には出さないと決めたほうが定着します。件数を個人別に並べると、件数を増やすための訪問が生まれ、記録の意味が変わります。個人別の活動量を見たい場合は、日報の自動化とは別の話として、目的を説明したうえで導入してください。

止まっている案件の判定は、何日が適切ですか

自社の商談の長さによります。最初は14日で始めて、1か月ごとに調整してください。判定に引っかかる件数が多すぎて見きれないなら日数を延ばし、逆に手遅れになってから出てくるなら短くします。業種によっては7日が適切な場合もあります。

営業から「機械に見られている」と言われたら

取得する範囲を書いた1枚を見せてください。開始時刻と件名だけで、参加者も場所も本文も取っていないことが、その1枚から分かります。口頭で「監視ではない」と言うより、何を取っていないかを具体的に示すほうが伝わります。

AIで日報の内容を分析してもよいですか

集計と傾向の把握であれば有用です。ただし、顧客名や担当者名は置き換えてから渡してください。また、個別の申し送りの1行は人が読むものとして残すほうが、営業の心理的な安全が保たれます。集計はAI、個別の中身は人、という線を引いてください。

同じ部門の記事

営業営業リスト作成を自動化する｜Places APIとスプレッドシートで毎週更新、営業が使うリストにする合意の取り方まで2026年9月20日