習慣化できない人向けのLLMライフログ

このエントリーをはてなブックマークに追加

「日々の活動をメモしろ」というのは、個人の生産性の文脈やライフログ等でよく言われます[要出典]。 実際に私も古くはA4用紙にメモっていったり、いろいろな手帳を試したり、howmやEvernote、Obsidianで色々やっていた過去がありましたが、最終的にはどれも三日坊主になり継続しませんでした。

というのも、メモをするより作業したほうが早いですし、いつも手を動かす方を優先してつい作業をしてしまいます。
特にOSS活動や趣味開発をしている時などは、仕事の後で時間がないので手を動かす方を優先したいとなりがちです。 実際、ここ1年ぐらいは毎週振り返りの予定をカレンダーに入れているのですが、2,3回ぐらいしか成功した記憶がありません。

入れているがほぼ実行されない予定
入れているがほぼ実行されない予定

正直、「LLMなんとかしてくれーーーーー」と思います。

なのでLLMになんとかしてもらいました

LLMによる自動ライフログ

こんな感じに30分毎に何をしていたかをまとめてくれるツールを作りました。
llm_auto_memo

summary_added: 20250223-170000
この30分間に行われた作業は、Twitterのタイムラインを
閲覧し、特に炎上対策に関するツイートに注目していたよ
うです。また、Factorioのゲームプレイ、特に
Krastorio2の改造モジュールに関連する作業も行ってい
たようです。具体的には、コードの修正や改良、バイオマ
スのレシピの変更などを行っていました。さらに、ゲーム
に関連するファイルのダウンロードや管理、Factorioの
プレイなども行っていたようです。最後に、KSPという別
のゲームのミッション管理施設であるVABにも関わってい
たようです。

summary_added: 20250223-173000
この30分間に行った作業を要約すると、主にKerbal 
Space Program（KSP）というゲームのチュートリアル
を進めていました。最初にロケットの組み立てと打ち上げ
の基本を学び、その後フライトインストラクターのGene 
Kermanの指導のもと、ロケットの飛行中に高度計、昇降
計、気圧計などの計器を確認し、ロケットの操縦方法を
練習しました。途中、燃料が不足し、パラシュートを展開
して安全に着陸する手順をシミュレーションしました。最
近では、ゲーム内のアイテムを追加し、プレゼンテーショ
ンの準備をしていたようです。また、ブラウザでGoogle 
Chromeを開き、映画「ヒプノシスマイク」の興行収入に
関する情報を調べたりもしました。

どうやっているか

やっていることはすごく簡単で

  1. 2分ごとにアクティブなウィンドウをキャプチャ
  2. 画面をOCRして文字を取り出す
  3. LLMに何をしているかを説明させる
  4. 30分事に3の結果をまとめ、この時間帯にやっていたことを説明させる

これで1日分が20個ぐらいの文章で説明されるようになります。

現状は毎日ざっと読んでいますが、ここからさらに1日のまとめや、一週間のまとめ、 今期のレポートまで作れればと考えています。 また、画面に出ているものだけなので、Github Issue等、 適切により詳細な情報を撮りに行く仕組みも作りたいですが、 実装量が増えたり処理が長くなったりするので慎重に考えています。

なぜこのような作りになったのか

例えば毎日振り返りの時間を確保する、ポモドーロの休憩時間中にやった事をまとめるなど、 自分でアクションをしないと記録が取られない方式は何度も失敗してきました。 そのため、自分は何もしなくても記録が貯まる方法が必要だと考え、以下の要求事項を用意しました。

  1. 自動で最低限のログが貯まる
  2. データにある程度の安全が保証される
  3. 内容を簡単に確認可能
    万が一機密情報が映り込んでいたら消したい
  4. 処理が軽い
    他の作業のじゃまになるのは受け入れられないので、軽量な処理が必要
  5. 1時間遅れ程度で処理が終わる
    読みたいと思ったときに直近の処理が終わってないのは厳しい
    溜まったときに終わるのに1時間以上かかるのはNG
    とはいえ電源接続時のみ動かすので、電源に接続した直後は許容する

何もこちらからアクションせずとも作業がまとめられるように、画面の内容を一定時間ごとにLLMに教え、それをまとめることで達成できると考えました。 このとき、性能的な課題を解決するために、一定時間ごとにOCRした内容をLLMに説明させています。他の手法を選ばなかった理由などは以下で説明していきます。

画面キャプチャを利用している理由

ターミナルのコマンドログやGithubの活動を利用することも考えましたが、個別にいろいろなものを実装していく作業量や、 例えば夜にゲームをやっているときなどはAPIがないので情報が取れないなど、大変さの割にあわないと思い採用しませんでした。

今回採用したアクティブなウィンドウのスクリーンキャプチャであれば全てのアプリケーションで個別実装なく適応可能です。 もちろん詳細な内容を把握することは難しいですが、LLMならなんとかしてくれるのと、 最終的にサマリーにする際に詳細はどうせ消えるので落としても問題ないと判断しています。

その他の疑問

Q. なぜアクティブなウィンドウにし、画面全体をとらないのか

A. 実際にやった所、外部ディスプレイを使った場合に片方のディスプレイがずっと同じ状態になるため、LLMに解釈する際にノイズになりました。 また、外部ディスプレイは大きいため画像サイズも大きくなり後段の処理が詰まるため、キャプチャ頻度を増やせないという課題もありました。

Q. 画面キャプチャではなく作業動画などにしないのか

A. 動画は録画やその後の処理が重いため、今回は候補から外しました。 また、最終的に30分間隔でまとめるため、細かい内容は多少落としても良いと考えてます。

Q. なぜOCRを利用して文字起こしし、それをLLMに説明させているのか

A. セキュリティ・速度・電力消費の理由からOCRにしています。

とにかく自動でスクショを撮るという前提であるため、ECサイトのusername/passwordが偶然入るなどは避けられません。 休日等は14時間ぐらいPCにいたりするので、60 * 14 / 2 = 420枚のキャプチャが生まれますが、 それらをすべて確認して問題ないことを確認するのは本末転倒になります。 そのため、一応学習には利用されないとなってはいますが、OpenAI API等に送信して解釈してもらうのは避けたいと考えました。

この場合、マルチモーダルなLLMをローカルLLMとして利用することも選択肢にはありました。 ただ、実際にmlxやollamaで実際に確認したところ、1枚あたりかなりのマシンパワーを使って50秒程度かかる結果となり、 他の作業を止めてしまう、時間がかかりすぎてしまうという問題が起きたため、採用しませんでした。

OCRをローカルで行う場合、ローカルLLMの画像入力に比べてはるかに軽くて早いことがわかっています。 実際、OCRは一枚あたり5秒、LLMに内容解釈させるのも10秒ぐらいで終了しています。 そのため、こちらの方式を今回は採用しました。

一般的にOCRの場合、文字をどこまで正確に認識できるのかという問題があります。 これに関しては今回は読み取り対象であるキャプチャ画像はほぼすべてがフォントを利用した文字であるため、あまり問題になってはいません。

また、OCRを雑にLLMに放り込んでも大きく間違った結果になる程の出力にはなっておらず、 ローカルLLM自体もそこまで良い結果を返してはいなかったため、説明の精度は気にならないと考えました。

Q. OCRはなぜeasyocrにしたのか

A. メンテに時間を割きたくないため、インストールが容易なものにしたかったためです。 また、前述のように対象はスクリーンショットのためほとんどがフォントを利用した文字ではっきりとしており、 文字の方向も揃っているため、それほど高性能なものは不要なのもあります。

このような理由から、pipで完結するeasyocr とyomitokuのふたつが候補に上がりました。 このうち、テスト用に使っていた画像ではほぼ同じぐらいの結果になったので、精度的には大差ありませんでした。 一方で、yomitokuはその強みであるレイアウト認識を今回は利用しない、 easyocrの場合のほうが基本的に早く、大きい画像の場合はyomitokuだと40秒かかるような場合がある、 商用利用だと勘違いされたときに面倒な問題となる事を避けたいと言った理由から、easyocrで十分と判断しました。 (この辺の実験はrepositoryにまとめています)

おそらく今回はOCRとしてはそこまで問題が難しくなく、かつかなり抽象化した出力にLLMが加工するので、要求水準が低かったのもあります。

Q. OCR後にOpenAI APIやローカルLLMを利用していないのはなぜか

A. 画像をOCRしたとしても、ECサイトのuser/passなどはOCR結果として出てくるため、信頼できるものにのみ投げたいと思ったためです。 ローカルLLMであれば処理可能だが、OCR結果を雑に読み取って意味を理解させるプロンプトが難しく、良い結果が出なかったのもあります。

Q. PLaMo2には1Bモデルがあるが利用していないのはなぜか

A. コードの大部分は正月ぐらいに作ったので、その時期にはまだ出ていなかったため選べませんでした。

Q. なぜLLMにPLaMo APIを利用しているのか、OpenAI APIと同じ理由で避けないのはなぜか

A. 現状においては100%学習などに利用されず安心に利用できることがわかっています。

Q. 本当に安全なのか

A. 「そいつの開発者俺だもん」