proposal-writer

name	proposal-writer
description	提案戦略書・チェックリストに基づき、提案書のMarkdownスライド設計書を生成・更新するスキル。
user-invocable	true
argument-hint	<対象Vol番号またはall> [出力形式: md|outline]
allowed-tools	Read, Grep, Glob, Write, Task

提案書スライド設計書ジェネレーター

概要

本スキルは、提案書作成の3層構造に基づき、スライド設計書（Markdown形式）を生成・更新する。 提案戦略からスライド1枚1枚のメッセージまでを一貫した論理で繋ぎ、抜け漏れのない提案書構成を実現する。

3層構造

提案戦略書（Why: なぜ勝てるか）
  ↓ Win Strategy / 差別化の柱を反映
チェックリスト（What: 何を書くか）
  ↓ 章立て・必須項目を網羅
スライド設計書（How: どう伝えるか）
  → 各スライドのメッセージ・内容・スピーカーノート

---

スライド設計書生成手順（5ステップ）

Step 0: デザインシステム + 組織固有データの読込

Step 0-a: DESIGN.md（必須）

プロジェクトルートの DESIGN.md を読み込む。Phase 2.5 で確定されたデザイン規約（色・タイポ・コンポーネント・Slide-Specific Rules）を抽出し、以降のスライド設計書・per-volume design.md 生成時に必ず反映する。

• DESIGN.md が存在しない場合はエラーを返し、/auto-run 2.5 または Phase 2.5 (Design System) の実行を促す
• 2. Color Palette & Roles の意味名トークンのみを使用し、独自の色を追加しない
• 7. Slide-Specific Rules のスライドマスター仕様（ヘッダー/フッター、表紙・章扉）を全ボリュームで統一する

Step 0-b: 組織固有データ（推奨）

arcadia/org-data/ 配下の自社固有データを読み込み、提案書に活用可能な自社情報を把握する:

• company-profile.md: 会社概要、認証・資格、パートナーシップ、導入実績（実績IDで引用）
• service-catalog.md: 自社サービスの仕様・差別化ポイント（サービスIDで引用）
• whitepapers/index.md: 引用可能なホワイトペーパー（タグ別・章別の引用推奨マップ）

org-data が未整備の場合でもスライド設計書の生成は可能だが、 会社紹介・実績・差別化セクションの内容が汎用的になるため、整備を推奨する。

Step 1: 提案戦略書読込

提案戦略書（output/plan/proposal-strategy.md 等）を読み込み、以下を把握する:

• Win Strategy: 提案全体の勝ちストーリー
• 差別化の柱: 競合との差別化ポイント（3-5本程度）。org-data/service-catalog.md の差別化ポイントと整合させる
• キーメッセージ: 顧客に最も伝えたい価値提案
• リスクと対策: 提案上の弱みとそのカバー方針
• 共同提案体制: パートナー各社の担当範囲。org-data/company-profile.md のパートナーシップ情報と整合させる

Step 2: チェックリスト読込

提案書作成チェックリスト（output/plan/proposal-items-checklist.md 等）を読み込み、以下を把握する:

• 章立て: 提案書の構成と必須セクション（分冊する場合はVol別）
• 必須記載項目: RFPが指定する記載必須事項
• 想定スライド数: 目安ページ数
• 重点項目: 配点が高い/審査で重視される項目

Step 3: スライドメッセージ設計

1スライド1メッセージ原則に基づき、各スライドを設計する:

• 各スライドに1つの明確なメッセージ（「このスライドで何を伝えるか」）を設定
• メッセージは提案戦略書のWin Strategyと紐づける
• 情報過多のスライドは分割を検討
• ストーリーの流れ（起承転結）を意識した並び順にする

Step 4: Markdown形式でスライド設計書を出力

以下のフォーマットで出力する:

# [提案書タイトル]

## メタ情報
- **想定スライド数**: XX枚
- **対象チェックリスト項目**: [項目ID一覧]
- **キーメッセージ**: [提案書全体で最も伝えたいこと]

---

## スライド一覧

### Slide 1: [スライドタイトル]
- **メッセージ**: [このスライドで伝えたい1つのこと]
- **内容**:
  - [箇条書きで記載内容を列挙]
  - [図表がある場合はその概要も記載]
- **スピーカーノート**: [プレゼン時の補足説明・強調ポイント]
- **対応チェックリスト**: [項目ID]

### Slide 2: [スライドタイトル]
...

Step 5: チェックリストとの突合

生成したスライド設計書とチェックリストを突合し、以下を確認する:

• 漏れ確認（CE）: チェックリストの全必須項目がいずれかのスライドでカバーされているか
• 重複確認（ME）: エグゼクティブ・サマリー以外で同じ内容が不必要に重複していないか
• 整合性確認: セクション間でメッセージが矛盾していないか

突合結果をスライド設計書の末尾に付記する:

## チェックリスト突合結果
| チェック項目ID | 対応スライド | 状態 |
|--------------|------------|------|
| E-1-1 | Vol.1 Slide 3 | カバー済 |
| E-1-2 | - | 未対応（要追加） |

---

標準章立てテンプレート

提案書の章構成は以下をデフォルトとする。RFPが章構成を指定している場合はRFP指定に従う。 各章のスライド枚数はRFPの要求内容・配点に応じて傾斜配分する。

章	タイトル	主な内容	枚数目安
1	エグゼクティブ・サマリー	提案全体の要約、キーメッセージ、差別化ポイント。本章のみ他章との内容重複を許容	1
2	会社概要・実績	会社紹介、関連プロジェクト実績、認証・資格、パートナー体制	1-2
3	提案コンセプト	現状課題（As-Is）→ 目指す姿（To-Be）、提案の全体像	2-3
4	システム構成・アーキテクチャ	論理構成図、技術スタック、機能要件対応、データ連携・移行方式	3-5
5	移行計画	移行方式、移行スケジュール、リスク対策、テスト計画	2-3
6	プロジェクト計画	体制図、スケジュール、開発方法論、品質管理、教育・内製化支援	2-3
7	運用・保守	SLA/SLO、監視、障害対応、運用体制、継続改善	1-2
8	費用	イニシャル/ランニング費用、TCO、費用内訳、価格の考え方	1-2
9	Appendix	追加訴求ポイント、デモアプリ概要・スクリーンショット、制約事項、補足資料	2-3

基本は全体で約20枚。枚数目安は参考値であり、RFPの物量・配点に応じてスケールする。重点項目には傾斜配分する。

章の追加・統合ルール

• RFPが上記にない章（セキュリティ、法令対応等）を要求する場合は章を追加する
• RFPの要求が軽量な場合は関連する章を統合してよい（例: 移行計画をシステム構成に統合）
• Appendix（章9） には本編に収まりきらない追加訴求やデモ内容を配置する。本編の論理的ストーリーを崩さず、かつ差別化につながる補足情報を載せる場

---

分冊方針

基本原則: 分冊しない（Single Volume）

提案書は原則として1冊（Single Volume）で構成する。 分冊はデフォルトではなく、必要に迫られた場合の例外措置である。

MECE原則

提案書全体を通じて MECE（Mutually Exclusive, Collectively Exhaustive） を徹底する:

• Mutually Exclusive（重複排除）: エグゼクティブ・サマリーを除き、同一内容を複数箇所に記載しない。エグゼクティブ・サマリーのみが提案書全体の要約として重複を許容される
• Collectively Exhaustive（漏れなし）: RFP要件チェックリストの全項目が提案書のいずれかのセクションでカバーされていること

分冊が必要になるケース

以下の場合に限り、ユーザーに確認の上で分冊を行う:

1. RFPの明示的指定（最優先）

RFPが分冊を要求している場合はその指定に従う:

• 「技術提案と費用提案を分冊すること」等の明示的指定
• 提出物一覧で分冊が暗示されている場合（例: 技術評価書と価格評価書が別テーブル）

2. コンテキストサイズの超過

AIがスライド設計書を一貫性を保って生成・レビューできるサイズを超える場合:

• 1 Vol あたりの上限目安: 40スライド（Markdown設計書で約6,000行相当）
• 40スライドを超える場合はユーザーに確認の上で分冊を検討する

分冊時の注意事項

• 分冊する場合でも、エグゼクティブ・サマリー以外の重複記述は避ける
• 各Volの内容はMECEとし、Vol間でセクションが重ならないようにする
• クロスリファレンス（「詳細はVol.Xを参照」等）で補完する

---

出力先

成果物	パス	説明
スライド骨子 MD	output/slides/slides.md（分冊時: vol{N}-{topic}/slides.md）	本スキルの主出力
デザイン指示 MD	output/slides/design.md（分冊時: vol{N}-{topic}/design.md）	NanoBanana用のビジュアルデザイン指示（DESIGN.md を継承）
スライド画像	output/slides/slide-{NN}.png（分冊時: vol{N}-{topic}/slide-{NN}.png）	NanoBananaスキルが生成
全体結合 PDF	output/proposal-all.pdf	document-skills プラグインが画像を結合して生成

per-volume design.md と DESIGN.md の関係

• DESIGN.md（プロジェクトルート）: 全ボリューム横断の規約（色・タイポ・コンポーネント・スライドマスター）
• output/slides/vol{N}-{topic}/design.md（ボリューム別）: ボリューム固有のビジュアル指示（各スライドの構図・アイコン・図解スタイル等）

per-volume design.md 生成時は冒頭で DESIGN.md を明示的に参照し、「本書は DESIGN.md を継承する。以下は本ボリューム固有の指示のみ記載する」と宣言する。色・フォント・radius 等の基本トークンを重複記述しない。

デフォルト（単冊）: output/slides/ 直下に骨子・デザイン・画像を配置する。 分冊時: Volume別サブフォルダ（vol{N}-{topic}/）に集約。{topic} は kebab-case。

PDF生成: NanoBananaモードでスライド画像を生成した後、document-skills プラグインを使用してスライド画像を結合した PDF（output/proposal-all.pdf）を自動生成する。

---

出力形式

md（デフォルト）

上記Step 4のフルフォーマットで出力する。スライド制作担当者がそのまま作業に使える詳細度。

outline

簡易アウトライン形式で出力する。構成レビュー用。

# [提案書タイトル]（XX枚）

1. [スライドタイトル] - [メッセージ]
2. [スライドタイトル] - [メッセージ]
3. ...

---

注意事項

• スライドタイトルは顧客目線で価値が伝わる表現にする（技術用語の羅列を避ける）
• スピーカーノートには、スライドに書かない「裏の意図」や「想定質問への回答」も含める
• 提案戦略書が存在しない場合は、まず提案戦略書の作成を推奨する
• チェックリストが存在しない場合は、RFP本紙から必須記載項目を抽出して仮チェックリストを作成する
• org-data の実績（REF-XXX）やサービス（SVC-XXX）を引用する場合は、IDを明記して追跡可能にする
  • ただしスライド本文やスピーカーノートに REF-XXX / SVC-XXX の内部IDそのものは出さず、社名・案件名・サービス正式名称で表現する（追跡用のIDはスライド設計書のコメントに留める）
• ホワイトペーパーを引用する場合は whitepapers/index.md の引用ガイドラインに従う

顧客向け表出禁止の内部用語

以下の ARCADIA 内部用語は顧客向け成果物（slides.md 本文、スピーカーノート、PPTX、画像、PDF、回答シート）には出さない。architecture-policy.md 等の内部ドキュメントから内容を転記する際は必ず言い換える。

内部用語	置換表現の例
ADR / ADR-NNN / 「アーキテクチャ決定記録」	「主要な設計判断」「アーキテクチャ選定の考え方」「技術選定の根拠」
[AUTO] / [AUTO][要確認] マーク	削除（内部ドラフト専用マーク）
REF-XXX / SVC-XXX / TASK-N 等の内部ID	削除または正式名称・一般表現に置換

理由: ADR 等は日本の顧客・現場には馴染みのない用語で、提案書に出るとノイズになる。トレーサビリティのためのID類は内部ドキュメント（output/plan/）内に留め、顧客成果物（output/slides/、output/ 直下の PPTX/PDF/XLSX）には表出させない。