会議 AI ツール（社内版）— 設計メモ

日付: 2026-06-30（GDrive 中心案に更新／0630 開発定例とすり合わせ済）起点: 「会議文字起こし」プロジェクトの蓄積（音声 → 文字起こし → 要約 → 成果物の手作業フロー、十数回分） きっかけ: 0630 開発定例で田村さんが「会議録音をリポジトリに集約し、進捗は人に聞かず Claude Code から引く」構想を共有（田村さん本人が当日トランスクライブを設定）。これが本ツールの直接の動機。社内 3 名で会議の「誰に・どんなタスク・進捗どう」を AI と対話して整理したい 位置づけ: 社内ツール MVP ＝オンプレ機密会議ツール商品化の社内実証。田村所長が試作を承認（2026-06-30、qmu.dev へのリソース作成 OK）。実装着手前の計画。本メモではコードは書かない。大前提（D9）: 田村（他者）のリソースは read／use のみ・write 禁止。 本ツールが書くのは自分の書き込み領域だけ。

決定ログ

#	決めたこと	補足
D1	Cloudflare（qmu.dev）を使う。Free 枠で収める	田村承認。事故課金なし（Free は超過時エラーで止まる）
D2	音声アップロードは各人がやる（録音が各自ローカルなので入口は分散）	→ D3 で「GDrive にドロップ」に具体化
D3	★GDrive 中心アーキ（田村案・採用）★	GDrive＝入口＆ファイル置き場。音声 drop → 文字起こし → AI 要約 → 内容から「日付_種別」フォルダへ自動仕分け → アプリが GDrive を読む
D4	Cloudflare は「処理＋アプリ」の裏方。ファイル実体は全部 GDrive	MVP では R2・D1 は使わない（後回し）。部品が減る
D5	M1 = 田村の最低限（GDrive パイプライン）／M2 = 「誰に何を・進捗」を AI 対話（益子の本命）	競合せず順番に積む
D6	whisper = 案1 Workers AI turbo に決定（PoC 済 2026-06-30）	turbo が medium の固有名詞誤りを多数修正・$0/Free・10.5 分 1 リクエスト・ローカル環境不要。結果は §11#1
D7	開発者向けは L2 先行（MCP-first） — M2 の対話をリモート MCP サーバーで出し、開発者の Claude Code から会議を引ける	詳細 §13。HSS / 経友会 MCP と同型・同居（qmu.dev Worker, OAuth）
D8	GDrive I/O は生 Drive API・バイトストリームで自前実装（公式 Drive MCP プラグインは使わない）	★0630 定例反映: 田村が公式プラグインの base64＋POST 制約（大ファイル NG・激遅）を実証済。本ツールは大きい音声を扱うので不可 → 同じ手法を自前で持つ（田村の QFS／GドライブFTP は read／参照のみ, D9）。詳細 §11#4
D9	★他者（田村）のリソースは read／use のみ・write 禁止★	本ツールが書くのは自分の書き込み領域だけ＝専用 GDrive フォルダ／自前 repo／qmu.dev の Worker・D1。田村の QFS・repo・Drive 等へは読む/呼ぶのみ、改変・push・書き込みはしない。[[feedback_self_contained_repo]] 方針とも整合
D10	会議テキスト＝`github.com/qmu` の新規専用 repo にコミット（要約＋文字起こし）／音声＝GDrive	2026-06-30 決定（益子）。git は 100MB 超 push 不可＋バイナリ膨張で音声は repo 不可 → 音声 GDrive・テキスト repo。repo を in-repo Claude Code が読む（§11#8 ハイブリッド確定）。repo 作成は田村に依頼/権限確認（D9）

1. 何を作るか（一言）

Google Drive の所定フォルダに会議音声をドロップすると、自動で文字起こし・AI 要約され、内容から「日付_種別」フォルダへ仕分けられる。アプリ（qmu.dev）はその GDrive を読んで表示し、次の段で「誰に・どんなタスク・進捗どう」を AI と対話照会できる。

2. やる / やらない

	内容	備考
✅ M1	① GDrive の入口フォルダに音声 drop（＝各人の操作はここだけ）	既存の習慣そのまま
✅ M1	② 自動で文字起こし（whisper）＋ AI 要約	今ローカルでやってる処理
✅ M1	③ 内容から日付・種別を判定して適切なフォルダへ自動仕分け	今の Desktop 構成を GDrive に再現
✅ M1	④ アプリが GDrive を読んで表示（一覧・要約閲覧）	Cloudflare Worker + Access
✅ M2	⑤ タスク/担当/進捗をデータ化し AI と対話照会	益子の本命。M1 の上に乗せる
❌ 今やらない	録音そのものの自動化（Meet 検知）	録音は手動のまま
❌ 今やらない	R2 / D1（MVP では GDrive で足りる）	M2 以降で必要なら導入
❌ 今やらない	社外公開 / 外販	社内実証が先
❌ 禁止	田村（他者）のリソースへの書き込み・改変・push	D9。read／use のみ

3. 全体アーキ（GDrive 中心）

[各自] 録音(手動) → Google Drive の「会議_入口」フォルダに音声をドロップ   ← 各人の操作はここだけ
                         │ (新規音声を検知: ポーリング or Drive 変更通知)
                         ▼
   ━━━━━━━ ここから全自動（裏方 = Cloudflare Worker / qmu.dev, Free 枠）━━━━━━━
        音声を取得 → 文字起こし（Workers AI whisper turbo / D6）
                         │ transcript
                         ▼
        Claude API: 要約(md) ＋ 日付・種別・タイトル判定（＋将来: タスク抽出）
                         │
                         ▼
        Google Drive へ書き戻し ＆「YYYYMMDD_種別/」へ自動仕分け
          ※ I/O は生 Drive API・バイトストリームを自前実装（公式プラグイン不可 D8 / 田村資産は read のみ D9）
          ※ 書き込み先は本ツール専用フォルダのみ
          例: 会議/20260630_開発定例/{audio, transcripts, summary.md}
                         ▼
   [アプリ（Worker + Access, 3 名限定）] が Google Drive を読んで表示
          一覧 / 要約閲覧 /（M2）タスク・進捗を AI と対話照会

肝: データ（音声・全文・要約）は GDrive（qmu の Google Workspace テナント）、処理とアプリは Cloudflare。「データ面／制御面を分ける」が自然に実現 → 商品版では GDrive を顧客側ストレージに差し替えるだけ（§9）。

4. データの持ち方

MVP は「ファイルが真実」 — 要約は summary.md、全文は transcript.txt、音声は audio/。GDrive 上にそのまま。D1 は使わない。
アプリは GDrive を読むだけ（一覧・閲覧）。AI 対話（M2）は GDrive の md/txt を Claude に渡して答えさせる。
タスク/進捗（M2） は最初は要約 md 内に構造化（例: front-matter か末尾に JSON ブロックで tasks / assignee / status）で持ち、規模が出たら D1 へ移す。
- 「誰に何を」＝ tasks、「その後どう」＝後続会議での言及を Claude が突合。

5. 処理フロー

録音（手動） → m4a。
入口フォルダに drop（各人） → GDrive 会議_入口/。
検知 → Worker がポーリング or Drive 変更通知で新規音声を拾う。
文字起こし → Workers AI whisper-large-v3-turbo（音声を GDrive から取得して投げる, D6）。
要約＋分類（Claude API 1 回） → summary.md 生成＋日付・種別・タイトル判定（＋将来 tasks 抽出）。過去会議の文脈も渡す。
書き戻し＆仕分け → 会議/YYYYMMDD_種別/ を作って audio・transcript・summary を配置。入口から移動（I/O は生 Drive API 自前実装 D8；書き込みは本ツール専用フォルダのみ D9）。
閲覧/対話 → アプリ（Worker + Access）が GDrive を読んで表示。M2 で AI 対話。

6. AI 対話（M2）

アプリのチャット → Worker → Claude（tool use）。ツールは GDrive 読み取り＋（D1 を入れたら）クエリ。
- list_meetings / read_summary(meeting) / search(keyword) /（D1 化後）query_tasks query_task_history
「ノベルさんの件どこ？」「益子の未完タスク」「先週から動いてない宿題」を会議横断で。

7. マイルストン

段階	成果物	価値
M1（田村の最低限）	GDrive drop → 文字起こし → 要約 → 日付_種別へ自動仕分け → アプリで読める	手作業が消える＋共有が始まる
M2（益子の本命）	タスク/担当/進捗のデータ化＋ AI 対話照会（＝ MCP サーバーとして実装, §13）	「誰に何を・進捗」が引ける。usage 本格消費
M3	横断 QA・進捗自動照合・成果物複数案・チケット `meeting_id` 連携	会議をしゃぶり尽くす／/catch 補完
M4（将来）	商品化（顧客ストレージ＋オンプレ）	B 案展開

8. 技術選定

レイヤ	選定	備考
入口・ファイル置き場	Google Drive（qmu Workspace, 本ツール専用フォルダ）	D3
処理・アプリ	Cloudflare Worker（qmu.dev, Free）	裏方
文字起こし	Workers AI whisper-large-v3-turbo（案1・決定）	D6 / §11#1
要約・分類・対話	Claude API（Opus 4.8 / Sonnet 4.6）	社長要件（usage）
GDrive 連携	生 Drive API・バイトストリームを自前実装	公式 Drive MCP プラグインは大ファイル NG（D8）。田村の QFS は read／参照のみ（D9）、write 依存しない
認証（アプリ）	Cloudflare Access（Google SSO, 3 名）	50 名まで無料
認証（MCP）	OAuth（HSS MCP 踏襲, §13）	開発者向け
ストレージ DB	当面なし（GDrive ファイル）／ M2 で D1 検討	R2 も当面不要

9. 商品化（B 案）への地続き

GDrive＝データ面 / Cloudflare＝制御・処理面 が MVP 時点で分離済み。
商品版では「GDrive」を**顧客のストレージ（顧客 Drive / VPC / オンプレ）**に差し替えるだけ。音声・全文は顧客側に留め、メタ/制御は qmu 側。OCR 案の分離思想と同型。

10. usage を使い切る設計（社長要件）

要約・分類・タスク抽出・既存突合・AI 対話・横断 QA・進捗自動照合・成果物複数案 — 会議ごと＆問い合わせごとに Claude を叩く。Cloudflare は Free、お金/usage は Claude API 側（＝狙いどおり）。

※ 0630 定例の釘刺し: 利用枠消費は手段であって KPI ではない（田村「毎週チェック／KPI 化はディストピア、やらない」）。「使い切る」は デカいタスク＋裁量＋高 reasoning effort＋自社案件への配分 の結果として伸ばすもの。アサインとテクニックがセットの条件付き。

11. オープン issue

~~whisper 実行場所~~ → 決定: 案1 Workers AI whisper-large-v3-turbo（PoC 2026-06-30, 題材=20260622_臨時 10.5 分）。10.5 分を 1 リクエストで処理・$0(Free 枠)・medium より固有名詞精度が上（1Password / 組合員 / ぶら下がる / 口頭 / 簡便 を修正、qmu@hokenss も部分改善）。残る誤り（経友会・対外API・人名アリス/益子）は要約時の Claude 補正＋固有名詞辞書で吸収（現行どおり、エンジン非依存）。
GDrive フォルダ構成 — 既存 20260630_開発定例 形をそのまま GDrive へ？ 本ツール専用フォルダを 1 つ切り、入口フォルダもその下に。→ 田村に確認中。
トリガー方式 — Drive 変更通知(changes.watch) vs ポーリング（数分間隔で十分）。
GDrive I/O ＆認証 — ★0630 定例: 田村が公式 Google Drive MCP プラグインの base64＋POST 制約（大ファイル NG・激遅）を実証 → 大きい音声は 生 Drive API・バイトストリームで自前実装（手法は田村の QFS／GドライブFTP を参照するが、彼のコード/Drive へは write しない, D9）。認証はサービスアカウントで、本ツール専用フォルダにのみ書き込み権限を付与。
日付・種別の判定元 — ファイル名 / 作成日時 / 音声内容（Claude 分類）。
タスク/進捗の持ち方 — 要約 md 内構造化 → 規模が出たら D1（M2 で決定）。
既存 16 会議の取り込み — GDrive に並べて初日から横断 QA を効かせるか（§13b で L2 の空ローンチ回避に必須化）。
~~「リポジトリ集約」との整合~~ → 決定（2026-06-30）: ハイブリッド採用（D10）。github.com/qmu に新規専用 repoを切り、要約＋文字起こし（テキスト）をコミット → in-repo Claude Code で引ける（田村の repo 集約理想と合流）。音声は GDrive（git は大ファイル不可）。MCP（§13/L2）はその上の横断対話として併存（L1＋L2 両取り）。repo 作成は田村に依頼/権限確認（D9）。
QFS との関係 — 田村の QFS（Rust・関数型クエリ言語、Claude Code プラグイン化予定）と本ツールの GDrive 読み取り／MCP 経路は思想が重なる（0630 §8・次回観点）。ただし依存・書き込みはしない（D9）、手法参照に留め、将来連携は別途田村と相談。

12. 次のアクション

✅ 完了: whisper PoC → 案1 Workers AI turbo 決定（D6） / Claude API キー入手（scratchpad に隔離） / 出力先 = qmu org 新規専用 repo（テキスト）＋ GDrive（音声）決定（D10/§11#8）。
次: M1 実装（音声 → whisper → 要約＋分類 → 日付_種別へ仕分け → repo/GDrive へ）。
- まずローカル試作（Desktop フォルダを GDrive 代わりに、田村リソース非依存・D9 安全）で end-to-end を実証 → その後 GDrive＋Worker 化＋ repo 作成。
- GDrive I/O は生 Drive API 自前実装（D8）、書き込みは専用領域のみ（D9）。
田村へ（一声）: 「会議用に github.com/qmu で新規 repo 作る（音声は GDrive・repo はテキストだけ）」＋ repo 作成権限（D9）。

準備物（scratchpad）: 20260622_16k_mono.mp3(4MB) / run_workersai.py / Anthropic キー（隔離）。計画フェーズ完了。M1 実装＋実証済（2026-06-30）: パイプライン（音声→Workers AI→Sonnet 4.6 要約+分類）を4タイプ・76分で検証（metadata 正確・¥4〜17/会議）＋ローカル MCP meeting-mcp を Claude Code に user スコープ登録・接続OK＝どの project からも会議を引けるを実証。常設スクリプトは 会議文字起こし/_tools/（秘密は env）。本番（GDrive自動取り込み / qmu.dev Worker＋OAuth で remote MCP化 / qmu org repo）は外部設定待ち。

13. 開発者向け配信: Claude Code プラグイン経路（★L2 先行 = MCP-first）

決定（D7）: 開発者が「会議の決定・経緯」を実装に活かす経路は、L1（要約を各 repo にコミット＋Skill で grep）を飛ばし、最初から L2 = M2 の対話レイヤをリモート MCP サーバーとして出す。開発者の Claude Code / Claude Desktop が一次対話面になり、アプリ内チャットは同じツールを叩く薄いクライアント（or 後回し）。

※ ただし §11#8 の通り、田村の「repo 集約」理想とは選択が分かれる点。要約 md を repo にも置くハイブリッド（L1＋L2）にするかは田村と要相談。その場合のコミット先も自前 repo（D9）。

13a. 既存アーキ（GDrive 中心）への乗せ方

MCP サーバー = もう一つの "アプリ"。§6 と同じツールを公開し、中身は GDrive を読む（D1 を入れたら query_tasks を追加）。
- ツール＝ §6 そのまま: list_meetings / read_summary(meeting) / search(keyword) /（D1 化後）query_tasks / query_task_history
qmu の既存 MCP と同型・同居: HSS MCP・経友会(zenkoku-keiyukai) MCP と同じ Cloudflare Worker のリモート認証 MCP（OAuth）。§8 の qmu.dev・Worker・Free 枠にそのまま乗る＝新しい配管は GDrive 連携だけ、認証も既存踏襲で自前設計不要。
配布: プラグイン（.mcp.json＝リモート接続＋使い方を教える Skill）を user / 社内 marketplace で 1 回入れれば全 repo で効く。repo ごとのコミットは不要（クロス repo がそもそも L2 の動機）。

13b. L2 先行で必要なもの

項目	内容
デプロイ	MCP はリモート（qmu.dev の Worker）。ローカル MCP では 3 名・複数 repo を跨げない
認証	MCP の OAuth（HSS MCP 踏襲）。§8 の Cloudflare Access はアプリ画面用
空ローンチ回避	§11 #7 を必須化 — 既存 16 会議を GDrive に並べてから出す。L2 は backend ができるまで day-1 価値ゼロなので、過去会議が無いと「空のサーバー」になる
ツール実装の共有	アプリ内チャット（M2）と MCP は同じツール実装を共有＝二度作らない

13c. これで閉じる "実装に活かす" ループ

チケット連携（M3 ＋ Workaholic）: チケット frontmatter に meeting_id → 実装中の Claude Code が「この実装の背景の会議議論」を 1 クエリで引ける。
田村さんの /catch（"何をやったか" ＝ commit/ticket）に、これは "なぜ"（会議の決定・経緯）を同じ Claude Code 面で足すもの。

13d. 代償（承知の上）

L1（repo コミット＋Skill ＝ backend なしで即・repo ローカルに引ける）を捨てる。代わりにクロス repo ＋構造化クエリが最初から手に入る。空ローンチは 13b（§11 #7 必須化）で潰す。
ただし §11#8（田村の repo 集約理想）との兼ね合いは未決 — L1 を完全に捨てるか、要約 md だけ自前 repoにも置くかは要相談。

反映メモ: §7 の **M2 を「MCP サーバーとして実装」**と読み替える。本セクションも計画 — 承認後に実装フェーズへ。

会議 AI ツール（社内版）— 設計メモ ​

決定ログ ​

1. 何を作るか（一言） ​

2. やる / やらない ​

3. 全体アーキ（GDrive 中心） ​

4. データの持ち方 ​

5. 処理フロー ​

6. AI 対話（M2） ​

7. マイルストン ​

8. 技術選定 ​

9. 商品化（B 案）への地続き ​

10. usage を使い切る設計（社長要件） ​

11. オープン issue ​

12. 次のアクション ​

13. 開発者向け配信: Claude Code プラグイン経路（★L2 先行 = MCP-first） ​

13a. 既存アーキ（GDrive 中心）への乗せ方 ​

13b. L2 先行で必要なもの ​

13c. これで閉じる "実装に活かす" ループ ​

13d. 代償（承知の上） ​