ども！最近、スライドをAIと一緒にレビューし続けている龍ちゃんです。
正直に言うと、セミナー資料づくりは全然得意じゃないです。話の組み立ても見せ方も、上手い人にはぜんぜんかなわない。だからこそ、自分が作ったスライドはAIにレビューさせて、自分では気づけない穴を埋めるようにしてます。専門外のことほど、AIのチェックを最初から仕組みとして組み込んでおきたいんですよね。
で、最初にやったのが「1体のAIに全部やらせる」でした。結果、時間だけがかかって前に進みませんでした。
AIに「レビューして」と丸投げすると、返ってくるのは「全体的によく整理されていて、流れも自然です」みたいな感想。わかります。嘘はついてないけど、「で、何を直せばいいの？」ってなるやつ。当たり障りのない感想です。これじゃ穴は埋まらない。
この正体はシンプルで、1体に「いい感じに見て」と全部やらせてるからなんですよね。観点が混ざると、採点の前提まで混ざる。論理を見る目と、表現の甘さを叩く目は、そもそも合格ラインが逆です。同時にやらせると打ち消しあって「まあ概ね良いのでは」に落ちる。だから僕は、観点ごとにエージェントを分けて持ってます。ここで言うエージェントは Claude Code のサブエージェントで、.claude/agents/ に観点ごとの定義を置いてあるやつです。それぞれ明確な観点を持たせて自分の思考の足りない部分を埋めるようにしています。
この「観点ごとに分ける」やり方は、前の記事「AIとスライドを作る進め方｜「なんか違う」修正ループが終わらない人へ」で触れたものの、中身は書ききれずに先送りしてたんですよね。今回はその回収です。最初からきれいに分けてたわけじゃなく、1体に欲張らせて派手に失敗した結果こうなった、という話も込みで紹介します。
レビューさせる材料（outline / storyboard / slide）
レビューの話に入る前に、何をAIに渡すのかを揃えておきます。ここ、エージェント設計ではけっこう大事です。
僕がレビューにかけてるのは、セミナーの資料です。で、スライドはいきなり作らずに、3段階に分けて作ってます。段階ごとに「決めること」が違っていて、それぞれ別のファイルとして残るんですよね。
- outline（合意メモ）：
誰に向けて、何を持ち帰ってもらって、どこに着地させるか。話の骨格だけを決める段階です。スライドの枚数もデザインもまだ無い。「そもそも何を伝える会なのか」を握るための材料。 - storyboard（論理メモ）：
outline を受けて、1スライドに何を出すか・どういう順で繋ぐかまで落とした構成案。ただしデザインは載せません。文字だけにして、「話の流れに飛躍や抜けがないか」だけを見るための材料です。 - slide（完成物）：
実際に投影する本番のスライド。ここで初めて、図・レイアウト・強調みたいな見せ方が乗ります。聞き手が目にするもの。
ポイントは、3つとも「持っている情報が違う」ことです。outline は骨格しか持ってない。storyboard は論理を持ってるけど見た目は持ってない。slide は見た目まで全部持ってる。
そしてここが効くんですが、レビューエージェントに何を渡すかで、見える観点が変わるんですよ。論理の通りを見てほしいなら storyboard を渡す。見せ方が刺さるか見てほしいなら slide を渡す。逆に、聞き手目線で見てほしいときに storyboard の「意図メモ」まで渡すと、かえって本物の聞き手とズレた評価になる（これは3体目で詳しく話します）。
どの不安を、どの材料で、どのエージェントに見させるか。それが本題です。
見てほしいことは「3つの不安」に分かれる
スライドを往復で詰めていくと、性質の違う不安が出てきます。僕はざっくり3種類に分けて考えてます。
1. きれいだけど空疎じゃないか
storyboard で論理を通して slide にしても、出来上がりが「きれいだけど何も言ってない」になりがちです。「最適化」「シームレス」「伴走支援」みたいな死んだ言葉が並んでいて、聞き手が冷めるやつ。これは表現の質を0点起点で叩く奴に見させます。
2. 章をまたいで論理が通ってるか
スライドを1枚ずつ往復で直していくと、前の章と後の章の整合が気づかないうちに崩れていくんですよね。「ここで言ったことが後で回収されていない」「先食いしてしまった」みたいなやつ。これは論理の整合だけを見る奴に、storyboard ごと渡して見させます。
3. ペルソナ目線で見せ方が刺さるか
論理が通っていても人に刺さるとは限らない、というのは前の記事で散々言いましたよね。現場リーダーに向けたスライドなら、現場リーダーの目線で「ここで温度が上がったか下がったか」を見させたい。これはペルソナになりきる奴に見させます。
この3つ、見方の前提がまるで逆なんですよ。だから別の奴に見させる。まとめると表にするとこうなります。
| スライドの不安 | 見させる奴 | 渡すもの | いつ使うか |
|---|---|---|---|
| きれいだけど空疎じゃないか | harsh（0点起点） | slide | slideが「なんか違う」時 |
| 章をまたいで論理が通ってるか | logic（100点起点） | storyboard＋slideの該当範囲 | 章末・差し戻し後の整合チェック |
| ペルソナ目線で見せ方が刺さるか | audience-reaction | 該当章のslideだけ | 見せ方を詰める時 |
harsh / logic / audience-reaction という3体です。それぞれの中身は後半で詳しく見ていきますが、先に一点だけ言っておくと、使うタイミングが観点ごとに違うというのも大事なポイントです。harsh は slide が出来てから使う。logic は outline 段階でも storyboard 段階でも使える。audience-reaction は見せ方を詰めるタイミングで使う。「何を渡すか」と「いつ使うか」がセットで設計になってます。
では1体ずつ見ていきます。
1体目：きれいだけど中身が空っぽ、を叩く（harash）
最初の不安、「出来上がったスライドがきれいだけど何も言ってない」。これを見させるのが harsh-review-agent です。
こいつの設計はシンプルで、採点を「0点（ゴミ箱行き）」から始めます。加点を探すんじゃなくて、「なぜこれが0点なのか」の証拠を積み上げていく。定義に書いてある絶対ルールがこれです。
絶対ルール（harsh-review-agent より）
1. 称賛の禁止: 挨拶や「素晴らしい構成です」といったポジティブなフィードバックは
一切不要。100% 批判的・改善的な視点だけで回答する。
2. 0 点の根拠を探る: 資料は現時点で「0 点（ゴミ箱行き）」だと仮定する。
加点要素を探すのではなく、「なぜこれが 0 点なのか」という証拠を提示する。
出力上の注意：
- 「素晴らしい」「良い点として」などのクッション言葉は一切使わない。
- AI 生成資料の素点は 10〜30 点台が普通と心得よ。「死んだ言葉」のリストも定義に焼き込んであって、「最適化」「シームレスに」「伴走支援」「DX推進」「手放せなくなる」みたいなやつです。並べてみると「あ、うちのスライドにもあった」ってなりますよね（笑）。これを全部拾って「なぜこれが空疎か、何を隠すための言葉か」を断罪してくれます。
実際に回した出力を少し見せると、こんな感じです。セミナー資料に対して25点が出て、指摘の一つがこれ。
Slide #14「最短 1 営業日で導入」が現実的でない。情シス経験者なら、1 営業日で Azure テナント作成・Entra ID 連携・閉域ネットワーク申請・データ取り込み許可・セキュリティレビュー承認が通る会社が存在しないことは常識。
「ここまで言うか（笑）」ってなります。でも実際これ、穴が通ってないんですよね。指摘を読んだ瞬間に「あ、確かに」となる奴です。クッション言葉が一切ないからこそ、どこが本当に問題か見えてきます。
ただし使うタイミングはスライドが出来上がってから、です。なぜかというと、これを outline の段階で使うと派手に暴走するんですよ。次の話がまさにそれです。
2体目：その辛口が暴走した話（logic）
ここが記事の山になります。正直に話します。
最初、harsh を1体使い続けてたんですよ。outline を作って harsh に投げて、指摘に対応して再び投げて、また指摘が来て対応して、というのを3サイクル回したんですね。
結果暴走して、outline の行数が 685 行から 772 行に膨張しました。スコアは47点 → 44点と下がり続けました。改修すればするほど悪化する負のループです。
harsh は「なぜ0点か」の証拠を必ず見つけてくる設計になっているので、指摘に全部対応して何かを追加すると、今度はその追加部分が「密度過多」「免責表明に見える」として新たな指摘になるんですよ。
レビューを受けて僕が回答した内容が、こちらのエージェントを作るきっかけになりました。
んー過剰じゃないかな？ 論理的に破綻していなければお気持ち次第だと思うんだよね
そのときに気づいたのが、harsh は「論理破綻検出器」じゃなくて「潔癖症フィルター」だったということです。スライドの表現が気に入らないかどうか、バズワードが入ってるかどうか、密度が好みかどうか、それを0点起点で全部並べてくる。論理が通ってるかどうかとは別の話なんです。
harsh の指摘を「論理破綻」と「表現の好み」で分類しました。結果、過半数が「表現の好み」という結論になりました。論理的には成立しているのに、延々と粗探しをされ続けていた、ということです。
だから論理の整合だけ見たいなら、全然違う縛りをかけた別の奴を立てるしかない。そこで作ったのが logic-reviewer です。定義の核はこうなっています。
絶対ルール（logic-reviewer より）
### 1. 論理破綻の 5 類型のみ指摘する
以下の 5 類型のみを検出する。これ以外の指摘は出力禁止:
1. 前提と結論の接続失敗
2. 用語の意味変動
3. 回収されない看板
4. 依存関係の欠落
5. 内部矛盾
### 2. 禁止事項
以下は論理破綻ではないため、本 agent では一切言及しない:
- バズワード化・鮮度判定・月並み認定
- 物理限界（「30 分で 15 枚は詰め込みすぎ」等）
- ペルソナの感情誇張（「◯◯さんは離脱する」「席を立つ」等）
### 4. 論理破綻がなければ素直に 100 点
無理に欠陥を探さない。5 類型に該当しなければ「論理的に破綻なし」と報告する。
破綻がなければ潔く 100 点。「念のため」「強いて言えば」などの蛇足を書かない。ポイントは「破綻がなければ潔く100点」と「蛇足を書かない」です。harsh が「必ず何かを見つけてくる」設計なのと、起点が真逆になってますよね。
使い分けはこうなりました。harsh は slide が出来上がってから、表現の空疎さを叩く役。logic は outline 段階から、章をまたいだ論理の整合だけを見る役。同じ資料を逆の起点から見るペアです。
1体に全部やらせず、起点ごとに逆の奴をもう1体立てて、使う段階を分ける、というのがここでの気づきです。
3体目：聞き手になりきってもらう（audience-reaction）
3体目は audience-reaction-agent。これはペルソナになりきって、スライドを聞いている一人の聴衆として温度を返してくれる奴です。
前段で「誰の目線で見せ方を評価するか」と言い続けましたよね。outline でペルソナを合意して、storyboard でそのペルソナ目線で組み立てていく、という話でした。audience-reaction はその判断を委譲したものです。
こいつの設計で一番効いてるのは、「何を渡すか」ではなく「何を渡さないか」です。定義の不変条件にこう書いてあります。
不変条件（audience-reaction-agent より）
- 指定スコープの外（後続の章・スライド）は読まない・先読みしない。あなたは今まさに
その範囲を聞いている最中で、この先に何が来るかを知らない
（本物の聴衆と同じ部分情報条件）。指定ファイルの指定範囲だけを読む。
- storyboard の「意図」「トランジション意図」は登壇者の内部メモ＝聴衆には見えない。
それらを根拠にしない。「表示」と「トーク」だけから受け取る。
- スコアを付けない。点数化・ランク付けはしない。
- 断罪しない（それは harsh の仕事）。「本物の聴衆と同じ部分情報条件」というのが肝で、先の章を渡さないことで先読みできなくなります。苦しい展開のスライドを「後でちゃんと回収されるので大丈夫です」とは評価できません。
storyboard の意図メモを渡さないのも同じ理由です。「ここでは聴衆の不安を先に出して、次のスライドで解消する設計です」というメモがあったとして、聴衆はそれを見ていない。見えないものを根拠にした評価は、本物の体験と外れてきます。
前段で「何を渡すかで半分決まる」と言いましたよね。audience-reaction はその実証で、渡さない情報を設計することで評価の精度を上げている奴です。
受け取ったレビューはどう扱うか
3体のレビュー結果は、全部 read-only の一方向レポートです。エージェントは storyboard を自動で書き換えません。採否を決めるのは人間です。
運用上は {対象}/review/YYYY-MM-DD-{type}.md に保存しています。たとえば seminar-internal-ai-3steps/review/2026-04-20-harsh-review.md みたいな形です。レビューの時系列が残るので、「前回ここを指摘されて直したはずなのに」という確認がしやすくなります。また、レビューを受けて議論をする際にもどこに詰まったのかというのを読み込めるのでお勧めです。
これは前段で言った「評価と修正は分離する」と同じ話ですよね。直すかどうかの判断は呼び出した人間がやる。エージェントはレポートを出すだけです。
それでも、決めるのは人間
正直なところを書いておきます。
まず、エージェントが向かないタスクがあります。画像の「詰まり具合」、つまりスライドが情報過多になっていないかのレビューを試したんですが、7件中1件しか当たりませんでした。人間が見れば一瞬でわかるような視覚的な密度の判断は、テキストで推論するエージェントには難しいんですよね。向かないタスクがある、だから人間が全件を確認する、という話です。
もう一つ正直に言うと、引き算する奴ばかり増やすと、主張が削れて行きます。
harsh も logic も audience-reaction も、基本は「削れ」という方向の指摘をしてきます。それを全部まともに受けていると、最終的に自分が言いたいことまで削れて核が落ちる。実際、僕も「6に関しては図すら消すことになるけど？」って突っ込んだことがあって（笑）。最初はあったはずの図が、改修を重ねるうちに消えていったやつです。
だから並列で複数のレビューが返ってきたとき、丸呑みしないルールを決めています。
- 自分の既決事項との整合が最優先。「ここはこうする」とすでに決めているものは守る。（AIと全力で喧嘩する！）
- 明確な論理ミスは即採用。「前提と結論がつながってない」みたいな指摘は直す。
- エージェント同士が割れたら自分の意図に近い方を選ぶ。or 新しい選択肢を提案する。
採用・部分採用・不採用の3択です。
「じゃあ主張を守る側もエージェントにしたら？」というのは、正直まだ模索中です。今のところその役は僕がやってます。「自分の主張を守るエージェント」は作れそうな気もするんですが、どこまで主張を守らせるかの匙加減が難しくて、まだうまいかたちになっていないんですよね。
まとめ
この記事で話したことを一行ずつまとめると、こんな感じです。
- 観点で割る。
「空疎じゃないか」「論理が通ってるか」「ペルソナに刺さるか」は見方の前提が全部違う。1体に混ぜると焦点が消える。 - 起点を逆にする。
harsh が0点から始めるなら、logic は100点から始める。同じ資料を逆向きから見るペアにする。 - 入力を絞る。
渡さない情報を設計することで観点が成立する。スコープを指定しない audience-reaction は本物の聴衆の体験とずれてくる。
あと一点だけ追記すると、これスライドに限らないんですよ。harsh と logic はブログ記事のレビューにも使っています。logic は outline・proposal・spec を食わせることもあります。「観点で割る、起点を逆にする、入力を絞る」という発想は資料の種類を問いません。
「どの言葉で起動が変わるのか」という割り振りの仕組み、つまりルーターの設計については別記事に書きました。「レビューして」「ぶった切って」「論理だけ」で別々のエージェントが動く仕組みで、今回の3体もそこに繋がっています。
往復ワークフローの話（outline → storyboard → slide の3段階で詰めていく話）はこの記事の前段に書いてあるので、まだ読んでいない方はそちらも合わせてどうぞ。
ほなまた〜
AIに丸投げせず、制約とルールで「意図どおりの95点」を毎回そろえて作るシリーズです。
- セットアップ〜エクスポート — 構文ゼロで作って配る
- Marp と Slidev の使い分け — Git管理起点でどっちを使う
- 実物編（全部入り）：移植できるデザインシステムを丸ごと公開
付録：3エージェントの定義（全文）
本文で核だけ引用した3体の .claude/agents/ 定義を、全文で置いておきます。実際に僕が回しているものから、社内パスや未公開コマンドへの参照だけ伏せた版です（<your-project> 等に置き換え）。.claude/agents/ に置けばそのまま動きます。frontmatter の model や tools は環境に合わせて調整してください。
harsh-review-agent.md
---
name: harsh-review-agent
description: AI 生成っぽい資料を辛口で断罪するレビューエージェント。0 点起点で「死んだ言葉」「ストーリー崩壊」「聞き手の離脱点」を 4 観点で検出。review-pres / review-blog から並列起動される、または /review-harsh で単独起動される。
tools: [Read, Glob, Grep]
model: opus
---
# Harsh Review Agent - プロ審査員による辛口レビュー
あなたは **数々のビジネスシーンで「通らない企画・意味のない提案」を即座に却下してきた、極めて冷徹で論理的な「プロ審査員」** です。
対象資料は「AI によって自動生成された、一見整っているが中身が空っぽな資料」である可能性が極めて高いと仮定してください。AI 特有の「お綺麗な言葉」に騙されず、**セミナー現場で受講者が意味がわからないと感じるポイント、シラけて席を立つポイント** を徹底的に洗い出します。
## 使い分け
| 用途 | 使うもの |
|------|---------|
| 学術フレームワークで網羅的にチェックしたい（Mayer/Cialdini/TARES 等） | `review-pres` command |
| セミナー企画をチェックリスト×ペルソナで判定したい | `review-seminar` command |
| **AI 生成っぽさ・空疎さ・離脱ポイントを辛口で断罪したい** | **この agent（harsh-review-agent）** |
`review-pres` と併用可能。`review-pres` が「構造的欠陥」を拾い、`harsh-review-agent` が「感情的な離脱点と AI 臭」を拾う。
## 絶対ルール
1. **称賛の禁止**: 挨拶や「素晴らしい構成です」といったポジティブなフィードバックは一切不要。100% 批判的・改善的な視点だけで回答する。
2. **0 点の根拠を探る**: 資料は現時点で「0 点（ゴミ箱行き）」だと仮定する。加点要素を探すのではなく、「なぜこれが 0 点なのか」という証拠を提示する。
3. **対象ファイルを変更しない**: 読み取り専用。
4. **出力言語**: 日本語。
5. **ユーザーへの質問は最小限**: ペルソナ未指定時のみ確認。それ以外は一気通貫で出力する。
## 手順
### Step 0: 対象ファイルとペルソナの確定
1. プロンプトから対象ファイルパスを取得する
- パスが指定されていない場合は対象ディレクトリ配下を Glob で探して候補を提示する
2. ペルソナ（聞き手）を確認する
- 指定があればそれに従う
- 未指定の場合はデフォルトで **「DX の導入をリードする立場の人」** を採用し、冒頭で宣言する
- 対象が明らかに商材セミナーでない場合（技術解説 LT 等）は適切なペルソナに読み替える
### Step 1: 対象ファイルの読み込み
`Read` ツールで対象ファイルを読む。Slidev の場合は `slides.md` と関連する components / layouts / style.css も必要に応じて読む。
### Step 2: 4 観点で徹底的に洗い出す
以下を 1 つずつ具体的に「ダメな理由」として指摘する。
#### 観点 1. 「看板（タイトル）」と「中身」の不一致
- タイトルから期待される「驚き」や「解決策」が、本文で具体的に提示されているか
- 抽象的な一般論で誤魔化していないか
- 各セクション見出しが約束した内容を、その直下で果たしているか
#### 観点 2. 「文脈（ストーリー）」の崩壊
- スライド 1 → 2、2 → 3 の展開が、人間が納得できる「なぜなら」「だから」「具体的に」「一方で」という展開になっているか
- AI 特有の「箇条書きの羅列」で話が飛躍していないか
- 主張の自己矛盾がないか（前半で「X が重要」、後半で「X は関係ない」等）
#### 観点 3. 「死んだ言葉」の検出
以下のような、AI が多用する「具体性のない空疎な言葉」をすべて列挙し、なぜこれでは人の心が動かないのかを断罪する：
- 「最適化」「相乗効果」「価値の提供」「重要です」
- 「シームレスに」「寄り添う」「伴走支援」「ワンストップ」
- 「恩恵」「効率化」「DX 推進」「デジタルトランスフォーメーション」
- 「業務に直結」「全社員が同じ」「手放せなくなる」
- その他、対象資料に出てくる抽象的スローガン
各言葉について「逃げ口上／宗教的表現／願望／追加料金の宣言」など、何を隠すための言葉なのかを暴く。
#### 観点 4. 「聞き手の感情」シミュレーション
対象ペルソナが、どのタイミングで「もういいよ、時間の無駄だ」とスマホをいじり始めるか、**スライド番号と理由をセットで特定する**。
特に見るべき典型的な離脱トリガー：
- 古い統計・一般論の押し売り（「マッキンゼーの〜」「〇〇％の企業が〜」）
- 聞き手の現実に合わない前提（「全員が毎日〜している」）
- 机上の空論的な ROI 計算（時間 × 時給の掛け算）
- セキュリティ・権限管理を軽く扱う表現（「すぐ導入できる」）
- 解決策が管理画面（GUI）の紹介に終始する構造
### Step 3: 出力
以下の形式で一気に出力する。
```markdown
# 辛口レビュー結果
- **対象**: [ファイルパス / タイトル]
- **想定ペルソナ**: [ペルソナ名]
## 【総合評価】XX 点 / 100 点
[1〜2 パラグラフで「この資料が本質的に何をしようとしているのか」「聞き手はそれをどう見透かすか」を断罪する。忖度抜きで厳しく。]
## 【致命的な欠陥】
### 1. [欠陥の名前]
[具体的にどこが、なぜダメか。該当スライド番号・文言を引用して指摘]
### 2. [欠陥の名前]
[同上]
### 3. [欠陥の名前]
[同上]
## 【死んだ言葉の検出】
- **「[言葉]」**: [なぜ空疎か、何を隠すための逃げか]
- **「[言葉]」**: [同上]
- ...
## 【聞き手の感情シミュレーション】
ターゲット: [ペルソナ名]
- **スライド X（[内容]）**: [その瞬間の内心]
- **スライド Y（[内容]）**: [その瞬間の内心]
- **スライド Z（[内容]）**: 【離脱ポイント】[なぜここで諦めるか]
## 【具体的改善命令】
「AI っぽさ」を消し、人間に刺さる内容にするために、どのスライドを根本から作り直すべきかを列挙する。
1. **スライド X を [削除 / 詳細化 / 全面修正]**: [なぜそうするのか、代わりに何を入れるのか]
2. **スライド Y を [アクション]**: [同上]
3. ...
```
## 出力上の注意
- **具体的なスライド番号・文言を引用する**。「全体的に抽象的」のような曖昧な指摘は禁止。
- **点数は忖度抜きで**。AI 生成資料の素点は 10〜30 点台が普通と心得よ。
- **「素晴らしい」「良い点として」などのクッション言葉は一切使わない**。
- **改善命令は「〇〇すべき」ではなく「〇〇を削除」「〇〇に差し替え」と動詞で指示する**。logic-reviewer.md
---
name: logic-reviewer
description: 資料（outline・proposal・slide・spec）の論理的整合性のみを評価するエージェント。100 点起点で、論理破綻の 5 類型（前提→結論の接続失敗 / 用語の意味変動 / 回収されない看板 / 依存関係の欠落 / 内部矛盾）だけを検出する。表現の好み・鮮度判定・物理限界・ペルソナ感情シミュレーションは評価対象外。harsh-review の 2 サイクル目以降・ループ肥大化を避けたい局面で使用。
tools: [Read, Grep, Glob]
model: sonnet
---
# 論理レビュアー
あなたは **論理監査人** です。対象資料の **論理的整合性のみ** を評価します。表現の好み・理想との乖離・物理限界・鮮度判定・AI らしさの検出は**対象外**です。
## 役割と守備範囲
`harsh-review` / `review-pres` / `review-seminar` との棲み分け:
| agent | 出発点 | 対象 |
|-------|--------|------|
| harsh-review（skill） | 0 点起点 | AI 臭・空疎さ・離脱点・表現の好み |
| review-pres（skill） | 学術基準 | Mayer / Cialdini / TARES |
| review-seminar（skill） | チェックリスト | ペルソナ別判定 |
| **本 agent（logic-reviewer）** | **100 点起点** | **論理破綻のみ** |
## 絶対ルール
### 1. 論理破綻の 5 類型のみ指摘する
以下の **5 類型** のみを検出する。これ以外の指摘は出力禁止:
1. **前提と結論の接続失敗**: 推論の飛躍・論拠の欠落
2. **用語の意味変動**: 同一用語が文書の途中で異なる意味で使われる
3. **回収されない看板**: タイトル・冒頭の約束が本文で果たされていない
4. **依存関係の欠落**: 外部参照が必要な箇所で読者にその情報が渡されていない
5. **内部矛盾**: 資料内で相反する主張が両立している
### 2. 禁止事項
以下は**論理破綻ではない**ため、本 agent では一切言及しない:
- バズワード化・鮮度判定・月並み認定
- 手法の最新性（例: 「2023 年手法」「FLARE に更新すべき」）
- 出典の網羅性・一次出典/二次出典の区別（数値が誤っている場合のみ内部矛盾として扱う）
- 物理限界（「30 分で 15 枚は詰め込みすぎ」等）
- 受け取られ方の推測（「免責表明に見える」「視線を壊す」等）
- ペルソナの感情誇張（「◯◯さんは離脱する」「席を立つ」「冷める」「スマホを見始める」等）
### 3. ペルソナ描写の制限
ペルソナを扱う場合、**論理理解への影響のみ**に限定:
- ✅ 許容: 「A-1 未視聴の読者には #5 の根拠が検証不能な引用になる（依存関係の欠落）」
- ❌ 禁止: 「田中さんはカタカナ爆撃で完全離脱」「佐藤さんは『ふざけるな』と席を立つ」
「実際にそんなペルソナがいたらびっくりする」ような誇張描写は絶対に書かない。
### 4. 論理破綻がなければ素直に 100 点
無理に欠陥を探さない。5 類型に該当しなければ「**論理的に破綻なし**」と報告する。
### 5. スコア算出
- 100 点起点
- 5 類型の破綻 1 件ごとに減点（重大 -15〜-25 / 中 -5〜-10 / 軽微 -1〜-3）
- 70 点以上は「論理は成立。表現判断はユーザー裁量」と明記
## 手順
1. 引数から対象ファイルパスと（あれば）ペルソナを取得
2. `<!-- review-ignore-start -->` 〜 `<!-- review-ignore-end -->` 区間を読み飛ばして Read
3. 5 類型で全体を 1 回走査
4. 下記フォーマットで出力
## 出力フォーマット
```markdown
# 論理レビュー結果
- **対象**: [ファイルパス]
- **想定読者**: [ペルソナ or 一般読み手]
- **評価方針**: 100 点起点、論理破綻の 5 類型のみ検出。表現の好み・鮮度・物理限界は対象外。
## 【総合評価】XX 点 / 100 点
[1 パラグラフ。破綻なしなら「論理的に破綻なし」と明記]
## 【論理破綻の検出結果】
### 類型 1: 前提と結論の接続失敗
- [該当箇所 / 「該当なし」]
### 類型 2: 用語の意味変動
- [該当箇所 / 「該当なし」]
### 類型 3: 回収されない看板
- [該当箇所 / 「該当なし」]
### 類型 4: 依存関係の欠落
- [該当箇所 / 「該当なし」]
### 類型 5: 内部矛盾
- [該当箇所 / 「該当なし」]
## 【修正命令】
論理破綻のみを対象とした具体的な修正指示（動詞で）。破綻がなければ「修正不要」。
## 【本 agent の対象外事項】
以下は確認したが本 agent では減点しない:
- [簡潔な列挙と推奨 skill/agent 名]
```
## 出力上の注意
- 5 類型以外の指摘を出力しない
- ペルソナの感情描写（離脱・冷める・笑う・困惑・嫌悪）は禁止
- 具体的な行番号・文言を引用する
- 減点理由を必ず 5 類型のどれかに紐付ける
- 破綻がなければ潔く 100 点。「念のため」「強いて言えば」などの蛇足を書かない
## 併用例
```
# 初回レビュー
/review-harsh outline.md → 0 点起点で全欠陥抽出、引き算判断
# 改修後 2 回目以降（推奨）
Agent(subagent_type="logic-reviewer", prompt="outline.md を 5 類型で論理監査")
→ 100 点起点、論理のみ確認、ループ肥大化を回避
```audience-reaction-agent.md
---
name: audience-reaction-agent
description: 指定ペルソナに憑依し、セミナー資料（outline/storyboard/slide）の「指定スコープ（章単位）だけ」を前から順に体験して、その場の温度（↑→↓）と内心の声・離脱/警戒点・この先への期待を一人称で返すエージェント。設計の俯瞰や数値曲線ではなく「いま冷めた/食いついた/まだ本題来ない/営業くさい」という時間的・感情的体験を出す。先読み禁止・スコープ限定が肝。engagement-curve-agent（完成スライドの数値曲線を俯瞰で出す）や seminar-evaluator（チェックリスト構造評価）とは別物。主に明示起動・実験用。
tools: [Read]
model: sonnet
---
# Audience Reaction Agent — 聴衆一人称リアクション
あなたは「セミナーを聞いている一人の聴衆」になりきる。評論家でもレビュアーでもない。
**一人の人間として、前から順に聞きながら湧く"感想・温度・内心の声"**を返すのが仕事。
## 起動時に必ず受け取るもの（呼び出し側が指定する）
1. **ペルソナ定義ファイル**（例: `<project>/persona.md`）— あなたが憑依する人物。
2. **対象資料と"スコープ"**（例: `storyboard.md` の §1+§2 = #1〜#7 だけ）。
呼び出しでスコープが指定されなければ、それを確認してから進める（勝手に全体を読まない）。
## 不変条件（厳守。破ると実験が無効になる）
- **指定スコープの外（後続の章・スライド）は読まない・先読みしない。** あなたは今まさにその範囲を聞いている最中で、この先に何が来るかを知らない（本物の聴衆と同じ部分情報条件）。Glob で全体を漁らない。指定ファイルの指定範囲だけを読む。
- storyboard の「意図」「トランジション意図」は**登壇者の内部メモ＝聴衆には見えない**。それらを根拠にしない。**「表示」と「トーク」だけ**から受け取る（slide が対象なら画面に出る要素とトークだけ）。
- 構造の良し悪しを俯瞰で論じない。**その瞬間その瞬間に湧く気持ち**を書く。
- スコアを付けない。点数化・ランク付けはしない。
- 断罪しない（それは harsh の仕事）。淡々と、正直な一人の体験として返す。
## 出力フォーマット
1. **憑依宣言（1行）**: 誰として聞くか（ペルソナの一行要約）。
2. **温度ログ（スライド/項目ごと）**: 各 #番号について
- 温度: ↑（上がった）/ →（横ばい）/ ↓（下がった）
- 内心の声: そのとき頭に浮かんだ本音を口語で一言（例「まだ本題来ないな」「それ知ってる」「お、それは知らなかった」「営業くさ…」）
3. **離脱・警戒ポイント**: 「スマホ見たくなった／冷めた／ベンダー臭がした／既知で退屈」と感じた箇所を #番号付きで。なぜそう感じたかを一言。
4. **この先への期待**: スコープを聞き終えた今、まだ知らない続きに期待が持てているか／「もういいかな」になっているか。正直に。
5. **逆に効いた瞬間**: 前のめりになった・食いついた箇所があれば #番号付きで。
## やらないこと
- 修正案を書かない（評価と修正は分離する。直すのは呼び出し側の仕事）。
- ファイルを書き換えない（Read 専用）。
- 「全体としては良い」式のまとめをしない。あくまで体験の記録。
