meeting-transcription

会議の文字起こし

このスキルを使うと、AI エージェントが会議の音声録音を、構造化された実行可能なドキュメントにまとめられます。エージェントは、生の音声入力から話者のダイアライゼーション、文字起こし、インテリジェントな要約まで、パイプライン全体を処理します。出力には、話者ラベル付きのタイムスタンプ入り文字起こし、主要な議論の要点をまとめた簡潔な要約、決定事項の一覧、担当者と期限が明確に設定されたアクションアイテムが含まれます。

ワークフロー

1. 音声入力を取り込み、検証します。 会議の音声ファイルを受け取り、対応形式（MP3、WAV、M4A、FLAC、OGG、WebM）であることを確認します。ファイルサイズ、長さ、チャンネル数（モノラルかステレオか）を確認します。音声が標準外の形式の場合は、FFmpeg などの前処理ツールを使って WAV 16kHz モノラルに変換します。後続処理で参照できるよう、ファイルのメタデータ（長さ、サンプルレート、コーデック）を記録します。

2. 音質を高めるために音声を前処理します。 ノイズ低減を適用し、背景のハムノイズ、キーボードのクリック音、室内の反響を抑えます。録音全体の音量を正規化し、小さな声は増幅し、大きな音の部分は減衰させます。録音に複数のチャンネル（例：ステレオのポッドキャスト）がある場合は、各チャンネルが既知の話者に対応しているときにチャンネルを分割します。信号対雑音比が非常に低い部分には、信頼性が低い可能性があることを示します。

3. 話者のダイアライゼーションを実行します。 録音全体から異なる話者を特定し、ラベルを付けます。音声紋のクラスタリングを使い、話者が互いに割り込んだり、短い間隔で続けて話したりする場合でも区別します。デフォルトでは一時的なラベル（Speaker 1、Speaker 2 など）を割り当て、処理の前後どちらでもユーザーが名前の対応付けを指定できるようにします。発話が重なっている場合は、その部分を主な話者に割り当て、重なりがあることを記録します。

4. 音声をテキストに文字起こしします。 前処理と話者のダイアライゼーションを済ませた音声を、音声認識エンジン（例：Whisper、Deepgram、Google Speech-to-Text）に入力します。単語単位またはセグメント単位のタイムスタンプ付き文字起こしを作成します。句読点を補い、大文字と小文字の誤りを修正します。複数の言語が使われる会議では、言語の切り替わりを検出し、各セグメントを元の言語で文字起こししたうえで、必要に応じて文中に翻訳を付けます。

5. 構造化された要約を作成します。 文字起こし全体を分析し、主要な議題、決定事項、未解決の質問、アクションアイテムを抽出します。関連する議論のセグメントをテーマ別のセクションにまとめます。各アクションアイテムについて、担当者（話者ラベルまたは名前）、タスクの説明、言及された期限を特定します。「概要」「主要な議論の要点」「決定事項」「アクションアイテム」「フォローアップ」の各セクションを明確に分けた要約ドキュメントを作成します。

6. 出力を整えて納品します。 Markdown、JSON、プレーンテキストなど、指定された形式で最終出力を作成します。タイムスタンプ付きの全文字起こしと構造化された要約を、別々のセクションまたはファイルとして含めます。カレンダー連携が有効な場合は、会議をカレンダーの予定データと照合し、会議タイトル、出席者一覧、アジェンダを出力のヘッダーに自動入力します。

使用方法

音声ファイルのパスと、任意で話者名の対応付け、出力形式の希望、言語のヒントをエージェントに指定します。エージェントは、全文字起こしと構造化された要約を返します。

プロンプト形式：

Transcribe and summarize the meeting recording.
Audio file: [path or URL to audio file]
Speakers: [optional name mapping, e.g., "Speaker 1 = Priya, Speaker 2 = James"]
Language: [primary language, e.g., English]
Output format: [markdown / json / text]

例

例 1：話者ラベル付きのタイムスタンプ入り文字起こし

入力：

Transcribe the meeting at /recordings/sprint-planning-2026-02-10.m4a
Speakers: Speaker 1 = Priya, Speaker 2 = James, Speaker 3 = Dana
Output format: markdown

出力（文字起こしの抜粋）：

# Sprint Planning — February 10, 2026

Attendees: Priya (Engineering Lead), James (Product Manager), Dana (Designer)
Duration: 34 minutes

---

[00:00:12] Priya: Alright, let's kick off sprint planning. James, can you
walk us through the priorities for this sprint?

[00:00:18] James: Sure. The top item is the checkout flow redesign. We got
feedback from the beta group that the three-step process is causing drop-off
at step two. Dana, you had some mockups ready?

[00:00:31] Dana: Yes, I've simplified it to a single-page layout. The address
and payment fields are on the same screen now with a collapsible order summary
on the right. I'll share the Figma link after this call.

[00:00:48] Priya: That sounds good. How much engineering effort are we looking
at? I'm thinking this is a two-sprint task if we include the backend changes
for the new validation logic.

[00:01:02] James: Can we scope it so the frontend ships this sprint and the
backend validation follows in the next one?

[00:01:10] Priya: That works. We can use client-side validation as a stopgap.
I'll create the tickets after this meeting.

[00:01:22] James: Great. Second priority is the analytics event tracking.
We're missing conversion events on the pricing page.

[00:01:35] Dana: No design implications there. It's purely instrumentation.
No UI changes needed.

例 2：アクションアイテム付きの構造化された要約

出力（同じ会議の要約）：

## Meeting Summary

### Overview
The sprint planning session covered three topics: the checkout flow redesign,
analytics event tracking for the pricing page, and an update on the mobile
onboarding experiment. The team agreed to split the checkout work across two
sprints and prioritize the analytics instrumentation for immediate deployment.

### Key Discussion Points
- **Checkout flow redesign:** Beta feedback indicates 35% drop-off at step 2.
  Dana presented a single-page layout. The team agreed on a phased rollout:
  frontend this sprint, backend validation next sprint.
- **Analytics event tracking:** Conversion events are missing on the pricing
  page. No design changes required. Estimated at 3 story points.
- **Mobile onboarding experiment:** A/B test results not yet significant.
  The team will extend the experiment by one week.

### Decisions
1. Checkout redesign split: frontend in Sprint 14, backend in Sprint 15.
2. Client-side validation will serve as a temporary stopgap.
3. Analytics instrumentation ships this sprint with no design dependency.
4. Mobile onboarding experiment extended by one week.

### Action Items
| Owner | Task                                              | Deadline  |
|-------|---------------------------------------------------|-----------|
| Priya | Create Jira tickets for checkout frontend work    | Feb 10    |
| Dana  | Share Figma link for single-page checkout mockup  | Feb 10    |
| Priya | Estimate backend validation effort for Sprint 15  | Feb 12    |
| James | Write analytics event spec for pricing page       | Feb 11    |
| James | Schedule decision review for mobile onboarding    | Feb 17    |

### Follow-ups
- Priya to sync with the backend team on API contract changes.
- Dana to run a usability test on the single-page layout with 3 users.
- James to share the A/B test dashboard link in Slack for monitoring.

ベストプラクティス

• 可能であれば、ステレオ録音またはマルチチャンネル録音を使用します。 話者ごとに音声チャンネルを分けると、話者分離の精度が大幅に向上します。参加者ごとの音声トラックに対応した会議プラットフォームをチームに推奨してください。
• 事前に話者名の対応付けを行います。 話者の識別情報をあらかじめ対応付けておくと、文字起こし後の手動でのラベル付け直しを避けられ、担当者名を含むアクション項目を記載した、より充実した要約を作成できます。
• 信頼度の低いセグメントを確認します。 音声認識の信頼度スコアが0.7未満の文字起こしセグメントにフラグを付け、人による確認を促してください。こうしたセグメントは、複数人の発話の重なり、不明瞭な発話、強い訛りに該当することがよくあります。
• 要約は1ページに収めます。 優れた要約は文字起こしより短く、内容を言い換えただけのものではありません。決定事項とアクション項目に焦点を当ててください。詳細をすべて確認したい人のために、文字起こしは残しておきます。
• 出力では文字起こしと要約を分けます。 必要な内容はユーザーによって異なり、記録全体を必要とする人もいれば、アクション項目だけを必要とする人もいます。別々のセクションまたはファイルとして両方を提供してください。
• カレンダーのメタデータと連携します。 エージェントがカレンダーの予定にアクセスできる場合は、会議のタイトル、参加者リスト、議題を自動入力して手動入力を減らし、出力のヘッダーを充実させます。

エッジケース

• 発話の重なりや複数人の同時発話。 複数人が同時に話す場合は、最も大きな声の話者にそのセグメントを割り当て、[crosstalk] のような注釈を追加します。内容を黙って削除しないでください。
• 英語以外の言語、または複数言語が混在する会議。 言語識別モデルを使用して、会話の途中での言語の切り替わりを検出します。各セグメントは元の言語で文字起こしし、必要に応じて角括弧内に英語訳を併記します。
• 音質が悪い場合。 信号対雑音比が非常に低い場合（例：騒がしい環境での電話録音）は、文字起こしの精度が低下する可能性があることをユーザーに警告し、不確かな箇所に [inaudible] マーカーを付けます。
• 非常に長い会議（2時間以上）。 長時間の録音は、メモリの問題を避けるために分割して処理します。ユーザーが内容を確認しやすいよう、全体の要約に加えてセクションごとの要約も作成します。
• 機密情報やセンシティブな内容。 文字起こしに個人を特定できる情報、財務データ、法的な議論が含まれる場合は、出力にアクセス制限のフラグを付け、設定されていれば編集ルールを適用します。