プロンプトエンジニアリングで実際に効いたこと、効かなかったこと。記事自動生成を毎朝回してわかった書き方
ブログ記事の自動生成パイプラインを運用しながらプロンプトを書き直し続けた記録。役割付与より具体例、出力形式の指定、XMLタグ構造化など実際に効いた書き方と、効かなかった俗説を正直に書く。
このブログには毎朝5時に記事を1本自動生成するパイプラインがあって、その生成プロンプトを私はもう何十回と書き直している。加えて開発はほぼClaude Code経由なので、起きている間の半分くらいはプロンプトを書いている計算になる。
その過程で「プロンプトエンジニアリング10のテクニック」みたいな記事もひと通り試した。結果、効いたものと効かなかったものがはっきり分かれた。効いたものは3つくらいしかない。順番に書く。
一番効いたのは、形容詞をやめて実物の例を貼ること
自動生成の初期、記事の文体を「一人称の体験ベースで、教科書調を避け、具体的に」と形容詞で指示していた。出てくるのは「〜と言えるでしょう」「いかがでしたか」で埋まった教科書だった。形容詞を増やしても直らない。「絶対に教科書調にしないでください」と強調しても直らない。
直ったのは、過去に自分で書いた記事を1本丸ごとプロンプトに貼って「この文体で」とやったときだ。文体規約を10行書くより、お手本1本のほうが圧倒的に通じる。いわゆるFew-shotだが、体感としては「テクニック」というより、口で説明できないものは例で見せるしかないという当たり前の話に近い。
逆に言うと、例に含まれる癖は全部コピーされる。お手本記事に「〜という話」という締め方が入っていたら、生成記事も全部それで締めてくる。例は指示より強い。だから例の選定が実質プロンプトの本体になる。
出力形式の指定は「品質向上」ではなく「事故防止」で効く
このブログの記事frontmatterはzodスキーマで検証していて、descriptionが160字を超えるとビルドが落ちる。自動生成を始めた頃、これで朝のデプロイが何度か死んだ。
対策は2段構えにした。まずプロンプト側で、期待するfrontmatterを説明文ではなくYAMLの実物として貼る。
---
title: "（体験が伝わる具体的なタイトル）"
description: "（160字以内厳守。120字までに要点）"
category: "ai" # 決められた6値のみ
publishedAt: 2026-04-09
---「YAMLで出力してください。descriptionは160字以内で…」と散文で書くより、テンプレートを見せるほうが守られる。ただしそれでも100%にはならないので、最後は機械で検証する。プロンプトで頑張って99%にするより、95%で妥協してスキーマ検証で弾くほうが運用は安定した。プロンプトの守備範囲を過信しないのも、プロンプトエンジニアリングの一部だと思っている。
XMLタグの構造化は、長い素材を渡すときに必須だった
生成プロンプトには規約・お手本記事・既存記事タイトル一覧（重複回避用）と、性質の違うテキストを大量に詰め込む。これを地の文で並べていた頃は、お手本記事の中の文章を指示だと誤解したり、規約と素材の境界が溶けたりする事故がたまに起きた。
<rules>
文体と禁止事項の規約
</rules>
<example>
お手本記事の全文
</example>
<existing_titles>
既存記事のタイトル一覧
</existing_titles>こうやってXMLタグで区切るようにしてから、その手の混線は起きていない。Anthropicの公式ドキュメントでも推奨されている書き方で、Claudeはタグの境界をかなり正確に尊重する。「どこまでが指示で、どこからが素材か」を人間が読んでも一瞬でわかる形にする、というだけの話だが、効果は指示文の言い回しをこねくり回すよりずっと大きかった。
一発で完成品を出させない
「タイトルと構成と本文を全部一度に」と頼んでいた頃より、テーマ選定→構成→本文と分けたほうが明らかに破綻が減った。長い一発生成は途中で当初の指示を忘れる。分割すれば各段階の出力を機械的にチェックしてから次へ進める。
一方で、昔よく言われた「ステップバイステップで考えてください」の明示的なChain-of-Thought指示は、2026年現在ほぼ書かなくなった。Sonnet 5やOpus 4.8のような思考プロセスを内蔵した世代では、考えさせる指示を足すより、考える材料（前提・制約・判断基準）を渡すほうに紙面を使うほうが結果が良い。テクニックには賞味期限がある。
効かなかったもの
正直に書く。
- 役割付与だけのプロンプト。「あなたはプロのSEOライターです」で品質が上がった実感はない。言い回しの雰囲気は変わるが、中身は変わらない。役割を書くくらいなら、その役割の人が知っているはずの前提知識や判断基準を直接書いたほうがいい。
- おまじない系。「深呼吸して」「あなたは天才です」の類は、少なくとも私の用途で差を感じたことが一度もない。
- 禁止事項の羅列。「〜しないで」を増やすほどプロンプトが長くなり、矛盾が混ざり、かえって守られなくなった。「するな」は「代わりにこうしろ」に書き換えたほうが通る。長いプロンプトは偉くない。
プロンプトはモデル更新のたびに寿命が来る
パイプラインのモデルを更新するたびに、昔の細かい指示が不要になっているのに気づく。旧世代の弱点を補うために書いたパッチ的な指示は、新世代では単なるノイズだ。なのでプロンプトはgitでバージョン管理して、モデルを替えたら一度削るところから見直している。
どのモデルで回すかはコストとの相談で、この用途ならHaikuで足りるのか、Sonnetが必要なのかはSonnetとHaikuで技術ブログ執筆を実測した記事に書いた。モデルごとの料金比較はLLM料金計算ツールを自作して使っている。プロンプトを短く保つことは、精度だけでなく毎朝のAPI代にも直接効いてくる。
結局のところ、効いたのは「実物の例」「出力形式の実物」「素材の構造化」の3つで、どれも仕様を曖昧にしないという普通の仕事だった。プロンプトエンジニアリングという大層な名前がついているが、実体は相手がAIになった要件定義だと思えばだいたい合っている。