記事を書き始める前に、「何を・誰に・どこまで書くか」を固めます。 曖昧なまま執筆を始めると、セクションごとにスコープがぶれて一貫性のない記事になります。
ユーザーへの質問は一度に最大3問まで。回答が薄い場合は深掘りします。 抽象的な問いより、選択肢を示す具体的な問いの方がユーザーは答えやすいです。
Q1: 何について書きますか？
技術・ライブラリ・設計手法・トラブル解決などの中から教えてください。
Q2: 読者はどのあたりのエンジニアを想定していますか？
例: 「Goは書けるが、goroutineの制御には自信がない」「Reactは使っているが、状態管理ライブラリの選定経験はない」のように、「〜の経験はあるが〜は詳しくない」という形で教えてもらえると的確な構成を作れます。
Q3: 読者に何を持ち帰ってほしいですか？（A・B・Cの中から最も近いもの）
- A: ハンズオン形式で手を動かしながら理解してほしい（チュートリアル）
- B: なぜそうなのかの内部コンセプトや設計判断を理解してほしい（解説）
- C: 自分が経験した失敗・解決・知見を共有したい（体験談）
Q4: 既存の技術との比較を含めますか？
例: 「ReduxとZustandの比較」「MySQLとPostgreSQLで迷った話」など。 含める場合、どの技術と比較するかも教えてください。
Q5: 読者が「なるほど」と思う瞬間はどこですか？
記事の核心となるポイント（aha momentと呼ばれるもの）を教えてもらえると、そこを軸に構成を組めます。 例: 「型引数に型クラス制約をつけることで、呼び出し側に実装を強制できる瞬間」
インタビューの回答をもとに、次の形式でアウトラインを生成します。
## アウトライン案
対象読者: 〜の経験はあるが〜については詳しくないエンジニア
記事の骨格:
この記事は〜を出発点に、〜を経て、〜という理解に着地するストーリーです。
---
### セクション一覧
1. イントロ: [見出し案]
何を扱う記事で、読むと何が得られるかを30〜50字で示す
2. 背景 or 問題提起: [見出し案]
なぜこのテーマを取り上げるのか。読者が共感できる問題を示す
3. 本論（複数セクション）: [見出し案]
技術の核心部分。設計・コード・考察をここに集める
4. まとめ or 次のステップ: [見出し案]
記事を通じて何が分かったのかを端的に示す
---
確認: このアウトラインで進めますか？変えたい箇所があれば教えてください。
- 対象読者が「知らない可能性が高い」情報
- 世の中の記事に書かれていない観点・判断・失敗談
- コードで示さないと伝わらない部分の実装例
- 「なぜそうするのか」の設計判断の根拠
- 公式ドキュメントの要約（リンクを貼れば済む）
- 対象読者が既に知っているであろう基礎知識
- 記事の核心と直接関係しない周辺知識の説明
- 単なるインストール手順（独自の工夫がない場合）
AIが生成できるのは「公開情報の再構成」まで。記事に一次情報としての価値を持たせるには、 ユーザー自身の経験・判断・失敗をインタビューで引き出して盛り込む必要があります。 記事タイプが決まったら、以下のインタビューをアウトライン確定前に行います。
読者が手を動かしながら理解するタイプ。
1. 何を作るか（完成イメージ）
2. 事前準備・環境
3. 〜を実装する（なぜこの順番か）
4. 〜を追加する（この設計判断の理由）
5. 動作確認（想定外の挙動があれば記載）
6. 応用・次のステップ
チュートリアル型の現場感インタビュー
アウトライン確定前に次の質問をします（最大3問）。
Q1: 手順の中で「公式ドキュメント通りにやったのに詰まった」という箇所はありましたか？ あれば、どのステップで何が起きたか教えてください。
Q2: 環境や前提条件で「ここを見落とすと動かない」というポイントはありましたか？ 例: OSのバージョン依存、特定のライブラリとの競合、権限の問題など。
Q3: 完成したものを使ってみて「思ったより〇〇だった」という感想はありましたか？ 良い方向でも悪い方向でも構いません。
回答が得られたら、詰まりポイントと感想を対応するステップの補足として組み込みます。 「インストールしました」「実行しました」の羅列ではなく、 各ステップの「なぜ」と「ここで詰まりやすい」が見える記事になります。
技術の内部コンセプトや設計思想を伝えるタイプ。
1. 問題提起（この技術が登場した背景・解決する現場の痛み）
2. コアコンセプト（一番大事な概念）
3. 仕組みの解説（内部でどう動くか）
4. 既存技術との比較（何が違うのか・どこに限界があるのか）
5. 使いどころの判断基準（効く現場・効かない現場）
解説型の現場感インタビュー
アウトライン確定前に次の質問をします（最大3問）。
Q1: この技術を使おうと思ったきっかけは何でしたか？ 例: 既存のアプローチで〜が辛かった、チームで〜という問題が起きた、など。
Q2: 実際に使ってみて「これは便利だが、ここは厳しい」と感じた点はありますか？ 公式ドキュメントには書かれていないような制約や落とし穴があれば教えてください。
Q3: 「こういう現場・チーム・規模には向いている/向いていない」という肌感覚はありますか？ 例: 小規模プロジェクトには過剰、大人数チームでは逆に助かる、など。
回答をもとに「効く現場・効かない現場」のセクションを作ります。 「A, B, Cという機能があります」という機能列挙ではなく、 コンセプトと現実の摩擦が見える記事になります。
自分が経験した問題解決や設計判断を共有するタイプ。
1. 状況の説明（何を作っていたか・どういうチームだったか）
2. 問題の発生（何がうまくいかなかったか・なぜ気づくのが遅れたか）
3. 試したこと（失敗した試みと、なぜそれでは駄目だったか）
4. 解決策と理由（なぜこのアプローチが効いたのか）
5. 振り返り・学び（同じ状況に置かれた読者へ）
体験談型の現場感インタビュー
アウトライン確定前に次の質問をします（最大3問）。
Q1: 問題が発生したとき、最初に試みた解決策は何でしたか？ それがうまくいかなかった理由も教えてください。
Q2: 最終的にうまくいったアプローチについて、「なぜそれが効いたのか」を一言で言うとしたら？ 例: 根本原因が〜だったから〜が効いた、〜という前提を捨てたから解決した、など。
Q3: 今同じ状況に置かれたとしたら、何を最初に確認しますか？ あるいは「あのとき〜をしていれば防げた」という後悔はありますか？
回答が体験談の骨格になります。 「解決しました。以上です」で終わらず、失敗→学びの因果が見える記事になります。