目次
- AI記事はなぜ薄くなるのか——3つの構造的な原因
- 原因1 — AIは「最も無難な答え」を返す仕組みになっている
- 原因2 — 「体験を入れましょう」だけでは具体的に何をすればいいかわからない
- 原因3 — 品質管理が「人間の気合い」に依存している
- 仕組み1 — AIへの「禁止事項」をファイルで管理する
- やること
- なぜ「やってほしいこと」より「やらないでほしいこと」のほうが効くのか
- 最小限の禁止事項リスト（すぐ真似できる3つ）
- 仕組み2 — 体験素材シートで「何を聞くか」を先に設計する
- 体験素材シートとは何か
- インタビュー設計の実例
- 体験素材シートを使い始めてからの変化
- 仕組み3 — 一般論の比率を構成段階でコントロールする
- 「一般論比率20〜30%以内」ルールの考え方
- 構成案への区分明記の実例
- 一般論が膨らみやすい見出しの傾向
- 一般論と体験の書き分けのコツ
- 仕組み4 — 判断基準の優先順位を決めておく
- 迷ったときのルール
- 矛盾が起きたときのルール
- なぜこの順番になったのか
- 仕組み5 — 品質審査で「私の記事」テストを回す
- 「私の記事」テストとは
- 品質審査で差し戻された実例
- 自己審査を禁止している理由
- 1人でブログを運営している場合の簡易版テスト
- 仕組み6 — AIに任せていい仕事と自分でやる仕事の線引き
- 線引きの基準
- この線引きに至った経緯
- AIへの指示の変化
- C11（ChatGPT構成）との連携
- よくある質問
- Q: AIで体験を入れると時間がかかりすぎませんか？
- Q: GoogleはAI記事を低評価するのですか？
- まとめ — 薄くならないのは仕組みの問題
- note で読む：「一般論記事→体験入り記事」の書き直し全過程
AIで書いた記事を読み返したとき、「これ、どこかで読んだことある気がする」と感じたことはないでしょうか。
情報は正確。文章もそれなりに読める。でも何か薄い。記事を書いた自分が読んでも、自分の話をしている感じがまったくしない。
私がhalolab.jpを立ち上げた最初の頃、それが続きました。AIに記事を書かせれば効率的にブログを更新できると思っていたのに、仕上がった記事を読むと「これは私が書く必要があったのか」という疑問しか残らなかった。
「体験を入れましょう」という言葉は知っていました。でも、具体的に何をどう入れればいいのかわからなかった。そのまま続けていたら、薄い記事が積み上がるだけで終わっていたと思います。
今は考え方が変わりました。薄くなるのは才能やセンスの問題ではなく、仕組みの問題だとわかってきたからです。
CLAUDE.mdに禁止事項を書く、体験素材シートで「何を聞くか」を先に設計する、一般論の比率を構成段階でコントロールする——この6つの仕組みを回し始めてから、「自分にしか書けない記事かどうか」を確認しながら進めることができるようになりました。
仕組みが先にある、というのがポイントです。「いい記事を書こう」という意気込みだけでは、AIの出力は変わりません。
AI記事はなぜ薄くなるのか——3つの構造的な原因
原因1 — AIは「最も無難な答え」を返す仕組みになっている
大規模言語モデルは、膨大な学習データの平均的な回答を出力します。言い換えると、AIは「多くの人が書いてきたこと」を高確率で返すように設計されています。これは正確さの観点では合理的な設計です。ただし、個性や一次情報という観点では、最初から不利な構造です。
halolab.jpの立ち上げ初期、私はClaude Codeに「看護師がAIでブログを運営する方法」という記事を書かせました。返ってきた記事は、文法的に正しく、情報として間違ってもいない。でも読んでいて、「これ、自分の話じゃないな」という感覚が抜けなかった。
誰かがまとめたノウハウを、AIがさらに平均化して返してきた、というのが正直な印象でした。AIが悪いわけではない。私がAIに「私らしい記事を書いて」と言わなかったのが原因だったと、後になってわかりました。
原因2 — 「体験を入れましょう」だけでは具体的に何をすればいいかわからない
「AI記事 薄い」で上位に出てくる記事を10本読みました。競合分析の結果でも、9割が「体験や一次情報を入れましょう」で止まっていました。
でも、「どの見出しに」「どんな体験を」「どういう形式で」入れればいいのかを説明している記事はほぼゼロでした。
最初の頃の私も同じ状態でした。「体験を入れろ」と言われても、何を体験として取り出せばいいのかわからない。AIに「私の体験を入れてください」と伝えても、AIは私の体験を知らないので、それらしい体験を作り出してしまう。
「体験を入れましょう」という言葉は正しいのですが、それだけでは動けません。体験を入れるための「設計」が必要で、それが体験素材シートという仕組みにつながっていきました。
原因3 — 品質管理が「人間の気合い」に依存している
記事を書くたびに「今回はちゃんと個性を出そう」と思っても、仕組みがなければブレます。気合いで品質を保つのは、毎回同じクオリティで料理を出すためにレシピを持たずに感覚だけで作るようなものです。
最初は、書くたびに記事のクオリティにばらつきが出ていました。うまく体験を入れられた記事もあれば、一般論の羅列で終わった記事もあった。振り返ると、うまくいった記事には、事前に「このテーマで自分が困ったこと」を言語化していた共通点がありました。
この気づきが、品質管理を「仕組み」として設計する起点になりました。
仕組み1 — AIへの「禁止事項」をファイルで管理する
やること
Claude Codeを使っているなら、プロジェクトのルートに CLAUDE.md というファイルを置きます。このファイルに「AIにやらないでほしいこと」を書いておくと、すべての記事作成作業に自動で適用されます。
# プロジェクトのルートに置くだけ
CLAUDE.md
# CLAUDE.md の禁止事項セクション（抜粋）
## 禁止事項
- 事実にないことを足さない
- 感情を美化・演出しない
- 成功談や感動話に寄せない
- 教訓でまとめない
- 説教口調にしない
- 一般論だけの記事を作らない
なぜ「やってほしいこと」より「やらないでほしいこと」のほうが効くのか
「個性的な文章を書いてください」という指示は、AIにとって曖昧です。何が「個性的」かの基準が共有されていないからです。
一方、「感情を美化しない」「成功談に寄せない」という禁止事項は、具体的で判定可能です。「この文章は感情を美化しているか？」という問いに、AIは答えることができます。
禁止事項を書く前は、Claude Codeが仕上げた文章に「その体験は思ったより辛かった、みたいな感じで書いてほしい」と後から修正指示を出すことが多かった。禁止事項を書いてからは、最初の出力の段階で感情が盛られた表現が減りました。修正の手間が明らかに減ったのを覚えています。
最小限の禁止事項リスト（すぐ真似できる3つ）
初めてCLAUDE.mdに禁止事項を書くなら、この3つから始めるといいと思います。
- 「事実にないことを足さない」 — AIが「おそらく書き手はこう感じたのだろう」と推測で感情を足すのを防ぐ
- 「一般論だけの記事を作らない」 — 記事の核を体験に置くための最重要ルール
- 「教訓でまとめない」 — 記事末尾が「この経験から学んだのは○○です」という綺麗なまとめで終わるのを防ぐ
CLAUDE.mdの書き方については、CLAUDE.mdの書き方ガイドで詳しく説明しています。
仕組み2 — 体験素材シートで「何を聞くか」を先に設計する
体験素材シートとは何か
体験素材シートは、記事の見出しごとに「どんな体験が欲しいか」を先に決めておくシートです。インタビュー形式で自分に質問し、答えを素材として収集します。
記事を書き始める前に、「このテーマについて自分が持っている体験は何か」を構造化することで、AIへの入力材料が整います。
インタビュー設計の実例
たとえば「AI記事が薄くなる原因」という見出しに対して、以下のような質問を設計します。
| 見出し | 欲しい体験の種類 | 質問例 |
|---|---|---|
| AI記事が薄くなる原因 | 失敗体験 | 「AIに任せて薄い記事になったのはいつ、どの記事でしたか」 |
| 仕組みを作るきっかけ | 転換点 | 「品質にばらつきが出た、と初めて気づいたのはどんな場面でしたか」 |
| 判断基準の優先順位 | 葛藤 | 「SEOと個別性が矛盾したとき、どちらを選んで、なぜそう決めましたか」 |
このシートがあることで、Claude Codeへの指示が具体的になります。
# Claude Codeへの指示例
以下の体験素材シートをもとに、「AI記事はなぜ薄くなるのか」の見出しを書いてください。
体験は素材シートの内容のみ使ってください。素材にない事実を足さないでください。
【体験素材】
- 立ち上げ初期に書いた記事を読み返したら「どこかで読んだことがある」内容になっていた
- AIに任せたが、返ってきた記事には自分の言葉がひとつも入っていなかった
- 「自分が書く必要があったのか」という疑問が残った
体験素材シートを使い始めてからの変化
使い始める前は、記事を書きながら「そういえばこのテーマで困ったことあったな」と後から体験を掘り起こしていました。後から掘り起こす体験は、どうしても曖昧になります。「たしかつらかった気がする」という感じで、感情の解像度が低い。
シートで先に設計してからインタビューに臨むと、体験の解像度が上がりました。「あの記事の、あのセクションを書いていたとき」という具体性で体験が取り出せるようになったからです。
1記事あたりのインタビュー時間は、15〜20分程度です。全見出しに体験を入れる必要はなく、記事の3〜4箇所に体験の核を置く設計にしています。
仕組み3 — 一般論の比率を構成段階でコントロールする
「一般論比率20〜30%以内」ルールの考え方
CLAUDE.mdには「一般論は記事全体の20〜30%以内」というルールを書いています。
このルールは感覚的に判断するものではなく、構成案の段階で各見出しに「一般情報 / 体験」の比率を明記することで管理します。
構成案への区分明記の実例
## AI記事はなぜ薄くなるのか
**区分：体験50% / 一般情報50%**
- H3: 原因1（AIの仕組みの話 → 一般情報）
- H3: 原因2（「体験を入れろ」で止まっている現状 → 一般情報）
- H3: 原因3（品質管理が人間の気合いに依存 → 体験60%）
## 仕組み1 — 禁止事項をファイルで管理する
**区分：体験70% / 一般情報30%**
- 禁止事項の実例（CLAUDE.mdから抜粋）→ 一般情報
- 禁止事項を書く前後でAIの出力がどう変わったか → 体験
こうしておくと、記事を書き終わってから「一般論が多すぎた」と気づいて手戻りする問題を、構成段階で予防できます。
一般論が膨らみやすい見出しの傾向
経験上、以下のタイプの見出しは一般論が膨らみやすいです。
- 「〜とは何か」「〜の定義」系の見出し
- 「〜のメリット・デメリット」比較系の見出し
- 「〜の原因」「〜の理由」説明系の見出し
これらの見出しは、体験なしで書けてしまうため、一般論で埋まりやすい。設計段階で「この見出しには体験を何割入れる」と決めておくことで、執筆中にブレにくくなります。
一般論と体験の書き分けのコツ
私が意識しているのは「体験→一般論の順番」です。
先に体験を書いて、その体験をもとに「こういうことだと理解した」として一般論を置く。この順番にすることで、一般論が「体験の裏付け」として機能します。逆に、一般論を先に書いてから「たとえば私の場合は」と体験を付け足すと、体験が「補足」になってしまい、薄さが出やすくなります。
仕組み4 — 判断基準の優先順位を決めておく
迷ったときのルール
記事を書いていると、複数の方向性が衝突する場面が出てきます。「SEOのために一般的な情報を増やすべきか、でもそうすると個別性が薄れる」「完成度の高い文章に整えるべきか、でもそうすると自分の言葉じゃなくなる」という感じの衝突です。
CLAUDE.mdには判断基準の優先順位を書いています。
## 判断基準の優先順位（上が最優先）
1. 書き手の感覚との一致
2. 事実の正確さ
3. 個別性と一次情報
4. 読者にとっての有益性
5. SEOでの発見されやすさ
6. 制作の効率性
矛盾が起きたときのルール
| 矛盾 | 選ぶ方向 |
|---|---|
| SEO vs 個別性 | 個別性を残し、SEO構成をそれに合わせる |
| 完成度 vs 自分らしさ | 未完成でも自分らしい方を選ぶ |
| 効率 vs 書き手の関与 | 書き手を省略しない |
| 収益 vs 読者の信頼 | 信頼を優先する |
なぜこの順番になったのか
最初は「SEOで見つかる記事を書きたい」という気持ちが先行していたこともありました。検索で上位に出るためにキーワードを詰め込んだ記事を書いて、読み返したら「これは自分が書く必要があった記事じゃない」と感じた経験があります。
「完成度が高いが自分らしくない記事よりも、多少未完成でも自分の感覚とズレていない記事を重視する」という方針は、そのときの反省から来ています。
この優先順位を書いておくことで、迷ったときにClaude Codeへの指示も整理しやすくなります。「読者の有益性よりも書き手の感覚を優先する」という指示は、ファイルに書いてある基準から自然に出てきます。
上位の競合記事を10本読みましたが、「SEO vs 個別性のどちらを優先するか」という判断軸を明文化している記事は1本もありませんでした。テクニックを並べることはできても、「矛盾したときにどう決めるか」という判断基準は、自分で設計するしかないと感じています。
仕組み5 — 品質審査で「私の記事」テストを回す
「私の記事」テストとは
これは、「書き手の名前を隠して読んでも、誰が書いた記事かわかるか」というテストです。
具体的には以下の3項目を確認します。
- 書き手の名前を隠して読んで、誰の記事かわかるか — 固有の体験・語り方・価値観が入っているか
- 体験が構成に組み込まれているか — 体験が「補足」ではなく「主役」として置かれているか
- 一般論だけの記事になっていないか — 全見出しを通じて書き手の実例が入っているか
品質審査で差し戻された実例
halolab.jpの記事で、品質審査から差し戻しを受けた経験があります。記事の仕組みが整い始めた初期の話です。
「AI記事 薄い」というテーマで、最初に書いた下書きは約4,000字の記事でした。原因の説明、解決策の提示、まとめ、という構成でした。
品質審査の指摘は「体験が補足になっている。解決策の見出しに体験が入っているが、一般論の後に添えられた例になっている。体験を先に置いて、一般論を体験の裏付けとして配置してほしい」というものでした。
この指摘を受けて書き直したとき、体験を先に書いてから一般論を置く順番に変えると、同じ内容でも文章の重心が変わりました。「体験から考えたこと」として一般論を読めるようになったからです。
自己審査を禁止している理由
自分が書いた記事を自分で審査すると、「このくらいは伝わるだろう」という思い込みが入ります。書いた文章は自分の意図が乗っているので、読み返しても「ちゃんと伝わっている」と感じやすい。
このプロジェクトでは、記事を書いた後に品質審査を別の役割（独立したエージェント）が行う設計にしています。自己審査を禁止することで、書いた本人が気づかないバイアスを外から指摘できる状態を保ちます。
1人でブログを運営している場合の簡易版テスト
Claude Codeを使っていない場合や、独立した審査を回す仕組みがない場合は、以下の簡易版テストが使えます。
手順（3ステップ）
- 書き終わった記事のタイトルと書き手の名前を隠して読む
- 「この記事は、私以外のブログに掲載されていても違和感がないか」と問う
- 違和感がなければ（どこにでもある内容であれば）、体験の入れ方を見直す
「違和感がない」＝「薄い」というサインです。
仕組み6 — AIに任せていい仕事と自分でやる仕事の線引き
線引きの基準
この仕組みが、記事が薄くなる問題への最終的な答えだと思っています。
AIに任せる仕事と、自分でやる仕事を明確に分けることです。
AIに任せていい仕事
– 情報やメモの整理
– 記事の構成案作成
– SEO観点での補助（キーワード・見出し設計）
– 言い回しや文体の整形
– Markdown形式への整形
– 内部リンクの候補提示
自分でやる仕事
– 何をこの記事で一番言いたいか
– 実際にあったこと
– そのときどう感じたか
– どこに違和感や引っかかりがあったか
– 自分なりの視点・判断
この線引きに至った経緯
「AIは代筆者ではなく、整理・構成・整形・確認の補助役として使う」というのが、今の私の基本思想です。
これは最初からそう思っていたわけではありませんでした。「AIに全部書かせれば効率的じゃないか」と思っていた時期があります。でも、AIに全部書かせた記事は、読み返すと自分の記事じゃない感覚が残り続けた。
「なぜ自分が書く必要があるのか」という問いに答えられない記事は、誰にとっても意味が薄い、というのが今の考え方です。
AIへの指示の変化
線引きを決める前の指示：
「看護師がAIでブログ運営する方法について記事を書いてください」
線引きを決めた後の指示：
「以下の私の体験をもとに、H2見出し『AI記事はなぜ薄くなるのか』を書いてください。
体験素材シートにない事実は足さないでください。
一般論は体験の後に配置してください。」
指示の中心が「書いて」から「私の素材を使って整形して」に変わりました。
C11（ChatGPT構成）との連携
記事の構成はAIに任せていい仕事の代表です。ChatGPTやClaude Codeで構成案を作り、見出し設計・キーワード配置・内部リンク設計はAIに任せる。その上で、各見出しの中身を体験素材シートで埋める、という分業が今の基本的な流れです。
ChatGPTで構成案を作る手順についてはChatGPTでブログ記事構成を作る基本手順（準備中）で詳しく解説予定です。
ブログ運営の全体像については、AIでブログ運営を自動化する5ステップの全体像で整理しています。
よくある質問
Q: AIで体験を入れると時間がかかりすぎませんか？
一般論として言えば、体験を入れるプロセスは確かに時間がかかります。ただし、「薄い記事を量産して後からリライトする」方が総コストは高くなります。薄い記事のリライトは、0から書くより時間がかかることが多いです。
私の場合、体験素材シートを使い始めてから、1記事あたりの体験収集にかかる時間は15〜20分程度に収まっています。全見出しに体験を入れようとすると時間がかかりますが、記事の3〜4箇所に体験の核を置く設計にしてから、負担感はかなり小さくなりました。
「体験を入れる」は全部の見出しに均等に入れる必要はない、というのが実感です。
Q: GoogleはAI記事を低評価するのですか？
Googleは制作方法ではなくコンテンツの品質で評価すると公式に表明しています。AI使用自体はペナルティの対象ではなく、「自動化されたコンテンツでも、高品質で人を第一に考えたものであれば問題ない」という立場です。
halolab.jpでは、AI支援で書いた記事がインデックス登録され、検索流入を継続的に得ています。重要なのは「AIで書いたか」ではなく「読者にとって有益か」だというのが実感です。
一方で、E-E-A-T（経験・専門性・権威性・信頼性）の「Experience（経験）」は2022年12月に追加された観点で、実際の経験・体験に基づくコンテンツが評価される方向性が明確になっています。「体験を入れる仕組みを持つ」ことが、SEO的にも理にかなっています。
まとめ — 薄くならないのは仕組みの問題
6つの仕組みを振り返ります。
| 仕組み | 何を防ぐか |
|---|---|
| 1. 禁止事項のファイル管理 | AIが「それっぽい」文章を生成するのを構造的に止める |
| 2. 体験素材シートの設計 | 「体験を入れろ」という曖昧な指示を仕組みに変える |
| 3. 一般論比率のコントロール | 構成段階で一般論が膨らむのを予防する |
| 4. 判断基準の優先順位 | 迷ったときに個別性を捨てる選択をしなくて済む |
| 5. 品質審査テスト | 薄い記事が公開される前に止める |
| 6. AIと自分の役割の線引き | AIに全部任せて個性が消える問題を防ぐ |
最初からこの仕組みがあったわけではありません。薄い記事を出して、「これじゃない」と感じて、何が足りないかを考えて、少しずつ形にしてきました。
今でもすべてが完成しているとは思っていません。まとめが教訓っぽくなりすぎたり、体験の比率が足りなかったりする記事は、まだ出てきます。
ただ、仕組みがあることで「何がまずかったか」を振り返りやすくなりました。気合いで品質を保とうとしていたときは、何が足りなかったのかが曖昧なままで、同じ失敗を繰り返していた。
まず禁止事項を3つ書くところから始めてみてください。「事実にないことを足さない」「一般論だけの記事を作らない」「教訓でまとめない」——この3つをCLAUDE.md、またはChatGPTへの指示ファイルに書いておくだけで、AIの出力は少し変わると思います。
note で読む：「一般論記事→体験入り記事」の書き直し全過程
この記事では6つの仕組みの考え方を紹介しましたが、「実際に一般論だけだった記事を体験入り記事に書き直した全過程」はnoteで記録しています。
どのセクションで何を変えたか、品質審査でどんな指摘を受けたか、書き直し前後の記事の変化——その試行錯誤のログを、noteに残しています。仕組みを実際に動かしたいと思っている方は、noteも参照してみてください。
関連 note 記事
AI に記事を書かせようとしてうまくいかなかった話は note で書いています。本文がなぜ薄くなるのか、根本の話。
