AIでブログ記事を書く手順|無料AIで5,000字を書いて分かった分業と事実確認【2026年版】

結論:AIは「下書き係」。設計と事実確認は人

3行の答え

AIは記事の下書きを速くする道具です。

調査・設計・事実確認・公開作業は人が担当します。

このサイトでは無料のAIモデルで本文約4,500字(全体約6,000字)の記事を作り、別モデルで校閲して公開しました。

分業の全体像

この分業を回すと、人が調査・確認に集中でき、AIが得意な「指示どおりに大量の文字を書く」作業を任せられます。

上位記事の多くは「AIは補助」「事実確認が大事」と一般論にとどまります。この記事では、実際に無料AIで5,000字級の記事を書かせ、別モデルで校閲し、公開前チェックリストで確認した一連の記録を示します。設計書を渡せば構成どおりに書けること、文字数は人が測って指示すれば解決すること、校閲を書いた本人以外のモデルにすると根拠のない解釈を見つけられること。これらを実測値とともに整理しました。

このサイトで実際にやったこと

無料のAIモデルを Claude Code から使った

このサイトを作る過程で、NVIDIA NIM の無料枠で提供されている Nemotron 3 Ultra 550B を Claude Code から呼び出し、トップページと記事を作りました。

実施日は 2026年11月14日 です。

実際の支払いは 0 円でした(NVIDIA NIM の無料枠を利用)。

同じ量を Claude の定価で処理した場合の推定は約 2.97 ドル(約 450 円、1 ドル = 150 円の仮定・仮の例)です。これは推定値であり、調査や事実確認などは含まないものです。

無料枠の条件は変わるため、最新の公式情報を確認してください。NVIDIA NIM は約40回/分の呼び出し上限があり(NVIDIA社員のフォーラム回答)、総量や期限の公式記載はありません。今回は260回ほど呼んで制限エラー(429)は0回でした。顧客の個人情報や社外秘データは無料枠に送らないようにしています。

役割分担:設計は Claude、本文は無料AI

ライバル調査、法令の公式確認、検索意図の整理、見出し構成の決定、各見出しへの文字数配分、入れる語と書かないことの指定は Claude が行いました。

設計書を受け取った無料AI(Nemotron 3 Ultra)が本文の下書きと手直しを担当しました。

公開前の最終確認と、法律について言い切りすぎた表現の修正は Claude が行いました。

この役割分担のポイントは、調査・判断・確認は人が持つことです。無料AIは「設計書にもとづいて指示どおりに書く」作業に集中させます。Claude Code の Web検索・Web取得は無料AI側では使えないため、ライバル調査は別の手段で行う必要がありました。

設計書を渡すと、構成どおりに書ける

設計書に入れるもの

検索意図、見出し(H2・H3)、各見出しの目安文字数、入れる語(共起語)、書かないこと(盛らないルール・法律の言い回し・出せない数字)を設計書としてまとめました。

設計書の作り方は、上位記事の確認から見出しを起こし、各節の役割と文字数を割り振るという一般的な手順です。検索意図を「知りたい・やりたい・不安」に分解し、それに応える見出し構成を作ります。各見出しには目安文字数と「入れる語」「書かないこと」をセットで指定します。「書かないこと」には、成果の数字を盛らない、法律を言い切らない、出典のない数字を出さないといったルールを明記します。

2,000字の指示と 5,000字の設計書つきを比較

設計書なしで「2,000字で書いて」と指示した場合、本文は約 1,340 字しかありませんでした(指示の約 3 分の 2)。

設計書をつけて「5,000字で書いて」と指示した場合、本文 4,547 字(全体 5,981 字)、H2 が 8 個・H3 が 24 個・表 4 つで、構成どおりに書けました。このとき 33 往復、入力約 170 万トークン、20 分の上限で打ち切られるまで続きました。

設計書があると、見出し構成・各節の文字数・入れる語・文体ルールがほぼ守られます。ただし弱点もあります。文字数が不足しやすいこと、根拠のない数字や事実を足しやすいこと、法律の説明が言い切りになりやすいことです。手直しの依頼(リンク差し替え・法令の表現など12項目)は 95 秒で全て反映できました。

これらの弱点は後述の「つまずき」と「校閲」「事実確認」で対処します。設計書の作成自体は手間がかかりますが、一度作れば何度も使える資産になります。

実際につまずいたこと3つ

文字数を自分で数えられない

無料AIに文字数を自分で数えさせると、数えるスクリプトを書いては実行できずにループしました(コマンド実行を禁止していたため)。

20 分の上限で打ち切られるまで 33 往復し、入力は約 170 万トークンに達しました。AI は自分で書いた文字数を正確に把握できず、「足りない」と判断して書き足し、「書きすぎた」と判断して削り、を延々と繰り返します。

対策として、文字数は人間側のスクリプトで測り、見出しごとに「○字」と区切って指示しました。設計書の各見出しに目安文字数を書き、それをプロンプトに含めて渡します。

足りない節だけを具体的に指示すると、ループせずに直りました。「第3節が 800 字足りないから書き足して」のように、対象と不足分を数字で示すのが効果的です。全体を書き直させると再びループするため、範囲を限定することが重要です。

根拠のない事実を足す

指示にない「7日間のステップメール」「承認率80%は一般的な水準」など、根拠のない記述を勝手に足しました。これらは設計書に一切書いていない内容です。

「設計書にない事実を足さない」と書いても完全には防げません。AI は学習データから「らしい記述」を予測して補完してしまうため、禁止指示だけでは漏れます。特に「一般的に」「通常は」「標準的な」といった言葉のあとに、出典のない数字やサービス名が続くパターンが多いです。

公開前の事実確認は必須です。校閲を別モデルにすると、書いた本人では気づきにくいこれらの混入を見つけられます。

指示の渡し方と止める条件

標準入力で複数行の指示を渡すと、途中で切れることがありました(短く記述)。長い指示はファイルに書き出して渡すか、分割して渡す必要があります。

最大往復回数や時間の上限を設定しても、止まる条件が曖昧だとループが続きます。「完成したら止めて」だけでは AI が完成と判断する基準がブレるため、「見出し H2-1 から H2-3 まで書いたら止めて」「文字数が設計書の合計に達したら止めて」のように、判断できる条件を数値化して指定します。

「この節だけ書き直して」と範囲を限定して指示すると、不要な往復が減りました。全体を書き直す指示は、すでに正しい部分まで巻き込んで再生成させ、新たなミスやループを招きます。

校閲を別モデルにすると何が見つかったか

分業で書いた記事での検証

オプトインアフィリエイトは怪しい?違法?の記事(本文約 5,200 字)で、下書き→校閲→修正の分業を試しました。

下書きは Nemotron 3 Ultra が 4 分 23 秒で本文 4,539 字を書きましたが、短い節が 2 つありました。これを同モデルで 2 分 55 秒かけて書き足し、5,222 字にしました。校閲役を変えて 3 回試した結果、Mistral Large 4 と 推敲の MiniMax M3.1 Flash は 15 分の上限で時間切れになりました。Mistral Large 4 は 1 回の応答に 13 分かかり、MiniMax M3.1 Flash は止まるまでに 18 か所を整えました。やり直しの校閲を Nemotron 3 Ultra が 2 分 47 秒で行い、的確な指摘 3 件を出しました。修正は同モデルが 53 秒で 3 件とも反映し、最終確認と公開は Claude が法律について言い切りすぎた 2 文を修正して完了しました。

的確だった指摘3件の中身

1つ目は、根拠のない解釈が含まれていたことです。下書きモデルが勝手に補完した「一般的な解釈」を、別モデルが客観的に見て指摘できました。

2つ目は、本文にない「仮の例」の免責について指摘されたことです。記事内で推定値を示していた箇所に「仮の例」という明記が抜けており、別モデルが気づきました。

3つ目は、免責の位置について指摘されたことです。免責事項が記事の末尾にあり、読者が見逃すおそれがあるため、該当箇所の近くにも入れるべきだと指摘されました。

これらは書いた本人(下書きモデル)では気づきにくい指摘でした。自分が書いた文章を自分で校閲すると、「書いた意図」で読み替えてしまい、客観的な欠落を見落とします。別モデルに渡すと、前提知識なしで「文章だけ」を見るため、根拠のなさや免責の不足が浮き彫りになります。

時間切れになった例

1 回の呼び出しは速くても、何往復もする作業では極端に遅くなることがあります。Mistral Large 4 と 推敲の MiniMax M3.1 Flash は 15 分の上限で時間切れになりました。校閲のように「読んで→指摘して→直して→また読んで」を繰り返す作業では、応答速度だけでなく、コンテキストが長くなるにつれて処理時間が伸びる傾向があります。1 回きりの短いタスクなら速いモデルでも、往復する作業では安定しないことを確認しました。

各段の本文の写しを残す

下書き後、校閲後、修正後と、各段の本文の写しを残すと、どの AI が何を直したか後から比べられます。この記録があるからこそ、校閲モデルの指摘が的確だったか、修正が正しく反映されたかを検証できます。また、どのモデルがどの段階でどう振る舞ったかの知見が蓄積され、次回の分業設計に活かせます。

公開前の事実確認チェックリスト

公開前には次の項目を 1 つずつ確認します。各項目の確認方法もあわせて記します。

このチェックリストは、Google 検索セントラル「生成AIコンテンツ」ページで「人の手でファクトチェックとレビューをすることが重要」とされていることに対応しています。生成モデルは事実を検索して取り出すのではなく、学習データから単語の並びを予測するため誤りを含むことがあります。公開前に人の手で 1 つずつ突き合わせることで、ハルシネーションや古い情報の混入を防ぎます。

title タグ、meta description、構造化データ、画像の代替テキストも確認対象です。これらは検索結果やソーシャル共有時に読者が最初に見る情報であり、本文と矛盾すると信頼を損ないます。構造化データは Article や BreadcrumbList など、ページの種類に合わせて正しく出力されているか検証します。画像の代替テキストは、画像が表示されない環境でも内容が伝わるよう、具体的に記述されているか確認します。

確認作業は「元資料と本文を横に並べて 1 行ずつ突き合わせる」のが基本です。数字は 1 つずつ公式ページを開いて確認し、法律は該当条文の URL を控えておきます。サービス仕様は公式ドキュメントの該当セクションをスクリーンショットで残すと後から見返せます。

Googleは何と言っているか

生成AIコンテンツも品質基準を満たす必要がある

Google 検索セントラル「生成AIコンテンツ」ページ(確認日 2026年11月14日)では、生成AIコンテンツも Search Essentials とスパムポリシーの基準を満たす必要があるとされています。

価値を加えずに大量のページを生成すると、「スケールされたコンテンツの不正利用」に違反するおそれがあります。

人の手のファクトチェックとレビューが重要

生成モデルは事実を検索して取り出すのではなく、学習データから単語の並びを予測するため誤りを含むことがあります。

公開前に人の手でファクトチェックとレビューをすることが重要とされています。

レビューは本文だけでなく、title タグ、meta description、構造化データ、画像の代替テキストにも必要です。

自動化の背景を示すと読者の理解を助ける

自動生成したコンテンツでは、自動化をどう使ったかの背景を示すことで、読者の理解を助けられます。

この記事自身が「このサイトで実際にやった記録」を示しているのは、そのためです。

書かないこと

「AIで作った記事は人が書いた記事と SEO 評価に差がない」とは書きません(一部の解説記事の言い方で、公式ページの文言ではありません)。

順位への影響の断定、検出ツールの精度についても書きません。

よくある質問と次の一歩

FAQ 3問

無料AIで十分ですか?

下書きなら使えました。ただし規約上は開発・テスト用で、回数制限(約40回/分)や期限は公式に明記されていません。最新の公式情報を確認し、公開前の確認は必須です。

AIで書いたとすぐ分かりますか?

設計書を渡し、校閲・事実確認を経た記事であれば、ひと目で AI と分かることは少ないです。ただし公開前の人の手による確認が前提です。

稼げますか?

この記事に収益の数字はありません。記事を読まれる形にするための土台は リストマーケティング、書く前の調査・構成の考え方は オプトインアフィリエイトの作り方 を例に解説しています。

まずは無料講座で基礎を学ぶ

AI 活用を含む情報発信ビジネスの全体像を学びたい方は、インフォマーケティング研究所の無料講座をご用意しています。

メールアドレスの登録だけで、基礎から応用まで体系的に学べるコンテンツをお届けします。