メインコンテンツへスキップ
AIワークフロー設計更新

fail-closedなAIワークフロー設計

出典が取れないのに文章を公開する。検証結果が返っていないのに、合格したものとして実行する。明確なエラーがなくても、業務に必要な確認が抜けたまま処理が進むことがあります。

fail-closedは、異常や不明を検知したら安全側で止める設計です。何が不足したら止めるか、どの確認が済めば再開できるかを、工程ごとに決めます。

01

「失敗したら止める」だけでは足りない

例外が出なくても、検索結果が0件、レビュー応答が空、価格の取得時点が古い状態は業務上の失敗です。正常データとして次工程へ渡すと、後段のAIが不足を推測で埋めます。

各工程は完了、再試行可能、人の確認待ち、情報不足、恒久失敗を区別します。必要条件を満たした完了状態だけを次へ渡します。

技術的な不明
タイムアウト、接続切れ、応答形式の不一致。未実行とは限りません。
業務上の不明
根拠不足、対象外、承認者不在、ルール競合。人の判断へ戻します。

02

状態と遷移条件を定義する

工程ごとに受け付ける入力、成功条件、停止理由、次に進める状態を定義します。状態遷移はAIの自由文ではなく決定的なルールで判定します。

工程ごとに定義する項目

  • 必須入力と有効期限
  • 成功を示す機械判定可能な条件
  • 情報不足・矛盾・対象外の状態
  • 自動再試行できる条件と上限
  • 人へ渡す判断材料
  • 次工程が受け付ける状態

03

再試行の前に実行済みか確認する

外部APIがタイムアウトしても、相手側では処理が完了している場合があります。送信、公開、決済をそのまま再試行すると重複します。

実行単位に一意なキーを付け、完了状態を照合します。止まった画面には、どの工程で何が不足し、誰が何をすれば再開できるかを表示します。

本番前の受け入れチェック

  • 必須データが空または古いと次へ進まない
  • 検証サービスが応答しない場合に合格扱いしない
  • 同じイベントが複数回来ても外部作用は一度だけ
  • 再起動後も停止状態と試行回数が保持される
  • 期限切れ・対象違いの承認を拒否する
  • 停止理由と復旧操作をログから追える
AIガバナンス

AI業務に人間承認ゲートが必要な理由

操作ごとに人が承認するか、条件を先に承認して自動処理するか。承認する人、対象の版、有効期限、実行前の確認を決め、許可のない操作を止める設計を紹介します。

読む →
AI品質管理

出典に基づくAI下書きの作り方

下書きを書く前に出典を集め、使える事実と未確認事項を分けておく。文章中の主張から出典へ戻れる記録の作り方と、公開前に確かめる項目をまとめています。

読む →

CONTACT YOLX

自社の業務でAIを使うには

対象の業務と使えるデータを確認し、AIに任せる処理、人が判断する場面、停止後の対応を決めます。設計から実装、検証までご相談ください。