Logseqで ログ収集 と PKM の両立は可能なのか
こんにちは。
前回のnote記事では、ランダムにノートページを一括表示するプラグインが公開になったことについて書きました。(Multi Random Note)
その後、また新たに 2つプラグインを作ってみました
Draft Notes プラグイン
複数の下書き用ページをまとめて生成・閲覧
Logging Search プラグイン
検索フォームからクエリーの検索結果を表示
これらのプラグインは、仮ページを自動生成することによって成立します。
手動でやると面倒なことを、プラグインがやってくれるという「しくみ化」の発想です。
トヨタ生産方式で言う「自働化」
Draft Notes プラグインは以前から考えていたアイデアです。
数か月前に思いついたものの、プライベート時間の制約で実現できずにいて、年末年始で時間がとれるところでプラグインの製作に打ち込みました。
さらに、そのプラグインを作っていてアイデアとして思いついたのが、もう片方の Logging Search プラグインです。
Logseq の検索機能が弱い
Logseq 標準の検索機能では不便だと思います。改善が必要です。
これが検索画面です。何も検索ワードを入力していない状態です。
ここで裏機能があって、「/」を押すと、次のような画面に切り替わります。
現れたのはフィルター機能です。でも、これは使い勝手にプラスになるレベルではありません。
ほかにも、入力欄で\「 Ctrl/Cmd + Enter 」キーを押すと 、サイドバー内に検索ボックスが移動する裏技が用意されています
(ただし、サイドバーで連続してページを開けないなどのバグがあります)
根本的な問題点として、Logseq の検索機能による検索結果は、マークダウンの生データのままであることが使い勝手を非常に悪くしています。
とくに、何かのワードで探してログを見たいときには、検索機能では役に立ちません。
生データが見たいのではなくて、Linked References のように、ちゃんとレンダリングされた内容を閲覧したいのです。
そして、「これいらないでしょ」と思うのが、コマンドの検索です。
コマンドを探すときもあるかもしれないけど、かなり低頻度のはずです。
個人的な考えですが、統合されていないほうがしっくりくると思います。
実際、アウトライナー系アプリだと、検索ボタンに近いところに、別のコマンドボタンがついているアプリもあります。
個人レベルでこういった問題点を認識していたので、Logseq アプリ開発側に提案とそのコードを提出してたのですが、それが採用されるまでの進捗に見込みがないので今回、プラグインを用意することに決めました。
クエリー機能があるのになぜ使わない？
標準の検索機能が不便だと書きました。だけど実際のところ、Logseq には検索機能以外に、もっと優れた機能があります。
それが、Linked References とクエリー機能です。コンポーネント(処理) に関しては、大半が共通しています。
Linked References は、ハッシュタグやページを開いたときに閲覧でき、それらにリンクされたブロックが表示されるしくみになっています。
Linked References は、[[ページ名]] がキーワードの全文検索に相当します。
Logseq には、Unlinked References も存在します。
こちらは、ページ名 をキーワードにして、全文検索をおこなって抽出されたすべてのブロックが表示されるしくみです
それに対してクエリーは
ページ内のブロックに 「 {{query "検索ワード"}} 」
というような記述をすれば、どのページからも表示が可能です。
簡易的な Live query は、「 / query」 スラッシュコマンドで呼び出します
Advanced query は、「 < query 」で呼び出します
スラッシュコマンドから実行した場合は、フィルターの選択が必要です。
「full text search」が全文検索です。これを選ぶと、そのキーワードの文字列を含んでいるブロックが、クエリーの検索結果として表示されます。
次の画像のように表示されます。一般のブロックと同じようにレンダリングされていて、編集やドラッグ操作が可能です。
ブロックを抽出している都合、若干バグのような動作になることがあります
Logseq だと Linked References は使ったことがあるけど、クエリー機能に関しては使ったことがないよという方も多いはずです。
使う際にクエリー機能に翻訳がなく、そのまま英語で読んでも専門用語に近く、クエリーというのが何なのか、その処理の仕方も理解する必要があるため、使い方がよく分からないという事になるかと思います。当然です。
Linkeed References に相当するクエリーを書くには、
「 {{query [[ページ名]]}} 」
というふうに書きます。
単純なキーワード検索だけでなく「 {{query (or "キーワード1" "キーワード2")}} 」のような条件を指定する記述が可能になっています。
[[ ]] を使う場合は、" " で囲わないようにする
上の画像のように、クエリー機能のほうが圧倒的に優れているので、それなら、検索にはクエリー機能を使いたい。そう考えるに至って。
ユーザーがクエリーを使うにはどんな手順になるかというと
どこか、ページを開く
ページ内のブロックにカーソルを置く
スラッシュコマンドで呼び出してクエリーを設置する
選択肢から条件を指定する
検索結果が表示される
(クエリーが残ったままになっているので、そのブロックを削除する)
これを、この工程をユーザーがやらなくてはいけません。なかなか面倒だと思いませんか。手動では、やりたくないです。
そこで、プラグインの出番です！
左メニューにある 検索フォームに入力する、Enterを押す
メインページあるいはサイドバーに検索結果が表示される
(検索結果ページの内容やクエリーは、プラグインが削除)
というふうに大幅にユーザーの手間を減らすことが可能です。これこそが、プラグイン本来の役割なのではないかと、作っていて強く思いました。
本当は、Logseq がクエリー機能を流用して検索機能を再構築してくれるとありがたいですが。開発チームの中では、Logseq の検索機能が弱いという認識が無さそうな気がします。
そもそも初期のころの開発段階で、検索機能が先に準備されたはずで。
クエリー機能があとに開発されて、そのままアップデートがされていない状況が続いているのかもしれない。
プラグインの名称に込めた思い
Logging Search プラグインと名付けました。
ログをつける、収集するというのは、Logseqの基本コンセプトのひとつに挙げられると思います。
私は 2022年8月ごろから、Logseq を使い始めました。そこから2年以上が経ち、個人レベルで Logseq の使い方に関しては、「デジタルの無限さ」に頼りすぎてしまったなと思っています。
今ではLogseq のグラフが、まるで「街」のような規模になっています。
こうなってしまったら失敗ですｗｗ笑
Graph グラフ ---
Logseq においての ネットワーク (ノートどうしの結びつき) の単位。
ひとりで作り上げたと言っても、これだけのページ数になってしまうと、一人では管理しきれるはずがありません。何個あるのか数えきれません！
Logseqのコンセプトとして、Log収集とgraph構築の両方があるわけなんだけど。
— ＹＵ (@YU000jp) January 2, 2025
ログをつけるためにハッシュタグを使う
それが空ページ化する >>> graphが肥大化する
という、システム的な流れがあって。
自分の場合は、まんまとそれに嵌ったとｗｗ笑
Logseq のもうひとつのコンセプト「グラフ構築」の観点でみると
自分の使い方では両立に失敗したなと思っています。
ログ収集 vs グラフ構築
挽回方法としてはページを減らすしかないですが、ハッシュタグを使った際の空ページがほとんどになっていて。その場合は、タグやリンクを消さないかぎり、Logseq のシステムだと、ページを削除しても復活してしまいます
「今までログをつける際に、どうやっていたか」ということですが、ハッシュタグをつけて、その配下のブロックで、箇条書きで記載していました。
ハッシュタグに関しては、たとえば仕事で部署が替わったときに 最後を「 / 」スラッシュで区切り1か月目、2か月目、という付け方もしました。
それ自体は、レビューする際に、すごく役立ちました。
結果としてハッシュタグを使いすぎて、グラフが肥大化してしまいました。Logseq だとハッシュタグはページと同等であり、空ページが作成されます。しかし、自分の場合は、その多くがログ収集のためのタグだったことに気づきました。
大部分は、LInked References のためにハッシュタグを使っていたのです。
この Logging Search プラグインがあれば、簡潔にクエリーが使えるようになるため、ハッシュタグを抑制できるのではないかと考えています。
結果として、ログ収集とグラフ構築のバランスがとれるのではないかと。
そういう点で、Logseq を使う上で意外と重要なポジションのプラグインが出来上がったかなと自分の中ではそう思っています。
ログ収集 vs グラフ構築
PKM (パーソナルナレッジマネジメント) として、Logseq を使いたいなら、ハッシュタグは抑制したほうが良い。ちょっと考えたらそれが分かったはずなのですが、ジャーナルで #タグ で書き始めたら、そのままタグが使えるシステムだったので、ついハッシュタグを使いすぎてしまった。
それで、そうなってしまったのは仕方ないとして、今後どうするかです。
それが今、悩んでいるところです。Logseq を使い続けるうえで、ハッシュタグの使用を限定させなければいけない。
その方法が思いつかないのであれば、ほかのアプリに移行するしかないのではないかと考え、ノートアプリの探求も始めました。
タグで、ブロックのタイトルをつけるという発想が良くないのでは？
カテゴリ分けのような事はタグでやるべきではないのでは？
考えた中でまだ結論は出ていませんが、あえてハッシュタグ化せずに、文字列のまま残す方法もありなのではないかというのが現状の仮定です。
(手元を増やすよりも、なるべくならアーカイブ化したほうがスッキリする)
PKMとしてグラフを構築していくために、一つのノートを作るときにも、必ずPKMを意識すべきなのかもしれないと考えています。
PKMというのは、デジタルだけど、人間の限界と同じ容量なのではないか、と今は考えています。
Logseq のグラフは、PARA メソッドで言うところの Areas of responsibility (自己責任の範囲) に相当すると考えたほうが良いかもしれません。
ジャーナルはグラフに含まれてはいますが、グラフビューでは除外可能になっているので、ほとんどアーカイブのような扱いです。
仮にLogseq 既存版を使い続けていくとしたら、ハッシュタグの使い方を工夫しないと、論理的に破綻してしまうのではないか。それが懸念点として挙げられます。
結局のところ、Logseq でジャーナルを使いながら、PKMをやろうとするのは難しい気がします。
Logseq db版で PKMは成立するのか
Logseq のグラフ (ページの集合体) をどう構築するのか、ということです。
db版での重要な点としては、ハッシュタグ機能が刷新されて、Class 型という機能性が付与されたことが一番に挙げられます。
おそらく通常通り、意識せずにハッシュタグを使っても大丈夫ですが、Class 型を活用すると、共通項どうしの結びつけがしやすくなります。
Class 型の採用によって、ページとタグは別物になるはずです。
db版の最近アップデートされた仕様では、
左メニューに、タスク Tasks と アセット Assets の項目が追加されました。
現時点の仕様では、標準では隠れているので、Navigations の右側にカーソルを置いて、それらの表示トグルをオンにする必要があります
db版では、次のようなものに関しては自動で Class 型タグ が付与されます
Card
Code
Journal
Math
PDF Annotation
Query
Quote
Task
Whiteboard
など
これらに関しては実質、Capacitiesで言うところの「オブジェクト」とほとんど同じ扱い方です。おそらく今後、Tasks や Assets のように左メニューに追加されるかもしれません。
Logseq db版の開発チームは、主にハッシュタグの共通項整理のために Class 型を採用しました。Class 型は汎用性がかなり高いですが、初期段階でオブジェクト整理を指向したものではなかったです。
「システムでClass 型タグを自動付与する」という機能性が追加されて、結果としてオブジェクト整理が可能になったという経緯があります。
そうなった場合に、ページとそうでないものが分離されるというわけです。
もしかしたらdb版では、ハッシュタグが増えても問題ないのかもしれません
PKMのためのツールとしては Capacites と同等もしくは、機能性で言えば、Class 型の汎用性の高さがプラスになって上回るかもしれません。
今までのLogseq だと区別や整理ができなかったけど、db版では整理方法が用意されるということになります。
ただ残念なことにdb版でも現時点では、検索機能が従来のままでした・・・
それは、Capacities でもそうなんですが、なぜか検索機能がアップデートされずに、ほとんど初期のまま、疎かになっています。
だから、db版でもハッシュタグを使わずにログを閲覧するには、クエリーで検索をしないといけないという状況は変化していません。
※ Logging Search プラグインは、現時点では、db版で使えるようにはなっていません。
db版のWebテストでも、プラグインが実行できるようになりましたが、動作しないため db版マーケットプレースには載っていません。