逆順ライティング:本文を先に書き、マークアップは最後に

多くの人は {a|b|c} の断片から書きはじめ、類語を積み上げれば記事になると期待します。しかしその進め方は、文法・サイトごとの事実・本当の話の流れが絡んだ瞬間に崩れます。直し方は、向きを変えるだけです。

思考モデル

パーサーと書き手は逆方向に進みます。

  • パーサーは内側から外側へ構文を展開します。まず内側の列挙、次に外側、そして順列、最後に変数の置換です。
  • 書き手は展開後の読める文から逆向きに構文へと設計していきます。

あなたはバリエーションを生成しているのではありません。きれいな記事を、エンジンが文法を壊さずに千回でも再生成できる形へと絞り込んでいるのです。

変わるのはそれだけです:

完成した読める文
→ 文法を束ねる
→ 安全な分岐境界を選ぶ
→ 変数を抜き出す
→ 構造のバリエーションを足す
→ 局所的な類語は最後に足す

類語化は最後の仕上げであって、最初の一歩ではありません。

逆順ワークフローの5ステップ

  1. 完成した文を普通の言葉で書く。波かっこも角かっこも変数もなし。読者に見せたい文そのものだけです。
  2. 束ねたままにすべき文法に印をつける。主語と述語。助詞と被支配語。連体修飾と名詞句。名詞と形容詞の一致。これらを分岐境界で切ってはいけません。
  3. 安全な分岐境界を選ぶ。境界は文法単位のあいだに置き、単位の内側には決して置きません。
  4. 繰り返す事実やサイト固有の事実は変数に抜き出す。サイトごと・製品ごと・記事ごとに変わるものはすべて %VariableName% へ移します。
  5. 構造のバリエーションが先、局所的な類語は最後。順列と省略可能な断片が本当の多様性を生みます。類語は、すでに安全になった文法上の隙間に入れる小さな最後の調整です。

書こうとしている {a|b} ごとに、実務的なテストがあります:

この断片だけを入れ替えたとして、格・一致・支配関係・冠詞・語順はすべて正しいままか?

すぐに「はい」と言えないなら、もっと長い句をひとつの分岐にまとめて束ねてください。

フェーズ0 — まず読める記事を書く

元テキストはまず記事であり、spintaxの入力であるのはその次です。読みやすさは常にテンプレートの都合に勝ちます。

ステップ1.普通の記事を書く

テンプレート化などしないつもりで、きれいで読める記事を書いてください。導入・つなぎ・背景・説明 — よい記事に必要なものはすべて入れます。あなたの声で。あなたのフックで。節と節のあいだに本当の流れを。

この段階でspintax向けに最適化しないこと。読者はひとりだと思って書きます。テンプレートは後からです。

ステップ2.テンプレート化できる領域を見つける

すべての段落が変わる必要はありません。書き上げた本文を通しで読み、候補になる具体的な領域に印をつけます:

  • 事実のリスト(機能、ユースケース、対応している連携先) — 要素を入れ替えたり一部だけ出したりできます。
  • 並列した説明(プランの段階、プラットフォームの能力) — 構造が似ている要素は順序を入れ替えられます。
  • 節の書き出しの文 — たいてい2〜3通りの言い換えが可能です。
  • サイトごとに変わる具体的な数値や事実 — 変数になります。

残りはそのままにします。導入・つなぎ・説明文・話の流れは、固定したほうが読みやすいのが普通です。そこをテンプレート化しても複雑さが増えるだけで、フットプリント対策としての実利はほとんどありません。

典型的な記事は、おおよそ読める固定テキストが60〜70%、テンプレート化する領域が30〜40%に落ち着きます。この比率が健全なテンプレートの目印です。

ステップ3.テンプレート化する領域を整える

印をつけた領域の中だけで、次の原則を適用します:

  • 文の独立性。順列にする領域の各文は、単独で成り立たなければなりません。「だからこそ…」「したがって…」「先ほど述べたとおり…」は禁物です — 順序が変わった瞬間に壊れます。
  • 並列したリスト項目。順列にする項目は同じ文法パターンに揃えます — 同じ構造、同じ文の形。並列した項目は入れ替え可能で、それこそ順列が必要とするものです。
  • 1文に1つの考え。考えは別々の文に分けます。それぞれが順列の要素になります。
  • 曖昧よりも具体。具体的な事実は、一般的な形容詞よりよいバリエーションを生みます。「リクエストは100 ms未満で完了します」は「速いです」よりずっと使えます。

記事全体のルール

これらはテンプレート化する領域だけでなく、記事のどこにでも当てはまります。

  • ブランド名の置きどころ。早い段階でブランド名を出し、以降は一般的な言い方(「このプラットフォーム」「この製品」)を使います。記事全体が、各段落にブランド名がなくても自然に読めるべきです。
  • 古びる手順を書かない。他社のUI(ウォレット、管理画面、外部連携)の手順書は書かないこと。頻繁に変わり、テンプレートごと古びます。そのツールが何をするのかを1〜2文で説明してください。
  • 節の長さ。<h2> の節は100〜250語、<h3> の節は50〜150語。約300語を超えたら分割します。
  • 埋め草とメタ発言を入れない。情報ではなく本文自体について語る文は削ります:「ちょっと見てみましょう…」「注目すべきは…」「この節では説明します…」。

執筆段階でよくある間違い

やらないこと理由代わりにすること
{a|b|c} の断片から始める 中身が存在する前に構文パズルを解こうとしています。 まず普通の記事を書く。構文は最後。
すべての段落をテンプレート化する 多様性を足さないまま読みやすさを壊します。 領域の約30〜40%をテンプレート化。語りは固定のまま。
語りの文を順列にする 「先ほど見たとおり…」は順序が変わると壊れます。 語りは固定。独立した事実だけを順列にする。
構造より先に類語を書く 形を考える前に文法を固めてしまいます。 構造が先(順列、変数)、類語は最後。
1文に3つの考えを詰めてから順列にしようとする 要素が重なり、並べ替えると意味不明になります。 順列にする領域では1文に1つの考え。

元テキストのチェックリスト

マークアップに進む前に確認します:

  • 記事が単独のページとして読める。
  • テンプレート化する領域が特定されている — 本文全体ではなく。
  • その領域の各文が単独で成り立つ。
  • その領域のリスト項目が並列になっている。
  • ブランド名は控えめにしか出てこない。
  • 他社UIの手順書がない。
  • 埋め草もメタ発言もない。
  • <h2><h3> の節が長さの範囲に収まっている。

すべてにチェックが入れば、元テキストは準備完了です。続く3本のガイドが、そのテキストをテンプレートに変えていきます:変数、順列、そして文法を壊さない類語化 — この順番で。


シリーズを続ける