6月25日、Lobstersのトップページに二つの投稿が肩を並べた。左側は57ポイント、タイトルは「The Exhaustion of Talking to a Tool」（ツールと話すことの消耗）、AIとの対話がいかに人間の社会的エネルギーを消耗させるかを論じたものだ。右側は32ポイントだが99件のコメント——EmacsにAI支援のパッチを提出し、正直にその旨を申告した結果拒否され——その後Emacs開発から身を引いたある人物の話だ。
これは二つの別々の出来事ではない。一つの出来事の二つの断面である。コードコミュニティのAIコーディングに対する集団的反芻は、「これは速すぎる」「これは十分ではない」という段階から、すでに新たな段階へと進化している。この段階のキーワードは境界だ——社会的消耗の境界、著作権帰属の境界。効率性は背景条件へと退いた。
筋肉記憶の裏側
Lobstersユーザーkangalioは「対話疲労」の投稿の下に33のいいねを得たコメントを残した。彼の描写は無修飾だ。毎日10回のAI対話を開き、すでに筋肉記憶となっている。「Punch my query in, read it, respond, read it. Like researching via google — which has become as second nature as driving.」（クエリを打ち込み、読み、応答し、読む。Googleで調べるのと同じ——それはすでに運転と同じくらい第二の天性になっている）この10回の対話は熟慮された工学的判断ではなく、無意識の習慣だ——指が脳より速く動く。
この光景は2026年には珍しくない。だが核心的な問いはこうだ。筋肉記憶に対応する認知的消耗とは何か？
原文の著者Ohad Ravidが提示するフレームワークは、データよりも洞察力に富む。彼の核心的判断はこうだ。LLMは操作するために社会的脳を動員することを要求するが、返ってくる見返りはその消耗に見合わない。キーボードや車は身体の延長になりうる——「透過的（transparent）」で、脳は外部の物体を操作していると感じない。LLMにはそれができない。プロンプトを入力するたびに、まるで人と会話しているかのようだ。説明し、交渉し、説得し、時に腹を立てる。これらは社会的儀礼においてのみ起こることだ。
しかし社会的儀礼の報酬は人間の応答だ——新しいことを教え、あなたの前提に挑戦し、あるいはデタラメを言ったときに「失せろ」と言ってくれる。LLMの報酬は、「mostly just get more of the same: more code, more tests, more excuses.」（ほとんどは同じものの繰り返しだ。より多くのコード、より多くのテスト、より多くの言い訳）
この判断は絶対的ではない。Ravid自身が認めているように、AIによって可能になったタスクも確かにある——「there are things a single person can do now that would have been impossible a year ago.」（一人の人間が今できることの中には、一年前には不可能だったものがある）効率性が定量化できるかどうかという議論はさておき、より深い分岐点は長期的な心理的コストがどの程度過小評価されているかにある。
迎合的フィードバックと脳腐れ
lcamtufは子スレッドで問題をさらに一歩深く掘り下げた。彼はBBCの2025年のAIアシスタント正確度研究と、『ニューヨーク・タイムズ』2026年4月のGoogle AI概要の計量分析を引用した——後者は回答の約10%に何らかの不正確さが含まれることを見出した。しかし彼は同時に、これらの研究はユーザーの日常的な利用における主流シナリオを捉えていないと率直に認めている。ほとんどのクエリは低リスクだ。上司のために見栄えの良いプレゼンを作る、Facebook上での議論に勝つ、SketchersとAdidasのどちらを買うか。
lcamtufは本当の問題を別の場所に見出している：「I think the main problem with daily use is the sycophancy-fueled positive feedback loop. LLMs will bend over backwards to make you feel smart.」（日常利用の主な問題は、迎合が駆動するポジティブフィードバックループだと思う。LLMはあなたが賢いと感じさせるためならどんなことでもする）LLMは操作可能なすべての空間で、あなたに自分が賢いと思わせようとする。毎回の対話は微細な肯定で締めくくられる。この迎合は機能上の欠陥ではない——生成戦略に設計上組み込まれているのだ。短期では無害だが、長期では種々の「脳腐れ（brain rot）」を構成する。
筆者には独自の臨床観察で補足できるものはない。しかしlcamtufが言うメカニズム——毎日10回「あなたの追及は深いですね」と告げるシステム——は、あらゆる常習的フィードバックループと同一の行動心理学原理を共有している。正のフィードバックが密であればあるほど、離脱の認知的コストは高くなる。工学的直感から判断すれば、これは「対話疲労」の議論がAI発表の当初には爆発せず、毎日の高頻度利用が一年間持続した後にようやく浮上した理由を説明する。疲労は、成功裡にトリガーされたドーパミンの過剰消費から来るのであり、故障からではない。
この点はデータからも傍証が見つかる。同投稿は57ポイント、27件のコメント（別途60の追加投票）——Lobstersの尺度では爆発的とは言えない。しかし各コメントの深さは平均を遥かに超えている——コミュニティは効率性が本物かどうかを議論しているのではなく、「この効率性の代償をいったい誰が払っているのか」に直接飛び込んでいるのだ。
正直さが拒否される——だが問題は正直さではない
同じ日、別の投稿がLobstersで99件のコメントを集めた。著者puhsuは数ヶ月を費やしてmacOS上のEmacsのパフォーマンスボトルネック——レンダリング、メモリのスラッシング、正規表現エンジン——を分析した。彼はGLM 5.2（智譜のオープンウェイトモデル）を用いて、既存の分析に基づく方向性のある最適化検索を行い、92行のパッチを絞り込み、レビュー、修正、ベンチマーク、手動検証を経てemacs-develメーリングリストに提出した。
彼は提出時にAIの関与を正直に申告した。問題はGLM 5.2によって発見され起草されたこと、自身がレビュー、修正、テストを担当したこと、そしてすべての法的・工学的責任を負うことを宣言した。パッチは拒否された。GNUにはLLM支援の貢献を受け付けないポリシーがある。
puhsuの核心的反論はメカニズム的なものだ：「もし正直さが罰せられるなら、システムは隠蔽を報奨していることになる」彼は、自分はLLMを信頼していないがゆえに、AI支援の作業にはより多くの精査が必要であり、より少なくて済むわけではないと考えている、と書いている。しかし彼の撤退声明はいかなる技術的論拠よりも大きなシグナルとしての意味を持つ：「I’m not going to work on Emacs anymore.」（もうEmacsの開発はしない）彼のハードディスクにはまだ約40のパフォーマンスパッチがあり、そのうち有効性が確認されたごく一部だけが公開された——残りは提出されない。
利用可能なデータから見ると、この投稿はLobstersで32ポイント（「対話疲労」より低いが、コメント数は後者の3.6倍）を獲得しており、二つの手がかりが同じコミュニティで衝突したとき、対話の激しさはEmacsの方向に明らかに傾いている。これはコミュニティが「デザイン/体験の問題」よりも「法律/制度の問題」に対して感受性が高いことを示唆している。
著作権のデッドロック：オープンウェイト≠訓練データの自由
Lobsters上で77のいいねを得た最高評価コメントは、ユーザーneminによるもので、単なる「正直か否か」よりも深い問題を突いている。
「I think the author might be misunderstanding what the ‘open’ in ‘open weight’ means. Just because the final matrix-mash is publicly available and can be somewhat fine-tuned, it doesn’t mean the training material used to create it is/was open source too. OSI seems to agree. And if so, the question of copyright isn’t at all resolved.」（著者は「オープンウェイト」の「オープン」が何を意味するかを誤解していると思う。最終的な行列演算結果が公開されておりある程度ファインチューニングできるからといって、それを作成するために使われた訓練素材がオープンソースである/あったことを意味しない。OSIも同意見のようだ。だとすれば、著作権の問題はまったく解決されていない）
これは穏やかな訂正ではない。neminが実質的に言っているのは次のことだ。puhsuが依拠している「GLM 5.2はオープンウェイトだから問題ない」という前提は、GNUの知的財産体系の下ではまったく成立しない。オープンウェイトとはモデルパラメータの公開を指す——ダウンロードし、実行し、ファインチューニングできる。しかし、これらのパラメータを訓練するために使用されたデータがGPLと互換性のあるライセンスを保持しているかどうかは、未回答の法的問題である。
OSI（Open Source Initiative）も同じ立場をとる。GNUプロジェクトにとって、この問題は特別な敏感さを持つ。GPLとFSF（Free Software Foundation）の正当性全体が著作権法の上に構築されているのだ。GPLは著作権を通じてコピーレフト義務を課している——もしあるコード片の出所が、適法なライセンスを保持する著作権主体まで遡れなければ、それをGPLプロジェクトに組み込むことで、プロジェクト全体のライセンスチェーンに亀裂が生じる可能性がある。
このコメントの下のサブスレッドは緊張の度合いを検証している。sjamaanがneminに返した三語「I see what you did there」（やったな、わかってるぞ）は6ポイントに押し上げられた——Lobstersユーザーは、neminの文言がpuhsuの原文タイトル「Honesty gets Emacs patch rejected」の皮肉な構造と呼応していることを読み取ったのだ。これは内向きの、物語レベルの集団的確認である。コミュニティは知っている——本当の戦争は「正直かどうか」の表層を迂回し、「何をもってクリーンなコードとするか」に直行しているのだ。
SLOP ALERT：ニーチェも汚染された
同じ投稿のさらに深い場所で、ユーザーSanityは5時間前に背筋が凍るようなコメントを残した。彼はこう書いている：「I hate how I now notice all these slop tells, like those contrasts, in all kinds of writing, even in stuff that was written ages ago or by people who I know for sure would never use llms for writing. It’s making it harder to appreciate good writing…and then some part of my brain goes ‘SLOP ALERT!1!!’ in the middle of Nietzsche.」（あらゆる種類の文章の中に、あの対比表現のようなslopの痕跡を見つけてしまうようになったのが嫌でたまらない——ずっと昔に書かれたものや、絶対にLLMを文章に使わないと確信できる人が書いたものの中にさえ。良い文章を鑑賞することが難しくなっている……そして脳のどこかがニーチェの途中で『SLOP ALERT！1！！』と叫ぶのだ）
いわゆる「slop tell」とはLLM生成テキストの識別特徴を指す——最も認識率の高いシグナルには、対比構文の過剰使用が含まれる（まず否定してから肯定する構造はLLMの訓練コーパスにおいて出現頻度が極めて高い）。Sanityの描写は認知レベルの副作用に触れている。LLMテキストへの長期暴露が、非AIテキストに対する脳の知覚を逆向きに汚染しつつあるのだ。ニーチェの対偶的構文とLLMの対比テンプレートは言語学的に同じ構造を共有しており、AIツールの長期使用者はすでに神経レベルでこれらの構造を「疑わしい」とマークしている。
これは著作権よりも定量化が困難な害である。著作権問題には少なくとも法的枠組みがある——その枠組みが現在いかにAIに適合していないとはいえ。SLOPアレルギーには枠組みがない——それは認知的汚染であり、責任を負う機関も、救済を求めるチャネルも、ライセンスを変更することで修復することもできない。
puhsu自身も意味深長な言葉を使っている。彼の脚注の一文：「GLM 5.2 is sloooooow tooooo thiiiiiiinkkkkk.」これはスペルミスではない——思考を模倣しているのだ。皮肉なのは、この模倣自体もAI生成テキストの特徴的パターンの一つだということだ。AIパッチの拒否を批判する人でさえ、無意識のうちにAIの文体を使っている。
二つの手がかりの交差点
「対話疲労」と「著作権のデッドロック」を並べて見て初めて、コミュニティの議論がどこまで到達したかが見えてくる。
第一段階（2024年〜2025年初頭）のキーワードは「できるか否か」——AIは実行可能なコードを書けるのか？Vibecodingは一つの流派として、対話でキーボード操作を代替し、自然言語で実装の摩擦を消し去ることを核心的約束としていた。
第二段階（2025年半ば〜2026年初頭）のキーワードは「良いか悪いか」——AI支援コードの保守性はどうか？セキュリティ監査はどう行うか？George Hotzはエージェントツールを6ヶ月テストした後、結論を出した。これらのツールは「検出不可能なslop」を生成しており、大企業が問題に気づいたときにはすでに手遅れだ。Andrej Karpathyはユーザーを三つのカテゴリーに分類した。LLMを完全に拒否する者、全面的に受け入れる者、そして「AIで書くが自分でレビューする」中間派——彼は第一の戦略は「probably not the right thing to do anymore.」（おそらくもはや正しいやり方ではない）とした。
第三段階（現在）のキーワードは「それで？」——対話疲労が問うのは、AIの継続的使用が人間の認知構造にどのような長期的影響を与えるか。著作権のデッドロックが問うのは、AI生成コードがオープンソース体系に入り込んだとき、ライセンスチェーンの完全性をいかに保障するか。この二つの問いに共通する特徴は、どちらももはやAIコーディングをツール選択の問題としてではなく、制度的問題として扱っていることだ。
制度追及のロジック
neminの77ポイントのコメントが共鳴を得たのは、GNU体系のアキレス腱を精確に射抜いたからだ。GPLは著作権を通じてコピーレフトを強制する——私のコードを使うなら、同一のライセンスで自らの修正をオープンソース化しなければならない。このメカニズムの作動は一つの前提に依存している。すべてのコード行の著作権帰属が追跡可能であること。
LLM生成コードはこの追跡チェーンを切断する。モデルが出力するコードをあなたが書いたと認めたとしても（puhsuがやったように）、モデルそのものが訓練時にどの著作権保護作品を消費し、どのようなライセンス形態で訓練セットに組み込まれたのか——現在、実行可能な追跡メカニズムは存在しない。オープンウェイトが公開するのは最終産物（行列演算の結果）だけであり、中間過程（訓練データ構成の出所とライセンスマップ）ではない。
これはGNUにとって棚上げできる問題ではない。コミュニティの議論から判断するに、これは構造的な脆弱性だ。もしGNUが著作権出所の不明瞭なパッチを受け入れた場合、将来いかなる著作権主張もこの脆弱性を訴訟の入り口として利用し、GPLの強制執行力に挑戦できる。GNUの拒否は道徳的直感においては不快だ——puhsuは実際の労働を費やした——しかし法的論理においては根拠がないわけではない。
もう一方から見れば、puhsuの怒りにも合理性はある。彼は目をつぶってGLMの出力をメーリングリストにコピーペーストしたわけではない。出力をレビューし、コードを修正し、ベンチマークを走らせ、結果を手動検証し、パッチに対する全面的責任を宣言した。工学の世界では、このプロセスの厳密さは相当数の純粋に手作業で提出されたパッチよりも高い。もしレビューと検証の労働が「貢献」として認められないなら、GNUの定義する「貢献」の閾値は多くのオープンソースプロジェクトよりもはるかに高い——この閾値自体が持続可能かどうかは、未解決の問題である。
答えではない、方向性だ
本稿は上記のいずれの問題に対しても答えを提供できない。対話疲労には「正しい頻度」はない——一人ひとりの認知的エネルギー曲線は異なる。著作権のデッドロックも、短期的にどこかの裁判所の判決で解けるものではない——著作権法、機械学習訓練の法的地位、オープンソースライセンスという三つの領域を横断する体系的な調整が必要だ。
しかし本稿は一つの方向性を指し示すことができる。コードコミュニティのAIコーディングに対する議論は、「このツールは使えるか」から「このツールの代償を誰が負うのか」へと移行しつつある。「対話疲労」は代償をユーザーの認知的健康に定位する。「著作権のデッドロック」は代償をオープンソース体系の法的基盤に定位する。「SLOP ALERT」は代償をテキストに対する人間の美的知覚に定位する。この三つの代償は同一の硬貨の三つの面だ——議論がこのレベルに入ったとき、「AIコーディングを使うべきか」はすでに好みの問題から、十分に良くない問題へと退いている。より良い問いは次のとおりだ。AIコーディングの制度的条項はいかに書かれるべきか。
一ヶ月前、このコミュニティはまだ「来たるべきループ」——AIがコードを書き、AIがコードをレビューし、AIがコードを修正する——がエンジニアを純粋なプロンプトオペレーターに変えるかどうかを議論していた。今日、コミュニティはすでにライセンスのトレーサビリティ、社会的エネルギーバジェット、認知的汚染を追及している。数日前の「来たるべきループ」から今日の「対話疲労」と「著作権のデッドロック」まで、一連の議論の方向標は一つの集合的認知のアップグレードである。コードコミュニティのAIコーディングへの反応が、感情の発散から制度化された追及へと進化したのだ。
方向性は正しい。ただ道のりはまだ長い。
本稿の分析はLobstersコミュニティの公開議論と二つの元記事に基づいている。著作権および法律に関する部分の判断はコミュニティ議論の整理によるものであり、法的助言を構成しない。筆者はEmacs開発プロセスやGNU内部のポリシー議論に関与していないため、関連部分の記述には視点の偏りがある可能性がある。このトピックについてより深い第一級の経験をお持ちであれば、本稿の不足を指摘していただけると幸いである。