Zettelkasten Inbox ／ ブロック詳細
保存とは別のもう1つの出口。Notionのゴミ箱へ移すだけで、完全に消す経路はどこにも無い。処理済みのノートは捨てられないという制約が、知識の網を守っている。
抽象度 Lv.4（技術用語＋システム上のやりとりまで／製品名・ライブラリ名は書かない）受信箱には「読んだけれど、知識にするほどではなかった」ものも溜まる。 それを1件ずつ片付けるための、保存とは別のもう1つの出口。
やることは1つだけ――Notionのゴミ箱へ移す。 本当に消すのではないので、気が変わればNotion側で戻せる。 アプリからデータを完全に削除する経路は、どこにも用意されていない。
10工程しかない小さなブロックだが、8番と同じ「待ち行列 → 状態の確認 → 書き込み → 照合」 という型をきちんと守っている。
3. 本文の取り出し（内容を見て判断） → 9. ノートの削除 → 2番の控えを捨てて次のノートへ
DELETE /api/notes/{id}。詳しくは5章の各工程に書いた400409（すでに処理済みのものは、この経路では捨てさせない）in_trash: true に更新するin_trash を確認し、立っていなければ 502本文を見たあとでなければ判断できない。削除ボタンは、 題名・要約・原典プレビューが並んだ画面の中に置かれている。 「中身を見てから捨てる」という順序が、画面の配置そのもので担保されている。
処理済みのノートを削除させない理由。タグやABC Noteが付いている＝ すでにどこかのABC Noteの本文から引用されている可能性がある。 それをゴミ箱へ移すと、ABC Note側のリンクが行き先を失う。 だからこの経路では「まだ何にも使われていないもの」しか捨てられない。
完全な削除を用意しなかった理由。ゴミ箱への移動なら取り返しがつく。 個人の知識の受信箱という性質上、「間違えて捨てた」が起きたときの損失が大きいので、 元に戻せる操作しか置かない、という判断に見える。
修正モードで削除ボタンを消す理由。全体マップから開いたノートは、
定義上すでにTagかABC Noteが付いている。9-5 の検査で必ず 409 になるので、
押しても失敗するボタンを最初から見せない。
| 工程 | 主体 | やりとりの内容 | 方向 |
|---|---|---|---|
| 9-1 | ブラウザ（内部） | 題名入りの確認ダイアログ | ↻ |
| 9-2 | ブラウザ → 削除API | 対象ノートのID | → |
| 9-3 | 削除API（内部） | IDの形の検査と、待ち行列への参加 | ↻ |
| 9-4 | 削除API → Notion | 現在のページの取得 | → |
| 9-5 | 削除API（内部） | DBの確認と、未処理かどうかの判定 | ↻ |
| 9-6 | 削除API → Notion | ゴミ箱への移動 | → |
| 9-7 | 削除API（内部） | 移動できたかの照合 | ↻ |
| 9-8 | 削除API（内部） | 受信箱と全体マップの控えを捨てる | ↻ |
| 9-9 | 削除API → ブラウザ | 移動したことの報告 | ← |
9-1 「このノートを削除」を押すと、題名を出したうえで確認を求める。 そこには「後から復元できる」ことも書いてある。
技術的には ブラウザ標準の確認ダイアログを使い、 本文に対象の題名をそのまま入れる。 「本当に削除しますか」ではなく「『◯◯』をNotionのゴミ箱へ移動しますか？」と 書くことで、対象の取り違えを防いでいる。 「取り消し」を選べばそこで終わり、通信は起きない。
9-2 確認が取れたら、サーバーへ削除を頼む。
技術的には DELETE /api/notes/{id}、
本文は無し、Cache-Control: no-store。
削除に DELETE というメソッドを使っているのは、
この操作が「対象を取り除く」ことを表すため。
同じパスの GET は本文の取得（3番）で、
メソッドだけで意味が分かれている。
9-3 IDの形を確かめてから、そのノート専用の順番待ちの列に並ぶ。 同じノートの保存が走っていれば、終わるまで待つ。
技術的には 検査は3番と同じく 16進とハイフンで32〜36文字という緩い条件。 待ち行列は8番の保存とまったく同じ列を使う（鍵はノートのID）。 これが重要で、「保存の最中に削除が走る」という最悪の組み合わせを防いでいる。 もし同時に走れば、8番が転記を終えた直後に9番がノートをゴミ箱へ移し、 ABC Note側のリンクだけが残る、という壊れ方になる。
9-4 Notionから、いまのページの状態を取り直す。 画面に出ている情報は古いかもしれないので、信用しない。
技術的には GET /v1/pages/{id} 1回。
関連づけを全部たどる処理はしていない――
ここで見たいのは「1つでも付いているか」であって、全部の中身ではないため。
ページ取得の応答に含まれる範囲（最大25件）に1つでも入っていれば十分。
9-5 2つ確かめる。本当にLiterature Notes DBのノートか。 そして、まだ何にも使われていないか。
技術的には
(1) 親の種類が「データソース指定」で、そのIDがLiterature DBと一致するか。
違えば 400 ＋「対象はLiterature Notes DBのノートではありません。」
――Tag DBやABC DBのページのIDを送りつけても、このAPIでは消せない。
(2) タグ欄かABC欄に1件でも関連があれば 409 ＋
「このノートはNotion側ですでに処理されています。画面を更新してください。」。
この2つは8番の 8-5・8-6 とまったく同じ考え方で、
書き込む2つの経路が同じ前提を共有している。
9-6 Notionのゴミ箱へ移す。ページそのものは消えない。
技術的には PATCH /v1/pages/{id} に
{"in_trash": true}。
Notionには「ページを完全に消す」APIが無いので、
これが可能な最も強い削除になる。ゴミ箱の中身は30日ほどで自動的に消えるが、
それはNotion側の動作であってアプリは関与しない。
9-7 返ってきたページに、本当にゴミ箱の印が立っているかを確かめる。
技術的には 更新の応答に含まれる in_trash が
真かどうかだけを見る。違えば 502 ＋「Notionのゴミ箱への移動を確認できませんでした。」。
更新の応答をそのまま照合に使っているので、
8番のように改めて取り直す往復は発生しない。
1回の要求で「変更」と「確認」の両方を済ませているのが、このブロックの効率の良さ。
9-8 成功したら、受信箱と全体マップの覚え書きを捨てる。
技術的には 5番・8番と共通の関数を呼ぶだけ。 2つの控え（30秒のものと5分のもの）を同時に無効にする。 削除したノートが、控えのせいで一覧に残り続けるのを防ぐ。
9-9 結果を返す。画面は一覧からそのノートを外し、次のノートへ進む。
技術的には 200 ＋
{"id": "…", "inTrash": true}。
画面側は8番と同じく再読み込みをせず手元のデータを直す。
次に選ばれるのは、消したものと同じ位置のノート（つまり1つ下にあったもの）。
「Notionのゴミ箱へ移動しました。」という帯が3.2秒だけ出る。
400 ＋「ノートIDが不正です。」。Notionへは行かない。400 ＋
「対象はLiterature Notes DBのノートではありません。」409 ＋「画面を更新してください。」。
何も書かない。画面の題名の下に赤い文字で出る。502 ＋
「Notionのゴミ箱への移動を確認できませんでした。」。
移動は実際には成功しているかもしれないが、控えは捨てられないので、
画面には残ったままになる。※ 2026年8月14〜15日時点の zettelkasten-inbox のプログラムを読んで作成しました。過去の設計資料は参照していません。
※ 番号は全体図・この解説・シーケンス図で共通です。工程番号は「ブロック番号-連番」で書いています。