朝比奈幸太郎 プロフィール 空音開発 INSTAGRAM

オーディオ機器の製作・レストア記録に Obsidian を用いる ― 知識管理ツールとしての設計と運用

2026-05-19

朝比奈幸太郎リリース：音のアプリ使い放題プラットフォーム『空音開発』

本日は、オーディオ機器の自作およびヴィンテージ機材のレストアに従事する読者を想定し、知識管理ツールとして Obsidian を導入・運用する方法を解説していきます。

製作・レストアという営みは、部品ひとつひとつの選定、工程ごとの判断、調整時の実測値、つまずきとその解決、最終的な記事化や次回プロジェクトへの転用まで、長い時間軸にわたって情報を蓄積する作業ですので、紙のノートや散逸したメモアプリでは管理しきれない情報量を、構造化された形で保持し、後年検索可能にする手段として、Obsidian は有力な選択肢となるわけです。

Obsidianに関してはすでに世界中で第二の脳とも呼ばれており、筆者もObsidianなしの暮らしはすでに考えられないほど。
Claude Codeとももちろんフォルダパス経由で連携できますので、この二つはまさに現代必須のデジタルオフィスといっていいでしょう。

記事は四つのパートで構成していきます。
まず Obsidian を選ぶ理由を整理し、次に製作・レストア記録に必要な情報の三軸を提示。
続いて具体的なプラグイン構成を、最小構成から拡張構成まで段階的に示していきます。
最後に運用設計の実例として、フロントマター設計、テンプレート、ディレクトリ構造を解説。

1. なぜ Obsidian なのか

過去の記事のおさらいになりますが、Obsidian は Markdown ファイルをローカルに保存する形式のメモアプリケーションです。

文書はすべてプレーンテキスト保存されるため、特定のサービスや形式に依存しません。
アプリ自体が将来終了した場合でも、ファイルそのものはテキストエディタで開ける状態が保たれる点もポイントがかなり高いです。

Obsidian の二つ目の特徴は、ノート同士を双方向リンクで接続できる点。
たとえば「PCM1794A」というICの部品ノートを作成すると、そのICが登場する工程ノート、調整ノート、記事下書きノートすべてから参照され、逆にIC側のノートからもどこで言及されているかを一覧できます。
この双方向性は、製作中に「以前この部品でつまずいた経験はなかったか」を即座に確認する際にとても便利に機能します。

三つ目は、コミュニティプラグインによる拡張性。
データベース機能、テンプレート展開、PDF注釈、図表作成など、製作記録に必要な機能のほとんどはプラグインで実現できます。

2. 製作・レストア記録の三軸

製作・レストア記録に必要な情報は、三つの軸に整理できる。
この三軸を意識して Vault を設計することが、後年の検索性を決める。

第一の軸は部品データベースです。

個々の部品の型番、定数、耐圧、メーカー、調達元、実測値、用途ブロック、数量、状態などを構造化して保持することができます。

同じ部品が複数のプロジェクトで使われる場合、横断検索によって過去の採用実績や問題発生履歴を引き出せる状態を作る。

第二の軸は工程ログ。

日付ごとの作業内容、判断の根拠、つまずいた箇所と解決、撮影した写真、実測した電圧値や波形を時系列で残していきます。

記憶に頼って後から再構成すると精度が落ちるため、作業当日のうちに記録することが原則となります。

第三の軸は視覚情報です。

回路図、ブロック図、配線図、基板の写真、調整箇所のマップなど。
Obsidian はテキスト中心のツールであるため視覚情報の扱いは外部ツールや専用プラグインに委ねるが、視覚情報を本文ノートから参照可能な状態に保つ運用が必要となるわけです。

3. プラグイン構成（最小構成）

最初から多数のプラグインを導入する必要はありません。
製作・レストア記録に必要な最小構成として、次の五つを紹介しておきます。
ちなみに個人的にObsidianベストプラグインは、Kindleの同期プラグイン（過去の記事）が最高です。

Dataview ノートのフロントマターに記載した属性を、クエリ言語で動的に集計・表示できるプラグイン。

各部品をひとつのノートとして作成し、フロントマターに型番や定数を YAML 形式で書いておくと、「+112V系で使うコンデンサ一覧」「未実装の半固定抵抗一覧」のような動的リストを生成できます。

製作・レストア記録における中核機能となるでしょう。

Templater 新規ノート作成時に定型のテンプレートを自動展開できるプラグイン。
部品ノート、工程ログ、調整ログなど、書式が定型化されるノートを一貫した形式で作成できます。

記録の抜けや書式の揺れを減らす効果が大きい。

Excalidraw 手描き感覚で図を作成できるプラグインである。
ブロック図、信号フロー図、配線図、調整箇所マップなどを作成し、本文ノートに埋め込める。
雑誌や書籍の回路図を画像として読み込み、その上に注釈を重ねる用途にも適する。

Annotator PDF に直接注釈を入れ、Markdown 本文から参照可能にするプラグインである。
データシート、製作記事、書籍のPDFを Vault に取り込み、注釈付きで保存できる。

Longform 連載記事や長文の章立てを管理するプラグインである。製作記録を最終的にブログ記事化する段階で、章立て、ドラフト、登場部品、引用文献を一元化できる。

この五つで、フェーズ単位の工程記録から最終的な記事化まで一貫して運用可能である。

4. プラグイン構成（拡張構成）

最小構成に慣れた段階で、必要に応じて追加するプラグインを示す。

Bases Obsidian 公式のデータベース機能で、テーブル、カード、ギャラリー形式での一覧表示が可能である。

Dataview がクエリ言語によるプログラマブルな集計を得意とするのに対し、Bases は GUI 操作による視認性の高い表示に向いています。

部品カタログや工具リストなど、頻繁に閲覧するデータベースは Bases で構築する選択肢がある。

Image Toolkit 画像のズーム・パン・ライトボックス表示を提供するプラグインです。
基板写真やはんだ付け箇所の細部確認において、本文中の画像をクリックで拡大できる機能は実用上の価値が高いといえます。

Breadcrumbs ノート間の階層構造を明示するプラグイン。
連載記事化の際に章立てを整理する場面で有効です。

Tag Wrangler 階層タグの管理プラグイン。
#project/no199/phase4, #parts/ic/pcm1794a, #troubleshoot/oscillation のような階層タグを整理し、リネームや統合を一括で行える。

Linter Markdown の書式統一プラグインである。見出しレベル、リスト記法、YAMLフロントマターの順序などを自動で整える。
複数の記事を連載として書き上げる場面で、書式の揺れを抑えます。

5. フロントマター設計の実際

部品ノートのフロントマターは、後年の横断検索を可能にする鍵となる。
最初の設計に時間をかける価値があるのでじっくり考察していきましょう。

部品ノートの推奨フロントマター項目は次のとおりである。
type（部品種別：抵抗、コンデンサ、IC、真空管など）、value（定数）、tolerance（許容差）、voltage_rating（耐圧）、manufacturer（メーカー）、part_number（型番）、source（調達元）、measured_value（実測値）、project（使用プロジェクト）、block（回路ブロック）、status（在庫・実装済み・予備など）、notes_link（関連工程ログへのリンク）。

工程ログのフロントマターは、date（日付）、project（プロジェクト名）、phase（フェーズ番号）、block（対象ブロック）、duration（作業時間）、outcome（成功・部分成功・失敗・保留）、linked_parts（言及した部品ノート）、photos（添付画像）が中心となる。outcome を構造化しておくと、後年「失敗事例だけを抽出して教訓集を作る」というクエリが可能になる。

調整ログのフロントマターには、date、project、adjustment_target（調整対象：IVC Io、DSC ゼロバランスなど）、channel（L/R）、spec_value（規定値）、measured_value（実測値）、adjustment_position（半固定抵抗の位置）、environment（室温など環境条件）が必要となる。エージングによる経時変化を追う場合、environment は重要である。

ここに図解。
フロントマター項目の構造と、それぞれの項目がどのクエリで利用されるかを示すマトリクス。

6. ディレクトリ構造の設計

Vault のディレクトリ構造は、プロジェクト軸と部品軸のどちらを優先するかで二つの流派がある。

プロジェクト軸を優先する場合、ルートに Projects/No199/, Projects/Revox_A77/ のようにプロジェクトディレクトリを置き、その下に phases/, logs/, parts/, drafts/ を配置する。プロジェクト単位での作業中は見通しがよいが、複数プロジェクトを横断する部品データベースを作りにくい。

部品軸を優先する場合、ルートに Parts/, Tools/, Projects/, Knowledge/ を並列に置き、Parts/ 配下を部品種別で分類する。プロジェクトディレクトリは工程ログと記事下書きのみを保持し、部品への参照はリンクで行う。横断検索に強い構造となる。

長期的にオーディオ製作を継続することを前提とするなら、部品軸優先の構造が推奨される。最初のプロジェクト一件のみを記録するのであればプロジェクト軸でも十分機能するが、二件目以降で部品の重複が発生した時点で構造の見直しが必要になる。

ここに図解が入る。プロジェクト軸構造と部品軸構造のディレクトリツリー比較図。

【書き手加筆余地】書き手自身の Vault 構造を例示として開示するか、あるいは抽象的なモデルに留めるかの判断空間。

7. テンプレートの実例

Templater で展開するテンプレートの基本三種を示す。

部品ノートテンプレートは、フロントマターに前述の推奨項目を空欄状態で展開し、本文に「概要」「用途」「採用判断」「実測ログ」「関連リンク」の見出しを配置する。新規部品ノート作成時にこのテンプレートを呼び出すと、書き手は値を埋めるだけで一貫した形式のノートが完成する。

工程ログテンプレートは、フロントマターに date（自動で今日の日付を挿入）、project、phase、block を展開し、本文に「目的」「作業内容」「実測値」「つまずきと解決」「次回への申し送り」「撮影写真」の見出しを置く。「次回への申し送り」は記録の抜けを防ぐ重要な節となる。

調整ログテンプレートは、規定値と実測値を並べて記録する表組みを含み、半固定抵抗の調整方向（時計回り・反時計回り）と巻数を記載する欄を持つ。エージング後の再調整時に過去の調整位置を参照できる状態を作る。

【書き手加筆余地】書き手が実際にテンプレートを設計して気づいた、文書化されない暗黙の工夫を述べる空間。

8. Claude Code との連携

Obsidian Vault はローカルディレクトリとして保存されるため、Claude Code から直接読み書きできます。

これにより「Vault 内の部品ノートを走査して、特定のIC周辺で未確認項目があるノートを列挙する」「複数の工程ログから失敗事例を抽出して教訓集の下書きを生成する」といった処理が可能に。

連携の前提として、Vault ルートに CLAUDE.md ファイルを置き、フロントマターの書式、ディレクトリ構造のルール、添付ファイルの保存先、禁止される操作などを記述する。
Claude Code はこの規約を尊重した上でノートを生成・編集する。

ちなみに任意のサブディレクトリに CLAUDE.md を置くと、そのディレクトリ配下で作業する際に追加で読み込まれます。

Claude Code はカレントディレクトリから親方向にツリーを遡って CLAUDE.md を収集するため、深い階層ほど多くの規約が累積適用される形になります。

連携時の注意点は二つあり、第一に、Obsidian は内部リンクを [[ノート名]] 形式で扱うが、Claude Code が生成するリンクが Vault 内のノートと正確に対応しているかを確認する必要があります。

第二に、フロントマターの YAML 構文エラーは Dataview のクエリ失敗に直結するため、生成後の構文検証は必須。

出典・情報源

«    »