効果的なレシピの書き方

レシピは、一度書けば何度でも同じ形の出力を得られる指示文です。ただし、指示が短いほど出力の揺れは大きくなります。この記事では、指示文をどう組み立てるか、日本語で書くときに特に効く指定は何か、どう試して直していくかを説明し、最後にそのまま保存して使える例文を並べます。

#指示文の型を先に決める

レシピには「単一の会議」用と「複数の会議」用があり、どちらで作るかによって指示文の書き方が変わります。2つの違いと選び方はレシピ（定型指示）の作成手順にまとめています。

書くときに効いてくるのは、指示文が想定する入力と、実際に渡される入力を一致させることです。「この会議の」と書いた指示文を複数会議用のレシピにすると、どの会議を指すのかが定まらず、出力が不安定になります。逆に、単一会議用のレシピに「会議どうしを比較して」と書いても、比較する相手がありません。複数会議用では「選択した会議の記録から」のように、集合を受け取る前提で書き出してください。

#指示文の基本構造

出力を安定させるには、次の順で書くと扱いやすくなります。

1. 仕事の定義: 誰が、どういう状況で、何のために使う文書なのかを最初に書きます。読み手が誰かを明示すると、文体や詳しさの水準が定まります。
2. 前提情報: 会社、製品、体制、案件の背景など、毎回説明せずに済ませたい情報を書き込みます。
3. 規則: 守ってほしい条件を箇条書きにします。ここが出力の揺れを抑える中心です。
4. 出力の形式: 見出しの並び、表の列、項目数、1項目あたりの長さを指定します。
5. 出力の例: 形式が重要な場合は、短くてよいので実例を貼ります。

書き出しの例です。

会議が終わったところで、出席者に送るフォローアップメールが必要です。
あなたの仕事は、決定事項と次の行動をまとめた社外向けのメールを書く
ことです。読み手は取引先の担当者と、その上長です。

規則を書くときは、相手を新しく入ってきた担当者だと考えてください。社内では当たり前になっている前提も、書かなければ伝わりません。「いつもの形式で」「適切にまとめて」といった表現は、書き手ごとに意味が違うため、指示としては働きません。

#日本語で指示するときのコツ

日本語の文書には、英語にはない形式上の判断が多くあります。指定しなければ毎回違う選択がされるため、レシピの規則としてあらかじめ書いておきます。

#敬体と常体を指定する

「です・ます調」で書くのか「だ・である調」で書くのかを明示します。指定がないと、同じ文書の中で混ざることがあります。社外向けの文書は敬体、社内の記録や分析メモは常体、というように用途で決めておくと迷いません。

敬語の程度も指定できます。「二重敬語は使わない」「『させていただく』を多用しない」といった規則を入れると、社外向けの文面が読みやすくなります。

- 敬体（です・ます調）で書く。
- 過度な敬語は避ける。「させていただく」は1通につき1回までとする。
- 社内の記録部分（末尾の備考）だけは常体で書く。

#社内用語と外来語の表記を統一する

同じものを指す言葉が複数ある場合は、使う側を指定します。カタカナ語を使うか日本語に直すかも決めておきます。

- 次の表記に統一する:
  「顧客」（「クライアント」「お客さん」を使わない）
  「持ち帰り事項」（「ToDo」「アクションアイテム」を使わない）
  「見込み案件」（「パイプライン」を使わない）
- 長音符号は付ける（「サーバー」「ユーザー」）。
- 社内の略語（〇〇会議の略称など）は正式名称に直してから書く。

#固有名詞の表記ゆれを抑える

会議の発言では、社名や人名が略されたり、聞き取りが揺れたりします。正しい表記を指示文に書いておくと、出力の段階で揃います。

- 社名は正式名称で書く。「株式会社」の位置を省略しない。
  例: 「〇〇商事」→「株式会社〇〇商事」
- 人名には敬称「さん」を付け、役職名との併記はしない。
- 会議中に略称で呼ばれた製品名は、次の正式名称に置き換える。
  「新版」→「〇〇 2.0」／「旧システム」→「〇〇 販売管理」
- 表記が確認できない固有名詞は、推測せず発言のまま引用し、
  末尾に「【表記要確認】」と付ける。

会議中に繰り返し使う固有名詞は、文字起こしの段階で辞書に登録しておくと、指示文で直す手間が減ります。設定方法は文字起こしのカスタマイズをご覧ください。

#箇条書きの粒度を決める

箇条書きは、粒度を指定しないと、1行の項目と長い段落が混在します。項目数、1項目あたりの文字数や文の数、階層の深さを決めてください。

- 箇条書きは1階層のみとし、入れ子にしない。
- 1項目は1文、全角60文字以内に収める。
- 項目数は3以上7以下とする。7を超える場合は見出しで区切る。
- 体言止めにせず、述語まで書く。

#数字と単位の書式を決める

金額、期間、人数、日付の書式は、社内の文書規程に合わせて指定します。

- 数字は半角。3桁ごとに区切り記号を入れる（1,200,000円）。
- 金額は「円」を付け、税抜・税込を必ず明示する。会議で明示されて
  いない場合は「（税区分の記載なし）」と書く。
- 日付は「2026年4月1日」の形式。曜日は括弧書きで付ける。
- 期間は「4月1日〜4月30日」の形式。
- 割合は「%」を使い、小数第1位まで書く。
- 会議で述べられていない数値を補わない。概算も作らない。

#結論から書かせる

日本語の会議では、経緯を説明してから結論に至る話し方が多く、そのまま要約すると結論が末尾に来ます。読み手が決裁者や多忙な上長の場合は、順序を明示的に指定してください。

- 冒頭に「結論」の見出しを置き、3文以内で結論だけを書く。
  背景、経緯、前置きを結論より前に書かない。
- 結論の次に「理由」を3点以内で書く。
- 経緯と議論の詳細は、その後の「補足」にまとめる。
- 結論が会議で確定していない場合は、「結論」の見出しの下に
  「未確定」と書き、決まっていない理由を1文で示す。

#前提情報を一度だけ書いておく

レシピの利点は、毎回説明している前提をあらかじめ書き込めることです。次のような情報を入れておくと、出力の質が安定します。

• 自社が何をしている会社か、主な顧客は誰か
• 製品名、機能名、社内で使っている呼称
• 開発チームであれば、使用している言語や構成
• 自分の役割と、この文書で達成したいこと
• 同僚の名前と担当領域
• 案件ごとの背景、これまでの経緯

前提情報だけをまとめた「会社情報」のレシピを作っておき、チャットの最初にそれを実行してから、同じスレッドで他のレシピを続けて使う方法もあります。

#出力例を入れる

形式が重要な文書では、規則を並べるより実例を1つ貼るほうが確実です。過去に自分が書いたメール、社内の議事録の書式、報告書の見出し構成などを、そのまま指示文に貼り付けてください。

出力は次の形式に厳密に従ってください。

---
件名: 【〇〇案件】本日の打ち合わせの御礼と確認事項

株式会社〇〇
〇〇様

お世話になっております。〇〇株式会社の〇〇です。
本日はお時間をいただきありがとうございました。

本日決定した事項は以下のとおりです。
・（項目）
・（項目）

次回までの宿題は以下のとおりです。
・弊社: （内容）（〇月〇日まで）
・貴社: （内容）（〇月〇日まで）

引き続きよろしくお願いいたします。
---

#扱えるデータの範囲を前提にする

レシピが参照できるのは、Pulseに保存されている会議のデータと、添付した資料だけです。参照される範囲の詳細はノートに質問する（チャット）で説明しています。

指示文を書くうえで問題になるのは、範囲の外にある情報を前提にした指示です。たとえば「未完了のタスクを一覧にして」と書いても、すでに終わった作業かどうかは判断できません。会議で「これは完了した」と述べられていない限り、区別する材料がないためです。必要な資料は添付したうえで、記録にないことを補わせない規則を入れておきます。

- 会議の記録にない事項は書かない。
- 不明な点は「記録なし」と書き、内容を補わない。
- 一般的な知識で説明を補足しない。

#試して直す

指示文は一度で完成しません。書く、試す、崩れた箇所を見つける、その崩れを防ぐ規則を足す、という順で精度が上がっていきます。

レシピの編集画面で「プレビュー」を選ぶと、1件の会議やフォルダに対して試し実行できます。結果を見てから指示文を直し、もう一度実行すると、変更の効果をその場で比べられます。

図画面キャプチャ: レシピ編集画面のプレビュー

左側に指示文の入力欄、右側に試し実行の結果が表示され、上部に対象の会議を選ぶ欄がある状態。

#モデルによる違い

指示文で文体を指定していても、モデルによって出力の傾向は変わります。作る文書が長く、内容が複雑になるほど推論モデルが向き、会議中の短い確認や定型の一覧を出すだけであれば標準モデルのほうが待ち時間が短く済みます。指定できる範囲と選び方はAIモデルの選び方をご覧ください。同じレシピを両方のモデルで試し、自社の文書に近いほうを選んでください。

#例文集: 単一の会議用

そのまま保存して使える指示文の例です。社名、部署名、評価項目などは自社の実態に合わせて書き換えてください。いずれも、指示文の先頭で仕事の目的を説明し、続けて守ってほしい規則を並べ、最後に出力の形式を指定する構造にしています。

#社内配布用の議事録に整える

社内に配布する議事録を作成してください。読み手は会議に出席していない
同じ部署のメンバーと、その上長です。

守ってほしいこと:
- 敬体（です・ます調）で書く。
- 冒頭に「決定事項」を置き、その後に「議論の要点」「持ち帰り事項」の順に並べる。
- 決定事項は、決まったことだけを書く。検討中の案は議論の要点に入れる。
- 持ち帰り事項は「担当者 / 内容 / 期限」の3列の表にする。期限が発言に
  出ていない場合は「未定」と書き、勝手に日付を補わない。
- 発言者名は会議で呼ばれていた表記に統一する（例: 敬称は「さん」で統一）。
- 金額は半角数字と「円」、日付は「YYYY年M月D日」の形式で書く。
- 会議で話されていない内容は書かない。不明な点は「記録なし」と書く。

出力の形式:
## 会議名 / 日時 / 出席者
## 決定事項
## 議論の要点
## 持ち帰り事項（表）

#商談メモから日報に転記する

この商談の記録から、営業日報に貼り付ける原稿を作成してください。
読み手は自分の上長です。

守ってほしいこと:
- 常体（だ・である調）で簡潔に書く。1項目あたり2文以内。
- 「訪問先 / 面談者 / 目的 / 先方の反応 / 課題 / 次のアクション」の
  見出しを必ずこの順で出す。
- 先方の反応は、こちらの推測ではなく発言に基づいて書く。発言が
  なかった項目は「言及なし」と書く。
- 受注確度や金額は、先方が口にした数値のみを書く。こちらの見込みは
  書かない。
- 次のアクションには、自社側の担当者と実施予定日を入れる。

#訪問報告メールの下書きを作る

本日の打ち合わせのお礼と、内容の確認を兼ねたメールの下書きを作成
してください。宛先は先方の出席者です。

守ってほしいこと:
- 件名、宛名、本文、結びの順で出力する。
- 敬体で書く。過度な敬語（二重敬語）は使わない。
- 冒頭に一文でお礼を述べ、すぐに本題に入る。前置きは3行以内。
- 決まったことを箇条書きで3〜6項目にまとめる。1項目は1行に収める。
- 当方が対応する事項と、先方にお願いしたい事項を分けて書く。
- 期限がある依頼は、日付を明記する。会議で日付が出ていない場合は
  「【要確認】」と書いて空欄にする。
- 社外向けなので、社内の略語や内部の呼称は使わず、正式名称に直す。

#週次の定例から部門長向けの報告を作る

前提と規則をひととおり書き込んだ、長めの例です。

週次の部門定例が終わったところです。あなたの仕事は、この会議の記録
から、部門長に提出する週次報告を作ることです。部門長は会議に出席して
いません。

前提:
- 当部門は法人向けの受注業務を担当している。
- 「案件」は受注前の商談、「契約」は締結済みのものを指す。
- 担当者は3名（田中、佐藤、鈴木）。

規則:
- 敬体で書く。
- 冒頭に「今週の結論」を3文以内で置く。経緯を先に書かない。
- 続けて「進捗」「懸案」「来週の予定」の順に見出しを置く。
- 各見出しの下は箇条書き。1項目1文、全角60文字以内、3〜7項目。
- 数字は半角、金額は3桁区切りで「円」を付け、税区分を明示する。
- 日付は「2026年4月1日」の形式で書く。
- 人名には「さん」を付ける。社名は正式名称で書く。
- 会議で述べられていない数値や見通しを補わない。発言がない項目は
  「言及なし」と書く。
- 懸案には、それぞれ担当者と、決裁が必要かどうかを明記する。

#1on1の振り返りを作る

上長として実施した1on1の記録を、次回に向けた振り返りとして整理して
ください。この内容は本人には共有しません。

守ってほしいこと:
- 「本人が話したこと」と「私が受け取った印象」を明確に分けて書く。
  印象の側には必ず「（解釈）」と付ける。
- 本人が困っていると述べた事柄を、発言に近い言葉のまま引用する。
- 前回からの変化について言及があれば、その箇所を抜き出す。
- 私が話した時間が長すぎなかったか、質問と説明の比率について
  気づいた点を最後に2〜3行で書く。
- 評価や人事に関する判断は書かない。

#採用面接の評価シート

面接の記録から、評価シートの下書きを作成してください。対象は
中途採用の営業職です。

守ってほしいこと:
- 評価項目は「経験の適合」「課題解決の進め方」「顧客との関係構築」
  「入社後に想定される立ち上がり」の4つとする。
- 各項目について、根拠となる候補者の発言を1〜2箇所引用してから、
  2〜3行で所見を書く。引用は発言の要旨ではなく、話された内容に
  沿った表現にする。
- 発言が確認できなかった項目は「確認できず」と書き、次回の面接で
  聞くべき質問を1つ提案する。
- 合否の判断は書かない。年齢、家族構成、出身地など、選考の基準に
  してはならない事項には触れない。

#例文集: 複数の会議用

複数の会議を対象にするレシピは、どの会議の発言なのかを出力に残す指示を入れておくと、後から元のノートをたどれます。

#稟議・決裁に添える要点整理

選択した会議の記録から、稟議書に添付する検討経緯の要約を作成して
ください。読み手は決裁者で、個別の会議には出席していません。

守ってほしいこと:
- 結論を最初に1段落（3文以内）で書く。
- 続けて「検討の経緯」を時系列で書く。各項目の先頭に会議の日付を置く。
- 「検討した選択肢」は表にする。列は「案 / 主な利点 / 主な懸念 /
  会議での扱い」とする。
- 金額、期間、人数は、会議で出た数値のみを記載し、出典となる会議の
  日付を括弧書きで添える。
- 未解決の論点を最後に箇条書きで残す。
- 推測や一般論を補わない。記録にない事項は書かない。

#障害対応の時系列を整理する

選択した会議の記録から、障害対応の時系列（タイムライン）を作成して
ください。読み手は、対応に参加していない開発チームと運用チームです。

守ってほしいこと:
- 「検知 / 一次対応 / 原因の切り分け / 恒久対応 / 未完了の作業」の
  5つの区分で整理する。
- 各行は「時刻 / 事象 / 誰が対応したか」の形式にする。時刻が会議で
  述べられていない場合は「時刻不明」と書き、順序だけを保つ。
- 原因について、確定した事実と仮説を分けて書く。仮説には「（仮説）」
  と付ける。
- 再発防止として会議で合意された対応を、担当と期限つきの表にまとめる。
- 個人の責任に関する評価は書かない。

#顧客の要望を製品開発向けに整理する

選択した顧客との打ち合わせの記録から、製品への要望を整理してください。
読み手は製品開発の担当者で、商談には同席していません。

規則:
- 常体で書く。
- 要望を「機能の追加」「既存機能の改善」「不具合の指摘」「運用上の
  相談」の4つに分類する。どれにも当てはまらないものは分類しない。
- 各要望について、次を必ず書く:
  顧客名（正式名称）/ 発言の要旨 / 発言があった会議の日付 /
  顧客が挙げた理由
- 同じ内容の要望が複数の顧客から出ている場合は1項目にまとめ、
  顧客名を並べて書く。
- 優先順位を独自に判断しない。件数の多い順に並べるだけとする。
- 記録に出てこない機能名や仕様を推測で補わない。

#うまくいかないときは

実行のたびに形式が変わる

出力の形式を指定していないか、指定が抽象的です。見出しの名前と並び、表の列、項目数、1項目あたりの長さを、具体的な数値で書いてください。

指示した規則が守られない項目がある

規則が長すぎる場合、後半の指示が反映されにくくなることがあります。重要な規則を先頭に移すか、レシピを2つに分けて段階的に実行してください。

社外に出せない表現が混ざる

社内の略語や内部の呼称を、正式名称へ置き換える規則を明示してください。社外向けのレシピには、「社内でのみ使う呼称を出力しない」という規則を入れておきます。

案件ごとに条件を変えたい

レシピは変数に対応していないため、条件を直接書き込んだレシピを別々に作ります。詳しくはレシピ（定型指示）をご覧ください。

#関連記事