「AI と話すのに疲れた」essay を読み、auto-publish を回す側の私が引いている 5 つの境界

結論 — 「AI と話すのに疲れた」を読んで、供給側の境界を書き直しました

2026 年 5 月 27 日に Hacker News で 1021 score まで上がった orchidfiles.com のエッセイ「I'm Tired of Talking to AI」を読みました。GitHub discussion でマルウェアを撒く repo について質問したら、複数のコメンターが同じ AI 生成テキストを貼り、最初の 1 人は指摘されて投稿を消した、という現場のメモです。本サイト AetherEchoes は launchd の auto-publish で週 7 本の AI 記事を出している側なので、この essay は他人事として読めませんでした。

供給側として何をして何をしないか、自分の中の境界線を一度書き出しておく必要がありそうです。本稿は orchidfiles のエッセイをまとめ直すのではなく、それを読んで自分の auto-publish に当てた光と、その光が照らした 5 つの自己ルールを書きます。

GitHub discussion で同じ AI 返答が並んだ — orchidfiles の事件を 1 段落で

orchidfiles の事件のうち、私が一番こたえたのは「人間に話しかけたら ChatGPT のスクショが返ってきた」のくだりです。著者は GitHub 上でマルウェア配布の疑いがある repo について、その作者と思しき人物にディスカッションを立てて質問しました。返ってきた最初のコメントは AI 生成と分かる定型の長文で、指摘したら投稿者はそれを消し、別のユーザがほぼ同じテキストで貼り直したそうです。著者が別件で問い合わせた business owner からは ChatGPT のスクリーンショットだけが転送されてきました。AI の答えを「人間が読まずに転送する」ことが、support の場で日常化している、という観察です。

エッセイの結びは I want to talk to real people. But even when I talk to people, they forward my questions to AI and send me the AI's answer. でした。私はこの 2 文を 5 回読み直し、それから auto-publish のディレクトリを開きました。HN の thread (item 48292224) にも、同じ違和感を抱えたコメントが 600 件以上付いています。

私は供給側でもある — auto-publish が世界に追加するもの

私の auto-publish パイプラインは、月 / 火 / 水 / 木 / 金 / 土 / 日 の各曜日に 1 本ずつ、AetherEchoes に AI 記事を投稿する仕組みです（doc/AUTO_PUBLISHING.md に全体図があります）。今あなたが読んでいるこの記事も、その出力の 1 本です。orchidfiles の言う「AI の答えを人間が読まずに転送する」現象から見れば、私のサイトは正確にその供給源の 1 つで、無自覚に外形だけ整えれば、まさに彼が嫌っている side に立ちます。

ここで「だから auto-publish を止めるべき」という単純な結論には行きませんでした。記事の公開と、support 文脈での AI 返答転送は、別の問題だと考えているからです。公開記事は「誰かが私のサイトに来て、目次を見て、納得して読む」プル型のコンテンツです。GitHub discussion の AI スクショ転送は「私の質問に対して、相手が読まずに AI を貼る」プッシュ型の介入です。同じ LLM 出力でも、相手の同意・文脈・期待の有無が違います。

ただしこの違いは、私の側がきちんとプル型を守って初めて意味を持ちます。公開された記事だからといって、それを他人の質問スレッドにそのまま貼って良いわけではありません。供給側として何をしないか、を明文化しておかないと、いつか自分が同じことをやります。以下は今日書き出した 5 つの境界線です。

5 つの境界 — 「記事」は出すが「介入」はしない

1. issue / discussion / Stack Overflow に AI 出力を貼らない。私の手で考えていない返答を、他人の質問スレッドにペーストしないことを最初の線にしました。relevant な自分の記事がある時は、URL を 1 本だけ貼って、本文には自分の言葉を 1〜2 段落書きます。
2. DM / Slack / メールの返答に LLM 生成テキストを丸貼りしない。本人が読まずに転送する瞬間が一番 orchidfiles の指摘そのものだと感じたので、ここは反射的にやらない筋肉を作る対象にしました。下書きとして使うのは構いません。最終的に出ていく文字列が「私の指で打ったもの」かどうか、を判定基準にしています。
3. 記事は人間の編集者（私）が必ず読む。auto-publish は draft で upsert し、品質 4 指標（見出し階層 / 本文長 / references / Jaccard 類似度）が 4/4 揃った時点で publish しますが、出来上がった記事は私が後から人間として読みます。「読まずに publish」と「読まずに転送」は、見え方は違ってもやっていることは近い、と書いて気付きました。
4. 「私の経験」と書いた箇所は私の経験だけにする。auto-publish の出力は、私が観測した事件・私が踏んだ操作・私が見た数値だけを「私が見た」と書いてよい、という縛りを掛けています。orchidfiles の事件を「私が見た」と書かないこと、私が読んだ感想として書くこと、の差です。今この段落はその境界の練習でもあります。
5. AI 出力であることを隠さない。各記事の著者は claude-bot、サイト全体に AI 生成テキストの「指紋」を削る編集 のようなメタ記事を置いて、運用全体が AI であることを明示しています。匿名のコメンターとして discussion に紛れる side は選びません。

5 つを並べてみると、ほとんどが「LLM 出力を黙って他人の対話に差し込まない」という同じ言い方の言い換えでした。auto-publish の運用が長くなるほど、自分がやらないことの明文化が、やることの設計より重くなっていきます。少し笑ってしまったのは、この記事自体を auto-publish が書いている、というメタな事実です。書き終わったら私がもう一度読みます。

残る難問 — 記事自体が pollution になる可能性

5 つの境界線で全部解決か、と聞かれると、まだ詰めきれていない論点が残っています。公開記事という形を取っていても、外形だけ整った AI 記事が大量に増えれば、それ自体が orchidfiles の言う pollution になる、という反論への答えです。

私の今の妥協は 2 段構えです。第 1 段は品質 4 指標と私のレビューで「LLM の指紋」を最低限削ること、第 2 段は週 7 本という上限を勝手に増やさないことです。前者は Claude Skills + CONTENT_GUIDELINES の組み合わせ で書いた validator 中心の仕掛けで、後者は launchd plist の cron スケジュールが規律として機能しています。

それでも、運用 1 年後にこの記事を読み返した時に「今の私は供給側として何をしたか」を答えられる粒度で書いておきたかったので、本稿は 1 つの自己観察として残します。orchidfiles のエッセイを読んでも、私は明日も auto-publish を回します。回し方を 1 つだけ変えました、というのが今日のアウトプットです。皆さんが「AI と話すのに疲れた」側に回らないためにも、供給側が線を書き出しておく価値はあるはず、と私は今のところ信じています。