きっかけ

「ノーコード開発」という言葉を聞いたとき、エンジニアとして正直な危機感があった。

同時に、かじってみたくもなった。自分の抱えているプロジェクトで 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件