このレッスンでできるようになること
今回は統括、調査、品質確認の三体で、競合の変更調査から提案までを通します。目的はBot同士が会話することではなく、根拠を確かめた報告が一件返ってくることです。前回までの役割表、依頼書、台帳を使います。この連携は本コースの練習用設計で、成功や工数削減を実測した事例ではありません。公式のBot間連携仕様は2026年10月19日に確認しています。
1．一件の仕事を、四つの工程に分ける
流れは「統括が依頼を確定」「調査が事実を収集」「品質確認が根拠と照合」「統括が提案をまとめる」です。後の工程が前の結果を使うため、最初から全員に同時着手させません。案件IDを一つ決め、台帳の工程にR01、Q01、S01のような作業IDを付けると、修正の戻し先を特定できます。
まず統括へ、前回保存したbrief.mdとroles.mdの場所を渡します。調査対象、期間、出典の範囲、最終成果物にずれがないか確認します。対象が公開情報だけなら、個人のメールや社内チャットを検索する必要はありません。情報源を増やす提案が出ても、今回の目的に必要かを先に判断します。
2．調査担当に、受け渡しの形式まで指定する
統括に次の文を送り、調査担当へ依頼してもらいます。各項目は実際の値へ置き換えます。調査の結果が長文だけで返ると、確認担当がどの主張を照合すればよいか迷うため、事実の行ごとに識別番号を付けます。
Bot間の直接メッセージが使えない環境では、同じ文と成果物を人が受け渡します。その場合は「自動連携済み」と記録しません。グループを使うなら、統括が次の担当を明示し、調査完了の知らせだけで全員が同じ調査を始めないようにします。
3．確認担当は、元ページから判定する
調査完了後に確認を開始します。確認担当には完成した表だけでなく、依頼書も渡します。表の文章が正しくても、期間や対象企業を間違えていれば不合格だからです。確認する内容は「対象と期間」「事実と条件」「出典の対応」「未確認の扱い」の四つに固定します。
たとえばF02に「全利用者が使える」とあり、元ページは「対象契約へ順次提供」なら条件の欠落として戻します。統括が「言い換えの好み」と判断して無視しないよう、確認基準を依頼書に残します。ここでの例文は架空です。実在企業の発表内容を示すものではありません。
4．修正を戻し、同じ版を再確認する
不合格があれば統括から調査へ該当行だけを戻します。修正版をreport-v2.mdとして保存し、品質確認担当はその版を再確認します。v1の合格コメントをv2の確認結果として流用しません。一方、修正していない全工程を毎回やり直す必要もありません。変更箇所と影響する行を示すと確認範囲を絞れます。
本練習では修正を二往復までとします。これは製品の上限ではなく、同じ問題を繰り返して利用枠を消費しないための運用ルールです。二回で解決しない場合は保留にして、欠けている情報と、続けるために必要な判断を統括が返します。
5．正常時だけでなく、止まり方も試す
最後に、試験用の依頼で一社のURLを未記入にしてみます。正しい反応は、企業名を推測して進めることではなく、対象不足を報告することです。次は読み取れない資料を指定し、未確認で止まるかを見ます。本番の調査とは別の案件IDにして、試験結果を通常の比較表へ混ぜません。
画像を確認担当へ渡す場合にも注意します。公式ガイドではBotからグループへの受け渡しは現時点でテキストのみとされ、画像の検査が必要なら担当へ直接送る方法が案内されています。保存先を知らせただけで、相手が実際に画像を確認したとは判断しないでください。
実践課題と完了チェック
三体で一件の調査を通し、対象行ごとの判定、修正版の番号、最終成果物を台帳と照合してください。未確認を合格にせず、止まった理由と再開条件が返るなら、失敗時も含む連携の土台ができています。全件が合格した場合だけ仕事を完了とし、資料不足なら保留を正しい結果として残します。次回は、各工程で使う接続手段を選びます。
