AI駆動文章作成において俺が意識しているテクニック集

はじめに

私は基本的に、「誰もわたしが書いた文章なんて読みたくない」と思っています。

みんな忙しいんです。そんな中であなたが文章を書いて、誰かがそれを読むということは、双方に何かしらの目的があるんだと思います。

しかも今は AI のおかげで、文章は一瞬でいくらでも書けるようになりました。結果として、仕事の中でも外でも AI が生成した文章が溢れかえっています。AI に書かせた長文を「で、何が言いたいの？」と思いながらスクロールした経験ってありませんか。

わたしはあります。

だからこそ、みんな忙しい中でどうやって読んでもらうか？ を考えるテクニックが大事になると思います。この記事では、私が普段使っているテクニックを小さく並べてみます。どこから読んでも大丈夫です。

読者を明確にする

その文章は誰が、なんのために読んで、読まれた結果としてどうなっていてほしいのかということを明確にしましょう。

なぜ読んでもらう必要があるのか？読んだ人にどうしてほしいのか？ 考えた結果、その目的を達成する手段は文章である必要はないかもしれません。文章は情報伝達の手段の一つに過ぎません。

文章は情報伝達の手段の一つであって、目的に対して最適ではないかもしれない

今回は Zenn の Idea カテゴリーに投稿するブログ記事で、以下のようなことを狙いにしています。

• 読者
  • AI × 文章作成でモヤモヤしている人
  • 文章作成の具体的なテクニックや考え方を知りたい人
• 目的・目標(ゴール)
  • 読者が「へー、こういう考え方のテクニックか、いいね」と思う
  • 「俺は他にもこういうテクニックがあると思うぜ」と反応してもらう
    • そこで私が知らない・考えていないことを紹介してもらえたら嬉しいな
  • 10いいね
    • なんとなく
  • ちょっとウケる

こんな感じで考えたら、テクニック集みたいな形式にしたら読まれそうだなーと思いました。『Tidy First?』みたいな。

読者と目的がある程度明確になったら逆に読者じゃない人とゴールじゃないものも明確になります。これもどこかに書いておくとコンテンツの内容が逸れていないかわかりやすくなります。

• 読者じゃない人
  • 文章の作成が得意で自身のテクニックを明示的に持ってる人
  • 別に AI で文章の作成してない人
  • 軽いノリで書かれている文章が嫌いな人
• ゴールじゃないもの
  • 文章術を網羅的に解説すること
  • 特定の AI ツールの使い方を解説すること

読者と目的を伝えないと、AI は「どこかの平均的な誰か」に向けて書いてしまう気がします。

目次から書く

目的が決まったら最初に目次だけを書くのはどうでしょうか。雑にこんな感じです。

# AI 時代の文章テクニック集（仮）

## 読者を明確にする
## 目次から書く
## 詳細を隠蔽する
## リストをグループ化する
## 途中まで書く
## インラインコメントを使う
## 絵を描く
## 参照しているコンテキストを書いておく
## 書かない

この時点で他の人からのフィードバックがもらえます。

はじめから詳細をがーっと書いていくと、それを渡された人はフィードバックを返すのが大変になるし、全く違う方向に進んでいたらその作業が全部無駄になるので、書く人にとっても読む人にとっても不幸せなことになります。

もちろん AI にフィードバックをもらってもいいですよね。むしろ AI に本文まで一気に書かせると、直すべき箇所が全体に散らばって手に負えなくなりがちです。まず目次だけ出してもらって、構成に合意してから中身に進むほうが、結局早いです。プログラミングで言う段階的詳細化ですね。

詳細を隠蔽する

私は基本的に「誰も私が書いた文章なんて読みたくない」と思っています。だから、全員が全部を読む前提では書きません。

プログラミングのカプセル化と同じで、読者に見せるのは「何をするか」だけにして、「どうやるか」は必要な人が必要な時に覗けるようにしまっておきます。

• 結論と要点を先頭に置く
• 補足や細かい手順は折りたたみや別ページに逃がす
• 「詳しくはこちら」とリンクで済ませる

あるあるとしてたまに聞くのが、調査報告でタイムラインから書き出してしまうというやつですね。

結論から書く、というのは読み手にとって最も重要なことを先に書く(読書を明確にして、読者の関心を優先して書く)ということであり、それ以外の詳細を隠蔽するということだと思っています。

リストをグループ化する

箇条書きの項目が増えてきたら、ネストしてグループに分けます。

例えば、リリース前にやることをそのまま並べるとこうなります。

• マイグレーションを流す
• リリースノートを書く
• ステージングで動作確認する
• CS チームに変更点を伝える
• ロールバック手順を確認する
• 監視ダッシュボードを開いておく

平らなリストは結局上から全部読むしかありません。グループに分けるとこうなります。

• 作業
  • マイグレーションを流す
  • ステージングで動作確認する
  • ロールバック手順を確認する
  • 監視ダッシュボードを開いておく
• 連絡
  • リリースノートを書く
  • CS チームに変更点を伝える

親の項目だけ見れば「作業と連絡があるのね」と全体がつかめるし、自分の担当が連絡なら「連絡」の下だけ読めば済みます。「読者を明確にする」で書いた読者と目的のリストも、この形にしています。

グループに名前がつけられないときは、分け方が違うか、関係ない項目が混ざっていることが多いです。

途中まで書く

本文を完成させずに途中で見せることができます。例えば私は設計書を書く際には、詳細な設計を書く前にユーザーストーリーや基本設計を書いて、その段階でレビューをしてもらいます。レビューする人だって長い文章は読みたくないし、書く側もたくさん書いてから直すのはめんどくさいです。

全部書き終わってから見せると、もう直したくない気持ちが勝って、防御的なことを言ったりしてしまうことってないでしょうか。半分くらいの状態で見せて「この方向で合ってる？」と聞くほうが、答える側も気楽です。

AI と書くときは、冒頭の数段落だけは超雑に自分で書くのもおすすめです。

ゼロから AI に任せると、どことなく「AI っぽい文章」になりがちですが、最初の数段落を自分で書いて「この文体を崩さずに続きを書いて」と渡すと、トーンや語尾、温度感が揃う気がします。

インラインコメントを使う

Google Docs や Notion のコメントみたいに、本文の横に注釈をつけられる場所があるなら、遠慮なく使います。

「ここは自信ない」「この数字は仮」「〇〇さんに確認中」みたいな補足を本文に書くと、全員がそれを読むことになります。コメントにしておけば、気になった人だけが開けばいい。

コメントはそこから会話が始まる場所にもなります。「ここどう思う？」と置いておけば、読んだ人がその場で返事を書けるし、やりとりがスレッドとして本文の横に残ります。「途中まで書く」で見せた下書きへのフィードバックも、コメントでもらうのがいちばん楽です。

インラインコメントの地味に良いところは、自分が書いた文章に対してセルフツッコミがやりやすいところです。GitHub でプルリクエストを出す前にセルフレビューでコメントを入れる人とかいると思うのですが、あんな感じです。

絵を描く

文章の弱点の一つに、上から順番に読んでいかなくてはいけないという点があります。しかし、長い文章は見ただけで読む気がなくなります。

なんとなく目に入ってくる文章量が多いなと思ったら、画面に映る文字数を減らすのがいいです。そのテクニックの一つとして、途中に絵を差し込みます。

例えば、ここまでの話を絵にするとこうなります。

文章で「目次を書いてフィードバックをもらい、途中まで書いてまたフィードバックをもらい…」と説明するより、ぱっと見でわかります。

絵を描くのが面倒なら、ここも AI の得意分野です。文章を渡して「この流れを Mermaid の図にして」と頼めば一瞬です。

ずらす

Mermaid の図見飽きてないですか？ AI で生成されているコンテンツっぽさ、みたいなものがあって、それをよく目にしていると、AI っぽいなと感じるシグナルを受けるだけで、萎えることがあります。なので、これは AI っぽいなと感じるものがあれば意図してずらしましょう。Mermaid ではない仕方で絵にしてみることができるのではないでしょうか。Claude の Artifact を使ってみます。

(まぁ、これ自体がただそれっぽいだけの図になっていそうとかはある)

Artifact で私が他によく使うのは、何かを作るときに、その触り心地を Artifact で html とかで表現してそれを触ってもらうとか。文章以外の仕方でやりたいことを伝える手段として重宝することがある。

ずらしすぎない

この文章ではところどころで「ウケるかなー」と思って、コンテンツを配置しています。これは AI っぽくないですよ。私が書いていますよ、というシグナルとして機能してくれることを期待しています。

しかし、それが過剰になってしまうと、ただ単に読みづらい文章になってしまいます。ボケすぎないように自制するのは人として大事です。

参照しているコンテキストを書いておく

その文章が何を前提に書かれているかを、文中か末尾に書いておきます。

• 元になった議論の Slack スレッドや議事録
• 参照したドキュメントや記事
• 書いた時点の日付や、対象のバージョン

書いている本人にとっては当たり前の前提でも、読む人は知りません。半年後の自分も知りません。リンクが一つあるだけで「なんでこうなったんだっけ？」をたどれるようになります。

AI は書かれていないことを知らないので、前提がまとまっていればそれをそのまま AI に渡してレビューや続きの執筆をお願いできます。

書かない

AI で文章を生成していると、私はときどきハイになってくることがあります。

ハイになるとともにだんだん訳がわからなくなってきて、文章はどんどん膨れ上がっていきます。誰に向けて書かれているか曖昧な文章は誰も読みません。私の場合こういうときには、なんのためにその文章を書いているのかが曖昧になっています。

一度キーボードから手を離して、「なんでこれを書くことになったんだっけ」と思い出してみるのがおすすめです。誰かにタスクをお願いされている途中にそれを書いているなら、その人をつかまえて同期で話してしまうのもいいと思います。

文章はあくまで情報を伝えるための手段の一つでしかないです。書かずに物事を前に進められたり、全員で合意できたりするなら、そんなに素晴らしいことはないです。

ただ、書いて残しておくと、あとから「あのときこう決めたよね」と参照できるのもたしかです。そこはメリットデメリットを見比べた上で、最適な方を選びましょう。

消す

いらない文は消しましょう。個人的に無駄な一文がついてるな、と感じることは結構あります。そういうのはさっさと消しちゃうのがいいです。

冗長に書く

逆に文体を装飾することで書かれている内容が曖昧になっているな、と感じたら愚直に複数の文で書き下すようにしましょう。

読んだり直したりを繰り返す

ぽんと出したものより、読んで直してまた読んで、を繰り返したものの方が、最終的に自分が納得いく文章になることが多いです。

もちろん、納得いくまで磨くこと自体が目的になって時間を溶かすのは本末転倒です。日報や軽い共有なら素手でパッと書くべきです。

一方で、仕事相手と認識をすり合わせて物事を前に進めたいときや、自分の考えを読者にちゃんと伝えたいときは別です。書いて、読者のつもりで読み返して、気になるところを直すということを何周か繰り返すほうが、結果的に近道になることが多いんじゃないかな、と思っています。

技術的なドキュメントを書くのは難しい

私は読者が明確であればあるほど、その人に文章を読んでもらいやすくなると思っています。

例えば読者が同じチームの A さんなら、A さんが何を知っていて、今どんなタスクを抱えているかがわかります。お互いのタスクで前提を共有しているから、説明を省いていい部分も、逆に丁寧に書くべき部分もはっきりします。その人の関心が強い内容が先に来るように順序を調整するといったテクニックも使いやすいです。

ところが技術的なドキュメントは様々な関心に応える必要があります。今のチームメンバー、来月入る新メンバー、隣のチーム、半年後の自分。全員に向けて書こうとすると、誰にとってもちょっと読みにくい文章になります。

そういうときは、こんなテクニックもあるかなと思います。

• いちばん読んでほしい読者を一人に絞って書く
• 読者ごとにドキュメントを分ける（概要用と手順書用など）
• 冒頭に「この文章の読者」を書いて、読者じゃない人には早めに離脱してもらう
• FAQを書いておく
• 関心ごとの読み進め方を書いておく

ツールを使う

コンテキスト管理や、スキルを積極的に使いましょう。私は最近以下の2つがお気に入りです。

https://zenn.dev/babarot/articles/claude-code-session-recall

https://zenn.dev/algoartis/articles/0b1c731881b25c

自分に向けて書く

「読者を明確にする」と矛盾しそうですが、Zenn の記事のような文章は、基本的に自分が第一の読者になるように書いています。

冒頭で「誰も私が書いた文章なんて読みたくない」と書きましたが、一人だけ例外がいます。私です。「こういう記事が読みたいんだよなー」と探しても見つからないとき、しょうがないので自分で書きます。この記事も「AI 時代に文章を書くとき、個人がなんとなく意識していること」を並べた記事が読みたかったのに見つからなかったので AI 使いながら書いています。

自分は、何を知っていて何に困っているかを一番よく知っている読者です。なので矛盾というより、「いちばん読んでほしい読者を一人に絞る」の極端なやつだと思っています。いつも自分と似たような人が読んで、何かしら参考になることがあると嬉しいな、と思っています。

個人的に、AI に自分が読みたい文章を書いてもらうことができるようになったので、いい時代だなと思ってます。

おわりに

読み返してみると、カプセル化とか段階的詳細化のような、プログラミング的な話をところどころでしています。

コードが読んでいて気持ちいいこと自体には、ビジネス的な価値はあまりありません。AI がコードを書くようになって、その傾向は加速している気がします。一方で、仕事を進めるために書いた文章が読みづらいせいで、自分の仕事が進まなくなることは未だによくあります。きれいなコードに向けてきたこだわりを文章にも向けてみると、AI 時代のエンジニアの強みになったりするのかもしれません。

どれか一つでも「お、いいね」と思ってもらえたら、この記事のゴールは達成です。読んでいただきありがとうございました！いいねをポチッと押してくださいね！

Discussion