この記事の下書きは、
昨日の私の作業ログからAIが作った ——日報が続かない経営者の「記録される仕組み」

1. 告白：会社員の頃は書けていたのに

正直に書きます。会社員時代——製造業で現場改善をやっていた頃——の私は、日報も週報も毎日書いていました。ところが独立した途端、続かなくなりました。書こうと決めて、テンプレートまで作って、3日で止まる。

この対比が、答えをほとんど言っています。会社員の頃に書けていたのは、私の意志が強かったからではありません。提出先があり、締め切りがあり、読んで返してくれる人がいたからです。独立してその構造が消えると、残るのは「1日の終わり＝いちばん意志力が残っていない時間」に、自分ひとりで机に向かう設計だけ。夜の自分に「今日をきれいに振り返って文章にまとめる」という知的作業を任せるのは、根性論です。そして私たちは、根性論で回っている業務を仕組みに置き換えるのが仕事です。だったら、自分の日報こそ最初に仕組み化するべきでした。

同じ悩みを、支援先の経営者からも何度も聞きます。「日報を書け、と社員に言っている自分が書けていない」「営業日報が形骸化して、コピペの定型文になっている」。続かないのは、あなたの意志が弱いからではありません。設計が人間の弱い時間帯に負荷をかけているからです。

2. それでも「記録」は経営の燃料である

では記録を諦めていいかというと、逆です。記録は思っている以上に多くのものの「上流」にあります。

• 発信の燃料。ブログもSNSも、ネタ切れの正体は「やったことを忘れている」です。仕事を1日すれば、ネタは必ず発生しています。消えているだけです。
• 振り返りの燃料。「今週は何に時間を使ったか」が分からなければ、改善のしようがありません。感覚での振り返りは、だいたい直近2日の印象に引っ張られます。
• 引き継ぎ・属人化対策の燃料。誰が・いつ・何をどう処理したかの記録は、そのまま業務マニュアルの素材になります。

つまり「記録が続かない」は、単に日記が書けないという話ではなく、発信・改善・組織化の3つが同時に燃料切れを起こすということです。これは放置できない。でも、書けないものは書けない。

3. 発想の転換：「記録する」をやめて「記録される」にする

ここで問いを変えました。「どうすれば日報を書き続けられるか」ではなく、「そもそも人間が書く必要があるのか」。

考えてみると、私の仕事の大半はパソコンの中で起きています。AIアシスタントへの指示、ブラウザでの調査や管理画面の操作、コードや文書の変更。行動の痕跡は、すでにデジタルの形でそこにあるのです。痕跡があるなら、人間がやるべきは「思い出して書く」ことではなく、「痕跡を集めて要約させる」ことです。

4. 素材は、もう3つ転がっていた

調べてみると、私の1日は意識しないまま3箇所に記録されていました。どれも一度設定すれば、あとは勝手に溜まり続けるものです。

たとえばPC行動ログは、こんな素朴なものです。5分ごとに1行、前面のアプリとウィンドウ名を書き足していくだけ。

1行ずつはただの断片です。しかし1日分まとめてAIに渡すと、「午前は計測まわりの整備、昼は申請書類の作成、午後は広告の調整」という物語として復元できる。ここが面白いところで、断片の記録は人間には読む気が起きませんが、AIにとっては十分すぎる素材なのです。

補足：もし仕事の中心が外回りや現場なら、素材はカレンダー・チャットの送信履歴・レジや基幹システムの操作ログに置き換わります。「すでに勝手に溜まっている記録は何か」から考えるのがコツです。

5. 毎晩21時に何が起きているか（仕組みの全体像）

素材が揃っているなら、あとは流すだけです。毎晩21時、1本のプログラムが自動で動きます。人間は起動ボタンすら押しません。

ポイントは①の「圧縮」です。生のログを全部AIに渡すと、量が多すぎて要点がぼやけます。だから先に機械的な集計を挟む。「AI稼働1,112行」は「広告調整プロジェクトで290アクション（10時〜23時）」のような十数行に潰してから渡します。前処理は機械、解釈はAI、という分業です。

②でAIに渡す指示文には、後述する「機密ルール」と「投稿の型」を毎回まるごと埋め込みます。つまりAIは毎晩、最新のルールブックを読んでから書き始める。ルールを更新すれば、翌日から出力が変わります。

ここまでの構築にかかった時間は、AIと一緒に組んで1時間弱でした。特別なサーバーも買っていません。普段使っているノートPCが、夜に1人で働くだけです。

6. あえて「人間の編集」を挟まない理由

設計時にいちばん迷ったのがここです。普通に考えれば「AIが下書き→人間が手直し→投稿」が安全に見えます。実際、最初はそう設計しました。そして捨てました。

理由は単純で、業務フローの中で詰まるのは、ほぼ必ず「人間の承認待ち」の箇所だからです。これは支援先の業務を見ていて毎回出てくるパターンです。承認や手直しのステップは、入れた瞬間は丁寧に回りますが、忙しい週に2日溜まり、溜まった瞬間に心理的負債になり、1ヶ月後には仕組みごと止まります。発信のような「やらなくても今日は困らない」業務では特にそうです。

だからこの仕組みでは、完璧な1本を磨くのではなく、まず出して、反応というデータで次を直す方に振りました。文章の細部の良し悪しを会議室で議論しても答えは出ません。読者の反応だけが答えを持っています。これは広告運用とまったく同じ思想です（後述）。

7. 無人運用の生命線：機密ルールの焼き込み

人間のチェックを外すなら、代わりに機械的に守られる防衛線が必要です。私たちはお客様の売上や利益という、絶対に外に出してはいけない数字を日常的に扱っています。ここが崩れるなら、この仕組み全体をやる資格がありません。

対策は、生成のたびにAIへ渡す指示文の先頭に「破ってはいけないルール」を明文化して焼き込むことです。実物から抜粋します。

あわせて、書いてよい「程度」も決めてあります。たとえばお客様の成果は相対値しか書かない。「売上◯◯万円」ではなく「前月比 約4倍」。これなら価値は伝わり、機密は守られます。逆に自社の数字は実数で出します。当事者の実数には、相対値にはない説得力があるからです（この記事の「1,112アクション」「530分」も自社の数字だから書けています）。

もうひとつ実務的な注意点。こうした仕組みを作るとき、ログそのものに機密が混ざることがあります。ウィンドウタイトルに顧客名が入る、コミットメッセージに金額を書いてしまう、など。だからルールは「出力時に守らせる」だけでなく、「そもそも記録に書かない」習慣とセットで運用しています。

8. 定期実行は「失敗する前提」で組む

毎晩21時に動く——と書きましたが、定期実行の仕組みは必ず失敗します。PCがスリープしている、Wi-Fiが切れている、外部サービスが一時的に落ちている。私たちは社内のあらゆる定期バッチ（広告データの収集、検索順位の取得、経理の集計）で散々失敗してきたので、最初から失敗前提で設計します。型は3つだけです。

• リトライの時刻を最初から仕込む。21:00に加えて22:30にも起動する。1回目が死んでも2回目が拾う。
• 「今日はもう実行済み」の目印（フラグ）を置く。成功したら日付つきの目印ファイルを作り、2回目の起動は目印を見て即終了する。これで二重実行・二重投稿を防ぐ。
• ログを1行残す。「いつ動いて、成功したか失敗したか」だけでいい。止まったときに原因を5分で特定できるかどうかは、この1行があるかで決まる。

この3点セットは、発信に限らずあらゆる自動化に使い回せます。逆に言うと、この3つがない自動化は「動いているように見えて、いつの間にか止まっている」状態に必ずなります。自動化の信頼性は、賢さではなく、失敗の拾い方で決まるのです。

9. 昨日のログから、実際に何が出てきたか

初回の実行で、昨日1日分のログから出てきたものをそのまま見せます。まず「1日の成果サマリー」の冒頭部分。

私は何も書いていません。それでも「★＝発信ネタになりそうな出来事」の目印つきで、1日が整理されて返ってきます。注目してほしいのは「〜と推定」という表現です。ログから断定できないことは断定しない、と指示してあるので、AIが成果を盛らない。記録系の自動化では、この「盛らせない」設計が信頼性のすべてです。

そして同時に生成されたSNS下書きが3本。そのうちの1本がこれです（一字も直していません）。

SEO記事、手で書いたら1本あたり2〜3時間はかかる。今日15本を同日中に公開した。キーワード設計と記事構成は自分が考える。「誰に・何を・どの角度で」だけ決めてしまえば、本文生成はAIに渡せる。人間がやる仕事が「書くこと」から「設計すること」に変わった。

正直に言えば、100点の文章ではありません。でも、私が夜に机に向かって書いたであろう60点の文章より、確実に「存在している」。0本と3本の差は、60点と100点の差より、はるかに大きい。発信が続かない人に必要なのは推敲ではなく、存在です。

10. 出しっぱなしにしない：投稿が勝手に上手くなる構造

「編集なしで出す」だけなら、ただの自動垂れ流しです。この仕組みの本体は、その先にあります。

私たちはAmazon広告の運用で、「毎朝データを集める → 悪化の兆候を自動検知する → 週次で効果を検証する → 検証結果をルール集に書き戻す → 翌週の判断がルール集を参照する」という改善ループを回しています。広告が上手くなるのは人間の勘ではなく、ルール集が育つからです。発信にも、まったく同じ構造を移植します。

このループが閉じると、何が起きるか。人間が文章を上達させるのではなく、仕組みが投稿を上達させるようになります。反応の良かった型はルール集に「勝ちパターン」として昇格し、翌日からの下書きに反映される。反応ゼロの型は「負けパターン」として封印される。担当者の感性に依存しないので、誰がやっても・何ヶ月続けても、劣化しません。

11. これは「発信」だけの話ではない

ここまで発信を題材にしてきましたが、構造を一段抽象化すると、こうなります。

この型に当てはまる業務は、中小企業の中にいくらでもあります。

• 社員の日報・週報：書かせるのをやめて、業務システムやチャットの記録から自動生成し、本人は一言添えるだけにする。
• 顧客への月次報告：売上データや対応履歴から報告書の骨格を自動で組み、担当者は所見だけ書く。
• 店舗の引き継ぎノート：レジ・予約システムの記録から「今日あったこと」を自動でまとめる。
• 経営者自身の振り返り：今週・今月、自分が何に時間を使ったかが、何もしなくても数字で届く。

共通するのは、いま誰かが「思い出しながら手で書いている」報告類は、たいていすでにどこかに記録された情報の写経だ、ということです。写経は人間の仕事ではありません。

「うちの会社でもできるのか」への正直な答え

できます。実際にこの型は自社専用ではなく、支援先にも納品しています。たとえば美容サロンでは、予約システムの売上・稼働率・集客経路を毎朝自動でSlackに届ける仕組みが稼働中です。素材が「PCログ」から「予約システムの記録」に変わっただけで、構造はこの記事とまったく同じです。

ただし、安請け合いはしたくないので、前提を3つ正直に書いておきます。

• 素材になる記録が先にあること。予約システム・POS・会計ソフト・チャット・業務システムなど、すでに勝手に溜まっている記録が出発点です。何もなければ、まず「記録される仕組み」から作ります（それ自体が支援の第一歩です）。
• 社員のPCログを使うなら、本人の合意とルールが必須。無断のPC監視は論外です。まず経営者自身の分から始めるのが定石で、サーバー側のデータ（予約・売上・会計）を素材にすれば、そもそも社員のPCに触れずに組めます。
• AIに渡す前の機密の線引きを最初に決めること。顧客名や金額をどう落とすか。この記事で見せた機密ルールの焼き込みを、その会社の事情に合わせて設計します。

12. まとめ

• 日報や発信が続かないのは意志の問題ではなく、人間の意志力が切れた時間帯に負荷をかける設計の問題。
• 「記録する」のをやめて「記録される」仕組みへ。素材（PCログ・AI稼働・変更履歴）はすでに勝手に溜まっている。
• 前処理は機械、解釈はAI、という分業。生ログは圧縮してから渡す。
• 人間の編集ステップは、品質ではなく停止を生みやすい。まず出して、反応で直す。
• 無人運用の生命線は、毎回の指示文に焼き込む機密ルールと、「盛らせない」設計。
• 定期実行は失敗する前提で、リトライ・重複防止フラグ・1行ログの3点セットを必ず付ける。
• 反応データでルール集を育てるループまで閉じれば、仕組みが勝手に上手くなっていく。