Prometheus プランニング：インタビュー形式の要件収集と作業計画の生成

このレッスンが終わるとできること

Prometheus プランニングセッションを開始し、インタビューモードでプロジェクト要件を明確化する
Prometheus の「プランニングのみ、実装なし」という核心原則を理解する
Metis と Momus を連携させて、高品質で抜けのない作業計画を生成する
/start-work コマンドを使用して、計画を Atlas に引き継ぎ実行する

あなたが直面している課題

想像してください。AI に複雑なタスクを依頼します：「認証システムのリファクタリングを手伝って」。

5 分後、AI はコードの記述を始めました。あなたは時間を節約できたと喜んでいます。

30 分後、あなたは気づきます：

AI はどの認証ライブラリを使用するか尋ねなかった（JWT？NextAuth？Session？）
AI は多くの要件を仮定した（例：「OAuth をサポートする必要がある」→ 実際には不要）
コードは半分書かれた状態で、方向性が間違っていたため、やり直しが必要
テスト時に、コアロジックが既存システムと互換性がないことが判明

これは典型的な「プランニングと実行の混在」問題です：AI は要件が明確でないまま作業を始め、大量のやり直しを招きます。

Prometheus を使うべきタイミング

使用タイミング

Prometheus に適したシナリオ：

複雑な機能開発（例：「ユーザー認証システムの追加」）
大規模なリファクタリング（例：「データアクセス層全体のリファクタリング」）
アーキテクチャ設計（例：「マイクロサービスアーキテクチャの設計」）
厳格な品質保証が必要なタスク

Sisyphus に直接実行させるシナリオ：

単純なバグ修正（例：「ログインボタンのスペルミスを修正」）
明確な小さな機能（例：「3 つの入力欄を持つフォームを追加」）

🎒 開始前の準備

以下の設定が完了していることを確認してください：

[ ] Prometheus エージェントが有効になっている（デフォルトで有効）
[ ] 少なくとも 1 つの AI Provider が設定されている（Anthropic、OpenAI など）
[ ] 基本的なエージェント概念を理解している（「AI エージェントチーム：10 人の専門家紹介」を完了）

Prometheus の可用性を確認：

bash

# OpenCode のチャットボックスに入力
@prometheus

# Prometheus のプロンプトが表示されるはず：
# "こんにちは、Prometheus - 戦略プランニングアドバイザーです。..."

核心アイデア

Prometheus の核心アイデンティティ制約

Prometheus の最も重要な特徴は何でしょうか？コードを絶対に書きません。

機能	Prometheus	Sisyphus	Atlas
要件収集	✅	❌	❌
作業計画の生成	✅	❌	❌
コード実装	❌	✅	✅（委託）
タスク実行	❌	✅	✅（委託）

なぜこれが重要なのでしょうか？

プランニング担当 ≠ 実行担当：プロダクトマネージャーがコードを書かないように、Prometheus の役割は「どうやるか」であって「やる」ことではない
仮定を防ぐ：Prometheus が直接コードを書けると、要件が明確でないまま「推測して作る」ことができる
思考を強制する：コードを書くことが禁止されると、Prometheus はすべての詳細を確認する必要がある

3 段階ワークフロー

mermaid

flowchart LR
    A[ユーザーが要件を入力] --> B[フェーズ 1: インタビューモード]
    B -->|要件は明確？| C[フェーズ 2: 計画生成]
    C --> D[Metis コンサルティング]
    D -->|高精度が必要？| E[Momus 検証ループ]
    E -->|計画が完成| F[.sisyphus/plans/*.md を生成]
    C -->|高精度不要| F
    F --> G[/start-work 実行]

各段階の責任：

フェーズ 1 - インタビューモード：要件の収集、コードベースの調査、ドラフトの継続的更新
フェーズ 2 - 計画生成：Metis へのコンサルティング、完全な計画の生成、サマリーの提示
フェーズ 3 - 実行：/start-work により Atlas に引き継ぎ実行

実践編

ステップ 1：Prometheus プランニングセッションの開始

理由キーワードまたはコマンドで Prometheus をトリガーし、インタビューモードに入ります。

操作

OpenCode のチャットボックスに入力：

@prometheus ユーザー認証システムのプランニングを手伝って

表示されるはず：

Prometheus がインタビューモードへの入場を確認
最初の質問（例：「あなたのアプリケーションはどのような技術スタックですか？」）
ドラフトファイル .sisyphus/drafts/user-auth.md の作成

重要な機能：ドラフトファイル

Prometheus は 継続的に .sisyphus/drafts/ 配下のファイルを更新します。これは彼の「外部メモリ」です：

毎回のディスカッションでの決定事項を記録
発見したコードパターンを保存
明確な境界をマーク（IN/OUT）

いつでもドラフトを確認し、Prometheus の理解が正しいか検証できます。

ステップ 2：質問に答えて、Prometheus にコンテキストを収集させる

理由 Prometheus は実行可能な計画を生成するためにプロジェクトを「理解」する必要があります。推測するのではなく、コードベースの調査とベストプラクティスの研究を通じて根拠を得ます。

操作

Prometheus の質問に答えてください。例：

ユーザー入力：
私のアプリケーションは Next.js 14、App Router で、現在認証はありません。
メールパスワードログインと GitHub OAuth をサポートしたいです。

Prometheus が行うこと：

explore エージェントを使用して既存のコード構造を分析
librarian エージェントを使用して認証のベストプラクティスを検索
ドラフトファイルの「Requirements」と「Technical Decisions」セクションを更新

表示されるはず：

探索エージェントを起動してプロジェクト構造を分析しています...

1. explore: 既存のセッションパターンを検索
2. librarian: NextAuth のベストプラクティスを検索

結果が返ってきたら、質問を続けます。

ステップ 3：ドラフトファイルを確認する（オプション）

理由ドラフトは Prometheus の「外部メモリ」であり、いつでも彼の理解が正しいか検証できます。

操作

bash

# ターミナルでドラフトの内容を表示
cat .sisyphus/drafts/user-auth.md

表示されるはず（類似の内容）：

markdown

# Draft: user-auth

## Requirements (confirmed)
- 技術スタック: Next.js 14, App Router
- 認証方式: メールパスワード + GitHub OAuth
- 現在の状態: 認証実装なし

## Technical Decisions
- 決定なし

## Research Findings
- 探索エージェント実行中...

ステップ 4：要件が明確になるまで回答を続ける

理由 Prometheus は「Clearance Checklist」を持ち、すべてにチェックが入るまで自動的に計画生成に移行しません。

Prometheus の判断基準：

CLEARANCE CHECKLIST (すべて YES で自動遷移):
□ コア目標は明確か？
□ スコープの境界は明確か（IN/OUT）？
□ 未解決の重要な曖昧さはないか？
□ 技術アプローチは確定しているか？
□ テスト戦略は確認されているか（TDD/手動）？
□ ブロッキング問題はないか？

操作

Prometheus の質問に答え続け、以下が表示されるまで：

すべての要件が明確になりました。Metis に相談し、計画を生成しています...

表示されるはず：

Prometheus が Metis エージェントを呼び出す
Metis が見落としがちな問題を分析
Prometheus が Metis のフィードバックに基づいて理解を調整

ステップ 5：生成された計画を確認する

理由計画ファイルは Prometheus の最終出力であり、すべてのタスク、依存関係、受け入れ基準を含みます。

操作

bash

# 生成された計画を確認
cat .sisyphus/plans/user-auth.md

表示されるはず（完全な構造）：

markdown

# User Authentication System

## Context
[元の要件記述]
[インタビューの要約]
[Metis 分析結果]

## Work Objectives
- コア目標：メールパスワードログインと GitHub OAuth の実装
- 具体的な成果物：ログインページ、API エンドポイント、セッション管理
- 完成の定義：ユーザーがログインし、保護されたルートにアクセスできる

## Verification Strategy
- インフラストラクチャ存在：YES
- ユーザーがテストを希望：TDD
- フレームワーク：vitest

## TODOs
- [ ] 1. NextAuth.js をインストールして設定
  - References:
    - https://next-auth.js.org/getting-started/installation
  - Acceptance Criteria:
    - [ ] npm run test → PASS (1 test)

- [ ] 2. API ルート [...nextauth]/route.ts を作成
  - References:
    - src/lib/session.ts:10-45 - 既存のセッションパターン
  - Acceptance Criteria:
    - [ ] curl http://localhost:3000/api/auth/... → 200

- [ ] 3. ログインページの UI を実装
  - References:
    - src/app/login/page.tsx - 既存のログインページ構造
  - Acceptance Criteria:
    - [ ] Playwright 検証：ログインフォームが表示される
    - [ ] スクリーンショットを .sisyphus/evidence/ に保存

...

ステップ 6：実行方法を選択する

理由 Prometheus は 2 つの選択肢を提示します：迅速な開始か、高精度のレビューか。

Prometheus の表示（Question ツールを使用）：

## Plan Generated: user-auth

**Key Decisions Made:**
- NextAuth.js を使用（Next.js App Router との統合が良好）
- GitHub OAuth プロバイダー + メールパスワード

**Scope:**
- IN: ログイン機能、セッション管理、ルート保護
- OUT: 登録機能、パスワードリセット、ユーザープロフィール編集

**Guardrails Applied:**
- 既存のセッションパターンに従う必要がある
- コアビジネスロジックは変更しない

Plan saved to: `.sisyphus/plans/user-auth.md`

---

**Next Step**

どのように進めますか？

1. **Start Work**: /start-work を実行します。計画は堅実に見えます。
2. **High Accuracy Review**: Momus に各詳細を厳密に検証させます。レビューサイクルは増えますが、精度は保証されます。

操作

選択肢を選びます（OpenCode でボタンをクリックするか、オプションを入力）。

「Start Work」を選んだ場合：

Prometheus がドラフトファイルを削除
/start-work の実行を促す

「High Accuracy Review」を選んだ場合：

Prometheus が Momus ループに入る
Momus が「OKAY」と言うまでフィードバックを継続的に修正
その後、/start-work の実行を促す

ステップ 7：計画を実行する

理由計画は Prometheus の出力であり、実行は Atlas の責任です。

操作

bash

# OpenCode で入力
/start-work

表示されるはず：

Atlas が .sisyphus/plans/user-auth.md を読み込む
boulder.json ステータスファイルを作成
各 TODO を順番に実行
専門エージェントにタスクを委任（例：UI 作業は Frontend に委任）

チェックポイント ✅

boulder.json ファイルが作成された
Atlas がタスク 1 の実行を開始
各タスク完了後、ステータスが更新される

落とし穴の注意

落とし穴 1：要件を半分言って急いで計画を求める

問題：

ユーザー：@prometheus ユーザー認証を作って
ユーザー：質問は後回しで、まず計画を生成して

結果：計画には仮定が満載で、実行時に何度も修正が必要になる。

正しいやり方：

ユーザー：@prometheus ユーザー認証を作って
Prometheus：あなたのアプリケーションはどの技術スタックですか？現在認証はありますか？
ユーザー：Next.js 14、App Router で、認証はありません
Prometheus：どのログイン方式をサポートする必要がありますか？
ユーザー：メールパスワード + GitHub OAuth
...
（Prometheus が自動的に遷移するまで回答を続ける）

この原則を覚えておいて

プランニング時間 ≠ 時間の無駄

5 分かけて要件を明確にすると、2 時間のやり直しを節約できる
Prometheus のインタビューモードは、未来のあなたのために「節約」しているのです

落とし穴 2：ドラフトファイルを確認しない

問題：Prometheus はドラフトに多くの決定事項と境界を記録しているが、それを見ずに計画生成を促す。

結果：

計画に誤った理解が含まれる
実行時に「なんでこれを言われた覚えがない？」となる

正しいやり方：

1. プランニング開始後、常に .sisyphus/drafts/ ファイルに注目する
2. 誤解を発見したらすぐに訂正：「違います、OAuth じゃなくて単純な JWT が欲しいんです」
3. 訂正後に続行する

落とし穴 3：計画を複数回に分けて生成する

問題：

ユーザー：このプロジェクトは大きすぎるので、まず第 1 フェーズだけ計画しましょう

結果：

第 1 フェーズと第 2 フェーズのコンテキストが途切れる
アーキテクチャの決定に一貫性がない
複数のセッションで要件が失われる

正しいやり方：

✅ 単一計画原則：どれだけ大きくても、すべての TODO は 1 つの .sisyphus/plans/{name}.md ファイルに含める

なぜ？

Prometheus も Atlas も大きな計画を処理できる
単一計画でアーキテクチャの一貫性が保証される
コンテキストの断片化を防ぐ

落とし穴 4：Metis の役割を忘れる

問題：

ユーザー：要件を話したので、早く計画を生成して
Prometheus：（Metis をスキップして直接生成）

結果：

計画に重要な境界が欠落している可能性がある
「絶対に必要ないもの」が明確に除外されていない
実行時に AI slop（過度な設計）が発生

正しいやり方：

✅ Metis コンサルティングは強制的で、急ぐ必要はありません

Metis は何をする？

Prometheus が尋ねるべきだったが尋ねなかった問題を特定
明確にする必要がある境界を提案
AI の過度なエンジニアリングを防ぐ

落とし穴 5：テスト戦略の決定を無視する

問題：Prometheus が「テストは必要ですか？」と尋ね、あなたは「どちらでも」またはスキップと答える。

結果：

テストインフラが存在するのに TDD を活用しなかった機会損失
テストがない場合、詳細な手動検証手順がなく、実行失敗率が高い

正しいやり方：

Prometheus：vitest テストフレームワークを検出しました。作業にテストを含めますか？
ユーザー：YES（TDD）

影響：

Prometheus は各タスクを RED → GREEN → REFACTOR の構造にします
TODO の Acceptance Criteria にはテストコマンドが明確に含まれます
Atlas 実行時に TDD フローで作業します

レッスンサマリー

Prometheus の核心価値：

プランニングと実行の分離：「コードを書かない」という強制制約により、要件を明確にする
インタビューモード：継続的な質問、コードベースの調査、ドラフトの更新
品質保証：Metis コンサルティング、Momus 検証、単一計画原則

典型的なワークフロー：

@prometheus [要件] を入力してプランニングを開始
質問に答え、.sisyphus/drafts/ ドラフトを確認
Prometheus が自動的に遷移するのを待つ（Clearance Checklist がすべてチェック）
生成された .sisyphus/plans/{name}.md を確認
「Start Work」または「High Accuracy Review」を選択
/start-work を実行して Atlas に引き継ぎ

ベストプラクティス：

計画を急がず、要件を理解する時間をかける
ドラフトファイルを継続的に確認し、誤解があればすぐに訂正
単一計画原則に従い、大きなタスクを分割しない
テスト戦略を明確にし、計画全体の構造に影響を与える

次のレッスンの予告

次のレッスンでは バックグラウンド並列タスク：チームのように働く を学びます。
学べること：
複数のエージェントを並列で動作させ、効率を大幅に向上させる方法
並列制限を設定し、API レート制限を回避する方法
バックグラウンドタスクを管理し、結果を取得して操作をキャンセルする方法
「リアルなチーム」のように複数の専門エージェントを調整する方法

付録：ソースコードリファレンス

クリックしてソースコードの場所を表示

更新日：2026-01-26

機能	ファイルパス	行番号
Prometheus システムプロンプト	`src/agents/prometheus-prompt.ts`	19-1184
Prometheus 権限設定	`src/agents/prometheus-prompt.ts`	1187-1197
Metis エージェント	`src/agents/metis.ts`	-
Momus エージェント	`src/agents/momus.ts`	-
オーケストレーションガイドドキュメント	`docs/orchestration-guide.md`	67-90

核心定数：

PROMETHEUS_SYSTEM_PROMPT：Prometheus のアイデンティティ、ワークフロー、制約を定義する完全なシステムプロンプト

主要関数/ツール：

PROMETHEUS_PERMISSION：Prometheus のツール権限を定義（.md ファイル編集のみ許可）

ビジネスルール：

Prometheus デフォルトモード：INTERVIEW MODE（インタビューモード）
自動遷移条件：Clearance Checklist がすべて YES
Metis コンサルティング：計画生成前に強制的に実行
Momus ループ：オプションの高精度モード、"OKAY" までループ
単一計画原則：どれだけ大きくても、すべての TODO は 1 つの .md ファイルに
ドラフト管理：.sisyphus/drafts/{name}.md を継続的に更新、計画完了後に削除

Prometheus プランニング：インタビュー形式の要件収集と作業計画の生成 ​

このレッスンが終わるとできること ​

あなたが直面している課題 ​

Prometheus を使うべきタイミング ​

🎒 開始前の準備 ​

核心アイデア ​

Prometheus の核心アイデンティティ制約 ​

3 段階ワークフロー ​

実践編 ​

ステップ 1：Prometheus プランニングセッションの開始 ​

ステップ 2：質問に答えて、Prometheus にコンテキストを収集させる ​

ステップ 3：ドラフトファイルを確認する（オプション） ​

ステップ 4：要件が明確になるまで回答を続ける ​

ステップ 5：生成された計画を確認する ​

ステップ 6：実行方法を選択する ​

ステップ 7：計画を実行する ​

落とし穴の注意 ​

落とし穴 1：要件を半分言って急いで計画を求める ​

落とし穴 2：ドラフトファイルを確認しない ​

落とし穴 3：計画を複数回に分けて生成する ​

落とし穴 4：Metis の役割を忘れる ​

落とし穴 5：テスト戦略の決定を無視する ​

レッスンサマリー ​

次のレッスンの予告 ​

付録：ソースコードリファレンス ​

Prometheus プランニング：インタビュー形式の要件収集と作業計画の生成

このレッスンが終わるとできること

あなたが直面している課題

Prometheus を使うべきタイミング

🎒 開始前の準備

核心アイデア

Prometheus の核心アイデンティティ制約

3 段階ワークフロー

実践編

ステップ 1：Prometheus プランニングセッションの開始

ステップ 2：質問に答えて、Prometheus にコンテキストを収集させる

ステップ 3：ドラフトファイルを確認する（オプション）

ステップ 4：要件が明確になるまで回答を続ける

ステップ 5：生成された計画を確認する

ステップ 6：実行方法を選択する

ステップ 7：計画を実行する

落とし穴の注意

落とし穴 1：要件を半分言って急いで計画を求める

落とし穴 2：ドラフトファイルを確認しない

落とし穴 3：計画を複数回に分けて生成する

落とし穴 4：Metis の役割を忘れる

落とし穴 5：テスト戦略の決定を無視する

レッスンサマリー

次のレッスンの予告

付録：ソースコードリファレンス