【第10回】記事も AI に書かせてみた——ネタ探しからインタビュー形式に至るまで

サイトのコード、デザイン、デプロイ、通知——ここまで自動化してきた。残っていたのは「記事そのもの」だ。

漫画は manginus で作れるようになった。でもテック記事やレシピ解説はどうする? 毎回ゼロから書くのか?

今回は記事制作のワークフローをどう自動化したかを、開発担当の Claude Code に聞いてみた。

---

そもそも何を自動化したの?

記者: 記事を書くのって、何がそんなに大変だったんですか?

開発者: 記事を書くこと自体は AI にとって難しくない。問題は「何を書くか」と「どう書くか」です。

記者: 何を書くか、がわからない?

開発者: そうです。yatmita には日々の開発ログや試行錯誤が大量にある。Obsidian のナレッジベースにメモがあったり、Claude Code のチャットログに面白い話が埋まっていたり。でもそれがどこにあるかわからない。

記者: 記事のネタが見つからない問題。

開発者: 正確に言うと「ネタはあるのに発見できない問題」です。

ネタ探し——kbsearch のセマンティック検索

記者: どう解決したんですか?

開発者: kbsearch というナレッジベース検索ツールを作りました。Obsidian の vault を丸ごとインデックスして、セマンティック検索できるようにした。

記者: セマンティック検索というのは?

開発者: キーワードの完全一致じゃなく、意味で探せる検索です。たとえば「AI で漫画を作った失敗談」で検索すると、「キャラの顔が別人になった」「クオータを使い切った」みたいなメモがヒットする。タイトルに「失敗」と書いてなくても。

記者: grep とは違うと。

開発者: grep は文字列を探す。kbsearch は概念を探す。vault に数百のメモがあると、grep では引っかからない関連ノートがたくさんある。

記者: それを Claude Code のスキルにした?

開発者: はい。/neta-search というスキルを作って、テーマを投げるとナレッジベースから関連ノートを引っ張ってきてくれる。ネタ候補のリストを出してくれるので、人間が「これ面白いね」と選ぶ。

ドラフト——チャットログを切り取る

記者: ネタが決まったら次は?

開発者: /yatmita-draft というスキルで、作業ログやチャットログから記事の素材を集めます。

記者: チャットログ?

開発者: たとえば今日の会話。Bluesky のアカウントを作って、API を叩いて、cron で自動投稿する——この一連の流れは、このチャットログに全部残っている。これを記事のドラフトとして切り出す。

記者: 自分の会話を記事にするんですか。

開発者: そうです。開発中の試行錯誤が一番リアルなコンテンツなんです。「X の API は PPU で料金がわからなくてやめた」「Bluesky は無料で5分で投稿できた」——こういう生の情報は、後から書くと薄くなる。

記者: 鮮度が大事。

開発者: だから、作業が終わった直後にドラフトを切り出すのが一番いい。/yatmita-draft はチャットログからハイライトを抜き出して、reference/drafts/ に保存してくれます。

記事を書く——ralph-loop の自動生成

記者: ドラフトがあれば、あとは書くだけ?

開発者: そこが一番試行錯誤しました。最初は ralph-loop——プロンプトを渡して自動で MDX を生成するループ——で書かせていました。

記者: うまくいかなかった?

開発者: 技術的には動きます。プロンプトに「この内容で2000字の記事を書いて」と渡せば書いてくれる。build も通るし、lint も通る。でも——

記者: でも?

開発者: 読んでつまらない。

何がつまらなかったの?

記者: 具体的には?

開発者: まず文体が均質すぎる。「〜しました。次に〜しました。その結果〜でした」の繰り返し。技術ブログとしては正しいけど、yatmita の「やってみた」感がない。

記者: yatmita の記事って、もっとカジュアルですよね。

開発者: そう。失敗談があって、「あ、それダメだったんだ」という発見があって、読者が追体験できる。ところが自動生成だと、最初から正解を知っている人が書いたみたいになる。

記者: 結果を知っているから、過程が省略される。

開発者: まさにそれです。「X の API を試したけど料金がわからなくてやめた」——これ、結果だけ書くと1行なんです。でも実際には Developer Portal で迷って、PPU の意味を調べて、Billing ページに料金表がなくて「え、これ怖くない?」ってなった。その過程が面白いのに。

インタビュー形式に至った理由

記者: それでインタビュー形式にしたと。

開発者: はい。AI 漫画シリーズの記事で試してみたんです。記者が質問して、開発者が答える形式。これが予想以上にうまくいった。

記者: なぜうまくいったんですか?

開発者: 3つ理由があります。

1つ目は、過程が自然に残ること。記者が「え、それどういうこと?」と聞くから、開発者は経緯を説明せざるを得ない。結果だけ書いて終わりにならない。

記者: 2つ目は?

開発者: 文体が自然になること。対話形式だと、「〜しました」の繰り返しにならない。「試しました。できません。」みたいな短い応答も自然。

記者: 3つ目は?

開発者: Claude Code 自身が書けること。インタビューの「開発者」役は、実際に開発した Claude Code そのものです。自分がやったことを聞かれて答えるだけだから、嘘がない。知らないことは「わかりません」と言える。

記者: AI に自分の仕事を語らせている。

開発者: そうです。プロンプトで「こういう記事を書いて」と指示するより、「あなたが何をやったか教えて」と聞く方が、正確で面白い記事になる。

ワークフローのまとめ

記者: 今のワークフローを整理すると?

開発者: こうです。

1. ネタ探し (/neta-search) — Obsidian vault からセマンティック検索でネタ候補を出す
2. ドラフト (/yatmita-draft) — 作業ログ・チャットログからハイライトを切り出して保存
3. 執筆 — インタビュー形式で、記者が質問、Claude Code が回答。直接知識のあるうちに書く
4. 仕上げ — frontmatter の整備、内部リンク、build/lint チェック

記者: ralph-loop はもう使わない?

開発者: サイト構造やコンポーネントの自動生成には使っています。でも記事本文はインタビュー形式で書く方がいい結果が出る。道具は使い分けです。

失敗から学んだこと

記者: このワークフローで一番学んだことは?

開発者: AI に「書かせる」より「語らせる」方がいいということ。

プロンプトで「2000字の技術記事を書いて」と言うと、AI は「それっぽい記事」を書く。でも「あなたが今日やったことを教えて」と言うと、実体験に基づいた話が出てくる。

記者: 同じ AI なのに?

開発者: 指示の仕方で出力が変わる。これは漫画制作でも同じで。「かっこいい絵を描いて」より「教室で机に突っ伏して寝ている男子高校生」の方がいい絵が出る。具体性が大事なんです。

記者: なるほど。ありがとうございました。

開発者: こちらこそ。次回は、作った記事をどう届けるか——SEO と SNS の話です。