OpenAIがCodexを「エンジニア以外にも使えるツール」として押し出してきた。The Next Era of Knowledge Workというレポートを読んで、最初は「またビジネス向けのポジショントーク系か」と思った。でも読み進めると、research・data analysis・workflow automationをCodexで回す具体的なユースケースが出てきて、これは自分のコードにも影響があると感じた。
自分がCodexに初めて触れたのは2年くらい前で、当時はGitHub Copilotの裏側にいるやつ、という認識だった。コード補完は便利だけど、あくまで入力補助。そこからOpenAIはCodexをAPIとして開放して、chat completions経由でコード生成・解釈・変換ができるようになった。今回のレポートで言ってるのは、そこからさらに一歩進んで、workflow自体をCodexに任せるフェーズに入ったということだ。
data analysisのパートが特にえぐかった。CSVを渡して集計コードを自動生成するだけじゃなく、「そのデータが何を意味するか」まで解釈して文章に落とすところまでやってしまう。うちのチームで月次のKPIレポートを半手動でやってる人がいるんだけど、あれをCodexに投げ込んだらどうなるか、わりと真剣に考えた。
今個人開発で作ってるのは、Notionのデータを引っ張ってきてMarkdownに変換して静的サイトにデプロイするやつだ。pipeline自体はそんなに複雑じゃないけど、データ変換まわりで雑なif分岐がわりと積み重なっている。Codexを使ってここを整理するとしたら、たぶんこういう流れになる。
今は変換ロジックを自分で全部書いてるけど、Codexに「このjsonスキーマからMarkdownフロントマターを生成するPythonコードを書いて」と投げたほうが早い。しかもレポートに出てくるcontent creationの話を読むと、変換コードだけじゃなくて各ページのsummaryまで生成できるらしい。それは正直やりたい。
APIコストの観点でいうと、gpt-4oベースのCodexをフル活用するとinputトークンが1Mあたり$2.50、outputが$10.00だ。自分のpipelineで1回あたり2000〜3000トークンくらい使うとして、月100回実行しても$0.60前後。これは全然許容範囲で、むしろ自分が変換ロジック書く時間のほうがコスト高い。
レポートの主語はknowledge workerで、エンジニア限定の話ではない。research automationやcontent creationでCodexが使われるようになると、非エンジニアがコードを介さずにworkflowを組む場面が増えてくる。これは職種の話というより、APIをラップするレイヤーの設計の話として自分には刺さった。
うちのスタートアップでも、PMやデザイナーがノーコードツールを使ってデータを触りたいという話が出てきている。そのバックエンドをどう設計するか、Codex APIを直接叩くのかMCP経由にするのか、セキュリティのサンドボックスをどこに置くのかは、エンジニアが判断する必要がある。「誰でも使える」ツールになればなるほど、インフラ側の設計は繊細になる。
彼女に「最近何かハマってるの?」と聞かれて「Codexの使い方考えてた」と言ったら「仕事?遊び?」と返ってきた。その区別がだんだんなくなってきてる気がする。個人開発でとりあえず動かしてみて、職場で応用する、というサイクルが自分には一番学びが速い。
次の週末、Notion pipeline全部Codexに食わせてリファクタリングを試してみる予定だ。summary自動生成まで通しで動いたら、チームに持ち込む価値があるかどうか判断できる。
Codexが「補完ツール」から変わってきた感覚
自分がCodexに初めて触れたのは2年くらい前で、当時はGitHub Copilotの裏側にいるやつ、という認識だった。コード補完は便利だけど、あくまで入力補助。そこからOpenAIはCodexをAPIとして開放して、chat completions経由でコード生成・解釈・変換ができるようになった。今回のレポートで言ってるのは、そこからさらに一歩進んで、workflow自体をCodexに任せるフェーズに入ったということだ。
data analysisのパートが特にえぐかった。CSVを渡して集計コードを自動生成するだけじゃなく、「そのデータが何を意味するか」まで解釈して文章に落とすところまでやってしまう。うちのチームで月次のKPIレポートを半手動でやってる人がいるんだけど、あれをCodexに投げ込んだらどうなるか、わりと真剣に考えた。
自分のコードのどこを直すべきか
今個人開発で作ってるのは、Notionのデータを引っ張ってきてMarkdownに変換して静的サイトにデプロイするやつだ。pipeline自体はそんなに複雑じゃないけど、データ変換まわりで雑なif分岐がわりと積み重なっている。Codexを使ってここを整理するとしたら、たぶんこういう流れになる。
# Notion APIからデータ取得してjsonで保存
curl -X POST https://api.notion.com/v1/databases/{DB_ID}/query \
-H "Authorization: Bearer $NOTION_TOKEN" \
-H "Notion-Version: 2022-06-28" \
-o raw_data.json
# Codex APIにjsonを渡して変換コードを生成させる
python codex_transform.py --input raw_data.json --output posts/今は変換ロジックを自分で全部書いてるけど、Codexに「このjsonスキーマからMarkdownフロントマターを生成するPythonコードを書いて」と投げたほうが早い。しかもレポートに出てくるcontent creationの話を読むと、変換コードだけじゃなくて各ページのsummaryまで生成できるらしい。それは正直やりたい。
APIコストの観点でいうと、gpt-4oベースのCodexをフル活用するとinputトークンが1Mあたり$2.50、outputが$10.00だ。自分のpipelineで1回あたり2000〜3000トークンくらい使うとして、月100回実行しても$0.60前後。これは全然許容範囲で、むしろ自分が変換ロジック書く時間のほうがコスト高い。
「エンジニア以外向け」の文脈で気になること
レポートの主語はknowledge workerで、エンジニア限定の話ではない。research automationやcontent creationでCodexが使われるようになると、非エンジニアがコードを介さずにworkflowを組む場面が増えてくる。これは職種の話というより、APIをラップするレイヤーの設計の話として自分には刺さった。
うちのスタートアップでも、PMやデザイナーがノーコードツールを使ってデータを触りたいという話が出てきている。そのバックエンドをどう設計するか、Codex APIを直接叩くのかMCP経由にするのか、セキュリティのサンドボックスをどこに置くのかは、エンジニアが判断する必要がある。「誰でも使える」ツールになればなるほど、インフラ側の設計は繊細になる。
彼女に「最近何かハマってるの?」と聞かれて「Codexの使い方考えてた」と言ったら「仕事?遊び?」と返ってきた。その区別がだんだんなくなってきてる気がする。個人開発でとりあえず動かしてみて、職場で応用する、というサイクルが自分には一番学びが速い。
次の週末、Notion pipeline全部Codexに食わせてリファクタリングを試してみる予定だ。summary自動生成まで通しで動いたら、チームに持ち込む価値があるかどうか判断できる。