Codex はただのコーディングエージェントからワークスペースへ向かっている

spinny:~/writing $ vim codex-role-plugins-sites-workflows.md

1~
2今回の Codex の発表でいちばん気になったのは、プラグインという言葉そのものではありません。Codex が、仕事が形になる場所になろうとしている点です。
3~
4OpenAI は 2026年6月2日に [Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/) を発表しました。目立つ新機能は役割別プラグイン、Sites、注釈です。ただ、本当に大事な問いはもっと素朴です。エージェントは、社内に散らばった文脈を、チームが見て、話し合って、直せるものにできるのか。
5~
6## 本当の変化
7~
8これまで Codex は説明しやすい存在でした。開発者がコードを直すのを助けるもの。今回の更新で、その説明は少し狭くなりました。新しいプラグインは analytics、sales、product design、creative production、public equity investing、investment banking も見ています。
9~
10つまり Codex はリポジトリだけを見るわけではありません。ダッシュボード、CRM のメモ、ドキュメント、スプレッドシート、デザイン brief、金融データを読み、そこから仕事の成果物を作ろうとします。
11~
12ここが面白いところです。多くのチームが欲しいのは、もう一つのチャット回答ではありません。みんなが開けるページ、ローンチルーム、レビュー用ボード、プランナー、小さな社内アプリ、ダッシュボードです。
13~
14## Sites は注目したい
15~
16Sites はかなり実用的に見えます。チャットの回答はスクロールの中に消えます。でも site には URL があります。共有できるし、コメントできるし、数日後に戻ってきて、変わった部分だけ Codex に直してもらえます。
17~
18プロダクトローンチ、顧客レビュー、週次の事業レビュー、投資家向けメモ、社内ツールには合いそうです。最初の版が完璧だからではありません。完璧ではないはずです。価値は、チームが同じものを見られることです。
19~
20## 注釈はフィードバックを小さくする
21~
22注釈も地味ですが重要です。もっと分かりやすくして、とだけ言うと、エージェントは触りすぎることがあります。グラフ、段落、セクションを指して依頼すれば、作業範囲が小さくなります。
23~
24実際の編集はそういうものです。全部を書き直したい場面は少ない。多くの場合、この文を少し鋭く、このグラフを少し見やすく、このスライドを軽く、この表を並べ替えたいだけです。
25~
26## 私ならこう試す
27~
28初日にすべてのツールをつなげることはしません。退屈だけれど境界が明確な workflow を選びます。たとえば週次の business review。少数の指標、いくつかのメモ、共有される出力、そして外へ出す前の人間レビューです。
29~
30確認することは多くありません。
31~
32- Codex が読んでよいソースを決める;
33- 書いてよい場所を決める;
34- 重要な主張にはソースへのリンクを残す;
35- 生成物ごとに owner を置く;
36- 使わなくなったものはアーカイブするか削除する。
37~
38怖いのは最初の草稿が悪いことではありません。チームは悪い草稿には慣れています。怖いのは、生成された site が増え続け、owner もソースもなく、どれが正しい版か分からなくなることです。
39~
40## 私の見方
41~
42この発表は、エージェントがデモの段階を出つつあるサインです。有用なエージェントは派手なものではなく、チームのリズムに入れるものです。文脈を集め、草稿を作り、根拠を残し、細かい feedback を受け取り、境界を守るものです。
43~
44開発者にとって、これは engineering の価値を下げません。むしろ上げます。権限、default、review point、完了の定義は、まだ誰かが設計しなければなりません。
45~
46## 参考
47~
48- [OpenAI: Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/)
49~

NORMAL · codex-role-plugins-sites-workflows.md [readonly]49 lines · :q to close

2今回の Codex の発表でいちばん気になったのは、プラグインという言葉そのものではありません。Codex が、仕事が形になる場所になろうとしている点です。

4OpenAI は 2026年6月2日に [Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/) を発表しました。目立つ新機能は役割別プラグイン、Sites、注釈です。ただ、本当に大事な問いはもっと素朴です。エージェントは、社内に散らばった文脈を、チームが見て、話し合って、直せるものにできるのか。

6## 本当の変化

8これまで Codex は説明しやすい存在でした。開発者がコードを直すのを助けるもの。今回の更新で、その説明は少し狭くなりました。新しいプラグインは analytics、sales、product design、creative production、public equity investing、investment banking も見ています。

10つまり Codex はリポジトリだけを見るわけではありません。ダッシュボード、CRM のメモ、ドキュメント、スプレッドシート、デザイン brief、金融データを読み、そこから仕事の成果物を作ろうとします。

11~

12ここが面白いところです。多くのチームが欲しいのは、もう一つのチャット回答ではありません。みんなが開けるページ、ローンチルーム、レビュー用ボード、プランナー、小さな社内アプリ、ダッシュボードです。

13~

14## Sites は注目したい

15~

16Sites はかなり実用的に見えます。チャットの回答はスクロールの中に消えます。でも site には URL があります。共有できるし、コメントできるし、数日後に戻ってきて、変わった部分だけ Codex に直してもらえます。

17~

18プロダクトローンチ、顧客レビュー、週次の事業レビュー、投資家向けメモ、社内ツールには合いそうです。最初の版が完璧だからではありません。完璧ではないはずです。価値は、チームが同じものを見られることです。

19~

20## 注釈はフィードバックを小さくする

21~

22注釈も地味ですが重要です。もっと分かりやすくして、とだけ言うと、エージェントは触りすぎることがあります。グラフ、段落、セクションを指して依頼すれば、作業範囲が小さくなります。

23~

24実際の編集はそういうものです。全部を書き直したい場面は少ない。多くの場合、この文を少し鋭く、このグラフを少し見やすく、このスライドを軽く、この表を並べ替えたいだけです。

25~

26## 私ならこう試す

27~

28初日にすべてのツールをつなげることはしません。退屈だけれど境界が明確な workflow を選びます。たとえば週次の business review。少数の指標、いくつかのメモ、共有される出力、そして外へ出す前の人間レビューです。

29~

30確認することは多くありません。

31~

32- Codex が読んでよいソースを決める;

33- 書いてよい場所を決める;

34- 重要な主張にはソースへのリンクを残す;

35- 生成物ごとに owner を置く;

36- 使わなくなったものはアーカイブするか削除する。

37~

38怖いのは最初の草稿が悪いことではありません。チームは悪い草稿には慣れています。怖いのは、生成された site が増え続け、owner もソースもなく、どれが正しい版か分からなくなることです。

39~

40## 私の見方

41~

42この発表は、エージェントがデモの段階を出つつあるサインです。有用なエージェントは派手なものではなく、チームのリズムに入れるものです。文脈を集め、草稿を作り、根拠を残し、細かい feedback を受け取り、境界を守るものです。

43~

44開発者にとって、これは engineering の価値を下げません。むしろ上げます。権限、default、review point、完了の定義は、まだ誰かが設計しなければなりません。

45~

46## 参考

47~

48- [OpenAI: Codex for every role, tool, and workflow](https://openai.com/index/codex-for-every-role-tool-workflow/)

49~