Codexは「コードを書くAI」から「業務を組み立てるAI」へ進化する

Posted at 2026-06-18

OpenAIは2026年6月2日、Codexに大きなアップデートを発表しました。新たに追加された中心機能は、役割別プラグイン、Sites、Annotationsの3つです。

Codexはもともと、ソフトウェア開発者向けのコーディング支援AIとして始まりました。しかしOpenAIの発表によると、現在では毎週500万人以上がCodexを利用しており、非開発者も全体ユーザーの約20%を占めています。さらに、非開発者ユーザーは開発者より3倍以上速く増えているとされています。

これは、Codexが「コードを書くためのツール」から、「業務そのものをAIで組み立てる基盤」へ広がっていることを意味します。

今回のアップデートで重要なのは、単に便利な機能が増えたことではありません。業務データに接続し、役割ごとの手順を再利用し、生成物をURLで共有し、必要な部分だけを修正できるようになったことです。

役割別プラグインは、プロンプト集ではなく業務パッケージである

今回の発表でOpenAIは、6つの役割別プラグインを紹介しました。

データ分析
クリエイティブ制作
営業
プロダクトデザイン
上場株式投資
投資銀行業務

ここで誤解しやすいのは、これらを「職種別のプロンプトテンプレート」と見てしまうことです。

OpenAIの説明では、役割別プラグインは関連するApps、Skills、指示、ワークフローをまとめたものです。6つのプラグイン全体では、62のアプリと110のスキルが含まれるとされています。

つまり、プラグインは単なる文章の型ではありません。Codexが業務に必要な外部ツールへ接続し、チームの作業手順に沿って動くためのパッケージです。

Plugins、Apps、Skillsの関係を整理する

Codexの業務利用を理解するには、Plugins、Apps、Skillsの違いを押さえる必要があります。

OpenAI Academyでは、プラグインはCodexを他のツールや情報源に接続するもの、スキルはCodexが特定の作業手順をたどるためのプレイブックとして説明されています。

もう少し実務寄りに言うと、次のように分けられます。

Apps
Google Drive、CRM、データウェアハウス、メッセージングツールなど、外部システムやデータに接続するための入口。
Skills
「顧客向け週次レポートをこの形式で作る」「営業レビューではこの順番で確認する」といった、チーム固有の作業手順。
Plugins
AppsとSkillsをまとめ、特定の職種やワークフローで使えるようにした業務パッケージ。

この構造により、Codexは単に「文章を生成するAI」ではなくなります。既存の業務システムから情報を取り、チームの手順に沿って加工し、成果物として出力するエージェントになります。

データ分析プラグインが示す「環境構築なし」の価値

データ分析プラグインは、この変化が分かりやすい例です。

OpenAIは、データ分析プラグインによって、アナリストやビジネスチームが製品データや事業データを探索し、主要指標が変化した理由を説明し、レポートやダッシュボードを作成できると説明しています。接続先の例として、Snowflake、Databricks Genie、Hex、Tableauなどが挙げられています。

従来、こうした作業には複数の前提が必要でした。

データ基盤への接続設定
SQLやBIツールの知識
ダッシュボード作成スキル
社内指標の定義理解
レポート形式の理解

Codexの役割別プラグインは、この前提を一部まとめて吸収します。ユーザーは自然言語で「先月から解約率が上がった理由を調べて」「営業部門向けに週次ダッシュボードを作って」と依頼し、Codexが必要なツールや手順を選びます。

これは、非エンジニアにとって大きな意味を持ちます。自分でSQLやアプリ実装をすべて書けなくても、業務データを使った分析や可視化を進められるからです。

ただし、ここで重要なのは権限管理です。OpenAIのヘルプでは、プラグインがそれ自体で新しいデータアクセス権を与えるわけではないと説明されています。ユーザーは、接続元のシステムでも適切な権限を持っている必要があります。

つまり、Codexが業務データに接続できるようになっても、「AIなら何でも読める」という設計ではありません。Appsの承認、ユーザー権限、読み取り・書き込み操作の制御、管理者設定が重要になります。

Sitesは、生成物をチームで使う場所に変える

Sitesは、Codexが生成したインタラクティブなWebサイトやアプリを、URLでワークスペース内に共有できる機能です。2026年6月時点では、BusinessおよびEnterprise向けにプレビュー提供されています。

OpenAIは、Sitesの用途として次のような例を挙げています。

ダッシュボード
プランナー
レビュー用ワークスペース
プロジェクトボード
ギャラリー
軽量な社内ツール

これまでAIが生成する成果物は、文章、コード、表、スライドのような「ファイル」に閉じがちでした。Sitesは、その成果物をチームで操作できる「場」に変えます。

たとえば、顧客レビュー用のサイトを作れば、製品アップデート、未解決事項、利用傾向、次のアクションを1つの画面にまとめられます。財務モデルからシナリオプランナーを作れば、経営層が複数の仮定を比較しながら意思決定できます。

ここで大事なのは、Sitesが単なる静的ページではないことです。OpenAIは、Sitesを進捗管理、カスタマーサービス支援、クリエイティブブリーフの保管場所としても使えると説明しています。

Codexが「コードを書く」だけでなく、「業務のための小さなアプリを作り、共有し、更新する」方向へ進んでいることが分かります。

SitesがBusinessとEnterprise中心になる理由

Sitesは便利な機能ですが、組織で使うには慎重な設計が必要です。

なぜなら、社内のダッシュボードや軽量ツールには、顧客情報、営業情報、財務情報、社内計画、未公開のプロダクト情報などが含まれる可能性があるからです。

そのため、URLで共有できることは強みであると同時に、アクセス管理の設計が欠かせません。

組織でSitesを使う場合は、少なくとも次の点を確認する必要があります。

誰がサイトを作成できるのか
誰が閲覧できるのか
外部共有は可能なのか
接続元データの権限は維持されるのか
サイト内で更新操作ができるのか
監査ログや管理者設定はどう扱われるのか
機密情報や個人情報を含むデータを扱ってよいのか

OpenAIは、SitesをBusinessおよびEnterpriseチーム向けにプレビュー提供し、Enterprise管理者が管理設定で有効化できると説明しています。これは、機能の便利さだけでなく、組織利用に必要なガバナンスが前提になるためです。

Annotationsは「全部作り直すAI」からの脱却である

今回のアップデートで、実務上かなり重要なのがAnnotationsです。

Annotationsは、Codexが作成したコード、Markdown、Webサイトに加えて、ドキュメント、スプレッドシート、スライドなどの成果物を、選択した部分に絞って修正できる機能です。

OpenAIは例として、次のような使い方を挙げています。

サイトのナビゲーションバーを選択して、フォントを変更する
投資仮説内の主張をハイライトして、根拠を確認する
スライド上のチャートを指定して、ラベルを分かりやすくする

これは、AI生成物の編集体験として重要な変化です。

従来のAI利用では、少し修正したいだけでも「全体を再生成する」流れになりがちでした。全体再生成では、気に入っていた表現が変わる、書式が崩れる、余計な変更が混ざる、別のハルシネーションが入る、といった問題が起こります。

Annotationsでは、ユーザーが修正対象を明示し、Codexはその選択部分に集中して変更します。これにより、成果物全体を壊さずに、必要な箇所だけを反復改善できます。

実務では、この差が非常に大きいです。

初稿をAIに作らせることよりも、レビュー、修正、差し戻し、再確認のほうが時間を使うからです。Annotationsは、AIを「最初の下書きを出す道具」から、「レビュー後の改善に付き合う道具」へ近づけます。

局所編集が業務AIの信頼性を上げる

ドキュメントやスプレッドシートの編集では、「ここだけ直してほしい」という場面が頻繁にあります。

たとえば、スプレッドシートで特定のセル範囲だけを修正したいとします。全体を再生成すると、周囲の数式、書式、参照関係、条件付き書式、グラフ設定に影響が出る可能性があります。

一方、選択範囲に対してだけ修正を依頼できれば、変更範囲を小さくできます。これは、ソフトウェア開発でいう差分レビューに近い発想です。

業務AIが信頼されるには、生成能力だけでなく、変更範囲を制御できることが重要です。

どこを変えるのか
どこを変えないのか
変更理由は何か
既存の構造や書式を保てるのか
人間がレビューしやすい差分になっているか

Annotationsは、この「変更範囲を絞る」体験をCodexの業務利用に持ち込みます。

非エンジニア向けでも、技術的にはエージェント基盤の話である

今回のアップデートは、表面的には非エンジニア向けの機能拡張に見えます。しかし技術的には、かなり本格的なエージェント基盤の話です。

役割別プラグインは、業務ごとの手順、外部ツール、データ接続をパッケージ化します。Sitesは、生成した成果物を組織内で使えるインタラクティブなアプリにします。Annotationsは、成果物の一部を選択して反復改善できる編集体験を提供します。

この3つを組み合わせると、Codexは次のような流れを扱えるようになります。

業務データや文書に接続する
役割別の手順に沿って分析・生成する
ダッシュボードや資料として形にする
URLでチームに共有する
レビュー指摘を局所的に反映する
変更後の成果物を継続的に更新する

これは、単発のチャットではありません。業務ワークフローそのものをAIが支える形です。

導入時に見るべきポイント

Codexの新機能を組織で使うなら、「便利そう」で終わらせず、次の観点で確認するとよいです。

対象業務
どの職種・どの定型業務に使うのか。分析、営業準備、レポート作成、資料レビューなど、最初の用途を絞る。
接続するデータ
Snowflake、Databricks、CRM、Google Drive、Slackなど、どのシステムに接続するのかを明確にする。
権限設計
ユーザーが元システムで持っている権限をCodex側でも守れるか。読み取り専用から始められるか。
書き込み操作
CRM更新、ファイル編集、チケット作成などの操作を許可するか。人間の確認を挟むか。
成果物の共有範囲
Sitesで作ったページを誰に見せるのか。ワークスペース内だけか、外部共有を許すのか。
監査とレビュー
何を参照し、何を変更したのかを後から追えるか。重要業務ではログや承認フローが必要になる。
スキルの標準化
チームのレポート形式、レビュー観点、表現ルールをSkillsとして再利用できるか。

特に最初は、読み取り中心のワークフローから始めるのが現実的です。たとえば「営業会議前に顧客情報を集約する」「指標変化の仮説を洗い出す」「資料の根拠を確認する」といった用途です。

いきなり重要システムへの書き込みを許すより、まずは人間の判断を補助する形で使い、信頼できる運用パターンを作るほうが安全です。

Codexの進化は、業務アプリ開発の民主化ではなく業務設計の民主化である

今回のアップデートは、「誰でもアプリを作れるようになる」という話に見えます。もちろん、それも重要です。

しかし本質は、業務設計そのものをより多くの人が扱えるようになることです。

これまでは、ダッシュボード、社内ツール、レポート自動化、営業支援、投資分析ワークスペースを作るには、エンジニア、データアナリスト、IT部門、BI担当者の支援が必要でした。

Codexが役割別プラグイン、Sites、Annotationsを備えることで、現場のナレッジワーカーが自分の業務に合わせてツールを組み立て、共有し、改善する流れが作りやすくなります。

ただし、これはIT部門やエンジニアが不要になるという意味ではありません。むしろ、重要性は上がります。

なぜなら、業務AIが社内データや外部システムにつながるほど、権限設計、データガバナンス、監査、セキュリティ、標準化、運用ルールが必要になるからです。

非エンジニアが業務を自動化しやすくなる時代には、エンジニアやIT部門は「全部を作る人」から「安全に作れる基盤を整える人」へ役割が変わっていきます。

Codexアップデートから見える次の業務AI

2026年6月2日のCodexアップデートは、開発者向けAIの延長ではありません。ナレッジワーカーが日常業務の中でAIを使い、成果物を作り、共有し、改善するための基盤に近づいたアップデートです。

役割別プラグインは、業務ごとのツールと手順をまとめます。Sitesは、生成した成果物をチームで使えるインタラクティブな場にします。Annotationsは、成果物を壊さずに必要な部分だけ改善します。

この3つがそろうことで、Codexは「開発者がコードを書くためのAI」から、「チームが業務を前に進めるためのAI」へ進化しつつあります。

重要なのは、AIに何でも任せることではありません。業務のどこにAIを入れ、どのデータへ接続し、どこまで自動化し、どこで人間が確認するのかを設計することです。

Codexの進化は、AI活用の主戦場が「個人の作業効率化」から「チームの業務ワークフロー設計」へ移っていることを示しています。

参考情報

作成日: 2026年6月6日

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up