SEOを意識した代替タイトル案(10件)
- Obsidianをプロンプト生成機にする:Claude CLI × Ansible 運用安定化の実践
- プロンプトの品質を資産化する:Obsidian × Claude CLI × Ansible のワークフロー
- 毎回いい感じに頼む をやめる:Obsidianでプロンプトをテンプレ化する方法
- Claude CLIの出力がブレる原因はプロンプト:Obsidianで解決するアプローチ
- プロンプトをコードのように管理する:Obsidian × Claude CLI × Ansible
- Obsidian × Templater × Claude CLI:プロンプト自動生成でAnsible運用を安定化
- AIの出力品質は入力で決まる:Obsidianをプロンプトコンパイラにする発想
- 属人的なプロンプトを標準化する:Obsidian × Claude CLI × Ansible の仕組み
- Prompt Factoryとしての Obsidian:Claude CLI × Ansible 運用の安定化手法
- プロンプトの再利用性を高める:Obsidian テンプレートで Claude CLI を安定運用
この記事の問い
Claude CLIは便利だが、プロンプトがブレると出力がブレる。
では、Obsidianを「プロンプト生成機(Prompt Factory)」にして、プロンプトの品質をテンプレ化・再利用・自動生成できるようにすると、Ansible運用はどれだけ安定するのか?
目次
- なぜ「Claude CLI × Ansible」だけだと運用がブレるのか
- Obsidianを「Prompt Factory」にする発想
- プロンプト自動生成の構成要素(ここが主役)
- 最小の具体例(再現できる)
- どこが"イノベーション"なのか(効率化と分けて語る)
- うまくいかないパターン
- 実務で回すための運用ルール
- 結論
1. なぜ「Claude CLI × Ansible」だけだと運用がブレるのか
生成品質の揺れはプロンプトの揺れ
Claude CLIを使ってAnsible playbookを生成する。便利だ。
しかし、同じ「nginx設定を追加して」という依頼でも、出力が毎回違う。
ある日は template モジュールを使い、別の日は lineinfile を使う。
ある日は handler を定義し、別の日は notify を忘れる。
なぜか?
プロンプトが違うからだ。
「nginx設定を追加して」と言ったのか。 「冪等性を担保してnginx設定を追加して」と言ったのか。 「template モジュールを使って nginx の gzip 設定を追加して、handler で reload して」と言ったのか。
AIの出力品質は、入力品質に依存する。ブレた入力からは、ブレた出力しか得られない。
“毎回いい感じに頼む"の限界
実務では、こうなりがちだ:
あなた:「nginx設定を更新するplaybook作って」
Claude:(何かを生成する)
あなた:「あ、gzip設定も入れて」
Claude:(修正する)
あなた:「handler忘れてるよ」
Claude:(また修正する)
これは対話的で柔軟だが、再現性がない。
同じ作業を来月やるとき、同じ品質のplaybookが生成される保証はない。 自分の調子、Claudeの調子、その日の言い回し、すべてが影響する。
“毎回いい感じに頼む"は、運用ではなくアドホックだ。
人間の思考が散らばる問題
さらに深刻なのは、プロンプトを考えるたびに思考が散らばることだ。
「このplaybookでは何を守るべきだっけ」 「うちのチームのベストプラクティスは何だっけ」 「前回どう指示したっけ」
毎回ゼロから考える。毎回、暗黙知を思い出す。毎回、車輪を再発明する。
これは非効率なだけでなく、品質が安定しない原因だ。
暗黙知は、明文化されていない限り、再現できない。
2. Obsidianを「Prompt Factory」にする発想
ノート = ドキュメントではなく"生成元”
Obsidianは、普通に使えばナレッジベースだ。メモを書き、リンクでつなぎ、知識を整理する。
しかし、この記事で提案するのは、Obsidianを「プロンプト生成機」として使う発想だ。
ノートは「読むためのドキュメント」ではない。 ノートは「プロンプトをコンパイルするためのソースコード」だ。
flowchart TB
subgraph Obsidian["Obsidian(Prompt Factory)"]
direction TB
FM["Frontmatter(変数・メタデータ)"]
TPL["テンプレート(プロンプト構造)"]
DV["過去の判断・制約(Dataview参照)"]
FM --> Compile
TPL --> Compile
DV --> Compile
Compile["コンパイル"] --> FinalPrompt["最終プロンプト"]
end
subgraph Claude["Claude CLI(生成エンジン)"]
direction TB
Receive["プロンプトを受け取り"]
Generate["Ansible playbookを生成"]
Receive --> Generate
end
subgraph Ansible["Ansible(実行器)"]
direction TB
Check["--check で事前確認"]
Diff["--diff で変更差分確認"]
Apply["問題なければ適用"]
Check --> Diff --> Apply
end
Obsidian --> Claude --> Ansible
Obsidianはコンパイラ。Claudeは生成器。Ansibleは実行器。
この役割分担が、運用を安定させる。
テンプレート/変数/Frontmatterでプロンプトを構造化する
プロンプトを「テキストの塊」として扱うのをやめる。
代わりに、プロンプトを構造化されたデータとして扱う:
- Frontmatter:変数やメタデータ(OS、対象、制約など)
- テンプレート:プロンプトの骨格(Templaterプラグインで展開)
- 参照データ:過去の判断やベストプラクティス(Dataviewで差し込み)
これにより、プロンプトは「その場の思いつき」ではなく「設計されたもの」になる。
プロンプトをコードのようにバージョン管理する
ObsidianのVaultはフォルダだ。Gitで管理できる。
プロンプトテンプレートの変更履歴が残る。 「このテンプレートをいつ、なぜ変更したか」が追える。 チームで共有すれば、プロンプトの標準化ができる。
プロンプトをコードのように扱う。これがPrompt Factoryの核心だ。
3. プロンプト自動生成の構成要素(ここが主役)
3-1. Frontmatter:プロンプトの変数を定義する
Obsidianノートの先頭に書くYAML形式のメタデータ。これがプロンプトの「パラメータ」になる。
---
target: nginx
task_type: config_update
os: Ubuntu 22.04
package_manager: apt
constraints:
- 既存設定を壊さない
- handler で reload(restart は避ける)
- 冪等性を担保
modules_preferred:
- template
- lineinfile
modules_avoid:
- shell
- command
related_notes:
- "[[nginx-best-practices]]"
- "[[ansible-coding-standards]]"
---
なぜ Frontmatter が必要か?
- プロンプトの変数を明示的に定義できる
- 「何を指示しているか」が一目で分かる
- 変数を変えれば、別の文脈に再利用できる
- Dataviewで検索・集計できる
3-2. Templater:テンプレートから最終プロンプトを生成する
Templaterは、Obsidianのプラグインだ。テンプレートに変数を埋め込み、最終的なテキストを生成する。
プロンプトテンプレートの例:
<%*
const fm = tp.frontmatter;
-%>
# Claude CLI 用プロンプト
以下の条件で Ansible playbook を生成してください。
## 対象
- ターゲット: <% fm.target %>
- OS: <% fm.os %>
- パッケージマネージャ: <% fm.package_manager %>
## タスク種別
<% fm.task_type %>
## 制約条件
<% fm.constraints.map(c => `- ${c}`).join('\n') %>
## 使用すべきモジュール
<% fm.modules_preferred.map(m => `- ${m}`).join('\n') %>
## 使用を避けるモジュール
<% fm.modules_avoid.map(m => `- ${m}`).join('\n') %>
## 参照すべきベストプラクティス
<% fm.related_notes.join('\n') %>
## 出力形式
- YAML形式
- コメントで各taskの意図を記載
- handler を適切に定義
なぜ Templater が必要か?
- 毎回同じ構造のプロンプトが生成される
- 変数だけ変えれば、異なる文脈に適用できる
- プロンプトの「書き忘れ」を防げる(テンプレートに入っていれば必ず出力される)
- チームで共有すれば、プロンプト品質が標準化される
3-3. QuickAdd:入力UIで変数を埋める
QuickAddは、Obsidianのプラグインだ。フォーム形式で変数を入力し、ノートを自動生成する。
┌─────────────────────────────────────┐
│ 新規 Ansible プロンプト作成 │
├─────────────────────────────────────┤
│ ターゲット: [nginx ] │
│ OS: [Ubuntu 22.04 ▼] │
│ タスク種別: [config_update▼] │
│ 制約: [冪等性担保, handler...]│
│ │
│ [作成] [キャンセル] │
└─────────────────────────────────────┘
なぜ QuickAdd が必要か?
- Frontmatterを手書きしなくていい
- 選択式にすれば、入力ミスを防げる
- 「このパラメータは必須」を強制できる
- 非エンジニアでもプロンプトを生成できる(標準化の極み)
3-4. Dataview:過去の判断・制約・ベストプラクティスを差し込む
Dataviewは、Obsidianのプラグインだ。ノートをデータベースのようにクエリし、動的に情報を埋め込む。
プロンプトに過去の判断を自動挿入する例:
## 過去の関連判断(自動取得)
```dataview
LIST
FROM "decisions"
WHERE contains(tags, "nginx") OR contains(tags, "ansible")
SORT date DESC
LIMIT 5
これにより、プロンプト生成時に「過去にnginxやansibleで何を決めたか」が自動で差し込まれる。
なぜ Dataview が必要か?
- 過去の判断を忘れない(同じ失敗を繰り返さない)
- ベストプラクティスを毎回参照できる
- プロンプトが「今だけの情報」ではなく「蓄積された知識」を含む
- 暗黙知を明文化し、プロンプトに組み込める
構成要素の関係図
flowchart TB
subgraph Vault["Obsidian Vault"]
direction TB
QuickAdd["QuickAdd<br/>(入力UI)"]
Frontmatter["Frontmatter(変数)<br/>target, os, constraints..."]
Dataview["Dataview<br/>(過去の判断)"]
Templater["Templater(展開)<br/>テンプレート + 変数 → 最終形"]
Output["最終プロンプト(出力)<br/>Claude CLI にコピペ or パイプ"]
QuickAdd --> Frontmatter
Frontmatter --> Templater
Dataview --> Templater
Templater --> Output
end
4. 最小の具体例(再現できる)
4-1. Obsidianノート(Frontmatter + テンプレート呼び出し)
ファイル名:prompts/nginx-gzip-config.md
---
target: nginx
task_type: config_update
description: gzip圧縮を有効化
os: Ubuntu 22.04
package_manager: apt
constraints:
- 既存の nginx.conf を上書きしない
- gzip 関連の設定のみ追加
- handler で reload(restart は避ける)
- 冪等性を担保
modules_preferred:
- template
- blockinfile
modules_avoid:
- shell
- command
- raw
handler_action: reload
created: 2026-01-02
---
# nginx gzip設定追加プロンプト
<% tp.file.include("[[_templates/ansible-prompt-template]]") %>
4-2. テンプレートファイル
ファイル名:_templates/ansible-prompt-template.md
<%*
const fm = tp.frontmatter;
-%>
## Claude CLI 用プロンプト(自動生成)
以下の条件で Ansible task を生成してください。
### 基本情報
- **対象**: <% fm.target %>
- **タスク種別**: <% fm.task_type %>
- **説明**: <% fm.description %>
### 環境
- **OS**: <% fm.os %>
- **パッケージマネージャ**: <% fm.package_manager %>
### 制約条件(必ず守ること)
<% fm.constraints.map(c => `- ${c}`).join('\n') %>
### 使用すべきモジュール
<% fm.modules_preferred.map(m => `- ${m}(推奨)`).join('\n') %>
### 使用禁止モジュール
<% fm.modules_avoid.map(m => `- ${m}(使用しないこと)`).join('\n') %>
### Handler
- アクション: `<% fm.handler_action %>`
- サービス名: `<% fm.target %>`
### 出力フォーマット
- YAML形式
- 各taskに `name` と意図を示すコメント
- 変数は `{{ }}` で参照
- handler は tasks と同じファイル内に定義
---
**生成開始してください。**
4-3. 生成される最終プロンプト
Templaterで展開後のノート内容:
## Claude CLI 用プロンプト(自動生成)
以下の条件で Ansible task を生成してください。
### 基本情報
- **対象**: nginx
- **タスク種別**: config_update
- **説明**: gzip圧縮を有効化
### 環境
- **OS**: Ubuntu 22.04
- **パッケージマネージャ**: apt
### 制約条件(必ず守ること)
- 既存の nginx.conf を上書きしない
- gzip 関連の設定のみ追加
- handler で reload(restart は避ける)
- 冪等性を担保
### 使用すべきモジュール
- template(推奨)
- blockinfile(推奨)
### 使用禁止モジュール
- shell(使用しないこと)
- command(使用しないこと)
- raw(使用しないこと)
### Handler
- アクション: `reload`
- サービス名: `nginx`
### 出力フォーマット
- YAML形式
- 各taskに `name` と意図を示すコメント
- 変数は `{{ }}` で参照
- handler は tasks と同じファイル内に定義
---
**生成開始してください。**
4-4. Claude CLIコマンド例
# プロンプトをファイルから読み込んで Claude CLI に渡す
cat ~/Obsidian/Vault/prompts/nginx-gzip-config.md | claude
# または、クリップボードにコピーしてから
pbpaste | claude # macOS
xclip -selection clipboard -o | claude # Linux
# 出力をファイルに保存
cat ~/Obsidian/Vault/prompts/nginx-gzip-config.md | claude > roles/nginx/tasks/gzip.yml
4-5. Ansible –check / –diff で安全に試す流れ
# 1. 静的解析(構文・ベストプラクティスチェック)
ansible-lint roles/nginx/tasks/gzip.yml
# 2. Dry-run(実際には変更しない)
ansible-playbook site.yml --check --diff --tags nginx-gzip
# 3. 出力を確認し、問題なければ適用
ansible-playbook site.yml --tags nginx-gzip
# 4. 適用後の状態確認
ansible-playbook site.yml --check --diff --tags nginx-gzip
# → "changed=0" なら冪等性が担保されている
このフローで重要なのは、人間の判断ポイントが明確なこと:
- プロンプトの変数を設定する → 人間
- 生成されたYAMLを確認する → 人間
--checkの結果を見て適用を判断する → 人間
AIは変換を担当するが、判断は人間が担当する。
5. どこが"イノベーション"なのか(効率化と分けて語る)
速度ではなく「品質の再現性」
このワークフローで短縮されるのは、「タイピング時間」だけではない。
本質的な価値は、同じ品質のプロンプトを、何度でも、誰でも生成できることだ。
- 月曜の自分も、金曜の自分も、同じプロンプトを生成できる
- 新人エンジニアも、ベテランも、同じプロンプトを生成できる
- 疲れているときも、集中しているときも、同じプロンプトを生成できる
品質の再現性。これが効率化とは異なる価値だ。
プロンプトの属人性を下げる
「あの人が頼むとうまくいくけど、自分が頼むとイマイチ」
これは、プロンプトの属人性だ。
テンプレート化されたプロンプトは、暗黙知を明文化したものだ。 「冪等性を担保」「shellモジュールは避ける」「handlerでreload」 これらの知識が、テンプレートに埋め込まれている。
属人的なノウハウを、チームの資産に変換できる。
失敗が"次のテンプレ改善"として積み上がる
プロンプトがブレていた時代、失敗は「たまたま」だった。
「今日はプロンプトの書き方が悪かった」で終わり、改善が蓄積しない。
テンプレート化されたプロンプトでは、失敗はテンプレートの欠陥として認識される。
「このテンプレートでは、XXXの指示が漏れていた」 → テンプレートを修正する → 次回以降、同じ失敗は起きない
失敗が、システムの改善として積み上がる。
これは、個人の学習ではなく、組織の学習だ。
6. うまくいかないパターン
テンプレが肥大化して逆に読めない
「あれも入れよう」「これも入れよう」を繰り返すと、テンプレートが巨大化する。
## 制約条件
- 冪等性を担保
- 既存設定を壊さない
- shellモジュールは使わない
- commandモジュールも使わない
- rawモジュールも使わない
- ...(50行続く)
対策:テンプレートは「最小限」を維持する。共通の制約は別ノートに切り出し、Dataviewで参照する。
変数設計が雑で出力が崩れる
Frontmatterの変数が曖昧だと、テンプレートの出力も曖昧になる。
constraints:
- いい感じにして
- よしなに
これでは、プロンプトも曖昧になる。
対策:変数は具体的に。「いい感じに」ではなく「冪等性を担保」のように、検証可能な表現で書く。
Obsidianがメモ倉庫に戻る
気づいたら、プロンプトテンプレートではなく、作業ログを書いている。
# 今日やったこと
- nginx設定を変えた
- なんか動いた
これはメモであり、Prompt Factoryではない。
対策:プロンプト用のフォルダを分離する(prompts/、_templates/)。メモと混ぜない。
Ansible理解なしで生成物を採用して壊す
Claude CLIが生成したplaybookを、理解せずにそのまま適用する。
# AIが生成したが、実は危険
- name: 設定を更新
shell: rm -rf /etc/nginx && cp -r ./nginx /etc/
見た目は動くが、冪等性がない。--check でも検出されない。
対策:Ansibleの基礎を理解する。少なくとも「冪等性」「モジュールの選び方」「handlerの意味」は把握した上で使う。
7. 実務で回すための運用ルール
7-1. テンプレートの責務分離(目的別に分ける)
1つのテンプレートに全部入れない。目的別に分離する。
_templates/
├── ansible-prompt-base.md # 基本構造(全プロンプト共通)
├── ansible-prompt-config.md # 設定変更系(nginx, apache, etc.)
├── ansible-prompt-package.md # パッケージ管理系
├── ansible-prompt-user.md # ユーザー管理系
└── ansible-prompt-security.md # セキュリティ設定系
ルール:新しいカテゴリが出てきたら、新しいテンプレートを作る。既存テンプレートを肥大化させない。
7-2. “チェック→差分→適用"のゲート
どんなに良いプロンプトでも、生成物を無条件に適用しない。
flowchart TB
PromptGen["プロンプト生成"] --> ClaudeCLI["Claude CLI実行"] --> YAML["YAML生成"]
YAML --> Gate1{"ゲート1: ansible-lint<br/>静的解析パス?"}
Gate1 -->|Yes| Gate2{"ゲート2: --check --diff<br/>変更内容は妥当?"}
Gate1 -->|No| Fix1["修正"]
Fix1 --> YAML
Gate2 -->|Yes| Gate3{"ゲート3: 人間のレビュー<br/>この変更を適用する?"}
Gate2 -->|No| Fix2["修正"]
Fix2 --> ClaudeCLI
Gate3 -->|Yes| Apply["適用"]
Gate3 -->|No| Fix3["修正"]
Fix3 --> ClaudeCLI
ルール:3つのゲートすべてを通過しないと適用しない。
7-3. Gitでテンプレートと生成物をどう扱うか
リポジトリ構成:
├── ansible/
│ ├── roles/
│ │ └── nginx/
│ │ └── tasks/
│ │ └── gzip.yml # 生成物(Git管理)
│ └── site.yml
└── obsidian-vault/
├── prompts/
│ └── nginx-gzip-config.md # プロンプトソース(Git管理)
└── _templates/
└── ansible-prompt-*.md # テンプレート(Git管理)
ルール:
- テンプレートと生成物を両方Git管理する
- コミットメッセージに「どのプロンプトから生成したか」を記載する
- テンプレート変更時は、影響を受ける生成物を再生成する
7-4. チームに渡すならどこまで標準化するか
| レベル | 内容 | 適用場面 |
|---|---|---|
| Lv.1 | テンプレートのみ共有 | 各自がFrontmatterを書く |
| Lv.2 | QuickAddの入力フォームも共有 | 入力ミスを防ぎたい |
| Lv.3 | 制約条件もDataviewで自動挿入 | チームのベストプラクティスを強制 |
| Lv.4 | CI/CDでプロンプト検証 | プロンプト品質をゲートに |
ルール:最初はLv.1から始める。必要に応じてレベルを上げる。最初から完璧を目指さない。
8. 結論
Obsidianは「思考の置き場」ではなく「プロンプトのOS」
Obsidianをナレッジベースとして使うのは、よくある使い方だ。
しかし、この記事で示したのは、Obsidianをプロンプトの生成基盤として使うアプローチだ。
- Frontmatterで変数を定義し
- Templaterでテンプレートを展開し
- QuickAddで入力を標準化し
- Dataviewで過去の知識を差し込む
これらを組み合わせると、Obsidianは「プロンプトのOS」になる。
Claudeは生成のエンジン、Ansibleは実行の器
役割を混ぜてはいけない。
- Obsidian:プロンプトをコンパイルする
- Claude CLI:プロンプトを受け取り、コードを生成する
- Ansible:生成されたコードを、安全に実行する
Claude CLIに設計を任せない。Ansibleに判断を任せない。それぞれの役割を守る。
AI時代の勝ち筋は"プロンプトを資産化する仕組み"にある
AIを使う人は増えた。
しかし、プロンプトを資産化している人は、まだ少ない。
毎回ゼロからプロンプトを考える人と、テンプレートから高品質なプロンプトを生成する人。長期的に見れば、後者が優位に立つ。
プロンプトは、書き捨てるものではない。設計し、管理し、改善し続けるものだ。
Obsidian × Claude CLI × Ansible の組み合わせは、その一つの形だ。
追加出力
この記事の要約(3パターン)
-
一言版:Obsidianをプロンプト生成機にすることで、Claude CLI × Ansible 運用の品質が安定する。
-
概要版:Claude CLIの出力品質は入力(プロンプト)に依存する。Obsidianの Frontmatter・Templater・QuickAdd・Dataview を組み合わせ、プロンプトをテンプレート化・自動生成することで、属人性を排除し、再現性のある高品質な Ansible playbook 生成を実現できる。
-
思想版:AIの価値を引き出すのは、プロンプトの品質だ。プロンプトをコードのように構造化・バージョン管理・改善し続ける仕組みを持つ者が、AI時代に優位に立つ。Obsidianは、そのための「プロンプトOS」になり得る。
X(Twitter)向け紹介文
Claude CLIの出力がブレるのは、プロンプトがブレるから。
「毎回いい感じに頼む」から脱却するため、
Obsidianを「プロンプト生成機」にしてみた。
Frontmatter で変数定義
Templater でテンプレート展開
Dataview で過去の判断を自動挿入
プロンプトをコードのように扱う。
Ansible運用の安定性が変わった。
#Obsidian #ClaudeCLI #Ansible
続編テーマ案(5件)
-
Obsidian Templater 実践レシピ集:Ansible以外のプロンプトテンプレート例
- Terraform、Kubernetes、Docker Compose など、他のIaCツール向けテンプレート
-
QuickAdd × Dataview でプロンプト入力を完全自動化する方法
- 入力フォーム設計、選択肢の動的生成、バリデーション
-
プロンプトのCI/CD:GitHub Actions でプロンプト品質をゲートする
- プロンプトのlint、テンプレートの整合性チェック、変更レビュー自動化
-
チームでプロンプトを共有する:Obsidian Vault の設計とガバナンス
- フォルダ構成、命名規則、レビュープロセス、オンボーディング
-
プロンプト改善サイクルの回し方:失敗から学ぶテンプレート進化
- 失敗の記録方法、改善のトリガー、バージョニング戦略