日報を書かずに残す。AIと作業ログで自動生成する仕組み

日報をAIで自動生成するとは、結局のところ何を機械に渡すことなのか

日報をAIで自動生成するとは、文章を代筆させることではありません。日報の源泉、つまり「その日に何をしたか」という事実のほうを機械に集めさせ、AIには言語化だけを任せることです。ここを分けないまま生成AIを足しても、入力欄が残る限り日報を書く時間は消えません。

僕はAIVESTという会社を経営していて、経営しながら自分でも手を動かしています。日報を書く時間を消すために作ったのが、その日の作業ログから日報を組み立てる自作の仕組みです。2026年9月10日時点で、2026年6月3日から9月9日までの98日分の日報が、僕が一度も書かずに溜まっています（出力フォルダのファイル実数を当日カウント）。

この記事では、その運用を「機械が集める／AIが言語化する／人が足す」の3層に分けて公開します。あわせて、作業ログの自動収集が従業員監視にすり替わらないための「集めない情報」の線引きも、実際に決めた形のまま出します。日報のAI作成をツール比較ではなく仕組みから考えたい人向けです。

なぜ「AIに日報を書かせる」だけでは、書く時間が消えないのか

「日報 AI」で調べると出てくる方法の多くは、その日やったことを箇条書きでプロンプトに入れると整った日報が返ってくる、という型です。実際に試すと文章はきれいになります。ただ、多くの人が数日で飽きます。

理由ははっきりしていて、箇条書きを打ち込む作業のほうが日報の本体だからです。日報にかかっている時間の大半は、文章を整える時間ではなく「今日の午前、自分は何をしていたか」を思い出す時間、どの案件のどのファイルを触ったかを探す時間です。文章生成はその後の数十秒しかありません。

入力欄が残っている限り、日報を書く仕事は消えていません。場所が移っただけです。

「AIに丸投げすると中身が空洞になる」という批判は半分正しい

日報をAIに任せると振り返りが育たない、という指摘があります。これは半分正しい。空洞になるのは事実の記述をAIに任せたときではなく、判断と所感までAIに書かせたときです。

その日に何をしたかは機械が正確に記録できます。それをどう解釈し、明日どう動くかは本人にしか書けません。だから僕の結論は「AIに日報を書かせるな」ではなく「AIに書かせる範囲を言語化だけに絞れ」です。

3層の分け方。機械が集める／AIが言語化する／人が足す

日報の自動化がうまくいくかどうかは、ツール選びではなく、この3層をどこで切るかで決まります。

決定的にできることをAIにやらせない。AIには、決定的にはできないことだけをやらせる。（僕がハーネス（自作の自動化システム）を組むときの原則）

この順番を守ると、AIが失敗した日でも日報は出る

3層に分ける実利は、責任の所在がはっきりすることだけではありません。上の層ほど壊れにくく、壊れたときの損害が小さいという点が大きいです。

第1層が決定的なコードなら、AIの機嫌に左右されず毎日同じ品質で事実が残ります。第2層のAIが黙った日も、集計結果さえあれば「何時に何を触ったか」は読めます。逆に第1層をAIに任せると、集め漏れた日は復元できません。作業ログは翌日には思い出せません。

第1層。作業ログから何を「決定的に」集めるか

僕の仕組みが日報の材料にしているのは2つだけです。ひとつはClaude Code（ターミナルで動くAIコーディング環境）のセッションログ、つまり僕がAIに出した指示とAIが実行した操作の記録。もうひとつは、作業フォルダ配下でその日に変更されたファイルの一覧です。

集めた行は、SQLite（1ファイルで完結する軽量データベース）に固有IDを主キーとして記録します。同じ日を何度回しても、同じ行は二度積まれません。日中に一度出して夜にもう一度回しても、数字が二重にならないためです。

なぜ収集を「決定的なコード」に寄せるのか

収集をAIに任せると、同じ日を2回処理したときに違う結果が返ります。日報は蓄積して初めて価値が出る記録なので、日ごとに粒度がぶれると後から比較できません。コードで集めた数字なら、あとから同じコードを流して再現できます。

この「事実は機械、解釈はAI」の切り分けは、会議の議事録を自動化するときにも同じ形で効きます。あちらの源泉が音声で、こちらが作業ログというだけの違いです。

何を集めないと決めたか。日報の自動化が従業員監視に変わる線

作業ログを自動で集める仕組みは、設計を一歩間違えると勤怠監視ツールになります。自動化の前に必ず線を引く必要があります。僕の運用では集める情報より先に「集めない情報」を書き出しました。

集めないと決めたのは次の4つです。

1. 会話や作業内容の全文。指示は先頭400字で丸め、それ以上はデータベースにも要約AIにも渡しません。実行結果の中身（コマンドの出力やツールの返り値）は収集対象から除外しています。

2. 画面の中身と生の操作ログ。実行したコマンドは先頭1行80字まで・サンプル30件までに切り詰め、それ以外は残しません。

3. 在席時間・稼働時間・打鍵頻度。「何時から何時まで席にいたか」は一切集めません。集めているのは行為の記録で、時間の監視ではありません。

4. 成果物に関係しない領域。ライブラリの自動生成物やバージョン管理の内部ファイル、設定フォルダは収集経路の時点で除外します。

集めていい情報の基準は「本人が日報に書くつもりだったことか」です。書くつもりのなかったものを機械が拾い始めた時点で、それは日報ではなく監視になります。

チームに広げるなら、この線を先に文書化する

自分ひとりで回している間は、線引きは頭の中にあれば足ります。チームに広げるなら、集める項目・集めない項目・保存期間・閲覧できる人の4点を先に書き、本人に見せてから収集を始めるべきです。順番が逆になると、後からどれだけ説明しても信頼は戻りません。

生成AIの業務利用ルールの考え方は社内のChatGPT利用ルールの決め方にまとめています。日報の作業ログも同じ枠組みで、取得する情報の範囲を先に定義しておくのが安全です。

第2層。AIに任せるのは「言語化」だけにする

第1層が終わると、その日の集計結果がデータとして手元にあります。AIに渡すのはこのデータだけで、返してもらうのも決まった形だけです。

僕の運用では、AIの出力を3つの配列に固定しています。話したこと（その日の論点）、実施したこと（成果物単位の実績）、オープンアクション（未完了の依頼とTODO）。日報の見出しもこの3つと機械集計サマリの4つで固定です。出力形式を固定すると、AIの仕事は「分類して短く言い換える」だけになり、失敗率が下がります。

AIが黙った日にどうするか。縮退運転を先に決める

2026年7月27日に、要約を担当するAIが16秒で空の応答を返し、そのまま中身のない日報が確定する事故が起きました。再試行の仕組みが無く、一撃で確定してしまったわけです。

対策は3つです。要約は最大3回まで、待ち時間を伸ばしながら再試行する。話したことと実施したことが両方空なら成功とみなさず次の試行に回す。送信の直前に品質ゲートを置き、要約の欠落を検知したら機械集計だけで日報を出して配信する（縮退運転）。

「AIが失敗した日に何を出すか」を決めていない自動化は、失敗した日に何も残りません。これは日報に限らず、無人で回す仕組み全般に言えることです。

第3層。人が足すのは判断と所感。ここを残すから日報が資産になる

機械が事実を集め、AIが言語化した時点で、日報は9割できています。残りは人の仕事で、僕がやっているのは2つだけです。

ひとつは、AIが抽出したオープンアクションから本当に自分がやると決めたものだけを残すこと。AIは発言から拾えるものを全部並べてくるので、捨てる判断をしないとタスクが増え続けます。もうひとつは、その日の判断について1行だけ所感を足すこと。「この設計を採用した理由」「やめた理由」は作業ログのどこにも残りません。

かかる時間は3分ほどです。削減効果の数字は測っていないので断言はしません。効果を数字で言い切りたいなら、AI導入の効果測定を設計する側の準備が別途必要です。

判断と所感を人が足すからこそ、蓄積した日報が後から読める資産になります。事実だけの記録は検索には使えますが、意思決定の再利用には使えません。

日報のAI自動化を自社で始める5ステップ

いきなり僕と同じ構成を組む必要はありません。順番だけ守れば、ツールは何でも構いません。

最初の1〜2週間は手動で回して、出てきた日報を自分で読んでください。中身が読むに耐えると確認できてから、無人化に進むのが安全な順序です。

毎晩22時に無人で回してみて分かった3つのこと

僕の仕組みは、macOSの常駐スケジューラ（LaunchAgent）で毎晩22時に起動します。人が触らずに回り続けて、2026年9月10日時点で98日分が溜まりました。分かったことを3つ挙げます。

1つ目。無人実行は「起動させる」ことより「二重に走らせない」ことのほうが難しい。手動で回した日と自動実行が重なる事態は普通に起きます。実行中かどうかを見て重複起動を止める仕組みと、同じ日に2回配信しないガードを入れて、ようやく安定しました。

2つ目。処理時間は思っていたより短い。2026年9月9日の実行ログでは、22時00分05秒に開始して22時00分55秒に完了、およそ50秒でした。1日分の収集と要約と描画を合わせてこの時間です。負荷を心配して着手が遅れるくらいなら、先に動かしたほうが早いです。

3つ目。価値が出るのは溜まってから。1週間分では単なる作業メモです。3か月分になると「この案件に何日使ったか」「あの判断はいつしたか」を後から追えます。日報の自動化は時短というより、記録が残ることそのものにリターンがあります。

無人実行のスケジューラ側の作り方は、別記事で詳しく書いています。

関連記事Claude Codeを毎朝定時に走らせるlaunchd自動化MacでClaude Codeを毎朝決まった時刻に無人で走らせる方法を、このブログ自体を運行する3系統のlaunchdジョブの実物設定と実ログで解説。二重起動の防止、冪等スキップ、止まったときに気づく仕組みまで公開します。→

よくある質問

まとめ。日報は「書くもの」ではなく「残るもの」にできる

日報のAI自動化で最初に決めるべきは、どのツールを使うかではありません。何を機械で決定的に集め、何をAIに言語化させ、何を人が足すかの3層です。

事実は機械が集め、言語化だけAIに任せ、判断と所感は人が足す。この順序を守れば、AIが失敗した日でも記録は残り、丸投げしても中身は空洞になりません。そして収集を始める前に、集めない情報の線を先に書く。これが日報の自動化を監視に変えないための最低条件です。

日報は毎日書くものではなく、毎日残るものにできます。まずは今のテンプレートを開いて、項目を事実・解釈・判断に仕分けるところから始めてみてください。