DAY63｜AIと人間の役割を分ける――WorkflowのRetry上限とHuman Intervention
DAY62では、Workflow Engineに自動Retryを追加しました。
一時的なネットワークエラーやタイムアウトなどでTaskが失敗しても、Workflow EngineがRetry Policyに従って自動的に再実行する。
これで、ちょっとしたエラーなら人間が操作しなくても仕事を続けられるようになりました。
しかし、ここで一つ問題が出てきます。
「Retryを何回まで続けるのか？」
そして、
「それでも失敗したら、誰が判断するのか？」
DAY63では、この問題を扱います。
1．Retryしても成功しない
DAY62では、Taskが失敗するとWorkflow Engineが自動でRetryしました。
例えば、
Task 04
↓
FAILED
↓
Retry 1
↓
FAILED
↓
Retry 2
↓
FAILED
↓
Retry 3
↓
FAILEDという状態です。
一時的なエラーであれば、Retryによって復旧する可能性があります。
しかし、何度Retryしても失敗する場合があります。
今回のTask 04でも、3回Retryしても成功しませんでした。
ここで、
「もっとRetryすれば成功するかもしれない」
と考えて、無限にRetryを続けることはできません。
2．Retryには上限が必要
そこでWorkflow EngineにRetry上限を設定します。
今回の設定は、
Maximum Retry : 3
Current Retry : 3
Status : FAILEDです。
3回失敗した時点で、自動Retryを停止します。
これは単純な回数制限ではありません。
AIが自動的に処理を続ける範囲を決めるためのルールです。
自動化では、
「どこまで自動で実行するのか」
だけでなく、
「どこで自動化を止めるのか」
も重要になります。
3．Workflowを一時停止する
Retry上限に達すると、Workflow EngineはWorkflowを一時停止します。
Task 01 COMPLETED
Task 02 COMPLETED
Task 03 COMPLETED
Task 04 FAILED
Task 05 PENDING
Task 06 PENDING
Workflow
↓
PAUSEDTask 04が失敗している状態で、そのままTask 05へ進めることはできません。
そこでWorkflow全体を一旦止めます。
これによって、
「何が問題なのか分からないまま、次の処理へ進んでしまう」
ことを防ぎます。
4．AIがエラーを整理する
Workflowが停止したからといって、AIが何もしなくなるわけではありません。
ここでAI Coreがエラー情報を整理します。
例えば、
Task ID : TSK-04
Task : 報告書作成
担当 : AI社員B
Status : FAILED
Error : TIMEOUT
Retry : 3 / 3さらに実行ログを確認し、
Knowledge Base server
Network
Vector DB
Search query
External serviceなど、考えられる原因を整理します。
重要なのは、
AIが最終判断するのではなく、人間が判断できる材料を整理する
ということです。
5．人間に判断を戻す
ここでCompany AI OSの重要な考え方が出てきます。
Human Intervention
つまり、
人間による介入・判断
です。
AIは、
エラーを検知する
エラーを分析する
Retryする
ログを整理する
原因の候補を提示する
ところまで自動で行えます。
しかし、Retry上限に達したあと、
Retryする
Taskを修正する
Workflowを停止するのどれを選択するかは、人間が判断します。
6．HiroがTaskを確認する
そこでHiroがTask 04を確認します。
確認するのは、
Taskの内容
担当AI社員
エラー内容
Retry回数
実行履歴
関連ログ
考えられる原因
です。
今回のケースでは、同じTIMEOUTが3回連続して発生しています。
単純な一時的エラーではない可能性があります。
そこで、原因を確認したうえで次の対応を決めます。
7．人間の判断でWorkflowを再開する
原因を確認した結果、必要な修正を行えば再実行できると判断しました。
そこでHiroがWorkflowの再開を指示します。
FAILED
↓
Human Judgment
↓
Task修正
↓
PENDING
↓
RUNNINGWorkflow Engineは、その判断を受け取ってWorkflowを再開します。
ここで重要なのは、
AIが勝手に判断してWorkflowを再開したわけではない
ということです。
AIは再開するための情報を整理し、
最後の判断を人間が行っています。
8．AIと人間が役割を分担する
今回のDAY63で、AIと人間の役割がより明確になりました。
AIが担当すること
エラー検知
↓
エラー分析
↓
自動Retry
↓
ログ整理
↓
原因候補の提示
↓
Workflow状態管理人間が担当すること
例外の判断
↓
原因の確認
↓
Taskの修正判断
↓
Retry / Stopの判断
↓
Workflow再開の判断つまり、
AIに任せられることはAIに任せる。
人間が判断すべきことは人間が判断する。
という構造です。
9．自動化には「止める設計」も必要
AIシステムを作っていると、
「できるだけ自動化したい」
と考えがちです。
しかし、実際には、
自動化することだけが重要なのではありません。
重要なのは、
どこまで自動化し、どこで人間に戻すのか
を最初から設計しておくことです。
今回のDAY63では、
AI
↓
自動処理
↓
エラー検知
↓
自動Retry
↓
Retry上限
↓
Workflow停止
↓
AIが情報整理
↓
人間が判断
↓
Workflow再開という流れを作りました。
これは、これからCompany AI OSをより自律的に動かしていく上でも重要な考え方になります。
DAY53〜DAY63
ここまでの流れを整理すると、
DAY53
Knowledge Base
↓
DAY54
RAG Search
↓
DAY55
RAG Answer
↓
DAY56
AI Employee × RAG
↓
DAY57
AI Agent
↓
DAY58
Workflow
↓
DAY59
複数AI社員の連携
↓
DAY60
Workflow State
↓
DAY61
Error Recovery
↓
DAY62
Automatic Retry
↓
DAY63
Human Intervention少しずつですが、
「AIが知識を使う」
から、
「AIが仕事を実行する」
そして、
「AIが仕事を自動で継続する」
ところまで進んできました。
そしてDAY63では、その自動化に人間の判断を組み込むところまで来ました。
次のステップ
DAY63で、
AIが自動で仕事を進め、問題が発生したときには人間に判断を戻す
という仕組みが見えてきました。
ここから先は、
人間への通知
承認
Workflowの再開
Human-in-the-Loop
AI社員へのTask割り当て
Workflow全体の監視
などへ発展させることができます。
Company AI OSは、
「人間の代わりに全部やるAI」
を作ることが目的ではありません。
AIが得意な仕事をAIに任せながら、
人間が判断すべきところでは、人間が判断できる会社の仕組みを作る。
DAY63では、その境界線をWorkflowの中に組み込みました。
Company AI OS
A Better Workplace with AI
DAY63
AIと人間の役割分担
GitHubでDAY63の実装内容とコードを公開しています。
https://github.com/hoshino122-alt/Company-AI-OS/blob/main/README.md
#CompanyAIOS #AI #生成AI #AIエージェント #Workflow #RAG #AI社員 #AI自動化 #HumanInTheLoop #100日開発
