Forms + Power Automate構成をやめて、DataSpiderで即時処理に寄せた話
はじめに
業務システムの設定変更を自動化するにあたり、当初は Microsoft Forms と Power Automate を中心とした構成で運用していました。
ノーコードで構築でき、導入コストも低く、初期段階としては合理的な選択でした。
しかし、運用を続ける中で「即時性」と「可観測性」に課題が出てきたため、最終的に DataSpider の HTTPトリガーを用いた構成へと移行しました。
本記事では、その背景・設計判断・実装イメージについて整理します。
従来の構成
当初は以下のようなフローでシステム設定変更を行っていました。
MS Forms
↓
MS Power Automate
↓
メール送信
↓
DataSpider
↓
API実行（設定変更）
この構成を採用した理由
- ノーコードで構築可能
- Microsoft製品で統一できる
- 既存の運用に組み込みやすい
課題
運用していく中で、以下の問題が顕在化しました。
1. 外部サービス障害に気付きにくい
Forms や Power Automate 側で障害が発生しても、即座に検知できません。
特に、メールトリガーを経由する構成のため、「処理が来ない＝障害」と気付きにくい状態でした。
2. 非同期連携によるタイムラグ
メール送信をトリガーにして DataSpider が処理を開始するため、
- 実行までに10-15分ほどラグがある
- 処理結果が即時に分からない
という問題がありました。
3. 入力不備にすぐ気付けない
入力値に誤りがあった場合でも、
- ユーザーは送信時に気付けない
- DataSpider 側で処理された後に問題が発覚する
結果として、手戻りや問い合わせが増える要因になっていました。
解決策
DataSpider の HTTPトリガーを利用し、入力〜処理までを一体化した構成に変更しました。
ブラウザ（フォーム） → DataSpider（HTTPトリガー） → API実行 → 結果返却
ポイント
- フォームを自前で用意（HTML）
- DataSpider が直接リクエストを受け取る
- 入力値チェックをその場で実施
- 問題なければ即API実行
- 結果をそのままレスポンスとして返却
実装イメージ
今回はDataSpiderのフォーム画面経由でAPIを実行し、
処理結果を画面に出力する仕組みを、簡易的な日本語翻訳システムとして実装します。
フロー
HTMLトリガー用のURLにアクセス
↓
DataSpiderがフォーム画面をブラウザに出力
↓
ユーザーが日本語を入力し、「翻訳する」ボタンを実行
↓
DataSpider側で入力値（prm01）を受け取る
↓
外部APIにリクエストを送信（翻訳処理）
↓
APIのレスポンスを画面に出力
実装手順
DataSpider側の構成
DataSpiderでは以下の2つのスクリプトを用意します。
- ① 画面表示スクリプト（フォーム表示用）
- ② 結果出力スクリプト（API実行＋結果表示）
ポイント
画面ごとにスクリプトを分け、それぞれHTTPトリガーとして登録します。
実装手順フロー
①と②のスクリプトでそれぞれ下記の手順を実施します。
スクリプト作成 → サービス登録 → HTTPトリガー設定
1. 結果出力スクリプトの作成
① スクリプト変数の設定
-
outPrm
HTML出力用の変数（スクリプト出力変数として使用） -
translated_text
APIレスポンスから翻訳結果を格納する変数 -
prm01
ユーザー入力値を格納する変数（スクリプト入力変数として使用）
② コンポーネント構成
マッピング（APIリクエスト作成）
↓
POST実行（API呼び出し）
↓
マッピング（レスポンス取得）
↓
HTMLデータ生成
↓
マッピング（outPrmへ設定）
③ HTMLデータ生成（結果画面）
以下のHTMLを入れます
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<title>翻訳結果</title>
</head>
<body>
<h2>翻訳結果</h2>
<p><strong>入力：</strong> $script.prm01</p>
<p><strong>翻訳結果：</strong> $script.translated_text</p>
</body>
</html>
④ マッピング設定
HTMLデータ生成コンポーネントの出力（html_data）を、
スクリプト出力変数 outPrm にマッピングします。
⑤ サービス登録
作成したスクリプトをサービスとして登録します。
2. 結果出力スクリプトのHTTPトリガー作成
-
マイトリガーから「新しいHTTPトリガー」を作成
-
トリガー名を設定
-
実行パス：/testkekka （任意）と設定します
4. スクリプト出力変数に ${trigger.outputData} を設定
5. 上記設定の説明枠内に自動生成されるスクリプト起動用の URL を取得します。
3. フォーム画面表示スクリプトの作成
① スクリプト変数
- outPrm：HTML出力用（スクリプト出力変数）
- prm01：入力値保持用
② コンポーネント
- HTMLデータ生成 ⇒マッピング
③ HTMLデータ生成（入力フォーム）
以下のHTMLを入れます
<form method="GET" action="（２-⑤で取得したＵＲＬ）">
<label>翻訳したい日本語：</label><br>
<input type="text" name="prm01" value="$script.prm01" required>
<br><br>
<input type="submit" value="翻訳する">
</form>
ポイント
- action="２-⑤で取得したＵＲＬは、②結果出力スクリプトを表示させるためのHTTPトリガー用のURLです
- $script.prm01 は、ユーザーが入力した値を取得するためのスクリプト変数
- **※ 業務データを扱う場合は、POSTメソッドの使用やリクエストボディでの受け渡しを推奨します。
**
④ マッピング設定
「マッピング」を開き、③で作成したHTMLデータ生成の出力（html_data）を、
スクリプト出力変数 outPrm にマッピングします。
⑤ サービス登録
フォーム表示スクリプトをサービス登録します。
4. フォーム画面のトリガー作成
- マイトリガーから「新しいHTTPトリガー」を作成
- トリガー名を設定
- 実行パス：/testhonyaku
- スクリプト出力変数に ${trigger.outputData} を設定
- URLを取得
5. 動作確認
4-5で取得したURLにブラウザからアクセスし、
フォーム入力 → 翻訳結果表示までの動作を確認します。
補足
今回は翻訳APIを例にしていますが、以下のような用途にも応用可能です。
- 入力チェックAPI
- 業務システム連携API
- 通知・ワークフロー連携
改善効果
Before / After
| 項目 | Before | After |
|---|---|---|
| 実行タイミング | 非同期（メール経由） | 即時 |
| 入力チェック | 後段で検知 | その場で検知 |
| 障害検知 | 気付きにくい | 直接確認可能 |
| ユーザー体験 | 低い | 改善 |
具体的なメリット
- 入力ミスを即時フィードバックできる
- API実行結果をその場で確認可能
- 外部SaaS障害の影響を受けにくくなった
- 運用フローがシンプルになった
注意点・デメリット
UIの限界
- HTMLベースの簡易フォームのため、リッチなUIには不向き
スケーラビリティ
- 同時実行数や負荷耐性は考慮が必要
⇒実運用では本番環境と待機環境それぞれにトリガーを設定し、ロードバランサでアクセスの自動分散を実施しています。
まとめ
外部SaaSを組み合わせた構成は手軽に構築できる一方で、
- 可観測性
- 即時性
- 制御性
といった観点では制約が出てくるケースがあります。
今回のように DataSpider の HTTPトリガーを活用することで、
小規模な業務ツールであれば「入力〜処理までを一体化」したシンプルな構成を実現できます。
同様に「メールトリガーの遅延」や「外部依存」に課題を感じている場合は、選択肢の一つとして検討する価値はあると思います。