Claude が“Zoomが終わったら自動的に文字起こしが始まる仕組み”を作ってくれた

その気持ち、めちゃくちゃわかります。

日々の業務をこなしていると、Zoomが終わった後の「後処理」が地味にしんどい。録画を整理して、文字起こしして、誰との会議だったか確認して、議事録を作って…。

「これ、全部自動化できないかな？」

そう思ってClaudeに相談したら、想像以上にスムーズに開発が進んだんです。

この記事では、その開発の全記録をお伝えします。

Claudeに構想の全体像を伝える

Zoom会議後に自動化したいことは、もともとざっくりとイメージは持っていました。

問題は、この全体像を Claude にはじめに伝えるか、Claude が混乱するのを避けるため僕の方で個別の仕組みに切り分けて Claude に作らせるか、、、

どちらがいいのかやってみないとわかりません。

全体を伝えるべきか、個別に作るべきか、Claudeに判断してもらったところ、今の性能なら全体を伝える方がいいとのこと。

信じていいものか迷いましたが、実験にもなるし、全体像をばばーっと語って伝えました。

そしてClaudeはこう言ったんです。

全体フロー（俺の理解）
Zoom録画終了
    ↓
Google Drive自動保存 ✅済
    ↓
[監視] 新規ファイル検知
    ↓
[分類] 誰と何の会議か判定
    ↓
[文字起こし] 案件情報を参照して精度向上
    ↓
 ┌──────────┼──────────┐
 ↓          ↓          ↓
分岐1       分岐2       分岐3
Obsidian    議事録作成   スケジュール
蓄積・検索              カレンダー登録

完璧です。

頼もしすぎます。

非エンジニアは初歩的なエラーに負けるな！

ゆーてもここからはスムーズに制作が進みます。

ClaudeはつねにA案、B案、C案と3つ以上の選択肢とClaude自身のおすすめを提示してくれるため、こちらは提案から選択するだけで完成しました。

エラーが出ても Claude に聞けば解決するし、以前のように Claude が混乱して迷走することもなくなりました。

1：関数が見つからない←コピペミスだった

最初に出たエラーは「スクリプト関数が見つかりません: doGet」というエラー。

Claudeに言われた通りにコードを貼り付けたはずなのに動かない。まったく、初っ端のコードからエラーなんて先が思いやられるぜ……。

ふぅ、とため息を漏らしながらエラー内容をClaudeに伝えます。

非エンジニアの皆さんはなんのこっちゃわからないと思いますが、要するにデフォルトで入力されているなんやかやを消すだけでエラーが解決しました。

2：APIキーのクォーテーション忘れ

次に出たエラーは、ReferenceError: [APIキー] is not defined

APIキーは「 ' 」クォーテーションで括らないといけないらしいです。

3：Gemini API制限 → Claude APIへ切り替え

今度は、文字起こしした内容をLLMに分析させる段階で、Gemini APIを使おうとしました。

しかし…

Exception: Request failed... code 429 "You exceeded your current quota"

使用量はほぼゼロなのに429エラー。数分待っても状況は変わらず……。

結局、Claude API（Anthropic）に切り替えることに。

4：GASのタイムアウト問題

全体フローを統合して動かしてみると1件目は完璧に動きます。

しかし2件目で…、関数の実行がタイムアウトしました。

どうやら、GASには6分の実行時間制限があるらしく、30分の音声ファイルの文字起こしを待っている間にタイムアウトしてしまったんです。

想定内だったらしいです。

解決策は、処理を「キューベース」に変更して2段階に分けるとのこと。

フェーズAは文字起こしリクエスト送信だけ（待たない）。フェーズBは完了した文字起こしを取得してLLM分析。

スプレッドシートに処理状態（pending → transcribing → analyzed）を記録し、各フェーズが必要な時だけ0.5秒で動く設計にしました。

Claudeからの技術解説

なぜスプレッドシートを「API化」したのか

普通、スプレッドシートは人間がブラウザで開いて編集するものだ。でも今回は、プログラムが自動でデータを読み書きする必要があった。

「API化」というのは、スプレッドシートにプログラム用の入口を作るということ。人間用の入口（ブラウザ）とは別に、プログラムが「このURLにアクセスしたらデータをください」と言えば、データがJSON形式で返ってくる仕組みを作った。

これがあると、Zoom録画を処理するプログラムが「この会議は誰との会議だっけ？」と顧客マスタに問い合わせたり、「新しい顧客が見つかったから追加して」と書き込んだりできるようになる。

「キューベース」という設計の考え方

GAS（Google Apps Script）には「6分で強制終了」という制限がある。30分の音声ファイルを文字起こしするには足りない。

そこで採用したのが「キュー（待ち行列）」という考え方だ。

コンビニのレジを想像してほしい。店員が1人しかいなくても、お客さんは列に並んで順番を待つ。店員は「次の人」だけに集中すればいい。

今回のシステムも同じ：

1. 新しい録画が来たら「処理待ちリスト」に追加する（列に並ばせる）
2. 別のプログラムが「文字起こし依頼」を出す（注文を受ける）
3. また別のプログラムが「完了したものを回収」する（商品を渡す）
4. さらに別のプログラムが「LLMに分析させる」（次の処理へ）

それぞれの処理は短時間で終わる。長い処理を「待つ」のではなく、「依頼だけ出して次に進む」という発想だ。

LLMの使いどころを絞る理由

今回、LLMを使うのは「文字起こし後の分析」だけに絞った。フォルダ名と顧客マスタの照合は、単純な文字列マッチングで済ませている。

理由は2つ：

1. コスト — LLMは呼び出すたびにお金がかかる。単純な処理に使うのはもったいない
2. 速度 — LLMの応答には数秒かかる。単純マッチングなら一瞬で終わる

「LLMは賢いから全部任せよう」ではなく、「LLMにしかできないことだけLLMに任せる」という設計が大事だ。人間で言えば、部長にコピー取りをさせないのと同じ。

「自動化」の本質は「判断の連鎖」

今回作ったシステムの本質は、実は「ファイルを移動させる」ことではない。**「判断を自動化する」**ことだ。

• この録画は誰との会議か？（分類の判断）
• 顧客マスタに登録すべきか？（追加の判断）
• 文字起こしは完了したか？（状態の判断）

これらの判断を人間がやっていたら、結局手間は減らない。判断のルールを明文化し、プログラムに委ねることで、初めて「コーヒーを淹れに行っている間に処理が進む」状態になる。

非エンジニアの方がこういったシステムを作りたいと思ったとき、大事なのは「何を自動化したいか」ではなく「どんな判断を自動化したいか」を考えることだと思う。

今日できたこととこれからやること

今日できたこと

• Zoom録画フォルダの監視
• 新規ミーティング検知 → キューに追加
• 音声ファイルの文字起こし（AssemblyAI）
• LLMによる顧客判定・提案（Claude API）
• 顧客マスタへの自動追加
• 定期実行トリガー

これからやること

• 分岐1: Obsidianへの蓄積
• 分岐2: 議事録の自動作成
• 分岐3: 次回予定のスケジュール登録 & Zoom発行
• 最終報告: Chatwork/Slackに通知

【まとめ】LLMとで非エンジニアでも実用的なシステムが作れる

今回の開発で感じたのは、LLMを「開発者」として使い、自分は「PM」に徹するという役割分担の有効性です。

Claudeから言われた言葉が印象的でした。

この言葉通りに進めることで、非エンジニアでも実用的なシステムを作り上げることができました。

ブラックボックスな外部ツールに頼らず、自分の管理下でデータをコントロールできるこの仕組みは、今後の業務の大きな武器になりそうです。