「メモは後で使えるように、きちんと整理して書け」。AI時代に入って、この助言はむしろ強くなった気がする。タグを付けろ、見出しを立てろ、後からAIに読ませやすい形に整えておけ——そういう声が、この一年で確実に増えた。だが半年ほど個人開発でメモアプリを作ってきて、自分はこの通説の、ちょうど反対側に立っている。整理して書くほど、メモはむしろ捕まえ損ねる。今日はその結論に至った理由を、実際に下した実装の判断と一緒に、順番に並べていきたい。まずは「整理」という作業そのものを疑うところから始める。

「整理して書け」という作法は、どこから来たか

メモを整理して書け、という発想には、思いのほか長い歴史がある。1960年代に社会学者ニクラス・ルーマンが磨いたZettelkastenは、1枚のカードに固有番号を振り、関連するカードへのリンクを手で張っていく方式だった。9万枚に及んだと言われるそのカードの束は、番号という構造があったからこそ、後から辿れた。1980年代以降に広まったGTDも近い。Inboxに放り込んだ中身を、まず「次に取る行動」へ分類してから手をつけろと説いた。1990年代以降のPCのフォルダ文化、その後のタグ文化も、すべて同じ系譜の上にある。整理を促す思想は、形を変えながら60年以上、ずっと「先に分類せよ」と言い続けてきた。どれも共通して、書いた直後に、分類というコストを払えと要求してくる。

この作法は、当時は完全に合理的だった。理由はただ一つ、後から「探す」のがとても高くついたからだ。紙のカードは全文検索できない。正しい棚に挿さなかった1枚は、物理的に二度と見つからない。9万枚の中の1枚を、内容から逆引きする方法など存在しなかった。だから前もって整理に払う労力は、将来の検索コストへの前払いとして、ちゃんと元が取れていた。整理とは、貧しい検索能力を補うための、よくできた保険だったわけだ。

問題は、その前提が2026年にはもう成り立っていない、という一点に尽きる。保険は、事故の確率が下がれば、ただの掛け捨てになる。

半年前の自分は、整理する側だった

偉そうに書いているが、半年前の自分は、完全に整理する側の人間だった。Notionに凝ったデータベースを組み、メモごとにプロパティを埋め、ネストしたフォルダを几帳面に育てていた。整っていく画面は、見ていて気持ちよかった。だが、ある日気づいてしまった。プロパティを埋めるのが面倒で、そもそもメモを開かなくなっていた。整理のために作った仕組みが、捕獲そのものを静かに止めていた。

決定的だったのは、構築に何時間もかけたデータベースを、自分がほとんど検索でしか使っていなかった事実だ。せっかく作ったビューも、丁寧に振ったタグも、振り返ってみればほとんど見ていない。引くときは、結局いつもキーワードで全文検索していた。あれだけ前払いした構造の、大半が死んでいた。それなら最初から、捕獲だけに集中して、引くのは検索に任せればいい。いま作っているアプリの設計思想は、その反省を、まるごと裏返したところから生まれている。だからこれは、他人への説教ではなく、半年前の自分への反論でもある。

AI時代のメモは、整理して書くべきなのか

いまや、手元のメモは全文検索できる。数千件の断片からでも一語で絞り込めるし、意味の近さで引くこともできる。曖昧な記憶からでも「たしかあの店の名前」で引っかかる。長文をまるごと放り込めば、後からまとめ直すのも一瞬だ。つまり「整理」という作業の値段が、この数年で劇的に下がった。後からいくらでも整えられるものを、わざわざ書く瞬間に整えておく理由は、もうほとんど残っていない。

逆に、値段がまったく下がらなかったものがある。捕獲だ。思いついてから、それが手元に残るまでの、あのわずか数秒。ここだけは、AIがどれだけ賢くなっても肩代わりしてくれない。頭の中の素材は、こちらが書き留めるまで、そもそもこの世界に存在しないからだ。検索とは「すでにある情報」を引く技術であって、「まだ書かれていない思いつき」は、検索の対象にすらならない。捕獲に失敗したメモは、どれだけ高性能なモデルを使っても、世界のどこからも出てこない。最初から無いものは、引けない。これは技術が進歩しても変わらない、ほとんど唯一の制約だ。

だから、問いを立て直したい。AI時代のメモで本当に守るべきなのは、後の整理しやすさなのか。それとも、捕獲の速さと、取りこぼしの少なさなのか。自分の答えは、迷わず後者だ。

ボトルネックは整理ではなく、捕獲にある

思いつきの寿命は、自分で思っているよりも、ずっと短い。電車のホームで浮かんだ一文は、改札を抜けるころには輪郭がぼやけ、階段を上がりきると、もう消えている。何を考えていたかは覚えているのに、その鋭さだけが抜けていく。この「消える前に間に合うか」こそが、メモアプリの本当の戦場だ。Day4で起動を0.3秒まで詰めた話を書いたが、あの数字も突き詰めれば、すべて捕獲のためのものだった。実際、自分が後で一番役立ったメモの多くは、机に向かって書いたものではなく、歩きながら、あるいは寝る直前に、ほとんど反射で放り込んだ断片だった。鋭い思いつきほど、こちらの都合を待ってくれない。人が「意識的に待たされた」と感じる閾値は、おおよそ0.5秒あたりにある。起動に1秒も待たされる時点で、間に合わずに死ぬメモが、確実に出てくる。

捕獲を最優先に置くと、データの持ち方そのものが変わる。整理のためのフィールドを、書く瞬間には一つも持たせないのが、むしろ正解になる。

// 構造を持たせない。1メモ = 1行。分類のための欄は用意しない。
struct Capture {
    let id = UUID()
    let body: String
    let createdAt = Date()
}

// フォルダもタグもピンもない。捕獲した順に積むだけ。
func append(_ text: String) {
    store.insert(Capture(body: text))   // O(1)。書く側に分類の判断をさせない。
}

このモデルには、書き手に分類を強いる箇所が、一つもない。フォルダを選ぶ画面も出さないし、タグの候補も提示しない。保存先を尋ねるダイアログも出さない。Day8でInbox一本のメモアプリとフォルダ前提のメモアプリの違いを書いたとき、最後に突き当たったのも、まさにこの一点だった。書く前に「これはどこに入れるか」を一瞬でも考えさせた瞬間、捕獲は遅れる。実際に測ってみると、保存先を一度選ばせるだけで、書き始めまでに2〜3秒の遅延が乗る。その数秒のあいだに、さっきの鋭い一文は逃げていく。分類は、思考とは別の脳の働きだ。捕獲の途中に割り込ませると、肝心の中身の方が薄くなる。考えるのは後でいい。多くの場合、考えなくてもいい。

「雑に貯めたメモは、結局ゴミの山になる」への反論

ここで、必ず返ってくる反論がある。整理せずに貯めたら、見返せないゴミの山になるだけだ、と。半分は当たっている。だが、比べている相手を、根本から間違えている。

比較すべきは「整理されたメモの山」と「雑なメモの山」ではない。「雑にでも捕獲できたメモ」と、「整理が面倒で結局書かれなかったメモ」だ。後者は、そもそも存在しない。存在しない完璧なメモは、存在する雑なメモに、永遠に負ける。整理のコストを書く瞬間に課すと、課された人は、だんだん書かなくなる。これは他人の話ではなく、自分自身で何度も観測した事実だ。試しに入力欄へタグ選択を一段だけ足してみた週がある。たった一段だ。それでも、その週のメモ件数は、前の週から3割ほど落ちた。機能を足したのに、行動が減った。摩擦は、こちらが思うよりずっと正直に、行動を削る。

逆の経験もある。何の整理もせず放り込んだ一行のメモが、半年後、検索でふいに出てきて、止まっていた仕事を動かしたことが何度もある。あの一行は、もし書く時にタグ付けや分類を求められていたら、たぶん書かれていなかった。捕獲できたから、後で効いた。順番はいつも、捕獲が先で、整理が後だ。

しかも整理は、後から、必要なぶんだけ遅延させて足せる。数百件のうち、後で見返す価値が本当に出るのは、せいぜい数件だ。残りの大半は、二度と開かれないまま流れていく。それでいい。だとすれば、その数件にだけ、見つけた時点で構造を与えればいい。全件にあらかじめ構造を前払いするのは、一生使わない保険に、金を払い続けるのに近い。検索が効く時代に、その保険はもう割に合わない。

「AIに読ませるなら、構造化しておく方が精度が出るのでは」への反論

もう一つ、いかにもAI時代らしい反論がある。どうせ後でAIに食わせるなら、構造化された形で書いておく方が、出力の精度が上がるのではないか、と。もっともらしい。だが実際に試すと、しばしば逆のことが起きる。

いまの言語モデルは、生の文章を読むのがそもそも得意だ。むしろ、個人が独自に決めたタグ体系や見出し記法は、モデル側の知識の枠組みと噛み合わず、解釈の邪魔になることすらある。たとえば自分が「#後で」「#重要」と振り分けてきたタグは、自分の中では意味を持っていても、モデルにとっては文脈の薄い記号でしかない。「#後で」が、締め切り前なのか、いつか暇な時なのか、モデルには判別できない。むしろ、その私的な記号を律儀に解釈しようとして、要約が歪むことさえある。AIにとって本当に効くのは、こちらが勝手に決めた階層ではなく、思考が途切れずに最後まで書かれているかどうか——つまり、捕獲の完全さの方だ。

だから結論は、また同じ場所に戻ってくる。AIに渡す前提であっても、優先すべきは構造ではなく、取りこぼさずに全部を捕まえることだ。構造が欲しければ、渡す直前に、AI自身に組ませればいい。実際、自分は要約を作るとき、手で付けたタグをむしろ消してから渡すことすらある。素の文章の方が、モデルはよく読む。前払いをやめて、注文時払いに切り替える。そういう移行が、いま静かに起きている。

手が離せない時、思いつきはどう捕まえるのか

捕獲優先を本気で詰めていくと、最後に「そもそも手が使えない場面」が残る。料理中、歩いている時、子どもを抱いている時。キーボードを打てない状況では、どれだけ起動が速くても、捕獲経路がそこで途切れてしまう。この最後の穴を埋める入力手段として、v3.0で音声入力を足した。マイクを一度タップして話すと、その場で文字になり、カーソル位置にそのまま挿し込まれる。

実装で一番悩んだのは、文字起こしをどこで走らせるか、という一点だった。選択肢は大きく二つ。クラウドの音声認識APIに送る方式と、端末内で完結させる方式だ。クラウドに送れば、認識精度は高い。だが、リクエストごとに従量課金が乗り、何より、話した声そのものが端末の外へ出ていく。メモという、一番個人的なものを扱う題材で、後者はやりたくなかった。料金の面でも厄介で、話した分だけ課金されるなら、長く喋るほど無意識のためらいが生まれる。捕獲のための道具が、使うたびに財布を気にさせるのでは、本末転倒だ。

最終的に、AppleがiOS 26で出したSpeechAnalyzer / SpeechTranscriber、つまり端末内で動く音声認識に寄せた。文字起こしは端末内で完結し、声もテキストも外へ送らない。従量課金の外部APIを一切呼ばないので、いくら話しても、追加のコストはゼロだ。容量についても、作りがうまく効いている。認識用の言語モデルは、アプリ本体とは分離された、システム共有のアセットとして端末側に置かれる。だからアプリ自体の容量は増えない。未導入の言語だけが、初回に一度ダウンロードされる仕組みだ。

確定したテキストを、どう本文へ流すか。ここは拍子抜けするほど素直に書ける。

// 確定した文字起こしを、いまのカーソル位置にそのまま差し込む。
// 録音中もキーボードは下げない。声と指を同時に使えるようにする。
func insert(_ transcript: String, into textView: UITextView) {
    guard let range = textView.selectedTextRange else { return }
    textView.replace(range, withText: transcript)
}

声で大筋を吐き出し、固有名詞や数字だけ指で直す。録音中もキーボードを下げないので、この併用ができる。画面では波形が声の大小に追従して動き、「いま聞こえている」「もう一度押せば止まる」が、文字なしで伝わる。送信すれば録音は自動で止まり、本文はクリアされる。捕獲の経路が一本増えただけで、書く→送る→消える、というアプリの作法そのものは、何も変えていない。

正直なトレードオフも、ここに書いておく。これはiOS 26以降の対応端末でしか動かない。条件を満たさない端末では、マイクのアイコン自体が表示されない。新しいOSと端末を前提に置いた、というのが、端末内処理に振り切った代償だ。精度の面でも、巨大なクラウドモデルにはまだ届かない場面がある。早口の固有名詞や専門用語は、取りこぼすことがある。それでも、捕獲のための入力手段としては、外に出ない・課金されない・容量が増えない、というこの3点を、精度のわずかな差より上に置いた。捨てる基準が一貫していれば、迷いは小さい。

捕獲優先で設計すると、アプリは何を捨てるか

ここまで読むと、捕獲優先は、良いことずくめに見えるかもしれない。違う。これは、はっきりとした「捨てる」の選択だ。トレードオフを書かずに利点だけ並べるのは、フェアではない。

捨てたものは、三つある。一つ、書いた直後の並べ替えやすさ。Inbox一本なので、書いた瞬間に「これは仕事、これは私用」と仕分ける、あの小さな達成感はない。二つ、フォルダという安心感。整っている、管理できている、という感覚を、こちらからユーザーごと取り上げてしまっている。中身が空でも、整然と並んだ空のフォルダには、不思議な安心がある。それを差し出さないと決めた。三つ、構造そのものを売りにする道。タグやリンクや階層を、機能として前面に出す他のメモアプリと、同じ土俵では戦わないと決めた。比較表の機能欄は、こちらの方が確実に短くなる。短いことを、弱みではなく主張にした。機能の多さで安心させるより、機能の少なさで速さを約束する方を選んだ、ということだ。

その代わりに、すべてを「後で引けること」に賭けている。捕獲だけは絶対に取りこぼさない、整理は引く側へ寄せる、という賭けだ。賭けである以上、外れる人もいる。構造を自分の手で組み上げる、その行為そのものが思考になる人にとって、このアプリは確実に物足りない。Zettelkastenでカードを繋ぐ行為そのものが快感で、思考の中心にある人もいる。それは否定しない。ただ、その人向けに整えた瞬間、捕獲の速さはまた鈍る。何かを尖らせるとは、別の何かをはっきり諦めることだ。諦めないツールは、たいてい、何にも尖っていない。

では、捕獲優先はいつ破綻するか

この設計にも、はっきり負ける場面がある。自分の主張を守るためにも、そこは正直に書いておきたい。捕獲優先が成立する大前提は、「後で引く」という習慣が、引く側にあることだ。一度も検索をかけず、振り返りもしない人にとって、雑に積まれた山は、ただの墓場になる。捕獲だけして引かないなら、整理しないぶん、本当にゴミが増えるだけだ。この場合に限れば、最初の反論の方が正しい。

もう一つ、構造が中身と不可分な領域では、この前提は崩れる。たとえばソースコードや、章立てそのものが意味を持つ契約書は、捕獲した後の整形ではなく、書く時点の構造そのものが価値だ。そういうものは、専用のツールで、構造ごと書くべきだ。メモアプリが引き受けるのは、あくまで「構造を後回しにできる種類の思考」——アイデア、覚え書き、言いかけ、感情の断片だ。その線引きを曖昧にすると、捕獲優先は、ただの散らかった倉庫に堕ちる。自分の場合、コードはエディタへ、長い設計の検討はドキュメントツールへ、と最初から行き先を分けている。メモアプリに流すのは、行き先が決まる前の、まだ形になっていない思考だけだ。

だから自分は、メモアプリに「全部」を任せてはいない。引く習慣と、領域の線引き。この二つがあって初めて、捕獲優先は機能する。万能だと言った瞬間に、この設計は嘘になる。尖った道具は、効く範囲が狭い。それを認めることが、たぶん一番フェアな売り方だ。

明日から試せること

考え方を変えるのに、アプリを乗り換える必要はない。いま手元にある道具のまま、二つだけ試せる。

一週間、思いついたメモを分類せずに貯めてみる。タグも見出しも付けず、一行で放り込むだけにする。週末に、件数が増えたかどうかだけを見る。
整理は、後から見返した数件にだけ与える。最初から全件を整えようとしない。残りは検索に任せる。

捕獲を増やすと、最初のうちは、雑な山が育って不安になる。整理されていない、という落ち着かなさがある。だが検索を一度かけてみれば、その山が思っていたよりずっと使えることに、たぶん気づくはずだ。きれいに整理して書いたメモよりも、雑にでも捕まえておいたメモの方が、結局よく残っている——半年作ってきて、自分が一番きれいに裏切られた結論が、これだった。整理は、未来の自分への思いやりのつもりで、実のところ、現在の自分の手を止めていた。AI時代のメモで最初に問うべきは、どう整えるかではなく、どこまで取りこぼさず捕まえられるか、の方だ。整えるのは、そのずっと後でいい。間に合わなかった思いつきは、二度と整理の対象にすらならないのだから。

参考にしたドキュメント

Apple — Speech framework（SpeechAnalyzer / SpeechTranscriber の公式ドキュメント）: https://developer.apple.com/documentation/speech
自分のアプリで採用した音声入力の挙動仕様（オンデバイス処理とiOS 26要件のまとめ）: https://simplememofast.com/voice-input/
関連する過去記事: Day8 Inbox一本とフォルダ前提の違い／ Day4 起動0.3秒を詰めた話

Obsidian連携シンプルメモ
Swiftと、Apple純正フレームワークだけで組んだ。外部ライブラリは入れていない。起動0.3秒、捕獲だけに振り切ったメモアプリ。
App Store：https://apps.apple.com/jp/app/captio%E5%BC%8F%E3%82%B7%E3%83%B3%E3%83%97%E3%83%AB%E3%83%A1%E3%83%A2/id6749649498