AIで自分の文体を再現する。文体を仕様書とskillsに転換する方法

AIで記事や文章を書くと、下書きそのものは一瞬で出てきます。問題はそこから先で、公開できる状態にするまでに、私はいつも1時間ほどかかっていました。内訳のほとんどは「なんかこれじゃない感」の修正です。AIっぽい言い回しを見つけては直し、直した先でまた見つける、の繰り返しで時間を食ってしまった経験をお持ちの方は多いのではないでしょうか？

この記事では、そんなあるあるを解消し、AIを育て上げて自分の文体を忠実に再現する方法について解説します。

「なんかこれじゃない」の中身は、だいたい6パターン

毎回何を直しているのかをはっきりさせるために、Claudeっぽい言い回しの「あるある」のうち、私が個人的に嫌悪している６パターンを紹介します。

パターン例何が起きているか断定回避「これは、全体に効いてきます」指示語が翻訳調で、誰の判断なのかもぼやける言い換え反復「回転速度が、分析の質を決めます」の数段落後に「分析の質は、回転速度に依存します」語順を変えただけの同じ主張で分量を稼ぐ三連短文「色が違う。フォントが違う。レイアウトが違う。」同じ型の短文を3連打する対句のリズム平板な文長30〜40字の文がずっと続く一文の長さがそろいすぎて、読み心地が単調になるメタナビ文「ここからが本題です」記事の構成を司会していて、内容を話していない疑似体験談「深夜2時、ズレたテキストボックスを1pxずつ直していた」鮮明なのに固有性がなく、実話か創作か区別がつかない

あるある、で済めば気楽だったのですが、他人事ではありませんでした。こうしたパターンを検出する仕組みに自分のブログ全57記事を通したところ、いちばんスコアの悪い記事には、AIっぽさのフラグが26個ついていたのです。なんというか悪い病気に感染してたような気持ちになってきます。

AIで作ったものの微修正に時間が消えていく構造は、スライド資料を題材にした記事でも書いています。

問題はモデルの賢さより、毎回ゼロから書き始めること

最初に疑ったのは、モデルの賢さでした。ただ、どれだけ賢いモデルに乗り換えても、私がどんな言い回しを嫌って、どんな癖を自分の声として残したいのかは、モデルの側に存在しないわけで、問題はモデル選びではありませんでした。毎回ゼロから書き始めていることが問題なわけです。

長いプロンプトで文体を細かく指定する方法も、ある程度はは機能します。それでも品質のガチャは残りました。今回うまく書けても、なぜそう直したのかがどこにも残らないため、次の記事が同じ品質になる保証がありません。会話が長くなるほど、序盤に決めた基準はほかの指示に埋もれていきます。ラストワンマイルの手直しは、結局いつも人間に戻ってくるのでした。

そこで、良い文章の定義をAIとの会話の外に出して検品のためのシステムにするようにしました。NGな言い回し、OKの基準、残したい自分の癖を書いて固定します。AIの仕事は「センスで書く」から「基準と照合する」へ変えるということです。この置き換えの何が大きいかというと、手直しのたびに見つかった「直した理由」がファイルへ追記されていくので、これまで使い捨てだった修正の一つひとつが、次の記事にも使える資産に変わることです。仕様書と呼んでいるものの正体は、それだけです。

仕様書の実物は、指示書1枚と参照資料3枚

実際に運用しているskillsの構成もお伝えします。SKILL.mdという指示書が1枚あり、場面に応じて3種のスキル構成になっています。

スキル①には、書くための規則が入っています。 核になっている発想は、文章の「自然さ」を美的判断のままにせず、字数の規則へ分解することです。たとえば「30〜45字の中文を3連続させない」「うねる長文は1記事に1〜2本まで」といった粒度といった具合です。人間が読むと融通の利かない規則に見えますが、この形でないとAIは従えません。

ふわっと「リズムよく書いて」と頼んだ時点で、何がリズムなのかの解釈はモデル任せのガチャに戻ってしまうからです。

生成された文章の検品を受け持つのがスキル②で、検出をコストの安い順に3層へ分けています。 最初の層はスクリプトが担当し、機械的に検出できるパターンを走査してスコアを付けます。スコアの高い記事だけを、安価めなモデル（Sonnetを利用）による2層目の照合に回して、該当箇所を原文の引用付きで列挙させます。最後にFableという上位のモデルが、その判定の1〜2割を抜き打ちで監査する構えです。

特にこのような検品の段階では、「実行モデルを賢くするのではなく、賢いモデルで賢い仕様を作る」ほうが再現性が高くコストも節約できます。

スキル③は、仕様書そのものを試験する道具です。 仕様書に従わせた別のAIに同じ題材を書かせて、基準にしている文章と並べ、どちらが基準か盲検で当てられるかを確かめます。3回読んでも当てられなければ合格です。見分けがついたら、差分の仕分けです。人間が埋める領域の差はそのまま許容し、規約違反は規則を具体化して再テストに回します。規約にないのに読み心地で負けている差が見つかったときだけ、新しい規則として仕様書に足しています。

AIへの頼み方を「検品」「リライト」「新規執筆」に分ける

仕様書ができると、AIへの頼み方も3種類に分かれます。どの型にも共通するのは、一度に1つの仕事しか頼まないことです。

型1 検品は「修正はまだしない」まで込みで頼む

検品を頼むときの指示文は、いつも決まっています。「NGの該当箇所を、原文の引用付きで一覧にして。修正はまだしない」。検出と修正を同時に頼むと、頼んでいない箇所まで一緒に書き換えられて、どこが変わったのかの確認からやり直しになるからです。条件がもう1つあり、各NGにはOK側の定義を添えています。

例えば冒頭で紹介した短文の3連打（例　「色が違う。フォントが違う。レイアウトが違う。」）はNGでも、単発の短文は良い息継ぎとして許容すると言った感じです。その区別まで仕様に書くことで、正常な文までフラグが立ってしまうのを防いでいます。

型2 リライトは構成・事実・口癖に触らせない

2つ目の型では、「見出し・段落数・事実は変えない。NG箇所だけ直して、新しい情報を足さない」と縛りをかけます。自分の口癖は、たとえNGに見えても残す側です。丸ごと書き直させない理由は損得の計算で、差分が全文に散らばってしまうと、確認の手間が新規執筆と同じ量へ戻るからです。自分の記事をこの型で直したときは、検出フラグが24個から9個まで減りました。文章を上手にするというより、離脱の要因を減らす作業です。

型3 新規執筆は体験・比喩・実数を空欄にする

新しい記事を書かせるときだけは、検出でも修正でもない仕掛けを1つ足します。体験・比喩・実数の3つは、AIに生成させません。代わりに本文の該当位置へ、【体験: ○○】のような空欄マーカーを置かせます。人間スロットと呼んでいる決まりです。数は1記事に2〜4個、場所は冒頭・主張の直後・結びを優先します。コラムで差がつくのは現場の実話と実数の部分なので、そこは人間の担当として空けておきます。先ほどの「深夜2時」のような描写をAIに任せると、鮮明なのに誰の実話でもないドラマチックなのに空虚な文章ができあがってしまいがちです。

自分にとっての「よい」文章を育てる方法

検品とリライトを回していくうちに、次の壁に気づきました。減点をゼロへ寄せた原稿が、良い文章かというと違いました。出てくるのは「無難だが自分らしくはない文章」止まりです。ここから先へ進むには、「自分にとっての良い」を、AIが従える形で書いたOK基準が要ります。

OK基準の素材として一番使いやすかったのは、自分の過去記事でした。手応えのあった記事を3本選び、「文体・リズム・構成の観点で、共通する特徴を規則の形にして」と頼みます。出てきた規則を全部使うことはありません。「たしかにそれだ」と自分で思えたものだけを採用して、残りは捨てます。

素材は自分の記事に限らず、好きな文章からも取り出せます。ただし権利には配慮が要るので、自著や許諾済みの文章を優先し、好きな本を使うときも必要な箇所だけを個人の分析にとどめます。この分析で欲しいのは、「なぜ自分はこの文章を良いと感じるのか」の言語化です。だから抽出した規則からは作家名を外して、使う条件・使わない条件・検品方法の形へ書き直していきます。

このとき、AIの分析をそのまま信じない手順を挟みます。仮説には根拠になる引用を3か所ずつ付けさせ、「当てはまらない段落はないか」「題材のせいで出た特徴ではないか」と反証を促し、最後まで生き残った特徴だけを規則にします。生き残る仮説は多くありません。

規則として書くときの粒度は、あえて定量まで踏み込みます。「短文を効果的に使う」のような抽象度のままでは、AIは従えないからです。「うねる長文の直後は、25字以内の短文で受ける」まで具体化するといった具合です。人間の側も、ルールを守れたかどうかを確認できるようになります。ニュアンスの定量化は気が引けるものですが、曖昧なまま解釈をモデルに委ねるより、外した規則をあとから直せるほうがAIにとっては扱いやすいはずです。

仕様書そのものも、一度作って終わりにせず、運用しながら育てていくものです。私のブログには「よしなな」という口癖めいた言い回しが出てくるのですが、あるとき検品が、これを誤字として検出してきました。そこで保護リストに「これは私の声、触るな」と書き足しました。この繰り返しによって、仕様書は育っていきます。何をOKとし、何をNGとし、どの癖を自分の声として残すのかという判断の履歴が、まるごと次回の基準になるものですから、数か月後に読み返したときには、自分が文章の何を大事にしているのかがそのまま読める、ちょっとした文体観の資料に変わっていく資産になっていくはずです。

書籍もスライドも、同じ仕組みの上で回る

書籍のように長いものを書くときは、原則を1つ足します。1つの会話で丸ごと書かないことです。読者・主張・目次・文体という全体ルールは、1つのファイルに固定します。章ごとの原稿は別ファイルへ分けて、どの章を書くときも共通ファイルの方を必ず読ませます。用語のゆれ、重複、章のあいだの矛盾は、全章がそろった最後にファイルを横断して検品する方が、AIは得意なはずです。書き上がった章が独立したファイルとして残るので、会話が長くなって基準が埋もれる問題も避けられます。置き場所は、初心者ならフォルダ管理で十分です。変更履歴を残したくなった段階で、GitHubへ載せれば足りるのではないしょうか？

余談ですが、このような考え方自体は、文章に限らず、別の表現や生成物においても同じ仕組みを適応させることが可能です。

例えば、スライドをAIに作らせることを考えましょう。

「1枚につき主張は1つ」「タイトルで結論を言い切る」「強弱はサイズと太さだけ」という決めごとをルール化していくわけです。

構成案と手元の実物を渡して、同じ型で全体を組ませました。文体のために始めた仕組みが、書籍にも、提案書や議事録にも、スライドにまで届いたことになります。

スライド生成をスキルへ育てていく過程は、実物のファイルを添えた記事で公開しています。

まとめ

ここまでの仕組みを、最初から全部丸ごと再現せずとも、部分的に活かすことが十分できると考えています。

1. 仕様書1ファイルと原稿1本をチャットに添付して、まず検品だけを試す
2. 慣れてきたら、プロジェクトの参照ファイルやskillsに常設して、毎回自動で読ませる
3. 書籍のような長いものは章を分けて、GitHubなどのバージョン管理ツールで履歴を残し、最後に横断で検品する

最初に作る仕様書は、規則が3行しかなくても成立します。「この言い回しは使わない」を3つ書いて検品を頼むだけで、AIの指摘はみなさんの基準に変わるからです。

この記事自体も、公開前に同じ仕様書の検品を通しています。それでも手直しはゼロになりません。体験と実数を埋める部分を、意識して人間の側へ残しているからです。プロンプトが1回の依頼で終わるのに対して、仕様書とskillsは、直した理由を覚えたまま次の記事へ持ち越して育てることができます。プロンプト一発でうまく書かせる方法を探すより先に、自分の文章の作り方を仕組みにしてしまうというアプローチが意外に有効かつ結果として近道となると考えます。

少しでも参考になれば幸いです。