音声ジャーナリング × NotebookLM、続けてみたら地味な壁がいろいろ出てきた

音声ジャーナリングをNotebookLMに入れて振り返る実験を始めた。2日目にして、地味な壁がいくつか出てきた。

そもそも仕組みは極めてシンプルで、

課題は「毎回録音の冒頭に日時を喋らないといけない」くらいだった。

あれから続けてみて、負担なく断念せずにできるやり方を一旦ひとつ見つけられた、という段階。固まったとまでは言えないが、型の候補は見えてきた。

その過程で出てきた地味な壁の話をする。

日時問題、力技で解決した

前回の課題だった「毎回日時を喋る」問題。

解決策はわりと泥臭い。

iPhoneのボイスメモ画面のスクリーンショットを撮って、音声データと一緒にNotebookLMにアップするだけ。

スクショにはファイル名と日時が写っているので、NotebookLM側で音声と紐付けてくれる。

自動化とは程遠い。

でも、ここをシステマチックにしようとすると設計が重くなって、自分の性格的に確実に手が止まる。

とにかく運用にのせることを優先した。

無料版による制約

今はGoogle AI Proの半額セールで使えているので、NotebookLMのソース上限はあまり気にしなくていい。ただ、この期間が過ぎれば無料版に戻る。無料版の上限は50ソース。音声45＋スクショ5枚くらいで埋まってしまいそうだ。

対策としては、文字起こしされたテキストを1つのGoogleドキュメントにまとめて貼り付ける運用しかない。

また、要約はせず、生の文字起こしデータのまま残す。一次情報に近い状態で保管しておきたいからだ。

運用が固まってくれば録音は朝晩の1〜2回程度に収まるだろうが、移動中にふと気づいたことをパッと録りたいときもあるので、ソースの消費はそれなりに早いと思う。

効率的な回し方は今後の課題。

前処理が地味に面倒

録音自体は気軽だ。ボイスメモを開いてしゃべるだけ。

問題はその後の処理にある。

NotebookLMにアップするとき、ただ音声を投げればいいわけではない。

前回どこまでアップしたか確認して、それ以降のボイスメモのスクショを1件ずつ撮って、音声と一緒にアップロードして、文字起こし結果をGoogleドキュメントに転記する。

この一連の前処理が、地味に精神的なハードルになる。

月1でまとめてやると対象が多すぎて心が折れるかも。かといって2〜3日に1回やるのも、そこまでマメにはなれない。

週1くらいが落としどころな気もしているが、正直まだ最適な頻度は見えていない。

iCloudの容量も地味に気になるので、処理済みの音声データは順次消していこうと思う。テキストにしてしまえば容量の心配はない。

iPhoneユーザ辞書がこの時代に化けた。ただしiPadに落とし穴

ユーザ辞書自体は前から使っていた。

メールアドレスや住所の登録くらいの、よくある使い方。

それがプロンプトを日常的に使うようになってから一変した。

NotebookLMに投げるプロンプトや、データ加工用の指示文をユーザ辞書に登録しておくと、2文字入力するだけで長文のコマンドが呼び出せる。

これがかなり快適で、登録数が一気に増えた。

で、ある日iPadで同じことをやったら、登録したプロンプトが途中で切れた。

iPhoneでは全文出るのに、iPadだと末尾が欠ける。

最初はiPad側の登録がおかしいのかと思ったが、原因はキーボードだった。

iPadのSmart Keyboard Folio（純正の外付けキーボード）を使っていると長文が切れる。

フローティングキーボード（画面上のiPhone風の小さいキーボード）に切り替えたら全文出た。

正直、なぜそうなるのかはちゃんとわかっていない。いずれ調べたいとは思っているが、今のところは「そういうものらしい」で止まっている。

同じ状況の人がいたら、まずフローティングキーボードを試してみてほしい。

よほどしっくりくるものがないと、続かないのか

蓄積したデータをNotebookLMで振り返ってみたが、まだ日が浅いので「そういえばあったな」程度。

名著の要点を使って日記を読み直す試みも、要約レベルでしか本を知らない状態だと、馴染みのない言葉で返ってきてあまりピンとこなかった。

振り返ると、今回やっていたのはほとんど運用の土台づくりだった。

日時の記録方法、ソースの管理、処理の頻度、プロンプトの呼び出し方。

肝心の「AIに自分の思考を振り返ってもらう」という本来の目的には、まだたどり着けていない。

そもそもこの一連の試み、出発点は「NotebookLMを何かに使いたい」だった。

ツール起点で始めた運用は、よほどしっくりくるものに出会わないと続かないのかもしれない。

まだ答えは出ていない。

上に書いた「要約はせず、生の文字起こしのまま残す」という判断が妥当だったのかは、後日、同じ音声をiPhone標準・Notta・NotebookLM・Geminiの4つに聞かせて確かめた。書き起こしの全文比較と、要約が何を落としたかの採点表を、別の記事にまとめてある。

持ち帰り——挫折しにくい音声ジャーナリングの最小構成

この記事のあとも試行錯誤して、いま残っている最小の型だけ置いておきます。

1. 録音はボイスメモで思いついた時だけ(頻度を決めない。決めると義務になって折れる)
2. 前処理は週1回・15分だけ(日時はスクショで力技。自動化しようとしない)
3. 要約せず生の文字起こしのまま残す(要約は大事な部分を落とす——下の記事で実測しました)

要約が何を落とすかを、同じ音声を4つのAIに聞かせて確かめた記事はこちらです。

iPhoneの要約機能が、大事な部分を消した──同じ音声を4つのAIに聞かせてわかったこと

読んでいる人はいま、何の前で止まっているだろうか。「◯◯が決められない」「◯◯がうまくいかない」——◯◯を埋めた一行だけ、コメントに置いていってほしい。理由も背景もいらない。どこで止まっている人が多いかで、次に何を確かめるかを決める。