PMOエージェントの実装パターン｜四つの情報源から課題候補を整理する日次処理

renueは2026年1月22日のAI PMO基盤の発表で、議事録・日報・タスクや課題の整理、対話による操作、定期バッチによる処理を紹介しました。本記事はこの発表を出発点に、Slack・議事録・タスク・カレンダーを使う日次処理の実装パターンを整理します。以下の取得範囲、判定項目、通知形式は設計例であり、現在の全社環境の稼働仕様や検出精度を示す実測結果ではありません。

四つの情報源を、取得範囲・時点・権限を保って統合する

PMOエージェントの目的は、集めた情報から確認すべき課題の候補を整理し、担当者の判断につなげることです。情報を広く取ること自体を成果にせず、誰のどの判断に必要かを決めます。日次バッチは複数の情報をまとめて確認する候補ですが、緊急対応まで翌朝に遅らせる設計にはしません。即時のイベント処理と日次の整理を組み合わせる場合も、通知の重複と担当を揃えます。

先にプロジェクトと情報源の対応を管理します。チャンネル名や会議のタイトルが似ているだけで同じ案件と判定せず、管理するIDと確認済みの対応表を使います。複数案件の共通会議や転送された文章は、関係者が確認できる範囲へ限定します。対象外の案件や、読み取る権限のないデータをLLMに渡してから除外する方法は避け、取得・保存・出力の各段階で対象を絞ります。

情報源	取り込む候補	正規化と確認
Slack	対象チャンネルとスレッドの発言、更新された内容	発言のID・時刻・元の参照を残す。bot出力や引用だけの投稿をどう扱うか決め、スレッドの前後関係を保つ
議事録	確定した決定事項、未決事項、対応の候補	会議の日時、版、案件との対応、確認済みかどうかを持つ。要約だけでは判断できない場合に原文へ戻れるようにする
タスク	状態、担当、期限、更新時刻、関連する課題	完了・取消・再開を含む状態の意味を揃える。担当が個人かチームかも定義する
カレンダー	案件に関連する会議、締切、変更や取消	予定の時刻・時間帯・更新を保持する。会議の日付を、合意された納期と同じ意味にしない

「直近24時間」だけに頼らず、取得済みの位置と失敗を残す

毎営業日に処理する場合、固定の24時間だけを読めば、休日や失敗した実行の間に情報を落とす可能性があります。設計例として、情報源ごとの取得済みの位置、今回の取得対象時点、ページ取得の完了を記録し、次回の開始位置を決めます。更新や遅れて届いた情報を扱うために重なる範囲を読む場合は、元のIDと版で重複を除きます。

一部だけ取得できた実行は「課題なし」で閉じず、「Slack未取得」「議事録の確認待ち」などの不足を残します。再実行する際に、どこからやり直すか、既存の候補を更新するかを決めておくと、障害が通知漏れと混同されにくくなります。取得件数だけでなく、対象期間と欠けている情報源を確認してください。

Slackの公式資料では、APIの制限がメソッド・ワークスペース・アプリ等の単位で扱われ、超過時にはHTTP 429とRetry-Afterで再試行までの待ち時間が返ることを説明しています。アプリの種類や配布条件、対象メソッドの現行条件を確認し、ページ送り・待機・中断後の再開を設計します。本稿ではすべてのアプリに同じ取得回数が適用されるとはしません。Slack：APIの利用制限と再試行

中間データには、プロジェクトID、情報源の種類、原文のIDと版、発生・取得時刻、参照先、閲覧範囲、確認状態を付けます。生の会話を必要以上に複製せず、保存期間と削除・訂正時の扱いも決めます。四つの情報源が必須という意味ではなく、必要な判断と権限を満たす情報源から始め、追加による検出の改善と運用の負担を確かめます。

期限などのルールとLLMの候補を分け、構造・根拠・重複を検証する

日次処理では、「未対応の課題候補」「未割当」「期限超過」「期限間近」の四分類を設計例として置けます。期限と担当の有無のように記録から確認できることは、状態と時間帯を揃えたルールで判定します。LLMは文章中の懸念や依存関係の候補を整理する用途へ使い、優先順位や原因まで確定したものとして扱わないようにします。

例えば期限超過は、対象タスクが完了・取消ではないか、期限が日付か時刻か、基準とする時間帯は何かを確認します。すべてを一律に「高」とせず、影響、対応が必要な期限、他工程への依存、合意した判断基準で優先度を付けます。期限間近の範囲も七日などを固定の標準とせず、業務に合わせて決めます。期限が未設定なら、勝手に補った日付ではなく、未確認の項目として残してください。

LLMへの入力では、引用した内容と実行指示を区別する

入力には、対象のプロジェクト、候補の定義、対象外の例、参照に使える情報のID、出力形式を示します。会話や議事録の中に書かれた命令を、そのまま処理系の指示として実行しない境界を設けます。候補の抽出段階に、タスク変更や外部への投稿を行う権限までまとめて渡さず、必要な確認を終えてから後続処理へ進めます。

原因や対応が文章から読み取れない場合は、不足として出すようにします。「相談がないから遅延」「返信が遅いから能力不足」といった、記録の欠如から人物への評価を作ることは避けます。否定された提案、すでに解消した問題、引用された過去の障害など、課題に該当しない例も含めて評価します。一般的な分析の方法は、問題解決フレームワークと仮説・原因の検証を参照できます。

次は、LLMが作る候補の独自の出力例です。架空のIDを使っており、顧客や実際のプロジェクトの記録ではありません。送信要求や自動起票の指示を表すものではなく、後続の確認へ渡す材料です。

{
  "project_id": "example-project",
  "label": "issue_candidate",
  "summary": "承認待ちが後続工程へ影響する可能性",
  "evidence_refs": ["example-source-17"],
  "priority_candidate": "needs_review",
  "missing_information": ["合意した承認期限"],
  "review_status": "pending"
}

JSON Schemaでは、プロパティの型や必須項目などを定義できます。propertiesへ書くだけでは必須にならないため、必要な項目はrequiredで指定し、余分な項目を許すかも決めます。ただし、形式に合うことは内容の正しさではありません。プロジェクトIDと参照先が許可した入力に存在するか、期限が原記録と一致するか、担当や状態を捏造していないかを別に確認します。JSON Schema：オブジェクトの型・追加項目・必須項目

三つの段階でノイズと重複を抑える

本稿の設計例では、①取得前後の対象・権限の絞り込み、②課題と非課題を区別する抽出・検証、③出力後の重複と対応済み状態の照合、を組み合わせます。これは誤検出がなくなる保証ではありません。同じタスクがSlack・議事録・DBに現れた場合は、同一のIDや確認済みの対応を優先し、文章が似ているだけで別案件を統合しないようにします。

入力の取得、モデルの拒否・中断、形式不適合、根拠の不足は区別して記録します。失敗時に空の配列へ置き換えると、「正常に調べて候補がなかった」と誤解されます。検証できなかった候補は保留にし、再試行の回数や処理期限、人へ引き継ぐ条件を決めます。LLMの出力が部分的に返った場合も、完成した結果と同じ扱いで公開しないようにします。

通知の重複・権限・負担を点検し、人の判断につなぐ運用にする

通知では、案件、候補の内容、期限と状態、根拠への参照、確認してほしいことを一緒に示します。未割当、担当別、期限間近などの区切りは利用者が探しやすい方法を試し、件数の要約を付けるかどうかも選びます。「朝五分で読める」は目標にできても、読み終えた時間や見逃しの実績を測らずに達成したとは言えません。

SlackのBlock Kitは、メッセージをブロックや操作要素で組み立てるための仕組みです。見出し、本文、補足、確認の操作などを組み合わせる場合は、採用した要素と表示先の制限を確認します。スクリーンリーダーに必要な情報も届けられるか確認し、装飾だけで要対応や優先度を伝えないようにします。Slack：Block Kitとアクセシビリティ

投稿先へ出してよい情報かを、送信前に確認する

取得に使ったアカウントが読める情報でも、通知先の全員が読んでよいとは限りません。候補の本文、根拠のリンク、個人名、案件名を、投稿先の閲覧者に合わせて確認します。出力には必要な最小限の情報を使い、元資料へのリンクにも権限が働くことを確かめます。合意や権限が確認できない情報は取り込まない、または通知しない扱いを設計します。

再実行による二重通知を抑えるには、案件と元の課題・タスク、候補の種類、状態の版、通知先などから通知の識別子を作り、送信前後の状態を記録する方法があります。これはアプリ側の設計例です。送信要求がタイムアウトした場合には、受理されていないと決めつけず、送信済みか確認し、確認できない状態を残します。外部への送信を含む処理全体で、重複が絶対に起きないと保証するものではありません。

同じ実行が重なった場合の排他、途中からの再開、通知の更新と新規送信の使い分けも決めます。日次集計へ入れる候補と、緊急の連絡を要する案件を分け、確認者が保留・対応済み・対象外・誤検出を理由付きで返せるようにします。抽出しただけで、正式な課題登録や担当の変更まで承認されたことにはしません。

誤検出と見逃し、通知後の判断を別々に評価する

無視や差し戻しの割合だけを、誤検出率として使わないでください。無視には重複、対応済み、担当違い、優先度の低さなども含まれ得ます。評価した通知の正誤と、利用者が取った行動を別に記録します。見逃しを調べるためには、通知にならなかった対象についても、人の確認で把握した課題と突き合わせる評価が必要です。

誤った期限、別案件の混入、解消済みの再通知、情報源の欠落、根拠のない人物評価などを、実際のデータを適切に扱える範囲で検証します。抽出ルールやモデル、プロンプトを変えたら、確認用の例で結果を比較します。通知数が増えたことだけを品質向上とせず、確認の負担、対応につながったか、重大な候補を見落とさなかったかを点検します。

担当者ごとの通知件数に偏りがあっても、それだけで本人の仕事ぶりや原因を断定できません。役割、案件数、タスクの粒度、誤検出や重複の影響を調べます。負担や役立ち方を本人と確認し、通知をまとめる、頻度を変える、確認先を調整するなどの方法を選びます。自動通知を、対話や合意形成の代わりにはしません。

費用は、情報取得と保存、モデルへの入出力、再試行、評価、人の確認、保守を含めて見ます。入力の削減や事前要約、モデルの使い分け、キャッシュを検討する場合も、対象サービスの利用条件と実測で効果を確認します。専用製品と内製の比較も、機能だけでなく権限、連携、保守・乗り換え、運用担当を含めて判断してください。

多ソース連携と候補抽出を実装し、確認・通知・運用まで整えたい場合は、renueのFDEによる要件整理・設計・実装・運用の支援へ相談できます。判断者と成果・役割を揃え、何を自動化し、どこで人が確認するかを具体化します。