#captio

起動を速くする、という目標にはどこかで底があると思っていた。開いた瞬間に書ける状態まで削れば、思いつきと記録のあいだの距離はほとんど消える。そう信じて、コンマ何秒を惜しんできた。ところが、ある地点から先で妙なことが起きた。土台が速くなるほど、遅さの正体がこちらへせり出してくる。速くしたはずのものが、いちばん遅い場所を照らし出す。その場所は、指だった。

先に結論を書いておく。とっさのメモの速さを決める最後の一押しは、起動の時間ではなく「入力の手数」だ。そして手数がいちばん重くのしかかるのは、両手が空いていない時に限って訪れる。

なぜ起動を速くしても、速くならないのか

思いつきを文字にするまでの時間を、仮にひとつながりの帯として見てみる。取り出す、開く、書く、送る。この帯のうち「開く」は、詰めれば約1秒あるかないかまで縮む。公開されている実測値でも、起動はおおよそ1秒前後だ。問題はその先で、20字ほどの一文を打つには数秒かかる。日本語は変換と確定があるぶん、さらに伸びる。開くのを半分にしても、打つのが変わらなければ、全体はほとんど縮まない。

たとえば「明日の午前中に牛乳と乾電池を買う」という十数字の一文を考えてみる。起動を0.5秒縮めても、この一文を打って変換して確定するまでの数秒は、まるまる残る。削れたのは全体の一割にも満たない。速い部分をいくら磨いても、遅い部分が残っていれば、全体はその遅い部分に引きずられていく。並列処理でよく言われる古い教訓と、まったく同じ形だ。起動を削り切った先で最後まで残っていたのは、打鍵という古くて硬い工程だった。

手数の内訳を、いちど分解してみる

帯を細かく割ると、体感の重さがどこにあるかが見えてくる。ポケットから出すのに一手、ロックを解くのに一手、入力欄に触れるのに一手、そこから文字を並べるのに十数手。送信でまた一手。起動が速いアプリは、最初の数手を軽くしてくれる。けれど文字を並べる十数手は、様式を変えないかぎり軽くならない。

日本語はここでもうひと押し重い。かなを打ち、変換候補を眺め、正しいものを選び、送り仮名を直す。英語圏のタイプ入力より、確定という工程がひとつ多い。同じ十数字でも、確定を挟むぶん、指と目を往復させる回数は一・五倍ほどに膨らむこともある。だからこそ「開いた瞬間に書ける」だけでは足りず、その先の十数手をどう畳むかが、体感速度の本丸になる。興味深いのは、この十数手がどれも「静かな机の前」を暗黙の前提にしている点だ。両手を鍵盤に置ける状況でしか、その速さは発揮されない。裏を返せば、机を離れた瞬間に、磨き上げた起動速度は宙に浮く。

両手がふさがっている時、速さはどこへ消えるのか

台所で油の付いた手のまま、ふと段取りを思いつく。子どもを抱いたまま、買い足すものを思い出す。傘と荷物で片手が埋まった駅のホームで、返す言葉の文面が頭に浮かぶ。こういう時、起動が1秒だろうと0.1秒だろうと関係がない。開いても、打てないからだ。

一日のうち、こういう「手がふさがった思いつき」が占める割合は、思っているより大きい。机に座って落ち着いて書けるアイデアより、動きながら不意に来るもののほうが、取りこぼしはずっと多い。そして取りこぼした一行は、たいてい二度と同じ鮮度では戻ってこない。あとで「何か思いついたはずなのに」と宙を探す、あの空白の感触だけが残る。ボトルネックは、もうアプリの内側にはない。指を鍵盤に置けるかどうか、という身体の側の条件へ移っている。「ハンズフリー メモ」や「iphone 音声入力 メモ」と調べる人が増えているのは、たぶんこの移動に気づいた人が増えたということだ。速さの残りは、時間ではなく様式の問題として立ち上がってくる。

入力の様式そのものを変える

打てないなら、話す。単純だが、これが手数を一気に飛ばす。話した先から文字になってカーソルの位置に入り、そのまま送れる。iOS 26 の音声認識は端末の中で完結していて、SpeechAnalyzer と SpeechTranscriber という新しい仕組みが、声をその場で文字へ変える。音声もテキストも端末の外へは出ない。外部のAPIを呼ばないので、いくら話しても追加の料金はかからず、言語モデルは共有の部品として置かれるため、アプリの容量も増えない。

もちろん万能ではない。この経路は iOS 26 以降と対応機種が前提で、非対応の端末ではマイクそのものが出ない。騒音の中や、聞き慣れない固有名詞は取り違えることがある。だから声で大筋を吐き出し、数字や名前だけ後から指で直す——そのくらいの距離感がちょうどいい。歩きながらや運転しながら画面を注視するのは危険なので、そこは声だけにするか、安全な場所で一度手を止めるほうがいい。手が離せない時ほど、声だけで一行を書き残せる入り口が効いてくる。

それでもキーボードは、要らなくなるのか

ならない。声は打鍵を置き換える道具ではなく、打鍵が届かない場面を埋める道具だ。静かな机の前では、たぶん今日も指が先に動く。変換を細かく効かせたい長文や、記号の多いメモは、手で打ったほうが速いこともある。要らなくなるのは「入力の様式はひとつきり」という思い込みのほうで、キーボードそのものではない。二つの様式を、その場の状況で握り替えられること。速さの正体は、たぶんそこにある。

速さの定義を、時間から手数へ

ここまでを一文に畳んでおく。キャプチャの速さとは、起動が何秒かではなく、思いつきを外に出すまでの手数と、その手数がその場の状況に噛み合っているかどうかで決まる。机の前では打鍵が最速で、手がふさがっていれば発話が最速になる。速さは端末の性能表の中ではなく、その瞬間の身体の側にある。同じ人が同じアプリを開いても、立っているか座っているかで、最速の入力はあっさり入れ替わる。だから「このアプリは速い」という一言は、本当は半分しか語っていない。残りの半分は、それを使う場所と姿勢が決める。以前、とっさの一行を数秒で外へ出すことについて書いた回があるが、あの「数秒」の中身も、様式が状況に合っているかどうかで大きく変わってくる。

FAQ

Q. 起動が十分に速いアプリなら、それで足りるのでは。

A. 机の前で打てる時は足りる。足りなくなるのは両手がふさがった時で、その場面では起動の速さは効かない。効いてくるのは、打たずに入力できる経路があるかどうかだ。

Q. 音声入力は、打つより本当に速いのか。

A. 状況による。静かな場所で記号混じりの短文を打つなら指が速い。変換の多い日本語の長めの一文を、手が使えない状態で残すなら、話すほうが速いことが多い。騒音下では誤認識が増えるので、その時は手直しを前提にすればいい。

Q. 声で書いたメモは、どこかへ送られてしまうのか。

A. 文字起こしは端末内で完結し、声もテキストも外へは出ない。送信して初めてメールなどに届くのは、手で打った時とまったく同じ挙動だ。

消えたアプリを振り返るとき、話はたいてい機能の一覧か、別れの感傷のどちらかに落ちる。今日書き残したいのは、そのどちらでもない。ひとつの小さな設計思想が、十四年という時間をかけて静かに証明してみせたことについてだ。結論を先に置いておく。よく設計された道具は、機能の多さではなく、削り切った潔さのほうで生き延びる。この一点を、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が手がけ、十四年動いて二〇二四年に静かに幕を下ろした。

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

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

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

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

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

自分の手元では、捕獲側が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が相棒と呼んだのは、そういう状態の箱のことだったはずだ。仕組みで自動化できるのは受け渡しまでで、その先を相棒にできるかどうかは、置き方と粗さの問題になる。

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

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

よくある質問

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

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

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

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

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

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

「車輪の再発明はするな」。プログラミングを学ぶと、たいてい最初のほうで刷り込まれる格言だ。この助言に、自分はこの三年、意図的に従ってこなかった。とはいえ、全面的に逆らってきたわけでもない。チームで期日に追われて作るなら、出来合いのライブラリを使うほうがいい。そこは疑う余地がない。話が反転するのは、一人で作る小さな道具を、十年単位で生かし続けたいときだ。ここでいう「依存ゼロ」とは、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標準の検証済みフレームワークに任せる。「自分で書く」の対象は、あくまで接着剤の部分だけだ。セキュリティの根幹を独自実装するのは、依存ゼロとはまったく別物の、ただの危険でしかない。

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

今月、下書きフォルダを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件書き直した過去の自分に一つだけ言えるとしたら、判断はあれほど急ぐ必要はなかった、ということだ。

よくある疑問

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

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

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

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

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

スマホのストレージも、クラウドの容量も、この十年でほとんど気にしなくていいものになった。写真も、スクリーンショットも、なんとなく取ったメモも、消す理由がないまま増えていく。増えても困らないはずなのに、増えるほど「どこに何を書いたか」を探す時間だけが伸びていく。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に限らず、メールだけでも、紙のノートに書き写すだけでも成立する。大事なのは、アプリの中で勝手に育てようとしないことだ。