導入事例からノウハウ記事をAIで書こうとしたら、書けなかった——AIの質問に答えて書き直した15本

このブログは、自社のCMS「writeWired」のサイトを、AIと一緒に作り直してきた記録です。質問づくりは2026年7月末、この記事の中心になる作業は8月3日と4日の2日間で、どちらもClaudeと進めました。

やりたかったこと：導入事例から、検討する人の役に立つ記事を作りたい

導入事例から、検討する人の質問を作らせた

writeWiredのサイトには、お客さんの導入事例が20本ほど載っています。どんな会社が、どんなサイトを、どう作ったかを書いたページです。

ここから、CMSを検討している人の役に立つ記事を作れないかと考えました。事例には、検討している人が「うちもこれだ」と思う場面が書いてあるはずです。

そこで、AIに導入事例を読ませ、導入を検討している担当者の立場で「ここが知りたい」という質問を作らせました。質問は千を超えました。この質問に私が答えていけば、検討する人の役に立つノウハウ記事になる。そういう目論見でした。

質問が生々しすぎて、そのまま答えられなかった

ところが、質問を読んでいくと、どれも特定の案件の話になっていました。「この会社のこの仕組みは、うちの場合どうなるのか」という形です。答えを書けば、その会社の作りを説明することになります。公開できる記事にはなりません。

そこで私は、方向を変えました。事例への質問に答えるのではなく、writeWiredでサイトを作るときの考え方を、場面ごとの定石としてまとめる。1つの考え方を1ページにする形です。目次を起こすと、51本になりました。

材料は、導入事例に加えて、公開しているサイトのテンプレートと、いくつかの案件の実装です。どう作ったかは、実装を見れば分かります。

こうやってみた：AIに下書きさせ、21本は赤を入れて公開した

51本のうち、データの持ち方とテンプレートの作り方の21本は、Claudeが下書きし、私が一本ずつ赤を入れました。社内の言葉が混じっていないか、例が特定の業種に寄っていないか、といった直しです。この21本は、その日のうちにサイトで公開しました。

残りの30本は、権限、移行、外部連携、運用、プロジェクトの進め方などです。こちらは、Claudeにまとめて書かせました。事例への質問に答える形はもうやめていたので、書く作業ごとAIに任せてよいだろう、と考えたからです。

こうなってしまった：30本は、何が言いたいのか分からなかった

主張を並べても、当たり前のことしか言っていない

30本の下書きを読んで、私は「うーん。良くわからないなぁ」と返しています。Claudeが記事の名前と要約を並べ、残す記事と落とす記事の案を出してきましたが、それを見ても「全般的に抽象的すぎでわからぬ。何を主張したいのだ？」でした。そこでClaudeが、各記事の主張を一文ずつ並べ直しました。たとえば、移行の記事の主張はこうです。

棚卸しは機械にやらせます。人がやるのは判断だけです。

間違ってはいません。でも、誰が書いても同じことを言う一文です。読む人が「なるほど」と思う差分がありません。

読み返して、だめな理由は三つありました。

• 方法論を上から言っているだけで、参考にならない
• 当たり前の要望に、当たり前の答えを書いている
• 困りごとの場面が書けていない。書こうとすると、創作になる

直そうとしても、同じ壁に当たった

捨てる前に、直せないかと粘りました。製品ではこう動く、という欄を足す。体験談の形に変える。具体的なケースから書き出す。実際の案件の実装から例を掘り出して入れる。

どの手も、同じ壁に当たりました。具体的にすると、創作になるか、特定の会社だと分かってしまう話になる。一般化すると、当たり前の話になる。

30本書いて、残ったのは0本でした。

材料に、判断の理由が入っていなかった

なぜ書けなかったのか。振り返ると、材料の側に原因がありました。

実装に残っているのは、解決したあとの姿だけです。どう作ったかは分かります。でも、なぜそう作ったのか、その前に何で困ったのか、何をやめたのかは、どこにも書いてありません。判断の理由は、私の頭の中にしかありませんでした。

導入事例のほうは、具体的すぎました。会社名を伏せても、たとえばフォームの項目の組み合わせだけで、どの会社の話か分かってしまいます。事例は読み物として書いたもので、ほかの記事に使い回すことを考えて書いていませんでした。

その案件で実際にどう判断したかを、渡した材料からは確かめられませんでした。今回の30本では、その判断の理由が、一般論か創作で埋められていました。

だからこうしてみた：AIに質問させて、私が答えた

公開した21本も、薄かった

30本の失敗のあとで、公開した21本を読み直すと、こちらも薄いことに気づきました。どう作るかは書いてある。でも、なぜそう作るのかがない。赤入れで言葉や例は整いましたが、理由は足されていませんでした。

理由を足せるのは、私だけです。そこで、21本を私の言葉で書き直すことにしました。その前に3本を取り下げ、残りを書き直す対象にしました。

1本ずつ質問が来て、私は思ったまま答える

やり方は、Claudeに質問させて、私が答える形にしました。最初に導入事例からAIに作らせた質問は、検討する人の立場で事例に向けたものでした。今回は違います。書き直す記事ごとに、なぜそう作るのかを私から聞き出すための質問です。Claudeが1本ずつ質問を出し、私はチャットで思ったまま答える。整理と清書は、Claudeが受け持つ。書き直す記事を、1日で一周できました。

一人で書くと、言いたいことを端的に言って終わります。質問が外から来ると、自分では自分に聞かない問いが来ます。その設計で何を守っているのか。やらないと決めていることは何か。答えているうちに、文章にしたことのない言葉が出てきました。

• writeWiredは、ページで情報を管理しません。データ設計が一番重要です
• エディターに自由に書いたテキストを除けば、writeWiredの情報はすべてマスタとして管理します
• パッケージの機能が、サイト構築の足かせになってはならない。既製のメニュー機能やバナー機能を作らないのは、このためです

三つ目は、20年やってきて初めて文章にしました。

AIが一般論で埋めたところを、経験で直した

書き直しの途中でも、Claudeが一般論で埋めてくることはありました。テンプレートの分け方の記事で、困りごととしてこう書いてきたときです。

気がつくとテンプレートが50本、というサイトは珍しくありません。

私はこう返しました。「これがなぜ困るの？現に必要だから80個あるサイトもあるわけだし」。

実際に、80本余りのテンプレートで問題なく動いているサイトがあります。一枚一枚が、別の作りのページだからです。困るのは本数ではありません。似たページのためにテンプレートを複製して少しずつ変えていくと、共通の直しを複製の数だけ繰り返すことになる。困るのは、複製です。

この記事の要約は、具体の一行に書き直しました。

お知らせと商品でテンプレートは分かれます。お知らせの中の見た目の違いでは、分かれません。

80本のサイトは、本数が多くても複製で増えたものは一枚もない例として載せています。

「テンプレートが多いと困る」は、もっともらしい一般論です。でも、現場を見てきた側からすると、困りごとの正体がずれています。このずれは、経験がないと気づけません。

どうなったか

質問に答えていく中で、特定の案件の話になっていた記事などをさらに取り下げ、近い記事は統合し、1本を書き加えました。最終的に15本を「設計リファレンス」という名前で公開しています。導入事例をまとめたものではなくなったので、名前も変えました。

AIにまとめて書かせた30本は、消さずに見送りにしています。実際の案件の話を、公開できる形で添えられるようになったら、そこから書き直すつもりです。

今回の作業で分かったこと

AIに書かせて薄くなったら、文章を直す前に、材料に判断の理由が入っているかを確かめる

30本が当たり前の話になったとき、私は文章の形を変えて粘りました。欄を足す、体験談にする、具体例から始める。どれも効きませんでした。足りなかったのは文章の形ではなく、材料に入っていない「なぜそう作ったか」だったからです。

今回渡した実装やページには、結果しか残っていませんでした。それを元に書かせた記事では、理由の部分が一般論か創作で埋まっていました。薄いと感じたら、まず材料に理由が入っているかを見る。入っていないなら、文章をいくら直しても埋まりません。

判断の理由は、自分で書くより、質問されて答えるほうが出てくる

理由を持っているのは私でした。ただ、一人で書くと端的に言って終わります。Claudeに質問させて答える形にしたら、「何を守っているのか」「何をやらないのか」と、自分では立てない問いが来ました。20年分の判断の理由が、初めて言葉になりました。

人が答え、AIが整理して清書する。この分担なら、AIが書けない部分を人が埋め、人が苦手な清書をAIが埋められます。それでもAIは一般論を混ぜてくることがあるので、答えた本人が読んで直す工程は残ります。

事例を記事の材料にするなら、使い回す前提で書き方を決めておく

導入事例は、具体的すぎて使い回せませんでした。会社名を伏せても、構成の組み合わせで特定できてしまいます。事例から別の記事を作りたいなら、事例を書く時点で、どこまでを公開できる事実として書くか、どの粒度で書くかを決めておく必要があります。

それだけでは足りないことも、今回分かりました。どう作ったかが残っていても、なぜそうしたかがなければ、記事の中身にはなりません。これから事例を材料にするなら、公開できる範囲の事実と一緒に、困っていたこと、選んだ理由、採らなかった方法も残しておきたいと考えています。今回は、そのどれもないまま事例と実装を材料にしようとして、つまずきました。