LLMで書く方法

2つの単純なルールで、LLMに文章を殺菌消毒させ、コーンシロップで満たすのではなく、削ぎ落として改善させる方法。

文章について書くのは厄介だ。自慢に読こえる。自分は上手く書けるとほのめかしているわけだから。実際に上手いかもしれないし、そうでないかもしれないが、インターネットには君の文章はクソだと考える評者たちが必ず大勢いる。私も誰と同じように虚栄心が強く不安も抱えているので、これを書くのは妙に不愉快だった。それでも腰を据えて書いた。この助言は重要で、反論しにくく、そして率直だからだ。

読者はLLMが書いた語を兆分の一の精度で検出する。どれだけ手をかけてざらつかせ、人間らしく見せようと、LLMが生成した文章は多くの読者にとってwritingではなくoutputだ。だからまず悪い知らせから。君は自分のために書かねばならない。

だがLLMは依然として極めて有用だ。ただし代筆者ではなく、テキストエディタとして使う必要がある。だから私の方法の第一歩はこうだ。自分の記事を書き上げる。第二のステップで、それを良いモデルに食わせ、欠点を探させる。

だがそのやり方を説明する前に、まず理解しておくべきルールが2つある。これらはLLMの浸透を食い止める。その浸透は君を表現と出力の間の不気味の谷へ押し込み、読者を君から離れさせる。

ルール1：LLMが提案した語は、一つも使ってはならない。

このルールを破れば厄介なことになる。理由はこうだ。フロンティアモデルは好まれる言い回しを選ぶ能力がほとんど超自然的に高い。それはほぼ彼らの本領だ。モデルが提案するものの問題は微妙だ。こう考えてみよう。フロンティアモデルはあるモードに嵌まっていて、何を書いても雑誌の見出しのようになる。見出しは良いものだが、ある人が記事の中に見出しを何十も詰め込んでいたら、その人物には少し問題があると君は思うだろう。

だから私は、知的自己防衛装備としてこのルールを採用すべきだと考えている。LLMが提案した具体的な言い回しは一切使用禁止。このルールは厳格に守れ！前提そのものがこうだ。君はフロンティアモデルがどんな手口で君の記事をVelveetaチーズに変えるか、信頼できる形で見分けられない。たとえその語が気に入っても、たとえ元の表現より優れていると確信しても、LLMが生成したフレーズは一律失格だ。

ルール2：励まさせない

LLMは影響力攻勢によっても君の記事に感染する。こちらの問題はずっと微妙で、損害もそれほど明白ではないが、同じように記事を悪くする。そうなったら、LLMなど最初から使わなければよかったということだ。

問題はこうだ。どんな記事でもLLMに渡せば、「that's gold, Jerry!」と返ってくる。だがそれは君が聞く必要のある言葉ではない！

初稿ではほとんどの段落が酷く、主題の運びはちぐはぐで、少なくとも750語は余分だ。それなのにモデルは全体の構成を褒める。次に段落とつなぎを褒める。次に語の選び方と比喩を褒める。ポップカルチャーのネタ。彼らは酷い！全部酷い！聞くな！

これがどう君を陥れるか。初稿にあった衝動のすべてを君は倍加させる。だが普段ならそんなことはしない。書き直し、考え直し、段落を差し替える。そうした考え直しこそが君の個人的な声の耐力壁だ。読者はどこがおかしいか言えないが、君に人工香料の匂いを感じ取る。

数年ほど、私はテキスト編集のプロンプトを書くたび、自分は著者ではなく、オンライン刊物の編集者で原稿を選別していると嘘をついていた。効果はあったが、モデルはたいてい力みすぎ、私の「刊物」の「目標」に過剰適合した。

だから今のところ私の最良の実用上の助言はこれだ。モデルに励ましの言葉を禁じ、賛辞には高度の警戒を保て。

ではこいつらに何ができるのか？

問題に印をつけるのは非常に得意だ。君の問題は山ほどある。機械的に見つけ出すこともできるが、それは退屈で骨の折れる作業だ。モデルは疲れない。だからこうした問題の察知において、彼らは君より優れている。

• 受動態を濫用している（あるいは、LLMの言い分を鵜呑みにすれば逆かもしれない——足りなすぎる）。動詞を名詞化している。行為を隠している。同じ言い回しと同じ語を繰り返し使っている。
• 草稿のあちこちに「very」「unfortunately」「really」「actually」が散らばっている。作業台にこびりついたおがくずのように。
• ほぼ確実に2、3の段落が素早く別の場所へ移せて、移せば明瞭さが即座に上がる（この種の修正は本当に、確かに、とても心地よい）。

君が私のようなプログラマなら、こうした修正のための設計図が載った本を望むだろう。散文版のC Interfaces And Implementationsだ。Hansonが最悪のプログラミング言語に対してやったことを、散文に対してやる本だ。そして——その本は実在する。Style: Lessons In Clarity And Graceといい、神に誓って言うが、テキスト編集をJavaプログラミングに変えてくれる。同じ退屈さ、同じ効き目だ。私はRichard Gabrielからこの本を知ったが、驚いたことに、私の知るプログラマで机に一冊置いている者はいなかった。 だから『Style』か、それに類する本を読め。読みながらノートを取れ。モデルに与えるプロンプトの一覧を作り、それを何度も何度も草稿に通せ。 この方法でかなり先まで行ける。

1. モデルに自分の文章の問題を挙げさせる。
2. 問題ごとに、その段落（あるいは文、節）を書き直す。
3. 元の文と新しい文を一緒にモデルに渡し、どちらが良いか尋ねる。

厄介なことに、ここでルール2の変種にぶつかる。注意しないと、モデルは君が今しがた何かを書き直したこと、そして新版本の方が良いと聞きたいのだと察する。だから選択肢は、君の編集過程を知らないモデルに渡せ。 タブを切り替え続けるのに、そして「自分は著者ではなく、おそらくは有望かもしれないが酷いかもしれない学生を助ける、親切だが厳しいライティングコーチだ」とモデルに納得させるのに、ついに嫌気がさしたあと、私はこれを代わりに管理してくれる小さなソフトをでっち上げた。以下の冒頭プロンプトがよく効く。 「ライティングワークショップツールを作る。まず骨組みを組もう。Python、インタラクションはHTMX、バックエンドはSQLite、フロントエンドはTailwind、ローカルビルドで、CDNは使わない。本当に優れた散文エディタ、Notion風。ハイライトに対応（複数ラウンドの編集をする）。Genius風のサイドバーコメントを、ハイライトした内容に対応させる。提案の間を前後に移動できるようにする。複数ドキュメントに対応、改訂を追跡、ユーザーが重要な改訂に印をつけられるようにする。ここまでやって、それから本当に欲しいものを伝える。」

次に、思いついた編集プロンプトのリストをそいつに渡し、Codex、Claude、Antigravity の CLI で1つずつ実行させる。ここでお前が考え出すものは、必ず俺のものより良くなる。自分で考え出したものは、誰にとっても他人のものより自分のもののほうが良いからだ。 だから、LLM に言葉を選ばせるな。それから、初稿が実際より優れていると錯覚させられないよう気をつけろ。そして、最も退屈な作業はすべてモデルに外注しろ。お前の声はそのままに、仕事はより速く、より良く、より楽になる。 最後に一つ。モデルが出した校正の提案を全部そのまま受け入れるな。これは2つ目のルールの帰結だ。1分前、俺はこの記事を GPT5 に食わせた（「これは俺が書いたんじゃない」）。すると全体が20%長いと言ってきた。おそらく正しい。だが俺は直さない。俺はこういうやつで、自分であり続ける。