Codexには「作って」
ではなく「目的・制約・完了条件」を渡す

Codex依頼はお願いではなく、作業空間の設計である

Codexに「この機能を作って」とだけ伝えると、AIは目的を推測しながら動く。推測が当たれば速いが、外れれば余計なファイルを触り、既存のデザインやルールを崩す。AIの実装力が高いほど、曖昧な指示の被害も大きくなる。

だからCodex依頼では、作業内容より先に作業空間を決める。対象ディレクトリ、編集してよいファイル、触ってはいけないファイル、参照すべきテンプレート、完了条件を並べる。AIを自由にするのではなく、動いてよい範囲を明確にする。

これはAIを縛るためではない。むしろ、迷わず進めるための地図である。制約があるほど、Codexは安全に速く動ける。

目的、対象、禁止、検収条件を一つのセットで渡す

よいCodex依頼には、最低でも四つの要素が必要である。何のためにやるのか。どこを変更するのか。何をしてはいけないのか。最後に何を満たせば完了なのか。この四点が揃うと、AIの作業はかなり安定する。

特に禁止事項は軽視しない方がよい。共通CSSを変えない、ルールファイルを編集しない、既存記事を触らない、機能追加をしない、などである。AIは改善のつもりで余計な修正をすることがあるため、禁止事項は品質を守るブレーキになる。

完了条件も重要である。表示確認、リンク確認、sitemap更新、差分の範囲、エラーがないこと。ゴールが明確であれば、Codexは作業後の確認まで含めて進めやすい。

Codexには判断より、変換と整合性チェックを任せる

Codexが強いのは、決まったルールに沿ってファイルを作り、既存構造に合わせ、リンクやメタ情報を整える作業である。記事MarkdownをHTMLテンプレートへ流し込む。slugに合わせてcanonicalを作る。indexとsitemapを更新する。こうした整合性が求められる作業では非常に頼りになる。

一方で、戦略判断やブランド判断を丸投げすると危ない。この記事を公開すべきか、どの表現が自分らしいか、どのリスクを許容するかは人間が握るべきである。

つまりCodexは、決める存在ではなく形にする存在として使うと強い。人間が判断し、Codexが実装し、人間が差分を見る。この役割分担が安定運用の基本になる。

弱い使い方と強い使い方を分けて考える

Codex依頼を作業指示ではなく制約設計として捉え、目的・編集範囲・禁止事項・完了条件を渡すことで実装品質を安定させる。

Codexを安定させるのは、作業条件の設計である

Codexに任せる前に、目的、対象、禁止事項、完了条件を定義する。判断を丸投げせず、作業空間を人間が設計することで、AIは既存構造を壊さず実装担当として機能する。