# Teams議事録ドラフト生成 — 運用ガイド

## 基本情報

| 項目 | 内容 |
|------|------|
| 業種 | 共通 |
| ユースケース | Teams議事録ドラフト生成 |
| WFパターン | `start(vtt_file+3タグ) → document-extractor(docext1) → llm1(gpt-5-mini, temp=0.2) → end` |
| RAG | なし（自己完結） |
| **提供形態** | **Service API 経由（バックエンドAPI）を正式な提供形態とする**。Difyの公開webappページ経由は使わない（下記の注記参照） |
| 検証結果 | ワークフローロジック・Service API実行は E2E pass（2入力、Dify 1.13.3 / openai gpt-5-mini）。Difyの公開webappページ経由の実行のみ既知の不具合あり（Dify側の問題、本UCの設定不良ではない） |

## 📌 注記: 本UCは Service API 経由で提供する（2026-07-29 決定）

**本UCの正式な提供形態は Dify の Service API（バックエンドAPI）です。** Difyの公開webapp共有ページ（`/chat/xxx` 形式のデモURL）は、Dify 1.13.3 側の不具合により本UCでは使いません。この前提で運用・提案してください。

理由と切り分けの結果:

- Service API（`POST /files/upload` → `POST /workflows/run`）は、**実際の `.vtt` ファイルをリネーム無しで、blocking / streaming どちらのモードでも完全に正常動作する**ことを確認済み（API直接実行6回すべて成功、streamingでは16秒後から議事録本文が逐次到着）。
- 一方、Difyの**公開webappページ経由の実行だけ**が完走しない（`invoke_from=InvokeFrom.WEB_APP` の経路固有。詳細は後述の技術メモ）。これはDify 1.13.3側の不具合であり、本ワークフローのYAML設定の誤りではない。
- したがって、**API経由での統合（自社アプリ組み込み・RPA/バッチ連携・カスタムフロントエンド）には一切支障がない**。むしろ本UCの実運用形態（Teamsから書き出した.vttを自動で流し込む）はAPI連携が自然。

**デモ・提案で使うもの**:

| 用途 | 使うもの |
|------|---------|
| 顧客向けライブデモ（GUIで見せたい） | 同梱の `_poc_demo.html` — Service APIを叩くカスタムフロントエンド。ブラウザでダブルクリックするだけで動く（`.vtt` をそのままアップロード可能） |
| 技術寄りの相手・動作確認 | `scripts/test_teams_vtt_minutes.py`（API直接実行） |
| 顧客システムへの組み込み提案 | Service API（`/files/upload` → `/workflows/run`）。`_poc_demo.html` がそのまま実装リファレンスになる |

**使わないもの**: Difyの公開webapp共有ページ（デモURL）。ここから実行すると、`.vtt`がMIMEタイプ拒否される／`.txt`にリネームしても実行が完走しない。営業トークでも「DifyのデモURLを開いてファイルをドラッグ&ドロップ」という見せ方はしないこと。

> なお、GUIをDifyの公開ページで見せたい場合は姉妹UC「会議議事録ドラフト生成」（テキスト貼り付け版）が確実に動きます。ファイルアップロードの導線が要らない相手にはそちらでも代替可能。

## 概要

Microsoft Teamsの会議で「レコーディング＋文字起こし」を有効にしていれば、会議終了後にTeams（またはStream/OneDrive）から `.vtt` 形式の文字起こしファイルをダウンロードできます。このファイルをアップロードすると、決定事項・ToDo（担当/期限）・論点・次回アジェンダを定型フォーマットで自動生成します（ブラウザでのアップロードは上記の制約に注意）。

**姉妹UC「会議議事録ドラフト生成」との違い**: あちらはテキスト貼り付け方式、本UCは実際のTeams書き出しファイル（.vtt）をそのままアップロードする方式。文字起こしのコピペ作業そのものが不要になり、「Teamsの録画から書き出したファイルをドラッグ&ドロップするだけ」という、より実際の業務フローに近いデモになる。

**設計思想は共通**: プロンプトロジックをワークフロー側に固定し、利用者は「ファイルを上げる → タグを選ぶ」だけ。誰が使っても会社として同じ品質・体裁の議事録が出る。

## 入力フィールド

| 入力 | 種別 | 説明 |
|------|------|------|
| Teams文字起こしファイル | ファイルアップロード（必須・`.vtt`限定・1ファイル） | TeamsからエクスポートしたWebVTT形式の文字起こしファイル |
| 会議種別 | 選択（任意） | 社内定例・チーム会議 / 商談・顧客打ち合わせ / プロジェクト進捗会議 / 経営・役員会議 / 1on1・面談 / ブレスト・企画会議 / その他 |
| 出力形式 | 選択（任意） | 標準議事録（全項目）/ 要点サマリのみ / 決定事項・ToDoのみ / **顧客共有用（社外向けに清書）** |
| 想定読者 | 選択（任意） | 社内 / 社外・顧客に共有 / 経営層に報告 |

## 出力セクション（標準議事録）

会議概要（表）/ 議事サマリ / 議題ごとの要点 / 決定事項 / ToDo（担当・期限の表）/ 保留・未決事項 / 次回に向けて

## デモ手順（Service API 経由 / `_poc_demo.html` を使う）

1. Dify の本ワークフローをインポートして**公開（Publish）**し、アプリ画面の「APIアクセス」から **APIキー（`app-...`）を発行**する
2. `_poc_demo.html` をエディタで開き、冒頭の `WORKFLOW_URL` と `API_KEY` を実行環境に合わせて書き換える
   - セルフホスト: `WORKFLOW_URL = "http://localhost/v1"`（VPSなら `https://dify.ddf-cloud.com/v1`）
   - Dify Cloud: `WORKFLOW_URL = "https://api.dify.ai/v1"`
   - ⚠️ APIキーを書き込んだ `_poc_demo.html` はキーを平文で含むため、外部共有・公開サーバー配置は禁止（このファイルはgitignore済み）
3. `_poc_demo.html` をブラウザでダブルクリックして開く（`file://` のままでOK、ローカルサーバー不要）
4. バンドル同梱の `sample_meeting.vtt`（架空サンプル会議、4名参加）、または実際のTeams会議からダウンロードした `.vtt` ファイルをアップロード（**リネーム不要、`.vtt` のまま通る**）
5. 会議種別・出力形式・想定読者を選択（任意）
6. 実行 → 議事録ドラフトが Markdown で出力される

CLI で確認だけしたい場合は `python scripts/test_teams_vtt_minutes.py` でも同じ経路を通せる。

## 営業への説明ポイント

- 「話者名もTeamsの表示名からそのまま拾うので、誰が何を言ったかが自然に議事録に反映されます」
- 「同じワークフローで"顧客共有用の清書"まで出せるので、商談メモから顧客向け確認メールへの転記作業もなくなります」
- 「Self-hosted なので会議内容は外部に出ません」
- 「Teamsの録画から書き出したファイルをそのまま連携できます」（API連携での訴求。実際の業務では人がファイルを上げるより、Teams/SharePointから自動で流し込む形が本命）
- 「APIで提供するので、お客様の既存の社内ポータルやRPAにそのまま組み込めます」（本UCはService API提供が前提。Difyの画面をそのまま使わせる前提の説明はしないこと）

## 前提条件（重要・営業トークに含めること）

- Teams側で「レコーディング」＋「文字起こし」が有効になっている会議が対象。無効な会議ではそもそも `.vtt` が生成されない（企業のTeams管理者ポリシー次第）。
- `.vtt` 自体には会議の開催日・絶対時刻の情報が無い（相対的な経過時間のみ）。議事録の「日時」欄が「（要確認）」になることがある。

## 技術メモ（実装者向け）

- Difyの `document-extractor` ノードは `.vtt` を標準サポート対象拡張子として認識するが、実際に検証したところ（2026-07-08, Dify 1.13.3）、公式ドキュメントが説明する「同一話者発言の自動マージ」は行われず、`WEBVTT` ヘッダ・cue連番・タイムスタンプ・`<v 話者名>` タグを含む生テキストがそのまま出力される。本UCではこれを前提に、LLMプロンプト側でVTT構文を解析させる設計にしている（Difyのバージョンが上がると挙動が変わる可能性があるため、Dify更新時は要再検証）。
- `prompts/system.md` の自動生成ルールは「start入力はqueryパラグラフ1つのみ・file型禁止」のため、本UCは自動生成パイプラインの対象外。手書きYAMLをそのままimportする（姉妹UC「会議議事録ドラフト生成」と同じ扱い、`force_start_schema=False`相当）。
- E2Eスクリプト: `scripts/test_teams_vtt_minutes.py`（API経由、ファイルアップロード込みで6回成功）

### file型start変数のUI描画バグと修正（重要・他UCにも影響）

start変数を `type: file` にする際、**variable自体に`allowed_file_upload_methods`を明記しないと、Studio/公開デモページどちらの「アップロードUI」も一切描画されない**（ラベルだけ出て入力欄が無い）。app-level の `features.file_upload.allowed_file_upload_methods` を設定しているだけでは不十分。本バンドルはこれに気づき、start変数に直接 `allowed_file_upload_methods: [local_file, remote_url]` を追加して解決した。

**この不具合は本バンドル固有ではない**。`verified/会計/伝票抽出v1_VLM単発GPT4o` をスポットチェックしたところ、同じくvariable-levelの`allowed_file_upload_methods`が欠落しており、同じ「UIが描画されない」症状を再現した。`type: file` を使う会計VLM系4バンドル（伝票抽出v1_VLM単発 / GPT4o / GPT5mini / v5_DocAI雛形）は、恐らく現状すべてブラウザから実行不能な状態にある可能性が高い。未修正（本セッションのスコープ外）。

### Dify 1.13.3 の `.vtt` MIMEタイプ拒否 + webapp実行が完走しない（未解決・確定した2つの不具合）

上記を直しても、`.vtt` ファイル自体はDifyのアップロードUIが**クライアント側で拒否**する（「ファイル拡張子はサポートされていません / text/vtt」）。ネイティブファイル選択ダイアログ（拡張子フィルタでグレーアウトし選択不可）・remote_url貼り付けの2通りで確認。document-extractorノードのバックエンド処理はAPI経由で問題なく動くため、これはDifyのアップロードUIコンポーネントが持つMIMEタイプ許可リストの制約であり、YAML側の`allowed_file_extensions`設定では回避できない。GitHub上でも近い事例(langgenius/dify#11841: `getFileExtension`がファイル名でなくMIMEタイプを優先して拡張子判定する実装)はあるが、`text/vtt`そのものを扱う完全一致issueは見つからなかった。

回避策として、拡張子を `.txt` にリネーム（＋本ワークフローの`allowed_file_extensions`に`.txt`を追加、実施済み）したところ、remote_url経由でのファイル添付自体は成功した（`/api/remote-files/upload` が201を返しファイルチップが表示される）。

**しかし、その状態で「実行」しても最後まで一度も完走しなかった**。新規appを都度作り直し、待機時間を10秒→28秒→38秒と毎回延長して3回検証したが、いずれも同じ結果: `/api/workflows/run` はHTTP 200を返す→ローディング表示が続く→出力されないままアイドルに戻る。裏付けとして以下を確認済み:
- コンソールAPI `/apps/{id}/workflow-runs` に実行記録が一切残らない（3app全てで空配列）
- `docker logs docker-worker-1` に該当時間帯のログが一切無い（ジョブがワーカーに渡っていない）
- `docker logs docker-api-1` にはremote_urlファイルのHEAD/GET取得ログはあるが、workflow実行関連のログは一切無い
- SSRF proxyのログでファイル取得（text/plain, 200）は確認できるが、それ以降の処理ログが無い

以上から、**単なる自動化のタイミングや操作ミスではなく、再現性のある実際の不具合**と判断した。ジョブがワーカーに渡る前の非常に早い段階で（エラーログも残さず）止まっていると推測されるが、Dify側のどのコードパスが原因かは未特定。人間が実際のTeamsエクスポート.vtt（リネーム無し、ローカルファイル選択）で試した場合に同じ現象になるかは未検証（今回の検証はremote_url×.txtリネーム経路のみ）。

**【2026-07-08 決定的な切り分けに成功】** Service APIを `response_mode: "streaming"` で呼び出したところ、実際の `.vtt` ファイル（リネーム無し）で**完全に正常動作した**（`workflow_started`→各ノード実行→16秒後から`text_chunk`が逐次到着、23.5秒時点でも議事録本文を正常に生成中）。これにより:
- 「非同期/Celery/streaming経路自体が壊れている」という仮説は**完全に却下**（`docker-worker-1`の起動ログで`workflow_based_app_execution`キューの購読も確認済み）
- **バグは公開webappページ固有の呼び出し経路（`invoke_from=InvokeFrom.WEB_APP`）だけで発生し、Service API（streaming/blocking問わず）では発生しない**という非常に狭い範囲に絞り込めた
- 認証層（`controllers/web/wraps.py`のJWT/passport検証）も確認したが、失敗時は明示的な401/404/400を返すはずでHTTP 200と矛盾するため除外

つまり **Service API経由なら、streamingモードも含めて完全に問題なく使える**（リアルタイム連携・チャットボット的なUI・自社アプリへの組み込みなど、API経由の統合には一切支障がない）。壊れているのは**Difyの公開webapp共有ページ経由の実行だけ**。

**【2026-07-29 方針決定】この不具合は本UCのブロッカーとしては扱わない。** Service API経由での提供を正式な形態とし（冒頭の注記参照）、GUIが必要な場面は同梱の `_poc_demo.html`（Service APIを叩くカスタムフロントエンド）でカバーする。以下は原因調査の記録として残すものであり、修正待ちではない。

Codexに`AppGenerateService.generate()`内の`invoke_from`分岐の詳細調査を依頼済み（原因は未特定のまま）。将来Difyのバージョンを上げた際にこの不具合が解消されていれば、公開webappページ経由も選択肢に戻せる。**次にこのUCを触る人は、まずDifyのバージョンが上がっていないか確認し、上がっていれば再検証すること。**

## 既存UCとの役割分担

新規UC（「会議議事録ドラフト生成」はテキスト貼り付け版。本UCはTeamsのVTTファイルを直接アップロードする版で、入力導線が異なるだけでプロンプトロジックは共通）。

## 次のステップ（受託提案）

1. 顧客の実際のTeams会議録でカスタマイズデモ（POC）
2. `.vtt` 以外（Zoom/Google Meetの文字起こし形式）への対応拡張
3. 議事録テンプレートの自社フォーマット適合
4. Notion/Backlog等の議事録ツールへの自動転記連携