私は現在、「お一人様アドベントカレンダー」と題し、12月1日から25日まで毎日ブログ記事を執筆するという挑戦に取り組んでいます。SNSでアドベントカレンダーの話題をよく見かけたことで、私も書きたくなってしまったのです。それも、一つと言わずたくさん！ 時間なら余らせていますので、ひたすら書くだけです。
毎日記事を書き続けるとなると、行き当たりばったりでは続きません。ルールを作り、タスクを管理し、ネタの探し方を考える。いわば量産体制が必要になります。量産と言うと少し嫌な響きがありますが、実際には「考え方を体系化して負荷を下げる」というだけの話です。
途中までではありますが、この挑戦を通じて、私にとって最も効率的な執筆フローが見えてきました。それは、「人とAIの作業分担」に焦点を当てた方法です。
- とっちらかってもいいのでとにかく書きまくる。
- 最低限意味が通る文章のリストにする。
- LLMに投げ付け、良くも悪くも平凡な記事にする。
- 解釈違いを起こす。
- 手直しをする。
この記事では、私が辿り着いた効率的な記事執筆フロー、その人間とAIの作業分担についてまとめます。
マインドマップは「思考分解」のツール
記事執筆において私が特に役立つと感じているテクニックは、マインドマップです。とはいっても、私が書いているものは、一般的な「単語を線でつないだだけの図」ではなく、実態としてはアウトラインに近いものです。詳しくは昨日の記事で解説しました。
思考を、Work Breakdown Structureのように「浮かんだ考えに依存している前提となる考え」まで掘り下げて書き出しておくと、最終的に意味の通った記事本文を組み上げるときに格段に楽になります。
上記記事では、マインドマップをプレーンテキストで書いていることについてまとめました。1行に1つの内容を書き、インデントで親子関係を示すだけ。この形式は気楽で、どんどん書き込んでいくことができ、とにかくたくさんの情報をアウトプットする必要がある場面で非常に役立ちます。最初から完璧な文章を書こうとは目指さないというのが重要です。
とはいえ、このマインドマップで得られるのは「とても短い文章が最低限の親子関係で列挙されたもの」に過ぎません。この断片を継ぎ接ぎする作業が必要になります。この作業はとても地味ですが、最終的な記事の品質に直結するため手を抜くことはできません。どうすれば省力化できるでしょうか？
LLMに「平凡なたたき台」を生成させる
この省力化を実現するのがLLM——ChatGPTやGeminiなどです。テキストで書いたマインドマップを文章のリストとして最低限整えた上でLLMに渡すと、LLMは素早く記事の形に整えてくれます。この現代、情報の加工は案外いくらでもできます。加工以外の部分に人間が注力するのが、最も効率的と言えるでしょう。
LLMのたたき台作りのスピードは、人間より圧倒的に速いです。そして、LLMが出力するのは良くも悪くも「平凡な記事」といった形式。これから自力で書き直していく必要があるわけですが、この平凡さはむしろ補助線として役立ちます。最初から自力で本文を書いてしまうと、どうしても自分の癖が強く出てしまい、自分の執筆能力で頭打ちになってしまうためです。
- 最低限文章として整えた下書きをLLMに渡す。
- 最低限記事として整ったものを得る。
- いかにもLLM的な太字・引用符などの無駄な装飾をエディタの一括置換で消し去る。
- さらなる精査をしていく。
この流れで作業を進めます。
LLMが得意ではないフェーズ
一方で、「ネタについての知識を深めるフェーズ」ではLLMはあまり役に立たないというのが私の雑感です。
LLMの文章生成はどうしても遅く、特に長文になると待ち時間が長くなってしまいます。また、そもそも会話が面倒です。こちらから質問して返答を読むより、Web検索上位の記事をドカ食いする方が速いのです。その方法なら、LLMのハルシネーションに怯える必要もありません。また、そうして探し出した記事のURLを控えておけば、必要に応じて記事の中で引用できて、より高品質な記事になるでしょう。
また、会話を伴わないLLM活用として、GitHub CopilotのNext Edit Suggestionも試してみたこともありましたが……会話ではないからといって使いやすいわけではなく、結果的に効率は下がってしまいました。
自然言語の補完はプログラミングでの補完とは別物です。シンタックスハイライタやリンタを活用して最低限の品質が保証されているかを即座に確認できるプログラミング言語に対し、自然言語は自分で読まなければ良し悪しは判断できません。補完された文章の良し悪しをいちいち判断しなければならないというのは、とても面倒です。そして大抵、自然言語の補完は低品質です……。
あと、編集中のカーソルの近くに補完が出るたびにその補完された文章に意識が引っ張られてしまいますし、場合によっては大量のテキストを補完として差し込まれて画面がガクッと動いて驚いてしまいますし、そもそもGitHub Copilotは無料枠の制限が厳しく、どんどん枠が消耗されていくのが見えてしまいますし……。
やはりプログラミング用ということでしょう。
せっかく独自形式のマインドマップなどで、どんどんと書いていける仕組みを作ったのです。AIが出してくる文章のレビューより、まずは自分が書くほうを優先するべきでした。
LLMとの往復にはVS Codeの差分表示が便利
とはいえ、ある程度記事が仕上がってから、その内容をLLMに渡して推敲を手伝わせる、というようなシチュエーションは存在します。一人で黙々と頑張るのも悪くはありませんが、別の視点から見た感想が欲しいときもあるのです。
そして、LLMに下書きを渡して推敲を手伝わせる際、「前回とどこがどう変わったのか」を確認したくなったり、また、ときどきLLMがする大量削除のような破壊的な編集を差し戻したりしたくなります。あいつら、何の前触れもなく大量に文章を削除しやがることがあるんですよね……。
こういった場面では、VS CodeのGit差分プレビュー機能が便利です。これを使えば、差分が視覚的にわかりやすく表示されたり、差し戻し（revert）が数回のクリックで行えるようになったりします。Gitの--patchでも悪くはないのでしょうが、分かち書きされず文章中で改行をしない（hard wrapしない）日本語では、VS Codeの単語単位の差分表示がとても有効です。
（なお、私はコーディングエージェントは使っていません。セットアップが面倒なうえ、この程度なら普通にChatGPTやGeminiの画面でコピペするほうが速く、融通も効くためです。）
やはり、LLMは完璧なものではありません。たとえ私がいくら下書きをうまく書いたとしても、期待通りの記事を一発で書いてくれることはありません。しかし、そんなときこそ——。
解釈違い駆動執筆
「なんだよこの箇条書き！ 分かりにくいだけだわ！」
「なんで順番を入れ替えた？ ここの表現はこの部分の上に成り立っているんだから、入れ替えちゃダメだろ！」
「この言い回しはヌルすぎる！ もっと強い言葉を使え！」
などなど。
LLMはそれっぽい文章を生成する機械であって、ブログ記事としてのそれっぽい文体とは……残念ながら大抵、ぼんやりしていて、くねくねしていて、いかがでしたかしています。それじゃあダメなのです。ぼんやりした説明は私はしたくありませんし、くねくねした論理も私は嫌ですし、読者に感想を求めることも私の意図に反します。
たたき台は叩いてこそ。解釈違いにより湧き出た憤りをぶつけるように、書き換えたり、差し戻したりしていきます。
というわけで、最終的に次のフローに落ち着きました。
- プレーンテキストのマインドマップ：インデントで構造化し、とにかく書きまくる。
- 最低限意味が通る文章のリストにする：インデントを外し、順番だけで構造を作る。
- LLMで記事化：接続詞など自然言語のつながりを整えて平凡にしてもらう。
- 解釈違いを起こす。
- 人間の手直しとMarkdownによる構造化：内容を精査し構造を仕上げる。
構成は書きながら直す
最終的にはMarkdownで記事を構造化しますが、最初からMarkdownで書いていく必要はありません。組版は後からでも行えます。まずは本文を書くことが大切です。
また、章立てをあとから行うと、話の流れに合わせて適切な長さに調整できて便利です。これまで文章の流れを意識して書いてきていれば、見出しは後からどうとでもつけられるのです。
よく、「記事の構成は設計図。時間をかけて考えればいい記事になる」と言われますが、正直私はそうは思いません。記事執筆にウォーターフォール的アプローチで挑むメリットは多くないはずです。記事執筆の手戻りなんてそう大したものではありません。書きながら直すほうが圧倒的に速いですし、楽です。アジャイル的アプローチでどんどん推敲を回していく方が現実的でしょう。
LLMだって、すでに書かれたものしか読んでくれません。私の頭の中にある思考を読み取れるのは私だけです。まずは他でもない私が手を動かして、その思考を完璧でなくとも言語化することが大事です。
とはいえ最終的には記事の構成を考える必要があります。情報伝達は順序が大事。その際のテクニックとしては、「結論を先に書くのが無難」というものがあります。話がどう進むかわからない文章は読みにくいものですが、結論が最初に書いてあれば、筋道が見通しやすくなるためです。書き手としても、話を着地させやすくなる利点がありますね。
見通しやすい文章を書くテクニックとしてはPREP法も有名ですが、個人的にあれは「相手を説得するための説明技法」であって、記事の構成そのものを決める順番ではないと考えています。PREP法とは、結論（Point）→理由（Reason）→例（Example）→結論（Point）という順番で書く文章術（？）です。結論とその結論に至った理由を説明することはできます。しかし、そこにストーリーが入り込む余地はありません。ブログ記事として書くなら、「結論に至った物語」が必要です。
以下の流れが扱いやすいでしょう。
- 結論（TL;DR）
- あらすじ
- 経過（結論に至った物語）
- 再び結論（物語の着地として）
- 振り返り
ただし、冒頭の結論は最後まで書いたあとに一度書き直すのがおすすめです。最初は仮の結論で十分。最後につじつまを合わせるように整えれば自然な流れになります。レポートや論文の執筆でも使われるテクニックですね。
おわりに：AIは道具、最後は己の腕力
25日間、毎日ブログを書くために仕組みを整えた結果、
- プレーンテキストで思考を吐き出す（人間）
- LLMにたたき台を作らせる（AI）
- そしてそれを叩きまくる（人間）
という「人間とAIの分担」が効率的だと分かりました。
「AIを活用して記事を書く」というと、「AIにやらせてみた！」というような、すべてをAIに任せて人間がレビューする方法ばかりが注目されがちですが、真に高品質なものを効率的に作ろうとしたときには、人間とAIで取り組む仕事の境界線をきちんと引いておくことが重要であると考えます。
そして、人間も手を動かす。最後に信じられるのは、きっと己の腕力です。
（なんか、画像生成AIを使っていたときにも、AI翻訳を試していたときにも、この結論に達していたような気がします。）