Kindle_AI_Driven_Dev_Book_Plan

Kindle本 企画書 新人のためのAI駆動開発入門 失敗しない「型」を、8章で身につける 査読済み論文 ＋ Claude公式ドキュメントを根拠に設計（仮題） うさうさ研修工房

Concept 本のコンセプト：Why / What / How Why なぜこの本か What どんな本か How どう作るか AI支援の利用者は、不安全なコードを 書きやすく、安全だと思い込みやすい 傾向が報告されています（Perry et al., 2023）。本書は、確認の「型」を 身につけることを提案します。 AIと開発する時の8つの型を、1章1テ ーマで学ぶ。各章に演習とチェックリ スト付き。山場は第7章のハンズオン 1つだけ。 論文10本＋Claude公式ドキュメント で根拠を固め、引用は限界つきで紹介 。図解は各章に最低1つ。 約束：断定しない。研究は「示唆」として、当時のモデル・ツールの結果は「現在は変わりうる」と添える。

Reader 読者像と、読了後の変化 想定読者 この本が扱わないこと ・プログラミングの基本文法はわかる ・特定ツールの細かい操作手順（変わりやすいため） ・文系出身、または転職直後のエンジニア ・AIで開発したいが、何に気をつけるか不安 ・高度なアーキテクチャ設計 読む前 読んだ後 AIに「作って」と丸投げする 目的・制約・完了条件を書いて依頼できる 動いたら大丈夫と思う 読む・実在確認・実行の3つで確認できる 長い会話を続けてしまう 小さく区切り、文脈を絞れる 失敗を隠したくなる マイルールで、仕組みとして再発を防げる

Design 設計思想：坂道を8章で登る（山場は1つ） 足場かけ（Wood, Bruner & Ross, 1976）の考え方を応用：段階的に難しく。原研究は幼児の課題で、成人学習への適用は類推です 。 第7章 第6章 第5章 第4章 第3章 第8章 第2章 第1章 AI開発とは 基本の流れ 依頼の書き方 出力を疑う 小さく進む テストで守る 山場の直前で予告、直後（第8章）で必ず一息つく。読者が最後まで読み切れる設計にします。 ハンズオン マイルール

Structure 章構成一覧 章 テーマ 読者が得るもの はじめに この本の約束 読み方と全体像 第1章 AI駆動開発とは：あなたが責任者 AIとの役割分担 第2章 基本の流れ：探索→計画→実装→検証 作業の型 第3章 良い依頼の書き方 目的・制約・完了条件 第4章 出力を疑う 読める・実在する・動く 第5章 小さく進む・文脈を絞る 分割と文脈管理 第6章 テストで守る 検証手段の与え方 第7章 ★ ハンズオン：失敗を探せ レビュー力（山場） 第8章 マイルールを作る 自分用の運用ルール おわりに・付録 次の一歩、失敗事例（筆者記入）、チェックリスト 持ち帰り資料

Evidence 根拠マップ：章 × 論文 × Claude公式 章 論文 Claude公式ドキュメント（要点） 1 Perry 2023／Parasuraman & Manzey 2010 検証できないものは出荷しない 2 Wood et al. 1976 探索→計画→実装の順（plan mode） 3 Perry 2023 具体的な文脈を与える 4 Ji 2023／Pearce 2022 「もっともらしい実装」が端のケースを外す 5 Sweller 1988／Liu 2024 文脈ウィンドウは最重要の資源 6 Parasuraman & Manzey 2010 合否が出る検証手段を与える 7 Kapur 2008／Pearce 2022 ― 8 Gollwitzer 1999 CLAUDE.mdは短く保つ 公式の記述は「推奨される使い方」、論文は「研究で示された傾向」として書き分けます。

Official docs Claude公式から取り入れる5つの原則 1 検証手段を与える 2 探索→計画→実装 3 具体的な文脈 テスト・ビルド・画面比較など、合否 が出る確認を用意する。 いきなり書かせず、先に調べて計画す る。 対象ファイル・制約・参考例を指定し て依頼する。 4 CLAUDE.mdは短く 5 文脈は有限の資源 長すぎると重要な指示が埋もれて無視される。定期的に見 直す。 会話が長くなると性能が下がる。区切って進める。 出典：Best practices for Claude Code（code.claude.com/docs/en/best-practices、確認日 2026-10-03）。書籍にはコマンドより原則を中心 に書きます。

Reading research 研究の読み方：何が言えて、何が言えないか 研究 わかったこと 注意（限界） Perry et al. (2023) ACM CCS AI利用群は5課題中4課題で、より不安全なコードを書き 、安全だと思い込みやすかった 実験室の利用者研究。当時のモデル。現在は 変わりうる Pearce et al. (2022) IEEE S&P 89シナリオ・1,689プログラムの約40%が脆弱 2021年8月時点のCopilot。脆弱＝即悪用可能 ではない Liu et al. (2024) TACL 重要情報が入力の途中だと精度が下がる 2023年当時のモデル。最新は要確認 Ji et al. (2023) ACM Comput. Surv. 生成モデルの幻覚を体系的に整理 自然言語生成全般。コードへの当てはめは本 書の応用 Kapur (2008) Cogn. & Instruction 先に自力で挑戦すると理解が深まる傾向 数学・理科中心。失敗後の解説が前提 本文では、引用のたびに「わかったこと」と「限界」を併記します。

Chapter template 1章の型：読者が迷わない7つの部品 問い Why What How 演習 チェック まとめ 各部品のねらい 章ごとのルール 問い：読者の不安を1文で ・1節1メッセージ Why：根拠は1〜2件、限界つき What：用語はたとえ話つき ・1章に図解を最低1つ ・章末チェックは3〜5項目 How：Before/Afterの例 演習：手を動かす1〜2問 ・まとめは3行以内 ・文字数は章ごとに揃える（目安3,000〜5,000字）

Visual design 図解計画：各章に最低1つ 章 図解 種類 1 AIと人の役割分担 2列の表 2 探索→計画→実装→検証のループ フロー図 3 Before/Afterの依頼文 比較表 4 3つの確認（読める・実在する・動く） 3カード 5 小さく区切る／文脈の使い方 段階図 6 テスト→合否→修正のループ フロー図 7 問題コードと答え合わせ コード＋表 8 「もし〜なら」ルールシート 記入表 図は短い説明と組み合わせ、配色は3色以内（Mayer & Moreno, 2003の応用）。

Reader bonus 読者特典の設計（案） 無料特典（案） 発展版（案） ・章末チェックリスト一覧（1枚） ・演習の解答例と解説 ・「もし〜なら」マイルールシート ・ワークブック形式のPDF Kindle本の末尾で案内し、読了後の行動を後押しします。 ※内容と提供方法は筆者が決定します。 未確定事項：特典の中身・配布先・価格。決まり次第、本文末の案内文を作成します。

Quality 品質管理：引用チェックのフロー 引用候補 書誌を検索 要旨を確認 限界を併記 断定を修正 引用ルール 誠実さのルール 1. 記憶だけで書かない。検索で書誌を確認 1. 筆者の体験談は筆者が書いた内容のみ 2. 確認できなければ使わない 3. 数値は原典で確認できたものだけ 2. 未提供の箇所は「（筆者記入）」の枠 3. 実在しないツール名・コマンドは書かない 4. 当時のモデルの結果は注意書きつき 4. 公式ドキュメントは確認日つき

Schedule 制作スケジュール：4週間のToDo（案） Week1 企画確定 Week2 前半執筆 Week3 後半執筆 Week4 仕上げ ・書名・読者・読了後の変 化を確定 ・はじめに〜第4章 ・第5〜8章（山場の第7章 ） ・品質チェックリスト全項 目 ・付録・失敗事例（筆者記 入） ・体裁確認（目次・画像） ・KDP公式ヘルプで要件確 認 ・章構成の確定 ・根拠マップ確認 ・各章に図解1つ ・引用チェック ・引用チェック

Skill 制作を支えるSkill：writing-kindle-ai-dev-books writing-kindle-ai-dev-books/ ├─ SKILL.md （77行） ├─ references/ │ ├─ chapter-template.md │ ├─ citation-bank.md │ ├─ style-guide.md │ ├─ kindle-production.md │ ├─ output-checklist.md │ └─ evals.md └─ scripts/ └─ check_skill.py Claude公式の推奨に沿った設計 1. nameは小文字・ハイフン、64文字以内、予約語なし 2. descriptionに「何をするか」「いつ使うか」を三人称で記 載 3. SKILL.md本文は500行未満 4. 参照はSKILL.mdから1階層 5. 評価シナリオ3件を同梱 6. 構造検査スクリプトで確認 ※Haiku・Sonnet・Opusでの実地テストは未実施

References 参考文献・公式資料 1. Perry, N. et al. (2023). Do Users Write More Insecure Code with AI Assistants? ACM CCS '23, 2785–2799. doi:10.1145/3576915.3623157 2. Pearce, H. et al. (2022). Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions. IEEE S&P 2022（Commun. ACM 68(2), 96–105, 2025） 3. Liu, N. F. et al. (2024). Lost in the Middle. TACL, 12, 157–173. doi:10.1162/tacl_a_00638 4. Ji, Z. et al. (2023). Survey of Hallucination in Natural Language Generation. ACM Computing Surveys, 55(12), Article 248. 5. Parasuraman, R., Manzey, D. H. (2010). Complacency and Bias in Human Use of Automation. Human Factors, 52(3), 381–410. 6. Sweller, J. (1988). Cognitive Load During Problem Solving. Cognitive Science, 12(2), 257–285. 7. Wood, D., Bruner, J. S., Ross, G. (1976). The Role of Tutoring in Problem Solving. J. Child Psychol. Psychiatry, 17(2), 89–100. 8. Kapur, M. (2008). Productive Failure. Cognition and Instruction, 26(3), 379–424. 9. Gollwitzer, P. M. (1999). Implementation Intentions. American Psychologist, 54(7), 493–503. 10. Mayer, R. E., Moreno, R. (2003). Nine Ways to Reduce Cognitive Load in Multimedia Learning. Educational Psychologist, 38(1), 43–52. 11. 公式：Best practices for Claude Code. code.claude.com/docs/en/best-practices（確認日 2026-10-03） 12. 公式：Skill authoring best practices. platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices（確認日 2026-10-03） 論文10件は書誌を検索で確認済み。IEEE S&P版のページ番号のみ未確認。