Codexを開いたのに、頼むのは文章の要約と検索だけ。作業が終わると、結局また自分でフォルダを開き、表へ転記し、見た目を確認している。これでは、少し賢いチャットを増やしただけです。
現在のCodexは、調査、文章、表計算、資料、画像、ブラウザ、Windowsアプリ、定期実行まで扱えます。
OpenAIの2026年6月2日の発表では、週間利用者は500万人超。非開発者は全体の約20％で、開発者より3倍以上の速さで増えていました。
OpenAI社内でも、非技術職が社内アプリ、経営資料、ダッシュボード、制作物へ使っています。
2026年8月15日、このWindows環境で確認できたCLIは0.147.0です。
最新版ではAgent Plugins、自動審査つき承認、長い会話の整理まで入りました。
さらに、CursorのSkill取り込み、日本語表示、Windows処理も修正されています。
ただ、機能名を50個覚えても仕事は減りません。大事なのは、Codexへ何を担当させ、どこで人が確認するかです。
そこでこの記事では、50の使い方を6つの部署へ分けました。
僕は製造業18年の非エンジニアです。AIを使う時も、自分で全部を抱えるより、リング脇のセコンドみたいに作戦と合格条件を渡す。
この立ち位置で見ています。だから知りたいのは、機能名の数より、仕事が最後まで終わるか、次回の説明が一つ減るかです。
・土台管理部：迷わず、安全に動くための7項目
・調査・発信部：集めた情報を読まれる形へ変える10項目
・制作部：文章以外の完成物まで作る9項目
・事務・数字部：ファイル、表、PC作業を減らす9項目
・仕組み化部：同じ説明を次回から消す8項目
・エージェント統括部：複数のAIと最新版を使う7項目
最初から全部は要りません。あなたが今いちばん嫌いな作業がある部署を開き、1個だけ試す。
その1個を次回も呼び出せる形へ残す。50選の使い方は、それで十分です。
最初に渡す共通依頼文
50個の頼み方を試す前に、どの仕事でも使える入口を一つ置いておきます。
「この作業を、入力、判断、実作業、確認、完成物へ分ける。最初は変更せず、必要な資料、分からないこと、危険な操作、僕が決めることを出す。
外部送信、公開、購入、削除は実行しない。計画を確認した後、許可した範囲だけ進め、最後に完成条件を検査する」
この依頼文の役割は、詳しい命令を全部書くことではありません。Codexが勝手に埋めてよい空白と、人へ戻す空白を分けることです。
資料が不足しているなら推測で完成させない。安全に進められる調査や制作は止めない。
判断が必要な場所だけを人へ返す。これだけで、確認の回数を増やさず、勝手な実行も抑えられます。
仕事に合わせて変えるのは、完成物、正本の場所、公開先、合格基準です。
記事なら文字数と出典、表なら列と合計、動画なら秒数と画面、サイトなら操作とリンク。
良い依頼文は長い文章ではなく、完成条件へ必要な情報が欠けていない文章です。
土台管理部｜Codexを迷わせない7つの準備
Codexが止まる原因は、モデルの性能だけではありません。読んでよい場所、完成の基準、変更してよい範囲が曖昧なら、高性能でも確認ばかりです。
この部署は地味です。でも、後ろの43項目すべてへ効きます。
1｜AGENTS.mdへ、毎回変わらない前提を書く
AGENTS.mdは、Codexが作業前に読む説明書です。
誰向けの仕事か、どのファイルが正本か、何をしてはいけないか、どこまで終われば完成かを置けます。
毎回チャットへ20行の前置きを貼っているなら、その大半はここへ移す候補です。
長く書けば良いわけではありません。「目的」「作業順」「禁止事項」「検査」「保存先」の5つが分かれば動けます。
反対に、日によって変わるテーマや数値まで固定すると、古い条件が残ります。変わらない手順だけを置くのがコツです。
頼み方は「この仕事で毎回説明している条件を、AGENTS.mdへ入れる内容と、その都度伝える内容に分けて。まだファイルは変更しない」。
最初は提案だけ出させ、内容を見てから保存します。完了の目印は、別の新しいタスクでも、同じ説明をせず同じ保存先と禁止事項を守れること。
2｜仕事ごとにフォルダを分け、人格と資料を混ぜない
X記事、顧客案件、経理、動画を同じフォルダへ置くと、Codexは読めても意味を分けられません。
別アカウントの記事を見本にしたり、古い料金表を新しい提案へ混ぜたりする事故は、指示の弱さより置き場の問題です。
仕事ごとに「入力」「作業中」「完成」「検品」「記録」を分けます。その上で、フォルダ直下のAGENTS.mdへ対象と保存先を書く。
案件名やアカウント名をファイルの中だけでなく、置き場そのものへ持たせるイメージです。
頼み方は「このフォルダを変更せずに調べ、別案件の資料、古い版、正本候補を一覧にして。移動案だけ出して」。
いきなり整理させないのが安全です。完了の目印は、どの資料を読んだかと、読まなかった理由が説明できる状態。
AIを賢くする前に、机を分けます。
3｜最初の依頼は、読み取り専用で始める
初めて触るフォルダで「全部直して」は危険です。
内容を理解する前に名前を変え、不要だと思ったファイルを移動し、後から戻せなくなる可能性があります。調査と変更は同じ依頼へ入れない方がいい。
CLIでは\--sandbox read-only\を使い、読むだけの範囲から始められます。
作業フォルダ内の変更が必要になったら\workspace-write\へ広げる。PC全体の広い権限は、必要性を説明できない限り選びません。
頼み方は「変更、移動、削除、外部送信はせず、現状と問題候補だけ報告して」。その報告を見て、次の依頼で対象ファイルを限定します。
完了の目印は、変更履歴が0件のまま、触る候補と危険な箇所が分かること。最初の安心があると、その後は思い切って任せられます。
4｜大きな作業は、計画だけ先に出させる
記事を2万字へ増やす。200個のファイル名をそろえる。
複数の資料からサイトを作る。こうした作業は、完成後に方向違いへ気づくと重い。
最初に計画を見れば、直すのは数行で済みます。
計画には、対象、作業順、変える物、変えない物、確認が必要な境界を入れます。「いい感じに進めて」では、AIが自分で空白を埋めてしまう。
空白を埋めてほしくない場所こそ、計画段階で見つけるべきです。
頼み方は「実行せず、①対象、②手順、③削除や外部送信が発生する箇所、④途中で僕が確認する箇所、⑤完了条件を出して」。
計画へ不足があれば、その場で直します。完了の目印は、何が起きるかを非エンジニアでも説明できること。
5｜完成条件を、見た目ではなく検査へ変える
「分かりやすい記事」「きれいな資料」「使いやすいサイト」は、人によって合格が違います。Codexが迷うのも当然です。
完成条件は、感想ではなく確認できる形へ変えます。
記事なら、タイトルが本文で回収されている、出典のない数字がない、指定文字数に入っている。
サイトなら、スマホで見切れない、すべてのリンクが開く、送信ボタンが本当に動く。表なら、元データの件数と合計が一致する。
これならCodex自身も検査できます。
頼み方は「この成果物の完成条件を、目で見る確認、数字で見る確認、実際に操作する確認へ分けて」。制作前が決め時です。
完了の目印は、「できました」という返事ではなく、検査項目ごとの結果が残っていること。感想を減らすと、修正も短くなります。
6｜続き、別案、別件を使い分ける
長い会話へ別の仕事を足し続けると、以前のタイトル、古い保存先、別の人物設定が混ざります。昨日の続きを開くならresume。
同じ材料から別案を試すならfork。関係のない仕事は新しいタスク。
この区別だけで、途中から文章が変になる症状を減らせます。
会話を長くするほど賢くなるわけではありません。過去の条件が役立つ仕事と、邪魔になる仕事があります。
判断基準は「前の決定を引き継ぐ必要があるか」です。必要なら続き、材料だけ共有したいなら分岐、不要なら新規です。
頼み方は「この依頼は、今のタスクの続き・別案・別件のどれか判断し、理由だけ答えて」。作業前の5秒で混線を止められます。
完了の目印は、新しいタスクの冒頭だけを読んでも、対象と目的が分かること。
7｜戻せる状態を作ってから、変更させる
AIへ任せる量は、信頼より復元で決まります。失敗しないAIを待つより、失敗しても戻れる作業場を先に作る方が現実的です。
原稿なら複製、表なら元ファイルを保存、コードならGitで変更前を記録します。
バックアップは「同じフォルダにコピー」だけでは不十分な場合があります。自動処理がフォルダ全体を触れば、コピーまで巻き込むからです。
重要度に応じて、別フォルダ、版管理、クラウド履歴を使い分けます。
頼み方は「変更前に戻し方を示して。バックアップを作る場合は場所と復元手順を報告し、僕の確認後に編集して」。
完了の目印は、修正後の成功ではありません。失敗した想定で、実際に1つ前へ戻せること。
土台管理部を一本の仕事として使う例
たとえば、新しい顧客向けの比較資料を作るとします。
いきなり「比較資料を作って」と頼むと、Codexは手元にある別案件の見本、古い料金、未確認の口コミまで読めてしまいます。
先にやるのは制作ではありません。対象フォルダを作り、今回の顧客、完成物、使ってよい資料、触らない資料をAGENTS.mdへ置くことです。
次に読み取り専用で中身を確認させます。資料が8件あり、最新版が2件、日付不明が1件、競合の資料が3件、顧客の原文が2件。
ここまで分かれば、何を根拠へ使うか人が判断できます。その後に構成だけを出し、承認したら作成へ進む。
完成後は、料金、固有名詞、出典、ページ表示を検査します。
この流れで土台の7項目は、別々の小技ではなくなります。
1は前提、2は置き場、3は最初の権限、4は実行前の確認、5は合格、6は会話の分離、7は復元です。
一つでも欠けたら必ず失敗するわけではありません。ただ、仕事が大きくなるほど、欠けた部分が手戻りとして返ってきます。
まず確認したいのは、Codexが賢いかではなく、正しい資料だけを読める机になっているかです。
調査・発信部｜集めた情報を読まれる形へ変える10選
情報発信で重いのは、文章を書く時間だけではありません。公式情報を探し、古い説明を捨て、数字を確認し、読者が知りたい順へ並べる作業です。
Codexは、検索結果をまとめるだけでなく、調査から公開前検査まで一つの流れにできます。
8｜最新情報を、公式発表だけで追う
AIの新機能は、紹介投稿が先に伸びます。ところが、対象プラン、対応地域、試験提供か正式版かは抜けやすい。
タイトルへ「最新版」と入れるなら、公開日だけでなく、現在も使えるかまで戻って確認します。
検索の順番は、公式ブログ、公式文書、公式GitHub、開発者本人の発信です。
二次記事は見つける入口には使えても、仕様を確定する根拠にはしません。更新日が違う資料は、新しい方を自動採用せず、何が変わったかを比較します。
頼み方は「2026年8月15日時点で使える情報だけ。公式一次情報を優先し、公開日、対象、提供条件、変わっていない点、未確認を分けて」。
完了の目印は、各主張から公式URLへ戻れること。
9｜長いPDFから、判断に必要な場所だけ抜く
100ページの資料を10行へ要約すると、読みやすい代わりに例外が消えます。契約、規約、研究、決算資料では、その例外が本体です。
Codexへ渡すなら、結論だけでなくページ番号と条件を残します。
抜き出す項目は、結論、数字、対象、除外、期限、注意、原文の位置。
契約書なら不利かどうかを断定させず、解約、支払い、責任、自動更新など、人が精読する場所を絞ります。
法的な最終判断は専門家または当事者に残します。
頼み方は「このPDFを、結論、重要な数字、適用条件、例外、確認が必要な箇所へ分け、必ずページ番号を付けて」。
完了の目印は、要約から元ページを30秒で開けること。
10｜複数資料の食い違いを見つける
公式ページ、料金表、ヘルプ、GitHub Releaseが同時に存在すると、同じ製品でも説明が違います。原因は誤りとは限りません。
地域、プラン、アプリ版、CLI版、更新日の違いかもしれない。
Codexには、一致した事実、食い違う記述、新しい資料、判断できない理由へ分けさせます。
比較表を作る前に基準日と対象環境を決めると、別条件の数字を同じ列へ並べる事故が減ります。
頼み方は「この4資料を比較し、①一致、②矛盾、③対象条件の違い、④どちらとも決められない箇所へ分類して」。
完了の目印は、結論が一つに決まらない箇所も残っていること。分からないを消さない調査は強いです。
11｜著名人の記事は、本人の発言だけを集める
有名人のAI活用は読まれます。ただし、本人が「AIに相談した」と言っただけで、独自の7ステップまで作れば別物です。
本人の動画、記事、投稿を集め、第三者の解説は背景へ分けます。
発言を並べるだけでは記事になりません。共通点、変化、語っていないことを整理し、実務への応用は「ここから編集上の翻訳」と明記する。
本人が使っている道具、頻度、成果が公開されていなければ、確認できないまま残します。
頼み方は「本人の一次発信だけを集め、発言、日付、URL、前後の文脈、確認できないことを一覧にして」。
完了の目印は、本人の事実と記事側の提案が段落で分かれていること。
12｜長い動画を、確認できる時刻つき資料へ変える
1時間の動画から使える発言を探す作業は、再生時間より確認の往復が重い。
字幕や文字起こしがあれば、発言、開始時刻、終了時刻、前後の話題を一覧にできます。
ここで危険なのは、切り抜いた一文だけで意味を決めることです。候補を出した後は元動画を再生し、前後を確認します。
字幕の誤認識もあるため、人名、数字、否定表現は耳で戻る。引用や映像利用の権利は、内容確認とは別に判断します。
頼み方は「主題に関係する発言候補を時刻つきで出し、前後30秒の要旨も添えて。最終確認が必要な固有名詞と数字へ印を付けて」。
完了の目印は、候補から元映像へすぐ移動できること。
13｜伸びた記事から、言葉ではなく構造を抜く
反応の良い記事を読ませる価値は、表現を真似ることではありません。
どの場面から入り、いつ結論を出し、どこで具体例を置き、何を持ち帰らせたかを比較できます。
分析では、冒頭、読者の困りごと、反転、根拠、実物、注意点、締めへ分けます。さらに、反応は構成だけで決まらないと明記する。
投稿時間、アカウント規模、話題性、画像の影響は、本文だけから断定できません。
頼み方は「固有表現、体験、結論は再利用せず、複数記事に共通する構造と、記事ごとに違う部分を出して」。
完了の目印は、元記事を隠しても新しい記事が別の文章として成立すること。
14｜口コミとコメントを、件数と原文つきで分類する
コメント100件を読んでいると、強い一言だけが記憶に残ります。それを「みんな困っている」に変えると、記事の入口からズレます。
Codexなら、便利だった点、止まった症状、要望、誤解、質問へ分類し、件数まで残せる。
大切なのは原文例です。分類名だけでは、読者が実際に何と言っているか消えます。
個人情報を外し、代表例を少数残す。一人の声を市場全体へ広げず、母数と収集条件も書きます。
頼み方は「このコメント群を意味の近い悩みへ分類し、件数、短い原文例、判断できないものを出して」。
完了の目印は、合計件数が元データと一致し、分類外も捨てていないこと。
15｜検索需要と、読者の困りごとを分ける
検索回数が多い言葉と、記事で解決すべき悩みは同じではありません。
「Codex 使い方」が多くても、読者は起動、料金、重さ、利用枠、指示、保存先のどこで止まっているか分からないからです。
検索候補、関連質問、公式FAQ、Xの実際の反応を集め、症状の言葉へ落とします。
抽象語より「止まる」「遅い」「改行が消える」「毎回説明する」の方が記事の入口です。
数字を使うのは、検索需要を確認できる道具がある場合だけです。
頼み方は「このテーマの検索語を、知りたいことではなく、読者が画面上で困る症状へ言い換えて」。
完了の目印は、タイトルを読んだ人が自分の場面を想像できること。
16｜調査の最後に、未確認だけを独立させる
調査結果が増えるほど、確認済みと推測が混ざります。記事の事故は、情報不足より、境界が消えた時に起きやすい。
そこで最後に「使える事実」「編集上の解釈」「未確認」を分けます。
数字、日付、人物の使用実態、効果、料金は特に注意します。「見つからなかった」は「存在しない」と同じではありません。
検索範囲と確認日を残せば、公開直前に再調査する場所も分かります。
頼み方は「本文へ使える確認済み事実と、まだ書けない未確認情報を別々に出して。推測で穴を埋めないで」。
完了の目印は、削るべき主張が明確になっていること。
17｜題名から公開前検査まで、一つの制作線にする
題名、構成、本文、事実確認、HTMLを別々の会話で作ると、途中で約束が変わります。タイトルは50選なのに49個しかない。
最新版なのに基準日がない。長文なのに後半が前半の言い換えになる。
制作線が切れると、こうしたズレが増えます。
Codexには、タイトルの名詞、数字、読者利益を最初に分解させます。構成の段階で回収場所を決め、完成後にもう一度突き合わせる。
作る役と検品する役は分けても、最初の約束は共通で持たせます。
頼み方は「このタイトルが約束していることを分解し、構成、本文、検品、貼り付け用HTMLまで同じ約束を維持して」。
完了の目印は、タイトルの各要素から本文の回収箇所を示せること。
調査・発信部を一本の仕事として使う例
最新AIの記事を作るなら、最初の検索で本文を書き始めません。
まず公式発表と公式GitHubを集め、公開日、対応環境、対象プラン、正式版か試験版かを確認します。
二次記事にしかない数字は、一次情報へ戻れなければ本文から外す。ここで記事へ使える事実と、まだ書けない主張を分けます。
次に、Xで反応が集まっている投稿やコメントを見ます。目的は仕様の確認ではなく、読者がどこで止まっているかを知ることです。
「便利そう」より、「起動しない」「前より重い」「毎回同じ説明をする」「利用枠が減る」の方が、記事の入口になります。
公式は事実、コメントは困りごと。役割を混ぜません。
材料がそろったら、タイトルを本文より先に比較します。「最新版」と書ける材料があるか。
「5選」なら別々の5項目があるか。「実測」と書くなら同じ条件の前後比較があるか。
約束を決めてから構成を作り、本文、事実確認、HTMLまで同じ線で進めます。
最後に別の検品役へ、数字、日付、出典、未検証の使用感だけを見せます。
調査担当が書いた文章を上手に直すのではなく、書いてはいけない箇所を見つける仕事です。
この一連の流れができると、「検索して長く書く」が「根拠を集め、読者の症状へ翻訳し、公開できる状態まで検査する」へ変わります。
制作部｜文章以外の完成物まで進める9選
Codexの価値は、下書きが速いことだけではありません。
文章を資料、画像、動画の設計、Webページへつなぎ、実際に開けるファイルまで持っていけます。
ここでは「案を出した」で止めず、使える状態を完成条件にします。
18｜タイトルを10案出し、本文より先に約束を検査する
タイトルを最後に付けると、本文にある言葉の要約にしかなりません。先に10案を作る目的は、派手な言葉を増やすことではありません。
読者、困りごと、得られる物、根拠の組み合わせを比較するためです。
「最新版」なら基準日、「50選」なら重複のない50項目、「実測」なら条件と生データが要ります。タイトルが大きくなるほど、必要な材料も増える。
本文で回収できない約束は、強化ではなく誇張です。
頼み方は「本文はまだ書かず、読者、具体的な困りごと、読後の成果物が違う10案を出して。数字は確認済みだけ」。
完了の目印は、各案に必要な根拠と弱点が分かること。
19｜長文記事を、構成で一度止めてから完成させる
2万字の記事を一気に書かせると、前半だけ具体的で後半が薄くなりやすい。構成で止め、各大見出しに新しい情報があるかを見る方が速いです。
見出しを入れ替えても意味が変わらないなら、論理ではなく項目の羅列になっています。
各章へ、主張、根拠、具体例、使えない条件、読者が持ち帰る物を割り当てます。全部の章へ同じ要素を詰める必要はありません。
ただし、新情報がない章は削る。文字数は材料の結果であって、先に水増しする理由ではありません。
頼み方は「2.5万字を書く前に、各章の新情報、根拠、前章との違いを1行ずつ出して」。
完了の目印は、構成だけ読んでも記事の展開が説明できること。
20｜一つの正本を、媒体ごとに作り直す
X記事を短くすれば通常ポストになる。動画台本を文字にすればメールになる。
そう考えると、媒体の違いが消えます。横展開で残すのは中心の事実と主張。
変えるのは入口、順番、長さ、見せ方、行動です。
X記事は深い判断、通常ポストは一つの気づき、動画は最初の画、メールは用件を先にします。
同じ文章を切って貼るのではなく、元資料を共有して別々に設計する。これなら、一つの調査が何度も働きます。
頼み方は「この正本から、X記事、210字の投稿、60秒動画を別々に作って。共通の事実は保ち、書き出しを使い回さないで」。
完了の目印は、三つを並べても同じ文章の短縮版に見えないこと。
21｜60秒動画を、秒数と画面つきで作る
台詞だけの動画台本は、撮影や編集で止まります。0〜3秒に何を見せるか、字幕は何文字か、画面がいつ変わるか、最後に何を残すかまで決めます。
情報量より、一画面一役が基本です。人物が話す、画面録画を見せる、数字を出す。
これを同時に詰めると視線が迷う。最初の3秒で約束し、途中で実物を見せ、最後に判断を置くと、台本が編集指示へ変わります。
頼み方は「60秒を0〜3秒、3〜15秒、15〜45秒、45〜60秒へ分け、映像、字幕、音声、切り替え理由を出して」。
完了の目印は、編集者が追加質問なしで素材を並べられること。
22｜サムネを、文言だけでなく構図まで比較する
タイトル10案を出しても、同じ写真へ文字を替えただけでは違いが弱い。
サムネは、誰を主役にし、どの道具を見せ、文字をどこへ置くかまで含めて一案です。
悩みを見せる案、結果を見せる案、比較を見せる案、人物の権威を使う案を分けます。落とした理由も残すと、次回の好みをルールとして残せる。
ただし、投稿結果は画像だけで決まらないため、一枚の勝ちを万能型にしません。
頼み方は「同じ記事から、切り口が違うサムネ案を5つ。背景、主役、文字、色、避ける誤解まで出して」。
完了の目印は、縮小しても主役と文字が読めること。
23｜画像を作り、残す部分と変える部分を分ける
Codexは画像生成や画像入力を扱えます。
新しい画像を作るだけでなく、元画像を見て「人物は残す」「背景だけ変える」「商品形状は変えない」と範囲を指定できます。
編集で崩れやすいのは、顔、手、商品の文字、ロゴ、細かな形です。変更を重ねるほど最初の版との差が見えにくくなるため、版を保存します。
人物写真や商品画像は、使う権利と公開範囲も先に確認します。
頼み方は「この画像で絶対に残す物と、変更してよい物を一覧にしてから編集して。完成後に元画像との違いを報告して」。
完了の目印は、見た目の好みだけでなく、残す条件を守ったか確認できること。
24｜スライドを、実際に開けるファイルまで作る
スライドの構成案だけなら、最後は人がPowerPointを開いて作り直します。
Codexへ渡すなら、誰が何を判断する資料かを決め、実ファイルまで作らせます。
一枚一メッセージを基本に、表の列数、グラフの意味、出典、文字量を決める。派手な装飾より、会議でどの順に話すかが先です。
完成後はファイルを開き、文字の見切れ、画像の粗さ、数字、ノート欄を確認します。
頼み方は「経営会議で5分説明する10枚の資料を作って。1枚目で結論、各数字に出典、最後に未決事項。
PowerPoint形式まで」。完了の目印は、説明者が画面を直さず通して話せること。
25｜表や文章を、確認できるPDFへ変える
提案書、手順書、報告書は、文章が正しくてもPDFで崩れます。
改ページ、表のはみ出し、URL、ページ番号、見出しの位置は、元データだけでは分かりません。
Codexには内容を作らせた後、PDFへ変換し、ページ画像を見て検査させます。文字の重なりや空白ページは目で見る。
送付前には宛名、日付、版、機密表示も確認します。
頼み方は「この原稿をA4のPDFへ。見出しの直後で改ページしない、表を横へ切らない、URLをクリック可能にして。
生成後に全ページを検査して」。完了の目印は、元ファイルではなく最終PDFを開いて合格していること。
26｜簡単なWebページを、実際の画面まで作る
料金計算、質問票、比較表、作業状況の確認など、文章より小さな画面の方が使いやすい仕事があります。
Codexなら、説明からHTMLや簡単なアプリを作り、ブラウザで動作確認できます。
最初から大きなサービスを作る必要はありません。入力、押すボタン、出る結果を一つに絞る。
個人情報を保存する、決済する、外部へ公開する場合は別の安全設計が必要です。まずPC内で動く試作品から始めます。
頼み方は「入力3項目、結果1画面の試作品を作って。外部通信、ログイン、データ保存は入れない。
ブラウザで入力から結果まで確認して」。完了の目印は、説明書を読まなくても一度操作できること。
制作部を一本の仕事として使う例
一つの調査から、X記事、短い投稿、60秒動画、スライドを作る場面を考えます。最初に作るのはX記事です。
理由は、出典、判断、注意点まで入る正本を一つ作れるから。
正本がないまま短文や動画から始めると、あとで詳しい説明を足した時に数字や結論がズレます。
記事が完成したら、媒体ごとに別の依頼を出します。短い投稿は、一つの症状と一つの変化へ絞る。
動画は0〜3秒の画を決め、話す言葉より先に何を見せるかを置く。スライドは会議で判断する順番へ並べ、X記事の段落順をそのまま使わない。
サムネはタイトルの短縮ではなく、悩み、結果、比較のどれを一枚で見せるかを選びます。
画像生成を使う場合は、人物、商品、文字、背景のうち、変えてよい物を限定します。
Webページへする場合は、読ませるだけでなく、何を入力し、何が返るかを一つに絞る。
そして全部の成果物で共通する数字と固有名詞を、正本へ戻って照合します。
これで一つの内容を何度も使えます。ただし、同じ文章を何度も使うわけではありません。
再利用するのは、確認済みの事実と判断。作り直すのは、読者が最初に見る入口です。
事務・数字部｜ファイル、表、PC作業を減らす9選
事務作業は一つひとつ短いのに、開く、探す、写す、確認するが積み重なります。この部署では、判断まで丸投げしません。
探す、そろえる、下書きする、異常を示す所までをCodexへ渡す設計です。
27｜散らかったフォルダを、削除せず健診する
Downloadsや案件フォルダには、同じ資料の別名、古い完成版、大容量の一時ファイルが残ります。
いきなり整理すると、必要な物まで消す危険があります。最初は健康診断です。
重複候補、古い版、容量が大きい物、名前が曖昧な物を一覧にします。更新日だけで不要と決めない。
別のファイルから参照されている可能性もあるため、理由と確信度を付けます。
頼み方は「削除も移動もせず、重複、古い版、大容量、名前が分かりにくいファイルを一覧にして。必要か判断できない物は別枠へ」。
完了の目印は、人が候補を見て選べること。自動削除はその後です。
28｜請求書や領収書を、ひな形から下書きする
宛名、金額、日付、振込先を毎回入力する作業は機械的です。ひな形と確定情報があれば、PDFの下書きまで作れます。
ただし、税、番号、支払い条件は事業や取引ごとに違います。
元となる契約や注文内容を一緒に渡し、空欄を推測で埋めない条件も欠かせません。作成と送信は分ける。
金額が合っていても、宛名や振込先の間違いは信用へ直結します。
頼み方は「この契約内容とひな形から請求書の下書きを作って。不足は空欄で残し、金額、宛名、日付、振込先を最後に照合して」。
完了の目印は、照合結果と未確認欄がPDFとは別に残っていること。
29｜領収書から、日付・店名・金額を一覧にする
画像やPDFの領収書を一枚ずつ開き、表へ写す作業は時間がかかります。
Codexなら、日付、店名、金額、税、支払い方法などを抽出し、一覧へまとめられます。
読めない文字を勝手に補わない条件は欠かせません。勘定科目は候補までにし、最終判断は本人か税理士へ残す。
元画像は移動せず、一覧から原本へ戻れるファイル名を付けます。
頼み方は「領収書を日付、店名、金額、税へ分け、読めない箇所は空欄。元ファイル名も残してCSVへ」。
完了の目印は、抽出件数と原本件数が一致し、空欄だけを人が確認できること。
30｜形式の違うCSVを、元データを守って一つにする
売上、広告、アクセス解析のCSVは、日付形式や列名がばらばらです。
単純に縦へ結合すると、金額が文字列になり、同じ注文が重複し、空欄が0へ変わることがあります。
統合前に列の対応表を作り、日付、通貨、文字コード、重複の基準を決めます。元ファイルは変更せず、加工後を別名で保存する。
何を直したかの記録も残します。
頼み方は「このCSV群をまだ結合せず、列名、形式、欠損、重複候補を比較して。対応表を承認後に統合して」。
完了の目印は、統合前後の行数と除外理由を説明できること。
31｜Excelへ追記し、数式と書式を壊さない
表へ一行追加するだけでも、コピー位置を間違えれば数式が切れます。Codexに任せる時は「追記する範囲」と「触らない範囲」を明確にします。
見出し、既存の計算式、入力規則、フィルターを確認し、新しい行だけ追加する。列を増やす場合は、何が下流の集計へ影響するかを先に調べます。
完成後は数式の件数と合計を比較します。
頼み方は「このExcelの構造を読み、新しいデータを末尾へ追記して。既存数式と書式は変更せず、変更セルだけ報告して」。
完了の目印は、追加した行だけでなく、既存の合計が意図せず変わっていないこと。
32｜数字が動いた理由を、影響の大きい順に出す
売上が落ちた時、合計だけ見ても次の手は決まりません。
商品数、単価、成約率、流入、キャンセルなどへ分け、どの変化が合計へ強く影響したかを見ます。
Codexは比較と理由候補を出せますが、因果関係までは自動で確定しません。
「広告を変えたから売上が落ちた」と言い切る前に、期間、母数、別の変化を確認します。データ不足なら、追加で必要な列を返させます。
頼み方は「前月比を出し、増減への影響が大きい項目を順番に。確認済みの変化、理由の仮説、追加で必要なデータを分けて」。
完了の目印は、次に確認する数字が一つ決まること。
33｜契約書は、読むべき場所を先に絞る
契約書をAIへ渡す目的は、法律判断を置き換えることではありません。
全文の中から、解約、支払い、自動更新、成果物の権利、損害、秘密保持など、当事者が確認すべき場所を見つけることです。
条文番号と原文を残し、「一般的な説明」と「この契約での意味」を分けます。不利かどうかは条件や交渉全体で変わるため、断定させません。
機密情報を外部サービスへ渡してよいかも先に確認します。
頼み方は「法的判断はせず、支払い、解約、権利、責任、更新の条文を番号つきで抜き、確認質問を作って」。
完了の目印は、専門家や相手方へ聞く質問が具体化していること。
34｜PCが重い時、原因候補を見える化する
Codexが重いからといって、Codexだけが原因とは限りません。
ブラウザのタブ、動画生成、メモリ、Cドライブ、同期アプリが同時に動いている場合があります。
先にCPU、メモリ、空き容量、GPU、プロセスを確認。
CLI 0.147.0には\codex doctor\があり、設定、認証、実行環境の診断入口として使えます。
ただし、プロセス終了やファイル削除は別の操作です。未保存データがあるアプリを勝手に閉じない条件を置きます。
頼み方は「変更せず、CPU、メモリ、空き容量、GPU、使用量の大きいアプリを調べ、Codex側とPC側の原因候補を分けて」。
完了の目印は、触る設定を一つに絞り、変更前後を同じ条件で測れること。
35｜ブラウザとWindowsアプリで、実際の動作を確認する
HTMLが正しい、リンクが文字として入っている、ファイルが作られた。それだけでは読者の画面で動く保証になりません。
ブラウザで開き、入力し、ボタンを押し、コピーして、貼り付ける所まで確認します。
Computer Useが使える環境では、画面を見ながらWindowsアプリを操作できます。
未保存データ、送信、投稿、購入、削除は確認で止める設計です。自動操作は便利ですが、画面に出ない背景処理まですべて安全に扱えるとは限りません。
頼み方は「読者と同じ入口から操作し、表示、入力、コピー、リンクを確認して。送信や公開の直前で止めて」。
完了の目印は、コードの検査ではなく実画面の結果が残っていること。
事務・数字部を一本の仕事として使う例
月末に領収書、売上CSV、請求書、契約書が一つのフォルダへ集まった場面です。ここで「全部整理して」は広すぎます。
最初は削除せず、ファイルの種類、件数、重複候補、読めない物を調べます。元データが何件あるかを確定しないと、処理後に欠けても気づけません。
領収書は日付、店名、金額へ分け、空欄を残します。売上CSVは列の対応表を作り、日付と通貨をそろえてから統合する。
請求書は契約内容と照合し、宛名、金額、振込先を別の検査へ回します。契約書は判断させず、読む条文と質問だけを抜く。
数字が一つにまとまったら、前月比を出します。増えた、減ったで終わらず、影響の大きい行や商品を示す。
理由は確定せず、確認済みの変化と仮説を分ける。ここまで来て初めて、人は次にどの数字を見るか決められます。
この部署で自動化しやすいのは、探す、読む、写す、そろえる、候補を出す作業です。
税務、法務、支払い、削除、顧客への送信は、人か専門家へ残します。事務を全部消すのではなく、判断前の準備を薄くする。
これなら非エンジニアでも境界を見失いません。
仕組み化部｜同じ説明を次回から消す8選
ここからが、チャットを便利に使う人と、仕事そのものを変える人の分かれ目です。
一度うまくいった作業を会話の中へ置いたままにすると、次回また説明します。手順、接続、検査、予定へ戻すと、二回目から短くなります。
36｜二回使った手順を、Skillへ変える
Skillは、特定の仕事を進める手順書です。入力、作業順、参考資料、完成条件、検査を一つにまとめられます。
長いプロンプトの保存ではなく、必要な資料や処理まで含むのが違いです。
一回だけの作業を何でもSkillにすると、探す方が大変です。同じ説明を二回した、同じ修正が続いた、別タスクでも再現したい。
このどれかが昇格の目印です。作った後は、別の新しいタスクで呼び出して検証します。
頼み方は「今完了した作業から、毎回変わる入力と変わらない手順を分け、再利用できるSkill案を作って。まだ登録せず内容を見せて」。
完了の目印は、元の会話がなくても同じ品質へ到達できること。
37｜Pluginで、Skillと外部接続を一つにまとめる
Pluginは、Skill、外部サービスとの接続、指示、作業の流れをまとめた入れ物です。
2026年6月、OpenAIはデータ分析、制作、営業など6つの役割別Pluginを発表しました。
合計62アプリ、110 Skillを含むと説明しています。
0.147.0ではAgent Pluginsの導入と検索が追加され、PC内、個人用、作業場所、外部カタログを横断して探せるようになりました。
ただし、利用できるPluginや接続先は地域、プラン、管理者設定で変わります。
頼み方は「この仕事に既存Pluginがあるか探し、入れる前に権限、接続先、できる操作、代替手段を説明して」。
完了の目印は、便利さより先に、何へアクセスするかを理解できていること。
38｜MCPで、外部サービスとの受け渡しを減らす
MCPは、Codexと外部の道具をつなぐ共通規格です。対応するサービスへ接続すると、情報を読み、許可された操作を実行できます。
人が結果をコピーして別の画面へ貼る運搬作業を減らせます。
最初から書き込み権限を渡す必要はありません。読み取り、下書き、更新、送信を分けます。
0.147.0はMCP 2026-07-28規格へ試験的に対応しましたが、既存接続が安定している人は急いで変更しなくて構いません。
頼み方は「この連携で必要な最小権限を、読み取り、下書き、変更、外部送信へ分けて。最初は読み取りだけで試して」。
完了の目印は、接続できたことではなく、意図しない書き込みが起きないこと。
39｜Hooksで、絶対に外せない検査を強制する
AGENTS.mdに「公開前に確認」と書いても、文章による指示です。長い作業の途中で抜ける可能性があります。
Hooksは、特定の操作前後に必ず処理を走らせる仕組みです。
削除前に対象を表示する。公開前にリンク検査を走らせる。
秘密情報が含まれていたら止める。こうした「お願いで済ませたくない境界」に向きます。
ただし、Hook自体が危険な処理を含めば逆効果です。内容と信頼元を確認します。
頼み方は「この事故を文章の注意ではなく、操作前に必ず止める検査へ変える案を出して。Hookの中身と失敗時の動作も説明して」。
完了の目印は、わざと失敗条件を入れ、本当に止まること。
40｜Scheduled tasksで、毎日・毎週の仕事を予定実行する
デスクトップアプリでは、決まった時間にタスクを動かせます。
朝の公式ニュース確認、毎週の数字集計、フォルダの健診など、頻度と入力が安定した作業に向きます。
最初から予約しない方がいい。手動で一度も完走していない手順を自動化すると、失敗を決まった時間に繰り返します。
ローカルファイルを使う場合は、PCやアプリの状態にも左右されます。投稿、購入、削除は予定実行の外です。
頼み方は「この手順をまず手動で実行し、成功条件、失敗時の停止、必要なPC状態を確認してから予定タスク案へ変えて」。
完了の目印は、実行回数ではなく、失敗した時に何も壊さず止まること。
41｜Goalへ、長い仕事の終わりを置く
数日かかる仕事は、今日の指示だけでは終わりがぼやけます。Goalには「何を作るか」より、「どの状態になれば完了か」を置きます。
サイトを作る、ではなく、スマホ検査とリンク確認が済み、公開直前まで完成している、までがGoalです。
途中で別の作業が入っても、戻る場所が残ります。ただし、Goalは勝手に公開範囲や権限を広げません。
長く続ける目的と、その都度必要な承認は別です。
頼み方は「この仕事を複数日に分けても迷わないGoalへ変えて。完了条件、途中成果、止まる条件を含めて」。
完了の目印は、残り作業が『だいたい』ではなく一覧で分かること。
42｜増えたSkillを、用途別の索引へまとめる
Skillが増えると、作ったこと自体を忘れます。似た名前が並び、毎回新しく作れば、仕組み化が新しい散らかり方になる。
そこで、名前、用途、入力、出力、使わない条件を一枚へまとめます。
索引は自動で実行する仕組みではありません。人とCodexが「すでにある物」を思い出す入口です。
重複するSkillは統合候補へ出し、古い仕様は更新日を付けます。
頼み方は「利用可能なSkillを読み、用途別に分類して。似た物、古い物、現在の仕事へ使えそうな物を分けて」。
完了の目印は、新しい依頼の前に索引から候補を一つ選べること。
43｜複数工程を、一本の仕事へつなぐ
調査、原稿、画像、HTML、検品を個別に自動化しても、工程の間で人が毎回ファイルを探せば止まります。
最後は、一つ前の出力を次の入力へ渡す流れを設計します。
ただし、全部を一気につなぐ前に、各工程の単独成功が先です。途中へ承認点を置き、失敗した工程だけやり直せるようにする。
最初から巨大な自動化を作ると、どこで壊れたか分からなくなります。
頼み方は「この仕事を入力、判断、作業、承認、出力へ分け、今つなげてよい工程と、まだ人が確認する工程を示して」。
完了の目印は、失敗時に最初からやり直さず、止まった工程から再開できること。
仕組み化部には、昇格の順番がある
自動化は、最初からScheduled tasksを作ることではありません。
順番は、手動で一度成功し、同じ手順をもう一度使ってからSkillへする。
失敗を検査へ変え、必要なら外部サービスへつなぎ、最後に予定実行します。
たとえば毎週のレポートなら、最初の週はCodexと一緒に数字の場所を確認します。二週目は、同じ入力から同じ表が出るか試す。
違う列名や欠損が見つかったら、手順へ戻す。三週目にSkillへし、作る役と検品する役を分ける。
手動で安定した後だけ、月曜朝の予定へ置きます。
途中で外部サービスが必要なら、MCPやPluginの最小権限を考えます。表を読むだけで良いのに、削除や送信まで許可しない。
公開前にリンク検査が必須ならHooksへ置く。Skillが増えたら索引を作り、使われない物を減らす。
各機能は、困りごとの置き場です。
ここを飛ばすと、自動化したのに人が毎朝エラーを直す状態へ変わる。それは時間を空ける仕組みではなく、決まった時間に仕事を増やす仕組みです。
自動化の合格は、動いた回数ではありません。失敗時に安全に止まり、人が見る場所が一つへ絞られていることです。
エージェント統括部｜複数のAIと0.147.0を使う7選
最後は、一つのCodexへ全部を任せる段階から、役割を分ける段階です。速さが増える一方で、利用枠、権限、ファイル衝突も増える。
人の仕事は減るというより、何を渡し、何を採用し、どこで止めるかへ移ります。
44｜Subagentsへ、独立した調査を並列で渡す
公式情報、競合、読者の声のように、互いの結果を待たず進められる仕事はSubagentsへ分けられます。
一つずつ調べるより早く、最後に主担当が統合できる。
向いていないのは、同じファイルを同時に編集する作業です。変更が衝突すると、どちらが正しいか判断できません。
最初は読む仕事だけを並列化し、出力形式と担当範囲をそろえます。Subagentsは一体より利用枠を使う点も忘れません。
頼み方は「公式、実務例、反対意見を別々のSubagentへ。全員読み取りだけ、同じ形式で出し、最後に主担当が矛盾を確認して」。
完了の目印は、三つの結果を混ぜる前に出典と違いが残っていること。
45｜作る担当と、疑う担当を分ける
同じ会話で記事を作り、「間違いない？」と聞くと、前提ごと見落とすことがあります。
自分の答案を自分で採点する形だからです。公開物は、制作と検品を分けます。
検品役には文章を良くさせません。数字、日付、固有名詞、出典、タイトルの未回収、架空体験だけを見る。
修正まで同時に任せると、指摘の証拠が消えます。まず問題一覧、次に制作側が修正、最後に再検査です。
頼み方は「制作内容を引き継がず、完成物と根拠だけを読んで検査して。修正はせず、問題、場所、理由、根拠を出して」。
完了の目印は、『問題なし』ではなく、何をどう確認したかが残ること。
46｜Worktreeで、AIごとの作業場を分ける
複数のAIが同じフォルダを触ると、片方の変更をもう片方が上書きします。
Git Worktreeは、同じプロジェクトから別の作業場を作り、変更を隔離する方法です。
別案のサイト、機能追加、長い修正を並列で進め、良い方だけ採用できます。ただし、Gitを使わない文書フォルダへ無理に導入する必要はありません。
単純な原稿なら複製でも足ります。人数を増やす前に席を分ける、という判断です。
頼み方は「この2案を同じファイルへ書かず、別の作業場で進める方法を示して。採用と破棄の手順も」。
完了の目印は、片方を消しても元ともう片方が壊れないこと。
47｜--approve-for-meで、承認待ちを自動審査へ回す
0.147.0で追加された\--approve-for-me\は、承認要求を自動審査へ回すCLIオプションです。
すべてを無条件で許可する機能ではありません。\workspace-write\の安全境界と組み合わせる設計です。
長い作業が何度も確認待ちで止まる場合の候補です。一方、外部送信、公開、決済、重要ファイルの削除へ使う設定ではありません。
最初は復元できる作業フォルダで試し、何が自動承認され、何が止まるかを記録します。
頼み方の前に、CLIでは\codex --approve-for-me\の意味と対象を確認します。
完了の目印は、止まる回数が減ったことだけではなく、守るべき境界で実際に止まったこと。
48｜CursorのSkillと外部会話を、確認して取り込む
0.147.0では、Cursorが管理するSkillの取り込みに対応しました。
ClaudeやCursorから取り込んだ会話を、重複なく同期する改善も入っています。
別のAIで作った手順を、すべてゼロから作り直さず移せます。
ただし、元のAI向けの命令がCodexで同じ意味になるとは限りません。
秘密情報、古い保存先、別アカウントの人格、存在しないツールが混ざっていないかを確認します。移行はコピーではなく、棚卸しの機会です。
頼み方は「取り込む前に、Codexで使える部分、書き換えが必要な部分、削除すべき秘密情報と別人格を分類して」。
完了の目印は、取り込み後の新しいタスクで実行し、元環境なしでも完走すること。
49｜長い会話を区分し、日本語とWindows修正を受け取る
0.147.0では、会話を固定した区分へ整理し、手動で順番を変え、長い履歴を少しずつ読める機能が追加されました。
調査、構成、制作、検品が続く仕事で、決定した条件を探しやすくなります。
同じ版では、日本語、絵文字、リンク周辺の表示位置、Windowsのパス、背景処理の中断も修正されました。
古い版で文字がずれる、止めた処理が残る症状があるなら、設定を壊す前に版を確認します。更新前にはReleaseの削除項目も読みます。
頼み方は「現在の版を確認し、最新Releaseから、この症状に関係する修正と、更新で変わる操作を出して」。
完了の目印は、更新前後で同じ手順を試し、症状が変わったかを確認すること。
50｜良いプロンプトより、雑な依頼でも崩れにくい環境を作る
50個の最後は、機能ではありません。毎回完璧な指示を書こうとすると、疲れた日は品質が落ちます。
強い環境は、短い依頼でも必要な前提を読み、安全な範囲で動き、完成後に自分で検査します。
人格と目的はAGENTS.md。繰り返す手順はSkill。
外部接続はPluginやMCP。必須検査はHooks。
予定作業はScheduled tasks。長い目的はGoal。
複数の読み仕事はSubagents。失敗したら、注意文を増やすのではなく、原因に合う置き場へ戻します。
頼み方は「最近の依頼と修正履歴を読み、毎回変わる入力、固定すべき前提、Skillへする手順、機械的に止める事故へ分類して」。
完了の目印は、次の新しいタスクで指示文が短くなり、検品結果は落ちないこと。
エージェント統括部を一本の仕事として使う例
新しいAIツールの比較記事を、三つのSubagentで調べるとします。
一体目は公式仕様、二体目は公開されている実務例、三体目は弱点と反対意見。
三体とも読み取り専用にし、出力を「主張、根拠、日付、URL、未確認」へそろえます。ここでは速さより、役割を混ぜない方を優先する。
主担当は三つの結果を統合します。同じ数字が一致しているか、公式と実務者で対象条件が違わないか、弱点が本文に反映されているかを確認する。
記事を書く担当は材料から構成を作り、別の検品担当は完成物と根拠だけを見ます。同じ会話の勢いで「問題なし」にしません。
複数の担当がファイルを直すならWorktreeで席を分けます。
長い作業の承認待ちが多い場合だけ\--approve-for-me\を検討し、復元可能な作業場所で境界を試す。
外部環境からSkillを移すなら、秘密情報と別人格を先に外します。
0.147.0の新機能は、全部使うためではなく、詰まっている場所へ選んで入れる物です。
人間が最後に見るのは、全担当の細かな会話ではありません。どの材料を採用したか、何が未確認か、どの検査に通ったか、どこで承認したかです。
AIを増やすほど、人は作業者から責任者へ近づきます。
50選を使う前に外したい、5つの勘違い
50個を並べると、上から順に全部入れたくなります。僕も機能の多さに引っぱられそうになる。
ですが、機能を増やすほど仕事が減るわけではありません。置き場と境界がないまま接続や自動化を増やすと、確認する画面だけが増えます。
AIに働いてもらうはずが、AIの世話係になったら逆なんですよね。ここでは、特に止まりやすい勘違いを先に外す。
長い指示を書けば、出力は安定する
長い指示が必要な場面はあります。ただ、毎回同じ20行を書く状態は、説明が整理されていない合図です。
読者、保存先、禁止事項、完成条件が毎回同じならAGENTS.md。作業順が同じならSkill。
事故を止めたいならHooksへ置きます。
長文をさらに長くしても、古い条件と新しい条件が競合すれば迷いは増えます。
安定させる判断は「何文字書くか」ではなく、「今回だけ変わる情報は何か」です。依頼文には今回の入力を残し、変わらない前提は環境へ移す。
これで短い依頼でも、必要な条件を失いません。
一度動いたら、自動化してよい
一回の成功には、たまたま資料名がそろっていた、空欄がなかった、同じ人が確認したなど、見えていない条件があります。
予定実行や外部接続へ進む前に、別の日、別の入力でもう一度試します。
二回目で止まった場所は失敗ではありません。Skillへ入れる例外や、Hooksで止める条件が見つかったということです。
少なくとも、正常な入力、欠けた入力、重複した入力を試し、どこで人へ戻すかを決める。
自動化は成功を繰り返す仕組みではなく、失敗を安全に扱う仕組みまで含むものです。
Codexが出した数字は、確認済みの数字である
Codexは資料から数字を探し、計算し、比較できます。
しかし、元資料が古い、対象期間が違う、単位が混ざる、空欄を0として扱う可能性は残ります。入力が違えば、きれいな計算にも意味はありません。
数字には、元ファイル、対象期間、単位、計算式を残します。外部の数字ならURLと確認日、実測ならPC環境と前後条件を付ける。
出力された数字を信じるのではなく、戻れる状態にする。記事、請求書、売上分析で共通するルールです。
Subagentsを増やせば、必ず速くなる
独立した調査は並列化できますが、同じ資料を読み、同じ形式で答え、同じファイルを直すだけなら、統合と確認の仕事が増えます。
利用枠も一体より多く使います。
分ける基準は人数ではなく、依存関係です。一体目の結果がないと二体目が進めないなら順番にする。
別々に読めるなら並列にする。同じファイルを触るならWorktreeを使う。
主担当には統合と最終判断を残す。AIを増やす前に、役割の境界を一文で言えるかの確認が先です。
公開まで自動化できて、初めて完成である
投稿、メール送信、購入、契約、顧客データの更新まで自動で進めれば、人の操作は減ります。その代わり、一回の誤りが外へ出ます。
制作が速くなったからといって、公開判断まで同じ速さへ合わせる必要はありません。
Codexには公開直前まで作らせ、タイトル、本文、画像、リンク、出典、公開先を人が確認する。
毎日同じ情報を内部集計する仕事と、外部へ発信する仕事は分けます。
自動化の終点は「人が一切触らない」ではなく、「人が責任を持つ判断だけ残っている」です。
この5つを外すと、50選は機能カタログではなく、仕事の設計図として読めます。
新しい機能を見つけたら、使えるかより先に、どの部署の何を減らし、どの確認を残す物かを考えます。
結局、Codexへ「6つの部署」を持たせられるか
50個の使い方に共通するのは、プロンプトの長さではありません。
調査のたびに検索条件を書く。記事のたびに文体を説明する。
請求書のたびに保存先を探す。公開のたびに同じ検査を思い出す。
この状態では、Codexを使う回数が増えても、人の管理作業はあまり減りません。
反対に、土台管理部が前提を持ち、調査・発信部が根拠を集め、制作部が完成物へ変える。
事務・数字部は記録をそろえ、仕組み化部は二回目の説明を消し、エージェント統括部は役割と安全を管理する。
ここまで分かれると、依頼は短くなります。
OpenAI自身も、Codexを開発者だけの道具として説明していません。
2026年6月の公式発表では、非技術職がレポート、表計算、プレゼン、契約書などを作っているとしています。
用途は調査、分析、自動化、軽い道具の制作まで広がっています。
役割別Plugin、Sites、Annotationsが出てきた理由も、コードを書く画面から、仕事を完成させる場所へ広がっているからです。
ただし、AIへ全部渡せばいいわけではありません。
公開するか。送信するか。
お金を払うか。契約へ同意するか。
重要なファイルを消すか。顧客へ何を約束するか。
ここは最後まで人の仕事です。Codexが担当する範囲を増やすほど、承認の境界ははっきりさせます。
最初の一個を選ぶなら、1番のAGENTS.mdです。
あなたが今日やっている仕事を一つ開き、「毎回変わる情報」と「毎回変わらない手順」を分ける。変わらない方だけを説明書へ置く。
次の新しいタスクで、前置きを書かずに同じ仕事を頼む。
そこで同じ品質が出れば、Codex活用が一回の会話から、再利用できる仕事へ変わり始めています。
自分に合う最初の部署を選ぶ
調べ直しが多いなら、8と16から始めます。文章を何度も直しているなら18と19。
ファイルを探す時間が長いなら27。表への転記がたまるなら29〜31。
同じ依頼を毎週書いているなら36。複数のAIが同じファイルを触って壊れるなら46です。
逆に、まだ一度も成功していない仕事を40の予定実行へ入れない。戻し方がないファイルへ47の自動審査つき承認を使わない。
権限が分からない外部サービスを38でつながない。上級機能を使わない判断も、立派な活用です。
一週間後に見る数字は、AIを何回使ったかではありません。完成した物の数、手戻り、確認待ち、作業時間、事故、次回も使える手順が増えたかです。
数字が変わらなければ、機能を足す前に、どこで人の作業へ戻っているかを見ます。
50個の中から一つ選び、手動で成功させ、次回の説明を一つ消す。僕が見たいのは、機能をいくつ覚えたかより、明日の作業が本当に一つ減ったかです。
まずは一つで十分なんですよ。
確認した公式情報
OpenAI：あらゆる役割、ツール、ワークフローに対応するCodex（2026年6月2日）
OpenAI：Codex is becoming a productivity tool for everyone（2026年6月2日）
