Transcript In

transcript-in スキル

Meet で話した内容の書き起こしを、~/.claude/board/transcripts/ に整形して置くだけのスキル。抽出とタスク化は /transcript-digest の仕事なので、ここではやらない。

入力経路

経路A: パスを指定（確実・推奨）

/transcript-in ~/Downloads/Project Alpha定例\ -\ 2026_07_29\ -\ 文字起こし.docx

引数にファイルパスが渡されたらそれを使う。複数渡されたら全件処理する。

経路B: 引数なし → ~/Downloads から探す

~/Downloads の中から、直近7日以内に更新された .docx / .txt / .md のうち、ファイル名に以下を含むものを候補にする:

文字起こし / Transcript / Gemini / メモ / Meet / 会議 / 会議名らしい語

候補が複数あれば一覧を出してユーザーに選ばせる。0件なら「~/Downloads に書き起こしらしきファイルが見つかりませんでした。パスを指定してください。」と伝えて終了する。

経路C: Google Drive から直接取得（/transcript-in --drive）

⛔ 2026-07-31 検証結果: 書き起こし本文の完全な自動取得はできない

一覧の取得までは問題なく動く。本文の持ち出しだけが構造的に不可能である。三経路すべて塞がっていることを実測で確認済みなので、同じ検証を繰り返さないこと。

取得手段	戻り値	結果
read_file_content	素のテキスト	❌ 第1タブ（Geminiメモ）しか返さない。tab 指定パラメータは存在しない（引数は fileId と includeComments のみ・スキーマ実査済み）
download_file_content	base64	❌ 全タブ取れるが、モデルが base64 を書き写す過程で破損する（実測: 11,332バイトを Write → デコードで invalid continuation byte at position 3021）。echo <base64> | base64 -d で argv 渡しにすると今度は巨大 argv でハングする（4件で14分→停止）
search_files の contentSnippet	素のテキスト	❌ 冒頭のみで打ち切られる

根本原因: MCP のツール結果はモデルのコンテキストにしか入らず、ディスクへの側路が無い。したがってバイト列は必ずモデルの出力トークンを通ることになり、base64 のような無冗長な文字列は忠実に運べない。これは工夫で回避できる類の問題ではない。

→ 本文が要るときは経路A/B（.txt を手動ダウンロード）を使う。 Google ドキュメント上で文字起こしタブを選んでから ファイル → ダウンロード → 書式なしテキスト。

以下に残す手順は、一覧の取得と、本文をモデルが読んでその場で要約・抽出する用途にはそのまま使える（ディスクに原文を残す用途にだけ使えない）。

前提と手順（一覧取得は動作確認済み）

前提

claude.ai の Google Drive コネクタが接続済みであること（@example.com アカウント）。headless 実行でも使えることは検証済み。未接続だとツール自体が authenticate / complete_authentication の2つに縮退するので、その場合は取得を試みずユーザーに接続を依頼して終了する。

手順

1. 一覧を取る — mcp__claude_ai_Google_Drive__search_files を parentId = YOUR_DRIVE_FOLDER_ID（マイドライブ直下の Meet Recordings・本人がオーナー）で1回呼ぶ。所要は約16秒。

⚠️ ファイル名で 文字起こし を検索してはいけない。 別部門の共有ドライブに 【文字起こし】<相手先名>(YYYYMMDD) のような同名パターンの別物が大量にあることがあり、他部署のヒアリング記録を丸ごと吸い込む。絞り込みは必ず parentId を主軸にする。

2. 未取得のものを選ぶ — ~/.claude/board/transcripts/ の既存ファイルと .processed.log を見て、まだ取り込んでいないものだけを対象にする。

3. 本文を取る — mcp__claude_ai_Google_Drive__download_file_content で text/plain としてエクスポートする。

• read_file_content は使わない。 これは Google ドキュメントの第1タブしか返さない。Meet の記録は第1タブが Gemini の要約メモ、**第2タブが文字起こし（逐語）**という構成なので、read_file_content だと要約しか取れず、この方式が前提とする「生の情報量」が失われる。7/29 に「文字起こしが生成されていない」と誤判定した原因がこれ。
• download_file_content の text/plain エクスポートは全タブを結合して返す。実測: 同一ドキュメントで read_file_content 約1,000字 / 手動 .txt ダウンロード 1,425字（選択中のタブのみ）/ download_file_content 3,341字（メモ＋文字起こし両方）。API 経由が最も情報量が多い。

4. 中身を検証してから保存する — 本文に ：（話者ラベル）と 00:0 形式のタイムスタンプが含まれることを確認する。含まれていなければ要約メモしか取れていないので、保存せずその旨を報告する。

観測されたファイル命名（Meet Recordings 直下）

• ファイル名は「Gemini によるメモ」だが、中身には文字起こしタブも入っている。名前に釣られて要約扱いしないこと。
• 会議名が空のときは先頭に半角スペースが1つ入る。名前でマッチングするならここに注意。
• mimeType はいずれも application/vnd.google-apps.document。
• 生成には会議終了から数分のラグがある。直近の会議が無くても異常ではない。

会議名の決め方

会議名なし形式のファイルは frontmatter の meeting を本文から推定するしかない。推定した場合は （推定） を付けて明示する（勝手に確定させない）。自動実行時はユーザーに確認できないので、必ずこの表記を残して後から直せるようにする。

実行手順

1. 本文の取り出し

.docx で pandoc を優先する理由: 検証したところ textutil は発言ごとの改行を潰して1行に結合してしまう（同じファイルで pandoc 8行 vs textutil 2行）。書き起こしでは「誰がどこで区切って話したか」自体が情報であり、話者数から kind（solo/meeting）を判定する根拠にもなるため、改行を保持できる pandoc を使う。

（Google ドキュメントを「Word 形式(.docx)でダウンロード」するとこの経路になる。.txt を選べるならそのほうが確実。）

本文が空になった場合はそこで止めてユーザーに報告する。空のファイルを transcripts に置くと、/transcript-digest が無内容のタスクを作ってしまう。

2. メタ情報の判定

date — ファイル名に含まれる日付（2026_07_29 / 2026-07-29 / 20260729 等）を優先。無ければ本文冒頭の日付、それも無ければファイルの更新日時を使う。

meeting — ファイル名の会議名部分を使う。Meet の書き起こしは会議名を含んだ名前で保存されるため、通常はここから取れる。取れない場合は本文から推定し、推定した旨を添えてユーザーに確認する（勝手に決めない。ここが後で Board のタスクタイトルの接頭辞になるため）。

kind — solo か meeting を判定する:

• 発言者が実質1人だけ → solo（一人で Meet に入って話した独り言）
• 複数の発言者がいる → meeting

判別がつかない場合はユーザーに聞く。/transcript-digest が抽出の観点を切り替える鍵になるため、雑に決めない。

source_url — Drive の URL が分かる場合のみ記載。手動取り込みでは元ファイルの絶対パスを書く。

3. 保存

保存先: ~/.claude/board/transcripts/YYYY-MM-DD-<slug>.md

<slug> は会議名を英数字とハイフンに落としたもの（日本語のみの会議名なら意味の通る英語かローマ字にする。長すぎる場合は40文字程度で切る）。

---
date: 2026-07-29
meeting: Project Alpha定例
kind: meeting
source_url: /Users/you/Downloads/Project Alpha定例 - 2026_07_29 - 文字起こし.docx
---

（本文をそのまま。要約しない・整理しない・削らない）

本文は絶対に要約しない。 このスキルの目的は「渡せる背景情報の量を最大化する」ことなので、言い淀み・繰り返し・脱線を含めて丸ごと残す。整理は /transcript-digest 以降の仕事。

4. 冪等性（重要）

同名ファイルが既に存在する場合は上書きせずスキップし、その旨を報告する。

~/.claude/board/transcripts/ は board-guard が Bash 経由の上書き・削除をブロックしているが、Write ツールは board-guard の対象外（PreToolUse の matcher が Bash のみ）なので、Write では上書きできてしまう。取り込み済みの書き起こしを壊さないよう、Write の前に必ず存在チェックすること。

同じ会議を再取り込みしたい場合は、ユーザーに確認してからファイル名に -2 等を付けて別ファイルにする。

5. 報告

取り込み: 2 件 / スキップ: 1 件（既存）

✅ 2026-07-29-proj-alpha-teirei.md
   Project Alpha定例（meeting・12,400字）
✅ 2026-07-29-proj-alpha-solo.md
   Project Alphaの詰め（solo・4,100字）
⏭ 2026-07-28-product-planning.md（既に取り込み済み）

次: /transcript-digest で決定事項と自分のタスクを抽出できます。

字数を出すのは、要約だけが取れていて生の文字起こしが入っていない事故（社内で報告あり）に気づけるようにするため。一人で数分話した書き起こしが1,000字を大きく下回る場合は、Gemini の要約メモしか取れていない可能性が高いので、その旨を警告する。

境界

• 対象は会社（@example.com）のデータのみ。個人アカウント由来・~/side-projects（副業）の内容は置かない
• 本文を要約・編集しない。整形するのは frontmatter だけ
• 既存ファイルを上書きしない