この記事は 弥生 Advent Calendar 2025 の21日目の記事です。
こんにちは、弥生の内山です。
エンジニアとして業務に携わってきましたが、最近プロダクトマネージャー（PdM）にチャレンジすることになり、日々試行錯誤しています。
この記事では、2025年12月にラスベガスで開催された AWS re:Invent 2025 に参加した私が、「エンジニア」と「PdM」の2つの視点で現地での体験と学びをまとめます。
結論から言うと、エンジニアはもちろん、プロダクトづくりに関わる人は全員行くべきです。その理由を、私の体験談からお伝えできればと思います。
今回の戦略：現地でしかできない体験に全振りする
re:Inventは数千のセッションが行われる巨大イベントで、後日配信されるセッションも多いです。今回はせっかくの初参加なので、「現地でしか体験できないこと」を最優先に以下を中心に参加しました。
- Chalk Talk: 講師と参加者が対話形式で議論するセッション（聞くだけでもOK）
- GameDay: チームや個人対抗で課題解決する実践型セッション
- Builders' Session / Workshop: 実際に手を動かし、講師に質問しながら学べるセッション
※上記以外のセッションでも講演後であれば講師に質問したり、参加者同士で交流することも気軽にできる雰囲気なので、気になるセッションがあれば、配信有無関係なく選ぶのも全然ありです。
Chalk Talkの会場例。今回はリアルタイム翻訳ができるアプリ（Notta）をフル活用しました。（これのおかげで英語に自信がなくても、なんとかなります）
エンジニアとしての学び：AIは誰でも使える。世界はその先のフェーズへ
エンジニア視点で最も衝撃を受けたのは、参加者で競い合う実践型セッション「GameDay」での出来事です。
GameDayで体験した「AIによる天国と地獄」
参加した「AI-powered troubleshooting: From chaos to Well-Architected」というセッションはAI（※）を活用してAWS環境のトラブルシューティングを行うものです。 ※ Amazon Q Developer CLI（今後はKiro CLIへ）
人間が手動で行う場合、ログやAWSのマネジメントコンソールを確認しながら原因特定と修復を行いますが、AIなら簡単です。
「このエラーを修正して」と言葉で指示するだけで、AIが瞬時に原因を特定し、AWS各種サービスの設定や修正までを一気に進めてくれます。
AIの圧倒的なパワーを借りた私は、約50人中、一時的に1位に躍り出ました。
「あれ、もしかして俺、勝ってしまう…？」
ラスベガスから栄光を持ち帰れるかもしれない。
そう思いながらニヤニヤしていました。
しかし、後半に地獄が待っていました。
複雑な課題に対し、AIの提案した修正を精査せずそのまま適用し続けた結果、環境が崩れ始め、復旧不能に近い状態に陥ったのです。
結果、順位は急降下し、上位入賞を逃してしまいました。
AIが作った小さな不整合が連鎖し、自分たちでは制御不能になる恐怖を覚えました。
「AIを使う」のは誰でもできる
この体験から得た教訓です。
AIを使うのは簡単です。誰でもすぐに試せるし、短期的な成果もすぐに出ます。 しかし、「AIを使い、継続的に、安全に、ユーザー価値として届け続けること」は難しい。
勝っている時ほど危ない。AIが速いからこそ、人間側の判断やガードレールが追いつかないと、一気に状況が崩れることを学びました。
どのようにAIを使ってユーザーに価値を届けるか
では、プロダクトとしてAIを使って価値を届けるにはどうすべきなのか。
これについては、Chalk Talk形式のセッション「Revolutionize shopping: Inside Amazon's AI-powered 'Buy for Me' experience (AMZ404)」で聞いたAmazon自身の取り組みが、ヒントになりました。
このセッションでは、Amazonが米国で試験的に導入している「Buy for Me（AmazonのAIエージェントが外部サイトの商品を購入代行してくれる機能）」の舞台裏が紹介されていました。
1. 進め方：完璧を目指さず「実験」から始める
まず驚かされたのは、Amazonほどの企業でも、この機能の開発においては泥臭いアプローチをとっていることでした。
「Buy for Me」が相手にするのは、Amazonが管理していない外部サイトです。購入フローはバラバラですし、サイト構造が急に変わることもあります。そんな不確実な環境で、最初から完璧なAIエージェントを作るのは不可能です。
彼らのマインドセットは「実験から始めよう」でした。
最初からすべてのサイトに対応する完璧なソリューションを作るのではなく、小さなスコープで素早く動くものを作り、そこから学びながら拡張していく。
「AIエージェントが本当にお客様の役に立つのか？」を検証するために、できるだけ早く外に出すことを技術的な完成度よりも優先していました。
2. アーキテクチャ：マルチエージェントという「解」
しかし、ただ早く出すだけでは、私がGameDayで経験したように「AIが環境を壊す（誤購入やエラー）」リスクがあります。
そこで彼らが採用していたのが、「マルチエージェントフレームワーク（MAF）」という設計思想でした。
これは、巨大なプロンプトで1つのAIにすべてをやり切らせるのではなく、役割ごとにエージェントを細かく分けて連携させるアーキテクチャです。
- Orchestrator Agent（司令塔）: 全体の進行を管理する。
- Variant Agent: 色やサイズなど、商品のバリエーション選択を処理する。
- Cart Agent: 商品をカートに追加する。
- PopUp Agent: 購入フローの途中で出現するポップアップ広告などを検知して閉じる。
このように役割を分割することで、それぞれの責任範囲が明確（疎結合）になり、エージェント単位でのテストや改善、そしてガードレールの設置が可能になります。
「あれ、これどっかで聞いた話だな…」
これを見たとき、かつて「モノリス」という課題に対して「マイクロサービス」という概念が生まれたときのような感覚を覚えました。 「新しいツール（AI）がすごい」という段階を超えて、複雑性にどう向き合い、どう制御するかが主戦場になっているのです。
「デモ」から「運用」へ
GameDayでの失敗と、このセッションが一本につながりました。
GameDayで私が失敗したのは、強力なAIにすべての制御を委ねてしまったからです。一方、Amazonは「不確実性」を前提に、プロセス（小さく実験）とアーキテクチャ（マルチエージェント）の両輪でリスクをコントロールしていました。
Amazonの「実験から始める」という言葉は、無策に作ることではありません。
ただ動くものを作る「実験」から、制御可能なアーキテクチャを模索する「実験」へ。その意識の転換が必要だと痛感しました。
こうした体験を受けて、その後の現地スケジュールも変えました。「Amazon Bedrock AgentCore」をハンズオンで触れる Workshop セッションを追加し、関連書籍も購入しました。
re:Inventは単に“聞いて終わり”ではなく、現地で行動が変わり始めるのが面白いところだと思います。
PdMとしての学び：「MVP」ではなく「MLP」という考え方
PdM視点での最大の収穫は、AmazonのDevOps文化を学ぶ「Chalk Talk」形式のセッション「Apply Amazon's DevOps culture to your team(DVT311-R)」での出来事です。
講師にぶつけた「HOW」と「WHAT」の悩み
セッション自体は「どのように早くリリースする仕組みと文化を作るか（HOW）」の話で、それ自体も有益でした。
ただ、最大の収穫はセッション終了後に講師を待って、以下の質問をしたときのことでした。
「スピードも大事だが、UX（ユーザー体験）も大事。Amazonでは『何をどこまで作るか（WHAT）』のバランスをどう決めているのか？」
講師から返ってきた答えには、私にとって初めて聞く言葉がありました。
「We aim for the MLP - Minimum Lovable Product.」
「愛される最小限」を目指す
Minimum Lovable Product（MLP）。
単に「動けばいい（Viable）」ではなく、お客様が使い始めて「これいいね（Lovable）」と思ってくれる最小限の形を目指す。
参考：MLP(Minimum Lovable Product)とは｜Goodpatch Blog
Amazonの現場のエンジニアの口から、当たり前の基準としてこの言葉が出てきたことにハッとさせられました。
近い言葉として「MVP（Minimum Viable Product：実用最小限の製品）」は認識していましたが、「最低限」という言葉をよりユーザーの感情に寄り添って定義し直していると感じました。
こういった細部へのこだわりが、プロダクトを通してユーザーに伝わり、競合との差別化につながる価値になっているのだと腹落ちしました。
また、「プロダクトでやりたいことが複数あって定量的に決め切れないとき、どのように決めるか？」という質問への回答は、たった一言だけでした。
「 Leadership. 」
この一言には、強く背中を押された気がしました。知識として知っていることと、現地の熱量の中で「お前の役割はこれだ」と言われることには、雲泥の差があります。
MLPという考え方も、それを実現するリーダーシップも、いずれも一朝一夕で身につくものではありませんし、一つの答えがあるわけではないので、自分なりのスタイルを見つけていく必要があります。
今このタイミングで、こうした考え方に出会えたことは、非常に大きな経験になりました。
セッションの外にある価値：国境を超えた「熱量とつながり」
こうしたセッションでの学びも大きいですが、現地に来たからこそ得られる体験はそれだけではありません。
re:Inventの価値の半分は、そこにいる「人」です。
今回は「世界中のエンジニアと交流する」という裏ミッションも掲げていましたが、結果として多くの出会いがありました。
「re:Inventは教会のようなものさ」
ランチで相席になったインド系アメリカ人のエンジニアが言った内容が印象的でした。
「ここは教会みたいなもの。毎年ここに来て、同じ志を持つ仲間と会うんだ」
また、中国系アメリカ人のエンジニアやノルウェー在住インド人の方とは、技術の話だけでなく「娘がいる」という共通点で意気投合し、家族の話で盛り上がりました。今度日本に来るとのことで、連絡先も交換しました。
re:Inventには国境も会社も関係なく、ただ「技術が好きで、ものづくりを楽しんでいる仲間」がいるだけでした。
出会った人々と。（掲載の承諾を取り忘れた方にはモザイクをかけています）
日本人同士の不思議な連帯感
ラスベガスという異国の地で出会う日本人への親近感は、とても高くなります。
会社や立場もばらばらですが、GameDayで同じ課題に頭を抱えたり、交流イベントで会話してみたり、会社を超えた交流が自然に行われます。
こうした「越境体験」をすると、日本に帰ってからも「もっと外部イベントに出てみよう」「外の世界は思ったより近い」と感じられるようになります。
このマインドセットの変化だけでも、来た価値があります。
re:Inventという「巨大プロダクト」の完成度
最後に、PdM視点でイベントそのものの「完成度」にも感動しました。
- 移動のUX: 数万人をスムーズに運ぶシャトルバス。バス内でもクイズ大会があり、移動中も退屈しない。
- ストレスフリー: 会場間の移動は迷いやすいが、至る所に案内係やアプリのガイド機能があり、迷うストレスが小さい。
- 街全体が会場: 道路を規制して行う 5K Race や、街中をジャックする re:Invent の広告が展開されている。
- 飲食: 会場の至る所で食事やコーラ、コーヒー、バナナなどが提供され、飲食には困らない。
- ゲーミフィケーション: アクティビティに参加すると記念品（SWAG）がもらえる仕組み。
- re:Play: フェスのような大規模ライブパーティ。今年は BECK が登場し、食べ放題・飲み放題だった。
カンファレンスパス（入場券）は$2,099（約30万円）と安くはありません。
ただ、アメリカの物価が高い中で、5日間を通してこのUX（ユーザー体験）を得られることを考えると、納得感がありました。
Amazonという企業は、AWSというサービスだけでなく、リアルイベントにおいても「徹底的にユーザー体験を考え抜いている」。その姿勢を強く感じました。
おわりに
エンジニアとしては「AI活用のアーキテクチャに対する健全な焦り」を持ち帰り、PdMとしては「MLP（愛されるプロダクト）への視座」を持ち帰ることができました。
その他ここでは伝えきれない学びが盛りだくさんで、re:Inventに行く前と後では、エンジニアとPdM双方の領域で解像度が明らかに変わったと感じています。
ツールや技術はオンラインでも学べますが、「世界がどの方向へ、どのくらいの熱量で動いているか」という肌感覚は、現地に行かないと分かりません。
私自身はエンジニア＆PdMとしての体験でしたが、参加できるセッションやイベントは膨大で、選びきれないほどあります。
re:Inventで出会った人々は社長、マネージャー、営業など様々な職種の方が集まっていたので、プロダクトづくりに関わる人であれば誰にとっても学びがあると思います。
職種を問わず、ここにはそれぞれの「世界基準」があります。
だから、「全員行くべき。」
エンジニアも、PdMも、その他職種の方も、ぜひラスベガスへ行きましょう。
そこには、コストや心理的ハードル以上の価値が確実にあります。
一緒に行ったメンバーと。
www.yayoi-kk.co.jp
弥生のエンジニアに関するnote記事もご覧ください。
note.yayoi-kk.co.jp
