の作業記録
ゆっくりする日曜日
- 作業記録の共有
- 週報作成
- 来週の予定確認
- やること管理体制
- やること管理体制
- ブックカタリスト+配信予約
- note+KW記事移動
7:00
おはようございます。本日は来週の予定などを確認し、あとはゆっくり過ごします。アイデアメモの扱いが少しずつ見えてきたので、あとはタスク・プロジェクトまわり、もっといえば「やること」の扱いについてを検討したいですね。
週報作成:
まずは週報の作成から。
2026年第29週（7月20日〜）の私の活動をまとめてください。作業の系統をいくつかの分類で分けてください。その後、一週間の活動のなかで、未解決な活動や疑問、面白そうなアイデアがあれば別途それを取り上げてください。
＊ ＊ ＊
このように作業記録を処理することを念頭におけば、後でやりたいことなどを明示的にマーキングしておけば拾える気がします。ハッシュタグやラベルで、「これは後で考える」みたいに印をつけておき、それをNotebook LMに拾ってもらい、整形して表示してもらう。その上で、別のエージェントに処理してもらう。そういう流れがイメージできますね。
＊ ＊ ＊
信頼できるシステム。それは後から取り出せることが心理的に保証できている状態のこと。
＊ ＊ ＊
来週のSTL確認:
まずはスケジュールから。
＊ ＊ ＊
来週は特に予定はありませんね。原稿に集中できそうです。
続いて、タスク。これが問題です。
＊ ＊ ＊
イメージとしては、やることの全体のDOと、7月ノートの両方を開くイメージでしょうか。
モーダルで呼び出して、右に開く、ができるようになったので、こういうビューは簡単に作れるようになりました。
一応これでやることの全体を整理しつつ、必要なものを月ノートに書き込む、という動作ができるようになりました。
が、今感じているもやもやはもっと大きなレベルでの方法の不在ですね。今日はこれについて考えていきましょう。
とりあえず、次。
＊ ＊ ＊
現状、リストは、jsonにまとめており、それをlist.mdというファイルで一覧できるようにしています。しかし、現状のTextboxはtypeで絞り込むことができるので、それぞれのリストをmdファイルにしてフロントマターを与える形でも構いません。
これをどう考えるか。
たとえば、そのリストを生成AIエージェントでも操作できるようにする、ということを考えた場合、わざわざ検索で絞り込むよりもJSONの方が速いでしょう。ただ、その場合、リストの全体が大きくなったら、消費トークン数も肥大化してしてしまいます。
＊ ＊ ＊
と、ひとまずはこんな感じにしておきましょう。
9:00
やることの管理体制:
現状のTextboxには二系等（notes/, cards/）があり、さらにnotes/にも、mdファイルと、jsonファイルを表示するmdファイル、という二系等がある。「やること」に関するもろもろはそれらにまたがっている。
これをどう扱うようにするか。
Cosense的な考えでは、基本的にすべてをmdファイルにすればいいだろう。しかし、あまりにも細かいものをテキストファイルとして実態をつくるのは何か違う気がする。あと、現状のTextboxだと、中身を見つつ振り返るのが難しい。いちいちファイルを開きたくないものもあるので、jsonでの管理には一定の理はある。
また、書き終えた原稿などはアーカイブ用のdbに入れる計画もある。そうなると、mdファイルに限定する意味もそこまでない。領域が異なれば、別の形もありえる。
たとえば、メモはjsonなどでまとめ、ノートはmd、アーカイブはdbという切り分けも可能。あるいは、その方がいいのかもしれない。
メモはWorkFlowy、ノートはCosense、アーカイブはEvernote、みたいな感じだとかなりそれっぽい。ただしこれらはすべて背後にデータベースを作っているわけで、基本はそれになる。Textboxも、ファイルの実体はテキストファイルだが、インデックスがあってこそ、という面はある。
議題
- タスクリストはネットワーク構造でよいか？
- mdファイルとJSONをどう考えるか。
10:00
note:
KWの記事を移しておきます。
＊ ＊ ＊
OKです。
13:00
ブックカタリスト:
アフターの配信予約を済ませておきます。
＊ ＊ ＊
OKです。
やること管理体制:
たとえば、カード形式でやることを管理するのはどうか。一つ一つをカードにしていく。mdファイルにする必要はなく、すべてをjsonにする。
終了済みのものは消していくので、jsonが肥大化することはない。
仮にそのような管理をする場合、そのJSONはどのような形式になるだろうか。
行為しか扱わないならば、難しいことはない。しかし、作業の記録を残す場合は、jsonが肥大化していくし、かつそれはmdファイルで「ノート」として残したい気持ちもある。
どうすればいいか？
＊ ＊ ＊
仮にごくシンプルなタスク管理ツールを作ったとする。でもって、その中でプロジェクトノートはmdファイルで管理できるようにし、Textboxと共有できるというやりかたはありえる。
あるいはJSONやDBで巨大な情報でも別に気にしないというアプローチもある。というか、巨大になるのがわかっているならば、DBでいい。
つまり、mdファイル群とそのindex、json、DBの三つを一つのビューで閲覧できたらいいわけか。
＊ ＊ ＊
そこまで大掛かりにしなくてもいいかもしれない。
現状は、mdファイルを表示することが前提で、jsonはmdファイル内のJSで処理している。で、book.mdなどはそれでうまくいっている。
＊ ＊ ＊
生成AIのエージェントも、私のタスクを触れるようにする、ということをずっと考えていて、ようやくAPIを作ればいい、という発想に至りました。WorkFlowy、Cosense、LogseqのAPIを触ってきたんだからもっとはやく思いついてもおかしくなかったのですが、「mdファイルを直接読めるんだから読んでもらった方がいいんじゃないの」的に考えていました。
でもそうすると、適切なファイルを見つける為にファイルを読み込む必要があり、トークン数的にあまり美味しくありません。
どういうtypeのノートを手渡せばいいのかは、私が分かっているので、その動作をするコマンドを作っておき、エージェントはそのコマンド使って出力だけ受け取ればいい、という形にすればいいですね。ようはObsidian CLIと同じ方向だ。
それができれば、どんな形で保存しても生成AIはうまく使ってくれるようになるだろう。
＊ ＊ ＊
「やることの一覧」と「大きな展望」をどのように扱うのか。
あと、「タスク管理」よりも土俵が一つ大きい名称が欲しいですね。
＊ ＊ ＊