一人事業のAI業務配置：Claude Code×Codexで実運用を組む

「AIを増やしたのに、なぜか自分の仕事が減らない。」

01ボトルネックはモデルではなく、仕事の置き場

先に弱さを出しておくと、私はコードが書けません。
現場仕事も一人で回しています。
だから、AIを使うときに欲しいのは、賢い雑談相手ではなく、自分が抱えている役割を外へ出せる作業構造です。

AIを仕事に入れるとき、多くの人は最初にモデルを見ます。
どのモデルが賢いのか。
どのモデルが速いのか。
どのモデルがコーディングに強いのか。

01.01作業構造から見る

もちろん、モデル差はあります。
ただ、一人事業の現場で詰まる場所は、そこだけではないです。
むしろ、かなり多くの場合、詰まりはモデルではなく配置にあります。

想定している読者は、AIで作業を自動化したい一人事業者です。
開発者向けの教材ではありません。

01.02役割を外へ出す

Claude Codeは、AIにファイルや作業手順を読ませながら、作業分解、修正、検査を進めるための作業環境です。
Codexは、ブリーフを受け取って、編集、実装、調査、ファイル処理などを進める実行役AIです。
hooksは、削除や危険操作のように、AIのお願いだけでは止めきれない動きを機械的に止める仕組みです。
rulesは常に守るルール、skillsは必要なときだけ読む手順、ブリーフは今回の作業だけを渡す依頼書です。

同じClaude Codeを使っても、ある人は毎回チャットで説明し直します。
ある人は、毎回似たようなプロンプトを貼ります。
ある人は、作業の途中でAIが何を読んで、何を忘れて、どこまで触っていいのかを確認し続けます。

これだと、AIを入れているのに、人間がずっと現場監督と作業員を兼任することになります。
仕事が減らない理由は、AIの性能不足ではなく、AIが働く場所の設計がないからです。

ここに、AI業務配置の一番大事な区別があります。

AIに「頼む」のと、AIが動ける「作業場」を作るのは違います。

頼むだけなら、毎回チャットで成立します。

01.03チャットだけで任せない

でも、事業の中で繰り返す作業を任せるなら、チャットだけでは足りません。
どのルールを常に読ませるのか。
どの手順を必要なときだけ読ませるのか。
どの判断は人間に戻すのか。
どの作業はCodexに切り出すのか。
どのチェックはhooksで機械的に止めるのか。

この配置がないままAIを増やすと、仕事は速くなりません。
単に、指示待ちのAIが増えるだけです。

一人事業では、これがかなり危ないです。
会社なら、PM、実装者、レビュー担当、運用担当が分かれます。
一人事業では、それを一人で持ちます。
だからAIを入れる目的は「賢い相談相手を増やすこと」ではなく、自分の中にある役割を外に配置することです。

01.04配置を決める

私がこの教材で扱うのは、AIの課金判断ではありません。
どのAIが一番優秀かの比較でもありません。
判断基準を人格に移植する話でもありません。

ここで扱うのは、配置です。

Claude Codeを指揮役として使い、Codexを実働として使い、rules、skills、agents、hooks、ブリーフをどこに置くか。
そして、一人事業の作業を、毎回の気合いではなく、再現できる構造に落とすことです。

この教材で作る完成形は、次のようなものです。

人間
↓
指揮役AI：作業分解、委譲先決定、受け入れ条件、最終確認
↓
ブリーフ：読む順番、やること、禁止事項、DONE/BLOCKED基準
↓
実行役AI：独立した実装、編集、調査、ファイル処理
↓
一次検査：成果物、ログ、過剰実装、判断保留の確認

これを作ると、AIとの会話の質が変わります。
「この作業をやって」ではなく、「このブリーフで、この範囲だけを、この条件で完了させる」に変わります。

一人事業でAIを使うとき、最初に作るべきものは巨大な自動化ではありません。
まず、自分の仕事をAIが迷わず受け取れる形にすることです。

▼ここで手を動かす

ここでは、自分でAIチームの図を作らなくて大丈夫です。
普段の仕事を貼って、指揮役、ブリーフ、実行役、一次検査に分けてもらってください。

私の仕事を、AIに任せる流れへ分けてください。
分類はあなたが行ってください。
分ける先は、指揮役AI、ブリーフ、実行役AI、一次検査、人間が最終判断する場所です。
各項目について、私が普段どんな作業を置けばよいかを出してください。
ここから私の仕事です。
普段やっている作業：
AIに任せたい作業：
任せるのが怖い作業：

なぜ効くか。
最初から仕組みを作ろうとすると、開発者向けの話に見えます。
普段の作業を貼って分けさせると、AIを増やす話ではなく、自分の仕事のどこを外へ出すかが見えます。

02Context Ladder：4階層メモリ

Claude CodeやCodexを業務で使うとき、まず決めるのは「何を覚えさせるか」ではありません。
先に決めるのは、「いつ読ませるか」です。

ここを間違えると、リポジトリ（AIに読ませる仕事フォルダ一式のこと。以下この呼び方を使います）が大きくなるほどAIが鈍くなります。
全部を最上位の設定ファイルに書くと、毎回すべての作業で読まれます。
これは一見安心に見えますが、実際にはノイズが増えます。
毎回読ませる必要がないルールまで読み込むので、AIが今の作業に関係ない情報を抱えたまま動くことになります。

私はこれを、Context Ladderとして分けます。
Context Ladderは、AIに読ませる情報を「いつ読むか」で分ける考え方です。
階層は4つです。

1階：CLAUDE.md / AGENTS.md
毎セッション読む最小ルール。

2階：rules/*.md
対象領域に触れるときだけ読む詳細ルール。

3階：skills/*
呼び出したときだけ読む作業手順。

4階：agents / workflows / briefs
独立した文脈で動く実行単位。

この4階層を分けるだけで、AIの動きはかなり変わります。

1階に置くのは、全作業に効くルールだけです。
言語、禁止事項、作業前に必ず読むファイル、Gitの扱い、既存ファイルを勝手に壊さないこと、判断に迷ったら止めること。
こういうものは、毎回読まれていいです。

逆に、特定の商品ページの文体、特定のアプリのUIルール、特定のAPIの実装手順を1階に置くと重くなります。
毎回使わない情報が、毎回AIの頭に入るからです。

2階のrulesには、対象領域別のルールを置きます。
たとえば、モデル運用ルール、開発ルール、スキル配置ルール、記事作成ルール、セキュリティルールです。
これは常に読むものではなく、「その作業に関係するときだけ読む」資料にします。

3階のskillsには、再現したい手順を置きます。

02.01手順はスキル化する

記事を書く手順、PDFを扱う手順、ブラウザ検証の手順、Figmaに書き込む手順、GitHub PRを処理する手順。
毎回プロンプトで同じ説明を書いているなら、それはskill候補です。

4階のagents、workflows、briefsは、完全に独立した作業単位です。
ここでは、メイン会話の文脈を汚さずに、調査や実装を切り出します。
一人事業では、この階層がかなり重要です。
なぜなら、自分が考える場所と、AIが手を動かす場所を分けられるからです。

実装するときは、次のように置きます。

<project>/CLAUDE.md
<project>/AGENTS.md
.claude/rules/model-operation.md
<project>/.claude/rules/dev-and-skills.md
<project>/.claude/skills/<skill-name>/SKILL.md
<project>/.claude/agents/<agent-name>.md
<project>/ops/codex/briefs/active/<task-slug>.md
<project>/ops/codex/runs/<task-slug>.log

この配置で大事なのは、ファイル名そのものではありません。
役割が分かれていることです。

CLAUDE.mdやAGENTS.mdは、AIにとっての常時ルールです。
ここに「毎回必ず守ること」以外を書きすぎない。

rulesは、領域ごとの参照資料です。
たとえばモデル別ルーティングは、毎回全文をトップに置くより、rulesに外部化したほうが扱いやすいです。
必要なときだけ読めるからです。

skillsは、手順の再利用です。
「記事を書くときはこの順番で判断する」「PDFはこの方法でレンダリング確認する」「ブラウザ検証はこの道具を使う」というように、作業のやり方を入れます。

agentsやbriefsは、仕事の切り出しです。
これは記憶というより、委任の単位です。
何を読ませるか、何をやらせるか、何を禁止するか、完了をどう判定するかを書きます。

ここまで分けておくと、AIを増やしても破綻しにくくなります。
指揮役は全体を見ます。

02.02最初は入口だけ作る

実行役はブリーフだけを見て動きます。
スキルは必要なときだけ呼ばれます。
hooksは守らせたいことを機械的に止めます。

一人事業で最初にやるなら、いきなり複雑にしなくていいです。
まずは次の4つだけ作れば十分です。

CLAUDE.md：全作業の原則
.claude/rules/model-operation.md：モデル別の役割表
skills/<main-work>/SKILL.md：繰り返す主作業の手順
ops/codex/briefs/00_template.md：Codexに渡すブリーフ雛形

この4つがあると、毎回の依頼が「その場の会話」から「構造化された作業」に変わります。

CLAUDE.mdに書く内容の例は、こうです。

## 作業原則

- 回答は日本語。
- 既存ファイルを勝手に削除しない。
- 実装前に、完了条件と禁止事項を確認する。
- 独立して進められる実装や処理はCodexへ委譲する。
- 判断が必要な場合は、勝手に決めずに人間へ戻す。

.claude/rules/model-operation.mdに書く内容の例は、こうです。

## 固定する役割

- 指揮役：作業分解、委譲先決定、受け入れ条件、最終確認。
- 実装ワーカー：独立して進められる実装、修正、テスト、ファイル処理。
- 軽作業ワーカー：軽微な編集、読み取り、定型整理。

skills/<main-work>/SKILL.mdには、作業手順を書きます。
ここは抽象的な精神論ではなく、入力、読むファイル、手順、出力、チェック項目に分けます。

ops/codex/briefs/00_template.mdには、Codexへ渡す仕事の型を書きます。
このテンプレートがあると、毎回「何を頼めばいいか」を考える負担が減ります。

AIに賢くなってもらうのではなく、AIが迷わない道を作る。
Context Ladderは、そのための棚です。

▼ここで手を動かす

ここでは、4階層を自分で設計しなくて大丈夫です。
今のメモやルールを貼って、どの階に置くかをAIに分けてもらってください。

私がAIに読ませているルールやメモを、4階層に分けてください。
1階は毎回読む最小ルール、2階は対象領域だけで読むルール、3階は必要なときだけ読む手順、4階は今回の作業単位です。
分類はあなたが行い、置き場所が重いもの、軽くできるもの、まだ作らなくてよいものを分けてください。
最後に、今日作るべきファイルを一つだけ提案してください。
ここから私のメモやルールです。

なぜ効くか。
全部を最上位に置くと、AIは毎回関係ない情報まで抱えます。
読むタイミングで分けると、AIの返答が軽くなり、今回の作業に必要な情報だけが残ります。

03ASKED と FORCED の境界

AI運用で事故が起きる理由の一つは、お願いで済ませてはいけないことを、お願いで済ませていることです。

Markdownにルールを書くと、AIはかなりの確率で従います。
でも、かなりの確率で従うことと、必ず止まることは違います。

03.01お願いと強制を分ける

ここで使う区別が、ASKEDとFORCEDです。

ASKEDは、AIに読ませて従ってもらう指示です。
CLAUDE.md、AGENTS.md、rules/*.md、skills/*に書くルールは、基本的にASKEDです。
AIが読み、解釈し、できるだけ守ります。

FORCEDは、AIの意思に関係なく止める仕組みです。
hooks、settings、permissions、CI（自動検査）、pre-commit（作業前後の自動確認）、テスト、型チェック（入力や形式のずれを見る検査）のようなものです。
AIが「大丈夫そう」と判断しても、機械側で止めます。

この区別を入れないと、AI運用は精神論になります。
「必ずテストして」と書く。
「必ずフォーマットして」と書く。
「絶対に本番DBに触らないで」と書く。

でも、AIは文脈が長くなれば忘れます。
別の目的に引っ張られれば、優先順位を間違えます。
人間でも忘れるので、AIだけを責める話ではありません。

だから、スタイルはASKEDでいいです。
安全性はFORCEDに寄せます。

たとえば、文章の文体ルールはASKEDで十分です。
「一人称は私」「見出しは##」「煽りすぎない」「創作数字を書かない」といったルールは、読ませて従わせる領域です。
もちろん検査は必要ですが、機械的に止めるより、文脈判断が必要です。

一方で、削除、秘密情報、本番環境、課金、認証、データ消失に関わるものはFORCEDに寄せます。
「触らないで」と書くだけでは弱いです。
permissionsで禁止する。

03.02機械で止める領域

hookで検査する。
CIで落とす。
レビューなしでは進めない。
このように、AIがうっかり進んでも止まる構造にします。

実務では、次のように分けます。

・対象：文体、口調、出力形式 / 置き場所：CLAUDE.md / rules / skills / 性質：ASKED
・対象：作業手順、読み順、完了条件 / 置き場所：brief / skills / 性質：ASKED
・対象：削除禁止、秘密情報、危険コマンド / 置き場所：permissions / hooks / 性質：FORCED
・対象：フォーマット、テスト、型チェック / 置き場所：hooks / CI / 性質：FORCED寄り
・対象：判断が必要な採否、路線変更 / 置き場所：指揮役 / 人間 / 性質：ASKEDでもFORCEDでもない判断領域

ここで大事なのは、何でもFORCEDにしないことです。
すべてを機械で止めようとすると、今度は動けなくなります。
一人事業では、速度も重要です。
だから、失敗しても戻せるものはASKEDでよく、戻せないものだけFORCEDに寄せます。

例を出します。

記事作成で「創作数字を入れない」はASKEDです。
これはAIが文脈を見て判断する必要があります。

03.03禁止語は強く止める

ただし、商品ページで「売上が2倍」などの禁止語を検出するhookを作るなら、FORCEDに近づきます。

コード編集で「.obsidian/に触らない」はFORCEDに寄せたいです。
ファイルパスで検出できるので、hookやpermissionsで止めやすいからです。

データベースのマイグレーションもFORCED寄りです。
人間承認なしでは実行できないようにする。
本番接続情報をAIの作業環境から外す。
これが現実的です。

最小の形なら、settings.json では危険コマンドをdenyに入れます。

{
  "permissions": { "deny": ["Bash(rm -rf:*)"] }
}

hookで止める場合は、発火タイミングと対象を分けて書きます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "pwsh -NoProfile -File .claude/hooks/block-obsidian.ps1" }
        ]
      }
    ]
  }
}

この例では、Write/Editの直前に .obsidian/ など触ってはいけないパスを検査するスクリプトを動かします。
危険コマンドはpermissionsで拒否し、パスや内容の検査はhookへ寄せる、という分け方です。

この例は環境により動かない場合があります。確実に止めたい危険操作は、まずpermissionsで拒否し、パスや内容の検査だけhookへ寄せます。

ASKED/FORCEDを分けると、AIへの指示が短くなります。
「絶対にこれを守って」と長く書く必要が減るからです。
守らせたいことは、守らせる場所に置く。
考えてほしいことは、考える場所に置く。

この整理は、AIに優しくするためではありません。
人間が検査しやすくするためです。

どの失敗が起きたときに、どこで止まるのか。
どの失敗は、あとで直せばいいのか。
この線引きがあると、一人事業でもAIを業務に入れやすくなります。

▼ここで手を動かす

ここでは、ASKEDとFORCEDを自分で分類しなくて大丈夫です。
不安な操作を貼って、止めるべきものをAIに分けてもらってください。

私のAI運用で、ASKEDで足りるものと、FORCEDで止めるべきものを分けてください。
ASKEDはAIにお願いするルール、FORCEDは権限や設定で止めるルールです。
削除、秘密情報、本番環境、課金、認証、個人情報、戻せない変更は特に厳しく見てください。
ここから不安な操作や任せたい作業です。

なぜ効くか。
お願いだけで止める設計にすると、AIが頑張った結果として危ない作業に進むことがあります。
FORCEDに寄せる場所を先に決めると、安心ではなく、戻せる範囲で任せる運用になります。

04指揮役×実行役の分業セットアップ

ここから、実際に分業を組みます。

考え方はシンプルです。
Claude Code側のメイン会話を、指揮役として使います。
Codexを、実行役として使います。

04.01指揮役と実行役を分ける

指揮役は、計画、分解、受け入れ条件、リスク判断、最終確認を担当します。
実行役は、独立して進められる実装、ファイル処理、テスト、修正、調査の実働を担当します。

この分け方にすると、メイン会話の役割が変わります。
メイン会話で全部やらせるのではなく、メイン会話は仕事を切り出す側になります。

まず、Claude CodeでCodexプラグインを使える状態にします。
環境によってコマンドや名称が変わる場合があるので、ここでは公開前の下書きの流れを、公開用に汎用化して載せます。
実行前に、自分の環境で使えるプラグイン名と認証状態は確認してください。

セットアップの流れは、次の4段階です。

1. Claude CodeでCodexプラグインを入れる。
2. 指揮役にCodexセットアップを完了させる。
3. 認証する。
4. 指揮役に、今後の委任ルールを教える。

公開前の下書きにある導入コマンドは、次の形です。

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins

この3行にしている理由は、追加、インストール、読み直しを分けるためです。まとめて考えると、どこで失敗したかが見えません。実行前に、自分の画面で表示されるプラグイン名と利用中の環境で使える手順を確認してください。

この段階で大事なのは、プロジェクトコードを変更しないことです。
セットアップ作業と、リポジトリ編集作業を混ぜない。
ここを混ぜると、何が原因で壊れたのか分からなくなります。

次に、指揮役へ渡すセットアッププロンプトです。
本文では要点だけ載せます。
全文は特典3に収録しています。

- Codex連携プラグインのインストール状態を確認する
- Codex CLI（コマンドでCodexを動かす入口）の有無と認証状態を確認する
- 認証が必要なら人間へ戻す
- Claude Code内からCodexが動くか確認する
- セットアップ中にプロジェクトコードを変更しない

このプロンプトのポイントは、AIに「セットアップして」と丸投げしていないことです。
やることを、インストール確認、CLI確認、認証確認、動作確認、コード変更禁止に分けています。

認証が必要な場面では、人間が入ります。
ここはAIに越えさせないほうがいいです。
ログインやアカウント認証は、人間が確認する領域です。
AIにやらせるのは、認証が必要であることを検出して、人間へ戻すところまでです。

次に、委任ワークフローのプロンプトです。
これは、分業の核になります。

これからは、このワークフローを使用してください。

あなたはオーケストレーターです。

指揮役モデルを、計画立案、リポジトリ理解、アーキテクチャ決定、タスク分解、最終レビューに使用します。

タスクに大規模な実装、デバッグ、テスト修正、リファクタリング、または複数ファイルのコード編集が必要な場合、Codexを実行者として使用します。

Codexに委任する際は、環境で利用できるCodex委任コマンドまたはサブエージェントを使用します。

Codexモデルとして、利用環境で選べる高性能設定を優先してください。

Codexタスクは集中して具体的に保ってください。

Codexが完了したら、受け入れる前に自分で結果を検査してください。

Codexの出力を盲目的に信頼しないでください。

元の下書きでは、特定のモデル名やプラン名に寄った表現があります。
商品版では、読者の環境差があるため、そこは「利用環境で選べる高性能設定」に置き換えています。
ここは固有名を伏せる処理というより、再現性のための置換です。
特定の名称を固定すると、読者の環境で使えない可能性があるからです。

このワークフローを入れたあと、すぐに大きい実装を任せる必要はありません。
最初は、読み取り専用の小さい作業で確認します。

たとえば、次のようなタスクです。

このリポジトリの構成を読み、主要フォルダの役割をまとめてください。
ファイルの変更は禁止です。
最後に DONE: marker と、読んだファイル一覧を出してください。

これで、Codexへ作業が渡るか、ログが残るか、DONEマーカーが出るかを確認します。
ここで扱っている委任は、プラグインやサブエージェント経由でCodexへ渡す経路です。
委任にはもう一つ、Codex CLI（コマンドでCodexを動かす入口）を直接実行する経路があります。
本文では①プラグイン/サブエージェント経由、特典1では②CLI直接実行の雛形を扱います。

ここで詰まるなら、まだ実装を任せる段階ではありません。

一人事業では、速く動くことが大事です。
でも、速く動くためには、どこで止まるかも決めておく必要があります。
指揮役×実行役の分業は、AIを増やす話ではなく、止める場所と進める場所を分ける話です。

▼ここで手を動かす

ここでは、セットアップを全部覚えなくて大丈夫です。
自分の環境で確認すべき項目だけをAIに並べてもらってください。

Claude CodeとCodexを分業させる前に、私の環境で確認すべき項目をチェックリストにしてください。
Claude Codeは作業分解と検査をする作業環境、Codexはブリーフを受けて実作業をする実行役AIとして扱います。
確認項目は、プラグインや連携の有無、Codex CLIの有無、認証状態、読み取り専用テスト、DONE/BLOCKEDの戻り方です。
まだ書き込み作業はさせない前提で、最初の確認順序を出してください。

なぜ効くか。
いきなり実作業を任せると、連携の失敗と作業内容の失敗が混ざります。
先に読み取り専用で確認すると、環境の問題とブリーフの問題を分けて見られます。

05ブリーフ駆動の委譲

Codexに作業を任せるとき、いちばん効くのはブリーフです。

ブリーフは、長いプロンプトではありません。
作業を検査可能にするための仕様書です。

普通の依頼は、こうなります。

この機能を直して。
このノートを整理して。
この資料をいい感じにまとめて。

これだと、Codexは動けます。
でも、検査しにくいです。
どこまで読んだのか。
どこまで変更していいのか。
何をもって完了なのか。
何をやってはいけないのか。
迷ったときに止まるべきか、推測で進めるべきか。
ここが曖昧だからです。

ブリーフでは、この曖昧さを先につぶします。

基本形は、次の8項目です。

1. タスク識別
2. 読むべきファイル
3. 対象素材
4. やること
5. 出力形式
6. 採用条件
7. 禁止事項
8. 完了報告 / 判断保留時の動作

この中で特に大事なのは、読む順番、採用条件、禁止事項、完了報告です。

読む順番は、AIの前提をそろえるためにあります。
たとえば、最初に全体ルール、次に文体ルール、次に素材、最後に出力条件を読ませる。
順番を指定しないと、AIは都合のいいところから読みます。
それでうまくいく場合もありますが、再現性は落ちます。

採用条件は、成果物を受け入れる基準です。
「読みやすい」では弱いです。
「指定見出しをすべて含む」「素材にない数字を創作しない」「既存ノートを上書きしない」「DONEマーカーを出す」のように、検査できる形にします。

禁止事項は、AIの自由度を下げるためではありません。
人間が後で見なくていい範囲を減らすためです。

05.01完了報告を固定する

「ブリーフ外の作業禁止」「いい感じに判断しない」「実ファイルの生の中身を無加工で貼らない」「既存ノート上書き禁止」などは、検査の負担を大きく下げます。

完了報告は、ログを見る場所を固定するためにあります。
Codexが長い作業をしたあと、最後にこう出させます。

DONE: created=<n> updated=<n> skipped=<n>
files:
- <作成・更新したファイル>
notes:
- <固有名を伏せる処理、判断保留、スキップ理由>

迷ったときは、勝手に進めさせません。
その場合は、こう出させます。

BLOCKED: <理由>

ここがかなり大事です。
AI運用では、失敗の多くが「分からないのに進んだ」から起きます。
だから、止まる形式を先に決めます。

実際に使うブリーフの最小形は、こうです。

# Codex ブリーフ：<task-name>

## タスク識別
- タスクID：YYYYMMDD_<slug>
- 生成日：YYYY-MM-DD
- 担当Codex：#1
- 目的：この作業で作るものを一文で書く

## 1. 読むべきファイル（順番厳守）
1. `AGENTS.md`
2. `CLAUDE.md`
3. `.claude/rules/model-operation.md`
4. `<task-specific-file>`

## 2. 対象素材
- `<path/to/input>`

## 3. やること
- [ ] 読む
- [ ] 必要な情報だけ抽出する
- [ ] 指定パスに出力する
- [ ] 完了報告を出す

## 4. 出力形式
- 出力先：`<path/to/output.md>`
- 書式：Markdown
- 言語：日本語

## 5. 採用条件
- [ ] 指定ファイルを順番通り読んでいる
- [ ] ブリーフ外のファイルを書き換えていない
- [ ] 素材にない数字や事実を作っていない
- [ ] DONEまたはBLOCKEDを出している

## 6. 禁止事項
1. ブリーフ外の作業禁止
2. いい感じに判断しない
3. 既存ノートを上書きしない
4. 秘密情報や実パスを公開用成果物へ出さない

## 7. 完了報告
書式は前章のとおり。

## 8. 判断保留時
書式は前章のとおり。

このテンプレートで仕事を振ると、Codexの作業はかなり見やすくなります。
人間が見るべき場所が、本文全体ではなく、最後のDONE、files、notesに集約されるからです。

一次検査では、次の5つを見ます。

1. DONEマーカーがあるか。
2. files一覧に成果物が出ているか。
3. BLOCKEDやエラーが残っていないか。
4. ブリーフ外の作業をしていないか。
5. 採用条件を満たしているか。

ここまで見ると、Codexの出力を盲信せずに使えます。

ブリーフ駆動の委譲にすると、仕事の渡し方が変わります。
自分の頭の中にある曖昧な期待を、先に外へ出すことになります。

一人事業では、これが効きます。
自分が忙しいときほど、依頼が雑になります。
依頼が雑になると、AIの出力も雑になります。
だから、忙しくなる前に、ブリーフの型を作っておく。

これはAI活用というより、業務の受け皿作りです。

▼ここで手を動かす

ここでは、ブリーフを白紙から書かなくて大丈夫です。
任せたい作業を貼って、AIにブリーフの初稿を作らせてください。

次の作業をCodexへ渡すためのブリーフにしてください。
入れてほしい項目は、タスク識別、読むべきファイル、対象素材、やること、出力形式、採用条件、禁止事項、完了報告、判断保留時です。
曖昧なところは勝手に埋めず、不明として最後に質問してください。
ここから任せたい作業です。

なぜ効くか。
「これやって」だけだと、実行役AIは範囲を広く解釈します。
読むもの、触る範囲、完了条件を先に書くと、作業がDONEかBLOCKEDで戻りやすくなります。

06モデル別ルーティング表

AIを複数使うとき、毎回「これはどのAIに頼むべきか」と考えると、それだけで疲れます。
だから、役割は先に固定します。

この教材では、3つに分けます。

・役割：指揮役 / 担当：利用環境で選べる高性能モデル / やること：作業分解、委譲先決定、受け入れ条件、設計・リスク判断、最終確認
・役割：実装ワーカー / 担当：Codex / やること：独立して進められる実装、コード修正、テスト、ファイル操作、バッチ処理、再現可能な処理
・役割：軽作業ワーカー / 担当：軽作業向けモデル / やること：軽微な単発編集、調査、読み取り、文章下書き、通常レビュー、定型整理

ここで大事なのは、「賢いモデルを全部に使う」ではないことです。
高い判断力が必要なところに指揮役を置く。
手を動かすところにCodexを置く。
軽い整理や読み取りは軽作業ワーカーへ逃がす。
この配置にします。

判断は、上から順に見ます。

1. 指揮役が直接処理するもの
- 受け入れ条件を書くこと自体が難しい。
- 設計判断が成果の中心。
- セキュリティ、認証、課金、データ消失リスクがある。
- Codexまたは軽作業ワーカーが同じ問題に2回失敗している。
- 仕様に矛盾がある。
- 長時間の文脈保持が必要。
- 手戻りコストが高い。

2. Codexへ委譲するもの
- 高度判断を必要としない。
- 独立した実装、変更、テスト、処理として完了できる。
- 読むファイル、触る範囲、出力先、採用条件をブリーフに書ける。

3. 軽作業ワーカーへ委譲するもの
- 軽微な単発編集。
- 調査、読み取り、文章下書き。
- 通常レビュー。
- 定型的な整理。

4. 重複委譲しない
- 同じ作業をCodexと軽作業ワーカーに同時に投げない。
- 比較実験をする場合だけ、目的と採用基準を先に定義する。

境界で迷ったときは、こう見ます。

実行可能な独立作業として切り出せる → Codex
変更範囲が小さく、定型的な知的作業で完結する → 軽作業ワーカー
判断そのものが成果、または失敗時の影響が大きい → 指揮役

この表を作ると、AI選びの迷いが減ります。
作業を受けた瞬間に、まず分類するからです。

たとえば、「既存アプリのログイン画面を直す」は、いきなりCodexではありません。
まず指揮役が、受け入れ条件を書けるかを見ます。
見た目だけか、認証が絡むのか。
課金や個人情報が絡むのか。
既存テストはあるのか。
ここを見て、リスクが低く、範囲を切れるならCodexに渡します。

「この長いノートから要点を抽出して」は、軽作業ワーカーでよい場合が多いです。
ただし、その要点を商品設計に使うなら指揮役が見るべきです。
読み取りと判断は違うからです。

「この仕様で実装して、テストも直して」は、Codex向きです。
ただし、仕様が曖昧なら、先に指揮役がブリーフを補強します。
Codexに曖昧な仕様を渡すと、Codexは頑張って解釈します。
でも、その解釈が正しいかどうかは別です。

このルーティング表は、完璧な分類表ではありません。
目的は、毎回の判断を減らすことです。

一人事業では、判断疲れがかなり大きいです。
AIを使っているのに疲れる人は、AIに仕事を渡す前に、毎回自分がPMをやり直していることが多いです。
だから、PM判断の一部を表にします。

この表を.claude/rules/model-operation.mdに置いておけば、必要なときに読ませられます。
CLAUDE.mdには、詳細全部ではなく「モデル運用の詳細は.claude/rules/model-operation.mdを見る」とだけ書けばいいです。

▼ここで手を動かす

ここでは、モデル名から選ばなくて大丈夫です。
作業を貼って、指揮役、実行役、軽作業、人間判断に振り分けてもらってください。

私の作業一覧を、どの役割へ渡すかに分けてください。
分ける先は、指揮役AI、Codexなどの実行役AI、軽作業AI、人間判断です。
判断基準は、作業範囲が切れているか、ファイルを触るか、失敗したときに戻せるか、最終判断が必要かです。
各作業について、最初に渡すならどの小さい単位に切るかも出してください。
ここから作業一覧です。

なぜ効くか。
モデルの強さだけで決めると、判断までAIに渡しがちです。
作業の切れ方で分けると、Codexへ渡すべきものと、人間が決めるべきものが混ざりにくくなります。

07Skillsの実配置

Skillsは、AIに読ませる手順書です。
ただし、置き場所を間違えると発動しません。

ここは地味ですが、かなり重要です。
「いい手順を書いたのに、AIが読んでくれない」という問題は、内容ではなく配置で起きます。

基本は、skills/直下にフラットに置きます。
カテゴリフォルダの中に入れ子にすると、発動対象として見つからない環境があります。
だから新しいskillを作るなら、まずこう置きます。

.claude/skills/write-article/SKILL.md
.claude/skills/review-pr/SKILL.md
.claude/skills/pdf-workflow/SKILL.md
.claude/skills/browser-check/SKILL.md

こうではありません。

.claude/skills/writing/write-article/SKILL.md
.claude/skills/dev/review-pr/SKILL.md
.claude/skills/tools/pdf/pdf-workflow/SKILL.md

分類したくなる気持ちは分かります。
でも、発動しない分類は、実務では負債です。
人間にとってきれいな棚と、AIが読み取れる棚は違います。
ここでは、AIが確実に発動できる配置を優先します。

Skillの中身は、最低限この形にします。

---
name: write-article
description: Use when the user asks to draft, rewrite, polish, or evaluate articles.
---

# Write Article

## When to Use

このskillを使う条件を書く。

## Required References

読むべき参照ファイルを書く。

## Workflow

1. 方向を決める。
2. 素材を読む。
3. 構成を作る。
4. 本文を書く。
5. 検査する。

## Checks

- 情報量を落としていないか。
- 未確認の数字を作っていないか。
- 指定された出力形式を守っているか。

descriptionはかなり大事です。
ここに発動条件を書きます。
「記事を書くskill」では弱いです。
「draft, rewrite, polish, evaluate articles」といった具体的な動詞を入れると、呼ばれる場面が明確になります。

Skillに入れるべきものは、毎回同じ手順です。
毎回変わる素材や判断は、skillに入れません。

たとえば、記事作成skillに入れるのは、文体ルール、構成ルール、ファクトチェックの考え方、納品前チェックです。
今回の記事のタイトルや出力先は入れません。
それはブリーフに入れます。

この分離が大事です。
Skillは、作業手順です。

07.01依頼とルールを分ける

Briefは、今回の依頼です。
Ruleは、領域の方針です。
Hookは、機械的な保証です。

全部をskillに入れると、skillが太ります。
全部をbriefに入れると、毎回長くなります。
全部をCLAUDE.mdに入れると、毎回の文脈が重くなります。

だから、こう分けます。

・置くもの：全作業で守る最小ルール / 置き場所：CLAUDE.md / AGENTS.md
・置くもの：領域別の方針 / 置き場所：rules/*.md
・置くもの：再利用する手順 / 置き場所：skills/<name>/SKILL.md
・置くもの：今回の作業条件 / 置き場所：briefs/active/<task>.md
・置くもの：必ず止めたいもの / 置き場所：hooks / settings / permissions

一人事業では、最初から大きなスキル体系を作る必要はありません。
まず作るなら、3つで十分です。

write-article：記事、販売ページ、SNS長文の作成。
codex-brief：Codexへ渡すブリーフ作成。
review-output：AI出力の一次検査。

この3つがあると、日常の仕事がかなり回しやすくなります。
書く、渡す、検査する。
AI業務配置の最小単位は、この3つです。

Skillsを増やす判断基準も決めておきます。

同じ説明を3回以上している。
毎回ミスが起きる順番がある。
参照資料が毎回同じ。
出力前チェックが毎回同じ。

このどれかに当てはまるなら、skill化候補です。
逆に、一回しか使わない作業はskillにしなくていいです。
ブリーフで十分です。

整理しすぎない。
でも、繰り返すものは外に出す。
このバランスが、一人事業のAI運用ではちょうどいいです。

▼ここで手を動かす

ここでは、skillを自分で命名しなくて大丈夫です。
毎回繰り返している説明を貼って、skill化候補を出してもらってください。

私がAIに毎回説明していることを、skill化する候補に分けてください。
skillに入れるべきものは、毎回同じ手順、毎回同じチェック、毎回同じ文体や判断基準です。
今回だけの素材、個別案件の事情、本人確認が必要な判断はskillに入れないでください。
候補ごとに、skill名、使う場面、入れる内容、入れない内容を出してください。
ここから毎回説明している内容です。

なぜ効くか。
毎回同じ説明をチャットに貼ると、使うたびに抜け漏れが出ます。
skillにする候補だけを分けると、再利用する手順と、その場で判断する内容を混ぜずに済みます。

08運用ループ

AI業務配置は、一回作って終わりではありません。
事業の仕事は毎日動きます。
未整理のメモが増えます。
修正したいコードが出ます。
商品ページの改善点が出ます。
問い合わせ、請求、発信、制作、保守が混ざります。

だから、単発プロンプトだけでは足りなくなります。
次に必要になるのが、運用ループです。

08.01運用は回して直す

運用ループというのは、AIに作業を勝手にやらせる魔法ではありません。
状態を見て、タスクを整理して、必要なら実行し、検証して、ログを残し、次回へつなぐ流れです。

形にすると、こうです。

定期確認
↓
状態整理
↓
タスク抽出
↓
AI作業
↓
検証
↓
人間確認
↓
STATE.md / LOOP.md / ログ更新
↓
次回へ

公開前の下書きでは、代表的な7パターンが整理されていました。

・パターン：Daily Triage / 内容：毎日または数時間ごとに状態整理する
・パターン：PR Babysitter / 内容：Pull Requestの進行を監視する
・パターン：CI Sweeper / 内容：CI失敗を検知し、修正候補を作る
・パターン：Dependency Sweeper / 内容：依存関係更新を確認する
・パターン：Changelog Drafter / 内容：変更履歴の下書きを作る
・パターン：Post-Merge Cleanup / 内容：マージ後の整理をする
・パターン：Issue Triage / 内容：Issueを分類し、優先度を付ける

一人事業で最初に入れるなら、Daily Triageだけで十分です。
PR BabysitterやCI Sweeperは、開発運用がすでに回っている人向けです。
Issue Triageも、GitHub Issuesでタスクを管理している段階なら効きます。
でも、最初から入れると重いです。

最初にやるべきことは、レポート専用L1です。

L1 report-only

これは、AIに自動修正させない運用です。
見るだけ。
整理するだけ。
提案するだけ。
ファイル変更はしない。

なぜこれから始めるのか。
理由は、運用ループの最初の失敗は「便利そうだから自動修正まで入れる」ことだからです。
自動修正は、状態把握ができてからでいいです。
最初に必要なのは、自分の仕事がどこで詰まっているかを見ることです。

Daily Triageの最小構成は、次の4ファイルです。

STATE.md：現在の状態。
LOOP.md：何を、どの頻度で、どう回すか。
loop-run-log.md：実行履歴。
loop-budget.md：頻度、コスト、上限。

最初のSTATE.mdは、こんな程度でいいです。

# STATE

## 現在の重点
- この教材の本文と特典を仕上げる。

## 未処理
- スクショ差し込み。
- 販売ページ文の確認。
- タイトル案の採用。

## 注意
- 既存ノートを書き換えない。
- 商品外の導線や未公開計画を書かない。

LOOP.mdは、こうです。

# LOOP

## Daily Triage L1

頻度：毎日1回。
権限：report-only。
入力：STATE.md、直近ログ、指定フォルダ。
出力：今日見るべきこと、止まっていること、次に人間が決めること。
禁止：自動修正、削除、既存ノート上書き。

これだけで、AIの使い方が変わります。
毎回「今なにからやる？」と聞くのではなく、状態ファイルを見て、次の候補を出させられるからです。

運用ループで大事なのは、ログです。
AIに作業をさせたら、何を見て、何を提案し、何をしなかったかを残します。

これを数回回すと、繰り返し出てくる詰まりが見えます。
その詰まりが、skill化、hook化、brief化の候補です。

同じ提案が毎回出るなら、STATEかLOOPが弱いです。
同じミスが毎回出るなら、hookか採用条件が弱いです。
同じ説明を毎回しているなら、skill化できます。
同じ実装を毎回頼んでいるなら、Codexブリーフ化できます。

08.02まず報告だけで回す

運用ループは、自動化のためだけにあるのではありません。
自分の業務構造を見えるようにするためにあります。

L1 report-onlyは、その構造を見つけるための安全な入口です。

▼ここで手を動かす

ここでは、STATEやLOOPをきれいに作らなくて大丈夫です。
まず、今の状態をAIに3項目へ整理させます。

私のAI運用の現在地を、STATEとLOOPの最小形に整理してください。
STATEには、現在の重点、未処理、注意を書く前提です。
LOOPには、何を、どの頻度で、どう見るかを書く前提です。
最初は自動修正せず、report-onlyで見るだけにしてください。
ここから今の状態です。

なぜ効くか。
状態管理がないままAIを増やすと、どこで止まっているかが毎回分からなくなります。
STATEとLOOPを小さく作ると、AIに動かす前に、見るべき場所だけを固定できます。

09チーム化の現在地

ここでは、特定ツール名に依存しない考え方として書きます。

AIを使い始めると、次に気になるのがチーム化です。
Lead、Frontend、Backend、Tester、Scribeのように、AIを役割ごとに分ける。
GitHub Issuesを見て、自動で振り分ける。
並列に作業させる。

09.01チーム化の前提

これは方向としては自然です。
会社の仕事は、もともと役割分担で動いています。
一人事業でも、頭の中では同じことをしています。
企画する自分、作る自分、直す自分、売る自分、記録する自分がいる。
それをAIに分ける発想は、かなり相性がいいです。

ただ、導入順序を間違えると重いです。

公開前の下書きでは、AI開発チーム化のツールとして、Squad系の考え方が紹介されていました。

09.02役割でチームを見る

人間主導で、Lead、Frontend、Backend、Tester、Scribeのような役割を持つAIチームを作る発想です。
機能としては、チーム設定、判断ログ、状態確認、セットアップ診断、Issue監視、文脈整理、設定の移植などがあります。

考え方としては面白いです。
でも、一人事業の最初の導入としては、まだ早い場合が多いです。

理由はシンプルです。
チーム化は、単発委任が安定してから効くからです。

Codexに1件のブリーフを渡して、DONE/BLOCKEDで戻せる。
指揮役が一次検査できる。
Skillが発動する。
Context Ladderが整理されている。
STATE.mdとLOOP.mdで状態が見える。

ここまでできていない状態でチーム化すると、混乱が増えます。

09.03複数AIほど基準が要る

AIが複数になるほど、ログ、責任、判断、採用基準が必要になるからです。

導入優先度は、私はこう置きます。

1. CLAUDE.md / AGENTS.md を整える。
2. モデル別ルーティング表をrulesに置く。
3. よく使うSkillsを棚卸しする。
4. Codexブリーフ雛形を作る。
5. 単発のCodex委譲をDONE/BLOCKEDで回す。
6. STATE.md / LOOP.mdでL1 report-onlyを始める。
7. GitHub Issuesなどでタスクが増えてからチーム化を試す。

この順番を飛ばさないほうがいいです。
チーム化ツールは、仕事が構造化されてから入れると効きます。
仕事が散らかったまま入れると、散らかった仕事を複数AIが同時に触るだけになります。

一人事業で最初に必要なのは、AIチームではありません。
まず、自分の仕事の入口を一つ作ることです。

入口は、ブリーフです。
出口は、DONE/BLOCKEDです。
検査は、指揮役です。
状態管理は、STATE.mdです。
繰り返し手順は、Skillsです。
強制停止は、hooksです。

ここまで揃ったあとなら、チーム化はかなり意味があります。
たとえば、商品制作を回すなら、役割はこう分けられます。

・役割：Lead / 担当する仕事：目的、採用条件、判断保留の整理
・役割：Writer / 担当する仕事：本文、販売ページ、SNS原稿の下書き
・役割：Researcher / 担当する仕事：素材読み、競合確認、一次情報の整理
・役割：Tester / 担当する仕事：リンク、ファイル、出力条件の検査
・役割：Scribe / 担当する仕事：ログ、変更履歴、判断メモの保存

AIチーム化は、派手です。
でも、実務で効くのは派手さではありません。
どの役割に、どの入力を渡し、どの成果物を戻すかです。

「まだ早い」と判断するのも、AI運用では重要です。
新しい道具を入れない判断は、遅れているのではありません。
今の構造に対して、導入の相性を見ているだけです。

▼ここで手を動かす

ここでは、自分のAI運用が何段階目かを判定しなくて大丈夫です。
今あるものを貼って、次にやる一手だけをAIに選ばせてください。

私のAI運用が、どの段階までできているかを判定してください。
見る項目は、最小ルール、モデル別ルーティング、skills棚卸し、Codexブリーフ、DONE/BLOCKEDの単発委譲、STATE/LOOPです。
できているもの、弱いもの、まだやらなくてよいものに分けてください。
最後に、今日やる一手だけを出してください。
ここから今あるものです。

なぜ効くか。
チーム化を大きく考えると、いきなり自動化全体を作りたくなります。
段階で見ると、まだ単発委譲が安定していないのに監視や自動修正へ進むズレを防げます。

10今日から2週間の導入順序

ここまで読んで、「結局どこからやるのか」が曖昧だと動けません。
なので、2週間の順番に落とします。

売上予測や成果の数字は書きません。
ここで必要なのは、期待値ではなく手順です。

10.012週間で順番に作る

1日目。
現在のプロジェクトに、AI運用の入口を作ります。
CLAUDE.mdまたはAGENTS.mdを開き、全作業に効くルールだけを書きます。
言語、既存ファイルを壊さない、危険操作をしない、判断に迷ったら止める、独立作業はCodexへ委譲する、という最小ルールです。

2日目。
.claude/rules/model-operation.mdを作ります。
指揮役、実装ワーカー、軽作業ワーカーの役割を書きます。
上から順の判定リストも入れます。
ここで、どのAIに何を渡すかを固定します。

3日目。
ops/codex/briefs/00_template.mdを作ります。
タスク識別、読むべきファイル、対象素材、やること、出力形式、採用条件、禁止事項、完了報告、判断保留を入れます。
空欄のまま渡さないルールも書きます。

4日目。
読み取り専用のCodexブリーフを1つ作ります。

10.02小さな委任で試す

内容は、リポジトリ構成の整理で十分です。
書き込み禁止にして、DONE/BLOCKEDが返るかを確認します。
ここでは成果物の品質より、委任の流れが通るかを見ます。

5日目。
指揮役の一次検査を行います。
DONEがあるか、files一覧があるか、notesがあるか、ブリーフ外作業がないか、エラーが残っていないかを見ます。
検査項目が曖昧なら、ブリーフテンプレートを直します。

6日目。
最初のskillを1つ作ります。
一番よく使う作業を選びます。
記事作成、レビュー、ブリーフ作成、出力検査のどれかです。
skills/<skill-name>/SKILL.mdとして、ルート直下フラットに置きます。

7日目。
Skillの発動確認をします。
小さいタスクで呼び出し、必要な参照を読んでいるか、出力前チェックをしているかを見ます。
うまく発動しない場合は、descriptionを具体化します。

8日目。

10.03危険作業を強制停止

ASKED/FORCEDを分けます。
Markdownに書けばよいルールと、hooksやpermissionsで止めるべきルールを分けます。
削除、秘密情報、本番環境、課金、認証、データ消失に関わるものは、FORCED候補にします。

9日目。
危険操作の最低限のガードを入れます。
最初から全部をhook化しなくていいです。
まずは、触ってはいけないフォルダ、削除してはいけないファイル、公開物に出してはいけない情報を洗い出します。

10日目。
STATE.mdを作ります。
現在の重点、未処理、注意、判断待ちを書きます。
最初は短くていいです。
AIが現在地を読めることを優先します。

11日目。
LOOP.mdを作ります。
Daily Triage L1 report-onlyとして、頻度、入力、出力、禁止事項を書きます。
この段階では、自動修正は禁止です。

12日目。
L1 report-onlyを1回実行します。

10.04状態確認から始める

AIに、STATEとLOOPを読ませ、今日見るべきこと、止まっていること、人間が決めることだけを出させます。
ファイル変更はしません。

13日目。
ログを見て、繰り返し出た詰まりを分類します。
Skill化するもの、brief化するもの、hook化するもの、STATEに追記するものに分けます。
この分類が、次の改善になります。

14日目。
2週間の構成を見直します。
CLAUDE.mdが太りすぎていないか。
rulesに逃がせるものはないか。
skillsが発動する配置になっているか。
Codexブリーフに空欄が残っていないか。
DONE/BLOCKEDで戻っているか。
L1が自動修正なしで回っているか。

2週間でやることは、AIを完全自動化することではありません。
AIが迷わず働ける入口と、人間が検査できる出口を作ることです。

この順番なら、途中で止めても無駄になりにくいです。

10.05段階ごとに積み上げる

1日目から3日目までで、最低限のルールとブリーフができます。
4日目から7日目までで、単発委任とskillができます。
8日目から11日目までで、安全性と状態管理ができます。
12日目から14日目で、運用ループの入口ができます。

一人事業のAI配置は、いきなり完成させるものではありません。
毎日の仕事の中で、繰り返しを外に出していくものです。

▼ここで手を動かす

ここでは、2週間分を自分で組み立てなくて大丈夫です。
今の状態を貼って、今日からの順番に直してもらってください。

私のAI運用を、今日から2週間の導入順序に並べてください。
1日目から14日目までに分け、各日にやることを1つだけ置いてください。
先にやるのは、最小ルール、読み取り専用ブリーフ、DONE/BLOCKED確認、skill候補、STATE/LOOPです。
大きい実装や自動修正は後回しにしてください。
ここから私の現在地です。

なぜ効くか。
順番がないと、便利そうなところから触ってしまいます。
2週間へ落とすと、読者の手元に、明日も使える委譲ワークフローが残ります。

11特典案内

この教材には、本文の実装をそのまま始めるための特典を3つ付けます。

特典1は、Codexブリーフ雛形です。
本文で説明したブリーフ駆動委譲を、そのまま使える形にしています。
読むべきファイル、やること、出力形式、採用条件、禁止事項、DONE/BLOCKED、起動コマンドまで入れています。
最初はこれをコピーして、空欄を埋めるところから始めてください。

11.01特典で分業を始める

特典2は、モデル別ルーティング表です。
指揮役、実装ワーカー、軽作業ワーカーの役割固定と、上から順に判定するリストを一枚にしています。
.claude/rules/model-operation.mdに置く想定で作っています。
毎回「どのAIに頼むか」を考えないための表です。

特典3は、セットアッププロンプト集です。
Codex連携のセットアップ、委任ワークフロー、読み取り専用テスト、ブリーフ作成依頼、一次検査依頼をまとめています。
公開前の下書きのプロンプトを、公開用に実パスや環境依存名を避けた形へ整理しています。

使う順番は、特典2、特典1、特典3です。

11.02役割から組み立てる

先に役割を決めます。
次にブリーフの型を置きます。
最後に、必要なプロンプトを貼って動作確認します。

この順番にすると、AIを増やす前に、仕事の入口と出口ができます。

付録A

12特典1_Codexブリーフ雛形

この雛形は、Codexへ独立作業を渡すためのブリーフです。
コピーして、空欄を埋めてから渡してください。
空欄のまま渡さないでください。
判断が必要な箇所は、人間または指揮役が先に決めます。

13Codex ブリーフ：<task-name>

14タスク識別

タスク名：<task-name>
タスクID：YYYYMMDD_<slug>
生成日：YYYY-MM-DD
担当Codex：#1
目的：この作業で作るもの、直すもの、確認するものを一文で書く。

151. 読むべきファイル（順番厳守）

Codexは以下をこの順で読んでから着手すること。

AGENTS.md または CLAUDE.md
.claude/rules/model-operation.md
skills/<必要なskill>/SKILL.md
<task-specific-file>

162. 対象素材

処理の起点となるファイル、フォルダ、URL、ログ。

<path/to/input>

173. やること（具体）

[ ] 指定ファイルを順番通り読む。
[ ] 対象素材から必要情報だけを抽出する。
[ ] 指定された出力先に成果物を作る、または指定範囲だけを更新する。
[ ] 採用条件に照らして自己検査する。
[ ] 最後にDONEまたはBLOCKEDを出す。

184. 出力形式

出力先：<path/to/output.md>
書式：Markdown
言語：日本語
ファイル名の禁止文字：/ \ : * ? " < > |

195. 採用条件

[ ] 指定された読む順番を守っている。
[ ] ブリーフ外のファイルを編集していない。
[ ] 素材にない数字、実績、事実を創作していない。
[ ] 出力先と書式を守っている。
[ ] 既存ノートを意図せず上書きしていない。
[ ] 完了報告にDONEまたはBLOCKEDがある。

206. やってはいけないこと

ブリーフ外の作業に手を出さない。
「いい感じに」「適切に」で判断しない。
実パス、顧客情報、秘密情報を公開用成果物へ出さない。
既存ノートを意図せず上書き、削除しない。
許可されていない設定フォルダに触れない。
未確認の数字や成果を作らない。

217. 完了報告の書式

ログの最終部に必ず出す。

DONE: created=<n> updated=<n> skipped=<n>
files:
- <作成・更新したファイルのパス>
notes:
- <固有名を伏せる処理、判断保留、スキップ理由>

228. 判断保留時の動作

ブリーフに書かれていない判断が必要になったときは、勝手に決めずに停止する。

BLOCKED: <理由>

23Codex 起動コマンド例（PowerShell）

codex exec --skip-git-repo-check --sandbox workspace-write --full-auto `
  (Get-Content "ops/codex/briefs/active/<task-slug>.md" -Raw) `
  *>&1 | Out-File "ops/codex/runs/<task-slug>.log"

24Codex 起動コマンド例（bash / Mac・Linux）

codex exec --skip-git-repo-check --sandbox workspace-write --full-auto \
  "$(cat "ops/codex/briefs/active/<task-slug>.md")" \
  > "ops/codex/runs/<task-slug>.log" 2>&1

25並列起動例（PowerShell）

Start-Job {
  codex exec --skip-git-repo-check --sandbox workspace-write --full-auto `
    (Get-Content "ops/codex/briefs/active/task1.md" -Raw) `
    *>&1 | Out-File "ops/codex/runs/task1.log"
}

Start-Job {
  codex exec --skip-git-repo-check --sandbox workspace-write --full-auto `
    (Get-Content "ops/codex/briefs/active/task2.md" -Raw) `
    *>&1 | Out-File "ops/codex/runs/task2.log"
}

26一次検査チェック

指揮役は、Codex完了後に次を確認する。

[ ] DONEマーカーがある。
[ ] files一覧がある。
[ ] notesに判断保留や置換が書かれている。
[ ] BLOCKEDやエラーが残っていない。
[ ] ブリーフ外の作業をしていない。
[ ] 採用条件を満たしている。

付録B

27特典2_モデル別ルーティング表

28固定する役割

役割	担当	責任
指揮役	利用環境で選べる高性能モデル	作業分解、委譲先決定、受け入れ条件、設計判断、リスク判断、最終確認
実装ワーカー	Codex	独立して進められる実装、コード修正、テスト、ファイル操作、バッチ処理、再現可能な処理
軽作業ワーカー	軽作業向けモデル	軽微な単発編集、読み取り、調査、文章下書き、通常レビュー、定型整理

29自動ルーティング（上から順に判定）

次のいずれかなら、指揮役が直接処理する。

受け入れ条件を書くこと自体が難しい。
設計判断が成果の中心。
セキュリティ、認証、課金、データ消失リスクがある。
実装ワーカーまたは軽作業ワーカーが同じ問題に2回失敗している。
仕様に矛盾がある。
長時間の文脈保持が必要。
手戻りコストが高い。

高度判断を必要とせず、独立した実装、変更、テスト、処理として完了できるなら、Codexへ委譲する。

読むファイルを指定できる。
触る範囲を指定できる。
出力先を指定できる。
採用条件を書ける。
DONE/BLOCKEDで戻せる。

それ以外の軽微な単発編集、調査、読み取り、文章下書き、通常レビュー、定型整理は、軽作業ワーカーへ委譲する。

同じ作業をCodexと軽作業ワーカーに重複委譲しない。

比較実験を行う場合だけ、目的と採用基準を先に定義する。

30境界で迷った場合

実行可能な独立作業として切り出せる → Codex
変更範囲が小さく、定型的な知的作業で完結する → 軽作業ワーカー
判断そのものが成果、または失敗時の影響が大きい → 指揮役

31ROUTE返却ルール

軽作業ワーカーが作業中に実装規模の拡大を検知したら、次のマーカーで返す。

ROUTE: Codex
理由：<実装規模が拡大した理由>

高度判断が必要になったら、次のマーカーで返す。

ROUTE: Orchestrator
理由：<指揮役判断が必要な理由>

32指揮役の一次検査

Codex完了後、指揮役は次だけを見る。

DONEマーカーがあるか。
files一覧があるか。
notesに置換、判断保留、未対応が書かれているか。
BLOCKEDやエラーが残っていないか。
ブリーフ外の作業をしていないか。
採用条件を満たしているか。

33置き場所例

.claude/rules/model-operation.md

CLAUDE.mdやAGENTS.mdには、詳細を全文貼らず、次のように参照だけを書く。

モデル別ルーティングの詳細は `.claude/rules/model-operation.md` を参照する。

付録C

34特典3_セットアッププロンプト集

35使い方

このファイルは、Claude CodeとCodexを分業させるためのプロンプト集です。
環境依存の名称は、自分の環境に合わせて置き換えてください。
実パス、ユーザー名、顧客情報は入れないでください。

361. Codex連携セットアップ依頼

Claude Code環境内でCodexをセットアップしてください。

インストール済み、またはこれからインストールする公式のCodex連携プラグインを使用します。

Codexセットアップコマンドを実行してください。

Codex CLIが欠落している場合は、インストール手順を確認してください。

Codexがインストールされているが認証されていない場合は、私に認証を求めてください。

認証が完了したら、Claude Code内からCodexが動作することを確認してください。

次に、Codexへ作業委任できるサブエージェントまたはコマンドが利用可能であることを確認してください。

セットアップ中にプロジェクトコードを変更しないでください。

372. Codexプラグイン導入コマンド例

/plugin marketplace add openai/codex-plugin-cc
/plugin install codex@openai-codex
/reload-plugins

※2026年7月時点のClaude Codeで動作確認済み。

環境によって、プラグイン名やインストール方法が変わる場合があります。

38ガード設定の型

危険コマンドは、settings.json のpermissionsでdenyに入れます。

{
  "permissions": { "deny": ["Bash(rm -rf:*)"] }
}

パスや内容を見て止めるものは、PreToolUseのhookに分けます。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          { "type": "command", "command": "pwsh -NoProfile -File .claude/hooks/block-obsidian.ps1" }
        ]
      }
    ]
  }
}

この型では、Write/Editの直前に .obsidian/ など触ってはいけないパスを検査します。
実行前に、自分の環境で利用できる名称を確認してください。

393. 委任ワークフロー指示

これからは、このワークフローを使用してください。

あなたはオーケストレーターです。

指揮役モデルを、計画立案、リポジトリ理解、アーキテクチャ決定、タスク分解、最終レビューに使用します。

タスクに大規模な実装、デバッグ、テスト修正、リファクタリング、または複数ファイルのコード編集が必要な場合、Codexを実行者として使用します。

Codexに委任する際は、環境で利用できるCodex委任コマンドまたはサブエージェントを使用します。

Codexモデルとして、利用環境で選べる高性能設定を優先してください。

Codexタスクは集中して具体的に保ってください。

Codexが完了したら、受け入れる前に自分で結果を検査してください。

Codexの出力を盲目的に信頼しないでください。

404. 読み取り専用テスト

次の作業をCodexへ委任してください。

目的：このリポジトリの構成を読み、主要フォルダの役割をまとめる。

制約：ファイル変更は禁止。

読むもの：
1. AGENTS.md または CLAUDE.md
2. README.md
3. 主要フォルダ一覧

出力：
- 主要フォルダの役割
- 不明点
- 次に整備すべきファイル

完了報告：
最後に次の形式で出してください。

DONE: created=0 updated=0 skipped=<n>
files:
- <読んだファイル>
notes:
- <不明点または判断保留>

415. ブリーフ作成依頼

次の作業をCodexへ委譲するためのブリーフを作ってください。

作業内容：<ここに作業内容を書く>

ブリーフには必ず次を含めてください。

1. タスク識別
2. 読むべきファイル（順番厳守）
3. 対象素材
4. やること
5. 出力形式
6. 採用条件
7. 禁止事項
8. DONE/BLOCKEDの完了報告

空欄を残さないでください。
判断が必要な点があれば、勝手に決めずに質問してください。

426. Codex一次検査依頼

Codexの実行ログと成果物を一次検査してください。

確認すること：

1. DONEマーカーがあるか。
2. files一覧があるか。
3. notesに置換、判断保留、未対応が書かれているか。
4. BLOCKEDやエラーが残っていないか。
5. ブリーフ外の作業をしていないか。
6. 採用条件を満たしているか。
7. 過剰実装がないか。

出力は、次の形式にしてください。

判定：採用 / 修正必要 / BLOCKED
理由：<短く>
確認したファイル：
- <path>
次の一手：<必要な場合だけ>

437. L1 report-only運用プロンプト

STATE.mdとLOOP.mdを読んで、今日の状態を整理してください。

モードはL1 report-onlyです。
ファイル変更は禁止です。
自動修正は禁止です。

出力するもの：

1. 今日見るべきこと
2. 止まっていること
3. 人間が決めること
4. Codexへ委譲できる候補
5. まだ委譲しないほうがよい候補

最後に次を出してください。

DONE: report-only
files:
- <読んだファイル>
notes:
- <判断保留>

44固有名を伏せた置換

特定ユーザー名を含む実パスは、<project>または<path>に置換。
特定モデル名に依存する箇所は、利用環境で選べる高性能設定に置換。
サブエージェント名は、環境で利用できるCodex委任コマンドまたはサブエージェントに置換。
顧客情報、未公開事業戦略、個別の導線情報は入れていない。