TL;DR
AIで記事サイトを作ると聞くと、「AIに文章を書かせて、100本くらい投稿すれば完成でしょ？」と思いがちだ。
違う。
それはコピー機を買って、図書館を作った気になっている状態である。
本当に作りたいのは、記事が増えても読者が迷わず、古い記事が混ざらず、12言語がごちゃ混ぜにならず、リンクが壊れず、事故が起きても自分で直せるサイトだ。
そのためには、AIを「作文マシン」ではなく、工場の作業員・検査員・道路工事屋・図書館司書・保守係として使う。
超ざっくり言えば、こうだ。
- 何のためのサイトか決める
- 記事を置く土地と倉庫を作る
- 記事1本ずつに名前札と指紋を付ける
- まず1言語でちゃんとした記事を作る
- 翻訳前に先生の赤ペン級の検査をする
- 12言語へ「意味を保ったまま」展開する
- 内部リンクとハブで道路と案内所を作る
- 時刻ではなく「状態」を見て自動工場を回す
- GitHubに入っただけで公開と言わず、本番ページまで確認する
- 100点の完成像と毎回比べ、壊れたら原因まで直す
AIに「いい感じに記事サイト作っといて」と言うだけでは、かなりの確率でAI町内会が勝手に道路を引き、看板を増やし、同じ家を3軒建てる。
だから大事なのは、AIの賢さより仕組みである。
まず最初に：サイトは「図書館＋道路＋工場」だと思えばいい
小学生向けに全部たとえる。
- 記事 = 本
- サイト = 図書館
- カテゴリ = 本棚
- ハブ記事 = 総合案内所
- 内部リンク = 本棚どうしをつなぐ道路
- URL = 本の住所
- 記事ID = 本の戸籍番号
- SHAやハッシュ = 本の指紋
- GitHub = 設計図と履歴を置く倉庫
- QA = 先生の赤ペンチェック
- デプロイ = 図書館を実際に開館すること
- 監視ルーティン = 夜中に見回る警備員
- CAS = 「この本がまだ第3版なら差し替えてよい」という確認
- 完了トークン = 「この工程はこの版で検査済み」というハンコ
これが分かれば、後半の難しい単語もほぼ怖くない。
1. まず「何のためのサイトか」を決める
1-1. 目標を「記事数」にしない
最悪の目標はこれだ。
1日100記事作る。
100記事作っても、誰にも読まれず、同じ話が20本あり、リンクが壊れ、翻訳が古かったら、100個のゴミ袋を高速で製造しただけである。
目標は読者の行動で決める。
たとえば、
- 困りごとの答えがすぐ見つかる
- 初心者がどの記事から読めばいいか分かる
- 詳しく知りたい人が次の記事へ進める
- 同じテーマの記事が整理されている
- どの言語でも同じ意味にたどり着ける
という状態だ。
1-2. AIに任せない「絶対ルール」を先に決める
AIは自由に考えさせるほど便利だが、何でも自由にすると事故る。
最初に「これは絶対ダメ」を決める。
例：
- 個人情報を出さない
- 数字や日付を勝手に変えない
- 出典を作り話で補わない
- 古い翻訳を最新版として扱わない
- 壊れたURLを公開しない
- 日本語ページから関係ない英語ページへ飛ばさない
- 同じ記事を2つの自動処理が同時に上書きしない
- AIが「できました」と言っただけで完成扱いしない
ここが工場の安全柵になる。
1-3. 「100点のあるべき姿」を文章にする
最初に100点を決めておくと、後からAIにこう言える。
今は何点？
何が足りない？
安全に直せるものを直して。
もう一度採点して。
これがQC、つまり「品質を見ながら改善する考え方」の基本だ。
2. 記事を置く土地と倉庫を作る
2-1. 最小構成
初心者なら、まずこれでいい。
- ドメイン：サイトの住所
- GitHub：ファイルと変更履歴の倉庫
- Webフレームワーク：ページを組み立てる道具
- ホスティング：実際にWebで見せる場所
- 分析：どの記事が読まれたかを見る道具
Astro、Next.js、Eleventyなど何を使ってもよい。大事なのは名前ではなく、記事データと表示プログラムを分けることだ。
2-2. 「元データ」と「表示結果」を分ける
元記事を直接、自動処理みんなで書き換えると危険だ。
おすすめは、
- 元記事
- AIが作った修正版
- 翻訳
- 内部リンク追加情報
- 検査結果
- 公開状態
を別々に持つこと。
料理で言えば、冷蔵庫の生肉に全員で直接ソースをぶちまけない。
下ごしらえ、調理、盛り付け、検品を分ける。
2-3. Git履歴を「タイムマシン」にする
GitHubを使う強みは、前の状態へ戻れることだ。
誰が、いつ、何を変えたかが残る。
だから自動処理には、
- 1回の変更を小さくする
- 変更理由を書く
- 強制上書きしない
- 途中経過をチェックポイント保存する
というルールを入れる。
3. 記事1本ずつに「名前札」と「指紋」を付ける
3-1. URLだけで記事を管理しない
URLは変わることがある。
タイトルも変わる。
だから記事には、変わりにくいIDを持たせる。
例：
articleFamilyId = article_000123
これが記事の戸籍番号。
日本語版も英語版も韓国語版も、同じ内容の家族なら同じ articleFamilyId を共有する。
3-2. 言語は別の軸にする
同じ記事でも、
article_000123 + ja
article_000123 + en
article_000123 + ko
のように扱う。
こうすると、
「英語だけ古い」 「韓国語だけ未完成」 「日本語だけ更新された」
を区別できる。
3-3. SHAやハッシュは「指紋」
文章が1文字でも変わるとハッシュが変わる。
だから、
この英訳は、どの日本語版を元に作ったの？
を確認できる。
日本語が新しくなったのに英語の指紋が昔の日本語を指していたら、
英語は古い。
AIが「たぶん大丈夫」と言っても関係ない。
指紋が違う。終了。
3-4. 状態を持つ
記事には最低限、
- 下書き
- 日本語確認済み
- 翻訳中
- 翻訳確認済み
- 内部リンク確認済み
- 公開可能
- 公開済み
- 古くなった
のような状態を持たせる。
これが後の自動化で超重要になる。
4. まず1言語で「ちゃんとした記事」を作る
4-1. 翻訳より先に原文を直す
原文がダメなまま11言語へ翻訳すると、ダメな文章が国際展開する。
世界進出するな、まず座れ。
最初に1言語を正本として仕上げる。
ここでは日本語を例にする。
4-2. 良い記事の最低条件
- 何の話かタイトルで分かる
- 冒頭で読者の疑問に答える
- 見出しだけ読んでも流れが分かる
- 難しい言葉はすぐ説明する
- 具体例がある
- 数字・日付・固有名詞を壊さない
- 事実と意見を混ぜない
- 必要な出典がある
- 個人情報がない
- 同じ説明を何度も繰り返さない
- 「AIが書いた感」のあるテンプレ文章を減らす
4-3. ネタは「意味を強くするため」に使う
笑わせることだけが目的ではない。
たとえば、
原文が壊れたまま12言語化するのは、傾いた家を11軒コピーするようなもの。
これは笑えるし、意味も分かる。
逆に、本文と関係ないギャグを5行入れて読者を迷子にしたら、ただの道路工事中の大道芸である。
5. 翻訳前にQA――先生の赤ペンを自動化する
5-1. 「AIが書いた」と「完成した」は別
AIが文章を出力した瞬間は、提出しただけ。
合格ではない。
最低限チェックする。
- タイトルと本文が一致
- 事実が変わっていない
- 日付・金額・単位が正しい
- URLが実在
- 引用・出典が壊れていない
- MarkdownやHTMLが壊れていない
- 見出し階層が変ではない
- 個人情報が残っていない
- 危険な断定がない
- 同じ内容の重複記事になっていない
5-2. 検査結果を「証拠」として残す
良い自動化は、
チェックしました！
だけでは弱い。
残すべきは、
- 対象記事ID
- 元の指紋
- 修正版の指紋
- QA結果
- 何を直したか
- どのルールで合格したか
である。
「宿題やった？」
「やった！」
ではなく、ノートを出せ方式だ。
5-3. 1件の失敗で工場全体を止めない
100記事中1記事だけ壊れていたら、
- その1記事は保留
- 理由を保存
- 次の記事へ進む
とする。
1個のネジが落ちたから工場全館停電、はやりすぎ。
6. 12言語へ展開する――翻訳は「コピー」ではない
6-1. 12言語を固定する
例として、
ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de
のように最初から固定する。
途中で「やっぱり英語だけ別ルール」などを増やすと、URL、QA、sitemap、hreflang、内部リンクがバラバラになる。
6-2. 各言語は別ページ・別URL
多言語サイトは、言語ごとにURLを分ける。
例：
/ja/articles/...
/en/articles/...
/ko/articles/...
そして「同じ記事の別言語版ですよ」と hreflang で伝える。
6-3. 既存翻訳を捨てない
毎回全部翻訳し直す必要はない。
- 現在の日本語と対応している翻訳 → 再利用
- 日本語が変わって古くなった翻訳 → その言語だけ更新
- そもそも無い翻訳 → 新規作成
これだけでコストも事故もかなり減る。
6-4. 日本語の語順をコピーしない
翻訳は単語置換ではない。
各言語で、
- 自然な文の長さ
- 見出し
- 接続
- 冗談
- アンカー
- 説明順
を調整する。
「意味を同じにする」と「形を同じにする」は別だ。
6-5. 言語ごとにQAする
英語が合格したからタイ語も合格、ではない。
記事ID × locale 単位で確認する。
1言語だけ失敗したら、その1言語だけ保留にできる構造が強い。
7. 内部リンクとハブで「道路」と「案内所」を作る
7-1. 内部リンクは適当に増やさない
Googleも、リンク文字は具体的で、リンク元とリンク先の両方に関係するものを勧めている。
「こちら」「詳しくはこちら」だけでは、読者は行き先が分からない。
良い例：
レチノール初心者は「濃度の選び方」を先に読むと迷いにくい。
悪い例：
詳しくはこちら。
道路標識に「どこか」と書いてあるようなものだ。
7-2. リンクを種類分けする
おすすめは最低でも次の5種類。
ハブ構造リンク
総合案内所から子記事へ行く道本文リンク
文章中で自然に補足記事へ行く道関連記事
読み終わった後の次の候補言語切替
同じ記事の別言語版へ行く道パンくず
サイトの階層を戻る道
これを全部同じ「リンク」として処理すると、ルールが衝突する。
7-3. 内容リンクは同じ言語へ
日本語記事から関連情報として英語記事へ勝手に飛ばさない。
同じ内容の英語版へ切り替えるのは「言語切替」。
別の記事へ進むのは「内容ナビゲーション」。
この2つを混ぜない。
7-4. ハブ記事は「リンク置き場」ではない
ハブ記事は総合案内所。
良いハブは、
- このテーマで何が分かるか
- 初心者はどこから読むか
- 選び方
- 使い方
- 比較
- トラブル
- 詳細記事
を整理する。
子記事20本のURLを縦に置いただけなら、駅員のいない駅に路線図だけ貼った状態だ。
7-5. 新規ハブより「既存記事の昇格」を先に見る
似た総合記事がすでにあるなら、それをハブへ育てる。
何でも新規作成すると、
「初心者向け完全ガイド」 「総合ガイド」 「全部わかるガイド」 「完全まとめ」
が同じテーマで殴り合いを始める。
サイト内SEOバトルロイヤル開催である。
7-6. 機械候補＋意味の最終確認
大規模サイトでは、文章の意味、リンク構造、実際のユーザー移動を使って関連記事候補を作る例がある。
ただし、候補を出す機械と最終判断を分ける。
AIには、
- なぜ関連するのか
- どの検索意図が共通か
- 重複リスクは何か
- 既存ハブで代用できないか
まで出させる。
8. 自動工場は「時刻」ではなく「状態」で動かす
8-1. スケジュールは目覚まし時計
たとえば、
- 02分：ハブ
- 07分：日本語
- 27分：翻訳
- 37分：内部リンク
- 58分：公開
のように時間をずらしてもよい。
でも、
27分になったから日本語は完成しているはず！
は危険。
時刻は「起きろ」の合図でしかない。
8-2. 前工程のハンコを見る
翻訳を始める前に、
- 日本語は最新版か
- QA済みか
- 記事IDは一致するか
- 指紋は一致するか
を見る。
内部リンク前には、
- 翻訳はcurrentか
- URLはcurrentか
- 品質QA済みか
を見る。
公開前にはさらに、
- 本文
- 翻訳
- リンク
- canonical
- hreflang
- sitemap
- 検証結果
まで見る。
8-3. 完了トークンを使う
done=true だけでは弱い。
「何を元に完了したか」を含むハンコを作る。
たとえば、
記事ID
+ 言語
+ 本文の指紋
+ URL
+ ルール版
+ 前工程のハンコ
からtokenを作る。
上流が変わればtokenも変わる。
だから古い下流処理を自動で「古い」と判定できる。
8-4. CASで同時編集事故を防ぐ
AさんAIとBさんAIが同じ記事を同時に見たとする。
Aが先に更新した後、Bが古い版を元に上書きするとAの仕事が消える。
そこで、
「今も私が読んだ版と同じなら書き込む」
という条件付き更新を使う。
違っていたら再取得。
これがCASや条件付き更新の考え方。
廊下ですれ違ったAI同士が、互いの宿題を消しゴムで消さないための仕組みだ。
8-5. 途中保存する
50件処理するなら、5件ごとなどでチェックポイントを残す。
途中で落ちても、
0件目からやり直さず、 20件目から再開できる。
「ゲームはセーブしましょう」という、文明が数十年前に発見した強い技術である。
9. 公開は「GitHubに入った」では終わらない
9-1. 公開には段階がある
たとえば、
記事完成
↓
翻訳完成
↓
内部リンク完成
↓
検証
↓
公開許可
↓
デプロイ
↓
本番HTML確認
↓
公開確認済み
とする。
9-2. 未完成言語を無理に公開しない
日本語・英語・ドイツ語が完成、韓国語だけ古い。
このとき、
- 韓国語だけ待つ
- 他の公開可能言語はポリシー次第で進める
という単位管理ができると強い。
「12人の遠足で1人靴ひもを結んでいるから学校そのものを閉校」はやりすぎだ。
9-3. SEOの基本情報も検査する
公開前に、
- title
- description
- canonical
- hreflang
- sitemap
- robots/indexability
- 構造化データ
- 404/redirect
- 内部リンク
を確認する。
多言語では特に「別言語URLの組み合わせ」を間違えやすい。
9-4. 本番ページを実際に見る
GitHubにcommitがある。
buildが通った。
deploy成功。
それでもまだ終わりではない。
実際のURLを取得して、
- HTTP 200か
- 最新本文か
- 正しい言語か
- title/metaが正しいか
- canonical/hreflangが正しいか
- リンクが壊れていないか
を見る。
弁当を作って玄関に置いたから「配達完了」と言うな。相手の家まで届けろ。
10. 100点の完成像と比べて、自分で直るサイトにする
10-1. 毎回QCループを回す
自動監査は、
観測
↓
採点
↓
差分を見つける
↓
原因を分ける
↓
安全に直す
↓
もう一度検査
↓
再採点
にする。
これが記事工場の心臓。
10-2. 100点を「数字遊び」にしない
たとえば、
- 壊れたリンク1件
- 別言語への誤リンク1件
- 古い翻訳をcurrent扱い
- 存在しないハブmember
- 二重書き込み
- 検査結果の捏造
が1つでもあれば、加重点数が100でも100点禁止。
これをハードゲートと呼ぶ。
10-3. 同じ事故が起きたら「仕組み」を直す
リンクが壊れた。
1回目： リンクを直す。
2回目： また直す。
3回目： また直す。
これは保守ではなくモグラ叩きである。
再発したら、
- ルール不足？
- 検査不足？
- 状態管理不足？
- 同時更新対策不足？
- スケジュール衝突？
- 外部サービス障害？
まで分類する。
必要ならvalidatorやtestを追加する。
つまり、
不良品を直す
から
不良品が出にくい工場へ変える
に進む。
10-4. 100点でも監視を止めない
今日100点でも、明日記事が増えれば98点になるかもしれない。
それでいい。
監視ルーティンが、
98 → 100
へ戻せばいい。
100点になったから警備員をクビにするのは、泥棒がいなかったから鍵を捨てる理論である。
30秒で分かる全体図
人間
「読者にとってこういうサイトにしたい」
↓
100点のあるべき姿・禁止事項
↓
AIが日本語記事を作る
↓
QA・証拠保存
↓
11言語へ展開
↓
各言語QA
↓
内部リンク・ハブ
↓
状態・指紋・token確認
↓
検証
↓
公開許可
↓
本番反映
↓
実URL/HTML確認
↓
読者行動を計測
↓
100点との差を監査
↓
安全に修正
└────────→ また回る
AI記事サイト事故あるある10選
1. 「記事100本できました！」→同じ話が30本
記事数を目標にした結果。
2. 原文が間違っていた→12言語すべて間違った
国際的事故。
3. 翻訳はある→でも古い
ファイルの存在とcurrentは別。
4. 日本語記事から英語関連記事へ突然ワープ
言語切替と内容リンクを混ぜた事故。
5. ハブを作りすぎる
案内所の隣に案内所、その隣にも案内所。
もはや目的地が案内所。
6. 「こちら」を内部リンクにしまくる
標識が全部「こっち」。
どっちやねん。
7. 2つのAIが同じ記事を同時上書き
CASなし工場の定番事故。
8. 50件処理予定→1件成功して「完了」
算数からやり直し。
9. GitHubに入った→公開済み扱い
まだ倉庫です。
10. 監視で異常発見→怖いのでルーティン停止
火災報知器が鳴ったので火災報知器の電源を抜くスタイル。
最小チェックリスト
設計
- ☐ 読者の目的を定義した
- ☐ 100点のあるべき姿を書いた
- ☐ 絶対禁止事項を書いた
- ☐ 記事にstable IDがある
- ☐ localeを別軸で管理する
- ☐ 本文の指紋を記録する
記事
- ☐ 原文QAがある
- ☐ 個人情報除去がある
- ☐ 事実・数字・URLを保護する
- ☐ 具体例がある
- ☐ AIテンプレ臭を減らす
多言語
- ☐ 各言語を別URLにする
- ☐ hreflangを管理する
- ☐ current原文との対応を記録する
- ☐ 古い言語だけ更新できる
- ☐ localeごとにQAする
- ☐ 内容リンクの別言語fallbackをしない
内部リンク・ハブ
- ☐ 本文リンクとハブ構造リンクを分ける
- ☐ 具体的なアンカーを使う
- ☐ orphanを監査する
- ☐ broken/self/duplicate/cross-localeを監査する
- ☐ 既存記事のハブ昇格を先に検討する
- ☐ 重複ハブを監査する
自動化
- ☐ 時刻だけで次工程へ進めない
- ☐ state/SHA/tokenを確認する
- ☐ claim/CASがある
- ☐ 途中保存できる
- ☐ 同一成功を二重計上しない
- ☐ 1件失敗で全体停止しない
公開
- ☐ validationを通す
- ☐ canonical/hreflang/sitemapを確認する
- ☐ 公開ポリシーを確認する
- ☐ deploy後に実URLを見る
- ☐ 本番HTMLを確認する
保守
- ☐ 100点との差を定期監査する
- ☐ hard gateがある
- ☐ 同じ事故は原因層まで直す
- ☐ 100点になっても監視を止めない
最後に：AIサイトで一番大事なのは、AIではない
結局、強いAI記事サイトは、
すごい文章生成AIを持っているサイト
ではない。
AIが間違えても、古くなっても、同時に動いても、事故を検出して正しい状態へ戻せるサイト
である。
人間が毎回1000記事を読むのは無理。
だから人間は、
- 目的
- あるべき姿
- 禁止事項
- 最後の責任
を持つ。
AIは、
- 作る
- 比べる
- 検査する
- 直す
- 記録する
を担当する。
そして証拠は、
- ハッシュ
- テスト
- Git履歴
- 実URL
- 実HTML
- 読者行動
に持たせる。
ここまで来ると、AI記事サイトは「ブログ」ではない。
小さな出版社＋図書館＋道路公団＋品質管理工場が、GitHubの中で24時間働いている。
文字にすると壮大だが、始まりは簡単だ。
まず1記事にIDを付ける。
次にQAする。
次に1言語増やす。
次にリンクを安全につなぐ。
次に状態を記録する。
それを1個ずつ積み上げる。
いきなり宇宙ステーションを建てなくていい。
ただし、コピー機100台を置いて「宇宙ステーション完成！」とは言わない。
それだけ覚えておけば、かなり強い。
