AI にプロジェクトを追跡させるには：重複通知を減らし、変化を見逃さない

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

金曜納品のプロジェクトを AI に見張ってもらうとします。月曜日、AI は顧客がまだ資料を確認していないとリマインドします。火曜日、またほぼ同じ要約を送ってきます。水曜日になると、顧客はすでにメールで延期を申し出ているのに、プロジェクトボードには依然として金曜納品と書かれています。アシスタントは両方の日付をレポートに入れ、最後に「引き続き注視してください」と提案します。

結局あなたは、メールを開き、ボードを確認し、担当者にもう一度聞かなければなりません。

継続フォローには、前回の判断を保持し、今回何が変わったのかを説明することが必要です。毎回すべての資料を要約し直すと、アシスタントは古いメッセージを新しい進展として書いてしまったり、まだ確定していない提案をすでに有効な取り決めとして扱ってしまうことがあります。

一度要約した後、何を残す必要があるか

アプリをまたいで情報を整理する試みはすでに多くあります。Composio の家庭日報の事例は、カレンダー、天気、娯楽コンテンツをその日の小新聞にまとめています。Lindy の AI teammate 紹介では、継続的なコンテキストと能動的なフォローアップについて議論しています。これらはその日の情報を何に整理できるかを示していますが、より具体的な問いには答えていません。すなわち、連続する 2 回のチェックの間に、どの確認済みの判断を保持すべきかということです。

その日の要約は目の前の予定を理解するのに役立ちますが、継続フォローのタスクでは、前回と比べて何が起きたかを説明する必要があります。

プロジェクト納品を例にすると、最初に資料を整理した後、残す価値のある内容はごくわずかです。現在確認されている納品日、まだ待っている資料、フォローアップを担当する人、そしてこれらの判断を裏付ける情報源です。さらに、今回のチェックがいつまでの範囲をカバーしたか、どの情報源が読めなかったかも記録します。

この記録が次回のチェックの出発点になります。アプリのデータベース、タスク記録、管理されたドキュメントなどに保存できますが、具体的な形式はアシスタントシステムが決めます。重要なのは、後続の実行が確実にそれを読み取れ、そのうちどれが確認済みで、どれが推測にすぎないかを把握できることです。

前回が「プロジェクトは順調です」の一言だけだったら、次回どこが変わったのかを説明するのは難しくなります。

新しいメッセージは必ずしも進展を意味しない

同じ資料がグループに転送され、メールボックスに「了解しました、ありがとう」が 1 通増え、ボードで誰かがタスクの説明を編集しました。これらはすべて新しい記録ですが、納品への影響は異なります。

タスクが気にする事実を中心に比較できます。このプロジェクトで本当に知る必要があるのは、資料が揃っているか、納品日が変わったか、誰が ToDo を引き受けたか、新しいブロッカーが発生したかです。

以下は仮定の状況です。

今回読み取った内容	どう理解すべきか	どう知らせるのが適切か
同僚が月曜の資料依頼を転送した	同じ事項で、まだ新しい納品情報はない	同じリマインダーを重複して送らず、期限が来たらリマインドする
顧客が以前欠けていた添付ファイルを送ってきた	資料は受領したが、要件を満たすかはまだ確認が必要	何を受け取り、何がまだ足りないかを説明する
顧客が来週月曜に変更できるか尋ねてきた	日程変更のリクエストが発生した	未決定としてマークし、現在確認されている日付を保持する
担当者が明確に日程変更に同意した	新しい確認記録が発生した	元の日付、新しい日付、確認の情報源を説明する

同じ記録を識別するには、ソースシステムが提供する識別子を使用できます。異なる記録が同じ事柄を説明しているかどうかを判断するには、プロジェクト、関係者、内容を組み合わせる必要があります。タイトルが同じというだけでは、2 通のメールを確実に統合することはできません。文言が違うというだけでも、プロジェクトが一歩前進したと考えるべきではありません。

すでに明確なフィールドは直接比較するのに適しており、意味を理解する必要がある箇所はモデルに任せます。たとえば、まず日付フィールドが変化したタスクを見つけ、次に AI に関連する議論を読ませ、この変化がすでに確認されたものかどうかを説明させます。

メールとボードが一致しないときは、不一致を残す

水曜のメールは来週月曜の納品を提案していますが、ボードには依然として金曜と書かれています。どちらが有効なのでしょうか？

「より遅く更新された」というのは記録時間を示すだけで、発言者に予定を変更する権限があることは示しません。メールはリクエストである可能性があり、ボードはまだ更新されていないか、別のタスクの日付を引用しているだけかもしれません。

チームは事前に根拠を決めておくことができます。たとえば、納品日は指定された担当者の確認を基準とし、ボードは確認後の予定を記録するために使う、といった具合です。そうすれば、アシスタントが日程変更メールを見たときに、それを未確認事項に分類できます。担当者が同意したのを見たら、ボードも同期する必要があると指摘できます。

取り決めがない場合、アシスタントは 2 つの記録を並べ、不一致を説明し、担当者に判断を委ねるべきです。以下は架空のリマインダー例です。

顧客は本日のメールで納品を来週月曜に変更するよう依頼しました。プロジェクトボードは依然として今週金曜のままです。現在読み取れる記録の中に、担当者による日程変更の確認はまだ見つかっていません。リクエストを受け入れるか確認してください。

情報源を引用するときは、実際に開けるリンクを示すべきです。「顧客メール」や「ボード」とだけ書いても、担当者は照合できません。

ここでは人が決定を下す必要があり、要求は明確です。「プロジェクトリスクに引き続き注意してください」と比べて、担当者は何を答えるべきかがわかり、根拠を直接開くこともできます。

変化がない場合、チェック失敗、期限到来は分けて扱う

継続的に実行されるアシスタントは、静かな結果を許容する必要があります。指定された情報源のチェックが正常で、物事にも変化がなければ、チェック結果を記録し、取り決めに従って重複した要約を送らないようにできます。

しかし、メールボックスの読み取りに失敗した場合、同じ結論を出すことはできません。アシスタントは自分がチェックを完了できなかったことだけを知り、最後に成功した読み取り位置を保持し、今回見落とした情報源を説明すべきです。アクセスが回復した後、見落とした期間の記録を補完的に確認する必要があります。API が増分カーソルを提供する場合は、その取り決めに従って続きを読むことができます。そうでなければ、見落とした時間をカバーするクエリを設計すべきです。回復当日だけを確認して、その間に変化がなかったと仮定してはいけません。

Viktor の自動化が静かに失敗するでは、長期間実行されるタスクが失敗しても気づきにくいことが説明されています。フォロータスクも同じです。リマインダーが来ないとき、前回実行されたか、どの情報源をチェックしたかを確認できるべきです。

もう 1 つのケースとして、新しいメッセージがなくてもリマインドが必要な場合があります。取り決めた期限が来たときです。顧客がずっと返信せず、双方が合意したフォローアップ時間になったら、この件は再び現れる価値があります。

したがって、リマインダーは実際の変化からも、事前に合意した時間条件からも発生し得ます。タスクが終了、キャンセル、または担当者に引き継がれた後は、対応するリマインダーを停止する必要もあります。そうでなければ、すでに完了した作業が毎日あなたに注意を求めることになります。

OOMOL はフォロータスクにアプリ接続を提供する

2 回のチェック間の変化を比較するには、アシスタントが実際のシステムから記録を読み取る必要があります。OOMOL では、Connector SDK が、認可済みの接続アカウントを選択し、対応するアプリ操作を呼び出す方法を説明しています。ゲートウェイが資格情報を保持し、実際のリクエストを発行します。

たとえば、プロジェクトフォロー用に仕事用メールボックスとプロジェクト管理ツールを接続し、それらが必要な検索、詳細読み取り、更新時間フィールドを提供しているか確認します。サービスごとにクエリ範囲、履歴記録、増分機能は異なるため、具体的なインターフェースごとに確認する必要があります。

前回確認した状態、異なる情報源間の関連付け、リマインダー条件、停止条件は、アシスタントまたはビジネスプロセスが保存・実行します。接続が成功した後も、これらのタスクルールは依然として実装する必要があります。

最初のバージョンでは必要な読み取り操作だけを開放し、変化のレポートを担当者に渡すことができます。ボードを同期したり顧客に返信したりする必要がある場合は、権限制御ガイドに従って対応する操作を設定し、実行目標と確認方法を明確にします。

チームが接続サービスを自分で管理する必要がある場合は、OOMOL のオープンソースプロジェクト OpenConnector を使用し、セルフデプロイガイドに従って資格情報、操作ポリシー、実行記録を管理できます。

同じプロジェクトで、2 回連続してチェックする

OOMOL Connections からタスクに必要なアプリを接続し、接続機能を呼び出せてタスク状態を保存できるアシスタントに、範囲の明確なリクエストを処理させることができます。

このプロジェクトの納品日と未納品資料をフォローしてください。まず指定されたメールスレッドとプロジェクトタスクを読み取り、現在確認済みの状態、未確認事項、情報源を整理し、後続の比較の根拠として保存してください。今回は結果を私に渡すだけで、ソースシステムは変更しないでください。次回チェック時には、今回と比べて何が変わったかを説明してください。変化がない場合は要約を繰り返さず、読み取りに失敗した場合は不足を説明してください。リマインダー時間と停止条件は、私が確認してから設定します。

最初のチェックでは、正しいプロジェクト、メール、担当者を選んだか確認します。2 回目はテスト資料で、重複転送を 1 件、日程変更リクエストを 1 件、正式な確認を 1 件加え、アシスタントが 3 つを区別できるか観察します。さらに 1 つの情報源を一時的に利用不可にし、読み取り失敗を「進展なし」と言ってしまわないか確認します。

これらの判断が期待どおりになったら、定時実行を設定します。次に受け取るリマインダーは、具体的な問いに答えられるはずです。前回確認した状態と比べて、今あなたが処理すべきことは何か？