2026年6月2日、OpenAIは「Codex for every role, tool, and workflow」を発表しました。今回の要点は、Codexを開発部門だけの道具にせず、営業、分析、デザイン、投資調査などの知識業務にも広げるための役割別プラグイン、共有用のSites、そして差分修正しやすいAnnotationsをまとめて投入したことです。すでにOpenAIは、Codex利用者のうち非開発者が約20%を占め、開発者より3倍超の速度で伸びていると説明しています。
企業にとって重要なのは、機能そのものより「どの部門に、どの権限で、どの成果物まで任せるか」です。この記事では、公式発表で確認できる事実だけに絞って、部門展開の判断軸、Sitesの扱い方、管理者が先に決めるべき統制ポイントを整理します。
Codexで何が追加されたのか
OpenAIが今回まとめて打ち出したのは3つです。1つ目は役割別プラグインで、部門ごとに必要なアプリ、スキル、ワークフローを束ねた構成が最初から入っています。2つ目はSitesで、Codexが作ったダッシュボードやプランナー、社内共有ページをURLでワークスペース内に共有できます。3つ目はAnnotationsで、生成済みのWebページ、ドキュメント、スライド、表の一部を指定して、その箇所だけ修正指示を出せます。
OpenAIによると、今回公開された役割別プラグインは6種類で、全体では62の人気アプリと110のスキルを含みます。対象はデータ分析、クリエイティブ制作、営業、プロダクトデザイン、上場株投資、投資銀行業務です。つまり「まずはコード生成」ではなく、「既存の業務文脈を引き込んで、部門別の成果物を早く作る」方向へCodexが広がったと読むのが実務的です。
非開発部門はどこから始めるべきか
全社展開を急ぐより、成果物が明確な部門から入れるほうが失敗しにくいです。たとえば営業なら会議準備、フォローアップ、案件更新、リスク案件レビューが使いどころとして公式に挙がっています。分析部門なら、SnowflakeやDatabricks Genie、Hex、Tableauの文脈を踏まえて指標変化の説明やレポート作成までつなげられます。デザイン部門なら、ライブURLからのプロトタイプ確認や静止画のインタラクティブ化まで視野に入ります。
判断基準は単純で、「入力データが既存SaaSにあり」「出力物の型が決まっていて」「人のレビューを挟みやすい」業務から始めるべきです。逆に、承認者が曖昧なまま広報文や見積、契約関連を一気に自動化すると、便利さより統制コストが先に立ちます。今回の発表は部門横断の可能性を広げるものですが、導入順序まで自動で決めてくれるわけではありません。
Sitesは何に向いていて何を決めるべきか
SitesはBusiness/Enterprise向けにpreviewとして展開される共有用の成果物レイヤーです。OpenAIは、顧客レビュー用ページ、シナリオプランナー、製品ローンチの情報ハブ、進捗トラッカーなどを例に挙げています。ここで重要なのは、Sitesが単なるHTML出力ではなく、ワークスペース内でURL共有される運用を前提にしている点です。
そのため管理側は、公開範囲、更新責任者、元データの出所、手修正の可否を先に決める必要があります。たとえば営業向けSitesなら、顧客名や商談情報が入る可能性があるため、誰でもURLを知っていれば見られる運用にしてよいのかを確認しなければいけません。OpenAIの発表文はSitesを便利な共有面として示していますが、社内では「共有できる」こと自体がガバナンス論点になります。
Annotationsで変わるレビュー手順
Annotationsの実務価値は、生成結果を全部作り直さず、問題箇所だけ直せることです。ナビゲーションのフォントだけ変える、投資判断メモの主張に根拠を求める、スライドのグラフラベルを修正する、といった細かい差分指示を前提にしています。これは「AIが初稿を作り、人が赤入れで仕上げる」運用と相性が良いです。
導入時は、どこまでをAI初稿に任せ、どこからを人の確定編集にするかを決めると運用が安定します。営業資料なら主張の骨子まで、IRや法務に近い文書なら構成案まで、という線引きです。Annotationsがあるからといってレビュー責任が薄くなるわけではなく、むしろレビューの単位が細かくなるぶん、承認手順を短く再設計しやすくなるのが利点です。
管理者が先に確認したい権限制御と展開条件
公式発表では、Business/Enterpriseワークスペースの管理者が基盤アプリの権限をworkspace settingsで制御できると案内されています。ここはPoC前の必須確認ポイントです。どのプラグインを許可するかだけでなく、HubSpotやSlack、Salesforceのような接続先にどの範囲まで触らせるか、監査対象をどこまで残すかを詰めないと、部門展開のスピードが出ても後で止まります。
おすすめは、1. 部門ごとに許可する接続先を最小化する、2. Sitesの用途を社内共有に限定する、3. Annotationsを前提にレビュー担当を固定する、4. plugin追加申請の窓口を一本化する、の4点を最初に決めることです。OpenAIは今後Corporate Finance、Private Equity Investing、Marketing Strategy、Strategy Consulting、Legal向けのプラグイン追加も予告しています。今のうちに統制ルールを先に作っておくと、後続ロールの追加が楽になります。
よくある質問
Q. 今回の機能は全ユーザーがすぐ使えますか？ A. いいえ。role-specific pluginsはsupported regionsで順次ロールアウト、SitesはBusiness/Enterprise向けpreview、Enterpriseでは管理者設定が関わります。全機能が即時一律提供とは限りません。
Q. まず試すべきプラグインはどれですか？ A. 部門横断で広げる前に、入力元と成果物が明確な業務に合うものからです。たとえば分析レポート、営業会議準備、デザイン試作のように、レビュー担当が最初から決まっている業務が向いています。
Q. 社内導入で一番詰まりやすい点は？ A. 機能理解より権限設計です。どのアプリ接続を許可するか、誰が公開URLを扱うか、AI初稿と最終承認の境界をどこに置くかを曖昧にすると、PoC後に止まりやすくなります。
Codexを営業・分析・デザイン部門まで安全に広げたい場合は、業務棚卸しと権限設計を先に行うのが近道です。 HelloCraftAIに相談する と、部門別の導入シナリオや承認フロー設計まで一緒に整理できます。
