# Kizashi Claude Code実装計画・Phaseごとのプロンプト設計 作成日: 2026-08-19 関連: [Kizashi 要件定義書 v3](https://clipnote.paritto.dev/p/b102955d-350c-4bb4-a576-c2b2a9fb4655) / [Kizashi 設計書 v2](https://clipnote.paritto.dev/p/0e4d0bf1-aef9-48b9-b64d-b7a278b1c8d4) 前提：要件定義書・設計書は `docs/要件定義書.md` `docs/設計書.md` としてリポジトリ内に配置する。 ## 実装フェーズ全体像 | Phase | 内容 | |---|---| | 0 | 基盤構築（モノレポ初期化・D1マイグレーション・独自認証） | | 1 | Threads連携の疎通確認（OAuth・トークン暗号化・手動投稿確認） | | 2 | Draft管理の最小機能（AI生成なし。CRUD＋評価） | | 3 | 予約投稿の自動実行（Cron・親子リプライ順序制御・トークンリフレッシュ） | | 4 | 実測エンゲージメント取得（スナップショットCron・実績サマリー） | | 5 | AI生成（内部）（kizashi-core・エージェント的生成フロー） | | 6 | MCP公開・APIキー管理 | | 7 | 複数アカウントUI仕上げ・友人への展開準備 | ### 進め方の考え方 - Phase 1（Threads API）を最優先にしているのは、外部要因に依存するリスクを早期に潰すため - AI生成（Phase 5）を意図的に後回しにしているのは、Draft・予約投稿・実測データという土台を先に作り、AI生成のフィードバックループをテストしやすくするため - Phase 1・3・5は不確実性が高いため、実装前にPlan Modeで計画を出させてレビューしてから着手する ## モノレポ構成 ``` kizashi/ apps/ kizashi-web/ # Next.js kizashi-api/ # Cloudflare Workers kizashi-mcp/ # Cloudflare Workers（別デプロイ） packages/ kizashi-core/ # create_draft等の共有ロジック docs/ 要件定義書.md 設計書.md CLAUDE.md ``` ## CLAUDE.mdに含めるべき内容 - 技術スタック（Next.js / Cloudflare Workers / D1、認証はKizashi独自） - Worker分離方針（kizashi-apiとkizashi-mcpは別デプロイだがkizashi-coreを共有する） - drafts.status の取りうる値一覧（draft/scheduled/ready_to_publish/published/failed） - docs/要件定義書.md, docs/設計書.md への参照 --- ## Phaseごとのプロンプト ### Phase 0：基盤構築 ``` docs/要件定義書.md と docs/設計書.md を読み込んでください。 以下の構成でモノレポを初期化してください。 - apps/kizashi-web（Next.js） - apps/kizashi-api（Cloudflare Workers） - apps/kizashi-mcp（Cloudflare Workers、apps/kizashi-apiとは別デプロイ） - packages/kizashi-core（共有ロジック用、中身は空でOK） その後、apps/kizashi-api に Wrangler の設定とD1バインディングを追加し、 docs/設計書.md の「3. DBスキーマ設計」にある users / threads_accounts テーブルの マイグレーションファイルを作成してください。他のテーブルはまだ作らないでください。 最後に、CLAUDE.md を作成し、以下を含めてください。 - 技術スタック（Next.js / Cloudflare Workers / D1、認証はKizashi独自） - Worker分離方針（kizashi-apiとkizashi-mcpは別デプロイだがkizashi-coreを共有する） - drafts.status の取りうる値一覧（draft/scheduled/ready_to_publish/published/failed） - docs/要件定義書.md, docs/設計書.md への参照 実装前に、進め方の計画を先に提示してください（Plan Mode）。 ``` ### Phase 1：Threads連携の疎通確認 ``` docs/設計書.md の「6. Threads API連携の要点」と、 docs/要件定義書.md の「3.5 アカウント管理」を踏まえて実装を進めます。 以下を実装してください。 1. Threads OAuth連携（/threads-accounts/oauth/start, /callback） 2. アクセストークンをWorkers Secretsで管理する暗号化キーでAES暗号化しD1に保存する処理 3. 手動で1件投稿できることを確認するための検証用スクリプト（threads_publishの2ステップ： コンテナ作成→publish） OAuthのコールバックURL・アプリ登録など、私が手動でブラウザ操作する必要がある手順があれば、 実装前に明示してください。 まず実装計画を提示してください（Plan Mode）。外部APIとの整合性、トークンの取り扱いに 特に注意して計画を立ててください。 ``` ### Phase 2：Draft管理の最小機能（AI生成なし） ``` docs/設計書.md の「3. DBスキーマ設計」「4. API設計」を踏まえて実装を進めます。 以下を実装してください。 1. groups, projects, project_files のCRUD API（kizashi-api） 2. drafts の手動作成・編集・削除・評価（rating 1-5）・一覧取得API （account_id/group_id/status/rating_min でフィルタ可能にする） 3. kizashi-webに、Draft一覧画面（フィルタ含む）と、Draft詳細画面（編集・評価）を実装 この段階ではAI生成機能・予約投稿機能は実装しないでください。 手入力でDraftを作成・評価できるところまでを完成させてください。 ``` ### Phase 3：予約投稿の自動実行 ``` docs/設計書.md の「3.4 予約投稿機能」の順序制御ロジックを踏まえて実装します。 以下を実装してください。 1. POST /drafts/:id/schedule（scheduled_at, parent_draft_id指定可） 2. Cron: 予約投稿実行ジョブ - 実行前に GET threads_publishing_limit で250件/日の残数を確認 - 親を持たないDraft、または can_publish_after_parent=1 かつ scheduled_at を過ぎたDraftを対象 3. Cron: 親投稿完了検知ジョブ - 親Draftのthreads_post_idが確定したら、子Draftのcan_publish_after_parentを1に更新 - 親投稿が失敗した場合は子を投稿保留にし、failure_reasonを設定 4. Cron: トークンリフレッシュジョブ（token_expires_atが近いアカウントを更新） Cron Triggersのローカル検証方法（wrangler dev）も含めて、まず実装計画を提示してください （Plan Mode）。特に、親子リプライの順序制御ロジックに矛盾がないか重点的に確認してください。 ``` ### Phase 4：実測エンゲージメント取得 ``` docs/設計書.md の「2. 実測エンゲージメントデータ設計」を踏まえて実装します。 以下を実装してください。 1. draft_engagement_snapshots テーブルへの書き込み処理 2. Cron: 投稿後1h/24h/72h/7dのタイミングでthreads_manage_insightsを叩き、 スナップショットとして保存するジョブ（取得失敗時は3回までリトライ、 それでも失敗したらfetch_failedを立てて通知） 3. GET /groups/:id/stats（グループ単位の実績サマリー：平均インプレッション、 評価分布など） 7日後のスナップショットが「確定値」として扱われることをコード上明確にしてください （変数名やコメントで区別する）。 ``` ### Phase 5：AI生成（内部） ``` docs/設計書.md の「5. MCPツール設計」内、create_draftの実装方針と 内部AI生成のフローを踏まえて実装します。 以下を実装してください。 1. packages/kizashi-core に create_draft のコアロジック（バリデーション＋DB書き込み） 2. POST /drafts/generate：以下のエージェント的フローを実装 - 同グループの高評価(4-5)・低評価(1-2)Draftを取得 - 指定プロジェクトの参照ファイルを取得 - グループの実績サマリーを取得 - 上記をコンテキストとしてLLMにDraftを生成させ、create_draftで保存 3. GET /drafts/generate/:jobId（ポーリング用、processing/completed/failed + progress_message） 非同期ジョブの状態管理の実装方針を先に提示してください（Plan Mode）。 ``` ### Phase 6：MCP公開・APIキー管理 ``` docs/設計書.md の「5. MCPツール設計」「6. APIキー発行方針」を踏まえて実装します。 以下を実装してください。 1. api_keys のCRUD API（scopes: drafts:read/drafts:write/projects:read） 2. apps/kizashi-mcp に以下のMCPツールを実装（packages/kizashi-coreのロジックを利用） - list_drafts, get_draft, get_group_stats（drafts:read） - list_projects, get_project_file（projects:read） - create_draft（drafts:write） 3. APIキーによるスコープ検証ミドルウェア 実装後、Claude Desktopから実際に接続し、動作確認の手順を教えてください。 ``` ### Phase 7：複数アカウントUI仕上げ・展開準備 ``` docs/設計書.md の「1. 複数Threadsアカウント対応」を踏まえて実装します。 以下を実装してください。 1. ヘッダーのアカウントスイッチャー（選択中アカウントでDraft一覧・生成をフィルタ） 2. 全アカウント横断のDraft一覧ビュー 3. 新規ユーザーのサインアップ〜Threadsアカウント連携までのオンボーディング画面 ``` --- ## 補足 - 各プロンプトの冒頭で `docs/要件定義書.md` `docs/設計書.md` の該当セクションを明示的に読ませることで、Claude Codeが毎回ゼロから設計判断をやり直さないようにする - Phase 1・3・5は不確実性が高い（外部API連携・非同期処理・エージェントフロー）ため、実装前にPlan Modeで計画を出させてレビューする一手間を入れる - Cron処理（Phase 3, 4）はローカルでは `wrangler dev` のCron Triggersエミュレーションを使い、実運用相当のタイミング検証はステージング環境で行う - Phase完了ごとに、Clipnoteの設計書に「実装状況」セクションを追記していく運用とする