AI議事録の自動化、止まったのは人のほうでした。毎日18時にClaudeが回す議事録バッチの作り方と、2ヶ月半の答え合わせ
「AIで議事録を自動化しても、最後に人がチェックすれば安心」「人が承認する工程を残しておけば、品質は担保できる」
私もそう考えて、仕組みを作りました。毎日18時にClaudeが会議の文字起こしを全部読んで、議事録を作って、Slackに配る。お客様との会議だけは、人が承認してから外に出す。
作ってから2ヶ月半。機械のほうは動き続けて、約150件の文字起こしから130本の議事録を作りました。一方で、お客様との議事録ドラフト約25件のうち、承認されたものは0件でした。
今回は、Claudeで毎日回している議事録バッチの作り方と、2ヶ月半回して分かった「止まったのは人のほうだった」という答え合わせを、お届けしたいと思います。
※この連載の全体像はこちらにまとめています → 中小企業のAI推進、この1年で何が起きたか。連載全27本の目次
この記事は、前回の議事録の記事の続きです。
前回の要点だけ先に書いておきます。
AI議事録ツールの自動要約が気に入らず、要約だけ手作業に戻した
部内では「先週の話と混ざる」「保存されずに消える」が起きた
毎日18時にClaudeが分類して配り、判断できないものだけ人に聞く形に作り直した。「うまくいっているかは、あとで書きます」で終わった
この記事に書いてあること
議事録バッチの設計方針と、9つの工程の中身
2ヶ月半の数字（読んだ件数・作った本数・承認された件数）
機械は止まらなかったのに、人の工程だけ止まった理由
こんな方に向けて書いています
AIの定期実行で、業務を毎日自動で回したい方
「最後は人が確認する」設計にしたのに、確認が回っていない方
記事の後半に、バッチの指示書の骨組みを載せています。作り方だけ知りたい方は、先に下まで飛んでください。
結論：機械は2ヶ月半止まらなかった。止まったのは、人が答える場所だった
バッチは7月8日の試運転から9月25日まで、処理ログに記録が残っている日だけで45日動きました。実行環境が終日落ちた日も、代わりの手段で議事録を作って配っています。
止まったのは、次の3つでした。
お客様との議事録の承認 … 約25件のドラフトに対して、承認は0件
社内の議事録の配り先 … 社内の会議体14行のうち13行が「（要設定）」のまま。社内の議事録の約8割が、確認用チャンネル止まりだった
未分類の会議の登録 … 同じ定例が5回「未分類」に落ちて、まだ登録されていない
どれも、Claudeがきちんと「これをお願いします」と聞いてきていたものです。聞かれた私が、答えていませんでした。
前回「詰まる場所が『AIの精度』から『人が答えるかどうか』に移った」と書きましたが、2ヶ月半たって、それが数字ではっきり出た感じです。
作り直しの前提：朝の「OK待ち」をやめて、「止まらない・シンプル・1日1回」にした
いまのバッチの前に、6月に作った別のタスクがありました。
毎朝Nottaの新着の文字起こしを見て、お客様との会議だけを拾い、Notionの案件管理に反映する「更新プラン」を出す。私がOKを出すまで書き込まない、確認をはさむ型です。1年前の議事録作成、最適解は一つじゃなかったでは手でコピペしていたので、それを一段進めたつもりでした。
ところが社内の会議まで広げようとしたところで、設計が複雑になりすぎて行き詰まります。7月8日、ゼロから作り直しました。
そのとき決めたのは、次のことです。
議事録の正本はGoogleドライブに一元化する。Notionは使わない
人の承認はお客様との会議だけ。社内の会議は自動で配る
過去の文字起こし446件は議事録にせず、月別にアーカイブするだけ
設計方針も3つ決めて、指示書の冒頭にそのまま書きました。
止まらない … 判断に迷っても止めない。仮の置き場に入れて、確認用チャンネルに通知する
シンプル … 要対応のことは、Slackの確認用チャンネル1本に全部集める
1日1回 … 平日18時に、その日の分をまとめて処理する
「止まらない」は、朝のOK待ちへの反省です。私が返事をしないと、その日の処理がそこで止まる。止まると翌日に2日分たまって、さらに返事がしにくくなる。だから新しいバッチでは、人の返事がなくても機械の工程は最後まで流れきることを優先しました。
この方針は、効いたところと裏目に出たところの両方がありました。
バッチの中身：9つの工程のうち、人が関わるのは2ヶ所だけ
指示書は、Claudeのデスクトップアプリの定期実行（平日18時）に登録しています。中身は文章の指示書1本で、プログラムは書いていません。定型業務を指示書にして任せるやり方はプロンプト、もう書いていませんでも書きましたが、これはその中で一番大きい1本です。
工程は、Step 0からStep 8の9つです。
会議体マッピング表の検証（保存先フォルダとSlackチャンネルが実在するか）
前回のお客様議事録ドラフトに、承認が付いたかを確認する
新着の文字起こしを集める。Google Meetの自動メモとも突き合わせて録り漏れを補う
会議を判別する（お客様／社内／個人／議事録にしないもの）
種別ごとのテンプレートで、Wordの議事録を作る
Slackに配る（社内は自動、お客様は【要承認】ドラフトとして確認用チャンネルへ）
定例だけ、会議体ごとの履歴とダイジェストを更新する（前回の宿題の消化状況つき）
処理した文字起こしをアーカイブして、処理ログに1件1行で書く
確認用チャンネルに、その日の処理サマリーを1本投稿する
人が関わるのは、Step 1の「承認が付いたか」と、Step 8の「サマリーの要対応事項」の2ヶ所だけです。それ以外はClaudeが1人で流します。
もう一つ気をつけたのが、前回の記事でひな形を載せた「会議体マッピング表」です。人とClaudeの両方が書き換えると壊れるので、列ごとに持ち主を決めました。
私だけが書く列 … 識別キーワード、保存先、Slack配信先、CRMとの連携の有無
Claudeだけが書く列 … 検証結果（「確認済(アクセスOK)」「要修正」）
いま振り返ると、この線引きには裏がありました。私の列が空欄でも、Claudeは埋めてくれません。埋めるのは私の仕事として、きれいに切り分けてあったからです。
「端的すぎて経緯が分からない」で、議事録の書き方を変えた
動かし始めて10日目の7月17日、私は議事録の書き方に注文を付けています。引き継ぎ用のメモには、そのときの私の要望が「端的すぎて経緯が分からない」と残っています。
最初の議事録は、決定事項とTODOがきれいな箇条書きでした。でも、あとから読むと「なぜそう決まったのか」が抜けている。
そこで、議題ごとに「背景・きっかけ」「議論の流れ（誰が何を言い、何と何を比べたか）」「結論とその理由」を、3〜8文の段落で書くように指示を変えました。指示書には「箇条書きの羅列や、結論だけの1行要約にしない」と書いてあります。
AIの議事録は、放っておくと「決まったこと」だけになります。「なぜ決まったか」は、指示しないと残りませんでした。
2ヶ月半の数字と、止まらない設計が効いた日
7月8日から9月25日までの処理ログを集計すると、こうなりました。
処理ログに記録がある日：45日
読んだ文字起こし：約150件（重複やスキップを含む）
作った議事録のWord：130本
会議の内訳：社内が約105件、お客様との会議が約25件（ログの書き方が月ごとに違うので、私の集計です）
一番大きな事故は、9月10日です。この日のサマリーは、見出しに「重大インシデントあり」と付いて届きました。
実行サンドボックス（コード実行・シェル）がセッション開始時から5回連続でマウント失敗し終日復旧せず。
（2026年9月10日 18時13分、確認用チャンネルへのバッチの投稿から引用しています）
Wordが作れない。マッピング表のExcelも読み書きできない。9つの工程の土台が、ほぼ全部使えない状態でした。
それでもバッチは、Googleドライブの連携機能で文字起こしを読み、Googleドキュメントで暫定版の議事録を作って配っていました。「止まらない」と決めておいた効果は、ここで出ました。
ただ、ここにも人の宿題が残ります。1週間後の9月17日のサマリーには、9月10日の議事録が「まだ暫定Googleドキュメントのまま」で「要docx化」と書かれていました。環境は15日に戻っていましたが、作り直しの確認は私のところで止まっていたわけです。
Google Meetの録画フォルダも、7月から断続的に接続が切れています。9月25日のサマリーにも「お手数ですが接続をご確認ください」とありました。
答え合わせ①：お客様との議事録の承認は、約25件で0件だった
ここからが、前回「あとで書きます」と言った答え合わせです。
お客様との会議の議事録は、確認用チャンネルに【要承認】のドラフトとして届きます。私が👍を付けるか「承認」と返信すると、翌営業日に社内の顧客向けチャンネルに配られ、CRMにも記録される設計でした。
7月15日の最初のドラフトから9月25日までで、ドラフトは約25件。承認が付いたものは0件です。9月23日のサマリーには、こう書かれていました。
承認済みドラフト:0件(配信・HubSpot登録なし)
（2026年9月23日、確認用チャンネルへのバッチの投稿から引用しています）
ドラフトは、承認がないまま3営業日たつと1回だけリマインドが来て、7日たつと「保留」に落ちます。保留になったものには、以後リマインドをしない。私が毎日責められないように、そう設計しました。
結果、ドラフトは静かに保留へ積もっていきました。8月20日のログには、保留が14件と記録されています。
確認用チャンネルを2ヶ月半ぶん読み返すと、人の返信もリアクションも1件もありませんでした。ドラフトに付いている返信は、すべてバッチ自身の自動リマインドです。
承認の仕組みを設計したのは私です。設計はしておいて、その運用が私にはできていませんでした。
催促を止める設計は、私を責めない設計でした。そのぶん、止まっていることに私自身が気づきませんでした。
しかもCRMとの連携は、マッピング表の「連携する」列に私が印を付けた顧客だけに動く作りです。その印は、37行のどこにも付いていません。仮に承認していても、CRMには1件も記録されない状態でした。
答え合わせ②：社内の議事録の8割は、配る先が決まっていなかった
社内の会議は、承認なしで自動配信する設計です。こちらは回っていると思っていました。
ところが、マッピング表の社内の会議体14行のうち、13行は配信先が「（要設定）」のままでした。配信先が空欄だと、議事録は確認用チャンネルに落ちます。処理ログで数えると、社内の議事録約105件のうち約85件がそうでした。
前回の記事で私は「マッピング表に書かれたSlackチャンネルへ投稿する」と書きましたが、実際は8割が確認用チャンネル止まりだったことになります。
未分類の会議も同じです。経営戦略室の定例は、7月16日から9月24日までに5回「未分類」に落ちました。Claudeは毎回、キーワードの案まで添えて「登録しますか」と聞いてきています。
前回のあとがきに、私は「この記事を出す前に、マッピング表に1行足しておこうと思います」と書きました。9月25日のサマリーでも、その定例は「未分類」のままです。1行足すのに、1分もかからないはずなのですが。
なぜ、人のところだけ止まったのか
いま考えている理由は、ひとつです。
機械の工程には「毎日18時」という時刻があります。人の工程には、時刻がありませんでした。
Claudeは18時になれば必ず動いて、9つの工程を上から順に流します。そこに気分は関係ありません。
一方で、私に残した工程は「サマリーを読んで、気づいたら返事をする」でした。いつ読むか、いつ返事をするかは決めていません。18時過ぎに届くサマリーは、その日の最後の会議のあと、帰る前の私に届きます。
設計したときは、人の工程を「判断」と呼んでいました。前回の記事でも、人にしかできない判断を3ヶ所だけ残した、と書いています。でも実際に私がやっていたのは、判断ではなく「後回し」でした。
自動化で人に残す工程は、「判断」と名付けるだけでは回りません。いつやるかまで決めないと、機械の速さに置いていかれました。
ここで一つ、反対側の見方も置いておきます
ここまで「人が止まった」と反省する流れで書いてきましたが、別の見方もあります。
承認が0件でも、この2ヶ月半で私の仕事は止まっていません。お客様との議事録は、承認されなくてもWordで保存されています。実際、必要なときにはそこを開いて済ませていました。
そうだとすると、「人がサボった」のではなく、「承認という工程が、そもそも要らなかった」のかもしれません。要らない工程だったから、誰も困らず、誰も押さなかった。
お客様の情報を社内に広く配る以上、確認をはさむこと自体は必要だと思っています。ただ、「1件ずつ👍を押す」形がこの仕事に合っていたのかは、2ヶ月半のログだけではまだ見分けがつきません。
そのまま使える：日次バッチの指示書の骨組み
最後に、指示書の骨組みを載せます。うちの実物から、会社固有の名前と細かい条件を抜いて、形だけにしたものです。
あなたは、会議の文字起こしから議事録を作る日次バッチです。
設計方針は「止まらない・シンプル・1日1回」。
判断に迷ったら止めずに仮の置き場へ入れ、確認用チャンネルに通知してください。
前提
- 入口フォルダ：文字起こしが自動保存されるフォルダ
- 正本フォルダ：議事録・マッピング表・ログを置くフォルダ
- 確認用チャンネル：すべての要対応事項を集めるSlackチャンネル（1本）
Step 0 マッピング表の検証（保存先フォルダと配信先チャンネルが実在するか）
※人が書く列は書き換えない。検証結果の列だけ書く
Step 1 前回の要承認ドラフトに承認が付いたか確認。付いたものだけ配信
※3営業日で1回リマインド、7日で保留
Step 2 入口フォルダの新着を列挙（重複はスキップ）
Step 3 会議の種別を判別（顧客／社内／個人／議事録にしないもの）
Step 4 マッピング表で会議体・保存先・配信先を決め、議事録を作る
議題ごとに「背景・議論の流れ・結論とその理由」を3〜8文の段落で書く
未登録の会議は _未分類/ に保存し、登録用の行を確認用チャンネルに提案
Step 5 配信（社内は配信先へ自動、顧客は【要承認】として確認用チャンネルへ）
配信先が空欄なら確認用チャンネルへ
Step 6 定例だけ、会議体ごとの履歴とダイジェストを更新（前回宿題の消化状況つき）
Step 7 処理済みの文字起こしをアーカイブし、処理ログに1件1行で記録
Step 8 確認用チャンネルに処理サマリーを1本投稿
（件数の内訳／要対応事項：未分類・エラー・承認待ち・保留）
使うなら、私の失敗を踏まえて2つだけ足してください。
配信先が「（要設定）」の行が残っている間は、毎回のサマリーの先頭にその行数を書かせる
人が答える工程に、時刻を決める（例：毎週金曜の朝に、保留と未分類だけまとめて見る）
まとめ：さて、あなたの自動化で「人の工程」には時刻がありますか？
3行にまとめます。
毎日18時のClaudeの議事録バッチは、2ヶ月半で約150件を読み、実行環境が落ちた日も止まりませんでした。
止まったのは人の側で、お客様との議事録の承認は約25件で0件、社内の配信先は14行中13行が空欄のままでした。
機械の工程には時刻があって、人の工程には時刻がなかった。その差が、そのまま出ました。
AIに業務を毎日回させる仕組みは、思ったより簡単に作れます。難しいのは、そのあと人に残した工程のほうでした。
「最後は人が確認する」と書いた設計書が、皆さんの会社にもあると思います。その確認、いつ、誰がやることになっていますか。
あとがき
この記事を書くために、2ヶ月半ぶんの処理ログと、確認用チャンネルのサマリーを読み返しました。
毎日のサマリーは、かなり丁寧です。登録すべきキーワードの案まで書いてあります。それを5回、私は読み流していました。
前回「1行足しておこうと思います」と書いてから、9日たっています。
Claudeは毎日18時に聞いてきます。答える時刻を決めていなかったのは、私のほうでした。
あわせて読みたい
同じように社内でAI活用を推進している方の話が、一番参考になります。 「うちはこうだった」があれば、ぜひコメントで教えてください。
この連載では、横浜の中小企業でAI活用を進めるなかで、 うまくいったことも、うまくいかなかったことも、そのまま書いています。 よかったらフォローして、次回も読んでいただけると嬉しいです。
