会議のメモを AI に整理してもらいたいのに、思ったような形で返ってこない ── そんな経験はないでしょうか。本記事では、依頼のときに添える「前置き」に何を書いておくと出力条件がはっきりするかを、よくある場面別のテンプレート案として整理します。
前置きの有無で出力がどう変わるかの比較は、今回行っていません。 以下のテンプレート案は、出力条件（目的・粒度・形式）を言葉にしておくための雛形で、効果を実測した結果ではありません。
この記事には、実際に試した記録が含まれています。 録音した会議を題材に、文字起こしから議事録の整形までを一度通してみました。題材にしたのは、検証用に台本を用意して実施した、架空の Web サイト制作会議です。実際の業務の会議ではありません。ただし、録音・文字起こし・AI による整理・人の目での照合という工程は、すべて実際に手を動かして試しました。
条件は次のとおりです。
- 会議: 検証用に作成した架空の Web サイト制作会議（参加者 3 人）
- 録音: 4 分 52.672 秒 / iPhone の「ボイスメモ」
- 文字起こし:
mlx-community/whisper-small-mlxを Mac の中でローカル実行 - 議事録の整理: Codex（GPT-5 系）。使用したモデル ID は取得できなかったため記載しません
- 実施日: 2026-09-19
今回の検証で使ったのは Codex で、ChatGPT ではありません。 両者を比較していないので、ここに書く結果は ChatGPT 固有の挙動ではありません。また、前置きの内容を変えた比較実験も行っておらず、実際に投げたプロンプトも保存していません。そのため、プロンプトの再現や効果の比較はこの記事では扱いません。
登場人物は社員 A・社員 B・社員 C、案件名は架空の「プロジェクト・リベット」です。実在の会社名・顧客名・金額は含みません。録音そのもの、台本の全文、文字起こしの全文は公開しません。掲載するのは、確認のうえで公開すると決めた短い抜粋だけです。
今回の検証で確認できたのは、次の 4 点だけです。
- 「GA4」が「JAF4」として文字起こしされた
- 「Cocoon」が「国務」として文字起こしされた
- 「まだ決めないでください」と言われていた担当が、AI 整理直後には「決定済み」として書かれていた
- 録音・台本・文字起こし・AI 出力を突き合わせることで、1〜3 を修正できた
これ以外の箇所については、検証していません。記事中の手順やテンプレート案は、この 4 点とは別の、一般的な提案として読んでください。
議事録づくりのどこを AI に任せるか
「議事録を AI に任せる」と言っても、工程はいくつかに分かれます。整理すると、だいたい次の 4 つです。
- 録音: 会議の音声をファイルとして残す
- 文字起こし: 音声をテキストに変換する
- 要点抽出: テキストから決定事項や次のアクションを取り出す
- フォーマット統一: 決めた型に沿って整える
この記事で扱う「前置き」が関わるのは、3 と 4 の工程です。1 と 2 は別の道具の話になります。今回の検証では、文字起こしの誤り（GA4 → JAF4）が、AI 整理後の文章にもそのまま引き継がれていました。 問題が出たのは、2 の文字起こしと、3 の要点抽出の段階です。
文字起こしをどこで動かすか
文字起こしの実行場所は、大きく 3 つに分かれます。
- 自分のパソコンの中で動かす（ローカル実行）
- API 経由で外部へ送る
- 専用の文字起こしサービスを使う
今回は 1 つ目を選びました。mlx-community/whisper-small-mlx を Mac の中で動かしています。音声を外に出さずに試せるからです。3 つ目の専用サービスは今回使っていないので、使用感は書けません。
判断の材料になりそうな点を、公式の情報で確認できる範囲だけ書いておきます（いずれも 2026-09-19 時点の記載です）。
API 経由で送る場合
OpenAI の Speech to text ガイド によれば、文字起こしは /v1/audio/transcriptions を使い、ファイルは 25 MB まで、対応形式は mp3 / mp4 / mpeg / mpga / m4a / wav / webm です。これを超える録音は、圧縮するか 25 MB 以下に分割します。分割するときは文の途中で切らないように、とも書かれています。
データの扱いは、Your data のエンドポイント別の表で確認できます。/v1/audio/transcriptions の行は、学習に使用: No / 不正利用監視の保持: なし / アプリケーション状態の保持: なし / Zero Data Retention の対象: Yes です。同じ表の別のエンドポイントには「30 日」と書かれた行もあります。記載は API ごとに分かれているため、使う API の行を確認します。
自分のパソコンで動かす場合
Whisper の公式リポジトリ の実装は pip install -U openai-whisper で導入でき、別途 ffmpeg が必要です。モデルは 6 サイズあり、速度と精度のトレードオフがあると説明されています。派生の実装としては、依存のない C/C++ 実装の whisper.cpp（MIT ライセンス。Apple Silicon では Metal / Core ML を利用でき、CPU のみでも動作）や、CTranslate2 を使った faster-whisper（同じ精度で最大 4 倍速とリポジトリが説明していますが、こちらでは速度を計測していません）があります。
会議の内容によっては、「どこで動かすか」が使う・使わないの分かれ目になります。機密情報を含む会議での考え方は、後半の「個人情報・機密情報の扱いに気をつける」で触れます。
ChatGPT が議事録を「うまく整理できない」のはなぜか
ChatGPT は、渡された会議メモの「文脈」を、こちら側ほど詳しく知っているわけではありません。誰が話したか、その場で何が決まったか、どこが暫定でどこが確定か ── 投入する側にとっては当たり前の情報でも、AI には伝わっていない部分があります。
たとえば「以下のメモを議事録にしてください」という依頼文だけでは、希望する出力形式・粒度・決定事項の扱いが指定されていません。どの粒度でまとめるか、決定事項とアイデアをどう分けるかは、依頼した側が決めていない状態になります。
この記事の後半で挙げるテンプレート案は、その指定されていない部分を言葉にしておくための雛形です。
ただし、整理を頼む前の段階でテキストが間違っていれば、依頼の書き方をどう変えても元の発言には戻りません。今回の検証でも、文字起こしの段階で 2 か所外れました（使ったのは mlx-community/whisper-small-mlx です）。公開すると決めた 2 件を載せます。
| 実際の発言 | 文字起こしの出力 | 人が直した内容 |
|---|---|---|
| GA4 | JAF4 | 「JAF4」→「GA4」 |
| Cocoon | 国務 | 「国務」→「Cocoon」 |
どちらも、録音と台本の該当箇所を聞き直して、実際の発言を確認しました。なぜこの形に外れたのかは書きません。条件を変えて再実行していないので、こちらで確かめられていないからです。わかっているのは「この 2 か所が外れた」という事実と、「照合すれば直せた」という結果だけです。
やっかいなのは、文字起こしの誤りはそのまま次の工程へ流れていくことです。AI は渡されたテキストを前提に整理するので、「JAF4」と書かれていれば、その語をそのまま議事録に載せてきます。
前置きに書いておく 5 つの情報（テンプレート案）
議事録の整理を依頼するとき、出力の条件を言葉にしておくための項目として、次の 5 つを前置きに置く形が考えられます。ここから先は、検証結果ではなくテンプレート案の紹介です。
- 会議の種類: 社内定例 / 顧客打合せ / 社外勉強会 / プロジェクト報告など
- 参加者の役割: 上司・同僚・取引先など、文脈に必要な範囲で
- 整理の目的: 共有用 / 自分用の覚書 / 上司への報告 / 議事録ファイル化など
- 求める粒度: 全体要約 / 発言ベース / 決定事項+タスクのみ など
- 出力形式: 箇条書き / 表 / 区切り見出しつき など
すべてを毎回入れる必要はないと考えています。省くなら、会議の種類・目的・出力形式の 3 つを残す、という組み方にしています。ここで挙げた 5 項目と、以下の場面別の例文は、いずれも出力条件を明確にするためのテンプレート案で、効果を比較検証したものではありません。
シチュエーション別: 前置きのテンプレート案
1. 手書きメモを清書する
会議中に走り書きした断片的なメモを、人に見せられる形に整える場面です。
例:
以下は社内定例ミーティングで取った手書きメモです。誤字や省略が多く、文章として不完全な部分があります。意味が通じるように補完しつつ、決定事項・進行中の課題・次回までのタスクの 3 区分で箇条書きに整理してください。
この例文では、メモが不完全であることと、**希望する 3 区分（決定事項・進行中の課題・次回までのタスク）**を明示しています。
2. 録音の文字起こしを要約する
長文の文字起こしから、要点を抽出する場面です。
例:
以下は 60 分の打合せの文字起こしです。話者は弊社の担当者 2 名と取引先の 1 名の計 3 名です。全体を 800 字程度で要約し、最後に「次回までのアクション」を箇条書きで 5 件以内にまとめてください。
この例文では、**要約の文字数（800 字程度）**と、**アクション項目の上限（5 件以内）**を指定しています。
今回の検証で起きたこと（整理に使ったのは Codex です。ChatGPT では試していません）
この工程で、事実がひとつ反転しました。同じ箇所の 3 段階を並べます。
① 文字起こし（未修正）
「JAF4の決定については、私が担当する可能性がありますので、まだ決めないでください」
「写真素材の最終確認担当とJAF4の担当決定は、設定担当は決定ですね」
② AI が整理した直後
写真素材の最終確認担当とJAF4の設定担当は決定済み
③ 人が直したあと
写真素材の最終確認担当とGA4の設定担当は、どちらも未決定
直したのは 2 か所です。ひとつは「JAF4」を「GA4」へ。文字起こしの誤りです。もうひとつは「決定済み」を「未決定」へ。こちらは事実が逆になっていました。
元の発言は「まだ決めないでください」でした。決まっていないことが、整理後には決まったことになっていた、ということです。文字起こしの側にも「担当決定は、設定担当は決定ですね」という崩れた言い回しが残っていました。**どちらがどう影響したのかは確かめていないので、ここでも原因は書きません。**確認できたのは、整理後の文章が事実と逆になっていたという結果だけです。
要約は、情報を削る作業です。今回の 1 件では、削る過程で事実の向きが変わっていました。決定事項まわりは、公開や共有の前に原文と突き合わせることを推奨します。
3. 決定事項とタスクを抽出する
長いメモから、決まったことと宿題だけを取り出す場面です。
例:
以下の会議メモから、決定事項とタスクのみを抽出してください。各タスクには、可能であれば担当者と期限を併記してください。本文中で担当者や期限が言及されていない場合は「未設定」と書いてください。
この例文では、担当者や期限が書かれていない場合の表記（「未設定」と書く）も指定しています。
今回の 1 件で確認できたこと: 抽出された「決定事項」「担当者」を、台本と録音の該当箇所に突き合わせて 1 件ずつ確認したところ、「決定済み」という記述が事実と逆であることがわかりました（詳細は下の before / after）。
編集方針として: 決定事項・担当者・期限は、公開や共有の前に原文と照合することを推奨します。
4. 議事録を共有用に整える
メモを、関係者に共有する正式な議事録に仕上げる場面です。
例:
以下のメモを、社内共有用の議事録に整えてください。冒頭に「日時・場所・参加者」のセクションを設け、本文は「議題」「議論内容」「決定事項」「次回までのタスク」の 4 セクションに分けてください。文体はですます調、見出しは Markdown 形式でお願いします。
この例文では、**共有用の議事録に必要な見出し構成（日時・場所・参加者 / 議題 / 議論内容 / 決定事項 / 次回までのタスク）**と、**文体（ですます調・Markdown 形式）**を先に指定しています。
利用先に合わせて出力形式を指定する
議事録は、その後 Slack に貼ったり、社内 Wiki に転載したり、Word に貼ったりと、いろいろな先で使われます。依頼の時点で、利用先に合わせて Markdown / プレーンテキスト / 表形式などを指定できます。
- Markdown 形式: Notion / GitHub / 各種メモアプリに貼りやすい
- プレーンテキスト + 箇条書き記号: メール本文や Slack に貼りやすい
- 表形式: スプレッドシートにコピーしたいとき (= 担当者・期限・内容など)
「あとで Notion に貼るので Markdown でください」は、用途と希望形式をセットで伝える例です。
個人情報・機密情報の扱いに気をつける
業務で議事録を扱う際は、利用規約と所属組織のルールに沿って情報を渡すことが前提です。
- 個人名、取引先名、未公表の数値などは、可能な範囲で伏字や匿名化を行ってから投入する
- 業務利用に対応した契約プラン (= 法人契約や入力履歴の扱いが明示されているもの) を選んでおく
- 各サービスの利用規約を確認し、所属組織のルールに従う
便利さと、組織として守るべき情報の扱いは別軸の話です。依頼文の工夫と同じくらい、ここも丁寧に扱っておく価値があります。
今回の検証でやったこと
今回は検証なので、会議そのものを「実在の情報が入らない形」で設計するところから始めました。手順としてはこうなります。
- 実在の顧客情報・実名・金額を含まない台本を用意し、その内容で録音した
- 登場人物は最初から社員 A・社員 B・社員 C、案件名は架空の「プロジェクト・リベット」とした
- 文字起こしは Mac の中でローカル実行し、音声を外部のサービスへ送っていない
- AI へ渡したのは、最初から実在情報を含まない状態で作られたテキストだけ（社員 A・社員 B・社員 C と架空の案件名で台本を書き、そのまま録音・文字起こしした。あとから置換する工程は挟んでいない）
公開のためには、さらに次の処理をしています。
- 掲載するのは、確認のうえで公開すると決めた短い抜粋だけ
- 音声・台本の全文・文字起こしの全文は公開しない
- 架空の会議である旨を本文に明記する
どこで動かすかも、この判断に含まれる
前半で書いた「文字起こしをどこで動かすか」は、この章と地続きです。実行場所を選ぶときの確認項目のひとつが、音声データを外部へ送信するかどうかです。ローカル実行なら音声はその端末内に留まり、API や外部サービスを使う場合は音声を送信することになります。どちらを選ぶかは、扱う会議の内容と、所属組織のルールに照らして決めることになります。
外部の API を使う場合は、サービス側の記載を確認することになります。記載はエンドポイントごとに分かれているため、使う API の行を見ます（具体的な記載は前半の「文字起こしをどこで動かすか」を参照）。記載は更新されることがあるので、確認した内容と確認日をあわせて記録しておく、という手順になります。
試すなら、整形だけから
手元にすでにテキスト化された会議メモがあるなら、整形だけを先に実行するという進め方があります。この場合、文字起こし工程を含まない条件で整形の結果を確認できます。
工程を足していく場合は、整形前のテキスト・文字起こし結果・AI 整理後の文章を、工程ごとに別々に保存しておくと、あとから並べて比較できます。なお、生成結果はそのつど変わりうるもので、条件を揃えた比較をしていない限り、差分がどの工程に由来するかは特定できません。
今回の検証では、文字起こしの誤り 2 件と、整理後の文章が事実と逆になっていた 1 件を、それぞれ別の工程の出力として記録しました。
まとめ
議事録のメモを AI に整理してもらうとき、出力の条件（会議の種類・目的・形式）を前置きで言葉にしておくのが、この記事で紹介したテンプレート案です。効果を比較したわけではないので、「これで安定する」とは書けません。あくまで、依頼の条件を決めておくための雛形です。
今回の検証で観測したのは、次の 3 件です。文字起こしの誤りが 2 件（GA4 → JAF4 / Cocoon → 国務）と、整理後の文章に、発言に対応しない記述が 1 件（「まだ決めないでください」と言われていた担当が「決定済み」と書かれていた）。いずれも、未修正の文字起こし・AI が整理した直後の出力・台本・録音の 4 つを突き合わせて確認しました。
この 3 件は、いずれも依頼文の内容ではなく、出力を原文と照合したことで見つかったものです。決定事項・担当・固有名詞については、公開や共有の前に原文と照合する、という手順を取っています。
繰り返し使う場面があれば、前置きのテンプレートをメモアプリなどに保存しておけば、次回はそれを読み込んで再利用できます。使ううちに項目を足したり削ったりして、自分の用途に合わせた版を保存し直すこともできます。
今回わかっていないこと
この検証は、4 分 52.672 秒の会議 1 件だけを対象にしています。これより長い会議、複数人が同時に話す場面、周囲の音が入る環境では試していません。別のモデルや別の文字起こしサービスとの比較もしていないので、「この方法がいちばん良い」という話はできません。
また、整理に使ったのは Codex であり、ChatGPT で同じことを試してはいません。前置きの内容を変えた比較もしておらず、実際に投げたプロンプトも保存していません。あくまで、1 回試して何が起きたかの記録です。
Photo by Startup Stock Photos on Pexels
