株式会社Walkersが運営するAI支援.comの記事づくりでは、AIが本文を書き、決まった基準で機械が検証し、書いたAIとは別のAIが事実を確かめたうえで、最後に人が公開の可否を決める方針をとっています。本文の執筆や修正はAIが担い、企画の方向性、価格・制度などの数値承認、そして何を公開してよいかという最終判断を人が担うという役割分担です。この記事では、2026年9月時点の運用記録をもとに、企画から公開・計測までの8工程と実際に起きた失敗を記録します。
AIが担う執筆と確認、人に残した公開の最終判断
導入前は、記事のテーマ決めも、本文の執筆も、事実の確認も、すべて人が順番にこなしていました。特に、関連するテーマをまとめて何本も並行して書く場面では、後から一つずつ事実を確認する作業が積み上がりやすく、これが自動化を考えた主な動機でした。
AI支援.comでは、このうち本文の執筆と、事実確認の一次チェックにあたる検収をAIに任せています。人が担うのは、公開してよいかどうかの最終判断と、価格や制度など踏み込んだ数値の承認です。件数が増えても、この最終判断だけは省略していません。何本を同時に進めていても、公開の可否を決める人が最後に見るという順番は変えていません。
現行の編集方針では、モデルの役割を明確に分けています。全体の構成案や推敲指示、最終監査を担う編集側のAI（Astra / Fableなど）と、その指示にそって本文作成やリライトを行う執筆側のAI（Gemini 3.8 Flash）を切り離す設計です。あわせて検収工程では、書き上がった原稿を記録済みの一次情報と照合する役割を執筆側とは別のAIに担わせます。AI同士の意見の一致をそのまま事実の保証とは見なさず、どの一次情報をもとに照合したかを検収の根拠にするためです。この一連のやり取りと機械検証が終わったあとに、人（代表の渡辺敦司）が原稿を見て、価格や制度などの数値を含めて公開してよいかどうかを判断します。
企画から公開までの8工程と担当の分け方
工程は、企画から公開・計測まで一本の流れになっています。ここでは工程と役割を示します。
| 工程 | 内容・使う道具 | 担当 | 頻度 |
|---|---|---|---|
| 企画 | テーマと構成案の設計、読者の疑問の洗い出し | 人＋編集AI（Astra / Fable） | 案件ごと |
| 執筆 | 決まった構成にそって本文を執筆 | 執筆担当のAI（Gemini 3.8 Flash） | 原稿ごと |
| 機械検証 | 禁止語・文字数・見出し構成・強調の配置・リンク到達などを自動判定 | スクリプトによる決定論チェック | 原稿ごと |
| 一次検収 | 一次資料との照合による事実確認と表現の妥当性確認、修正案の作成 | 検収担当の別のAI | 原稿ごと |
| 修正反映 | 指摘に沿って本文をリライトし、機械検証と編集監査を実施 | 執筆担当のAI＋編集AIの最終監査 | 原稿ごと |
| 二次レビュー | 公開済み・下書きの横断点検。事実性・表現・構成・内部リンクを採点（2026年9月に28本を対象に実施した記録） | 複数班のAI（2026年9月点検時） | 一定規模ごと・定期点検（実施記録） |
| 承認 | 数値や内容変更を伴う公開・修正を人が最終確認 | 渡辺敦司 | 運用単位（2026年9月当時は週1回） |
| 公開・計測 | 機械検証の合格を確認して公開し、以後のアクセス状況を確認 | 編集運用＋人 | 都度 |
テーマは1本ずつではなく、関連する記事をまとめて企画し、読者が同じ関心から複数の記事にたどり着けるようにしています。機械検証で見ているのは、文字数や見出し構成、強調記号の使いすぎ、記事末の問い合わせ導線の有無、公開済み本文と入稿原稿の文言差分など、ルールに沿って自動判定できる項目です。本文中のリンク確認も行いますが、これはチェック時点の通信結果を確かめるものであり、相手先サイトの将来の稼働まで保証するものではありません。定型的な形式チェックはAIの解釈に頼らず、同じ入力なら同じ結果になるスクリプトで機械的に処理しています。一方で、出典の最新性や事実関係の真偽といった判断は、機械検証ではなく一次検収と人の確認で引き受けます。
- 1. 企画（人＋編集AI） テーマ設計と読者疑問の洗い出しを行い、構成案を作成します。
- 2. 執筆（執筆AI: Gemini 3.8 Flash） 構成案に沿って本文を執筆します。
- 3. 機械検証（スクリプト） 文字数・見出し構造・強調記号・禁止語・文言差分などを決定論的に自動判定します。
- 4. 一次検収（別の検収AI） 記録された一次情報と照合して事実関係と表現の妥当性を確認し、修正案を作成します。
- 5. 修正・監査（執筆AI＋編集AI） 指摘に沿って執筆AIがリライトし、機械検証と編集AIの最終監査で合格を確認します。
- 6. 人の承認（渡辺敦司） 合格原稿に対し、価格・制度等の重要数値と公開可否を人が最終判断します。
- 7. 公開・計測（編集運用＋人） 本番公開を実施し、アクセスや検索認識の状況を監視します。
【定期・一括の別経路】二次レビューは毎原稿の必須通過ではなく、2026年9月当時に複数班のAIで公開済み記事等を横断点検したような、一定規模ごとに行う工程です。検収・監査で不合格となった場合は執筆・修正へ差し戻されます。
2026年9月10日に実施した二次レビューでは、事実性・出典の新しさ、表現の適切さ、構成、読みやすさ、内部リンクという5つの観点で採点し、記事のまとまりごとに当時の複数班へ分担しました。指摘は、公開中の事実誤りを最優先、読者を誤導しかねない表現を次点、品質向上の指摘をその次、という優先度で仕分けました。この網羅レビューを行った時点の対象は28本でした。その後も新しい記事を公開しています。関連する記事どうしが互いにリンクし合っているかどうかも、当時のレビューで確認した観点のひとつです。
実際に起きた失敗と直し方
年表の形で、実際に起きた失敗をそのまま記録します。仕組みを作ったからといって失敗がなくなったわけではなく、むしろ網羅レビューを一度実施したことで、それまで気づいていなかった失敗がまとめて見つかりました。
- 2026年9月5日 公開直後の記事でサムネイル画像が未設定のまま残り、あわせてトップページの一部が検索エンジンにうまく認識されない状態が重なっていた。原因は公開作業時の確認漏れだったため、以降はアイキャッチの設定と検証合格の確認を、公開手順そのものに必須要件として組み込んだ。
- 2026年9月8〜9日 別の原稿の検収作業の副産物として、公開済みの記事が引用していた他社サービスの料金が、実際とは異なる契約区分の数値になっていたと判明した。検収の対象は新しい原稿だったが、その過程で既存記事の誤りが見つかった形で、原稿は修正したものの、本番への反映は人の確認を経るまで保留にした。
- 2026年9月10日 公開済み・下書きの全記事（当時28本）を対象にした網羅レビューで、他社サービスの料金改定が複数本の本文に反映されないまま残っていることが分かった。公開して終わりではなく、時間が経てば一次情報は古くなるという前提を、この時点で仕組みに組み込み直した。
- 2026年9月10日 同じレビューで、あるツールの分類が提供元の公式な表記と食い違っており、サイト内の別の記事とも矛盾していることが分かった。表記をそろえるため、該当箇所の分類を修正した。
- 2026年9月10日 別の記事で、条件付きで無料になる例外の記載が抜けており、実際より費用が高く見える書き方になっていたことが分かった。数値自体に誤りはなかったが、読者に不利な誤解を与えかねない書き方だったため、公式情報に基づいて例外の条件を書き加えた。
- 2026年9月10日 レビュー側のAIから、ある制度名について「検索しても出てこないので存在しない用語ではないか」という疑義が出た。しかし検索方法を変えて一次情報を独立に確認したところ実在すると分かり、この指摘は取り下げた。記事側の誤りだけでなく、検収側の過剰・誤った指摘を人が見極めて取り下げる判断も、運用に不可欠な一部となった。
これらの事例から分かるのは、単発の執筆時だけでなく、あとから見返して初めて見つかる課題や、AI側の誤指摘を見極める工程が必要になるという点です。似たような失敗を防ぐための考え方は、AI活用でつまずきやすい失敗パターンにも整理しています。画像・バナー制作の工程を1日単位で記録した実例は、〈AIにバナーを作らせた1日〉で確認できます。
人に残った判断
機械検証と2段階の検収を経ても、最後に人が見るところは残ります。何を公開してよいかという線引き、価格や制度など踏み込んだ数値の承認、そして誤りが見つかったときにどこまで書き直すかという最終判断です。二次レビューで洗い出した指摘も、公開中の事実誤りか、読者を誤導しうる程度か、品質向上に留まるかを仕分けたうえで、内容変更を伴うものは公開前に人の確認を経る運用にしています。
2026年9月時点の運用では、週に1回まとめて確認する形をとることで、都度の判断コストを抑えつつ公開前に人の目を通す機会を確保していました。反対に、機械的に判定できる形式項目にまで人の確認を挟むと、確認そのものが形骸化しやすいという判断もあります。価格のように後から変わりうる数値は、公開時点で正しくても再確認の対象から外していません。
何をAIに任せ、何を人が見るかという線引き自体も、一度決めて終わりではありません。実際に失敗が見つかるたびに、どこまでを機械検証に寄せ、どこからを人の確認に残すかを見直しています。最終的にどの記事に誰の名前で監修が付くかは、監修者プロフィールで公開しています。
AIに任せるときに先に決めた4つの前提
Walkersが記事制作の流れを設計するにあたり、あらかじめ定めた前提が4つあります。
まず、書いてよい事実は一次情報にあるものだけとし、実績や効果の数値を作らないことです。出典のない断定や、存在しない統計・URLを本文に混ぜないという制約を、執筆と検収の両方にかけています。
次に、AIの「完了しました」「反映しました」という報告をそのまま信じないことです。過去に、作業を任されたAIが何も実行しないまま完了したと報告し、そのまま止まっていた事象が複数回起きました。この教訓から、報告は主張であり証拠ではないという前提に立ち、実際のファイルや反映結果を確認して初めて完了とみなす運用にしています。この教訓をそのまま検収の起点にした実例は、〈AIの「完了しました」を信じない〉で確認できます。
また、隠しテキストのような読者に見えない形で検索エンジン向けの操作をしないことも、公開の前提にしています。
最後に、公開後も価格や制度は変わり続けるという前提を置いています。一次情報を引用するときは取得日をあわせて記録し、古くなった情報だと後から分かるようにしています。同じ入力なら同じ結果になる機械検証は、これらの前提のうち形式ルールや禁止語、必須項目の有無、文言差分などを毎回同じ基準で確かめるための仕組みという位置づけです。一次情報の真偽や最新性の判断は機械検証に含めず、検収と人の確認で引き受けています。
中小企業が同じことをするなら
Walkersと同じ規模の仕組みを一度に作る必要はありません。最小構成は3つの工程です。
まず、書いてよい事実だけを一つの場所にまとめた台帳を作ります。次に、その台帳にある事実だけを使って原稿を書きます。そのうえで、書いた本人とは別の目（別のAIや社内の別担当者）が台帳と原稿を照合して検収し、最後に公開責任者が確認して公開します。
最初から仕組みのすべてを自動化する必要もありません。文字数や見出しの数のように機械的に判定できる項目から自動チェックに任せ、事実の妥当性のような判断が要る部分は、当面は人が見る形で始めても構いません。検収の担当を別のAIにするか、社内の別の担当者にするかも、規模に合わせて選べば十分です。台帳・執筆・検収という順番を守るだけで、事実と違う内容が公開される前に止められる可能性は上がります。どの製品を使うべきかという話ではなく、確認の順番を先に決めることが重要です。自社のどの業務からAI化すべきか整理したい場合は、無料のAI自動化診断が出発点になります。
よくある質問
AIに書かせた記事は、そのまま公開しているのですか
いいえ。AI支援.comの方針では、AIが書いた原稿はまず機械検証にかけ、次に別のAIが事実を検収し、指摘があればAIがリライトして編集監査を通したうえで、最終的に人が公開の可否を判断してから公開しています。原稿ごとの必須確認は省略していません（全体を横断する二次レビューは2026年9月のように定期点検として実施した記録に基づきます）。
人はどの段階で記事を見るのですか
企画段階でテーマや方向性を確認するほか、執筆・機械検証・検収を経て修正がすべて反映された後、公開や修正の最終承認を行います。価格や制度などの重要な数値の確認も含め、人が最終判断を行います。
AIの「完了しました」という報告は信用できますか
そのままは信用していません。過去に何も実行せず完了したと報告する事象が起きたため、報告は主張であり証拠ではないという前提に立ち、実際のファイルや反映結果を人が確認しています。
中小企業がこの仕組みをまねる場合、何から始めればよいですか
事実を書き出した台帳、執筆、検収という最小の3工程からで十分です。最初から全自動化を目指す必要はありません。
自社のどの業務からAI化すべきかを知りたい方は、無料のAI自動化診断をご利用ください。自社の業務に合わせてAIを組み込む伴走支援については、FDE型AI導入支援で相談を受け付けています。自社の業務に合わせたシステムをAI駆動開発で作る場合の相談・見積りは、株式会社Walkersのシステム開発事業で受け付けています。本記事は、FDE型のAI導入支援を行う株式会社Walkersが運営しています。
参考
自社のモデル分担は現行の執筆・編集規程に基づき、各工程の運用と失敗事例は2026年9月時点の社内運用記録に基づきます。外部ガイダンスは以下の公開情報に基づきます。
