はじめに

この記事の対象者

macOSでChatGPT有料プラン（Pro/Team/Enterprise/Edu）を使用
Zoom/Teamsの議事録機能が使えない、または対面会議が多い環境
手動で議事録を書く時間を削減したい方

「会議の議事録作成を自動化したいけど、Teamsの議事録機能は使えない...」

こんな奇特な悩みを抱えていませんか？私は抱えていました。

そんな時に「ChatGPT Record機能なんてものがあるのか」と知り、試してみたところ非常に便利でした。

使い方は至って簡単。ChatGPTのmacOSデスクトップアプリ版を起動し、このボタンを押すだけ。

Recordボタン

私の場合、手動で議事録を書くと30分かかっていましたが、この方法で3分に短縮できました。

ChatGPT Record機能とは

この記事は2026年1月時点の情報です。ChatGPT macOSデスクトップアプリのRecord機能について記載しています。

ChatGPTのmacOSデスクトップアプリに搭載されている録音・要約機能です。会議を録音すると自動で要約を生成してくれます。

詳しい機能説明は公式ヘルプを参照してください。

実際に使ってみた

試しに、架空のプロジェクト進捗会議の原稿を読み上げて、Record機能で議事メモを作成してみました。

読み上げた原稿（約8分）

田中:
それでは、週次の進捗会議を始めます。本日の議題は3つあります。1つ目がバックエンド開発の進捗、2つ目がフロントエンド開発の進捗、3つ目が来月のリリースに向けたスケジュール確認です。まず、バックエンドチームの佐藤さんから報告をお願いします。

佐藤:
はい、佐藤です。今週の進捗を報告します。まず、APIの認証機能の実装が完了しました。JWT認証を採用していて、アクセストークンの有効期限は1時間、リフレッシュトークンは2週間に設定しています。テストも全て通っていて、カバレッジは85%を達成しています。来週にはステージング環境にデプロイできる予定です。

ただ、一点課題がありまして、レスポンス速度が想定より遅いです。現状、認証APIのレスポンスが500ミリ秒くらいかかっています。調査したところ、データベースへのクエリが3回発生していて、それがボトルネックになっているようです。

田中:
500ミリ秒は確かに遅いですね。目標は200ミリ秒以内でしたよね？ユーザー体験に影響が出そうです。

佐藤:
はい、その通りです。改善策として2つ考えています。1つ目はRedisを使ったキャッシュの導入です。ユーザー情報をキャッシュすることで、データベースへのアクセスを1回に減らせます。2つ目はクエリの最適化です。現在、3つのテーブルを別々にクエリしているのを、JOINを使って1回のクエリにまとめることができます。

田中:
なるほど。どちらの方法が現実的ですか？

佐藤:
短期的にはクエリの最適化が早いです。今週中に対応できます。キャッシュの導入は、Redisの環境構築も必要なので、来週以降になります。ただ、将来的なスケーラビリティを考えると、キャッシュは必須だと思います。

田中:
では、まずクエリの最適化を今週やって、キャッシュは来週から着手という方針でいきましょう。インフラチームにもRedisの環境構築を依頼しておきます。他にバックエンドで何かありますか？

佐藤:
あと一点、ユーザー登録APIで、メールアドレスの重複チェックを追加しました。同じメールアドレスで登録しようとすると、409エラーを返すようになっています。あと、パスワードのバリデーションも強化しました。最低8文字、大文字小文字と数字を含む必要があります。

田中:
セキュリティ面の強化、いいですね。ありがとうございます。では次、フロントエンドの山田さん、お願いします。

山田:
はい、山田です。フロントエンドの進捗を報告します。今週は主に3つの画面を実装しました。ログイン画面、ユーザー登録画面、そしてダッシュボードです。

ログイン画面は、メールアドレスとパスワードの入力フォームに加えて、パスワードを忘れた場合のリンクも実装しました。バリデーションはリアルタイムで行っていて、入力中にエラーメッセージが表示されます。

ユーザー登録画面は、佐藤さんが言っていたパスワードのバリデーションルールをフロントエンドでも実装しています。パスワード強度のインジケーターも付けました。弱い、普通、強いの3段階で表示されます。

田中:
パスワード強度のインジケーター、いいですね。ユーザーにとってわかりやすいです。

山田:
ありがとうございます。ダッシュボードについてですが、こちらはまだ仮のデータで表示しています。グラフはChart.jsを使っていて、日別のアクティブユーザー数と、機能ごとの利用率を表示する予定です。APIとの繋ぎ込みは来週行います。

ただ、デザインチームからの最終確認がまだ来ていません。色味やフォントサイズの微調整が必要になるかもしれません。鈴木さん、いつ頃フィードバックもらえますか？

鈴木:
すみません、今週中に確認します。大きな変更はないと思いますが、ボタンの色とフォントの行間を少し調整してもらうかもしれません。

山田:
わかりました。では今週中にフィードバックをいただいて、来週の前半で修正します。あと、来週の金曜日にユーザーテストを予定しているので、それまでにバグを潰しておきます。現在、既知のバグが5件ありますが、いずれも軽微なものです。

田中:
ユーザーテストは何名で行う予定ですか？

山田:
社内から5名を予定しています。営業部から2名、カスタマーサポートから2名、あと経理から1名です。実際のユーザーに近い視点でフィードバックをもらいたいと考えています。

田中:
いい人選ですね。テスト後のフィードバックは、どうやって収集しますか？

山田:
Googleフォームでアンケートを用意しています。使いやすさを5段階で評価してもらうのと、自由記述で改善点を書いてもらいます。あと、テスト中の様子は画面録画しておいて、後で分析します。

田中:
完璧ですね。ありがとうございます。では、3つ目の議題、来月のリリースに向けたスケジュール確認に移ります。

現在の予定では、2月15日にベータ版をリリースする予定です。そこから2週間のベータテスト期間を経て、3月1日に正式リリースという流れです。このスケジュールで問題ないか、各チームの見解を聞かせてください。

佐藤:
バックエンドは問題ないです。2月10日までに全てのAPIを完成させて、残りの5日間でバグ修正とパフォーマンスチューニングに充てる予定です。

山田:
フロントエンドも大丈夫です。ユーザーテストのフィードバックを反映して、2月12日までに実装を完了させます。

鈴木:
デザインも問題ありません。来週中に全ての最終デザインを納品します。

田中:
素晴らしい。では、このスケジュールで進めましょう。最後に、来週のアクションアイテムをまとめます。

佐藤さんは、今週中にクエリの最適化、来週からキャッシュ導入の着手。山田さんは、デザインフィードバックの反映とバグ修正、金曜日のユーザーテスト実施。鈴木さんは、今週中にフロントエンドのデザイン最終確認。私の方で、インフラチームにRedis環境構築を依頼します。

次回の会議は来週月曜日の10時、同じ場所で行います。何か質問はありますか？

なければ、本日の会議は以上です。皆さん、お疲れ様でした。

この原稿を録音した結果、以下のような要約が生成されました。

Record機能が生成した要約

生成された要約の全文

Date/Time: 2026-01-16 00:28 JST

Overall Summary

バックエンドの認証APIが完成しテストも完了したが、レスポンス速度の遅延が課題。クエリ最適化を今週中に実施し、Redisキャッシュ導入は来週から開始予定。フロントエンドはログイン、登録、ダッシュボード画面を実装し、ユーザーテスト準備中。リリースは2月15日にベータ版、3月1日に正式版を予定している。

Key Points

バックエンドのJWT認証機能が完成し、テストカバレッジ85%を達成。レスポンス速度が500msと目標の200msを超えているため、クエリ最適化とRedisキャッシュ導入を計画中。
フロントエンドはログイン、ユーザー登録、ダッシュボード画面を実装し、パスワード強度インジケーターやリアルタイムバリデーションを導入。デザインチームの最終確認待ち。
ユーザーテストは社内5名で金曜日に実施予定。Googleフォームでフィードバック収集し、画面録画も行う。
リリーススケジュールは2月15日にベータ版リリース、3月1日に正式リリース。各チームは2月上旬までに開発完了とバグ修正を目指す。

Action Items

佐藤さん：今週中にクエリ最適化対応、来週からRedisキャッシュ導入開始。
山田さん：デザインフィードバック反映とバグ修正、金曜日のユーザーテスト実施準備。
鈴木さん：今週中にフロントエンドデザインの最終確認。
司会者：インフラチームにRedis環境構築を依頼。

8分の会議が、要点を押さえた要約に自動変換されました。

ちなみに、タイトルが「習字プロジェクト進捗会議」になっていますが、正しくは「週次プロジェクト進捗会議」です。音声認識なので、このような誤変換は起こり得ます。気づいたら手動で修正しましょう。

ただ、このままだと内容が簡潔すぎるので、任意のフォーマットに変更する方法をTip 2で紹介します。

ここからは、私が実際に使っている運用Tipsです。

Tip 1: 「議事メモ」専用プロジェクトで管理する

議事録は後から振り返りたいことが多いですよね。しかし、通常のチャットと同じ場所に並ぶと探しづらくなります。

おすすめ: 「議事メモ」という専用プロジェクトを作成し、議事録を集約します。

「議事メモ」専用プロジェクト

専用プロジェクトを使うと、過去の議事録が一覧化されて探しやすくなります。検索もプロジェクト内で完結するので、他のチャットと混ざらず便利です。

Tip 2: 社内フォーマットに変換する

先ほど示した要約結果（Overall Summary、Key Points、Action Itemsなど）は便利ですが、そのままでは社内で求めるフォーマットと異なることが多いです。

そこで、チャットでフォーマットを指定して変換を依頼します。

フォーマットを指定して変換を依頼

私は以下のようなフォーマットを使っています。

指定するフォーマットの例

# 議事録

## 基本情報

| 項目   | 内容 |
| ------ | ---- |
| 会議名 |      |
| 日時   |      |
| 場所   |      |
| 参加者 |      |
| 記録者 |      |

## 議題

## 議論内容

### 議題1:

**報告事項**: **議論**: **決定事項**:

## アクションアイテム

| 担当者 | タスク | 期限 |
| ------ | ------ | ---- |

## 次回会議

フォーマットに沿った議事録に変換してくれます。

変換後の議事録（例）

社内フォーマットに変換された議事録

議事録

基本情報

項目	内容
会議名	プロジェクト進捗会議
日時	2026-01-16 00:28〜00:34
場所	会議室A
参加者	佐藤、山田、鈴木他
記録者	***

議題

バックエンド開発の進捗
フロントエンド開発の進捗
来月リリースに向けたスケジュール確認

議論内容

議題1: バックエンド開発の進捗

報告事項:

APIの認証機能（JWT認証）の実装が完了
テストは全て通過し、カバレッジは85%
認証APIのレスポンスが約500msと想定より遅い

議論:

目標レスポンスは200ms以内であり、現状はユーザー体験に影響が出る懸念
改善策として「クエリ最適化」と「Redisキャッシュ導入」を検討

決定事項:

今週中にクエリ最適化を実施
来週からRedisキャッシュ導入に着手

議題2: フロントエンド開発の進捗

報告事項:

ログイン画面、ユーザー登録画面、ダッシュボード画面を実装
デザインチームからの最終確認待ち

決定事項:

今週中にデザイン最終フィードバックを受領
金曜日にユーザーテストを実施

議題3: 来月リリースに向けたスケジュール確認

決定事項:

2月15日にベータ版リリース、3月1日に正式リリースで進行

アクションアイテム

担当者	タスク	期限
佐藤	クエリ最適化対応	今週中
佐藤	Redisキャッシュ導入着手	来週
山田	デザイン反映・バグ修正	来週前半
山田	ユーザーテスト実施	来週金曜日
鈴木	フロントエンドデザイン最終確認	今週中

次回会議

日時: 来週月曜日10:00
議題（予定）: 各チームの対応結果確認

Tip 3: Markdown形式で共有する

作成されたCanvasはMarkdown形式でコピー・エクスポートできます。

操作手順

Canvas上部の「...」メニューをクリック
「Copy as Markdown」を選択
Slack/Notion等に貼り付け

Canvasから「Copy as Markdown」を選択

Markdownでコピーできると、Slackやメールでサッと共有できますし、社内WikiやNotionへの貼り付けも簡単です。わざわざ別ツールで整形する必要がありません。

注意点

話者分離ができない

Record機能は「誰が話したか」を区別しません。複数人の会議を録音しても、発言者の情報は含まれないため、必要に応じて手動で補足する必要があります。

英語で出力されることがある

日本語の会議を録音しても、要約が英語で出力されることがあります。その場合は、チャットで「日本語に翻訳して」と指示すれば変換できます。

まとめ

ChatGPT Record機能を使った議事録作成のTipsをまとめました。

専用プロジェクトで管理 - 議事録を一箇所に集約して探しやすく
社内フォーマットに変換 - フォーマットを指定するだけで自動変換
Markdown形式で共有 - チームへの共有が手軽

ZoomやTeamsの議事録機能が使えない環境でも、この方法なら議事録作成の負担を大幅に減らせます。ぜひ試してみてください。