きっかけ
「ノーコード開発」という言葉を聞いたとき、エンジニアとして正直な危機感があった。
同時に、かじってみたくもなった。自分の抱えているプロジェクトで AI にどこまで任せられるのか試してみたい。iOS（VIPER + RxSwift + UIKit）のアプリを開発していて、ChatGPT と Codex app をベースに AI 駆動開発を始めてみた。
Claude Code も検討したけど、料金プランの折り合いがつかなかった。で、別のツールも試してみようと Antigravity（AG）を使い始めたら、これが思った以上にしっくりきた。理由は後述するけど、対話型という構造が自分の開発スタイルに合っていた。
ちなみに、同時期に Claude Opus 4.6 と GPT-5.3-Codex がリリースされたのも大きい。モデル性能が上がったことで「これはもう本腰入れていいな」と腹をくくった。
結論から言うと、一番難しかったのは実装じゃない。
AI をどう統制するかだった。
AI に任せたら、構築してきた文化が壊れた
最初は普通に ChatGPT に実装相談していた。でもすぐに問題が起きる。
- 推測で API を決める
- 勝手にファイルを修正する
- 既存の公開契約（Protocol）を壊す
- 「それっぽく動くコード」を出してくる
動く。でも危ない。
何より絶望感があったのは、アーキテクチャ、コメント方針、命名規則 ── 長年かけて構築してきた開発文化を、全部テキストに言語化しないといけないということだった。
暗黙知でやってきたことを、全部ルールに落とす。でないと AI は「それっぽく」壊していく。既存プロジェクトに AI を入れるときの、最初にして最大のハードルがここだった。
そこで作ったのが AGENTS.md。AI に自由に書かせない仕組み。
効いた統制ルール
files=Yes / files=No モデル
一番効果があったのがこれ。
-
files=No→ 実装禁止。計画フェーズのみ -
files=Yes→ 変更対象が確定済み。実装開始していい
「考察」と「実装」を完全に分けた。AI は意外と止めないと止まらない。このモデルのおかげで、AI が確認もなしに走り出すのを防げた。
API 証跡必須（WF-28）
API は推測禁止。実体ファイルのパス、行番号、型根拠を必ず出させるようにした。
これを入れてから「それっぽいレスポンスをでっちあげる」現象が激減した。地味だけど一番効いたルールかもしれない。
停止テンプレ（WF-30）
曖昧なときは必ず止まれ、という仕組み。停止時は不足情報・影響範囲・代替案をセットで出させる。
AI に「進めるな」と言える仕組みは本当に大事だった。放っておくと、AI は自分なりに「たぶんこうだろう」で進めてしまう。
「AIならナレッジも自動化できるんじゃないか」
ルールを人力で整備していくなかで、ふと思った。AI なら走査システムを作って、ノウハウ自体を自動化できるんじゃないかと。
そこから ai-scan ポリシー（WF-25〜27）が生まれた。Module のコード構造を JSON に走査して、設計パターンの適合度を判定する仕組み。schema バリデーション、facts の冪等性チェック、source_commit の鮮度管理まで作り込んだ。
でも結局、壁にぶつかった。
ナレッジを集めるのは AI にできる。でも「何が正解か」を決めるのは人間しかできない。
「この場面では ViewData に items を入れない」「この Protocol は増やさない」── そういう判断は、そのプロジェクトの歴史を知っている人間じゃないと下せない。長年の開発で積み上げてきた文脈がないと、AI がいくらスキャンしても「事実の列挙」にしかならない。
ai-scan は参考情報としては使える。でも設計の根拠にはならなかった。
制度疲労
統制を強めたら、別の問題が出てきた。
files=Yes / No の矛盾
文脈上の files=No と PlanB 本文の files=Yes が衝突する場面が出てきた。AI は律儀にこれを検出して止まる。正しい。でも進まない。
「出典IDって何？」
source_of_truth を厳密にしたら、「出典IDとは何を指すのか、URL？ チケット番号？」と現実がついてこなくなった。AI は完璧を求める。現実は曖昧。ここで何度か衝突した。
ChatGPT と Codex の監査合戦
ChatGPT が指摘 → Codex が修正 → ChatGPT がさらに改善提案。AI 同士が延々と監査し合う。正しいんだけど、重い。終わらない。
半角スペース事件
CHANGELOG に半角スペース規則がない。Git コミットルールにはある。Guardrail を足すか？ でも足すと全体が重くなる。
ここで気づいた。統制は簡単に増える。でも削るのは難しい。
この時点で AGENTS.md は682行。DG4件、WF30件。テンプレートだけで本文の3割。正直、自分でも全部は把握できてなかった。
AG が682行を採点したら67点だった
ツールを Google Antigravity に移行して、最初にやったのが既存の AGENTS.md のレビューだった。
ChatGPT と Codex で苦労して積み上げた682行のルールファイル。AG に「これレビューして」と渡してみたら、64点。
あなたはソフトウェア開発プロセス設計の専門家です。
添付の AGENTS.md は、個人プロジェクトにおける駆動開発運用ルールです。
以下の観点で総合レビューを実施してください。
■ 評価方法
各観点を 1〜5 点で採点し、理由を簡潔に述べてください。
その後、総合スコア（100点換算）と成熟フェーズ判定を出してください。
■ 評価観点
1. 構造健全性
- ルールの整合性
- 内部矛盾の有無
- 依存関係の明確さ
2. 再現性 / 監査性
- 誰が実行しても同じ結果になる設計か
- 証跡設計は十分か
- StopCondition の明確さ
3. 運用負荷
- 認知負荷の高さ
- 通常タスクでのコスト
- 制度疲労リスク
4. 拡張性
- チーム運用への展開可能性
- 難易度別レイヤー分離の余地
- 将来的な簡略化可能性
5. 駆動開発成熟度
- 個人レベル / 小規模チーム / 組織レベルのどこか
- 防御過多 or 防御不足の傾向
■ 出力形式
- 各項目スコア（1〜5）
- 総合評価（A〜E）
- 成熟フェーズ判定（初期 / 安定 / チーム対応可能 / 組織レベル）
- 制度疲労リスク（低 / 中 / 高）
- 分割推奨度（不要 / 将来 / 早期 / 即時）
- 抽象総評（300字以内）
- 改善提案（最大5つ、抽象レベル）
具体的な文言修正は不要です。
あくまで設計レベルのレビューに留めてください。
総合評価
項目 スコア
構造健全性 4 / 5
再現性 / 監査性 4 / 5
運用負荷 2 / 5
拡張性 3 / 5
駆動開発成熟度 3 / 5
総合スコア 64 / 100
総合評価 B-
成熟フェーズ 安定（個人最適化済み、チーム対応は未到達）
制度疲労リスク 高
分割推奨度 早期
正直ちょっと凹んだ。でも指摘内容を見て納得もした。
- Codex CLI 固有の暴走防止ルールが大半を占めている
- 対話型ツールでは不要なゲートが多い
- テンプレートが肥大化して本質が埋もれている
- 設計原則（DG）とツール固有の運用ルール（WF）が混在している
要するに「ルールとしては機能するけど、このツール（AG）では過剰で、読み手が消化しきれない」という評価だった。
ここから108行への再設計が始まった。
なぜ108行で足りるのか
Codex CLI と AG の構造的な違い
| 観点 | Codex CLI | AG |
|---|---|---|
| 実行モデル | 非同期バッチ | 対話型リアルタイム |
| 人間の介入 | タスク投入後は基本なし | 毎ターン確認できる |
| ファイル操作 | 自律実行 | 提案 → 承認 → 実行 |
対話型ということは、毎ターン自分が見ている。
「承認前に実行するな」「開始宣言しろ」「ゲート通過してから実装しろ」── これ全部、対話そのものがゲートになるから明文化する必要がない。
682行の半分以上は「Codex CLI を信用してなかったから」書いていたルールだった。ツールが変わったら、書かなくていいものが見えた。
残したのは「設計の型」と「運用の型」だけ
Design Guardrails（設計の型）: DG-01〜05
- ViewData の責務、Presenter の出力契約、Navigation 構造、初回表示の信頼性、コメント規約
- これは VIPER + RxSwift の急所。AI ツールに関係なく必要
Workflow Guardrails（運用の型）: WF-01〜10
- CHANGELOG・コミット規約、ビルド検証、既存パターン参照、Protocol 追加禁止、ファイル操作ガード
- 「暴走防止」系で残したのは WF-10（ファイル操作ガード）だけ
手順的な知識はスラッシュコマンドに分離した。
| コマンド | やること |
|---|---|
/task |
タスク開始（ルール確認→設計→実装→検証） |
/completion |
完了フロー（CHANGELOG + コミット→承認→実行） |
/review |
ルール改善（DG/WF の追記・修正→承認→反映） |
VIPER + RxSwift は AI が苦手
この構成で AI 駆動開発やってる話、ほとんど見かけない。実際やると、なかなかきつい。
- ファイル数: 1 Module で10ファイル超える
- 疎結合: Protocol 経由で流れが非連続。AI が依存関係を追いにくい
-
RxSwift:
flatMapのネストやwithLatestFromの合成は AI もしんどそう - テンプレート制約: Generamba の構造から外れないようにする必要がある
対策は DG-01〜04 で VIPER の急所を押さえること。「ここだけは守れ」という型をルールで固定すると、AI の出力がブレにくくなる。
ツールの棲み分け
試行錯誤の末に落ち着いた使い分け。
- ChatGPT → 壁打ち相手。設計議論、ルール改善の叩き台。コードには触らせない
- Codex app → 定型バッチ（縮小中）。682行のルールが要る時点で正直しんどくなった
- AG → ペアプロの相方。設計→実装→検証を対話でフルサイクル回す
核心は信頼モデルの違い。
- ChatGPT: 出力を人間が全部レビューする前提
- Codex app: 出力を事後レビュー → だから厳密なルールが要る
- AG: 出力を逐次レビュー → 対話がルールの代わりになる
学んだこと
- AI は放置すると推測する。証跡を要求する仕組みが要る
- AI は止めないと止まらない。停止条件の設計が最重要
- ナレッジの収集は AI にできるが、取捨選択は人間にしかできない。長年の開発で何が正解かを知っているのは人間だけ
- 統制は簡単に増える。削るのは難しい。だから「増やす」より「育てる」仕組みが要る
- 既存プロジェクトに AI を入れるなら、忍耐力がいる。やりたいことをちゃんとイメージして、作業は細かく、質を高く保つ。雑にやると既存の文化が壊れる
682行 → 108行は「ルールを削った」んじゃなくて、「ツールが変わったことで、書かなくていいものが見えた」結果。108行も完成形じゃない。/review で今後も変わっていく。
でも、こうやってタスクを重ねて、ルールを育てて、自分に合ったエージェントが出来上がっていけば ── これからの「時間」という価値観そのものが大きく変わるに違いない。
そう信じて、日々研鑽している。
AI が。
環境情報
| 項目 | 詳細 |
|---|---|
| アプリ構成 | iOS / UIKit / VIPER / RxSwift |
| ChatGPT | GPT-5.3 |
| Codex app | GPT-5.3-Codex |
| Antigravity | Claude Opus 4.5 → 4.6 |
| ルール管理 | AGENTS.md + .agent/workflows/（スラッシュコマンド） |
| 圧縮前 | 682行 / DG4件 + WF30件 |
| 圧縮後 | 108行 / DG5件 + WF10件 |