この記事は、記事を作成・修正・検査するときにAI編集者が「どこを見るか」「何を優先するか」「どうやって根拠とネタを両立するか」を、現行の記事品質v5に沿ってまとめた運用ガイドです。
個人を特定できる情報は含めません。固有の私生活・勤務先・住所・アカウント情報などは一般化しています。
5秒で結論：記事を書くときは8層を見る
AI編集者が見る場所は、ざっくり次の8層です。
- 今回の依頼 — 何を作るのか、何をしないのか
- 過去メモリ・過去セッション — 文体、品質ルール、過去に決めた例外
- GitHubの最新main — 現在有効な契約、品質epoch、編集ルール、QA
- 元記事・原資料 — 数字、日付、引用、固有名詞、不確実性という「壊してはいけない地面」
- Webの一次・公式・研究資料 — 現在性、制度、仕様、研究、反証
- 記事そのもの — 読者ニーズ、切り口、構造、主張と根拠、ネタ、自然さ
- 12言語版 — 言葉ではなく概念をローカライズし、正確な名前は保存
- 実サイト・実データ・QA証拠 — スマホ、拡大、長文、リンク、表、エラー時まで確認
つまり、「Googleのガイドを読んで文章を書く」ではない。
Googleだけ見ていたらGoogle社員の霊が乗り移るし、Microsoftだけ見ていたら説明書が説明書を産み始める。記事工場で必要なのは、複数の強い情報源と、その記事の目的をつなぐ編集判断です。
1. 最初に見るのは「今回の注文」
最優先は今回のユーザー指示です。
「網羅的に」「短く」「ネタ多め」「研究ベース」「画像なし」「12言語」「個人情報は除く」など、今回だけの条件があります。古いテンプレートがどれだけ立派でも、今回の注文が「ラーメン」なのにカレーを出したら普通に事故です。
ここで決めるのは主に次の5点です。
- 誰向けの記事か
- 読者の疑問は何か
- 読後に何が分かる・できる状態を目指すか
- どこまで調べる必要があるか
- 今回だけの禁止・形式・トーンは何か
この段階で記事の「Reader Need（読者ニーズ）」と「Reader Outcome（読後成果）」を置きます。
2. 次に見るのは過去メモリと過去セッション
記事には、その場限りの指示だけでは足りない「積み上がった編集ルール」があります。
たとえば現在の基準では、
- 普通の成人に自然なまま、中学生でも意味を追える
- 5秒で結論、30秒で概要
- タイトルだけで何の記事か分かる
- H2だけ読んでも流れが分かる
- 原則1段落1テーマ
- 結論→理由→具体例
- 専門語は「名前」より先に「正体」を説明
- ネタは論点を理解しやすくするために使う
- 個人を特定できる情報は一般化
- 12言語は逐語訳しない
といったルールがあります。
ここで重要なのは、過去メモリを事実の出典にしないことです。
「以前こう決めた」は制作方針には使えます。しかし価格、法律、仕様、研究結果、現在の制度まで「昔そう言ってたから」で通すと、記事がタイムカプセルになります。
メモリは編集方針の継続性に使い、事実は現在の証拠へ戻ります。
3. GitHubの最新mainは「現在の取扱説明書」
長期運用では、GitHubの最新mainが記事工場の正本です。
現在の品質システムでは、新しい29個目の品質軸を増殖させず、既存28親軸の下に専門編集ノウハウをサブゲートとして統合しています。
AIが見る代表的な正本は次の種類です。
- 現在の品質epoch
- 28品質軸
- 読者体験・認知アクセシビリティ
- コンテンツ品質
- Microsoft / Google拡張基準
- プロ編集ワークフロー
- 日本語編集ルール
- 自然な文章スタイル
- 多言語・ローカライズ基準
- 情報パスポート・鮮度
- PASS / SAMPLE_PASS / COMPLETE_100の定義
- 正式採用・公開・検証の契約
ここで大事なのは、古い成功記録より最新のルールが上ということです。
昨日100点だった記事でも、品質ルールが変われば「昨日の100点」という歴史になります。ゲームの旧レギュレーションで全勝しても、新環境の大会に「昨日勝ったので今日も優勝です」とは入れません。
4. 元記事・原資料は「絶対に壊してはいけない地面」
編集できるのは文章の見せ方であって、事実を都合よく作り替えることではありません。
特に保護するものは次です。
- 数字
- 日付
- 金額
- 単位
- 人数
- 制度名
- 製品仕様
- URL
- 引用
- 出典
- 固有名詞
- 研究設計
- 不確実性
- 「分からない」という状態
文章を読みやすくするために「約30%」を「半分くらい」にしたら、読みやすい以前に別の世界線です。
AI編集者は、意味を変えずに順序・説明・例・見出し・表現を直すのが基本です。
5. ネットでは「強い根拠」から見る
現在性や外部事実が必要な記事では、ネットを調べます。ただし検索結果の上から順に土下座はしません。
情報源はおおむね次の強さで見ます。
- 規格・法令・一次資料
- 公式提供者のガイド・仕様
- 一次研究・査読研究
- 専門的な編集・報道基準
- 信頼できる二次資料
- コミュニティ・SNS・体験談
もちろん記事タイプによって変わります。
「利用者が実際どう感じたか」ならRedditやSNSが意味を持つこともあります。逆に「WCAGの必須条件は何か」を掲示板の「たぶん24pxっす」で決めたら、規格が泣きます。
さらに、分析・比較・研究・推薦・高インパクト記事では、自分の結論を壊す資料も探します。
「この説を支持する資料を5個集めました！」だけだと、研究というよりファンクラブです。
6. 28品質軸は「28個の神様」ではない
現行システムは28親軸を維持します。大きく見ると、17の読者体験軸と11の内容品質軸です。
読者体験の17軸
- 注意
- 記憶
- 判断
- 処理速度
- 理解
- 情報の匂い
- 視覚的混雑
- 階層
- レイアウト
- 文字
- 色・視覚
- 操作
- 多言語
- 支援技術
- 動き
- 状態変化
- 実データ耐性
内容品質の11軸
- 読者・目的・読後成果
- 独自価値
- 信頼・著者・制作方法
- リスク・数字・意思決定
- 表・図・画像の意味
- 手順・行動・記憶負荷
- 包摂性・文化
- 読者タスク成立性
- 地域別完成度
- 性能・集中読書
- 音声としての文章
28個をチェックリストとして毎回全部文章中に唱える必要はありません。
目的は「軸を埋めること」ではなく、読者がどこでコケるかを先に考え、その障壁に関係する軸を使うことです。
記事工場で「本日の28神への奉納がまだ3軸不足しています」と言い始めたら、品質管理ではなく宗教法人です。
7. プロ編集の14サブゲートを見る
28親軸の下には、プロ編集工程として14のサブゲートがあります。
- 読者ニーズと読後成果
- 記事の切り口
- 冒頭のつかみ
- この記事は何の話で、なぜ重要か
- 重要情報の前出し
- 各段落の役割
- 主張と根拠の対応
- 反証チェック
- 情報源の強さ
- 構造→事実→文章の順で編集
- タイトルの約束を本文で回収
- 次に何があるか予測できる導線
- 表記・用語の一貫性
- 公開後の鮮度とコンテンツ負債
ただし全部を全記事へ機械適用しません。
グルメ体験記事にReutersのニュース構造を丸ごと着せる必要はありませんし、API仕様書を「突然、麺が笑った。」から始める必要もありません。
記事タイプに合う技法だけ使う。これが重要です。
8. 編集順は「構造→事実→文章」
プロ編集で地味に効くのが順番です。
1周目：構造
- 読者の疑問に答えているか
- 切り口があるか
- 結論が遅すぎないか
- H2だけで流れが通るか
- 重複した章はないか
- 不要な章はないか
2周目：事実と根拠
- 主張に根拠があるか
- 根拠はその主張を本当に支えるか
- 数字の母数・比較対象は必要か
- 反対証拠はないか
- 古い情報ではないか
3周目：文章
- 1文が詰まりすぎていないか
- 専門語を説明したか
- 指示語が迷子ではないか
- ネタが効いているか
- AIっぽい装飾太字や「※補足」連射になっていないか
この順番を逆にすると、来週取り壊す家の壁紙だけピカピカに張り替える編集になります。
9. 数値ルールは3種類に分ける
数字が出るとAIは急に「基準値」を作りたくなることがあります。そこを止めます。
数値は必ず3種類へ分けます。
公式・規格が定めた数値
例：WCAGの320 CSS px相当のリフロー、200%文字拡大、対象サイズなど。
これは、その規格が定めた範囲と例外の中でhard gateにできます。
研究で得られた数値
研究対象、言語、条件、サンプルが違えばそのまま万能基準にはできません。
「英語で○語」が研究にあったから「日本語では○文字」と電卓で錬金してはいけません。
サイト内部のヒューリスティック
「H2が4個以上なら目次を確認する」など、レビュー候補を見つける目安です。
便利ですが、目安が警察官に昇進してはいけません。
Google自身も「Googleが好む文字数」のような万能値を示していません。長さより、目的に必要な内容を満たしているかを見るべきです。
10. 12言語は翻訳ではなくローカライズする
対応言語は、
- 日本語
- 英語
- 韓国語
- 中国語（簡体字）
- 中国語（繁体字）
- スペイン語
- ポルトガル語（ブラジル）
- インドネシア語
- タイ語
- ベトナム語
- フランス語
- ドイツ語
です。
多言語化では、言葉を3種類に分けます。
LOCALIZE_CONCEPT
一般概念は、その言語で普通に理解できる言葉へ置き換えます。
KEEP_EXACT_NAME
製品名、規格名、API、URL、コード、ファイル名、論文識別子など、正確な名前が重要なものは保持します。
KEEP_EXACT_NAME_WITH_LOCAL_DESCRIPTOR
名前は保持するが、それだけでは何者か分からない場合は、その言語で短い説明を添えます。
日本語の語順・改行・ダジャレを12言語へコピーするのは翻訳ではありません。
それは海外旅行に日本のコンセントを気合いで刺している状態です。
ジョークも意味をローカライズします。通じないネタは別の自然な笑いへ置き換えます。
11. PASSは平均点ではなくゲート方式
現行の基本はgate-first-score-secondです。
つまり、
「事実は間違っているけど、デザイン95点、文章96点、平均90点超えたので合格！」
はありません。
重大なFAILは平均点で消せません。
SAMPLE_PASS
確認した標本では重大問題がなかった。
PASS
現在の対象範囲が正確に定義され、必要な証拠が現在のコンテンツidentity・品質epoch・ルール版へ結び付き、必要な項目に未解決の重大UNKNOWNがない。
COMPLETE_100
適用されるhard gate、意味レビュー、必要な外部/runtime証拠まで成立し、現在の全対象で閉じている。
人間が採点していないだけでFAILにはしません。現在はsource-grounded AI semantic editorが正式な意味レビュー主体です。
ただしAIが自分で書いて、
「AI先生による厳正な審査の結果、AI先生の文章は完全に正しいと判定されました」
とやっても証拠にはなりません。
裁判官はAIでもいい。しかし証拠品まで裁判官が粘土で作ってはいけない。
12. 本文の次は実画面を見る
記事本文が正しくても、画面で壊れれば読めません。
実サイトでは少なくとも次のような状態を確認します。
- 320px級スマホ
- 390px級スマホ
- 横向きスマホ
- タブレット
- 1280px / 1440px級PC
- 200%文字拡大
- WCAG Text Spacing
- 疑似ローカライズによる文字膨張
- forced-colors
- reduced-motion
さらに実データの「地雷」を使います。
- 最長タイトル
- 最長の改行不能文字列
- 最長本文
- 最短本文
- 見出し最多
- リンク最多
- 表最多
- 定義っぽい要素最多
- code / pre最多
- 複数文字体系が混ざる記事
普通の記事だけで「大丈夫でした！」と確認すると、図書館でスクワットして健康診断を終えた気になるくらい検査範囲が違います。
エラー、0件、読み込み失敗、翻訳欠損などの状態も記事体験の一部です。
13. 研究ルールも自走する
品質ルール自体も古くなります。
そこで既存の中央監査へ研究更新を組み込みます。
- 通常refresh：原則7日ごと
- deep sweep：原則30日ごと
- 重大な公式変更：必要なら前倒し
見る対象には、W3C/WCAG、ISO 24495、Microsoft、Google、Reuters、AP、GOV.UK、認知科学、HCI、読解、情報探索、アクセシビリティ、多言語・編集研究などがあります。
新発見は、
既存ルールと重複していないか → 情報源は強いか → どの記事に適用するか → 数値の範囲は何か → 反対証拠はあるか
を見て、
- ADOPT
- CONDITIONAL
- TEST
- DEFER
- REJECT
- SUPERSEDED
へ分類します。
2026年8月28日のv5初回deep sweepでは、現行のPASS基準をひっくり返すほどの変更は見つからず、v5を維持する判断になっています。
14. 公式ガイドは神託ではない
Microsoft、Google、Reuters、AP、W3C、ISO。全部強い資料ですが、適用範囲が違います。
たとえば技術文書では、慣用句やユーモアを抑えることが翻訳性や正確性に効く場合があります。
でも、そのルールをグルメ体験記や娯楽記事へ全適用すると、
ハンバーグを摂取した。肉汁が発生した。満足度が向上した。
みたいな、感情をコンプライアンス室へ置いてきた文章が完成します。
公式ガイドは「どの文脈で正しいか」を見ます。
公式だから全記事へADOPTではなく、必要ならCONDITIONALです。
15. GitHubが死んでも記事の脳まで死なせない
GitHubが取得できない時も、記事作成・意味レビューを全部止める必要はありません。
復旧baselineとして、
- 28親軸
- AI編集者方針
- プロ編集ワークフロー
- 情報源の強さ
- 数値基準
- 研究更新方法
- PASS判定
- 工場を止めない原則
を別系統にも残します。
ただしGitHubが見えない時に、
- current SHA
- 最新receipt
- repoへ適用済みか
- 現在の正式進捗
を想像で埋めてはいけません。
そこはUNKNOWNです。
GitHubが復旧したら、latest main＋復旧baseline＋最新の一次・公式情報を突き合わせて通常運用へ戻します。
「最後に書いた方が勝ち」というblind last-write-winsは、編集方針ではなくじゃんけんです。
16. やらないこと
この記事工場では、少なくとも次を避けます。
- AI回答だけを事実の根拠にする
- 人間レビューを実施していないのに「専門家確認済み」と書く
- 公式が言っていない数字を「Google基準」などと名付ける
- 検索順位のためだけに低価値記事を大量生成する
- タイトルだけ煽って本文で答えない
- 元記事の数字や不確実性を読みやすさのために改変する
- すべての記事を同じニュース型・技術文書型へ押し込む
- 日本語の見出し・語順・ネタを他言語へ機械コピーする
- 全文を太字で殴る
- 「※補足」を雑草のように生やす
- 1記事の失敗で関係ない工場まで停止する
- 標本検査だけで「全サイト100点」と名乗る
まとめ：AI編集者は「文章を書く前」と「書いた後」の方が忙しい
記事を書く作業だけを見ると、AI編集者は文章生成機に見えます。
でも実際の仕事は、
依頼を読む → 過去ルールを読む → GitHub正本を読む → 元資料を守る → 一次・公式・研究を調べる → 反証する → 構造を作る → 事実を検証する → 文章を磨く → 12言語へローカライズする → 実画面で壊す → QAで閉じる → ルール自体も定期研究する
までです。
「記事を書いて」はスタートボタンであって、仕事の説明ではありません。
記事工場のAI編集者は、作家・校閲・リサーチャー・翻訳編集・QA・設備保全を一人で巡回します。
そして一番大事なのは、ルールを守った文章を作ることではなく、読者が意味をすぐ拾え、根拠を追え、必要な判断をできる記事を作ることです。
ルールはそのための工具です。工具箱を拝むための記事工場ではありません。
