AIエージェントとの1日：報告・承認・止める、そして外の相手のペース

いま起きていること

AIは、人が頼む前に報告する。 パンダオフィスでは2026年5月から、朝7時と夕19時に、AIが状況をまとめて通知する運用が動いている。そこに至るまでと、そこから先の記録から、3つの事実を挙げる。

• 2026年6月2日：朝の報告に、メールの件数や開いている課題の数といった確定データを渡したところ、AIがそれを無視し、改変した。指示を書き直す代わりに、確定データはAIを通さず、プログラムが報告の最後に直接書き足す形にした。その後、毎時の見張りも加えた。締切や新着を1通にまとめて通知し、変化がなければ黙る。この見張りはAIを呼ばないので、費用はかからない。
• 2026年6月14日以降：外部に影響のある操作は、承認を4段階（知らせる、見てもらう、承認が要る、必ず止める）に分けた。予定やタスクの書き込みは、人が承認ボタンを押すまで動かない。メールの送信は、権限そのものを取っていない。
• 外の相手の反応（著者への取材）：AIが作った成果物を取引先と外部の協力者に渡したところ、速さに驚かれた。同時に、量が多すぎて相手が読み切れなかった。渡す前に要点を絞る対処をすると、相手は次も同じ速さを前提にした。

外の製品も、同じ形に向かっている。Google が2026年10月に発表した業務用の「Gemini agent」は、目的を渡すとサブエージェントを生成し、仕事によっては数時間から数日続く。エージェントごとの権限と、エージェント名義の監査ログも備える。長く動くAIほど、報告と承認の設計が仕事の中心になる。

（出典：自社の運用記録 2026-05〜09／著者取材 2026-10-15／Google Cloud「Gemini at Work 2026」2026-10-08）

PMの仕事で何が変わるか

人間のチームの1日は、朝礼、作業、夕方の報告でできている。AIが加わっても、この形は残る。変わるのは、誰が先に動くかだ。

AIは、人より先に動いて報告する。人は、報告を受けて、承認するか止める。1日の流れは次のようになる。

この表で、人が受け取る量が増えることが分かる。AIは疲れないので、報告は際限なく詳しくできる。詳しい報告は、読み切れない報告になる。

外の相手に渡すときは、もっと厳しい。相手には、こちらの文脈も、AIがどう作ったかの経緯もない。速さは驚きになるが、量は負担になる。

（出典：自社の運用記録 2026-05〜09／著者取材 2026-10-15）

PMBOK-AIではこう扱う

PMBOK-AIは、人とAIの混成チームを、役割と接点の設計として扱う。PMBOK-AIの全体像はこちら。

1. 報告は、短くする。 報告は、結論と、人に判断してほしいことを先に出す。詳しい経緯は、読みたい人が開く場所に置く。外の相手に渡す成果物にも、同じ形を使う。取材で得た対処と同じだ。

2. 確定した数字は、AIに書かせない。 件数や金額のように、確定したデータは、プログラムが直接書き足す。AIには文章の整理を任せ、数字は触らせない。

3. 承認は仕組みにする。 書き込みは、人が押すまで動かない。押されなければ、30分で取り消される。外部への送信は、AIが実行できない形にして、人が行う。AIに任せる範囲と判断軸はこちら。

4. 止める条件を、先に決める。 手順書に「この条件に当たったら止めて報告する」と書き、AIが止まったまま事実を報告する形にする。止める条件を破る案は、AIが推奨してはいけない。

5. 外の相手のペースは、先に決めて伝える。 速さが評価されると、次も同じ速さを前提にされる。これは、期待値を管理する話だ。納品のたびに、何を、いつまでに、どの形で渡すかを、相手と決める。AIの速さは、一度見せると標準になる。標準にしてよい速さなのか、1回きりの速さなのかを、見せる前に決めておく。

（出典：自社の運用記録 2026-05〜09／著者取材 2026-10-15）

明日からやること

• AIの報告の冒頭に、結論と「判断してほしいこと」が入っているか確認する
• 報告の中の確定データ（件数、金額）を、AIが書いていないか確認する
• 外部への送信が、AIに実行できない形になっているか確認する
• 手順書に、止める条件を1つ書く
• 外の相手に渡す成果物について、渡す形と頻度を、次の納品の前に相手と決める

まとめ

人とAIの混成チームの1日は、報告、承認、止めるでできている。外の相手には、AIの速さを標準にしてよいかを、見せる前に決めておく。