Claude と技術記事をつくる — 量産をやめて「インタビュー方式」にした話

はじめに

この Portal に置いている技術記事は、Claude と一緒に書いている。その「付き合い方」を、最近ひとつ大きく変えた。

きっかけは、あまり格好のつかない話だ。この Portal で Google AdSense の審査に何連敗もした。最初はサイトの作り（ドメインの見せ方・ページ速度・規約ページ）を疑い、いっそ基盤ごと WordPress に載せ替えるかとまで考えた。でも突き詰めると、問題は技術スタックのどこにもなく、記事そのものに書き手が一人もいなかったことに行き着いた。

原因は「AI に書かせたこと」だと思っていたが、正確には違った。Claude との付き合い方を間違えていた。この記事はその見直しの記録で、AI に記事を書かせる人には割と汎用的に効く話だと思う。

最初の付き合い方：Claude を「生成器」として使っていた

当初の運用はこうだった。毎週スケジュールで「記事を 1 本追加せよ」という Issue が自動で立ち、Claude がテーマを選び、Claude が本文を書く。自分はほとんど中身に関与していない。Claude を丸ごと生成器として使っていた。

犯人を探したら、自分の GitHub Actions の中にいた。週次 Issue を自動起票するワークフローのテンプレートに、こう書いてあった。

• 既存記事と重複しない新規テーマを選定せよ
• ボリュームは 7〜9 KB を目安に
• はじめに → 本文 → まとめ の構成で

改めて読むと、これは「書き手に思い入れのないトピックを捻り出し、規定の分量まで膨らませろ」という指示だった。悪気なく、しかし正確に、量産を製造する装置になっていた。Claude は指示に忠実だっただけで、出てくる記事が金太郎飴になるのは当然だった。

一番 AI っぽい記事を、自分で読んでみた

自分のブログで一番 AI っぽい記事を探したら、すぐ見つかった。「Next.js generateStaticParams 完全ガイド」。タイトルからして量産記事の匂いがする。

中を数えると、見出しの 7 割が「自分では使っていない機能」の解説だった。多階層ルート（この Portal はルートが 1 本しかない）、ISR（使っていない）、外部 API からのスラッグ取得（ファイルから読んでいる）。「完全ガイド」を名乗って API を端から並べているだけで、大半が自分の実装と無関係だった。

決定的だったのは、この記事について自分が何ひとつ語れなかったことだ。実装で詰まった記憶も、判断に悩んだ記憶もない。ただ動いた機能の教科書的な要約に、署名だけが載っていた。読者が受け取る「手応えのなさ」を、審査する側も同じように受け取っていたのだと思う。

逆に、語れる記事もあった

一方で、読み返しても手応えのある記事もあった。たとえば「draw.io が d.setId is not a function で開けない」。実際に自分が詰まり、外れた仮説を一つずつ潰し、回り道した末に真因へ辿り着いた経緯から生まれたものだ。ちゃんと探偵物語になっている。

この差が答えだった。質を分けるのは「AI が書いたか」ではなく「その人にしか言えないことが入っているか」。素材が本物（実際にハマったバグ）なら、Claude が下書きしても読めるものになる。素材がゼロなら、どれだけ整った文章でも空っぽになる。

つまり Claude を生成器として使うと、素材の有無に関係なく「それっぽい記事」が出てしまう。ここが落とし穴だった。Claude の使いどころは、書くことではなく、素材を引き出すことの方だった。

新しい付き合い方：Claude に「自分をインタビューさせる」

そこで役割を反転させた。「Claude にトピックを選ばせて書かせる」のをやめ、Claude に自分をインタビューさせることにした。

流れはこうだ。

1. Claude が題材について自分に質問を投げる。「これに最初に遭遇したとき、何をしていた最中だった？」「分かった瞬間、どう思った？」「途中で何を疑って外した？」——コードからは絶対に読めない、記憶の中にしかない部分を掘る。
2. いったんまとめさせ、一次体験の濃さをチェックする。文量は目安であって判定基準ではない（「完全ガイド」は長いのに空っぽだった）。足りなければ追加でインタビューする。
3. 掘っても何も出てこなければ、破棄する。 それは記事にするほどの内容ではなかった、というだけのこと。別の題材に移るか、Issue ごと閉じる。

この 3 番目——書くに値しないなら生ませない、というキルスイッチ——が一番効く。「完全ガイド」を捨てられる仕組みが最初からあれば、あの記事はそもそも生まれなかった。

実際にこの方式を draw.io のバグ記事で試すと、コードには残らない情報が次々に出てきた。あの図はいつもどおり Claude に生成させたもので、それを開こうとして初めて沼ったこと。「手元なら大丈夫なはず」「拡張機能のせいだからブラウザで見ろ」と何度もミスリードされ、ブラウザでも壊れて詰んだこと。最終的に、白紙のサブエージェントに複数視点で見てもらって真因に辿り着いたこと。どれも、インタビューされて初めて言語化された部分だった。

方法を「スキル」に閉じ込める

ただ、こういう方法は「今度から気をつけよう」では続かない。手順をドキュメントに書き残しても、次に書き始めるときには忘れている。実際、量産を指示していたあのテンプレートも、もとは良かれと思って書いたルールだったはずだ。心がけは、いつか必ず風化する。

そこで、このインタビュー方式とキルスイッチを、Claude Code のスキル——名前で呼び出せる手順のまとまり——として定義することにした。記事を書くときにそれを名指しで起動すれば、「まず質問で記憶を掘る」「濃さが足りなければ追撃する」「出てこなければ破棄する」という流れが、毎回そのまま適用される。書き手の意志力ではなく、仕組みの側で守られる。

AI との付き合い方は、心がけよりも「呼び出せる形」にしたほうが定着する。うまくいった手順を見つけたら、文章で自分を戒めるのではなく、いつでも同じように起動できる単位に閉じ込めておくといい。ここはツールに依存する話だが、Claude を使うなら Claude の道具立て（スキル）に乗せてしまうのが早い。

運用も変える：文章を読むのをやめて、描画を見る

付き合い方をもう一つ変えた。レビューのやり方だ。

記事の良し悪しは、原稿を眺めても分からない。見出しの重さ、余白、コードブロックの見え方、読み進めたときのリズム——実際に表示された姿を見て初めて「この節は手応えがないな」と気づける。なのに以前は、書いたテキストをその場でレビューして良しとし、見た目は公開後の本番任せにしていた。これは検証の放棄だった。

そこで、記事は公開する前に必ずプレビュー環境へ出すことにした。手を入れるたびに自動で反映され、本番と同じ見た目で確認できる。読んでみて薄いと感じたら、インタビューに戻って掘り直すか、破棄の判断に戻る。「本当に公開してよいか」の最終確認は、実物を見たそのあとでいい。

「テキストをレビューする」から「レンダリングされたページをレビューする」へ。これは技術記事に限った話ではなく、ドキュメントでもニュースレターでも同じだと思う。読み手に届く形を見ないまま、公開の可否は判断できない。

おわりに

正直に書くと、この記事自体も、いま説明したインタビュー方式で書いた。Claude に自分の失敗を根掘り葉掘り聞かれ、AdSense に何連敗したか、どこで「何も語れない」と気づいたかを引き出されて、ようやく形になった。

Claude に記事を書かせること自体が悪いのではない。書き手の一次体験を素材にせず、トピックを製造してしまう使い方が問題だった。生成器としてではなく、こちらの記憶を掘る編集者・壁打ち相手として使うと、Claude はまったく別の道具になる。

AdSense に通るかどうかは、まだ分からない。でも少なくとも、これで出す記事には書き手が一人いる。それだけは、前の量産記事たちと決定的に違う。