はじめに
ChatGPTのCodexで個人開発していました。
便利でしたが、毎回こうなっていました。
- 計画して
- 実装して
- レビューして
- lintして
- また修正して
便利だけど、これ毎回やるのしんどくない？と思いました。
最初は「もっと良いプロンプトを書けばいいのかな」と思っていましたが、調べたり実際に触ったりする中で、考え方が変わりました。
AIに頑張ってもらうのではなく、AIがミスしにくい環境を作るべきでは？
いわゆるハーネスエンジニアリング（AIが安全に・自律的に働ける環境を整える考え方）に近い発想です。
そこで、ChatGPT画面からの利用だけでなく、Codex CLIベースで“AIが安全に自走しやすい開発環境”を作ってみました。
まずCodex CLIを導入
公式:
https://developers.openai.com/codex/cli
セットアップはかなり簡単でした。
npm i -g @openai/codex
codex
npm i -g @openai/codex@latest
ログインすればすぐ使えます。
最初にやったこと: AGENTS.md
まず、プロジェクト直下に AGENTS.md を作成しました。
これは、このリポジトリでAIエージェントが従うルールブックです。
例えばこんな内容です。
- 最小変更を優先
- 無関係なリファクタ禁止
- any の安易な利用禁止
- UXを勝手に変えない
- lint / build を実行する
- 機密情報をコミットしない
さらに、自分のプロダクト固有ルールも追加しました
私のアプリは資格学習支援サービスなので、
- 学習継続の心理負荷を下げる
- 高機能より迷わないUI
- 3タップ以内の入力を理想とする
- 学習継続を阻害しない
のようなプロダクト思想もルール化しました。
ここが意外と重要でした。
普通のコーディングルールだけでは、
「このプロダクトで何を大事にするか」は伝わらないからです。
いきなり気づいたこと
① AIはめちゃくちゃ許可を求めてくる
例えばこんな感じです。
- package-lock変えていい？
- この修正やっていい？
- このファイル触っていい？
安全性としては正しいです。
でも、自動化したい側からするとかなりテンポが悪い。
ここで気づいたのは、
AIが迷うことは先にルール化しておくべきということでした。
② 同じ失敗を繰り返す
例えば:
- package-lockを毎回触る
- 同じlint違反
- 型の雑な扱い
これも毎回プロンプトで注意するのではなく、仕組みとして防ぐ方が強いと感じました。
逆にルールを増やしすぎると重くなるので、毎回起きる問題だけルール化するのが大事そうです。
③ 無料枠でもかなり動く
これは正直驚きました。
無料枠でもかなり試せました。
実際にできたこと:
- リポジトリ全体分析
- 問題指摘
- 全体修正
- 軽微修正を数回
- 最終レビュー
「まず試してみる」には十分すぎました。
でも全自動とは程遠い
毎回
- 計画して
- 実装して
- レビューして
- lintして
は面倒すぎる。
なので次に、自動化を進めました。
skills を作る
Codexには「よく使う作業手順を名前付きで保存できる」skillがあります。
毎回長いプロンプトを書く代わりに、
$review-diff
のように呼び出せます。
作ったのはこんなskillです。
plan-safe-change
- 実装前に安全な計画を作る
- 影響範囲
- リスク
- 対象ファイル
- 検証方法
を整理します。
review-diff
- 実装後レビュー
- ルール違反
- 目的外変更
- 型安全性
- server/client境界
などを確認します。
safe-implement
一番便利だったやつ。
$safe-implement
で、
-計画
-実装
-lint
-typecheck
-build
-差分レビュー
まで一連でやります。
かなり楽になりました。
hookで自動チェック
Git hook
commit前に自動で
npm run lint
npm run typecheck
を実行、失敗したらcommitできません。
Codex hook
Codexがファイル編集した直後にも
npm run lint
npm run typecheck
を自動実行するようにしました。
つまり、AIが壊した瞬間に検知できます。
その他やったこと
他にも以下を追加しました。
lintルール強化
-any 禁止
-ts-comment制限
-warningもfail
-consistent-type-imports
-server/client境界保護
-Client Componentから server-only code をimport禁止。
Zodでschema validation
OpenAIのJSONレスポンスをそのまま信用しないようにしました。
AIはそれっぽいJSONを返しても、shapeがズレることがあります。
なので、
AI出力も外部入力として扱う
ようにしました。
学び
ハーネスエンジニアリングという言葉自体は、セミナーなどで聞いたことがありました。
でも実際に自分でやってみると理解度が全然違いました。
最初は、
AIコーディング = 良いプロンプトを書くゲーム
だと思っていました。
でも実際は違いました。
AIがミスしない構造を作るゲーム
でした。LLMに頼らずにルールベースで設定できる部分も多いです。
この感覚はかなり大きな学びでした
次にやりたいこと
まだ途中です。
次はこのあたりをやりたいです。
-API scaffold
-subagents
-MCP
-GitHub PR自動レビュー
もっと自動化できる範囲を増やしていきたいです。