Behind the Craft
OpenAI 流 Codex 活用術 — 「AI PM」の実態はこうなっている
要点
- OpenAI Codex チームの PM・Rohan Varma は Slack / Notion / Linear / Gmail / Drive を Codex に接続し、複数ツールをまたいだコンテキスト収集を自動化している
- 「プロジェクトに急遽アサインされた」状況でも、Codex に Slack 履歴・ドキュメント・メール・Linear チケットを一括収集させることでキャッチアップ時間を大幅短縮できる
- PRD（企画書）を「生きたサイト」に置き換える——Codex でデモ・プロトタイプを先に作り、ドキュメント起点のプランニングを逆転させる手法を実演
- Slack のリプライをトリガーに Codex 自動化を起動したり、スレッドを再利用可能な「スキル」に変換する使い方で、定型作業をゼロコストに近づける
- Varma の結論は「合理的だと思う野心の10倍を目指せ」——AI によって PM の時間の使い方そのものが変わると主張
編集部の考察
Varma が実演した最も具体的な手法は「Codex でデモを先に作り、PRD の代わりとして使う」順序逆転だ。従来の承認フローは「仕様書→レビュー→承認→開発着手」という文書アーティファクトを前提に設計されている。動くプロトタイプが先に存在する世界では、この前提が静かに崩れる——「承認すべき対象が文書からデモに変わっている」のに、フロー自体は変わっていないという状態が起きやすい。
自社に置き換えると、問うべき問いは3つある。（1）デモが先に存在するとき、誰がいつ承認権を持つか——文書レビュアーとデモレビュアーを同じ人・同じプロセスで回せるか。（2）PM や担当者が Codex でプロトタイプを高速生成できる環境では、デザイナーや開発者の「初期関与タイミング」が後ろにずれるリスクがあり、手戻りの発生点が変わる。（3）デモが承認の起点になると、早い段階で方向性が固まりやすく、後工程での要件変更が却って重くなる可能性がある。
経営として決めるべき一点は、「デモ承認を正式なゲートとして制度化するか、それとも文書フローの補足扱いに留めるか」だ。曖昧なまま運用すると、現場は最速でデモを作って既成事実化しようとし、ガバナンスが形骸化する。
原文より
“Rohan has more time now to spend meeting enterprise customers and teams. Since Codex can handle the manual PM work around information synthesis and follow-ups.”
本記事は原文ニュースレターの独自キュレーション・考察であり、翻訳ではありません。引用部分の著作権は原著者に帰属します。