ヤシノミ ロゴ 合同会社ヤシノミ LINEで相談
仕組み化・自動化 業務改善コラム

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

業務改善コラム / 仕組み化・自動化 / 読了目安:約10分

タイトルは比喩ではありません。いまあなたが読んでいるこの記事の骨格は、ある一日の私のパソコン操作の記録(ログ)・AIの稼働記録・プログラムの変更履歴を、毎晩21時に動く小さなプログラムがAIに渡して書かせたものです。私はいま、日報を自分の手では書いていません。会社員の頃は毎日書けていたのに、独立したら続かなくなったからです。書けない自分を責めるのをやめて、仕組みのほうを変えた話をします。

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

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

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

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

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

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

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

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

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

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

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

この記事でいちばん持ち帰ってほしい一文

記録する努力をやめて、記録される仕組みにする。意志力に頼る運用は、必ず止まります。

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

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

記録中身ある日の実際の量
PC行動ログ5分おきに「どのアプリで・何のウィンドウを開いていたか」を自動記録(Macの標準機能で組める)155行
AIの稼働ログAIアシスタントが「どのプロジェクトで・何時に・何をしたか」の操作記録1,112アクション(操作回数)
プログラムの変更履歴9つのプロジェクトの「今日の変更記録」(gitという変更履歴を残す道具に自動で溜まる)。変更内容の一行説明つきプロジェクト横断で十数件

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

10:35 Google Chrome Search Console - 所有権の確認
10:40 Claude 構造化データの実装
10:45 Claude 構造化データの実装
10:50 Microsoft Word 行動計画策定・変更届.docx
……これが1日中、勝手に積み重なっていく

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

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

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

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

① 3つの記録を集めて圧縮(プロジェクト別の稼働、アプリ別の時間、変更記録の一覧に整形)
↓
② AIに渡して2つを生成(「1日の成果まとめ」と「SNS投稿の下書き3本」)
↓
③ 日付つきファイルとして保存(記録が資産として溜まっていく)
↓
④ チャットに配達(翌朝、下書きがSlackに届いている)

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

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

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

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

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

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

よくある失敗

「品質のための確認工程」が、実際には品質ではなく停止を生んでいる。確認の価値と、仕事の流れが止まる危険は、いつも天秤にかけるようにしてます。

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

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

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

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

# 機密ルール(違反したドラフトは破棄する)
・顧客・支援先の実数値(売上・利益・稼働率・広告費)は書かない
・顧客名・店舗名は書かない(事例化の許可を得た案件を除く)
・連携用の鍵やパスワード、内部の管理番号の類は書かない
・自社ブランドの仕入先・原価などの内部数値は書かない
・OK:自社の作業時間、失敗談、仕組みの構造、相対値(「約4倍」「半日→3分」)

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

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

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

毎晩21時に動く——と書きましたが、定期実行の仕組みは必ず失敗します。パソコンが休止状態になっている、Wi-Fiが切れている、外部サービスが一時的に落ちている。うちも社内のあらゆる定期処理(広告データの収集、検索順位の取得、経理の集計)で散々こけてきたので、いまは最初から失敗前提で組んでます。型は3つだけです。

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

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

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

初回の実行で、ある1日分のログから出てきたものをそのまま見せます。まず「1日の成果まとめ」の冒頭部分。

## 2026-06-10 作業サマリー
### 自社ECサイト(★メイン進捗)
・ロングテールSEO記事を15本一括追加 ★
・GA4計測・クリックイベント・sitemap/robots・構造化データを一気に整備 ★
### 広告調整(290アクション)
・コミットなし。施策の検討・分析・調整作業と推定
### 補助金・助成金(73アクション)
・申請書類一式をWordで作成と推定
### 本日の稼働規模
・AI:530分(約9時間)、Chrome:110分……

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

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

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

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

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

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

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

広告運用での役割発信での対応物頻度
日次データ収集作業ログの収集と下書き生成(本記事の仕組み)毎日
入札の打ち手投稿する毎日
悪化・好調の検知投稿ごとの反応(表示・反応・プロフィール到達)を取得毎日
週次の効果検証どの型・どの話題が効いたかを分析し、ルール集を更新週1
ルール集の参照更新されたルール集が翌日の指示文に自動で入る毎晩

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

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

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

勝手に溜まる記録 → 機械で圧縮 → AIで解釈 → 決まった形で届く

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

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

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

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

できます。この型は自社専用ではなくて、支援先にも納品しています。たとえば予約システムを使うサービス業では、日々の実績を毎朝自動でSlackに届ける仕組みが稼働中です。素材が「PCログ」から「予約システムの記録」に変わっただけで、構造はこの記事とまったく同じでした。

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

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

12. まとめ

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

日報が続かへんかった自分を、しばらく責めてました。でも直すべきやったのは自分じゃなくて設計のほうやった、というだけの話です。同じところで止まってる人がいたら、どの記録がもう溜まってるかを一緒に探すところから話しましょう。

「うちの会社の“手で書いている報告”、自動にできる?」という方へ

日報・月次報告・引き継ぎ・発信——「すでに記録されている情報の写経」になっている業務は、この記事と同じ型で自動化できます。
どの記録がすでに溜まっているかの棚卸しから、一緒にやります。LINEで概要を送ってもらえたら、組み方の考え方を返します。

LINEで相談する

あわせて読みたい

いま、どこで詰まっているか

当てはまるものをタップするだけ、約1分。入力も登録も要りません。詰まっている場所が分かったら、その直し方を「診断書」にしてLINEでお送りします。

記事の更新通知だけ受け取りたい方は、LINEで新着記事を受け取る。月に数本、相談の義務はありません。

業務改善コラム一覧に戻る