Codex非エンジニア189倍、OpenAI公式データで読む使い方
OpenAI社内で法務・人事・サポートまでコードを書き始めた。非開発者のCodex利用が189倍に増えた公式データから、非エンジニアが今週から使える3ステップを読み解く。
この記事でわかること
- 本文に入る前に、まず押さえるべき結論
- 開発や実装の判断が、ここからどう変わるか
- 次に読むべき関連記事の入口
私は毎晩、Claude CodeかCursorを開いて自分の業務ツールを書いている。スプレッドシート連携やSlack通知の小さなスクリプトが中心だ。エンジニアとして食えなくなり、カスタマーサクセスに逃げた過去を持つ私にとって、コードを書く行為はずっと専門家だけのものだった。それがAIによって自分の手に戻ってきた瞬間、凄腕エンジニアが自分に宿ったような感覚を味わったのを覚えている。
2026年6月、OpenAIが社内調査「The Shift to Agentic AI: Evidence from Codex」を公開した。読んでみると、同じ感覚が自分だけの話ではなくなっていることに気づいた。OpenAI社内でコーディングエージェント「Codex」を使う人のうち、非開発者の利用が組織単位で189倍に増えたと報じられている。法務やカスタマーサポートまでコードを書き始めているという。
私の「復活」が、いつの間にか企業全体で起きる現象になっていた。今日はこの公式データを読み解きながら、非エンジニアがどこから手を付ければいいのかを整理したい。
非開発者189倍が示す、コードを書く人の定義が変わった証拠
OpenAIは2026年6月25日、自社ブログで社内のCodex利用実態を公開した。Codexとは、自然言語の指示からコードを書き実行までこなす、OpenAIのコーディングエージェントだ。もともとはエンジニア向けのツールとして始まった。
公開されたデータの中心は、非開発者によるCodex利用の伸び率だ。2025年8月を基準にすると、個人単位の非開発者利用は137倍、組織単位では189倍に増えたと報じられている。OpenAI社内に限れば12倍だという。エンジニアだけが使うツールという前提が、10ヶ月足らずで崩れた計算になる。
部門別の内訳を見ると、この崩れ方がより具体的にわかる。リサーチ部門は2025年11月から2026年6月にかけて利用が56倍に伸び、最大の伸び幅を記録したと報じられている。カスタマーサポートは32倍、エンジニアリング部門自体も27倍に伸びた。法務部門は他部門よりゆるやかな伸びだが、それでも13倍に達したという。
私が驚いたのは、伸び幅がエンジニアリング部門を上回る部門があった点だ。リサーチやカスタマーサポートは、コードを書く仕事だと思われてこなかった職種になる。そこがエンジニアリング部門の27倍を超える56倍という伸びを記録した。ツールを使う主役が、静かに入れ替わり始めている。
私は今もカスタマーサクセスの現場に片足を置いている。だからこそ、カスタマーサポートが32倍という数字は他人事に思えなかった。問い合わせの一次対応、返金判断のログ確認、過去チケットの横断検索。どれも「本来は自分で仕組み化したいが、開発チームに頼むほどでもない」と諦めていた作業ばかりだ。この数字は、そうした諦めが崩れ始めている現場が自分の周りにもあることを裏づけているように読めた。
さらにOpenAIは、法務・財務・採用の3部門が2026年4月ごろにCodexを最もよく使うAIツールへ切り替えたと報告した。チャット型のAIより、コードを実行できるエージェントの方が業務に合うと判断した部門が、社内で増え続けているそうだ。
この報告を読んで、私は自分がツールを選ぶときの基準を思い出した。チャット型のAIに「これをやって」と頼んでも、返ってくるのは手順の説明止まりのことが多い。実際に手を動かして結果まで出してくれるのは、エージェント型のツールならではの体験になる。私が業務ツールをClaude CodeやCursorで書くようになったのも、同じ理由からだった。指示を出すだけで実際にコードが動く体験は、一度味わうと後戻りしづらい。法務や採用の担当者が、チャット型からエージェント型へ乗り換えた理由も、この体験の差にあるのではないかと思う。
「30分超えタスク80.6%」が突きつける、コード＝専門職という前提の崩壊
利用回数の増加だけなら、単なる話題性で片づけられるかもしれない。OpenAIが公開したデータで私が一番引っかかったのは、依頼するタスクの重さの方だった。
2026年5月時点で、個人ユーザーの80.6%が、人間換算で30分を超える作業をCodexに少なくとも1回依頼していたと報じられている。70.2%は1時間超、25.6%にいたっては8時間超の作業を任せていたという。もはや「ちょっとしたコード片を書いてもらう」規模の話ではなくなっている。
8時間超という数字を見て、私は自分がツールを作っている時の感覚を思い出した。単発のスクリプトなら数十分で終わる。だが業務フロー全体を一つのツールに落とし込もうとすると、要件の詰めと修正だけで軽く半日を超える。25.6%の人が、この規模の作業をエージェントに任せている計算になる。
実際、私が最も時間をかけたツールは、カスタマーサクセス部門向けの週次レポート自動生成だった。複数のスプレッドシートからデータを集計し、異常値にフラグを立て、Slackに整形して投稿するところまでを一気通貫でやらせようとした。最初のプロトタイプができるまでに丸2日、実運用に耐える形に仕上げるまでにはさらに3日かかっている。時間換算すれば優に8時間を超える作業だ。OpenAIのデータで25.6%が任せているという「8時間超のタスク」は、決して特殊な例ではなく、業務フロー全体を任せようとすれば誰でも到達する規模だと実感している。
ここで見逃せないのは、任せている本人の多くがエンジニアではないという点だ。コードを書く行為そのものより、業務の一連の流れを言語化して渡す行為の方が、今のCodexにとって中心の仕事になっている。読み書きの主導権が、キーボードを打つ人からタスクを設計する人へ移った。
私自身、業務ツールを作るとき一番時間を使うのは「何をどう自動化するか」を決める段階だ。実際にコードが生成される時間はごく短い。OpenAI社内のデータは、この配分がエンジニアだけでなく企業全体で起き始めていることを示している。
法務・人事が最初に動いた理由は、業務の言語化力がエンジニア力を超えたから
なぜエンジニアリング部門ではなく、法務や人事、カスタマーサポートといった非技術部門が先に動いたのか。私はこの逆転現象こそ、今回のデータで一番面白い部分だと思っている。
エンジニアはもともとコードを書く手段を持っていた。Codexが登場しても、既存の開発フローに新しい道具が一つ加わるだけになる。一方、法務や人事は違う。彼らはずっと「やりたいことはあるが、実装する手段がない」立場に置かれてきた。契約書の一括チェック、応募者データの突合、問い合わせ対応の自動振り分け。アイデアは山ほどあっても、形にするには開発チームへの依頼と順番待ちが必要だった。
Codexのようなエージェントは、その順番待ちを消した。自分の業務を言葉で説明できれば、実装は自分でできるようになる。ここで効いてくるのは、コードを書く技術力ではなく、自分の業務を型として言語化する力だ。
私はカスタマーサクセス出身で、エンジニアとしての技術力ではプロに敵わないと早々に諦めた人間になる。それでも今、自分の業務ツールを作れているのは、ユーザーの困りごとを言葉で整理する訓練を何年も積んできたからだと思っている。OpenAI社内で法務や人事が先行した理由も、根っこは同じではないか。
判断軸を一つに絞るなら、これに尽きる。自分の業務を「入力・処理・出力」の3段階で説明できるかどうか。説明できる人は、コードを書けなくてもエージェントに仕事を任せられる。説明できない人は、どれだけ高性能なツールを渡されても使い道が見えてこない。
抽象的に聞こえるかもしれないので、私自身の例で3段階に分解してみる。私がカスタマーサクセス業務で最初に作ったツールは「解約リスク顧客の早期検知」だった。入力は、CRMに蓄積されたログイン頻度・問い合わせ回数・契約更新日のデータ。処理は、ログイン頻度が2週間連続で前月比50%以下に落ちた顧客を抽出し、契約更新日が60日以内に迫っているかを判定するルール。出力は、該当顧客をSlackの担当者チャンネルに自動投稿する、という3段階だ。エンジニアなら数時間で書けるレベルのロジックだと思う。だが私にとって難しかったのは、コードそのものより「解約リスクをどう定義するか」を自分の頭の中から言葉に落とす作業だった。この言語化さえできれば、あとはAIに渡すだけで動くコードが返ってくる。
日本でも、企業のAIエージェント導入は着実に進んでいる(AIエージェント導入33%の現実)。導入率が伸びる一方で、使いこなす部門とそうでない部門の差も出始めているという。OpenAI社内の逆転劇は、その差を分ける条件が技術力ではなく言語化力だと教えてくれる。
ここから先は、OpenAIの公式データの要約ではなく、私自身が業務ツールを作ってきた中で実際に転んだ経験になる。理屈はわかっても、実際に手を動かすと必ずどこかでつまずくからだ。
非エンジニアが業務ツールを作る時、最初に詰まる3つのハマりポイント
私が業務ツールを自作してきた中で、非エンジニアが最初にハマるポイントは大きく3つある。ここは自分の失敗を先に共有しておきたい。
1つ目は、業務を分解しないまま丸投げすることだ。「Slackに通知が来るようにして」とだけ伝えても、AIはどのタイミングで何を通知すべきか判断できない。私が最初に作ったツールも、条件を詰めずに依頼した結果、不要な通知が1日100件届く事態になった。3時間かけて条件を絞り込み、ようやく実用レベルに落ち着いた。
2つ目は、認証情報の扱いだ。SlackやGoogleスプレッドシートに接続するツールを作ると、APIキーやトークンをコードに直接書いてしまいがちになる。以下は私が実際に書いていた、良くない例だ。
# 悪い例: APIキーをコードに直接書いてしまう
SLACK_TOKEN = "xoxb-1234567890-abcdefg" # これは絶対NG
def send_notification(message):
# このままGitHubに公開するとキーが流出する
requests.post(SLACK_WEBHOOK_URL, json={"text": message})環境変数に切り出すだけで防げるミスだが、初めてツールを作る人はここで必ず一度ハマる。私も最初のツールでキーをコードに直書きしたまま社内共有フォルダに置いてしまい、慌てて作り直した経験がある。
# 良い例: 環境変数から読み込む
import os
SLACK_TOKEN = os.environ.get("SLACK_TOKEN") # .envファイルなどで管理
def send_notification(message):
requests.post(SLACK_WEBHOOK_URL, json={"text": message})3つ目は、動くコードで満足して止まってしまうことだ。「とりあえず動くもん作ろう」は私の信条だが、動いた直後がゴールだと思い込むと危ない。先ほどの解約リスク検知ツールも、作った直後は快調に動いていた。ところが2週間後、CRM側の仕様変更で契約更新日のフィールドが一時的に空欄になる顧客が出た。その瞬間ツールがエラーで止まり、丸一日誰にも解約リスクが通知されない状態になった。例外処理を書かないまま業務で使い続け、想定外のデータが来た瞬間にツールごと止まる、というトラブルを何度も経験している。
3つとも、技術力の不足が原因ではない。業務の分解不足、管理の甘さ、完成の定義があいまいなことが原因になる。OpenAI社内で法務や人事が伸びている裏側でも、同じ壁に当たっている人は少なくないはずだ。
今週から始める3ステップ、非エンジニアがコードに触れる最初の一歩
ここまで読んで「自分も試したい」と思った人に向けて、今週中に着手できる3ステップを用意した。大きな投資は要らない。
ステップ1は、自分の業務を1つだけ選んで書き出すことだ。全部を自動化しようとせず、毎日繰り返している単純作業を1つに絞る。私の場合は「Slack通知の見逃し」から始めた。対象を絞るだけで、AIに渡す指示が驚くほど具体的になる。欲張って「経理業務を全部自動化したい」のように範囲を広げると、AIへの指示もぼやけてしまう。まずは自分が最も苛立ちを感じている1つの作業だけに絞るのがコツだ。
ステップ2は、Claude CodeかCursorのどちらかを試しにインストールし、選んだ業務を「入力・処理・出力」の3段階で説明してみることだ。入力は何のデータか、処理でどう判断するか、出力は誰にどう届けるか。この3段階を言葉にできれば、コードを書く部分はAIに任せられる。言葉にする際は、箇条書きで構わない。私も最初は「入力: Slackの新着メッセージ」「処理: キーワードでカテゴリ分け」「出力: 該当チャンネルへ転記」のように、3行のメモから書き始めた。完璧な設計書を作ろうとせず、まず3行で十分だ。
ステップ3は、動いたコードを一晩寝かせてから、例外パターンを1つだけ追加することだ。想定外のデータが来たらどうなるか、担当者が不在の時はどうするか。完璧な例外処理を目指す必要はない。私が解約リスク検知ツールで実際に加えたのは「必須データが欠けていたら、エラーで止める代わりに『要確認』として通知する」という、たった1行の条件分岐だ。これだけで、CRM側の仕様変更があっても通知が完全に止まる事態は避けられるようになった。1つ追加するだけで、業務で使い続けられる強度がぐっと上がる。
これはデータの裏付けがあるわけではなく、自分が業務ツールを作ってきた実感からの推測になる。それでもOpenAI社内の非開発者たちが、最初から8時間規模のタスクを任せていたわけではないはずだ。80.6%が超えた30分という基準は、私の体感では最初の1週間で誰でも届く距離だと思う。
まとめ
OpenAI社内で非開発者のCodex利用が189倍に増えたというデータは、私にとって遠い会社の話ではなかった。カスタマーサクセス出身の自分が業務ツールを作れるようになった経験がある。法務部門が利用13倍・2026年4月ごろにCodexを主要AIツールとして使い始めたという話は、この経験と同じ構造の上に立つ。
コードを書ける人だけが強い時代は、静かに終わりへ向かっている。強いのは、自分の業務を型として言語化できる人だ。
今日の内容を3点にまとめる。
- 非開発者のCodex利用は組織単位で189倍、部門別ではリサーチが56倍と最大の伸びを記録したと報じられている
- 個人ユーザーの80.6%が30分超、25.6%が8時間超の作業をCodexに依頼していると報じられている
- 業務を「入力・処理・出力」の3段階で言語化できるかどうかが、非エンジニアがエージェントを使いこなせるかの分かれ目になる
かつて挫折してコードから離れた私が言うのだから、間違いない。今のあなたに足りないのは技術力ではなく、最初の1つを選んで書き出す勇気だけだ。
関連記事
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
