あなたが書いていない文章は読みたくない — 生成コストと読解コストの非対称
あなたが書いていない文章は読みたくない — 生成コストと読解コストの非対称
AIが書いた文章が拒まれるのは品質のせいなのか、それとも、その文章がもはや何も保証しないからなのか?
導入
2026年9月21日(UTC)、Hacker NewsにColin Breckのエッセイ「I Don’t Want to Read What You Didn’t Write(あなたが書いていない文章は読みたくない)」が投稿され、1,070ポイントを獲得した。ブログの公開日は9月20日である。その2日前の9月19日には、Erich Grunewaldの「I think you should almost never use AI to write(AIで文章を書くことは、ほぼ常にすべきではないと思う)」が363ポイントを集めていた。同じ週に、同じ主張の記事が続けてトップページに並んだことになる。HNのあるユーザー(idreyn)は、ここ数日、似た内容のブログ記事が小さな流れのように投稿されていて、自分はそのすべてを楽しく読んだと書いている（直接の引用ではなく、コメントの要旨の要約）。
Breckの最初の一文は観察である。以前はオリジナルの文章をほとんど書かなかった人々が、いまや設計提案書、事業計画書、ドキュメント、プレゼンテーション、チケット、プルリクエスト、ブログ記事、議事録を大量に生み出している。すべてAIが生成したもので、すべて読めない、というのだ。ところが同じ記事の中で、彼はAIが自分の執筆をより良く、より速くしてくれているとも述べる。これはAI拒絶論ではない。AIをどちらの方向に向けて使うか、という話である。
本稿では、BreckとGrunewaldの主張を原文に基づいて整理し、HNの議論で出た反論も含めて、一つの問いに絞り込む。生成はほぼタダになったのに、読むことは依然として高くつく。この非対称は、文章というメディアの契約をどう変えつつあるのか。
現象分析 — 「読めない」文章はどこで生まれるのか
Breckが挙げる事例は具体的だ。一つ目は設計ドキュメントである。人々はまずAIで何かを作り、それから既に作ったものをAIで事後的に要約して設計ドキュメントに仕立てる。彼はこうしたドキュメントを読むことは単に難しいのではなく「懲罰的」だと書く。設計ドキュメントは本来、合意を形成し、人々を巻き込み、ゆっくりとした慎重な思考でアイデアを磨くための提案だった。それがいまや、機械が作った、文脈も視点もない、うんざりするほど詳細な要約になってしまった。さらに厄介なのは、同僚が関心を示さないと著者が苛立つことだ。同僚の側からすれば、関心を持つのは難しい。作ったものは既に動いているのだから。
二つ目はプルリクエストの要約である。Breckは、機械が機械のために書いたことが明らかなPR説明が増えていると言う。これをあれに変えた、これらを分割した、あれらを統合した、これには手を付けていない、テストを追加した、といった細部は豊富だ。しかし、レビュアーが本当に知りたいことが抜けている。なぜこの作業をするのか。価値は何か。どれほどリスクがあり、どれほど急ぐのか。どこに自分の意見が必要なのか。何に注意すべきなのか。彼はこうした文章を「文脈の外にある記述の集まり」と呼ぶ。
HNの議論で、この点は最も実務的な共感を集めた。あるユーザー(zmmmmm)は、説明が多すぎるという理由でPRを差し戻していると書いた。20行の変更に、生成された説明が何ページも付いていて、なぜ安全なのかの正当化、設計判断ごとの弁明、リスクと副作用の分析が続く。作成者は「ドキュメントが多すぎるから却下するのか」と憤慨するが、彼の答えはこうだ。それを読む時間はない。しかし承認するということは読んで受け入れたという意味になるので、読まずに済ませることもできない。自分ならプロンプト一回でできるコード変更の価値に対して、その読解コストが大きすぎる、というのである（直接の引用ではなく、コメントの要旨の要約）。
このコメントは問題の構造を正確に示している。承認とは署名である。署名には「私はこれを読んだ」という主張が含まれる。文章の量が増えるほど、その主張を誠実に保つコストはレビュアー側へ移っていく。作成者は生成ボタン一つでページを増やし、そのページを消化するコストはすべて相手が負う。
三つ目の事例はより個人的だ。Breckは、デリケートな話題について誰かから個人的なメッセージを受け取ったが、それは自分を不快にさせないようにAIと一緒に練り上げたものだと明らかに分かった、と書く。結果は非人格的で、感情がなく、継ぎ目の合わない文章だった。部品はすべて揃っているのに、全体としては意味をなしていなかった。彼は、言葉をうまく見つけられなくても、あるいは自分を不快にさせるリスクを冒してでも、相手が自分の声で書いてくれたほうがよかったと言う。人間関係には脆さとリスクがあるが、AIとのやり取りにはそれがなく、脆さとリスクを取り除こうとする試みは関係というプロセスそのものを取り除いてしまう、というのが彼の診断である。
彼が「最も怠惰で侮辱的な使い方」として挙げる事例はこうだ。誰かの提案書に彼がコメントを付けたところ、相手はそのコメントをAIで要約して、彼への返信として送ってきた。Breckは「ありがとう、私自身でもこれ以上うまくは言えなかった」と皮肉っている。
読者の反応に関するデータも引用されている。BreckはCynthia Dunlopが共有したアンケート結果を挙げ、多数の読者は記事がAIの助けを受けている、あるいはAIが書いたと思うと読むのをやめ(78%)、以後その著者を避ける(71%)と伝える。最も強い結果は、欠点や癖も含めた著者本人の文章を、AIによる書き直しより圧倒的に好むという回答(98%)だったという。ただし、この数値はBreckの記事を通じて間接的に確認したものであり、調査の標本や方法は本稿では直接検証できていない。開発者向けブログの読者という特定の集団の反応として読むのが無難である。
深層分析 — 文脈はプロンプトを書いた人にしかない
Breckの記事で最も鋭いのは、なぜAIの出力が書き手には有用で、読み手には読めないのかを説明する部分である。AIにプロンプトを与えた本人にとって、その出力はかなり役に立つ。しかし、それを効果的な文章と取り違えてはいけない、というのが彼の警告だ。
出力を読むとき、書き手は既に多くの文脈を持っている。プロンプトを組み立て、制約を決め、ドキュメントやソースコード、ログ、統計、図といった資料を与えた。だから出力をざっと眺めて、何が関連して価値があり、何が無関係か間違っているかを素早く見分けられる。書き手はプロセスの一部でもある。問いかけて結果を見る、呼びかけと応答のプロセスだ。ところが同じテキストを他人に送ると、その人には文脈がほとんどない。展開していくプロセスに参加していないので、何が重要で何がそうでないかを判断するのがはるかに難しい。だからすべての行を網羅的に読み、検討しなければならない。文脈を得るために機械の内部を覗き込むようなものだ。読むのをやめるのは自然な反応である。
この説明をコストの言葉に置き換えると、非対称がはっきりする。生成コストはゼロに近づいた。しかし読む側のコストは減っておらず、むしろ増えている。文脈を欠いた詳細さは、読み手に「どこが重要か」を自力で再構成するよう要求するからだ。書き手が出力を流し読みできるのは、その出力をふるいにかけるフィルター、つまり文脈を既に頭の中に持っているからである。読み手はそのフィルターなしで同じテキストを受け取る。
HNのトップコメント(hatthew)は、これを情報量で説明した。文章を書くことは、根本的には書き手の脳から読み手の脳へ情報を移すことである。伝えたい意味情報が1,000ビットあるとして、LLMに300ビットだけ渡して残りの700ビットを埋めさせることはできない。LLMはその700ビットが何なのかを知らないからだ。もしLLMがその700ビットを正しく推測できるなら、それは本当の意味情報ではなく、実際に伝えるべきは300ビットだけだったということになる。それなら、その300ビットを読み手に直接渡したほうがいい。読み手がふるい落とさなければならない余計な700ビットを付け足す理由はない（直接の引用ではなく、コメントの要旨の要約）。
この論理は単純だが強力である。生成された文のうちプロンプトから予測可能な部分は、読み手にとって新しい情報ではない。予測不可能な部分は、書き手の意図とは無関係なモデルの推測である。どちらにしても読み手は損をする。前者は時間の浪費であり、後者は書き手が主張していない内容を書き手の名前で受け取ることになる。
Grunewaldの記事は、同じ問題を「思考」の側面から扱う。彼は三つの理由を挙げる。執筆のプロセスは思考のプロセスの中核であること、AIの文章は気づきにくい形で曖昧かつ誤っていること、そしてAIで書いた文章を表示なしに出すのは無礼で誤解を招くこと、である。二つ目の論点について、彼は実際の実験を見せる。Claude Fable 5にAIチップ密輸問題を紹介する短い段落を書かせ、その出力を一文ずつ解剖するのだ。「輸出規制は執行の強さ次第だ」という文は、当たり前のことを言っているか、何も言っていないかのどちらかだ。チップが「小型」だという描写は事実だが、実際に密輸されるのは多くの場合小型ではないAIサーバーであり、密輸は隠すよりも別の品目としてラベルを貼り替え、堂々と輸送されるのが普通だという。規模の推計を「数万から10万超まで幅がある」と書いた部分は、文字通りには正しいが、彼の判断では低い推計はほぼ確実に間違っているので誤解を招く。彼の見立てでは、出力は「悪くはなく、むしろかなりもっともらしい」が、小さな言葉選びのたびに少しずつずれている。
この解剖が示しているのは品質の問題ではなく、責任の問題である。もっともらしい段落の各文について「これは正確には何を意味するのか」と問えるのは、その文を書いた人だけだ。AIが書いた文には、その問いに答える主体がいない。だからGrunewaldは、読み手と書き手のあいだには暗黙の契約があると言う。読み手は注意を差し出し、書き手はその見返りに価値あるものを返す。文章がAIで書かれたと気づいた瞬間、読み手は書き手がその文章にどれだけ思考を注いだのか分からなくなり、そのため信頼が即座に、しかも合理的に下がる、と彼は書く。
Breckが引用するBryan Cantrillの一文も、同じ契約を指している。LLMで文章を書くことは書き手と読み手のあいだの社会契約を無効にすることであり、書き手自身が苦労して作らなかった文を、読み手が苦労して理解することを期待すべきではない、というものだ。Breckによれば、CantrillはAI生成文の検出モデルであるPangramを試し始め、Oxideのすべての公開文書がPangramで人間の執筆と判定されることを義務化するところまで踏み込んだという。
展望と示唆 — AIが正当な場面と、信頼が壊れる場面
興味深いことに、Breck自身はAIを執筆に幅広く使っている。彼は最近学術論文を書き、AIのおかげでプロセスがより速く、より楽しくなったと言う。しかし論文の一行たりともAIは書いていない。彼はLaTeXで自分で書き、AIには学術誌のスタイルガイドとテンプレート、その学術誌に掲載された既存の論文、論文が扱うソフトウェアのソースコード、本番デプロイの設定とログ、メトリクスを文脈として与えた。
彼のAIの使い方は一貫している。段落を一つ書くと、AIにソースコードや設定、ログを参照させてその内容が正しいかを検証させた。たとえば、データベースのどのカラムにインデックスが張られているか、Parquetファイルの行がどう並んでいるかを正しく記述できているかを確認させる。その間に彼は次の段落へ進んだ。引用情報の補完も任せた。本文に{TODO: reference the Amazon Aurora paper}のような指示を残しておけば、AIがBibTeXの項目を処理してくれた。スペルや文法の誤りを見つけることにかけては「容赦ない」ほど優秀で、長すぎたり不明瞭だったりする文を簡潔にする提案も良かった。TikZで技術的な図を描く作業も任せた。さらには、専門家のレビュアー4人が全員見落とした表記の誤り、つまりLSMのレベルをL2と書くべき箇所でL1と書いていたミスをAIが見つけた。
逆方向はどうだったか。彼が与えた文脈からAIに段落を書かせること、たとえばソースコードから何かの動作を説明させることは、一度も価値がなかったと彼は書く。読むのが一貫して不快で、しばしば不正確だった。例外は一つだけあった。アブストラクトである。論文の中で最も簡潔で、機械的で、非人間的な部分、文字通り最も抽象化された部分をAIは非常にうまく書き、彼はそれを修正なしで掲載した。
この経験から一本の境界線を引くことができる。AIが検証者、校正者、文献管理者、作図ツールとして使われるとき、人が書いた文章の正確さは高まる。このとき、テキストの主張と声は依然として書き手のものであり、AIはその主張が事実と合っているかを確かめるだけだ。逆にAIが主張そのものを生成すると、そのテキストは書き手の名前を掲げてはいても、書き手の思考を保証しない。アブストラクトが例外なのも同じ原理で説明できる。アブストラクトは既に人が書いた本文の要約であり、新しい主張を作らない。要約は、要約する原本が人の思考で満たされているときにのみ誠実である。
Grunewaldの線引きもほぼ同じ場所にある。彼は自分が反AI主義者ではないと明言し、音声の文字起こし、データ分析、情報検索、ブレインストーミング、草稿へのフィードバック、そして人が一つひとつ採否を判断するという条件付きの校閲は問題ないと言う。反対しているのはAIがテキストを書くことである。AIの出力を明示して引用すること、たとえば「Claude Fable 5によればこうだ」と書くことも、おおむね問題ないとする。読み手がその部分を各自で割り引いて受け取れるからだ。
反論もある。HNのあるユーザー(gfody)は、AIはこれまで声を聞くことのなかった多くの人に声を与えていると反論した。誰もが明晰な散文で考えるわけではなく、自分の気づきを共有可能な言葉として取り出すには労力が要るか、AIと気恥ずかしいほど長いやり取りを重ねて「そう、これが言いたかったことだ」と確認できる地点にたどり着く必要がある。そういう人たちも直接言えばもっと情熱的で継ぎ目の少ない文章になったはずだ、という考えは必ずしも正しくない、という主張である（直接の引用ではなく、コメントの要旨の要約）。事実を扱う文章なら事実の述べ方は限られており、最新のモデルでは人の文章とAIの文章を見分けることも難しくなっている、という反論(tygon)もあった（直接の引用ではなく、コメントの要旨の要約）。
そして、議論の中で繰り返し現れた皮肉がある。複数のユーザー(blandcoffee、almondfestival)が、Breckの記事そのものにある「こうしたドキュメントを読むことは単に難しいのではない—懲罰的なのだ」という一文こそAI特有の文型に見える、と指摘した（直接の引用ではなく、コメントの要旨の要約）。この指摘は冗談に近いが、実際の問題を浮かび上がらせる。「AIっぽさ」を文体で判定した瞬間、その判定は誤検出を生む。ダッシュを使う人は今や疑われる。文体の検出は信頼問題の解決策にはなり得ない、ということだ。Pangramのようなツールを公開文書に義務付けたOxideの試みがどこまで有効かも、現時点では判断するには早い。
実務的に残る問いはチームの規範である。idreynは、AIで文章を書くのを好む同僚にこの問題をどう切り出すかが悩みだと書いた。「slop」という言葉は刺々しく、それ自体が思考を止める決まり文句であり、「あなたが書いていない文章は読みたくない」にしても、もっと短く前向きな表現、たとえば「あなたから直接聞きたい」のような言い方が必要だというのである（直接の引用ではなく、コメントの要旨の要約）。この提案は問題の核心を突いている。規範は「AI禁止」ではなく、「誰が何を保証するのか」を問う形であるべきだ。PR説明なら、生成された変更点の一覧ではなく、作成者が自分で書いた三つの文、つまりなぜやるのか、何がリスクか、どこを見てほしいのかが求められるべきである。その三文はプロンプトで代替できない。それを知っているのは作成者だけだからだ。
結論
最初の問いに戻ろう。AIが書いた文章が拒まれるのは品質のせいか、保証の欠如のせいか。BreckとGrunewaldの記事を併せて読むと、答えは後者に近い。Grunewaldが解剖したClaudeの段落は「悪くなかった」。Breckが受け取ったPR説明は「細部が豊富だった」。問題は、そのテキストが何を主張しているのか、その主張に誰が責任を持つのかが見えないところにあった。
文章は長いあいだ、二つのものを同時に運んできた。情報と、その情報をまとめるのに誰かが時間と注意を費やしたというシグナルである。生成コストがゼロに収束するにつれ、二つ目のシグナルが崩壊した。読み手はもはや分量から労力を推し量れず、だからすべての行を疑いながら読むか、まったく読まないかになる。読むコストはそのままなのに、そのコストを正当化していたシグナルが消えたのだ。
Breckの経験が示した境界線は実用的である。AIが人の書いた文を検証し、校正し、整理する方向は、読み手のコストを減らす。AIが人の代わりに主張を生成する方向は、読み手のコストを増やす。同じ道具の、逆の向きである。
あなたが今週送ったドキュメントやPR説明のうち、相手に「この部分はどういう意味か」と聞かれたとき、プロンプトの履歴を開き直さずに答えられる文はいくつあるだろうか。
出典: