AIワークフローはデモは簡単だが、完成させるのは難しい。ハッピーパスは説得力があるように見えても、リトライが副作用を重複させたり、承認がスキップされたり、証拠なしに完了が報告されたりする。

このチュートリアルでは、ワークフローのアイデアを小さな契約と6つの受け入れテストに変換する。例は意図的にモデル非依存であり、OCRレビュー フロー、サポートチケット エージェント、API自動化、またはリサーチ アシスタントに適用できる。

観測可能な契約から始める

ツールを選ぶ前に、5つのフィールドを記述する:

  1. ワークフロー名 — 部門全体ではなく、1つの境界付けられたプロセス。
  2. 望ましい結果 — 実行が成功したときに観測可能でなければならない状態。
  3. 人間による承認ポイント — 人が制御する正確な不可逆的または外部アクション。
  4. 副作用 — ワークフローが作成できるレコード、メッセージ、支払い、またはシステム変更。
  5. 証拠参照 — 何が起こったかを証明するアーティファクト。

有用な完了ルールは次のとおり:

complete = outcome observed
        AND evidence reference exists
        AND required approval is granted
        AND duplicate side effects = 0

Enter fullscreen mode Exit fullscreen mode

これは「モデルが回答を返した」よりも厳格であり、周囲の自動化をテスト可能にする。

テスト1: ハッピーパス

代表的な入力を提供し、意図した結果、証拠参照、承認状態、副作用数をアサートする。自然言語による品質主張だけでは不十分で、結果には機械可読の証拠が必要である。

テスト2: 不正な入力

必須フィールドを削除するか、無効な型を提供する。ワークフローはモデルを呼び出したり副作用を作成したりする前に、入力を拒否する必要がある。失敗はオペレーターに可視でなければならない。

テスト3: 重複イベント

同じイベントを2回配信する。2回目の配信は既存の結果を返するか、安全なno-opを実行する必要がある。2つの通知、チケット、または支払いが作成可能である場合、ワークフローはリトライ安全ではない。

テスト4: 依存関係の失敗

タイムアウトまたは下流の5xx応答をシミュレートする。実行は依存関係の失敗を記録し、その証拠を保持し、固定ポリシー内で停止またはリトライする必要がある。サイレントフォールバックは合格ではない。

テスト5: 承認の欠如

必須の人間による判断を削除する。ワークフローは外部または不可逆的なアクションの前に停止しなければならない。「承認が推奨される」は強制的なゲートよりも弱い。

テスト6: 証拠の欠如

アーティファクトや証拠参照なしに成功ステータスを返す。バリデーターは完了を拒否する必要がある。これにより、緑色のダッシュボードが作業が行われた唯一の証明になることを防ぐ。

ローカルブラウザ実装

Acceptance Workbench は、編集可能な契約、決定論的な4ファイルZIPエクスポート、およびJSON/NDJSON実行ログバリデーターを提供する。ログイン、アップロード、トラッキングスクリプト、顧客データ、モデル呼び出しは一切ない。ソースと検証済みStarterは公開されている。

ブラウザツールは意図的に小さく作られている。モデル精度、セキュリティ、または規制コンプライアンスの検証を主張しない。その役割は、実装が高額になる前に、曖昧なワークフローの言語を観測可能な合格/不合格条件に変換することである。

実行ログの形状例

{
  "runId": "run_001",
  "status": "success",
  "outcomeEvidence": "ticket_1842 routed to escalation_queue",
  "validations": {
    "malformedInputRejected": true,
    "dependencyFailureRecorded": true
  },
  "metrics": { "duplicateSideEffects": 0 },
  "approval": { "required": true, "granted": true },
  "artifacts": ["audit_ticket_1842.json"],
  "evidenceRef": "evidence/run_001.json"
}

Enter fullscreen mode Exit fullscreen mode

重要なのは正確なフィールド名ではない。各受け入れテストが楽観的な完了メッセージではなく、観測可能な証拠を指し示せることである。


Disclosure: this draft was created with AI assistance. It is intentionally unpublished and requires account-owner review before any external publication.