実録:Claude Fable 5でブログ11記事を一晩一斉改善
- 更新日: 2026年7月3日
- 読了目安: 約20分
- 再現の目安: 3記事なら約3時間
Claude Fable 5を司令塔（オーケストレーター）にして、記事ごとに専任の分身AI（サブエージェント）11体を並列で走らせると、人間なら1ヶ月かかるブログ11記事の一斉改善が一晩（数時間）で終わります。
これは2026年7月2日に、このブログで実際に行われた改善の実録です。登場する数字はすべて実測値で、自分のブログで再現する手順とプロンプトまで全部載せています。
この記事にはエージェントやlintなどの専門用語が出てきますが、全部その場で一言ずつ説明します。コードを書いたことがなくても大丈夫。ブログを持っている人なら、誰でも真似できる話です。
この記事で分かること
「AIでブログを改善したい」と思って検索している人が知りたいのは、たぶん「AIはブログ改善に使えます」という一般論ではありません。
実際に何記事を、どれくらいの時間で、どこまで直せたのか。
数字はどう変わったのか。
AIが暴走したり、嘘を書いたりしなかったのか。
自分のブログでやるなら何から始めればいいのか。費用はいくらかかるのか。
この記事は、その全部に実物の数字で答えます。
この記事を読み終えると、「監査 → ルール整備 → 並列改善 → 機械チェック → 公開」という一斉改善の型が分かり、自分のブログでまず3記事から同じ体制を再現できます。
11記事のリライトが、一晩で終わった。これが「AIチームで働く」の実物です。
結果サマリー:ブログ11記事はどれだけ変わったのか
先に結果です。文字数は空白を除いた実測値で、改善前→改善後です。
| 記事 | 改善前 | 改善後 | 増加 |
|---|---|---|---|
| GitHub/Vercelサイト公開 | 5,184字 | 16,029字 | +10,845字 |
| Mac環境構築 | 5,812字 | 17,291字 | +11,479字 |
| Claude Codeインストール | 8,436字 | 13,562字 | +5,126字 |
| Codexインストール | 12,447字 | 16,241字 | +3,794字 |
| 1Passwordで.env管理 | 15,764字 | 19,679字 | +3,915字 |
| LINE CRM構築 | 12,647字 | 15,386字 | +2,739字 |
| 画像プロンプト30選 | 13,417字 | 20,090字 | +6,673字 |
| スマホ操作（Moshi） | 10,995字 | 13,685字 | +2,690字 |
| Codexデスクトップ | 約10,500字 | 12,944字 | +約2,400字 |
| 動画系2記事 | — | — | 微修正のみ |
文字数以外の結果はこうです。
- 全11記事が、記事の健康診断ツール（lint）の自動チェックでerror 0 / warn 0
- 検索エンジン向けの記事情報（構造化データ）のFAQが、全記事で本文と完全一致
- 全記事にAIプロンプト集・用語集・記事同士の相互リンクを整備
- 古くなった情報（削除済みコマンド、旧モデル名、旧料金）を公式情報ベースで更新
- Supabaseへ一括投入して再公開
- おまけに「一覧には表示されるのにクリックすると404」だった3記事の本文欠落を発見して復旧
所要時間は、監査からルール整備、デザイン改修、11記事の並列改善、公開検証まで含めて一晩。時間にして数時間です。
人間（運営のhashshnet）がやったのは、方針の判断と最終GOだけ。キーボードでリライト作業は1文字もしていません。
文字数を増やすこと自体が目的ではありません。監査で「検索意図に対して薄い」と判定された記事に、エラー対処・実務事例・FAQなど足りなかった中身を足した結果が、この数字です。
なぜ人間がやると1ヶ月かかるのか
「11記事のリライトくらい、頑張れば1週間でできるのでは？」と思うかもしれません。実際にやったことがある人なら分かりますが、無理です。
1記事の本気のリライトには、最低でもこれだけの工程があります。
- 記事を読み直して、何が弱いか判定する（1〜2時間）
- 競合や検索意図と照らして、足すべき内容を決める（1〜2時間）
- 本文を増補・リライトする（半日〜1日）
- 料金・コマンド・仕様など古くなった情報を公式ページで確認して直す（1〜2時間）
- HTMLや構造化データ、OGP（SNSでシェアされた時に出る画像や説明文の設定）、内部リンクを整える（1〜2時間）
- 見直して公開する（30分〜1時間）
1記事あたり2〜3日。11記事なら、他の仕事をしながらだと1ヶ月コースです。
しかも人間の作業は直列です。1記事目を直している間、残りの10記事は放置されます。10記事目に着手する頃には、1記事目で決めた方針を忘れかけていて、記事ごとに品質がブレます。
さらに厄介なのが「一貫性」です。11記事に同じルール（タイトルの文字数、FAQの形式、内部リンクの張り方、用語の説明レベル）を適用し続けるのは、人間の集中力では相当きついです。
Claude Fable 5の並列体制は、この構造をまるごとひっくり返します。
- 11記事を同時に直すので、直列の待ち時間が消える
- 全エージェントが同じルールファイルを読むので、一貫性が崩れない
- 機械チェックが最後の門番になるので、「うっかり」が公開に混ざらない
Claude Fable 5は、タスクが長く複雑になるほど他のモデルとの差が大きくなるモデルです。今回のような「11記事×数十項目のルール適用」という長丁場は、まさにその得意分野でした。
体制:Fable 5がオーケストレーター、記事ごとに専任エージェント
今回の体制はシンプルです。
ポイントは「1エージェント＝1記事フォルダの所有」というルールです。
各エージェントは自分の担当記事フォルダの中だけを編集できます。他の記事や共有ファイルには触れません。これで、11体が同時に走っても編集の衝突（コンフリクト）がゼロになります。
会社で例えるなら、編集長が1人いて、記事ごとに専属ライターを11人雇い、それぞれに「あなたはこの記事だけ。ルールブックはこれ。締切は今夜」と渡すイメージです。違うのは、11人のライターが全員、同じルールブックを一言一句忘れずに適用し続けることです。
なお、Claude Code（パソコンの中のファイルを直接扱えるAIツール）でFable 5を使う準備自体は数分で終わります。まだの人は、先に下のインストール記事を見て環境を作っておいてください。バージョン2.1.170以降にして、起動後に /model でFable 5へ切り替えるだけです。
ここから、実際の一晩を時系列で見ていきます。
実録①:全11記事の精読監査でバックログを作る
最初にやったのは、直すことではなく「測ること」でした。
エージェントに全11記事を精読させて、記事ごとにスコアを付けさせました。基準は執筆ルールとの適合度、検索意図の網羅度、情報の鮮度、構造化データの整合性です。
結果、スコアは3.5〜9.0までバラけました。動画制作系の記事は9.0で、ほぼ手を入れる必要なし。一方で、初期に書いたサイト公開記事とMac環境構築記事は3.5と4.0。看板のはずのClaude Codeインストール記事ですら6.0で、後発のCodex記事より薄いという判定でした。
これは正直、耳が痛い監査結果でした。書いた本人は「全部それなりに良い記事」だと思っていたからです。
監査結果は、課題ごとに優先度P1〜P5を付けたバックログ（課題一覧表）にまとめさせました。
- P1: 弱い記事の全面増補（5,000字台の2記事＋看板記事）
- P2: 機械的に直せる横断修正（FAQ構造化データの不一致が8記事、説明文の文字数不足が10記事）
- P3: 鮮度の問題（削除済みコマンド、旧モデル名、旧料金）
- P4: 良い記事の型を全記事へ横展開（プロンプト集、用語集、相互リンク）
- P5: 運用の宿題
この監査だけで見えた発見が2つあります。
1つ目は、FAQ構造化データの不一致が11記事中8記事にあったこと。本文のFAQを後から増やしたのに、検索エンジン向けのデータを更新し忘れるミスが、積み重なっていました。人間の運用ではほぼ確実に起きる漏れです。
2つ目は、鮮度の劣化です。たとえばCodexの記事には npm bin -g というコマンドが載っていましたが、これはnpmのバージョン9で削除済みのコマンドです。読者が実行するとエラーになります。書いた時点では正しかった情報が、時間経過で「動かない手順」になっていました。
測ってみないと、自分のブログの本当の状態は分かりません。改善はスコアリングから始まります。
実録②:ルールと機械lintという「基盤」を先に作る
監査が終わった時点で、すぐ11記事の改善に入りたくなります。でも、その前にやるべきことが2つありました。
執筆ルールを1本化する（rule.md v3.0）
11体のエージェントがバラバラの判断で記事を直すと、11通りの「良い記事」ができてしまいます。それを防ぐために、執筆ルールを1つのファイル（rule.md v3.0）に固めました。
中身は大きく5本柱です。
- 事前リサーチ: 書く前に検索キーワード・検索意図・差別化ポイントを決める
- 一次体験: 実測値や実際の失敗など、本人にしか書けない証拠を必ず入れる
- 内部リンク: 記事を孤立させず、関連記事と相互にリンクする
- 鮮度: 料金・コマンド・モデル名は公式ページで確認し、更新日を必ず動かす
- LLMO: ChatGPT検索やAI Overviewに引用されやすい形（結論先出し、自己完結するFAQ）にする
機械lint（自動チェック）を作る
もう1つが、記事の合格判定を人間の目からプログラムに移すことでした。
チェックスクリプトを作り、次を自動で検査させます。
- 本文の文字数（最低基準を下回ったら不合格）
- 見出し（h2）の数
- 本文のFAQと構造化データ（JSON-LD）の件数・文言の一致
- タイトルと説明文の文字数
- OGP画像やURLの整合性
- 誇大な収益表現など、禁止ワードの混入
そして「lintのerrorが0になるまで公開禁止」というゲートを敷きました。
これが効きました。エージェントは優秀ですが、11体もいれば誰かが何かを見落とします。人間のダブルチェックの代わりに、機械が全記事を同じ基準で検査する。品質保証を「頑張り」ではなく「仕組み」にした瞬間です。
実録③:サブエージェント11体で並列改善
基盤ができたところで、いよいよ本番です。
オーケストレーターのFable 5が、記事ごとに指示書を作り、11体のサブエージェントを並列で起動しました。各エージェントへの指示はおおむねこうです。
- あなたの担当は記事フォルダ◯◯だけ。他のフォルダと共有ファイルは編集禁止
- rule.md v3.0とバックログの担当分を読んでから作業する
- 監査で指摘された課題（P1〜P4のうち担当分）をすべて潰す
- 料金・コマンド・仕様は公式情報と矛盾しないこと。不確かなら「最新は公式で確認」と書く
- 完了条件はlintのerror 0
ここからの数時間は、正直に言うと人間は見ているだけでした。
5,184字だったサイト公開記事が、公開作業（デプロイ）まわりのエラー対処12パターンを足して16,029字に育っていく。5,812字だったMac環境構築記事が、17,291字の本格ガイドになっていく。それが11並列で同時に進みます。
鮮度の修正も同時に走りました。実際に直った例を挙げます。
- npmのバージョン9で削除済みの
npm bin -gを発見して、現行のコマンドに置換 - Codexの承認モードが旧名称のままだったのを、現行仕様の名称へ更新
- コード例に残っていた旧モデル名を、現行モデルへ更新
- 各ツールの料金を公式ページで再確認して、変わっていた部分を修正
面白かったのは、エージェント同士が競合しないので、進捗の速い記事と遅い記事が自然にバラけて終わっていくことです。軽い修正の記事は先に終わり、全面増補の記事は最後まで走る。人間のチームと同じ光景が、画面の中で起きていました。
実録④:統合チェックと公開、そして404の発見
全エージェントの作業が終わったら、オーケストレーターに戻して統合フェーズです。
- 全11記事にlintを一括実行 → error 0 / warn 0 を確認
- FAQ構造化データが本文と一致しているか全記事で確認
- 記事同士の相互リンクが両方向で張られているか確認
- Supabase（記事データベース）へ一括投入
- 公開後のページを実際に開いて表示確認
そして、ここで想定外の発見がありました。
公開検証の途中で、「記事一覧には表示されるのに、クリックすると404になる」記事が3つ見つかったのです。調べると、記事のメタ情報（タイトルや説明文）はデータベースにあるのに、本文データが欠落していました。過去の運用のどこかで、投入が中途半端に終わっていたようです。
つまりこのブログは、11記事あるつもりで、実際に読める記事は8記事しかなかった。何ヶ月もです。
3記事の本文はローカルの原稿から復旧して、その夜のうちに再投入しました。改善プロジェクトのつもりが、障害対応までセットで終わった形です。
これも「全部を機械的に検証する」体制だから見つかった問題で、人間が目視でチラチラ確認する運用では、たぶんまだ気づいていません。
一晩で終わった設計上の理由
「Fable 5がすごいから速かった」だけだと、再現できる話になりません。一晩で終わった理由は、設計に分解できます。
自分のブログで再現する手順（まず3記事から）
ここからは、あなたのブログ・サイトで同じことをやる手順です。
いきなり全記事はおすすめしません。まず3記事で小さく回して、体制の感触をつかんでください。3記事でも監査→改善→検証の流れは同じで、効果は十分に体感できます。
前提はClaude Code（Fable 5が使える状態）と、記事データを手元のファイルとして触れることです。コードを書く作業は出てきません。人間がやるのは、日本語で指示を出すことと、結果を確認することだけです。
WordPressの人は、記事をエクスポート（書き出し）して手元のフォルダで直し、直した本文を管理画面から貼り戻す形なら同じ流れが組めます。noteやはてなブログのように書き出しにくいサービスでも、記事本文をコピーしてテキストファイルとして保存すれば、監査と改善はまったく同じようにできます。戻すときは、直った本文を投稿画面に貼り直すだけです。
監査させる
30分〜1時間やることを一言で：直す前に、AIに記事の通信簿を作ってもらいます。
改善対象の3記事をAIに精読させ、スコアと課題一覧（バックログ）を作らせます。ここで大事なのは、直させないことです。まず測る。
観点は、検索意図の網羅度、情報の鮮度（料金・手順・ツール名）、構造（見出し・FAQ・内部リンク）、独自性（他のサイトにない一次情報があるか）あたりで十分です。
ルールを1枚にまとめる
約30分やることを一言で：「うちの記事のあるべき姿」を1枚のメモにします。
監査結果を見ながら、「うちの記事はこうあるべき」を1つのファイルにまとめます。完璧を目指さなくて大丈夫です。タイトルの付け方、結論の位置、FAQの形式、やってはいけない表現、この4つだけでも効果があります。
チェックリストを機械化する
30分〜1時間やることを一言で：記事の合格・不合格を、機械が判定できるようにします。
ルールのうち、機械的に判定できるもの（文字数、見出し数、FAQの件数、リンク切れ）をチェックスクリプトにしてもらいます。プログラムが書けなくても大丈夫です。AIに「このルールを自動チェックするスクリプトを作って」と頼めば作ってくれます。
最低限、「公開前にこのチェックを通す」という合格ゲートを作ることが目的です。
記事ごとにエージェントを走らせる
1〜3時間やることを一言で：記事ごとに専属の担当AIを付けて、一斉に直してもらいます。
3記事なら3体のサブエージェントを並列で起動します。指示のポイントは3つです。
- 担当記事のフォルダ（ファイル）以外は編集禁止と明示する
- ルールファイルとバックログを必ず読ませてから作業させる
- 完了条件を「チェックがすべて通ること」にする
Claude Codeでは、タスクを分けて依頼すれば、サブエージェントへの分担はFable 5が自分で組んでくれます。「3記事を並列で、それぞれ専任の担当で直して」という頼み方で十分伝わります。
統合チェックして公開する
約30分やることを一言で：大事な数字だけ人間の目で確かめて、公開します。
全記事のチェックを一括で通し、料金や手順など「間違うと読者に実害がある情報」だけは人間が公式ページと突き合わせます。問題なければ公開。更新日は必ず動かしてください。
- 3記事のスコアと課題一覧（バックログ）ができている
- 執筆ルールが1ファイルにまとまっている
- 公開前チェックの合格ゲートがある
- 各エージェントの編集範囲を担当記事だけに制限した
1つでも欠けている場合は、次のプロンプト集から該当するものを貼って埋めてください。3記事で回るようになったら、対象を10記事、20記事と広げるだけです。増えるのはエージェントの数だけです。
コピペで使えるプロンプト集
実際の流れをそのまま真似できるように、各STEPで使えるプロンプトを置いておきます。[ ]の中を自分の状況に書き換えて、Claude Code（またはCodex）に貼ってください。
プロンプトに秘密のキー、パスワード、顧客情報は書かないでください。監査を依頼する時
あなたはブログの監査担当です。まだ記事を直さないでください。
対象: [記事フォルダやURLの一覧]
全記事を精読して、次の観点で監査してください。
- 検索意図の網羅度（読者の疑問に答え切れているか）
- 情報の鮮度（料金、コマンド、ツール名、画面の文言が現在も正しいか）
- 構造（結論の位置、見出し、FAQ、内部リンク）
- 独自性（実体験や実測値など、他サイトにない情報があるか）
出力:
1. 記事ごとの10点満点スコアと判定理由
2. 課題を優先度P1（今すぐ）〜P3（余裕があれば）に分けた一覧表
3. 機械的に直せる課題と、書き足しが必要な課題の区別執筆ルールを作る時
さっきの監査結果をもとに、このブログの執筆ルールを1つのMarkdownファイルにまとめてください。
含めるもの:
- タイトルと説明文の付け方（文字数の目安つき）
- 記事の基本構成（結論の位置、FAQ、まとめ）
- 使ってはいけない表現（誇大表現、根拠のない断定）
- 料金や手順を書く時のルール（公式確認、更新日の扱い）
条件: 今後この1ファイルだけ読めば書けるように、簡潔に。完璧より運用しやすさを優先してください。チェックリストを機械化する時
執筆ルールのうち、機械的に判定できる項目を自動チェックするスクリプトを作ってください。
チェックしてほしいこと:
- 本文の文字数（最低[9,000]字）
- 見出し（h2）の数（最低[12]個）
- FAQの件数（最低[6]問）と、構造化データとの一致
- タイトル[28〜32]字、説明文[120〜160]字
- 禁止表現が入っていないか
条件: 実行するとerrorとwarnの一覧が出て、errorが1つでもあれば不合格と表示してください。使い方も教えてください。1記事の改善を任せる時（範囲制限つき）
あなたは記事「[記事名]」の専任担当です。
編集していいのは [記事のフォルダ/ファイルパス] だけです。
他の記事、共通ファイル、設定ファイルは読むのはOKですが、編集は禁止です。
作業前に必ず読むもの:
- 執筆ルール: [ルールファイルのパス]
- 監査で出たこの記事の課題: [課題の一覧を貼る]
課題をすべて解消してください。料金・コマンド・仕様は公式情報と矛盾しないように。
確認できない事実は書かず、「最新は公式で確認」と添えてください。
完了条件: チェックスクリプトでerror 0になること。複数記事を並列で任せる時
[3]記事の改善を並列で進めてください。
体制:
- あなたがオーケストレーターとして全体を管理する
- 記事ごとに専任のサブエージェントを起動する
- 各サブエージェントは自分の担当記事フォルダ以外を編集禁止にする
各担当への共通指示:
- 執筆ルール[パス]と監査結果を読んでから作業する
- 完了条件はチェックスクリプトのerror 0
全員が終わったら、全記事のチェック結果と変更内容の一覧を報告してください。公開前の最終確認をする時
改善が終わった[3]記事の公開前チェックをしてください。
- 全記事にチェックスクリプトを実行して、結果を一覧で出す
- 料金・コマンド・手順など、読者に実害が出る情報の記述箇所を抜き出して、根拠（公式ページ）と一緒に一覧にする
- 記事同士の内部リンクが切れていないか確認する
- 更新日が今日の日付になっているか確認する
errorやリンク切れがあれば、公開せずに理由を報告してください。正直な注意点:暴走・捏造・コスト
うまくいった話だけだとフェアではないので、リスクと対策も正直に書きます。
注意1: エージェントの暴走は「範囲の制限」で防ぐ
エージェントに全権を渡すと、頼んでいないファイルまで「良かれと思って」直すことがあります。11体が同時にそれをやったら、ブログは壊れます。
対策はシンプルで、担当フォルダ以外は編集禁止と、指示に明文化することです。今回の体制で競合や事故がゼロだったのは、Fable 5が賢かったからではなく、賢さに頼らない構造にしたからです。
あわせて、作業前の状態をGit（変更履歴を記録して、いつでも元に戻せる仕組み）などでバックアップしておけば、何が起きても戻せます。「戻せる状態で任せる」が大原則です。
注意2: 事実の捏造リスクは「公式確認の一元化」で潰す
AIは、それらしい嘘を自信満々に書くことがあります。ブログ改善では、料金・コマンド・仕様が特に危険です。間違えると読者に実害が出ます。
今回の対策は2つでした。
- 料金・モデル名などの重要な事実は、オーケストレーター側で公式ページを確認して「事実シート」に一元化し、各エージェントはそれに従う
- 各エージェントには「確認できない事実は書かず、最新は公式で確認と添える」を義務化する
11体がバラバラに事実確認をすると、記事ごとに数字が食い違う事故が起きます。事実確認は中央で1回、が正解でした。
注意3: コストは「使いどころの選別」で管理する
Claude Fable 5は最上位モデルなので、安くはありません。使った分だけ支払う直接利用（API）なら100万トークンあたり入力10ドル・出力50ドルで、これは同社のOpusの2倍、Sonnetの5倍です。
ただ、今回のような「一晩で1ヶ月分の作業」に対する対価としては、人間の人件費と比べれば圧倒的に安い、というのが実感です。サブスクプラン（Pro/Max/Team）で使う場合の条件や、OpusやSonnetとの使い分けの考え方は、Claude Fable 5の料金記事に詳しくまとめています。
全部をFable 5でやる必要はありません。監査や統合のような判断の重い工程はFable 5、機械的な修正はSonnetなど、工程でモデルを使い分けると費用は大きく下がります。料金は変わる可能性があるので、最新は公式料金ページで確認してください。
実務展開例12選:ブログ以外にも使える
この「監査→ルール→並列改善→機械チェック」の型は、ブログ専用ではありません。「同じ形式のコンテンツがたくさんあって、全部を一定品質に揃えたい」場面なら、ほぼそのまま使えます。
どの場合も勘所は同じです。1エージェント1担当で範囲を区切る。ルールを1枚に固める。合格判定を機械にやらせる。この3つを守れば、対象が記事でも商品説明でも求人票でも、体制はそのまま回ります。
学び:次もこの体制でやるための4原則
一晩やってみて固まった原則を4つ残します。この4つは、次に同じことをやる時のチェックリストでもあります。
よくある質問
何記事くらいから並列改善の効果がありますか？
3記事から効果があります。並列化の時間短縮は3体でも十分に体感でき、監査→ルール→機械チェックという基盤は記事数が増えるほど効いてきます。逆に1〜2記事なら並列体制を組むまでもなく、1体のエージェントに順番に任せる方がシンプルです。この記事では、まず3記事で小さく回す手順を紹介しています。
WordPressのブログでもできますか？
WordPressでもできます。記事をMarkdownやHTMLとしてエクスポートし、手元のフォルダで今回と同じ「監査→ルール→並列改善→機械チェック」を回してから、直した本文を戻す流れです。注意点は、AIに管理画面やデータベースを直接触らせないこと。手元のファイルで作業して、公開への反映は人間が確認してから行うのが安全です。
Claude Fable 5でないとできませんか？
体制自体はSonnetやOpusでも組めます。ただしClaude Fable 5はタスクが長く複雑なほど他モデルとの差が広がる特性があり、今回のような「11記事×数十項目のルール適用」を途中で崩れずに走り切る安定感が違いました。費用を抑えたい人は、判断が重い監査・統合をFable 5、機械的な修正を下位モデルに分ける使い分けがおすすめです。
AIが事実を捏造するリスクはどう防ぎますか？
捏造リスクはゼロにはならない前提で、仕組みで潰します。今回は、料金やモデル名などの重要な事実を指揮役が公式ページで確認して事実シートに一元化し、全エージェントにそれ以外の断定を禁止しました。さらに「確認できないことは、最新は公式で確認と書く」をルール化しています。公開前に人間が実害の出る記述だけ最終確認すれば、実運用上の事故はほぼ防げます。
費用はどれくらいかかりますか？
Claude Fable 5のAPI料金は100万トークンあたり入力10ドル・出力50ドルで、Opusの2倍、Sonnetの5倍です。Pro/Max/Teamのサブスクプランから使う方法もあります。今回のような一斉改善は消費トークンが大きいものの、人間が1ヶ月かける作業の対価と考えると十分に安いのが実感です。料金は変わる可能性があるため、最新は公式料金ページと料金解説記事を確認してください。
記事を一気に書き換えるとSEO評価は下がりませんか？
内容が薄くなる書き換えなら下がるリスクがありますが、今回のような増補型の改善は逆です。検索意図に足りなかった中身（エラー対処、FAQ、実例）を足し、構造化データと内部リンクを整え、更新日を正しく反映させる作業なので、検索エンジンには「手入れされているサイト」として伝わります。大事なのは、元記事の検索意図とURLを変えないことです。
人間の作業はどこまで必要ですか？
今回、人間がやったのは方針の判断（どこまで直すか、何を優先するか）と最終GOの2つだけです。ただし、この2つは省略できません。特に料金や手順など読者に実害が出る情報の最終確認と、公開の責任は人間側に残すべきです。作業はAIに任せて、判断と責任は人間が持つ。この分担が現時点の正解だと考えています。
まとめ
2026年7月2日の夜にやったことを、もう一度並べます。
- 全11記事をエージェントが精読監査して、スコアとバックログを作った
- 執筆ルールを1本化し、機械lintという公開ゲートを作った
- 記事ごとに専任のサブエージェント11体を並列で走らせた
- 全記事lint error 0で一括再公開し、ついでに404だった3記事も復旧した
- 人間の作業は方針判断と最終GOだけ。所要は一晩
これは特別な会社の特別な事例ではありません。Claude CodeとFable 5があれば、個人ブログでも同じ体制が組めます。
- 自分のブログ・サイトから改善したい3記事を選ぶ
- この記事の監査プロンプトを貼って、まず「測る」
- 出てきたバックログの一番上から、エージェントに直させてみる
Fable 5をまだ触っていない人は、この2本から読むと、今回の体制がどの機能で成り立っているかが繋がります。
AIを触れる人で終わらず、AIのチームを運営する人へ。その最初の一晩として、まず3記事から始めてみてください。
更新履歴
- 2026-07-02: 記事公開。
- 2026-07-03: 初心者向けに説明を見直し。エージェント・lint・構造化データなどの言い換えを追加し、再現手順に「やることを一言で」とWordPress・note向けの補足を追記。
最初の監査で詰まったら、そこで止まらなくて大丈夫です。
自分のブログやサイトでこの体制を組みたいけれど、最初の設計で迷う人は、公式LINEで相談してください。30分無料で、一緒に画面を見ながら監査の最初の一歩を進めることもできます。