AI部署7役割プロンプト集
— コピペでClaude Codeがあなたの会社にAI部署を作る

あなたはこれから、私の作業フォルダに「AI組織のCEO（代表取締役）」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- AI組織は「部署 = 責任者（CxO）＋ 実行ロール（人）」で作る。CEOだけは部署に属さず、AI組織フォルダのルート直下に置く
- 責任者は戦略と振り分けだけを行い、実作業は実行ロールが持つ
- すべてのロールは knowledge（判断材料）/ skills（手順書）/ output（成果物）の3層を必ず揃え、混ぜない
- スキル = 同じ品質で繰り返すための再現可能な手順書。手順・参照ファイル・出力先・品質基準を必ず書く

# まず私に質問する（回答が揃うまでファイルを1つも作らない）
1. 会社・事業の名前と、一言でいうと何の事業か
2. いま一番増やしたい数字は何か（売上 / 問い合わせ / フォロワー / 受講生 など）
3. AIに絶対に勝手にやってほしくないことは何か（外部への送信 / 課金 / ファイル削除 など）

# 回答を受けたら、この構造を作る
03-AI_departments/
└── ceo（代表取締役）/
    ├── _RULE.md
    ├── knowledge/
    │   └── business-summary.md   ← 私の回答をまとめた事業サマリー
    ├── skills/
    │   └── 01-memory-maintenance/
    │       └── SKILL.md
    └── output/
        └── archive/

# ceo（代表取締役）/_RULE.md に必ず書く項目（この順で）
1. 役割 — 全体戦略、意思決定、部署間の調整、組織の長期記憶（MEMORY.md）の管理。実作業は持たない
2. 境界 — 各部署の実作業を奪わない。CEOがやるのは「これはどの部署の誰の仕事か」の裁定まで
3. 必読 — ルートの MEMORY.md と knowledge/business-summary.md（フルパスで書く）
4. 品質基準 — 依頼を受けたら「新しい仕事か既存の仕事か」「どの部署に振るか」を先に判定してから動く、判断に迷ったら人間に質問して止まる、など測れる形で5個
5. NG — 私が質問3で答えた内容をそのまま転記＋「実作業を自分でやらない」
6. 改善ログ — 日付 / 変更内容 / 理由 の3列の空テーブル

# 最初のスキル skills/01-memory-maintenance/SKILL.md
「日々の作業ログから組織の長期記憶を更新する」スキル。次の節で書く:
概要（memory/の日次ログから恒久的な学びだけを MEMORY.md へ蒸留する）/ 必読 / 実行手順（1. memory/YYYY-MM-DD.md を読む → 2. 一時的な情報と恒久ルールを仕分ける → 3. 恒久ルールだけをMEMORY.mdへ1行ずつ追記 → 4. 追記した行を報告）/ 品質基準（1エントリ1行・日付や案件名など一時情報は書かない）/ 改善ログ

# 併せてルート直下に作る
- MEMORY.md — 組織の長期記憶。事業サマリー・一番追う数字・NG事項・部署一覧（今はCEOのみ）を初期記載
- memory/ フォルダ — 毎日の作業ログ置き場。「作業をしたら memory/YYYY-MM-DD.md に、やったこと・保存先・次にやること・未解決を書く」ルールをMEMORY.mdに明記

# 完了条件
- 上のツリーが全部でき、_RULE.md と SKILL.md が空テンプレでなく私の事業内容で埋まっている
- 最後に、作ったファイル一覧（パス付き）と「あなたの事業なら次に作るべき部署」の提案を1つ報告する

あなたはこれから、私の作業フォルダの 03-AI_departments/ に「マーケティング部署」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- 部署 = 責任者（CxO）＋ 実行ロール（人）。責任者は戦略と振り分けだけを行い、実作業は実行ロールが持つ
- 仕事は「人に振る」。実行ロールには職種名を付ける
- すべてのロールは knowledge / skills / output の3層を必ず揃え、混ぜない
- ルートに MEMORY.md（長期記憶）と ceo（代表取締役）/ がある前提。あれば必ず先に読み、事業内容を反映する。無ければ「先にCEO構築プロンプトの実行」を私に促して止まる

# まず私に質問する（回答が揃うまでファイルを1つも作らない）
1. 何を売っていて、理想のお客さんは誰か
2. 発信に使っている（使いたい）チャネルはどれか — X / Instagram / YouTube / メルマガ / 公式LINE / ブログ / セミナー
3. 発信に割ける時間は週どれくらいか
4. マーケで一番困っていることは何か（ネタ切れ / 継続できない / 反応がない など）

# 回答を受けたら、この構造を作る（実行ロールは回答2から1〜3人選ぶ。例: X運用担当・コンテンツ制作担当・セミナー企画担当）
03-AI_departments/Marketing Department/
├── _RULE.md                      ← 部署の入口。役割と「誰に振るか」の一覧
├── cmo（最高マーケティング責任者）/
│   ├── _RULE.md
│   ├── knowledge/
│   ├── skills/
│   │   └── 01-marketing-task-router/
│   │       └── SKILL.md          ← 依頼を分類して実行ロールに振るスキル
│   └── output/archive/
└── <実行ロール名>/                 ← 選んだ人数分（例: x-operations-specialist/）
    ├── _RULE.md
    ├── knowledge/
    │   └── audience-and-voice.md ← 私の回答から作る「読者と文体」メモ
    ├── skills/
    │   └── 01-<そのロールの主業務>/
    │       └── SKILL.md
    └── output/archive/

# 各 _RULE.md に必ず書く項目（この順で）
役割 / 境界（CMOは実作業をしない・実行ロールは戦略判断をCMOに戻す・他部署の仕事の線引き）/ 必読（MEMORY.mdと部署内ファイルをフルパスで）/ スキルマップ（番号・スキル名・パス・用途の表）/ 品質基準（測れる形で5個以上。例: 投稿は冒頭3行に専門用語を入れない）/ NG（例: 外部への投稿・配信は必ず人間の承認後）/ 改善ログ（空テーブル）

# 最初のスキルの中身
- CMOの 01-marketing-task-router: マーケ依頼を受けたら「どの実行ロールの仕事か」を判定し、目的・対象読者・完了条件を1枚のブリーフにして振る手順
- 実行ロールの01スキル: 回答2のチャネルに合わせた主業務（例: X投稿作成なら、knowledge/audience-and-voice.md を読む → 下書き3案 → 品質基準で自己チェック → output/archive/YYYY-MM-DD_<件名>/ に保存 → 人間の承認待ち、まで）

# 完了条件
- ツリーが全部でき、全 _RULE.md と SKILL.md が私の事業・チャネル・読者で埋まっている
- ルートの MEMORY.md の部署一覧にマーケティング部署を追記する
- 最後に「この部署への最初の依頼文の例」を1つ提案して終わる

あなたはこれから、私の作業フォルダの 03-AI_departments/ に「営業部署」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- 部署 = 責任者（CxO）＋ 実行ロール（人）。責任者は戦略と振り分け、実作業は実行ロール
- すべてのロールは knowledge / skills / output の3層を必ず揃え、混ぜない
- ルートの MEMORY.md と ceo（代表取締役）/ を先に読む。無ければCEO構築を先に促して止まる

# まず私に質問する（回答が揃うまで作らない）
1. 何をいくらで売っているか（価格帯・プランがあれば全部）
2. 商談はどう発生するか（問い合わせ / 紹介 / SNS経由 / 展示会 など）
3. 商談で毎回作っている資料は何か（提案書 / 見積もり / 会社紹介 など）
4. 営業でAIに任せたい一番面倒な作業は何か

# 回答を受けたら、この構造を作る
03-AI_departments/Sales Department/
├── _RULE.md
├── cso（最高営業責任者）/
│   ├── _RULE.md
│   ├── knowledge/
│   │   └── offer-and-pricing.md   ← 回答1・2をまとめた商材サマリー
│   ├── skills/01-sales-task-router/SKILL.md
│   └── output/archive/
└── proposal-designer（提案資料担当）/   ← 回答3・4に合わせて名前・専門を調整してよい
    ├── _RULE.md
    ├── knowledge/
    ├── skills/01-proposal-document/SKILL.md
    └── output/archive/

# 各 _RULE.md に必ず書く項目
役割 / 境界（金額の最終決定と値引き判断は必ず人間・契約締結はしない・マーケ部署との線引き）/ 必読 / スキルマップ / 品質基準（例: 提案書には相手の課題を先に書く、価格は knowledge/offer-and-pricing.md 以外から書かない）/ NG（実在しない実績・事例を書かない、送信は人間の承認後）/ 改善ログ

# 最初のスキル skills/01-proposal-document/SKILL.md
相手の会社名・課題・予算感を入力に、提案書の下書きを作る手順。必読（offer-and-pricing.md）→ 構成案を先に出して人間の確認 → 本文作成 → 品質基準チェック → output/archive/YYYY-MM-DD_<相手名>/ に保存、まで固定する

# 完了条件
- ツリー完成・全ファイルが私の商材で埋まっている・MEMORY.mdの部署一覧へ追記
- 最後に「この部署への最初の依頼文の例」を1つ提案して終わる

あなたはこれから、私の作業フォルダの 03-AI_departments/ に「カスタマーサポート部署」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- 部署 = 責任者（CxO）＋ 実行ロール（人）。責任者は分類と振り分け、実作業は実行ロール
- すべてのロールは knowledge / skills / output の3層を必ず揃え、混ぜない
- ルートの MEMORY.md と ceo（代表取締役）/ を先に読む。無ければCEO構築を先に促して止まる

# まず私に質問する（回答が揃うまで作らない）
1. お客さんは誰で、どこから連絡が来るか（メール / LINE / チャット / SNSのDM など）
2. よく来る質問・トラブルを思いつくだけ挙げてほしい（3個以上）
3. 返信の口調はどうしたいか（丁寧 / フランク / 既存の返信例があれば貼ってほしい）

# 回答を受けたら、この構造を作る
03-AI_departments/Customer Support Department/
├── _RULE.md
├── csm（カスタマーサクセス責任者）/
│   ├── _RULE.md
│   ├── knowledge/
│   ├── skills/01-support-task-router/SKILL.md   ← 問い合わせを分類して担当へ振る
│   └── output/archive/
└── support-staff（顧客対応担当）/
    ├── _RULE.md
    ├── knowledge/
    │   ├── faq.md            ← 回答2を「質問→回答」の型で初期整備
    │   └── reply-voice.md    ← 回答3の口調ルール
    ├── skills/01-inquiry-reply-draft/SKILL.md
    └── output/archive/

# 各 _RULE.md に必ず書く項目
役割 / 境界（返金・契約変更など金銭が絡む判断は必ず人間・回答に自信がない時は推測せず人間へ）/ 必読 / スキルマップ / 品質基準（例: 返信下書きは必ずfaq.mdを先に検索してから書く）/ NG（憶測で仕様や約束を答えない、実送信は人間の承認後）/ 改善ログ

# 最初のスキル skills/01-inquiry-reply-draft/SKILL.md
問い合わせ文を入力に、faq.md と reply-voice.md を読んで返信下書きを作る手順。「faq.mdに無い質問だった場合は、回答後に人間の承認を得てからfaq.mdへ追記する」を手順に含め、対応するほどFAQが育つ形にする

# 完了条件
- ツリー完成・faq.mdに初期FAQが入っている・MEMORY.mdの部署一覧へ追記
- 最後に「この部署への最初の依頼文の例」を1つ提案して終わる

あなたはこれから、私の作業フォルダの 03-AI_departments/ に「財務部署」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- 部署 = 責任者（CxO）＋ 実行ロール（人）。責任者は判断と振り分け、実作業は実行ロール
- すべてのロールは knowledge / skills / output の3層を必ず揃え、混ぜない
- ルートの MEMORY.md と ceo（代表取締役）/ を先に読む。無ければCEO構築を先に促して止まる

# まず私に質問する（回答が揃うまで作らない）
1. 毎月発生するお金の作業は何か（請求書発行 / 領収書の整理 / 売上のまとめ など）
2. 請求書を出す相手は何社くらいで、金額・振込先などの定型情報はどこにあるか
3. 会計ソフトや税理士など、最終的にデータを渡す先はあるか

# 回答を受けたら、この構造を作る
03-AI_departments/Finance Department/
├── _RULE.md
├── cfo（最高財務責任者）/
│   ├── _RULE.md
│   ├── knowledge/
│   │   └── billing-master.md   ← 回答2の定型情報（請求先・金額・振込先）の台帳
│   ├── skills/01-monthly-finance-routine/SKILL.md
│   └── output/archive/
└── invoice-operator（請求書・証憑担当）/
    ├── _RULE.md
    ├── knowledge/
    ├── skills/01-invoice-draft/SKILL.md
    └── output/archive/

# 各 _RULE.md に必ず書く項目
役割 / 境界（振込・支払い・送信は絶対にAIが実行しない。作るのは下書きと一覧まで）/ 必読 / スキルマップ / 品質基準（例: 金額・口座は billing-master.md 以外から書かない、請求書は1ページに収める）/ NG（台帳に無い金額を推測で書かない）/ 改善ログ

# 最初のスキル
- cfoの 01-monthly-finance-routine: 月初に「今月出す請求書一覧」「先月の売上まとめ」「未回収チェック」を作って人間に報告する月次手順
- invoice-operatorの 01-invoice-draft: billing-master.md を読んで請求書下書きを output/archive/YYYY-MM/ に作る手順。数字の転記ミスを防ぐため「台帳の値と突合した結果」を必ず報告に含める

# 完了条件
- ツリー完成・billing-master.mdの雛形に私の回答が入っている・MEMORY.mdの部署一覧へ追記
- 最後に「この部署への最初の依頼文の例」を1つ提案して終わる

あなたはこれから、私の作業フォルダの 03-AI_departments/ に「人事部署」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- 部署 = 責任者（CxO）＋ 実行ロール（人）。ただし仕事量が少ない部署は責任者1人から始めてよい
- すべてのロールは knowledge / skills / output の3層を必ず揃え、混ぜない
- ルートの MEMORY.md と ceo（代表取締役）/ を先に読む。無ければCEO構築を先に促して止まる

# まず私に質問する（回答が揃うまで作らない）
1. 一緒に働いている人は誰か（社員 / 外注 / パートナー / コミュニティ運営メンバー。人数と役割）
2. 人に関して毎回困ることは何か（依頼内容の伝達 / 引き継ぎ / 採用 / オンボーディング など）
3. 新しい人が入った時に毎回説明していることは何か

# 回答を受けたら、この構造を作る
03-AI_departments/Human Resources Department/
├── _RULE.md
└── chro（最高人事責任者）/
    ├── _RULE.md
    ├── knowledge/
    │   ├── org-chart.md        ← 回答1から作る組織図（誰が何担当か）
    │   └── members/            ← 1人1ファイルのメンバーノート置き場
    ├── skills/
    │   └── 01-onboarding-guide/SKILL.md
    └── output/archive/

# 各 _RULE.md に必ず書く項目
役割（組織図の管理・メンバーノートの更新・オンボーディング資料・採用基準）/ 境界（評価や報酬の決定はしない。判断材料の整理まで）/ 必読 / スキルマップ / 品質基準（例: メンバーノートは「得意・依頼の仕方・NG」を必ず持つ）/ NG（本人に確認していない個人情報を書かない・機微情報は外部に出さない）/ 改善ログ

# 最初のスキル skills/01-onboarding-guide/SKILL.md
回答3をもとに「新しい人が入った日に渡すオンボーディング資料」を作る手順。事業概要 → 使うツール → 最初の1週間でやること → 質問の投げ先、の構成で output/archive/ に生成し、以後は新メンバーのたびに名前だけ差し替えて再利用できる形にする

# 完了条件
- ツリー完成・org-chart.mdに実際のメンバーが入っている・MEMORY.mdの部署一覧へ追記
- 最後に「この部署への最初の依頼文の例」を1つ提案して終わる

あなたはこれから、私の作業フォルダの 03-AI_departments/ に「技術部署」を構築する担当です。チャットで役割を演じるのではなく、フォルダとファイルを実際に作ってください。

# この組織の設計思想（作る全ファイルにこの前提を反映する）
- 部署 = 責任者（CxO）＋ 実行ロール（人）。仕事量が少ないうちは責任者1人から始めてよい
- すべてのロールは knowledge / skills / output の3層を必ず揃え、混ぜない
- ルートの MEMORY.md と ceo（代表取締役）/ を先に読む。無ければCEO構築を先に促して止まる

# まず私に質問する（回答が揃うまで作らない）
1. いま動いている技術的なもの（サイト / LP / フォーム / スプレッドシート / スクリプト など）は何か。どこで動いているか
2. よく発生する技術作業は何か（サイト更新 / 集計 / 定型作業の自動化 など）
3. 触ってはいけないもの・壊れると困るものは何か

# 回答を受けたら、この構造を作る
03-AI_departments/Technology Department/
├── _RULE.md
└── cto（最高技術責任者）/
    ├── _RULE.md
    ├── knowledge/
    │   └── system-inventory.md   ← 回答1の一覧（何が・どこで・どう動いているか）
    ├── skills/
    │   └── 01-tech-task-intake/SKILL.md
    └── output/archive/

# 各 _RULE.md に必ず書く項目
役割（技術判断・実装・自動化・他部署からの技術依頼の受付）/ 境界（本番公開やデプロイなど後戻りできない操作は必ず人間の承認後・回答3のリストは変更前に必ず確認）/ 必読 / スキルマップ / 品質基準（例: 変更前に「触るファイル一覧と方針」を先に提示する、動作確認せずに完了報告しない）/ NG（依頼されていない機能を勝手に足さない・確認していないのに「動くはず」と報告しない）/ 改善ログ

# 最初のスキル skills/01-tech-task-intake/SKILL.md
技術依頼を受けた時の共通手順。system-inventory.md を読む → 現状を1〜3行で要約 → 触るファイルと方針を提示して人間の確認 → 最小変更で実装 → 動作確認の結果つきで報告 → やったことを output/archive/YYYY-MM-DD_<件名>/ に記録、まで固定する

# 完了条件
- ツリー完成・system-inventory.mdに実際のシステムが入っている・MEMORY.mdの部署一覧へ追記
- 最後に「この部署への最初の依頼文の例」を1つ提案して終わる