ワークフロー

​

概要

手動で繰り返される業務を自動化されたワークフローに変えます。

​

ワークフローの種類

ワークフローには 3 種類あります。

​

ワークフローのモード

Run モードには 2 種類あります。

• ライブ実行: ワークフローをライブで自動実行します。ブラウザセッションを閉じる、または URL が変更されると処理が終了します。
• バックグラウンド実行: ワークフローはサーバーサイドで実行され、ブラウザタブを閉じたりデバイスの電源を切ったりしても処理が継続されます。

​

ワークフロー内のノード

ワークフロー内のノードには Action と Event の 2 種類があります。

​

Action ノード

Action は、トリガーに応じてワークフローが実行する特定のタスクまたは操作です。

​

Event ノード

Event は、ワークフローを起動する条件を設定できます。

​

ワークフロータイプ別のアクションノード対応状況

すべての Action ノードが、すべてのワークフロータイプで利用できるわけではありません。各ワークフロータイプは異なるユースケース向けに設計されており、機能的・セキュリティ的に妥当な箇所でのみ特定のアクションが利用可能です。

​

Action ノードの詳細

​

Instruct

事前入力済みのプロンプトや前のステップから応答を生成します。AI にどのように応答してほしいかが明確に決まっている場合に使用します。

• ワークフローの自動化では、複数ソースからのデータを統合する必要があります。そのため、まさにこの統合を担う Instruct ノードは、どのワークフローでも最もよく使われるノードの一つです。
• Instruct ノードはワークフローのロジックの中核です。データを受け取り、情報の統合、テキスト生成、意思決定などの特定のアクションを実行します。
• 指示が具体的であるほど、出力の品質が向上します。「これを要約して」のような一般的な指示ではなく、どのような要約が欲しいかを明確に指定してください。例えば「この記事を、主要な論点と結論に焦点を当てた 3 つの箇条書きに要約してください。トーンは簡潔かつプロフェッショナルに。」のように指定します。
• マルチステップのワークフローでは、複数の Instruct ノードを連結します。これにより、複雑なタスクを小さく管理可能な部分に分解できます。例えば、1 つのノードですべてを行う代わりに、最初のノードで長文ドキュメントを要約し、2 番目のノードで要約から重要な事実を抽出し、3 番目のノードでそれらの事実を使ってメール文を起草、といったやり方が可能です。
• 最終出力の形式についても Instruct ノードに正確に指示しましょう。JSON、リスト、表、プレーンテキストなどでの応答を指定できます。例えば「‘product_name’ と ‘price’ をキーとする JSON オブジェクトで出力してください」のように指定します。これは、後続のノードがデータを利用するために不可欠です。

​

Agent

推論、コード実行、ファイル生成が可能なエージェント型タスクを実行します。

• ワークフローで、他のアクションタイプの固定機能を超える柔軟な多段階の推論、コード実行、ファイル生成が必要な場合に Agent ノードを使用します。複雑なタスクにリアルタイムで適応できる「動的なオペレーター」と考えてください。
• 必要とする作業の複雑さ全体をカバーするには狭すぎたり硬直的すぎたりする他のアクションノードとは異なり、Agent ノードは動的に設計されています。指定した目標に基づいて、使用するツール (推論、コード、連携、ファイル生成) を自ら判断できます。
• Agent ノードは汎用的な問題解決ツールとして扱えます。同一ステップ内で、データ分析、データの変換やクレンジング、計算の実行、シナリオのシミュレーション、構造化された出力 (JSON、表、整形済みテキストなど) の生成に使用できます。
• Agent ノードはコードを実行できるため、複雑な入力の解析、複数ソースからのデータの突き合わせ、ビジネスルールの適用といった技術的・反復的なロジックを、多くの個別ワークフローステップを構築せずに、そこへ委ねることができます。
• Agent ノードを使ってファイル (例: レポート、サマリー、処理済みデータセット) を生成し、後続のノードに引き渡せます。
• 多数の Instruction ステップを連結しないと実現できないようなプロセスには、Agent ノードを使用しましょう。Agent は複数のサブタスクにわたって推論し、中間的なアクションを判断し、統合された結果を生成できるため、ワークフローの複雑さを軽減できます。

• Agent ノードへの指示は明確かつ正確にしましょう。「これを分析して」のような漠然とした依頼ではなく、目的、制約、出力形式を含めてタスクを明確に定義してください。例えば「この CSV データをクリーニングし、重複行を削除し、月ごとの総収益を計算して、‘month’ と ‘total_revenue’ フィールドを持つ JSON オブジェクトを返してください」のように指定します。
• 期待する出力形式 (例: JSON、Markdown の表、プレーンテキスト、ファイル) を明確に指定してください。Store into a Dataset、Create Report、または連結された別の Agent ノードなど、後続のノードで出力を利用する場合に特に重要です。

​

Upload Files

ユーザー自身または他のユーザーにファイルのアップロードを依頼し、ワークフロー内でインデックス化して利用できるようにします (例: 実行ごとに新しいレポートやドキュメント)。

• 新しいレポートや日次ログなど、使用ごとに変化するファイルには Upload Files ノードを使用します。
• このノードはファイルを変数として扱うため、ワークフロー実行ごとに異なる内容を処理できます。
• 一方、固定された情報セットに繰り返しアクセスする必要がある場合は、Contextualize From Library ノードを使用します。製品カタログや標準作業手順書 (SOP) のような、静的な参照情報に繰り返し参照するのに最適です。ファイルを永続的な参照データソースとして扱います。

​

Process OCR

画像内のテキストを理解します。

• スキャンしたドキュメントや写真など、画像からテキストを抽出するタスクには Process OCR を使用します。光学式文字認識 (OCR) 技術が画像を解析し、テキストを認識して機械可読な形式に変換します。物理ドキュメントのデジタル化、データ入力の自動化、スキャンしたコンテンツを検索可能にする場合に特に有用です。

​

Input Text

Run モード中にユーザーへ情報入力を求めます。

• Input Text ノードは、ユーザーの入力を取得して保存するためのノードで、その値は変数として機能します。単独で動作するノードではなく、より大きなシステム内で他のノードと接続する重要な構成要素として機能します。

​

Download Document

PDF、DOC、または XLSX 形式でダウンロード可能なレポートを作成します。

• Download Document ノードは、Instruct ノードからの統合データをダウンロード可能なレポートに変換するのに適しています。処理された情報を、洗練された共有可能なドキュメントに仕上げられます。
• Download Document ノードはプロセスの最終ステップとして使用するときに最も力を発揮します。

強力な組み合わせ:

• Instruct ノードと組み合わせて、テキスト出力をプロフェッショナルなレポートに
• Process OCR ノードの後に使い、抽出したテキストを整ったドキュメントに整形
• Send Email と組み合わせて、レポートを自動添付・配布

​

Contextualize From Library

コンテキストとしてソースに接続します。

• Contextualize From Library ノードは、さまざまなソースからインデックス化されたデータすべてに、一元的にアクセスできる手段を提供します。自動化タスクのコンテキストとして特定の情報を選択したい場合に使用します。ワークフローを情報で支えたり導いたりするため、ユーザーは組織のナレッジ全体にアクセスできます。

• このノードが提供する情報は、含まれるデータの品質に左右されます。最新かつ正確な情報をワークフローで使えるように、統合されたドキュメントやデータベースを定期的に更新してください。

​

Recognize Image

コンピュータビジョンで画像または画像の一部を検出します。

• ワークフローで、オブジェクトの識別、ラベルの読み取り、シーンの理解など、画像の内容を検出・解釈・分類する必要がある場合に Recognize Image を使用します。
• Recognize Image はワークフローの「目」と考えてください。OCR ドキュメント処理がテキストを抽出するのと同様に画像から視覚的なコンテキストを抽出しますが、書かれている内容だけでなく、写っているものの理解に焦点を当てています。

• 指示は明確にしましょう。「この画像を分析して」のような一般的なプロンプトではなく、望むことを指定してください。例えば「見えるすべての製品とその色を特定してください」や「この写真に署名と社印が含まれているか検出してください」のように指定します。
• ドキュメントとビジュアルが混在する自動化 (例: 写真付きレポート、点検ログ、デザインレビュー) を構築する場合は、ワークフローの早い段階で Recognize Image を使って見えるもの (オブジェクト、ラベル、状態) を構造化し、その構造化された結果を Store into a Dataset や Create Report などのノードに渡しましょう。

​

Send Email

件名と本文を付けて特定のアドレスにメールを送信します。

• ワークフロー内で直接メール送信を設定できます。件名と本文を入力し、1 人または複数の宛先に送信できます。CC 宛先も指定可能です。

強力な組み合わせ:

• スケジュール実行 と組み合わせて、特定の日と正確な時刻 (定期または 1 回限り) にメールを自動送信
• Download Document と組み合わせて、送信したメールのレポートをダウンロード

​

Request Email Reply

最初のメールを送信し、ワークフローを継続させるためにそのメールへの返信を受け取ります。

• Request Email Reply ノードは、ワークフローを継続するために返信を得る目的で、メール受信者にメールを送信する際に使用します。
• 返信を受け取るまで時間がかかる場合があるため、画面右側の実行履歴からワークフローを確認してください。

​

Fill In Form

Run モード中にユーザーが入力するカスタムフォームを作成します。

• Fill In Form ノードは、ユーザーにフォームに従って情報を入力させる動的なフォームビルダーです。
• まずは、フォームの目的を特定しましょう。どんなデータを収集する必要があり、質問の論理的な順序はどうあるべきか?
• 適切な入力フィールドを使いましょう。データの種類とフィールドタイプを合わせることが、良いユーザー体験につながります。
• ラベルとプレースホルダーテキストでユーザーを誘導します。「メールアドレスを入力してください」のような明確なラベルは、汎用的な「Input」よりはるかに良いです。
• 重要なフィールドは Required (必須) としてマークしましょう。これにより、データ不足によるワークフローの失敗を防げます。
• 本当に必要な情報のみを尋ねましょう。長く複雑なフォームはユーザーの疲労を招き、離脱率の上昇につながります。

​

利用可能なフォームフィールド

​

Get Approval

Shieldbase ユーザーであるチームメンバーに承認を依頼します。

• Get Approval ノードは、ワークフローの出力に対する承認を得るために使う意思決定ノードです。
• 結果は「承認」と「未承認」の 2 通りのみです。そのため、Get Approval ノードは 2 つの異なるパスへ分岐する判断ノードです。
• 承認者からの承認には時間がかかる場合があるため、画面右側の Execution History からワークフローを確認してください。

​

Create a Report

データをインサイトに分析し、可視化を生成します。

• Create a Report ノードは、データ分析と可視化をワークフローに直接統合します。生データを構造化されたビジュアルレポートに変換でき、複雑な情報を理解し、インサイトを効果的に共有するのに役立ちます。
• 開始前に、Create a Report ノードに渡すデータがクリーンで適切に整理されていることを確認します。一貫した明確な形式を使用し、データ列には説明的な名前 (例: Revenue_2024、Region、Customer_ID) を付けます。
• 指示の中で目的を明示してください。例えば、単に「レポートを作成して」ではなく、「月次売上トレンドを分析し、上位パフォーマンスの地域を示す売上パフォーマンスレポートを作成してください。レポートには売上推移の折れ線グラフと地域別売上の棒グラフを含めてください」のように指定します。
• Create a Report ノードを Input Text ノード、Fill In Form ノード、または Contextualize From Library ノードと組み合わせ、その情報をコンテキストとしてデータ分析や可視化を生成します。

​

Store Into a Dataset

テキストを抽出してデータセットに格納します。

• Store Into a Dataset ノードを使用する前に、ワークフロー内の前のステップが構造化されたデータを生成していることを確認してください。
• データセットを作成する際は、データの目的を反映するカスタムカラム名 (例: 「Customer_ID」「Transaction_Amount」) を必ず定義してください。これにより、スプレッドシート、データベース、レポートソフトウェアとの統合における可読性と互換性が向上します。
• ワークフローが動的な入力 (例: レコード数の変動) を扱う場合は、前のステップで条件分岐を使ってデータをバッチ化またはフィルタリングしてください。これにより、データセットに不要なエントリが溢れるのを防ぎ、パフォーマンスを最適に保てます。
• エンタープライズ環境ではデータセットのサイズに注意してください。大規模なデータセットはワークフロー速度に影響を与える可能性があります。プラットフォームが対応している場合は、しきい値の設定や圧縮を活用しましょう。

​

Start a Workflow

ステップの一部として別のワークフローを起動します。

• 起動したワークフローが完了するまで、最初のワークフローの実行を継続させたい場合は、待機チェックリストを切り替えます。
• Start a Workflow ノードは、メインのワークフローが継続する一方で、バックグラウンドで自律的に実行されるリアクティブで疎結合なワークフローを構築するのに最適です。

​

Refer to a Parent Workflow

このワークフローを起動した親ワークフローの特定のステップから、データやファイルを使用します。複数の親から情報を集約するのに便利です。

• このフィーチャを設定する際に正しい「Parent Step」を選びやすくするため、親ワークフロー側の主要なステップに明確な名前とラベルを付けましょう。
• 複数の親ワークフローが同じ子をトリガーする場合は、マッピングエラーを避けるため、出力スキーマ (フィールド名や型) を統一しましょう。
• 並列で動作する親ブランチ (例: 複数の承認) の結果を、単一の統合サマリーステップに集約するために、この機能を活用しましょう。
• 親出力を参照する前に、その存在を必ず検証してください (例: 不足/空データに対するガード条件や分岐を追加)。
• 子ワークフロー側で親ワークフロー ID と起動元ステップをログに残し、デバッグや監査の追跡を容易にしましょう。

​

Loop Action

リストを反復処理し、各項目に対して同じアクションを実行します (例: リスト内のすべてのアドレスにメールを送信)。

• ループは焦点を絞りましょう。本当に繰り返す必要があるアクションのみをループ内に配置し、無駄な処理時間を避けます。
• 大きなリストの場合は、ダウンストリームシステムでのタイムアウトやレートリミットを防ぐために、項目数の上限やバッチサイズなどのセーフガードを追加してください。
• ループ内で Pull Data From API を使って外部 API を呼び出す場合、レートリミットやクォータエラーが見られたらスロットリングや短いディレイを実装してください。

​

Pause Until

指定した条件が満たされるまで、ワークフローの実行を一時停止します。

• ステータス、タイムスタンプ、フラグなど機械が検知できる正確な条件を使用し、曖昧なテキスト値は避けてください。ワークフローが無期限に停止することを防げます。
• 条件が満たされない場合に備え、最大待機時間とフェイルオーバーパス (例: エスカレーション、通知、自動クローズ) を設定してください。
• 長い固定ディレイよりも、イベントベースのトリガー (Webhook、ステータス更新) を優先し、レイテンシとリソース使用を抑えましょう。
• 一時停止の開始時と終了時に明確なログメッセージを出力し、実行が待機している場所と理由をオペレーターが把握できるようにしましょう。
• ユーザー入力待ちの場合、必要なアクションへの直接リンクを含むプロアクティブな通知 (メール、チャット、アプリ内) を送信してください。

​

Pull Data from API

コンテキストとして利用するため、サードパーティアプリから特定のフィールドを取得します。

• サードパーティアプリから API でデータを取得するための初期権限は、Integrations で設定する必要があります。
• まずは本当に必要なフィールドのみを取得することから始めましょう。不要なフィールドを過剰に取得すると、ワークフローが遅くなり API コストも増加します。
• データ取得直後に API レスポンスを正規化・検証 (型チェック、null チェックなど) し、ダウンストリームでの障害を防ぎましょう。
• デバッグ目的で raw レスポンス (または機密情報を除いたもの) をログに残しますが、機密フィールド (トークンや個人情報) はマスキングするか、ログから除外してください。

​

Push Data to API

サードパーティアプリにデータを書き込みます。

• サードパーティアプリにデータを書き込むための初期権限は、Integrations で設定する必要があります。
• フィールドのマッピングを明示的に行い、ドキュメント化しましょう。特に、複数の API や同一サービスの異なるバージョンと統合する場合は重要です。
• ターゲット側のスキーマや形式の不一致による致命的な失敗を防ぐため、データを送信する前に検証・サニタイズしてください。
• 追跡や将来の更新・削除のために、API からのレスポンス ID や確認トークンを取得・保存しましょう。

​

Templatize

フォーマットを維持しつつ、ダウンロード可能なテンプレートに内容を埋め込みます。

• テンプレートに最も正確にコンテンツをマッピングするには、スプレッドシートや構造化されたテキストドキュメントをテンプレートとして使用してください。
• 最適な精度のためには、空欄でかつ表形式のテンプレートを使用してください。この構造により、システムが各データフィールドを正しくマッピングし、データエラーを防ぎます。
• 明確なプレースホルダーマーカー (例: {{field_name}}) を使ってテンプレートを設計し、テンプレート作成者・ビルダー向けにマッピングドキュメントを整備しましょう。
• フォーマットロジック (フォント、間隔、レイアウト) はテンプレートファイル内に保持し、動的コンテンツはできるだけテキストと画像に限定しましょう。
• 非常に長い文字列、特殊文字、空のフィールドなどエッジケースの値でテンプレートの埋め込みをテストし、実運用でのレイアウト崩れを防ぎましょう。
• 任意フィールドには条件付きセクションやフォールバックテキストを用意し、データが一部欠けていても見栄えの良いテンプレートを保ちましょう。
• テンプレートをバージョン管理し、どのワークフローのバージョンがどのテンプレートを使っているかを追跡し、本番フローでの予期しないフォーマット変更を防ぎましょう。

​

Translate Document

フォーマットとスタイルを維持しつつ、ドキュメントを他言語に翻訳します。

• 法律、医療、技術などのドメイン特化コンテンツでは、対応している場合に用語集や用語リストを提供し、翻訳の一貫性を高めましょう。
• 翻訳は主にコンテンツ理解のために使用し、法律文書や外部向け資料で利用する前に、追加の人手または専門家によるレビューを行ってください。
• 元の版と翻訳版の両方を保存し、メタデータ (言語、翻訳日時、ワークフロー ID) を含めて将来の参照や監査に備えましょう。

​

Merge to PDF

複数のファイル (PDF, JPEG, JPG, PNG, XLSX, XLS, CSV) を 1 つの統合されたドキュメントに結合します。

• ワークフローが複数のドキュメント (レポート、フォーム、添付ファイルなど) を生成または収集し、関係者と共有できる単一ファイルに統合する必要があるときに Merge to PDF を使用してください。
• 一貫した順序 (例: 表紙、サマリー、詳細分析、付録) で結合し、出力を標準化しましょう。週次レポートやクライアント向け納品物のような繰り返しワークフローで、最終 PDF が読みやすく参照しやすくなります。
• スキャンされたドキュメントや画像を扱う場合は、Process OCR と組み合わせて使用してください。まず画像を機械可読なテキストに変換し、次に検索可能な単一の PDF に結合することで、利便性と保管性が向上します。
• 承認や署名を含むプロセスでは、Merge to PDF を使って関連する全資料 (依頼、裏付け資料、判断ログ) を 1 つのファイルにまとめましょう。後で保存・送付・参照できる、整理された監査証跡が作成できます。
• ファイルサイズに注意してください。多くの大きなドキュメント (特に画像や高解像度レポート) を結合する場合は、最終 PDF を扱いやすく保つため、入力を事前に圧縮するか、不要なページを省くことを検討しましょう。

​

Handle Conversation

ユーザーのクエリに応じて、適切な会話フローへルーティングします。

• 明確なルーティング基準 (インテント、キーワード、エンティティ) を定義し、フローのあいまいさを避けるため、可能な限り相互排他的に保ちましょう。
• どの会話パスにもマッチしないクエリを丁寧に処理する、フォールバックや「不明」用のルートを用意しましょう。
• 実際のユーザークエリと会話ログを継続的にレビューし、ルーティングルールを改善し、新しいインテントを追加していきましょう。
• ダウンストリームフローに引き渡す際、コンテキスト (ユーザー属性、過去のメッセージ、チャネル) を渡し、基本的な質問を再度しなくて済むようにしましょう。
• 課金変更、プライバシー、セキュリティといった高リスクなトピックには、専門のフローや人間のエージェントにルーティングするガードレールを実装してください。

​

スケジュール実行ノード

スケジュールに基づいてワークフローを実行します。

• スケジュール実行ノードは、特定の日時にワークフローを自動的に実行できます。手動操作なしでルーチンタスクを自動化するのに最適です。
• 日次、週次、月次のタスクをスケジューリングするのに使えます。例えば、毎週金曜日 9 時に週次売上レポートを生成するワークフローや、日次のメールリマインダーを送信するワークフローを設定できます。
• 将来の特定日時に 1 回だけワークフローを実行することもできます。タイマーリマインダーの送信や、特定日のキャンペーン開始などに便利です。
• スケジュール実行ノードは、ワークフロー全体のトリガーとして機能します。指定された時刻になると、ワークフローが自動的に開始され、データの取り込み、処理、出力の生成まで完了まで実行されます。

​

ワークフローの構築方法

​

直線的なワークフローの構築

直線的なワークフローは、出力を生成するために一直線のシーケンスで実行されます。各ステップが順番に完了するシンプルで分かりやすい流れで、ループや分岐、条件分岐はありません。各ステップの出力が次のステップの入力となり、予測可能なイベントの連鎖を生み出します。

​

分岐ワークフローの構築

分岐ワークフローでは、複数の選択肢から条件に応じてワークフローを特定のパスに導けます。単なる「Yes/No」プロセスにとどまらず、複数のオプションを提示し、異なる基準を評価し、適切な次のステップを実行します。 中核として、分岐ワークフローは判断ノードを使って条件を評価します。例えば、「請求書金額が 1,000 ドル以上か?」とワークフローが尋ねる場合:

• Yes の場合: 請求書を承認のためにマネージャーへ自動転送するように構成可能
• No の場合: 請求書を直接経理部門に送って支払い処理するように構成可能

​

トリガーをスケジュールしてワークフローを実行

ワークフローを特定日時に自動実行するには、トリガーをスケジューリングします。週次レポートの生成や日次サマリーの送信など、手動操作なしで定期タスクを設定できます。

​

ワークフローの編集

公開済みのワークフローは、新しいバージョンに編集できます。

​

ワークフローテンプレート

ワークフローテンプレートは、共通の自動化タスクをすばやく始められるように事前に構築されたワークフローです。確かな土台とベストプラクティスを提供し、ゼロからワークフローを構築する手間と時間を省きます。

​

Prompt-to-Workflow

ワークフローの構築は Prompt-to-Workflow から開始できます。具体的な要件を含むプロンプトを入力するだけで、Shieldbase AI が自動シーケンスを起草し、手動構成の必要性を減らします。

​

ワークフローのエクスポートとインポート

ワークフローはエクスポートもインポートも可能で、環境、チーム、プロジェクトをまたいで自動化を再利用・バックアップ・共有・移行するのが簡単になります。

​

ワークフローのエクスポート

環境やチームをまたいでワークフロー構成を再利用・バックアップ・共有したい場合は Export を使用します。エクスポートする前に、ワークフローとその主要ステップに明確な名前と説明を付けておくと、インポート後に他の人が理解しやすくなります。

​

ワークフローのインポート

別の環境、チーム、プロジェクトから、事前構築済みのワークフロー (JSON ファイル) を取り込みたい場合は Import を使用します。

​

プロのヒント

​

ベストプラクティス

​

よくあるユースケース

​

データ処理パイプライン

構成例

1. Upload Files: CSV ファイルを受信
2. Process OCR: 画像からテキストを抽出
3. Instruct: データをクリーニング・整形
4. Store Into a Dataset: データベースを更新
5. Create a Report: 分析ダッシュボードを生成
6. Send Email: 関係者にレポートを送付

​

承認ワークフロー

構成例

1. Fill In Form: 従業員がリクエストを提出
2. Decision Node: リクエスト種別/金額に基づきルーティング
3. Get Approval: マネージャーがレビュー
4. Decision Node: 承認/却下のパス
5. Download Document: 判断結果の通知書を生成
6. Send Email: 結果を従業員に通知
7. Store Into a Dataset: リクエストをシステムに記録

​

スケジュールレポート

構成例

1. Scheduled Execution: 毎週 9 時
2. Contextualize From Library: 最新データを取得
3. Instruct: トレンドとパターンを分析
4. Create a Report: 週次メトリクスを生成
5. Download Document: PDF レポートを作成
6. Send Email: チームに配信

​

自動化のタイミング

​

自動化に向いた候補

​

トラブルシューティング

ワークフローが実行されない

• すべての必須フィールドが入力されているか確認
• データソースの接続を確認
• Run モードでエラーログをレビュー
• 各ステップを個別にテスト
• データフォーマットが適切か確認

スケジュールされたワークフローが動かない

• スケジュール設定を確認
• タイムゾーン設定を確認
• ワークフローが公開済み (ドラフトでない) ことを確認
• システム権限をレビュー
• 競合するスケジュールがないか確認

パフォーマンス問題

• 複雑なワークフローを小さく分割
• Contextualize From Library でのデータクエリを最適化
• 不要なステップを削減
• 大きなファイルを 1 ステップで処理することを避ける
• 最適化サポートが必要な場合は support@shieldbase.ai までご連絡

フォームや承認が機能しない

• ユーザー権限を確認
• すべての必須フィールドが構成されているか確認
• 異なるユーザーロールでテスト
• メール通知が構成されているか確認