OpenAIが2026年6月25日に出したCodexの利用研究を読んで、ちょっと考え方を変えたほうがよさそうだなと感じました。
最初は「Codexの利用が増えています」という、よくあるAIニュースかなと思っていたんです。でも中身を見ると、単にAIコーディングが流行っているという話ではありませんでした。むしろ、AIへの頼み方がかなり変わってきている、という話に近いです。
これまでの生成AIは、どちらかというと「質問する相手」でした。エラーの意味を聞く。SQLの書き方を聞く。コードの一部を直してもらう。そんな使い方です。
でもCodexのようなエージェント型AIは、少し違います。ファイルを読んで、必要なコマンドを動かして、複数の手順を進めて、途中で詰まったら別の方法を試して、最後に差分や結果を返してくる。つまり、AIに聞くというより、AIに仕事を渡す感覚に近づいています。
ここが今回のニュースの面白いところです。そして、少し怖いところでもあります。
「AIに聞く」から「AIに任せる」へ変わってきた
OpenAIの発表では、エージェント型AIによって知識労働の単位が変わる、と説明されています。チャットなら、1回質問して1回答えてもらう。エージェントなら、数分から数時間かけて、ツールを使いながらまとまった作業を進める。
これ、SEの感覚だとけっこう分かりやすいです。
たとえば「このエラー、何が原因？」と聞くのはチャット的な使い方です。一方で、「このリポジトリでログイン失敗時の処理を調べて、影響範囲を出して、最小の修正案を作って、既存テストで確認して」と頼むと、もう作業依頼です。
もちろん、AIが全部うまくやってくれるとは限りません。むしろ、そこを雑に扱うと危ないです。対象範囲を広くしすぎると、関係ないファイルまで触るかもしれません。テストが薄いままだと、動いているように見えて実は壊れているかもしれません。指示が曖昧だと、こちらの意図とは違う方向へきれいに進んでしまうこともあります。
なので、この流れは「AIが賢くなったから何でも任せよう」ではなく、「任せ方をちゃんと設計しないと危ない」という話だと思っています。
数字を見ると、かなり長い作業を渡し始めている
OpenAIの発表で目を引いたのは、Codexに渡されている作業の長さです。
2026年5月時点で、サンプル対象の個人ユーザーの80.6%が、人間なら30分以上かかると推定されるCodexリクエストを少なくとも1回行っていました。70.2%は1時間超、25.6%は8時間超に相当するリクエストを少なくとも1回行っていたそうです。
ここは少し冷静に読む必要があります。この「何時間分」という数字は、実際にストップウォッチで測った時間ではありません。モデルがタスク内容から推定したものです。OpenAI自身も、方向性を見るための数字として扱うべきだと説明しています。
それでも、「短い質問だけではなくなっている」という傾向は見えます。少なくとも、ユーザーはCodexに対して、かなりまとまった仕事を投げ始めています。
arXiv版の論文でも、2026年上半期にCodexのアクティブユーザー数が5倍以上に伸びたことが書かれています。さらに、10%を超えるユーザーが週のどこかで3つ以上のCodexエージェントを並行管理していた、という話も出ています。
このあたりを読むと、「AIを1つ開いて質問する」段階から、「複数のAI作業を走らせて、人間が結果を見比べる」段階へ進み始めている感じがあります。
非エンジニアの伸びが大きいのも気になる
もう一つ気になったのが、非エンジニアの利用増です。
OpenAIの発表では、Codexはもともと開発者向けに広がったものの、非開発者の伸びがかなり大きいとされています。2025年8月以降、非開発者の個人ユーザーは137倍、組織ユーザーは189倍に増えたとのことです。
これだけ見ると、「非エンジニアもコードを書く時代だ」と言いたくなります。でも、そこまで単純に読むのは少し雑だと思います。
非エンジニアがいきなり大規模なシステムを作っている、というより、データ整理、社内資料の構造化、定型作業の自動化、ちょっとしたツールの修正相談、ログやCSVの読み取りなど、これまでエンジニアに頼んでいた周辺作業へAIが入り始めている、と見たほうが現実的です。
この変化は、SE側にも影響があります。
今後は「これを作ってください」だけでなく、「AIにここまでやらせてみたんですが、業務で使って大丈夫ですか？」という相談が増えるかもしれません。これはけっこう重いです。コードが動くかどうかだけでなく、データの扱い、権限、例外処理、運用担当、失敗したときの戻し方まで見ないといけないからです。
AIで現場の小さな自動化が増えるのは良いことです。ただ、増えた分だけ、誰が管理するのか、どこまで使ってよいのか、どのタイミングでSEが見るのかを決めないと、あとで小さな混乱が積み上がります。
SEの仕事は「全部書く」から「任せ方を見る」へ寄っていく
この流れを見ていて思うのは、SEの仕事がなくなるというより、重心が少しずつ変わるということです。
もちろん、コードを書く力はまだ必要です。AIが出した差分を読むにも、設計の違和感に気づくにも、結局は基礎が要ります。ただ、全部を自分の手で書く場面は減っていくかもしれません。
代わりに大事になるのは、たとえばこういう力です。
- AIに渡してよい作業と、渡さないほうがよい作業を分ける
- 作業範囲を小さく切る
- 触ってよいファイル、触ってはいけないファイルを決める
- 最後に何を成果物として返してほしいかを指定する
- レビューしやすい差分にする
- テストや確認手順を先に決める
このへんは、地味ですがかなり効きます。
AIに「いい感じに直して」と渡すと、いい感じに見えるけどレビューしにくい差分が出てくることがあります。小さな修正のつもりが、ついでにリファクタリングされていたり、命名が変わっていたり、関係ないファイルまで触っていたりする。経験がある人も多いと思います。
なので、AIエージェントに任せるなら、最初から「今回はこの関数だけ」「仕様変更はしない」「テスト追加まで」「リファクタリングは別タスク」といった境界線を置くほうが安全です。
レビュー観点も少し変えたほうがいい
AIが作った成果物を見るとき、コードが動くかどうかだけを見ると足りません。
人間が書いたコードでもレビューは必要ですが、AIの場合は少し違う見方が要ります。AIは、もっともらしい理由をつけて、意外と大きく変えてくることがあります。説明はきれいなのに、差分を見ると「いや、そこまで頼んでない」ということもあります。
個人的には、AIエージェントのレビューでは次のあたりを先に見たいです。
- 依頼した範囲を超えていないか
- 関係ないファイルを触っていないか
- 既存の設計や命名に合わせているか
- テストで確認できる形になっているか
- 戻しやすい差分になっているか
- 認証情報や個人情報をログに出していないか
特に「戻しやすい差分」は大事です。AIに任せるほど、作業スピードは上がります。でも、戻しにくい差分が増えると、結局レビューと修正で時間を取られます。
AIの出力を信じるかどうか、という話にしすぎないほうがいいと思っています。信じる・信じないではなく、確認できる形で出してもらう。ここが実務ではかなり大事です。
まず試すなら、大きな実装より小さな調査から
Codexの利用拡大を見ると、つい「自分も大きなタスクを丸ごと任せてみよう」と思いたくなります。でも、最初から大きく任せるのは少し怖いです。
まず試すなら、次のような軽めの作業がよさそうです。
影響範囲の洗い出し
たとえば「このAPIレスポンス項目を変えると、どの画面、型定義、テストに影響しそうか調べて」と頼む使い方です。
この段階なら、AIにいきなり修正させなくても価値があります。コードを読む力、関係ファイルを探す力、影響範囲をまとめる力を見られます。成果物もレビューしやすいです。
小さなテスト追加
次に試しやすいのはテスト追加です。「このバリデーション処理に、正常系1つと異常系2つを足して」といった依頼なら、差分も比較的見やすいです。
ただし、期待値は人間が見たほうがいいです。AIは仕様を勝手に補ってしまうことがあります。テストが通るから正しい、とは限りません。
仕様メモや社内資料の構造化
コード変更にまだ抵抗があるなら、資料整理から入るのもありです。長い仕様メモから、決定事項、未決事項、確認が必要な点、実装に関係する点を分けてもらう。これはかなり使いやすいはずです。
この使い方なら、開発環境に深く入れなくても試せます。AIエージェントの便利さを見つつ、危ない操作を避けやすいです。
数字は面白い。でも、そのまま信じすぎない
今回の研究はかなり面白いです。ただ、数字だけを見て「AIで何時間も節約できる」と言い切るのは早いです。
作業時間の推定はモデルによる判定です。対象ユーザーにも条件があります。OpenAI社内の利用状況も、一般的な会社とは環境が違います。AIに慣れている人が多く、ツールの整備も進んでいるはずです。
なので、このニュースは「すぐ真似すれば同じ成果が出る」というより、「先に進んでいる現場では、AIへの任せ方がこう変わってきている」と読むのがちょうどよさそうです。
自分の現場で使うなら、まずは小さく試す。失敗しても戻せる範囲にする。レビュー観点を先に決める。これくらいが現実的だと思います。
フリーランスSEなら、ここはチャンスかもしれない
フリーランスSE目線で見ると、AIエージェントの広がりは少しチャンスでもあります。
AIを触れる人はどんどん増えます。だから、単に「AI使えます」だけでは弱くなっていくはずです。むしろ価値が出るのは、AIに任せてよい範囲を見極めたり、現場の小さな自動化を安全に整えたり、レビューしやすい形に分解したりする部分です。
たとえば、既存システムの保守、テスト追加、社内ツールの整理、CSVやログの加工、業務フローの見直し。こういう地味な領域に、AIエージェントは入りやすいです。そして、地味だからこそ、ちゃんと見られるSEが必要になります。
「AIに任せれば終わり」ではなく、「AIに任せても壊れない形を作る」。ここに仕事が残るし、むしろ増える可能性もあると思っています。
まとめ：Codexの伸びは、仕事の渡し方が変わるサイン
Codexの利用拡大は、単なるAIコーディングツールの流行ではなく、AIへの仕事の渡し方が変わってきたサインに見えます。
短い質問に答えてもらうだけではなく、調査、修正、テスト、資料整理のようなまとまった作業をAIに渡す。非エンジニアにも利用が広がり、複数のエージェントを並行して動かす人も出てきている。これはかなり大きな変化です。
ただし、丸投げは危ないです。AIエージェントを使うほど、タスクの切り方、権限の渡し方、レビューの仕方が大事になります。
まずは、影響範囲の洗い出し、小さなテスト追加、仕様メモの構造化あたりから試すのがよさそうです。大きな実装を任せる前に、AIがどこまで読めるか、どこでズレるか、どんな出力ならレビューしやすいかを見ておく。
Codexのニュースを読んで感じたのは、AIがSEの仕事を一気に消すというより、SEの仕事を「全部自分でやる」から「任せ方を設計して、結果を見極める」方向へ寄せていくということです。ここに早めに慣れておくと、かなり差が出そうです。
