毎週の定例会議が増えるほど、議事録の作成と共有に追われていませんか。じつはClaude Codeを使えば、会議の文字起こしを探して取得し、Notionなどの管理ツールへ反映する一連の作業を自動化できます。ただし、既存の記録を誤って上書きしたり、同じリンクを関係者全員分に流し込んでしまったりする落とし穴もあります。議事録づくりに時間を取られたくないなら、仕組み化の勘所を押さえましょう。ここでは、GOROが実際の業務で設計し、運用しながら直してきた仕組みをもとに、文字起こしの集め方から定期実行の設定、運用で見えた注意点までを解説します。
Claude Codeは議事録作成をどこまで自動化できるのか
Claude Codeは、会議の文字起こしを取得する工程と、その内容を管理ツールに書き込む工程、さらに毎週決まった時刻に実行する工程までを一つの仕組みにできます。議事録そのものを「書く」作業というより、散らばった素材を「集めて整えて記録する」作業を代わりに担う範囲だと捉えるとわかりやすいでしょう。
議事録の「集めて整える」作業をAIに任せるとはどういうことか
議事録作成の手間は、文章をまとめる作業だけではありません。会議ごとに違う場所にある素材を探し、正しい記録先に反映する作業にもかかります。会議の録画や自動文字起こしはGoogle DriveやZoomなど複数のサービスに分散しており、記録先もNotionやスプレッドシートなど会議の種類によって異なります。
この「探す」「突き合わせる」「書き込む」を一連の手順として実行する仕組みが、議事録同期の自動化にあたります。たとえば1週間分の会議を対象に、会議ごとのフォルダへ文字起こしを蓄積し、管理ツールの該当レコードへリンクを反映する、という流れを一括で任せられます。開催されなかった会議は静かに飛ばし、対象外と決めた会議には手を出さない、という区別も手順に含められます。
「スキル」という仕組みで自動化が成り立っている
この一連の手順は、Claude Codeの「Agent Skills」という機能の上に作られています。Agent Skillsは、指示やスクリプトなどのリソースをひとまとめにした、Claudeの能力を広げるモジュールだと公式に説明されています。通常のプロンプトと違い、必要なタスクのときだけ自動で読み込まれるため、同じ指示を毎回の会話で繰り返す必要がありません(Agent Skills - Claude Platform Docs)。
公式ブログでも、Skillは指示・スクリプト・リソースを含むフォルダであり、Claudeはタスクに関連するときだけそのSkillを読み込むと説明されています(Introducing Agent Skills)。GOROの社内で運用している議事録同期の仕組みも、会議の種類ごとの手順をこのSkillとしてまとめたものです。複数の定例会議や商談、月末の振り返りまで、対象ごとに守るべき条件を一つの手順書に収めています。
ターミナルだけでなくデスクトップアプリ・ブラウザでも動く
Claude Codeというと、黒い画面(ターミナル)で操作するツールだという印象を持つ人も多いかもしれません。しかし公式ドキュメントでは、ターミナルに加えてIDE・デスクトップアプリ・ブラウザで動くエージェント型ツールだと説明されています(Overview - Claude Code Docs)。ターミナルの操作に慣れていなくても、デスクトップアプリやブラウザから使えます。
定期実行の仕組みも2種類あります。クラウドで動く「Routines」はパソコンの電源が切れていても動き続け、「Desktop scheduled tasks」は手元のファイルに直接アクセスしながらマシン上で動作します(Overview - Claude Code Docs)。議事録を決まった時刻に取りに行く作業は、このどちらかの仕組みに乗せて動かせます。
また、Model Context Protocol(MCP)という仕組みを使うと、Google Drive・Jira・Slackなど外部ツールとの連携もできます(Overview - Claude Code Docs)。議事録の記録先に管理ツールを選ぶ場合も、この連携が選択肢の一つになります。Notionとの連携で実際につまずいた点はNotionとClaude Codeの連携でできること・つまずきで詳しく扱っています。
自動化の仕組み:会議の文字起こしをどう手に入れるか
議事録を自動化する最初の工程は、文字起こしをどこで、どう手に入れるかを決めることです。会議の種類によって文字起こしの置き場所が違うため、それぞれに合った取得方法が必要になります。
| 取得元 | 保存場所 | 自動化の着眼点 | 注意点 |
|---|---|---|---|
| Gemini議事録(Google Doc) | Drive内の決まった命名規則 | 名前検索のあと作成日時で絞り込む | 候補が複数あると人の確認が要る |
| Google Meetの録画 | 主催者のDrive「Google Meet」フォルダ | Driveで指定日以降に作られた動画を探し、ローカルで文字起こしする | 外部に送らない設計にする必要がある |
| Zoomの自動文字起こし | Zoom内蔵の機能 | 会議中に自動で記録される | ブレイクアウトルームで前半が消えることがある |
Gemini議事録(Google Doc)を自動で探して取得する仕組み
Gemini議事録は、決まった命名規則でGoogleドキュメントとしてDriveに保存されます。社内で運用している取得用のスクリプトは、まず名前で検索し、見つからなければ作成日時で絞り込むという順番で候補を探す仕組みになっています。
文字起こしが本文とは別のタブに入っているドキュメントも、タブの中身まで含めて全文を取得します。候補が複数見つかった場合は、候補の一覧もあわせて出すようにしてあり、人の目で確認できます。取得した結果はドキュメントのID・名前・URL・本文という形でまとめて出すため、記録先への書き込み作業にそのまま渡せます。
Google Meetの録画をDriveから取得し外部に送信せず文字起こしする方法
Google Meetの録画は、主催者のGoogle Driveにある「Google Meet」という名前のフォルダに保存されます。フォルダの中には会議ごとのサブフォルダが作られると公式ヘルプで説明されています(Record a video meeting - Google Meet Help)。
社内の運用では、Driveで指定した日以降に作られた動画を探し、見つけたらダウンロードする仕組みを作っています。動画から音声だけを抜き出し、16kHz・モノラルの音声ファイルに変換したうえで、ローカルの文字起こしエンジンにかけます。「外部への送信は一切ない(Drive からの取得のみ)」という条件を、仕組みの前提にしています。
この確認作業は決まった時刻に繰り返す形にしてあり、「壁時計で判定するため、Macがスリープしても復帰時にすぐ追いつく」よう作ってあります。確認の回数は「依頼された3回 + 取りこぼし防止の予備4回(21:00まで)」にして、録画の取りこぼしを防いでいます。
Zoomの自動文字起こしを使うときに気をつけたいこと
Zoomにも会議中の自動文字起こし機能があります。ただし、途中でブレイクアウトルームに分かれる会議では、注意が必要です。
GOROでは2026年9月15日、顧客とのスライドのミーティングをZoomの自動文字起こしで記録していました。ブレイクアウトルームに入室したところで、ホスト側の参加者の文字起こしが前半まるごと消えました。別の参加者が12:24から手動で取り直した分だけが残り、前半はNotion AIの自動文字起こし(精度が低く、話者ラベルもない)で代替しました。
実録GOROの作業記録
Zoomのブレイクアウトルームで文字起こしの前半が消えた
Zoomの自動文字起こしは、ブレイクアウトルームに入室すると文字起こしデータがリセットされ、それまでの前半分が保存されない。
出典:GOROの社内の作業記録
ブレイクアウトを使う可能性がある会議では、Zoomの文字起こしだけを記録手段にしないほうがよいでしょう。Notion AI議事録やGemini、録画などの別系統を必ず並走させておくと、片方が消えても穴埋めができます。精度の低い代替文字起こしから議事録を書く場合は、固有名詞の誤変換が多く出るため、発言をそのまま引用するのは避けたほうが安全です。
Gemini・Meet・Zoomのどれを使う場合も、一つの記録手段だけに頼らない設計にしておくと安心です。
議事録をNotionなどの管理ツールに書き込む仕組み
MCP連携で外部ツールとつなぐ仕組み
前述のとおり、Claude CodeはMCPを使って外部ツールと連携できます。ただし公式ドキュメントが説明しているのは、外部ツールと接続できるという点までです。会議の記録先を間違えずに特定し、安全に書き込むところまでは、使う側が手順を組む必要があります。社内では、この書き込み部分を専用のスクリプトに切り出してNotionのAPIを直接呼ぶ形にし、2つの安全策を組み込んで運用しています。
既存レコードを上書きしない・複数一致したら止まる設計
社内で使っている書き込み用のスクリプトは、議事録DBのレコードを開催日で特定し、「AI議事録」というプロパティにGoogle DocのURLをセットする仕組みになっています。ここで重視しているのは、間違った上書きを起こさないことです。
「既にURLが入っているレコードは上書きしない(—force で上書き)」という挙動を基本にしています。一度記録済みのリンクを、別の会議の分で誤って塗りつぶす事故を防ぐための設計です。
該当するレコードが複数見つかった場合も、どれか一つを自動で選びません。デフォルトでは処理を中断し、候補の一覧を表示します。絞り込みが必要なときはタイトルの一部を指定し、全件に反映したいときだけ専用の指定で明示的に実行します。
実行前には、まず対象を確認するだけのモードで動かし、そのあとで本実行に進む手順を徹底しています。対象を変更せずに確認する工程を一段挟むことで、意図しないレコードへの書き込みを防いでいます。
| 場面 | 挙動 |
|---|---|
| 既にURLが入っている | 上書きしない(明示的な指定で上書き可) |
| 候補が複数ある | 処理を中断し一覧を表示する |
| 本実行の前 | 確認専用モードで対象を見てから進める |
Notionの日付フィルタでハマった落とし穴
NotionのURLプロパティは、ページへの書き込み時に文字列を渡すだけのシンプルな構造だと公式リファレンスで説明されています(Data source properties - Notion Docs)。構造自体は単純でも、書き込む前に対象レコードを日付で絞り込む段階には、見落としやすい挙動がありました。
実録GOROの作業記録
日付の範囲指定で片方の条件が黙って無視される
Notion日付フィルタの罠(重要):
{"date":{"on_or_after":X,"on_or_before":Y}}のように1つのdateオブジェクトに2条件を入れると片方が黙って無視され全件返る(エラーにならないので気づけない)。出典:GOROの社内の作業記録
見た目にはエラーが出ないため、絞り込みが効いていないことに気づきにくいのが厄介な点です。社内のスクリプトでは、日付の範囲を指定するときは必ずand条件で結合する実装にしています。単日で絞り込む場合は、範囲指定ではなくequalsを使います。
毎週自動で回す:定期実行(ルーティン)の組み方
書き込み先の安全策が整ったら、次は「毎週決まった時刻に動かす」部分の設計になります。前述のとおり定期実行には2種類の仕組みがあり、どちらを選ぶかで動き方が変わります。
クラウドで動くRoutinesとローカルで動くDesktop scheduled tasksの違い
2つの違いを整理すると、次の表のとおりです。
| 項目 | Routines | Desktop scheduled tasks |
|---|---|---|
| 実行場所 | クラウド | 手元のマシン |
| 公式の説明 | パソコンの電源が切れていても動き続ける。APIの呼び出しやGitHubのイベントでも起動できる | 手元のファイルやツールに直接アクセスできる |
社内の議事録同期は、手元のマシンで動くDesktop scheduled tasksに乗せています。取得した議事録は、手元の会議ごとのフォルダへファイルとして保存しています。
どちらを選ぶべきかは、扱う素材がクラウド上だけで完結するか、手元の環境を使う工程があるかで決まります。
金曜17時に設定した理由とスリープ対策
実行する曜日と時刻も、適当に決めているわけではありません。社内のルーティンは毎週金曜の17時に設定しています。「これはMacが開いていて通信できる時間帯を選んだ結果であり、意図的な設定。」という考え方に基づいています。
17時はその週の全社定例が始まる時刻にあたり、ほかの定例会議や商談、月末の振り返りはすでに終わっています。全社定例の分は、翌日の別の実行枠で回収する形にしています。
この時刻には前段階がありました。
実録GOROの作業記録
夜間実行で無言failした事故
以前は金曜21:00だったが、旭が外出しMacがクラムシェルスリープ中のDarkWakeで発火して、無言failする事故が起きた
出典:GOROの社内の作業記録
Macを閉じてスリープさせている間の一時的な復帰(DarkWake)で処理だけが始まり、何の通知もないまま失敗していました。この経験を受けて、2026年8月に17時へ前倒ししました。夜間の枠には戻さない方針です。実行結果を知らせるレポートには「冒頭に【meeting-sync 金曜17:00】と付けて、土曜10:30の二段目のレポートと区別できるようにする。」という工夫も加えています。
扱う会議・扱わない会議を最初に線引きする
定期実行の設計で見落としやすいのが、どの会議を対象にして、どの会議を対象にしないかを先に決めておくことです。社内のルーティンでは、対象の会議を4系統に絞っています。
- 顧客との開発定例(文字起こし全文つき)
- 顧客とのUIUX改善定例(文字起こしはリンクのみ)
- 週内に行われる社外商談のすべて
- 月末の振り返り(開催された週だけ、人ごとに個別のURLをセット)
一方で、社員の全社定例と、新規事業の検証プロジェクトの定例は、対象外と明記しています。対象外の会議については「探しに行かない・『未取得』として報告もしない(正常な想定内なので触れなくてよい)」という扱いにしています。
対象を決めずに動かすと、対象外の会議で見つからなかったことがエラーのように報告され、本当に確認すべき問題が埋もれてしまいます。扱わない範囲を先に決めておくことは、扱う範囲の精度を保つための前提になります。
対象の会議が見つからなかった週も、放置はしません。「無言で終了しない」ことを運用の条件にしており、該当がない週には「今週は対象なし」という形で一行だけ知らせるようにしています。
実際に運用してわかったつまずきと対策
対象の線引きと時刻を決めても、運用の中で見つかった落とし穴がありました。ここでは、議事録まわりで起きた3つのつまずきと対策を紹介します。
月末の1on1に全員同じURLを流し込んではいけない
月末の振り返りは、全員参加の会議ではなく、1対1の面談として個別に開催されます。メンバーごとに別々のGoogle Docがある点が、他の定例会議とは違います。全員に同じURLを流し込んではいけないことは、2026年8月22日に7月分を検証したときに判明しました。
ところが、書き込み用のスクリプト冒頭の使用例は、月末振り返りの全レコードに同じURLをセットする指定になっています。一方で手順書となるスキルの側には、「(全員に同じURLを流し込んではいけない。2026-08-22の7月分検証で判明)」という注意が書かれています。同じ仕組みの中で、使用例と手順書の指示が食い違っている状態です。
社内では、月末振り返りについては手順書の側に従い、振り返る本人ごとに個別のURLをセットする指定を使っています。
Notionの日付フィルタで全件返ってきたバグ
前述のとおり、日付の範囲指定で片方の条件が黙って無視され、エラーにならないまま全件返ってくる挙動です。日付条件はandで結合したうえで、本実行の前に確認専用のモードで対象を見ています。
Zoomのブレイクアウトルームで文字起こしが消えた話
前述のとおり、ブレイクアウトルームに入ると文字起こしの前半が消えました。Zoomの文字起こしを唯一の記録にせず、別系統の記録を並走させています。
| つまずき | 起きたこと | 対策 |
|---|---|---|
| 月末の1on1 | 1on1なのに、使用例は全員に同じURLをセットする指定になっていた | 手順書に従い、振り返る本人ごとに個別のURLをセットする |
| Notion日付フィルタ | 範囲指定の条件が片方だけ無視され、全件返ってくる | 日付条件は必ずand結合し、本実行前に対象を確認する |
| Zoomのブレイクアウト | ルーム入室で文字起こしの前半が消える | 複数の記録手段を並走させ、代替記録からの直接引用は避ける |
議事録のあとの資料作成も軽くなる
Claude Codeは、議事録を残す工程だけでなく、その内容をもとにした資料づくりにも使えます。
議事録を取ったあとの要件資料づくり
Anthropicが公開した社内活用レポートがあります。そこでは開発者だけでなく、非技術者のスタッフもClaude Codeを使っていると説明されています。ファイナンスチームの例では、コーディング経験のない社員が手順を平易な文章で書くだけで、ダッシュボードの照会からExcel出力までを一括で実行していると紹介されています(How Anthropic teams use Claude Code)。別のチームの例では、ドキュメントの統合にも強みがあり、SlackやGoogle Docsですぐ使える文書作成に活用されているとも書かれています。
GOROでも、議事録を取ったあとの要件資料づくりをClaude Codeに任せています。代表の旭俊成はnoteで、経緯説明の資料づくりが劇的に軽くなったことに続けて、次のように書いています。
実録代表・旭の一次体験
要件資料づくりも同じ
議事録を取ったあとの要件資料づくりも同じです。
出典:Claude Codeを半年使って、消えたのは「集めて整える」仕事でした(代表・旭俊成のnote)
議事録の自動化は、記録を残す工程だけで終わりません。記録した内容をもとに次の資料を作る工程も、Claude Codeに任せられる範囲に含まれます。まずは議事録の記録を安定させ、そこから広げる範囲を一つずつ試すのが現実的な進め方です。
非エンジニアが始めるときの考え方・注意点
議事録の記録や要件資料づくりが軽くなっても、仕組みを作る側が気をつけるべき点は残ります。コードを書けなくても、最初に決めておく条件さえ押さえれば、安全に始められる範囲は広いといえます。
最初に決めておくべきこと:上書きしない・複数一致で止める設計
前述のとおり、議事録を記録先に書き込む仕組みには、上書きしない設計と、該当が複数あるときに止まる設計を組み込んでいます。これは特別な技術ではなく、非エンジニアが仕組みを依頼するときにも、最初に確認しておきたい条件になります。
仕組みを作る前に、次の3点を決めておくと事故を防ぎやすくなります。
| 確認すること | 理由 |
|---|---|
| 既存の記録をいつ上書きするか | 一度書いた記録を、別の会議の分で塗りつぶす事故を防ぐため |
| 候補が複数あるときどう扱うか | 間違ったレコードへ自動で書き込まれるのを防ぐため |
| 本実行の前に確認する工程があるか | 対象を変えずに見るだけの段階を挟み、意図しない反映を防ぐため |
この3点は、Notionに限らずどの管理ツールに記録する場合にも当てはまります。仕組みを発注する側が「上書きしない設計になっているか」「確認してから実行する段階があるか」を聞けるだけでも、運用の安全性は変わります。許可の出し方や設定の考え方はClaude Codeの設定、最初に何を決める?でも扱っているので、あわせて確認してください。
自分だけで全部組まなくても始められる方法
ここまで紹介した仕組みは、会議の取得元ごとの違いや、記録先のプロパティ名の違いなど、細かい条件を一つずつ積み重ねて作られています。この積み重ねをすべて自分で設計する必要はありません。
まず自分の業務でどの会議を対象にしたいか、記録先はどこかを整理するところから始めれば十分です。上書きしない条件や確認工程をどう組み込むかは、支援を受けながら一緒に設計する進め方もあります。全部を一人で組み立てられるかを心配するより、どの会議から試すかを決めることのほうが、始める段階では大事になります。
この記事と合わせて読みたい
- Claude CodeとNotionの連携方法とは?できること・制限と実際につまずいた点を解説 — Notionとの連携をもっと詳しく知りたい読者に、具体的な設定方法とつまずきポイントをまとめた記事です。
- Claude Codeのセキュリティは大丈夫?法人導入前に知るべき安全性と対策を非エンジニア向けに解説 — 会議の文字起こしのような社内情報を扱う際に気になるセキュリティ面を、法人導入前の視点から解説した記事です。
- Claude Codeの設定、最初に何を決める?非エンジニアが知るべき許可の出し方と置き場所 — 議事録自動化の仕組みを作る前に決めておくべき権限設定や保存場所の考え方を解説した記事です。
Claude Codeを業務で使いたい方へ
自分の業務を題材に試したい方には、1対1で進めるClaude Code マンツーマン講座があります(オンライン・回数制)。部署やチームで導入する場合は、業務に合わせて内容を設計するClaude Code法人研修をご覧ください。