Obsidian Vault Template for AI Engineering Notes

AIコーディングエージェントと共同で開発ノートを運用するための、 エンジニア向けObsidian Vaultテンプレート。

AIが書庫係、Obsidianが閲覧室。

日常のノート作成・更新はAIエージェントに任せ、
Obsidianアプリは Home・Bases・Backlinks・Graph で情報を俯瞰するために使う、
という分担を前提に設計。

誰の・何のためのテンプレートか

開発案件に途中から参画するエンジニアが、GitHub（Issue / PR）を起点に働きながら、
キャッチアップの過程と日々の学びを AI エージェントとの分業で
「読めるメモ」ではなく再利用・鮮度確認できる作業資産にするために設計している。

ユースケースと受け皿

ユースケースは inbox の消化レーン（queue）とフォルダにそのまま対応する。

ユースケース	例	受け皿（レーン / フォルダ）
担当Issueの対応	調査・設計判断・レビュー対応の文脈維持と引き継ぎ	gh-issue / 10_workspace/github-issue/
自分の作業に影響する内容の把握	ADR・設計方針の確認、他メンバーPRの分析、セルフレビュー品質の向上	pr-analysis / 20_knowledge/decision/・30_operation/checklist/
開発環境・AIハーネスの改善	devcontainer / AIエージェント等のつまずきの runbook 化	harness / 30_operation/runbook/・40_source/incident/
汎用知識の蓄積	案件に紐づかない技術理解	knowledge / 20_knowledge/concept/・pattern/

活用の流れ（3層）

日々の記録は AI に任せて「取り込むだけ」、人間は週次の判断（curation）に集中する。

いつ	誰が	すること
タスク区切り	人間の操作は2つだけ	/vault-capture <topic> を実行（次のアクション更新はAIが行う）→ 提示された /export をコピペ実行
1日の終わり	AI	/vault-distill — ログを読み、Workspace反映・既存ノートとの照合・draft作成（queue付与）・蒸留台帳更新まで行う
週次	人間	Home の消化キューで draft を消化し、昇格待ち（in-review）の canonical 化を判断し、鮮度切れを見直す

取り込み口はテキストログなら何でもよい（推奨は Claude Code CLI の /export。
Desktop App や他のエージェントで作業した日は、対応内容のまとめを md でログ置き場へ置けば同じ蒸留に乗る）。
日次が「取り込むだけ」で済む一方、週次の昇格判断を人間が回すことは省略できない
（capture first, curate later。ここを止めると draft が堆積する）。

特徴

• フォルダ = 情報の役割（トピック別の棚ではなく、情報がどの段階にあるかで分類）
• 状態 = Properties（status等のYAML frontmatter。状態変化でファイルを移動しない）
• 巡回 = Bases（「消化キュー」「昇格待ち」「作業中の一覧」「鮮度切れ」はフォルダではなくビューで見る。
  inbox は消化レーン queue でカテゴリ別に消化し、付け忘れは「未分類」ビューに浮かび上がる）
• AIの出力はDraft止まり（canonicalへの昇格は人間が判断する。
  in-review は昇格候補にのみ使う）
• canonicalは鮮度確認可能な作業資産（verified_commit を基準点に
  git diff <verified_commit>..HEAD -- <source_refs> で実コードとの差分から鮮度を判断する）
• 運用負荷は最小（タスク区切りの同期義務は「次のアクション更新 + /export」の2操作だけ。
  ノート化はログの蒸留でAIが行い、例外記録主義で量を抑える）

構成

.
├── Home.md            # 入口。Basesの埋め込みと導線だけを置く
├── 00_inbox/          # 保存先が未確定な情報の一時置き場（フラット）
├── 10_workspace/      # 進行中の作業（Issue対応・成果物づくり・調査）
│   ├── github-issue/  #   担当Issueごとの作業ホーム
│   ├── project/       #   Lookback・Checklist作成・Skill開発など自己起点の成果物
│   └── investigation/ #   改善仮説・障害の調査
├── 20_knowledge/      # 再利用可能な検証済みの理解
│   ├── concept/       #   「Xとは何か」
│   ├── pattern/       #   「どんな状況で何を選ぶか」
│   ├── decision/      #   採用した判断（チームADR/TDRへの索引 + 個人の横断判断）
│   └── product-context/ # リポジトリ・環境固有の構成知識
├── 30_operation/      # 次回の行動に直接使う資産
│   ├── checklist/     #   実装・レビュー前に確認する質問の原本
│   └── runbook/       #   実行手順 + ツール・Scriptへの入口
├── 40_source/         # 一次資料への入口と観測記録（Literature Notes相当）
│   ├── pull-request/  #   PR分析・Lookbackの事実面
│   ├── incident/      #   障害の証跡（発生日prefix）
│   ├── code-reading/  #   コードリーディングの観測結果
│   ├── external-research/ # 外部記事・ドキュメントからの観測結果
│   └── claude-code-session/ # セッションexportログの蒸留台帳
└── 90_system/         # Vaultの運用機構（規約の正本・テンプレート・ビュー定義）
    ├── template/      #   ノートテンプレート
    ├── base/          #   .baseファイル（保存済みビュー）
    └── skill/         #   Claude Code Skillのひな形（vault-capture / vault-distill）

各フォルダの詳細な運用ルールは、それぞれの README.md を参照。

フォルダ	README
進行中の作業	10_workspace/README
検証済みの知識	20_knowledge/README
手順・チェックリスト	30_operation/README
観測記録・証跡	40_source/README
一時置き場	00_inbox/README
運用機構と命名規約	90_system/README

設計原則

1. 役割の4分類を崩さない — 作業中の文脈（workspace）/ 検証済みの理解（knowledge）/
   次回の行動（operation）/ 根拠への入口（source）。保存先に迷ったら00_inboxへ
2. 状態でファイルを移動しない — 完了したWorkspaceはstatus: archivedで同じ場所に残す。
   文字列パス参照（source_refs・スクリプト・AIプロンプト）を壊さないため
3. 日付フォルダを作らない — 時系列はactivity-log.mdとGit履歴へ。
   例外はincidentのファイル名prefix（発生日が識別子になるため）
4. 例外記録主義 + capture first, curate later — routineは書かない。
   判断・例外・昇格候補の学びだけをノート化する。タスク区切りの同期義務は
   「次のアクション更新 + /export」の2操作だけで、activity-logへの追記とノート化は
   ログの蒸留（その日の終わり・/vault-distill）でAIが行う
5. 原文を複製しない — 一次資料・実行可能なScript・設定はVault外の実体を正とし、
   Vaultには入口（source_refs・Tool情報）だけを置く
6. AIの出力は人間が昇格する — AIはdraftの作成まで。
   canonical化・原本Checklistの変更・Knowledgeへの昇格は人間が判断する
7. 横断分類はPropertiesへ — areas / technologies / topics等で表し、
   深い技術分類フォルダを作らない

はじめ方

1. Vaultとして開く

このリポジトリをcloneし、Obsidianで「Open folder as vault」する。

2. アプリの初期設定

• Settings → Files and links → Automatically update internal links を有効化
• Default location for new attachments → In subfolder under current folder → attachment
• Settings → Templates → Template folder location を 90_system/template に設定
• Settings → Core plugins → Daily notes を無効化（日付フォルダを使わない設計のため）

3. 最初のWorkspaceを作る

担当しているIssueを1件選び、10_workspace/github-issue/gh-<番号>/ を index.md + activity-log.md + note/ の最小構成（Tier 1）で作る。 構造は必要になってから昇格させる（10_workspace/README参照）。

4. AIエージェントと接続する

記録フローの入口は user scope Skill 2本（ひな形とインストール手順は 90_system/skill/README）。Claude Code等から運用する場合の依頼例:

GitHub Issue #1234 のWorkspaceを
10_workspace/github-issue/gh-1234/ にTier 1で作成する。
テンプレートは 90_system/template/workspace.md を使う。

（タスク区切り）
/vault-capture gh-1234-design
→ index.md の「次のアクション」が更新され、コピペ用の /export コマンドが提示される。
  /export の実行は人間が行う（ログはVault外のログ置き場へ）

（その日の終わり）
/vault-distill
→ 未蒸留の最新ログを読み、Workspace反映・activity-log追記・既存ノートとの照合・
  00_inbox への draft作成（queue付与）・蒸留台帳の更新までを行う。
  昇格候補は in-review に上がるが、canonical 化は人間が判断する

エージェント向けの読み込み順とルール（蒸留手順の正本を含む）は 90_system/agent-entry.md に集約する
（AI設定ファイルには長文を書かず、ここへの参照だけを置く）。

kepano/obsidian-skills を導入すると、 エージェントがWikilinks・Properties・Basesの構文とObsidian CLIの操作を扱えるようになる。

命名規約

トップレベル・第2階層   NN_role / role（英語・単数形・小文字、複合語はkebab-case）
個別ノート・フォルダ     英語kebab-case（gh-1234, decision-adopt-feature-flag.md）
日本語表示が必要なノート aliases Propertyに日本語名を追加

番号prefixは表示順の制御であり、Johnny.Decimal準拠ではない。

Properties（最小セット）

---
type: project | research | knowledge | decision | source-index |
      incident | checklist | runbook | log
status: draft | in-review | canonical | superseded | archived
created: 2026-01-01
updated: 2026-01-01
source_refs: []     # 由来があるノートは必須（リポジトリルート基準パス）
verified_at:        # 陳腐化する内容（ツールのバージョン依存等）は必須
verified_commit:    # 実コード依存の昇格資料は必須（source_refsとのdiff基準点）
---

「作業中」はstatusがarchived以外であることから導出する（activeという値は使わない）。
語彙の正本は 90_system/property-schema.md。

License

Copyright (c) 2026 yuji91. All rights reserved.

閲覧・参考のための公開です。内容の複製・改変・再配布には事前の許可が必要です。 詳細は LICENSE を参照してください。