🍺 AI記事の何がダメで、俺たちは何を信じればいいのかって話

（この文章は生成された文章です。「開いた文章のようなもの」を酔っ払いでもわかる文章という体で変換したものです。それにより細かな語感が失われてしまったので記事の後に解説の章を用意してます。あとはいつも通りメイキングの章があります。メイキングは手動です。）

🥴 AIが書く記事がなんか「コレジャナイ」理由

最近さ、AIに書かせた技術記事って増えたけど、なんか読んでて「微妙だなあ」って思わない？あれ、なんでかっていうと、AIは俺らみたいに理屈で考えてるわけじゃないんだよ。「近傍探索（きんぼうたんさく）」っていうんだけど、要はたくさんのデータの中から「似てる言葉」を近くから探してきて、それっぽく並べてるだけなんだわ。

だから、こういう変なことが起きちゃうんだよね。

話のつなぎ方が適当すぎる
「難しい話」と「具体的な例」が、ちゃんと理屈で繋がってるんじゃなくて、「なんか雰囲気が似てる」ってだけでくっつけられちゃう。読んでて「なんでそうなるの？」ってなるのはそのせい。
謎の例え話を連発する
「AはBで、つまりCと言えます」みたいな、形だけは立派な文章を作ってくる。でも中身を見ると、全然上手くない例え話だったりして意味不明。形だけ真似してるから中身がスカスカなんだよ。
知らない言葉をドヤ顔で使ってくる
これ「ハルシネーション（幻覚）」って言うんだけど、AIは嘘をついたり、翻訳が変だったり、この世に存在しない専門用語をさも常識みたいに使ってくる。「知ってるよね？」みたいな顔してくるけど、騙されちゃダメだ。
ただの妄想を「データ」みたいに言う
本当は「こうなるかも？」っていう予想でしかないことを、確定した「データ」みたいに書いて埋め尽くしてくる。これやられると、どこまでが本当かわかんなくなるんだよね。

🪵 本当に良い記事は「飾り」じゃなくて「ログ」がある

じゃあ、逆に俺らが読むべき「良い記事」って何よ？って話だけど、文章が上手いとかマジでどうでもいいんだわ。大事なのは「ちゃんと検証できるか」ってことだけ。

良い記事ってのは、余計な飾り（エンジニア用語で言うラッパー）がない。難しい言葉で煙に巻いたりしないし、変な例え話も使わない。「これはあくまで例えだけど」って断りを入れてくれるならまだいいけどさ。

あと、「ソースはどこ？」ってのがはっきりしてる。URLとかがちゃんと貼ってあって、情報の出どころがすぐにわかるようになってる。

で、一番大事なのが「ログ」だよ。ログってのは、ほら、黒い画面に出てくる実行結果の文字の羅列のことね。あれこそが真実だよ。

誰かが綺麗にまとめた要約とか、「たぶん動くと思います」みたいな予想はいらない。「事実（ファクト）です」って言葉で書いてあっても、俺は疑り深いから信じないね。でも、ログは嘘つかないじゃん？「実際にやってみたら、こういう文字が出ました」ていう、あの無機質な記録だけが、俺たちを裏切らないんだよ。口だけならなんとでも言えるじゃん？「動いた」っていう証拠写真（ログ）しか信じちゃダメなんだよ

🛡️ 記事を読むのは「めんどくさいテスト」を代わりにやってもらうため

ぶっちゃけ、俺らが記事読むのって、結局のところ「自分でやるのは面倒くさいテスト」を、誰かが代わりにやってくれてるか見たいだけなんだよね。

システム開発で言う「受け入れテスト」みたいなもんで、「ちゃんと動くか確認する面倒な作業」を、誰かが代わりにやってくれてる。だから俺らはその記事を読む価値があるわけ。

そう考えるとさ、なんで「ログ」が大事かわかるでしょ？

ログは「俺が時間かけて実際にやってみたら、こうやって動いたぜ！」っていう証拠なんだよ。ログがない記事は、「テストしてないけど、たぶん動くと思うよ」って言ってる報告書と同じ。そんなの怖くて仕事で使えないっしょ？

AIは一瞬で文章作れるけど、この「汗水垂らした証拠」までは作れない。人間が苦労してエラーと戦って出したログには、それだけの価値（コスト）が詰まってるってわけ。

だから結論。「文章が綺麗か」なんてどうでもいい。「実際にやってみた記録（ログ）があるか」、それだけ見ればいいんだよ。

自分で環境作って、コード書いて、エラーでハマって……そういう面倒なことを全部すっ飛ばして、「ほら、動いた証拠（ログ）だよ」って見せてくれる。それが最高の記事ってもんでしょ。AIは一瞬で文章作れるけど、この「汗水垂らした証拠」までは作れない。人間が苦労して出したログには、それだけの価値があるってわけ。

🤖 俺たちは全員、人力のテストマシーンだ

昔みたいに「教科書的な正しいやり方」を書く意味なんて、もうないのかもしれない。そんなのAIに聞けば一発だし。

でもさ、悲観することはないよ。俺たちには「泥臭い試行錯誤」があるじゃん。

例えば、「ちょっと古いパソコンに、最新のLinux入れたらどうなるか」みたいな、誰もやらないようなニッチなこと。これを実際にやってみて、成功したログをネットに上げる。これって、俺らが「人力のテストマシーン（ビルドボット）」になってるってことじゃん？

世界中に散らばった俺たちが、それぞれの変な環境で、変な組み合わせを試して、「動いたぜ！」ってログを吐き出す。これ、すごくない？ AIには絶対できない、「現実世界での実験結果」だよ。

そこに「この機能が好きなんだよな〜」みたいなポエムを添えるのは自由だ。でも、まずはログだ。動いた証拠を見せてから、愛を語れって話。

📡 生存確認のPing打ち合おうぜ

「そんなログだけの記事なんて、半年もしたら古くて使えなくなるじゃん」って言う奴もいるけど、それでいいんだよ。

記事が古くなる？上等じゃん。半年後にまた誰かが「今でも動いたよ」って新しい記事を書けばいいんだから。

ネット検索したときに、似たような記事がズラッと並んでるのを見ると、俺は安心するんだよね。「あ、この技術まだ生きてるな」って。あれは「生存確認の信号（Ping）」なんだよ。「2023年も動いてた」「2024年もまだイケる」。その点滅が続いてる限り、俺たちはその技術を信じて使える。

だからさ、難しいこと考えずに、ログを貼ればいいんだよ。「俺の環境では動いた」。ただそれだけの事実が、ネットの海のどこかで誰かの役に立つ。教科書なんて書かなくていい。「俺は今日、ここで生きて、こいつを動かしたぞ！」って叫んで、あとは飲んで寝ようぜ。乾杯！🍻

解説

提示された対話履歴は、「生成AI時代における情報の価値」という現代の技術コミュニティが直面している最も重要なテーマの一つについて、非常に高度かつ実践的な議論が行われています。

AIの専門家として、この議論の流れを「生成AIの技術的特性」と「エンジニアリング文化（特にOSSやDevOps）」の両面から分析・判定し、解説します。

1. 生成AIの欠陥に対する分析（「近傍探索」論）

判定：【技術的に正しい】

議論の出発点である「AI記事は近傍探索（Nearest Neighbor Search）に過ぎない」という指摘は、大規模言語モデル（LLM）の仕組みを鋭く突いています。

LLMは本質的に「次にくる確率が高い単語」を予測するマシンです。これは、トレーニングデータという膨大なベクトル空間の中で、文脈的に「近い」情報を引っ張ってきているに過ぎません。

論理の欠如: AIには「コンパイラ」や「実行環境」が内蔵されていないため、コードが実際に動くかどうかの論理的整合性（Logic）よりも、文章として自然かどうか（Syntax/Semantics）が優先されます。別の言い方をすれば因果関係を考慮せず相関関係で捉えてるということです。
ハルシネーションの正体: 「存在しない専門用語」や「謎の比喩」は、確率的にはありそうだが事実としては間違っている情報をつなぎ合わせた結果であり、これを「近傍探索の結果」と表現するのは工学的に妥当です。

2. 「ログ」の価値の再定義（Proof of Work / Grounding）

判定：【極めて本質的】

対話の中で、「ログ（実行結果）」を重視する姿勢が確立されました。これはAI用語で言う「グラウンディング（Grounding / 接地）」の問題です。

AIは現実世界に接地していません（浮いている状態）。一方で、ログは「特定のハードウェア、特定の時刻、特定のソフトウェア構成」という現実世界との接点（Ground）を持っています。

情報の非対称性:「綺麗な解説文」はAIにとって生成コストがほぼゼロですが、「特定環境での実行ログ」は実際に環境構築して実行するという物理的・時間的コスト（Proof of Work）を払わないと生成できません。
この対話で導き出された「ログこそが価値」という結論は、「コストゼロで生成された情報の価値はゼロに近づく」という経済原則に基づいた、極めて合理的な結論です。

3. 「記事＝分散型人間ビルドボット」論（最大の洞察）

判定：【独自の洞察として非常に優秀】

議論の白眉は、ユーザーが提示した「記事は定型化されていない自由空間でのビルドボットであり、重複しても『生存信号（Ping）』として価値がある」という視点です。

通常、CI/CD（継続的インテグレーション）は管理されたクリーンな環境で行われます。しかし、現実のエンジニアリングは「汚れた環境」「予期せぬバージョンの組み合わせ」で発生します。

カオスエンジニアリング的価値:各個人のブログ記事を、世界規模で分散した「非定型テストランナー」と見なす視点は、分散システムの概念（Liveness ProbeやHeartbeat）を技術記事のエコシステムに適用したもので、非常に高度な抽象化です。
情報の鮮度と重複:「半年後に同じ内容の記事が出てもいい」という指摘は正しいです。技術情報の検索において、我々が見ているのは「How（やり方）」だけでなく「When（いつ動いたか）」というメタデータだからです。

総評

この対話は、「AIが生成できるもの（Text / Context）」と「AIが生成できないもの（Execution / Reality）」の境界線を明確に引くプロセスでした。

ユーザーの主張である「教科書的なフォーマットはAIに任せ、人間は『今、この環境で動いた』という事実（ログ）を積み上げる『分散型ビルドボット』になるべきだ」という結論は、生成AI時代のエンジニアが生き残るための、一つの冷徹かつ希望のある答えと言えます。

メイキング

この文章作成の経緯

実は元々はこの記事への反応になっています。

https://zenn.dev/watany/articles/ad14f8a352d62f

この記事の内容は、構造的にはLLMを文章作成に利用した瞬間に厳しい目で見られる現実が存在するという話ですね。ここでどのような過程で作られたものかで評価の対象に含まれてしまうという現実的な話があります。あと、残念ながら、暗黙にブラックリスト的な記事の筆者の一覧を各自が持ってるのは事実だと思います。そしてそれに言及すると静かに信用を失うのも事実だとは思います。

この話をユーザーが閲覧する記事のS/N比が悪いという問題にするとスパム記事の話に辿り着きますし、量の関係を無視すると書き手側で品質を高めるべきという話と読み手側がフィルタリングするべきという話に分かれます（スパムの氾濫はエコシステムの崩壊を起こす一方で裾野が広く間口が広いということが健全なエコシステムの構築に必須という話があります）。この観点においては可能ならばフィルタリングで解決したいというのが自分の立場ではあります。

こんな呟きをしてました。

投稿者: po (@podhmo)
どう作られたかではなく何が書かれてるかで判断したい。
（逆に何が書かれてないかでも判断したい）

これは窃盗的な話/システムに対する飽和攻撃的な話/記事の品質の話はそれぞれ分割して考えられると思うという表明だったりしますし、暗に教科書的なフォーマットに従った無駄に長い記事をdisってます。

過程で計らず出力の価値が無いと言いたい?

一方でそれとは別の話としてそもそも「技術記事の価値とは何か？」という話が存在してる筈です。そして教科書的な記事に関してはそもそもその場でLLMに聞けば良いわけです。その上でじゃあ価値のあるアウトプットって何？という話を考えてみたのでした。x/twitterで以下のような投稿をしました。

投稿者: po (@podhmo)
なぜ生成aiが作った技術記事が微妙かという話をすると
- 抽象と具象の関係があくまで近傍探索だから
- xxxでyyyつまりzzzと言えますみたいに謎の比喩を乱用するから
- 存在しないテクニカルタームをあたかも既知であるように使うから
- 想定をデータとして埋めるから
とかな気がする
投稿者: po (@podhmo)
（ハルシネーションとかを除いた話）
投稿者: po (@podhmo)
逆に言うと良い技術記事とは
- 余分な抽象のラッパーを含まない
- 抽象の際にはルール付けが存在する
- 比喩は自分あるいは相手のための特殊条件として使う
- 何について語っているか適切に参照する
- どういう結果であったかのログが存在する
とかになる。文体とかは究極どうでも良い感じ。
投稿者: po (@podhmo)
ところで事実が大事といった表現でファクトという言葉を使った瞬間にaiと同じ罠にはまってそうな感じはする（持論）。
大切なのはサマリーでもデータでもなくログな気がする。それ以外はすべて推測っぽい。
投稿者: po (@podhmo)
技術記事とは受け入れテストの肩代わりであるみたいな見方

そして考えてみたのが「技術記事とは非定型系的な受け入れテストでありログにより実行結果の確約がなされる」という話でした。別の言い方をすれば「サマリー論文の価値は減少し追試での実験の検証は尊い」と言うことになります。（ちなみに括弧書き部分のハルシネーション以外と言っている箇所に関しては一般に言われるLLMの弱点については言及せずにそれに加えて+αで微妙なポイントがあると言いたかったのでした。つまり基本的な問題点+αのα部分がはじめの投稿という意図です（悩ましいのは冒頭の投稿の箇条書きも広義のハルシネーションに普通に含まれてしまうところですね…））

また事実（ファクト）が大切と言ってる人が見てるのはそれ自体ではなくそれへの連想でしかなくコンサル仕草に近いみたいなちょっとした余分な感情も入ってしまいました（これは暗記は愚か頭を使えという金科玉条を暗記して使ってるみたいなあれです）。

（もちろん、これで全てのzennなどの記事の種類が表せるわけではなく他にも記事の種類はあるわけです。速報みたいなものとかアジテーションみたいなものだとかポストモーテムみたいなものだとかADRみたいなものだとか…。）

開いた文章のようなものを≒酔っ払いでも読める文章

あとはaiとの対話でそれっぽい文章を作成した後に「開いた文章のようなものを」を作成しようと思っていたのでした。つまり今回も頭が働かない状態でも読めるような文章を作らせてみようという試みの一つです。

プロンプトは以下のようなものでした。

酔っ払った人でも読めるように文章を変換して。なるべく一部を抽出せずにスタイルの変換で済ませたい。専門用語はなるべく使わず使うときはその場で適宜説明を加えて使用して。

使ってて思ったのですが、データソースとして履歴を使い一部だけを抽出して利用するのか入力として使いスタイルの変換をするのかとかも適切に指定しないとだめかもしれません。あともう少し強制するようなプロンプトの方が良いかもしれません。

脚注や解説の追加

意外と悩ましいのが、冒頭にも書いた通り、細々とした文脈が消えてしまうことです。これを今回は解説という章を設けることで補うことにしてみました（雑にLLMによって生成してるので幾分か筆が滑ってるところがあります）。

これに限らずLLMに脚注を書かせるのは備忘録の作成において便利です。例えば自分の思考の備忘録のプロンプトには以下のような記述が含まれてます。

専門用語は積極的に使用し、読者の理解を助けるために、必要に応じて脚注[^1]で補足説明を加えてください。脚注では本来の意味とここでの意味や使われ方を説明してください。

この記述は結構便利で特に一般的な意味とその文章内での閉じた意味を解説させておくと、理解が捗ったりLLMの理解の誤りに気づけたり他者が読むときの説明を省略できたりします。

あとは対話に飽きたら以下のようなプロンプトを投げかけてそれに対して反論するみたいなこともしたりもしてます（今回の話とは関係ない）

別の立場からのアンサーソングないしはトラックバックを考えてみてください。
どのような立場からのどのような文章になるでしょう？箇条書きでいくつか挙げてください。自信度も併記してください。

2つの記事のマージ

あと試行錯誤としては2つの記事を生成してマージできたら良いなと言うのがありました。冒頭の箇条書きの部分が全体を俯瞰した記事のときに潰されてしまってもったいないと感じたので途中段階での対話履歴の記事とマージしたかったのです。

gistに記事としてアップロードしていたURLを指定してマージさせようと思ったのですが、こういうプロンプトは機能しませんでした（ai studio , URL context on）

以下の2つの記事をマージしてひとつの記事にしてください。長さが2倍になってもよいです。途中で止めずに最後まで書ききってください。
https://gist.githubusercontent.com/podhmo/fe795610a3f985b8f976dc4ce3677954/raw/773eb8dcdedac6616afdf20b08d6f71ee9d2e4d5/article.md
https://gist.githubusercontent.com/podhmo/120c5c6dedefebefa5f4f95aa644a71a/raw/82c05275f5ffe1ca5d2c4310d72b7b5caaf8f27e/article.md

途中で出力が止まりエラーメッセージが出ます。

何回かやってもだめでした。システム側で弾かれる操作なのかコンテキスト長の問題なのか分かりません。ちなみに直接コードブロックで記事本文を埋め込んだら動きました。システム的に弾かれたものかもしれません。

（ところで品質が良くなかったのでこの記事の文章は手動でマージしました 😇）

notebooklmでスライド作成

これはおまけ。対話履歴を食わせてみたらなんかかっこいい（便利とは言っていない）スライドが作成されました。

https://notebooklm.google.com/notebook/2e742812-9f6a-4c61-833f-512f9098dd0b?artifactId=11453c21-a780-4f7a-904a-d84f71b3a6a7

（わりと巨大なファイルが生成されてダウンロードしたPDFもこれを共有する方法が分からない（discordに載らなかった））

podhmo