OpenAIが提供するコーディングエージェント「Codex」は、2026年4月7日に週間アクティブユーザー数が300万人に達したことが発表されました。この記事では、2026年4月8日に行われたOpenAI JapanのDeveloper Experience Engineer、瀬良和弘氏への取材をベースに、OpenAIの公式ブログなどの情報を交えて構成を整え、Codexが変えつつある開発スタイルを紹介します。

Codexの利用拡大

冒頭で言及したとおり、OpenAIが提供するコーディングエージェント「Codex」の利用が広がっています。2026年4月7日（US現地時間⁠）⁠、OpenAI CEOのSam Altman氏が、Codexの週間アクティブユーザー数300万人突破を公表しました。CodexのエンジニアリングリードであるThibault Sottiaux氏は、週間アクティブユーザー数が1か月弱で200万人から300万人へ伸びたと紹介しました。

瀬良氏は、利用拡大の背景について、単なるモデルの進化だけでなく、開発者の間でCodexを使った体験が共有され始めたことが大きいとみています。2026年3月にリリースされたWindows版のCodexアプリ[1]は大きな要因の1つである一方、それだけでユーザーが増えたわけではないと話します。

2月に先行してリリースされたMac版のCodexアプリで評価を得ていたことに加え、Codexの利用体験が共有され始めたことも、利用拡大を後押ししていると瀬良氏は考えています。

Codexがもたらす開発スタイルの変化

Codexの普及とともに、開発の進め方そのものにも変化が現れています。

AIとのペアプログラミングから⁠、オーケストレーションへ

瀬良氏がCodexによる開発スタイルの変化の中心にあるとみるのは、AIと人間の役割分担の変化です。わずか1年前までは、コードエディターの横にチャットボックスを置き、開発者自身がコードを書きながらAIとペアプログラミングを行うスタイルが主流だったと言います。

しかし現在では、エージェントが作業の主体となり、人間がそれを監督するような開発スタイルが行われるようになってきています。瀬良氏は自身の開発フローを振り返り、「⁠コーディング自体はエージェントに任せ、人間は最終的な意思決定や細かい調整といったオーケストレーションを行う段階に入っている」と話します。

こうした思想はツールの設計にも表れています。Codexアプリは、フル機能のIDEというより、複数のエージェントを管理し、コードや実行結果を確認しながらエージェントを指揮するためのUIとして設計されています。

並行処理を支えるWorktreeとクラウド環境

オーケストレーションできるようになると、開発者は、複数のプロジェクトだけでなく、1つのプロジェクトの中でも複数のタスクを並行して進めやすくなります。Codexアプリは、この並列処理を後押しする機能を備えています。

たとえば、エンジニアがコマンドを使って利用していたGit Worktreeの切り替えを、UI上の操作で行えるようになっています。メインの作業環境を維持したまま、別ブランチでの不具合修正や機能追加といった複数のタスクを同時に走らせやすくなりました。なお、瀬良氏自身は複数のプロジェクトを切り替えて作業することが多く、Worktreeを使う場面は限られるとのこと。その一方、複数のサーバーサイドエンジニアが作業するプロジェクトではWorktreeが有効だと述べていました。

また、タスクを複数のサブエージェントに分けて並行処理させると、時間を短縮できるだけでなく、それぞれに渡す情報量をしぼり余計な文脈を減らせるるため、精度を高めやすいそうです。

このほか、OpenAIはクラウド環境を用意しています。クラウド上で、GitHubのリポジトリからソースコードをチェックアウトしてコンテナ（環境）を構築できます。その後のテスト実行はクラウド上のエージェントに任せられます。これによってローカル環境を汚さずにクラウド上で検証ループを完結できるようになります。

習熟度別に見る⁠、Codex定着の3ステップ

現在、Codexの導入現場では、個人としての生産性向上から、チームや組織でいかに標準ツールとして定着させるかという次のフェーズへと関心が移ってきています。そこで瀬良氏が示したのが、エンジニアの習熟度に応じた、3つのステップです。

初級⁠：小さなタスクを並行して任せる

初心者向けの入口として、瀬良氏はCodexを「非常にレベルの高いコーディング能力を持った優秀な新人として扱うのが良い」とアドバイスします。エージェントとしてのコーディング能力はすでに高い水準にあるものの、実際のプロジェクト固有のルールや状況は人間が適切に教える必要があるからです。

ここで取り組むべきなのは、簡単なテストコードの追加や、影響範囲の小さい不具合修正といったスコープの狭い作業です。こうした小さな仕事をいくつかエージェントに依頼し、Codexアプリ上で並行して動かしてみるところから始めます。

そうすることで、エージェントに作業を任せるという新しい作業スタイルを、自分なりに掴んでいけます。

中級⁠：ツール連携とスキルで運用を標準化する

個人の作業スタイルが固まってくると、次に求められるのはチーム全体でのプロセスの標準化です。具体的には、プロジェクトのルートにある.codexディレクトリに設定を置いたり、チームで共有したいエージェントスキル（以下スキル）を.agents/skills/ディレクトリの下に置いたりすることで、誰が使っても同じ基準でエージェントが動く環境を整えていきます。

あわせて重要になるのが、日常的に使うツール群との連携です。OpenAI社内ではGitHubに加え、プロジェクトタスク管理ツールにLinear、コミュニケーションツールにSlackを使っており、それぞれ目的に応じた連携ワークフローが構築されています。

たとえば、LinearとGitHubを組み合わせた運用が標準的なスタイルとして使われています。また、Codexのクラウドタスクを活用する場合は、GitHubやSlackと接続したワークフローも使われています。後者では、Slack上で「こういう不具合があるから直してほしい」といった会話が発生した際、その場でCodex宛にメンションを飛ばすだけでタスクの依頼が完了し、作業が終わると完了報告の返信が返ってくる流れができているそうです。

さらに、チーム内で繰り返し発生する作業手順は、スキルとしてパッケージングすることが勧められます。単なる自動化スクリプトとの違いは、エージェントによる「文脈に応じたヒューリスティックな判断」を伴う点にあります。単なる作業手順であればスクリプト化するだけで十分ですが、スクリプトを実行しつつ、文脈に応じてエージェントに判断させながら進めたい場合には、スキルという形式でまとめるのが適していると言います。

この考え方は、瀬良氏が別途OpenAIのブログで紹介しているOpenAI Agents SDKリポジトリの運用にも当てはまります。このブログではrepo-local skillsやAGENTS.md、GitHub Actionsを組み合わせることで、検証やリリース準備、プルリクエストのレビューといった繰り返し作業を反復可能なワークフローとして回していることを紹介しています。

上級⁠：自律動作を実現するためのハーネスエンジニアリングの整備

3つ目のステップとして瀬良氏が挙げるのが、エージェントのパフォーマンスを最大限引き出すために環境全体を整える「ハーネスエンジニアリング」と、それによる自律駆動の実現です。ここで重要になるのは、エージェントが必要な情報へたどり着けるよう、参照先のドキュメント構造や判断材料まで含めて環境を設計することです。

その一部として使われるのがAGENTS.mdです。ただ、瀬良氏は「何でもそこに突っ込めばいいわけではなく、数千行も書いたらエージェントは何が重要か分からなくなってしまう」と指摘します。コーディングエージェントを使いこなしている人はAGENTS.mdを地図のように使います。そして、エージェントが迷った時に参照すべき情報やスキル、ドキュメントへの経路自体をシステムとしてデザインしています。

OpenAIのブログにあるハーネスエンジニアリングの説明でも、AGENTS.mdは目次として扱い、実際のナレッジは構造化されたドキュメントや設計資料、実行プランなどに分けて管理する考え方が紹介されています。こうした環境整備が進むとエージェントは高い自律性を見せ始め、実際、Codexが6時間以上にわたって自律的に作業を継続した事例に言及されています。また瀬良氏は、適切なハーネスを整えた環境で、25時間一度も止まることなく作業を続けた事例にも触れていました。

OpenAI社内の活用実績と⁠、これからのエージェント活用

こうした変化は、OpenAI社内での活用実績や、エージェントを使いこなすための新しい考え方にも表れています。

Codexを日常的に活用することで生産性を向上

OpenAI社内でも、Codex活用は急速に広がっています。瀬良氏によれば、サーバーサイドやクライアントサイドを含む多くのコード変更にCodexが関わっていると言います。

その効果は数字にも表れています。2025年10月時点で、Codexを導入したOpenAIのエンジニアによるプルリクエストのマージが、導入前と比べて70%増加していることがわかっています。

エンジニアだけでなくリサーチャーの研究活動でも、これまで1〜2週間かかっていた作業が1〜2日で完了するようになった事例に触れていました。

また、重要なプロジェクトでは、GitHub上に作られるプルリクエストをCodexが自動でレビューする仕組みがしっかりと導入されています。瀬良氏が担当するオープンソースSDKの開発でも、ロジックレベルのバグをCodexが自動で指摘するため、人間が手作業で確認する負担は大きく減ったと述べています。

全体像を把握するアプローチが重要に

AIへの依存度が高まるにつれ、プロジェクトの全体像やコードの状況がわからなくなるのではないかと懸念する開発者も少なくありません。この点について瀬良氏は、AIを使ってプロジェクト全体像を把握することが重要になると話しています。

たとえば、新しいプロジェクトや他者の支援に入る際には、Codexで壁打ちを行い、全体像を短時間で理解するアプローチが有効だと挙げていました。コードが一貫性を持って構築されていれば、全体像を把握しやすくなり、人間がコントロールを失う状況も防ぎやすいと瀬良氏は述べています。

エージェントを活用するためのシステム設計

コードの細部を追う代わりに、開発者が注力すべきなのが現実的な検証プロセスをどう組むかです。単にコードレベルで正しそうに見えるだけでなく、実際に使ったときに正しく動くかまで確かめる仕組みが欠かせません。こうした検証や環境設計まで含めて整えることが、先に挙げたハーネスエンジニアリングそのものです。

たとえば、生成されたコードの見た目を確認するだけでなく、実際のAPIエンドポイントへの接続テストまでをCodexに実行させるような仕組みを整えることが挙げられます。また先に触れたように、あらかじめ定めた指標が目標値に達するまでエージェントに作業を続けさせるといった検証プロセスを組み込むことも重要になります。

高度な自動化を進めるには、エージェントが途中で判断に迷って止まらないよう、先回りして環境や判断材料を整えるシステムデザインが重要になると瀬良氏は述べています。