[!NOTE]
【この記事の要約（TL;DR）】
- プロンプト指示の限界: 確率モデルであるLLMに対して、プロンプトだけで出力形式やファイル操作の100%の規律を求めると、一定の確率で形式崩れやすり抜けが発生し、人間が目視検品係になる本末転倒が起きる。
- 二層防御アーキテクチャ: 発想や文章作成を担う「生成層（LLM）」と、形式検査・上書き防止を担う「規律層（決定論的Pythonコード）」を完全分離する。
- 3つの実践ガードレール: ①本番予約枠の物理的重複遮断、②YAML FrontmatterとMarkdown独自記法のLinter、③文字数・行数のハードリミットにより、認知負荷を大幅に削減してObsidian等のナレッジ品質を安定維持する。
導入：AIの出力を「疑う時間」は最大の隠れコストだった
AIエージェントやLLMを活用して、ブログ記事の下書き作成やObsidianへの情報蓄積、日々の業務自動化を組み上げることは、いまや僕の開発や発信に欠かせない日常になりました。
ですが、自動化を回し続ける中で、僕はずっと「ある地味で強烈なストレス」と格闘していました。
- プロンプトへの過信とすり抜け: 「JSONで出力して」「1行13文字以内で」「特定の記号は外側に置いて」とどれだけ厳密に指示しても、数回に1回フォーマットが崩れる
- 人間が「AIの検品係」になる本末転倒: 生成テキストをCMSやObsidianに保存する前に、タグの破損やキーの抜けがないか、僕自身が目を凝らして手動修正している
- モデル進化への脆さ: 最新モデルに切り替えた瞬間、出力の癖が微妙に変わり、後続の自動化パイプライン全体が止まってしまう
「自動化して時間を節約したはずなのに、形式のチェックと手直しで結局脳のエネルギーをすり減らしている」――。
この違和感に向き合ったとき、僕はひとつの根本的な事実に気づきました。
数学的に確率で推論するLLMに対して、プロンプト（言葉）だけで100%の決定論的規律を守らせようとすること自体が、設計としてのアンチパターンだったのです。
1. 現場で起きたヒヤリハット：なぜ「プロンプト信仰」は破綻したのか
AIにすべてを任せきりにしていた頃、僕の現場ではいくつかの冷や汗をかく出来事がありました。
① 丹精込めて推敲した「本番予約枠」の上書き危機
「明日の下書きを作っておいて」とAIに指示した際、AIが親切心を働かせて、すでにスケジュール表に登録されていた本番枠（例: 08:00 や 18:00）と同じファイル名で出力し、既存の完成原稿を上書き保存しそうになったことがありました。
AIに悪気はありません。ですが、「既存の本番ファイルが存在するかどうか」を推論だけで判定させようとすると、文脈の解釈違いで取り返しのつかない事故が起きます。
② WordPressの表示を壊す「太字記号の巻き込み」
WordPressの投稿処理において、太字マーカーの内側に括弧を含めてしまうと、HTML変換時にタグ構造が崩れる現象があります。
プロンプトに「括弧は太字の外側に置くこと」とどれだけ注意書きを添えても、数万文字を生成する中でたまにすり抜けてしまいます。そのたびに僕が手動で検索して直す作業が発生していました。
③ 確率的推論（Probabilistic）の壁
LLMは「意味の理解と生成」に特化した確率モデルです。サンプリング温度（Temperature）を0に設定した場合でも、実装環境・バッチ処理・APIの仕様差異によって、完全な決定性（再現性）が保証されるとは限りません。自動化において、この微小なブレがパイプラインを止めていたのです。
2. 解決策：二層防御アーキテクチャ（Dual-Layer Architecture）
この失敗を繰り返して僕がたどり着いた結論が、「生成層（Generative Layer）」と「規律層（Deterministic Guardrail Layer）」の責務を明確に分離することでした。
flowchart TD
A["僕の思考・一次情報"] --> B["【第1層：生成層】<br/>LLMによる確率的生成<br/>（思考・文章作成・発想・多角分析）"]
B --> C{"【第2層：規律層】<br/>決定論的コード（Python / Linter）<br/>（型・文字数・重複・構文の冷徹検査）"}
C -- "規律違反検知（REJECT）" --> D["自動修復 or 即時差し戻し"]
D --> B
C -- "全検査クリア（PASS）" --> E["【安全な永続層】<br/>Obsidian Vault / CMS / 本番DB"]
style B fill:#121212,stroke:#7DCA7E,stroke-width:2px,color:#fff
style C fill:#7DCA7E,stroke:#000,stroke-width:2px,color:#000
style E fill:#121212,stroke:#7DCA7E,stroke-width:2px,color:#fff役割分担の原則
- 生成層（Generative Layer / LLM）:
- 担当: 文脈理解、構成の提案、アイデアの壁打ち、表現の豊かさ
- 指針: 「正しさの保証」に過度なリソースを割かせず、創造と推論のスピードを最大化する。
- 規律層（Deterministic Guardrail Layer / Code）:
- 担当: YAMLパーサーによるFrontmatter検証、文字数・行数のハードリミット、ファイル重複防止、プロジェクト独自ルールのLinting
- 指針: 定義したルールに対して、決定論的かつ再現性のある判定を行う。
「AIを優秀な新人スタッフと見立て、その直後に冷徹な自動検品ゲートを置く。」
AIにルールを「守らせる」のではなく、コードで境界線を「守る」。
この境界線を物理的なプログラムで引いた瞬間、僕の自動化運用は劇的な平穏を取り戻しました。
3. 実装パターン：僕の環境で実際に動かしている3つのガードレール
現在、僕のシステムで実際に高い耐障害性を発揮している、3つのガードレール実装をご紹介します。
パターン1：物理的リソース保護（重複・上書き防止ゲート）
AIが生成したファイルパスが、スケジュール済みの本番枠や既存の資産ファイルを破壊しないよう、保存の手前で強制的にインターセプトします。
import os
def enforce_safe_filepath(target_path: str, is_sample: bool = False) -> str:
"""本番予約枠の誤上書きを物理的に遮断するガードレール"""
basename = os.path.basename(target_path)
# 本番予約枠（例: 0800, 1800）を含むファイルの上書きをコードレベルで拒絶
protected_slots = ["0800", "1800"]
if not is_sample and any(slot in basename for slot in protected_slots):
if os.path.exists(target_path):
raise PermissionError(f"[CRITICAL] 本番予約枠 {basename} の上書きを物理的に遮断しました。")
return target_pathパターン2：構文Linter（YAMLパーサー ＆ 独自記法検査）
本文中の文字列に惑わされず、YAML Frontmatterを正式にパースして必須キーとデータ型を検証し、プロジェクト固有の記法ルールを検査します。
import re
import yaml
def lint_article_syntax(content: str) -> None:
"""YAMLパーサーと独自ルールによる決定論的Linter"""
errors = []
# 1. YAML Frontmatterの抽出と厳格な型検証
frontmatter_match = re.match(r"^---\n(.*?)\n---\n", content, re.DOTALL)
if not frontmatter_match:
errors.append("SchemaError: Frontmatter (---) が正しく定義されていません。")
else:
try:
metadata = yaml.safe_load(frontmatter_match.group(1))
required_keys = ["title", "slug", "date", "description"]
for key in required_keys:
if key not in metadata or not metadata[key]:
errors.append(f"SchemaError: 必須メタデータ '{key}' が欠落しています。")
except yaml.YAMLError as e:
errors.append(f"YAMLError: Frontmatterのパースに失敗しました: {e}")
# 2. プロジェクト独自ルールの検証（例: 太字記法の括弧内包チェック）
bad_bold_regex = r'\*\*([「『（【][^_\*]+?[」』）】])\*\*'
if re.search(bad_bold_regex, content):
errors.append("RuleError: 太字(**)の内側に括弧が含まれています。『「**テキスト**」』の形式に統一してください。")
if errors:
raise ValueError("\n".join(errors))パターン3：UI・レイアウト保護（文字数・行数のハードリミット）
テロップや要約バナー等の表示領域制限に対して、「短めにして」というプロンプトではなく、文字数カウントによる物理的判定を下します。
def validate_ui_constraints(text: str, max_chars: int = 13, max_lines: int = 2) -> bool:
"""テロップやスピーチバナーの表示崩れを防ぐハードリミット"""
lines = [line.strip() for line in text.split("\n") if line.strip()]
if len(lines) > max_lines:
raise ValueError(f"LayoutError: 最大{max_lines}行を超過しています（現在: {len(lines)}行）")
for line in lines:
if len(line) > max_chars:
raise ValueError(f"LayoutError: 1行最大{max_chars}文字を超過: '{line}' ({len(line)}字)")
return True4. 導入して変わったこと：Obsidianが「散らからない第二の脳」へ
二層防御アーキテクチャを導入してから、日々の運用の手触り感は劇的に変わりました。
| 指標 | 従来のプロンプト依存型 | 二層防御アーキテクチャ導入後 |
|---|---|---|
| 形式確認コスト | 毎回人間が目視チェックし手動修正 | 規律層が形式要件を保証し、目視確認の手間を大幅削減 |
| ナレッジ管理の質 | 表記揺れ・タグ破損でObsidianが散らかる | 常に完全構造化された高純度の知識資産を維持 |
| モデル移行耐性 | モデル変更のたびに出力崩れの調査が発生 | モデル非依存（規律層が常に同一の基準で監査・防御） |
- 目視確認のストレスが消えた
「どこかにタグの閉じ忘れがあるのではないか」と疑いながらテキストを見る必要がなくなりました。規律層を通過した時点で、少なくとも定義した形式要件についてはチェック済みになるため、純粋に文章の中身やメッセージの推敲だけに集中できます。 - ナレッジベース（Obsidian）の品質が安定した
メタデータと構文が体系的に保護されるため、Dataview等の集計やハブノート（MOC）とのリンクが壊れるケースも大幅に減りました。Obsidianが「いつ開いても美しい状態」を保てています。 - 最新モデルへの変更に怯えなくなった
基盤モデルを最新のものに切り替えても、最後の防波堤がコードで守られているため、出力の癖でシステム全体が壊れる心配がありません。
5. 結論：AIに「お願いする」のをやめ、コードで境界線を引く
真に実用的なAI自動化とは、AIの「知能」にすべてを丸投げすることではありません。
- AI（確率モデル）の役割: 僕たちの思考を拡張し、豊かな表現と洞察を最速で生み出すこと。
- プログラム（決定論的コード）の役割: システムの境界線を守り、規律と形式の一貫性を担保すること。
プロンプトで無理やりルールを縛り付けるのをやめ、保存の手前にYAMLパーサーや正規表現によるPython検品レイヤを挟む。
AIに「守らせる」のではなく、コードで「守る」。
このシンプルな二層設計こそが、僕たちのシステムを「壊れやすい実験作」から「揺るぎない実用基盤」へと進化させる確かなアプローチだと確信しています。