連携ノード
このページでは、外部システムと連携するワークフローノード — OCR Task ノード、API ノード、GitHub 系ノード、Forge Function ノード — の設定について説明します。利用可能なノードの一覧については、ワークフローノードを参照してください。
OCR Task ノード
OCR Task ノード は、ドキュメントのページに対して光学式文字認識（OCR）を実行し、テキストの画像を機械可読なテキストに変換します。
OCR Task ノード の設定
| 設定 | 説明 |
|---|---|
| OCR engine | 使用する OCR エンジンです。現在は Google Cloud Vision の1つのみが提供されています。 |
| Pages that already have text | すでに機械可読なテキストを含むページをこのノードがどう扱うかです: Skip pages with existing text、Remove all text and OCR every page、OCR only the parts of the page without text のいずれかを選択します。 |
| Show image processing options | 以下で説明する、追加の画像前処理コントロール一式を展開表示します。 |
画像処理オプション
| 設定 | 説明 |
|---|---|
| Ensure orientation - billed additionally | 低コストのモデルを用いて4方向すべてを OCR し、向きを判定します。デフォルトでは無効で、有効にすると OCR の課金が追加されます。 |
| Auto-rotate pages | OCR の前にページを正しい向きに回転させます。デフォルトで有効です。 |
| Deskew | OCR の前に傾いたページをまっすぐに補正します。Pages that already have text が OCR only the parts of the page without text に設定されている場合は使用できません — deskew を使用するには別のオプションを選択してください。 |
| Clean before OCR | OCR の前に、ページの余白（空白部分）をクリーンアップしようと試みます。 |
| Output optimisation | 出力ファイルサイズと品質のトレードオフです: None、Lossless、Lossy images、Maximum（デフォルト）のいずれかを選択します。 |
API ノード — Auto Retry
API ノード には Auto Retry セクションがあります。有効にすると、失敗したリクエストは即座に失敗として処理されるのではなく自動的に再試行され、再試行のタイミングはランダム化された減衰型の遅延によって時間的に分散されます。再試行が尽きると、設定済みの Failure Routes に処理が引き継がれます。
API ノード — Auto Retry の設定
| 設定 | 説明 |
|---|---|
| Enable auto retry | このノードの自動リトライ動作を有効にします。 |
| Retry on | どの失敗タイプで再試行をトリガーするか: Timeout、HTTP error status、Null / empty response、Other errors。 |
| Max retries | 最大の再試行回数です。 |
| First retry delay | 最初の再試行までの待機時間です。再試行は5分単位のスケジュールで確認されるため、遅延は5分刻みで選択され、最初の再試行は選択した遅延が経過した後の次回チェック時に行われます。 |
| Delay decay factor | 連続する再試行の間の遅延に適用される乗数です。 |
| Max delay | 再試行間の遅延の上限です。 |
| Jitter (0–1) | 遅延をどの程度ランダム化するかです。1 にすると、同時に失敗した項目が同じタイミングで一斉に再試行されないよう、再試行がウィンドウ全体に完全に分散されます。0 にすると固定の遅延が使われます。 |
API ノード — Concurrency & burst control
API ノード には Concurrency & burst control セクションもあり、速度が遅い、またはレート制限のあるエンドポイントに対してこのノードが送信するリクエスト数を制限します。上限に達すると、実行は失敗する代わりにキューに入れられ、自動的に再試行されます。
API ノード — Concurrency & burst control の設定
| 設定 | 説明 |
|---|---|
| Limit concurrent requests | このノードの同時実行数・バースト制限を有効にします。デフォルトでは無効です。 |
| Group requests by | 以下の上限を適用する際に何を「同じエンドポイント」とみなすかです。デフォルトは URL (host and path) で、各エンドポイントに個別の上限が割り当てられます。他のオプションとして、ホスト全体で1つの上限を共有する（Server）、または宛先を問わずノード全体で共有する（This node）もあります。 |
| Requests at the same time | 同時に実行できるリクエストの数です。それ以上のリクエストは、いずれかの応答が返るまで待機します。 |
| Requests per time window | 重複の有無を問わず、各ウィンドウ内で許可されるリクエストの総数です。0 のままにすると、この時間ベースの上限は無効になり、同時実行数の上限のみが適用されます。 |
| Wait for a free slot (seconds) | 待機中のリクエストが、キューに入れられて次のスイープに回される前にスロットの空きを待つ時間です。混雑のほとんどは数秒で解消するため、短い待機時間でもリクエストがすぐに送信されることが多いです。すぐにキューへ入れたい場合は 0 に設定します。 |
これらのフィールドの上には、設定した上限を平易な文章で言い換えたライブサマリーが表示されます（例: 「各 URL (host and path) に対して同時に最大2件のリクエスト。待機中のリクエストは最大30秒待ち、その後次のスイープでキューに入ります。」）。キューに入った実行は、およそ5分ごとの次のスイープで再試行され、失敗としてではなく Inbox 上で Queued として表示されます。解消されないキューは、ノードの Failure Routes 設定にある Queue limit reached オプションでルーティングできます。
GitHub Commit ノード
GitHub Commit ノード は、1つ以上のドキュメントを接続済みの GitHub リポジトリにコミットします。コネクタの contents_write 機能が有効になっている必要があり（.github/workflows 配下にコミットする場合は workflow_files も必要）、そうでない場合は実行が拒否されます。
GitHub Commit ノード — リポジトリとブランチの設定
| 設定 | 説明 |
|---|---|
| Repository | コミット先となる、接続済みの GitHub リポジトリです。 |
| Branch | コミット先のブランチです。ソースドキュメントに対する Jinja テンプレートに対応しています。 |
| Base branch（任意） | ブランチがまだ存在しない場合に、そこからフォークする元のブランチです。空欄の場合はリポジトリのデフォルトブランチが使用されます。 |
| Create branch if missing | ブランチが存在しない場合に作成します。無効で、かつブランチが見つからない場合、ノードは失敗します。 |
| Delete branch on completion | 後続の GitHub Action の実行が完了した時点でブランチを削除します。使い捨てのブランチを片付ける際に便利です。このノードの後に poll モードまたは webhook モードの GitHub Action ノード が必要です。 |
| What to commit | このノードがコミットするドキュメントを選択します（詳細は下記）。 |
| Repository path（任意） | ファイルを配置するリポジトリ内のサブフォルダーです。空欄の場合、各ドキュメントの元のファイル名でリポジトリのルートにコミットされます。 |
| Commit message（任意） | デフォルトのコミットメッセージを上書きします。Jinja テンプレートに対応しています。 |
What to commit には3つのオプションがあります。
What to commit — 選択オプション
| オプション | 説明 |
|---|---|
| Workflow document | このワークフローの開始元となったアイテムです。 |
| Node input | 前のノードで生成されたドキュメントです。 |
| Specific document IDs | コミットするドキュメント ID をカンマ区切りで指定したリストです。 |
GitHub Action ノード — Run Tracking
GitHub Action ノード は GitHub Actions のワークフロー実行をディスパッチし、選択した Run Tracking Mode に応じて、処理を進める前にその実行が完了するのを待つことができます。コネクタの actions 機能が有効になっている必要があり、そうでない場合は実行が拒否されます。
| 設定 | 説明 |
|---|---|
| Repository | 接続済みの GitHub リポジトリです。 |
| Workflow File | 選択した ref 上の、.github/workflows 内にあるワークフローファイル名です。workflow_dispatch トリガーと docwize_run_id の入力を宣言し、run-name を通じてそれをエコーする必要があります。これにより Docwize がその実行を識別できるようになります。 |
| Ref（ブランチまたはタグ） | ディスパッチ先となるブランチまたはタグです。Jinja テンプレートに対応しています。 |
| Workflow Inputs | 実行に渡す、追加の workflow_dispatch 入力です。値は Jinja テンプレートに対応しており、ディスパッチ時に展開されます。docwize_run_id の関連付けトークンは自動的に追加されます。 |
| Run Tracking Mode | Fire and forget（ディスパッチ後、即座に処理を継続）、Poll for completion（一時停止し、実行が完了するまで Actions API をポーリング）、Await webhook（一時停止し、GitHub が workflow_run の完了 webhook を配信した時点で再開。取り逃した配信はウォッチドッグによるポーリングで回収されます）。 |
対象のワークフローファイルが実行の関連付けに対応していない可能性がある場合、ダイアログに事前警告が表示されます。
事前警告: このワークフローでは実行トラッキングが機能しない可能性があります
実行をポーリングまたは待機するには、ワークフローファイルで workflow_dispatch トリガーと docwize_run_id 入力を宣言し、それをトップレベルの run-name にエコーする必要があります（例: run-name: "${{ inputs.docwize_run_id }}"）。run-name へのエコーがない場合、Docwize は実行を関連付けられず、ノードはタイムアウトするまで停止したままになります。Fire and forget モードはこの影響を受けません。
このノードは3つのアウトプットのいずれかにルーティングされます: On success（実行が成功して完了）、On failure（実行は完了したが失敗した）、On infrastructure error（GitHub Actions の実行自体の失敗とは異なり、コネクタや API の問題などにより、Docwize が実行をディスパッチまたはトラッキングできなかった）。
Forge Function ノード
Forge Function ノードは、対応するアップロード済みのファンクションをワークフローのドキュメントとそのファイルに対して実行します。アウトプット側は固定のポート数ではなく、そのファンクションのマニフェストで宣言されたアウトプットルートごとに1つのポートを持ちます。たとえば、あるファンクションが Appended、No PDF、Error のルートを公開し、それぞれが異なる次のステップに接続される場合があります。
関連する設定
- ワークフローノード — 利用可能なすべてのキャンバスノードの完全なリファレンス
- 高度なノード設定 — 条件ロジック、Run Oliver、distribution set ノード
- Docwize Forge — Forge Function ノードとして表示されるカスタムファンクションのアップロード
- GitHub コネクタ — GitHub 系ノードが使用するリポジトリの接続
- ワークフローテンプレートの構築 — ノードをテンプレートに組み立てるキャンバス