最近、バイブコーディングはも夢のような作業ではなくなった。
できて当たり前の技術のひとつになってしまった。
2026年2月。
さて、とはいえまだ実戦経験が少ない私にとってただ闇雲に作業をすすめるよりも最初の設計段階がとても大事だとわかってきた。
そう、最初につくるべきは、.mdだ。これをルールとして読み込んでもらい。作業を進めてもらう。
とはいえ私の場合はそこまで大きなプログラムを創るわけでもないので、最低限のルールと何を作りたいのかタスクは何が残っているのか。また過去に何をやってきたのかを残しておく土台を作っておくことが大切かなと思っている。
AIに微課金しかしていないため、途中で開発が止まってしまうこともある。
その時にほかのAIを使って作業を続行できるようにしておくためにも、mdを的確に書いておけばそこまでずれることはないと思う。
では、「最初のステップから」Codexにどう伝えるかを、実運用そのままの順番で書きます。
これは考え方ではなく、実際に打つ指示です。
ステップ0：前提（これは人間がやる）
まず、リポジトリ直下に 空でもいいから 次の4つを用意します。
AGENTS.md
PLANS.md
LOG.md
PROJECT.md
中身が空でもOKです。
「場所が存在する」ことが重要です。
ステップ1：最初に Codex に伝える一文（超重要）
Codexを起動したら、最初の指示はこれです。
このリポジトリでは、AGENTS.md / PLANS.md / LOG.md を使って作業します。
まず AGENTS.md を読んだ前提で動いてください。
これを言わないと、Codexは
「一発回答モード」
「即コード生成モード」
に入りやすくなります。
ステップ2：AGENTS.md を書かせる（最初の仕事）
次にいきなり作業を頼まない。
まず「作法」を書かせます。
まず、このプロジェクト用の AGENTS.md を作成してください。
目的は、Web調査とCSV生成を安全に行うことです。
短く、運用ルール中心で書いてください。
ここで Codex が書くべき内容はこうなります（例）。
# AGENTS.md
## Role
- Web調査とデータ整理を担当する
## Rules
- 推測は禁止。確認できない情報は空欄
- 判断や変更は必ず LOG.md に記録
- 作業定義は PLANS.md を最優先する
## Workflow
- 計画 → 実行 → ログ → 次の提案
👉 この時点で「作法の主導権」はあなたにあります
ステップ3：PLANS.md を「一緒に」作る
ここが一番大事です。
PLANS.md は任せない。共同編集です。
指示はこう出します。
次に、データベース作成タスクの PLANS.md を作りたい。
私が要件を出すので、構造化してください。
そして、あなたは要件を「箇条書き未満」で渡す。
・駄菓子屋さんのリスト作成
・既存の作りかけデータあり
・ネット検索で補完
・CSVで使いたい
・趣味での駄菓子屋さんデータベース作成が目的
Codex が構造化 →
あなたが修正 →
確定。
👉 ここで仕様が固定される
ステップ4：実行指示は「PLANS.md 参照」で出す
仕様が決まったら、初めて作業を頼みます。
PLANS.md に従って作業を開始してください。
途中の判断・発見・変更は LOG.md に追記してください。
まずは既存データの欠損整理から。
この言い方がポイントです。
- ❌「調べてCSV作って」
- ⭕「PLANS.md に従って」
Codexは
「考える場所」と「実行する場所」を分けて動きます。
ステップ5：LOG.md が勝手に育つ状態を作る
途中であなたがやることは、これだけ。
LOG.md を見て、判断がおかしければ指摘する
修正指示はこう出します。
この判断は不要です。
PLANS.md の Done Definition に従って修正してください。
感情も説明もいりません。
まとめ（超重要）
最初のステップでやるべきことはこれだけです。
- mdの「場所」を先に作る
- 最初の一文で「md前提運用」を宣言
- AGENTS.md を先に書かせる
- PLANS.md は共同で作る
- 実行は PLANS.md 参照で命じる
- 履歴は LOG.md に集約
この順番を守ると、Codexは
「作業者」になり、あなたは「設計者」のままでいられます。
これはGitを使わない人にとって、
一番事故らないCodex運用の初動です。
次にやるとしたら
「PLANS.md の良い粒度」
「CSV生成を途中で止めないDone Definition」
ここを詰めると、一気に精度が上がります。
これさえつくっておけばcodexでもantigravityでもまたいでもだいじょうぶそうか
結論として、あなたが最初に用意した “作法ドキュメントセット（AGENTS.md / PLANS.md / LOG.md / PROJECT.md） は、Codex でも Antigravity でも共通して使える有効な運用仕様になります。ただし “それだけで完全” とは言えません。理由を整理します。
1) AGENTS.md は跨ツールに有効な共通仕様
AGENTS.md は AI コーディングエージェントにとっての “プロジェクト仕様の公式ドキュメント” です。Codex はルートにある AGENTS.md を最初に読み込んでプロジェクトの前提・ルール・ワークフローを理解します。これは Codex に限らず他の AI コーディングツールでも同じ設計思想 です。
その意味で、AGENTS.md をしっかり作れば、Codex と Antigravity の両方で通用する基盤になります。
2) 汎用設計だけなら複数ツール間で共通化可能
Antigravity の場合、標準化された agent/skill 形式でエージェントを拡張したり、リポジトリ構造をルール化する方法があります（例：.agent/rules, .agent/workflows）。実用上、これも ドキュメント + ルール + ワークフロー を押さえておけば他ツール（Codex や Claude Code のスキル等）でも読み込み対象になります。
つまり、最初の設計とドキュメント作法がツールをまたいでも役に立つ状況は成立します。
3) ただし「作法ドキュメントだけ」で完結ではない
実際に複数エージェント・複数ツールで運用する際には、次のような点も考慮する必要があります：
① それぞれのツール固有の補完ルール
Codex は AGENTS.md を読み込みますが、それだけではなくプロンプトやコマンドの実行ポリシー（例：テスト実行、Lintルール、実行可能コードの書き方）を明示的に記述する必要があります。
② Antigravity のワークフロー定義
Antigravity では .agent/ 配下にワークフローを置く運用が標準化されつつあります（例：ルールとワークフローファイル群）。単なる Markdown だけではなく、フォルダ構造そのものがエージェントの「身体」になるという考え方が推奨されています。
③ スキル（Agent Skills）対応
最新の Antigravity と一部他ツールでは、Agent Skills という標準化された能力パッケージが使えます。これは複数ツール間でも共通化を進める標準仕様です。
4) 何を作れば「またいで使える」のか（最短セット）
あなたが基本に置くべきは次の4点です。
1) AGENTS.md
→ ツール共通：ルール・前提・ワークフロー
2) PLANS.md / PROJECT.md
→ 目的・設計・仕様・完了条件（AI にやらせたいこと）
3) LOG.md
→ 判断・履歴・変更ログ（Gitを使わない運用）
4) Optional: .agent/ ワークフロー定義
→ Antigravity 向けにワークフローステップを明確化
5) 結論
はい、あなたが最初に用意しようとしているドキュメント構成は、Codex と Antigravity の両方で有効です。
ただし、
- AGENTS.md は「AI にプロジェクトのルールを伝える公式仕様」であり、ツールをまたいでも読み込まれる
- それだけではなく、具体的なルール・ワークフロー・完了条件を明確に書くことが重要
- Antigravity ではワークフロー構造をリポジトリ階層で表現する方法もある
という点を押さえる必要があります。煌びやかに一つのファイルだけを用意すれば済む、という話ではなく、プロジェクトの設計情報を整理したドキュメント一式がツールをまたいで機能するという形です。
それだけ守れば、CodexでもAntigravityでもまたいで運用できる土台が成立します。
