検証事例レポート #004

Power Automate × LDX hub で
20件の議事録を
全社ダッシュボードに変換する

SharePoint に保存された20部門の月次議事録 Word ファイルを Power Automate で一括処理し、LDX hub ExtractDoc・StructFlow を経て全社横断型 HTML 経営ダッシュボードを自動生成した検証記録。

著者 — 森口功造（川村インターナショナル） 公開日 — 2026.05.09 所要時間 — 約2日
20
処理部門数
100
抽出タスク数
8
HTTPアクション数
21
高リスク件数
背景と目的

なぜバッチ処理が必要だったか

Part 3 で Copilot Studio に LDX hub を MCP 経由で接続し、1件の議事録を構造化抽出することに成功した。しかし次の問いが生まれた。

「20部門の月次議事録を一括処理して、全社横断型の経営ダッシュボードを自動生成できないか？」

MCP はインタラクティブな1件処理に向いている。SharePoint に保存された20件の Word ファイルをバッチ処理するには Power Automate の REST API 呼び出しが適切だ。

フロー設計

1ファイルあたり8つの HTTPアクション

// Power Automate フロー構成（ループ内）
1
パスによるファイルコンテンツの取得 SharePoint
SharePoint から Word ファイルのバイナリを取得
2
POST /uploads LDX hub
アップロードセッション作成 → file_id 取得
3
PUT /uploads/{file_id} LDX hub
Base64エンコードしたファイル内容を送信
4
POST /extractdoc/jobs ExtractDoc
Word → テキスト抽出ジョブ作成 → job_id 取得
5
Do until GET /extractdoc/jobs/{job_id} ポーリング
status = completed まで5秒間隔で繰り返し
6
GET /files/{output_file_id}/content LDX hub
抽出テキストをダウンロード
7
POST /structflow/jobs StructFlow
テキスト → 構造化JSON抽出ジョブ作成
8
Do until GET /structflow/jobs/{job_id} ポーリング
completed 後に results[] 配列変数に追加

ループ完了後、蓄積した20件分のJSONを StructFlow に渡して全社横断分析を実施。その結果を HTML テンプレートに流し込んでダッシュボードファイルとして SharePoint に保存する。

エラーログ

発生した8つのエラーと解決策

1

アップロードエンドポイントが 404

/api/v1/uploads は存在しない。正しくは https://gw.ldxhub.io/uploads（バージョンプレフィックスなし）。API ドキュメントで事前確認が必須。

2

multipart/form-data の壁

POST /files は multipart/form-data が必要だが Power Automate の HTTP コネクターでは正しく送れない。チャンクアップロード（POST /uploads → PUT /uploads/{file_id}）で回避。

3

SharePoint ファイルパスの形式

「ファイルの取得（プロパティのみ）」の出力フィールドは {'{FilenameWithExtension}'}（波括弧付き）。「パスによるファイル コンテンツの取得」アクションで正しいパスを組み立てる必要がある。

4

ExtractDoc エンジン名のエラー

"engine": "docx" は無効。正しくは "engine": "ki/extract"。GET /extractdoc/engines で事前確認が必要。

5

Do until 条件式の構文エラー

新デザイナーの GUI 条件式が boolean を期待するエラー。詳細モードで @equals(body('HTTP_3')?['status'],'completed') と記述することで解決。

6

ExtractDoc はテキストを直接返さない

レスポンスに output_file_id が返り、テキスト本文は GET /files/{'{output_file_id}'}/content で別途ダウンロードが必要。StructFlow 呼び出し前に追加の HTTP アクションが必須。

7

配列変数への追加で null エラー

body('HTTP_5')?['results'] は null になるケースがある。レスポンス全体 body('HTTP_5') を配列変数に追加することで解決。

8

ループ外からのスコープ参照エラー

foreach の多重ネスト内のアクションはループ外から参照不可。ループ内で results[] 配列変数に蓄積し、ループ外では variables('results') を参照する設計に変更。

検証結果

20部門・全件処理完了

全社タスク一覧

20部門から合計100件のアクションアイテムを抽出。担当者・期限・関連部門を含む構造化データとして一覧表示。

深刻度別リスク一覧

高リスク21件・中リスク複数件を全部門から抽出・統合。色分けカード形式で経営層が即座に把握できる形式で表示。

部門間依頼マップ

60件超の部門間依頼・連携事項を可視化。どの部門がどの部門に何を依頼しているかが一目でわかる。

部門別サマリーカード

20部門それぞれのタスク・リスク・部門間依頼をカード形式で一覧。経営会議前の確認に最適な形式。

アーキテクチャ上の重要な気づき LDX hub がすべての「知性」を担っている — テキスト抽出（ExtractDoc）と構造化データ生成（StructFlow）。HTML テンプレートはその JSON を受け取って表示するだけ。処理エンジンとプレゼンテーション層が完全に分離されており、デザインだけ変えたい場合はテンプレートのみ修正すればよい。
MCP vs REST API 比較

実際に両方やった結果

このシリーズで MCP（Part 3）と REST API（Part 4）の両方を実装した。それぞれの特性を整理する。

比較項目 MCP（Part 3） REST API（Part 4）
セットアップ時間 約2時間 約2日
発生エラー数 2件 8件超
ポーリング処理 エージェントが自動処理 Do until ループを手動構築
ファイルアップロード MCP チャンク API REST チャンク API
1件処理（対話型） ✓ 最適 過剰な構成
バッチ処理（20件） ✗ 非現実的 ✓ 最適
定期スケジュール実行 ✗ 不向き ✓ 対応可能
今回の学び

次回に活かせるポイント

まず1件でテストしてから20件へ
全件処理でデバッグしていたために多くの時間を消費した。「ファイルの取得（プロパティのみ）」の「上から順に取得」を1に設定して1件ずつ確認する習慣が必須。
API エンドポイントは必ずドキュメントで確認
/api/v1/ プレフィックスの有無など、エンドポイントのパスは思い込みで入力しない。GET でエンジン一覧・ジョブ一覧を確認してから構築する。
Do until 条件は詳細モードで記述する
GUI の条件ビルダーが生成する式は boolean を期待するエラーを引き起こす。@equals() を使った詳細モードの式が確実。
ExtractDoc の出力はファイル経由
ExtractDoc は output_file_id を返す。テキスト本文を取得するには GET /files/{output_file_id}/content が必要。StructFlow との間に必ずこのステップが必要になる。
次のステップ

今後の展開

項目内容
ダッシュボード品質比較検証 構造化データ（StructFlow）を用いたダッシュボードと、非構造データ（生テキスト）を直接 LLM に渡したダッシュボードの品質・精度・コストを比較する
スケジュールトリガー化 手動トリガーから月次自動実行へ変更
エラーハンドリング強化 API 失敗時のサイレントタイムアウト対策
RefineLoop の統合検証 翻訳品質改善機能の同パイプライン組み込み