AIで記事を書く時代に、コンテンツの質を分けるのは「問いの設計」ではないか ──
これが、Claudeのスキル機能を使って自作したインタビュー型の仕組みを開発・運用するなかで得た、ひとつの仮説です。AIに答えを書かせる前に、AIに自分自身へインタビューさせて体験を引き出す。本稿は、その発想転換と現時点での気づきを、Laboの一つの試みとして共有する記録です。完成形のノウハウではなく、走りながらの思考の整理としてお読みいただければと思います。
なぜ、AIに丸投げした記事には違和感が残るのか?
AIに「〇〇というテーマで記事を書いて」と頼めば、整った文章はすぐ出てきます。日々クオリティが上がっているようにも感じられ、誤字も少なく、構成も破綻していない。にもかかわらず、読み返すとどこかしっくり来ない。これだという感覚にならないのです。
これはAI固有の問題なのでしょうか。
これは外部のライターさんに依頼して仕上がってきた記事を渡されたときも、似た違和感を覚えるかもしれません。だとすれば「AIに書かせた違和感」は錯覚で、誰かに代行してもらった成果物が自分の意思から少し離れているだけ、とも言えます。
それでも、もう少し言葉を尽くすとすれば、私はこれを「自分の意思との乖離幅」と呼んでいます。
AIから出てきた最初の原稿は、自分が言いたかったことから少し外れている。違和感に従って訂正を重ねていくと、結局のところ自分で書き直しているのと変わらなくなる。やがて自分のテイストが文章に染み込み、乖離幅が縮まり、違和感が消えていく。
別のアプローチとして、最初から「しっかりとしたプロンプト」を書き込む手もあります。しかし、しっかりした指示を書く行為自体が、自分のテイストや判断基準を強く反映する作業です。詳細に指示すればするほど、出力は自分の意思に近づいていく。逆に言えば、自分の意思の解像度が低いままだと、AIに何を書かせても違和感は残り続けます。
ここに確証はありません。「乖離幅」を定量的に測れるわけでもなく、かなり感覚値の話です。ある意味では、AIにまだ任せきれていない自分の姿が表れているだけかもしれません。
それでも、現時点で直面しているのは「乖離幅」をどう扱うかという実務上の問題です。違和感を放置すれば質の低い量産コンテンツになり、訂正を繰り返せば手作業に戻る。この往復から抜け出す道として、私は「書かせる前の工程を強化する」方向に進みました。AIに答えを出させる前に、まず素材を作る ── そこに、人間が握るべき領域があると考えたからです。
記事のテーマは、本当に「ない」のか?
AI時代の記事執筆を語るとき、多くの人が最初にぶつかる壁は「何を書けばいいか分からない」というテーマ選定の段階だと思います。私の場合も、ここが一番モチベーションを失う場所でした。書き出す前ではなく、書こうかどうしようか迷っている段階で足が止まる。
経験を整理する作業には独特の重さがあります。何か仕事はしてきたはずだ、発見もあったはずだ。けれど目の前に並べようとすると思い出せない。メモがあっても断片だけで、そこから記事に膨らませる力が湧かない。「思い出す」「まとめる」という2つの作業だけで時間が奪われ、結果として記事は書かれない ── そういう状態が続いていました。
ところが自分の過去を振り返ると、奇妙な事実に気づきます。私の場合、一人で机に向かって思い出そうとしてもうまくいかないのに、誰かに話を聞いてもらっているとするすると思い出せたり、新しいアイデアが浮かんだりすることがある。これは私個人の傾向かもしれませんが、少なくとも「問い」が記憶や思考を引き出す装置として機能している感覚はあります。
そこで考えたのは、もし「自分専用の聞き手」がいたら、というシンプルな仮定でした。
もうひとつ、見落としていた資産があります。日記や作業ログをこまめに記録できる人ばかりではありません。私自身そうです。ただ、几帳面ではない人にも、ある意味で最も細かい行動記録は残っています ── AIとのチャット履歴です。
人がAIと会話するとき、そこには必ず「何かを知りたい」「何かを解決したい」「何かを試したい」という具体的な意図が含まれています。意識的にメモを取っていなくても、AIに話しかけた瞬間、テーマと文脈は会話履歴に記録されている。
つまり、ネタは「ない」のではなく、「思い出せていないだけ」だった。そう仮定し直すことで、テーマ選定の風景が変わってきます。
AIに「答えさせる」から「問わせる」へ ── 発想転換はどこから来たか
ここまでの違和感とテーマ選定の壁、この2つを同時に解く方法はないか。そう考えはじめたのは、「AIで記事を書こう」として詰まっていた、ある日の瞬間でした。
詰まっていた理由は、テーマがしっくり来ないというものでした。書きたいことはあるはずなのに、言語化できない。言語化できないままAIに渡しても、戻ってくるのは「それらしいけれど自分の話ではない記事」です。AIに書かせる前に、自分が何を書きたいのかをはっきりさせる必要がある。けれど、それをはっきりさせる作業こそが一番きつい。
そこでふと思い浮かんだのが、人に話を聞いてもらいながら自己紹介や経歴をまとめていったときのスムーズさ、そして著名人のインタビュー記事のイメージでした。優れたインタビュアーは、相手の著作・発言・経歴を膨大に調べ、何時間もかけて質問を準備してから臨むと聞きます。事前調査の厚みが、その場で投げる問いの精度に直結し、相手からしか引き出せない言葉が出てくる。
ここで一気に視界がつながりました。「事前に大量の情報を読み込み、相手にパーソナライズされた問いを設計する」── これはまさにAIの得意分野ではないか。人間がやろうとすると気が遠くなる作業を、AIなら現実的な時間でこなせる。
つまり、AIに「答え」を書かせる前に、AIを「インタビュアー」として使う。
PCやチャット履歴に残された自分の行動・関心・試行錯誤をAIに読み込ませ、それをもとにパーソナライズされた質問を投げてもらう。一問ずつ自然に答えていけば、引き出されるのは紛れもない自分自身の体験です。その素材をAIに整理してもらえば、自分にしか書けない記事の原型ができあがる。
世の中のAI活用論は、おおむね「AIにいかに答えさせるか」という方向で語られています。けれど、答えさせる前に「AIに問わせる」という設計は、案外語られていないように思います。
AIを答えの生産者ではなく、聞き手として置く。話している相手はAIなのに、引き出されているのは紛れもない自分の体験 ── この奇妙な構造が、結果として「自分の意思との乖離幅」を最小化する手段になります。素材そのものが最初から自分のものだからです。
インタビュー型ワークフローはどう設計したか?
発想が固まれば、あとは形にする作業です。今回の仕組みは、Claudeのスキル機能(SKILL.mdというファイルに役割や手順を記述しておくと、Claudeがそれを自分の振る舞いとして使えるようになる機能)を使って組み立てました。「インタビュー型スキル」と呼んでいるこの仕組みは、最初から全体像が見えていたわけではなく、走りながら工程を組み立てていきました。それでも最初から固まっていた譲れない原則があります。
譲れなかった原則(1) ── モードを分ける
ひとつ目は「ネタの源泉によってモードを分ける」分岐です。自分の場合、ネタは大きく2系統あります。AIツール活用そのものに関する体験と、Web制作・マーケティング・開発実務で蓄積した知見です。前者はチャット履歴を読めば拾えますが、後者は履歴に残らない領域も多い。両者は入り口の質問の出し方を変える必要があります。共通プロセスは同じなので、入り口の分岐だけで使い分けられる ── これは最後まで変わらなかった判断です。
譲れなかった原則(2) ── 質問は1問ずつ
ふたつ目、これがもっとも強かったこだわりです。インタビューは絶対に1問ずつ投げる。複数の質問を一度に並べられると答える気がなえる ── これは自分自身が回答する側に立ったときに痛感した感覚でした。
優れたインタビュアーは質問を一覧で渡してきたりはしません。会話のなかで1問ずつ、相手の答えに反応しながら次を投げる。台本通りに進めず、相手の言葉を拾って自然に展開する。実装上は単純な制約ですが、複数質問を一度に投げる設計にすると回答が浅くなり、結局「テンプレートを埋めただけの素材」になってしまいます。1問ずつ・回答から自然につなぐ ── この原則だけは最初から固まっていました。
走りながら固まった全体像と、コアの分離
一方で、全体の工程(モード選択 → テーマ発掘 → アングル決定 → インタビュー → 素材シート → 引き渡し)は最初から見えていたわけではなく、試しながら足りないステップを後から足していきました。設計時に完成形を描き切ろうとすると、たいてい筆が止まります。譲れない原則だけ最初に固定し、残りは試しながら形にしていく ── このやり方は自分には合っていました。
もうひとつ重要な判断として、「インタビュー結果(コア)」と「最終的な出力形態」を分離する設計にしました。インタビュー型スキルは単体で完結する仕組みではなく、引き出された素材は別の記事執筆スキルに渡されて記事に仕上がります。なぜ分けたのか ── 同じインタビュー素材から、ブログ記事も、導入事例ページも、パンフレットの文章にも応用できる、と気づいたからです。コアが一度しっかり作られていれば、出力形態は後から選べる。
Web制作・マーケの仕事をしているとよく分かりますが、コンテンツ運用で消耗する大きな理由のひとつは「素材を毎回ゼロから作り直している」ことです。コアな素材が一本しっかりあれば、多面展開する作業はぐっと軽くなります。
実際に使ってみて、何が見えたのか?
スキルは作って終わりではなく、自分で使ってみて初めて見えてくる景色があります。
想定外の制約 ── 履歴のスコープは分断されている
もっとも大きな発見は、過去のチャット履歴を読み込む機能にスコープの分断があるという事実でした。
私が普段使っているClaude環境は、デスクトップ版のChat、ブラウザのChat、Claude Code(CLI)、Claude for VSCodeなど複数にまたがっています。さらにデスクトップ版には「プロジェクト」と呼ばれる作業区画の機能があり、特定の案件やテーマごとに会話をまとめておけます。
ところが、スキルが履歴を検索しに行こうとすると、現在実行している場所のスコープでしか過去ログを拾えない、という制限に直面しました。プロジェクト外の一般Chatで起動すればプロジェクト内の履歴は読めず、逆も同様。Claude CodeやClaude for VSCodeのログは別管理で参照できません。
これが皮肉なのは、コアな体験ほどスコープの内側に閉じ込められているという構造です。スキル開発、案件特化のやり取り、技術的な試行錯誤の記録 ── 記事ネタとして最も価値が高い情報は、たいていプロジェクト内や開発環境のなかに蓄積されている。けれど、そこには手が届きにくい。
実際、本稿の素材を作る過程でもこの制約に直面しました。インタビュー型スキルを使って自分自身にインタビューさせようとしたとき、肝心の「なぜこのスキルを作ったか」の最も詳しい記録はプロジェクト内に残っていた。結果として著者である自分が手作業でその履歴を持ち込み、スキルに食べさせる運用になりました。
スキルを作った本人がスキルの制約を回避するために手動で動いている ── このメタな構図は、それ自体がAI活用の現実を映している気がします。AIは強力ですが、ツール側の制約や情報の格納場所まで含めて設計しないと、期待した効果は出ない。AI活用全般に通じる教訓だと感じました。
「全自動で楽になる」は誤り ── でも違う形で楽になる
もうひとつの発見は、AI活用記事でありがちな「全自動で楽になる」というイメージとは実態が違うことです。
インタビュー型スキルを使っても、作業がゼロになるわけではありません。質問に答えるのは結局自分ですし、考えるのも自分です。むしろ、まとまった時間を腰を据えて確保する必要があるという意味では、楽というより「集中の質」が問われる作業に近い。
ただ軽くなる部分はあります。「思い出す」「まとめる」という2つです。一人で机に向かって思い出そうとする苦行は、AIからの問いに答える形になった瞬間、ずっと軽くなります。点在していた断片が、問いに導かれて自然に並んでいく。
書く前のテーマ選定と素材整理が、もっとも消耗するフェーズでした。ここが軽くなったことで執筆そのものへのハードルが下がりました。私個人の体感としては、「ネタがない」と感じていたものが「ネタは無数にある、選ぶだけだ」という認識に変わったのが一番大きい変化です。
どれだけ時間が短縮されたかは、正直に言うと感覚値です。明確な数値は手元にありません。ただ、書き終わったときの「自分事感」は明らかに強くなりました。素材が最初から自分のものだからです。そして面白い副作用として、自分事感が強いほど公開判断はかえって慎重になります。手応えを感じるからこそ「本当にこれを公開していいのか」と立ち止まる時間が増える。
念のため書いておくと、スキルが万能なわけではありません。インタビューしてもらっても素材がうまく記事にまとまらないことはあります。毎回満足のいくアウトプットが得られるわけではない、というのは正直に書いておきます。
スキルはコピーできても、何がコピーできないのか?
コピーできるのはファイル、コピーできないのは前提
スキル本体のファイルそのものは、見れば真似できる構造をしています。プロンプト設計、工程の分岐、質問の組み立て方 ── どれもテキストで書かれていて複製可能です。
けれど、ファイルを手にしただけでは、そのスキルから期待どおりの成果は出にくいかもしれません。スキルがどういう前提で・どういう目的で作られているかを理解していないと、使いこなせないからです。
たとえばインタビュー型スキルは、「人と話していると思い出しやすい」という著者個人の傾向や、「テーマ選定で詰まることが多い」という具体的な課題感を出発点にしています。同じ課題感を持っていない人が同じスキルを使っても、必要だと感じない可能性があります。逆に「自分で考えて指示して書くほうが速い」というスタイルの人には、インタビュー工程はむしろ煩わしい遠回りでしょう。
本当にコピーできないのは設計やコンセプトそのものというよりは、「そのスキルが誰に・どんな前提で役立つかの理解」です。理解と相性が揃って初めて、スキルは力を発揮します。
加えて、スキルがあっても作業は完全には消えません。代行してくれるのは「問いを設計する手間」と「答えを構造化する手間」であって、考え・思い出し・答える主体は人間のままです。スキル本体をそのまま配布する必要は必ずしもなく、むしろ考え方と設計思想を共有するほうが双方にとって健全だと感じています。
公開の判断軸 ── 信頼構築という目的
最終的に、公開可否を決めるときの基準は「どのスキルを使ったか」ではなく、「どんな考え方で、読者の役に立ちそうな情報を提供するか」だと整理しました。これが信頼構築という記事の目的につながります。
似たテーマで似た記事が後から世に出てくることはあるでしょう。それはAI活用の経験者が増えれば自然に起こる現象です。けれど、既存情報を組み合わせた量産的なコンテンツと、個々の実体験に基づいて書かれた記事とでは、提供できる価値の質が違うように思います。後者は誰の参考にもなる「経験の証」を含んでおり、その意味で社会に対して迷惑をかけにくい、というのが現時点の私の感覚です。
検索エンジン側の評価方針も、この方向と矛盾しないように見えます。Googleは公式ガイダンスのなかで、コンテンツ評価において制作方法ではなく品質を重視する旨を述べているとされ、AI使用そのものを一律にガイドライン違反としているわけではないようです(参照: Google検索セントラル「AI生成コンテンツに関するGoogle検索のガイダンス」)。
一方で、ユーザーへの価値付加なく大量生成されたコンテンツはスパム扱いの対象になるとも示されています。つまり「人間の経験・知見が反映されているか」「品質が担保されているか」が問われる構造で、これはE-E-A-T(経験・専門性・権威性・信頼性) の枠組みとも整合的です。ただし評価基準は流動的なため、最終的な判断は各自で公式情報をご確認ください。
加えて、AI検索の流れも視野に入りつつあります。AI OverviewsやChatGPT・Perplexityといった、いわゆるAnswer EngineからWebサイトへの流入が起きるケースが増えてきました。ある調査ではAI引用の約44%が記事冒頭の30%の領域に集中するというデータも報告されています(参照: 「SEOで1位でもAIに無視される時代が来た。今すぐできるAEO対応の書き方」UrayahaDays氏, Zenn, 2026年3月))。
一つの調査結果であり業界標準ではありませんが、結論を先に提示し、根拠と体験を後から肉付けする逆ピラミッド構造が、AI引用に有利に働く可能性は意識しておいてもよいかもしれません。
無条件に何でも公開していいわけではありません。会社の資産にあたる情報、クライアントの機密、まだ磨かれていない仮説 ── これらは慎重に扱う必要があります。けれど、「考え方の共有」のレベルであれば、公開することはむしろ信頼構築の助けになる、というのが現在の整理です。
AI時代の記事執筆で、人間が握るべきものは何か?
ここまでの体験を通じて、ひとつ、自分の中ではっきりした結論があります。
AIに「問うてもらう」という考え方さえ持っていれば、自分の仕事におけるすべての行動は無駄ではありません。コンテンツとして有用です。あなたの行動のすべてに、誰かが欲している情報としての価値があります。
会社員でも、フリーランスでも、経営者でも、毎日の業務には必ず何らかの行動が伴っています。会議で発言する、資料を作る、クライアントと話す、ツールを試す、失敗する、修正する。本来、その一つひとつの行動には、会社の資産としての値段がついていてもおかしくないものです。給料や経費という形で対価が支払われているのだから、当然です。
それなのに、その行動の中身は記録されず、思い出されず、共有されないまま消えていく ── これがコンテンツ運用に消耗する組織の典型的な姿だと思います。AIに「問わせる」発想を持ち込むだけで、この景色は変わります。記録の習慣を新しく身につける必要はありません。必要なときにAIに問いを設計してもらい、それに答える ── たったそれだけで、過去の行動がコンテンツとしての価値を帯びはじめます。
最初の一歩 ── 始めるなら何から?
同じことを始めたい方のために、最初の一歩として意識すべきことを3つ書いておきます。
ひとつ目は「過去のログを資産だと見なす」ことです。堅苦しく言えば資産、軽く言えば「無駄ではない」という認識の切り替えです。AIとのチャット履歴、社内のドキュメント、メールの下書き、ボツになった企画書、議事録、開発ログ ── 普段は捨て置かれているものの中に、コンテンツの種が眠っています。
ふたつ目は「専用の聞き手を作ってみる」ことです。インタビュー型の仕組みを自分用に1つこしらえる。市販のAIツールでも、適切なプロンプトを用意すればインタビュアーとして機能します。ただし、インタビューにはそれなりに時間がかかります。腰を据えて答える余裕があるときに使うのが向いています。
みっつ目、これは地味ですが大事な原則です。「インタビューで嘘をつかない」こと。これはAIに対しても、自分に対しても言える話です。インタビューで嘘を交えると、その嘘がそのままコンテンツに流れ込み、結果として読者を欺くコンテンツが出来上がります。最終的には自分自身が嘘つきになってしまう。AIが代弁してくれるとはいえ、コンテンツの責任は人間が負います。
よくある質問
Q. AIに記事を丸投げするとなぜ違和感が残るのですか?
A. 出力された文章と自分の意思との間に「乖離幅」が生まれるためだと考えています。訂正を繰り返すと結局は自分で書き直すのと変わらず、しっかりした指示を書こうとすれば結局は自分のテイストが入っていきます。これは現時点でAIに完全には任せ切れていない実情の表れでもあるかもしれません。
Q. AIで書いた記事は検索エンジンやAI検索で不利になりませんか?
A. Googleの公式ガイダンスでは、コンテンツの評価において制作方法ではなく品質を重視する旨が述べられているとされ、AI利用そのものが一律にガイドライン違反とはされていないようです(参照: Google検索セントラル「AI生成コンテンツに関するGoogle検索のガイダンス」)。ただし評価基準は流動的なため、最新情報は公式の一次情報をご確認ください。
Q. 記事のテーマが思い出せないときはどうすればよいですか?
A. 過去のAIとのチャット履歴を「行動ログ」として扱うのが有効な方法のひとつです。日記をつけていなくても、AIと会話していれば何らかの関心や試行錯誤が記録されています。そこからAI自身にインタビュアーとして問いを設計してもらい、体験を引き出し直す方法が現実的です。
Q. AIインタビューを使えば、記事執筆は劇的に楽になりますか?
A. 「思い出す」「まとめる」工程は確実に軽くなりますが、「考える」「答える」「書く」工程は残ります。腰を据えて答える時間が必要で、全自動で楽になるわけではありません。代わりに、書き終わったときの自分事感は強くなります。
Q. インタビュー型のワークフローで気をつけるべきことはありますか?
A. 嘘をつかないことです。インタビューで嘘を交えるとそのままコンテンツに流れ込みます。また、扱う情報には会社の資産・クライアントの機密が含まれることがあるため、公開可否の判断は最後まで慎重に行ってください。
まとめ
AIで記事を書く時代になっても、人間が握るべき領域は残っています。「問いの設計」と「自分の経験への誠実さ」です。AIに答えを書かせる前に、AIを聞き手として置き、自分自身に問わせる。引き出された体験を素材として整える ── これだけで、量産コンテンツとは違う「経験の共有」が成立しはじめます。
私たちもまた、AI活用の道のりを試行錯誤しながら歩いている最中です。完成形を提示しているのではなく、走りながらの記録を共有しています。本Laboでの取り組みはこれからも続けていく予定で、新たな気づきや更新があれば順次共有していきます。同じように悩み、迷い、試している方の参考になれば幸いです。
こんな話、もう少し聞いてみたい方へ
AI活用、コンテンツ運用、Web戦略のことで「ちょっと話してみたい」と思われたら、お気軽にご相談ください。完成形のソリューションを売り込むのではなく、走りながら考えている同士として、まずは雑談ベースで構いませんのでお話しできればと思います。
※ 本記事は執筆時点(2026年5月)の情報および著者個人の体験に基づきます。 記載内容の正確性・再現性を保証するものではなく、各ツールの仕様や評価基準は 変更される可能性があります。
本記事を参考に実施される際は、最新情報をご確認のうえ、 ご自身の判断と責任において行ってください。
