日記(日報)を書くのを諦めたら逆に続くようになった話〜Google Workspace Studioで作るAIネイティブな日記・日報システムへの活用事例〜

まとめ

Google Meetで3分しゃべるだけで、AIが自動で構造化・保存・通知してくれる日記(日報)システムを作った。本人の気づきとAIの解釈を分けて記録することで、将来の振り返りや分析にも使える設計にしている。

結論：この仕組みを入れて何が変わったか

実際にこの日記システムを回してみて、今のところこんな変化が出ています。

• 「日記書こう」とPCを開いて三日坊主になるループが、ここ数週間は毎日3分だけ続いている
• その日の振り返りにかける時間が、30分前後から3分＋メールを読むだけになった
• 「あの時期なに考えてたっけ？」を思い出す時に、factsとinsightsだけを一覧で眺められるようになった

この記事は、この変化を生んでいる設計の考え方と設計について扱っています。他記事で実装編も扱います。

誰向け？

• 日記(日報)や振り返りを習慣化したいけど、書くのが面倒で続かない人
• 自分の意思決定パターンや思考の変遷を長期的に記録・分析したい人
• Google Workspace Studioの活用事例を探している人
• 会社に提出を義務付けられた日報を爆速提出して帰りたい人
• スマートウォッチでログ見るの好きな人、Spotifyの年間まとめ見るの好きな人もあるいは

日記を続けたいのに続かない、という悩み

日記(あるいは日報/週報などに読み替えていただいても問題ないです)をちゃんとつけたいと思うものの、三日坊主になった経験が無限にある、という方は多いのではないでしょうか？

私自身いざ書こうとすると、必要以上に気合が入って構成を考えたり言葉を選んだりしているうちに疲れてしまって、結局続かず三日坊主を繰り返してきました。

一方で、ふだんは仕事柄「情報をどう設計するか」ということをよく考えています。SSOT（Single Source of Truth＝情報の一元管理）やドキュメントの資産化、メタデータ設計による「あとから参照しやすい形」といったテーマですね。

折角散々仕事で関連する話を扱っているので、どうせ日記をつけるなら、こういう知恵を全部つっこんで、続けやすくて、将来使いまわせて、ちょっとおもしろい仕組みにできないだろうか、と思い至りました。

そこで試しているのが、Google Workspace StudioとGASを使った「AIネイティブな日記システム」です。

やることはとてもシンプルで、

Google Meetを立ち上げて、3分くらいまとまりなく一人でしゃべるだけ

あとはエージェントとスクリプトが、自動で構造化と保存とメール通知までやってくれます。

この設計編では、思想寄りの話とデータ設計の考え方だけをまとめてみます。細かい設定やコードは別の「実装編」で詳しく解説しますので、まずは「なぜこういう設計にしたのか」という部分を共有させてください。

この日記(日報)システムで満たしたい3つの価値

まず最初に、日記の「役割」をはっきりさせました。何のために記録するのかが曖昧だと、続かないですよね。

1. 長期的な資産にしたい

半年後や一年後に振り返った時に、「自分は何を大事にしてきたのか」「どんな前提や仮説で動きがちなのか」が分かるようなログを残したいと思いました。

具体的には、

• 何が起きて
• どう解釈して
• どう決めたか

という「意思決定OSの履歴」です。結果だけでなく、そこに至るプロセスや文脈まで残します。

2. 短期的なヘルスチェックと示唆が欲しい

日々のコンディションも可視化したいと考えました。

• その日の気分
• 仕事への満足度
• 不安度
• エネルギーレベル

こういったざっくりした状態を数値で残しておくと、「あの時期は無理していたな」といった振り返りができます。

加えて、AIから「こういう見方もできるよ」「本音レベルだと、こっちを望んでいそうだよ」といった軽い示唆をもらえると、自分では気づかない視点が得られるかもしれません。

3. 習慣化しやすいことが何より大事

そして一番重要なのは、やはり継続です。どんなに素晴らしい設計でも、続かなければ意味がありません。

私の場合、

• ノートを開かない
• キーボードに向かわない
• 構成も考えない

くらいまでハードルを下げる必要がありました。そこで、「Google Meetを開いて3分しゃべるだけ」という運用に振り切ることにしたんです。

全体アーキテクチャ

やっていることを一行で書くと、

Meetでしゃべる → Workspace Studioが文字起こしと要約とJSON生成 → Sheetsにログ追加 → GASが整形とメール通知

という流れになります。

もう少し分解するとこんな感じです。

1. カレンダーで「日記用Meet」を入れておく
2. 時間になったらGoogle Meetを開き、3分ほど一人で話す
3. 会議終了後、Google Workspace Studioのフローが起動
   • Gemini for Meetが作った会議メモドキュメントを読み取る
   • テキストをまとめて日記プロンプトに投げる
   • JSON形式の出力を得る
   • それをスプレッドシートのjson列に1行として追加
4. 別途GASが、朝の時間トリガーでシートをスキャン
   • jsonをパースして各列に展開
   • 読みやすい箇条書きに整形
   • その日のログを自分宛にメール送信

人間が意識するのは「Meetを開いて話す」という一動作だけ。あとは全部自動で処理されます。

日記をAIネイティブにするためのJSON設計

この日記システムの中核は、最初からJSONで日記を受け取る前提にしたことです。

「なぜJSON？」と思われるかもしれません。理由はシンプルで、後からの加工や分析がとても楽になるからです。自然言語のままだと、特定の項目だけを抽出したり、時系列で比較したりするのが難しいです。

LLMには、次のようなスキーマで出力してもらっています。

{
  "summary": ["..."],
  "facts": ["..."],
  "insights": ["..."],
  "insights_ai": ["..."],
  "future": ["..."],
  "future_ai": ["..."],
  "emotions": {
    "mood": 0,
    "work": 0,
    "anxiety": 0,
    "energy": 0,
    "comment": "..."
  }
}

それぞれの項目の意味を整理しておきます。

summary: 今日の3行まとめ

その日の話を1〜3文で要約したものの配列です。後から一覧したときに、「どんな一日だったか」がパッと見えるようになります。

例えば、

• 「長く続いていたプロジェクトが一区切りを迎えた。」
• 「インプットとアウトプットのバランスについて改めて考えた。」

といった形です。

facts: その日に起きた事実ログ

仕事・私生活・学びなどを含む「出来事」のリストです。解釈は入れず、できるだけ事実ベースで残します。

例えば、

• 「継続していたプロジェクトが今月で終了することになった。」
• 「近所の銭湯が来週リニューアルオープンする予定だ。」
• 「新しいアウトプット先の可能性について考えた。」

長期的には、ここが「何を経験してきたか」のタイムラインになっていきます。

insights: 本人の気づき・仮説

自分が明示的に話している気づきだけを集める箱です。

例えば、

• 「新規の営業活動から逃げがちだと自覚していることに気づいた。」
• 「作業負荷の割に対価が見合わない仕事を引き受けがちだと感じている。」

ここは完全に「本人ログ」なので、言葉のトーンも自分寄せで残します。

insights_ai: AI視点の補助的な気づき

こちらはあえて、AI専用の箱として分けています。本人は明示していないけれど、テキスト全体から自然に読み取れる範囲の解釈や仮説を入れてもらいます。

例えば、

• 「仕事を手放すと新しいチャンスが来るという経験則を、自分のリスク許容度を支える前提として使っている可能性がある。」
• 「新規営業への苦手意識を、自分を責める材料というより"設計で補う対象"として見ているように感じられる。」

ここは少し先の視点を足す場所で、外部ファシリテーターのメモに近い役割です。

future: 本人の意思・方針・やりたいこと

「今後こう動きたい」と自分で言っている内容だけをまとめます。

例えば

• 「コンテンツをある程度書き溜めてから外部発信を始めたい。」
• 「苦手な営業活動から逃げないように、優先度を上げて取り組んでいきたい。」

future_ai: 本音寄りの方向性・可能性

こちらもAI専用です。テキスト全体のトーンから読み取れる範囲で、「もう少し奥にありそうな願望」や「実は選びたいかもしれない方向性」を書いてもらいます。

例えば、

• 「短期的な売上より、長期的に納得できるクオリティの仕事を優先したい気持ちが強いのかもしれない。」
• 「一人で完結する仕事だけでなく、チームで成果をつくる方向にも本当は再挑戦したい可能性がある。」

ここは完全に示唆なので、自分の言葉と混ぜないようにしています。

emotions: その日のヘルスチェック

気分・仕事満足度・不安度・エネルギーを0〜10でスコアリングし、一言コメントも添えてもらいます。

mood: 6
work: 7
anxiety: 4
energy: 5
comment: 「案件は一つ減るが、区切りとしては納得感がある。」

短期的には、その日の自分の状態を軽く振り返るため。長期的には、「どの時期に無理をしていたか」が分かるログになっていくはずです。

なぜ「本人ログ」と「AIログ」を分けるのか

設計上いちばんこだわったのがここです。

• 本人が言っていること → insights、future
• AIが読んで補足していること → insights_ai、future_ai

を、必ず別キーにするようにしました。

これを混ぜてしまうと、どこまでが自分の言葉で、どこからがAIの解釈なのかが、後から分からなくなります。

将来こんなことをやりたくなるかもしれません。

• 「過去一年分の"自分の気づき"だけを並べて読みたい」
• 「AI側が当時どういうメタ視点を返していたかだけを眺めたい」
• 「本音寄りのfuture_aiだけを抽出して、隠れた願望の変化を見たい」

そのとき、本人ログとAIログが混ざっていると、抽出が非常に面倒になります。

また、この設計はクライアントワークに転用することも考えています。例えば1on1の記録で、

• 本人ベースのログ（メンバーの発言や振り返り）
• ファシリテーターのログ（問い、示唆、解釈）

を分けておくのは、割と普遍的なパターンになるのではないでしょうか。

「AI分身がマネジメントする未来」のための訓練データ

ここからは少し未来の話になりますが、個人的に楽しみにしていることがあります。

今回の仕組みは今のところ、自分のヘルスチェックと意思決定OSの可視化のために回しています。ただ、もう少し長い時間軸で見ると、こんな可能性もあるのではないかと考えています。

自分自身のコンテキスト（何をインプットして、どう解釈して、どう判断してきたか）のログがあることで、将来自分のAI分身が、部下やチームをマネジメントできるようになるかもしれない。

単に「過去にこう決めた」という結果だけを学習させても、AIは本当の意味で再現してくれないと思います。大事なのは、

• どんな情報を見て
• 何に重みを置いて
• どんな仮説を立てて
• どこで腹をくくったか

という「コンテキストとプロセス」の方です。

今回のJSON設計は、まさにそこを丸ごと残そうとしています。

• factsで出来事
• insightsとinsights_aiで解釈
• futureとfuture_aiで意思と本音寄りの方向性
• emotionsでそのときの状態

これらが数年分たまると、それ自体が「自分の思考パターンのデータセット」になります。つまり、将来のAI分身に渡すための訓練データを、今せっせと3分日記で集めている、とも言えるわけです。一見ディストピア感がある営みですが、複利で効く系の営みになるなーと思っています。

もちろん、これはまだ妄想の域を出ません。ただ、どうせログを残すなら将来の可能性を広げる形で設計しておいて損はないと思っています。

まとめ

この設計編でやったのは、以下の3つです。

1. 日記の用途を3つに整理したこと

• 長期の意思決定ログ
• 短期のヘルスチェック
• 将来のAI分身の訓練用データ

2. 7つのキーを持つJSONスキーマを設計したこと

• summary、facts、insights、insights_ai、future、future_ai、emotions

3. 本人ログとAIログのレイヤーを分けたこと

• 後からの抽出や分析がしやすくなる
• クライアントワークへの転用も視野に入る

  

実際にどうFlowを組んで、どうスプレッドシートとGASで動かしているかは、別の「実装編」で詳しく解説します。

ここまで読んで「思想だけでお腹いっぱい」という方は、この設計編だけでも十分参考になるかもしれません。「手を動かしたい」という方は、ぜひ実装編も合わせてご覧ください。