# FigmaのPMは毎日どうAIを使っているか｜Ezra Mechaber（FigmaのPM）

- 番組: [How I AI](https://ai-curator.jp/podcasts/shows/cmv40atz1000f5j0zm69lxx8n)（Claire Vo）
- 元のタイトル: How Figma’s PMs actually use AI every day | Ezra Mechaber (PM, Figma)
- 配信日: 2026年11月2日
- 長さ: 42分
- 要約作成日: 2026年11月2日
- トピック: [#PM OS](https://ai-curator.jp/topics/PM%20OS) [#Claude Code](https://ai-curator.jp/topics/Claude%20Code) [#Codex](https://ai-curator.jp/topics/Codex) [#AIエージェント](https://ai-curator.jp/topics/AI%E3%82%A8%E3%83%BC%E3%82%B8%E3%82%A7%E3%83%B3%E3%83%88) [#実験自動化](https://ai-curator.jp/topics/%E5%AE%9F%E9%A8%93%E8%87%AA%E5%8B%95%E5%8C%96) [#RAG](https://ai-curator.jp/topics/RAG)
- URL: https://ai-curator.jp/podcasts/cmvza8buu00005t119n5kaety

## 要約

FigmaのグロースPMであるEzra Mechaberが、Claire Voのインタビューで、社内PM向けの共有リポジトリ「PM OS」（31スキル）を紹介した回。Slackを整理する「what's up」スキル、Codexによるバグバッシュ、実験を自動で回す「AutoXP」、小型高速モデルJevを使ったリアルタイム執筆支援を実演している。最後に、AIに苛立ったときの向き合い方も語られる。

## ポイント

- PM OSは製品ではなく、agent.md、スキル、起動時フック、フォルダ構成だけの基本的なリポジトリ。親リポジトリと各PM専用のサブリポジトリの二層構造で、60〜70人のPMの同期を保っている。
- 最初は3人のPMがPRを大量に出し、スキルが乱立する状態から絞り込んだ。春にはFigmaの全PMが参加するオフサイトで試用し、批評し合った。モデルの進化に合わせて不要なスキルは削っている。
- 「what's up」スキルは1日6回ほど実行し、Slackやプロジェクトから返信待ちや未決事項を拾う。ほかに組織図から担当者を探すスキル、成果物を公開するbuild artifact、コーチング、FigJam生成などがある。
- Codexでのバグバッシュでは、テスト手順を書いたFigJamを渡して実行させる。絵文字を1000個入力すると壊れる問題や、チーム名の冠詞（A／An）の不具合など、人が見落とす細かな点を拾った。
- AutoXPはCursor Automationsで動き、データサイエンス、UXライティング、エンジニアのエージェントを連携させる。人間が確認するのは実験の開始前の1回だけで、初回の実験で大きな成果が出たと本人は述べている。
- Jevを使った執筆支援は、入力が止まるたびに空欄（TK）や根拠の薄い主張を検出し、ライブラリのインタビューから裏付けを引く。AIへの苛立ちは自分の指示やコンテキストの汚れが原因のことが多い、という見方も示した。

## 章立て

- [02:11] **PM OS誕生の背景** — 社内でエンジニア以外がAIをほとんど使っていないと気づいたEzraが、自分のClaude Code環境を共有リポジトリに発展させた経緯を語る。
- [06:22] **PM OSのデモとスキル群** — チーフオブスタッフ設定、担当者検索、Slackを整理する「what's up」スキルを紹介する。
- [10:28] **リポジトリ構造と作り方** — agent.md、フック、サブリポジトリの二層構造と、スキルを試して絞り込んだ過程を説明する。
- [13:40] **その他のスキルとターミナルからの脱却** — build artifact、FigJam MCP、コーチングのスキルを紹介し、ローカルWebフロントエンドへ移行した経緯を述べる。
- [19:30] **Codexでのバグバッシュ** — FigJamの手順書を使い、Codexにブラウザ操作でテストさせる方法と、見つかった不具合の例。
- [22:10] **AutoXP：自動グロースPM** — Slack起点で複数エージェントが実験を立案・実装・分析する仕組みと、人間の確認が1回で済む点を説明する。
- [26:58] **Jevでリアルタイム執筆支援** — 入力が止まるたびに空欄や主張を検出し、ライブラリから根拠を引くプロトタイプを実演する。
- [33:40] **ライトニングラウンド** — パーソナルエージェントのInstinctやdots、AIに苛立ったときの接し方を語る。

## 解説記事

FigmaのグロースPM、Ezra Mechaberが、ホストのClaire Voに社内PM向けの仕組み「PM OS」を紹介した回である。31のスキルを束ねた共有リポジトリを軸に、バグバッシュ、実験の自動化、リアルタイム執筆支援まで、PMがAIで実務を進める具体例が語られた。

#### 「適切な場所で怠ける」ために作ったPM OS

Ezraは入社当初、エンジニア以外で実務にAIを使う人がほぼいないことに驚いたという。そこで自分の生産性を上げるため、Claude Codeの端末環境で自動化を始めた。当時のCPOからは、全PMをAIに慣れさせるには何が必要かという課題が出ていた。同僚のPM2人と、個人の環境を再利用できる形にしたのがPM OSである。

狙いは、PMが苦手なことや手が回らない仕事を「最低限許容できる水準」まで引き上げることだ。サポートチームへの共有漏れを防ぐ、議事録を十分な品質で残す、といった例が挙がった。Ezraはこれを、全体の底上げ（フロアを上げる）と表現している。

#### 製品ではなく、ただのリポジトリ

PM OSは専用のアプリではなく、基本的なリポジトリである。agent.mdで振る舞いを定義し、スキルが発動条件と処理を記述する。起動時には新バージョンの有無を確認するフックが動き、60〜70人のPMがおおむね同じ状態を保てる。

構成は二層になっている。全員がダウンロードする親リポジトリと、各自のワークスペースであるサブリポジトリだ。書き戻したい内容は自分専用の側に保存できる。当時はUIがなく、GitHubを触ったことのないPMにも使わせる工夫が必要だったという。

作り方も特徴的だ。3人でPRを大量に出してスキルが乱立した後、絞り込んだ。春には全PMのオフサイトで実際に使い、批評してもらった。利用状況の計測は、監視されていると感じさせたくないことと時間の都合から入れていない。モデルが賢くなるにつれ、不要になったスキルを削っているとも述べている。

#### 日常で使うスキルの例

中心の一つが「what's up」で、1日に6回ほど実行する。重要なSlackチャンネルのスレッドを読み、返信すべき相手や未決の判断をまとめる。実行中の実験を一覧する版もある。ほかに、約2,000人の組織でコードオーナーや関係者を探すスキルがあり、ドキュメント作成時にレビュー担当を自動で追加する。

build artifactはHTMLの成果物を社内ホスティングで公開するスキル、FigJam MCPを使ったワークショップテンプレート生成もある。コーチングのスキルは、キャリアラダーやフィードバックを踏まえて助言する。Claireは、実務的なものから対人、生成系までそろった構成だと評した。

なお、端末での利用は本来の終着点ではないとEzraは考えている。文章を多く書くPMには等幅フォントが読みにくいため、ローカルで動くWebフロントエンドを作り、モバイルでも動くようにした。現在は自身はほぼCodexに移っている。

#### Codexによるバグバッシュと自動実験AutoXP

バグバッシュでは、テスト用アカウント、辿る経路、見るべき点を書いたFigJamをCodexに渡し、ブラウザ操作で実行させる。結果はFigJamに書き戻される。Ezraによると、1000個の絵文字を入力すると壊れる問題や、チーム名が「A」で始まると冠詞を「An」にすべき表示の不具合が見つかった。自分では気づけなかった細部をAIが拾った例だ。

AutoXPは、未使用のトラフィックを無駄にしたくないというグロースPMの発想から生まれた。Cursor Automationsで3つの自動化がSlackをきっかけに動き、データサイエンスのエージェントが離脱やファネルを分析し、UXライティングのエージェントが文言案を出し、エンジニアのエージェントがPRを作る。人間が見るのは、データ分析、仮説、文言、コードをまとめて確認する開始前の1回だけで、終了後は分析がWebhookで自動起動する。初回の実験で大きな成果が出たといい、現在は5本が並行して動いている。ただしEzra自身は、理論上は優れているが実際にはほぼ到達という段階だと認めている。

#### Jevによるリアルタイム執筆支援

Jevは、複雑な問いに対して素早く安価に数値などを返す小型モデルとして紹介された。Ezraは、Figma内のエージェントが大型モデルの遅延で同僚のように感じられない点を挙げ、Jevの速さに可能性を見ている。

試作では、入力が止まるたびにJevが文章をチェックする。TKや空欄、根拠が必要な主張を見つけ、ライブラリのインタビューから引用を引いて裏付ける。単なるパターン検出に加え、文章と関連する別の箇所を結びつけられる点に、検索や文書取得（RAG）を想定した設計の強みがあると述べている。

#### AIに苛立ったとき

ライトニングラウンドでは、メッセージで動くInstinctや、dotsといったパーソナルエージェントの話が出た。AIに声を荒らげるかという質問に、Ezraは「友人のように接する」と答えた。苛立つ原因は多くの場合、自分の指示やコンテキストの汚れにあり、会話が回復不能になったら新しく始めるのが良いという見方だ。Codexで、ローカルからリモートに移したセッションが権限設定を引き継ぎ、承認を何度も求められる不具合にも触れた。

#### まとめ

日本の読者にとって注目点は、高度なツールを作らなくても、リポジトリとスキル、フックという簡素な構成で数十人規模のPMを揃えられる点だ。底上げを狙い、モデルの進化に合わせてスキルを削る運用は参考になる。AutoXPのように人間の確認点を1回に絞る設計は、実験運用の考え方として示唆に富む。一方でEzra自身も、実用面ではまだ途上と述べている。

> この要約・解説記事は、元の音声の文字起こしをもとに AI（Claude）が日本語で作成したものです。出典: How I AI「How Figma’s PMs actually use AI every day | Ezra Mechaber (PM, Figma)」