Grok Bot プロダクトマネージャー向けガイド：アテンションリストと目標を担う特化型Agentチーム

Grok Bot のプロダクトマネージャー向けガイドは、Kevin Niparkoが自身の働き方を見直した実践から生まれたものです。彼はカレンダー管理とコミュニケーションをChief of Staff（幕僚長）に委ね、エンジニアリングの組織化、コーディング、データ分析、プロダクトリサーチ、採用をそれぞれの専門Agentに分担させました。直属の部下を持たないことが多いPMにとって、これは目標をダイレクトに託せる実動チームとなります。

その中でも特に注目に値するアプローチが2つあります。1つは、実際の業務から「アテンションリスト」を動的に生成し、あらかじめ設定した目標と突き合わせること。もう1つは、エンジニアリングマネージャーにタスクの分解と検収を担わせ、エンジニアリング職がクラウド上のコーディングAgentを管理することです。ただし著者も注意を促しているように、この運用手法には学習曲線が存在し、重要な意思決定は依然として人間が行う必要があります。

硬直化した優先順位から、動的に生成される「アテンションリスト」へ

ほぼすべてのPMが次のような経験をしているはずです。月曜日に今週の優先順位リストを入念に整理したものの、火曜日の午前中には本番環境のアラート、大口顧客からの突然の個別カスタマイズ要望、緊急の採用面接などによって、そのリストが完全に崩壊してしまう――。静的なToDoリストは、混沌とした現場の現実の前にあっけなく時代遅れになってしまいます。

このペインポイントに対して、実践の中で生み出された最初のコア・ワーク・プリミティブが「アテンションリスト」（Attention List）です。

この仕組みでは、常駐Agentが1日の業務の中であなたが実際に注いだエネルギーと注意力をリアルタイムに追跡し、現在進行しているプロジェクトの焦点を動的に抽出します。アテンションリストが反映するのは「今、何に追われているか」であり、「何を優先すべきか」と同義ではありません。ましてや人間が手作業で書き出した戦略的目標の代わりになるものでもありません。その中核的な役割は、実際のエネルギーの配分先を記録し、既定の目標との乖離を客観的に照らし合わせることにあります。

従来のワークフロー（形骸化しやすい）：
[静的な週間計画 / 優先順位リスト]  ──(現実に打ち砕かれる)──>  [Slack / メール / 突発的障害の火消しに忙殺]

Grok Bot の動的ワークフロー：
[Slack / メール / Granolaの会議録音 / カレンダー] 
      │
      ▼ (1時間ごとにバックグラウンドで現状を静かに分析)
[Chief of Staff (幕僚長)] ──> [動的アテンションリスト (Attention List)]
      │
      ├─ 1. ノイズの逆引きフィルター：自身宛てかつ焦点に合致するメールのみ残し、他はアーカイブ
      └─ 2. 実際のエネルギー監査：「口頭の計画」と「実際の時間消費」を比較し、委任可能なタスクを特定

アテンションリストの2つの具体的な活用法

1. 1日の情報ストリームに対する動的フィルターとして：PMは毎日、数百から数千通ものSlackメッセージやメールを受け取ります。著者が提示した個人のアーカイブ基準は、「メールが自分を名指しでメンションしており、かつ内容がリスト内の焦点プロジェクトに合致している場合を除き、毎時アーカイブする」というものです。なお、この強力なフィルタリング条件は著者自身の個別設定例であり、アテンションリストのデフォルト機能ではありません。日々の協働において、Chief of Staff Agentはカレンダー調整も能動的にサポートします。たとえば先週、Agentはまず仮の予定枠（holds）を押さえた上で開始時間の選択を著者に尋ね、著者が「午前10時（10am）」と返信すると、自動的にその時間枠へ予定を移動させました。
2. 実際のエネルギー配分を映し出す鏡として：アテンションリストは、自分が実際にどこにエネルギーを注いだかの軌跡を映し出します。毎週末や1日の終わりに、これと人間が手書きした戦略目標を客観的に突き合わせ、ギャップを確認できます。もし自分が雑務に過剰な時間を費やしていると気づけば、今後切り出して専任Agentに委任できる具体的なタスク境界線を即座に特定できます。

本ワークフローに基づく設定プロンプト例（アテンションリスト）

プロンプト設定（Chief of Staff Agent の例）：
「アテンションリストの作成：[例：1時間] ごとの周期で、私のメール、主要なSlackチャンネル、Granolaのミーティング議事録、カレンダーの予定を自律的に取得してください。私が現在実際に進めているプロジェクト群を凝縮したリアルタイムリストとして抽出し、各プロジェクトの現在の進捗状況および次に取るべきネクストアクションを明記してください。」

日常の呼び出しおよびフィルタリング指示：
「現在のアテンションリストと照合して受信トレイを確認し、現在のコアな焦点と関係のないメールをすべて直接アーカイブしてください [人間によるメンションがあり関連するものは保持]。」
「今週のカレンダーとアテンション記録を比較し、私が実際に最も時間を費やしたもののうち、今後は独立したAgentに切り出して任せられるタスクをリストアップしてください。」

重要な制約事項：このようなフィルタリングやアーカイブのルールを設定する際は、Agentが部門間の緊急コラボレーション通知を誤ってサイレント破棄してしまわないよう、明示的な絞り込み条件を設ける必要があります。また、導入初期には人間が抜き取り検査できるよう、アーカイブログを保持しておくことを推奨します。

全領域のコンテキストを統合：散在する顧客の生声を推論可能にする

プロダクトチームにとって最も価値ある資産は、各専門システムの中に散らばり、データのサイロを形成しがちです：

• 顧客ミーティングの録音・文字起こし：Granola や Gong に蓄積；
• 現場のリアルな不満や即時フィードバック：主要顧客ごとのSlack共有チャンネルに絶え間なく流入；
• 構造化されたリサーチやペルソナのインサイト：専任UXリサーチャーが管理するデータベースに記録；
• 利用指標やサブスクリプション課金データ：Databricks などのデータウェアハウスに格納；
• オンラインのテクニカルサポートやチケット：Plain や Intercom に分散；
• 複雑な過去の意思决定の経緯やPRD（製品要件定義書）：Notion のナレッジベースに保管。

従来、「最近オンボーディングした数社のエンタープライズ顧客は、具体的にどのステップで躓いているのか」といった問いに答えようとすると、PMは5つも6つものシステムを行き来して検索し、手作業で情報を繋ぎ合わせる必要がありました。

Grok Bot のエコシステムにおいて、この連携パイプラインを実現するのは2つの重要メカニズムです：

1. ツール単位のプラグイン（Plugins）と MCP 連携：常駐ランタイム環境で、主要なコラボレーションツールの連携プラグインを有効化する。
2. 仮想マシンによる事前認証（VM Authentication）：標準化されたMCPインターフェースを持たない社内システムやサードパーティの管理画面に対しては、Agent専用の仮想マシン内ブラウザでアカウント認証とセキュア環境の事前設定を直接完了させる。

コンテキストがAgentに対して構造化され透明になると、PMはシステムを横断した総合的な分析を行えるようになります。たとえば、Slack上のリアルタイムな顧客の不満と、Databricks上の利用率急落ポイントを直接クロス分析し、重要ファネルの離脱ボトルネックを迅速に突き止めることができます。

Agentに実コードをデリバリーさせる：2桁パーセントのPRマージを支える協働ループ

このエンジニアリング実践において、著者の自己申告によると、現在 Grok Bot がチーム内でマージされたPR（プルリクエスト）の2桁パーセント（double-digit percent）を占めているとのことです。

この自己申告による割合はチーム内で実際にマージされたコード貢献を示したものであり、Botによる自動マージ権限や個人の生産性向上を保証するものではありません。集計期間、PRの総数、手戻りの発生状況については具体的に言及されておらず、実際の現場導入にあたっては、各チームのコードレビューおよびリリース基準に則って運用する必要があります。

このアウトプットを支えている中核的な仕組みは次の通りです：

• 制御された独立クラウド実行環境（Cloud Agents）：Agentはコード断片をあてずっぽうに生成するのではなく、対象リポジトリのブランチ、実行時の依存関係、テストに必要なクレデンシャルが整ったサンドボックス環境で変更を適用し、テストを実行します。リポジトリの機密情報に対する無制限のアクセス権が付与されているわけではありません。
• PM視点における抽象度の引き上げ：PMはコードの実装詳細を1行ずつ監視する必要はなくなり、エンジニアリングマネージャーAgentに対して高次の機能目標と受入基準を提示し、タスクの組織化と分担を委任できるようになります。

[PMが高レベルのプロダクト目標と機能受入基準を提示]
                 │
                 ▼
     [エンジニアリングマネージャーAgent (Emily)]
     * 重要な制約：マネジメント専任、自らコードを書くことは厳禁
     * アクション：タスク分解 ──> アサイン・差配 ──> 目標と突き合わせて検収
                 │
   ┌─────────────┼─────────────┐
   ▼             ▼             ▼
[ICエンジニア 1] [ICエンジニア 2] [ICエンジニア 3] ... (5つの専属エンジニアAgent)
   │             │             │
   └─────────────┼─────────────┘
                 ▼
   [クラウドサンドボックス (Cloud Agents)]
   * 対象ブランチ、実行依存関係、制御されたテスト用クレデンシャルを事前配置
   * 自動コンパイル・実行、テストケース実行、インターフェースの相互すり合わせ
                 │
                 ▼
   [レビューおよびメインブランチへのマージが可能なコードPRを生成]

基盤となるタスクの分解、ブランチでのコーディング、テストの実行はエンジニアリングAgent群が分担して進め、チームのレビューに耐えうるPRを生成してくれるため、PMはより大局的な視点からプロダクトの機能を設計できるようになります。

特化型Agentチームの役割分担：なぜ「単一の万能Agent」を断固として拒むのか？

Agentの設計アーキテクチャには、根本的な分岐点が存在します。「すべてを知る巨大な単一モノリシックAgentを使うのか」、それとも「それぞれが明確な責務を担う専門Agentチームを構築するのか」という問いです。

著者が自身の業務において複数の特化型Agentを好む理由は、主に次の3点にあります：

1. 明確な参照可能性（Referenceability）：どのタスクを誰に任せるべきかが明確で、権限と責任の所在が極めてクリアになります。
2. 真の並行処理（Parallelism）：複数のAgentがバックグラウンドで独立したタスクを同時に進め、成果物の共有が必要なときにだけハンドオーバーを行います。
3. 分離された専用メモリ（Scoped Memory）：これが最も決定的な技術的制約です。Chief of Staffがフロントエンドのリグレッションテストのエラースタックを把握する必要はありません。同様に、コーディングを担当するAgentのコンテキストウィンドウを、受信トレイの日常メールで汚染させるべきではないのです。

中核となるAgentの役割構成と実践的運用ディテール

各特化型Agentの責務、インプット、アクションの整理は以下の通りです：

元記事の主要ワークフロー抽出：編集して使えるプロンプトテンプレート

既存のツールスタック（Slack、Teams、Jira/GitLab、Notionなど）で実践したい読者がすぐに活用できるよう、元記事から特に価値の高いプロンプトワークフローを標準テンプレートとして再構成しました。角括弧 [...] で囲まれた部分は、ご自身のチームの状況に応じて書き換える調整用パラメータを示しています。

1. コミュニケーションスタイルガイドの抽出（「いかにもAIっぽい不自然さ」を解消する要点）

多くのチームが、LLMに代筆させたメールや返信が型通りの紋切り型になってしまうと不満を漏らします。この記事が提示する最もレバレッジの高いテクニックは、Agentにあなたの過去の実際のコミュニケーションから文体の特徴を抽出させることです：

<!-- 本ワークフローに基づく設定プロンプト例：個人の文体スタイル抽出 -->
私が過去に [送信トレイ / 主要なコラボレーションチャンネル / ドキュメントのコメント欄] で送信した実際のメッセージ履歴を網羅的に読み込んでください。
私のコミュニケーションの癖を分析し、簡潔な「個人用コミュニケーションスタイルガイド」を策定してください。特に以下の点を抽出してください：
1. 私が普段使っている書き出しと結びの表現；
2. よく使う文の長さと句読点・記号の傾向；
3. 技術的な詳細とビジネス上の結論に関する記述の好み（例：結論ファーストか、事実の提示から入るか）；
4. 私が嫌い、決して使わない「空疎な定型句、クリシェ、いかにもAI特有の言い回し」の明確なリスト。

今後、私の代わりに外部向けコミュニケーションの下書きを作成する際は、現在のコンテキストにおける議論のトーンを参照した上で、
必ずこのスタイルガイドに厳格に従って生成し、一般的なAIの要約ではなく、私本人が書いたような文章に仕上げてください。

2. 非構造化な議論を正式なRFCに変換する（PM Pete のワークフロー）

プロダクト開発を進める中で、優れたアイデアが長大で散漫なグループチャットの奥深くに埋もれてしまうことがよくあります。このプロンプトは、混沌とした議論を高精度な仕様ドキュメントへと昇華させます：

<!-- 本ワークフローに基づく設定プロンプト例：議論スレッドから構造化RFCへの変換 -->
このスレッド [またはチャンネル / 共有ドキュメント] にある [特定の機能またはプロダクト方針の対立点] に関するすべてのコンテキストを読み込み、
専門的なプロダクト要件提案書（RFC）としてまとめてください。以下のセクションを含める必要があります：
1. 背景と議論の論点：各ステークホルダーの懸念事項を抽出し、議論内の重要な発言をそのまま引用する（発言者と文脈を保持）；
2. 要件の分解と優先度分類：[P0 必須 / P1 重要改善 / P2 保留・探索] の基準に従って機能スコープを明記する；
3. 主なトレードオフ（Trade-offs）：各選択肢における技術的・ビジネス的なコストや代償を指摘する；
4. 未決事項リスト：現時点で合意に達しておらず、PMが人間として最終判断を下すべき決定ポイントを整理する。

現場の実践から得られた4つの重要知見と人間の防衛線

数か月にわたる組織内での徹底的な実践を経て、著者は極めて実直かつ不可欠な4つの原則を導き出しました：

1. 明確に命名し、記憶を厳格に分離する（Named agents, separate memory）

各Agentには明確で独立した役割の境界とコンテキストスコープを持たせなければなりません。あらゆる業務をこなそうとするモノリシックなAgentを作ろうとしてはなりません。カレンダー担当にはスケジュールと連絡に集中させ、エンジニアリングAgentにはコードベースに集中させます。記憶の範囲を限定することで、無関係なコンテキストによるノイズを減らせます。ただし、この分離は人間が明確に境界線を設計する必要があり、システムが全自動で混信を防いでくれるわけではありません。

2. 実務の現場を通じてAgentに学ばせる（Agents learn on the job）

Agentに業務を教え込む最も有効なアプローチは、長大で抽象的なプロンプトの原則を書き連ねることではなく、過去の実務サンプルの実物を与えることです。「過去のコミュニケーションログを読み込んでスタイルガイドを作成せよ」と指示するほうが、「プロのプロダクトマネージャーらしく振る舞え」と空疎に指示するよりも、はるかに期待通りの表現を引き出すことができます。

3. 能動的な介入を厳格に抑制する（Agents shouldn't be noisy）

常駐Agentは本質的に自律行動への強い指向性を持ちがちですが、節度を欠けば不要な通知を撒き散らすノイズ源と化してしまいます。システム設計においては、「重大な変化がない限り沈黙を保つ」ことをデフォルトの最低ラインとして徹底し、真に必要でない限り人間への通知や割り込みを控えさせなければなりません。

4. 重要な局面は人間が必ず引き受ける（Human on the important stuff）

著者自身も、現在でも大半のメッセージを自ら送信し、ほとんどのドキュメントやアイデアに自ら手を入れていると語っています。これは定型的な表現を修正するためだけでなく、リクエストを発信した人間自身が真摯に思考を巡らせたことを受け手に伝えるためでもあります。

さらに著者は、以下のアクションについて最終レビューの権限を手元に残しています：

• 金銭の支出を伴う調達・購買操作；
• 社外の顧客やパートナーに向けた最終的なメール送信；
• 不可逆的な破壊を伴うあらゆるシステム操作（物理削除など）；
• プロダクトの根幹に関わる方針の綿密なトレードオフ判断と、重要ドキュメントの最終的な推敲。

これらのプロセスを人間が握り続けるのは、Agentの偶発的なミスを防ぐためだけではありません。組織横断的なコラボレーションの本質は、依然として人と人との信頼の上に成り立っているからです。重要な意思決定や対外的なステートメントの背後には、責任を持って深く思考した本物の人間のプロダクトマネージャーが存在しているという事実を、関係者全員が実感できることが不可欠なのです。