ディレクションシステムβ

• スピード優先: まず公開し、公開後に改善を重ねる方針（MVP重視）
• 品質優先: 仕様・表現・テスト精度を優先し、完成度を担保して公開する方針
• コスト優先: 予算上限を守るため、実装範囲を段階分割して進める方針
• 学習優先: 新技術や新運用の検証価値を重視し、知見獲得を目的に含める方針

# プロジェクトコンセプト合意
- 優先方針: [スピード優先 / 品質優先 / コスト優先 / 学習優先]
- 今回この方針を選ぶ理由:
- 例外条件（方針を切り替える条件）:
- 最終判断者:
- 見直しタイミング: [毎週定例 / マイルストーン到達時 など]

• プロジェクトコンセプト（スピード優先 / 品質優先 など）
• 目的・成果指標（KGI / KPI）
• スコープ（やること / やらないこと）
• 体制・意思決定（責任者 / 決裁ルート）
• コミュニケーション設計（ツール / 定例 / SLA / 議事録）
• エスカレーション（条件 / 連絡先 / 手段）
• 開発環境・運用（リポジトリ / ブランチ / 権限）
• 使用ツール・必要アカウント・コスト
• design.md の必要有無（必要時の管理責任者・更新ルール）
• AI利用ポリシー（どの工程で使うか / 使ってよい範囲 / 禁止事項）
• スケジュール管理（管理方法 / 更新責任者 / マイルストーン）
• リリース方法（手順 / 責任者 / ロールバック条件）
• 納品完了の定義（Definition of Done）
• 変更管理ルール（仕様変更時の再合意ルート）

キックオフ項目をコピーする

# キックオフ合意チェックリスト
- [ ] プロジェクトコンセプト（スピード優先 / 品質優先 など）
- [ ] 目的・成果指標（KGI / KPI）
- [ ] スコープ（やること / やらないこと）
- [ ] 体制・意思決定（責任者 / 決裁ルート）
- [ ] コミュニケーション設計（ツール / 定例 / SLA / 議事録）
- [ ] エスカレーション（条件 / 連絡先 / 手段）
- [ ] 開発環境・運用（リポジトリ / ブランチ / 権限）
- [ ] 使用ツール・必要アカウント・コスト
- [ ] design.md の必要有無（必要時の管理責任者・更新ルール）
- [ ] AI利用ポリシー（利用工程 / 許可範囲 / 禁止事項）
- [ ] スケジュール管理（管理方法 / 更新責任者 / マイルストーン）
- [ ] リリース方法（手順 / 責任者 / ロールバック条件）
- [ ] 納品完了の定義（Definition of Done）
- [ ] 変更管理ルール（仕様変更時の再合意ルート）

# AI利用ポリシー
## 1. 利用する工程
- [ ] 企画整理
- [ ] 要件定義の叩き台
- [ ] 文案作成
- [ ] 実装補助
- [ ] テスト補助

## 2. 利用してよい範囲
- 利用可能データ: [公開情報 / 匿名化済み情報 / 社内限定情報]
- 出力の扱い: [必ず人がレビューして確定]

## 3. 禁止事項
- 個人情報・機密情報を未加工で外部AIに投入しない
- AI出力を無検証で本番反映しない
- 著作権・利用規約に抵触する生成物を納品しない

## 4. 承認フロー
- AI利用ルール変更の承認者: [@お名前]
- 例外利用時の連絡先: [@お名前]

ヒアリングシートをコピーする

# 🚀 Web制作初期ヒアリングシート (GPOL-Inspired)

## 1. 基本情報
- 会社名 / 担当者名:
- 連絡方法（メール/Slack/その他）:

## 2. 構築の目的（コンバージョン）
- 解決したい課題 / 達成したい目標（売上・集客・認知等）:
- 特にアピールしたい強み・特徴:
- サイトのゴール（問い合わせ/資料請求/購入など）:
- 競合・ベンチマークサイト（3社ほど）:

## 3. ターゲット
- 年代 / 性別 / 区分（B2B or B2C） / エリア指定:

## 4. コンテンツ・希望業務
- 希望業務（企画/設計/デザイン/コーディング/システム開発/運用）:
- 希望するコンテンツ（新設 / リニューアル箇所）:
- 希望の公開予定日（デッドライン）:

## 5. 現状のインフラ仕様
- ドメイン・サーバー（新規契約 or 既存移管）:
- SSL対応・テスト（検証）環境の要否:
- CMS（WordPress等）の指定:

## 6. デザイン仕様
- コーポレートカラー / 主に使いたい色:
- 素材（ロゴ・写真・紹介動画・コピーテキスト）の有無:
- 参考サイト、既存パンフレットなどの有無:

## 7. コーディング・システム仕様
- 対応デバイス（PCのみ / スマホ対応 / レスポンシブ）:
- 上位表示させたいSEOキーワード:
- OGP・SNS連携（埋め込み等）の有無:

## 8. その他
- 最終決裁者の確認ルート:
- リリース（公開）後の保守・運用体制: 

設計テンプレートをコピーする

# 👥 プロジェクト体制図 ＆ コミュニケーション設計

## 1. プロジェクト体制図（誰が何を決定するか）
- **プロジェクトオーナー（最終意思決定者）**: [@お名前] (仕様の最終決定・予算/スコープの承認権限を持つ)
- **ディレクション実務担当（窓口）**: [@お名前] (要件定義、タスク設計、進捗の全責任者)
- **制作・開発実務者**: [@お名前] (UIデザイン・Figma設計・システム実装)

## 2. コミュニケーション設計
- **メインチャットツール**: Slack (チャンネル名: #xxx-project)
- **定例ミーティング**: 毎週 [曜日] [時間] 〜 [時間] (アジェンダは前日までに用意)
- **チャット上の運用ルール**:
  - メンション付きのメッセージには原則24時間以内に「👀」リアクションで既読を明示する。
  - 会話が3往復以上長引く議論はスレッドへ移行し、決定した結果のみをチャンネル親スレへ同期する。
  - 口頭や会議で合意した決定事項は、必ず「5分以内」に要約テキスト化して関係者へ送る。

## 3. エスカレーション設計（遅延・事故時）
- **トリガー条件**:
  - 納期遅延見込みが24時間を超える
  - 仕様衝突が発生し、担当者間で解決できない
  - 本番影響の不具合を検知した
- **一次連絡先**: [@ディレクション実務担当]
- **二次連絡先（最終判断）**: [@プロジェクトオーナー]
- **連絡手段**: Slackメンション + 緊急時は電話

## 4. 開発環境・運用ルール
- **リポジトリ**: [GitHub URL]
- **ブランチ運用**: main保護 / featureブランチ作業 / PRレビュー必須
- **環境**: local / staging / production
- **デプロイ方法**: GitHub Actions（手動FTPは禁止）
- **リリース判定**: チェックリスト完了 + 最終承認者OK

## 5. リリース方法（本番反映手順）
- **リリース責任者**: [@お名前]
- **実行方法**: [mainへマージ後に自動デプロイ / 手動実行]
- **実行タイミング**: [平日xx:xx / 定例後 など]
- **リリース告知**: [Slack #xxx-project に開始/完了を投稿]
- **ロールバック条件**: [重大不具合時は直前バージョンへ戻す]

## 6. 納品完了の定義（Definition of Done）
- [ ] 仕様・デザインの合意項目が反映済み
- [ ] テスト項目（表示・導線・フォーム等）が完了
- [ ] 本番反映後の疎通確認が完了
- [ ] 納品物（URL / ソース / 付帯資料）の共有が完了
- [ ] クライアント最終確認の承認コメントを取得済み

## 7. ディレクションノート参照（そのまま転記する項目）
- **使用ツール**: [Figma / Notion / Slack / GitHub / その他]
- **必要アカウント**: [誰に何の権限が必要か]
- **コスト**: [月額費用・初期費用・負担者]
- **スケジュール管理方法**: [管理ツール名 / 更新責任者 / 更新頻度]
- **補足**: [プロジェクト固有の運用ルールを追記] 

AGENTS.mdをコピーする

# AGENTS.md — AIエージェント向け設計書

## 1. 重要: 非Git管理の必須ファイル
以下はデプロイで自動更新されません。消失した場合は復旧手順に従ってください。
- `api/config.php`         : 設定・認証キー
- `api/data/*.sqlite`      : DBファイル本体（バックアップから復旧）

## 2. データ管理ルール
- 削除は status = 'deleted' への変更（ソフトデリート）を原則とする
- 物理削除が必要な場合は、事前にバックアップを確認すること

## 3. UI仕様のロック（先祖返り防止）
- 確定した表示件数・ソート順はコードで固定する
- デプロイスクリプトに自動チェックを組み込む
- 意図的な変更の場合はチェックロジックも必ず併せて更新すること

## 4. デプロイ後チェック手順
1. 必須ファイルの存在確認
2. 先祖返りチェック（スクリプト自動実行）
3. 疎通確認（WAF環境ではcurlでなくブラウザ・Playwright使用）

プロンプトをコピーする

# クライアントからの要件インプット
[ここに箇条書きやメモを挿入]

# 出力ゴール
- 目的と背景の整理
- 必要な制作物（HTML/CSS/JS構成）
- 発生しうる懸念点と確認事項（3点）
上記を「段取り化（ステップ順）」して構造的に出力してください。

議事録フォーマットをコピーする

# 定例MTG議事録 (2026/05/26)

## 🎯 今回の合意ゴール
- 本番リリースの日程決定
- 修正箇所の合意

## 📢 決定事項
- [x] リリース日は 2026年6月1日（月）に決定
- [x] キャッシュバスターのパラメータは「20260526」で統一

## ⏳ Next Action (誰が・いつまでに)
- [ ] @担当A : 修正対応 (5/28まで)
- [ ] @担当B : プレビュー確認 (5/29まで)

• スプリント周期（1週 / 2週）と、計画・レビュー・レトロの実施曜日を固定する
• デプロイ差し戻し条件（エラー率、CV低下、重大不具合）を数値で定義する
• Hotfix の扱い（誰の承認で、どこまで即時対応可能か）を明確化する
• 運用KPI（障害件数、復旧時間、改善完了率）を毎スプリントで確認する
• 運用変更は必ず議事録と運用ルールへ反映し、次回から標準化する

# ローンチ後 運用ガバナンス
## 1. スプリント周期
- 期間: [1週 / 2週]
- 計画MTG: [曜日・時間]
- レビューMTG: [曜日・時間]
- レトロMTG: [曜日・時間]

## 2. デプロイ差し戻しルール
- 差し戻し条件:
  - [ ] 重大不具合（P1）発生
  - [ ] エラー率が閾値超過（例: xx%）
  - [ ] CV/主要KPIが閾値以上で悪化
- 判断責任者: [@お名前]
- 差し戻し手順: [直前安定版へロールバック]

## 3. Hotfix運用
- 実行条件: [緊急度の定義]
- 承認者: [@お名前]
- 事後対応: [翌営業日までに原因・再発防止を記録]

## 4. 運用KPIレビュー
- 監視項目: [障害件数 / MTTR / 改善完了率 / 問い合わせ件数]
- レビュー頻度: [毎スプリント]
- 改善オーナー: [@お名前]

• [ ] : 未着手（デフォルト）
• [/] : 進行中（進行状態の明示）
• [x] : 完了（タスクのクローズ）
• [!] : 警告・遅延（期限切迫などのアラート）

• [DRAFT] : 草稿・作成中（内部確認前）
• [REVIEW] : レビュー中・承認待ち
• [APPROVED] : 承認済み・確定（変更時は再合意が必要）
• [ARCHIVED] : 廃止・アーカイブ（参照のみ）