全体像：五本のガイドはいずれもチャットを常設の作業システムへ変えている

Eric Zakariassonは当初、Coder、Writer、Researcherを別々のチャットに置いていた。単一プロジェクトなら対応できたが、複数を並行するとシグナルとノイズが混ざり、Bot同士も互いの進捗を把握しにくくなった。そこで人間のチームで馴染みのある構造を移植した。一プロジェクトにつき一チャンネル、固定roster、一件のプロジェクト記録、そして状態を保存するタスクボードである。

残る四本も同じ方向へ進む。モバイルスタジオは責任を分析、クリエイティブ、エンジニアリング、デプロイ、修復に分割する。デザインチームは探索、モーション、Figma制作、エンジニアリング解釈を別々のBotに任せる。GTMチームは会議、メール、見込み客開拓、アカウント、スライドの役割を作る。PMチームはさらにChief of Staff、Engineering Manager、エンジニアリングAgent、データ分析、採用を加える。

五本をまとめると、導入順序は次の七段階に整理できる。

1. 各Agentの職務と、やらないことを明記する。
2. Manager、Specialist、プロジェクトチャンネルで責任と文脈を分ける。
3. 業務完遂に必要な実アカウント、データ、コンピューター、制作資産へ接続する。
4. 反復作業をスキルとして記録し、ルーティンに実行時刻と入力元を与える。
5. 検収可能な成果物をAgent同士で直接引き継ぎ、フィードバックループを作る。
6. 外部送信、支出、削除、デプロイ、曖昧性の高い判断は人に残す。
7. まず一つのループを成立させ、責任が実際に増えたときだけ役割を追加する。

この七段階は五つの実践を編集上まとめたもので、xAIが正式に命名したフレームワークではない。

第一段階：各Agentの責任範囲を明確な役割として定義する

モバイル開発ガイドが最も完全な定義を示している。常設Botには六つの構成要素がある。役割定義は「何者か」、接続は「何にアクセスできるか」、専用コンピューターは「どこで働くか」、ルーティンは「いつ自律的に動くか」、スキルは「どう反復して実行するか」、引き継ぎは「誰に結果を渡すか」を決める。

六項目の中で見落とされやすいのが、拒否事項と引き継ぎである。Analytics Agentだけがデータ上の発見を宣言できるが、広告制作もアプリのコード変更も行えない。Creatives Agentは発見をもとに広告仕様とバリエーションを作るが、媒体購入はできない。Engineering Agentが受け取るのは曖昧な助言ではなく仕様である。GCS Agentは証明書、デプロイ、ロールバックを管理し、そこを通らない変更はプレイヤーに届かない。

Analyticsの設定は、時刻、情報源、出力まで具体的だ。毎日19:10にMetaとAppLovinの支出、インストール、CPIを集計し、毎日6:30にPostHogでルーム規模とPartner Challengeファネルを確認する。月曜9:00には7日・30日のCPIとApple・Google Playの収益をまとめる。広告の勝者と敗者はCreativesへ、プロダクト上の発見は仕様としてEngineerへ渡し、費用が発生する行為は必ず先に人へ確認する。

第二段階：Manager、Specialist、プロジェクトチャンネルで組織する

五本に登場する役割名は多いが、組織形態は安定している。日常調整のための汎用窓口を一つ残し、Managerにタスク分解・割り当て・検収を担わせ、Specialistには明確なデータ・ツール・責任を与え、プロジェクトチャンネルで異なる目標の文脈を分離する。

Ryan Perryによるモバイル開発の分解は、責任分離が必要な理由を示す。ゲーム本体の実装は全体の約15%で、残る約85%はユーザー獲得、クリエイティブ、クライアント側の開発、バックエンドとlive ops、ストアへのリリース、QA、インシデント対応だと見積もる。対応する六つの役割はOrchestrator、Analytics、Creatives、Rank’em Engineer、GCS、Bug Fixで、それぞれに担当しない領域が明記されている。デザインガイドもFigma Bro、Motion God、Experiments、Devbotで同様に役割を分離する。GTMページの関連カードも、チャンネル、roster、Notionボードという同じプロジェクト管理基盤を指している。

元のrosterは六つの役割と各作業面を一枚にまとめている。

複数プロジェクトのガイドは、この構造を最も簡潔に実装する。NotionにはProjectsとTasksの二つのデータベースがあり、Projects ManagerがProject Opsスキルでプロジェクトを作成し、チャンネルを開き、rosterを提案する。人員配置では既存のCoder、Researcher、Writerを先に再利用し、PM以外に提案できるBotは最大五体。適任がいない場合だけ新しい役割を作り、必ず人の承認を得る。ここでの六体上限は、執筆者が設定した実験値にすぎない。

プロジェクトチャンネルは人、PM、固定rosterを収容し、文脈の境界になる。

タスクボードはBacklog、Planning、In progress、Blocked、Doneを共有状態にする。

プロジェクト開始後、人とrosterはチャンネル内でタスクを分解する。PMは主に進捗を観察し、データベースを更新する。Botが止まったらタスクをBlockedに変え、チャンネルで人に助けを求める。単純だが、マルチAgentで頻発する制御不能を防ぐ。システムは沈黙で失敗を隠さず、人も各チャットを回って進捗を聞く必要がない。

PMガイドは、さらに深い階層を示す。Chief of Staffは唯一の汎用役で、カレンダー、Slack、受信箱、Attention Listを担当する。Engineering Managerはコードを書かず、技術タスクを分解して五体のエンジニアリングAgentへ委任し、目標に照らして検収する。エンジニアリングAgentは複数のCloud Agentを管理できる。執筆者がマルチAgentを使う理由は、誰が担うかを明確にできる責任、並列作業、役割ごとに範囲を限定したメモリの三つだ。Chief of Staffがコンピューター操作評価をデバッグすべきではなく、評価Agentが受信箱を整理すべきでもない。

Kevin NiparkoのPMチームの全体編成には、データ分析のAshley、プロダクト業務のパートナーであるPM Pete、Recruiterも含まれる。Chief of Staffは文体を学びAttention Listを維持できるが、外部送信、購入、削除は人の承認で止まる。階層化されたエンジニアリング組織では、Engineering Managerが目標を検収し、五体のエンジニアリングAgentがCloud Agentsへ委任する。「チーム」は役割一覧だけではなく、上下二層の委任と確認を含む。

第三段階：業務システム、専用環境、制作資産へ接続する

役割を丁寧に定義しても、作業環境がなければ助言しかできない。五本の事例は繰り返し、Agentを実際の業務システムへ接続している。モバイルチームはMeta Ads、AppLovin、Adjust、PostHog、Google Cloud、アプリストア、Sentry。GTMチームはSalesforce、Gmail、Calendar、Sheets、Drive、Slack、Notion、Granola、Figma、X、LinkedIn、データウェアハウス。PMリサーチはさらにGong、顧客Slack、Databricks、PlainまたはIntercomを加える。

GTM Botのコンピューターは24/7で稼働し、ノートPCを閉じても働き続ける。過去のGmailとSlackから文体を学び、Krista LetzはPCを離れているときもモバイルアプリと音声で仕事を依頼できる。プロダクトリサーチBotは、インタビュー、顧客Slack、ユーザー調査リポジトリ、Databricks、サポートチケット、Notionの意思決定を同時に検索し、複数情報源の質問に一つのシステムだけで答えるのを避ける。

PMガイドのCloud Agentも、空のクラウドマシンではない。コードベース、プロジェクト依存関係、Secrets、テストに必要な条件があらかじめ用意されているからこそ、エンジニアリングAgentは実装を委任し、検証を実行し、成果物を回収できる。後述する「Botが上位目標を分解し、PRのマージに参加する」という動作は、モデル、開発環境、階層委任、検収が一体で機能した結果であり、モデルだけに帰属させることはできない。

専用クラウドコンピューターがブラウザとターミナルを操作するため、ユーザーのPCが停止していてもルーティンは動く。この環境は実用的な代替手段にもなる。Ryan PerryはMeta Ads APIの認証問題でAPIを使えなかったため、録画ボタンを押し、Botのコンピューター上でWebからクリエイティブをアップロードする手順を一度実演した。Botはクリック手順を覚え、その後は毎日Web UIから少なくとも一件の新しいクリエイティブをアップロードしてテストできた。

デザインガイドは「実環境」をさらに徹底する。Motion GodはスクリーンショットからGrok Botのキャラクターを近似描画せず、製品で実際に使うアニメーション仕様ファイルを用いてlocalhostにplaygroundを作った。デザイナーはtiming、spring、distance、scale、easingを直接調整し、「左下をもう少し長く見る」「跳ね方が大げさ」と伝えて、すぐに全シーケンスを再生できる。

キーフレームは抽象的なモーションのフィードバックを、フレーム単位で比較できる制作資産に変える。

Figma Broも目測に頼らない。Figma MCPを通じて実ファイルのx/y座標、幅、高さ、間隔、書体、塗り、線、コンポーネント構造を読み、一つのAuto Layoutコンポーネントから20枚のstarter Botキャラクターカードを生成する。新規ユーザー向けのツール選択画面では、一般的なツールLogoの正しい版を探し、利用確率順に並べる。既存Figmaファイルが正本となる情報源であり、Agentは複製精度と規模を担い、人が残す価値のある版を判断する。自動化は、誤ったLogo、古いコンポーネント、不統一なアバター出典、一枚目と十枚目で異なる間隔といった小さなずれが大量に蓄積するのも防ぐ。

一括生成されたキャラクターカードは、スクリーンショットの近似ではなく構造化されたFigma制作を示している。

プロジェクト状態

デザイン分担

注意の実態

ソフトウェア納品

第四段階：ルーティン、スキル、引き継ぎで閉じたループを作る

ルーティンが定時に起動し、スキルが安定した実行を担い、引き継ぎが次の役割に結果を渡す。三つがそろって初めて、Agentは「呼ばれたときだけ動くアシスタント」から継続稼働するワークフローへ変わる。

プロジェクトPMの運用手順もここに含まれる。主に進捗を観察し、Projects/Tasksを維持する。Botが止まったり入力を欠いたりすれば、タスクをBlockedに変え、チャンネルで人に知らせる。明示的な状態は失敗を引き継ぎ可能にし、止まった仕事が無言で消えるのを防ぐ。

モバイルチームは、ルーティンが仕事から生まれる過程も示す。六体のBotは毎晩一つずつ仕事を担当し、朝に結果を渡す。ある夜間リクエストを実行した後、Botは今後も継続すべき仕事だと判断し、自分の固定責任へ追加した。つまりルーティンは人が事前に書いた予定表だけでなく、Agentが反復責任から帰納する場合もある。この方法を採るなら、「常設ルーティンの追加」を職務変更として扱い、継続利用する権限、資源、通知経路を確認すべきだ。

モバイルスタジオは最も完全なループを示す。Analyticsが広告とプロダクトのデータを読み、「発見」と呼べる判断を作る。CreativesまたはEngineerが発見を検証可能な変更へ変え、GCSがデプロイを管理し、新しい行動データがAnalyticsへ戻る。執筆者によれば、この循環で広告をpartyの場面からpartnerの場面へ変え、インストール単価を15ドルから1ドルへ下げた。別の分析では高得点と継続率の相関を見つけ、bonus hintを追加し、D7継続率を約2.5%から10%へ、元の約4倍に引き上げた。

元の会話は、Analyticsの発見がレポートで止まらず次の役割へ直接入る様子を示す。

Analytics広告 + プロダクト行動 → 出典付きの発見

→

Creatives / Engineer広告バリエーションまたはプロダクト仕様

→

GCS / Releaseデプロイ、証明書、ロールバック

→

再計測CPI · 得点分布 · D7継続率

CPI：15ドル → 1ドルD7：約2.5% → 10%自己申告であり、対照実験ではない

数字は目を引くが、証拠は単一チームの自己申告だけである。出典にはサンプル数、対照群、アトリビューション期間、同時期の変更、長期維持の状況がない。事例から学べるのはループの構造と責任境界であり、「六体のBotを導入すればCPIが15倍改善する」という一般的な約束ではない。

GTMガイドはルーティンを、より厳格な運用プロトコルとして記述する。

• 受信箱は顧客、見込み客、更新、見積もり、紹介、直接質問だけを抽出し、ニュースレター、自動通知、領収書、カレンダーRSVP、社内ノイズは除外する。要約と返信案は作るが自動送信はしない。返信すべき内容がなければ沈黙する。
• 会議後フォローは終了直後の外部会議だけを扱い、GranolaまたはGongの記録を正本となる情報源として、宛先、件名、本文、具体的な次の行動を下書きする。
• 初回の見込み客開拓では、CRM、メール、表計算、利用データ、インテントツール、アカウント担当、買い手の職能と役職を確認する。実際に送信した15–30通のメールから文体を学び、約30日後に更新する。
• 毎回、役職フィルターと件数を再確認し、CRMの実際のフィールドとステージを先に特定する。職能で厳密に絞り、重複を排除し、最近の公開情報がなければ「見つからない」と明記する。
• プロダクトデータ接続後は、各行にアカウント内のアクティブユーザーとプラン上限到達者を示し、上限到達を拡張シグナルとして扱う。インテントはプロダクトへの直接言及を優先し、一般的なAIの話題を強い意向とみなさない。
• 各行に既存商談のステージ、金額、最後のCRM活動を表示し、温まったパイプラインを新規コールドリストとして再利用しない。CSVではなくライブの表計算リンクを渡し、LinkedInの短文で「すでにメールした」とも書かない。
• 下書き前に過去90日の送信履歴、表のEmailed列、CRM活動を確認する。接触済みの人はSkip Draftとし、表には残すが再営業しない。
• まず2–3組のメールとLinkedInサンプルを人に見せ、承認後に全件を生成する。実際の送信後は日付を書き戻し、次回も重複を防ぐ。
• アカウント専門Agentは「処理済み内容」の状態ファイルを維持し、新しい情報だけを報告する。ポッドキャスト、動画、講演は文字起こしを取得するか実際に視聴・聴取し、3–6個の要点、競合への言及、感情、タイムスタンプ付き引用、購買シグナルを残す。通話から機能要望を抽出し、サポートチケットを追跡し、顧客に関係する新機能も照合する。テキストを取得できなければ明記し、見たふりはしない。

この種のプロンプトの価値は、文章が長いことではない。初回をどう初期化するか、毎回何を確認するか、何を正本となる情報源とするか、重複をどう防ぐか、どこで承認を待つか、完了後に何を書き戻すかという運用状態がそろっている点にある。

PMのソフトウェア納品も同じ経路で動く。人が上位目標を与え、Botはコードベース、依存関係、Secrets、テスト条件を備えたCloud Agent環境で分解、委任、レビュー、統合する。Kevinは当時、Grok Botが社内でマージされたPRの二桁パーセントを占めたと報告する。しかし期間、分母、手戻りの定義がない。この記述が示すのは実コード納品へ入った事実であり、品質や純効率ではない。

第五段階：五分野の実装例

五つの分野には異なる役割が必要で、万能Bot一覧を使い回すことはできない。役割定義、接続、ルーティン、スキル、引き継ぎ、人による承認ゲートは共有するが、具体的な作業単位は事業責任から決まる。

複数プロジェクト：プロジェクトチャンネルを文脈の境界にする

一プロジェクトにつき一チャンネル、一つのroster、一件のNotionプロジェクト記録を用意する。Projects Managerがメタ作業を担い、Specialistがタスクを引き受け、PMが状態を維持し、Blockedが続行不能な仕事を人へ明示的に戻す。プロジェクト終了後は一時的な役割を外せる。責任が再発したら、まず既存の職務を再利用する。

モバイル開発：「アプリを作る」を完全なスタジオへ広げる

Ryan Perryは六体のBotでモバイルゲームRank’emを運営する。記事公開時、直前一週間のiOSとAndroid合計ダウンロードが1,000回を超えたと報告した。事例はユーザー獲得、クリエイティブ、クライアント側の開発、バックエンドとlive ops、リリース、QA、インシデント対応を含む。ゲーム本体が約15%、周辺業務が約85%という比率は執筆者の経験的判断である。チームは収益Botと広告ネットワークの追加も計画し、その他の役割は新しい責任が生じたときに作る方針だった。ガイド一覧もこの実践を「六体のBot、一つのモバイルゲームスタジオ」と要約する。

デザイン：判断できるバージョンの数を増やす

John Baiは、常設AgentでFigmaや既存のデザインツールを置き換えたのではない。デザイナーが早い段階で実際に触れ、フィードバックできるプロトタイプを増やすために使った。Experimentsは三つのambient accessプロトタイプを作った。Macのノッチに常駐するもの、デスクトップの隅から顔を出すもの、カーソルを追うものだ。キャラクターモーションはMotion God、デスクトップ挙動と技術課題はDevbotへ渡し、実際の一日で体験できる版にまとめた。三案はいずれもそのまま採用されなかった。成果物は、いつ役立ち、いつ邪魔になるかをデザイナーが判断する材料になった。ガイド一覧も、always-on Agent、実際の制作資産、人間の判断を残すこととして紹介している。

GTM：顧客と成果物ごとに専任担当を置く

Krista Letzは当初、自分の使い方を社内Notionに書き、Enterprise GTMチームのドッグフーディングに使った。社内利用が広がってから実践を公開した。Chief of Staffは会議、メール、他Agentの編成を担い、毎日の資料は短く、一覧しやすく、通勤中にスマートフォンで読める必要がある。Prospectingは開拓状態を維持する。戦略アカウントにはCustomer Expertを置け、状態ファイルで未処理の新資料だけを報告する。Data Agentは顧客利用を追跡する。Product Expertはコードベースにつながり、通話中に顧客向けの技術回答を作る。権限がなければGleanなどの社内ナレッジを使える。1:1 Agentはマネージャーとの面談を準備する。Forecasting BotはGranola、Gong、Slack、メールからSalesforceの商談メモを更新する。Slides Botは事前に与えたデザイン規則に従ってFigmaマスターを維持し、顧客向けデッキも翻訳する。Sales CoachはGong通話を振り返る。

Slides Botの境界はそのまま応用できる。通話終了の5–10分前に録音を止めれば、直前に顧客が話した内容から「聞いたこと」のページを更新できる。通話前なら企業ブログや決算資料など一次情報だけを使い、ページは「相手が優先していること」と表現し、調査出典を明示する。公開資料を顧客の発言として見せてはならない。

PM：実際の行動から注意の向きを可視化する

Kevin Niparkoの出発点は、PMがプロダクトを管理していても直属部下を持たないことが多いという事実だ。常設Agentにより、PMは初めて目標を直接受け取り、納品を支援するチームを持てたという。ただし習得曲線もあると明言する。Attention Listは毎時Slack、メール、Granola、カレンダーを読み、現在注意を向けているプロジェクト、状態、次の行動を生成する。人が維持する週次目標ではなく、実際の行動から作られる。Agentは大量のメッセージを絞り、現在の関心外のメールを整理できる。PMは宣言した優先順位と実投入を比較し、一週間の注意配分を振り返り、後にAgentへ任せる仕事を見つけられる。

Chief of Staffのカレンダー事例は、自律性の境界を具体化する。まず仮の予定枠を作り、開始時刻を人に選ばせる。Kevinが10時と返信してから枠を移動する。Agentが情報収集と定型操作を完了し、予定に影響する重要パラメータだけを人が決める。

データAgentは既存の統合図表を更新・切り分けに使い、曖昧性の高い解釈は人に残す。

PMチームにはデータ分析のAshley、プロダクト業務のパートナーであるPM Pete、Recruiterもいる。Engineering Managerは着任時に、評価の高い人間のEMのSlack履歴を読み、優れたエンジニアリングマネージャーの分解、追加質問、検収を学ぶ。Specialistの訓練資料は役割定義だけでなく、優れた実務家の作業軌跡も含む。データAgentは主に統合図表を使い、過去に回答済みで更新が必要な質問や、別の切り口が必要な戦術的質問に答える。曖昧性が高く、経験や判断力を要する分析は人に残す。PM Peteはチャンネル、スレッド、DMに散在する機能をめぐる意見の相違を、原文引用とP0–P2優先度を含むRFCへ整理できる。Raspberry Piの不足部品を調査・購入し、配線を案内したこともある。執筆者はGrok Botが社内でマージされたPRの二桁パーセントを占めたと報告するが、期間、分母、手戻りデータは公開していない。

第六段階：送信、支出、削除、曖昧な判断を人に残す

五本はいずれもAgentに行動させる一方、重要箇所には人による承認ゲートを置く。「human in the loop」という一言で済ませず、どの種類の行為をどこで止めるかを具体的に示している。

外部メールは下書きまで。広告費は事前確認。新Agentの作成は承認制。アプリ変更はデプロイ役を通る。PMは引き続き大半のメッセージを自分で送り、重要文書を編集する。購入と削除は人が確認する。曖昧性の高いデータ問題は人間の分析チームに残す。モーションを280ミリ秒にするか340ミリ秒にするかはデザイナーが判断し、Agentに「正しく感じるか」を自己評価させない。

同じくらい重要なゲートが、沈黙することだ。変化がなければChief of Staffは通知しない。返信対象がなければ受信箱ルーティンは報告しない。アカウント週報に新資料がなければ一文だけ送る。Botの作業量は多くても、人への通知量は小さくなければならない。注意、承認、Blocked解除が必要なときだけエスカレーションする。

デザインとデータの判断は別の境界も示す。Agentは「作る—反応する—直す」を加速できるが、どの版が正しく感じられるかを人に代わって判断できない。データAgentは統合図表の更新や戦術的な切り分けに向くが、曖昧性が高く、経験や判断力を要する問題は人間のデータチームが扱う。Kevinは経験を四つにまとめる。役割に名前を付ける、メモリを分ける、役割の中で学ばせる、用事がなければ報告せず重要事項だけ人へ渡す。

Experimentsの三つのambient access案はいずれもそのまま採用されなかった。Motion Godに動きを、Devbotにデスクトップ挙動と技術課題を渡し、体験できる版へまとめた後、それが有用か、邪魔か、その中間かを人が判断した。

第七段階：検収できる一つのループから始め、必要なときだけ拡張する

五本は最初から数十体のAgentを作るよう勧めていない。モバイルチームは最も時間のかかるデータとプロダクトフィードバックのループから始める。複数プロジェクトのチームはチャンネルとタスク状態から、デザイナーは体験可能な一つのプロトタイプから、GTMは毎日の会議準備と受信箱をルーティンにするところから、PMはChief of StaffによるAttention Listの維持から始める。

モバイルチームは収益Botと広告ネットワークの追加を計画していたが、その他の役割は新しい問題が常設責任になってから作る方針だった。この拡張順序は、事前に巨大な組織図を描くより五つの実践に近い。

開始に向く仕事は通常四つの条件を持つ。反復する、入力元が明確、結果を確認できる、失敗時に停止して人へ聞ける。人が一度実演したらスキルとして記録し、連続実行が安定したら次のSpecialistへ出力を渡す。新しい責任が継続して初めて役割を増やす。

GTMの拡張経験はこの経路を補う。一度の画面実演からスキルを作り、実際の送信箱から文体を学び、人の修正を規則へ継続的に書き戻す。タスクが増えたらAgentを並列実行し、Chief of Staffが監査し、グループチャットで複数の役割に同じ目標と状態を共有する。監査は自動化・並列化できる仕事を探すだけでなく、不要になったルーティンも削除し、自動化システムが増える一方になるのを防ぐ。拡張するのは孤立したチャット数ではなく、追跡可能な責任の連鎖だ。

以下の最小役割カードは五本の素材をもとに編集したテンプレートで、xAIの原文ではない。六つの中核フィールドはモバイル開発ガイドから取り、拒否事項、承認点、成果物、成功基準には他四本の制御方法を加えた。

name: analytics-agent
mission: 実際の行動データと広告データを読み、検証可能な発見を作る
refuses:
  - 広告クリエイティブを書かない
  - プロダクトコードを変更しない
connections: [ads, attribution, product-analytics, revenue, errors]
environment: 専用クラウドコンピューター。接続がなければ先に質問し、独断で迂回しない
routines:
  - 毎日、支出・インストール・コストを集計する
  - プロダクトファネルが広告の約束と一致するか毎日確認する
skills: [広告レポートのエクスポート, クリエイティブ明細の取得]
handoffs:
  findings: creatives-agent
  product-specs: product-engineer
approvals: [費用が発生するすべての行為, 説明できないデータ矛盾]
deliverable: 出典、定義、勝者、敗者、次の行動を含むレポート
success: 次の役割が推測なしで実行でき、人が重要な判断をすべて監査できる

検収時に問うのは五つだけだ。役割内の仕事だけをしているか、正本となる情報源は正しいか、失敗を明示的にBlockedへ移せるか、下流への引き継ぎは実行可能な成果物か、重要な行為は本当に承認点で止まるか。答えられないなら、チームを拡張しない。

公式ガイド五本：複数プロジェクトのチーム、モバイルアプリ開発、Grok BotでGrok Botをデザインする、Enterprise GTM、プロダクトマネージャーのチーム。