AI が「完了」と言ったとき、結果をどう確認するか

レポートは検証済みとマークされているが、独立した通知メモはまだ確認待ちとマークされている

AI が生成した概念イラスト。内容は仮定の例です。

AI にレポートをチームのドキュメントに保存し、その後、担当者に通知するよう依頼したとします。数分後、AI は「完了しました」と返信します。

ドキュメントを開くと、タイトルと冒頭の段落しかありません。通知を見ると、指定されたチャンネルにメッセージはありません。アシスタントは嘘をついたわけではありません。呼び出した各ステップは応答を受け取っています。ただ、「完了しました」という表現は、あなたが望んだ結果ではなく、アシスタントの呼び出しプロセスを説明しているのです。

タスクが複数のシステムに依存するほど、この言葉はずれやすくなります。本当に答える必要がある問いは 1 つだけです。タスクが要求する結果は、今、あるべき場所に本当に存在するのか？

「完了」を確認可能な結果として記述する

「レポートを整理してチームに通知する」はタスクの概要としては適切ですが、受け入れ基準には使えません。これを、対象システムで照合できる一連の条件に展開できます。

毎週の競合レポートを例にします。

タスク要件	完了条件（どこで確認できるか）
レポートを整理する	指定された期間をカバーし、出典リンクを保持し、欠落資料を明示する
ドキュメントを保存する	指定されたワークスペースと親ページにあり、本文が最終稿と一致する
チームに通知する	指定されたチャンネルに表示され、メッセージ内のリンクが上記のドキュメントを指している
結果を納品する	ドキュメントの場所、通知記録、および未完了または未検証の事項を返す

完了条件を書くときは、できるだけ「誰がどこでそれを見られるか」に落とし込みます。下書きの保存だけが求められているなら、チームに通知する必要はありません。同僚が読めることが求められているなら、対象メンバーのアクセス権限も確認する必要があります。アシスタント自身のアカウントでドキュメントを開けても、すべての受信者が開けるとは限りません。

「すでに送信した」と「相手がすでに読んだ」も分けて考えます。チャンネルにメッセージが表示されていれば、「公開済み」という判断は支持できます。閲覧や確認の記録がなければ、相手が見てフォローアップしたと推測することはできません。

3 種類の証拠は異なる問いに答える

検証には 3 種類の材料があり、それぞれが問いの一部にしか答えられません。

ツールの応答        この呼び出しはどんな応答を得たか？
                     ステータス、エラー、返されたオブジェクト識別子
                          │
対象レコード        結果はどこに落ちたか？読み戻せるか？
                     対象アプリ内のドキュメント、メッセージ、レコード
                          │
内容チェック        成果物は要件を満たしているか？
                     完了条件に照らして本文、出典、欠落項目を確認する

ツールの応答は、この呼び出しで何が起きたかを説明します。応答内のステータスフィールド、エラーメッセージ、返されたオブジェクトは、呼び出されたサービスが決めます。具体的な意味は、そのツールと対象 API の取り決めによります。ドキュメント識別子が返っていれば、それを手がかりにこのドキュメントを探せます。識別子だけでは、本文が完全かどうかはまだ判断できません。

対象レコードは、結果が本当にシステムに落ちているかを説明します。返された識別子でドキュメントを再読み込みするか、対象アプリ内の対応するレコードを開き、アカウント、ワークスペース、親ページ、内容を照合します。通知を確認するときも、チャンネルとメッセージ自体を見るべきで、似たタイトルで検索して今回の結果だと決めつけてはいけません。

内容チェックは、成果物を納品できるかを説明します。ドキュメントが存在しても、1 節が抜けているかもしれません。レポートに出典リンクがあっても、誤った期間のデータを引用しているかもしれません。このステップは、最初の完了条件に戻り、項目ごとに照合する必要があります。「作成に成功したかどうか」だけを見るのではありません。

3 種類の証拠は、短い実行結果レポートにまとめられます。何をしたか、結果はどこにあるか、何を確認したか、まだ不確かなことは何か。実行ログ全体をユーザーに貼り付ける必要はありません。

部分的な成功は個別に報告する必要がある

複数ステップのタスクは、一部だけ完了することがあります。前のステップはすでに完了し、後のステップはまだ結論が出ていない状態です。

以下は処理方法を説明するための仮定の記録であり、実際の呼び出しログではありません。

ステップ	観察された結果	現在の判断
ドキュメントを保存	ドキュメント識別子を返し、再読み込み後、本文は完全で場所も正しい	保存済みかつ検証済み
通知を送信	リクエストがタイムアウトし、メッセージ識別子を取得できなかった	結果不明
対象チャンネルを照会	現在のアカウントにメッセージを読み取る権限がない	このアカウントでは確認できない

この場合、アシスタントは「ドキュメントは保存済み、通知結果は未確認」と報告し、ドキュメントリンクとブロック理由を添えるべきです。

タイムアウトは、呼び出し側が想定時間内に応答を受け取らなかったことだけを意味します。通知は送られていないかもしれませんし、すでに対象システムに書き込まれたが応答が失われたのかもしれません。したがって、タスク全体をそのまま再実行すると、2 つ目のドキュメントを作成したり、通知を重複させたりする可能性があります。

後続の処理は、結果が不明なステップから始めるべきです。アカウントに読み取り権限があれば、対象チャンネル、送信時刻、レポートリンクでメッセージを確認します。今回のタスクに対応するレコードが存在すれば、内容を照合して実行結果レポートを補完します。照会で結果が出ない場合は、照会範囲、権限、データ可視化の遅延も考慮する必要があり、「見つからなかった」をすぐに「送信されていない」と書いてはいけません。

どうしても証拠が得られない場合は、権限を持つ人に対象チャンネルを確認してもらい、再送信を保留します。再送が必要だと確認できてから、通知ステップを続行し、すでに検証済みのドキュメントを再利用します。

実行結果レポートには「未確認」を残す

使える実行結果レポートは次のように書けます。角括弧内の内容は実際の結果で埋めます。取得できない場合は明確に説明し、もっともらしいリンクを生成してはいけません。

タスク：今週の競合レポートを保存し、指定チャンネルに通知する

ドキュメント：保存済みかつ検証済み
場所：[実際のドキュメントリンクまたはレコード識別子]
確認済み：対象ワークスペース、親ページ、本文、出典リンク

通知：結果未確認
理由：送信リクエストがタイムアウト。現在のアカウントは対象チャンネルのメッセージを読み取れない
処理：重複通知を避けるため再送を保留

確認が必要：対象チャンネルに上記ドキュメントリンクを含むメッセージが表示されているか

「失敗」「未実行」「結果不明」を同じ状態に押し込めないでください。それぞれ異なる対処法があります。ツールが明確にアクセス拒否を報告した場合は、通常、アカウントと権限を確認します。タスクがそのステップまで実行されていない場合は、続行するかどうかを決める必要があります。送信結果が不明な場合は、まず記録を確認すべきです。エラー原因が変わっていないのに、同じリクエストを繰り返し送信しても、通常は結果は変わりません。

長期的に自動実行されるフローでは、各ステップの結果識別子と検証状態も保存する必要があります。タスクに番号を付けると記録の関連付けに便利ですが、番号自体は重複書き込みを防ぎません。安全に再試行できるかは、対象 API が冪等性をサポートしているか、およびフローが実際に重複チェックを実行しているかによります。

OOMOL では、実行記録はどこまでカバーできるか

接続レイヤーは呼び出し能力と呼び出し記録を提供できますが、完了判定は依然としてタスク自身が示す必要があります。

OOMOL の権限コントロールは、connection ごとに呼び出せる操作を設定します。タスクを設計する際に留意すべき点が 2 つあります。1 つは、検証に必要な読み取り能力も同時に考慮する必要があることです。ドキュメントの作成を許可しても、アシスタントが関連レコードを読み戻せることを自動的に意味しません。2 つ目は、権限が特定の操作の呼び出しを許可していても、メッセージ送信、外部データの変更、共有範囲の拡大、コンテンツの削除の前には、対象 connection、操作、最終パラメータを確認すべきです。

OpenConnector をセルフデプロイする場合、最近の実行記録にはマスクされた入力サマリーと provider エラーが含まれ、OOMOL_CONNECT_ALLOWED_ACTIONS と OOMOL_CONNECT_BLOCKED_ACTIONS で実行可能な操作を制限できます。アシスタントは schema、scope、実行状態、安全なアカウントラベルしか見られません。これらの記録は呼び出し失敗の調査に適していますが、それらが説明するのは呼び出しであり、ビジネス目標が達成されたかどうかではありません。セルフデプロイガイド

タスクが人手による承認を待つ必要がある場合、Open Flow の Approval ノードと Wait ノードは待機状態を永続化し、確認後は同じ実行を続行でき、完了済みのステップを再実行する必要はありません。実行履歴は対応するフローバージョンに関連付けられ、ある結果がどのバージョンのロジックで生成されたかを明確にできます。ホスト版 · ソースコードとセルフデプロイ

完了条件、ステップ状態、再試行の決定、最終実行結果レポートは、アシスタントの指示、ビジネスコード、またはワークフローによって実装される必要があります。接続レイヤーは呼び出しパスと記録を提供しますが、タスク全体が完了条件を満たしたかどうかを判断する代わりにはなりません。

結果を検証できるタスクから始める

まず 1 つの書き込みステップを選び、最初からチェーン全体をつなげないでください。OOMOL Connections でタスクに必要な接続を設定し、利用可能な操作を確認してから、次の要件をアシスタントに渡します。

この確認済みのレポートを、私が指定したテストドキュメントの場所に保存してください。保存後に再読み込みし、本文が原稿と一致するか確認し、実際のドキュメントリンクを返してください。まだ他の人には通知しないでください。読み取りまたは検証ができない場合は、実行したステップ、返されたレコード識別子、不足している条件を説明し、タスクをすべて完了としてマークしないでください。

保存と検証が安定して完了するようになってから、通知を追加し、対応するメッセージ記録を返すよう要求します。書き込みステップを追加するたびに、対象システムで確認できる完了条件を 1 つ補います。

検証の鍵は、アシスタントが最後に何を言ったかではなく、アシスタントが示した場所をたどって、対象システムでその結果を見つけられるかどうかです。各書き込みステップが確認可能な条件に対応していれば、その「完了しました」には根拠があります。