# Kizashi（きざし） 要件定義書 v3 作成日: 2026-08-19 ## 1. 概要・目的 Threads APIを利用し、以下を実現するツール「**Kizashi**」を構築する。 - 指定テーマ・コンバージョン最適化の指示に沿ってAIに投稿内容を提案させる - 提案内容を「Draft」としてリスト保存・管理する - Draftを指定日時に予約投稿する（通常投稿・リプライ投稿の両方に対応） - 複数Threadsアカウント・複数ユーザーでの利用を前提とする - 投稿の実測エンゲージメントを取得し、評価データと合わせてAI生成へフィードバックする ## 2. 用語定義 | 用語 | 定義 | |---|---| | Draft | AIが提案した投稿内容の1件。生成→リスト管理→予約投稿の対象となる単位 | | プロジェクト | Draft生成時にAIへ参照させるMarkdownファイル群をまとめる単位（用途は限定しない汎用的な参照ファイル置き場。投稿の伸びを最適化するための情報などを想定） | | グループ | Draftをテーマ単位でまとめる分類（例：「新機能告知シリーズ」） | | アカウント | 投稿先のThreadsアカウント（1ユーザーが複数保有可能） | ## 3. 機能要件 ### 3.1 AI投稿生成機能 - ユーザーがプロンプト（テーマ・コンバージョン最適化の指示など）を入力し、AIに投稿内容案を生成させる - 生成時に「グループ（テーマ）」と「使用するプロジェクト（1つ以上）」を選択する - 生成時、同じグループ内で過去に★4〜5評価だったDraftを「良い例」、★1〜2を「避けるべき例」としてプロンプトに自動注入する - 生成結果はそのままDraftとして保存され、選択したグループに自動的に入る ### 3.2 プロジェクト機能 - 参照ファイルはMarkdownのみ対応 - 用途は限定しない汎用的な参照ファイル置き場（例：投稿の伸びを最適化するための情報、トンマナガイドなど） - ファイル本文はKizashi自前のDBに保存する（Clipnote等の外部ファイルストレージとの連携はしない） - プロジェクトとグループは独立した概念とし、多対多で組み合わせ可能 - プロジェクトに「デフォルトグループ」を設定でき、選択の手間を軽減する ### 3.3 Draft管理機能 - 生成されたDraftはリストとして保存・閲覧・編集できる - グルーピング：テーマ単位でグループを作成し、Draftを分類できる - 評価：5段階評価（★1〜5）でDraftを評価できる - Draftのステータス管理（下書き／予約済み／投稿済み など） - 投稿後、一定時間後（例：24時間後・72時間後）に実測エンゲージメント（インプレッション・いいね・返信数など）を取得し、Draftに紐づけて保存する - 星評価（主観）と実測エンゲージメント（客観）の両方をAI生成へのフィードバック材料として活用する ### 3.4 予約投稿機能 - Draftに投稿予定日時を設定し、自動投稿を実行する - リプライ投稿：指定したDraft（投稿済み・予約済みで未投稿のものも可）への返信として投稿できる - 順序制御はイベント駆動方式：親の投稿完了（投稿ID確定）をトリガーに、子の「投稿可能フラグ」を立てる。子は「投稿可能フラグが立っている」かつ「予定時刻を過ぎている」の両方を満たした時点で投稿される（子の予定時刻は下限として扱う） - 親投稿が失敗した場合、子は自動的に投稿保留にしてユーザーに通知する - 実行前にThreads APIの24時間250投稿上限を確認し、超過を防ぐ ### 3.5 アカウント管理 - 複数のThreadsアカウントをOAuth連携で登録できる（1ユーザーが複数アカウントを保有可能） - 複数ユーザーでの利用に対応（マルチテナント） - 認証方式：Kizashi単体で独立した認証を持つ（他Parittoプロダクトとの認証統合はしない） - Threadsアクセストークンは複数保持できる設計とし、D1に暗号化して保存する（復号キーはWorkers Secretsで管理）。60日の有効期限が切れる前に自動リフレッシュする ### 3.6 外部AI連携（MCP） - Draft・実績データ（評価・実測エンゲージメント）をMCPサーバーとして公開し、Kizashi外のClaude・ChatGPT等からも参照できるようにする - 想定ツール：`list_drafts`（グループ・評価・実績でフィルタ可能な一覧取得）、`get_draft`（本文・評価・実測実績の取得）、`get_group_stats`（グループ単位の実績サマリー、想定） - MCP経由の対応はまずClaude向けに実装し、ChatGPT対応（Developer Mode経由のMCP接続）は安定性を見て後追いする ## 4. 非機能要件 - Threads APIのレート制限（4800×インプレッション数）・投稿数上限（250件/日）・リプライ上限（1000件/日）を遵守する - アクセストークンの自動リフレッシュ処理 - 個人・少人数利用の範囲であればMeta App Reviewは不要だが、対象ユーザーが広がる場合は審査が必要になる点に留意 ## 5. 技術構成 | レイヤー | 技術 | 役割 | |---|---|---| | フロントエンド | Next.js（Vercel） | Draft管理UI・プロジェクト管理・アカウント連携画面 | | バックエンドAPI | Cloudflare Workers（kizashi-api） | Draft CRUD・評価・グループ管理・Threads OAuth処理・Cron（予約投稿実行・トークンリフレッシュ・実績データ取得） | | DB | Cloudflare D1 | ユーザー・Threadsアカウント（暗号化トークン含む）・Draft・プロジェクト（Markdown本文含む）・実績データ | | Cronスケジューラ | Cloudflare Workers Cron Triggers | 予約投稿の実行・親子リプライの順序制御・実績データの定期取得 | | MCPサーバー | Cloudflare Workers（kizashi-mcp、完全に別Worker） | Draft・実績データの外部公開（Claude/ChatGPT向け） | ## 6. Threads API連携の要点 - 投稿は2ステップのコンテナモデル：`POST /{threads-user-id}/threads` でコンテナ作成 → `POST /{threads-user-id}/threads_publish` で公開 - 必要スコープ：`threads_basic`（必須）、`threads_content_publish`（投稿に必須）、`threads_manage_insights`（実測エンゲージメント取得に必須） - クォータ確認：`GET /{threads-user-id}/threads_publishing_limit` ## 7. 未決事項（今後詰める点） - MCPサーバーの認証・アクセス範囲の詳細設計 - 実測エンゲージメント取得のタイミング（何時間後に何回取得するか）の細部 - グループ単位の実績サマリー（`get_group_stats`）の具体的な集計項目