非エンジニア向け Claude Code 要件定義自動化体系
プレゼンテーションスクリプト（発表原稿）
作成者: Manus AI
対象聴衆: 非エンジニア、AI初心者、個人事業主、業務自動化を検討する担当者
想定発表時間: 約25〜30分
スライド枚数: 12枚
オープニング（スライド1：タイトル）
【発表者の言葉】
みなさん、こんにちは。本日は「非エンジニアでも、Claude Codeを使って本格的なシステムを作れる体系」についてお話しします。
突然ですが、こんな経験はありませんか。「Substackの投稿を自動化したい」「noteの記事をAIに書いてもらいたい」「メルマガの配信を仕組み化したい」。そう思ってAIに相談したら、最初は動いたのに途中で壊れた。あるいは、何を頼めばいいかわからなくて、結局諦めてしまった。
今日お伝えするのは、そういった問題を根本から解決する方法です。AIに「やりたいこと」を伝えるだけで、要件定義書から仕様書、テスト計画、安全設計まで、プロが作るような開発仕様を自動で揃える体系です。
第1章：なぜ今、この体系が必要なのか（スライド2）
【発表者の言葉】
まず、なぜこの体系が必要なのかをお話しします。
Claude CodeやChatGPTのようなAIが登場したことで、「プログラミングを知らなくても、アイデアを伝えればシステムが作れる」という期待が高まっています。これは事実です。しかし、実際に試してみると、多くの方が壁にぶつかります。
その壁は、「AIが賢くない」ことではありません。問題は、最初の設計が整っていないまま実装に入ることです。
たとえば、「Substackを自動化して」とだけ伝えた場合、AIは何かを作ります。しかし、どこまで自動化するのか、失敗したときどうするのか、本番の読者に誤配信しないための仕組みはあるのか、Substackの規約に違反しないか、こういった問いに答えられないまま実装が進みます。
その結果、途中でバグが出る、修正するたびに別の問題が起きる、最終的に最初から作り直しになる。これが、非エンジニアがAI開発でつまずく典型的なパターンです。
解決策は、実装の前に「型」を揃えることです。
第2章：逆順アプローチとは何か（スライド3）
【発表者の言葉】
本体系の核心は、「逆順アプローチ」です。
通常の開発では、まずリサーチして、次に要件定義書を書いて、仕様書を作って、実装する、という順番です。しかしこの順番は、専門家を前提にしています。非エンジニアには、リサーチ結果を読んでも、どれを要件にすべきか、どれをリスクとして扱うべきか、判断できません。
そこで、本体系では順番を逆にします。
先に「世界最高基準の型」を用意します。 要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、詳細設計書、リスク台帳、ゲート判定ログ。これらのテンプレートを最初から揃えておきます。
次に、その型を埋めるためのリサーチを行います。 これをリサーチV2と呼びます。「Substackの認証方式はどうすべきか」「誤配信を防ぐためのテストはどう設計するか」「rollbackの手順は何か」。テンプレートの空欄を埋めるための問いを立て、AIがその答えを調査します。
型が先にあるから、調査の方向性が決まります。調査の方向性が決まるから、要件定義書が正確に埋まります。要件定義書が埋まるから、実装が安全に進みます。
これが逆順アプローチの本質です。
第3章：リサーチV1とリサーチV2の違い（スライド4）
【発表者の言葉】
少し詳しく説明します。本体系では、リサーチを2段階に分けます。
リサーチV1は、「そもそも作れるのか」を調べる段階です。
たとえばSubstack自動化であれば、Substackに公式APIがあるのか、投稿や配信はどこまで自動化できるのか、規約上問題がないのか、どんな技術が使えるのかを調べます。この段階で、実現可能性と方向性が決まります。
リサーチV2は、「テンプレートをどう埋めるか」を調べる段階です。
たとえば要件定義書の「認証方式」という項目があれば、「Substackの認証にはどの方式が適切か」を調べます。ハーネス設計の「rollback手順」という項目があれば、「投稿失敗時の復旧手順はどう設計するか」を調べます。
この分離が重要です。リサーチV1だけで終わると、「作れそうだ」という感触は得られますが、要件定義書は空白のままです。リサーチV2があるから、型が確実に埋まります。
非エンジニアの方は、「何を調べればいいかわからない」という問題を抱えています。本体系では、テンプレートの空欄がそのまま「調べるべき問い」になります。だから、調べる方向性を自分で考える必要がありません。
第4章：揃えるべき11の成果物（スライド5）
【発表者の言葉】
では、実際に何を揃えるのかをお話しします。本体系では、実装に入る前に11の成果物を揃えます。
まず、Intent Sheetです。「やりたいこと」を目的、対象者、成功条件、不明点へ分解します。最初の自然文を、開発可能な入口へ変えるものです。
次に、Research BriefとEvidence Matrixです。何を調べるかを定義し、公式資料、規約、API仕様、制約をID付きで管理します。これにより、思い込みで要件を書くことを防ぎます。
そして、要件定義書、仕様書、技術要件です。何を作るか、どう動くべきか、どの技術を使うかを合意します。
さらに重要なのが、ハーネス設計です。sandbox、dry-run、rollback、ログ、手動承認を設計します。これは「壊さずに試せる仕組み」です。
テスト計画では、単体テスト、統合テスト、E2Eテスト、受入テスト、回帰テスト、運用テストを定義します。「できました」を検証可能にします。
SDD（詳細設計書）は、Claude Codeが迷わず実装できる状態にするためのものです。
最後に、Risk RegisterとGate Decision Logです。リスクを見える化し、進行可否を赤黄緑で管理します。
この11点が揃って初めて、安全に実装を開始できます。
第5章：ユースケース別の複雑度（スライド6）
【発表者の言葉】
次に、ユースケースの分類についてお話しします。
「Substackを自動化したい」という要望でも、何をどこまで自動化するかによって、必要な設計の厚みが大きく変わります。
Level 1は、記事の下書き生成や記事案の作成です。品質リスクはありますが、本番環境への影響は限定的です。軽量な要件定義とテスト計画で対応できます。
Level 2は、実際の投稿自動化です。ここから、規約違反、認証情報漏洩、誤投稿のリスクが生じます。ハーネス設計とE2Eテストが必要になります。
Level 3は、Kindle、note、Substackを組み合わせた複数サービス連携です。データ不整合、重複投稿、権利管理の問題が加わります。
Level 4は、メルマガ配信、販売導線、文章生成を含む複合自動化です。誤配信、課金、個人情報、ブランド毀損のリスクがあります。SDD、監視設計、承認フローが必要です。
Level 5は、企業レベルのAI秘書です。情報漏洩、権限逸脱、監査不備のリスクがあり、セキュリティ要件、監査ログ、権限設計が必要です。
重要なのは、シンプルに見える要望でも、実際には危険操作を含む場合があるという点です。最初にレベルを正確に判定することが、後の設計全体を左右します。
第6章：Anthropicハーネス設計からの原則（スライド7）
【発表者の言葉】
本体系は、Anthropicの公式資料に基づいています。
Anthropicは、AIエージェントの評価において、評価ハーネスという考え方を提唱しています。これは、AIの最終発話を信用するのではなく、実際に環境上に残った結果、つまりデータベースの状態、投稿の有無、テストの合否、ログの内容を確認することが重要だという考え方です。
「できました」というAIの自己申告ではなく、実際に何が起きたかを外部から確認する。これが評価ハーネスの本質です。
また、Anthropicは長時間の開発タスクについて、次のことを推奨しています。初期化エージェントが環境と機能リストを準備する。コーディングエージェントが1機能ずつ実装する。各機能の完了後にクリーンな状態を残す。E2Eテストで実際の動作を確認する。
本体系は、これらの考え方を非エンジニア向けに落とし込んだものです。Claude Codeを単なるコード生成ツールではなく、進捗ログを残し、テストを実行し、破綻を検出しながら進むエージェントハーネスとして扱います。
第7章：Codex・Opus・人間の役割分担（スライド8）
【発表者の言葉】
本体系では、AIを一つの万能人格として扱いません。役割を分けることで、AIの過信と自己評価の甘さを防ぎます。
Codexは、実装・CI・破綻検出を担います。 コード、テスト、CI、差分、依存関係を見て、バグ、破壊的変更、テスト不足、復旧不能リスクを検出します。
Opusは、要件・運用・事業リスクを担います。 要件、仕様、レビュー結果、リスク台帳を見て、要件の採否、代替案、運用負荷、事業リスクを評価します。
人間は、目的・許容可否・最終合意を担います。 要約、赤黄緑の判定結果、再提案を見て、方向性、許容範囲、最終合意を決めます。
この分担により、非エンジニアは技術詳細の採点をする必要がなくなります。人間が判断するのは、「この目的でよいか」「このリスクを受け入れるか」「このYellow条件で進めるか」「この提案を採用するか」だけです。
専門判断はAIが担い、目的判断は人間が担う。これが本体系の役割分担の核心です。
第8章：RYGゲートと「100%完璧」の定義（スライド9）
【発表者の言葉】
本体系では、「100%完璧」を明確に定義します。
「完璧」とは、将来永遠にバグが発生しないという意味ではありません。それは現実的でも検証可能でもありません。
本体系での「100%完璧」とは、現時点で確認可能な要件、根拠、テスト、ハーネス、リスク、レビュー、ゲート条件がすべて接続され、未解決のRedがない状態です。
Greenは、根拠、要件、テスト、ハーネス、リスク、レビューが接続され、進行可能な状態です。
Yellowは、進行可能だが、期限、担当、解除条件が付いている状態です。条件付きで進め、期限内に再判定します。
Redは、重大な未解決リスク、規約違反、破壊的操作、テスト不能、根拠不足がある状態です。停止し、再リサーチまたは再提案へ戻します。
この定義により、非エンジニアでも「専門的に完璧か」を判断する必要はありません。判断すべきなのは、「完璧判定の条件を満たしているか」だけです。赤黄緑が見えれば、誰でも判断できます。
第9章：Substack自動化への適用例（スライド10）
【発表者の言葉】
具体例として、Substack自動化への適用をお話しします。
最初のユーザー入力は「Substackの自動システムを作りたい」で十分です。Claude Codeはまず、この要望をIntent Sheetへ分解します。
目的は「記事の企画、下書き作成、投稿準備、配信確認を効率化したい」。自動化する範囲は「企画生成、本文生成、校正、タイトル案、投稿前チェック、手動承認後の投稿」。自動化しない範囲は「無承認の本番投稿、課金設定変更、読者情報の無制限取得」。
次にリサーチV1で、Substackの公式仕様、利用可能な手段、規約、認証方式を調査します。
そしてリサーチV2で、テンプレートの各項目を埋めます。「認証方式はどうするか」「誤配信防止のテストはどう設計するか」「投稿失敗時のrollback手順は何か」。
この流れで、「Substackの自動システムを作りたい」という一文から、要件定義書、仕様書、技術要件、ハーネス設計、テスト計画、SDDが揃います。
第10章：全体工程の14ステップ（スライド11）
【発表者の言葉】
全体工程を整理します。14のステップで構成されています。
- 自然文でやりたいことを入力する。
- AIがIntent Sheetへ変換する。
- リサーチV1で実現可能性を確認する。
- テンプレートを選択する。
- リサーチV2でテンプレートを埋める。
- 要件定義書、仕様書、技術要件、SDDを作成する。
- ハーネス設計を行う。
- テスト計画を作成する。
- Codexレビューで実装・CI・テストを検証する。
- Opusレビューで要件・運用・事業リスクを評価する。
- RYGゲートで進行可否を判定する。
- Red/Yellowを再リサーチへ戻す。
- 再提案を作成し、採用・保留・却下を決める。
- Green条件が揃ったら合意し、実装を開始する。
このループは一度で終わりません。RedまたはYellowが残る限り、再リサーチと再提案へ戻ります。Greenが連続して達成され、未解決Redがなくなったとき、初めて合意可能になります。
クロージング（スライド12）
【発表者の言葉】
最後にまとめます。
本体系が目指すのは、非エンジニアが「Substackを自動化したい」と一言伝えるだけで、世界最高基準の開発仕様が揃う状態です。
そのために必要なのは、3つのことです。
第一に、逆順アプローチ。 型を先に用意し、型を埋めるためにリサーチV2を行う。
第二に、役割分担。 Codexが実装を見て、Opusが要件を見て、人間が目的を判断する。
第三に、RYGゲート。 赤黄緑で進行可否を管理し、Greenが揃ったら合意する。
この3つが揃えば、非エンジニアでも、AI初心者でも、「作りたいもの」を「作れるもの」へ変換できます。
本日はご清聴ありがとうございました。ご質問があればお受けします。
質疑応答の想定問答
Q1: 「型」を用意するのも難しくないですか？
A: 型は事前に準備されています。ユースケースのレベルを選ぶと、必要なテンプレートが自動的に選択されます。テンプレートは空欄になっており、AIがリサーチV2でその空欄を埋めます。利用者は、埋まった内容を確認して赤黄緑を判断するだけです。
Q2: Substackに公式APIがない場合はどうなりますか？
A: リサーチV1の段階で、公式APIの有無と代替手段が調査されます。公式APIがない場合は、代替案（非公式操作のリスク、手動操作との組み合わせ、別サービスへの変更など）が提案され、リスクと共に評価されます。
Q3: 「100%完璧」になるまでどれくらいかかりますか？
A: ユースケースの複雑度によります。Level 1の単純な下書き生成であれば、数日から1週間程度で揃います。Level 4の複合自動化であれば、数週間かかる場合があります。ただし、最初から全機能を対象にするのではなく、最小機能から始めることを推奨しています。
Q4: 非エンジニアが赤黄緑を判断できますか？
A: はい。赤黄緑の判定はAIが行い、その理由と解除条件も提示されます。利用者は「この条件で進めるか」「このリスクを受け入れるか」を判断するだけです。専門的な技術判断は不要です。
参考資料
本スクリプトは以下の資料を参照しています。