Obsidianテンプレート実例7選｜デイリー・PARA・読書メモ

『Obsidian』でテンプレート運用を始めたい人に向けて、コアテンプレート機能と『Templater』の違いから、実際に使える代表テンプレートまでを整理します。
結論として、日常運用では『Templater』を入れないとできることが一気に狭くなり、呼び出しの手間も残ります。
導入手順は4ステップで迷いにくく、デイリーノートから週次レビューまで型を決めれば、ノート作成の速度と再現性が揃っていくでしょう。

Obsidianテンプレートの基本｜コア機能とTemplaterの違い

『Obsidian』のテンプレートは、標準機能だけでも日付やタイトルを差し込めますが、運用が増えるほど『Templater』の差が効いてきます。
固定文の貼り付けで足りるならコア機能で十分ですが、日付の整形、入力の対話化、条件分岐まで使いたいなら『Templater』が前提です。
読者としては、まず「何を自動化したいか」を切り分けるだけで、導入の迷いがかなり減るでしょう。

コアテンプレート機能でできること・できないこと

コアテンプレート機能は、{{title}}、{{date}}、{{time}} の3変数を埋め込むのが中心です。
毎回同じ定型文を少し楽に入れる用途には向いていますが、日付の書式を変える、前日のノートへリンクを作る、入力内容に応じて文を切り替える、といった処理はできません。
つまり「手で打つ回数を減らす道具」であって、「書く流れそのものを組み替える仕組み」ではないのです。

この差は、日報や週次レビューで顕著です。
たとえば毎回「日付」「見出し」「固定メモ欄」だけを入れるならコア機能で足りますが、KPTや議事録のように項目が増えると、手作業の置き換えだけでは続きません。
日常運用でテンプレートが重くなるほど、標準機能は入口、実務は『Templater』という役割分担になります。

Templaterプラグインの導入とTemplate folder location設定

導入は『設定』から『コミュニティプラグイン』へ進み、『Templater』を検索してインストールし、有効化する流れです。
続いて『Template folder location』でテンプレート保存先を指定します。
ここでは例として『90-Templates』のように専用フォルダを切ると、通常のノートと混ざらず、あとから探す手間が減ります。

設定の意味は単純で、Templaterに「どこから呼び出すか」を教える作業です。
保存先が曖昧だと、テンプレートが増えたときに挿入元を見失いやすいですが、フォルダを1つ決めておけば、日報、読書ノート、議事録を同じ入口で管理できます。
実際、運用が続く人ほど最初にフォルダ名を固定していて、ここを曖昧にしないのが効きます。

Templaterでは<% tp.date.now('YYYY-MM-DD') %>のように書けるので、単なる差し込みではなく、実行結果を作れます。
これが大きく、毎回の手入力を減らすだけでなく、ノートの見た目や流れを揃えられるからです。
テンプレートが「雛形」から「自動化の小さなスクリプト」に変わる感覚だと思っておくと、理解が早いでしょう。

テンプレートをホットキーやコマンドパレットから呼び出す方法

呼び出しはコマンドパレットかホットキーが基本です。
コマンドパレットは初回の迷いが少なく、ホットキーは毎日の入力で強い。
特に日報や週次レビューのように回数が多いテンプレートは、ホットキーに割り当てておくと、テンプレートを開くまでの数クリックが消えます。

体感としては、呼び出しの速さより「思い出さなくていい」ことが効きます。
テンプレートを使う場面で毎回メニューを探すと、書き始める前に気持ちが切れやすいのですが、キー操作に落とし込むと、ノート作成が反射に近づくからです。
まずはよく使う1種類だけをホットキー化しましょう。
残りはコマンドパレットで十分で、ここを急いで全部登録する必要はありません。

サンプル1：デイリーノートテンプレート

毎日開くノートを、迷わず3分で書ける形に落とし込んだ実用テンプレです。
対象は、Obsidianで日次記録を続けたい人や、日報・ふりかえりを1枚にまとめたい人。
結論はシンプルで、固定セクションを4つに絞り、date と tags をYAMLで先に仕込むと運用が止まりにくくなります。
テンプレ運用の肝は、書く内容を増やすことではなく、毎日同じ入口から始められることです。

YAMLフロントマターの設計

YAMLには date と tags を入れて、ノートの性質を機械的に揃えます。
date: <% tp.date.now('YYYY-MM-DD') %> と書いておけば作成日が自動で入り、あとから並べ替えたり検索したりするときに日付の抜けが起きません。
tags は daily-note のような固定タグに加え、#分報 #日報 #KPT #気づき のようにリンク先候補を意識して分けると、週次レビューで拾いやすくなるでしょう。
タグを増やしすぎると逆に見失うので、入口になるものだけを残すのが使いやすさにつながります。

実際の運用では、コアテンプレート機能よりも『Templater』を前提にしたほうが扱いやすいです。
標準機能は {{title}}/{{date}}/{{time}} の3変数に限られるため、日付の整形や前日リンクの生成まで踏み込みにくいからです。
たとえば毎朝のデイリーノートで「昨日のノート」をすぐ参照したいなら、date を埋めるだけでなく、関連ノートへ飛ぶ導線をタグで持たせたほうが運用が滑らかになります。
タグ設計は見た目より実務優先。

本文セクション

本文は4区画に固定します。
🗣️分報 には今やっている作業や思考の断片、📅日報 には今日の進捗と出来事、🔄KPTふりかえり には Keep・Problem・Try、💡気づき/学び には明日以降に残したい発見を置きます。
4つに分かれていると、何を書けばいいかを毎回考え直さずに済み、空欄でも「今はここだけ書けばいい」と判断しやすいです。
特にKPTは、Problemを書いた直後にTryへ落とせるので、反省だけで終わりにくい構造になります。

## 2026-05-27

### 🗣️分報

- 

### 📅日報

- 

### 🔄KPTふりかえり

- Keep:
- Problem:
- Try:

### 💡気づき/学び

- 

この形の良さは、情報量が少なくても見栄えが崩れないことです。
デイリーノートは長文をためる場所ではなく、その日の状態を最小限で残す場所なので、箇条書き1行だけの日があっても運用が壊れません。
むしろ項目過多を避けたほうが、3分以内で書き終えやすくなります。
毎日書く前提なら、完成度よりも継続可能性のほうが価値が高いでしょう。
空白が多い日が続いても、それ自体が記録になる。

Templaterでの自動化

Templaterでは、テンプレートの呼び出し時に日付を自動挿入し、必要なら前日ノートへのリンクも差し込めます。
<% tp.date.now('YYYY-MM-DD') %> を使うと、その日付がタイトルやYAMLにそのまま入るため、手入力の揺れが消えます。
加えて、テンプレ保存先を 90-Templates のように決めておくと、呼び出し先が散らかりません。
インストール後は Template folder location を設定し、コマンドパレットかホットキーで起動する流れが自然です。

デイリーノートは、設定そのものより呼び出しの速さで差が出ます。
ホットキーに割り当てておけば、思いついた瞬間に開けるので、記録の初速が落ちません。
そこから date が埋まった4セクションの雛形に書き込むだけにしておくと、朝の作業開始前でも夜の振り返りでも迷いが少ないです。
『Templater』を日課の入口に置くと、ノートは「書こうかどうか」を考える対象ではなくなる。
これが続けやすさの核心です。

サンプル2：Zettelkastenの3種テンプレ

Zettelkasten向けのテンプレは、フォルダを分けるだけでは足りません。
00-Literature/01-Fleeting/02-Permanent/03-Structuredの4層を切り分け、YYYYMMDDHHmmのIDとフロントマターを揃えると、ノートが「流れて、熟して、定着する」構造になります。
とくにFleeting Noteをそのまま残さず、Permanent Noteへ昇格させる前提で書くと、あとから探す手間が減ります。

フォルダ構成とIDの付け方

まずは00-Literatureに読書メモや引用元、01-Fleetingに思いつき、02-Permanentに1ノート1アイデアの本体、03-Structuredに索引やまとめを置きます。
IDはYYYYMMDDHHmmの12桁で付けるのが扱いやすく、たとえば202605271430のように時系列がそのまま並びます。
ファイル名に意味を詰め込みすぎないほうが、後から名前を変えても履歴が崩れません。

フロントマターにはaliases、tags、source、statusを入れておくと、検索と昇格の判断が速くなります。
sourceで元情報を残し、statusでfleeting、literature、permanentの段階を見える化する。
aliasesは同じ概念を別名で呼ぶときの逃げ道になり、tagsは主題の横断検索に効きます。
迷ったら、名前よりもIDと状態を優先して管理しましょう。

Fleeting Note・Literature Note・Permanent Noteの3種テンプレ

Fleeting Noteは、考えが浮かんだ瞬間を逃さないための短い下書きです。
ここでは整った文章にせず、1メモ1論点で書き切るのが向いています。
Literature Noteでは、00-Literatureに入れた情報を自分の言葉へ言い換え、何が要点でどこが気になったかを残します。
Permanent Noteは、Fleetingの断片を寝かせたうえで、他ノートとつながる形に磨き上げる段階です。

特にPermanent Noteは、1ノート1アイデアを崩さないことが肝心です。
複数の論点を1枚に詰めると、あとでリンク先がぼやけますし、再利用も落ちます。
実際に7枚ほどの断片をまとめて1枚にしたとき、見出しが増えるほど要点が散り、かえって検索しづらくなりました。
だからこそ、Fleetingで散らし、Literatureで整え、Permanentで1つに絞る流れが効きます。

ノート同士をリンクしてグラフを育てる運用ルール

リンクは「関連があるから貼る」のではなく、「次に読む自分の導線を作る」ために貼ります。
Permanent Noteからは、直接つながる2〜3枚だけを選んでリンクし、03-Structuredにはテーマ別のハブを置くと、ノート群が点ではなく面で見えるようになります。
タグだけに頼るより、文脈を持ったリンクのほうが再発見が起きやすいです。

昇格時のルールは単純で、Fleetingに書いた内容をその日のうちに寝かせ、翌日に読み直してPermanentへ移す、これで十分です。
リンクを増やしすぎると追跡が難しくなるので、1枚につき最初は2本、多くても3本に絞ると見通しが保てます。
つながりが増えるほど思考の地図は育ちますが、最初から密にしすぎないほうが、後で手を入れやすいのです。

サンプル3：PARAメソッドのテンプレート4種

PARAメソッドでは、Projectsを「締切のある進行中」、Areasを「継続的な責務」、Resourcesを「将来役立つ参照」、Archivesを「完了・休眠」で切り分けると、迷わず置き場所を決められます。
Obsidianではトップレベルを4フォルダに固定し、各ノートの役割をフロントマターで明示すると運用がぶれません。
特に、Projectだけは期限と完了条件を先に書く設計が効きます。

PARAの4分類とObsidianフォルダ構成

フォルダは Projects、Areas、Resources、Archives の4つに揃えるのが素直です。
新規ノートを開いた瞬間に「今動かす案件か、継続管理か、資料か、保管か」を判定できるので、検索より先に整理の判断が済みます。
実際、フォルダ名が増えるほど分類の迷いが増えるため、まず4分類に固定してからタグやリンクを足す流れが扱いやすいでしょう。

この4箱の考え方が効くのは、ノートを「作成時の気分」ではなく「今の役割」で管理できるからです。
たとえば会議メモでも、次回までに仕上げる資料ならProjects、継続担当の改善点ならAreas、あとで使う調査結果ならResourcesになります。
分類の軸が時間で揺れないので、Obsidianの検索結果も散らかりにくい。
ここが肝だ。

Project/Area/Resource/Archiveの各テンプレ

Projectテンプレには goal、deadline、status、progress、success_criteria を入れます。
完了条件を最初に書くと、途中で「やった気分」のメモに流れず、締切までに何を終えるべきかが見えます。
たとえば status: in_progress のままでも、success_criteria が「原稿提出」「議事録共有」まで定まっていれば、迷いなく前に進められるでしょう。

Areaテンプレは、責務の範囲を狭く書くほど強いです。
responsibility、standard、review_frequency を入れておくと、担当の境界と合格ラインが揃います。
家計なら「毎月の支出記録を更新する」、学習なら「週1回30分の復習を続ける」のように、レビュー頻度まで書いておくと放置しづらくなる。
Resourcesは逆に、結論を急がず、summary、related_topics、usage_notes だけで十分です。

Archivesは編集前提で育てないのがコツです。
完了したProjectや役目を終えたAreaの記録は残してよいが、日常的に書き換える場所にすると4分類の意味が崩れます。
私は、2週間触らなかったProjectを月末にArchiveへ寄せる運用のほうが、現在進行中のノートだけが前面に残って見通しがいいと感じます。

アーカイブ運用と月次レビューのチェックリスト

月次レビューでは、Projectsを1件ずつ見て、完了したものだけArchivesへ移します。
移動の基準は単純で、success_criteria を満たしたかどうかです。
未完了なのに止まっている案件はProjectに残し、締切が消えたものだけArchiveへ送ると、作業中の棚が濁りません。

• 完了条件 success_criteria を満たしたか確認する
• deadline が過ぎていて、再開予定がないか見る
• Area化すべき恒常作業が混ざっていないか点検する
• Resourcesとして残す価値がある断片を切り出す
• Archivesへ移す前にタイトルを整理し、重複を減らす

この手順のよさは、毎月の判断が「削除するか残すか」ではなく「役割を移すか」に変わる点です。
記録を消さずに整理できるので、後から見返したときも経緯が追いやすい。
Archiveは倉庫であって作業台ではない、そう決めてしまうと運用が安定します。

サンプル4〜5：読書ノート・議事録テンプレート

読書ノートと議事録は、どちらも「あとで探せる形」に落とし込めるかで価値が決まります。
『Obsidian』なら『Book Search』で書影・著者・出版日を取り込みつつ、本文側では要約と解釈を分けて残せます。
会議メモも同じで、目的と結論を先頭に置けば、読み返した瞬間に何を決めた会議だったかが見えるようになります。

読書ノートテンプレ

type: book
title: "{{title}}"
author: "{{author}}"
published: "{{published}}"
read_date: "{{read_date}}"
tags: [reading, note]

Book Searchで書影・著者・出版日を埋めたら、本文は「1行要約→章別メモ→引用→自分の解釈」の順が扱いやすいです。
要約を先に置くと、読了直後の温度感が薄れても核心を残せます。
章別メモは章ごとに1〜3文で十分で、引用は長く貼りすぎないほうが、自分の言葉が埋もれません。

## 読書メモ

- 1行要約: 
- 章別メモ:
  - 第1章:
  - 第2章:

- 引用:
  - 「」

- 自分の解釈:

実務で効くのは、読後に「何を考えたか」を1段だけ深く書くことです。
同じ本でも、仕事ならプロジェクトの判断材料に、学習なら次に読む本の選定に変わるからです。
『Book Search』で自動取得した書誌情報と、自分の解釈を同じノートに置くと、検索の起点が増えて後から拾いやすくなります。

議事録テンプレ

type: meeting
date: "{{date}}"
place: "{{place}}"
participants: [""]
project: "[[ProjectX]]"

議事録は『目的』と『結論』を最初に書くと、会議が長引いても記録の軸がぶれません。
日時・場所・出席者・アジェンダを並べ、その後に議論、決定事項、アクションアイテムを続けると、読み手は「何を議論し、何を決め、誰が動くか」を一目で追えます。
人リンクの『山田』とプロジェクトリンクの『ProjectX』を入れておけば、あとで人物別・案件別に集計できます。

## 会議メモ

- 目的:
- 結論:
- 日時:
- 場所:
- 出席者: [[山田]], [[佐藤]]
- アジェンダ:
- 議論:
- 決定事項:
- アクションアイテム:
  - [[山田]]: 
  - [[佐藤]]: 

議事録の強さは、後でDataviewが拾える形にしておくと一気に出ます。
『山田』のような人リンクで担当を結び、『ProjectX』のようなプロジェクトリンクで案件を束ねると、会議ごとのメモが散らばらず、進行中の仕事だけを抽出できます。
口頭で流れた話を残すだけでは足りず、再利用できる構造にすることが肝心です。

DataviewでToDo・人別ログを自動集計する設定

Dataviewで集計したいなら、ノートのYAMLと本文の両方に同じ軸を持たせます。
読書ノートはtype: book、議事録はtype: meetingのように分け、議事録ではparticipantsとprojectを固定のキーにすると、ToDoも人別ログも崩れません。
実際にはこの揃え方がいちばん効きます。

TABLE date, place, participants, project
FROM "meetings"
WHERE type = "meeting"
SORT date DESC

TABLE author, published, read_date
FROM "books"
WHERE type = "book"
SORT read_date DESC

こうしておくと、読書では「どの本をいつ読んだか」、会議では「誰がどの案件に関わったか」が同じ発想で引けるようになります。
ノートが増えるほど差が出るのはここで、手で一覧を作るより、記録の粒度を先にそろえたほうが後工程が軽い。
小さなテンプレですが、運用の負担をずっと減らしてくれます。

サンプル6〜7：プロジェクト管理・週次レビューテンプレート

プロジェクト用と週次レビュー用の2つを分けて持つと、中期運用は一気に回しやすくなります。
目標・マイルストーン・タスク・リスク・関連ノートをひとつにまとめたプロジェクトテンプレなら、進行中の判断がぶれません。
週次レビューではKPT、次週の優先タスク、読書・学び・出費の集計を同じ流れで確認し、振り返りを習慣化できます。

自動化の軸は、『Dataview』のToDoクエリ、tp.file と tp.system.prompt() の入力プロンプトです。
TASK FROM "" WHERE !completed で全Vaultの未完了タスクを拾い、テンプレ作成時にタイトルや日付を対話入力にしておけば、記録の抜けが減ります。

テンプレ運用が続かないときは、項目を削るのが先です。
金曜夜か日曜夜の15〜30分に固定し、まずは「書く量を減らして開く回数を増やす」設計にすると、習慣として残りやすいでしょう。