SEOを意識した代替タイトル案(10件)

  1. Obsidianをプロンプト生成機にする:Claude CLI × Ansible 運用安定化の実践
  2. プロンプトの品質を資産化する:Obsidian × Claude CLI × Ansible のワークフロー
  3. 毎回いい感じに頼む をやめる:Obsidianでプロンプトをテンプレ化する方法
  4. Claude CLIの出力がブレる原因はプロンプト:Obsidianで解決するアプローチ
  5. プロンプトをコードのように管理する:Obsidian × Claude CLI × Ansible
  6. Obsidian × Templater × Claude CLI:プロンプト自動生成でAnsible運用を安定化
  7. AIの出力品質は入力で決まる:Obsidianをプロンプトコンパイラにする発想
  8. 属人的なプロンプトを標準化する:Obsidian × Claude CLI × Ansible の仕組み
  9. Prompt Factoryとしての Obsidian:Claude CLI × Ansible 運用の安定化手法
  10. プロンプトの再利用性を高める:Obsidian テンプレートで Claude CLI を安定運用

この記事の問い

Claude CLIは便利だが、プロンプトがブレると出力がブレる。

では、Obsidianを「プロンプト生成機(Prompt Factory)」にして、プロンプトの品質をテンプレ化・再利用・自動生成できるようにすると、Ansible運用はどれだけ安定するのか?


目次

  1. なぜ「Claude CLI × Ansible」だけだと運用がブレるのか
  2. Obsidianを「Prompt Factory」にする発想
  3. プロンプト自動生成の構成要素(ここが主役)
  4. 最小の具体例(再現できる)
  5. どこが"イノベーション"なのか(効率化と分けて語る)
  6. うまくいかないパターン
  7. 実務で回すための運用ルール
  8. 結論

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" なら冪等性が担保されている
  

このフローで重要なのは、人間の判断ポイントが明確なこと

  1. プロンプトの変数を設定する → 人間
  2. 生成されたYAMLを確認する → 人間
  3. --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パターン)

  1. 一言版:Obsidianをプロンプト生成機にすることで、Claude CLI × Ansible 運用の品質が安定する。

  2. 概要版:Claude CLIの出力品質は入力(プロンプト)に依存する。Obsidianの Frontmatter・Templater・QuickAdd・Dataview を組み合わせ、プロンプトをテンプレート化・自動生成することで、属人性を排除し、再現性のある高品質な Ansible playbook 生成を実現できる。

  3. 思想版:AIの価値を引き出すのは、プロンプトの品質だ。プロンプトをコードのように構造化・バージョン管理・改善し続ける仕組みを持つ者が、AI時代に優位に立つ。Obsidianは、そのための「プロンプトOS」になり得る。


X(Twitter)向け紹介文

    Claude CLIの出力がブレるのは、プロンプトがブレるから。

「毎回いい感じに頼む」から脱却するため、
Obsidianを「プロンプト生成機」にしてみた。

Frontmatter で変数定義
Templater でテンプレート展開
Dataview で過去の判断を自動挿入

プロンプトをコードのように扱う。
Ansible運用の安定性が変わった。

#Obsidian #ClaudeCLI #Ansible
  

続編テーマ案(5件)

  1. Obsidian Templater 実践レシピ集:Ansible以外のプロンプトテンプレート例

    • Terraform、Kubernetes、Docker Compose など、他のIaCツール向けテンプレート
  2. QuickAdd × Dataview でプロンプト入力を完全自動化する方法

    • 入力フォーム設計、選択肢の動的生成、バリデーション
  3. プロンプトのCI/CD:GitHub Actions でプロンプト品質をゲートする

    • プロンプトのlint、テンプレートの整合性チェック、変更レビュー自動化
  4. チームでプロンプトを共有する:Obsidian Vault の設計とガバナンス

    • フォルダ構成、命名規則、レビュープロセス、オンボーディング
  5. プロンプト改善サイクルの回し方:失敗から学ぶテンプレート進化

    • 失敗の記録方法、改善のトリガー、バージョニング戦略