バイブコーディングでブログ記事はどう変わるか

「vibe coding」という言葉がある。AIにコードを書かせて、自分は方向性だけを示す作り方のことで、2025年2月にAndrej Karpathyが言い出し、その年のCollins Dictionaryの年間ワードにも選ばれた。

“You just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.”

ただ見て、言って、実行して、コピペする。だいたい動く。

マーケターがランディングページを作り、デザイナーがプロトタイプを動かし、ライターがインタラクティブな記事を書く。作り手と使い手の境界が溶け始めている。コードを書ける人の範囲が広がれば、ブログ記事の作り方も変わる。テキストだけでなく、読者が動かしながら理解する記事も選択肢に入ってきた。この記事では、そう考えるようになったきっかけと、参考にしているもの、作るときの手順を書いておく。

The Pudding を見て、記事はここまでできるのかと思った

数年前、The Puddingというサイトに出会った。最初に見たのは、たしかSpotifyの再生データを分析した記事だったと思う。スクロールするたびにグラフが動き、自分のデータを入力すると結果が変わる。読んでいるというより、動かしている感覚だった。記事はここまでできるのか、と思った。

The Pudding は2017年に立ち上がったデジタルメディアで、「文化で議論されるアイデアを、ビジュアルエッセイで説明する」ことを掲げている。名前は「the proof is in the pudding（論より証拠）」という慣用句から来ていて、最初は「The Proof」にしようとしたら取られていたので、冗談で「The Pudding」と呼んでいたらそのまま定着したらしい。

題材は身近なものが多い。1958年以降のTop 10ヒット5,141曲から、ポップソングの中の「愛」の変遷を追ったIs Love Dead in Pop Music?や、2,000本の映画脚本から男女のセリフ量の偏りを可視化したFilm Dialogueがそうだ。

面白いのは作り方の方だ。The Pudding は「ジャーナリスト兼エンジニア」という珍しい人の集まりで、階層的なチームではなく、各メンバーが自分でテーマを選び、リサーチからデータ分析、デザイン、ライティング、コーディングまでを一人で担当する。フロントエンドはD3.jsやSvelte、データ処理はRやPythonやNode.js、地図はMapboxと、ツールはストーリーに合わせて選ぶ（resources、JS Party #193）。制作の手法も「Making Internet Things」という3部作のガイドで公開している。

問いを立てるところから実装までを、一人の作り手が往復している。こういう記事を作りたいと思っていた。ただ、個人で作るには実装量が重いとも感じていた。

なぜ、読むより触れる方が分かるのか

こういう記事のアイデア自体は、バイブコーディングよりずっと前からある。2011年、Bret Victorは「Explorable Explanations」というエッセイで、テキストを消費する情報ではなく、思考するための環境として使うことを提案した。読者が著者の仮定を変えて、その結果を自分で確かめられる記事だ。

“A reactive document allows the reader to play with the author's assumptions and analyses, and see the consequences.”

リアクティブなドキュメントは、読者が著者の仮定や分析を操作し、その結果を見ることを可能にする。

翌2012年には、New York Times が雪崩事故を追った「Snow Fall」を公開した。スクロールするたびに動画やアニメーション、シミュレーションが本文の理解を助ける作りで、スクロールテリングの原点と言われ、Pulitzer賞も受賞している。

Victorの考えを具体的な形にしているのが、Nicky Caseだ。作品はどれも「複雑なシステムを理解させる」ことを目指していて、たとえばThe Evolution of Trustでは、ゲーム理論の古典「囚人のジレンマ」を30分ほど遊びながら、信頼がなぜ崩れ、どうすれば築けるのかを理解できる。

その中身をごく単純なモデルにして、条件ごとに並べると次のようになる。

Distill の「Communicating with Interactive Articles」は、インタラクティブな記事が理解を助ける理由として、自己反省、カスタマイズ、段階的開示を挙げている。先に自分の予想を置いてから答えを見る、自分の条件に当てはめてみる、理解の順番に沿って少しずつ見せる、といったことだ。

学習の研究にも近い話がある。Freeman et al. (2014) のメタ分析では、従来の講義形式は、アクティブラーニングと比べて失敗率が1.5倍だった。大事なのは派手な演出より、読者が考える余地を設計することなんだと思う。

Nicky Case は作り方も「How I Make Explorable Explanations」に書いている。説明したいことをゲームにするプロセスで、まず伝えたいことを短い問いに絞り、読者が触れる動作を1〜2個に決め、紙やプロトタイプで素早く試してはルールを削っていく。

バイブコーディングで、何が変わったのか

変わったのは、「コードを書く人」の定義だと思う。たとえば、エンジニアではない人たちがこんなものを作っている。

ほかにも、いくつか動きがある。Microsoft の Satya Nadella は LlamaCon 2025 で、社内コードの20〜30%がAIで書かれていると話した。自然言語でアプリを作る Base44 は、2025年6月にWixに8,000万ドルで買収された。Sarkar と Drosos の研究は、vibe coding を、プロンプト、実行、素早い評価、手での修正を繰り返す制作サイクルとして分析している。

もちろん批判もある。設計やレビューを飛ばせば、実装は簡単に破綻する。それでも、The Pudding のように一人で全工程を担うのは、以前ならかなり重かった。いまは、個人が試作して公開するところまでは現実的になっている。

The Pudding のクオリティに個人が追いつくのは、まだ難しい。何を作って何を出すかを決める編集の責任は、変わらず作り手の側に残る。

AIが作ったHTMLを、そのまま載せていいのか

コードが書けるということは、動くものを作れるということだ。従来のブログ記事はテキストと画像、せいぜい埋め込み動画までで、構造、根拠、比較、出典を同じ画面で読ませるには限界があった。コードがあれば、数字を大きく出したり、根拠を同じ粒度で並べたり、データをグラフにして読み方と限界をすぐ近くに置いたりできる。

ただ、AIが出したHTMLをそのまま載せると、作業用のUIや弱い図まで読者に見せてしまう。だから、AIに作らせたHTMLは公開物ではなく、Markdownと公開記事の間に挟む単一HTMLの下書きとして扱う。Thariq Shihipar の「The unreasonable effectiveness of HTML」には9カテゴリ20個のデモがあって、比較を横に並べる、流れを地図にする、操作感だけ先に試す、といった使い方が並んでいる。どれも完成品というより、AIに作らせた考えの途中を、ブラウザで読める、比べられる、触れる形にしたものだ。

画面にすると、Markdownでは流れてしまう粗が見える。見出しの重複、弱い図、根拠の遠さ、スマホでの崩れは、ここで目で潰せる。レビュー用のチェック表や作業ログ、コピー用のメモは読者には要らないので落とす。残すのは、予測、比較、フィルタ、図解のように触ることで意味が変わる部品で、それを本文、図、表、操作、引用に分けて、記事のコンポーネントへ移す。

単一HTMLは、公開するための形式というより、編集するための形式だ。この記事は読む価値のある形になっているか、を確かめる作業台なので、公開するときには削る判断も同じくらい大事になる。

このブログでやりたいこと

個人で作るには重い、という前提は、Claude Codeを使うようになって少し変わった。このサイトもほぼ全部Claude Codeで作っていて、自分が「こういう感じにしたい」と言葉にし、AIがデザインやコンポーネント、アニメーションのコードに落とし込んでいる。

この記事も同じで、文章は自分が書いているけど、図やレイアウトはClaude Codeと一緒に作った。この記事自体が、バイブコーディングの実践例になっている。

扱うのは、AIエンジニアリング、LLMやAIエージェント、プロダクト開発あたりの話だ。必要なときには、コスト計算のシミュレーターや意思決定のフローチャート、データの可視化のように、読者が自分の状況に当てはめて考えられる形でも書きたい。

毎回インタラクティブにする必要はないし、触ることに意味があるときだけでいい。アイデアがあれば、とりあえず形にできる。形にすればフィードバックがもらえて、それをもとに直せる。このサイクルが、以前より速く回せるようになった。このブログでは、そのサイクルを自分の題材で回していきたい。