はじめに

私はいま、MSP の監視チームのマネジメントをしています。

日々アラートを捌いたり、手順書（ランブック）を整えたり、インシデントの初動を回したり、という世界にいます。

最近はエージェント時代の話題が一気に増えてきて、「これ、自分たちの仕事はどう変わるんだろう」と気になっていました。

そんな中で観たのが、AWS Summit Sydney 2026 の「A leader’s guide to advanced team structures in an agentic world」というセッションです。Amazon の Stephen Brozovich さん（Executive in Residence, AWS）が、エージェント時代に組織とチームをどう作り変えるか、をリーダー向けに話したものでした。

冒頭から「今日は AI ハイプの話はしません」と言い切っていて、実際ずっと地に足のついた話でした。自分の現場に効きそうだったので、整理がてらBlog書きました。

ひとつだけ先に。話の順番は、動画そのままではなく、自分が腹落ちした流れに少し組み替えています。動画と見比べながら読む方は、その点だけご容赦ください。

 

ざっくり言うと

先に、私が「これは持ち帰りたい」と思ったポイントを3つだけ。

  • 脅威は AI そのものではなく「AI を使いこなす人」 ── 数字で見ると、若手とシニアで真逆のことが起きている
  • 従来型のIT運用（開発と運用の分離）は、もう厳しい ── 監視・運用の現場にいる身としては一番ヒヤッとした
  • リーダーの仕事が「手順の管理」から「境界線の設計」に変わる ── ここが個人的に一番の学びでした

特に2つ目は、まさに自分の足元の話だったので、いったん手が止まりました。

「AIに仕事を奪われる」の本当の意味

セッションは、わりとドキッとする一言から始まります。

「AIはあなたの仕事を奪わない。あなたの仕事を奪うのは、AIを使う人だ」

AI 自体には野心も売上目標もない。だから本当の競争相手は、AI を武器にして、あなたより一歩先に習熟した同僚や競合だ、という話です。たとえに使われていたのが農場のトラクターで、トラクターは農業を滅ぼしたんじゃなくて、「農場で誰が役に立つか」を変えただけ。運転を覚えた人が残った、と。

面白かったのは、ここで出てきた採用市場のデータでした。

大量失業が起きているわけではない。でも、若手とシニアで真逆のことが起きている、と。

ジュニア（新卒・エントリー）の採用は前年比 73%減、AI スキルの求人需要は +1,587%
一方でシニアの AI 人材は爆発。AI エンジニアの平均給与は $206K（前年から+$50K）、新規の AI ロールは 130万件

「理論上は代替され得る」と「実際に職を失う」の間には大きなギャップがあって、起きているのは大量失業ではなく、入り口（ジュニア）の急激な再構築なんですよね。

漠然とした不安が、少し具体的な解像度になった感じがして、聞いていて引き込まれました。

「従来のIT運用はアンチパターン」と突きつけられて

ここからが、私にとっての本丸です。

セッションでは、運用モデルが3つに整理されていました。

  • Model A（従来のIT Ops）：開発チームが作って、運用チームに引き渡す。いわゆる分離型
  • Model B（組み込み型ポッド）：3〜5人のシニアが、構築から運用まで一気通貫で持つ
  • Model C（ポッド＋プラットフォーム）：Model B に、共通基盤（アイデンティティ・可観測性など）を足したもの

そして Model A には、スライドではっきり「The Anti-Pattern（アンチパターン）」とラベルが貼られていました。「あなたはたぶん、ここにいる。認めて、抜け出そう」と。

刺さったのが、スライドの「THE TEST」でした。「あなたの運用チームは、エージェントの挙動をデバッグできるか（プロンプトや推論チェーンを読み、検索品質を評価できるか）。それとも、サービスを再起動してチケットを切るだけか。後者なら、チームの名前が何であれ、それは Model A だ」と。

…これ、構造としては監視・運用の現場そのものなんですよね。開発と運用が分かれていて、ランブックと ITIL でプロセスを回す。脚注の「企業の97%がエージェント AI に予算を持つのに、デプロイ済みは18%だけ。障壁は技術ではなくオペレーティングモデル」も、うーん、、唸りました。

行き先は Model B / C。これまで専門家が分業していた 6〜8人 のチームが、エージェントを使いこなす 2〜3人＋エージェント に集約されていく、と。Model C では、共通プラットフォームの上で、採用マッチング・カスタマーサービス・サプライチェーン最適化・不正検知…といった「ポッド」が並走する絵が示されていました。

自分のチームの編成図を思い浮かべながら聞いていました。

手順を管理するのをやめて、境界線を引く

「Model A が厳しい」と言われると、じゃあリーダーは何をすればいいの、となります。その答えがガバナンスの章でした。

ここで使われていたのが「Agents find their own path（エージェントは自分で経路を見つける）」という、川のようなビジュアルでした。

これまでは、配管（パイプ）のように実行手順を細かく決めて、予測可能な入力に予測可能な出力を返す、というやり方だった。ランブックや ITIL がまさにそれです。でもエージェントは、川みたいに自分で経路を見つけて流れていく。

正直、この章が今回いちばんの収穫でした。「手順を書く人」から「境界線を引く人」へ ── リーダーの仕事の定義そのものが変わるんだな、と腹落ちした瞬間です。

具体策が「Policy as Code」でした。Cedar（AWS のポリシー言語）がゲートウェイで全リクエストを横取りし、LLM の推論ループの”外”で決定論的に強制する。しかも”お願い”ではないので、プロンプトインジェクションでもすり抜けられない（ツールの認可レイヤーで止める）。「ほとんどのフレームワークが見落とす層だ」と。

そして「Governance as Infrastructure」。エージェントが動く前に、毎回4つの問いに答えさせる、と。

  • Who is this agent?（誰なのか／アイデンティティ・権限・境界）
  • What is it allowed to do?（何が許されているか／決定論的なポリシー強制）
  • Is it working correctly?（期待どおりに動いているか／リアルタイム監視）
  • Can we prove it?（証明できるか／監査証跡）

この4つがそれぞれ AgentCore（Identity+Gateway / Policy=Cedar / Evaluations+Observability / CloudWatch）に対応していて、しかも脚注に「シンガポールの Model AI Governance Framework が、独立に同じ4次元へ到達した」と。…この4つ、エージェントに限らず、いまの運用の自動化を見直すときにもそのまま使えそうだなと思いました。

検証税と、2034年問題

最後に、育成の話。ここは20名のチームを預かる立場として、一番考えさせられました。

セッションでは、いまチームに効いている「4つの力」が紹介されていました。中でも私に刺さったのが2つです。

ひとつは「検証税（Verification Tax）」。AI を使えばコードは10倍速く書けるけれど、その検証（レビュー）は3倍難しい、というもの（脆弱性は2.74倍とも）。ボトルネックが「書く」から「確かめる」へ移った、と。生成が速くなっても、確認が詰まれば結局そこで相殺されるんですよね。

もうひとつが「脱スキル化の罠」。AI を使うジュニア層は速く出荷できる一方で、自分が作ったものの理解度は 17% 下がる、と。スライドには「AIなしで学ばなかったら、5年後に誰がそのAIを検証するのか」とありました。

ここで組織の「形」の話につながります。スライドでは、形の変遷が4つ並んでいました。

  • ピラミッド型（いま）：たくさんのジュニアが土台を支える。昔ながらの徒弟制
  • ダイヤモンド型（罠）：ジュニアを削り中間を厚くした形。「パイプラインを枯らす」
  • 逆ピラミッド型（ポッド）：シニア＋エージェント＋ジュニア1〜2名。実行は速いが学びの場がない
  • 砂時計型（目標）：上に実行部隊、下に学び続けるジュニアを意図的に残す。「パイプラインを生かし続ける」

そして「2034年問題」。スライドはこう問いかけます。「若手の育成を止めたら、5〜10年後のシニアはどこから来るのか？ 年功のピラミッドは反転し、AI が実行を吸収する。残るのは判断力（judgment）だ」と。AWS の CEO、Matt Garman さんの言葉も引かれていました ──「若手を AI で置き換えるなんて、これまで聞いた中でいちばん愚かな話だ」。

いま若手を育てるコストは、短期で見れば「非効率」に見える。でもそれは、10年後の自分のチームへの仕送りに近いと感じました。送金を止めた瞬間、未来の口座は空っぽになる。育成は美談じゃなくて、普通に経営判断だよなと腑に落ちました。

思ったこと

全体を通して、Brozovich さんが繰り返していたのは以下のメッセージ。

「勝つのは、最高の AI を持つ企業ではない。AI の周りに、最高のオペレーティングモデルを作った企業だ」

経済性のところでは、ワークフローを3つの世界に振り分けろ、と。Use（使う）＝ ServiceNow のような完全マネージド、Compose（組み合わせる）＝ Bedrock や Anthropic API を自社ワークフローに組み込む、Build（作る）＝ Hugging Face 等で自前。「差別化しない仕事は左（Use）へ寄せ、自社の”モート”になる部分にだけ投資しろ」と。

その背景が「価格のハサミ」でした。モデルの訓練コストは年2.4倍で上がる一方、推論（利用）コストは年10倍で下がっている。ギャップは年12〜24倍で開く。だから「Day 1 から全部自前構築」は、自社のワークフローを理解する前に会社を燃やし尽くすリスクがある、と。

人材の面でも、価値の源泉が「速く作れる人」から「エージェントを指揮できる人（オーケストレーター）」に移る、と。象徴的だったのが、Anthropic のハッカソン（2026年2月・13,000人規模）。3位が心臓専門医で、診察の合間や出張の機内で、患者ケアの基盤「PostVisit.AI」を7日で作ったそうです。1位は弁護士。スライドのまとめは「ドメイン知識 ＋ AI ツールは、コーディング力単体に勝つ」。

監視・運用の現場って、まさにドメイン知識のかたまりなんですよね。だから悲観する話というより、「持ち札の活かし方が変わる」話として受け取りました。

これ、MSP の現場に引きつけると

ここからは完全に私見です。（以下は私個人の見立てで、所属する会社の公式見解や、料金・SLA の方針を示すものではありません。）

このセッション、監視・運用の現場にいる人間には、けっこう生々しい話だなと思いました。

運用って、そもそも「検証税」のかたまりと思っています。アラートの一次切り分けも、AI が出してきた対応案のレビューも、ぜんぶ「確かめる」仕事です。だから AI で対応が10倍速くなっても、確かめる人の価値はむしろ上がる。コモディティ化していく「オペレーションの量」から「判断と検証」へ、商品の重心をずらせるかどうかだな、と思いました。

ここに、顧客提供価値の話もつながってくる気がしています。

エージェント化が進むと、「どれだけ捌いたか」より「どれだけ安心して任せられるか」── つまり信頼とガバナンスのほうに、お金の理由が移っていくんじゃないかな、と。ここを先に言葉にできたチームが、価格競争から一歩抜けられる気がします。

もうひとつ、2034年問題は MSP でこそ重いと思っています。

監視の一次対応って、AI が最初に食べる領域です。でも、インシデントを仕切れるシニアは、その一次対応の場数からしか育ちません。全部 AI に渡したら、10年後の”指揮官”がいなくなる。だからうちみたいなチームこそ、ジュニアに「AI 付きで、でも本物の判断を任せる」砂時計型を、意図して作らないといけないんだと思います。

そして、一番ワクワクしたのが「川岸を引く」話でした。

エージェントが本番をいじる時代になるほど、ガードレールを設計して、その順守を保証する仕事の価値が上がります。顧客の本番に責任を持つ MSP からすると、これは脅威というより新しい”商品”になりうるんじゃないか、と。いつか SLA も、「稼働率の保証」から「ガードレールを守れているか、あとから監査できるか」の保証に広がっていくのかもしれません。

これからどうするか

セッションは最後に「What To Do Monday Morning（月曜の朝からやること）」として、6つのアクションにまとめていました。経済性 → 人材 → 構造 → ガバナンス → 人 → パイプライン、をワークフローごとに順番に当てていく、と。

具体的には、こんな6ステップでした。

  1. 経済性：ワークフローを「Use / Compose / Build」のどれかに割り当てる。多くは Use か Compose。Build を選ぶなら、経済性を四半期ごとに見直す（答えは変わるから）
  2. 人材：3〜5人のシニアでポッドを組む。シニアだけで組めないなら、まだ Build の段階じゃない（Use か Compose に留める）
  3. 構造：Model A から抜け出す。「運用チームはエージェントの挙動をデバッグできるか？ それとも再起動してチケットを切るだけか」。後者なら、引き継ぎなし・運用分離なしの組み込みポッドを1つ作る
  4. ガバナンス：ポリシーをコードで（Policy as Code）、4つの問いをゲートウェイで強制する
  5. 人：AI が圧縮できないドメイン専門知識（顧客・規制・製品の機微）を持つシニアに投資する
  6. パイプライン：短期 ROI に負けず、ジュニアの採用・育成を止めない

私もまず、自分のチームの業務をひとつ選んで、「これは Use / Compose / Build のどれか」「うちは本当はどのモデル（A/B/C）か」を正直に棚卸ししてみようと思っています。あわせて、いまの自動化やランブックを「手順の管理」から「境界線（ガードレール）」の発想で、4つの問い（誰が・何を・期待どおりか・証明できるか）を当てて見直してみるつもりです。

同じように運用・監視の現場でチームを預かっている方、「Model A、うちのことだ…」と苦笑いした方がいたら、ぜひ感想を聞かせてほしいです。育成と短期 ROI のバランス、みなさんどう取っているんだろう、というのが今いちばん知りたいところです。

私もまだ、観て・考えて・揺さぶられている最中なので、一緒に考えていけたら嬉しいです。

まとめ

最後に、持ち帰りたいポイントをもう一度。

  • 脅威は AI ではなく「AI を使いこなす人」。ジュニア採用は急減（前年比73%減）、シニアの AI 人材は爆発（需要+1,587%）と真逆 ※いずれもセッションで示された数字
  • 従来型のIT運用（開発と運用の分離）はアンチパターン。少人数ポッド＋共通基盤へ
  • リーダーの仕事は「手順の管理」から「境界線（ガードレール）の設計」へ。Policy as Code と4つの問い
  • 検証税と脱スキル化に気をつけつつ、砂時計型で育成パイプラインを守る ＝「2034年の自分への仕送り」
  • 勝つのは最高の AI を持つ企業ではなく、AI の周りに最高のオペレーティングモデルを作った企業
  • （私見）運用の価値は「捌く量」から「判断・検証・ガバナンス」へ。MSP にはむしろ商機になりうる

エージェント時代のチーム作り、これからも自分の現場で試しながら、また書きます。

※本記事は、AWS Summit Sydney 2026 のセッション「A Leader’s Guide to Advanced Team Structures in an Agentic World」（登壇: Mr.Stephen Brozovich, Executive in Residence, AWS）を視聴して書いた記事です。