Claude APIで記事を作れば、すぐ良い下書きが出ると思っていました。
甘かったです。最初の出力は、丁寧で、正しくて、そして驚くほど薄味でした。3分で読めるのに、読後に何も残らない。夜中のコーヒーより薄い文章が出てきて、私は少し黙りました。
原因はモデルではなく、プロンプトでした。私が「良い記事」の条件を渡していなかったのです。
失敗したプロンプト
最初はこんな依頼でした。
Claude Codeについて初心者向けの記事を書いてください。
これで出てくる文章は、だいたい安全です。安全ですが、刺さりません。
誰が書いたのか分からない。どこでつまずいたのか分からない。数字がない。痛みがない。つまり、読む理由が弱いです。
変えたプロンプト
そこで、条件を分解しました。
次の条件で技術ブログ記事を書いてください。
読者:
- Claude Codeを触るか迷っている個人開発者
- PythonとGitは少し分かる
記事の条件:
- 冒頭3行に数字か失敗談を入れる
- 具体的な失敗を3つ入れる
- コードブロックを1つ以上入れる
- 3000字前後
- 敬体
- 最後は1行の断言で締める
禁止:
- ぼんやりした体験談タイトル
- 「便利です」で終わる結論
- 実装していない機能を事実のように書く
この時点で、出力はかなり変わりました。AIは空気を読むのではなく、条件を読むのだと実感しました。
Pythonから呼び出す最小例
API呼び出しは、まず最小構成で確認します。
import os
from anthropic import Anthropic
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
def draft_article(topic: str) -> str:
prompt = f"""
テーマ: {topic}
条件:
- 冒頭3行で数字か失敗談を出す
- 具体例を3つ入れる
- コードブロックを1つ入れる
- 敬体で書く
- 最後は一文で断言する
"""
message = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=3000,
messages=[{"role": "user", "content": prompt}],
)
# ハマりポイント: contentは配列なので、最初のtextを取り出す
return message.content[0].text
print(draft_article("Claude Code導入で失敗した話"))
モデル名は利用時点の環境に合わせて確認してください。大事なのは、まず1関数で動かし、出力の形を見ることです。
8つの失敗から残ったルール
1つ目は、読者を指定しなかったことです。初心者向けと言っても、完全初心者なのか、Python経験者なのかで全然違います。
2つ目は、禁止事項を書かなかったことです。AIは無難な表現を選びがちです。「便利です」「勉強になりました」を禁止するだけで、結論が少し締まります。
3つ目は、数字を要求しなかったことです。30分、3回、47行、12個。数字が入ると、文章が急に現実に寄ります。
4つ目は、失敗談を薄く書かせたことです。失敗は読者の接点です。恥ずかしいところほど、読まれます。
5つ目は、コードの実用性を指定しなかったことです。雰囲気コードは読者を助けません。
6つ目は、出力後のチェックをAI任せにしたことです。記事は生成して終わりではなく、人間が「本当に読みたいか」を見る必要があります。
7つ目は、1回で完成させようとしたことです。最初は構成、次に本文、最後にタイトル。この3段階のほうが安定しました。
8つ目は、個性を入れ忘れたことです。地方在住、夜中、コーヒー、弱気、少し笑える失敗。こういう小さな癖がないと、文章はすぐ匿名になります。
私のチェックリスト
出力後は、毎回この5つを見ます。
1. 冒頭3行で読む理由があるか
2. 数字が3つ以上あるか
3. 失敗談が具体的か
4. コードは実際に動くか
5. 結論が「便利です」で逃げていないか
これを通すだけで、記事の密度が変わります。特に1番と5番は厳しく見ます。入口と出口が弱い文章は、途中が良くても残りません。
生成後に必ず1回削る
AIの文章は、足すより削るほうが効くことがあります。
私は最初、出力された記事をそのまま整えようとしていました。すると、丁寧な前置き、一般論、似たような結論が残ります。文字数はあるのに、読み応えが薄い状態です。
そこで、生成後に必ず3種類の文を削るようにしました。
1つ目は、誰でも言える文です。2つ目は、数字のない感想です。3つ目は、次の段落と同じことを言っている文です。
削る基準:
- その文は自分の経験でしか書けないか
- 数字、場面、失敗のどれかがあるか
- 次の1文を読みたくなるか
この削りを入れると、同じ3000字でも密度が変わります。AIに書かせるほど、人間の編集が必要になるのは少し皮肉ですが、そこが一番おもしろいところでもあります。
温度を指定するより、採点表を渡す
プロンプトで「熱量高く」「読みやすく」と書きたくなります。私も最初はそうしていました。
でも、熱量は人によって意味が違います。AIにとっての熱量は、やたら大きな形容詞になることがあります。そこで、感覚語ではなく採点表に変えました。
採点:
- タイトルはクリックしたくなるか 10点
- 冒頭3行で痛みか数字が出るか 10点
- 失敗談が具体的か 10点
- コードが実用か 10点
- 結論が一文で刺さるか 10点
合計45点未満なら書き直す。
これを入れると、出力の自己点検が少し具体的になります。もちろん採点を鵜呑みにしてはいけませんが、少なくとも「良い感じ」という霧は薄くなります。
文章生成で怖いのは、悪文ではなく、欠点が見えにくい平均点の文章です。
もう1つ効いたのは、先に失敗談だけを箇条書きで渡す方法です。完成文をいきなり求めず、材料を8個ほど並べます。
材料:
- 初回出力が薄かった
- 数字を入れ忘れた
- コードが雰囲気だけだった
- 結論が弱かった
材料が具体的だと、AIの文章も具体に寄ります。白紙から名文を出させるより、泥のついた材料を渡したほうが読める記事になります。
まとめ
Claude APIは、文章を作る道具ではなく、条件を満たす下書きを高速に出す道具です。
良い出力が欲しいなら、良い雰囲気ではなく、良い制約を渡す必要があります。私が8回失敗して分かったのは、プロンプト設計とはAIへのお願いではなく、品質基準の設計だということです。
AIに個性を出させる前に、人間が読む理由を設計しなければいけません。
コメント