文書 ワークフロー 自動化

執筆：Ai Flowi · 公開日 2026-10-11。

文書 ワークフロー 自動化では、提供された文書を受付、検証、レビュー、管理された出力処理へと進めます。抽出や文書書き込みのコンポーネントを接続する前に、各状態、責任を持つレビュー担当者、状態遷移に必要な証拠を定義してください。この設計は、標準の承認サービスを前提とせず、提供されたキューと明示的な遷移記録を使います。

設定例であり、記録されたテストではありません。この文書ライフサイクル案はカタログに記載されていますが、Ai Flowiが本番検証したものではありません。

1. 受付記録と再実行キーを定義する

安定した記録識別子、文書の識別子、文書のバージョン、依頼された作業、割り当てたレビュー担当者を持つ文書キューを用意します。受付は受け入れとは別に記録します。ファイルを読めても、必須フィールドが含まれていることや、誰かが結果を承認したことは証明できません。

行を書き込む前に、再実行キーの業務上の意味を決めます。キーが1つの文書バージョンと1つの処理依頼を表すなら、バージョンの変更には新しいキーが必要です。同じ依頼の再試行では同じキーを保持します。これらの識別子は受付処理から提供し、モデルに文書のテキストから作らせないでください。

AI Flowi Workflow、文書を読む権限、設定済みのモデル接続、状態遷移を管理するレビュー担当者が必要です。必要に応じて自分のプロバイダーアカウントやAPIキーを使い、料金は別途支払います。Sheetsでの状態追跡とGoogle Docsへの出力には、自分のGoogleアカウント、認可済みの接続、対象のスプレッドシートと作業文書へのアクセスが必要です。

関連情報：人事ワークフロー：段階・担当者・安全な AI 支援。

2. 業務上の管理として状態を定める

これらのラベルは台帳の設計案であり、製品が提供する承認状態ではありません。誰が変更でき、どこに判断を記録するかを定義します。最初の最小構成は、レビュー担当者が管理し、手動で状態を変えるキューでも構いません。抽出した状態フィールドを、最終文書を書き込む権限として扱わないでください。

3. 読み取りと抽出を、受け入れと混同しない

受付時の読み込みにはRead Fileの選択ガイドを使い、得られたテキストを、キュー内の特定の文書バージョンの記録に結び付けます。

修正したアップロードでは、前のバージョンの受け入れを引き継がず、受付の確認に戻します。以前の判断は、実際に確認したバージョンに結び付けて保持します。抽出中にレビュー担当者を変更した場合は、その変更を記録し、保留中の下書きを新しい担当者に渡します。以前の割り当てを、レビューが行われた証拠として扱ってはいけません。

Structured Outputでは、system_promptに、依頼の業務フィールドと文書内の位置を抽出し、ワークフローの状態をモデルの権限外に置くよう指示します。文書に「承認済み」という言葉があっても、現在の依頼がレビューされたことを証明しません。その表現は文書の証拠として保持し、提供された遷移記録に基づいて依頼の状態を定めます。

抽出はStructured Outputのインターフェースで実装し、必須フィールドの証拠は、モデルが提案する完全性の状態とは独立して評価します。

関連情報：PDF 表 抽出：再利用の前に見出し・セル・原文の根拠を保持する。

4. 必須フィールドとレビュー担当者による判定を適用する

抽出したフィールドを、依頼の必須フィールド一覧と比較します。識別子、文書バージョン、各値の証拠を確認します。欠けたフィールドや競合するフィールドは、レビュー担当者が対処できる理由を付けて「修正が必要」にします。入力済みの値でも、元の文書に見つからなければ判定を通過できません。

受け入れを、依頼キー、確認した文書バージョン、受け入れた正確な内容に結び付けます。いずれかが変わればレビューに戻し、以前の判断を履歴として保持します。却下には、根拠のない値や添付の欠損など、受付担当者が意味のある改訂を提供できる修正理由が必要です。「修正が必要」と「却下」は区別してください。前者は証拠を待つ状態で、後者はレビューした依頼への判断を記録します。

5. キー付きの状態記録を意図的に更新する

キーによる書き込みはUpsert Rowのリファレンスで説明されています。この台帳では、key_columnを安定した依頼キーとし、value_input_optionに"RAW"を使います。

現在の状態、文書バージョン、最新のレビュー判断、利用可能なら出力先の参照を含むrow_dataを用意します。現在の状態のテキストを置き換える前に、別の遷移記録を保持します。同じ依頼キーの行がシートに2つある場合は、どちらかを更新する前にその曖昧さを解消してください。1行への書き込みが成功しても、もう1行が担当者のレビューから消えるわけではありません。

テスト済みのSheetsチュートリアルでの重複保護は、順次届くデータに限定されています。この文書キューの同時書き込み保護を証明するものではありません。また、Upsertが更新するのは最初に一致した行だけなので、状態変更を信頼する前に、既存の重複キーを確認してください。キー付きの現在状態の行は、変更不能な遷移履歴ではありません。

関連情報：RFP回答の自動化：根拠に基づく回答マトリクスを準備する。

6. 受け入れた内容を書き込み、出力先を確認する

受け入れた内容にはTemplate Mergeの文書化済みの引き渡し手順を使い、実際の出力先を確認した後にだけ、出力確認済みの状態を記録します。

別の検証済みフォームのレシピの42/42チェックには、文書化されたCR+LF変換とCreate Documentが含まれます。一方、このライフサイクルの状態遷移とTemplate Mergeへの引き渡しには、独自の検証が引き続き必要です。

7. 中断した状態遷移のテストと範囲の限定をどう行いますか？

元の文書がない場合、根拠のない抽出値、却下した下書き、繰り返された依頼、状態を書き込んだ後の出力先の失敗を確認します。キューには作業が止まった場所を保持する必要があります。結果が不確かな操作を再試行する前に両方の出力先を確認し、台帳の行が変わっただけで依頼を完了扱いにしてはいけません。

中断の例をたどります。レビューで受け入れられ、状態の行が保存された後、文書操作の接続が切れたとします。依頼は受け入れ済みのままにし、出力は未解決とします。文書操作を繰り返す前に、想定した内容が出力先にあるか確認します。完全な内容があれば参照を記録し、引き渡しを完了します。存在しないか不完全なら、失敗を記録し、その操作だけを再開します。この時点で元の文書を再抽出すると、表現が変わり、以前の受け入れが無効になる可能性があります。

次に中断の順序を逆にします。文書は正しいのに、完了状態の書き込みが失敗した場合です。確認済みの出力先の参照を遷移記録に保持し、現在の行を確認してから台帳の更新を再試行します。推測した「完了」ラベルを使わずに、担当者がこの2つのケースを区別できて初めて、ライフサイクルの復旧チェックに合格します。

この設計には、受信箱からの受付、無人での承認、自動削除、SheetsとDocsをまたぐ不可分のトランザクションはありません。承認が得られない場合や、記録から文書バージョンを特定できない場合は停止します。バージョンの競合には文書ソースの監査を、文書の内容を書く作業には手順書の下書きを参照してください。

プラン：Goは年払いで月額USD8から（月払いUSD10）、Plusは月額USD16から（月払いUSD20）、Pro 100は月額USD80から（月払いUSD100）、Pro 200は月額USD160から（月払いUSD200）、Pro 500は月額USD400から（月払いUSD500）。毎月5,000～250,000 Flowi Tokensが含まれ、追加購入も可能です。ノード実行1回につき1トークン。サードパーティのAPIとモデルの利用料金は含まれません。

追加の状態遷移を実装する前に、カタログの取り決めと記録されたユースケースを確認します。レビュー台帳が役立つのは、その判断が実際に確認した作業に対応している場合だけです。