ショート一覧

結論

Codexに毎回ニュース収集を頼まず、定期的に結果を受け取るには、収集から通知までを予約します。僕は、CodexのクラウドでGitHubの指示書からニュースを生成・保存し、Discordへ要約と保存ファイルへのリンクを送る構成にしました。一回の予約実行で、生成・保存・受信まで確認しています。

この構成を試すには、GitHubの指示書と保存先、外部へ通信できるCodexのクラウド環境、Discordの通知先を用意します。

最新の開発情報を知るために、Codexへその日のニュース収集を頼む。これを繰り返す代わりに、集める条件と時刻を設定し、結果が通知で届くようにする使い方です。

ここでは、収集条件をGitHubの指示書に書き、Codexのクラウドへ毎朝の実行を予約します。届いた要約をDiscordで読み、気になるニュースの詳細はGitHubのMarkdownから開きます。Markdownは、見出しや箇条書きを付けられるテキスト形式です。

三つの役割を分けると、何を用意するかが見えます。

• Codexのクラウド環境：OpenAI側でニュース生成を実行する場所。GitHubの指示書を読み、指定時刻に処理を進めます。
• GitHub：収集条件を書いた news.md と、生成した詳しい結果の保存先。通知からそのファイルを開けます。
• Discord：要約と保存ファイルへのリンクを受け取る入口。専用URLへ送信するとチャンネルに投稿するWebhookを使います。

クラウドで動くので、自分のPCがスリープしていても処理を続けられます。手元のフォルダを使うローカル定期タスクにはPCとアプリの起動が必要なため、この用途では実行先をクラウドにします。クラウド環境、定期タスク

試す前の準備は、次のように分けられます。

• GitHubに、収集条件を書く news.md と結果の保存先を用意します。たとえば開発ツールの公式発表を集める、といった条件を指示書へ書きます。自分が管理し、Codexから読み書きできるリポジトリを使います。
• DiscordのWebhook URLを、処理が名前を指定して値を読める環境変数に登録します。
• そのリポジトリとDiscordへの通信を使えるクラウド環境を公開し、その環境を選んで新しいタスクの会話（クラウドチャット）を開きます。

僕はこのチャットで通知を試してから、ニュースの毎朝の予約を登録しました。その設定を維持したまま、同じ処理を一回だけ走らせる確認用の予約も追加しました。この確認用の予約では、ニュースのMarkdownとその一覧がGitHubへ保存され、Discordへの送信が成功し、僕自身も届いた要約とリンクを確認しています。

同じ構成を試すときは、予約が登録されたことだけで済ませず、生成物ができたか、GitHubに保存されたか、Discordで受け取ってリンクを開けたかを順に見ます。この三つがそろえば、収集を毎回依頼せずに、届いた通知から詳しいニュースを読める形を確かめられます。

結論

ローカルLLMを動かすには、重みだけでなく、その構造を解釈する設定、対応するトークナイザーと入力形式、それらを実行できる推論エンジンが必要です。重みファイルが手元にあることと、モデルを正しく実行できることは同じではありません。

重みは、学習で得た大量の数値です。ただし、その数値をどの層のどの場所へ配置するかは、モデルのアーキテクチャや設定が決めます。さらに、入力文字列をモデルが使うID列へ変えるトークナイザーも、モデルに対応していなければなりません。

チャット用モデルでは、会話を学習時に想定された制御トークンと並びへ変換するチャットテンプレートも確認します。同じ「userとassistantの会話」でも、モデルごとに期待する入力形式が異なるためです。

推論に必要なものは、大きく次の役割へ分けられます。

• モデル設定：層数や次元など、重みの構造を解釈する
• 重み：学習で得たテンソルを保持する
• トークナイザーと入力形式：文字列や会話をモデル用のID列へ変える
• 推論エンジン：対応形式を読み、CPUやGPUで計算を実行する
• 生成設定：logitから次のトークンをどう選ぶかを調整する

Safetensorsは、テンソルを保存する形式です。Hugging Faceのモデルでは、重みのほかに config.json やトークナイザー関連ファイルも使います。

GGUFはテンソルと推論用メタデータを一つのファイルへまとめますが、対応する推論エンジンが必要です。

参考：Using Transformers at Hugging Face、Chat templates、Safetensors、GGUF specification、llama.cpp

互換な一式を読み込めても、次は「重みファイルがメモリに収まるから実行できる」とは限りません。推論中には、重み以外のメモリも使います。

結論

LLMの入力を追うときは、トークンIDと、モデルが計算に使うベクトルを分けて見ます。トークンIDの大小や差を意味の近さとして読むと、語彙表を引くための番号と、意味や文脈を表す数値を混同してしまいます。

このスレッドでは、LLMの数値処理を「IDへの変換」「各層での更新」「生成時の再利用」「次のIDの選択」の順に追います。モデルの出力ログや生成設定を読むときも、いま見ている数値がどの段階のものかを切り分けられます。

LLMに文章を渡すと、まずモデルに対応したトークナイザーが、文字列をトークンの列へ変換します。トークンは必ずしも単語一つではなく、単語の一部や記号、バイト列、特殊トークンになることもあります。

各トークンには、モデルの語彙表に対応する整数のIDが割り当てられます。このIDは、語彙表の項目を指定するための番号です。たとえばID 120と121が隣り合っていても、二つのトークンの意味が近いとは限りません。

1. 文字列
2. トークン列
3. ID列
4. トークンごとの埋め込み

モデルは各IDを使って埋め込み層を参照し、各トークンの最初のベクトルを得ます。一方、意味検索などで使う文章埋め込みは、文章や段落などのテキスト全体を一つのベクトルとして比較するための表現です。どちらも「埋め込み」と呼ばれますが、表している単位と役割が違います。

参考：Tokenizer（Hugging Face Transformers）、Semantic Textual Similarity（Sentence Transformers）

IDから得たトークンのベクトルは、まだ周囲のトークンの情報を反映していません。次は、Transformerの層がこの表現をどう更新するかを見ます。

結論

外出先からTailscale経由で自宅PCをWake on LANで起こすときは、Subnet Routerが作るIP経路だけで成功を判断できません。LAN側でマジックパケットを送る常時起動端末と、スリープ中もネットワークアダプターが起動信号を待てる条件を分けて確認します。

Subnet Routerを有効にすると、Tailscaleを入れられないLAN内機器のIPアドレスへ通信できます。ただし、離れた場所からLAN内へブロードキャストする通信を、そのまま自宅LANへ転送する機能ではありません。

Wake on LANでは、対象PCを起こすマジックパケットをネットワークアダプターへ届けます。よく使われるのは、UDPを使って同じLAN内へ一斉に送る方法です。

Tailscale側：LANのIP範囲までの経路を作る
LAN側　　　：対象PCのネットワークアダプターへ
              マジックパケットを送る

そのため「LAN宛てのIP経路を設定したので、ブロードキャストも必ず届く」とは判断できません。実際の動作は環境によって変わります。確認する条件は次の4つです。

• 使うOS
• Tailscaleの設定
• Wake on LANを送るアプリ（WoLアプリ）
• マジックパケットの宛先

まず、同じLAN内から対象PCを起動できるかを確認します。

僕の構成では、起動中のAndroidを自宅LAN側へ置きました。外出先から操作し、PCが起動するところまで確認しました。

ただし、Android版TailscaleとWoLアプリが、受け取った通信をどのようにLANへ送るかは未確認です。構成を再現するときは、Android経由でLAN内のIPへ届くことと、WoL操作で実際にPCが起動することを分けて試します。

参考：Subnet routers、Kernel vs. netstack subnet routing

IP経路だけではWoLの成功を判断できず、LAN側でマジックパケットを送る役割が必要です。次は、スリープ中のPC自身がその役割を担えるかを見ます。

結論

Tailscaleを入れられない自宅LANの機器へ届きたいならSubnet Router、Web閲覧などのインターネット通信を別の端末から出したいならExit Nodeを選びます。違いは中継端末の名前ではなく、経路の宛先です。

どちらも、Tailscale端末を別の通信先への中継に使います。そのため設定画面だけを見ると似ていますが、クライアントへ配る経路が異なります。

Subnet Router
外出先の端末 → 自宅LANの特定範囲 → プリンターやNASなど

Exit Node
外出先の端末 → インターネット全体への経路 → Webサイトなど

Subnet Routerは、自宅LAN内の機器へ届けるためのIPアドレス範囲を、Subnet Router経由で使える経路としてTailscale端末へ知らせます。接続する側の端末は、その範囲宛ての通信だけをSubnet Routerへ送ります。目的は、Tailscaleを直接動かせないLAN内機器への到達です。

Exit Nodeは、インターネット全体へ向かう通信の経路を引き受けます。接続する側の端末が明示的にExit Nodeを選ぶと、Tailscale宛てや個別に設定したLAN向けの経路を除くインターネット通信がその端末を通ります。

僕は「何を置くか」ではなく、「どの宛先へ届けたいか」を先に決めます。LAN内の一部ならSubnet Router、インターネット側ならExit Nodeです。

参考：Subnet routers、Exit nodes

結論

外出先から自宅のIPv4端末へTailscaleで接続するときは、NATで届きにくいことと、安全対策が済んでいることを分けて考えます。そのうえで、自宅側と通信事業者側のNAT、Tailscaleの接続調整、実際の通信経路を順に追うと、ポート開放なしで接続できる理由を整理できます。

家庭のIPv4ネットワークでは、NAT（ネットワークアドレス変換）を行うルーターが、LAN内の複数端末を一つのグローバルIPv4アドレスへ対応付けます。LAN内の端末から外へ出た通信は対応表に記録され、その返答だけが元の端末へ戻ります。

反対に、外部から突然届いた通信に対応する記録や転送規則がなければ、通常そのままLAN内へ転送されません。

ここで起きているのは、外部から自宅LAN内の端末へ届く経路が作られていないということです。端末やアプリに脆弱性がないこと、許可された人だけが使えること、データが暗号化されていることまで保証しているわけではありません。

僕は次の二つを分けて考えます。

• 到達性：どの経路を通れば、目的の端末やサービスへ届くか
• 安全対策：誰の通信を許可し、何を暗号化し、端末をどう更新するか

Tailscaleのような仕組みでNATを越えて到達経路を作っても、安全対策が不要になるわけではありません。反対に、NATの内側に置いただけで安全対策が完成するわけでもありません。

参考：How NAT traversal works、Control and data planes

ここまでで、自宅ルーターのNATが外から突然届く通信を端末へ渡せない理由が分かりました。ただし、回線によっては自宅ルーターの外側にもNATがあります。次はCGNATで、なぜ自宅側のポート開放だけでは届かないかを見ます。

記事とショートの公開と未公開を、front matter（ファイルの冒頭に書く設定の並び）のフラグではなく、フォルダの場所で決めることにしました。

未公開のものは content/drafts/ に置き、公開するときは content/posts/<年>/ や content/shorts/<年>/ へフォルダごと移動します。ファイルの中身は編集しません。

これまではフラグを見るためにファイルを開く必要がありました。いまは公開の操作がフォルダの移動だけなので、開かなくても状態が分かります。

結論

Flutterで TextEditingController を使う入力ダイアログを作るなら、Controllerはダイアログの State で生成し、State.dispose で破棄します。showDialog の完了後も終了アニメーション中は入力欄が残るため、呼び出し側ですぐ破棄すると、表示中の入力欄から参照されるおそれがあります。

僕が実装した入力ダイアログでは、呼び出し側が showDialog の完了を待ってControllerを破棄すると、終了アニメーション中に「破棄後に使われた」というエラーが出ました。Navigator.pop で返り値が確定する時点と、画面からダイアログが取り除かれる時点は同じではありません。

そこでControllerをダイアログの State で作り、ダイアログが画面から取り除かれるときに呼ばれる State.dispose で破棄するようにしました。これなら、入力欄が残っている間はControllerも残ります。

Controllerの寿命は、それを作った関数ではなく、最後まで参照するWidgetに合わせるのが判断の基準です。

結論

JSONファイルの読み込み結果をSQLiteへキャッシュするアプリで差分更新を実装するなら、ファイルの追加・変更だけをテストして終えてはいけません。フォルダ削除は差分として検出されず、古い警告が残ることがあるため、更新対象が0件になる削除ケースもテストに含めます。

指定フォルダ内のJSONファイルを読み、結果と警告を一覧表示するローカルアプリで、画面表示用データをSQLite（アプリ内に組み込めるデータベース）へキャッシュとして保存しています。僕の実装では、ファイル差分だけでキャッシュを更新したところ、削除したフォルダに紐づく警告が画面に残りました。そこで、更新時に警告の参照先を確認し、存在しない対象の警告を削除しました。

ファイルの削除は変更として検出できました。一方、フォルダの削除はファイルの変更として検出されないため、フォルダがなくなっても警告の行だけがSQLiteに残っていました。

対策として、キャッシュの更新時に保存済み警告の参照先が実在するかを確認し、存在しないファイルやフォルダの警告を削除します。変更されたファイルが1つもない場合でも、この確認は省きません。

このようなJSON読み込み・SQLiteキャッシュ・ファイル差分更新の構成を使うなら、フォルダ削除後にも古い警告が消えるかをテストする必要があります。差分更新のテストでは、ファイルを追加・変更する処理だけでなく、参照先が消えた後に警告を削除できるかも確認します。

手元のHTMLを分野ごとのフォルダへ整理したら、ページ間のリンクがまとめて切れました。../別分野/index.html のように、今いるファイルからの位置でリンクを書いていたためです。

ファイルを移すと、リンクに必要な ../ の数も変わります。今後もフォルダ構成を直す前提だったので、置き場所を基準にするリンクをやめることにしました。

僕のブログでは、ショートを1件共有するときも、共有先は個別ページではなくショート一覧にしました。URLには一覧内の特定位置を指すアンカーが付き、該当するカードを示します。

ショート一覧でカードを選ぶと、別ページへは移らず、ブラウザのアドレスバーにあるURLだけが変わります。選んだカードは枠で強調され、URLをコピーするボタンも同じ一覧内アンカーを返します。

共有されたURLを開くと、一覧が該当カードの位置までスクロールします。その前後には、ほかのショートもそのまま並びます。

Hugoを選びましたが、将来も使い続けるとは決めていません。僕は別のツールへ移るとき、記事本文とデザインまで作り直すのは避けたいと考えました。

そこで、記事本文はHugo固有の記法を入れないMarkdownで書き、Hugoのショートコードは使わないことにしました。装飾はCSS、動きはJavaScriptに分け、Hugoだけで動く処理はテンプレートと設定にまとめています。新しくHugo固有の機能を使う場合は、専用の処理をまとめた一覧へ追記します。

haruki256.comの本番を、WordPressからHugoへ切り替えました。切り替え前にデータベースとファイル一式をバックアップし、Hugoの生成物は公開先とは別のフォルダへ展開しています。

WordPressは削除せず、public_html を別名に変えてからHugo側と入れ替えました。公開後は主要ページ、CSS、JavaScript、SVG、RSS、サイトマップ、404、HTTPSへの転送を確認しています。

問題があればHugoを別の場所へ動かし、WordPressのフォルダ名を public_html へ戻します。切り替える方法だけでなく、問題が起きた場合に戻す方法も先に用意しておきました。

WordPressから取り出した旧記事は、Hugoへ移したからといって、すべて公開し直す必要はありません。

このブログでは、公開されていた7本と旧下書き6本をMarkdownで手元に残し、13本すべてを非公開にしました。以前の公開URLは記録用の legacy_url に残しますが、Hugoの公開先には使いません。

新しい記事は /:year/:month/:day/:slug/ の形式で、slugを英小文字のkebab-caseに統一します。旧記事を将来書き直して公開する場合だけ、新URLと転送を設定します。

結論

HTML教材で誤答した学習項目から復習先を探すなら、学習項目同士の「先に理解する項目から、後で学ぶ項目へ」という関係をJSONで持ちます。誤答した項目のIDだけでは、その項目より先に理解しておくべき項目のどれでつまずいたかまでは分からないため、関係を逆向きにたどって復習候補を出します。

「HTML教材の採点結果は、問題文ではなく学習項目IDに結び付ける」では、問題の正誤と学習項目IDを一緒に残す設計を書きました。ただし、誤答したIDから分かるのは、その問題が扱う学習項目です。

そこで僕は、学習項目同士の直接の前提関係をJSONで表しました。たとえば「関数」の前提が「変数」、「変数」の前提が「値」なら、関数の問題で間違えたときに、関係を逆向きへたどって変数と値を復習候補として並べます。

このJSONが示すのは、教材内で決めた学習項目の前後関係です。復習候補を整理するために使い、学習効果を測った結果としては扱いません。

結論

ブラウザで問題を解くHTML教材を作るなら、採点結果には正誤だけでなく、問題が扱う学習項目の固定IDも残します。問題文を後から直しても同じ項目の誤答として追えるため、復習対象を文章の比較に頼らず選べます。

「HTML教材の必須構成を、目視チェックリストからスクリプト検査へ移した」では、僕が章ごとのHTML教材を作り、各章に理解を確かめる問題を置いていることを書きました。その問題の採点結果を後から復習へ使うため、問題文とは別に、その問題が扱う内容を表す学習項目IDを持たせました。

たとえば関数を扱う問題なら、採点結果へ正誤と concept-functions を一緒に残します。

これなら問題文を読みやすく書き直しても、同じIDの結果を同じ学習項目として扱えます。問題が扱う学習内容そのものを変えるときだけ、新しいIDに分けます。

正誤はその問題の結果、学習項目IDは復習する範囲を特定する手がかりとして、役割を分けて残します。

僕は、ソフトウェアアーキテクチャなどを学ぶための教材を、1章につき1つのHTMLページとして作っています。各章は、見出しで学ぶ内容を分け、図で関係を示し、問題で理解を確かめ、復習リンクから前の項目へ戻れる構成です。

章の中から必要な要素が1つ抜けても、HTMLページ自体はブラウザに表示されます。そのため、章を追加するたびに目で探すだけではなく、必要な要素が欠けていたらエラーにするスクリプトを書きました。

スクリプトへ章のHTMLを渡すと、見出し・図・問題・復習リンクを順に探します。どれかが欠けた章はエラーになり、すべて含む章だけが検査を通ります。

この検査で分かるのは、必要なHTML要素が存在するかどうかです。画面上のカード配置や図の読みやすさは、別に画面を見て確認します。

haruki256.comを、WordPressからHugoへ移す作業を始めました。

WordPressに大きな不具合が起きたわけではありません。記事をMarkdownで手元に置き、gitで変更を追い、公開環境では静的ファイルだけを配信する形が、これからの運用に合うと判断しました。

調査時点の投稿は7本で、承認済みコメントは0件でした。移行コストがまだ小さい今のうちに、既存URLを保ったまま切り替えられるか検証しています。

僕は、検索結果を生成AIへ渡して回答を作るRAGを実装しました。質問に関連するノートの一部を、回答用の情報としてチャットモデルへ渡します。回答だけを表示すると、どのノートが候補に入ったのか分かりません。

そこで、回答の下に「参照ソース」欄を置き、検索で選ばれたノートのパスと見出しを表示しています。見出しがない場合は、ノートのタイトルを表示します。

参照ソースは、回答が正しいことの保証ではありません。どのノートが候補だったかを確認するための手がかりとして使います。

僕は、Obsidianに蓄積したMarkdownノートを探すデスクトップアプリを作っています。名前や用語の一致だけでなく、内容の近さからも候補を出せるように、検索方式を一つに絞りませんでした。

実装では、BM25（単語の一致度で順位を付ける全文検索）と、ONNX形式のモデルで内容の近さを数値化するベクトル検索を使います。検索用のベクトルを用意できている場合は、同じ検索文を両方に渡します。二つの順位はRRF（複数の検索順位を一つにまとめる方法）で統合します。

ベクトルを利用できないときは、BM25の結果だけを返します。利用者に検索方式を選ばせず、一つの検索欄で扱う設計です。

結論

Obsidianで一つの焦点に絞った考えをZettelとして残し、親子関係を階層IDで管理するなら、IDの移動機能では自分自身・子孫への移動を拒否します。利用者が指定した新IDが別のノートですでに使われている場合も、書き込み前に止めます。循環やIDの重複ができると、親子ツリーを一意にたどれなくなるためです。

「Obsidianの階層Zettel IDを移すときは、子孫IDの対応表を先に作る」では、親ノートを移す前に子孫までの新旧ID対応表を作る判断を書きました。

僕は、Obsidianで一つの焦点に絞った考えをZettelとして残しています。ノート先頭には、親子関係を表す一意のZettel IDを付けています。

このIDを管理するために自作プラグインを作りました。Obsidian標準の機能ではありません。

移動先が自分自身または自分の子孫なら、親をたどると元のノートへ戻る循環ができます。指定した新IDが移動元以外で使われていれば、複数ノートへ同じIDを割り当てる衝突になります。僕のプラグインでは、どちらも対応表をノートへ反映する前に拒否します。

これは、実行前に分かる不正な移動を止める処理です。書き込み開始後に保存が失敗した場合は自動で元へ戻らないため、実行前のバックアップと実行後のID照合は別に必要です。

結論

Obsidianで階層Zettel IDを移すなら、親ノートのIDだけを書き換えず、先に子孫までの新旧ID対応表を作ります。親のIDだけを 1 から 3 に変えると、子と孫のIDが古いまま残り、親子関係がずれるためです。

「Obsidianの親子ノートIDを手作業で管理しにくくなり、自動採番プラグインを作った」では、階層IDの採番と重複確認を自作プラグインへ切り出した経緯を書きました。続く「Obsidianの親子ノートIDを自動採番し、子作成とツリー表示まで行うプラグイン」では、子ノートの作成とツリー表示までの設計をまとめています。

僕は、Obsidianノートの置き場所とは別に、考えがどのノートから派生したかをZettel IDで管理しています。1.a は 1 から派生したノート、1.a.1 は 1.a から派生したノートを表します。今回は、フォルダや分類番号ではなく、このIDが表す親子関係を別の位置へ移す話です。

僕の自作プラグインは、変更するノートとその子孫を集め、次の対応表を作ってからfront matter（ノート先頭のメタデータ）へ反映します。Obsidian標準の機能ではありません。

1       → 3
1.a     → 3.a
1.a.1   → 3.a.1

対応表は親から子へ順にたどり、新しい親IDに合わせて子のIDを付け直して作ります。1 を 3 へ移した後も、子は 3.a、孫は 3.a.1 という関係で保存されます。

プラグインは、表にあるノートを1件ずつ保存します。途中で失敗しても自動では元に戻らないため、実行前にVault（Obsidianのノート保管場所）をバックアップします。実行後は、各ノートのIDが対応表の新しい値と一致するかを見比べます。

結論

Obsidianで1、1.aのようなIDを使ってZettelの親子関係を表すなら、次の子IDを選ぶ処理と重複確認は自動化できます。人は「どの考えから派生させるか」を決め、連番の管理をプラグインに任せれば、IDを考えの親子関係だけに使えるようになります。

僕のVault（Obsidianのノートをまとめる保管場所）では、自分の考えを一つの焦点へ絞ったノートをZettelとして残しています。1の考えから派生したZettelには1.a、さらにそこから派生したZettelには1.a.1というIDを付けます。

「NDCは主題、Zettel IDは考えの派生に使う」で書いたように、このIDの役割はノートの分類ではなく、考えの親子関係を残すことです。

Zettelが増えると、新しい子を作るたびに、次の三つを手作業で行う必要がありました。

• 同じ親の子IDを調べる
• 次に空いているIDを選ぶ
• 既存のIDと重ならないか確かめる

考えを書く前にこの三つを毎回行うことが、手作業では負担になりました。

そこで、階層Zettel IDの管理だけを補助するObsidianプラグインを作りました。ツリーで親を選んで子を追加すると、プラグインが既存の直下の子IDを調べ、空いている最初のIDを付けたノートを作ります。たとえば1.aと1.bがあれば、次は1.cです。

どの考えを親にするかと、新しいZettelに何を書くかは僕が決めます。プラグインへ任せたのは、その判断の後に繰り返していたIDの割り当て（採番）と重複確認です。

結論

Obsidianで1ノート1焦点のZettelを整理するなら、僕はNDC（日本十進分類法）を参考にした分類番号を、ノートの主題に使います。1から1.aのようなZettel IDは、どの考えから派生したかという親子関係に使います。主題と考えのつながりを、一つの番号で表さないためです。

僕のVault（Obsidianのノートをまとめる保管場所）では、Zettelを1ノート1焦点で残しています。Zettelは、自分の考えを一つの焦点へ絞ったノートです。

「外部資料から自分の考えまでを、3つのレイヤに分ける」では、Zettelを自分の思考を置くレイヤとして分けました。そのZettelを増やしていくと、ノートの主題と、どの考えから発展したかを別々にたどりたくなりました。

そこで、僕のVaultでは二つの番号へ別の役割を持たせています。

• NDCを参考にした分類番号：そのノートが何について書かれているかを表す
• 1、1.aのようなZettel ID：どの考えから発展したかを表す

ここでの分類番号は、日本十進分類法を参考にしてノートの主題を表す、僕のVault内の運用です。一方のZettel IDは分類には使わず、1.aなら1から発展した考え、という派生関係だけを表します。

同じ主題のノートでも、考えの派生関係が別ならZettel IDは別になります。反対に、ある考えから派生した流れが続いていても、焦点が別の主題へ移れば分類番号は見直せます。

この二つを分けておけば、主題に合わせてノートの置き場を変えることと、考えの親子関係を変えることを、同じ操作として扱わずに済みます。

結論

Obsidianで本や記事を読みながらメモするなら、要約・引用は外部資料のノートに残し、そこから生まれた自分の考えはZettel（1ノート1焦点で残す自分の考えのノート）へ分けます。出典と自分の解釈の境界を、あとからたどれるようにするためです。

僕はObsidianのVault（ノートをまとめる保管場所）を、外部資料と自分の考えの両方を残す場所として使っています。

「ObsidianのVaultを、情報の役割ごとに構成する」では、Vault全体の置き場を役割で分けました。その中でも、書籍や記事を読んだ記録は、次の2つを同じノートへ混ぜないようにしています。

• 外部資料のノート：著者の主張、要約、引用、出典
• Zettel：読んだ内容から、自分の考えを一つの焦点に絞ったノート

僕のVaultで読書由来のZettelに残すのは、本の内容を章ごとにまとめ直したものではありません。元資料を読んで生まれた自分の考えを、一つの焦点へ絞ったものです。

自分の考えが独立したときは、元の要約へ書き足さず、新しいZettelから考えの元になった外部資料のノートへリンクします。これにより、どこまでが資料の内容で、どこからが自分の解釈なのかを分けて読み返せます。

ただし、短い引用に一言だけ感想を添えた段階では、無理にZettelへ切り出しません。あとから単独で考え直したい焦点になったときに、初めて別のノートにします。

結論

Obsidianで複数種類の情報を同じVault（ノートの保管場所）に置くなら、Vault直下は情報の役割ごとに分けます。主題だけで分けると、同じ分野の資料と自分の考えが混ざるためです。Zettel（1ノート1焦点で残す自分の考え）は、その中の一つの役割として置きます。

僕はObsidianを、Zettel専用ではなく、自分の情報をためて整理する場所として使っています。

同じVaultには、役割の異なる情報を置いています。

• 書籍や記事などの外部資料
• あとから参照する事実や用語
• 試して得た手順や、整理した知識
• 1つの焦点に絞って残した自分の考え
• アイデア、計画、外部向けの成果物

これらを最初から技術、社会、芸術といった主題だけで分けると、同じ主題について集めた資料と、自分で考えたことと、実用できる形に整理した知識が同じ場所へ混ざります。

そこで、情報を何に使うかで、Vault直下の最初のフォルダを分けています。その内側で、必要に応じて「何について書かれているか」を主題として分類します。

この構成では、Zettelは自分の考えを1ノート1焦点で残す置き場です。Vault全体をZettel中心の構成にせず、ほかの情報と区別して扱うための一つの役割として使っています。