定員超えのキャンセル待ち——PM×AIの関心の高さ

A graph showing high demand for the event.

「AI駆動開発勉強会で、PM/PdMスペシャルをやります」

…正直、最初に聞いたときは「ニッチすぎて人集まるのかな」と、いらぬ心配をしていました。

蓋を開けてみると、定員240名に対して応募255名、キャンセル待ち発生。

いや、すごい。PM×AIへの関心、想像以上でした。

AI駆動開発勉強会 第7回 AI駆動PM/PdMスペシャル

私自身、普段からAI駆動開発を実践しており、PMとしてプロジェクトを推進する立場なので、このテーマは気になって仕方なかったんです。実際に参加してみて、予想をはるかに超える収穫がありました。

この記事では、勉強会で得られた気づきと各登壇者の内容をまとめてお伝えします。

• AIをPM業務にどう活かすか
• 「アンビエントエージェント」と「Human in the Loop」の共存
• インプットの精度がアウトプットを決めるという共通認識
• 今までにない発想——コードベースから始める上流工程

一番刺さったのは「Human in the Loop」

Concept of Human-in-the-Loop synergy.

今回一番印象に思ったのは「アンビエントエージェント」による業務効率化の爆上がりを目の当たりにしつつ「Human in the Loop」の重要性を皆さんが意識しているところ

登壇された方々は豪華で、内容も非常に濃いものでした。

もちろんPM業務をAIで効率化する話は勉強になりましたが、私が一番興味を持ったのは別のところです。

AIを完全自動化してバックグラウンドで動かすアンビエントエージェントの実践例が紹介される一方で、登壇者の皆さんが共通して強調していたのがHuman in the Loop——つまり、判断やコミュニケーションなど「人間にしかできないこと」をきちんとやるという考え方でした。

これ、ものすごく共感しました。

AIがどれだけ進化しても、最終判断やステークホルダーとの対話は人間の仕事ですよね。「全部AIに任せよう」ではなく、「AIに任せるからこそ、人間がやるべきことに集中しよう」という姿勢。この両輪が回ってこそ、本当のAI駆動PMなんだと感じました。

AIは仕事を奪うのか？学習の道具として使うという発想

Visualizing AI as a staircase for learning.

AIは仕事を奪う？——学習の道具として使うという発想

勉強会の中で特に腹落ちしたのが、AIのアウトプットを学習の材料にするという考え方です。

私も様々な企業や自治体の方から「AIが若手の仕事を奪うのでは？」という相談を受けることがあります。

でも、今回の勉強会で語られていた視点はまったく逆でした。

AIが自動で出力した行動や成果物を教材として活用し、そこからさらに踏み込んで学んでいく。単なる自動化ではなく、全人類のラーニングサポートとしてAIを位置づける。

「仕事を奪われる」のではなく、「学びの質が上がる」。この視点の転換は、AIに対する漠然とした不安を持つ方にこそ届けたい内容でした。

インプットの精度がすべてを決める

Comparing different AI integration approaches.

インプットの精度がすべてを決める

「AIのアウトプットの精度を上げるにはインプットが重要」——これは登壇者の皆さんに共通した認識だったと思います。

ただ、そのアプローチが人によって全然違っていて、ここが面白かったんです。

アプローチ	提唱者	内容
土台→型→AIに食わせる	湯川さん	まず丁寧にエンジニアリングの土台を作り、型化してからAIを増幅装置として適用
コードから始める	熊井さん	プロジェクト開始時（0日目）に基盤コードとCI/CDをデプロイし、AIにリバースして書かせる

率直に言って、熊井さんのアプローチには衝撃を受けました。ドキュメントから始めるのではなく、動くものをベースにAIでリバースエンジニアリングしてドキュメントを作るという発想…今までの私にはなかった視点です。

私自身、AIツールの活用は要件定義やステークホルダーマネジメント、リスク管理を固めるくらいに留まっていました。でも今回の話を聞いて、PM作業にアンビエントエージェントの仕組みを構築し、インプットの精度を上げてアウトプットの精度も上げる——そんな実践を早速始めたいと思っています。

1. おかもとさん——AI駆動PMの理想像と現実

Levels of AI integration for PMs.

1. おかもとさん——AI駆動PMの理想像と現実

PM領域でのAI活用を「レベル」で段階的に定義し、現時点で実践可能なアプローチを紹介されていました。

• AI駆動PMの段階的レベル: 最終的には PM経験がなくてもプロジェクトを成功させられる世界を目指しているそうです。ただ、現段階（レベル1）では「PMができる人がAIで能力を拡張する」フェーズ。例えば1人で10プロジェクトを管理するような世界観ですね
• コンテキストエンジニアリング: Slack・Notion等のあらゆる情報をAIに処理させて、人間はメール返信案やアジェンダなどの「生成された案」を確認して最終アクションを行う。クライアントへの連絡を勝手にやられたら困りますよね。だからこそ、この形が今の現実的な落としどころだと感じました
• 自社実践: Slackボット型の社内ツールを構築。複数LLM（GPT・Claude・Gemini）で要件定義をチェックし、全LLMで95点以上取るまで進めないシステムを運用しているそうです。これは面白い仕組みですよね
• ツールの使い分け: エンジニアにはCursor、非エンジニアやチーム共有にはNotion AIが導入しやすい。ただ、Cursorは非エンジニアにはIDEの壁があるという指摘には納得です。さらに進むとSlackボットやアンビエントエージェントが重要になってくるとのこと
• アンビエントエージェントの展望: チャットではなくバックグラウンドで常時稼働するイベント駆動型AI。a16zも「AIアプリの主要UIだったテキストボックスが消滅する」と予測しているそうです

2. さとけいさん ——PMの仕事、どこまでAIに渡せる？

AI as the nervous system of an organization.

2. さとけいさん ——PM의 仕事、どこまでAIに渡せる？

1人で4法人・16プロジェクトを管理するために構築したAI駆動マネジメントシステム「BRAIN BASE」の実践報告でした。正直、ここまで作り込んでいるのかと驚きました。

• 組織の自律神経としてのAI: 会社組織を人体に例えていたのが面白かったです。脳（意思決定）と筋肉（実行）の間にある連絡・調整（自律神経）は、今まで人間が手作業でやっていた。ここをAIに担わせることで、組織の循環が止まらなくなるという発想です
• 「Ship（Outcome）」の再定義: AIでアウトプット自体が容易になる時代、単なる成果物ではなく市場に出荷して価値を出す「Ship」を重視すべきという指摘。「新人がAI使ってこれできました、と言ってくるけど、それ本当に意味あるの？」という問いかけは鋭かったです
• 議事録→タスク→AI実行の自動化パイプライン: Tactiq等で会議を文字起こし→Zapier経由でSlackに送信→AIボット「まなちゃん」が議事録・決定事項・タスクを構造化→NocoDB（月25ドルのオープンソースDB）で状態管理→Cloud Code / Codexと連携して実行。しかも正本情報をMCP経由で参照するため、固有名詞のブレもほぼなくなるそうです
• 12のアンビエントエージェント: 朝のブリーフィングを各メンバーにパーソナライズして送信、期限切れタスクのアラート、プロジェクトヘルスチェック…これが全部バックグラウンドで動いている。ここまでやっている事例はなかなか聞かないですよね
• 情報の正本管理: 「散在する情報はAIも人間も管理しきれない。どこか一つに正しい情報を置く」——これはAIの有無に関わらず、すべての組織に刺さる話だと思います

個人的には「まなちゃん」という名はギャルにしてほしくないと思いました。「のあちゃん」とか「りなちゃん」にしてほしいですどうでもよいですが（笑）

3. みやっちさん —— ペーパードライバーは自動運転車に乗るべきか

Accelerator and Brake metaphor for AI use.

3. みやっちさん ——　ペーパードライバーは自動運転車に乗るべきか

AIに任せて加速する「アクセル」と、あえて人間が介在する「ブレーキ」。この両面から考察されていて、非常にバランスの取れた発表でした。

• アクセル（完全委任）: 「AIPoコマンド」というシステムを開発・公開。ゴールだけ渡せばAIがNotion等から再帰的にコンテキストを収集し、サブゴールに3〜4レイヤーまで分解して仕様策定から実行まで行う。再帰的な処理のおかげで記憶が揮発せず、法的問題・経理的問題まで含めて抜け漏れなく仕様を考えてくれるそうです。人間が考えるより抜け漏れが少ないというのは、実に興味深い
• ブレーキ（Human-in-the-Loop）: 計画（Discovery）と実行（Delivery）をあえて2段階に分離。さらに、毎回タスクごとにAIにスキル（プロンプト）を生成させてから実行する。ペーパードライバーが全自動で突っ走ると、スコープクリープや非機能要件の見落としが確実に起きるからです。プロは加速全開でいいけど、経験が浅い人ほどこのブレーキが必須だと
• AIの出力を「写経」する: Human-in-the-Loopの過程で「こんな風に仕様を書くのか」と学べる。AIの出力をそのまま使うのではなく、自分で書き直すことで実スキルが向上する。これは「AI駆動学習」と呼べるんじゃないでしょうか。「速さ」ではなく「全人類のラーニングサポート」としてAIを捉え直す——この視点の転換が印象的でした

4. 文分さん　——　生成AIを活用したプロダクト企画の課題と改善

The 'Critic Agent' concept for better planning.

4. 文分さん　——　生成AIを活用したプロダクト企画の課題と改善

上流の上流、「プロダクト企画」でAIを使って企画の質を上げる「攻めのAI活用」についてでした。コスト削減のような「守り」ではなく、プロダクト価値を上げて売上・グロースにつなげる「攻め」にフォーカスしているのが新鮮でした。

• 生成AIの企画における限界: 例えば「ECサイトをアプリ化したい」という相談に対して、AIも経験の浅いPdMも「いいですね、こう作りましょう」と当たり障りない提案をしがち。「それ作って意味あるの？」「顧客が満足するポイントは？」をすっ飛ばしてしまうんですよね。しかも、AIも人間と同じく自分のコンテキスト内で着地させようとするため、なかなか否定してくれない
• 壁打ちサブエージェントの導入: 同じAIに情報を追加しても「予定調和」になるだけ（これは人間と同じですね）。そこで、別の視点を持つサブエージェントを作って批判的にフィードバックさせる。UXの視点が弱い企画にはUX観点から厳しく叩くサブエージェント、といった具合です
• Before/Afterが分かりやすい: 「二店舗の信頼を全国に届ける中古時計アプリ」という当たり障りない企画が、サブエージェントの壁打ち後には「店舗の信頼と専門性をデジタルで再現し、失敗したくないという不安を精度と体験の両方で下げるアプリ」に。確かに、後者の方が「聞いてみようかな」と思えますよね
• 企画の形式知化: 良い企画と当たり障りのない企画を比較させ、差分の観点を大量に抽出してサブエージェントに読み込ませる。優秀なPdMの視点を形式知化し、ジュニアメンバーでも高品質な企画を出せる仕組みへ。組織の底上げにつながる考え方だと思います

5. 流川さん——AI活用をスケールさせる丁寧なエンジニアリング

AI as an amplifier on a solid engineering foundation.

5. 流川さん——AI活用をスケールさせる丁寧なエンジニアリング

MonotaROでの商品データパイプライン刷新プロジェクトにおけるAI活用事例です。「AIは魔法の杖ではなく増幅装置」という一言が、この発表のすべてを言い表していると感じました。

• 効果的な3ステップ: ①ストーリーを描く（課題解決の青写真）→②土台を作る（丁寧なエンジニアリングとマネジメント）→③AIを適用する（増幅装置として機能させる）。この順番が重要だという指摘にはなるほどと思いました。いきなりAIを入れても効果は限定的ですよね
• プロセスの主従逆転: Before（人が判断してシステムが動く）→After（システムが判断して人が動く）。メールや電話で情報収集→担当者が判断→バケツリレーという旧来のプロセスから、システムが自動取込・プロセス制御し、不備時にシステムが担当者をアサインする形へ。さらに、業務改善の主導権を業務ユーザーに渡し、ITリソースをボトルネックにしないという構想も描かれていました
• 丁寧な土台設計: アーキテクチャ設計（業務部門の技術スタックを軸に）、複雑性のカプセル化（変則1処理1ファイルで機能追加可能に）、開発プロセスの型化、CI/CDの完全自動化…こうした土台があるからこそ、非エンジニアメンバーもAIサポートを受けて開発に参画できているそうです
• AI適用の成果: 開発生産性がピーク時に走り出しの約4倍。週119機能の開発を実現。GitHub ActionsにAIレビュー機能を組み込み、LLMによるコードレビューだけでなく開発要件や社内標準も参照したフィードバックを自動化。これは説得力のある数字ですよね
• 今後の構想: 業務分析AI→コンサルタントAI→プログラマーAIという複数の専門AIが協業し、施策立案から修正PRの自動作成まで完結。人間は提案された改善案をレビューして最終承認する——というサイクルを目指しているとのことでした

6. 熊井さん——0日導入からはじめるAI駆動PM

Comparison of traditional vs 0-day AI deployment.

6. 熊井さん——0日導入からはじめるAI駆動PM

開発プロセス全体の変革（全体最適）を目指し、最初からコードベースで進める手法の提案です。個人的に、この発表が一番衝撃的でした。

• 局所最適の罠: 要件定義だけ速くなっても、顧客レビューが大量に来て結局変わらない——TOC理論でいうところの「ボトルネックの移動」。AI駆動PMは単なる生産性向上ではなく、プロセス変革が必要だという前提がまず鋭い
• AI駆動開発1年の3つの気づき: ①生成されたものを判断できるアーキテクトの視点が必要、②高速化するほどレビュー等のプロセスがボトルネックに→プロセスの破壊が必要、③ツールだけではドーピング。「小学生がドーピングしても世界新記録は出せない」という例えが分かりやすかったです
• 0日導入の具体的手法: プロジェクト開始時（キックオフ当日）にAWSにデプロイしてCI/CDも整えた状態を作る。そこからリバースエンジニアリングしたドキュメントを顧客向けにカスタマイズして持参。動くシステムの画面を見せながら要件ヒアリング→差分更新→Claude Codeが実装。50人月規模のプロジェクトを1人で1ヶ月、実稼働8時間程度で進めているそうです
• レビューを減らす発想: アーキが決まっていればアーキのレビューは不要。技術スタックを統一・固定化すれば考えることが減り、ドメイン（顧客・事業領域）に全振りできる。なかなか大胆な考え方ですが、理にかなっている気がします
• PMの進化: 前だけ見ていればよかった PMが、技術的知見（CI/CD・テスト等）も求められる時代へ。自身が変革の最前線に立ち、組織・事業変革を推進する立場になるべきだと

7. 平さん——AI時代のPMに求められるマインドセット

Meaning and Connection as human roles.

7. 平さん——AI時代のPMに求められるマインドセット

最後の登壇は、ツールや手法ではなく「人間のマインドセット」の話。これがまた深かったんです。

• 「実力以上にはならない」という実感: AIでアウトプットは大量に生成されるようになったけれど、レビューする人間の負荷や文脈の抜け落ちは依然として課題。じゃあ、PMに問われる「実力」って何なのか？——ゴールが描けるか、そしてそれをもって判断を成立させられるか。この2つだと
• 編集力（Meaning）: ここでいう「編集」は原稿を書くことではなく、文脈（コンテキスト）をつないで意味を付与すること。プロジェクトやプロダクトの「何のためにやっているのか」を定義できる力こそが、これからの人間の役割だと. 編集工学の考え方がヒントになるそうです。DDDやOUI等の構造化アプローチも「編集的なフレーム」として親和性が高いとのこと
• 地力（Jiriki）の重要性: 実力を発揮するには土台となる「地力」（蓄積された経験・知識）が不可欠。作業や進捗管理はもうAIに任せられる時代。空いた時間をユーザーとの対話に充てるもよし、自身の強みを磨くもよし、プロジェクト実践を通じてパターンをつかむもよし。「急がば回れ」でPMとしての地力をつけていく——この考え方には強く共感しました

まとめ——今日から実践したいこと

Summary of key takeaways for immediate action.

まとめ——今日から実践したいこと

今回の勉強会を通じて、改めて感じたポイントを整理します。

• Human in the Loopは必須: AIがどれだけ進化しても、判断・コミュニケーション・意味づけは人間の仕事
• AIは学習の道具: 「仕事を奪われる」ではなく「学びの質が上がる」という視点の転換
• インプットの精度がすべて: 土台を作ってからAIに食わせる、コードベースから逆算する…アプローチは様々でも、共通しているのは「インプットへの投資」
• プロセスの破壊という発想: 局所最適ではなく、全体最適を目指す大胆な姿勢

正直なところ、私自身のAI活用はまだまだ「要件定義やリスク管理を固める」程度でした。

でも今回の話を聞いて、PM業務にアンビエントエージェントを組み込み、インプットの精度を上げてアウトプットの質も引き上げる——この循環を早速構築していきたいと思っています。

皆さんは、PM業務でどのようにAIを活用されていますか？

本日の勉強会を通じて、PM業務だけでなく他の業務でも活用できる知見がごっそり得られたので、今後の実践につなげていきたいと思えた勉強会でした。このような有意義な勉強会を開催していただいている運営の皆様には本当に感謝です。