Obsidian Templater 使い方・設定・自動化入門

Obsidianの標準Templatesは定型文の挿入には十分ですが、会議直前に1クリックでfrontmatterと見出しが整った議事録ノートが開く体験を知ると、もう一歩先の自動化が欲しくなります。
この記事は、標準機能との違いを押さえたうえで、Templaterで動的テンプレートと新規ノート自動化を最短で始めたい人に向けた実践ガイドです。

読みながら進めるだけで、テンプレート保存フォルダの設定、3種類の実用テンプレート作成、手動挿入と自動適用の使い分けまで一通り終えられる構成にしました。
標準機能は手動中心、Templaterは tp. 関数や自動適用で定型作業を削る道具なので、まずは実用最小セットから組むのが回り道を減らす近道です。

Obsidian Templaterとは？標準Templatesとの違い

Templaterの概要

TemplaterはObsidianのコミュニティプラグインで、テンプレート内に tp. で始まる関数や JavaScript を書けるのが中核です。
固定文を差し込むだけでなく、現在日時、ファイル名、frontmatter、選択中テキストなどを、その場の状態に合わせて動的に埋め込めます。
Templater公式ドキュメント。

たとえば通常の関数呼び出しなら、次のように書くだけで当日の日付を差し込めます。

作成日: <% tp.date.now("YYYY-MM-DD") %>
タイトル: <% tp.file.title %>

この形は「値をそのまま埋め込む」用途に向いています。一方で、条件分岐や複数行の組み立てをしたいときは JavaScript 実行ブロックを使います。

<%* const prev = tp.date.now("YYYY-MM-DD", -1); tR += ${prev} | ${next}; -%>

もうひとつ見落としやすいのが、終了タグの -%> です。これは前後の不要な改行を抑えるための記法で、空行を増やしたくないテンプレートでは効果が大きいです。

<%*
const title = tp.file.title
tR += `# ${title}`
-%>

通常の %> で閉じると、テンプレート中の改行がそのまま残って見出しの前に空行が入ることがあります。
-%> にすると、その余計な1行を消せるので、frontmatter直後の見出しや、リストの直前直後でレイアウトが崩れません。
Templater を触り始めたばかりの頃は、この空行の扱いで「書式が合っているのに見た目が整わない」と感じやすいので、早めに覚えておくと後で助かります。

標準Templatesとの機能差

Obsidian標準のTemplatesは、コアプラグインとしてすぐ使える安心感があります。
定型文の挿入という目的なら十分で、会議メモの見出しやチェックリストを呼び出すだけなら困りません。
私も最初はそれで満足していました。
ただ、日付やタイトルを毎回手で差し替える場面が残り、テンプレートを入れたあとにもう一度カーソルを動かす必要がありました。
Templaterに切り替えてからは、その1操作が消えた感覚がはっきりありました。

違いをひと言で言うなら、標準Templatesは「固定文の手動挿入」、Templaterは「状況に応じて内容が変わるテンプレートと自動化」です。
たとえば標準機能では、議事録テンプレートに date: や title: という項目を書いておくことはできますが、その値をノート作成時に自動生成する力は限定的です。
対してTemplaterなら tp.date.now や tp.file.title を使って、frontmatter も本文も一度で埋められます。

frontmatter 付き議事録なら、たとえば次のような形にできます。

title: <% tp.file.title %>
date: <% tp.date.now("YYYY-MM-DD HH:mm") %>
tags:
 - meeting

# <% tp.file.title %>

{{related:obsidian-daily-notes}}
## 参加者

## 議題

## 決定事項

ここまで来ると、テンプレートは単なる雛形ではなく、新規ノートの初期状態を整える仕組みに変わります。
さらにTemplaterには、テンプレートから新規ノートを作るコマンドと、現在のノートに挿入するコマンドの両方があります。
標準Templatesでも挿入はできますが、「新規作成の瞬間に必要な情報を埋める」という流れではTemplaterのほうが一歩先です。

補助系プラグインとの位置づけも分けて考えると整理しやすくなります。
QuickAddのようなプラグインは、入力フローやマクロの起点をまとめる役割が中心です。
対してTemplaterは、ノートの中身をどう生成するかを担当します。
つまり、まずTemplaterでテンプレート本体を作り、その後にQuickAddで呼び出し導線を短くする、という順番のほうが理解しやすく、構文の混線も起こりません。

まず何から使い始めるべきか

最初から複雑な JavaScript に入るより、効果が見えやすい3つに絞るほうが理解が進みます。
ひとつめは日付挿入です。
<% tp.date.now("YYYY-MM-DD") %> を本文や frontmatter に入れるだけで、Templater の基本である「その場で値が変わる」感覚がつかめます。
標準Templatesとの差も最もわかりやすい部分です。

ふたつめは frontmatter 付き議事録テンプレートです。
会議名をファイル名にしておけば、tp.file.title と日時を組み合わせるだけで、タイトル、作成日時、見出しまで一度にそろいます。
テンプレートの恩恵が最も見えやすい用途で、あとからタグや参加者欄を足しても破綻しません。
新規作成時に frontmatter を入れる構成へ進むと、Templater の強みがさらに見えてきます。

みっつめはDaily Noteの前後日リンクです。
これは通常の関数呼び出しだけでも書けますし、JavaScript ブロックに入れて tR を使う練習にも向いています。

<%*
const prev = tp.date.now("YYYY-MM-DD", -1);
<%*
const prev = tp.date.now("YYYY-MM-DD", -1);
tR += `[[${prev}]] ← 今日 → [[${next}]]`;
-%>
この順番で触れておくと、QuickAddのような補助プラグインを後から足したときも混乱しません。テンプレートの中身をTemplaterで確定させ、その呼び出しを1アクションにまとめるのがQuickAddの役目です。逆にここを逆順にすると、どの自動化がどこで動いているのか見えなくなり、修正時に詰まりやすくなります。

## 導入前の前提条件と準備するもの

### 対応OSと前提

Templaterを入れる前に、まず前提になるのはObsidian本体の導入が終わっているということです。Obsidianはローカル保存中心のMarkdownノートアプリで、Windows / Mac / Linux / iOS / Androidで使えます。[本体の配布状況や最新版はObsidian Changelog](https://obsidian.md/changelog/)で確認できます。この記事の手順は、すでにVaultを1つ作成し、普段どおりノートを開ける状態を前提に進めます。

ここでいうVaultは、Obsidianがノートを保存する作業フォルダのということです。Templaterの設定では、このVault内のどこにテンプレートファイルを置くかを指定します。つまり、アプリ本体だけでなく「どのVaultで運用するか」が固まっていないと、後の設定で迷いやすくなります。実際に触ってみると、Vaultを複数作ってからテンプレートを整えようとしたとき、テンプレートの置き場所が曖昧だと、どのVaultに何を入れたのか追いにくくなります。

前のセクションで触れたとおり、Templaterは標準のTemplatesより一歩踏み込んだ自動化向けのプラグインです。そのため、まずはObsidian本体で通常のノート作成、フォルダ作成、設定画面の移動ができる状態になっていると、後の手順が素直につながります。

なお、この先の設定で出てくる用語は最初に軽く押さえておくと流れを追いやすくなります。frontmatter はノート冒頭に書くメタデータ欄、YAML はそのfrontmatterでよく使う記法、Dataview はノート内の情報を一覧・抽出するための代表的なコミュニティプラグイン、Citations は文献情報を取り込む用途で使われるプラグインです。この段階では意味だけ分かっていれば十分です。

{{ogp:https://obsidian.md/changelog/|Obsidian Changelog|Follow the latest updates to Obsidian apps for desktop and mobile.|https://obsidian.md/images/banner.png}}

### コミュニティプラグインを有効化する

Templaterはコミュニティプラグインのため、まずはコミュニティプラグイン機能自体を有効にしてください。設定画面で **Settings** > **Community plugins** を開き、**Turn on community plugins** をオンにします。続けて **Browse** を押すとプラグイン検索画面が表示されますので、そこでTemplaterを検索してインストールし、最後に明示的に有効化しましょう。よくあるつまずきは「インストールしたのに設定項目が見つからない」ケースです。インストールだけで終わらせず、一覧でプラグイン名の横が有効になっているかを確認してください。放置するとコマンドパレットに何も出ないなどの現象が発生します。
テンプレートに変数や関数の結果を差し込めるのが中核で、固定文を貼るだけの段階から一歩進めたい人向けです。構文の基本はTemplater公式ドキュメントにまとまっていて、後で `tp.` 関数を使う場面でも参照しやすい構成です。

> [!NOTE]
> Obsidianではコアプラグインとコミュニティプラグインが別管理です。Templatesはコア機能側、Templaterはコミュニティ側にあるため、設定場所が違うと覚えておくと迷いません。

{{ogp:https://silentvoid13.github.io/Templater/introduction.html|Introduction - Templater||}}

### テンプレート保存フォルダを作る理由

Templaterを入れたらすぐテンプレートを書き始めたくなりますが、その前にVault直下へ `Templates/` のような保存フォルダを作っておくと、後の設定が安定します。理由は単純で、Templater側の **Template folder location** に指定する場所が最初から決まっていると、テンプレート一覧が出ない、誤ったフォルダを見に行く、といった初歩的なトラブルを避けやすいからです。

このフォルダは名前が `Templates` である必要まではありませんが、多くの運用例で `Templates/` が使われています。Vault直下に置いておくと、設定画面でパスを見つけやすく、他のノート用フォルダと役割も分かれます。実際、最初にフォルダを決めておくと、テンプレートが3個から10個に増えたときでも置き場に迷わず、設定ミスもぐっと減ります。逆に、日報テンプレートは `Daily/`、議事録テンプレートは `Meeting/` の中にその都度ばらばらに置く運用にすると、「どれがテンプレート本体で、どれが通常ノートなのか」が混ざりやすくなります。

Templaterの設定では、このテンプレート保存先を明示しておく運用が基本です。 **Template folder location** が前提になっており、未設定だとテンプレート一覧を正しく出せないケースがあります。導入直後にテンプレートが見つからず止まるパターンはここで起きやすいので、先にフォルダを作ってから中身を書く順番のほうが流れが崩れません。

{{related:obsidian-plugins}}

## Templaterのインストールと初期設定

### Templaterのインストール

ここでは、テンプレートを書き始める前にTemplaterを実際に動く状態まで持っていきます。導入そのものは短く終わりますが、**Install のあとに Enable まで進める**ことが分岐点です。設定項目やコマンドが見えないときは、この有効化が抜けていることが多くあります。
手順は次の順番です。

1. Obsidianで **Settings** を開き、**Community plugins** に進んでください。
2. **Browse** を押して、プラグイン検索画面を開いてください。
3. 検索欄に **Templater** と入力します。
4. Templaterを開いて **Install** を押します。
5. インストール完了後、そのまま **Enable** を押して有効化します。

有効化まで終わると、設定画面のコミュニティプラグイン一覧にTemplaterが現れ、コマンドパレットにも関連コマンドが追加されます。機能の全体像はTemplater公式ドキュメント Introductionにまとまっていて、単なる定型文挿入ではなく、日時やファイル情報、JavaScript を使った処理まで広げられることが分かります。

この記事の確認時点ではTemplaterは v2.18.1 です。最近も修正が続いているので、[コマンド名や設定項目の位置を追うときはTemplater CHANGELOG](https://github.com/SilentVoid13/Templater/blob/master/CHANGELOG.md)で前後関係を掴むと迷いません。

### Template folder locationの設定

インストール直後にやることは、テンプレートを置く場所の指定です。前のセクションで作成した `Templates/` をここで結びつけます。これを入れないままコマンドを試すと、テンプレート候補が出ずに「入れたのに使えない」と感じやすくなります。導入時の詰まりどころは、ほぼここです。

設定手順はシンプルです。**Settings** を開いて **Templater** に進み、**Template folder location** に `Templates/` を入力します。Vault 内で見えているフォルダ名と同じ表記に揃えるのが無難です。`Templates` と `Templates/` の違いで認識がずれる報告もあるため、この記事では作成したフォルダ名そのままの `Templates/` で統一します。

つまり、テンプレート候補に出てくる起点はこの設定です。コミュニティでは `Templates/Daily/` や `Templates/Meeting/` のような運用例が多く見られますが、ここではまず `Templates/` を指定し、候補表示が通る状態を作ることを優先します。

> [!TIP]
> **Template folder location** が見当たらない場合は、Templater側の表示条件で隠れていることがあります。設定画面内の関連項目を見直すと現れるケースがありますが、少なくとも `Templates/` を作っておくと、その後の切り分けがぐっと楽になります。

### Script folder（任意）と候補表示の仕組み

次に見ておきたいのが、**Script folder location** です。これは必須ではありません。テンプレート本文に変数や日付を入れるだけなら、まだ設定しなくても進められます。設定する意味が出てくるのは、独自の JavaScript を `tp.user.<関数名>` として呼びたい場面です。たとえばタイトル生成や複数項目の整形を関数化したくなったとき、このスクリプト置き場が効いてきます。

設定する場合は、**Settings** > **Templater** > **User Script Functions** にある **Script files folder location** へ進み、たとえば `Scripts/` のようなフォルダを指定します。ここに置いた `.js` ファイルは読み込まれ、テンプレート内から呼び出せます。仕様の詳細はTemplater公式ドキュメント User Scriptsに整理されています。この仕組み自体は後の User Scripts の話で触れるので、ここでは「独自関数の置き場を決める設定」と押さえれば十分です。

設定後に把握しておきたいのは、**どこでテンプレート候補が見えるか**です。普段使いではコマンドパレットから開く候補一覧が中心になります。`Template folder location` に指定したフォルダ内の Markdown ファイルが、その候補として並びます。逆に言えば、通常ノートを別フォルダに置いている限り、候補一覧に混ざりません。この切り分けがあるだけで、Daily Note 用、会議メモ用、プロジェクト開始用のテンプレートを迷わず選べるようになります。

{{ogp:https://silentvoid13.github.io/Templater/user-functions/script-user-functions.html|User Scripts - Templater||}}

### コマンドとホットキー設定

設定が終わったら、実際に使う入口は主に2つです。コマンドパレットに現れる **Templater: Create new note from template** と **Templater: Open Insert Template Modal** です。前者はテンプレートから新規ノートを作るコマンド、後者は今開いているノートのカーソル位置へテンプレートを挿入するコマンドです。新しい会議ノートを立ち上げるときは前者、既存ノートに議事録ブロックや日報の見出しだけ差し込みたいときは後者、と分けると整理しやすくなります。

動作確認はコマンドパレットを開けばすぐできます。コマンドを実行したときに、`Templates/` に置いた `.md` ファイルが候補として表示されれば初期設定は通っています。ここで候補が出ない場合は、ほぼ `Template folder location` の指定先が原因です。対象になるのは、その設定で指したテンプレートフォルダ内の Markdown ファイルです。

ここでひと手間かけておくと、その後の使用感が一段変わります。**Settings** > **Hotkeys** を開き、上の2コマンドに任意のショートカットを割り当てます。macOS なら `Cmd`、Windows なら `Ctrl` を軸に、既存ショートカットとぶつからない組み合わせにしておくと運用が安定します。私はこの2つにホットキーを付けたところからテンプレートの使用率が一気に上がりました。特に Daily Note を起点に作業を始める日は、コマンドパレットを呼んで探すより、指が先に動く状態になって立ち上がりが明らかに速くなります。

ホットキー化の効果は、テンプレートの中身より先に現れます。1回の操作短縮は小さく見えても、ノート作成のたびに入口が固定されるので、テンプレートを使うかどうか迷う時間そのものが減ります。Templaterは高機能ですが、導入直後の段階では「候補が見える」「新規作成と挿入の2コマンドをすぐ呼べる」まで整っていれば十分です。ここまでできていれば、次のテンプレート作成にそのまま入れます。

## 最初に作るべきテンプレート（まずは3つ）

ここからは、最初に手元へ置いておくと効果が出やすい3つのテンプレートをまとめて作ります。日付挿入、議事録、Daily Note の前後リンクがその3つです。なお「読書メモ」は任意の追加例として後述します（運用に合わせて追加してください）。
コードはどれもObsidianにそのまま貼れるコピー用です。テンプレートファイルとして保存するときは、frontmatter を使うものでは YAML の区切りである `---` を含めたまま保存します。構文の基本はTemplater公式ドキュメント Syntaxにも整理されていますが、ここではそのまま動く形に絞ります。

### テンプレ1：現在日時を挿入

最初の1本は、現在日時だけを挿入する最小テンプレートです。テンプレートの利点がいちばんわかりやすいのは、実はこのくらい短いものです。日付を毎回手で打つ運用だと表記ゆれが混ざりますが、テンプレート化すると `YYYY-MM-DD HH:mm` で揃います。作業ログ、電話メモ、打ち合わせの開始時刻メモなど、短いノートの冒頭に置く用途と相性が合います。

<% tp.date.now("YYYY-MM-DD HH:mm") %>

このテンプレートは frontmatter を持たないので、本文だけの `.md` ファイルとして `Templates/` に保存すれば十分です。まずは開いているノートの任意の位置にカーソルを置き、`Open Insert Template Modal` から挿入すると、Templater が動いて現在日時へ置き換えます。標準のTemplatesでも定型文の挿入はできますが、このような動的な日時生成はTemplaterのほうが素直です。

### テンプレ2：議事録

次に作りたいのが議事録テンプレートです。ここは frontmatter、見出し、入力位置のガイドをまとめて入れておくと、会議の冒頭で迷う時間が消えます。本文のどこから書き始めるかを `tp.file.cursor` で先に決めておくと、カーソル移動のひと手間もなくなります。実務ではこの差が地味に効きます。冒頭3分で参加者と議題だけ埋める流れに変えると、その後のメモが散らばりにくく、決定事項の取りこぼしも減ります。

title: <% tp.file.title %> # 重複1 date: <% tp.date.now("YYYY-MM-DD HH:mm") %> type: meeting tags:

• meeting

participants: agenda:

# <% tp.file.title %>

参加者

-

議題

-

決定事項

-

メモ

<% tp.file.cursor %>

frontmatter の `participants` や `agenda` を空で置いているのは、会議の開始直後に必要な項目だけ先に埋められるからです。タイトルをノート名と揃えておくと一覧で見返したときにも崩れません。新規作成で使うならTemplaterの `Create new note from template`、既存ノートへ差し込むなら `Open Insert Template Modal` と役割を分けると運用が安定します。

### テンプレ3：Daily Noteの前日/翌日リンク

Daily Note では、昨日と明日へ1回で移動できるだけで回遊性が変わります。日記や作業ログを日単位でつないでいる人ほど、このテンプレートの便利さを実感しやすいはずです。ファイル名が `YYYY-MM-DD` で揃っている前提なら、前日と翌日のノートリンクを自動で出せます。

date: <% tp.date.now("YYYY-MM-DD") %> tags:

• daily

<% tp.date.now("YYYY-MM-DD", -1) %>|← 前日 | <% tp.date.now("YYYY-MM-DD", 1) %>|翌日 →

# <% tp.date.now("YYYY-MM-DD dddd") %>

今日のメモ

<% tp.file.cursor %> # 重複1

この形なら、Daily Note を開いた瞬間にナビゲーションと本文の入口が揃います。日次ログは1日単体で終わらせるより、前後につながっていたほうが流れを追いやすくなります。とくに連日同じテーマを追っているときは、昨日の続きへ戻る操作が減るだけで思考が途切れません。Templaterはこうした日付ベースの生成で真価が出ます。

> [!TIP]
> Daily Note のテンプレートは、まず手動挿入で動作を見てから自動適用へ進めると詰まりません。日付リンクの出力だけでも確認できれば、構文の理解が一気に進みます。

### 追加例：読書メモ

用途別でもう1本加えるなら、読書メモは相性の良い題材です。本のノートは書誌情報を毎回同じ位置へ置けるだけで、後から検索するときの精度が上がります。frontmatter に著者、出版社、ISBN を持たせておくと、本文の感想とメタ情報が分離でき、Dataview 系の運用へ広げるときも流れがきれいです。

title: <% tp.file.title %> # 重複2 date: <% tp.date.now("YYYY-MM-DD") %> # 重複1 type: book author: publisher: isbn: tags:

• book
• reading

# <% tp.file.title %>

書誌情報

• 著者:
• 出版社:
• ISBN:

要点

-

印象に残った箇所

-

メモ

<% tp.file.cursor %> # 重複2

読書メモは自由記述だけでも続けられますが、最初に枠があると「何を書けばよいか」で止まりません。議事録と同じで、空欄の意味が明確なテンプレートほど継続に向きます。構造を先に用意しておくことで、内容そのものに意識を回せます。

ここまで作ったテンプレートは、保存した直後に手動挿入で試すのがいちばん早い確認方法です。今開いているノートでコマンドパレットを開き、`Templater: Open Insert Template Modal` を起動して、現在日時テンプレートなら日時がその場に入るか、議事録テンプレートなら見出しとカーソル位置が意図通り出るか、Daily Note テンプレートなら前日と翌日のリンクが生成されるかを見れば十分です。最初の段階では、新規作成の自動化まで一気に進めるより、この手動挿入が通る状態を作るほうがテンプレートの手応えをつかみやすいです。

## Templaterの基本構文：`<% %>` と `<%* %>` の違い

### 評価デリミタと実行ブロック

Templaterの構文で最初につまずきやすいのが、`<% %>` と `<%* %>` の役割の違いです。ここを曖昧なまま書き始めると、「値は出るのに条件分岐が書けない」「JavaScriptを書いたのに何も表示されない」といった混乱が起きます。

`<% %>` は、**式を評価して、その結果をその場に差し込む**ための基本デリミタです。日時、ファイル名、カーソル位置のように「1つの値を埋める」場面では、まずこちらを使います。

作成日: <% tp.date.now("YYYY-MM-DD") %> タイトル: <% tp.file.title %> 本文開始位置: <% tp.file.cursor %>

この書き方では、それぞれの評価結果がその位置に直接入ります。日付なら文字列、`tp.file.title` なら現在のノート名、`tp.file.cursor` なら挿入後のカーソル位置です。前のセクションで使った会議メモや Daily Note のテンプレートは、ほとんどがこの基本形で組めます。

一方の `<%* %>` は、**JavaScriptを実行するためのブロック**です。複数行の処理、変数の宣言、条件分岐、ループなどをまとめて書けます。通常の評価デリミタと実行ブロックは分けて説明されています。

たとえば、曜日によって文言を変えたいなら `<%* %>` の出番です。

<%* const day = tp.date.now("ddd"); // 例: "Sat"

if (day = "Sat" || day = "Sun") {

tR += "今日は週末です"; } else { tR += "今日は平日です"; } -%> <%* const day = tp.date.now("ddd"); // 例: "Sat"

if (day = "Sat" || day = "Sun") {

tR += "今日は週末です"; } else { tR += "今日は平日です"; } -%>

<%*
const name = "田中";
tR += `こんにちは、${name}さん`;
%>

この結果は、ノート上では次のように展開されます。

こんにちは、田中さん

初学者が混乱しやすいのは、return と tR の違いです。<% %> の感覚で「式を書けばそのまま出る」と考えると、<%* %> の中で変数を作っただけで終わってしまいます。

<%*
const title = tp.file.title;
%>

この例は変数 title を作っているだけで、本文には何も出ません。表示したいなら、tR に足します。

<%*
const title = tp.file.title;
tR += `# ${title}`;
%>

複数行を組み立てる場面でも tR は便利です。たとえば frontmatter の一部を条件付きで作るなら、次のように書けます。

<%*
const today = tp.date.now("YYYY-MM-DD");
tR += "---\n";
tR += `date: ${today}\n`;
tR += "type: memo\n";
tR += "---\n";
%>

こうしておくと、出力する順番を JavaScript 側で明示できます。
見出し、本文、条件分岐付きの補足行をまとめて制御したいときに向いています。
実際、テンプレートが長くなるほど「どこで何を表示しているのか」を追える形のほうが保守しやすく、後から書き換える負担も減ります。

余計な空行を消す書き方

テンプレートを何度も試していると、文末やブロックの区切りに意図しない空行が残ることがあります。
原因のひとつが、タグの閉じ方です。
%> で閉じると、その行の改行までテンプレートに残るため、ブロックの前後で空白が積み上がりやすくなります。

そこで使うのが -%> です。これは直後の改行を取り除く書き方で、空行の制御に効きます。

開始
<% tp.date.now("YYYY-MM-DD") %>
終了

この場合、テンプレートの置き方によっては出力に余計な改行が残ります。閉じタグを -%> に変えると、次の行とのつながりを詰められます。

開始
<% tp.date.now("YYYY-MM-DD") -%>
終了

実際に使っていて効いたのは、条件分岐や短い実行ブロックを見出しの直前に置く場面でした。
出力の末尾に謎の空行が積み上がる問題は、この -%> に置き換えるだけで消えます。
テンプレート本文の内容は同じでも、生成後の見た目が整うので、会議メモや Daily Note を毎日作る運用では差が出ます。

短い例で見ると違いが。

<%*
tR += "A"
%>
B

このままだと、A と B の間に意図しない空行が入ることがあります。閉じ側を -%> にすると、改行を食べて詰まります。

<%*
tR += "A"
-%>
B

見出しの直前、frontmatter の終端、条件付きで1行だけ出したい箇所では、この書き分けだけで整形の手間が減ります。
テンプレート本体を修正するたびに空行を手で消すより、最初から改行制御を入れておくほうが安定します。

よく使う tp. 関数一覧

Templaterの構文を覚えるときは、すべての関数を一気に追うより、毎日触るものから固めたほうが定着します。
ここでは、最初のテンプレートで登場頻度が高い tp. 関数だけを押さえておくと十分です。

tp.date.now("YYYY-MM-DD") は現在日時を指定フォーマットで出力する関数です。
Daily Note の日付、frontmatter の created、会議メモの記録時刻など、最初に使う場面が最も多い関数です。

tp.file.title は現在のノートタイトルを取得します。
ノート名と見出しを揃えたいときに便利で、# <% tp.file.title %> のように書くと、ファイル名をそのまま本文のタイトル行へ反映できます。

tp.file.cursor はテンプレート適用後のカーソル位置を指定します。
定型文を入れたあとに、次に入力する場所へすぐ移れるので、議事録や読書メモのように追記が前提のテンプレートで効きます。

tp.file.create_new はテンプレートや文字列から新規ノートを作るための関数です。
内部関数として用意されており、ファイル名や保存先フォルダも制御できます。
新規作成の自動化に進むと活躍しますが、処理順を意識しないとタイトル参照のタイミングで詰まりやすいため、最初の段階では手動挿入や単純な新規ノート生成から触れるほうが理解が進みます。

tp.file.rename は現在のファイル名を変更する関数です。
テンプレート実行時にノート名を整えたい場面で使います。
タイトルや frontmatter をファイル名と一致させたいときに役立ちます。

tp.frontmatter. は既存の frontmatter 値を参照します。
たとえば tp.frontmatter.author と書けば、author の値を本文中へ再利用できます。
メタデータと本文を連動させるテンプレートで便利です。

JavaScript 実行や system commands に対応していることも機能として明記されています。
柔軟さはObsidian標準のTemplatesより明確に広い一方で、最初から外部コマンド実行まで手を出すと、テンプレートの不具合なのか JavaScript の問題なのか切り分けづらくなります。
導入直後は tp.date.now で日付を入れる、tp.file.title で見出しを揃える、frontmatter を生成する、といった範囲から始めると構文の理解が安定します。

GitHub - SilentVoid13/Templater: A template plugin for obsidian

A template plugin for obsidian. Contribute to SilentVoid13/Templater development by creating an account on GitHub.

github.com

新規ノート自動化：Folder templates とフロントマター自動挿入

新規作成トリガーの考え方

Templaterを単なる差し込みツールで終わらせないなら、発想の切り替えが必要です。
本文の途中にテンプレートを挿すのではなく、どのフォルダで新規ノートを作った瞬間に、何を自動で入れるかを決めると、運用が一段進みます。
会議ノートは会議フォルダ、読書メモは読書フォルダ、日報は日報フォルダというように、ノートの種類と保存先がほぼ一致しているなら、フォルダ単位でテンプレートを割り当てる考え方が最も素直です。

このとき使うのがTemplaterの Folder Templates です。
標準のObsidianコア機能Templatesは、基本的に今開いているノートへ手動で定型文を挿入する役割です。
対してTemplaterは、新規作成というタイミングを起点に frontmatter や本文の骨組みを先回りして入れられます。
この差が、毎回同じ項目を埋める作業を消してくれます。

実際、会議フォルダに Folder Templates を割り当ててからは、ノートを作るたびに frontmatter の項目が自動で揃うようになりました。
type や date の表記ゆれがなくなると、Dataview側の集計条件も安定します。
会議一覧で抜けが出る原因は、集計ロジックより先に、入力時点の揺れであることが多いので、入口で形を揃える効果は想像以上に大きいです。

なお、自動化の前提としてテンプレートの置き場所は明示しておく必要があります。
Templaterでは Template folder location に指定したフォルダ内のファイルがテンプレート候補になります。
ここが未設定だとテンプレート一覧が出なかったり、別フォルダに置いたテンプレートが候補に現れなかったりします。
テンプレートを書いたのに見つからないときは、内容より先に保存場所を疑うほうが早いです。

Folder templatesの割り当て手順

設定画面での作業自体は短く終わります。流れは次のとおりです。

1. Obsidianの Settings を開き、Community pluginsのTemplaterへ進みます。
2. まだテンプレート格納先を決めていない場合は、Template folder location にテンプレート用フォルダを指定します。たとえば Vault 直下の Templates です。ここが未設定だと候補一覧が出ません。
3. 同じ設定画面の Folder Templates セクションを開きます。
4. Add New を押し、対象フォルダに Meetings のようなノート保存先フォルダを指定します。
5. 紐付けるテンプレートとして、Template folder location 内に置いた会議メモ用テンプレートを選びます。
6. Meetings フォルダ内で新規ノートを作り、frontmatter と本文が自動で入るか確認します。

この運用では、テンプレート本体を Templates/Meeting.md のように一か所で管理し、実際のノートは Meetings/ に増やしていく形になります。
テンプレートを置くフォルダと、ノートを保存するフォルダを分けておくと、テンプレートそのものが集計対象に混ざりません。

ひとつ押さえておきたいのは、公式ドキュメント上で Folder Templates と新規作成時トリガー関連の設定に排他的な説明がある点です。
設定項目が見当たらないときは、期待する自動化方式と現在の設定が噛み合っていないことがあります。
Templater公式ドキュメント Introductionと設定ページの挙動を見比べると、何を手動にして何を自動にするか整理しやすくなります。

会議メモ用frontmatter例

自動化の効果が最ものは、frontmatter を毎回そろえて入れる場面です。会議メモなら、最低限これくらいから始めると実務で回しやすくなります。

type: meeting
date: <% tp.date.now("YYYY-MM-DD") %> # 重複2
attendees:
 -
status: draft
tags:
 - meeting

# <% tp.file.title %>

## 参加者

## 議題

## 決定事項

## メモ

<% tp.file.cursor %> # 重複3

このテンプレートを Meetings フォルダに Folder Templates として割り当てておくと、新規ノートを作った時点で type: meeting と当日の日付が入り、参加者・議題・決定事項の見出しまで揃った状態で始められます。
空の attendees を frontmatter に残しておくと、会議後に YAML 側へ正式な参加者名を書き戻す運用にもつなげやすく、本文だけに情報が散らばりません。

status: draft を最初から入れておくのも効きます。
下書きのままなのか、清書済みなのかを後で見分けやすくなるからです。
会議直後は本文だけ先に書き、あとから draft を final のように更新する運用にすると、一覧で未整理のノートを拾いやすくなります。
Obsidianでノート作成時にフロントマターを自動的に追加されるようにしてみる。

標準Templatesとの役割分担

ここで一度、標準のTemplatesとTemplaterの役割を切り分けておくと混乱しません。
コア機能のTemplatesは、基本的に手動挿入の道具です。
今開いているノートに定型文を差し込む用途なら十分ですが、新規ノート作成と同時に frontmatter を自動でそろえる運用には向いていません。
新規作成時のトリガーを軸に自動適用したいなら、Templaterの Folder Templates を使う、という対比で覚えると整理できます。

使い分けを短くまとめると、次のようになります。

たとえば、議事録ノート全体のひな形は Folder Templates に任せて、本文中の「決定事項まとめ」や「次回アクション」だけを標準TemplatesやTemplater: Open Insert Template modalでその場挿入する、という分担はきれいに回ります。
ノートの外枠は自動、必要な部品の差し込みは手動、という考え方です。

もうひとつ見落としやすいのが、テンプレート候補の表示範囲です。
Template folder location を設定していないと候補が出ず、テンプレートを別フォルダに置いた場合も対象外になります。
テンプレートが呼べないとき、構文ミスを追う前に、テンプレートファイルがTemplaterに認識される場所へ置かれているかを見るほうが、詰まりどころを早く外せます。

応用編：DataviewやCitationsと組み合わせる使い方

Dataviewで再利用しやすいメタデータ設計

Templaterで frontmatter を入れる価値は、作成時の手間が減ることだけではありません。
項目名と値の揺れを抑えておくと、Dataviewで一覧化したときに、そのまま再利用できる土台になります。
会議ノートなら type: meeting と status: draft のような最小構成でも効きます。
本文に「議事録」「会議メモ」「打ち合わせ」など表記が混ざると拾い漏れが出ますが、frontmatter 側のキーが統一されていれば、抽出条件を一度書くだけで済みます。

たとえば Meetings/ に置いたノートへ type、status、date を継続して入れておくと、「未整理の会議メモだけを見る」「今月分だけ並べる」「final に更新されていないものを残す」といった切り分けが素直に通ります。
私は type と status を揃えただけで、進捗一覧が実務でそのまま使える水準まで整いました。
どの会議メモが下書きのまま残っているか一目で拾えるので、見直しの頻度も自然に上がります。
タグを増やす前に、この2項目を固めるほうが効きました。

会議ノートの最小例なら、次のような設計で十分です。

type: meeting
status: draft
date: 2026-03-18
project: Alpha

この形にしておけば、Dataview側では「meeting だけ」「draft だけ」「project が Alpha のものだけ」と条件を重ねられます。
逆に、最初から項目を増やしすぎると入力が止まりやすくなります。
owner や reviewer のような列まで欲しくなる場面はありますが、本文で毎回埋める負担のほうが先に表面化しがちです。
中級者向けの拡張として考えるなら、まずは「後で並べたい項目だけを frontmatter に置く」という発想が安定します。

Citationsとfrontmatterの相性

文献メモでは、Citationsとの連携が frontmatter の整理に向いています。
特に著者名、年、文献IDのような書誌情報は、本文に散らすより YAML へ入れておいたほうが後から扱いやすくなります。
Templaterで文献メモの枠を作り、Citationsで取得した情報を frontmatter 更新に回す、という考え方です。

最小構成なら、文献メモは次の程度で十分です。

type: literature-note
citekey: smith2024example
author: Smith
year: 2024

# タイトル

## 書誌情報

- 著者:
- 出版社:
- 年:

## 要点

これだけでも、「著者ごとに並べる」「年で絞る」「同じ citekey の重複を避ける」といった管理がしやすくなります。Citationsは書誌データを扱う役割、Templaterはノートの型を揃える役割と分けると整理しやすく、設定の見通しも保てます。ここで無理に複雑なテンプレートへ寄せる必要はありません。著者、年、ID の3つが安定して入るだけで、文献メモは十分に再利用可能になります。

る通り、Templaterは動的な値の挿入に強いので、Citationsから得た値をノートの先頭へ整えて残す発想と相性がいいです。ただし、本記事の範囲では連携の最小例に留めるのが現実的です。文献管理まで一気に自動化しようとすると、テンプレートの保守より設定の追跡に時間を取られやすくなります。

### QuickAddなど補助プラグインの位置づけ

入力フローをさらに詰めたいなら、QuickAddのような補助プラグインも視野に入ります。たとえば、会議メモ作成時にテンプレート選択、ファイル名入力、保存先指定までを一連の操作にまとめる、といった使い方です。Templater単体ではテンプレートの中身を整える役割が中心ですが、QuickAddを重ねると「どう起動するか」まで設計できます。

ただ、この段階で一気に足すと、どこで frontmatter が入り、どこでファイル名が決まり、どのコマンドが本文を展開したのかが追いにくくなります。補助プラグインは、基本のテンプレート運用が固まったあとに追加するほうが整理しやすいです。この記事では参照に留め、まずはTemplaterだけで meeting ノートや文献メモの型を揃えるところまでで十分です。

モバイル環境も見逃せないポイントです。デスクトップではコマンドパレットやホットキーから自然に呼べる操作でも、スマートフォンやタブレットでは起動導線が変わるため、押す場所を覚える負担が先に来ます。そういう場面では、自動化を増やすより、手動挿入を起点にしたほうが運用が安定します。まずは決まった frontmatter を自分で差し込み、その後に必要な部分だけTemplaterや補助プラグインへ寄せる流れのほうが、途中で崩れにくい構成になります。

## よくあるエラーと対処法

### 候補が出ない/コマンドが効かない

Templater導入直後のつまずきでいちばん多いのは、コマンドパレットにテンプレート候補が出ない、あるいは `Templater: Open Insert Template modal` を押しても何も選べない、という場面です。ここは構文より先に設定を疑ったほうが切り分けが早く進みます。Templaterの公式ドキュメントでも、`Template folder location` に指定したフォルダ内のファイルがテンプレートとして扱われる前提になっています。設定が空のままだと一覧を作れず、Issue でも `No Template Folder Configured` に近い報告が出ています。

実際に詰まりやすい確認点はかなり絞れます。

- Templater自体がコミュニティプラグインとして有効化されているか確認する
- `Template folder location` が設定されているか確認する
- 指定したパス名が、Vault 内の実フォルダ名と1文字単位で一致しているか確認する
- テンプレートファイルの拡張子が `.md` になっているか確認する
- テンプレートを `Script folder location` 側に置いていないか確認する
- 実行しているコマンドが「新規作成」なのか「挿入」なのかを取り違えていないか

自分の運用でも、候補が出ないトラブルはほぼフォルダ設定ミスでした。設定画面のパスと実際のフォルダ名を声に出して照合するようにしてから、この手の再発は止まりました。`Templates` と `Template`、末尾スラッシュの有無、日本語名と英語名の混在は見落としやすいポイントです。コマンドが壊れているように見えても、原因はその前段の設定であることが多いです。

公式の設定ページで触れられている通り、`Template folder location` は表示条件つきになることがあります。設定項目が見当たらないときは、テンプレート自体の不具合ではなく、設定画面の表示状態を先に疑うと迷走しません。Templaterの設定仕様はTemplater Settingsにまとまっています。

{{ogp:https://silentvoid13.github.io/Templater/settings.html|Settings - Templater||}}

### frontmatterに`Untitled`が入る

この現象を避けるなら、ファイル名を先に確定させてから参照する順番に寄せるのが基本です。`tp.file.rename` を使う構成にするか、作成後にもう一度テンプレートを評価する形へ分けると安定します。新規作成の瞬間にすべてを一気に決めようとすると、本文、frontmatter、ファイル名のどれが先に確定するかでズレが出ます。

たとえば次のように、作成直後のタイトルをそのまま frontmatter に入れる書き方だと、意図せず `Untitled` が残ることがあります。

title: <% tp.file.title %> # 重複3

この現象を避けるなら、ファイル名を先に確定させてから参照する順番に寄せるのが基本です。`tp.file.rename` を使う構成にするか、作成後にもう一度テンプレートを評価する形へ分けると安定します。新規作成の瞬間にすべてを一気に決めようとすると、本文、frontmatter、ファイル名のどれが先に確定するかでズレが出ます。

ワークアラウンドとして扱いやすいのは、frontmatter の `title` を初回生成で無理に埋めず、ファイル名が決まったあとに再評価する方法です。会議ノートなら、まず `date` や `type` だけを先に入れ、タイトルは命名後に追記するほうが事故が減ります。`Untitled` が混ざる問題はテンプレート記法の知識不足というより、作成タイミングの癖を踏まえた設計でほぼ回避できます。

なお、CHANGELOG ではカーソル移動や挿入位置まわりを含め、実行順に関わる修正が継続的に入っています。`tp.file.cursor` の挙動のように、以前の癖が今の版で変わっているケースもあるため、古い記事のサンプルをそのまま持ち込むと混乱しがちです。Templaterの更新履歴に目を通す習慣があると、テンプレート側の問題なのか、修正済みの既知挙動なのかを切り分けやすくなります。

### 構文が文字列のままになる

`<% tp.date.now("YYYY-MM-DD") %>` のような構文が評価されず、そのまま本文に表示される場合は、ほぼ「実行されていない」か「書式が違う」かのどちらかです。構文そのものが壊れているより、テンプレートとして処理されていないケースのほうが多く見つかります。

代表的な原因は3つあります。ひとつは、ただの Markdown ファイルとして開いただけで、Templaterの挿入コマンドや新規作成コマンドを通していないということです。もうひとつは、デリミタの打ち間違いです。`<% %>` と `<%* %>` を混同したり、`%>` の閉じ忘れがあると、見た目は近くても評価されません。もうひとつは、コードブロックの中に入れてしまっているパターンです。フェンスコード内では、当然ながらテンプレートではなく文字列として扱われます。

次のような例は、見た目どおり文字列として残ります。

<% tp.date.now("YYYY-MM-DD") %>

テンプレートとして展開したいなら、コードブロックの外に置く必要があります。また、サンプルをブログやメモから貼り付けたときに、全角の記号や余計なバッククォートが紛れ込むこともあります。とくに `<%` と `%>` は一文字でも崩れると評価対象から外れます。

> [!TIP]
> 構文がそのまま残るときは、複雑なテンプレートを疑う前に `<% tp.date.now("YYYY-MM-DD") %>` の1行だけを新規ノートで試すと切り分けが速くなります。これで展開されれば、原因は元テンプレート内の配置か記法に絞れます。

### Template folder未設定時の具体挙動

`Template folder location` を未設定のまま使い始めると、見た目の印象としては「Templater が動かない」に近くなります。実際にはプラグイン本体が読み込まれていても、テンプレート一覧を作る起点がないため、`Open Insert Template modal` では候補が並ばず、`Create new note from template` でも選択元がありません。GitHub の報告には、テンプレート一覧の取得に失敗するものや、UI 上でパス表示が不自然になるものもあります。

ここで混同しやすいのが、`Folder Templates` も同じ前提に乗っている点です。フォルダごとに自動適用したくても、参照するテンプレートファイルが解決できなければ、そもそも紐付け先が成立しません。`Template folder location` が空の状態では、手動挿入だけでなくフォルダ単位の自動化も止まります。

公式設定ページでは、`Template folder location` と `Folder Templates` の関係、さらに表示条件つきの設定項目があることも明記されています。導入初期に「モーダルに出ない」「自動適用されない」「テンプレートが見つからない」が同時に起きたら、個別の機能を別々に直すより、この設定一点から見直したほうが早く収束します。更新頻度も続いており、公開情報上ではTemplaterは 2.18.1 系まで修正が積み重なっています。既知の不具合修正が含まれていることもあるので、古い挙動を前提に原因を探すと遠回りになりやすいです。

## まとめと次のアクション

Obsidianで定型作業を減らす入口は、導入を迷わず済ませるということです。議事録、読書メモ、日次ノートの3テンプレートがあるだけで、ノート作成の初速が揃います。手動挿入と自動適用を切り分けると、テンプレートは「書式集」ではなく作業の流れそのものになります。日付、議事録、前後日リンクの3点セットだけでも、毎日の繰り返し作業の引っかかりが目に見えて減る感覚は何度も実感してきました。

次にやることは順番に進めるのが近道です。

1. Templaterを入れ、Vault内に `Templates` フォルダを作って設定します。Settings > Templater > Template folder location に `Templates/` を指定すると、テンプレート候補が正しく検出されやすくなります。設定パスが見つからない場合は Templater の設定画面で表示条件を確認してください。
2. 議事録テンプレートを1本作り、`Open Insert Template Modal`で既存ノートに挿入して動きを確かめます。
3. `Create new note from template`で新規作成の流れを試し、必要なら会議フォルダに`Folder Templates`を割り当ててfrontmatterまで自動化します。

JavaScriptやsystem commandsに踏み込むのは、基本運用が固まってからで十分です。更新も続いているので、挙動を判断するときはObsidianのCHANGELOGとTemplaterのCHANGELOGを都度見ながら進めると遠回りを避けられます。