LLMを味方につけた文章執筆術 - 執筆から校正までの実践的アプローチ
この記事は、技術同人誌/技術を取り巻く様々な執筆 - Qiita Advent Calendar 2024 - Qiitaの16日目です。
ChatGPTやClaudeなど（以下、LLMと呼ぶ）を使って技術文章を書くというのは、まだまだ発展途上の分野です。「LLMに丸投げすれば楽ができる」という単純な話ではありませんし、逆にLLMを全く使わないのももったいないです。この記事では、筆者が実際に技術同人誌を執筆する中で得た、LLMを活用した効率的な文章作成の具体的なノウハウを解説します。
この記事を読むことで、以下のような知識が得られます。
- LLMを活用した効果的な校正・推敲の方法
- 著者の文体や個性を保ちながらLLMを活用するテクニック
- 原稿の質を高めつつ執筆時間を短縮するためのプロンプト設計
- 各種LLMモデルの特性を活かした使い分け方
対象読者は、ブログや技術同人誌を書いている、あるいはこれから書こうとしている方々です。特に、文章の校正や推敲に時間がかかっている方、より効率的な執筆プロセスを模索している方に役立つ内容となっています。
この記事では、筆者が実際に技術同人誌の執筆で得た経験とノウハウを惜しみなく公開します。元の文章の良さを損なわずに、LLMの力を借りて原稿の質を高める方法について、具体的な例を交えながら解説していきます。
背景
おやかた氏のサークルである親方Projectでは、様々な同人誌を出したり、それを底本とした書籍を出版しています。
その親方Projectで出している合同誌が今度の冬コミに出ます。正式なタイトルは忘れましたが、たぶん「ワンストップ！学び」とかそういうタイトルだったはずで通称「学び本」です。
筆者は、この本に5章文の原稿を寄稿しました。
この原稿を書く上でLLMを活用しまくってノウハウがいろいろとたまったので、この記事で惜しみなく公開するというのが今回の背景です。
寄稿したうち4章分はすでにnoteで公開済みです。
学び本は筆者のみならず、多数の著者による様々な学びについて書かれた最高の本です。興味がある人は是非とも、コミケや技術書典など、実イベントで印刷された本を手に取ってみてください。詳しくは、おやかた氏のX(Twitter)の告知を見ておいてください。
本の宣伝はこれまでにして、LLMを使うときの利点と欠点を説明します。
利点と欠点
技術文章を書くにあたりLLMの活用には以下のような利点があります。
第一に、LLMは優れた文章能力を持つ校正者として活用できます。原稿全体の文体、統一感、読みやすさを向上させることができます。また、たたき台を書いてそこから原稿を膨らませることもできます。
第二に、最も重要な点として、LLMを使う場合、あなたの心理的安全性は完全に保証されます。24/265いつでも文句を言わず即座に対応してますし、気後れや遠慮なく校正や修正をしてもらえます。指摘事項に従うかどうかはあなたの判断次第です。あなたのアイデアは、すべてあなた自身が受けとめればいいだけです。
一方で、以下のような欠点もあります。
- プロンプトの組み立てを失敗すると、あなたの原稿を望まない方向に改変しようとします
- LLMのモデルによって、ライティングに活用できる・できないが大きく異なります
- あなた自身の言語化能力の訓練にはマイナスになる可能性があります
- 「この記事」のように大量のプロンプトを含んだ記事の場合、原稿を校正するためのプロンプトと混同しがちなので、指示への追従能力が劣化します。つまり内容によってLLMの能力は変化します
ただし、これらの欠点は適切なコントロールにより回避できます。以降では、実際の活用方法について具体的に解説していきます。
LLMをライティングに使う時に気をつけること
人間の手で書くとき以上にバージョン管理が重要です。以下バージョン管理ではGitを使いますが、ほかの方法でのバージョン管理の場合は適宜読み替えてください。
まず最初に校正前の原稿をcommitしておきましょう。その上で、校正したときも細かくcommitし続けてください。
いつでも戻れる状態にすることが必須です。LLMを使って原稿を修正する場合、取り返しのつかない修正が入ることが割とあります。
LLMを使ったライティングは以下のフローになります。
モデル選択
文章のライティングに関して、LLMでもどのモデルを使うで話は大きく変わります。
まず、日本語の読み書きに関してはClaude Sonnetがおすすめです。Claude SonnetはClaude Professional Planという月額$20で利用できます。以下の特徴があります。
- 長い文章を与えても破綻しない安定性
- 日本語の読み書きが特に強い
- 校正・推敲作業に優れた性能
ChatGPTのgpt-4oもSonnetに近い性能を持ちますが、日本語のライティングにおいては現時点でSonnetの方が優位性があります。
次に、深い洞察や分析が必要な場合はo1/o1-proが最適です。
- ChatGPT Plus（月額$20）でo1を制限付きで利用可能
- ChatGPT Pro（月額$200）でo1-proを利用可能
- o1/o1-proはほかのモデルでは実現できない賢さ・深い洞察力を持っています
- o1/o1-proは物事の相談を深いレベルで行うのに向いています
注目すべき新モデルとしてGemini-2.0-Flashがあります。このモデルはgpt-4oを凌駕する要素があるという報告もありますが、本記事執筆時点では十分な検証ができていないため、参考情報として記載しています。
実際の執筆では、これらのモデルを目的に応じて使い分けるといいかもしれません。
- 文章の校正・推敲：Claude Sonnet
- 日本語の表現改善：Claude Sonnet
- 話題・相談の深掘り：o1/o1-pro
この組み合わせを採用すると毎月$40（日本円だと6000円ちょっと）かかってしまうという問題はありますが、各モデルの強みを活かした効率的な執筆が可能になります。
出力上限を超えることがある
さて、LLMを使う上での注意点として、max_tokensというパラメータを見たことがある人はわかるかもしれませんが、出力上限というものがあります。
そのためClaudeの応答は途中で途切れることがあります。
Claude's response was limited as it hit tha maximum length allowed at this time.
このような注意書きが表示されたら、その上限に抵触してしまっています。長い原稿を出力しようとするとこうなります。
「続けて」と入力して続きを出力させて、その続きをうまく手動でくっつける必要があります。
- 純粋に続きを出してくるケース
- 一部重ね合うように出力してくるケース
それぞれがあり得るので、あなたの目で見てうまくくっつける必要があります。
長い原稿を取り扱うときは必ずこれと向き合う必要があります。
小さく変更する
色々な理由により一回の変更はなるべく、少ない項目を取り扱うようにしましょう。
- 構成を大きく変更するような場合は、構成の変更だけを行います
- 順番の入れ替えが必要な場合、順番の入れ替えだけ行います
- 削除が必要な場合は、削除以外のことはしません
- 細かい校正はまとめてもいいですが、そのとき、内容を変更させません
修正が終わったらまず修正をGitにcommitしましょう。手動で変更したい場合はそれも反映しましょう。その上で必ずチャットのセッションをはきして、次のセッションを開始しましょう。
やりとりが増えるとトークン数が肥大化して、レートリミットに抵触しやすくなるため、こまめにセッションを作り替える必要があります。
筆者の個性を消させないために
何も指定しないと、大幅に破壊的変更を施した原稿を出力します。とても許しがたい人類への反逆行為ですね。プロンプトの組み立て方が重要になります。
たとえば、筆者が実際に困ったのは執拗に箇条書きを使ってくることです。チャットでやりとりする対話型AIなので箇条書きを活用したレスポンスが好まれる傾向があり、それを原稿にも反映します。
以下は筆者が実際に愛用している指示です。
- 箇条書きよりは自然な文体を使う。本当に必要なときのみ箇条書きを使ってもいい
- 元の原稿の文体や内容を尊重する
- 「私達」ではなく「我々」を使うこと
- 自分を指す言葉は「筆者」を使うこと
なお、これをやった上でも、色々削りたがるので、
- 基本的に元の原稿の削除をしてはならない
これも追加しておいた方がいいかもしれません。削除をするときは、覚悟を決めてそれ用の手順を行うべきです。
記事を書く
記事を書くフローはこんな感じです。
それではそれぞれの手順を見ていきましょう。
執筆開始
まずリポジトリを作成し、書きたい内容を書き始めましょう。最初は単なるメモ書きでも、断片的な記事でも大丈夫です。
この記事は、技術同人誌/技術を取り巻く様々な執筆 - Qiita Advent Calendar 2024 - Qiitaの16日目です。
文章のライティングにClaudeを活用するものです。技術同人誌をLLMで書くというものだけど、もちろん技術同人誌に限らず、文章をライティングするという目的に役立ちます。
ジャンルは、アイデアなのか技術記事なのか悩んだものの、LLMを活用するプロンプトエンジニアリングの側面もあるため、技術記事というカテゴリにしました。
筆者が今回の記事で最初に書いたものは冒頭部分でした。この時点で、すでに筆者には知見がたまっていたので、それらを取り留めなく追加しました。
なお、学び本の原稿では断片的なメモ書きから始まっています。
LLMとの対話による内容の発展
LLMは執筆プロセス全体を通して活用できる強力な対話相手です。企画・構想段階から、目次の作成や構成の検討、対象読者の設定まで、幅広い相談が可能です。さらに内容の過不足の確認や、記事の切り口、独自性の検討にも役立ちます。
具体例やユースケースの発想にも活用できます。また、自分の主張の妥当性を検証する際にも効果的です。
例えば、学び本の執筆では「学びとは自己変容である」という主張について、o1に対して、様々な対話を行いました。「この主張はどの程度正しいのか」「なぜ学びが自己変容をもたらすのか」といった質問を投げかけ、さらに「自己変容を受け入れづらい人、受け入れやすい人それぞれの特徴は何か」といった観点からも掘り下げていきました。この目的ではSonnetよりもo1が優れています。
このような対話を通じて、筆者自身の視点では気づかなかった観点を得ることができます。特に、自分とは異なる立場や考え方について理解を深めるのに非常に役立ちます。
校正プロセス
校正は文章の質を高める重要なステップです。LLMを活用することで、客観的な視点からの指摘を得られ、効率的に文章の改善が可能です。校正は大きく3つの段階で行います。
まず構造的な修正から始め、章立ての見直しや文章の流れの改善を行います。次に表現の改善として文体の統一や説明の明確化を図ります。最後に重複の整理として、類似内容の統合や冗長な説明の簡潔化を行います。
具体的な校正の手順やテクニックについては、後述の「校正」セクションで詳しく解説します。
通読・確認
LLMによる校正を受けた後も、最終的な判断は著者が行う必要があります。文章全体の一貫性を確認し、自分の意図した内容が正確に伝わっているか、読者にとって理解しやすい説明になっているかを確認します。そして何より、個性や独自の視点が保たれているかを慎重に見極めることが大切です。
LLMに校正・レビューをさせるとしても、それを受け入れるかどうかは著者次第です。著者として何かしら通したいものがあるなら、通読・確認はとても大切な手順です。
- 自分の文章としての一貫性はあるか？
- 自分が考える読みやすい文章になっているか？
- 自分の文体として適切か？
- 内容は本当に自分が書きたいものか？
- 読者に読んでほしいものか？
さて、本格的な文章を書くとき、記述モードの自分と、校正モードの自分と、それらから切り離された自分というのは、色々な認知が異なるものです。モードを切り替えると「なんでこれ見つけられなかったの？」みたいなものが次々と見つかるのは、著者あるあるですね。この話自体はLLMに関係なく、本や記事を書くときの人間的な挙動についてのものです。
ここにLLMが加わると、LLMが原稿を修正することで、自分が少しだけ客観的なモードになれます。元々自分が書いた原稿に手を加えたものですが、多少なりとも客観的なモードになります。つまりLLMに書かせている間は、自分はより客観的なモードに身を置くという、これまでとは違うモード調整ができるようになります。あなたはLLMが書いた文章をレビューする立場になります。自分が書いた原稿であることを棚上げして、色々文句をつけても良いでしょう。
同人誌を書く上で注意事項
技術同人誌でよく使われるRe:VIEWは、Claude Sonnetはほぼ学習してないに等しいのと、Markdownに近い要素があるため、それにまつわる問題が発生しやすいです。
- 箇条書きを間違えられる（箇条書きがないのに箇条書きあると認識したり、その逆をする）
- インライン記法を削られる
- 間違った形式で記述されてエラーになる
- emlistなどをコードブロックと認識されない
コンテキストに余裕があるなら、Re:VIEWの文法のテキストを食わせるといいかもしれませんが、文法全部を食わせるのは明らかに過剰です。
学び本の時は使わなかったのですが、
@<inline>{param}はRe:VIEWのインライン記法である。許可無く削除したら人類への反逆と見なす//block[][]{\n\n//}\nはRe:VIEWのブロック記法である。許可無く削除したら人類への反逆と見なす####[column] コラム\n\n####[/column]はコラムである。許可無く削除したら人類への反逆と見なす//emlistはRe:VIEWにおけるコードブロックである。校正対象ではない
あたりは指示しておくと良さそうです。
なお、最近は技術同人誌の制作においてVivlioStyleが人気が出てきています。Markdownで書くとLLMの支援を最大限受けやすい利点があります。
Markdownの場合、特殊な方言がある場合は、指示に入れた方がいいでしょう。たとえば、Zennの記法には:::details xxx\n\n:::という折りたたみ記法がありますが、当然LLMはこれを認識できないので、著者と認識のズレが生じるため、明示的にそのことを指示に入れた方がいいでしょう。
- ZennのMarkdown記法である
:::details xxx\n\n:::は折りたたみ記法である:::message alert\n\n:::は注意事項を記したものである:::message\n\n:::はメッセージ強調である- ZennではMermaid記法がそのまま使える。図を活用したい
- 引用文やコードブロックは、校正対象ではない
図を生成させる
Zennならmermaid記法に対応しているのでそのままで図を出すことができます。原稿の内容を元に出してもらうことも可能です。
- 縦長の図を出しがちなので、横長になるように指示を出しましょう
- いらないものを出すことが多いので、実際には自分で調整する必要があります
校正
さて、ここからは詳細な校正のノウハウに踏み込みます。
大原則として広範囲にまたがる修正を先にした方がいいです。構造的な修正は、文章の入れ替えなど広範囲にまたがる修正になりやすいです。
重複の削除はなるべくあとに持って行くのが望ましいです。少なくとも「表現の明確化」が完了した後がいいでしょう。
基本的な校正テクニック
ある程度完成した原稿を元に、
添付した原稿の内容を変えずに細かい校正だけをしたい。
- 「である、だ」が混在しているのを「〜〜だ」に書き換える
修正した原稿を出力して
というような指示を与えると、実際に文体の変更をした原稿を出力してくれます。
必要に応じて指示を追加すると、従ってくれます。
このとき、原稿をClaudeに渡す方法ですが、ある一定サイズを超える原稿をコピー＆ペーストしようとすると、文字列のペーストではなく、PASTEDというファイルがClaude上に作られます。これはClaudeも添付ファイルとして認識しているため、「添付した原稿」という指示で正しく認識してくれます。
サイズが一定を超えない原稿の場合は、
以下に添付する原稿の内容を変えずに細かい校正だけをしたい。
* 「である、だ」が混在しているのを「〜〜だ」に書き換える
----
= 学びのプロセスを詳細に分解する
//flushright{
@erukiti
//}
前章では、学びと切り離せない言語化について説明してきた。言語化によって、漠然とした理解を明確なものにし、他者と共有可能な形にできることを見てきた。しかし、言語化は学びのプロセス全体から見れば、その一部に過ぎない。
のような形で渡すといいでしょう。
どうしても納得がいかない場合
LLMが指摘する項目の中には、どう考えてもそれに従わない方がいいというものも含まれます。そういったときは、指示の内容に「〜〜〜〜は変更禁止」などを追加して、セッションを開始しましょう。
校正済みの原稿を元に校正する
複数の章に渡って校正をすることもできます。
一つ目の原稿は、言語化について書いたもので校正済みである。二つ目の原稿はこれから校正を行う
- 文体や書き方の癖などを第一章の原稿を参考にすること
- 「〜〜だ」調
- 書式はRe:VIEW形式である
- なるべく箇条書きよりは自然な文体を使う
- 元の原稿の文体や内容をなるべく尊重する
これを踏まえて、第二章に関して、読みづらい部分や一貫性のない部分、内容の重複などはあるだろうか？
第一章で苦労した分をうまく反映してくれる可能性が上がります。
筆者は一応、指示を重ねていますが、もしかしたら、第一章をまねしろという指示だけでもなんとかなるかもしれません。
指摘事項を別セッションで反映させる
先ほど原稿の校正をいただきありがとうございました。
- 「つまり」「だから」「しかし」などの接続詞の使用頻度にばらつきがあります。特に「つまり」の使用が多いように見受けられます。
- 一文が長くなっている箇所で読点が少ない部分があります。特に条件を並列する際の読点の使用にばらつきがあります。
- 「言語化」という単語が特に後半で頻出しています。言い換えられる箇所は別の表現を検討してもよいでしょう。
というご指摘をいただきました。これらを実際に書き換えるとどのような感じになりますか？
具体的に修正した原稿を出力してください
原稿を添付した上で、指摘事項を渡すと修正してくれます。このとき全部の指摘事項を渡す必要はありません。チェリーピックしましょう。
原稿をmergeする
原稿をmergeすることも可能です。
一度ごっそりと原稿を削られたことがあります。まぁそれを受け入れてしまった筆者が悪いといえばそうなのですが、自分でも書いててピンと来てなかったのだから仕方ありません。さて、ごっそり削ると「情報量の欠損」が生じます。
欠損した情報量を回復させるためには別の何かをmergeさせると良いでしょう。
- 消されるまえの原稿を引っ張ってくる
- o1/o1-proのような賢いLLMに、出力させた深い洞察などを活用する
添付の原稿では物足りない。色々と内容を補完していきたい。原稿の以前のバージョンを添付するのでそれを元に、内容を膨らませてみて
みたいな無茶振りでもそれなりに対応してくれます。
添付の原稿にたりないものを補うために、別の人に、自己変容に関する考察を聞いてみた。この内容を元に内容を補ってみて
o1とのやりとりを元にしたときは、このような指示をしています。
構造的な修正、文章の流れの改善
LLMを使った校正では、なるべく大きな修正から先にした方がいいです。
そのため、構造的な修正、文章の流れの改善では、
読みづらい部分や一貫性のない部分はないだろうか？
まずは、大きく構成の変更がある部分を指摘してほしい
なお、文章の削除は一切禁じる
読みづらい部分や一貫性のない部分はないだろうか？
文章の流れを改善すべき箇所を指摘してほしい
なお、文章の削除は一切禁じる
読みづらい部分や一貫性のない部分はないだろうか？
内容の不足はないだろうか？
なお、文章の削除は一切禁じる
などを指示してみるといいでしょう。
その返答を元に、実際にどこをどう修正すべきかを指示しましょう。
表現の明確化、細かい校正
内容はもうおおよそ固まってきたら、表現の明確化をしましょう。
読みづらい部分や一貫性のない部分はないだろうか？
- 内容は変更しないこと
なお、文章の削除は一切禁じる
このような指示を与えると、内容は変更せずに、表現だけを変えてくれるようになります。
- 接続がなめらかじゃない、という指摘を受けたら、そのまま原稿を書かせると大分それっぽいのを書いてくれます
- 読みづらい箇所に関しては、実際に出力させてみて、元の文章と読み比べてリズム感を見ましょう
校正に関しては、何回も読み慣れている自分よりは、LLMの方が中立的に読みやすさを見極めてくれます。ただし、それを受け入れるかどうかは著者が決めることです。
筆者は試していませんが、「文章が、必ず主語と述語が繋がってるかを確認して」はやってみる価値はあるかもしれません。
1セッションにつき、一つの内容という原則さえ守っていれば、ここで変なことをされる可能性は限りなく低いでしょう。
なお、この原稿を最終的に校正したプロンプトは以下の通りです。
添付の原稿は校正中である。文章のライティングにLLMを使うというテーマでブログを書いている。読みづらさや統一感の欠けているところはあるか？
* ZennのMarkdown記法である
* `:::details xxx\n\n:::`は折りたたみ記法である
* `:::message alert\n\n:::`は注意事項を記したものである
* `:::message\n\n:::`はメッセージ強調である
* ZennではMermaid記法がそのまま使える。図を活用したい
* 引用文やコードブロックは、校正対象ではない
* 原稿を修正する場合
* 原稿の文体を使うこと。特に元の原稿のリズム感を再現するように
* 「〜〜です、ます」調で統一
* あなたは箇条書きを過剰に使う癖がある。自然な言葉を優先すること。どうしても必要なときは箇条書きを使うこと
必ず、これらのルールを守ってください。
重複の削除
重複の削除は少なくとも表現の明確化のあとが望ましいです。
これを行うときは覚悟を決めて、いつもより注意して作業を行いましょう。
読みづらい部分や一貫性のない部分はないだろうか？重複を洗い出して
「削っていいよ」というと、遠慮無くコラムを削ったり、著者の個性を削ったりしがちです。許しがたい反逆ですね。これをやられると、文字屋としては確かにAI許さんって気持ちになることは理解できました。
気をつけて反映させてください。
校正を途中で切り上げる
校正プロセスは無限に続けられるので、適当なところで切り上げる必要性があります。
筆者が実際に遭遇したのは「ここの説明が足りなくて唐突に感じるので説明を増やしましょう」といわれて修正したあとに「ここの説明は過剰に感じます。削った方がいいです」といわれたケースです。完成に近づいてくると、割とそういうことが増えます。ある程度のところで切り上げましょう。
ヒントを出してもらう
校正のやりとりの最後とかに 今回の校正をしてくれたけど、読みやすさについて持っている判断基準はなに？ を聞いてみると、何かしらヒントがあるかもしれません。
記事の分析をさせる
先日公開した、プロンプトジェネレータで実現する持続可能なLLMプロダクト開発を目指すという記事について、とっつきにくさがあるのでは？と公開した後に気づいたので、分析させてみました。
添付の原稿はZennに投稿した技術ブログである。
- Zennでは ::details xxxx\n と :::の間は折りたたみ記法として扱われる事に注意
この記事は、とっつきやすい？とっつきにくい？
この記事は、以下の理由からとっつきにくい部分とつきやすい部分が混在していると考えられます：
とっつきにくい要素:
* 長文で情報量が非常に多い
* プロンプトジェネレータという比較的新しい概念を扱っている
* TypeScriptのコードを含む技術的な実装の説明が含まれている
* LLMやプロンプトエンジニアリングの基礎知識が前提となっている
とっつきやすい要素:
* TRPGシナリオ作成という具体的で親しみやすい例を使って説明している
* 実際のプロンプトと出力結果を示しながら段階的に説明を進めている
* メタ認知プロンプトなどの概念を丁寧に解説している
* 問題点や改善案を明確に示している
* 折りたたみ記法を使って情報を整理している
全体として、LLMやプログラミングの基礎知識がある読者にとっては有用な情報が多く含まれていますが、それらの予備知識がない読者にとっては少し難しい内容かもしれません。ただし、具体例を使った説明方法は理解の助けになっていると言えます。
人工知能やプロンプトエンジニアリングに興味のある読者であれば、この記事は良い学習リソースになるでしょう。
良さを殺さずに、とっつきにくさだけを改善する方法はある？
はい、以下のような改善案が考えられます：
1. 記事の構造を改善
- 冒頭に「この記事で学べること」と「必要な予備知識」を箇条書きで明示
- 目次を追加して全体像を把握しやすくする
- 技術的な深さによって章を分け、基礎→応用の流れを作る
2. 導入部分の工夫
- プロンプトジェネレータが解決する具体的な課題を、より身近な例で説明
- 「なぜこの技術が必要か」をストーリー形式で伝える
- 技術的なメリットを図やイラストで視覚的に表現
3. 技術的な説明の改善
- コード説明の前に、そのコードが何を実現するのかを平易に説明
- 複雑なコードブロックは部分に分けて段階的に説明
- 重要な概念は図や表を使って説明を補足
4. 実践的な部分の強化
- シンプルな使用例から始めて、徐々に複雑な例に移行
- 「よくある失敗パターン」と「解決方法」のセクションを追加
- 読者が試せる簡単なサンプルコードを提供
5. 理解度に応じた情報の階層化
- 基本的な説明は本文に
- より詳細な技術的説明は折りたたみセクションに
- 発展的な内容や追加情報はリンクとして提供
これらの改善により、初学者でも入り口部分から段階的に理解を深められる構造になり、かつ上級者にとっても価値のある情報を維持できると考えられます。
ほんともう仰る通りですね。アドベントカレンダーの締め切り過ぎていたから気持ちが焦っていました。
書いている途中で記事の分析をしておくことをお勧めします。
なお、今回の記事もやたらと長大になってしました。
今後の発展
今回あれこれ使いましたが、まだまだこんなものではないと思っています。
学び本の原稿と、プロンプトジェネレータで実現する持続可能なLLMプロダクト開発を目指すのブログでしか試していないので、今後もう少し活用を繰り返して、またノウハウをまとめなおしてみます。
- LLMとの対話は、もっと様々なものがあるはず
- 原稿執筆や校正のプロンプトをもっと安定させる手法があるはず
- 試してないけど、既存の原稿から、特徴を抜き出すことも可能なはず
まとめ
この記事では、LLMを活用した文章の執筆について、実践的なノウハウを解説してきました。深い洞察を含むやりとりにはo1/o1-proが強く、校正・推敲にはClaude Sonnetが強い、というように、目的に応じた使い分けが重要です。
執筆プロセスでは、バージョン管理を徹底し、大きな構造から細かい校正へと段階的に改善を進めることが大切です。そして何より、完全な心理的安全性が保証された環境で、無限に質問や要望を投げられる環境を最大限活用することが重要です。
ただし、LLMはあくまでも執筆の協力者です。著者の個性や文体を守りながら、より良い文章を目指すためのツールとして活用していきましょう。人類の遙か上の高みから見せてくれる景色を、我々は謙虚に、そして賢明に取り入れていくべきです。そこには、新しい気づきと学びがたくさん隠されているはずです。
Discussion
人類の反逆とみなすというところに笑ってしまいました。
内容参考にさせていただきます。