「AIエージェントマネージャー」とは？HBRが定義した新職種と令和トラベルの5つの実践事例

AIエージェントマネージャーという新しい職種が生まれた

PMのみなさん、正直に聞きます。

毎週のKPI集計、データチームへの分析依頼待ち、各部門へのヒアリング——こういう「本来の意思決定に集中したいのに、その前段の情報収集で時間が消えていく」感覚、ありませんか。

自分はずっとそこに違和感を持っていたんですよね。

「PMの仕事は意思決定。それ以外はAIに任せていい」が自分の持論なんですが、2026年4月、まさにその思想を組織レベルで実装している事例が出てきました。

令和トラベルCEOの篠塚孝哉氏が「AIエージェントマネージャーという新しい役割を作った」とXで発信したんです。

社内で動くAIエージェントを「働きやすく」し、共通品質と運用をマネジメントする責任者だそうです。

最初に見たときは「また新しい肩書きか」と思いました。

でも中身を読み込むと、これはPMとして見逃せない話でした。

単なるAIツール導入担当じゃない。

組織そのもののOSをアップグレードする仕事なんです。

この記事では、Harvard Business Review（HBR）が定義した「エージェントマネージャー」という概念と、令和トラベルが実践する5つの具体事例を、PM視点で深掘りしていきます。

AIエージェントマネージャーとは何か？HBRが定義した役割の本質

HBRが2026年2月に正式定義した背景

HBRは2026年2月、「To Thrive in the AI Era, Companies Need Agent Managers」という記事を公開しました。

ハーバード・ビジネス・スクールのSuraj Srinivasan教授と、SalesforceのUnified Agentforce Platform COOであるVivienne Wei氏による共著です。

ここで定義されたエージェントマネージャーの役割をざっくりまとめると、こうなります。

• AIエージェントにタスクを定義し、アウトプットをレビューする
• エージェントが処理できない例外をハンドリングする
• 実際の結果をもとにワークフローを最適化する
• 品質基準を維持・改善し続ける

ソフトウェア革命でプロダクトマネージャーが生まれたように、AI革命ではエージェントマネージャーが不可欠になる。

HBRはそう主張しています。

To Thrive in the AI Era, Companies Need Agent ManagersHarvard Business Review LogoHarvard Business Review LogoHarvard Business Review LogoHarvard Business Review Logo

hbr.org

現場のエージェントマネージャーが語る「Data, Data, Data」

HBR記事の中で特に印象的だったのが、Salesforceのサポート部門でエージェントマネージャーを務めるZach Stauber氏の言葉です。

> 「Data, Data, Data. 私の1日はダッシュボード、スコアカード、エージェントのオブザーバビリティ・モニタリングで始まり、それで終わる」

この言葉だけ聞くとPMっぽい仕事に聞こえますよね。

実際、Salesforceが展開するAgentforceプラットフォームの成果を見ると、この言葉の重みが分かります。

カスタマーサポートの約74%を自律的に解決し、営業開発では30日で150件だったミーティング設定が1週間で350件以上に拡大。

年間6,000万ドルのパイプラインを生み出しているとのこと。

つまり、エージェントマネージャーの仕事は「AIを使うこと」じゃなくて「AIのパフォーマンスを計測・改善すること」なんです。

PMがプロダクトのKPIを追うように、エージェントマネージャーはAIエージェントのKPIを追う。

「あ、これPMの仕事と本質的に同じじゃないか」と感じたら、その直感は正しいです。

PMとの違い・重なり

PMの方なら気になるのが「自分の仕事とどう違うのか」だと思います。

自分なりに整理するとこんな感じです。

重なる部分はかなり大きいです。

実際、篠塚氏もPM的な素養を持つ人がこの役割に向いていると示唆しています。

違いがあるとすれば、マネジメント対象が「人間のチーム」から「AIエージェント群」にシフトしている点ですね。

では、この定義が実際の組織でどう実践されているか。令和トラベルの5事例で見ていきましょう。

令和トラベル（NEWT）の5つのAIエージェント活用事例

ここが本題です。

NEWTで実際に動いている5つの事例を、PM視点で見ていきます。

読みながら「あ、これうちのチームでもできそう」と思うはずです。

Slack経営ダイジェスト：朝3分で全社把握

毎朝8時に、全部門のKPIがSlackに自動配信されます。

3分で全社の状況を把握できる仕組みです。

これが嬉しいのは、朝のミーティング前に「今日の状況どうですか？」を各部門に聞いて回る時間がゼロになるという点なんですよ。

経営情報の集約って、地味だけど毎日発生するし、各部門に聞いて回ると30分以上かかる。

頻度が高く、定型的で、かつ経営判断のボトルネックになりやすい業務。

自動化の第一弾としては教科書的に正しい選択だと思います。

PMとして注目したいのは「なぜこの業務から自動化したか」という優先順位の付け方です。

インパクトが高く、失敗してもリカバリーしやすい。そこから始めているのが、プロダクト思考そのものですよね。

ニュース収集＆ブログライティング：10分で記事ドラフト完成

毎朝10個のネタが提案され、番号を選ぶだけでリサーチャー・ライター・エディターの3つのAIエージェントが協調して、数十分でドラフトを作成します。

ここ、面白いんですよ。

1つのAIに全部やらせるのではなく、役割を分けている。

リサーチ、執筆、編集を別エージェントに担当させることで、品質管理がしやすくなるんですよね。

いわばチームの分業構造をそのままAIで再現している感じです。

「番号を選ぶだけ」という人間の介入設計も秀逸で、これはエージェントマネージャーが設計する「ワークフロー」の好例です。

Figmaクリエイティブ大量生成：打席数の革命

AIでFigma上のクリエイティブバリエーションを一気に生成し、その中から選ぶスタイルです。

篠塚氏は「打席数が変わった」と表現しています。

これ、プロダクト開発でいう「Build-Measure-Learnサイクルの高速化」そのものですよね。

仮説検証の回転数が上がれば、当たりを引く確率も上がる。

デザイン領域でも同じ原理が働くというのは、PMとして覚えておきたいポイントです。

BQ×GA連携：自然言語でデータ分析

これ、個人的には5事例の中で一番「うおっ」と思ったやつです。

Claude CodeからBigQueryに自然言語でクエリを投げられる環境を構築。

経営会議中に「ちょっとこのデータ見てみよう」とその場で分析できるようになったそうです。

「来週までに分析レポートお願いします」が「今この場で出しましょう」に変わる。

PMの仕事は意思決定だと自分は思っていて、意思決定の質はデータへのアクセス速度に比例します。

この違い、想像以上に大きいですよ。

会議の場でリアルタイムにデータを引き出せるということは、「データ待ちで意思決定が先送り」という構造自体がなくなるんですよね。

モックドリブンミーティング：構想から1ヶ月でリリース

PMとしてはこれが一番衝撃的でした。

要件定義の前にAIでモックを作成し、実物を見ながら議論する手法です。

篠塚氏によると、この方法でコンシェルジュサービス「NEWT Bespoke」を構想から1ヶ月でリリースしたとのこと。

従来の「要件定義→ワイヤーフレーム→デザイン→実装」という順序を、「モック→議論→要件確定→実装」にひっくり返している。

抽象的な仕様書で合意を取るより、目の前にモックがあったほうが議論の質は圧倒的に上がります。

「仕様書を書かないPM」を名乗っている自分としては、まさにこの方向性なんですよね。

「仕様書を書いても伝わらない」という摩擦が、モックドリブンにすることで消える。構想から1ヶ月でリリースというのは、その証拠だと思います。

5つの事例を見てきましたが、共通しているのは「個人が楽になった」ではなく「組織の仕組みとしてAIを組み込んだ」という点なんですよね。

次のセクションで、このことをPM視点で深掘りします。

PMがAIエージェントマネージャーから学ぶべきこと

「標準化」がカギ：個人最適ではなくチーム最適

5つの事例に共通しているのは、「個人がAIを使って楽になった」という話ではなく「組織の仕組みとしてAIエージェントを組み込んだ」という点です。

篠塚氏の主張を借りれば、個人が自由にAIを使うだけでは、チーム全体で数%の効率化にしかならない。

標準化し、全員が同じエージェント・同じスキルセットを使える環境を整えることで、組織の品質バーが底上げされるわけです。

これはPMが普段やっている「プロセス設計」「ナレッジの型化」と本質的に同じ仕事ですよね。

ここで自分が重要だと思うのが「企業OSのAIアップグレード」という視点です。

これまでのDXは、紙の業務をデジタルに置き換えるアプリケーション層の話でした。

でも今起きているのは、OS層の書き換えです。

業務プロセス、情報の流れ、意思決定の仕組み。これらすべてを「AIエージェントが働く前提」で再設計する。

個々のツール導入ではなく、組織の根幹をアップグレードする話なんですよ。

スマホで例えるなら、アプリを1個入れる話ではなく、iOSのバージョンが上がる話です。

Anthropicが公開したチーム活用事例によると、マーケティング、デザイン、リーガルまで全チームがClaude Codeを活用しているとのこと。

How Anthropic teams use Claude Code | Claude

claude.com

一部のエンジニアだけがAIを使うのではなく、全部門がAIエージェントを「同僚」として扱う世界観です。

「自分だけ使えてる」では意味がない。組織としてAIを使いこなせるかどうか——ここが2026年の分岐点だと自分は思っています。

明日から始める3ステップ

「令和トラベルの事例はすごいけど、自分のチームでどこから手をつければ……」という方、安心してください。

令和トラベルのような大規模な取り組みをいきなり真似する必要はありません。

PMとして明日から始められるステップを3つ提案します。

ステップ1：棚卸し

自分のチームで「毎日・毎週発生する定型業務」をリストアップします。

KPI集計、議事録作成、競合調査、レポート作成など。

頻度が高く、フォーマットが決まっている業務がAIエージェント化の候補です。

ステップ2：1つの業務でパイロット運用

リストの中から1つ選んで、AIエージェントで自動化してみます。

最初はSlackへの日次レポート配信など、失敗してもリスクが低いものがいいですね。

令和トラベルがSlack経営ダイジェストから始めたのと同じ発想です。

ポイントは「個人で使う」のではなく「チームの仕組みとして導入する」ことです。

ステップ3：計測と改善サイクルを回す

エージェントの出力品質、所要時間、人間の介入頻度を計測します。

Zach Stauber氏が言う「Data, Data, Data」の実践です。

計測結果をもとにプロンプトやワークフローを改善していく。

この改善サイクルを回す人が、実質的にAIエージェントマネージャーの仕事をしていることになります。

3ステップで言えば、まずステップ1の棚卸しを今日中にやってみてください。

リストを作るだけでいい。それだけで見え方が変わります。

まとめ：AIエージェントマネージャーは「次のPM」か

HBRが定義し、令和トラベルが実践しているAIエージェントマネージャーという役割。

結論から言うと、これは「PMの進化形の1つ」だと自分は捉えています。

マネジメント対象が人間チームからAIエージェント群に広がり、意思決定のスピードとスケールが変わる。

でも本質は同じです。

ゴールを定義し、プロセスを設計し、品質を担保し、改善し続ける。

令和トラベルの5つの事例を見ても、どれも「AIに丸投げ」ではなく「AIが働きやすい仕組みを人間が設計している」。

この視点を持てるかどうかが、2026年以降のPMにとって大きな分岐点になるはずです。

まずは自分のチームで1つ、AIエージェントを「チームメンバー」として迎え入れることから始めてみてください。

Slackの日次レポートボットでいい。それ、明日から動かせます。