9月22日、ソフトウェアエンジニア・技術ライターのPaul Bakkerが「Don't use AI to write」と題した記事を公開した。生成AIを文章作成に使うことで思考プロセスそのものを失うリスクと、AIを正しく活用するフェーズの分け方について論じている。
BakkerはClaude・ChatGPT・Geminiを日常的に使う自他共に認めるヘビーユーザーだ。コーディング、リサーチ、データ分析など幅広く活用する一方で、文章を書くことだけは例外だと明言している。生成AIが職場のあらゆる文書作成に浸透しつつある今、この主張は多くのエンジニアや知識労働者にとって無視できない問いを投げかけている。
「書くこと＝考えること」という前提
Bakkerの主張の核心はシンプルだ。「書くこと」は「考えること」と不可分であり、AIに文章を生成させると思考のプロセスごとスキップしてしまう、というものだ。
具体的なシナリオとして、こう指摘している。箇条書きのメモをAIに渡して文書を生成させると、アウトプットは「それなりに良く見える」。ほとんどの人はそれを軽微な修正だけで受け入れるだろう。しかし、本質的な問いに深く向き合ったかどうかは確認しようがない。思考を外注した時点で、その機会は失われている。
「AIツールの問題は、文章が下手なことではない（むしろ逆だ）。AIは新しいアイデアを生み出す思考が苦手なのだ。そこにこそ、あなたの出番がある」
60ページの「フワっとした」戦略文書と、3ページの「本質を突いた」戦略文書、どちらが組織の役に立つか——という問いかけは、エンジニアリング組織のドキュメント文化を考えるうえで鋭い視点だ。表面上きれいに見えるAI生成の文書ほど、思考の浅さが見えにくくなる点は特に注意が必要だ。
使っていいフェーズ、使ってはいけないフェーズ
Bakkerの主張は「AIを一切使うな」という原理主義ではない。使うフェーズを分けろというのが核心だ。
使ってはいけない：文章を「書かせる」こと
- 箇条書きから文書を生成させる
- 文章の「改善」や「修正」をAIに任せる
これらはいずれも、自分の思考をAIに代替させる行為だと位置づけている。
使っていい：書き上げた後に「問い直す」こと
初稿が完成した後、Bakker自身が使うプロンプトの例として以下を挙げている：
"Read this doc, what questions would you have?"（読んで、どんな疑問を持つか教えてほしい）"What is the most important take away in this doc?"（この文書の最も重要な要点は何か）
これは同僚にプルーフリードを頼む行為と同じだという。ただし、フィードバックをもらったら、どう対応するかは自分で考える。AIに「直させる」のではなく、あくまで問いを返してもらうだけだ。
使っていい：書く前の情報整理
文章を書く前段階——データの精査、パターンの抽出、問題の構造化——はAIが得意とする領域だ。問題を深く理解するためにAIを使い、解決策を考えるのは自分でやる、という役割分担を提案している。
エンジニアリング組織のドキュメントへの示唆
「生産性＝最短時間で最多アウトプット」という発想への反論は、コードの文脈でも馴染み深い。コード行数を最大化することがエンジニアリングの価値ではないのと同様に、ドキュメントの量を最大化することに価値はないという主張は論理的に一貫している。
技術仕様書、設計ドキュメント、ポストモーテム、ADR（Architecture Decision Records：アーキテクチャ上の意思決定を記録する軽量ドキュメント）——こうした文書こそ、書き手の思考の質がそのまま組織の意思決定の質に直結する。生成AIが文書作成の「省力化ツール」として当たり前になりつつある今だからこそ、何をAIに委ねて何を自分でやるかの線引きを意識的に持つことが求められる。
詳細はDon't use AI to writeを参照していただきたい。
