仮想テスト：素人がSubstack自動化を作る3シナリオ
前提設定
ユーザー像：田中さん（45歳、会社員、プログラミング経験ゼロ） 目標：Substack記事を毎週月曜日に自動投稿するシステムを作りたい 使用ツール：Claude Code（claude -p）
シナリオA：現体系を正しく使った場合（理想ケース）
ステップ1：要件定義書の作成
田中さんは world_class_requirements_template.md を開き、Claude Codeに指示する：
このテンプレートを使って、Substack自動投稿システムの要件定義書を作ってください。
私がやりたいこと：毎週月曜日の朝7時に、事前に書いておいた記事を自動でSubstackに投稿する。
Claude Codeの応答：要件定義書を生成し、以下の質問を返す： - 「記事はどこに保存しますか？（Google Drive、ローカルファイル、Notion等）」 - 「Substackの認証情報はどのように管理しますか？」 - 「投稿失敗時の通知方法は？」
田中さんが回答し、完全な要件定義書が完成する。
ステップ2：CLAUDE.md + CONSTRAINTS.md + progress.mdの作成
この要件定義書を元に、CLAUDE.md、CONSTRAINTS.md、progress.mdを作成してください。
生成されるCLAUDE.md（適切な例）：
# Substack自動投稿システム
## プロジェクト概要
毎週月曜朝7時にSubstackへ自動投稿するPythonスクリプト
## 技術スタック
- Python 3.11
- substack-api ライブラリ
- Google Drive API（記事保存先）
- cron（スケジューリング）
## 必須環境変数
- SUBSTACK_EMAIL: Substackログインメール
- SUBSTACK_PASSWORD: Substackパスワード
- GOOGLE_DRIVE_FOLDER_ID: 記事フォルダID
## テスト方法
python test_post.py --dry-run（実際には投稿しない）
## 完了基準
- dry-runで記事取得・フォーマット確認OK
- 本番投稿1回成功
- cronジョブ登録・動作確認OK
生成されるCONSTRAINTS.md（適切な例）：
# 禁止事項リスト
## 絶対禁止
- 本番Substackアカウントへのテスト投稿（dry-runのみ使用）
- .envファイルのgitコミット
- 認証情報のハードコード
- 既存投稿の削除・編集
## スコープ外（今回は実装しない）
- 複数アカウント対応
- 画像の自動挿入
- SEO最適化
- 分析・レポート機能
ステップ3：E2Eシナリオの事前作成
実装前に、E2Eテストシナリオを作成してください。
生成されるE2Eシナリオ（適切な例）：
正常系：
- 月曜朝7時にcronが起動する
- Google Driveから今週の記事ファイルを取得する
- 記事をSubstackフォーマットに変換する
- Substackに投稿する
- Slackに成功通知を送る
異常系：
- Google Driveに記事がない場合→Slackにエラー通知
- Substack認証失敗→Slackにエラー通知、投稿をスキップ
- 記事フォーマット不正→Slackにエラー通知、投稿をスキップ
ステップ4：Explore→Plan→Implement→Commitの4フェーズ実行
planモードで、まず既存のコードベースを調査してください。
（新規プロジェクトなので）技術スタックと依存関係を調査してください。
ステップ5：RYGゲートによる完了判定
- 全E2Eシナリオがパス → Green
- dry-run成功 → Green
- 本番投稿1回成功 → Green → 完了！
シナリオAの結論
成功確率：85% - 要件定義書・CLAUDE.md・CONSTRAINTS.md・E2Eシナリオが揃っているため、Claudeが迷わない - 残り15%の失敗リスク：Substack APIの仕様変更、Google Drive認証の複雑さ
シナリオB：CLAUDE.mdを作らずに進めた場合（コンテキスト枯渇ケース）
ステップ1：直接実装指示
田中さんはCLAUDE.mdを作らず、直接指示する：
Substackに毎週月曜日に自動投稿するPythonスクリプトを作ってください。
問題の発生（会話20回目あたり）
Claudeの挙動の変化： - 最初：「Substack APIを使って投稿スクリプトを作ります」 - 10回目：「先ほどの実装を修正します」（前の決定を覚えている） - 20回目：「新しいアプローチで実装します」（前の決定を忘れ始める） - 30回目：「このファイルの目的は何でしたか？」（完全に迷子）
具体的な破壊パターン：
田中さん：「エラーが出ました。修正してください」
Claude：「認証方式をOAuthに変更します」
（←最初にBasic認証で設計していたことを忘れている）
田中さん：「動きました！次は通知機能を追加してください」
Claude：「Slackに通知を追加します」
（←最初にメール通知で設計していたことを忘れている）
田中さん：「なんか前と違う動きをしています」
Claude：「申し訳ありません。コードを見直します」
（←何が正しい状態かわからない）
コンテキスト枯渇の症状
- 矛盾した実装：最初の設計と異なるコードが生成される
- 重複実装：同じ機能を別の方法で2回実装する
- 削除忘れ：不要になったコードが残り続ける
- 完了誤認：「完成しました」と言うが実際には動かない
田中さんが気づかない理由
- コードを読めないので「Claudeが言うなら完成したんだろう」と思う
- エラーが出ても「また修正してもらえばいい」と思う
- 気づいたときには30回以上の会話が積み重なっており、最初の設計が何だったか誰もわからない
シナリオBの結論
成功確率：20% - コンテキスト枯渇により、30〜50回の会話で必ず迷子になる - 「完成した」と思っても実際には動かないコードが生成されている可能性が高い - 現体系でのリスク評価：HIGH
シナリオC：E2Eシナリオなしで実装した場合（完了誤認ケース）
ステップ1：CLAUDE.mdは作ったが、E2Eシナリオは作らなかった
田中さんはCLAUDE.mdとCONSTRAINTS.mdは作ったが、E2Eシナリオを作らずに実装を進めた。
問題の発生（実装完了後）
Claudeの「完了」宣言：
実装が完了しました。
- post_to_substack.py: 投稿スクリプト
- cron_setup.sh: cronジョブ設定
- test_post.py: テストスクリプト
テストを実行してください：
python test_post.py
田中さんのテスト実行：
$ python test_post.py
テスト成功：記事を取得しました
テスト成功：Substackに接続しました
テスト成功：投稿フォーマットを確認しました
All tests passed!
田中さんの判断：「テストが全部通った！完成だ！」
翌週月曜日の現実
月曜日朝7時：cronが起動しない
（理由：cronジョブの設定がサーバー再起動後に消えていた）
田中さん：「なぜ動かないんですか？」
Claude：「cronジョブが消えています。再設定します」
再設定後の翌週月曜日：cronが起動するが投稿されない
（理由：Google Drive APIの認証トークンが1週間で失効していた）
田中さん：「また動かない！」
Claude：「認証トークンを更新します」
さらに翌週：投稿されるが文字化けしている
（理由：日本語エンコーディングの処理が抜けていた）
E2Eシナリオがなかった場合に見落とされる項目
| カテゴリ | 見落とし項目 | 影響 |
|---|---|---|
| 永続性 | cronジョブのサーバー再起動後の維持 | 毎回手動設定が必要 |
| 認証 | OAuthトークンの有効期限と自動更新 | 週1回手動更新が必要 |
| 文字コード | 日本語エンコーディング処理 | 文字化けで読めない記事が投稿される |
| エラー通知 | 失敗時の通知手段 | 失敗に気づかない |
| 冪等性 | 同じ記事の重複投稿防止 | 同じ記事が複数回投稿される |
| タイムゾーン | JST/UTC変換 | 月曜7時ではなく別の時間に投稿される |
シナリオCの結論
成功確率：40% - 単体テストは通るが、統合テスト・境界ケース・エラーケースが未検証 - 「完成した」と思ってから実際の問題が次々と発生する - 非エンジニアは「テストが通った＝完成」と誤認しやすい - 現体系でのリスク評価：MEDIUM-HIGH（E2Eシナリオテンプレートはあるが、素人が使い方を理解できるか不明）
3シナリオの比較まとめ
| 項目 | シナリオA（理想） | シナリオB（CLAUDE.mdなし） | シナリオC（E2Eなし） |
|---|---|---|---|
| 成功確率 | 85% | 20% | 40% |
| 主なリスク | API仕様変更 | コンテキスト枯渇・迷子 | 完了誤認・本番障害 |
| 発見タイミング | 開発中に修正 | 開発中に気づかず | 本番稼働後に発覚 |
| 修正コスト | 低 | 高（最初からやり直し） | 中（個別修正） |
| 非エンジニアへの影響 | 管理可能 | 絶望的（何が起きているかわからない） | 困惑（なぜ動かないかわからない） |
仮想テストから得られた重要な発見
発見1：CLAUDE.mdの「作り方」が最大のボトルネック
現体系はCLAUDE.mdの「必要性」は説明しているが、「具体的な書き方」が不明確。 素人が「何を書けばいいか」を理解できるテンプレートが必要。
発見2：E2Eシナリオの「境界ケース」が見落とされやすい
正常系は思いつくが、「サーバー再起動後」「トークン失効後」「日本語文字化け」などの 境界ケース・異常ケースを素人は思いつかない。 「このシステムで必ず確認すべき境界ケースリスト」が必要。
発見3：「完了」の定義が曖昧
「テストが通った」≠「完成」であることを素人は理解できない。 RYGゲートの「Green」の定義に「本番環境での動作確認」を明示的に含める必要がある。
発見4：本番移行チェックリストが存在しない
プロトタイプ→本番への移行で必要な項目（認証・セキュリティ・信頼性・監視）の 具体的なチェックリストが現体系にない。
発見5：Explore→Plan→Implement→Commitの4フェーズが明示されていない
Claude Code公式推奨の4フェーズワークフローが現体系に組み込まれていない。 特に「Explore（探索）フェーズ」の欠如が、設計ミスの原因になる。