提案書を送るたびに Claude Code に「このクライアントへの提案書を書いて」と頼んでいた時期がある。毎回それなりの文章が出てきた。しかし振り返ると、そこに「判断」はほぼなかった。案件名・金額・スケジュールを所定の位置に埋め込む、フォーマットをそろえる——それは決定論的な処理だ。AIに毎回考えさせる必要はない。
アプローチ：テンプレ JSON 定義 + Drive コピー + replaceAllText
八雲で採用しているのは3ステップのパイプラインだ。
**Step 1: JSON でテンプレを定義する。**書類の構造（見出し・本文段落・プレースホルダ）をローカルの JSON ファイルに書く。段落ごとに style（HEADING_1 / NORMAL_TEXT 等）と text（{{CASE_NAME}} のようなプレースホルダを含む）を定義する。
{
"title": "TEMPLATE_提案書",
"sections": [
{ "style": "HEADING_1", "text": "【案件情報】" },
{ "style": "NORMAL_TEXT", "text": "案件名: {{CASE_NAME}}", "text_style": { "color": "#666666" } },
{ "style": "NORMAL_TEXT", "text": "{{GREETING}}" },
{ "style": "NORMAL_TEXT", "text": "{{WORK_CONTENT}}" }
],
"placeholders": ["CASE_NAME", "GREETING", "WORK_CONTENT"]
}Step 2: Drive にテンプレートドキュメントを生成する。sync-doc-templates.py を実行すると、JSON の定義に従って Google Drive 上のテンプレ Doc が再構築される。新規作成時はドキュメント ID が config/google-ids.json に自動追記される。以降、Drive 上のドキュメントを直接編集してはならない——次回 sync で上書きされるからだ。
**Step 3: テンプレをコピーし、replaceAllText でプレースホルダを置換する。**案件が発生したら drive.files.copy でテンプレを案件フォルダにコピーし、Docs API の batchUpdate / replaceAllText でプレースホルダに実データを流し込む。完成した書類は所定のフォルダに配置されて終わり。AIが文章を「考える」のはコピーライティングが必要な箇所だけでよい。
構造：スタイル統一・差し込み変数・命名規則 SSOT
書類の見た目はすべて config/templates/_styles.json が定義するデザイントークンで制御する。フォント（Noto Sans JP）・サイズ（本文 10pt / H1 15pt）・行間（115%）・ページマージン（約 20mm）の定数が1ファイルに集まり、全テンプレがここから参照する。個別 JSON でこれらを再定義してはならない。
プレースホルダの命名は {{UPPER_SNAKE_CASE}} で統一する。変数名は specs/templates.md に一覧を持ち、どのスキルがどのプレースホルダを埋めるかをトレースできるようにしている。{{CASE_NAME}} は /scrape スキルが書き込み、{{PRICING}} は /propose スキルが書き込む、という責務の対応が明確だ。
書類の命名規則も SSOT に集約する。ドキュメント ID は config/google-ids.json が管理し、テンプレ名 → Drive ファイル ID のマッピングを持つ。スキルは ID をハードコードせず、キー名（template_proposal 等）で参照する。新規テンプレを追加しても、既存スキルのコードには触れなくてよい。
なお、法務書類（契約書・NDA・誓約書）は汎用スタイルとは別に legal スタイルセットを定義している。本文を明朝体（Noto Serif JP）・11pt・行間 150%・余白 25mm に切り替えることで、法律事務所慣行に準拠した見た目を自動的に適用できる。テンプレ JSON に "style_set": "legal" と一行書くだけで切り替わる。
sync スクリプトで Drive 反映、ローカルが SSOT
Drive 上のテンプレは「出力先」であり、「正本」ではない。正本はローカルの config/templates/*.json だ。この原則が崩れると二重管理が生じる。Drive で直接フォントを変えた、段落を追加した——次の sync でそれらはすべて失われる。
sync-doc-templates.py には dry-run モードがある。実際に Drive を変更する前に「何が変わるか」を確認できる。また、特定テンプレだけを対象にした部分同期も可能だ。
# 変更プレビュー
python3 scripts/templates/sync-doc-templates.py --dry-run
# 提案書テンプレだけ同期
python3 scripts/templates/sync-doc-templates.py proposal
# 全テンプレ一括同期
python3 scripts/templates/sync-doc-templates.pyconfig/templates/README.md がテンプレ一覧の目次を兼ねる。新しい JSON を追加したら README の一覧表を更新し、sync を走らせて Drive に反映する——この手順を CLAUDE.md のドキュメント自動更新ルールに明記することで、更新忘れを防止している。
運用してわかった効果と落とし穴
効果。書類フォーマットの「差異」がなくなった。手動で書いていた時代は提案書ごとにフォントや余白がわずかにズレていた。テンプレ駆動にしてからは全書類が同一の見た目で出力される。しかもスタイルを変えたいときは _styles.json の1箇所を修正して sync を走らせるだけで済む。
スキルの実装コストも下がった。/propose・/invoice・/estimate のような書類生成スキルは、テンプレコピー + replaceAllText の共通パターンを呼び出すだけでよい。書類固有の「組み立てロジック」をゼロから書く必要がない。
落とし穴。プレースホルダの過不足が問題になることがある。テンプレに {{CASE_URL}} を追加したのに、スキル側が埋める処理を持っていない——するとドキュメントに {{CASE_URL}} という文字列がそのまま残る。対策として、スキル実行後に replaceAllText の未置換プレースホルダを検出するバリデーションを挟んでいる。
もう一点。テンプレが増えすぎると管理が煩雑になる。現時点では16種類のテンプレが存在する。それぞれに JSON・Drive ドキュメント・README 記載・google-ids.json エントリが必要で、追加のたびに手順が多い。小さな差異（例: 送付文のバリエーション）はプレースホルダで吸収し、テンプレ種別を増やすことを避けるのが運用上の判断だ。
まとめ
「書類を作る」という行為は、テンプレートの構造・スタイル・プレースホルダが正しく設計されていれば、AIが考える余地のない決定論的処理になる。Claude Code にとって価値ある仕事は、どのテンプレを使うかの判断・プレースホルダに埋めるコピーの生成・状況に応じた追記など、「判断」が要る部分だ。その判断の前後を決定論的処理でサンドイッチする設計が、スキルの品質と速度を同時に高めている。
決定論的処理と LLM 呼び出しの使い分けについては モデル使い分けポリシー で詳述している。八雲の AI 駆動開発の全体設計は AI 駆動開発概論 を参照してほしい。