#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]

タスク管理を完璧にした年、いちばん何も進まなかった

押し入れの奥の段ボールから、四つ折りになった一枚の紙が出てきた。2016年に自分で印刷して、赤いボールペンで矢印まで描き足したものだ。中央に「Inbox」と書いた四角があって、そこから線が放射状に伸びている。「2分以内なら即実行」「プロジェクトへ」「いつか/たぶん」「資料へ」。我ながら、よくできた図だった。よくできていたから、十年近く捨てられずに、段ボールの底で眠っていたのだろう。正直に書いておく。この完璧な図を仕上げた年、自分は人生でいちばん、何も前に進まなかった。

紙の上では、すべてが流れていた

2016年の春、David Allen の『Getting Things Done』をようやく通して読んだ。原著は2001年、邦題は『ストレスフリーの整理術』。説いていることは、拍子抜けするほど単純だった。頭の中の気がかりを全部外に出し、一箇所のInboxに集め、決まった手順で上から処理していく。たったそれだけだ。

痺れた。頭の中でぐるぐる回り続けていた「やらなきゃ」が、紙の上では一本の流れになって、整然と片付いていく。当時はちょうど、海外の生産性ブログが GTD や「43 Folders」的なライフハックで盛り上がっていた頃で、自分もその熱に当てられていた。

だから、図をできるだけ精密に再現しようとした。タスク管理アプリはOmniFocusに落ち着き、コンテキストは「@電話」「@PC」「@外出」「@家」に切り分けた。プロジェクトごとにレビューの頻度を変え、週次レビュー用のチェックリストは、気づけば47項目に膨らんでいた。日曜の夜になるとコーヒーを淹れ、たまったInboxを一件ずつ点検していく。あの時間は、正直に言えば嫌いではなかった。むしろ一週間でいちばん心が落ち着く時間だった。仕組みが緻密になっていくのが、純粋に楽しかった。何かを片付けたわけでもないのに、自分の生活が一段ずつ高機能になっていく——そういう手応えだけは、確かにあった。今思えば、その手応えこそが、最初の罠だった。

なぜ仕組みが重いほど、手が止まったのか

ところが、だ。仕組みが精密になればなるほど、肝心の「実行」のほうが痩せていった。タスクを分類し、コンテキストを付け替え、適切なプロジェクトに紐づける。その整える時間のほうが、タスクそのものを片付ける時間より長くなっていく。「タスク管理 続かない」と検索する人の気持ちが、当時の自分にはまだ分からなかった。自分は立派に続けられている、と思い込んでいたからだ。続けていたのは管理であって、仕事ではなかった。

一つ、よく覚えている例がある。学生時代の恩師に近況を書いて送ろう、とある晩に思い立った。それをInboxに入れ、「@PC」のコンテキストを付け、「個人・連絡」というプロジェクトにぶら下げ、優先度の旗を立てた。分類は、我ながら完璧だった。そして、そのタスクは半年間、一度も実行されなかった。旗の立った状態のまま、リストの奥へ静かに沈んでいった。分類するという行為が、やった気分だけを先に支払ってしまっていたのだと思う。

今になって分かる。あの47項目のチェックリストは、不安をなだめるための儀式だった。GTDは本来、頭の中の未完了の気がかり——オープン・ループと呼ばれるもの——を全部書き出して、脳を解放するための技術だったはずだ。それがいつのまにか、ループを閉じるのではなく、ループに丁寧なラベルを貼って棚に並べる作業に化けていた。分類の精度と、実行の確率は、どこかで反比例しはじめる。きれいに片付いた棚を眺めて満足してしまえば、もう箱を開ける理由がなくなるからだ。動くことより、動ける状態を整えることのほうが、ずっと安心できる。だからこそ、整える作業のほうを、やめられなかった。

そして、システムは一点から崩れた。週次レビューだ。最初の数ヶ月は、日曜の夜にきちんとやっていた。半年後には隔週になり、一年後には「来週ぜんぶやる」が口癖になった。気づくと、処理されていない気がかりがInboxに三百件たまっていた。三百件のInboxは、もうInboxではない。ただの沼だ。David Allen 自身、GTDは「信頼できるシステム」である時にだけ機能すると、繰り返し書いている。週次レビューが止まった瞬間、自分の仕組みは信頼を失い、ただ巨大な未読リストに変わった。崩れた原因は、意志の弱さというより、メンテナンスのコストだったと思う。重い仕組みは、それ自体が日々の負債になる。作るときには資産のつもりだったものが、いつのまにか毎日の利息を取り立ててくるようになる。

最後まで残ったのは、捕まえる一歩

ある週末、ぜんぶ捨てた。コンテキストも、プロジェクト分類も、47項目のチェックリストも、未練なく消した。十年使ったアプリのアイコンを、ホーム画面から外すときの、奇妙な身軽さだけは覚えている。

それでも一つだけ、どうしても手放せない動作が残った。「思いついたら、すぐ一箇所に放り込む」。GTDでいう Capture、収集のステップだ。整理(Organize)も見直し(Review)も自分には重すぎたが、捕まえる最初の一歩だけは、十年経っても体に染みついて離れなかった。信号待ちで、寝る前の布団の中で、歩いている途中で——思いついた瞬間にどこかへ放れる、という安心だけは、どうしても手放したくなかった。

だから自分は、その一歩だけを速くする道具を作ることにした。分類機能もフォルダもタグも付けない。ただ思いつきを最短で外に出して、メール経由で自分の受信箱へ送るだけ。Apple純正のフレームワークだけで組んだ、起動の速い捕獲専用のメモアプリだ。設計の細かい記録は https://simplememofast.com に置いてある。

捕獲だけに振り切った道具には、長い系譜がある。かつて Captio という小さなアプリがあって、一行をTwitterやメールへ放流するためだけに存在していた。整理は一切しない。ただ捕まえて、投げる。それだけで完結する潔さがあった。ああいう思想の道具を何度か自分なりに並べ直してきた記録は、https://simplememofast.com/captio-alternative/ に書き留めてある。捕獲の摩擦は年々下がっていて、いまでは画面のマイクに向かって一言つぶやくだけでも、一行が残る。手がふさがっている時でさえ、思いつきだけは取り逃さずに済むようになった。入口さえ十分に速ければ、人は安心して、整理のほうを後ろへ回せる。順番が逆だったのだ。整理から入るのではなく、捕獲から入る。その順番を、自分は十年かけて取り違えていたのだと思う。

十年かけて、引き算していた

振り返ると、自分がやっていたのは足し算ではなく、長い長い引き算だった。2016年のあの放射状の図から、矢印を一本ずつ消していった。「@電話」を消し、「いつか/たぶん」を消し、週次レビューを消した。ぜんぶ消していくと、中央の「Inbox」と、そこへ放り込む矢印が一本きり残った。David Allen が示した五つのステップ——収集・把握・整理・見直し・選択——のうち、自分の手元で本当に生き残ったのは、いちばん最初の「収集」だけだった。皮肉な話だ。あれほど時間をかけて作り込んだ整理の階層は、ひとつも残らなかった。残ったのは、本を読む前から体が知っていたような、ごく当たり前の一動作だけだった。わざわざ大きく遠回りをして、出発点に戻ってきたようなものだ。

これを「GTDの敗北」と呼ぶ人もいるだろう。でも自分はそうは思わない。五段あった階段の、一段目だけが自分には必要だったと分かった。残りの四段が悪かったわけでもない。自分の生活には、ただ重すぎただけだ。どの一段が要るのかは、十年かけて確かめるよりほかになかったのだと思う。

では自分は、またいつか、あの精密な仕組みを一から作り込んでしまうのだろうか。たぶん、作る。人は不安になると、動くことより整えることを選びたくなる生き物だ。完璧な仕組みは、何もしていない時間に、何かをしているという錯覚を与えてくれる。その錯覚は、たぶん一生なくならないのだろう。ただ、次にその手が動きはじめたら、今度はきっと思い出す。段ボールの底で眠っていた、あの一枚の紙のことを。よくできた図ほど、自分を一歩も前へは進ませてくれなかった、ということを。

—

Obsidian連携シンプルメモ：Apple純正フレームワークだけで作った、起動0.3秒の軽量メモアプリ。もとは終了したCaptioの代替として作り始めた。詳細は https://simplememofast.com に置いてあります。

[obsidian-simple-memo]

受信箱ひとつで暮らす人を、何人か知っている

この半年で、受信箱にフォルダを一つも持たない人に、立て続けに三人会った。一人はフリーランスのデザイナー、一人は中小企業の経理担当、一人は中学校の社会科教員で、職種も年齢もばらばらだった。共通していたのは、メールも、思いつきのメモも、買い物リストも、全部「上から下へ流れていく一本の列」に放り込んでいたことだ。最初は、ただ片付けの苦手な人たちなのだと思っていた。違った。打ち合わせでノートパソコンを開いてもらうと、画面も机まわりも、いちばん整然として見えたのは、その整理をしない三人だった。雑然としていたのは、むしろフォルダを丁寧に作り込んでいる自分の方だった。経理の人は、月末に何百通と届く請求メールを、振り分けではなく「処理したら即アーカイブ」だけでさばいていた。受信箱に残っているのは、その日まだ支払っていない数件だけ。銀行の残高みたいに、受信箱の件数そのものが進捗だった。

なぜフォルダを作らなくなったのか

理由を聞くと、三人とも判で押したように同じことを言った。「振り分けている数秒のあいだに、中身を忘れる」。思い当たる節があった。2007年ごろ、自分はGmailのラベルを四十個近く作っていた。「仕事」「個人」「請求」「あとで読む」、その下にさらに入れ子を作り、受信ルールでの自動振り分けまで設定した。半年後に棚卸しをすると、ラベルの八割は作って以来一度も開かれていなかった。そもそもフォルダを設計するというのは、未来に届くあらゆる情報を、届く前に分類しておくという賭けだ。だが実際に届いてみると、どの箱にも入らないものや、二つの箱にまたがるものが必ず出てくる。フォルダという仕組みは、未来の自分がいつも几帳面で時間に余裕がある、という前提で作られている。実際の未来の自分は、たいてい疲れていて、片手で歩きながら画面をいじっている。前提が、最初から狂っている。

「探す」より「流す」が勝った

転機は、おそらく検索だった。2004年にGmailが全文検索を当たり前にし、2005年前後にはデスクトップの検索も一瞬で効くようになった。「どこに入れたか」を頭で覚えておく価値が、その十年で静かに暴落していった。場所で管理するか、検索で取り出すか。この二択を突きつけられて、ほとんどの人は無意識のうちに後者を選んでいた。フォルダは場所の技術であり、受信箱は時間の技術だ。逆に言えば、時系列という一本の軸さえ通っていれば、人は驚くほど物を失くさない。古いオフィスの格言に「OHIO＝Only Handle It Once（一度しか触るな）」というのがある。フォルダ整理は、一通のメールを最低二度触らせる。読むときと、しまうときだ。受信箱ひとつの暮らしは、この二度目を丸ごと消す。三人が口を揃えたのは「探す手間より、もう一度書いた方が速い」という、身も蓋もない一言だった。

受信箱ひとつで、本当に困らないのか

困る場面は、もちろんある。最大の弱点は、「あとで必ず処理する」もの——支払い期限のある請求書、返信期限のある依頼——が、新着の濁流に飲まれて下へ下へと沈んでいくことだ。ここでフォルダ派は勝ち誇る。専用の「未処理」フォルダさえあれば沈まない、と。だが三人を観察していると、彼らはフォルダの代わりに「数」を使っていた。受信箱に残すのは、常に十件以下。処理したら消す、読んだら消す、転記したら消す。受信箱が「保管庫」ではなく、離着陸だけをくり返す滑走路になっていた。2007年に「Inbox Zero」という言葉が流行ったが、彼らがやっているのは、その過激な日常実践版だった。もっとも、件数が三桁に膨らんだ瞬間、この方式は一気に崩れる。十件の規律が利いているうちだけ成立する、薄氷の上の秩序でもある。

受信箱を「滑走路」に保つ技術

滑走路には、置きっぱなしの飛行機がない。同じように、三人の受信箱には沈殿物がほとんどなかった。残っている十件は、すべて「これから動くもの」だけだ。終わった用件は消え、長く育てたいものは別の場所へ移される。面白いのは、三人とも「あとで読む」フォルダを持っていなかったことだ。あとで読むものは、結局あとでも読まない。十年前のラベルがそれを証明していた。だから彼らは、読まないと判断したものはその場で消す。残すか、消すか、別の場所へ送るか。判断を先送りしないことが、列を短く保つ唯一のコツだった。フォルダを二十個も巡回して確認するより、一本の列の上澄みだけを見る方が、認知の負荷は明らかに低い。彼らは整理をしていないのではない。整理する対象を、目の前の十件だけに絞り込んでいる。

入口の速さが、すべてを肩代わりする

この滑走路を成立させているのは、つきつめれば入口の速さだ。思いついた瞬間に、迷わず一列へ放り込める入口がなければ、人はまた「とりあえずの逃げ場」としてフォルダを作りはじめる。捨て場所が遅いと、人は仕分けで時間を稼ごうとするからだ。アプリの起動に二秒もかかると、人はメモを取るのをやめ、頭の中に留めようとする。そして忘れる。入口の遅さは、そのまま記憶の漏れになる。captio 代替を探していた頃に自分が作ったメモアプリも、つきつめればこの一点だけに賭けている。起動して、書いて、送る。0.3秒で開いて、行き先は一つだけ。整理を諦めるための道具ではなく、整理を安心して後ろへ回すための入口だ。その設計の細かい記録は https://simplememofast.com に置いてある。

では、整理はどこへ消えたのか

消えてはいない。整理する場所が、受信箱の外へ移っただけだ。受信箱で「捕まえる」のがうまい人ほど、別のどこかで、別の道具で、丁寧に「育てて」いる。最近よく見かけるのは、捕獲はiPhoneの一本の列、熟成はObsidianの保管庫、という役割分業だ。送ったメモがiCloud Drive上のデイリーノートかInboxノートに時刻付きで一行ずつ積まれていく——コミュニティプラグインも要らず、Obsidianを開く必要すらない地味な追記で、しかもメールには従来どおり届く——という仕組みを、自分も最近試している。捕まえる場所と育てる場所を物理的に分けてしまうと、受信箱は驚くほど軽くなる。その分業の覚え書きは https://simplememofast.com/obsidian/ に残した。「obsidian iphone メモ 自動」のような言葉で検索して行き着く先は、たぶん全部この「分けて考える」話に収束していく。

フォルダを捨てた三人が、最終的に正しいのかどうか、自分にはまだ言い切れない。一つだけ確かなのは、彼らが「整理をやめた」のではなく、「整理する場所を一つ後ろへずらした」だけだということだ。受信箱は出発点であって、終着点ではない。三人を見ていて思うのは、整理術の優劣ではなく、「どこで悩むか」を先に決めているかどうかの差だということだ。では、出発点はいくつ持つのが正解なのか。一本に絞るべきか、捕獲用と熟成用で二本に割るべきか。その問いには、観察を重ねた今でも、自分の中で答えが出ていない。たぶん、しばらくは出ないままだろう。それでも、フォルダをまた二十個に増やそうという気だけは、もう起きない。

—

Captio式シンプルメモ：Apple純正フレームワークだけで作った、起動0.3秒のメモアプリ。詳細は https://simplememofast.com に置いてあります。

[obsidian-simple-memo]

1971年生まれの規格を、2026年の朝に使い続けている

最初に断っておくと、これは「メールはオワコンではない」という弁護の文章ではない。メールは古い。古いまま勝ち続けている。なぜここまで古いものが残るのかを、自分のために整理しておきたいだけだ。

メールは、もともと社内チャットだった

Ray Tomlinson が ARPANET 上で別ホストへのテキスト送信に成功したのは1971年のことだ。当時 BBN にいたエンジニアが、暇つぶし半分で書いた SNDMSG と CPYNET の改造から始まったとされる。その最初のメールが何だったかは本人も覚えていないと言っているが、ひとつだけ確実なのは、「ユーザー名と機械名を区切るために @ を選んだ」というあの選択が、半世紀以上経った2026年現在も生き残っているという事実だ。

ここで強調しておきたいのは、メールがもともと「同じネットワーク内で機械を超えてテキストを渡すための、ちょっとした便利機能」として生まれた、ということだ。最初から「世界中の誰とでも繋がる通信手段」として設計されたわけではない。むしろ機能としては、現代のSlackやMicrosoft Teamsの最初期コンセプトに近い。社内ハック由来のプロトコルが、なぜか外に染み出して、後発のあらゆるサービスを生き延びてしまった。

そのままRFC 821（SMTP, 1982）、RFC 5321（2008）と何度もリビジョンが重ねられてきたが、コアにあるアイデアは変わっていない。テキストを、ホスト間で、非同期に、相手の都合がよくなった時刻に渡す。誰の許可も要らずに送れる。受け取り側は読みたい時に読む。それだけだ。

なぜ「それだけ」が勝ち続けているのか

理由は3つあると考えている。

ひとつは、メールが標準であること。SMTP、IMAP、POP3 はオープンな仕様で、Apple も Google も Microsoft も Yahoo も、好き嫌いに関係なく実装している。Slack や Notion がいくら便利でも、自分の会社のSlackから他社のNotionに直接メッセージを送ることはできない。ところがGmailからiCloudメールへは何の手続きもなく送れる。「相手が使っているサービスを意識せずに連絡できる」というのは、本当はとても異常な状態で、その異常な状態を維持しているのがメールしかない。

ふたつめは、分散であること。世界中に何万台もメールサーバーがあって、それぞれが独立して動いている。Slackの障害が起きると全世界のSlackが止まるが、Gmailが落ちてもFastmailもProtonMailも動いている。インフラとしての耐障害性が、設計者の意図を超えて結果的に高い。

みっつめは、非同期であること。これがいちばん大事だと思う。Slackもメールも文字を送るという意味では同じだが、受け手の期待値がまったく違う。Slackで30分既読をつけないと「あの人いるかな」と気にされるが、メールで30分返事がなくても誰も何も思わない。むしろ、半日後に丁寧な返事が来るほうが普通だ。同期コミュニケーションは脳の前頭葉を削るが、非同期通信は手元に置いておいてよい。1971年の通信回線がそもそも遅かったから非同期にせざるを得なかった、というだけの話なのだが、その制約が2026年の集中力を救っている。

「メールはもう古い」と言われ続けて20年

Slackが日本で流行り始めたのが2014〜2015年あたり、Notionの本格普及が2019年あたり、ChatGPTが2022年末。新しいツールが出るたびに「これでメールは終わる」と言われ続けて、もう20年近く経っているのではないだろうか。

しかし、見渡してみる。請求書はメールで届く。ECサイトのパスワード再設定もメールだ。Slackの未読通知も、最終的にはメールで届く。GitHubのIssue更新もメールだ。新しいツールが出るたびに、そのツールの「外側」との通信路としてメールが温存されている。これは偶然ではなく、新しいツールがどれだけ便利でも、メールほど普遍的な届け先を提供できないからだ。

Captio というアプリの話を前回書いた。Twitter から自分のメールへ140字を投げる、という極端に絞られた1機能だけのアプリだった。あれが2014年に静かに消えたあと、自分は乗り換え先を3年近く探して回った。captio 代替を探していた人なら覚えがあるかもしれないが、整理した記録は https://simplememofast.com/captio-alternative/ に置いてある。結論だけ書くと、「Captioが何のアプリだったかは、要するに『自分宛メールを送るUIをひたすら速くしたもの』だった」。Captioの本質的な価値は、Twitterへの接続でも、UIの美しさでもなく、宛先がメールだったことに集約される、と気付くまでに3年かかった。

自分宛メール、というメモ術の地味な完成度

メールを「メモ」として使うのは、決して新しい発想ではない。GTDの David Allen が2001年の著書で「Inboxに集約せよ」と書いて以来、メール受信箱を Inbox として扱う流派は途切れたことがない。多くのメールクライアントが「Send to myself」ショートカットを持っているのも、この延長線上にある。

なぜこれが地味に最強かというと、どの端末でも開ける（メーラーが標準アプリとして必ず入っている）、検索に強い（過去20年分のフルテキスト検索が3秒で終わる）、バックアップが勝手に多重化されている（クラウド＋端末＋IMAP）、「あとで考える」をスレッドで蓄積できる、外部サービス（領収書、リマインダー、共有リンク）と地続きである、という5点に尽きる。Notionでもよく似たことはできるが、Notionが10年後にも今と同じ仕様で動いている保証はない。一方、メールが10年後に廃止される可能性はほぼゼロだ。Tomlinson のあのプロトコルは、Notion のスキーマよりも確実に長生きする。

自分が個人開発で作っているメモアプリも、結局のところ「自分宛メールを速く送るためのUI」に過ぎない。起動時間とキーボード即フォーカスだけを徹底的に詰めたら、それがそのまま商品の輪郭になった。経緯と設計思想は https://simplememofast.com にまとめてあるが、要するに「Captioが消えてから10年経って、まだ同じ場所で同じことを考えている人間が、ひとり地味に作っている」というだけのことだ。

メールはインフラだからこそ、生き残る

新しいツールが古いツールを置き換える、というのは、技術的にはよくある話だ。だがインフラはそう簡単に置き換わらない。電気の周波数がいまも50/60Hzで揺らいでいるのも、鉄道のレール幅がイギリス由来の1435mmのまま固定されているのも、最初に決まった仕様が「ちょうど多くの人が依存してしまったから」生き残っている。メールはこの種のインフラに分類される。便利だから残っているのではなく、依存している人が多すぎて剥がせないから残っている。

ただしインフラとして残っている、というのは、決して悲観する話ではない。むしろ、メールの上に新しい層を乗せれば、その層も自動的にメールと同じ寿命を獲得する。Captio がそうだったし、いま自分が作っているメモアプリもそうだ。レールが変わらない限り、その上を走る車両はいくらでも更新できる。

ある古いハッカーが、こんなことを書いていた。「メールは、インターネットで唯一勝ち続けたユーザー体験だ」。半分は皮肉で、半分は本気だったと思う。2026年の朝、受信箱の一番上に並んでいる自分宛のメモを眺めながら、その評価は、ますます正しくなっている気がしている。

—

Captio式シンプルメモ：Apple純正フレームワークだけで作った、起動0.3秒のメモアプリ。詳細は https://simplememofast.com に置いてあります。

[obsidian-simple-memo]

2014年の冬、App Store からアイコンがひとつ消えていた

2014年の12月、たしか平日の朝だった。地下鉄を出て駅前のコンビニでホットコーヒーを買って、信号待ちの間に App Store を開いた。アップデートのバッジが出ていたからだ。一通り更新して、最後にホーム画面に戻ったとき、いつも左下に置いていた小さな封筒のアイコンがなかった。

Captio が消えていた。

検索しても出てこない。デベロッパーの Agile Tortoise のページに飛んでも、Drafts はあるけれど Captio は並んでいない。再ダウンロードしようとしたら「このアプリは現在使用できません」と書かれていた。あのとき自分は通勤の人混みの中で、不思議なほど落ち着いた気持ちで画面を眺めていた。「ああ、終わったんだ」と思った。コーヒーはまだ熱くて、信号は赤のままだった。

消えたアイコンの後に残った習慣

Captio がやっていたことは、ただひとつ。起動すると即フォーカスの入った入力欄が現れて、そこに何か打ち込んで送信ボタンを押すと、自分のメールアドレスに件名なしで飛ぶ。それだけだった。それだけのアプリに、自分は3年間ずっとお世話になっていた。

アプリが消えても、自分の中の習慣は残った。何か思いついたら自分宛にメールする。会議中に出た数字、駅で見た看板の言葉、夜中に読み返したい本のタイトル、夢の余韻。全部メールにした。受信箱の上の方に並ぶそれらは、誰にも見られないし、誰かを煩わせもしない。ただ、未来の自分にだけ届く小包だった。フォルダ分けもしない。タグも付けない。検索したくなったらメールクライアントの全文検索を使う。それだけで、何年か分の思考の断片が手元に残った。

もとはメールに自分宛で送るだけのアプリだった

Captio はカテゴリ的に言えば「メモアプリ」ではなく、もっと正確に言えば「キャプチャアプリ」だった。整理しない、検索しない、振り返らない。ただ脳の中にあるものを最短距離で外に出す。出した先は自分のメール。それだけ。

UI もシンプルで、起動すると黒い背景にテキスト入力欄がひとつだけ。タイトルもタグもない。送信先のメールアドレスを最初に設定したら、もう設定画面に戻ることもない。送信ボタンを押した瞬間に「ピッ」という短い効果音が鳴って、アプリは閉じる。そして0.3秒後にはもう、次の信号待ちの考え事が始まっている。あの潔さは、いま振り返っても他に類を見ないと思う。

なぜメール宛先が最強のキャプチャ先だったのか

当時の自分はあちこちの「メモアプリ難民」を経験していた。Evernote、Simplenote、Apple純正のメモ、テキストエディタ系、知らないインディーアプリまで。だがどれも、開いて書いた瞬間に「整理」という宿題がついてきた。タグはどうするのか、フォルダはどこに置くのか、後で読み返す導線はあるのか。書くという行為と同時に、5つくらいの判断を迫られる。

Captio はそれら全部を放棄していた。書く → メールで自分に送る → 終わり。整理は受信箱という古き良き場所がやってくれる。検索はメールクライアントの仕事。バックアップは IMAP の責任。書く側は「思考の流出」だけに集中していい。決断の数を最小化するという意味で、これは認知科学的にも理にかなった設計だった。

探し続けた代替の3年間

Captio が消えた後、自分は同じ仕事をしてくれる代替を探し始めた。Drafts はよく出来ているが起動後にアプリ内に保存する設計で、結局アプリの中を整理する手間が戻ってきた。Bear や Notes はもっと「メモのため」のアプリで、サッと書いて流すには重かった。iOS の Mail.app から自分宛に送ることも試したが、起動が遅く、件名を空にすると警告が出るのが地味に煩わしかった。

候補は全部試した。Pushbullet 経由でデスクトップに飛ばす実験もしたし、IFTTT で SMS を Gmail に転送するレシピも組んだ。Apple の Shortcuts に同じ動作を組み込もうとして、起動から送信完了までに3タップかかる時点で諦めた。どれも、Captio が10秒で済ませていた動作を15秒から25秒に伸ばしてしまった。たかが15秒。されど15秒。思考が脳の表面に出てきている時間が15秒以上経つと、もう半分は逃げてしまう。

App Store から消えるアプリの「使い心地」は誰が残すのか

ここで気づいたのは、ソフトウェアの世界には「消えると同時に思想ごと忘れられる」アプリが大量にある、ということだった。コードはバイナリのまま漂って、開発者は別のプロジェクトに移って、ユーザーは別のアプリに移って、そのアプリ特有の使い心地だけが空中に取り残される。

Vesper、Clear、Sunrise、Mailbox。同じ時代に消えていったアプリは数えきれない。どれも当時の使用者にとっては「あの感じ」が確かにあって、消えた後にスクリーンショットを眺めても、その感じはもう戻ってこない。何年か後、Captio のことを検索しても、出てくるのは廃止のニュースと、当時のブログ記事の断片だけ。あの起動の速さ、あの背景の黒さ、あの送信音の短さ、それらは誰の手にも残っていない。だから自分は、忘れたくなかった。

結局、自分で同じ思想のアプリを作ることになった

2025年、自分はその思想を引き継ぐためのアプリを Apple 純正フレームワークだけで書き始めた。起動を速くするためにサードパーティ依存を一切入れない。書いた瞬間にメールに飛ぶことだけを最優先にする。整理機能はあえて持たない。SwiftUI、MailKit、Combine。それだけで作れた。コードベースは1ファイル数百行に収まった。

開発の記録と思想・設計のメモは https://simplememofast.com にまとめてある。アプリを売り込みたいというより、Captio のような小さなアプリが残した使い心地が、もう一度地続きに繋がるための備忘録のつもりで書いている。誰にも参照されなくても、自分にとっては毎週見返す場所だ。

代替候補を整理した記録のほうは、https://simplememofast.com/captio-alternative/ に置いてある。当時の自分のように、消えたアプリを探して右往左往している人がいたら、たぶんそこから何か拾える。

Captio が残したもの、いまのメモアプリに足りないもの

最近の生成AIブームで、メモアプリは「賢くなる」方向に進化している。タグを自動で付ける。要約してくれる。Q&A形式で振り返らせてくれる。それはそれで便利だし、自分も使う。

でも、Captio が残した思想はその逆だった。メモはただ脳から外に出るだけで価値がある。整理は後回しで、いやそもそも整理しなくていい。考えるべきは書く速度であって、書いた後の整頓ではない。これは AI が代わりにやってくれることではない。書き手の指と脳の距離を、極限まで近づける道具がいる。賢さは外側に置いておけばいい。賢いメモアプリは AI と通信したそのあとに作ればよくて、その手前の「とにかく書く1秒」を AI が短くしてくれることは、原理的にない。

メモアプリの本質は「賢さ」ではなく「速さ」だ。あの2014年の冬、App Store から静かに消えていったアイコンは、そのことを誰よりも先に証明していたのだと思う。

—

Captio式シンプルメモ：Apple純正フレームワークだけで作った、起動0.3秒のメモアプリ。詳細は https://simplememofast.com に置いてあります。

[stateofnow]

THIS IS A CAPTION