# Cfp Review

> 技術カンファレンスのCFP（Call for Papers）を新規作成・改善・段階レビューする。イベントとの整合、冒頭2〜3行、聴講者価値、実践的根拠、新規性、読みやすさ、提出制約を検証し、採択確率を上げる応募文と具体的な修正案が必要なときに使用する。

- Skill: `nwiizo/cfp-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nwiizo/cfp-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nwiizo/cfp-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nwiizo (https://skillmd.com/u/nwiizo)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nwiizo/cfp-review

---


# CFPの作成と段階レビュー

審査員の第一スクリーニングと、聴講者がセッションを選ぶ場面の両方を想定する。文章の巧さより内容の価値を優先し、流行語や著名技術への親近感だけで加点しない。

## 1. モードを決める

- **作成モード**: イベント情報と話者の知見から、提出可能なタイトル・概要・関連項目を作る。
- **改善モード**: 既存案を評価し、妥当な指摘だけを反映した改稿を作る。
- **レビューモード**: 原文を変更せず、段階評価と具体的な修正案を返す。

ユーザーの依頼からモードが明らかなら確認を挟まない。ファイルが指定されていれば読む。未指定時に既定のファイルを推測せず、会話または現在の作業ディレクトリから対象を特定する。

## 2. イベント情報を確定する

次の情報を集める。

| 項目 | 確認内容 |
|---|---|
| イベント | 名称、目的、テーマ、想定聴衆 |
| 発表枠 | 時間、カテゴリ、受講者レベル、言語 |
| 提出制約 | タイトル・概要の文字数、キーワード数、必須項目 |
| 選考文脈 | 公開された基準、過去2〜3回の採択傾向、隣接イベントの傾向 |
| 発表内容 | タイトル案、主張、事例、失敗、数値、持ち帰り |

現在の募集要項、採択事例、トレンドが判断に影響する場合は、公式情報を優先して確認する。確認できた事実と推論を分ける。不採択案や非公開の選考理由を想像しない。

不足情報を次のように扱う。

- 文字数や発表時間など、提出の有効性または内容量を左右する情報は確認する。
- 非本質的な情報がなくても、明示した仮定の範囲で初稿を作る。
- 実績、失敗、数値、第三者評価は絶対に捏造しない。不足時は概念解説、Blueprint、仮説など、根拠に合うトーク型を選ぶ。

## 3. 作成モード

### 設計文を一つ作る

本文を書く前に、次の一文を埋める。

> [課題]を抱える[対象者]が、[経験・証拠・手法]を通じて[独自の洞察]を学び、[仕事での適用]ができるようになる発表。

対象者、中心課題、主張を一つずつに絞る。発表時間内に扱えない論点を削る。

### 5段階で材料を組み立てる

次の順序を思考の骨格として使う。短い概要で見出しをそのまま並べる必要はない。

1. **要約**: 課題、提案の核、期待効果、なぜ今かを示す。
2. **背景**: 現状、影響、放置リスクを具体化する。
3. **検討**: 選択肢、トレードオフ、制約、選定理由を示す。
4. **提案**: 発表で扱う方法、実例、手順、成果を示す。
5. **発展**: 今後の変化、応用範囲、持続的な価値を示す。

### 冒頭2〜3行を先に書く

最初の数秒で次を伝える。

1. 誰のどの課題を扱うか
2. どの視点、経験、手法で扱うか
3. 聴講後に何を判断または実行できるか、あるいはなぜ今必要か

専門用語を必要最小限にする。数値や成果は、検証できて発表内容の中心である場合だけ使う。

### 本文を完成させる

- イベントの目的との接点を明示する。
- 成功だけでなく、関連する失敗、制約、トレードオフを含める。
- 一般論ではなく、話者固有の経験、具体例、比較、手順、または独自の分析を示す。
- 「何を学べるか」「仕事でどう使えるか」「なぜ今か」に答える。
- トレンド語は実質的な接点があるときだけ使い、独自の価値を併記する。
- 将来予測だけで押し切らず、その予測を支える根拠と不確実性を示す。

### タイトルと提出項目を整える

タイトルで対象、課題、特徴的な方法または成果のうち、重要な二つ以上を伝える。本文にない強い主張や流行語を足さない。カテゴリ、レベル、キーワード、公開可否なども同じトークを指すよう揃える。

作成モードの出力には、少なくとも次を含める。

- 本命タイトル
- 提出用概要
- 指定された追加項目
- 文字数と個数の検証結果
- 仮定または追加すると強くなる未確認情報

## 4. 段階レビュー

前段階の結果を踏まえ、順番に評価する。

### Step 0: 制約と事実の整合

- 必須項目と文字数・個数制限を満たすか
- タイトル、概要、カテゴリ、レベル、キーワードが同じ内容を示すか
- 事例、数値、トレンド、第三者評価を裏づけられるか
- 約束した内容を発表時間内に扱えるか

制約違反や裏づけ不能な主張は、平均スコアに埋もれさせず最優先で指摘する。

### Step 1: 第一印象

タイトルと冒頭2〜3行だけを読み、5秒で次を把握できるか評価する。

1. 発表の目的と中心課題
2. 続きを読みたくなる具体性または意外性
3. 聴講者のメリット
4. イベントおよび現在の文脈との接点

### Step 2: 内容

#### 2-1. イベントとの整合性・聴講者価値

- テーマ、目的、カテゴリに自然に合うか
- 対象者と前提知識が明確か
- 聴講者が得る知見と適用方法が具体的か
- 他の発表と区別できる視点があるか
- イベントの他セッションを補完するか、類似トピックとの重複を新しい視点で超えているか

#### 2-2. 技術的深さ・専門性の根拠

- 実践経験、具体例、比較、検討過程のいずれかがあるか
- 成功だけでなく失敗、制約、トレードオフを扱うか
- 数値やBefore/Afterがある場合、主張と直接関係するか
- 一般論に終わらず、話者が語る理由が伝わるか

数値が不適切なテーマに数値を強要しない。検証済みの具体例や再現可能な方法も根拠として評価する。

#### 2-3. 新規性・タイムリーさ・持続性

- 「なぜ今か」に答えるか
- 流行語の背後に実質的な内容があるか
- 既知の話題に新しい経験、組み合わせ、反証、適用先があるか
- 短期的な話題性と、陳腐化しにくい学びの両方を検討しているか

流行から外れることだけを理由に減点しない。イベントに価値をもたらす独自性や先見性があれば評価する。

#### 2-4. 聴衆への配慮

- 誰に有益かを特定しているか
- 聴講後に何をできるようになるかを示すか
- 難易度、専門用語、前提知識が対象者に合うか
- 異なる役割や経験レベルに価値を誇張していないか

### Step 3: 明確さと構造

- タイトルと本文が一致するか
- 課題から内容、根拠、持ち帰りまで論理がつながるか
- 各段落の役割が一つに絞られているか
- 一文が長すぎず、専門用語を説明しているか
- 書式を外しても重要点が伝わるか

段落3〜4文、一文約40文字は日本語の読みやすさを確認する目安として扱い、機械的な減点基準にはしない。

## 5. フィードバックを書く

各評価軸を1〜5で採点し、根拠を原文に結びつける。

| 点 | 判断 |
|---|---|
| 5 | 卓越。イベントに必須となる価値が明確 |
| 4 | 優良。小さな修正で提出可能 |
| 3 | 良好。重要な欠落または差別化不足がある |
| 2 | 要改善。方向性はあるが大幅な修正が必要 |
| 1 | 弱い。基本的な採択基準を満たさない |

改善点を重要度順に最大3件へ絞り、各件を次の形式で示す。

- **現状**: 問題のある原文または欠落
- **提案**: 置換文、追加すべき事実、削る範囲などの具体策
- **期待効果**: 審査員または聴講者の判断がどう改善するか

「もっと具体的に」「読みやすくする」だけで終えない。原文にない実績や数値を修正案へ作り足さない。

## 6. レビューレポートを出力する

次の順序で簡潔なMarkdownレポートを作る。

1. 総合スコア表: 制約・事実、第一印象、整合性・価値、深さ、新規性、聴衆配慮、明確さ・構造
2. 各評価のスコア、根拠、必要な書き換え案。他セッションとの補完・重複も含める
3. 最も強い点
4. 優先度順の改善点（最大3件）
5. 採択判断: `採択推奨`、`修正を条件に検討`、`不採択` のいずれかと理由
6. 個人的に参加したいか、その理由

内容をスタイルより重視する。建設的かつ具体的に書き、馴染みのあるテーマ、企業、発表者へのバイアスを点検する。