#captio

[hermitmoss]

[id: a digital painting of halt and crowley from ranger’s apprentice, set several years before the main series. halt has warm brown skin and short wavy black hair, and crowley has warm pale skin and light orange hair in a ponytail. they are kissing, and crowley is holding halt’s oakleaf necklace. halt is running a hand through crowley’s hair, and the background is a pale blue sky with clouds. ed id]

[obsidian-simple-memo]

一行を送るためだけの道具が、十四年間そこにあった

消えたアプリを振り返るとき、話はたいてい機能の一覧か、別れの感傷のどちらかに落ちる。今日書き残したいのは、そのどちらでもない。ひとつの小さな設計思想が、十四年という時間をかけて静かに証明してみせたことについてだ。結論を先に置いておく。よく設計された道具は、機能の多さではなく、削り切った潔さのほうで生き延びる。この一点を、Captioという名前の道具ほど分かりやすく体現したものを、自分は他に知らない。

2011年、一行を送るだけの道具として現れた

オランダの小さな開発元Tupilと、Ben Lenartsという一人の作り手。彼らが世に出した「Captio」は、海外の個人ブログで2011年の春にはもう紹介されていた。やることはひとつしかない。開く。打つ。送る。それだけだ。書いた一行は、その場で自分のメールアドレスへ飛んでいく。フォルダもタグもカテゴリも、整理のための棚は何ひとつ用意されていない。他アプリの共有シートからも、テキストやリンク、写真をそのまま自分宛てに投げられた。価格は数百円の買い切り。一度払えば、あとは黙って動き続ける。当時の画面写真を見返すと、そこには入力欄と送信ボタンしかない。潔いというより、いっそ何もなさすぎて最初は不安になるほどの引き算だった。自分宛てにメールを送るという行為自体は、スマートフォン以前からある古い習慣だ。Captioはそれを発明したのではなく、そこから摩擦だけをきれいに削り取ってみせた。

そもそも「最小ハブ設計」とは、何を捨てた設計なのか

Captioの本質は、メモアプリではなかった。むしろ、自分では何も抱え込まないことを選んだ道具だ。書いたものをアプリの内側に保存しない。データベースも、同期の仕組みも、バックアップ画面も持たない。ただ、思いついた瞬間と、保存する先とを、最小の操作で一本の線につなぐ。これを仮に最小ハブ設計と呼んでおく。定義はこうだ——入力の瞬間を、すでに世界中で同期されている既存の器へ、余計な寄り道なしに受け渡すだけの設計。その器に、Captioはメールを選んだ。なぜメールだったのか。答えは拍子抜けするほど単純で、メールはどの端末にも最初から入っていて、どのメモアプリより長生きするからだ。新しいメモアプリは毎年のように生まれては消える。だが受信箱は、二十年前に届いた一通が今日でもそのまま開く。自分の中に抱え込まない設計は、抱え込む設計より、たいてい長く残る。ここがCaptioという道具の、いちばん静かな賭けだった。

抱え込むアプリと、通り抜けさせるアプリ

この十数年、メモやノートのアプリの主流は、はっきり逆の方向へ進んだ。EvernoteもNotionも、思想は「すべてをここに集めよう」だ。中に入って暮らすための、広くて機能豊かな部屋を用意する。それはそれで一つの正解で、実際に自分も長く住んだ。だが部屋は、住み込むほど出入りが重くなる。起動し、目的のノートを探し、階層をたどる。その数秒のあいだに、捕まえたかった一行は半分ほど輪郭を失っている。Captioの立ち位置はまるで逆だった。中に住まわせない。通り抜けさせるだけ。玄関と裏口しかない廊下のような道具で、入ってきた思いつきは立ち止まる間もなく受信箱へ抜けていく。抱え込むアプリは記憶の宮殿を目指し、通り抜けさせるアプリはただの土管に徹する。どちらが偉いという話ではない。ただ、思いつきを取りこぼさないという一点においては、土管のほうが速く、そして壊れにくかった。

なぜ十四年ものあいだ、それは手放されなかったのか

Captioを深く愛したのは、GTDを実践する人たちや、取材メモを絶やさない書き手たちだった。惹きつけたのは速さそのものではない。正確には、速さが生む「今は考えなくていい」という感覚のほうだ。ホーム画面のアイコンに親指を伸ばし、浮かんだ一行を打ち、送る。この数秒のあいだ、どのフォルダに入れるかも、あとでどう整理するかも、一切考えない。捕まえること（収集）と、片づけること（処理）を、Captioはきっぱり別の作業として切り分けていた。これはGTDが最初に説く原則そのものだ。収集の瞬間に分類まで背負わせると、人は書くこと自体をためらうようになる。開発者が公開したお別れの文章には、App Storeから姿を消したあとの最後の一年でさえ、二百三十万通を超えるメモがこのアプリを通って送られた、と書かれている。もう新規には手に入らなくなってなお、それだけの数の一行が、世界のどこかで毎日投げ込まれ続けていた。短い言葉で考える癖が広まっていった時代に、Captioはその短い衝動を、公開の場ではなく自分だけの受信箱へそっと流し込む道具だった。同じ「短く書く」でも、向ける先が外か内かで、道具の性格はまるで変わる。

2024年10月、その受信箱行きの線は静かに切れた

終わりは、少しも派手ではなかった。二〇二四年十月一日、Captioの裏側のサーバーが停止した。十四年動き続けた線が、一本、そっと外れただけだ。App Storeからはその二年ほど前に既に姿を消していて、残った利用者のためだけに裏方が保たれていた。作り手は「これ以上、安定性とセキュリティに必要な労力を割き続けられなくなった」と正直に書き、そのうえで、これほど単純な道具が自分の歩みに大きな意味を持ったことへの感謝を綴っている。止まった本当の理由は、公式には語られていない。ただ広く推し量られているのは、送信の裏側が外部のメール基盤に深く寄りかかっていたことと、一度きりの買い切りでは、動かし続ける費用を長く賄えなかったことだ。皮肉な話ではある。何も抱え込まないという設計思想そのものは正しかったのに、その一本の線を張り続ける商いの側が先に力尽きた。設計は正しく、勘定が合わなかった。外部の基盤に一点で依存していたことが、結果として単一の急所になった。サーバーが止まったあと、「captio 代替」と検索窓に打ち込んだ人が、この二年でどれほど増えたことか。愛用していた人ほど、同じ手触りの代わりを一本、静かに探していた。同じわだちを踏まないように、その設計を独立した土台で組み直そうとした記録は、別のところに置いてある。それが不意に使えなくなった日の、残された側の心細さについては、以前ここに書いた。

遺された思想を、いま自分はどう受け継ぐのか

道具は消えても、設計思想のほうは残る。Captioが十四年かけて実演したのは、「捕まえる場所」は軽ければ軽いほどいい、という一点に尽きる。自分でメモの道具を手を動かして作るようになってから、この教えは日ごとに重みを増している。機能を足したくなる誘惑は、毎朝のようにやってくる。タグを付けたい、フォルダで仕分けたい、あとで見返す一覧画面が欲しい。そのたびに思い出す。Captioは、それを全部やらなかったからこそ十四年生きた、と。何かを抱え込んだ瞬間から、道具は少しずつ重くなり、重くなった道具は、いつか自分自身の重さで沈んでいく。足し算は誰にでもできる。機能を一つ増やせば、そのぶん確実に売り文句は増える。だが引き算は、何を残せば道具がまだ道具でいられるのか、その境目を見極める作業だ。だからずっと難しい。Captioが十四年間そこにあり続けたのは、その難しいほうを、最初から最後まで手放さなかったからだと思う。

よくある質問

Captioとは何だったのか。開いて一行打って送れば、それがそのまま自分のメールに届く、それだけのiOSアプリだ。メモを内部に貯め込まず、メールという既存の器へ渡すことに徹していた。オランダのTupilが手がけ、十四年動いて二〇二四年に静かに幕を下ろした。

最小ハブ設計の要点はどこにあるのか。アプリ自身が何も抱え込まないことだ。入力の瞬間を、すでに同期されている長寿命の保存先へ、最小の手数でつなぐ。器のほうが長生きなら、道具が消えても記録は手元に残る。

なぜ保存先がメールでなければならなかったのか。どの端末にも最初から入っていて、特定のアプリより確実に長く生き延びるからだ。二十年前の受信箱が今も開くという事実が、その地味な選択をいちばんよく裏づけている。

飛行士でもあった作家サン＝テグジュペリは、道具について論じた章で、こう記した。「完璧とは、付け加えるものがなくなった時ではなく、取り去るものがなくなった時に達成される」。Captioという小さな道具は、その一文を、十四年かけて静かに実演してみせたのだと思う。

[obsidian-simple-memo]

この記事を書いている間も、メモは別の場所に溜まっていた

この記事の下書きは、数週間かけて溜まった走り書きを拾い直すところから始まった。信号待ちで打った五文字。電車で浮かんだ反論。夜中に一行だけ残した引用のメモ。それらを一箇所に集めて並べ替える作業をしていて、途中で手が止まった。集める作業と、書く作業では、明らかに違う頭を使っている。

先に結論を書いておく。メモが続かない原因の多くは、道具の性能ではなく、「捕まえる」と「育てる」を同じ画面でやろうとしていることにある。この二つは要求が正反対だ。片方に必要なのは無思考の速さで、もう片方に必要なのは腰を据えた判断になる。同じ場所に押し込むと、速い側が遅い側に引きずられて鈍る。

用語を先に決めておく。捕まえる場所とは、思いついた内容を評価せずに投げ込むための一時的な受け口を指す。育てる場所とは、投げ込まれたものを後から読み返し、選び、つなぎ直すための常設の保管庫を指す。前者に求められるのは速度と摩擦のなさ、後者に求められるのは検索性と持続性で、この二つは同じ設計指針からは出てこない。

自分の手元では、捕獲側がiPhone、育成側がObsidianの保管庫という配置に落ち着いている。受け渡しの具体的な挙動については、保管庫のノートへ時刻付きで一行ずつ並ぶまでに整理してあるので、ここでは繰り返さない。この記事で考えたいのはもっと手前の話だ。なぜ場所を分けると楽になるのか。三つの角度から見ていく。

なぜ、作業の切り替えは「移動」ではなく「残留」なのか

作業を切り替えるコストを、多くの人は移動時間のように捉えている。Aを終えてBに移る、その乗り換えに数秒かかる、という理解だ。しかし認知の側から見ると、実態は移動ではなく残留に近い。

Sophie Leroyが2009年に Organizational Behavior and Human Decision Processes 誌（109巻2号、168–181頁）で提示した「アテンション・レジデュー（注意の残留）」という概念がある。人がタスクAからタスクBへ切り替えたとき、Aに関する認知活動の一部が頭に残り続け、Bに使えるはずの資源を削る。Leroyの実験で効果が強く出たのは、Aが時間に追われていた場合と、Aが終わっていない場合だった。中途半端に切り上げたものほど、しつこく残る。

この知見をメモの現場に置き換えると、順番が逆になっているのが見えてくる。整理機能のついたメモアプリを開き、フォルダを選び、タグを付け、既存のメモとの重複を確認する。その一連の判断は、頭の中でまだ形になりきっていない「書こうとしていたこと」を中断させる。中断されたそれは消えるのではなく、残留物として居座る。整理の判断をしているあいだ、思考は前の話題に半分ひっかかったままになる。

規模の感覚として、もう一つ役に立つ数字がある。Gloria Mark（カリフォルニア大学アーバイン校）が2004年に行った職場の観察研究では、中断された作業の81.9パーセントは同じ日のうちに再開されるものの、再開までに平均23分15秒かかっていた。しかも人は中断された直後に元の作業へ戻るわけではなく、平均して二つ別のタスクを挟んでから帰ってくる。Markが2023年の著書『Attention Span』で示した追跡調査では、一つの画面に留まる時間の平均が2004年の約2分30秒から47秒まで縮んでいる。

注意しておきたいのは、これらの研究がそのままメモアプリの操作に当てはまるわけではない、という点だ。Leroyの実験は職場のタスク切り替えを対象にしているし、Markの23分15秒は複雑な業務の再開に要した時間で、買い物リストに一行足す程度の作業には効かない。数字を借りてきて「だから分けるべきだ」と押し切るのは乱暴だと思う。

それでも一つ、確かなことがある。捕まえる瞬間に判断を求める設計は、判断のコストだけでなく、判断が終わったあとの残留まで請求してくるということだ。フォルダを選ぶのに要する時間は0.5秒かもしれない。だが選び終わったあとに元の思考へ戻る速度は、その0.5秒とは無関係に決まる。

分けるという設計は、この請求書を捕獲の側から取り除く。何も選ばせない。宛先も分類も既定値にして、入力欄に打ち込んで送る以外の操作を用意しない。判断はすべて後回しにされ、育てる側でまとめて処理される。まとめて処理するほうが安く済むのは、切り替えの回数そのものが減るからだ。一日に三十回の小さな判断を、週に一度の大きな判断へ畳む。

ただし、畳んだ先で請求書が消えるわけではない。週に一度そこを開いたとき、三十件の未処理の断片が並んでいる状態は、それ自体がそれなりの負荷になる。分業は判断の総量を減らす手法ではなく、判断が発生する場所を移す手法だ。移した先で処理が滞れば、負債はそちらに積み上がる。この点を無視して「捕獲だけ速くすれば万事解決する」と書いてある文章は、たぶん後半を書いていない。

分業はLuhmannから受け継いだものではない

「捕まえる」と「育てる」を分ける発想は、ナレッジマネジメントの文脈では Niklas Luhmann のツェッテルカステン（カード式の索引箱）に起源があるものとして語られることが多い。走り書きを取り、あとから恒久的なカードに書き直して箱に納める。その二段階の手続きこそが、あの生産量の秘密だった、という筋書きだ。

この筋書きは、記録に照らすとかなり怪しい。

Luhmannが索引カードを溜めはじめたのは1951年ごろで、1997年に亡くなるまで続いた。箱は二つある。第一の箱は1951年から1962年まで、法学と行政学が中心。第二の箱は1963年以降で、社会学とシステム理論が中心になる。ここで肝心なのは、この二つが「捕獲用」と「育成用」の分業ではないという点だ。時期と主題によって分かれた、逐次的な二代目にすぎない。

枚数についても、通説と記録には差がある。一般には「約9万枚」と紹介されることが多いが、ビーレフェルト大学のアーカイブがカタログ化した数は、第一の箱が22,079枚、第二の箱が51,636枚、合わせて73,715枚だ。9万という数字がどこから来たのかは出典によって揺れがあり、どちらかが単純な誤りだと断じられる話でもない。ただ、少なくとも「9万枚」を検証済みの事実のように扱うのは慎重であるべきだと思う。

そして肝心の二段階についてだ。「fleeting note（走り書き）／literature note（文献ノート）／permanent note（恒久ノート）」という三分類は、Luhmann自身の用語ではない。この整理を体系化したのは、2017年の Sönke Ahrens『How to Take Smart Notes』である。Luhmannが一時的な書きつけをしていた可能性は高いが、遺された紙束の中でそれが独立した種類として制度化されていた形跡は薄い。つまり現代のPKM界隈が「古典の作法」として引用しているものの相当部分は、2017年に整えられた現代的な再構成だ。

これを知って落胆する必要はない。むしろ面白いのはここからで、権威ある起源がないにもかかわらず、同じ形が何度も再発明されているという事実のほうだ。GTDの収集フェーズ。メールの受信箱。Ahrensのfleeting note。そして手元のメモアプリの送信ボタン。誰かが正解として配ったのではなく、別々の人間が別々の場所で同じ壁にぶつかり、同じ形に行き着いている。権威に支えられた作法よりも、こちらのほうがよほど強い証拠だと思う。

では、Luhmann自身は自分の箱を何だと考えていたのか。1981年の論考「Kommunikation mit Zettelkästen（ツェッテルカステンとのコミュニケーション）」で、彼はあの箱を保管場所ではなく、コミュニケーションの相手として説明している。自分とは少しずれた関心を持ち、こちらが思ってもみなかった問いを返してくる相棒。箱の価値は、入れたものが無事に残っていることではなく、入れた覚えのない組み合わせがそこから出てくることのほうにある、という捉え方だ。

この一点は、現代の分業論から抜け落ちやすい。育てる場所を「捕まえたものの保管先」として設計すると、保管はできるが会話が起きない。実際、整然と分類された保管庫ほど二度と開かれない、という現象は多くの人が経験している。あとから自分を驚かせる可能性を残すには、分類の解像度をむしろ粗くしておいたほうがいい場合がある。ここは分業の設計とは別の、もう一段深い話になる。

同時に、起源が神話なら、忠実に再現する義務もない。Luhmannの番号体系を真似る必要はないし、三分類のうち文献ノートを省いても罰は当たらない。分業は原理であって儀式ではない。守るべきなのは「捕獲時に判断させない」という一点だけで、そこから先の形は各自の作業量に合わせて削ってよい。

では、二つの場所の線はどこに引くのか

判断基準を一つに絞るなら、そのとき判断させるかどうか、になる。

・捕獲側に置いてよいのは、内容の入力と送信だけ。宛先も分類も既定値で固定する。

・育成側に回すのは、分類・統合・削除・参照付け。読み返しを伴う操作はすべてこちら。

自分の運用はこうだ。捕獲側は一画面・一操作で、送信すると手元には何も残らない。育成側はプレーンテキストのファイル群で、日付ごとのノートに「- HH:mm 本文」の形で一行ずつ積まれていく。追記はバックグラウンドで行われるので、育てるとき以外はObsidianを開かない。開かなくても溜まっている、というのが分業の肝心なところで、ここが手動だと数日で破綻する。

なぜ育成側がプレーンテキストなのか。育てる場所は十年単位で持たないと意味がないからだ。Obsidianが2020年に公開されたとき、多くの人が最初に評価したのは機能の豊富さではなく、ローカルのMarkdownファイルをそのまま読み書きするという一点だった。育てる場所に必要な条件は、道具が消えても中身が残ることに尽きる。捕獲側の道具は乗り換えてよい。育成側の形式は乗り換えられない。

「obsidian デイリーノート 追記」のような語で検索した記録が手元に残っているが、当時ほしかったのは自動化の手順そのものではなかった。日付ごとのノートへ機械的に足していく運用が、半年後に破綻しないのかどうかを確かめたかった。

ここまで書いておいて言うのも妙だが、分けないほうがいい場合もある。

一つ、一日に生まれる断片が数件しかないなら、分業のオーバーヘッドのほうが高くつく。受け渡しを整える時間で、一つのアプリの中で片づけたほうが早い。

二つ、メモが即座に行動へ変わる種類のもの――買い物、連絡、その日のうちに済む用事――なら、育てる工程そのものが要らない。捕獲して消費すれば完結する。

三つ、場所を分けると「見に行かない場所」が生まれる危険がある。これが最大の落とし穴だ。

三番目は自分にも起きた。育成側を開かない期間が続いたことがあり、そのあいだ捕獲側だけが機嫌よく膨らんでいた。分業は成立していたが、何も育ってはいなかった。置き場所が二つに増えただけだ。受信箱ひとつで暮らす人たちを観察した回でも触れたが、場所を増やすこと自体には何の価値もない。

なぜ開かなくなるのかを考えると、義務感で運用していたからだと思う。溜まったものを処理しなければならない場所として扱っている限り、開く行為は作業であって、作業は後回しにされる。逆に、開くと何か思わぬものが見つかる場所として機能していれば、頻度は勝手に上がる。Luhmannが相棒と呼んだのは、そういう状態の箱のことだったはずだ。仕組みで自動化できるのは受け渡しまでで、その先を相棒にできるかどうかは、置き方と粗さの問題になる。

もう一つ、受け渡しには必ず欠落がある。捕獲側で書いた一行は、書いた瞬間の文脈を持っていない。どこで、何を読んでいて、何に反応して書いたのか。時刻だけは自動で付くが、それ以外は落ちる。落ちた分を後から補えるかどうかが、育てる側で実際に効いてくる。自分は補えないことのほうが多いと分かってきたので、最近は捕獲時に一語だけ、文脈になる語を足すようにしている。それ以上は速さと引き換えになる。

だから分業の成否は、二点でほぼ決まる。受け渡しが自動かどうか。育成側を開く習慣があるかどうか。前者は仕組みで解決できる。後者は解決できない。仕組みで解決できないほうが本体だという事実は、道具を作る側にとってかなり居心地が悪い。

よくある質問

捕まえる場所と育てる場所は、必ず別のアプリでなければいけないのか。

別アプリである必要はない。条件は「捕獲時に判断を求められないこと」と「育成側が後から検索・編集できること」の二つで、同じアプリの中に十分に分離された二つのモードがあるなら、それでも成立する。ただ、一つのアプリで両方を満たそうとすると捕獲側の画面が重くなりやすい、という傾向はある。

捕まえたメモは、どのくらいの頻度で育てる側に見に行けばよいのか。

決まった正解はない。自分の場合は週に一度で足りている。頻度そのものより、見に行かない期間があっても捕獲が止まらない構造になっていることのほうが重要だ。育成のリズムが崩れた瞬間に捕獲まで止まる設計だと、立て直しに時間がかかる。

走り書きをそのまま残しておくと、あとで意味が分からなくならないか。

なる。半分近くは読み返しても再現できない。ただしそれは分業の副作用ではなく走り書きの性質で、一箇所にまとめて書いていても同じことが起きる。捕まえる時点で主語を一つだけ入れておくと再現率が上がる、という程度の対策しか自分は見つけられていない。

分業の話をすると、次の質問がほぼ必ず来る。育てる側の入口は、日付ごとのノートと、固定した一つのノートと、どちらに置くべきか。好みの問題に見えて、実際には振り返りの単位をどこに取るかという設計判断で、自分も何度か乗り換えている。次回はその選択について書きたい。

[obsidian-simple-memo]

『車輪の再発明はするな』に、素直には頷けない

「車輪の再発明はするな」。プログラミングを学ぶと、たいてい最初のほうで刷り込まれる格言だ。この助言に、自分はこの三年、意図的に従ってこなかった。とはいえ、全面的に逆らってきたわけでもない。チームで期日に追われて作るなら、出来合いのライブラリを使うほうがいい。そこは疑う余地がない。話が反転するのは、一人で作る小さな道具を、十年単位で生かし続けたいときだ。ここでいう「依存ゼロ」とは、Appleが配る標準フレームワーク以外の外部ライブラリを、プロジェクトに一つも入れないという方針を指す。個人でメモの道具を作りながらこの面倒な縛りを続けてみて、見えてきたことを書いておく。念のため断っておくと、これは武勇伝ではない。損も得もある選択の、損のほうまで含めた記録だ。

「車輪の再発明はするな」が正しい場面は、確かに多い

逆張りを始める前に、公平な話をしておきたい。既存のライブラリに頼る理由は、いくらでも挙がる。期日がある。複数人で同じコードを触る。扱う領域が複雑すぎて、自前で書けばどこかで必ず間違える。とりわけ暗号やネットワークのように、失敗が即事故へ直結する領域を、思いつきで自作するのは無謀というほかない。「車輪の再発明はするな」という古い格言は、この現実を的確に突いている。現に、世に出ているプロダクトの大半は、無数のライブラリの肩の上に立って動いている。数十人が関わる製品で、一人が便利機能を毎回ゼロから書き直していたら、それはむしろ罪に近い。むしろ、車輪を上手に借りる技術こそが、現代のものづくりの土台になっている。ここを否定するつもりは、まったくない。

では、なぜ個人のメモアプリでは話が変わるのか

理由は単純で、規模と寿命がまるで違うからだ。自分が作っているのは、思いついた一行をメールへ送るだけの、ごく小さな道具にすぎない。機能を絞っているぶん、自前で書ける範囲がそもそも広い。そして何より、これを十年は使い続けたい。この「長く保ちたい」という一点で、依存の性質が牙をむく。外部ライブラリは、自分ではなく作者の都合で更新され、放置され、ある日ひっそりと消える。2016年、わずか11行の left-pad というnpmパッケージが取り下げられただけで、世界中のビルドが連鎖的に壊れた。2021年末のLog4Shellでは、どこにでもあるログ用ライブラリのたった一行が、無数のシステムを一晩で危険にさらした。借り物のコードには、他人の時計が埋め込まれている。その針が何時を指すかを、こちらは決められない。そして、機能の輪郭が小さい道具ほど、たった一つの依存が全体の生死を左右してしまう。大きな製品なら一部の差し替えで済む事故が、小さなアプリでは丸ごとの作り直しになりかねない。

借りた便利さには、いつ請求書が来るのか

ライブラリを足した瞬間は、たしかに速い。半日かかる処理が一行で済む。だが、その速さは前借りだ。請求書は忘れた頃に届く。ある朝、OSのバージョンが上がってライブラリが非対応になる。作者が更新をやめ、別の依存と衝突しはじめる。使っていたのはたった一つの関数なのに、その裏に何十もの孫依存がぶら下がっていたと、後になって気づく。しかも請求書は、たいてい自分が別の作業で手一杯なときに限って届く。小さなアプリにとって、この保守コストは、得た機能の対価として重すぎることがある。便利ライブラリを一つ入れないという判断は、将来の自分に届く請求書を、あらかじめ破り捨てておく行為に近い。

ライブラリを避けるのは、ただの自己満足ではないのか

ここは自分でも一番後ろめたい部分なので、正面から書く。外部を避けたがる心理は、いわゆるNIH症候群——「ここで作られたものではない」という理由だけで他人の成果を遠ざける、技術者の悪癖——と、よく似ている。自分で書き直したものは、たいてい世に出回るライブラリより出来が悪い。時間も余分にかかる。この批判は、半分は当たっている。

だが、残りの半分はこうだ。自分は「車輪」をすべて自作しているわけではない。むしろ逆で、危ない車輪ほどAppleの標準に預けている。暗号処理を独自に発明することはせず、OSが用意した検証済みの仕組みをそのまま使う。画面もデータ保存も、プラットフォーム純正の部品で組み上げる。避けているのは、一晩あれば書ける程度の「接着剤」を、わざわざ第三者のリポジトリから借りてくることだけだ。消えた愛用アプリの後継を目指した記録でも触れたとおり、標準フレームワークという巨大な車輪の上には遠慮なく乗り、その上に載せる細工だけを自分の手で握る。線引きは、ずっとそこにある。

消えるのは、いつも自分の書いていない部分だった

十年ほど前、愛用していたCaptioという小さなアプリが、ある日App Storeから静かに消えた。作者が個人で、事業をたためばアプリもろとも終わる。あのとき失われたのは、機能表には載らない「使い心地」だった。同じことが、ライブラリにも起きる。2017年の初め、Facebookが買収したParseというバックエンド基盤が停止し、それに乗っていた無数のアプリが作り直しを迫られた。振り返ってみると、壊れたのは決まって「自分の書いていない部分」だった。自分にも、一度だけ肝を冷やした記憶がある。開発の初期に、便利だからと外部の部品を一つだけ試しに組み込んだことがあった。半年後、OSの更新でそれが警告を吐きはじめ、まる二日かけて自分の手で書き直すはめになった。以来、最初の一つを入れないことのほうが、あとの百の手間を省くのだと考えるようになった。鍵の管理まで外部に預けなかったときの話にも書いたが、道具の要を自分の手の届く範囲に収めておけば、少なくとも他人の廃業や方針転換で、それが一夜にして死ぬことはない。起動が0.3秒で済む軽さも、突き詰めれば、余計な部品を積んでいないことの副産物にすぎない。

借りないことで、失ったものはないのか

正直に書けば、失ったものはある。世に定評のあるライブラリには多くの目が入っていて、自分一人では気づけない例外処理まで織り込まれている。それを使わないぶん、細かな不具合を自分で踏み抜く回数は増えた。凝ったUIの表現をあっさり実装できず、途中で諦めた機能もいくつかある。開発の初速も、目に見えて落ちる。依存ゼロは、無料で手に入る美徳ではない。はっきりと代償のある選択だ。その代償を、道具の寿命と引き換えに前払いしている——そう自覚したうえで、なお選んでいる。

では、何を自分で書き、何を借りるべきか

三年やってたどり着いた線引きを、一つだけ残しておく。借りるなら、プラットフォームそのものが配る部品を借りる。iOSでいえばAppleの標準フレームワークで、これは少なくとも自分のアプリより長生きする公算が高い。逆に、第三者が片手間で公開した便利ライブラリは、一晩で書ける程度のものなら自分で書く。たとえば日付の整形や暗号化はOS標準に任せ、画面の細かな飛び回りは自分の数十行で受け持つ、という具合に振り分ける。判断の軸は「機能が優れているかどうか」ではない。「その部品の寿命を、誰が握っているか」だ。寿命の主導権が、自分かAppleの手の中にあるものだけを土台に選ぶ。派手さはないが、小さな道具を長く生かすには、この地味な問いがいちばん効いた。

よくある疑問

Q. 依存ゼロは、誰にでも勧められる方針か。

A. まったく勧めない。期日のある仕事や、複数人で開発する現場では、素直に既存のライブラリに頼るほうが速く、そして安全だ。これはあくまで、一人で作る小さな道具を長く保つための、かなり特殊な最適化にすぎない。

Q. 自分で書くぶん、開発は遅くならないのか。

A. 最初は確実に遅くなる。ただ、外部更新への追随やバージョン衝突の後始末が消えるので、長い目で見ると保守の総量はむしろ減った。速さを前借りするか、後払いするかの違いだと考えている。

Q. 暗号のような重要な処理まで自作するのか。

A. しない。そこは例外なくOS標準の検証済みフレームワークに任せる。「自分で書く」の対象は、あくまで接着剤の部分だけだ。セキュリティの根幹を独自実装するのは、依存ゼロとはまったく別物の、ただの危険でしかない。

では、この方針を人にも勧めるかと問われれば、答えは否だ。ほとんどの現場では、車輪は借りたほうがいい。省いた便利さを恨めしく思う夜も、正直に言えば何度もあった。それでも、自分がこの小さな道具をもう一度ゼロから作り直すとしたら、やはり同じ選択をするだろう。壊れるのが他人の都合ではなく、せめて自分の手の中であってほしい。たぶん自分は、その一点だけは、どうしても譲れないのだと思う。

[obsidian-simple-memo]

とっさに書いた一行は、あとで自分を助けるか

思いついたことを、5秒以内に外へ出す。この習慣を三年ほど続けてみて、たどり着いた結論を先に書いておく。速く書くこと自体には、大した価値はない。価値があるのは、速く書けたおかげで「あとで手を入れる余地」が残ることのほうだ。とっさに書いた一行は、それ単体ではまず使いものにならない。だが消えずに残ってさえいれば、翌朝の自分がいくらでも育て直せる。この記事は、その「残すための5秒」を巡る覚え書きだ。

なぜ、思いついた言葉はこんなに速く消えるのか

記憶の実験に、よく引かれる数字がある。1959年、Lloyd Peterson と Margaret Peterson は、TGH や CLS といった無意味な三文字を24人の学生に覚えさせ、直後に指定した数から3ずつ逆算させて、頭の中での反復を邪魔した。結果、正しく言えた割合は3秒後で約50%、18秒後にはたった5%前後まで落ちた。声に出さず心の中でつぶやき直す作業——リハーサルを封じると、短期記憶はおよそ18秒しかもたない。同じ結論には、前年の1958年にイギリスの John Brown も独立してたどり着いている。日常でこの反復が続かないのは、意志が足りないからではない。次から次へと入ってくる刺激が、そのつぶやきを片端から上書きしていくからだ。

日常の体感は、たぶんもっと短い。電気ケトルのスイッチを押して振り返る数秒のあいだに、さっき組み立てた一文は語尾だけを残して抜け落ちている。しかも厄介なことに、場所を移すと忘却は加速する。2011年、ノートルダム大学の Gabriel Radvansky らは、同じ距離を歩いても、ドアをくぐって別の部屋へ入った人のほうが、直前に扱っていた物事を思い出しにくくなることを実験で示した。脳はドアを「一つの場面の終わり」とみなし、古い文脈を静かに捨てにかかる。廊下に出た瞬間に「あれ、何を取りに来たんだっけ」となるのは、意志の弱さではなく仕様なのだ。

5秒という数字は、目的ではなく制約だ

先に断っておくと、5という数字に魔法はない。肝心なのは、思考が短期記憶から蒸発する前に、できるだけ少ない手数で外部へ固定してしまうことのほうだ。ここでは便宜的に、この習慣を「5秒ルール」と呼んでおく。定義しておけば、5秒ルールとは、浮かんだ言葉が消える前に最小手数で外へ書き留めてしまう習慣のことだ。数字は5でも10でも、本質は変わらない。

手数を実際に数えてみると、思ったより多い。ポケットからスマホを取り出す。画面のロックを解く。目当てのアプリを探す。起動を待つ。入力欄にカーソルを置く。この五手も六手も踏んでいるうちに、Peterson の言う18秒はとうに尽きている。実は、人は書くのが遅いのではない。書きはじめるまでが遅い。個人開発でメモの道具を作りながら、自分がこの数年ずっと削ろうとしてきたのは、この「書きはじめるまでの時間」ただ一点だった。

殴り書きの断片は、本当に役に立つのか

ここで、自分でも気になっている反論に正面から向き合っておきたい。5秒で殴り書きした一行は、たいてい雑だ。主語が抜け、前後の文脈が飛び、ひどいときには翌朝の自分ですら解読できない。「そんな断片をいくら量産しても意味がない」という批判は、半分は当たっている。

しかし、残りの半分はこうだ。雑な一行は、何も残っていない状態よりもはるかに強い。完全に忘れてしまえば、翌朝の自分には手がかりの一片も残らない。だが「牛乳／切れてた／例の返信」という三語の断片さえ残っていれば、そこから記憶はしばしば丸ごと復元される。心理学でいう検索手がかり(retrieval cue)がまさにこれで、断片は思い出すための取っ手になる。現に自分も、「例の返信」というたった四文字から、締め切りの相手も用件も、返すべき文面の口調までまるごと引き戻せたことが何度もある。逆に言えば、速さとは質を捨てる言い訳ではない。質を安心して後回しにできる権利を、前もって買っておく行為だ。捕まえるのは今の自分、整えるのはあとの自分——この分業は、断片が消えずに残っているという一点にすべてを賭けている。

では、最初の5秒をどうやって削るのか

削れる手数から、機械的に削っていくしかない。自分の場合は、通知もフォルダ分けもタグ付けも全部やめて、開いたら即入力・一行送ったら画面はクリア、という状態に寄せた。1メモ=1アクション。整理という面倒は、受信箱のほうに勝手に溜めておけばいい。送信ボタンを押した時点で、その一行はもう頭の外へ出て、あとで拾える場所へ移っている。頭は空にして、次の思いつきへ手を空けておく。

それでも、指を動かすという一手はどうしても残る。歩いているとき、鍋を火にかけているとき、片手が子どもでふさがっているとき——その一手さえ重く感じる場面がある。最近は、指を動かすより早く声で吐き出してしまう入力に頼る日が増えた。iOS 26 のオンデバイス音声認識で、話した先から文字になり、そのまま送れる。声もテキストも端末の外へ出ない仕組みなので、口に出すことへの心理的な抵抗も小さい。試しに「iphone メモ 音声入力」で自分の作ったものを含めていくつか触ってみると、手がふさがった瞬間の一手が確かに軽くなった。ただし万能ではない。対応する機種と言語が要るし、非対応の端末ではマイクのアイコンすら現れない。騒音の中や固有名詞は誤変換するので、そこだけは後からキーボードで直す前提でいるのが現実的だ。

以前、頭に浮かんだ一文が消えるまでを数えた回にも書いたことだが、速さの最大の敵は、いつも「あと少しだけ便利にする設定」だった。入り口は、狭ければ狭いほど速い。

速さは、記憶を信じないための保険だ

煎じ詰めれば、5秒で書くという行為は、5秒後の自分を信用していないことの裏返しだ。Miller が1956年に『Psychological Review』誌で示した「7±2」という有名な見積もりも、のちに Nelson Cowan が2001年に「実質は4つ前後」と下方修正した。人が同時に頭の中で握っていられる情報は、自分で思っているよりずっと少ない。ならば、握れているうちにさっさと手放して、外側に置いてしまう。

書いた瞬間の一行は、未完成でかまわない。むしろ未完成のまま残っていることこそが、翌朝の完成を可能にする。

よくある疑問

Q. 「5秒」に厳密な科学的根拠はあるのか。

A. 秒数そのものはあくまで目安だ。ただ、短期記憶がリハーサルなしで20秒ともたないことは、Peterson らの1959年の実験が繰り返し確かめている。数字を守ることより「消える前に外へ出す」という原則のほうが本体で、5でも8でもかまわない。

Q. 雑なメモばかり増えて、かえって散らからないか。

A. 確実に増える。だからこそ「捕まえる場所」と「整える場所」を最初から分けておく。受信箱には速く放り込み、読み返しと選別は別の時間にいっぺんにやる。入り口は速く、出口は丁寧に、と役割を割り切る。

Q. 音声入力は、実際のところどんな場面で効くのか。

A. 手が物理的にふさがっている瞬間だ。歩行中や家事の途中など、キーボードを打つ一手すら惜しい場面で、声はいちばん手数の少ない入力になる。静かな環境なら精度も十分に実用の範囲に入る。

思いつきは、まだ資産ではない。放っておけば数秒で蒸発してしまう、ただの気配にすぎない。その気配を、消えてしまう前に一行の言葉へ変えておく——自分が個人で作り続けているメモの道具も、結局はそのためだけに存在している。5秒ルールの本質は、速く書くことではない。忘れてしまう前に、未来の自分の手のひらへ、そっと渡しておくことだ。

[obsidian-simple-memo]

3年間、同じメモをタスクへ書き直し続けていた

今月、下書きフォルダを3年分さかのぼって数えてみた。同じ内容の一行を、メモからタスクへ、タスクからメモへと書き直した形跡が61件あった。結論から言うと、あの作業のほとんどは無駄だった。メモとは、まだ何をするか決めなくていい記録であり、タスクとは、いつ・何をするかがすでに決まった記録だ。この二つを書く瞬間に無理やり分けようとするから、せっかく捕まえた思いつきの熱量が、分類の作業だけで冷めていく。境界線そのものは必要だが、引く場所とタイミングを長いあいだ間違えていたのだと思う。

メモとタスクは、そもそも何が違うのか

辞書的には近い言葉に見える。だが実務で効いてくる違いはひとつだけだ。「次に自分が何をすればいいか」が、書いた時点ですでに決まっているかどうか。決まっていれば、それはもうタスクだ。決まっていなければ、ただのメモでしかない。「牛乳を買う」は次の行動が一意に決まっているからタスクになる。「牛乳と乳糖不耐性の関係が気になる」は、次に何をすればいいのか自分でもまだ分からない。後者を無理やり「牛乳について調べる」というタスクに変換しても、実際に開くのは検索窓ではなく、また別の思いつきのメモであることのほうが多い。にもかかわらず、多くのタスク管理アプリは、書いた瞬間にどちらかへ強制的に分類させようとする。「メモ タスク 使い分け」と検索してこのあたりに来た人になら、この迷いはきっと伝わると思う。決まっていないものを、決まっているふりで箱に入れる作業が、そこかしこで発生している。

今月、3年分の下書きを数えてみた

自分が作っているメモアプリには、送信前に一時保存される下書きの履歴が残る。今月、その履歴をさかのぼって、内容を変えずに「メモ」から「タスク」、あるいはその逆へ書き直された形跡を数えたら61件あった。平均すると、ひと月に1.7件のペースで同じ内容を行き来させていたことになる。書き直しの多くは、深夜に思いついてメモとして放り込んだものを、翌朝タスクリストへ律儀に転記し直す作業だった。転記した瞬間は仕事をした気になれる。だが実際に実行されたのは61件のうち9件だけで、残りはタスクという体裁だけを得て、そのままどこにも動かなかった。行き先を変えても中身は空のままだったのだから、当然の結果だ。動かなかったものの大半は、その場でタスク化せずにそのままノートへ積もっていく経路に流しておいた一行だった。整理しないまま置いておいた一行のほうが、変な体裁を得なかった分、あとで素直に読み返せた。9件と61件という数字の差を見て、自分がやっていた「転記」という作業の大半が、実行の準備ではなく実行した気分を得るための儀式だったと認めるしかなかった。

なぜ「とりあえずタスクにしておく」が危ないのか

「あとで困るよりは」と思って、判断に迷うメモを片っ端からタスクリストに変換した経験は多くの人にあるはずだ。だが宙ぶらりんの項目は、消化されないまま頭の負荷として居座り続けることが分かっている。1927年、旧ソ連の心理学者ブリューマ・ゼイガルニクは、中断された作業のほうが完了した作業よりも強く記憶に残ることを実験で示した。ツァイガルニク効果と呼ばれるこの現象は、良い方向にも悪い方向にも働く。適度な未完了は集中を保つ助けになるが、未完了のタスクが際限なく積み上がると、頭は常にどこかでその処理を気にし続けることになる。厄介なのは、この緊張感がタスクという「形式」自体から生まれてしまう点だ。中身が本当は何も決まっていないメモであっても、タスクという箱に入れた瞬間、頭は「いつかやる」という緊張だけを律儀に生成し続ける。タスクという形式は実行の予定までは与えてくれないのに、緊張感だけは律儀に発行してしまう。

GTDの2分ルールが取りこぼしているもの

2001年、David Allen は著書『Getting Things Done』のなかで「2分ルール」を示した。2分未満で終わる作業ならその場で片付けてしまえ、という指針だ。実務的で、いまも色あせない知恵だと思う。ただしこのルールは、所要時間をすでに見積もれる作業にしか使えない。「牛乳と乳糖不耐性の関係が気になる」に必要な時間は、2分か、2時間か、それとも一生かからないのか、書いた本人にも分からない。GTDの仕組みに一度心中しかけて何も進まなくなった話は以前ここに書いたが、あのとき苦しかったのも結局、所要時間の見積もれない気がかりまで律儀に分類しようとしたせいだった。時間の見積もれないものを無理にタスク化すると、見積もれないという事実そのものが隠れてしまう。見積もれないことをいったん認めてしまえば、それはタスクではなくメモとして扱うしかない、という当たり前の結論に、当時はなぜか辿り着けなかった。

「まだ決めない」を、サボりと呼ばない仕組み

迷ったら、無理に分類しない。これが3年かけてようやく落ち着いた自分なりの結論だ。次の行動が決まっていない一行は、タスクリストの下に置くのではなく、時刻だけつけてそのままノートに流しておく。分類という判断を先送りにしているだけで、記録そのものを先送りにしているわけではない。数日後、あるいは数週間後に読み返すと、次の行動が向こうから見えてくることがある。たとえば「乳糖不耐性」のメモは、3週間後に別の記事を読んでいるときにふと「体質を調べる」という具体的な行動に変わった。逆に、何度読み返しても行動が見えてこないものは、それもまた立派な結果だ。行動にならなかったという事実が分かっただけでも、書いた意味はあった。ただし、公平のために書いておくと、「まだ決めない」を都合のいい免罪符にして、何もかも判断保留のノートへ流し込むだけなら、それはただの先延ばしでしかない。実際、61件のうち、判断を保留にしたまま3年間一度も読み返されていない項目も4件あった。そのうちの1件は「独立した友人の仕事を手伝えないか」という、3年前の自分にとってそれなりに重かったはずのメモだ。分類しないことと、放置することは違う。自分の場合、週に一度だけ、保留にしたノートを古い順に5件だけ目を通す時間を作っている。5件という数は多くない。だが読み返す習慣そのものをなくすと、「まだ決めない」はそのまま「一生決めない」に変わってしまう。

境界線は、書く瞬間ではなく読み返す瞬間に引く

メモとタスクの境界線は、書いた瞬間に引く必要はない。むしろ書いた瞬間に無理やり引こうとするから、迷いが分類作業の時間を食い、思いついた勢いのほうが先に消えていく。境界線を引くのにふさわしいのは、読み返す瞬間だ。数日後の自分が読んで、次の行動が見えたならタスクにすればいい。見えなければ、まだメモのままでいい。書く瞬間の自分より、少し時間を置いた自分のほうが、たいてい正確な判断ができる。61件書き直した過去の自分に一つだけ言えるとしたら、判断はあれほど急ぐ必要はなかった、ということだ。

よくある疑問

メモとタスクを同じアプリで管理してもいいのか。問題はない。むしろアプリを分けるより、置き場所を一つにして「まだ決めない」の一行を紛れ込ませておくほうが、あとで読み返す手間が減る。アプリを分けた瞬間に、見返す場所も二つに増えてしまう。

「あとで判断する」と先延ばしは何が違うのか。判断する期限を自分で決めているかどうかだ。読み返す日を先に決めておけば判断の保留であり、決めずにただ埋もれさせれば先延ばしになる。

思いついた瞬間にタスク化したくなる衝動は、抑えたほうがいいのか。次の行動が本当にもう決まっているなら、抑える必要はない。抑えるべきなのは、行動が決まっていないのに形式だけタスクに合わせてしまう習慣のほうだ。

61件のうち、まだ4件が判断保留のまま残っている。今日それを読み返すかどうかも、正直まだ決めていない。

[obsidian-simple-memo]

忘却とは、初めから設計に含めておける機能だ

検索窓に何を打ち込んでも、たいてい何かしら引っかかる。自分が作っているメモアプリの検索バーに、試しに三年前の日付を入れてみた。忘れていたはずの小さな一行が、いくつも出てきた。うれしいような、少し気味が悪いような感覚だった。全部を検索可能にしておくことは一見親切に見えて、メモを取るという行為そのものを重くする。だから最近は、アプリの中にすべてを溜め込まない設計のほうが、案外正しいのではないかと考えている。忘れることは事故ではない。最初から設計に含めておける、ひとつの機能だ。

朝、検索窓の中だけがやけに賢くなっている

スマホのストレージも、クラウドの容量も、この十年でほとんど気にしなくていいものになった。写真も、スクリーンショットも、なんとなく取ったメモも、消す理由がないまま増えていく。増えても困らないはずなのに、増えるほど「どこに何を書いたか」を探す時間だけが伸びていく。1万件のメモから1件を探すのと、50件のメモから1件を探すのとでは、検索技術がどれだけ賢くなっても体感の重さが違う。全文検索は見つけることを助けてくれるが、捨てる判断は誰も助けてくれない。むしろ「検索すれば出てくるから」という理由で、捨てる判断そのものを先送りにしてしまう。だから多くの人の手元には、二度と開かれない一行がひたすら積み上がっていく。スクリーンショットのフォルダを開くたびに、なぜ保存したのか思い出せない画像が並んでいることに気づいた人は少なくないはずだ。増える速度に、探す技術の進歩が追いついているように見えて、実際には探す対象そのものが毎日膨らみ続けている。

なぜ人はこんなに忘れっぽいのか、少し調べてみた

心理学者ヘルマン・エビングハウスは1885年、自分自身を被験者にして無意味な綴りを暗記し、時間の経過とともにどれだけ思い出せなくなるかを記録した。結果はいまも「忘却曲線」と呼ばれ、学習した内容の多くが1時間以内に失われはじめ、1か月後にはその大半を思い出せなくなることを示していた。人間の記憶は、放っておけば忘れる方向に強く傾いている。長いあいだ、それは補わなければならない欠点として扱われてきた。文字も、印刷も、写真も、この傾きに抗うための道具として発明されてきた側面がある。ところが2018年、英ノーサンブリア大学のSweeten・Sillence・Neaveらが学術誌Computers in Human Behaviorに発表した研究は、デジタル環境がこの傾きをほぼ無効化してしまったことを指摘する。彼らが「デジタルホーディング」と呼ぶこの行動には、ため込むことへの執着と、削除することへの困難や不安が共通して見られるという。忘れる方向に傾いていたはずの生き物が、消せない・消さない道具を手に入れてしまった結果である。

夕方、それでも自分がアプリに求めるものは何か

「メモアプリ おすすめ」という検索結果を見比べていた時期がある。多くのアプリが、どれだけ保存できるか、タグでどれだけ整理できるかという保存力を競っていた。けれど自分が本当に欲しかったのは、保存力ではなく手放しの良さだった。思いついた一行をその場で書き、送り先を決めたら、あとはアプリの中に残さない。送信のあとに待っているのは検索可能な倉庫ではなく、キューをひとつずつ空にしていくだけのOutboxのような仕組みでいい、というのが自分の出した答えだった。忘れる前提の設計とは、アプリの中を検索可能な倉庫にすることではなく、メモを別の場所――メールや、Obsidianの保管庫へその都度手渡す経路――に預けていく設計を指す。「obsidian iphone メモ 自動」のような検索をしたことがある人になら、この感覚はわかってもらえると思う。キャプチャと整理を同じ場所でやろうとするから、アプリはどんどん重くなる。捕まえる場所と、あとで育てる場所を分けてしまえば、捕まえる方はいつまでも身軽なままでいられる。実際に、積読が千件を超えていた話は以前ここに書いた。あのときの反省は、この話にもそのままつながっている。増やさない工夫より、増えた先を別の場所に移す工夫のほうが、結果として長続きしている。1メモ＝1アクションという原則を自分の中で決めてからは、書く・送る・忘れるの三つを一続きの動作として扱うようになった。三つ目の「忘れる」を工程からわざと外さないことが、地味だが一番効いている。

夜、全部を記録した人たちの末路を思う

忘れないことを突き詰めた人間が、実際にいる。マイクロソフト・リサーチのゴードン・ベルは2000年代、自分の会話や文書や行動をひたすら記録し続ける「MyLifeBits」という実験に自らを差し出した。その集大成である著書『Total Recall』(2009年、ジム・ジェメルとの共著)は、人生をまるごと電子的な記憶として残す「eメモリー」の可能性を描いている。ただしこの実験は同時に、記録する量が増えるほど、あとから使える形に整理し直す仕組みがなければ記録そのものが死蔵することも明らかにした。全部残しても、探し出せなければ無いのと同じだ。もっと極端な形を、フィクションの中に見ることもできる。ホルヘ・ルイス・ボルヘスが1942年に発表した短篇「フネス、記憶の人」は、落馬の事故をきっかけに何ひとつ忘れられなくなった青年を描く。彼はあらゆる木の葉の形も、あらゆる瞬間の雲の形も寸分違わず覚えている。けれど個々の違いを消して「木」や「昨日」のようにまとめ上げる、抽象という作業だけができない。忘れられないことが、そのまま考えられないことに直結してしまう逆説がそこにある。全部を持つことと、使えることのあいだには、思っている以上に距離がある。ベルの実験もフネスの物語も、行き着く先は同じ一点だ。記憶の量を増やす技術は、それだけでは何も解決しない。

もうひとつ夜、社会も「忘れる」ための制度をつくっていた

個人の記憶だけでなく、社会も似た問題にぶつかってきた。2014年5月13日、欧州司法裁判所はスペイン人男性マリオ・コステハ・ゴンサレスが起こした裁判(Google Spain対AEPD、事件番号C-131/12)で、本人にとって不適切または無関係になった検索結果を削除するようGoogleに命じる判断を下した。いわゆる「忘れられる権利」の起点とされる判決だ。これは2018年5月25日に全面施行されたEUのGDPR(一般データ保護規則)第17条「消去権」として、いまも制度化されている。法学者ヴィクター・マイヤー＝シェーンベルガーは2009年の著書『Delete』のなかで、デジタル技術にはもともと有効期限という発想が組み込まれておらず、それこそが忘却を難しくしていると論じた。もっとも、この権利には批判もある。公共性の高い報道や歴史的記録まで検索結果から消えてしまえば、それは「忘れる自由」ではなく「知る権利」の後退になりかねない、という指摘だ。判決自体も、本人の権利と公共の利益を天秤にかけることを求めており、単純な話ではない。それでも、人間の記憶は放っておけば薄れるのに、検索エンジンの記憶は放っておいても薄れない、という非対称は残ったままだ。だからこそ、忘れる権利をわざわざ制度として作り直す必要があった。個人のメモアプリと国家間の法律とでは規模がまるで違うが、根っこにある問題は同じに見える。放っておけば忘れる生き物のために作った道具が、放っておいても忘れない道具になってしまった、というねじれだ。

一週間後、よく聞かれる3つの疑問に答えておく

「忘れる前提のメモアプリ」と、ふつうの全文検索アプリは何が違うのか。違いは検索性能ではなく、設計の向きにある。全文検索アプリは全部を貯め込んで、あとから探させる。忘れる前提のアプリは、その場で送り先を決めて手放し、探すという作業ごと別の場所に預けてしまう。

大事なメモまで本当に消えてしまわないか、という心配もよく聞く。消えるわけではない。メモは必ず自分宛のメールに届くし、Obsidian連携を使えば保管庫にも複製が残る。アプリの中に無限の検索可能なデータベースを作らないという話であって、データそのものを捨てる話ではない。

Obsidianを使っていなくても、この話は関係あるのか。関係はある。キャプチャの道具と保存の道具を分けるという発想は、Obsidianに限らず、メールだけでも、紙のノートに書き写すだけでも成立する。大事なのは、アプリの中で勝手に育てようとしないことだ。

ボルヘスのフネスは、忘れられなかったせいで、ものを考えられなくなった。全部を覚えているアプリが正しいとは限らない理由は、たぶんそこにある。今日もどこかで一行を書いて、送って、手放す。忘れることも、ちゃんと設計に含めておきたい。

[obsidian-simple-memo]

Pocketが消えた日、積読は1,000件を超えていた

Pocketの保存リストをエクスポートしたら、1,247件あった。2017年にMozillaが買収し、2025年7月8日にサービスを終えたあの「あとで読む」アプリに、自分は八年近く記事を放り込み続けていたことになる。深夜、寝る前にブラウザのタブを整理する習慣があって、読みかけの記事を閉じる代わりに保存ボタンへ逃がす。ベッドに入る直前の数分間、画面を消す罪悪感を先送りにするための最後の一手が保存だった。それを八年繰り返した結果がこの数字だった。エクスポートしたJSONファイルを開いて中身を見返すと、開封済みのフラグが立っていたのは百件に満たなかった。残りの千百数十件は、タイトルだけを覚えられて、本文には一度も目を通されないまま、サービスごと消える寸前だった。先に言っておくと、この千件超を今から全部読もうとは思っていない。開かれないまま消えても、それは失敗ではない。問題は保存した数の多さではなく、自分の言葉に変換できた数の少なさのほうだ。

保存は、判断を先に延ばすための小さな儀式だ

タブを閉じる前に保存ボタンを押す瞬間、頭の中には「これで大丈夫」という妙な安心が生まれる。だがそこで実際に起きているのは、読むかどうかという判断そのものを、未来の自分に丸投げしただけの動作だ。未来の自分がいまの自分より暇になる保証は、どこにもない。むしろ大抵は忙しさが積み増しされていて、リストはその前提の上にひたすら積み上がっていく。たとえば夕食の支度をしながら見かけた作り置きレシピを保存したとする。翌週末には別の新しい料理動画のほうを開いてしまい、先週のレシピは二度と呼び出されない。1,247件のうち、保存した直後の高揚をいまでも覚えている記事は、数えるほどしかない。あとは見出しの記憶すら怪しい。

なぜ「あとで読む」は具体的な日時にならないのか

会議やゴミ出しには曜日と時刻が付く。歯医者の予約にはリマインダーが飛んでくる。だが「あとで読む」という約束にだけは、期限が存在しない。カレンダーに載らない予定は、載っている予定に毎回負ける。土曜の朝にぽっかり時間が空いても、そこに座るのは大抵、通知の来た別の作業か、真新しく保存したばかりの記事の方だ。古い記事はリストの底に静かに沈み、沈めば沈むほど「いまさら読む理由」を失っていく。半年前に保存した記事を開こうとすると、なぜそれを面白いと思ったのかという文脈のほうが先に失われていることも多い。読まれない記事そのものが悪いのではない。「あとで」という言葉が、そもそも一度も予定表に載ったことがないのが原因だ。read it later アプリが軒並み積読解消に苦戦しているという話をよく見かけるが、原因の大半はここにある気がしている。

「Read It Later」という名前だった十八年

Pocketは最初からPocketではなかった。2007年8月、Nate Weinerという開発者がFirefoxの拡張機能として公開したときの名前は、そのまま「Read It Later」だった。名は体を表すという言葉があるが、あの名前は皮肉なほど正確だった。読むのはいつも「後で」で、実際に開かれる保証はどこにも書いていなかった。2012年にPocketへ改名され、記事だけでなく動画やレシピまで保存対象を広げて利用者を増やし、2017年にMozillaへ渡り、2025年7月8日に十八年の歴史を閉じた。エクスポートの猶予は同年10月8日までと案内されていた。名前を変え、機能を足し、会社が変わっても、保存してから読まれるまでの距離だけは最後まで縮まらなかったように見える。

積読リストは記憶の代わりではなく、罪悪感の保管庫になる

積読という言葉はもともと紙の本の話だったが、デジタルでも構造はほとんど変わらない。ためた本や記事は、いつか読む自分への投資のつもりで積まれる。ところが実物は、開くたびに「まだやっていない」を思い出させる装置に変わっていく。以前、三千のノードを振り返った話をこのブログに書いたことがあるが、あれはRoam Researchのノードが対象だっただけで、罪悪感の保管庫としての働きはまったく同じだった。増やすことは驚くほど簡単で、減らす動機だけは外からはやって来ない。だから残高は一方向にしか動かず、静かに嵩を増していく。しかもリストが長くなるほど、上から順に見返す気力そのものが失われていくという、厄介な悪循環まで付いてくる。

保存されるものは、本当にひとまとめにできるのか

すべての「あとで読む」を一律に扱うから、リストは際限なく膨らむ。手を止めて分けてみると、性質はだいたい三つに分かれる。ひとつはニュース性の高い速報記事で、これは半日過ぎれば価値の大半が失われる。あるサービスの障害速報を三か月後に読んでも、もう何の役にも立たない。ふたつめは手順を説明したハウツーで、これは必要になったときにもう一度検索したほうが早い場合が多い。バージョンが上がれば手順自体が古くなっていることさえある。みっつめは、自分の考え方そのものを揺らす類の文章で、これだけが「あとで」ではなく「いま少し考える」に値する。1,247件を大まかに分類してみると、三種類目に該当したのは体感で一割にも届かなかった。九割は、そもそも保存する必要すらなかったのかもしれない。速報とハウツーは、保存という行為に見合うほど賞味期限が長くないのだと思う。

開かれないまま消えることは、失敗なのか

ここは結論を急がずに考えたい。保存した瞬間、自分はすでにその記事のタイトルと数行の要約から「面白そうだ」という判断を下している。その判断作業自体には、確かに価値があった。あとから開いて中身まで読むかどうかは、まったく別のタスクだ。このふたつを同じ「読書」という行為だと思い込んでしまうから、開かれずに消えた千件超を、まるごと失敗のように感じてしまう。実際に起きたのは、判断というタスクは成功し、精読という二番目のタスクだけが単に発生しなかった、というそれだけの話だ。Pocketがサービスを終えても、あの判断の履歴そのものは消えていない。判断した瞬間の自分の興味関心は、記事の中身とは別に、確かに存在した。

分けるべきは「あとで読む」ではなく「もう一度考える」

Pocketのエクスポートファイルを最後まで見て、ひとつ発見があった。百件に満たない「開封済みの記事」のうち、自分の言葉で何か一行でもメモを残していたのは、そのまた半分にも届いていなかった。つまり本当に効いていたのは保存した数ではなく、自分の言葉に変換した回数のほうだった。だとすれば、外部のリンクを溜める場所と、自分の考えを育てる場所は、最初から分けておいたほうがいい。手元のアプリでは、送ったメモをiCloud Drive上のObsidian保管庫に自動で追記できるようにしてあるが、これも同じ発想から足した機能だった。リンクをただ増やす代わりに、一行だけObsidianへ送る仕組みを挟んでおくと、増えていく先が「消化待ちの山」ではなく「少しずつ育っていくノート」に変わる。保存の総量を減らすことよりも、変換される割合を上げることのほうが、たぶん効く。

よくある質問

「あとで読む」リストは一気に消してしまっていいのか。

問題はない。保存した時点で、興味があるかどうかの判断という仕事はすでに終わっている。開かないまま消えても、その判断自体が無効になるわけではない。

保存と記録の違いは何か。

保存は外部のURLをそのまま預ける行為で、記録は自分の言葉で一行に置き換える行為だ。前者は際限なく増え続け、後者は増える速度が自然と遅くなる。

積読を減らすための最初の一歩は何か。

新しく保存する前に、リストの一番下、つまり最初に保存した記事を開くか消すかを先に決める。増やす前に一件減らす順番を守るだけで、山の高さは変わってくる。

では自分は、この先もPocketの後継アプリに千件を積み上げるのだろうか。たぶん積む。ただし今度は、保存する瞬間に「これはリンクの山行きか、一行の記録行きか」のどちらかを先に決めてから積むつもりでいる。