AIの文章が微妙だったとき、最初に思いつくのは「もっと賢いモデルに替える」かもしれない。
でも、モデルの横に異常に細かい編集長を置く方法もある。
しかも、その編集長は寝ない。タイトルを見て、見出しを見て、本文との約束を照合し、専門語を探し、同じ留保を3回言っていないか数え、12言語を確認し、ダメなら該当箇所だけ書き直させる。
TypeScriptは文章を書かない。だが、「良い文章になるまで帰さない編集部」は作れる。
1. 5秒で結論：文章力をコード化するのではなく、編集工程をコード化する
結論はシンプルだ。
AIの文章品質は、共通ルールを増やすだけでも改善する。ただし本当に強いのは、ルールをプロンプトへ足すことではなく、生成→検査→意味評価→部分修正→再検査までを工程化することだ。
OpenAIはAIシステムの評価について、「何が良いかを定義する→測る→改善する」という循環を勧めている。実際の出力で新しい失敗を見つけ、それを次の評価基準へ加える考え方だ。[1]
文章工場に置き換えると、かなり製造業っぽい。
不良が出る。原因を見る。検査項目を足す。再発を止める。
「今回うまく書けた」で終わらず、次の100本にも効く改善に変えるのがポイントになる。
2. TypeScriptに文才はない。あるのは工程管理能力だ
ここは勘違いしやすい。
TypeScriptへ「結論を先に」「見出しを分かりやすく」と書けば、TypeScriptが文章を理解するわけではない。
コードが得意なのは、たとえば次だ。
- H1が2個ないか
- titleとog:titleが大きく食い違っていないか
- 必須の12言語がそろっているか
- URLや日付の形式がおかしくないか
- 同じ見出しが重複していないか
- 禁止語や未説明の略語候補がないか
- 評価結果が基準未満なら再生成へ戻す
一方で、
- この導入は面白いか
- この比喩は残すべきか
- この見出しは文脈なしでも意味が通るか
- タイトルが本文の本当の問いを表しているか
- 研究の説明が元の面白い観察を食っていないか
のような判断は、文字数や正規表現だけでは弱い。
そこで、機械的な検査はTypeScript、意味の判断はAI編集者と役割を分ける。
3. 「プロ編集者」は一人ではなく、役割に分解すると実装しやすい
「プロの編集者みたいに直して」は便利だが、システムとしては曖昧だ。
実装するときは役割を分けると強い。
構成編集
読者が何を知りたいか、結論が遅すぎないか、章の順番が自然かを見る。
コピー編集
タイトル、導入、言葉の強さ、読みやすさ、重複を整える。
事実編集
数字、日付、引用、断定の強さ、出典との一致を見る。
検索入口の編集
タイトル前半だけで何の記事か分かるかを見る。
Google Search Centralは、検索結果のタイトルはページ内容と検索クエリとの関連性を素早く理解するための重要情報だと説明し、具体的で簡潔なタイトル、キーワード乱用の回避、ページごとの固有化を勧めている。[2]
NN/gのユーザビリティ研究も、Web利用者は文章を逐語的に読むよりスキャンしやすく、リンクや見出しの先頭に情報量の高い言葉を置く重要性を示している。[4][5]
つまり「SEO魔法の呪文を左端に置く」のではない。
読者が0.5秒で自分向けの記事だと判断できる入口を作るという話だ。
4. Before / After：ネタを消すのではなく、入口から退避させる
たとえば、こんなタイトルがあったとする。
変更前
名字は悪くない、辞書が事故っている――Manko・Wang・Chinから見る「外国語にするとヤバい名前」
キャッチコピーは強い。しかし最初に見えるのは「名字は悪くない」で、記事の主質問が後ろにいる。
そこで、こうする。
変更後
外国語にするとヤバい名前――Manko・Wang・Chinから見る「名前の多言語事故」
そして本文1行目へ、
名字は悪くない。辞書が事故っている。
と戻す。
これならネタは死なない。むしろ、読者が「何の話か」を理解したあとに殴ってくるので強い。
Googleも、検索エンジン向けの量産を目的にするより、人にとって役立ち、タイトルが内容を適切に要約するコンテンツを重視するよう案内している。[3]
5. 良い共通ルールは「文章を同じ形にする」のではなく「同じ事故を防ぐ」
ルールを増やせば無限に良くなるわけではない。
たとえば全記事に、
- 必ず3文
- 必ず疑問形見出し
- 必ず例を2個
- 必ず結論から同じ言い回しで開始
と固定すると、今度は全部の記事が同じ顔になる。
良いルールは、型を押し付けるより失敗を禁止する。
たとえば、
- 主質問がタイトル後半へ埋まらない
- 本文にない約束をタイトルへ足さない
- 同じ留保を何度も言わない
- 専門語を説明なしで投げない
- 見出しだけ読んでも意味が分かる
- 研究は元の観察を補強し、主役を奪わない
- 12言語を日本語の語順で直訳しない
というルールだ。
自由を残しながら、不良だけ止める。
6. P0 / P1 / P2に分けると、文章がルール地獄になりにくい
文章ルールは優先順位を分けた方がいい。
P0：絶対に落とせない
- 事実、数字、日付、引用を壊さない
- タイトルと本文が同じ問いに答える
- 12言語を欠落させない
- 個人を特定できる情報を公開しない
- 本文にない断定を作らない
P1：かなり重要
- 結論を早めに出す
- 1段落1テーマを基本にする
- 専門語は普通の言葉で先に説明する
- 見出しだけでも流れが追える
- 重複と無駄な留保を減らす
P2：記事の味
- ネタ
- 比喩
- 会話っぽさ
- 文のリズム
- 強いキャッチコピー
P0を守るためにP2を全部殺す必要はない。
ここを分けないと、「品質管理した結果、すべての文章が役所の注意書きになりました」という悲劇が起きる。
7. 強いのは「ルール集」ではなく、失敗から育つ評価ループ
OpenAIのevalsの考え方で重要なのは、評価表を一度作って終わりではない点だ。実際の出力から新しい失敗を見つけ、その失敗を次の評価へ追加していく。[1]
文章ならこうなる。
- AIが原稿を書く
- 機械検査を通す
- AI編集者が意味を読む
- 不合格理由を構造化して返す
- 不合格箇所だけ直す
- もう一度検査する
- 新種の失敗なら恒久ルール候補へ送る
このとき重要なのは、毎回全文を書き直さないことだ。
タイトルだけ悪いならタイトルだけ直す。見出しだけ意味不明なら見出しを直す。全文再生成は、直っていたところまで別の文章に変えてしまう。
8. TypeScriptで書くと、イメージはこのくらいでいい
const draft = await writeArticle(input);
const hardCheck = runDeterministicChecks(draft);
const editorial = await semanticEditor.review(draft, rubric);
if (!hardCheck.ok || editorial.hasCriticalIssue) {
const revised = await reviseOnlyFailures(draft, {
hardCheck,
editorial,
});
return verifyAgain(revised);
}
return draft;
大事なのはコードの格好良さではない。
runDeterministicChecksには機械で確実に判断できるものを入れる。
semanticEditor.reviewには意味を読まないと分からないものを入れる。
そしてreviseOnlyFailuresで、失敗理由を修正指示へ変換する。
この分業ができると、「プロンプトに200行追加した謎の巨大呪文」より管理しやすい。
9. 自動化しても残る弱点：評価AIも間違える
AI編集者も神ではない。
- 面白い文を「冗長」と誤判定する
- 少数派の文体を不自然と判定する
- 文化的なネタを12言語で平板化する
- 自分で書いた文章を自分で高評価する
- 事実確認を、もっともらしい文章評価で代用してしまう
だから、意味評価の点数は「真実」ではなく検査信号として扱う。
事実は一次情報や公式情報へ戻す。公開リスクが高いものは人間確認へ送る。複数言語は各言語として自然かを見る。
「AIがOKと言ったのでOK」は品質管理ではない。
10. 100本、1000本で効いてくるのは、文章力より「改善の複利」
手書きなら、良い編集者が一度直して終わることも多い。
工程化すると違う。
ある記事で、
キャッチコピーが主質問を押しのけた
と分かったら、次から全記事で検査できる。
別の記事で、
「ただし」が4回続いて結論が溶けた
と分かったら、それも評価項目にできる。
さらに、
日本語では自然だが、ドイツ語では逐語訳臭が強い
という失敗までロケール別の基準にできる。
一つの失敗が、一つの記事の修正で終わらない。
失敗が編集資産へ変わる。
ここが一番強い。
11. 結論：作るべきは「文章ルールの山」ではなく、眠らない編集部
AIの文章品質を上げる方法は、モデル更新を待つことだけではない。
TypeScriptで、
- 機械で判定できる品質を固定し
- AIに意味を読ませ
- 不良だけを書き直させ
- 新しい失敗を評価基準へ足し
- 12言語でも同じ編集思想を維持する
という流れを作れば、同じモデルでも完成品は変わる。
要するに、TypeScriptへ文才を移植するのではない。
プロ編集者の「そこ、読者は分からん」「そのタイトル、何の記事やねん」「そのネタは消すな、場所を変えろ」を、再現可能な工程にする。
それがAI文章工場の本体である。
