Codexを最初に見ると、やはりコーディングの道具に見えます。リポジトリを読み、コードを直し、テストを回し、差分を確認する。そこが一番わかりやすい入口です。

ただ、プラグインを使い始めると見え方が少し変わります。OpenAIの説明では、プラグインはスキル、アプリ連携、MCPサーバーなどをまとめたものとして扱われます。Codexアプリでは、文書、PDF、スプレッドシート、プレゼン、Browser、Chrome、Computer Use、Figma、GitHub、Google Drive、SharePoint、Slackといった仕事の接点が、同じワークフローの中に入ってきます。

ここで期待しすぎると失敗します。これは「事務作業を全部代行するAI」ではありません。実務の作業台に近いものです。分散したファイル、ブラウザ画面、チーム文書、反復ルールを集めて、草案、照合表、確認結果、引き継ぎ資料に変える作業台です。

コーディング以外の仕事で効くのは、まさにここです。文章をきれいに書くことより、コピー、貼り付け、表の作り直し、画面確認、同じ説明の繰り返しを減らせるかどうかです。

実務ではここを見る

私がCodexプラグインを見る時、最初に「どれが一番強いか」は聞きません。その聞き方だと、ほぼ全部が便利そうに見えます。DocumentsもPDFもChromeもComputer Useも、単体ではよく見えます。

まず見るのは、仕事の文脈がどこで切れているかです。

向いている業務は、だいたいこういう形をしています。

  1. PDF、表、文書、ブラウザページ、社内会話に原材料が散らばっている。
  2. 誰かが判断メモ、比較表、QA結果、スライド草案、課題の要約、データ確認表を作る必要がある。
  3. 毎回似た作業なので、基準を文書化できる。
  4. 最終判断は人が持っている。
  5. 顧客送信、支払い、削除、アカウント変更の前に間違いを止められる。

この範囲ならプラグインは使えます。機能の追加というより、文脈を移動させる橋です。

業務入力、Codexプラグインの接点、人による確認を分け、取り消しにくい実行前の判断点を示す図
プラグインを増やすだけでは業務自動化になりません。入力を適切な接点へ渡し、草案や確認結果を作り、最後の判断は人が持つ形にする必要があります。

プラグインで変わること

プラグインがない場合、AIはチャット欄の中に閉じがちです。文書を貼り、スクリーンショットの状況を書き、CSVの一部を貼り、要求を書いて出力をもらう。一回限りの作業なら成立しますが、業務が複数のツールをまたぐとすぐ崩れます。

プラグインがあると、運用の形が変わります。

業務接点 向いている用途 確認点 最初から任せない仕事
Documents 判断メモ、方針草案、議事メモ整形 責任者が表現と抜けを確認 法務・契約の最終文言
PDF 主張の抽出、版の比較、ページ根拠確認 人がページ番号と意味を確認 監査・遵守の承認
Spreadsheets 列整理、異常値確認、数式案、前提表示 責任者が数式と元行を確認 未確認の財務報告
Presentations ブリーフをスライド構成にする 発表者が話と数字を確認 役員向け最終版
Browser ローカル確認、公開ページQA、レイアウト確認 スクリーンショットと指摘一覧 ログイン済みアカウント操作
Chrome ログイン状態が必要な流れの確認 権限と画面状態を確認 裏側でのアカウント作業
Computer Use APIがない古い管理画面の処理 人がアプリ状態を見る 長時間の無人GUI操作
Figma 画面比較、余白確認、コンポーネント差分確認 デザイナーや担当者が意図を確認 最終的な好みの判断
Drive, SharePoint, Slack ファイル探索、会話要約、返信草案 出典リンクと担当者確認 機密メッセージ送信

大事なのは名前ではなく、どこまで任せてどこで止めるかです。

文書とPDF業務

コーディング以外で最初に試すなら、私はDocumentsとPDFから始めます。危険度は比較的低く、時間短縮はわかりやすいからです。

たとえば、長い要件メモ、価格表PDF、ベンダーのセキュリティ回答、社内レビュー文があるとします。通常は誰かが全部読み、必要な箇所を拾い、表現を整え、抜けている質問を書き、別の人に根拠確認を頼みます。地味ですが時間を食います。

Codexには、こういう形で任せるのが現実的です。

  1. 何が変わったか。
  2. どの原文が根拠か。
  3. まだ不確かな点は何か。
  4. どんな決定が必要か。
  5. まだ使ってはいけない文言は何か。

これは使える成果物です。最終回答のふりをせず、人が確認できる材料になっているからです。

失敗基準もはっきりしています。PDFからページ根拠が落ちる、メモに出典のない断定が混ざる。この場合、その流れを判断資料に使ってはいけません。読書メモや概要作成まで範囲を下げます。

選ぶ場面と選ばない場面を分けるなら、草案と根拠照合が多い仕事には使えます。単語一つが法務、人事、財務、顧客リスクにつながる最終文言には、そのまま使わない方がいいです。

スプレッドシートとデータ

スプレッドシートは簡単に効きそうに見えますが、私はここで少し慎重になります。

列名をそろえる、空行を見つける、重複IDを確認する、初期数式を作る、乱れたエクスポートを比較表にする。こうした作業は実際に速くなります。「担当者がないリードはどれか」「ステータスが二回変わった請求はどれか」といった確認も早いです。

問題は、表の結果が客観的に見えすぎることです。間違った数式もきれいに見えます。フィルタ漏れのチャートも説得力があります。日付解釈がズレると、売上が別月に入っても表面上は自然に見えます。

私のルールは、Codexに表を準備させても、前提を見えるようにすることです。列名は明確にする。数式は隠さない。変更行を示す。未確認の点を短く残す。

向いている仕事はこうです。

  • 生データを追跡表に変える。
  • CSVの二つの版を比較する。
  • 優先順位スコアの草案を作る。
  • 人が見るべき行を抽出する。
  • ラベルが揺れたデータをピボットしやすい形にする。

避ける仕事もあります。

  • 行単位確認なしに月次報告を確定する。
  • バックアップなしに元ファイルを直接更新する。
  • 担当者の業務ルールをモデル推測に置き換える。

編集時間は減ったのに確認時間が減らないなら、その自動化はまだ途中です。

プレゼンと報告の流れ

プレゼン作業を「スライドを作ること」と見ると、あまり良くありません。難しいのは1枚目に何を置くか、何を削るか、聞き手に何を判断してほしいかです。

入力が明確ならCodexは使えます。PRD、調査メモ、表、顧客課題リスト、聞き手があれば、スライドタイトル、各スライドの主張、必要な根拠、足りないデータを出せます。

足りないデータの表示が大事です。それがない草案は、早く完成品に見えすぎます。

たとえばプロダクト計画の資料なら、こう出てくるべきです。

  • 問題: オンボーディング後の問い合わせが増えている。
  • 必要な根拠: 問い合わせ分類、影響を受ける顧客層、対応時間。
  • 必要な決定: オンボーディング修正、自動化追加、ルーティング変更のどれを先にするか。
  • リスク: 現在の問い合わせデータに重複チケットが混ざっている可能性。

このくらいなら使えます。担当者に方向とチェックリストを渡せます。ただし最終プレゼンではありません。

私はプレゼンプラグインを構成づくりには使いますが、説得の責任までは渡しません。

Browser、Chrome、Computer Use

ブラウザ系は境界をより厳しく確認します。

In-app browserは、ローカル確認、公開ページ確認、レイアウト検証、スクリーンショット証拠、簡単なユーザー導線QAに向いています。「このページを開き、フィルタを押し、モバイルでカードレイアウトが崩れるか確認して報告する」くらいなら自然です。

Chromeは別物です。拡張機能を通じてユーザーのログイン状態を使えるためです。便利ですが危険も増えます。ログイン済みページには個人情報、顧客データ、請求情報、管理者権限、戻せないボタンがあります。

Computer Useはさらに一段進みます。ブラウザやAPIで足りないデスクトップアプリまで触れます。私はAPIがない古い管理画面、ローカルツール、一回限りのGUI確認のように代替手段がない時だけ使います。

私の基準はこうです。

  • 公開ページやローカルQAはBrowserで足ります。
  • ログイン状態が必要で、人が画面を見られる時だけChromeを使います。
  • ファイル、ブラウザ、コネクタ、APIで解決できない時だけComputer Useを使います。

失敗基準は明確です。ボタンの意味を推測しなければならない、作業中に画面が変わる、削除、支払い、顧客送信、パスワード変更、取り消しにくい送信が入る。この場合は止めます。

Figma、Drive、Slack、SharePoint

Figmaは質問が具体的なら使えます。デザインと実装画面を比べる、余白の問題を探す、コンポーネント差分を書き出す、実装メモへ落とす。逆に「もっと上質にして」とだけ頼むとぼやけます。「モバイルナビがタイトルを隠す。余白、タップ領域、言語選択UIを確認する」なら仕事になります。

DriveとSharePointは、散らばった資料を探してブリーフへ変える用途に合います。Slackは、会話要約、アクション抽出、フォロー文案に使えます。派手ではありませんが、実際の勤務時間はこういう所で削られます。

この領域では、要約のうまさより権限設計が重要です。プラグインがフォルダやチャンネルを見られるなら、何を引用してよいか、どのリンクを残すか、公開資料に絶対入れない情報は何かを先に決めます。

私はこれらを発行や送信ではなく、準備段階で使います。良い出力は、出典リンク、残った質問、次の担当者を一緒に残します。

任せない仕事

技術的に可能でも、自動化対象にしない方がよい仕事があります。

私は次の仕事をCodexプラグインの通常フローには入れません。

  • 確認なしの顧客メッセージ送信。
  • 支払い、アカウント、セキュリティ、権限設定の変更。
  • ファイル、チケット、課題、レコード、ユーザーの削除。
  • 規制機関、銀行、プラットフォーム、ベンダーへのフォーム提出。
  • 契約、給与、経費、返金、アクセス権の承認。
  • バックアップと差分なしの基準データ更新。
  • 根拠が足りない状態での事業判断。

Codexに役割がないという意味ではありません。草案を作る、根拠を集める、チェックリストを作る、差分を見せる、危険を見える化する。そこまでは任せられます。間違えた時のコストが大きい最後の実行は、人が持つべきです。

続ける前に止まる条件

プラグインの使い方で一番危ないのは、最初にきれいな出力が出たからそのまま運用へ入れることです。現場では残り作業が出ます。

私が見る失敗基準は次の通りです。

失敗シグナル たいてい意味すること 次にやること
出典リンクがない 確認できる成果物ではない 引用を必須にするか入力を絞る
担当者が結局全部読み直す 作業が減らず場所だけ変わった 範囲を狭めるか確認項目を足す
同じ例外が毎週戻る モデルではなくルールが足りない スキルやチェックリストを直す
権限を広く求めすぎる 業務範囲が広すぎる 読む、作る、実行するを分ける
文章は滑らかだが中身が薄い 根拠ではなく雰囲気を求めている 前提、欠損データ、次の判断を求める
ブラウザ作業がアカウント状態を変える 危険境界が間違っている 人の承認へ移す
戻し方がない 運用準備ができていない バックアップ、差分、復旧経路を置く
人が結果を信じなくなる 確認負担が大きすぎる 業務をやめるか目標を下げる

単純な精度より、この方が見やすいです。現場の信頼は、根拠と戻せることから作られます。

導入はこの順で進める

私がCodexプラグインを業務に入れるなら、派手な業務から始めません。地味で繰り返される一つの業務を選びます。

例として、ベンダー比較の受付を考えます。

入力はベンダーPDF、価格ページ、セキュリティ回答、要件表、社内コメントです。出力は出典付き比較メモ、残リスク、不足回答、進行・保留・却下の状態です。

最初からベンダー決定まで自動化してはいけません。準備だけを自動化します。

最低限の設定はこれです。

  1. 責任者を一人決める。
  2. 入力してよい資料を決める。
  3. 出力テンプレートを決める。
  4. Codexが必ず残す出典を決める。
  5. Codexが判断してはいけない項目を書く。
  6. 出典確認のチェックを置く。
  7. 元ファイルと生成物を一緒に保管する。
  8. 繰り返す例外を記録する。

二、三回回せばパターンが見えます。同じ整形が続くならスキル化します。同じ資料が毎回必要なら接続を変えます。同じ承認質問が続くならテンプレートへ入れます。

その段階で、プラグインは機能の集まりではなく運用の形になります。

選ぶ前に見ること

問いは「Codexがコーディング以外もできるか」ではありません。できる部分はすでにあります。

見るべきは、仕事のどこが文脈移動、草案作成、比較、確認、引き継ぎなのかです。そこならプラグインは役に立つ可能性があります。

判断、権限、お金、顧客影響、取り消しにくい変更が入るなら、Codexは一段前に置く方がいいです。根拠を準備させ、差分を見せ、面倒な部分を見える化し、最後の決定は人が持ちます。

これは弱い自動化ではありません。長く残る自動化は、だいたいこの形です。

先に答えておきたい質問

Codexプラグインは開発者向けだけですか？

いいえ。Codexは開発作業から入るのが自然ですが、プラグインは文書、PDF、スプレッドシート、プレゼン、ブラウザ、デザイン、チームファイル、コミュニケーションにも届きます。ただしコーディング以外では、入力、出力、確認基準がより重要になります。

ChromeやComputer Useは常に有効にすべきですか？

いいえ。公開ページやローカル確認ならBrowserで足りることが多いです。ログイン状態が必要な時だけChromeを使い、Computer Useはファイル、ブラウザ、コネクタ、APIで解けないGUI作業に残す方が安全です。

最初に試す業務は何がよいですか？

最終判断が人に残る業務が向いています。ベンダー比較、方針確認、PDFからのメモ作成、表の整形、デザインQA、サポート会話の分類などです。最初から支払い、削除、アカウント変更、顧客送信は選ばない方がいいです。

プラグインとスキルはどう一緒に使いますか？

プラグインは道具や資料へアクセスする面で、スキルは反復作業の方法と確認基準を残す手順です。同じ仕事が繰り返されるなら、プラグインでアクセスし、スキルで方法を固定し、最後の確認は人が持つ形が現実的です。

参考にした資料

報道内容、公式文書、政策背景、製品情報、変わる可能性のある主張を確認するために参照した公開情報です。

  • Codex pluginsOpenAI確認した内容: プラグイン構成; スキル、アプリ連携、MCPサーバーの関係確認日: 2026-08-25
  • Codex app featuresOpenAI確認した内容: コード以外の成果物; 自動化とブラウザ機能確認日: 2026-08-25
  • Codex Chrome extensionOpenAI確認した内容: ログイン済みChrome状態; 拡張機能の境界確認日: 2026-08-25
  • Computer Use in CodexOpenAI確認した内容: デスクトップアプリ操作; Windowsでの前面実行制約; 安全境界確認日: 2026-08-25
  • In-app browser in CodexOpenAI確認した内容: ローカル確認; 未ログインWeb確認; ブラウザQA確認日: 2026-08-25
  • Agent SkillsOpenAI確認した内容: 反復作業の手順; 段階的な文脈読み込み確認日: 2026-08-25
  • Model Context Protocol in CodexOpenAI確認した内容: 外部文脈とツール接続確認日: 2026-08-25
  • GPT web generated imageOpenAI確認した内容: 代表画像の生成確認日: 2026-08-25