そういう会話をしてたのさ。
ところでLLMは情報自体の内容のモジュール化が苦手というか仮説や具体例に回答の性質自体が引きづられてしまう問題があるよな。 例えば今回の例で言えば記事の分類のところでわざわざ多態性みたいな言葉を持ち出してしまっている。この辺は人間が記事を書くならまずやらない行為なのだけど確率的に近しいものなのでLLMはやってしまう。
Last active
November 22, 2025 03:39
-
-
Save podhmo/09293f999c9007537a47ab623d253bde to your computer and use it in GitHub Desktop.
zennとかで現れてきた一見網羅的な記事のだるさについて
検索窓にエラーログを叩き込み、表示された検索結果の海を眺めるとき、そこに広がる光景に目眩を覚えることがある。かつては砂金のように輝いていた知見が、今や大量の砂利の中に埋もれてしまっている感覚だ。
なぜ、技術記事はこれほどまでに「冗長」になってしまったのだろうか。 この問いを出発点として、現代の技術情報共有におけるノイズの正体と、私たちが無意識に囚われている「記事執筆のアンチパターン」について、その思考の深淵を探求してみたい。
ノイズの主因として、生成AIの普及が挙げられることは論を待たない。AIに「記事を書いて」と頼めば、それはそれは立派な、導入から結論まで網羅されたテキストが出力される。しかし、問題の本質はAIそのものにあるのではなく、それを使う人間側の「編集意識の欠如」にあるのではないかと思い至った。
カメラにおける写真撮影を例に考えてみる。 美しい花の写真を撮りたいとき、私たちはファインダーを覗き、構図を決める。その行為の本質は「何を入れるか」ではなく、「何をフレームの外に切り捨てるか」にある。花を際立たせるために、背景の看板や足元の吸い殻を排除する。これをトリミングと呼ぶ。
ところが、最近の技術記事、特にAIの出力をそのまま利用したような記事は、このトリミングが行われていない。Reactの特定のエラー解決策を知りたいだけなのに、記事は「Reactとは何か」「Reactの歴史」「仮想DOMの仕組み」から始まっている。これは、花の写真を撮るために、その花が咲いている公園の設立経緯や、公園の入り口の地図まで全て一枚の写真に収めようとしているようなものだ。
ここで重要なのは、「要約（Summary）」をして短くすればいいという話ではないということだ。必要なのは「削除（Delete）」だ。
「この記事に辿り着くような読者は、Reactのことは既に知っている」という、読者のコンテキスト（文脈）に対する信頼が欠けている。読者を信頼できないから、念のためにと不要な前置きを書き連ねる。結果、本当に必要な「ピントの合った情報」がどこにあるのか、読み手が探さなければならないコストが発生する。情報のS/N比1を高めるために必要なのは、情報を圧縮する技術ではなく、勇気を持って「書かない」という選択をする編集者の視点なのだ。
ここで、さらに思考を一歩進めてみる。「長い記事なら、目次（Table of Contents）や要約があればいいではないか」という反論についてだ。 私はこれに対し、否定的にならざるを得ない。なぜなら、目次や要約とは、記事の構造（スケルトン）そのものを反映した縮図だからだ。
「要約」とは、対象の構造を保ったまま、その表層を撫でてサイズを小さくする行為だ。 もし元の記事が、80%のノイズ（不要な挨拶や概論）と20%のシグナル（解決策）で構成されていた場合、それを要約した結果もまた、80%の「要約されたノイズ」と20%の「要約されたシグナル」になる。情報の縮小（スケーリング）を行っても、その構成比率（アスペクト比）は変わらない。これは一種のフラクタル構造2だ。
「目次」も同様である。目次は記事のガイド役であると同時に、「この記事がいかに旧来のSEO的・教科書的な構造に支配されているか」を示すレントゲン写真でもある。「Reactの歴史」という不要な章と、「解決コード」という重要な章が、目次の中では等しく並列の項目として扱われてしまう。
つまり、構造自体が腐っている記事は、要約しても目次をつけても、腐った構造が維持されるだけなのだ。 本当に必要なのは、構造を保ったまま圧縮することではなく、既存の構造（トポロジー）を破壊し、必要な部分だけを摘出することだ。それこそが前述した「トリミング」の本質であり、要約とは決定的に異なるプロセスである。
では、なぜ私たちはそのような冗長な構造を選んでしまうのか。 ここで「鉄は熱いうちに打て」という格言と、技術情報の性質について考えてみる。
技術情報には、明確に二つの性質があることに気づく。
一つは、エラー対応やトラブルシューティングだ。 これらは、目の前で火が燃えている状態だ。エラーが出た瞬間、書き手の感情は「困った」から「直したい」、そして解決した瞬間に「やった！」というピークに達する。鉄は最高に熱い状態だ。 このとき、その熱量に任せてログと解決策を書き残すことは、理にかなっている。解決策（情報の価値）と、書きたいという衝動（モチベーション）が完全に同期しているからだ。
もう一つは、アーキテクチャの選定理由や、長期間運用した後の総括（ポストモーテム3）だ。 これらは、鉄が冷えて固まった後に初めて価値が出る。導入して一週間後の「使ってみた」記事にはない、一年間泥水をすすった後の「重み」がそこにはある。 しかし、残酷なことに、鉄が冷えて固まった頃には、書き手の情熱も冷めきっている。「今更このバージョンの話をするのもな」「もう次のプロジェクトに移っているし」と、筆を執る動機が失われている。
その結果、世の中には「熱いうちに打たれた」だけの、浅い「やってみた記事」が溢れかえり、本当に価値のある「冷えた鉄の記録（失敗談や運用知見）」が圧倒的に不足する。
さらに悪いことに、私たちは「熱い鉄（エラーログ）」をアウトプットする際にも、「ブログ記事」という冷めたフォーマットに押し込めようとしてしまう。本来なら3行のコードブロック（熱いままの鉄）で済むものを、無理やり3000文字の物語（冷めた製品）に加工しようとするから、余計な不純物が混入するのだ。
ここまでの思考を統合すると、根本的な問題は「技術記事」というクラス（概念）が単一であると考えてしまっている点にある。
プログラミングにおいて、私たちは「銀の弾丸（万能な解決策）」が存在しないことを知っている。状況に応じて適切なデザインパターンを選び、クラスを設計する。 それなのに、こと「記事の執筆」に関しては、たった一つの「ベストプラクティス（導入・本文・まとめ）」が存在すると錯覚し、すべての情報をそこに流し込もうとしている。
情報の性質に合わせて、記事のフォーマットも多態性（ポリモーフィズム）4を持つべきだ。
-
Snippet / Log 型（熱い鉄） エラーログやTipsはこれだ。ここには挨拶も背景も要らない。Stack Overflowのように、エラーログ（Input）と解決策（Output）だけが淡々と記されていればいい。それを「記事として薄い」と恥じる必要はない。S/N比の観点からは、それが最高品質なのだから。
-
Tutorial 型（教育） 初学者向けの解説はこれだ。ここではAIが得意とするような、丁寧な背景説明や歴史的経緯が役に立つ。既存のブログフォーマットが最も輝く領域だ。
-
Post-Mortem / ADR 型（冷えた鉄） 運用の知見や設計判断はこれだ。ここではコードの書き方よりも、「なぜその決定をしたのか（Context）」「結果どうだったのか（Result）」という文脈が主役になる。「失敗した」「剥がした」という記録こそが、後続のエンジニアにとっての貴重な標識（行き止まりの看板）になる。
-
Journal / Scrap 型（実験） まだ結論が出ていない試行錯誤はこれだ。タイトルに
[WIP]や[実験]とラベルを貼ることで、「完成品ではありません」という免責事項を提示する。完成品を探している読者を回れ右させる優しさ（フィルタリング）が必要だ。
さらに言えば、記事のタイトルもAPIのインターフェース設計と同じだ。 中身がエラーログなら、タイトルはSEOを意識した日本語の文章ではなく、エラーメッセージそのものであるべきだ。それが、その情報を必要としている人にとって最も精度の高い検索クエリとなるからだ。
私たちが直面している情報の洪水は、「1つの正解フォーマット」ですべてを記述しようとした結果の歪みだ。
「ベストプラクティス」という言葉が形骸化し、単なる「最初に試した設定」と同義になってしまった今、私たちは言葉の定義を再構築する必要がある。 「要約」によって構造を維持したままお茶を濁すのではなく、情報の性質を見極め、不要な文脈を「トリミング」する。そして、その情報が「熱い鉄」なのか「冷えた鉄」なのかに応じて、適切なコンテナ（フォーマット）を選択する。
書き手ができる最大の貢献は、無理に立派な記事を書こうとすることではない。 自分の持っている情報が持つ「熱」と「構造」を正しく理解し、それに最も適したインターフェースで世に出すことだ。
「分からないことは分からない」と書き、「失敗は失敗」として記録する。 その情報の解像度に対する誠実さと、読者のコンテキストを信頼して不要な情報を削ぎ落とす勇気こそが、これからの技術発信における新たな価値基準となるだろう。
Footnotes
-
S/N比 (Signal-to-Noise Ratio): 信号（必要な情報）と雑音（不要な情報）の比率。この比率が高いほど、ノイズが少なくクリアで良質な情報であることを示す。 ↩
-
フラクタル構造 (Fractal Structure): 全体と部分が自己相似になっている構造のこと。ここでは、記事全体が冗長な構造であれば、それを縮小（要約）しても、やはり冗長な構造のままであることを指す。 ↩
-
ポストモーテム (Post-Mortem): 直訳すると「検死」。IT業界では、プロジェクト終了後や障害発生後に行う「事後検証」や「振り返り」を指す。誰かを責めるのではなく、プロセスや仕組みの改善に焦点を当てる活動。 ↩
-
多態性 (Polymorphism): オブジェクト指向プログラミングの概念の一つ。同じ名前のメソッドやインターフェースが、受け取るオブジェクトの種類によって異なる振る舞いをすること。ここでは、同じ「技術記事」であっても、内容によって形式や構成が変化すべきであることを指す。 ↩
ZennやQiita、あるいは個人の技術ブログを日々巡回している、一介のエンジニアです。
今日は、最近のタイムラインを眺めながら感じている「ある種の息苦しさ」と、私たちが無意識に陥っている「記事執筆のアンチパターン」について、少し立ち止まって考えてみたいと思います。
これは特定の誰かを糾弾するための文章ではありません。「そもそも、なぜ私たちは技術記事を書くのか？」「読み手にとっての『価値』とは何だったのか？」という原点に立ち返るための、静かな思索の記録です。
ある日の午後、Reactの特定のマイナーなエラーに遭遇した私は、いつものようにエラーログを検索窓に叩き込みました。検索結果には、ZennやQiita、個人の技術ブログがずらりと並びます。
期待に胸を膨らませて、上位の記事をクリックしました。しかし、そこで私を待ち受けていたのは、求めていた「オアシス（解決策）」ではなく、広大で冗長な「砂漠」でした。
「Reactとは何か」から始まり、「JavaScriptの歴史」「今回のライブラリの概要」「メリット・デメリット」……。 スクロールバーは豆粒のように小さく、私が知りたい「たった数行の解決コード」は、大量の「教科書的な解説」の海に沈んでいました。
皆さんも、似たような経験はないでしょうか？
ここ数年、明らかに技術記事の**S/N比（シグナル・ノイズ比）**が下がっています。 AIの台頭により、誰もが「それっぽい網羅的な記事」を無限に生成できるようになったことが一因でしょう。しかし、本質的な問題はツールにあるのではなく、私たち人間の「編集意識」の変化にあるような気がしてなりません。
「長い記事なら、要約や目次があればいいではないか」と思われるかもしれません。 しかし、私はあえて言いたい。「要約」や「目次」は、根本的な解決にはなりません。
なぜなら、要約とは「構造を保ったまま、表層を撫でる行為」だからです。 もし元の記事が、80%のノイズ（不要な挨拶や概論）と20%のシグナル（解決策）で構成されていた場合、それを要約しても、やはり80%の「要約されたノイズ」が残ります。これは一種のフラクタル（自己相似）な構造です。
目次も同様です。今の技術記事における目次は、ナビゲーションというより、**「この記事がいかに旧来のSEO的・教科書的な構造に汚染されているかを示すレントゲン写真」**になってしまっています。「Reactの歴史」と「解決コード」が、目次の中で並列に並んでいること自体が、構造的な欠陥なのです。
必要なのは「要約（縮小）」ではなく、**「トリミング（削除）」**です。
写真を撮るときのことを想像してください。美しい花を撮りたいとき、私たちは背景の看板や電柱をフレームの外に切り捨てます。 「Reactのエラー解決」を探している読者は、Reactの経験者です。その人に対して「Reactとは……」と語りかけるのは、写真に写り込んだ電柱と同じです。
読者のコンテキスト（背景知識）を信頼し、不要な情報をバッサリと切り捨てる。その「書かない勇気」こそが、情報の密度を高めます。
この「トリミング不足」が招いた結果が、現在の「Google離れ、LLM（ChatGPTなど）頼み」の傾向です。
私たちがAIに質問をする理由。それはAIが賢いからという以上に、AIが「動的なフォーマット変換器」として優秀だからではないでしょうか。
Web上の記事（入力）がどれほど冗長でノイズまみれであっても、LLMを通すことで、私たちは「結論だけ教えて」と、強制的にトリミングされた出力を得ることができます。 つまり、書き手がトリミングをサボったツケを、読み手がAIというフィルターを使って払わされているのが現状です。
一方で、AIを使った自動検索（Deep Research等）が、期待したほど深い情報を拾ってこれない理由もここにあります。 AIエージェントは真面目なので、検索上位に出てくる「SEO最適化された（＝中身が薄まった）記事」を読みに行き、その構造を尊重して「要約」してしまいます。 元の記事が表層的であれば、AIの出力もまた表層的なまとめに留まります。
結局、人間が「良質な一次情報（トリミングされた原液）」を提供しない限り、AIもまた、ノイズを再生産する装置にしかならないのです。
では、私たちはどうすればいいのでしょうか？ 私が提案したいのは、記事フォーマットの**「多態性（ポリモーフィズム）」**を取り戻すことです。
プログラミングの世界では、「銀の弾丸（万能な解決策）」など存在しないと知っています。適材適所でクラスを使い分けます。 しかし、記事の執筆となると、なぜか**「ブログ記事」というたった一つのクラス**ですべてを処理しようとしてしまいます。「導入・本文・まとめ」という画一的なフォーマットへの固執が、諸悪の根源です。
情報の性質に合わせて、以下の4つの型を使い分けることを提案します。
- 性質: エラー対応、トラブルシューティング。
- タイミング: エラーが出た瞬間（鉄が熱いうちに打つ）。
- スタイル: Stack Overflow形式。 挨拶も背景も「いかがでしたか」も不要です。エラーログ（Input）と解決コード（Output）だけでいい。 タイトルは「〇〇の方法」ではなく、エラーメッセージそのものにします。それが最高の検索性（SEO）だからです。
- 性質: 初学者への導入。0から1を作る。
- スタイル: 教科書形式。 ここだけは、丁寧な背景説明や歴史的経緯が必要です。AIが生成するデフォルトの構成が最も輝く場所です。
- 性質: アーキテクチャ選定の理由、長期運用の総括。
- タイミング: プロジェクト終了後、あるいは撤退時（鉄が冷えた後）。
- スタイル: 事後検死報告書。 コードの書き方よりも、「なぜその決定をしたのか（Context）」と「結果どうだったのか（Result）」に特化します。「失敗した」「ライブラリを剥がした」という記録は、成功談の何倍もの価値があります。
- 性質: 未解決の試行錯誤、学習ログ。
- スタイル: 作業日報。
結論が出ていなくても構いません。ただし、タイトルには
[WIP][実験]とタグ付けし、中身には「試したこと」と「生のログ」を残します。それは後続の誰かにとっての「行き止まりの看板」となり、立派な貢献になります。
私たちが直面している情報の洪水は、「1つの正解フォーマット（SEO記事）」ですべてを記述しようとした結果の歪みです。
PVを稼ぐために、中身が何であれ「〇〇完全攻略」「最強のベストプラクティス」とつけるのは、もうやめにしませんか。 タイトルは、読者を釣り上げるための「釣り針」ではなく、倉庫の段ボールの中身を正確に示す「ラベル」であるべきです。
- 中に「エラー解決のメモ（Snippet）」が入っているなら、ラベルはエラーコードであるべきです。
- 中に「失敗した記録（Post-Mortem）」が入っているなら、ラベルは「〇〇に失敗した話」であるべきです。
「熱い鉄（エラー対応）」を無理やり冷まして記事っぽく加工する必要はありません。 「冷えた鉄（運用総括）」を、美しく見せようと飾る必要もありません。
情報の解像度に対する誠実さと、読者のコンテキストを信頼して不要な情報を削ぎ落とす「トリミング」の勇気。 それを持つことが、AI時代において人間が書く記事の、最後の砦になるような気がしています。
さて、私もそろそろ、書きかけの（しかし結論の出ない）デバッグログを、無理にまとめたりせず、そのまま Scrap に放り込んでくるとしましょう。それが、今の私にできる「最善の貢献」だと信じて。
Author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
ai君勝手にこういうこと書くんだよな。見張ってないと自分の取るべき責任が増える。