私は数えてみた。3月の最初の2週間だけで、Get筆記に約200篇のものを保存していた。記事、podcast要約、得到Appのコース筆記、会議録音の逐語録。保存する時は皆「これは後で絶対見る」と思っていた。

そして？その後がない。

Appを開いてみると、全て同じタイムライン上に詰め込まれ、コース筆記と買い物リストが混在し、3週間前に保存したAI Agentアーキテクチャに関する深い記事は、後から保存した20篇の記事に埋もれてどこにあるかわからなくなっていた。

このシーンは必ず馴染みがあるだろう。私の周りの友人も同じ悩みを抱えている：美しいデータベースを構築し、3日間書いた後はもう二度とメンテナンスしない。他のツールを使う人も苦労しており、どのpluginを使うか、tagをどう設計するかで悩むだけで、整理する力を使い切ってしまう。

問題は明確である：収集が難しいのではなく、整理が難しいのだ。そして整理が難しい理由は、我々がそれを「自律」で維持すべき習慣として捉えているからだ。

しかし自律は世界で最も頼りにならないリソースである。

発想を変えて：整理に人の参与が不要だったら？

一人とAIで完成できるエンジニアリング量の体得の一つは：人間が持続的に手動で介入する必要があるフローは、最終的には崩壊するということだ。自律が足りないからではなく、手動フローのメンテナンスコストはデータ量に比例して線形増加するが、我々の注意力は指数的に成長しないからである。

ソフトウェアエンジニアリングにpipelineという概念がある——データがAからBへ、BからCへと流れ、各段階が自動的に次のステップをトリガーし、人が横に立って監視する必要がない。CI/CDはpipeline、ETLはpipeline、家の食洗機も一種のpipelineである：汚れた皿が入り、きれいな皿が出てくる。あなたが横に立って一つずつ洗う必要はない。

知識管理もpipelineにできるだろうか？わからない、まず試してみよう。

4段階：収集 → 同期 → 分類 → 使用

パイプライン全体を分解すると、4つの段階がある。（全体像を見たい方は、このインタラクティブフローチャートを開いてください。）

収集は、スマートフォン端で完了する。Get筆記が私の統一入口である：良い記事を見つけたら保存；podcastで感銘を受けた部分があったら保存；得到Appのコース筆記は自動同期され、別途操作不要；会議録音を投げ込むと、AIが自動で転写と要約を行う。この層のキーポイントは「入口が一つだけ」である。全てGet筆記に入れ、分散させない。

ローカル同期は、Pythonスクリプトに依存する。Get筆記にはOpenAPIがあり、私はsync_notes.pyを書いた。crontabで毎日夜23:00に自動実行するよう設定。新規追加された筆記のみを取得し（増分同期）、Markdown形式に変換してローカルのnotes/フォルダに保存する。毎朝目覚めると、前日に保存したものは既に静かにコンピュータの中に眠っている。

自動分類は、パイプライン全体で最も心血を注いだ部分——そして私が最も自慢に思う部分である。

使用では、分類完了した筆記を直接全文検索でき、Cowork Skillを通じて自然言語で検索することもできる。「あのロブスターに関する記事を探してください」と言うと、APIで検索して結果を取得する。ファイル名を覚える必要もなく、どのフォルダに保存されているかを覚える必要もない。

三層分類エンジン：各筆記が自動的に居場所を見つける

分類エンジンは三層fallbackアーキテクチャで、各筆記は上から下へ処理され、第一層でヒットすれば下へは進まない。

第一層は録音カード検出である。Get筆記の録音筆記には「録音カード筆記」のtagが自動的に付与され、スクリプトがこのtagを検出すると会議録音フォルダに分類する。その中で更にキーワードで8つのプロジェクトサブフォルダに分かれる——SDTIのもの、CircleFlowのもの、投資家会議のもの、それぞれが定位置に収まる。

第二層はコースシリーズ検出で、これが私の最も満足いく設計である。得到Appのコース記事のURLにはcourseArticleIdパラメータが隠されている。同じコースの全記事は同じcourseArticleIdを共有する。私のスクリプトはこのIDを解析し、_course_registry.jsonという動的登録ファイルと照合する。

このregistryの巧妙な点は：自動拡張することである。スクリプトが今まで見たことのないcourseArticleIdに遭遇しても、そこで困惑することなく、自動的に新しいフォルダを作成し、このコースをregistryに登録してからアーカイブを開始する。次に同じコースの他の記事に遭遇すると、どこに送るべきかがわかる。

私は新しいコースを開始するたびにプログラムコードを変更する必要がない。システムが自ら新しいコースを認識する。

第三層はキーワード分類で、最も素朴だが最も安定したセーフティネット戦略である。スクリプトは筆記のタイトルと内容の最初の300文字をスキャンし、キーワードライブラリと照合して、対応するテーマフォルダに分類する：AIと科学技術、医療健康、投資理財、個人成長、生活雑記…。どのカテゴリにも分類されないものは「その他」に入り、少なくとも虚空に消失することはない。

三層の優先順位は重要である：録音カードは最も確実（明確なtagがある）、コースシリーズは次に確実（構造化IDがある）、キーワードは曖昧マッチングだが範囲が最も広い。各筆記には必ず居場所がある。

なぜ手動タグを使わないのか？

パイプライン構築の過程で、手動でタグを作成することを繰り返し試した。結論：うまくいかない。

技術的にうまくいかないのではなく、人間性の面でうまくいかない。記事を保存する時に頭にあるのは「これは有用だ」であって、「これはどのタグ体系の第何層に帰属すべきか」ではない。ユーザーに収集の時点で分類決定を求めることも、認知リソースを消費する作業である。

第二の問題は、タグが漂流することである。1月に設定したタグ体系は、3月になると適切でなくなるが、前の2ヶ月の数百篇の筆記を振り返って再タグ付けすることは不可能である。タグシステムのメンテナンスコストは内容量に比例し、しかも遡及的である——ルールを一度変更すると、すべての履歴データを再処理する必要がある。

自動分類の利点は：ルールが変わっても、スクリプトを一度再実行するだけで良いことである。100篇でも1万篇でもコストは同じである。

「整理」から「取得」へ

パイプラインが完成した後、私の作業方式を変えたのは「整理」が速くなっただけでなく、「取得」もより使いやすくなったことである。私はClaudeのウィンドウで直接データを呼び出し、必要な内容を出力できる。

以前は保存したものは保存しなかったも同然だった。検索が不便だったからである。今は私はCoworkで直接「最近循環経済に関する記事を保存したことがあるか」と言うことができ、SkillがAPIで検索して該当する筆記をリストアップし、要約も付けてくれる。「万維鋼のあのコースがどこまで進んだか見て」と言うと、_series_meta.jsonの進捗インデックスを読んでくれる。

知識管理の目標は「うまく保存する」ことではなく、「使えること」である。パイプラインが解決するのは整理の問題だけでなく、収集と使用の間にある溝を埋めることである。

これは私がpaulkuo.twでAI-Ready継続最適化で行った論理と同じである：人にシステムに適応させるのではなく、システムを人に適応させる。ウェブサイトの最適化は自動ループに任せ、知識整理は自動パイプラインに任せる。人の精力は本当に判断力が必要なことに残しておく。

一つのパイプライン、一つの態度

振り返ってみると、このパイプラインは技術的には実は複雑ではない。Pythonスクリプト一つ、crontabスケジュール一つ、JSONレジストリ一つ、Cowork Skill一つ。機械学習もなく、ベクターデータベースもなく、高度なNLPもない。

しかし、私を悩ませていた問題を解決した。

以前知識管理の記事を読むたびに、その「第二の脳を構築する」という論理に魅力を感じ、週末を使ってNotionテンプレートを構築し、tag体系を設計し、使用ガイドラインを書いて——そして2週間後には元の状態に戻っていた。ツールが悪いのではなく、その方法が本質的に人間性と賭けをしているからである：毎日手動で整理する力があることに賭けている。しかし私は毎日十分な集中力を持てるとは限らない。

パイプライン思考は人間性と賭けない。それが賭けるのはAPIの安定性、cronの時間厳守、プログラムロジックの正確性である。この三つの信頼性は、どんな人の自律よりも高い。

もしあなたも知識管理で悩んでいるなら、私の提案はより良いAppやより美しいテンプレートを探すことではない。AIと協働し、従来のSOPを手放し、自分に一つの質問をすることである：フローの中で、実は私を必要としないステップはどれか？委託できるものはどれか？自分を必要としないステップをパイプラインとAIに任せる。「読書、思考、連結、創造」を自分に残しておく。

それが知識管理のあるべき姿だと思う。もちろん、これは私個人のバージョンであり、あなたは自分のものを発展させることができる。

パイプライン出力例

  • AIロブスター十日物語 — 得到App共同創業者・快刀青衣による10日間のライブ対談を、ナレッジパイプラインで同期・AI構造化整理した総覧ページ。