Zettelkasten Inbox ／ ブロック詳細
いちばん長く触れる編集欄。中身は「入力しても画面が重くならないようにする」ための作りが大半で、推薦の作り直しは自動ではなくボタンを押したときだけ。機械が追いかけるのをやめて、人に決めさせている。
抽象度 Lv.4（技術用語＋システム上のやりとりまで／製品名・ライブラリ名は書かない）このアプリでいちばん長く触れる場所――新しいタイトルと、自分の言葉のコメントを書く欄。 やっていることは「文字を受け取る」だけに見えるが、中身は 「入力しても画面が重くならないようにする」ための作りが大半を占めている。
受信箱の画面には、Tagの一覧（数百件）とABC Noteの候補（9件）が並んでいる。 素直に作ると、1文字打つたびにその全部を計算し直すことになる。 それを避けるために、このブロックは3つの手を打っている。 (1) 文字を編集欄の中だけに閉じ込める。 (2) 画面へ伝えるのは「空か、空でないか」が変わった瞬間だけ。 (3) 推薦の作り直しは、ボタンを押したときだけ。
とくに (3) は珍しい判断で、画面にもはっきり「候補更新は手動です／入力中は推薦計算も候補取得も行いません」 と書いてある。機械が勝手に追いかけるのをやめて、人に決めさせている。
3. 本文の取り出しと自動要約 → 13. 入力の受け止めと候補更新の手動化 → 5. Tagの推薦／6. ABC候補／7. 画像の添付／8. 保存
ここを分けないと、アプリが実用にならない。 1文字打つたびに、Tag数百件それぞれについて2文字の並びの重なりを数え直し（5番）、 ABC Note9件の点数を計算し直す（6番）ことになる。 日本語の入力は変換の途中でも文字が変わるので、 この計算が1秒に何十回も走る。結果、文字が遅れて出るようになる。
「待ってから計算する」方式を採らなかった理由。 よくある手は「入力が止まって0.5秒経ったら計算する」というやり方だが、 このアプリはそれを意図的に採っていない（採っていないことを確かめる検査まで書かれている）。 待ち時間方式だと、書いている途中で候補が勝手に入れ替わる。 候補の順位が動くのは「決める」ための情報なので、 利用者が「いま決めたい」と思った瞬間にだけ動くほうが良いという判断。
推薦用と保存用で文を分けている理由。 推薦は「ボタンを押した時点」で止まっていてよいが、 保存は必ずいまこの瞬間の文でなければならない。 もし保存も推薦用の文を使ったら、 ボタンを押したあとに書き足した分が保存されないという事故になる。 だから保存だけは、画面の状態を経由せず控えの箱から直接読む。
空かどうかだけを画面へ伝える理由。 画面が知りたいのは「保存ボタンを押せるか」だけで、文字の中身は要らない。 0文字→1文字のときと、1文字→0文字のときだけ伝えれば足りる。 これで、2文字目以降の入力では画面がまったく反応しなくなる。
| 工程 | 主体 | やりとりの内容 | 方向 |
|---|---|---|---|
| 13-1 | 利用者 → 編集欄 | 1文字の入力 | → |
| 13-2 | 編集欄（内部） | 自分の中の状態として文字を保持 | ↻ |
| 13-3 | 編集欄 → 受信箱の画面 | 現在の下書きを控えの箱へ（再描画なし） | → |
| 13-4 | 受信箱の画面（内部） | 空↔入力ありの境目だけを状態に反映 | ↻ |
| 13-5 | 利用者 → 編集欄 | 「候補を更新」ボタンの押下 | → |
| 13-6 | 編集欄 → 受信箱の画面 | そのときの下書き（再描画あり） | → |
| 13-7 | 受信箱の画面（内部） | 推薦の計算し直しと候補の並べ直し | ↻ |
| 13-8 | 利用者 → 受信箱の画面 | 保存の指示（ボタンまたはCtrl+Enter） | → |
| 13-9 | 受信箱の画面（内部） | 控えの箱から最新の下書きを読み出す | ↻ |
13-1 利用者が題名やコメントを1文字打つ。日本語なら、変換が確定する前の段階でも 文字は次々に変わっていく。
技術的には 入力欄の変更を知らせる仕組みは、 日本語の変換中でも発火する。「かんじ」と打って変換して確定するまでの間に、 10回以上呼ばれることも珍しくない。この回数の多さが、 このブロックの設計を決めている。
13-2 文字はまず、編集欄が自分の中だけで受け止める。 この時点では、周りのTag一覧や候補一覧は何も知らない。
技術的には 題名とコメントを 編集欄という部品の中の状態として持つ。 親の画面ではなく子の部品が持っているので、書き換わったときに 描き直されるのは編集欄の中だけで、Tag一覧も候補一覧も再計算されない。 「状態は、それを使う一番狭い範囲に置く」という原則そのままの形。
13-3 同時に、いまの下書きを親の画面が持つ控えの箱へ入れておく。 入れるだけで、画面は何も反応しない。
技術的には ここが要。 親の画面は下書きを「状態」ではなく「箱」として持っている。 状態に入れると値が変わるたびに画面が描き直されるが、 箱に入れる操作は画面を描き直さない。 つまり1文字ごとに最新の値は届いているが、誰も反応しないという状態を作れる。 これで「保存のときに最新の文が要る」という要件と 「入力中は何も計算したくない」という要件が両立する。
13-4 ただし1つだけ、画面に知らせることがある。 「題名が空かどうか」「コメントが空かどうか」。これが変わったときだけ伝える。
技術的には 前後の真偽を比べて、 変化があったときだけ状態を更新する。 つまり画面が描き直されるのは、0文字→1文字と、1文字→0文字の2回だけ。 2文字目から499文字目までは一切反応しない。 この値は保存ボタンを押せるかどうかと、その下の案内文 （「新タイトルを入力してください」「自分の言葉でコメントを入力してください」）に使われる。 画像の添付状態（アップロード中があるか、失敗があるか）も、 まったく同じ「境目だけ伝える」やり方で扱われている。
13-5 書き終えて、あるいは書いている途中で、 利用者が自分の意思で「入力内容からTag・ABC候補を更新」を押す。
技術的には このボタンは 下書きと推薦用の文が一致していると押せない。 「Tag・ABC候補は最新です」という表示に変わるので、 押す必要があるかどうかが見て分かる。 画像を足したり消したりしても、このボタンは反応しない―― 画像の操作が推薦を作り直すことは絶対にない（そのことを確かめる検査も書かれている）。
13-6 押されて初めて、そのときの下書きが親の画面へ「状態として」渡る。 ここで画面が描き直される。
技術的には 推薦用の入れ物には ノートのIDも一緒に入れる。ノートを切り替えた直後に 前のノートの文で推薦が走らないようにするため（IDが違えば、元の題名とコメントに戻す）。
13-7 画面は受け取った文で、Tagの点数とABC Noteの点数を計算し直し、並べ替える。 必要なら、まだ中身を読んでいないABC Noteの下読みも取りに行く。
技術的には 5番と6番が一斉に動く。 このときTag名やABC Noteの題名から作った2文字の並びの集合は、 1,200件まで使い回される――同じTag名を何度も刻み直さずに済むので、 2回目以降の更新は1回目より速い。 下読み（6番）も、まだ持っていないものだけを取りに行く。
13-8 保存は、右下のボタンでも、キーボードの Ctrl+Enter でもできる。
技術的には キー操作の受け取りは 画面全体に対して仕掛けられている。 コメント欄にいても、Tagの検索欄にいても、どこからでも保存できる。 押せる条件は5つ：Tagが1件以上、ABC Noteが1件以上（または新規作成の題名と親Tagが揃っている）、 題名が空でない、コメントが空でない、画像に「アップロード中」も「失敗」も無い。 押せないときは、ボタンの上にいま何が足りないかが1行で出る。
13-9 保存の処理は、画面が持っている推薦用の文ではなく、 控えの箱から最新の下書きを読む。これで書いた通りが保存される。
技術的には 箱の中身を読み、前後の空白を落として8番へ渡す。 ここに1つ、見た目と実際がずれる箇所がある。 編集欄の下にある「ABC Noteへの転記イメージ」は、 ボタンを押した時点の文（推薦用の文）を表示している。 一方で保存されるのは、いまこの瞬間の下書き。 つまり更新ボタンを押したあとに書き足して保存すると、 プレビューに出ていた文と、実際にNotionへ書かれる文が違う。 見出しには「（候補更新時のプレビュー）」と断りが入っているので嘘ではないが、 気付きにくい。保存されるのは書いた通りの最新の文なので、 内容が失われる向きの間違いではない。
※ 2026年8月14〜15日時点の zettelkasten-inbox のプログラムを読んで作成しました。過去の設計資料は参照していません。
※ 番号は全体図・この解説・シーケンス図で共通です。工程番号は「ブロック番号-連番」で書いています。