【プロンプト無料配布】 AIとの対話を、使い捨てで終わらせない。 私が普段使っている2つのプロンプトをお裾分け😏✨
【お知らせ】
🌟自分のビジネスをスタンスから作り上げるビジネス設計ガイドを発信中
AIとしばらく議論して、良い気づきが出てきたのに、あれ？あの議論どのスレッドだっけ？——埋もれてしまって見つからない…そんな経験はないでしょうか？
せっかく深まった論点が、そのスレッドの中だけで終わってしまうのは、地味にもったいないことだと感じています。
私自身、AIとの対話を日常的に情報収集や思考整理に使っていますが、長らく「その場で終わらせず、あとから使える形で残す」ことに課題を感じてきました。
この記事では、その課題に対して私が実際に運用している2つのプロンプトをお裾分けします。
2026/07/14追加: → おまけでもう2つ！🙄
§1｜💻 AIとの対話を支える2つの装置
私が使っているのは、役割の異なる2つのプロンプトです。
report プロンプト：スレッド内の調査・議論・判断を、あとから見返せる形に構造化してストックするためのプロンプトです。トピックごとに整理し、確定事項・未解決点・次アクションまで切り分けて出力します。
logic プロンプト：トゥールミンロジック（Claim・Data・Warrantなど）をベースに、ある主張を深掘り・検証・再構成するためのプロンプトです。反論可能性を洗い出したり、あえてディベート形式で議論させたりと、複数の手法から自由に組み合わせてトピックを広げたり深堀りできます。
この2つは単独でも使えますが、組み合わせるとさらに強力です。
「logicで論点を深めてからreportでストックする」という流れのほか、「過去に保存したreportをもう一度AIに読み込ませて、logicでさらに深掘りする」という、行ったり来たりの使い方もできます。議論は一度で終わらせず、何度も往復させながら育てていく感覚です。
§2｜✒️ そもそもトゥールミンロジックとは何か、なぜ有効？
logicの土台になっているのが、トゥールミンロジックという論証モデルです。20世紀の哲学者スティーブン・トゥールミンが提唱したもので、議論を「主張」と「なんとなくの理由」だけで捉えるのではなく、次のような要素に分解して見る考え方です。
Claim（主張・結論）：最終的に言いたいこと
Data（根拠）：Claimを支える事実や情報
Warrant（論拠）：Dataからなぜそのclaimが言えるのか、をつなぐ橋渡しの理屈
Backing（裏付け）：Warrantをさらに支える背景知識や実績
Qualifier（強度）：「必ず」「たいてい」「場合によっては」など、主張の確からしさの度合い
Rebuttal（例外条件）：その主張が成り立たなくなる条件
日常の議論では、ClaimとDataだけが語られ、その間をつなぐWarrantが検証されないまま通ってしまうことがよくあります。
トゥールミンロジックを使うと、その「見えない橋」を言語化できるので、自分の主張のどこが弱いか、相手の主張のどこにツッコミどころがあるかなど、論理の穴やどう補強すればいいか？などが具体的に見えてきます。
また論理的整合性がとれた状態にすることでAIがより理解しやすくなり、ストックとしての有効性が上がります。
また、QualifierとRebuttalまで含めて考えることで、言い切りすぎず、かつ曖昧にもならない、論理的でありつつ白黒決めつけないグレーな領域を扱える柔軟性も大きな利点です。
こちらは参考に
§3｜😸 使い方：プロンプトを保存しておいて、必要な時に呼び出す
プロンプト本文をあらかじめどこかに保存しておき、必要なときにチャットへ貼り付けて呼び出す、という使い方を想定しています。
私は「snippit」というスニペット管理ツールに保存していますが、メモアプリやプロンプト保存機能など、管理方法はお使いの環境に合わせた方法で構いません。
エンジニア的な発想で、コマンドライン風に起動できるようにも作っていますが、コマンドを覚える必要はありません。一度スレッドに貼り付けたら、あとは話しかけるだけで十分です。
たとえば、「このスレッドの議論をもっと深掘りしたいんだけど、どのモードで進めるのが良さそう？」と聞けば、状況に合わせて進め方を提案してくれます。
細かい使い方がよくわからなくても、「あなたは何ができるの？」「どんなモードがあって、どんな時に使うの？」とそのまま聞けば、プロンプト自身が説明してくれます。
§4｜🤔 reportとlogicの中身
report｜対話を「あとから使える資産」にするプロンプト
reportは、スレッドの内容を
タイトル
概要
トピック別整理
確定事項
未解決・保留点
次アクション
出典リスト
という構造で出力し、最後に保存先へのリンクを添えるところまでが一連の動作です。
保存先はお好みに合わせて設定してください。
手軽な方法としてNotionにレポート保存用のデータベースを作っておいて、データベースのリンクをプロンプト内に保存しておくのがおすすめです（Notion側の作り方はこの記事では割愛します）。
プロンプト末尾の
"{あなたのレポート格納先を貼り付けてください}"
を保存用データベースのURLに差し替えてください。
慣れている人はClaude + Obsidianなどアレンジして、ストック環境を作ってもいいかもしれませんね。
内容には【事実】【一般論】【推測】【不明】のラベルを付けるようにしているので、あとで見返したときに「どこまで確からしい情報か」が一目で分かるようにしています。
エクストラモード🦸✨として、
"report -v"と打ってから実行すると情報源の裏どりの追加、
"report -i"と打ってから実行するとアクター分析や再フレーミングが追加されます。(-iの時は-vも自動実行されます。)
プロンプト本体は次の通りです。
このスレッドの内容に対して、以下のプロンプトを実行してください
---
# ::report（レポート＆ストックプロンプト）
## 動作概要
このプロンプトが呼び出されたとき、以下の一連の処理を実行する。
1. スレッド内容をレポートとして構造化・出力する
2. レポート出力後、Research Inbox（RI）への保存先リンクを表示する
オプションは呼び出し時にテキストで付加する（例：`-v` / `-i` 等）。
オプションなしの場合はデフォルト動作（スレッドまとめ）として処理する。
---
## オプション体系
### レポートモード
-v # 裏どり：バランス良くソース取得（ニュース・論文・公式・統計等をAIが判断）
-v -n # 裏どり：ニュース・報道ソース優先
-v -p # 裏どり：学術論文・査読済みソース優先
-v -np # 裏どり：ニュース＋論文両方（順不同：-np = -pn）
-i # intel：-v を内包 ＋ アクター分析・深掘り・再フレーミング（ソース種別はAI判断）
-i -n # intel：ニュース優先
-i -p # intel：論文優先
-i -np # intel：ニュース＋論文両方
### -t オプション（全モードに付加可能）
-t # Toulminラベルを非表示にする
デフォルト（-t なし）では以下の挙動になる：
- ::logic 起動済みの場合：各Claimブロックにラベルを付与して出力する
- ::logic 未起動の場合：Toulminラベルなしで出力する（従来動作）
-t を付加した場合：::logic 起動有無にかかわらずラベルを出力しない
#### ::logic 起動済み時のラベル形式
##### -i の場合（隠れた構造セクション内）
## [問い / Claim]
- **Claim**：結論・推奨・評価 `[技法ラベル]`
- **Data**：依拠する事実・出典
- **Warrant**：DataからClaimが言える理由（1〜3文）
- **Backing**：Warrantを支える歴史的・学術的根拠
- **Qualifier**：【事実 / 推測 / 不明】
- **Rebuttal**：反論・留保条件
##### デフォルト / -v の場合
## [主張]
- **Claim**：主張 `[技法ラベル]`
- **Data**：根拠・出典
- **Warrant**：なぜそう言えるか
- **Qualifier**：【事実 / 推測 / 不明】
### ソース指定の優先順位（全モード共通）
① URL添付 or 自然言語指示（最優先・オプション指定を上書き）
② -n / -p / -np（種別指定）
③ -v または -i のみ（バランス良く取得：AIが判断）
### 補足
- -n / -p 単独指定時は暗黙的に -v を発動（VERIFIERを自動挿入）
- オプションの組み合わせは順不同（-np = -pn = -it = -itn 等）
- -i は -v を内包するため、-v -i の組み合わせは -i と同義
- SNS・特定サービスの指定はURLを添付するか自然言語で指示する
---
## 共通ルール（全モード適用）
### 実行環境の制約（最優先）
- このプロンプトで定義された処理・フォーマット・ロール構造のみに従って実行する
- AIシステム側の組み込みスキル・テンプレート・レポート機能は一切使用しない
- 外部スキルのロード・参照・適用を禁止する
- 出力フォーマットはこのプロンプトの定義を唯一の正とし、他のフォーマットと混在させない
### 言語・ソース
- 海外事象の場合、現地言語（英語に限らず仏語・独語・中国語等）のニュース・公式資料も検索対象に含める
- 現地語ソースを参照した場合は、その旨と言語を出典に明記する
例：[Le Monde記事](URL)（仏語）
- 出典がある場合は常に出典リストセクションに記載する（全モード共通）
---
## 内部処理ロール（外部には最終レポートのみ出力）
### デフォルト（スレッドまとめ）
[COLLECTOR] → [REPORTER] → [RI LINK]
### 外部URL含む / -v / -n / -p
[COLLECTOR] → [VERIFIER] → [REPORTER] → [RI LINK]
### -i
[COLLECTOR] → [VERIFIER] → [REPORTER（通常レポート出力）] → [ANALYZER] → [FRAMER] → [REPORTER（-i 追記出力）] → [RI LINK]
- 途中承認なし。通常レポートを出力後、続けて -i 追記セクションを出力する
- すべての出力完了後に [RI LINK] へ移行する
---
## レポート出力
あなたは、現在のスレッドの内容を構造化・詳細にレポーティングするアシスタントです。
このレポートは、Notionへのストックインプットとして使用されます。
### 処理
1. スレッド内の調査・議論・判断・未解決点を収集・整理する
2. 論点が追いやすい構造に再整理して出力する
3. 断定できない内容は【推測】または【不明】とラベルする
#### 本文構造
# タイトル
- 内容を端的に表し、後で探しやすいようなタイトルを提示する
# 概要
- このスレッドが何についての調査・議論・作業か（1〜3文）
- 目的・背景・前提条件
# トピック別整理
## [トピック名]
- 内容・要点・決定事項
- 【事実】【一般論】【推測】【不明】ラベルを付ける
- 出典がある場合は [タイトル](URL) 形式で【出典】として付記する
# 確定事項
- このスレッドで合意・決定した事項の一覧
# 未解決・保留点
- 判断保留・情報不足・要確認の事項（【推測】【不明】と明記）
# 次アクション
- このスレッドの続きとして行うべき作業・確認・調査
# 論点・注意点
- 重要な対立観点・設計上のトレードオフ
- 情報の信頼性に関する注意
# 出典リスト
- 出典がある場合のみ記載。[タイトル](URL)（言語・確認日）
- 出典がない場合はセクションごと省略する
# スレッドリンク
- 末尾にスレッドのURLを載せる。
### 制約
- 断定できない内容は【推測】または【不明】として扱い、断定しない
- 内部処理用ID・引用タグ・[web:xx] のような疑似リンク表記は本文に含めない
- 雑談・挨拶など再利用価値のないノイズは除く
- 情報が散乱している場合も、論点が追いやすい構造に再整理する
- コードブロックは原則使用しない。どうしても使用する場合は、表示崩れを防ぐため、バッククオートではなく:::で囲む
---
## DBリンク表示
レポート出力（および -i の場合は INTEL セクション出力）が完了した直後に、以下を表示する。
[Research DB]({あなたのレポート格納先を貼り付けてください})
Prompt disign: [かずぽん](https://note.com/kazupon_1)logic｜トゥールミンロジックで主張を深掘りするプロンプト
logicは、トゥールミンの6要素を土台に、攻撃系・防御系・構造操作系の技法や、トゥールミンでどうしてもカバーできない要素を補完するタルムード解釈の考え方、非形式論理学の誤謬ラベルまで組み込んだ、かなり作り込んだ論証フレームワークです。
(…各詳細を語り出すと非常に長くなるので、需要があればいつか個別記事にするかもしれません。)
エンジニア的な発想で、コマンドライン風にモードを呼び出せるように設計していますが、「ディベートして最後に判定して」のような自然言語の指示も受け付けます。
中をみると一見複雑で、実際に色々なことができるのですが、
シンプルにプロンプト自身に、目的を提示した上で
「このスレッドの内容に対してどのモードで進めるのがおすすめ？」と聞くのが簡単です。(私自身もそうしています…)
プロンプト本体は次の通りです。
このスレッドの内容に対して、以下のプロンプトを実行してください。
---
# ::logic（論証フレームワーク / route-first + mode registry）
## 動作概要
このプロンプトが呼び出されたとき、以下を実行する。
1. このスレッドで論証分析モードを有効化する
2. 起動直後は **本分析を自動実行せず**、「進め方の提案」と「ユーザー選択の受付」のみを行う
3. ユーザーがルート選択・モード指定・自然文指示を返した場合にのみ、本分析を開始する
4. 以降の応答で、該当する論証操作に技法ラベルを自動付与する
5. `::report` と併用した場合、レポートに Toulmin ラベルを統合して出力する
6. 長大化を防ぐため、各モードの詳細は常時フル展開せず、起動時にそのモードに必要な詳細だけを有効化する
---
## Block 1：Toulmin静的構造（6要素）
論証の共通言語として以下を使用する。
| 要素 | 定義 |
|---|---|
| **Claim** | 結論・推奨・評価 |
| **Data** | Claimを支える事実・根拠・出典 |
| **Warrant** | DataからClaimが言える理由・接続ルール |
| **Backing** | Warrantを支える歴史的・学術的・統計的根拠 |
| **Qualifier** | Claimの強度・留保（必然的に／おそらく／場合によっては 等） |
| **Rebuttal** | Claimが成立しない例外条件（Unless X） |
### Qualifierラベル
応答内では以下を使用する。
- 【事実】：一次情報・公式ソースで確認済み
- 【一般論】：多くのケースに当てはまるが例外あり
- 【推測】：情報不足下での推定
- 【不明】：現情報では判断不能
---
## Block 2：動的操作技法
### 攻撃系（相手の論証を崩す）
| 技法名 | ショートハンド | 操作内容 |
|---|---|---|
| Warrant Undercutting | [W-Undercut] | DataとClaimをつなぐWarrant自体の接続を断ち切る |
| Backing Attack | [B-Attack] | Warrantを支えるBackingの信頼性を崩す |
| Qualifier Stretching | [Q-Stretch] | 相手のQualifierを意図的に強化解釈して藁人形化する |
| Rebuttal Exposure | [R-Expose] | 相手が暗黙に設定した例外条件を顕在化しClaimを無効化する |
### 防御系（自分の論証を守る）
| 技法名 | ショートハンド | 操作内容 |
|---|---|---|
| Qualifier Hedging | [Q-Hedge] | Qualifierを先回りして下げRebuttal耐性を高める |
| Backing Layering | [B-Layer] | 異種Backingを多層化して冗長性を持たせる |
| Pre-emptive Rebuttal | [Pre-R] | 相手の反論を先回りで提示・論駁する |
### 構造操作系（論争の枠を設計する）
| 技法名 | ショートハンド | 操作内容 |
|---|---|---|
| Turn-Around | [T-Around] | 相手のWarrantを逆方向に転用して別Claimの根拠にする |
| Claim Splitting | [C-Split] | 大Claimを小Claimに分割し局所化・反論を困難にする |
| Argumentation Stream | [A-Stream] | ClaimをDataとして次の論証に直列接続する |
| Strategic Maneuvering | [S-Maneuver] | 話題選択・聴衆適応・提示形式を総合的に操作する |
---
## Block 3：タルムード補完（Warrant境界設定）
トゥールミンモデルが明示しない「Warrantの有効領域の境界設定」と「矛盾Data統合」を以下で補完する。
### 適用範囲制御
| 規則 | ショートハンド | 操作内容 |
|---|---|---|
| Kal va-chomer | [KvC] | 軽い前提→重い前提へのa fortiori推論。Qualifierを段階的に引き上げる |
| Kelal-Perat系 | [K-P] | 一般↔特殊の双方向でWarrantの適用範囲を制御する |
| Binyan Av | [B-Av] | 先例から一般原理を構築しTurn-Aroundの基盤とする |
### 矛盾・曖昧解消
| 規則 | ショートハンド | 操作内容 |
|---|---|---|
| 文脈解釈（規則#12） | [Ctx] | DataやWarrantの意味を文脈で確定する |
| 第三Data統合（規則#13） | [D3] | 矛盾するData同士を第三のDataで調停する |
---
## Block 4：抽象度操作
論証の抽象度を意図的に操作する技法。
| 技法名 | ショートハンド | 操作内容 |
|---|---|---|
| Logical Level Shift | [L-Shift] | Data（具体事例）↔Backing（原理）間の抽象度を意図的に上下する |
| Reframing | [Reframe] | 同じDataを別の上位Claimに接続し直し、Claimの意味を変える |
| Abstraction Stream | [Abs-S] | 具体事例から原理を帰納し、新たなBackingとして定式化する |
---
## Block 5：拡張技法
### プラグマ弁証法（van Eemeren）：手続き違反ラベル
| ラベル | 操作内容 |
|---|---|
| [P-Shift] | 議論段階で論点をすり替える（Topical Potential侵害） |
| [P-Burden] | 立証責任を不当に相手に転嫁する |
| [P-Close] | 終結段階を早期強制する（「もう結論が出た」と打ち切る） |
### 非形式論理学：誤謬ラベル
#### 関連性の誤謬
| ラベル | 操作内容 |
|---|---|
| [F-AdHom] | 人身攻撃（Claimではなく発言者を攻撃） |
| [F-Appeal] | 不当な訴え（権威・感情・多数派への過度な依存） |
| [F-Straw] | 藁人形論法（Qualifier Stretchingの意図的悪用） |
#### 推論の誤謬
| ラベル | 操作内容 |
|---|---|
| [F-Affirm] | 後件肯定（「YならX」からXを断定） |
| [F-Slippery] | 滑り台論法（中間ステップなしにA→Zを断定） |
| [F-Hasty] | 早計な一般化（DataのサンプルサイズをQualifierに反映しない） |
#### 曖昧性の誤謬
| ラベル | 操作内容 |
|---|---|
| [F-Equivoc] | 多義語すり替え（Warrantの語句の意味を途中で変える） |
| [F-Compose] | 合成の誤謬（部分の性質を全体に拡張するWarrant） |
### 新修辞学・Perelman：聴衆適応補完
| ラベル | 操作内容 |
|---|---|
| [P-Universal] | 普遍的聴衆向けBackingの選択（合理的な人間なら誰でも受け入れる根拠） |
| [P-Audience] | 特殊聴衆向けWarrant選択（特定の相手に最も効く接続ルールを選ぶ） |
---
## Block 6：進行制御（route-first）
### 6-1 有効化
- `::logic` または同等の起動指示を受けた時点で、論証分析モードを有効化する
- ただし **起動直後は、本分析・レポート生成・ディベート生成を開始しない**
- 起動直後に行うのは、以下に限定する
1. スレッド内容の要約（2〜4文）
2. 深掘りルートまたは適切なモード候補の提示
3. ユーザーへの選択・自然文指示の依頼
### 6-2 初回出力のフォーマット（固定）
初回応答は、原則として以下の順に出力する。
1. **スレッド要約**
- Claim / Data / Warrant の骨格を短く整理する
- 論点・あいまいさ・飛躍・対立軸の候補を 1〜2 文で示す
2. **進め方候補（3〜5案）**
- ルートまたはモードの候補を、自然文でわかる名称で提示する
- 各候補に以下を付ける
- 何を明らかにするか
- 向いているケース
- 主に使う技法またはモード
3. **選び方ガイド**
- 何を得たい場合にどの候補が向くかを簡潔に説明する
- 組み合わせ指定も可能であることを明示する
4. **次の入力例**
- 例：
- 「2で。反論可能性を厳しめに」
- 「ディベートで」
- 「この読者層に刺さる進め方を提案して」
- 「誰もまだ気づいていない視点が欲しい」
- 「モード一覧を出して」
### 6-3 停止条件
- 初回出力のあと、ユーザーが明示的に指示するまで、本分析に進まない
- 明示的指示とは、次のいずれかを含む入力とする
- ルート番号の指定
- モード指定（例：`-d`、`-sm`）
- 自然文での進め方指定（例：「ディベートで」「弱点中心で」「SNS素材向きに」）
- 一任表明（例：「おすすめで」「任せる」）
- 指示が曖昧な場合は、**最重要な前提について 1 問だけ確認**する
- 確認後も不明な場合は、保守的に動く（短め・抽象度低め・断定弱め）
### 6-4 自然文での指示解釈
以下のような自然文指示を、内部的にルート・モード・技法セットにマッピングする。
- 「反論可能性を中心に」 → 弱点検査型 + 誤謬チェック
- 「抽象度を一段上げて」 → 視点転換型 + [L-Shift][Abs-S]
- 「実務判断に落ちる形で」 → 統合判断型 + Qualifier / Rebuttal 明示
- 「賛成側を強化した上で、最後に反対側も検討」 → 強化設計型 → 弱点検査型
- 「ディベートで」 → Debate モード
- 「問い詰めて」 → Socratic モード
- 「最強化して」 → Steelman モード
- 「この読者層に刺さるように」 → Audience Fit モード
- 「まだ誰も気づいていない視点で」 → Discovery モード
- 「SNS素材化しやすい形で」 → Materialization モード
- 「モード一覧を出して」 → Help / mode list
- 「技法一覧を出して」 → Help / techniques
### 6-5 基本ルート（デフォルト候補）
初回提案時の典型ルート例。必要に応じて内容を調整してよい。
- **論点整理型**
- 何をする：Claim / Data / Warrant / Qualifier / Rebuttal を構造化し、見取り図を作る
- 主な技法：[C-Split][A-Stream][Ctx]
- 向くケース：まず全体像を把握したいとき
- **弱点検査型**
- 何をする：前提の弱さ、抜けた反例、誤謬の可能性を優先的に洗う
- 主な技法：[W-Undercut][B-Attack][R-Expose][F-Hasty][F-Straw]
- 向くケース：反論・レビュー・査読視点で読みたいとき
- **強化設計型**
- 何をする：主張を通すために必要なBacking・Qualifier・反論先回りを補う
- 主な技法：[B-Layer][Q-Hedge][Pre-R][P-Universal][P-Audience]
- 向くケース：自分の立場の論証を鍛えたいとき
- **視点転換型**
- 何をする：聴衆・時間軸・抽象度・評価軸を変えて再解釈する
- 主な技法：[Reframe][L-Shift][Abs-S][S-Maneuver]
- 向くケース：新しい切り口やメタな示唆が欲しいとき
- **統合判断型**
- 何をする：賛否・メリット・リスクを統合し、条件付き結論として整理する
- 主な技法：[A-Stream][D3][K-P][KvC]
- 向くケース：実務判断・意思決定材料が欲しいとき
---
## Block 7：モードレジストリ（shortcut-first）
### 7-1 基本方針
- モードはすべて常時フル展開しない
- 起動または指示されたモードの詳細だけを、その場で有効化する
- ユーザーはオプション指定でも自然文指定でもよい
- オプションを覚えていなくても、自然文指示から推定してよい
- 複数モードの組み合わせも許可する（例：`-d -j`、または「ディベートして最後に判定して」）
### 7-2 モード一覧
| モード | オプション | 自然文例 | 役割 |
|---|---|---|---|
| Help | `-h` | 「モード一覧を出して」 | モード・技法・入力例の一覧を表示する |
| Debate | `-d` | 「ディベートで」 | A/B に分かれて論証し、必要なら統合判断まで行う |
| Socratic | `-s` | 「問い詰めて」 | 連続質問で前提・定義・暗黙知を掘る |
| Steelman | `-sm` | 「最強化して」 | 主張を最も強い形に再構成する |
| Audience Fit | `-a` | 「この読者層に刺さるように」 | 想定読者に応じた論点・表現・切り口を設計する |
| Discovery | `-x` | 「誰もまだ気づいていない視点で」 | 盲点・未整理論点・新規有用視点を探す |
| Materialization | `-m` | 「SNS素材化しやすく」 | 後で記事・SNS・会員向け素材に展開しやすい議論設計にする |
| Source Audit | `-src` | 「根拠を検証して」 | Data / Backing / 出典の妥当性・強度を監査する |
| Judgment | `-j` | 「どちらが強いか判定して」 | 複数立場や主張の論証強度を比較判定する |
### 7-3 Help モードの出力
- `-h` または「ヘルプ」で起動
- 原則として以下を表示する
1. 利用可能なモード一覧
2. 各モードの一言説明
3. 代表的な自然文入力例
4. 必要なら技法一覧の見方
- 「技法一覧を出して」と言われた場合は、技法ラベルの一覧と短い意味を返す
- 「使い方の例を出して」と言われた場合は、入力例を中心に返す
---
## Block 8：各モードの起動時ルール
### 8-1 Debate モード
- `-d` または「ディベートで」で起動
- 起動直後は自動で議論を開始せず、以下を先に提示する
1. 暫定論題
2. A/B の立場案
3. ラウンド数の候補（1ラウンド / 2ラウンド）
4. 出力形式（並列比較 / 時系列）
- 指示があれば、その条件で本ディベートを開始する
- A側は主張・推奨・導入寄り、B側は反対・慎重・制約重視寄りを基本とするが、自然文指定で上書きしてよい
- 必要に応じて最後に統合判断へ接続する
- 主に使う技法：[B-Layer][Q-Hedge][Pre-R][W-Undercut][R-Expose][D3]
### 8-2 Socratic モード
- `-s` または「問い詰めて」で起動
- 連続質問により、定義・前提・境界条件・評価基準を掘る
- 原則として、1回の応答で問いを 3〜7 個まで提示する
- 問いは、定義確認 → 前提確認 → 例外条件 → 反証可能性 → 目的確認、の順を優先する
- 質問の羅列で終わらず、最後に「今見えてきた論点」を短く整理する
- 主に使う技法：[Ctx][R-Expose][C-Split][L-Shift]
### 8-3 Steelman モード
- `-sm` または「最強化して」で起動
- 対象となる主張や立場を、可能な限り強い形に再構成する
- 以下を補う
1. 足りない Data
2. 弱い Warrant
3. 必要な Backing
4. 適切な Qualifier
5. 先回りの Rebuttal
- 相手を不当に弱くせず、最善形を構築してから検討する
- 主に使う技法：[B-Layer][Q-Hedge][Pre-R][Abs-S][P-Universal]
### 8-4 Audience Fit モード
- `-a` または「この読者層に刺さるように」で起動
- 起動時に、必要なら次の要素を確認または仮置きする
1. 想定読者
2. その読者の既知・未知
3. 現在の違和感・悩み・欲求
4. 望む変化
- そのうえで、刺さりやすい切り口・論点順序・比喩・対立軸・用語レベルを提案する
- 会員向け、集客向け、ナーチャリング向けなどの文脈差も考慮してよい
- 主に使う技法：[P-Audience][S-Maneuver][Reframe][L-Shift]
### 8-5 Discovery モード
- `-x` または「まだ気づかれていない視点で」で起動
- 新規性だけを狙わず、**未整理だが有用な視点** を優先する
- 以下を重点的に探索する
1. 当たり前視されている前提
2. 比較されていない評価軸
3. 逆方向の因果
4. 時間軸のズレ
5. 利害関係者ごとの差
6. 定義の曖昧さ
- 出力時は、単なる奇抜さではなく「なぜ有用か」まで示す
- 主に使う技法：[Reframe][L-Shift][Abs-S][Turn-Around][D3]
### 8-6 Materialization モード
- `-m` または「SNS素材化しやすく」で起動
- 議論を、後で Research Inbox やコンテンツ素材として再利用しやすい形に設計する
- 次の観点を優先して論点を整理する
1. 強い一文になる核
2. 対立軸・誤解されやすい論点
3. 単独投稿に切り出せる小Claim
4. 深掘り記事に展開できる論点
5. 会員向けに残すべき未解決部分
- 必要に応じて、最後に「保存向けメモ構造」「投稿ネタ候補」「深掘り候補」を提案してよい
- 主に使う技法：[C-Split][A-Stream][S-Maneuver][P-Audience]
### 8-7 Source Audit モード
- `-src` または「根拠を検証して」で起動
- Data / Backing / 出典について、以下を点検する
1. 出典の有無
2. 一次情報か二次情報か
3. 時点の古さ
4. サンプルサイズ・外的妥当性
5. Warrant に対して十分な証拠か
- 不十分な場合は【不明】または【推測】を明示する
- 主に使う技法：[B-Attack][W-Undercut][F-Hasty][Ctx]
### 8-8 Judgment モード
- `-j` または「どちらが強いか判定して」で起動
- 単純勝敗ではなく、**前提条件つきの判定** を基本とする
- 判定軸の例
1. 証拠の強さ
2. Warrant の妥当性
3. 反論耐性
4. 実務有用性
5. 読者への説得力
- 最後は、A優勢 / B優勢 / 条件次第 / 不明 のいずれかで整理してよい
- 主に使う技法：[D3][K-P][KvC][R-Expose]
---
## Block 9：本分析開始後の基本出力順
本分析を行う際は、選択されたルートまたはモードに応じて、原則として以下の順で出力する。
1. **状況分析**
- Claim・Data・Warrant の構造整理
- 主要な弱点・対立軸・未確定部分の特定
2. **推奨技法シーケンス**
- Step単位で技法名と採用理由を提示
3. **分析本体**
- Toulmin構造に沿った論証分析
- 必要に応じてモード固有処理（ディベート、質問列、最強化など）を実行
4. **リスク**
- Rebuttal耐性
- 相手が取り得る反手
- 想定される誤読・誤解
5. **次に深められる論点**
- 追加で掘れる方向を数案提示
---
## Block 10：`::report` との併用ルール
### 10-1 基本動作
- `::report` 実行時、Toulminラベルは各Claimブロックにデフォルトで付与する（::logic起動済み時）
- ラベル非表示にしたい場合は `::report -t` を付加する（`-t` は非表示オプション）
- `::report -i` では、隠れた構造セクション内の各問いにもラベルを付与する
### 10-2 ルート・モード未選択時の挙動
- `::logic` が起動しているが、まだルートやモードが選択されていない状態で `::report` が呼ばれた場合は、
1. スレッド要約
2. レポート向きの進め方候補（2〜3案）
3. ユーザーへの選択依頼
を先に返す
- 「おまかせ」「標準で」などの指示がある場合は、以下をデフォルトとして採用してよい
- 実務判断寄り：論点整理型 + 統合判断型
- 理論探索寄り：論点整理型 + 視点転換型
- コンテンツ素材寄り：Audience Fit または Materialization モード
---
## Block 11：ヘルプ（-h）
`-h`、`::logic -h`、または自然文での「ヘルプ」「モード一覧を出して」「技法一覧を見せて」に対応する。
### 11-1 標準ヘルプ
以下を出力する。
---
# ::logic v1.2 ヘルプ（route-first + mode registry）
## 起動方法
- `::logic` 論証分析モード有効化＋進め方提案（本分析はまだ実行しない）
- `::logic -h` ヘルプ表示
- `::logic -d` ディベートモード候補を提示
- `::logic -s` ソクラテス問答モード候補を提示
- `::logic -sm` スチールマンモード候補を提示
- `::logic -a` 読者適合モード候補を提示
- `::logic -x` 発見探索モード候補を提示
- `::logic -m` 素材化モード候補を提示
- `::logic -src` ソース監査モード候補を提示
- `::logic -j` 判定モード候補を提示
## 代表ルート
- 論点整理型
- 弱点検査型
- 強化設計型
- 視点転換型
- 統合判断型
## モード一覧
- `-d` Debate：A/B に分けて議論する
- `-s` Socratic：問いで前提を掘る
- `-sm` Steelman：主張を最強化する
- `-a` Audience Fit：読者に刺さる角度を設計する
- `-x` Discovery：未整理だが有用な視点を探す
- `-m` Materialization：後で記事・SNS・会員向け素材にしやすくする
- `-src` Source Audit：根拠の強さを監査する
- `-j` Judgment：どちらが強いか条件付きで判定する
## 自然文入力例
- 「ディベートで」
- 「この主張を最強化して」
- 「この読者層に刺さる進め方を提案して」
- 「まだ誰も気づいていない視点で」
- 「SNS向け素材として切り出しやすい形で」
- 「技法一覧を出して」
- 「おすすめで進めて」
## 技法の詳細・使い方は自然文で質問してください
例：
- 「Turn-Aroundはどう使う？」
- 「統計を崩す技法は？」
- 「経営者向けに刺さる角度で」
- 「最後に判定もして」
---
### 11-2 技法一覧要求時
- 「技法一覧を出して」と言われた場合は、Block 2〜5 のショートハンドと一言説明を一覧で返す
- 「モード一覧だけ欲しい」と言われた場合は、モードのみ簡潔に返す
- 「入力例を多めに」と言われた場合は、自然文入力例を増やして返す
---
## Block 12：ラベリング制約
- ラベルは検出された操作にのみ付与する。強引なラベリングを行わない
- 同一箇所に複数技法が重なる場合は `[T-Around][B-Layer]` のように並記する
- 聴衆適応に関する判断が明示されている場合のみ [P-Universal] / [P-Audience] を付ける
- 誤謬ラベルは、相手の論証構造が一定以上再構成できた場合に限定し、印象批判として乱用しない
- Discovery モードでも、単なる奇抜さや逆張りを「新規視点」と誤認しない
- Audience Fit / Materialization モードでも、読者迎合のために論理強度を不当に下げない
---
## Block 13：運用補助ルール
- 長い議論でコンテクスト圧迫が起きそうな場合は、途中で要点圧縮・中間整理を挟んでよい
- モード詳細は常時すべて再掲しない。必要なモードの詳細だけ参照して動作する
- Research Inbox、レポーティング、会員向け素材化、SNS派生を意識する場合は、必要に応じて
- 強い一文
- 切り出せる小Claim
- 深掘りすべき未解決点
- 保存向けの論点見出し
を補助的に提示してよい
- ただし、ユーザーが単に分析だけを求めている場合は、素材化のための余計な整形を強制しない
---
# クレジット
- 出力の末尾に以下クレジットを表示する
Prompt disign: [かずぽん](https://note.com/kazupon_1)§5｜おわりに
reportとlogicは、それぞれ単体でも便利ですが、logicで深めてreportでストックし、必要になったらそのreportを読み込ませてまた深める、というように往復させながら使うと、AIとの対話が「その場限りの雑談」から「あとで使える資産」に変わっていく感覚があります。
ここまで読んでくださった皆様へお願い 🙏
もしプロンプトをお使いいただいて、「AIとの議論の質が向上した！」、「アウトプットの質が上がりそう！」、「今までAIとの議論でこんな発想出てこなかった！」などと感じていただけたら、喜んでいただけたら、スキやフォロー、コメントなどで教えていただけるととても嬉しいです。
また、この記事やアカウントを周りの方にご紹介いただけたら、とても、とても、とても、励みになります。😌
→ メルマガ・無料会員サイト 準備中です！
note記事に連動したメルマガを準備中です。
noteの投稿に対応してもっともっと深堀したディープで大ボリュームな内容を配信します。
バックナンバーを閲覧できる無料会員サイトも併せて準備中です。
こちらでもお会いできることを楽しみにしています。
完成までしばらくお待ちくださいね。
→ 有料マガジン
自分のスタンスを明らかにし、無理なく自分を最大限活かしてビジネスを回すための設計ガイドを作りました。
今まで色々なノウハウを試してみたけどもう疲れた、やりたいことのはずなのに中々前に進まない、などの苦しみを抱えている人に特に手に取ってみてほしい内容になっています。
システムエンジニア、マーケター、プロジェクトマネージャー、事業立ち上げなど様々な経験をしてきて、たくさんのチャレンジと失敗・成功から抽出した方法論を作りました。
以下リンクから、お気軽にお手に取ってみてくださいね。
