KOKaizenOpsAI workflow operations

Coding Agentを触ってみる (Codex)

Codexを実際に触ってみましょう

それでは実際に Codex を触ってみましょう。

project の設定、Plugin を利用した外部ツールとの接続、Skill の作成、Automation の作成、Permissions、Intelligence、Plan モードなど、Coding Agent を実務で使ううえで重要になる基本的な考え方を見ていきます。

これらの機能やプラクティスは、Codex だけに閉じたものではありません。Claude Code や Devin など、他の Coding Agent でも似た考え方や機能が整備されつつあります。Coding Agent のエコシステム全体として、外部ツールにつなぐ、作業手順を Skill 化する、定期実行する、実行権限を管理する、難しい作業では先に plan を作る、といった必要性が高まっているためです。

そのため、この lesson では「Codex のこのボタンを押す」という説明に終始するのではなく、Coding Agent で大きく何ができるのか、どのような考え方で使うとよいのかということを意識した解説をしていきます。Codex で一度この流れを体験しておくと、他の Coding Agent を使うときにも同じような観点で試せるようになります。

Codexが作業するprojectの設定

Codex Desktop App では、最初に local の folder を選択します。ここで選んだ folder が、Codex が作業する project になります。

Codex は、この project folder の中を読みながら作業します。Codex にファイルを作成させたり、既存ファイルを編集させたりした場合、その生成物や変更内容は基本的にこの project folder の中に保存されていきます。

まずは、空の folder でも構いません。たとえば codex-practice のような folder を作り、それを Codex Desktop App で選択してみましょう。

Gmail Pluginで返信ドラフトを作る

ここでは、Gmail を使って「返信すべきメールを探し、返信案の draft を作る」タスクを Codex に依頼してみます。

そのためには、まず Codex Desktop 左上の Plugins から Gmail を選択し、Gmail への接続を済ませておきます。普段 Outlook Email を使っている場合は、自分の環境で Outlook Email Plugin が利用できるかを確認したうえで、以下のプロンプト中の Gmail を Outlook Email に置き換えてください。

Gmail Pluginを指定して返信ドラフト作成を依頼する画面

Codex で Plugin を明示的に使いたい場合は、@Gmail のように @ で利用したい Plugin を指定します。

@Gmail を使って、返信すべきメールがあるか確認してください。過去の返信内容を参考にして、返信案のドラフトもGmail上で作成してください。

ルール：
- Primary Inboxにあるメールを対象にしてください。
- 何かを要求しているメール（クレジット、イベント関連、仕事依頼など）すべてに返信する必要はありません。また、ニュースレターも必要ありません。本当に正当そうなものだけ返信対象にしてください。
- こちらが最後に連絡をしているが、まだ1週間以上返信がないものについては、状況確認や催促のドラフト作ってください。
Gmail Pluginに返信ドラフト作成を依頼するプロンプト入力画面

Gmail や Outlook Email 上に返信 draft が作られたでしょうか。もしエラーが出た場合は、そのエラー内容も Codex に貼り付けて、どう直せばよいか聞いてみてください。

繰り返す作業をSkill化する

この Gmail triage がうまく動いたら、次に考えたいのは「これを今後も繰り返せるようにする」ことです。

毎回同じルールを長く書くのは大変です。また、今後「この種類のメールは無視する」「この相手には少し丁寧に返す」といった細かいルールが増える可能性もあります。そのような繰り返し作業は、Skill にしておくと扱いやすくなります。

たとえば、次のように Codex に依頼してみましょう。

今後この作業を定期的に行いたいです。また、細かいルールも今後増やせるようにしていきたいです。ここで行った Gmail triage と返信 draft 作成の流れを Skill にしてください。Skills はグローバルではなく、この project 内に作ってください。

Codex はこの指示をもとに、Skill を作成してくれます。

ここで書いている「Skills はグローバルではなく、この project 内に作ってください」についても少し補足しておきます。Skills には、自分のすべての project で使えるグローバルな Skill と、特定の project だけで使う project 内 Skill があります。

今回の Gmail triage は、他の project（例えば資料作成）などで使っていくことは想定できません。そのため、最初からグローバルにしてすべての project で使うよりも、まずは project 内 Skill として作り、project 内で改善していくほうが自然な流れになります。グローバルの Skill とし、project 横断で使えるようにしても良いですが、Skill が増えすぎると Coding Agent の判断材料が増え、思考に時間がかかったり、振る舞いが不安定になることがあります。Coding Agent には smart に必要最低限の情報を与える仕組みづくりを心がけていきましょう。

何度か使ってみて、「これは他の project でも同じように使えそうだ」と分かってきたら、その時点でグローバルな Skill に移すことを考えれば十分です。最初から完璧な Skill を作る必要はありません。よく使う仕事を小さく Skill 化し、使うたびにルールを足して育てていく、という感覚で進めてみてください。

出来上がった Skill の使い方については、Codex に「この Skill はどうやって実行できるのですか」と聞いてみてください。答えてくれます。

作成したSkillの実行方法をCodexに確認する画面

Automation

Skill にできたら、次はそれを決まった時間に実行するといった自動化プロセスを作ることもできます。たとえば同じ Codex の中で、「毎朝7時にこの Gmail triage が実行されるような Automation を作って」と指示してみてください。

また、Codex の UI にある Automations の機能から、schedule と prompt を設定して実行することもできます。Codex の Automations については、公式 docs も参照してください。Codex App Automations

Permissionsを理解する

Codex に作業を依頼していると、「この操作を実行してよいか」と何度か確認されたと思います。これは、Codex がむやみに大事なファイルを変更したり、外部サービスにアクセスしたりすることを防ぎ、安全性を高めるためです。

この確認回数を調整するために、Codex には Permissions の考え方があります。2026年5月時点では、代表的には次のような考え方で理解すると分かりやすいです。

  • Default Permissions: 通常の設定です。Codex は project 内での読み取りや編集を行えますが、project の外を編集したり、ネットワークアクセスが必要な操作をしたりする場合には確認が入ります。
  • Auto Review: 承認が必要な操作を、実行前に Codex 側の reviewer agent が確認する設定です。sandbox の外に出る操作、network access、権限要求、副作用のある App / MCP tool call などを対象に、データ持ち出しや破壊的操作などのリスクを見ます。
  • Full Access: 制限を大きく緩め、確認を減らす設定です。便利な一方で、重要なファイル変更や外部アクセスのリスクも高くなるため、信頼できる project でだけ慎重に使うべきです。

人間の確認の手間とセキュリティはトレードオフです。実行する内容のセキュリティ要件に応じて、Permissions を変更してみてください。

Intelligenceとモデルを選ぶ

Codex の画面右下には、5.5, High のように model と Intelligence の設定が表示されることがあります。クリックすると、model や Intelligence のレベルを切り替えられます。

Intelligence は、どれくらい深く考えさせるかの設定だと理解すると分かりやすいです。Codex だと、Low、Medium、High、Extra High のような段階を選べます。

例えば簡単なタスクでは Low や Medium を使い、高速にタスクを実行させる。難しいタスクでは、Extra High を使うといったプラクティスになります。ただし、毎回 Extra High にすると、考える時間が長くなりすぎることがあったり、考えすぎてうまくいかないこともあります。そこで、後述する plan を作るところは Extra High、その後の実装や小さな修正は High や Medium にする、といった使い分けがおすすめです。

このあたりのプラクティスは、Codex の進化に合わせて変わっていきます。最も賢い model や高い Intelligence を常に使うのではなく、どの場面で使うと効果が高いかを実際に試しながら、自分の作業に合う使い方を探していきましょう。

Plan モード

上で「Extra High で plan を作らせる」と書きましたが、複雑なタスクでは Plan モードを使うと便利です。Codex Desktop では、入力欄の近くにあるプラスボタンから Plan モードを選択できます。Plan モードでは、いきなりスクリプトを書いたりファイルを変更したりせず、まず作業方針や手順だけを整理します。

たとえば難しいタスクでは、Extra High の Intelligence で最初の plan を作らせ、その結果を Plan.md というファイルに書き出させます。それを Claude Code にレビューさせると、違った視点が出てくることがあります。それをまた OpenAI のモデルにレビューさせつつ、plan を練り上げさせ、その後に一気に実行するといったプラクティスが、2026年中旬では効果的とされています。ソフトウェア開発以外でここまでのプラクティスが求められることは少ないかと思いますが、使い方のコツとして一つ知っておくと応用が効くかと思います。

その他機能

Codex をはじめとする Coding Agent の機能やプラクティスは、日々アップデートされていきます。Coding Agent が Coding Agent の開発にも使われているため、従来のソフトウェアと比べても開発速度は非常に速くなっています。

上記の基本的な機能やプラクティスを確認した後は、Coding Agent を開発している企業のエンジニアが登壇している動画を見たり、X や公式ページ（Codex App Features）を見たりしながら、自分が便利に使えそうな最新機能を継続的にキャッチアップしていきましょう。

もし使い方が分からない機能があれば、そのまま Codex に「この機能はどう使えばよいですか」と聞いてみるのも一つの手です。

例えば、2026年に入ってからは Computer Use のように、Coding Agent が computer の画面を見ながらクリックや入力を行う機能も使えるようになってきました。これは、API や Plugin が用意されていないアプリケーションでも、GUI を通じてある程度の作業を進められる可能性があるということです。たとえば社内で使っている経費システムに API がなかったとしても、Computer Use を使えば、画面操作を前提にした一部の自動化タスクを作れるかもしれません。ただし、Computer Use は project folder の外側にあるアプリやブラウザにも影響し得るため、最初は対象アプリや作業範囲を小さくし、permission prompt を確認しながら進めることが重要です。

このあたりの機能は、少しずつ安全な範囲で触ってみるのが良いと思います。自分の業務と照らし合わせながら、「どこまでなら Coding Agent に任せられるか」「どこは人間が確認すべきか」を考え、業務を少しずつ Coding Agent に委託していきましょう。