要点

Codexプラグインは、コーディング以外の仕事にも使えます。ただし万能な事務担当を作るものではありません。文書、PDF、スプレッドシート、ブラウザ、デザイン、チームファイルに分散した文脈を一つのワークフローに集める道具として見る方が現実的です。私は草案、照合、QA、表の整形、デザイン確認には使いますが、削除、支払い、顧客送信、アカウント変更は確認ログと戻し方なしには任せません。

主なポイント
  • Codexプラグインの価値は、コード生成よりもファイル、ブラウザ、チーム文書、反復ルールを一つの流れに置ける点にあります。
  • Documents、PDF、Spreadsheets、Browser、Chrome、Computer Use、Figma、Drive、Slack、SharePointは、それぞれリスクの境界が違います。
  • 大事なのはCodexが書けるか、クリックできるかではなく、人が根拠を見て確認し、誤りから戻れるかです。
  • 最初は文脈収集、草案作成、QA確認、引き継ぎ資料作成から使う方が安全です。
  • 一つの業務、一人の責任者、一つの失敗基準、一つの戻し方で始めるのが現実的です。
向いている読者
Codexプラグインを文書作成、資料確認、ブラウザQA、業務自動化に使うか判断したい運用担当者、プロダクト担当者、サービス企画者。
テーマ
自動化
最終確認
2026年6月16日
取り上げるツール

ワークフローの要点

このガイドを自動化フローに変えるための実用マップです。

  1. 01 入力

    繰り返す業務、必要な入力データ、担当者、成功基準を先に決めます。

  2. 02 AI処理

    AIは下書き、分類、要約、振り分け、ツール実行など、範囲が明確な工程に置きます。

  3. 03 人の確認

    承認、例外処理、コスト上限、慎重な判断は人が確認できるように残します。

  4. 04 出力

    結果をチェックリスト、保存プロンプト、SOP、監視できる自動化実行に落とし込みます。

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

運用メモ

ツールを先に押さず、業務に合うかを先に見る。

入力、承認点、失敗時のログが曖昧なままだと、自動化は混乱を速くするだけです。

判断する点

このツールを信頼できる場所と、監視すべき場所を見ます。

Codexプラグインをコーディング以外の業務自動化に使う時、どこまで任せてどこで人が確認するべきかを判断できるようにします。

確認する資料

8 参照した公開情報

変わりやすい機能や価格は、参照先と公式情報で確認してから判断します。

最初の一手

比較

大きく変える前に小さな試行を行い、確認地点が明確になってから広げます。

後で効いてくる確認点
  • Codexプラグインの価値は、コード生成よりもファイル、ブラウザ、チーム文書、反復ルールを一つの流れに置ける点にあります。
  • Documents、PDF、Spreadsheets、Browser、Chrome、Computer Use、Figma、Drive、Slack、SharePointは、それぞれリスクの境界が違います。
  • 大事なのはCodexが書けるか、クリックできるかではなく、人が根拠を見て確認し、誤りから戻れるかです。
  • 最初は文脈収集、草案作成、QA確認、引き継ぎ資料作成から使う方が安全です。

業務フロー

このガイドがつながる業務フロー

読んでいるガイドが、どの業務フローに関係するのかを確認できます。

ツールスタック選定 チームの運用成熟度に合うスタックを選びます。

自動化プラットフォーム、アプリビルダー、エージェントビルダー、会計ツール、汎用AIアシスタントを比較するルートです。

関連トピックを見る
向いている場合
単体ツール購入、社内ワークフロー構築、広いプラットフォーム導入で迷うチーム
向かない場合
1つのツールだけの詳細な実測レビューが必要な場合は、このガイドの範囲と異なることがあります。
関連ガイド

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. 顧客送信、支払い、削除、アカウント変更の前に間違いを止められる。

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

プラグインで変わること

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

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

業務接点向いている用途確認点最初から任せない仕事
Documents判断メモ、方針草案、議事メモ整形責任者が表現と抜けを確認法務・契約の最終文言
PDF主張の抽出、版の比較、ページ根拠確認人がページ番号と意味を確認監査・遵守の承認
Spreadsheets列整理、異常値確認、数式案、前提表示責任者が数式と元行を確認未確認の財務報告
Presentationsブリーフをスライド構成にする発表者が話と数字を確認役員向け最終版
Browserローカル確認、公開ページQA、レイアウト確認スクリーンショットと指摘一覧ログイン済みアカウント操作
Chromeログイン状態が必要な流れの確認権限と画面状態を確認裏側でのアカウント作業
Computer UseAPIがない古い管理画面の処理人がアプリ状態を見る長時間の無人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、サポート会話の分類などです。最初から支払い、削除、アカウント変更、顧客送信は選ばない方がいいです。

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

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

参照した公開情報

機能、価格の文脈、比較上の判断を確認するために参照した主な公開ページです。

次のステップ

このガイドを運用チェックリストに変える。

まずリソースで業務フローを点検し、現在のプロセスと引き継ぎポイントを整理してからツールを比較します。

比較 更新を報告