Claude との対話で設計する IT 作業手順書の構造化プロンプトフォーマット

Markdown・XML・YAML・JSONなど複数の形式でシステムプロンプトを書く場合、混在は逆効果で単一形式の選択が推奨される。XMLはタグで境界が明示的で構造制御に優れ、Markdownは短くシンプルな場合に向く。セクション数や文字数を目安に形式を選定し、特に参照制御やインジェクション対策が必要な場合はXML構造化が有効。

スキルシート深掘りツールの後続開発で、面接練習（圧迫面接対応）、自己分析＆面談メモ、記事チェック提案の 3 モードを追加。実装過程で逆質問の準備が必要、作業スタイル自体が自己 PR 材料になること、スプレッドシート自動反映の落とし穴を実体験で学び、対話プロセス重視の設計へ改善した。

非開発者が Claude とチャットで半年かけて社内 Web ツールを構築する過程で、チャット終了時に AI が文脈を失う問題に直面。要約では漏れが生じ、詳細な資料は消費が膨らむジレンマを経験しながら、38 版の引き継ぎプロンプトへ進化させた。決定事項の明記、禁止項目の記載、教訓 52 件の蓄積など、試行錯誤から導き出した実装パターンを公開。

営業出身でコーディング未経験のフロントエンドエンジニアが、編集画面でのみ発生するバリデーションエラーをデバッグした事例。Gemini で仮説を整理し Claude でコード全体を検証するという 2 段階の AI 活用で、初期値の型（undefined vs null）に起因するバグを特定。AI を「思考を深める家庭教師」として使うデバッグ手法を言語化した。