Simon WillisonがAIライティングの厳格な原則を支持：「書き換えは決して無損失ではない」
Simon Willisonは2026年8月11日、AI支援によるライティングにおける明確な対立を取り上げた。より速い書き換えは、気づかないうちに忠実性の低いコミュニケーションを生み出しかねないというものだ。
この主張は、ソフトウェアエンジニアのSophie Alpertによるものだ。彼女はClayでの勤務中に策定した社内ポリシーを公開した。このポリシーはAI支援を認める一方、最終文書のすべての文に対する責任を人間の著者に負わせている。
この基準は、大規模言語モデル、すなわちLLMに関する一般的な前提に異議を唱える。多くの人は、書き換えを、アイデアを保ったままトーン、構成、文法を改善する装飾的な操作として扱う。Alpertは、自然言語の変換はどれもそのようには機能しないと主張する。
あらゆる書き換えは、強調点、含意、リズム、または具体性を変える。その危険性は、書き換えを行うシステムが元の著者の詳細な思考モデルを持たない場合に高まる。
Willisonの支持が重要なのは、彼がソフトウェア開発におけるLLMの生産的な利用例を数多く記録してきたからだ。彼の支持はAI支援を否定するものではない。生産を加速することと、判断を外部委託することの境界線を引くものだ。
したがって中心となる対立は、人間による文章作成と機械による文章作成の対立ではない。利便性と忠実性の対立であり、その間には著者の説明責任がある。
Simon Willisonがエンジニアリング向けライティングポリシーを広める
直接の出来事は小さなものだが、そこで提案される基準は、エンジニアリング組織が作成するあらゆる文書に及ぶ。
8月11日、Willisonは自身のAIライティングに関するノートで、Alpertの6月25日のエッセイにリンクした。彼はこの短いポリシーを「本当に良い」と評し、その中核となる説明責任の原則を強調した。
AlpertはClayのエンジニア向けにこのポリシーを策定し、その後エンジニアリング向けガイダンスとして公開した。対象は、ブレインストーミング、下書き作成、校正、レビュー、文書の共有に及ぶ。
このポリシーは、それらの利用を禁止しているわけではない。むしろ、各アイデアと各文が著者の意図した内容を表していることを確認するよう、著者に求めている。
「ドキュメントにあるすべてのアイデアとすべての文に責任を持たなければなりません」とAlpertは書いている。この要件により、最初の下書きをどのツールが作成したかにかかわらず、文書を共有する人物が著者となる。
この原則はレビューの場面で具体性を持つ。同僚からある文の意味を尋ねられても、AIシステムのせいにしても混乱は解消しない。その表現を選び、配布したのは著者だからだ。
この区別が重要なのは、エンジニアリング文書がしばしば重大な業務を調整するためである。技術仕様書は実装を導き、インシデントレビューは将来の安全策に影響を与え、ステータス更新は人員配置やスケジュールに関する判断を左右する。
カジュアルなメッセージにある曖昧な一文は、短い誤解を招くだけかもしれない。しかし技術仕様書の曖昧な要件は、コード、テスト、インターフェース、運用手順へと広がり得る。
Alpertのタイトルは、このリスクの仕組みを捉えている。自然言語の変換が無損失ではないのは、表現には明示的な事実以上のものが含まれるからだ。
文の順序は優先順位を決める。例は解釈の範囲を限定する。限定表現は確信の度合いを示す。削除された留保は、暫定的な観察を、確約のように見せてしまうことがある。
LLMは、こうした要素のいずれかを変えながら、より洗練された文章を作成できる。結果はより整って聞こえるかもしれないが、著者をより正確に表すとは限らない。
だからこそ、流暢さは忠実性の弱い証拠にすぎない。読みやすい段落であっても、主張のずれ、裏付けのないつながり、誤った強調を含む可能性がある。
Willisonが重視するのは、単なる開示ではなく責任の所在だ。AIが下書きに関与したことを明示すれば透明性は高まるかもしれないが、それだけで誤解を招く文書が有用になるわけではない。
読者には、信頼できる文書が依然として必要だ。また、その論理を説明し、主張を擁護し、異議を受けた際に修正できる著者も必要である。
したがってこのポリシーは、完成の基準を変える。文書はモデルが書き終えた時点で完成ではない。著者が全体を理解し、受け入れた時点で完成する。
より速い下書き作成は読者へ負担を移す
AI生成文の長さは、著者が数分を節約する代わりに、組織全体の注意を何時間も消費する場合、隠れた組織コストを生む。
Alpertは、著者は各読者が読む時間よりも長く、文書の作成に時間をかけるべきだと主張する。この原則は、職場における文章作成の非対称な経済性を反映している。
技術文書を作成するのは通常1人だ。一方で、それを読む必要があるエンジニア、マネージャー、デザイナー、顧客は複数いる場合がある。
著者にとっての5分の近道が、各受信者に数分の追加負担を課しかねない。大規模なレビューグループ全体では、節約された労力は純損失になる。
この問題は、誰かがLLMに短いプロンプトを与え、ほとんど修正せずに長い応答を配布する場合に現れる。著者は事実上、解釈を読者に委ねている。
読者は、実際の決定事項を見つけ、証拠と冗長な記述を切り分け、どの文が著者の立場を示しているのかを判断しなければならない。生成中に持ち込まれた矛盾を解消する必要もあるかもしれない。
文書は文法的に正しくても、この負担を課し得る。問題は必ずしも悪い文章ではない。不確かな意図にある。
エンジニアはすでに情報が過密な環境にいる。プルリクエスト、チケット、設計文書、チャットスレッド、ダッシュボード、インシデントチャンネルの間を行き来している。
もっともらしいが十分にレビューされていない文章を加えることは、判断を必要とする資料の量を増やす。それが有用な知識の量を自動的に増やすわけではない。
これは個々の貢献者だけでなく、エンジニアリングリーダーにも圧力をかける。文書量がコミュニケーションを測るものなのか、それとも単にツールの出力を記録しているだけなのかを判断しなければならない。
読者の負担を測定せず、より速い下書き作成を称賛するポリシーは、目に見える生産を優遇する。その生産物を解釈、検証、修正するために必要な下流の作業を見落としている。
Alpertの基準は、このインセンティブを反転させる。すべての読者がその後に恩恵を受けるため、著者は文書を簡潔にする一度きりのコストを負担すべきだ。
同じ論理は、Atlassianが2026年6月に公開したライティングガイドラインにも見られる。同社のブランドチームは、一般的で未検証の資料が、画像の複製が繰り返されるように、社内のナレッジシステムを劣化させると警告している。
この比較は、第二のコストを示している。質の低い文書は、一度読まれた後に消えるわけではない。組織はそれらを検索インデックス、ナレッジグラフ、プロジェクトアーカイブ、AI検索システムに保存する。
一度保存されると、歪められた要約が後の意思決定に影響を及ぼす可能性がある。別のモデルがそれを取得して再び圧縮し、元の文脈なしに結果を提示するかもしれない。
その結果、組織は損失を伴う変換の連鎖に直面する。各段階で留保が失われる一方、組織的な権威があるように見える度合いは増していく。
個人のナレッジシステムも同じ課題を抱える。意思決定に至った理由を要約が保てないなら、すべてを記録しても価値はほとんどない。
優れたナレッジマネジメントは、来歴、文脈、検索の質に依存する。文章量を増やすだけでは、そのいずれも得られない。
この負担は、大規模に文書を消費する人々に最も重くのしかかる。スタッフエンジニア、セキュリティレビュー担当者、経営幹部、インシデントコマンダーは、異なる著者による多くの成果物をレビューすることが多い。
彼らは、すべての著者の隠れた意図を再構築することはできない。提出された文書自体に、関連する区別が含まれている必要がある。
これが、「AIが書いた」という説明が成り立たない理由だ。それは作成方法を示すだけで、読者の問題を何も解決しない。
求められる対応は、一律の禁止ではない。チームには、AI出力を、責任ある著者が自らのものとして引き受けるまでは未完成の素材として扱うレビュー基準が必要だ。
事実が保たれていても、AIによる書き換えは意味を変える
中核となるトレードオフは単純だ。書き換えは表面的な明瞭さを高められる一方で、言葉と著者の実際の思考モデルとのつながりを弱める可能性がある。
自然言語は、構造化データ形式ほど明確には、内容と表現を分離しない。語の選択と構成は、文が何を意味するかを決める助けとなる。
たとえば、あるエンジニアが「キャッシュがレイテンシ急増の原因だった可能性は高いが、デプロイ変更も別の有力な要因として残っている」と書いたとする。
書き換えツールは、「レイテンシ急増はキャッシュが原因だった」と返すかもしれない。この文はより短く、自信に満ちている。しかし、別の主張でもある。
別の書き換えでは両方の要因を残しつつ、デプロイを先に置くかもしれない。その変更は、どの調査に注目が集まるかに影響し得る。
中立的に見える要約でさえ、何を省くかを選んでいる。結論を維持しながら、その結論を正当化していた証拠、不確実性、または退けられた代替案を削る可能性がある。
プロンプトが大まかなアイデアしか提供しない場合、変換はより危険になる。モデルは、著者が明示したことのないつなぎや前提を補わなければならない。
そうした追加によって、筋の通った議論に見えても、実際には十分に考え抜かれていない議論が生まれ得る。すると一貫性が、著者性の欠落を隠す。
Alpertは、書くことを思考の一形態として説明する。主張を並べ、例を選び、反論に対処する作業は、根底にあるアイデアの欠陥を明らかにし得る。
この作業を省けば、混乱を残したまま下書き時間を節約できる。著者は、完成した議論を構築する前に、完成したように見える成果物を手にすることになる。
この懸念は、エンジニアリング仕様書に特に関係する。仕様書はコミュニケーションであると同時に、誰かが制約、代替案、失敗ケースを検討した証拠でもある。
AIシステムはその文書の形を模倣できる。目標、アーキテクチャ、セキュリティ、移行、未解決の問題に関するセクションを作成できる。
しかし、その構造は著者がそれらの主題を評価したことを証明しない。完全なテンプレートは、不完全な思考を隠すことがある。
したがってこのポリシーは、支援と代替を区別する。ブレインストーミングは代替案を示せる。校正は不自然な箇所を見つけられる。下書きは、著者が出発点を見つける助けになる。
しかし人間はなお、どの主張を含めるべきか、それらが何を意味するのか、そして文書が読者の時間に値するのかを判断しなければならない。
これは、事実に関するハルシネーションだけの問題ではない。モデルは、名前の挙がるすべての事実を保ったまま、強調によってメッセージを歪めることができる。
警告を和らげたり、予測を強めたり、不都合な例外を削ったり、正確な用語をより広い同義語に置き換えたりする可能性がある。
トーンの変換にも意味がある。率直な反対意見を丁寧な企業風の表現に書き換えると、元のメッセージにあった緊急性や確信が隠される可能性がある。
翻訳にも関連するリスクがある。翻訳された文は中心的な命題を保っていても、文化的なニュアンス、技術的な正確さ、あるいは推奨の強さに対する受け止め方を変えるかもしれない。
こうした変換は有用になり得る。単に、無償ではないということだ。
書き換えを受け入れる著者は、出力を文法規則だけでなく、意図した意味と照らし合わせる必要がある。そのためには、注意深い読解と主題に関する知識が求められる。
生成された文章が長くなるほど、このレビューは難しくなる。著者は見慣れた文章を流し読みし、小さな意味上の変化を見落とすかもしれない。
洗練された文体は、自動化バイアスを生み出す。これは、システムが自信を持って出力したという理由で、その内容を信頼してしまう傾向だ。流暢さはそのバイアスを強める可能性がある。
意味の損失は、その後の検索も複雑にする。検索・要約システムは、しばしばニュアンスのある議論よりも、簡潔な断定文を上位に表示する。
その簡潔な文が原典を誇張していれば、将来の読者はまずその歪曲に触れるかもしれない。変換後の版が、組織の記憶において実質的に原文を置き換えてしまう可能性がある。
「lossless transformations は存在しない」という表現は、すべての文を永遠に保存せよという要求として読むべきではない。編集は依然として必要であり、人間による編集も意味を変える。
違いは説明責任にある。人間の著者は、どの意味を残し、磨き、取り除くかを意図的に決められる。
LLMは、著者の完全な目的を持ち合わせていない。利用可能な文脈から、もっともらしい続きを推定する、あるいは書き換えるだけだ。
その仕組みは優れた文章を生み出せる。しかし、著者の頭の中にしか存在しない、明示されていない意図との整合性を保証することはできない。
AIらしい文章の検出よりも説明責任が重要
チームが得られる価値は、どの文がモデル由来かを見極めようとすることより、最終的な主張への責任を割り当てることのほうが大きい。
AIライティングを巡る議論の多くは、検出に焦点を当てている。レビュー担当者は、繰り返し使われる表現、均質な構成、水増しされた接続表現、見慣れた文体パターンを探す。
こうしたシグナルは、ガバナンスの基盤として信頼できない。人間の著者もありふれた文章を書くことがあり、一方で慎重にモデル支援を使った文章は明白なパターンを避けられる。
検出はまた、誤った成果に狙いを定めている。運用上の問いは、その文書が正確で、目的にかなっており、説明可能で、読む価値があるかどうかだ。
完全に人間だけで作成した草稿でも、これらの基準を満たさないことはある。著者がすべての部分を慎重に検証し、自身のものとして採用していれば、大きく支援を受けた草稿でも合格できる。
だからといって、開示が無関係になるわけではない。読者が制作過程を理解したり、利益相反を評価したりする必要がある場面では、開示が求められる。
学術出版はその一例だ。Elsevierの現行の著者の説明責任に関する規則は、人間による監督、検証、開示を求めながら、支援的な利用を認めている。
同社の方針は、AIツールには著者資格を与えられないとも述べている。著者資格には人に帰属する責任が伴うためだ。この考え方は、Alpertの職場における基準と密接に一致している。
報道機関も同様の立場に至っている。Associated Pressが更新したニュースルーム基準は、編集上の監督と確立された取材要件を維持しつつ、限定的な支援を認めている。
これらの方針は対象範囲こそ異なるが、実践的な洞察を共有している。ツールは、公開された主張に対する職業的な説明責任を引き受けることはできない。
エンジニアリングチームは、この洞察をレビュー行動に落とし込める。記名著者または文書オーナーは、生成された一節を切り離せる偶発的な産物として扱わず、質問に答えるべきだ。
レビュー担当者は、根拠のない確信、欠けている証拠、曖昧な推奨に異議を唱えるべきである。限られた注意力を、どのツールが文章を生成したのか推測することに費やすべきではない。
組織は機密情報も守る必要がある。チームは正確な文章を作成できても、機密コード、顧客データ、社内計画を不適切なサービスへ送れば、方針に違反する可能性がある。
この問題は、意味的忠実性を置き換えるものではなく、それと並存するものだ。責任あるAIライティング方針は、情報の取り扱いと最終的な著者責任の両方を対象にしなければならない。
Fast Companyの編集方針は、このより広いアプローチを示している。実質的な人間による編集を求め、ツールの保存設定、機密コンテンツ、説明責任も扱っている。
難しい問いは、何が十分なレビューに当たるかだ。ざっと読むだけでも、段落がもっともらしく聞こえることは確認できるが、すべての含意を確認できるわけではない。
チームは、この閾値に完璧な数値テストがあるふりをすべきではない。レビューの深さは、文書の目的と起こりうる結果に依存する。
気軽な会議の要約は、インシデント報告書ほど厳密な確認を必要としない。顧客向けのセキュリティ声明は、社内のブレインストーミング用メモよりも多くのレビューを要する。
最も安全な原則は、影響に応じて責任を拡大することだ。著者は、誤解を招く文が引き起こしうる害に応じて、事実、主張、約束を検証すべきである。
明確な来歴情報は、このプロセスを支えられる。チームは、結論がどのように形成されたかを明らかにする場合、ソースノート、意思決定記録、リンクされた証拠、以前の草稿を保存できる。
検索可能な技術ナレッジベースは、要約の近くにソース文書を置いておける。この近接性は、読者が圧縮された文章だけを信頼するのではなく、文脈を確認する助けになる。
それでも、オーナー自身が理解していない文書を来歴情報が救うことはできない。リンクは証拠を提供するが、その証拠が何を裏付けるのかを判断する者は必要だ。
Alpertの方針に対する懐疑的な見方として、文単位の所有責任を求めることは有用な支援を妨げるかもしれない、というものがある。構成面や表現面の支援を受けることで、よりよく伝えられる書き手もいる。
英語を母語としない人々は、明瞭さを改善するツールからとりわけ恩恵を受ける可能性がある。障害のある人々は、アクセシビリティ支援として生成や書き換えを利用することがある。
こうした利点は現実のものであり、この方針は支援なしの執筆を求めてはいない。最終成果を理解したうえで採用することを求めている。
しかし、すべての文をレビューする負担は、ゼロから書く負担に近づくことがある。一部の作業では、そのことが効率上の利点を減らす。
それは必ずしも、このルールの欠陥ではない。それは、主張される生産性が、認知的作業を読者やレビュー担当者に移すことで得られていた箇所を明らかにする。
不確実なのは、将来のシステムが忠実性を損なわずにこのレビュー負担を減らせるかどうかだ。より優れた文脈、ソースへのリンク、追跡可能な意味的変更が役立つかもしれない。
これらの機能のいずれも、著者が一度も表現していない意図を完全に観測することはできない。著者は検証ループの一部であり続けなければならない。
この方針はAI禁止よりも優れた境界線を引く
有用な方針は、LLMとのあらゆるやり取りを同一視するのではなく、許容される支援と所有されていない出力を区別する。
一律の禁止は、表明するのは簡単でも、施行するのは難しい。AI機能はすでに、エディタ、コミュニケーションプラットフォーム、検索ツール、オペレーティングシステムに組み込まれている。
禁止は、非常に異なる行為も一括りにする。文法チェックは、一行のプロンプトからインシデント分析を生成することと同じリスクを伴わない。
Alpertの枠組みは、ブレインストーミング、下書き、校正を許可している。その境界は、内容が他者に向けた主張になる時点にあるように見える。
このアプローチは、識別可能なオーナーを維持しながら、エンジニアに柔軟性を与える。また、チームがすでに他の形態の協働を扱っている方法にも合致する。
エンジニアは同僚から修正を受けられるが、文書オーナーが最終版を承認する。レビュー担当者の提案によって著者資格が自動的に移るわけではない。
同じ論理をLLMにも適用できる。その提案は、著者が検討して採用するまで、提案された表現にとどまる。
チームは、いくつかのレビュー質問を通じて、この境界を具体化できる。
著者はすべての主張を理解しているか。著者は各セクションが存在する理由を説明できるか。不確実性と代替案は正確に表現されているか。
その文書は、重要な意思決定に必要な証拠を引用しているか。より短い版のほうが読者に役立つか。
これらの問いは、草稿作成過程を法医学的に再構築せずに出力を評価する。また、AIを使わずに作られた文書にも有効だ。
モデルが既存の文章を書き換える場合、変更履歴が役立つ。著者は、記憶だけで二つの長い文書を比較するのではなく、削除、追加、変更された限定表現を確認できる。
不確実性を維持するようモデルに指示すれば、明白な歪曲を減らせる。ソース資料を提供することも、根拠のない追加を見つけやすくする。
どちらの手法も、変換をlosslessにはしない。人間によるレビューの条件を改善するだけだ。
より強いワークフローでは、著者は具体的なメモ、決定、証拠から始める。モデルはその後、すでに十分な思考を反映した材料に取り組む。
これは、短いプロンプトから完全な仕様書を要求することとは異なる。前者のワークフローは表現を支援する。後者は、推論の大部分をモデルに発明させる。
この区別は常に明確とは限らない。草稿作成と思考は相互に作用し、モデルが生成した問いが本物の洞察を引き起こすこともある。
所有責任のルールは、作業の一覧表よりもこの曖昧さをうまく扱える。どのような経路で洞察が得られたとしても、著者は最終的な記述を理解し、擁護しなければならない。
マネージャーも、文書の処理量だけで成功を測るべきではない。仕様書、更新、要約が増えても、意思決定がより速く、より良くなるとは限らない。
有用な指標には、レビュー時間、確認依頼、再開された意思決定、事実訂正、下流工程での実装エラーが含まれる。
方針は、低リスクの例外も定義すべきである。ツールが生成したアイデアをチームで検討したいときは、明確に表示されたモデル出力が有用な場合がある。
Alpertは、それがAI出力であると明示される場合、AI出力の逐語的な掲載を明確に認めている。読者はそのとき、著者の確定した立場ではなく、提案を評価していることを理解できる。
そのラベルは、会話上の契約を変える。著者は、自らの推論の所有を主張するのではなく、議論の対象を提示している。
この区別は、よくある失敗を防ぐ。チームは、正式な文書に記載されているというだけで、暫定的な生成テキストを意思決定記録として扱うべきではない。
したがって、最良の境界はコミュニケーション上の地位に依存する。草稿、質問、実験は暫定的なままにできる。
仕様書、振り返り、推奨、公開声明には、説明責任を負うオーナーが必要だ。それらの表現は行動を導き、組織の記憶を形づくる。
Simon WillisonのAIライティング規則が注視するもの
次の試金石は、エンジニアリングチームが、より整った文章をより速く作るだけでなく、意図を保持するワークフローを構築するかどうかだ。
最初のシグナルは、エンジニアリング組織内で明示的な著者責任ルールが広がることだ。有用な方針は、生成された主張の責任者と、レビュー完了の意味を特定するだろう。
より多くのチームがこの基準を採用すれば、WillisonとAlpertの議論は実践的な裏付けを得る。それは、組織が意味的忠実性を運用上の問題と見なしていることを示すだろう。
より軽いレビューで、訂正の増加もなく、チームが信頼できるコミュニケーションを実現できるなら、この判断は弱まる。その結果は、現在の懸念がコストを過大に見積もっていることを示唆するだろう。
二つ目のシグナルは、意味的レビューに対するプロダクト支援だ。ライティングツールは、変更された主張、削除された限定表現、根拠のない追加、変更された確実性を示せる。
通常の変更履歴は、変更された単語を明らかにする。より有用なシステムは、提案された書き換えが論旨をどのように変えたかを説明するだろう。
こうした機能が信頼できるものになれば、AI支援は変換を隠さずに時間を節約できる。著者は依然として出力に責任を負うが、より効果的に確認できるようになる。
ツールが透明な証拠なしに意味の保持を主張するなら、この議論は弱まる。確信度ラベルだけでは、書き換えが著者の私的な意図と一致することを証明できない。
三つ目のシグナルは、下流工程における文書の品質だ。チームは、確認の件数、レビュー期間、インシデントのフォローアップ、要約とソース記録の間の矛盾を注視すべきである。
洗練された文書が増える一方で訂正も増加するなら、情報損失を伴う変換という仮説を支持することになる。表面的な品質が、コミュニケーション上の負債を覆い隠していたことを示すからだ。
成果が安定、あるいは改善していたとしても、書き換えに情報損失がないことの証明にはならない。それは、人によるレビューとより優れたツールによって、その損失を適切に管理できることを示すにとどまる。
読者は、AIによる検索・取得が状況の重要性をどう変えるかにも注目すべきだ。社内アシスタントは、保存された仕様書、会議メモ、進捗報告書をもとに質問へ答える機会が増えている。
そのため、弱い文書は本来の読者だけに影響するわけではない。将来生成される回答のために検索・参照される根拠となり得る。
この増幅効果により、情報源の品質は重要になる。組織には、レビュー済みの決定事項と暫定的な下書き、生成された提案とを区別する手段が必要だ。
Simon Willisonの提言は、こうした環境に役立つ基準を示している。役立つ場面ではAIを使う。ただし、生成された流暢さを、自らが採用した考えと混同してはならない。
AI支援で作成した文書を共有する前に、モデルへ責任を戻すことなく、すべての行を説明できるか自問してほしい。そして、擁護できない内容は削除する。
重要な主張を支える証拠を残し、不確実性を見える形に保ち、判断を支えるために必要最小限の文書を読者に提供する。最終的な文章は、自分自身の仕事として扱うべきだ。
実務上の問いは、AIが文書に関与したかどうかではない。あらゆる変換を経た後も、その文書があなたの意味を保っているかどうかである。
