Automation / API

RELAY が動くときに何が起きているかを、業務の言葉ではなく契約で見る画面です。入力から、抽出の根拠、実行計画、承認の紐づけ、失敗と「結果が分からない」の違い、再実行の扱い、記録まで、同じ 1 回の実行を追えます。

業務側の見え方は RELAY のデモに、日々の運用画面は SMART INBOX にあります。

1. 入力

同梱のサンプル文だけを入力に使います。URLを渡して取得させる入口も、式やスクリプトを受け取る入口もありません。

1通目：最初の相談1通目。書かれていない所要時間・準備時間は、質問として残ります。2通目：追加の情報2通目。同じ案件に紐づき、1通目で聞いた質問は繰り返しません。

実行できるのは上の「操作の種類」にある 8 種類だけで、この一覧はコードの閉じた集合そのものです。式やスクリプトを受け取る入口はありません。

入力は同梱サンプルと、この画面から選んだファイルだけです。URLを渡して取得させる機能はありません。

このコンソールは sample モードで動きます。mail.send・calendar.confirm・calendar.update は計画と承認までで、実行は customer_live と実接続がそろったときだけです。

計画の作成は同じサイトの /api/flow が行い、承認・実行・再実行の判定はブラウザ内の模擬アダプターで行います。入力文はサーバーに保存されません。

いずれもコードの定数から読み出しています。ここに無い値は、計画を作る側が作り出すこともできません。

どこまで届いてよいか。外へ出る操作は customer_live と実接続がそろったときだけ実行されます。

実行計画 runtime/types.ts · ActionPlan

抽出の結果ではなく、これから何をするかの一覧です。承認はこれに対して行われます。

実行計画の項目
項目	型	意味
`runId`	`string`	この実行の識別子。
`version`	`number`	計画の版。内容が変われば上がり、古い承認は効かなくなります。
`inputHash`	`string`	入力そのもののハッシュ。同じ入力かどうかの判定に使います。
`policyVersion`	`string`	どの規則で作られた計画か。後から説明するために残します。
`mode`	`ExecutionMode`	どこまで届いてよいか。
`evidence`	`Evidence[]`	抽出の根拠。原文の位置と引用で、言い換えではありません。
`missingFields`	`MissingField[]`	埋められなかった項目と、その理由。
`warnings`	`Warning[]`	blocking は needs_info を強制します。
`actions`	`PlannedAction[]`	実行する操作の一覧。

計画された操作 runtime/types.ts · PlannedAction

1 つの操作。承認と冪等性はこの単位で効きます。

計画された操作の項目
項目	型	意味
`kind`	`ActionKind`	閉じた集合のどれか。
`targetRef`	`string`	どこに対する操作か。
`payloadHash`	`string`	中身のハッシュ。承認はこの値に紐づきます。
`idempotencyKey`	`string`	同じ鍵の再実行は、二度目の実行になりません。
`requiresApproval`	`boolean`	計画側の提案。実際の可否は authoriseAction が環境から計算し直します。

実行の記録 runtime/types.ts · EffectRecord

外の世界で何が起きたか。計画ではなく結果です。

実行の記録の項目
項目	型	意味
`status`	`succeeded \| failed \| outcome_unknown \| skipped`	failed と outcome_unknown を分けます。後者は再送が二重配信になりえます。
`externalId`	`string?`	相手側の識別子。突き合わせの唯一の安全な根拠です。
`idempotencyKey`	`string`	計画の鍵と同じもの。再実行時の照合に使います。
`detail`	`string`	人が読むための説明。
`at`	`string`	実行を試みた時刻。あとから相手側の記録と突き合わせるための起点。