2026-09-23 · code

Claude Codeで2サイトを並行運営して3ヶ月、プロンプト設計を「再利用できる型」に分解したら記事生成の手戻りが1/3になった話

本記事は広告（アフィリエイトリンク）を含みます。掲載商品の購入によって運営者に紹介料が発生することがあります。内容は当サイト運営の独立した判断に基づいて選定しています。アフィリエイト表記

Claude Codeで2サイト並行運営を始めて3ヶ月が経った

私は現在、urisol.com（法人・NDT技術記事）と urinosuke.com（個人ペンネーム・biz/code/fi/life/side）の2つのサイトを Claude Code + GitHub Actions で自動投稿している。火木土の朝6時3分に記事が公開される仕組みだ。

運用開始から3ヶ月、記事本数は50本を超えた。この間に何度も「生成された記事が事実と異なる」「禁止事項を踏んでいる」といった手戻りが発生し、その都度プロンプトを修正してきた。最初は1本の記事を出すのに3〜5回の再生成が必要だったが、プロンプトを「指示・事実・禁止」の3層構造に分解してから手戻りが1/3に減った。

今回は、その設計の実録を書く。

最初のプロンプトは「全部入り」で破綻した

運用開始当初、私のプロンプトは1つの長大なファイルに「こういう記事を書いて」「こういうことは書かないで」「事実はこれ」を混在させていた。Claude Code に渡す指示は500行を超え、どこに何が書いてあるか自分でも把握できなくなっていた。

結果、次のような問題が頻発した。

事実と異なる年齢・経歴を書く（38歳を「50歳を迎える」と書く、NDT歴20年を「30年」と書く等）
未取得の資格を「取得済み」として書く（UT Level 2 は2026年1次合格・2次試験準備中なのに「Level 2 取得済み」と書く）
未実施の副業を「稼いでいる実績」として書く（潜水士は案件が少なく未継続なのに「潜水士で月収○万円」と書く）

これらは「プロンプトに書いてあるのに守られない」問題ではなく、プロンプト内で指示・事実・禁止が区別されておらず、Claude が優先順位を判断できない問題だった。

『LLMのプロンプトエンジニアリング』（オライリー）で Berryman と Ziegler が指摘するように、プロンプトは「何をするか」「何を参照するか」「何をしないか」を明確に分離する必要がある。私のプロンプトはこの分離ができていなかった。

「指示・事実・禁止」の3層に分解した

そこで、プロンプトを次の3層に分解した。

① 指示層（generate-post.py の System Prompt）

「あなたは urinosuke のブログ編集担当です」から始まる役割定義と、出力形式（JSON・Markdown・文字数・構成）の指示。ここには事実を書かない。事実は次の層に分離する。

② 事実層（author-facts.md + books.md）

著者の実体験・実績・実際に読んだ本だけをまとめたファイル。プロンプトには「以下の事実から外れた内容を書くのは厳禁」と前置きして差し込む。

author-facts.md: 年齢・キャリア・事業構造・資格・副業実績・資産状況・使用ツール・題材ドメイン・開示ホワイトリスト
books.md: 実際に読了した書籍のみ（ASIN・カテゴリ・読了メモ付き）

この2ファイルは「事実の根拠」として機能する。Claude がここに載っていない情報を書こうとすると、プロンプト内で矛盾が発生するため、生成精度が上がる。

③ 禁止層（プロンプト末尾の【書いてはいけないこと】）

過去に実際に発生した誤り・推測・捏造のパターンを箇条書きで列挙。例えば次のようなものだ。

年齢の断定禁止: 「今年50歳を迎える」等は事実と異なる。50歳論は「12年先を見据えた設計」として書く
未実施収入の事実化禁止: 日給・月収・年収の具体額を「稼いでいる実績」として書かない
未取得資格を達成済みとして書かない
内部情報を書かない: ディレクトリ名・ファイルパス・リポジトリ名・実行URL・シークレット名を本文に一切出さない
不正確な制度名・運営機関名を書かない: 小規模企業共済 / セーフティネット貸付 / 経営セーフティ共済の混同は頻発するため特に注意

この層は「過去の失敗事例集」であり、同じミスを繰り返さないためのガードレールとして機能する。

手戻りが1/3になった理由

3層に分けてから、記事生成の手戻りが明確に減った。以前は1本の記事に3〜5回の再生成が必要だったが、現在は1〜2回で完成する。

その理由は次の3つだ。

① 事実の参照元が明確になった

以前は「38歳」「NDT歴20年」「UT Level 2 は1次合格・2次準備中」といった情報がプロンプト全体に散らばっており、Claude がどこを参照すればよいか曖昧だった。事実層に集約したことで、Claude が「事実はここを見る」という参照先を持てるようになった。

② 禁止事項が「失敗パターン」として蓄積された

禁止層は、過去に実際に発生した誤りを「こういう書き方は禁止」という形で蓄積したものだ。例えば「UT Level 2 取得済み」と書いてしまった失敗があったため、「未取得資格を達成済みとして書かない」という禁止事項を追加した。

禁止層は運用しながら育てるものであり、手戻りが発生するたびに「なぜそのミスが起きたか」を分析して追記している。

③ 指示層がシンプルになった

事実と禁止を分離したことで、指示層は「役割・出力形式・構成」だけに集中できるようになった。プロンプト全体の見通しが良くなり、どこを修正すればどこに効くかが明確になった。

メンテナンス性も上がった

プロンプトを3層に分けたもう1つのメリットは、メンテナンス性の向上だ。

例えば、私は2026年8月に「マネーフォワード ME を13年使っている」という事実を author-facts.md に追加した。この追加は事実層だけに閉じており、指示層や禁止層には影響しない。

逆に、「内部情報（ディレクトリ名等）を書かない」という禁止事項を追加したときは、禁止層だけに追記すればよく、事実層には触らなかった。

どの層に何を書くかが明確なため、修正の影響範囲が限定される。これは『達人プログラマー』が指摘する「直交性」の実践でもある。

これから自動投稿を始める人へ

Claude Code や GPT を使って記事を自動生成する仕組みを作るなら、最初から「指示・事実・禁止」の3層に分けることを勧める。

指示層: 役割・出力形式・構成だけを書く
事実層: 著者の実体験・実績・実際に読んだ本だけをまとめる
禁止層: 過去の失敗事例を「こういう書き方は禁止」として蓄積する

この構造は、記事生成だけでなく、報告書・提案書・営業メールなど、定型的な文書を LLM に生成させる場面全般に応用できる。

私は現在、この3層構造を NDT検査の報告書生成にも転用できないか試している。報告書も「指示（様式）・事実（測定値）・禁止（誤記パターン）」の3層に分解できるはずだ。

まとめ

Claude Code で2サイトを3ヶ月運用して、プロンプトを「指示・事実・禁止」の3層に分解したら手戻りが1/3になった。事実の参照元が明確になり、禁止事項が失敗パターンとして蓄積され、指示層がシンプルになったことが理由だ。

この構造は、記事生成以外の定型文書にも応用できる。LLM を業務に組み込むなら、プロンプトを「再利用できる型」に分解することが運用の鍵になる。

参考

Anthropic Claude API Documentation: https://docs.anthropic.com/
GitHub Actions Documentation: https://docs.github.com/actions
Astro Content Collections: https://docs.astro.build/

まとめて読む: AI活用・自動化

← ブログ一覧へ戻る