Hane Platform

承認と Task

人が決める・作業する Task の割り当てと処理、Agent が提案した操作の承認、誰が決めてよいかを決める DeciderPolicy を説明します。

このページでは、人の判断を扱う Approvals サービス（/v1/approvals）を説明します。Task がどこから作られ、誰に割り当てられ、どう決めるのか、そして Agent が提案した外への操作をどう承認するのかを扱います。

Task とは

Task は、人が決める・作業する 1 件です。担当のグループか担当の人に割り当て、あらかじめ決めた結果（outcomes）のどれかを選んで閉じます。Task は次のところで作られます。

作るもの	Task の中身
Workflow の `task`・`escalate` のステップ	業務の判断や確認。結果で案件が次へ進む
Agent が提案した外への操作	承認の Task。結果は「承認する」（`approve`）か「却下する」（`reject`）
人が行う操作	承認された郵送・電話・窓口などの操作を担当に行ってもらい、結果を記録する実行の Task
監視の Agent	洗い出しの規則に当たった項目を、担当の候補に割り当てる Task

Task のステータスは open・completed・cancelled です。案件を取り消すと、その案件の開いている Task も取り消されます。

割り当て

誰に Task を割り当てるかは、割り当ての規則（AssignmentRule）のマニフェストで決めます。

apiVersion: approvals/v1alpha1
kind: AssignmentRule
metadata:
  name: vehicle-manager
spec:
  candidates:                       # レコードから関係をたどって担当の候補の人を引く
    path:
      - { relation: managed_by, direction: out }
    email: email                    # たどった先のレコードのメールアドレスの項目
    role: operator                  # このロールを持つメンバーだけを候補にする
  stages:
    - group: fleet-desk             # 候補がいなければこのグループに割り当てる

指定	内容
`stages`	割り当てるグループの順。Task の期限を過ぎたら次の段のグループへ回す
`routes`	案件の対象のレコードの値（CEL）で、最初の段のグループを選ぶ条件。どれにも当たらなければ `stages` の最初の段
`candidates`	レコードから関係をたどって担当の候補の人を引く。その日の所属・ロール・代理で絞り、残らなければ段のグループに割り当てる

担当の人（assignee）が決まっている Task は、グループのほかのメンバーではなく、その人だけが決められます。不在の期間に代理を設定しておくと、担当の候補は代理のメンバーに回ります（組織・プロジェクト・環境）。

Task を処理する

操作	API
一覧	`GET /v1/approvals/tasks`。`status`・`case_id` で絞れ、`mine=true` で自分か自分のグループの Task だけにできる
取得	`GET /v1/approvals/tasks/{id}`
引き受ける	`POST /v1/approvals/tasks/{id}/claim`
手放す	`POST /v1/approvals/tasks/{id}/release`
結果を選んで閉じる	`POST /v1/approvals/tasks/{id}/complete`

引き受け・手放す・閉じる操作は、Task の version を If-Match で送ります。2 人が同時に操作しても、片方だけが通ります。

POST /v1/approvals/tasks/tsk_01J…/complete
Authorization: Bearer <アクセストークン>
If-Match: "2"
Idempotency-Key: 1b7e…
Content-Type: application/json

{ "outcome": "renew", "comment": "見積を比べて再リースに決めた" }

Task を決められるのは人だけです。approvals:tasks.decide のスコープが要り、業務アプリから呼んだときも、アプリのサービスアカウントではなく、操作した利用者本人で判定して記録します。そのため、業務アプリは利用者のアクセストークンで呼びます（認証）。

外への操作の承認

Agent がメールの送信や電話、外部システムの更新のような外へ影響する操作を提案すると、Hane は操作の中身を固定した ActionRequest を作ります。承認で決めるのは、この固定した中身（承認の対象）です。何を、だれに、いくらで行うか、取り消せない影響があるかを、サーバーが固定した内容のまま見せます。

承認の Task を閉じるときは、画面で見た承認の対象の digest を action_digest で送ります。いまの内容と違えば 409 になり、承認も却下も記録しません。
Agent の実行を始めた人は、その実行が提案した外への操作を承認できません。
承認に段があるとき、同じ人は 2 つの段で承認できません。どの段で却下しても止まります。
承認の期限を過ぎた操作は、承認しても実行しません。
承認された操作も、実行の直前に緊急停止や提案した主体の権限などをもう一度確かめ、止めるべきなら実行しません。

人が行う操作（郵送・電話・窓口など）が承認されると、担当に実行の Task が作られます。担当は行った結果を記録して Task を閉じます。承認と違う内容で行ったときは「逸脱」として記録し、完了にせず再承認に回します。

誰が決めてよいか（DeciderPolicy）

操作ごとに誰が承認を決めるかは、DeciderPolicy のマニフェストで決めます。Agent の定義の approval.decider でこのポリシーを指定します。指定がなければ、すべての操作を人が決めます。

apiVersion: approvals/v1alpha1
kind: DeciderPolicy
metadata:
  name: lease-application
spec:
  rules:
    - tools: [human.perform]
      when: { amount: { field: input.amount, at_least: 1000000 } }
      decider: human
      stages: [{ group: approvers }, { group: accounting }]   # 部門長 → 経理の順
    - tools: [human.perform]
      decider: human
      stages: [{ group: approvers }]

規則は上から順に当て、最初に当たった規則で決定者と承認の段を決めます。どの規則にも当たらない操作は、人が 1 回決めます。金額が読めない操作は、上限のない金額として扱います。

決定者（`decider`）	意味
`human`	人だけが承認できる。`stages` で順に承認するグループを決められる
`agent_or_human`	審査用の Agent（`reviewer`）も承認できる。審査用の Agent は承認・却下・人への引き上げのどれかを返す
`policy`	条件（`when`）に合う提案を、Task を作らずに提案のときに承認する。メール・SMS・電話では、送ったことのある宛先（`first_contact: false`）だけに使える

条件（when）には、金額（amount）、宛先が社内か社外か（recipient）、初めての宛先か（first_contact）を書けます。ポータルの手順、顧客アプリの API への書込み、人が行う操作は、human だけにできます。

人だけの承認にすぐ戻す

AI に任せている承認を止めたいときは、ReleaseBundle を待たずに、ツールの承認を人だけに戻せます。承認を待っている提案にもすぐ効きます。

POST /v1/agents/decider-overrides
Authorization: Bearer <アクセストークン>
Idempotency-Key: 8d02…
Content-Type: application/json

{ "tools": ["communication.send_email"], "reason": "送信の内容を見直すため" }

戻すには approvals:deciders.restrict のスコープが要り、operator も持っています。上書きを外して DeciderPolicy に戻す（DELETE /v1/agents/decider-overrides/{tool}）のは admin だけです。

次に読む

Workflow と案件Task を待つ案件の進め方

AgentAgent の提案と ActionRequest

監査と使用量承認と決定の記録を確かめる

コンソール承認の inbox で決める