見出し画像

おまけ🌟【プロンプト無料配布:2】 AIと対話を続けていると最初の方を忘れてしまう、、また説明するのはめんどい、、🙄

かずぽん

【お知らせ】
🌟自分のビジネスをスタンスから作り上げるビジネス設計ガイドを発信中


昨日共有した、プロンプト2つの配布記事が思いのほか好評だったため、おまけでもう2つご用意することにしました！😏

どちらも私自身が普段使いしているものです。

スキやフォロー、コメント、記事の紹介をしていただいた方々、本当にありがとうございます！🙏

↓↓↓ 無料配布していますので、まだの方はぜひ受け取ってくださいね。


§1｜🛠 今回のおまけ： 地味だけど効く、2つの装置

今回配布するのは、前回の report・logic とは少し役割の違う、土台側の2つです。

  • カスタム指示：AIとの対話そのものの信頼性を上げるための、ChatGPTやClaudeなどの「カスタム指示」欄に貼っておくプロンプトです。ハルシネーション（AIの嘘）を防ぎ、論理的に筋の通ったアウトプットにすることを目的にしています。

  • handoverプロンプト：スレッドが長くなってコンテクストウィンドウが厳しくなってきたときに、次のスレッドへスムーズに引き継ぐためのプロンプトです。Notionに引き継ぎ情報を残し、次スレッド冒頭に貼るだけの引き継ぎ文まで自動生成してくれます。

前回の2つが「深掘り・ストックの装置」だとすると、今回の2つは「土台・接続の装置」というイメージです。派手さはありませんが、地味に効いてきます。

毎日使うものだから


§2｜🤥 なぜ「カスタム指示」が要るのか — AIは、なぜ平気で嘘をつくのか

AIと話していて、自信満々に間違ったことを言われた経験がある方は多いのではないでしょうか。

これは、AIに悪意があるわけではなく、構造的に仕方がない部分があります。AIは「正しいことを言う」ように作られているというより、「それらしく続きを生成する」ように作られている、というのが近い理解です。特に、学習した時点より新しい情報や、細かい固有名詞・数字については、もっともらしい誤りが混ざりやすくなります。

なので、本来はファクトチェックが必須なのですが、通常の対話の中でそれを毎回やるのは、正直かなり大変です。

そこで私は、対話の出力そのものが「あとから検証しやすい形」になるよう、カスタム指示を作りました。ポイントは大きく3つです。

  • 外部情報が絡む話題では、必ずWeb検索した上で結論を書く（学習済みの記憶だけで断定しない）

  • 事実／一般論／推測／不明、をラベルで明示的に分ける（どこまで確からしいかが一目でわかる）

  • 結論を含む回答は、Claim（結論）→Data（根拠）→Warrant（なぜそのDataからその結論が言えるか）という構造で書く

3つ目のトゥールミンロジック（Claim・Data・Warrantなどで議論を分解する考え方）については、前回の記事の logic プロンプトの中で詳しく説明していますので、気になる方はそちらもご覧ください。


§3｜🧵 なぜ「引き継ぎプロンプト」が要るのか — コンテクストウィンドウの壁

AIとの対話には、コンテクストウィンドウという、一度に扱える情報量の上限があります。スレッドが長くなるほど、この上限に近づいていきます。

自動実行される仕組み（バッチ処理やエージェント的な環境）では、あらかじめこの問題への対策が組み込まれていることが多いのですが、普段よく使うことが多いチャットベースのやり取りでは、この壁を自分でなんとかする必要があります。

一番面倒なのが、スレッドをまたぐたびに、同じ経緯や前提をもう一度説明し直すことです。「これまでの経緯なんですけど…」から毎回始めるのは、地味にストレスですし、伝え漏れも起きやすくなります。

そこで作ったのが、handoverプロンプトです。今のスレッドの内容を要約してNotionに記録し、次のスレッド冒頭にそのままコピペできる引き継ぎ文まで一緒に作ってくれます。これがあれば、新しいスレッドを開いてすぐ、続きから作業を再開できます。

次のスレッドにまた説明しなくて良いのです🤵‍♂️


§4｜⚙️ 使い方

カスタム指示の使い方

お使いのAIツールの「カスタム指示」「システムプロンプト」に該当する設定欄に、そのまま貼り付けてください。

  • 口調の部分（「私」「〇〇さん」などの一人称・二人称の表記）はお好みでカスタマイズしてください。

  • できる限り文字数を圧縮していますが、ツールによってはカスタム指示の文字数制限を超えてしまう場合があります。その場合は申し訳ないのですが、ご自身の環境に合わせて削って調整してお使いください。

handoverプロンプトの使い方

report のときと同じく、あらかじめどこかに保存しておいて、必要なときにスレッドへ貼り付けて呼び出す使い方を想定しています。

人間側がやることは、実質この2つだけです。

  1. プロンプトをスレッドに貼って実行する

  2. 生成された引き継ぎプロンプトをコピーして、次の新しいスレッドの冒頭に貼る

Notionへの記録・旧レコードのアーカイブ化などは、すべて裏側でAIが自動でやってくれます。 呼び出すと、

  1. 現在のスレッド内容を要約

  2. Notionの「Handover DB」に構造化して保存

  3. 次スレッド冒頭に貼るだけの引き継ぎプロンプトを生成

まで、一気に実行してくれます。

事前準備
Notionとお使いのAIをあらかじめコネクト（連携）しておく必要があります。（プランによってはコネクタ機能自体が使えない場合があります。その場合は申し訳ないのですが、他の保存先に読み替えてお使いください🙏）

コネクトができたら、Notion側へ以下のプロパティを持つデータベースを1つ作っておいてください（Notion側の作り方はこの記事では割愛します）。

プロパティ名 / 型
Title / title
Output_Page / url
Status / status
Prev_Handover / url
Next_Handover / url

データベースができたら、プロンプト本体の

DB URL：{あなたのHandover DBのURLを貼り付けてください}

の部分を、ご自身の値に差し替えます。

  • DB URL：作成したデータベースのURLをそのまま貼り付けてください。

エラーが起きた場合は、AI側が自動でフォールバックし、手動で入力すべき値をそのまま出力してくれる作りになっているので、Notion側の設定さえできていれば、大きく詰まることは少ないはずです。

"ちょっと"良くなる☺️


§5｜📋 プロンプトの中身

カスタム指示｜対話の信頼性を底上げするプロンプト

言語・口調
日本語・ですます調。一人称は私、ユーザーはxxさん。砕けた表現やスラングは禁止。ビジネスでも通用するフォーマルかつ中立的な文体で、事実とロジックを重視。

構成・分量
技術・抽象内容前提で、構造・前提・論理を重視。多情報時は「要点2〜4文→詳細」。質問が不明瞭なときは、最重要な前提のみ1問だけ確認。

外部情報・Web検索
外部情報タスク（仕様・シリーズ作品・ゲーム・技術・API・サービス・時事・投資・ニュースなど時間とともに変化するもの）では、学習済み知識のみでの回答を禁止、最新Webを検索し、その結果に基づき結論を書く。検索結果を無視して学習済み知識だけで結論を出さない。対象集合（登場キャラ一覧、API一覧など）がある場合は、最初にWebでその一覧や定義を確定し、それを前提に推論する。ユーザーの性格・価値観・抽象的思考整理・文章構成など、外部ソース不要のタスクはこの限りではない。Webで十分な情報が得られない場合は【不明】【推測】と明示、断定しない。

Evidenceとラベル
【事実】は公式・一次情報や明示可能な外部ソースに基づく内容。【一般論】は多くのケースに当てはまるが例外があり得る内容。【推測】は情報不足下での推定。【不明】は現情報では判断不能な内容。事実の文には必ず出典を付け、【事実】とラベルする。出典のない内容は【一般論】または【推測】とし、事実として断定しない。【事実】とする数値や一覧は、出典ソース内で直接確認できる内容限定。ソースにない細部を学習済み知識で補完して【事実】と書かない。古い可能性がある情報を用いる場合は、その時点（年・月）を明示し【一般論】として扱う。情報不足や矛盾がある場合は【不明】と明記し、無理に埋めない。

Toulmin構造（判断を含む回答）
提案・推奨・選択・評価など結論を含む回答では、Claim → Data → Warrant（必要に応じて Backing → Qualifier → Rebuttal → 補足）の順で書く。Claimには結論・推奨・評価を簡潔に書く。Dataには依拠する外部ソース（URLまたはメディア名）、おおよその更新時期（可能な範囲で年月）、前提条件を書く。Warrantには、そのDataからなぜそのClaimが妥当と言えるかを1〜3文で説明する。Dataが学習済み知識に大きく依存する場合は、その旨を明示して強い断定を避ける。
ラベルと内容は必ず合致させること。（WarrantラベルにClaimの内容を書く、などは意味が無い。実際に発生しました。）

コードブロックの作法
Notion貼付前提の出力を指示された場合は、マークダウンをコードブロック（```markdown）で出力する。コードブロックを含む出力では用途を問わず以下のルールを守る。
- 内部処理用ID・引用タグ・疑似リンク（[xxx:nn]形式）を出力しない
- コードブロック内でさらにコードブロックをネストする場合、:::mermaid / :::/mermaid、:::code:言語名 / :::/code の擬似記法を使用する
- 見出し＋箇条書き中心。長いリストや比較は表を優先。広告・雑談などのノイズはカット
- 調査内容には[タイトル](URL)形式で【出典】を付ける

禁止事項
外部情報タスクで学習済み知識のみから結論を出すことは禁止。出典のない【事実】ラベル、推測を事実のように述べる行為、「わからない」「情報不足」と言うべき状況での断定を禁止する。【一般論】や【推測】を事実のように扱わない。
GUI操作（computer tool / navigate tool 等）は原則禁止。コネクタ経由で。書き込み時承認必須


handoverプロンプト｜スレッドを次につなぐプロンプト

このスレッドの内容に対して、以下のプロンプトを実行してください。

---

# ::handover スレッド引き継ぎ用プロンプト

## 共通仕様

### Evidenceラベル
- 【事実】：公式・一次情報や明示可能な外部ソースに基づく内容。出典を付ける
- 【一般論】：多くのケースに当てはまるが例外があり得る内容
- 【推測】：情報不足下での推定
- 【不明】：現情報では判断不能な内容

### 出力制約
- 内部処理用ID・引用タグ・[web:xx] のような疑似リンク表記を出力しない
- コードブロックのネストが必要な場合、:::code:言語名 / :::/code の擬似記法を使用する
- 断定できない内容は【推測】または【不明】として扱い、断定しない

***

## Handover DB スキーマ（固定）

このスキーマ通りに書き込むこと。

- DB URL：{あなたのHandover DBのURLを貼り付けてください}

プロパティ一覧：

| プロパティ名 | 型 | 値・制約 |
|---|---|---|
| Title | title | AIが内容を反映して生成 |
| Output_Page | url | 作業対象ページURL。不明・複数の場合は空欄 |
| Status | status | Active のみ指定（旧レコードは本プロンプトで Archived に更新） |
| Prev_Handover | url | 前のHandoverページURL。初回は空欄 |
| Next_Handover | url | 新規作成後に旧レコードへ書き戻す。初期は空欄 |

Output_Page の扱い：
- 作業対象ページが1件 → URLを入力
- 複数ある場合 → 最も中心的な1件のみ入力。残りはHandoverページ本文に記載
- 不明な場合 → 空欄（「不明」という文字列は入力しない）

Statusプロパティの運用前提：
- 型：status
- 主なオプション：Active / Archived
- 新規Handoverレコードは必ず Active で作成し、前レコードは本プロンプトのSTEP 2で Archived に更新する

***

## タスク全体ルール

- 各STEPの成否に関わらず、STEP 4まで必ず完走すること
- 同一MCPリクエストを2回以上繰り返してはならない
- エラーが返った場合は即座にフォールバック処理へ移行する
- 成功の判定は「作成されたページのURLを取得できたか」をもって行う（自己申告不可）

***

## STEP 0：現在のHandoverページの取得

引き継ぎプロンプトに「現在の Handover ページ URL：」が含まれる場合：
- MCPでそのページをfetchし、本文の文字数を概算する
- fetch成功 → 文字数で判定（4,000文字未満：追記 / 4,000文字以上：新規作成）
- fetch失敗 → 新規作成をデフォルト動作とする

「現在の Handover ページ URL：」の記載がない場合 → 新規作成

結果を記録する：
【STEP 0】fetch：成功／失敗　→　判定：新規作成／既存追記

***

## STEP 1：Handoverページ本文の生成

セクション構成の原則：
- 該当内容がないセクションは省略可
- 「本スレッド」という表現は使用しない。このページはAIが書くアーカイブであるため、「次スレッド」が常に正しい
- 追加すべき内容があればAIが適宜見出しを追加して挿入する

### 新規作成の場合：ページ全文を出力

***
# （スレッドの内容を反映したタイトル）

前のレコード：[タイトル](URL)　※前のレコードがある場合のみ記載

## 作業概要
（このスレッドで何を目的とし、どのような経緯で進行したか。2〜4文で要約）

## 確定事項
（スレッド内で決定・合意された仕様・方針・設計内容を箇条書きで記載）

## 未完了タスク・保留事項
（着手したが完了していない作業、判断が持ち越された事項）

## 次スレッドへの申し送り
（次のスレッドで最初に確認・実行すべき事項。3項目以内に絞る）

***

### 既存追記の場合：追記分のみを出力

***
## 追記：（YYYY-MM-DD または トピック名）

## 確定事項（追記）
（追加で確定した内容）

## 未完了タスク・保留事項（更新）
（変更・追加された保留事項）

## 次スレッドへの申し送り（更新）
（最新の申し送り内容。3項目以内に絞る）

***

## STEP 2：Handover DB への書き込み（MCP自動実行）

### 2-A：新規作成の場合

Sub-step 1：新レコードの作成
上記スキーマに従い、Title / Output_Page / Status / Prev_Handover を入力してレコードを作成する。
作成後、返却されたページURLを取得する。URLが取得できない場合は失敗とみなす。

Sub-step 2：Handoverページ本文の書き込み
作成したレコードのページ内に STEP 1 の本文を書き込む。

Sub-step 3：旧レコードのリンク更新
Prev_Handover がある場合のみ、旧レコードの Next_Handover に新レコードのURLを入力する。

Sub-step 4：旧レコードのStatus更新
Prev_Handover がある場合のみ、旧レコードの Status を Active から Archived に変更する。
Status更新が何らかの理由で失敗した場合は、そのエラー内容を記録し、STEP 2のフォールバック処理に進む。

結果を記録する：
【STEP 2】レコード作成：成功（URL：xxx）／失敗
         本文書き込み：成功／失敗
         旧レコードリンク更新：成功／失敗／対象なし
         旧レコードStatus更新：成功／失敗／対象なし

### 2-B：既存追記の場合

指定されたHandoverページの末尾に STEP 1 の追記内容を書き込む。
新レコード作成・Next_Handover への記入・Status更新は不要。

結果を記録する：
【STEP 2】既存ページ追記：成功／失敗

### フォールバック処理（いずれかのSub-stepが失敗した場合）

失敗したSub-stepのエラーメッセージをそのまま出力し、以下を順番に行う：

① 状況の分析
どのSub-stepで何が起きたかを記述する。

② 原因の仮説
エラーメッセージから考えられる原因を列挙する（型不一致・権限エラー・接続タイムアウトなど）。

③ 対策の仮説
原因ごとに対処方法を提示する。

④ 手動操作用の情報出力

【手動操作が必要です】

失敗したSub-step：（番号と内容）

レコード作成が失敗した場合の入力値：
- Title：（生成値）
- Output_Page：（URL または 空欄）
- Status：Active
- Prev_Handover：（URL または 空欄）

旧レコード更新が失敗した場合：
- 旧レコードURL：（URL）
- Next_Handover に入力する値：（新レコードURL）

旧レコードStatus更新が失敗した場合：
- 旧レコードURL：（Prev_Handover に指定したURL）
- エラーメッセージ：（APIから取得した内容をそのまま記載）
- 想定される原因の例：
  - Statusプロパティが削除・リネームされている
  - Statusプロパティの型が status 以外になっている
  - 「Archived」オプションが存在しない
  - DBまたはページへの書き込み権限がない
  - 一時的な接続・APIエラー
- 実施してほしい操作：
  1. 上記旧レコードを開き、Statusプロパティの有無と型（status）を確認する
  2. オプションに Active / Archived が存在するか確認し、なければ追加する
  3. 手動で Status を「Archived」に変更する
  4. 必要に応じてHandoverプロンプトのスキーマ定義（Statusの仕様）とDB構成を再同期する

***

## STEP 3：次スレッド冒頭用引き継ぎプロンプトの生成

設計原則：
- 受け取るスレッド（B）の視点で書く。「本スレッド」とはBのことを指す
- 経緯・確定事項の詳細はHandoverページを参照すれば足りるため、転記しない
- 引き継ぎプロンプトは「着手命令＋参照情報」に絞る
- 運用しやすいように引き継ぎプロンプトはMarkdownのコードブロックとして出力する

HandoverページURLはSTEP 2で取得したURLを使用する。
STEP 2が失敗した場合のみ「【Handoverページ URL を入力】」とプレースホルダーにする。

***

## 引き継ぎ：（作業内容を反映した名称）（YYYY-MM-DD）

> 前スレッドからの引き継ぎです。以下を読み取り、「本スレッドで着手すること」から作業を開始してください。

### 参照
- Handover DB：{あなたの引き継ぎ格納先を貼り付けてください}
- Handover ページ：（URL）※詳細な確定事項・経緯はこちらを参照

### Output_Page
- （作業対象ページのURL。不明な場合は「不明」）

### 本スレッドで着手すること
（STEP 1「次スレッドへの申し送り」の内容を転記。3項目以内）

### 注意事項・制約（あれば）
（前スレッドで発生した制約・注意点があれば記載。なければ省略）

***

## STEP 4：処理サマリー,クレジットの出力

=== Handover 処理サマリー ===
STEP 0：（fetch結果と判定）
STEP 2：（各Sub-stepの成否）
STEP 3：引き継ぎプロンプト生成：完了
手動対応が必要な項目：（あれば列挙 / なし）
=============================

Prompt disign: [かずぽん](https://note.com/kazupon_1)



§6｜おわりに

カスタム指示は、AIとの対話すべての土台として効いてきます。handoverは、対話が長く・深くなってきたときに初めて価値を感じる、地味だけど手放せない存在です。

前回の report・logic と組み合わせると、

「土台を整え（カスタム指示）→ 深掘りし（logic）→ ストックし（report）→ 必要なら次スレッドへつなぐ（handover）」

という一連の流れができあがります。


ここまで読んでくださった皆様へお願い 🙏

もし使ってみて、「AIが以前より嘘をつかなくなった気がする」、「ファクトチェックがやりやすくなった」、「スレッドを跨ぐストレスが減った」など、何か感じていただけることがあれば、スキやフォロー、コメントで教えていただけるとすごく嬉しいです。

この記事やアカウントを周りの方にご紹介いただけたら、それもとても励みになります。😌

メインコンテンツのマガジンの方も、閲覧やスキ、ご紹介いただくと、ひっくり返って喜びます🙄  (ご購入いただければもっと…😏✨)


→ メルマガ・無料会員サイト 準備中です！

note記事に連動したメルマガを準備中です。noteの投稿に対応してもっともっと深堀りしたディープで大ボリュームな内容を配信します。

バックナンバーを閲覧できる無料会員サイトも併せて準備中です。

こちらでもお会いできることを楽しみにしています。☺️

完成までしばらくお待ちくださいね。

→ 有料マガジン

自分のスタンスを明らかにし、無理なく自分を最大限活かしてビジネスを回すための設計ガイドを作りました。

今まで色々なノウハウを試してみたけどもう疲れた、やりたいことのはずなのに中々前に進まない、などの苦しみを抱えている人に特に手に取ってみてほしい内容になっています。

システムエンジニア、マーケター、プロジェクトマネージャー、事業立ち上げなど様々な経験をしてきて、たくさんのチャレンジと失敗・成功から抽出した方法論を作りました。

無料パートもございますので、以下リンクからお気軽に手に取ってみてくださいね。☺️


いいなと思ったら応援しよう！