議事録 AI プロンプト実例集｜構造化・要約・アクション抽出

Q: 機密会議の議事録を外部 API に投げるのはリスクではないですか？

A. そのとおりです。経営会議・人事評価などは Azure OpenAI / Bedrock のような 企業向け閉域プラン を使うか、オンプレ LLM を検討してください。API ログのオプトアウト設定も必須です。

Q: プロンプトのバージョンはどう管理すべきですか？

A. Git で管理するのが鉄板です。 prompts/meeting_minutes/v3.2.txt のように議事録用途ごとにファイル分割し、評価スコアを CI でレポートさせると運用が崩れません。

Q: SaaS の AI 議事録ツールと自前プロンプト、どちらが良いですか？

A. 一般的な社内会議は SaaS で十分です。ただし 独自の出力フォーマット・社内システム連携・機密レベル のいずれかが要件にある場合は、自前プロンプト＋API 直叩きのほうが総合コストで有利になるケースが多いです。

こんにちは！株式会社雲海設計の技術部です。

「文字起こしを ChatGPT に貼っただけの議事録が、肝心の決定事項を落としている」「Claude に要約させたら話者が入れ替わっていた」——2025 年に AI 議事録 SaaS が乱立した結果、2026 年に入って逆に「プロンプト設計を自前で握り直したい」という相談が急増しています。本記事では、業務に耐える議事録 AI プロンプトを ChatGPT / Claude で設計するためのパターンを、構造化・要約・アクション抽出・話者識別の 4 軸で整理します。

TL;DR
議事録 AI プロンプトの肝は「役割定義・出力スキーマ・抽出規則・検証条件」の 4 層を分けて書くこと
「要約して」だけでは 7 割の現場で失敗する。JSON スキーマ指定＋Few-shot＋否定命令が 2026 年の標準
アクション抽出は「担当者・期限・依存関係」の 3 フィールド必須化で精度が一段上がる
話者識別は LLM 単体では不安定。文字起こし側の diarization を信頼し、LLM は正規化のみに役割を絞る
プロンプトは評価セットとセットで管理しないと、モデル更新のたびに品質が揺れる

なぜ「要約して」だけのプロンプトは業務で使えないのか？

結論から言うと、議事録は要約タスクではなく構造化抽出タスクだからです。ここを取り違えると、どれだけ高性能なモデルでも現場で使い物になりません。

現場で起きている典型的な失敗

決定事項の欠落：発言量の多い雑談パートが要約に引っ張られ、1 行だけ言及された重要決定が消える
アクションの曖昧化：「〜を検討する」で終わり、担当者と期限が議事録に残らない
話者の混線：A さんの反対意見が、B さんの発言として要約される
文体の暴走：「〜という議論が活発に交わされました」のような、後で読むと情報量ゼロの文が量産される

MIT Sloan が 2025 年末に公開したレポートでも、業務系 LLM 活用の失敗要因 1 位は「出力形式の曖昧さ」でした。議事録はこの失敗を最も踏みやすいタスクと言えます。

LLM は「何を書くか」より「どの枠に何を埋めるか」を指定したほうが安定する。要約は副産物である。

議事録の周辺論点は過去記事の議事録作成だけで終わってない？会議の記録を活かす方法でも扱っていますので、運用設計側の視点はそちらもご参照ください。

議事録 AI プロンプトの 4 層構造とは？

私たちが顧客の社内導入で使っているプロンプトは、必ず次の 4 層に分けて書きます。この順序を崩すと精度が落ちます。

層

目的

書くべき内容

① 役割定義

モデルの立ち位置を固定

「あなたは B2B SaaS の PM 向け議事録編集者である」

② 出力スキーマ

構造を強制

JSON / Markdown テンプレの明示

③ 抽出規則

判断基準を固定

「決定事項とは〜、アクションとは〜」の定義

④ 検証条件

自己チェックを強制

「全アクションに担当者と期限があることを確認せよ」

基本テンプレート (Claude / ChatGPT 共通)

あなたは B2B 企業の会議議事録を整理する編集者です。
以下の文字起こしから、指定スキーマに沿って議事録を生成してください。

# 出力スキーマ (JSON)
{
  "meeting_title": string,
  "date": "YYYY-MM-DD",
  "attendees": string[],
  "summary": string,           // 3〜5 文、事実のみ
  "decisions": [                // 決定事項
    { "topic": string, "decision": string, "rationale": string }
  ],
  "actions": [                  // アクション
    { "owner": string, "task": string, "due": "YYYY-MM-DD|未定", "depends_on": string|null }
  ],
  "open_questions": string[]    // 未決事項
}

# 抽出規則
- 決定事項: 明示的に合意された事項のみ。「検討する」は決定に含めない
- アクション: 主語・動詞・期限のいずれかが明示された発言のみ
- 推測で埋めない。情報がない場合は "未定" または null を使う
- summary には感情表現・評価語を含めない

# 検証
出力前に以下を自己チェックし、満たさない場合は修正せよ:
(1) 全 decision に rationale がある
(2) 全 action に owner と due がある (未定も可)
(3) JSON として valid

# 入力 (文字起こし)
"""
{{TRANSCRIPT}}
"""

このテンプレートを社内の議事録 AI の基底プロンプトにするだけで、アクション抽出の欠落率が体感で 4 割以上改善します。プロンプトを「依頼文」ではなく「仕様書」として書くのがコツです。

アクション抽出の精度を上げるプロンプト設計は？

結論から言うと、「担当者・期限・依存関係」の 3 フィールドを必須化し、未定を許容するのが正解です。

よくあるアンチパターン

「ToDo を抽出して」だけで投げる → 「〜について議論する」レベルの空アクションが量産される
期限を必須にする → モデルが発言にない期限を捏造し始める
曖昧な表現を残す → 「田中さん側で進める」のような、誰が何をするか不明な記述が残る

正解パターン: Few-shot でエッジケースを教える

# アクション抽出の例

入力: 「じゃあ山田さん、来週金曜までにワイヤー作ってもらえる？」
出力: { "owner": "山田", "task": "ワイヤーフレーム作成", "due": "2026-05-01", "depends_on": null }

入力: 「API 仕様が固まったら、実装着手ということで」
出力: { "owner": "未定", "task": "実装着手", "due": "未定", "depends_on": "API 仕様確定" }

入力: 「いい感じですね」
出力: (アクションではないため抽出しない)

3 例でいいので、「抽出しない例」を必ず 1 つ混ぜるのがコツです。これを入れないと、モデルは何でもアクションに寄せてしまいます。プロンプト設計の一般論は ChatGPT に仕様書やメールを書かせるプロンプト術も参考になります。

話者識別は LLM に任せるべきか？

結論から言うと、話者識別 (diarization) は LLM に任せず、文字起こしエンジン側の話者タグを信頼するべきです。LLM の役割は「発言主の正規化」に限定します。

なぜ LLM 単体だと不安定なのか

長い文字起こしではコンテキストが薄まり、話者のクセを追えなくなる
代名詞（「私」「こちら」）の解決がモデルによってブレる
評価が難しく、間違いに気づきにくい（読むと自然に見えてしまう）

正しい分業: 文字起こし側と LLM の役割

工程

担当

出力

音声 → テキスト

Whisper / AssemblyAI / Azure Speech

[Speaker_01] 発話内容 ...

話者 ID → 実名

LLM (マッピング表を渡す)

[山田 PM] 発話内容 ...

議事録生成

LLM (基底プロンプト)

構造化 JSON

話者マッピング用プロンプト例

次の参加者リストと発話冒頭を照合し、Speaker_XX を実名にマッピングせよ。
確信が持てない場合は "不明" のまま残し、推測で埋めない。

参加者: 山田 (PM), 佐藤 (エンジニア), 鈴木 (デザイナー)

[Speaker_01] (冒頭) 「今日の議題は要件定義のレビューです」
[Speaker_02] (冒頭) 「API 側の懸念から共有させてください」
[Speaker_03] (冒頭) 「UI のパターンを 3 案用意しました」

出力: { "Speaker_01": "山田", "Speaker_02": "佐藤", "Speaker_03": "鈴木" }

「推測で埋めない」という否定命令が効きます。Claude 系は特にこの指示を忠実に守る傾向があり、業務利用では精度が安定します。

プロンプトを継続運用するにはどうするか？

結論から言うと、プロンプトはコードと同じく評価セットとバージョン管理をセットで運用する必要があります。これを怠ると、モデル更新のたびに議事録品質が揺らぎます。

最低限揃えるべき運用要素

評価セット: 過去の議事録 20〜50 本を「正解 JSON」付きで保管
回帰テスト: プロンプト変更時に全件再生成し、decision / action の一致率を自動計測
モデル固定: 業務運用では gpt-4o-2024-11-20 のように日付付きで固定
ログ保全: 入力文字起こし・プロンプト・出力を 3 点セットで保存（監査用）

この考え方はハーネスエンジニアリングベストプラクティスで深掘りしているので、本番運用を目指す方は併読をおすすめします。また、社内ナレッジとして議事録を活かす設計はナレッジ管理×生成 AI の実装設計が参考になります。

評価指標の例

# 議事録評価の最小構成
def evaluate(pred: dict, gold: dict) -> dict:
    return {
        "decision_recall": match_ratio(pred["decisions"], gold["decisions"]),
        "action_recall":   match_ratio(pred["actions"],   gold["actions"]),
        "owner_accuracy":  field_accuracy(pred["actions"], gold["actions"], "owner"),
        "hallucination":   hallucination_rate(pred, gold),  # gold にない情報の混入率
    }

雲海設計の実運用では、decision_recall と hallucination の 2 指標を最重要 KPI に置いています。経験上、この 2 つが安定すれば現場からの「議事録が信用できない」というクレームはほぼ消えます。

雲海設計の支援サービス

私たちは議事録 AI に限らず、業務プロセスに LLM を組み込む際のプロンプト設計・評価基盤・権限設計まで一気通貫で支援しています。「SaaS を導入したが現場で定着しない」「自社データに合わせてプロンプトを握り直したい」といったフェーズの相談を多くいただいています。

DX ソリューション: 業務フロー設計から AI 組み込みまで
IT コンサルティング: 生成 AI 活用戦略・PoC から本番化
Web 開発・デザイン: 議事録 AI を組み込んだ社内ポータル開発
お問い合わせ: 現状のプロンプトレビューから承っています

よくある質問

Q. ChatGPT と Claude、議事録用途ではどちらが向いていますか？

A. 長文の文字起こし (1 時間超の会議) では Claude のほうが安定する傾向があります。一方、JSON スキーマ厳守や関数呼び出しを多用する場合は ChatGPT (GPT-4o 系) が扱いやすいです。両方を評価セットで比較してから選ぶことをおすすめします。

Q. 文字起こしの精度が低い場合、プロンプトで補えますか？

A. ある程度は補えますが限界があります。特に固有名詞・専門用語は文字起こし側にカスタム辞書を設定するほうが費用対効果が高いです。プロンプトは「誤認識を無視して文脈優先で解釈せよ」という指示までが現実的です。

Q. 機密会議の議事録を外部 API に投げるのはリスクではないですか？

A. そのとおりです。経営会議・人事評価などは Azure OpenAI / Bedrock のような企業向け閉域プランを使うか、オンプレ LLM を検討してください。API ログのオプトアウト設定も必須です。

Q. プロンプトのバージョンはどう管理すべきですか？

A. Git で管理するのが鉄板です。prompts/meeting_minutes/v3.2.txt のように議事録用途ごとにファイル分割し、評価スコアを CI でレポートさせると運用が崩れません。

Q. SaaS の AI 議事録ツールと自前プロンプト、どちらが良いですか？

A. 一般的な社内会議は SaaS で十分です。ただし独自の出力フォーマット・社内システム連携・機密レベルのいずれかが要件にある場合は、自前プロンプト＋API 直叩きのほうが総合コストで有利になるケースが多いです。

←ブログ一覧に戻る

議事録 AI プロンプト設計完全ガイド｜構造化・要約・アクション抽出の実例集