3行まとめ
90分、半日、1週間の研修設計を決めます。
read-only、workspace、承認境界を分けます。
作業契約、禁止事項、テスト手順を固定します。
日常タスク3本で導入可否を見ます。
Codex 101は、チームの合意を作る材料として使います。
- Codex 101は、個人が最初に触るための教材として読むだけでなく、チームのオンボーディング、権限初期値、
AGENTS.md、評価タスクを決める材料として使えます。 - チーム導入では、最初から広い編集権限や外部通信を渡すより、read-only調査、限定workspace、明示承認、ログ確認の順で広げるほうがレビューしやすくなります。
- 導入可否は「Codexがすごいか」ではなく、日常タスク3本で、差分品質、未検証報告、テスト結果、人間承認、secret露出なしを確認して判断します。
本文の事実確認には、OpenAI Academy、Codex Docs、OpenAI Help、OpenAI公式ブログと関連する公開済み記事を使っています。Xで伸びていた投稿は需要シグナルとして扱い、本文の根拠にはしていません。
この記事でわかること
90分、半日、1週間の導入計画を作れます。
初期値と承認条件を分けられます。
AGENTS.mdの最小テンプレートを作れます。
日常タスクで導入可否を判断できます。
便利さではなく、運用に残る判断材料を作ります。
- Codex 101をチーム研修の時間割に変換する考え方
- 初回導入で決めるべき権限、外部通信、MCP、リモート操作の境界
AGENTS.mdに書くことと、設定や管理者権限で強制することの分け方- 90分、半日、1週間パイロットの進め方
- code understanding、bugfix、test coverageで評価するタスク表
- 導入を広げないほうがよい失敗条件
前提知識
- 1触る
基本操作と対象repoを確認します。
- 2境界を決める
権限、外部通信、承認者を決めます。
- 3契約を書く
AGENTS.mdに作業前提を残します。
- 4評価する
日常タスクで差分とログを確認します。
チーム導入では、学習順より判断順が大事です。
Codex 101は、Codexの入口として使いやすい教材です。ただし、チームで使う時は「教材を見たか」だけでは足りません。実務では、誰がどのrepoで使うのか、どの権限で始めるのか、何を禁止するのか、どのログを残すのか、どのタスクで導入可否を見るのかまで決める必要があります。
公式情報を見ると、CodexにはChatGPT上の利用、CLI、IDE拡張、クラウドタスクなど複数の使い方があります。さらに、permission profile、AGENTS.md、sandbox、approval、network policy、管理者向けのworkspace controlsなど、チームで効いてくる論点があります。個人の「試して便利だった」をそのまま組織導入に広げると、権限、ログ、レビュー、データ利用の確認が後追いになります。
個人の入門とチーム導入は目的が違う
個人の入門では、Codexに小さな変更を頼み、差分を読み、テストを走らせられれば十分なことがあります。チーム導入では、同じ操作でも意味が変わります。誰が承認するのか、秘密情報に触れないか、外部通信をどこまで許すのか、失敗時にどのログで切り戻すのかを先に決めます。
確認項目
初回研修では、対象repo、利用プラン、使用クライアント、許可するコマンド、禁止する操作、レビュー担当、ログ保存先を短く記録します。ここを曖昧にしたまま「まず触ってみよう」にすると、導入後に判断基準が揃いません。
注意点
AGENTS.mdに「危ないことはしない」と書くだけでは、実行境界を強制したことにはなりません。自然言語の作業契約と、permission profile、approval、network allowlist、RBAC、branch protection、secret管理は分けて扱います。
Codex 101をチームオンボーディングへ読み替える
| 項目 | 内容 | 見方 |
|---|---|---|
| 基本操作 | 初回研修の時間割と対象repoへ変換します。 | |
| 依頼の書き方 | Issue風テンプレートへ変換します。 | |
| 差分確認 | レビュー観点と未検証報告へ変換します。 | |
| 反復作業 | 1週間パイロットの評価タスクへ変換します。 |
教材の要約ではなく、チームで使う形へ落とします。
Codex 101をチームで使うなら、教材の順番をそのまま追うより、チームの成果物に変換したほうが実務に乗ります。目標は「全員がCodexを触った」ではなく、「チームとして使う範囲、止める条件、評価方法が残った」です。
公式教材の流れを成果物に変える
OpenAI Academyの導線は、Codexを始める人にとって入口になります。チームでは、それを次のように読み替えます。
| 公式教材で学ぶこと | チーム側で作るもの |
|---|---|
| Codexの基本操作 | 初回研修の時間割と対象repo |
| タスクの頼み方 | Issue風依頼テンプレート |
| 差分確認 | レビュー観点と未検証報告の型 |
| 環境設定 | permission profile、approval、network方針 |
| 反復作業 | 1週間パイロットの評価タスク |
根拠
OpenAIのCodex関連資料では、Ask Mode、Issueのような依頼、task queue、AGENTS.md、テストやレビューの扱いが繰り返し出てきます。これらは個人の便利技ではなく、チームの標準作業に変換しやすい要素です。
評価基準
研修後に、依頼テンプレート、権限初期値、AGENTS.md初版、評価タスク表が残っているかを見ます。感想だけが残る研修は、導入判断には使いにくいです。
役割ごとに宿題を変える
全員に同じ宿題を渡すより、役割ごとに見るポイントを分けます。
| 役割 | 初回に見ること |
|---|---|
| エンジニア | 依頼文、差分、テスト、未検証報告 |
| レビュー担当 | レビューしやすい粒度、禁止操作の遵守 |
| EM/テックリード | 対象タスク、導入範囲、レビュー負荷 |
| 管理者 | plan、workspace controls、RBAC、ログ |
| セキュリティ担当 | secret、外部通信、MCP tool、承認境界 |
上振れ
上振れは、研修の最後に低リスクな実Issueを1つ処理し、差分、テスト、レビューコメント、未検証範囲が揃う状態です。この状態なら、1週間パイロットへ進めます。
下振れ
下振れは、参加者が便利さだけを覚え、権限や禁止事項が決まらない状態です。Codexは強いほど作業範囲が広がりやすいので、最初に境界が残らない導入は危ういです。
初回研修を90分、半日、1週間に分ける
- 90分
操作と安全境界を確認します。
- 半日
Issue風依頼とレビューまで扱います。
- 1週間
実務タスクで評価します。
- 判断
権限を広げるか止めるか決めます。
時間を分けると、学習と安全確認を同時に進められます。
導入の速さはチームによって違います。いきなり全社展開を狙うより、90分、半日、1週間の3段階に分けると、学習と安全確認を同時に進めやすくなります。
90分版は操作と安全境界に絞る
90分版では、Codexの基本操作と安全境界だけを扱います。対象はサンプルrepoか、失敗しても影響が小さい社内repoにします。成果物は、対象repo、許可コマンド、禁止操作、初回質問集、ログの残し方です。
確認項目
ログイン方法、利用プラン、使用するsurface、対象repo、編集してよい場所、実行してよいコマンド、外部通信の扱い、秘密情報の扱いを確認します。ここでは本番PRの作成まで進めなくて構いません。
注意点
90分版でdanger-full-accessや広いnetwork accessを使う必要はほとんどありません。最初はCodexにコードを読ませ、質問し、計画を出させ、差分を作らない練習から始めます。
半日版はIssue風プロンプトとレビューまで扱う
半日あれば、Issue風の依頼文、作業計画、差分、テスト、レビューまで見られます。ここで大事なのは、Codexに丸投げすることではなく、レビュー可能な依頼文を作ることです。
対象: packages/web/src/components/SearchBox.tsx
目的: キーボード操作時に候補選択が1つずれる不具合を直す
制約: UI文言は変えない。外部依存は追加しない。
許可: 調査、最小差分、既存テストの追加、npm test
禁止: unrelated refactor、snapshot全面更新、secret読み取り、git push
完了条件: 変更理由、実行したテスト、未検証項目を報告する根拠
Codexに渡す依頼は、ファイルパス、component名、失敗ログ、期待する挙動、制約を含めるほどレビューしやすくなります。GitHub Issueのように書くと、Codexの作業計画と人間のレビュー観点が揃います。
評価基準
半日版の合格は、実装が完璧なことではありません。依頼文、Codexの計画、差分、テスト結果、未検証項目、レビューコメントが1つの作業ログとして残ることです。
1週間パイロットは実務タスクで評価する
1週間パイロットでは、日常業務に近い小さなタスクを3本から5本選びます。おすすめは、code understanding、bugfix、test coverageです。依存関係追加、DB変更、CI/CD変更、課金や認証に触れる作業は、初回評価から外します。
条件
対象repoを絞り、参加者を少人数にし、タスクごとに許可権限と承認者を決めます。1タスクごとに、作業ログ、テスト結果、レビューコメント、未検証項目、権限昇格の有無を残します。
注意点
成功した1件だけで導入を広げないほうが安全です。失敗したタスク、権限が足りなかった場面、レビューが重かった場面、Codexの説明が不正確だった場面も判断材料です。
権限設計はread-onlyから始める
| 項目 | 内容 | 見方 |
|---|---|---|
| :read-only | 調査、質問、影響範囲整理に使います。 | |
| :workspace | 小さな修正やテスト追加で限定的に使います。 | |
| custom profile | チーム標準の許可と拒否を固定します。 | |
| :danger-full-access | 初回研修では避け、明示目的がある時だけ使います。 |
自然言語の禁止より先に、実行境界を決めます。
Codexの権限設計では、最初に広く渡してから制限するより、read-onlyから始めて必要な範囲だけ広げるほうが事故を見つけやすくなります。公式のpermissionsには、:read-only、:workspace、:danger-full-accessのような考え方とcustom profileがあります。
初期値はread-onlyまたは限定workspaceにする
初回研修では、read-onlyでコード理解、影響範囲調査、テスト候補の整理をさせます。編集が必要な場合も、workspace内に限定し、git push、secret読み取り、破壊的削除、外部通信は承認または拒否に残します。
| 権限 | 初期導入での扱い | 使う場面 |
|---|---|---|
:read-only | 最初の標準 | 調査、質問、影響範囲整理 |
:workspace | 低リスクrepoで限定的に使う | 小さなbugfix、テスト追加 |
| custom profile | チーム標準にする | 許可コマンド、拒否パス、network制御 |
:danger-full-access | 初回研修では避ける | 意図して広い操作が必要な限定場面 |
根拠
Codexのpermissionsでは、filesystem access、network access、approval、profileの組み合わせで実行境界を作れます。チーム導入では、自然言語の依頼よりも先にこの境界を決めます。
注意点
danger-full-accessは名前の通り、広いアクセスを意図して使う設定です。便利だからという理由で研修初日から使うと、禁止操作を検出する前に実行される余地が増えます。
network、MCP、リモート操作は別の承認境界にする
ネットワーク、MCP tool、Computer Use、リモート操作は、ファイル編集とは別の境界として扱います。コードを読むこと、workspace内で編集すること、外部へ接続すること、別アプリを操作することはリスクが違います。
確認項目
外部URL、HTTP method、送信される可能性があるコードやログ、MCP toolのread/write、対象端末、承認者、ログ保存先を確認します。npm registryや公式Docsの参照だけでも、社内規程によって扱いが変わることがあります。
評価基準
誰が承認したか、なぜ承認したか、どの範囲に接続したか、Codexが何を送った可能性があるかを後から説明できる状態にします。説明できない外部通信は、初回導入には向きません。
管理者設定と個人設定を分ける
Business、Enterprise、Eduのような組織利用では、個人のローカル設定だけでなく、workspace controls、RBAC、Compliance API、connected services、data controlsを確認します。個人の端末で問題なく動いたことと、チーム全員に許可してよいことは別です。
条件
管理者が、誰にCodexを使わせるか、どのsurfaceを許可するか、ログをどう見るか、データ利用設定がどうなるかを説明できる状態にします。
注意点
料金、usage limits、提供されるsurfaceは変わりやすい情報です。導入前には必ず公式Helpと管理画面で確認し、記事やSNSの古い説明をそのまま運用ルールにしないようにします。
AGENTS.mdはチームの作業契約にする
| 項目 | 内容 | 見方 |
|---|---|---|
| AGENTS.md | 作業前提、テスト手順、報告形式を書きます。 | |
| Permissions | filesystem、network、approvalを制御します。 | |
| Admin controls | 利用者、surface、ログ、データ設定を管理します。 | |
| Review | 実際の差分で守られたか確認します。 |
AGENTS.mdは作業契約、権限設定は実行境界です。
AGENTS.mdは、Codexに作業前提を渡すための重要な場所です。ただし、これは万能の安全装置ではありません。チームの作業契約として使い、実行境界はpermission、approval、network policy、管理者設定で補います。
グローバル、repo、サブディレクトリの役割を分ける
公式ガイドでは、Codex home、プロジェクトroot、サブディレクトリなど、複数の場所にあるAGENTS.mdを読み込む考え方が示されています。モノレポでは、rootに共通ルールを置き、領域ごとのテストや禁止事項はサブディレクトリに置くと管理しやすくなります。
根拠
近い場所の指示ほど、その領域の具体ルールを書きやすくなります。frontend、backend、infra、docsでテストコマンドや禁止操作が違うなら、1つの長いrootファイルに詰め込むより分けたほうが読みやすいです。
注意点
AGENTS.mdが長すぎると、Codexにも人間にも読みにくくなります。共通ルール、領域別ルール、例外ルールを分け、古い指示が残らないようにレビュー対象にします。
最小テンプレートは6項目で始める
最初のAGENTS.mdは、完璧を狙わず6項目で始めます。
AGENTS.md
[Repository]
- このrepoの目的:
- 主要なディレクトリ:
[Allowed Work]
- read-only調査:
- 小さな修正:
[Requires Approval]
- 依存関係追加:
- 外部通信:
- MCP write tool:
- CI/CD変更:
[Never Do]
- secret読み取り:
- unrelated refactor:
- git push:
- 本番データ操作:
[Test Commands]
- lint:
- typecheck:
- unit test:
- e2e:
[Final Report]
- 変更内容:
- 実行したテスト:
- 未検証:
- 人間に確認してほしい点:確認項目
新メンバーが3分で、頼んでよいこと、承認が必要なこと、絶対にしないこと、完了報告に含めることを判断できるかを見ます。
評価基準
実際の作業ログで、Codexがテスト手順、禁止事項、報告形式を守っているか確認します。AGENTS.mdを置いただけで合格にしないことが大事です。
AGENTS.mdが効いているか確認する
研修では、Codexに読み込んだinstruction sourcesを確認させます。さらに、実際の作業後に、AGENTS.mdに書いたテスト、承認、最終報告が守られたかをレビューします。
注意点
読み込み確認だけでは不十分です。実際の差分で禁止操作を避けたか、未検証を隠していないか、承認が必要な操作を止めたかを見る必要があります。
改善方法
守られなかった指示は、AGENTS.mdの文面が曖昧だったのか、permissionが広すぎたのか、依頼文が悪かったのか、テストが不足していたのかを分けて直します。
評価タスクは日常業務から3本選ぶ
| 項目 | 内容 | 見方 |
|---|---|---|
| Code understanding | read-onlyで関連ファイルと影響範囲を整理します。 | |
| Bugfix | 小さな不具合を失敗ログつきで直します。 | |
| Test coverage | 既存仕様に沿ってテストを追加します。 | |
| Scorecard | 差分品質、権限、未検証報告を評価します。 |
日常タスクなら、導入後のレビュー負荷も見えます。
導入可否を見るなら、派手なデモより日常業務に近いタスクが向いています。最初は、書き込みなしのcode understanding、小さなbugfix、既存仕様に沿ったtest coverageの3本で十分です。
1本目はcode understandingにする
未知のcodebaseを読ませ、componentの関係、data flow、影響範囲、テスト候補を整理させます。read-onlyで価値を見られるため、初回評価に向いています。
成功条件
関連ファイル、呼び出し関係、変更候補、リスク、未確認の点が整理されていることです。実装をしていないのに、関係ない大きな改修案へ飛んだ場合は減点します。
失敗条件
根拠ファイルを示さない、存在しない関数を前提にする、調査範囲を広げすぎる、secretや本番情報に触れようとする場合は導入範囲を狭めます。
2本目はbugfixにする
小さな不具合を、失敗ログつきで渡します。期待値、制約、対象ファイル、実行してよいテストを書き、Codexに作業計画、最小差分、テスト結果を出させます。
成功条件
差分が小さく、失敗原因が説明され、既存挙動を壊さず、関連テストが通っていることです。テストが実行できない場合は、理由と代替確認を報告しているかを見ます。
失敗条件
期待値だけを書き換える、関係ないリファクタを混ぜる、テスト失敗を隠す、未検証なのに完了と言う場合は不合格にします。
3本目はtest coverageにする
既存仕様が明確な関数やUIに対して、足りないテストを追加します。Codexはテスト補助と相性がよい一方、仕様を勝手に変えるリスクもあるため、レビューしやすい評価タスクになります。
成功条件
テスト名、fixture、境界値、失敗時のログが読めることです。実装を変えずにテストだけで仕様を固定できれば、チーム導入の最初の成功体験になります。
注意点
snapshot全面更新や、意図のないfixture変更は避けます。テスト追加のはずが実装変更へ広がった場合は、別タスクとして人間承認に戻します。
結果：導入可否はスコアカードで決める
小さく、関係ない変更がありません。
実行結果または未実行理由が残ります。
承認が必要な操作を勝手に進めません。
未検証、リスク、次の確認点を書きます。
Codexが成功したかより、人間が判断できる形で戻るかを見ます。
パイロットの結果は、成功/失敗だけでなく、スコアカードで見ます。Codexは出力がそれらしく見えやすいので、差分品質とレビュー可能性を分けて評価します。
| 評価軸 | 合格ライン |
|---|---|
| 依頼理解 | 制約、対象ファイル、完了条件を守る |
| 差分品質 | 小さく、関係ない変更がない |
| テスト | 実行結果または未実行理由が残る |
| 権限 | 承認が必要な操作を勝手に進めない |
| 報告 | 未検証、リスク、次の確認点を書く |
| セキュリティ | secret、顧客データ、本番操作に触れない |
| レビュー負荷 | 人間が短時間で差分を判断できる |
点数より止める条件を決める
点数が高くても、secretに触れた、禁止操作をした、テスト失敗を隠した、外部通信を説明できない場合は導入を広げないほうがよいです。逆に、実装が失敗しても、未検証や失敗理由を正しく報告できていれば改善余地があります。
評価基準
チーム導入で見るべきなのは、Codexの成功率だけではありません。失敗した時に止まれるか、人間がレビューできる形で戻ってくるか、権限を守れるかです。
次の一手
合格した場合も、repo追加、タスク種類追加、workspace write、network allowlist、MCP read-onlyのように1段階ずつ広げます。いきなり全社、全repo、全権限にはしません。
失敗点とハマりどころ
secretや本番操作に触れた場合は止めます。
テスト失敗や未実行を隠した場合は止めます。
レビュー不能な変更を作った場合は粒度を下げます。
接続先を説明できない場合は許可しません。
失敗条件が明確だと、導入判断が感想に寄りません。
Codex導入でよくある失敗は、ツールの性能不足より、チーム側の条件不足から起きます。特に、権限、依頼文、テスト、レビュー、ログのどれかが曖昧だと、便利さがそのままリスクになります。
AGENTS.mdを安全装置だと思い込む
AGENTS.mdは作業契約です。安全境界そのものではありません。禁止操作は、permission、approval、network policy、branch protection、secret管理で補います。
成功例だけで判断する
うまくいったデモは導入の入口にはなりますが、運用判断には失敗例が必要です。失敗時に止まれるか、ログが残るか、レビューで戻せるかを見ます。
導入初日から難しいタスクを渡す
依存関係の大規模更新、DB migration、CI/CD変更、認証や決済の改修は初回評価に向きません。小さく始めて、失敗時の戻し方を先に覚えます。
実務で使うなら
- 1日目
90分研修と権限初期値を決めます。
- 2日目
read-only調査を試します。
- 3-4日目
bugfixとtest coverageを評価します。
- 5日目
スコアカードで継続可否を決めます。
最初の成功条件は、広く任せることではなくレビュー可能性です。
最初の1週間は、Codexを「全部やってくれるエンジニア」ではなく、「調査、計画、差分作成、テスト補助をするメンバー」として扱います。人間のレビューと承認を残したまま、任せる範囲を少しずつ広げます。
1週間の進め方
1日目は90分研修、2日目はread-only調査、3日目は小さなbugfix、4日目はtest coverage、5日目はスコアカードレビューにします。週末に、権限を広げるか、AGENTS.mdを直すか、導入を止めるかを決めます。
関連する社内ルール
社内のAI利用規程、secret管理、ソースコード持ち出し、外部サービス接続、ログ保存、監査対応と矛盾しないか確認します。Codexだけのルールにせず、既存の開発統制に載せるほうが運用しやすいです。
読者向けの次アクション
まずは、低リスクrepoを1つ選び、AGENTS.md初版、permission profile、評価タスク3本、スコアカードを作ります。比較やベンチマークへ進む場合は、公開済みのAI Coding Benchmark Kitの記事も合わせて使えます。
セキュリティ・コスト注意
プランと組織設定を公式情報で確認します。
env、credentials、顧客データを除外します。
read-onlyから始め、write toolは別承認にします。
利用量だけでなく人間の確認時間も見ます。
コストはトークンだけでなく、レビュー不能な差分にも出ます。
Codex導入では、セキュリティとコストを最後に見るのではなく、最初の研修に入れます。便利さの確認と同じタイミングで、データ利用、secret、外部通信、usage limits、管理者設定を確認します。
データ利用と管理者設定
ChatGPT planや組織向け設定は更新されることがあります。Business、Enterprise、Eduなどで扱いが変わる可能性があるため、導入時にはOpenAI Helpと管理画面を確認します。
外部通信とMCP
MCPや外部APIを使う場合は、read-only toolから始めます。write tool、顧客データ、社内DB、本番環境への接続は、初回研修では扱わず、別の承認設計にします。MCPの認可やToolsの確認は、MCP更新確認の記事で詳しく整理しています。
コストとレビュー時間
Codexの利用量だけでなく、人間のレビュー時間もコストです。大きな差分を1回で作らせるより、小さなタスクを複数回に分けたほうが、レビュー時間と失敗時の戻しやすさを抑えられます。
FAQ
権限、評価、管理者設定まで別途決めます。
作業契約であり、強制境界ではありません。
read-only開始と評価タスクの考え方は横展開できます。
低リスクタスクに絞り、認証や決済は外します。
迷ったら、権限、テスト、承認境界へ戻ります。
Codex 101だけ見ればチーム導入できますか？
入口としては有用ですが、それだけでは足りません。チームでは、権限、AGENTS.md、評価タスク、管理者設定、ログ、承認者まで決める必要があります。
AGENTS.mdに禁止事項を書けば安全ですか？
いいえ。AGENTS.mdは作業契約であり、強制境界ではありません。禁止事項は、permission、approval、network policy、RBAC、branch protection、secret管理と組み合わせます。
Claude CodeやCursorにも同じ考え方は使えますか？
使えます。ツールごとの設定名は違いますが、read-only開始、権限分離、評価タスク、テストゲート、人間承認という考え方は共通です。依存関係更新の権限設計は、Claude Codeの記事も参考になります。
最初から本番repoで試してもよいですか？
低リスクな本番repoなら可能ですが、最初は影響範囲が小さいタスクに絞ります。認証、決済、DB migration、CI/CD、本番データに触れる作業は初回評価から外すほうが無難です。
更新履歴
- 2026年5月31日
OpenAI Academy、Codex Docs、Help、公式ブログ、changelogを確認して初版を作成しました。
導入時には、公式ドキュメントと管理画面を再確認してください。
2026年5月31日 JSTに、OpenAI AcademyのCodexページ、Codex 101、Codex permissions、AGENTS.md guide、OpenAI Help、Running Codex safely、Codex changelogを確認して初版を作成しました。公式情報は変わりやすいため、導入時には最新のドキュメントを再確認してください。