2026-08-23の作業記録

ゆっくり過ごす日曜日

作業記録の共有
週報作成
来週のSTL確認
アイデアノート点検
note+記事移転

8:00

おはようございます。本日は来週の予定を確認して、残りはゆっくり過ごします。

朝ノート:

今日も朝ノートです。

週報作成:

まずは一週間の作業記録の振り返りを。

2026年第33週（8月17日〜）の私の活動をまとめてください。作業の系統をいくつかの分類で分けてください。その後、一週間の活動のなかで、未解決な活動や、面白そうなアイデアがあれば別途それを取り上げてください。「これについて後で考える」のような文言があればそれも注意深く拾ってください。

＊　＊　＊

現状はTextboxに入れていますが、別にここでなくてもいいんじゃね、という気になってきました。一度書いたら書き直すことはまずないですし、後から読み返す可能性も低いです。

ここで検討すべきなのは、Cosenseの運用のように特に区別なく保存し、リンクベース、あるいは自作インデックスベースで区分けを行う方向か、粒度ごと役割ごとにフォルダを分けるのか、ということ。

で、実体のファイルを使う場合は、フォルダで分けないとかなり扱いにくい、という問題があります。「情報」を扱うには区別がなくていいのですが、「ファイル」を扱うには区別があった方がいい。このねじれが検討すべき第一の問題。

第二の問題は、混ぜておくことの弊害はあるのか、ということ。メリットはなくても弊害がないなら別に混ぜておいてもいいのですが、メリットがなく弊害があるならば、やめた方がいいでしょう。

10:00

フローを考える:

たとえば、昨日『自己啓発本を1000冊読んでわかったこと』を読み終えました。その後、じゃあどう処理をするのかというフローから検討します。

まず、基本的に蔵書を管理しているlibrary.jsonおよびdbの更新です。最終的にdbに統一したいのですが、不具合が生じることも考えて、現状は両方更新しています。忘れやすいので書いておくと、cards/にある方が、dbで、notes/にあるのがjsonです。

それを開いて、読了日の情報を更新する、というのがこのステップ。

次に、2026年の読書日記.mdに追記する。

正直こちらにも手書きするというのは二度手間だし、忘れることも多い。しかし、先ほどのは蔵書リストの更新であり図書館で借りた本は含まれていない。言い換えれば蔵書リストの読了ログだけでは拾い切れない情報がある。そのため、こちらでも総合的に記録を残すようにしている。

ただし、蔵書リストを更新したら、自動的にこちらに追記するというアルゴリズムがつくれないわけではない。蔵書はそれで自動的に更新し、図書館の本は手書きする、という区分けができたら、もう少し単純にはなるだろう。

あるいは、ぜんぜん違う仕組みを考えることもできなくはない。「知的活動ログ」のように読書以外の何かも含めること、あるいは月別ノートに書き込んでいくこと、といったこと。

＊　＊　＊

その上で、具体的な個別ノートを作る。

Cosenseならば話は早い。

『自己啓発本を1000冊読んでわかったこと (インターナショナル新書)』 - 倉下忠憲の発想工房

こうして登録すれば、書籍名のinfoboxで一覧が作れるし、月ノートとのリンクもあり、著者の他のノートともつながる。ほぼこれで問題ないだろう。

あとは、ここに読了のメモなどを書き込んでいけばいい。

＊　＊　＊

WorkFlowyの場合はどうだろうか。少しだけ話がややこしくなる。

まず、デイリーに読了をつける。

必要なのは個別ページである。ここで問題が生じる。個別ページをデイリーの中に作るのか、外に作るのか。外につくるのが一般的のように思えるが、別にデイリーに起きっぱなしでも構わないというのがWorkFLowyの強みである。ハッシュタグやアットマークを付けてさえおけば、どこにあっても抽出は可能である。むしろ、デイリーにおいておけば上位構造をわざわざ作るまでもない。

では、別につくる場合はどうなるか。

おそらくはこういう形になり、Notesなりなんなりにページを作ることになる。そうするとデイリーに存在するのは、Notes化のページへのリンクだけになって、本体はNotesになる。

これは読書ノートにあたるから、そこに配置しておく。

以降、デイリーでこの本に言及するときは、この項目のリンクを貼ることになる。

同じ操作はデイリー内にこの項目を置いていても可能である。booksのハッシュタグを付けておけば、一覧を作るのも容易い。だったらデイリーに置いておく手もあるだろう。

もう一つ考えたいのは、読書ノートなどを追記するときに、この項目の直下に書き込むのは、デイリー内でこの項目へのリンクを作り、その子項目として書くのか、というところ。

デイリーに書名を書き込む形もあるし、書名項目に日々のリンクを書き込む形もある。どちらも可能なのが、WorkFlowyの柔軟性だが一意に定めにくい。

「やったことはデイリーに書く」というスタイルならば、デイリー内に書名へのリンクをはるのが適切だろう。しかしその場合、バックリンクが見えないと見えなくなる。たとえば、WorkFLowyのAPIを叩いて、項目の中身を取得した場合、バックリンクの中身は含まれないことになる。それが良い場合もあるだろうし、そうでない場合もあるだろう。

調べてみたところ、やはりAPI経由では項目のバックリンクは得られない。もちろん、すべてを検索して、リンクを含むものを抽出するという手順を踏めば取得できるわけだが、なかなかの仕事になる（スクリプト化しておけば、少しマシだろう。リンクの形は常に一定で、idだけが異なるのでアルゴリズム化は容易）。

とりあえず、MCPを直線的に扱っただけでは、WorkFLowyでのバックリンクは出てこない。となると、項目に含めておくのが適切な用には思われる。あるいは、その項目に含めるのは書誌情報に限定し、自分が何を考えたのかはあえてデイリーに分けることで、生成AIのコンテキスト把握を補助するという考え方はあるだろう。

というところで、悩むポイントが出てくるのがWorkFLowy（あるいはLogseq）の難しいところだ。

＊　＊　＊

Textboxの場合、書誌情報のdbがあり、個別ノートがmdでも作れるという点がさらにややこしさを増す。書誌情報のdbにもメモ欄はあるが、そこに書いてしまうと、他のmdとのリンクは失われてしまう。

Cosenseは便利だが、蔵書一覧においてさまざまパラメータでソートを変える、ということはできない。dbならそれは容易。よって、用途が異なると考えるのがよく、むしろそれを混ぜない設計が良いだろうとは思う。

だとしたら、Textboxでも蔵書管理用のdbと、個別の読書ノート用のmdは基本的に別物として扱うのがよいだろうか。Obsidianのbasesの考え方を拝借すれば、mdファイルからデータベース用のindexを作ることはできるし、Textboxでもその仕組みになっている。ということは、せっせとmdファイルを作って、index.jsonをbasesのように利用すれば、似たことはできる。だったら、dbは不要かというと、そうも言い切れないのが微妙な具合である。

いったん、ここまでにして作業に戻る。