なぜ codex と antigravity を併用すると迷子になるのか

作業が進むたびにファイルが増え、どれが最新なのか判断できなくなる瞬間がある。これは単なる“整理不足”ではなく、判断を預ける場所が存在しないことが原因だった。codex は指示に従って新しいファイルを次々と生み、antigravity は作業ログを積み上げる。どちらも強力だが、両者が生む情報量に対して、受け皿が用意されていなければ、思考は編集画面のどこかに散ってしまう。私はこの状態に陥り、目的を追うのではなく、ファイルを追う作業に時間を奪われた。

task.md が迷いを止める

作業の中心は task.md にある。目的と現状と次の行動が一枚にまとまることで、作業の起点が固定される。何を達成するために今日の作業が存在するのかが明確になり、判断がぶれなくなる。どれほどファイルが増えても、task.md に立ち返るだけで、プロジェクトの向かう方向が再び見える。ここに書く言葉が、作業そのもののリズムを整える。

map.md が構造の崩壊を防ぐ

問題が起きた時、どのファイルに触れるべきか判断が止まることがある。これは構造が可視化されていないためだ。map.md はプロジェクト全体の姿を固定し、役割と位置関係を一行ずつ外に出す。これがあると、ファイルが増えても文脈が崩れず、codex に依頼するときも antigravity に作業を渡すときも、どの部分を扱うべきかが自然に見える。構造が見えると、作業は迷わず動き出す。

log.md が判断の喪失を防ぐ

作業を続けるほど判断が積み重なる。だが、残しておかない限り、理由はすぐに霧になる。log.md はその霧を晴らす役割を担う。採択した方針、捨てた案、方向転換の理由を短く残すだけで、未来の自分が同じ迷路に入らなくなる。決めた根拠を一つの場所に集めることで、判断の一貫性が保たれる。思考の往復が減り、作業の速度が上がる。

三枚がそろうとプロジェクトは前へ進む

task.md が方向を示し、map.md が道筋を描き、log.md が記憶を支える。この三枚が揃うと、codex と antigravity の併用がようやく機能し始める。生成物が増えても焦らず、判断が揺れても戻る場所がある。作業の流れを乱さないために必要だったのは、複雑な管理方法ではなく、役割の異なる三つのファイルだけだった。これが整ったとき、プロジェクトはようやく本来の目的に沿って進み始める。

🔧 プロジェクト起動プロンプト（コピペで使える）

あなたに依頼する前提として、以下の三つのファイルをプロジェクトの中枢として扱います。

■ task.md

作業目的・現状・ToDo を一枚にまとめた指揮書です。
常にここから読み始め、作業方針は task.md を基準に判断してください。

■ map.md

プロジェクト全体構造とファイルの役割を一覧化した地図です。
ファイルの追加・削除・編集を行う際は、map.md と矛盾がないか必ず確認してください。

■ log.md

意思決定の履歴を保管する記録書です。
採択した案・却下した案・仕様変更の理由がここに保存されます。
必要な場合のみ log.md を参照し、判断の連続性を確保してください。

🔽 実行時ルール

1. 作業に入る前に task.md → map.md → log.md の順番で読み込むこと。
2. 回答は必ず task.md の目的に沿う形で提案・生成すること。
3. 新しいファイルを作る場合は、map.md の構造に従い、必要なら map.md 更新案も提示すること。
4. 仕様変更や重要な判断が必要な場合は、log.md に追記すべき内容を短く提案すること。
5. 文脈が曖昧な場合は、task.md の不足点や曖昧箇所を指摘したうえで質問を返すこと。

🔽 プロジェクト開始宣言

以下の三枚のファイルを中枢として、このプロジェクトの作業を開始します。
まず task.md の目的に沿って、次のアクションを提案してください。

【実践編】プロジェクトを前へ進める「3つのフェーズ」

ここからは、実際にこの3ファイルをどう動かしていくのか、具体的な「作業の続き（運用フロー）」について解説します。 この管理術の真髄は、コードを書くことではなく「MDファイルを育てること」に主導権を置く点にあります。

フェーズ1：始動（Launch） – アンカーを打つ

プロジェクトの開始時、または一日の作業の始まりは、必ず task.md の更新からスタートします。いきなりコードを書き始めてはいけません。

1. 現状の言語化： task.md の「Current Status」に、今の状況を数行で書く。
2. 目的の再確認： 今日のゴール（ToDo）を明確にする。
3. AIへの共有： 冒頭で紹介する「プロジェクト起動プロンプト」を使用し、AIに3つのファイルを読み込ませる。

この儀式を行うことで、AIは「あなたの脳内」と同期した状態で待機状態に入ります。

フェーズ2：巡回（Cycle） – 作業のリズムを作る

実際の開発は、以下のループで進めます。コードエディタとMDファイルを行き来する「呼吸」のようなリズムです。

1. 指示（Prompt）： task.md に基づき、AIにコード生成を依頼。
2. 生成（Generate）： AIがコードを出力。
3. 更新（Update）：
   • 新しいファイルができたら map.md に追記する。
   • タスクが完了したら task.md のToDoにチェックを入れる。
   • 予期せぬエラーや仕様変更があったら log.md にメモする。

ポイント： 作業に詰まったら、すぐに task.md を開いてください。AIへの指示に迷うのは、task.md の記述が曖昧だからです。ファイルを更新することが、そのまま「的確なプロンプト」を作る準備になります。

フェーズ3：収束（Commit） – 記憶を定着させる

作業の区切り（Gitのコミット前など）には、必ず log.md を整理します。

• 決定事項の要約： 長い会話ログを読み返す必要がないよう、「結論」だけを log.md に残します。
• 次のセッションへのバトン： task.md の最後に「次はここから始める」というメモを残し、作業を終了します。

これにより、翌日のあなたは「昨日の自分」が何を考えていたかを0秒で理解し、ロケットスタートを切ることができます。

運用テクニック：ファイルが「肥大化」した時の対処法

長くプロジェクトを続けていると、特に log.md や task.md が肥大化し、AIのトークン制限（記憶容量）を圧迫することがあります。その際は「圧縮」を行いましょう。

• task.mdのアーカイブ： 完了したToDoは削除するか、archive/ フォルダへ移動させます。常に「現在」と「直近の未来」だけを残します。
• log.mdの要約： AI自身に「これまでの経緯を10行で要約して」と依頼し、古いログを要約文に置き換えます。詳細なログは別ファイル（log_history_v1.mdなど）に退避させます。

「情報は捨てることで価値が出る」。この原則を守ることで、AIは常に鋭い回答を維持できます。

コピペで即起動！プロジェクト制御プロンプト

この管理術をAIに徹底させるためのプロンプトです。作業開始時、チャットの一発目にこれを貼り付けてください。

あなたに依頼する前提として、以下の三つのファイルをプロジェクトの中枢として扱います。

■ task.md
作業目的・現状・ToDo を一枚にまとめた指揮書です。
常にここから読み始め、作業方針は task.md を基準に判断してください。

■ map.md
プロジェクト全体構造とファイルの役割を一覧化した地図です。
ファイルの追加・削除・編集を行う際は、map.md と矛盾がないか必ず確認してください。

■ log.md
意思決定の履歴を保管する記録書です。
採択した案・却下した案・仕様変更の理由がここに保存されます。
必要な場合のみ log.md を参照し、判断の連続性を確保してください。

【実行時ルール】
1. 作業に入る前に task.md → map.md → log.md の順番で読み込むこと。
2. 回答は必ず task.md の目的に沿う形で提案・生成すること。
3. 新しいファイルを作る場合は、map.md の構造に従い、必要なら map.md 更新案も提示すること。
4. 仕様変更や重要な判断が必要な場合は、log.md に追記すべき内容を短く提案すること。
5. 文脈が曖昧な場合は、task.md の不足点や曖昧箇所を指摘したうえで質問を返すこと。

【プロジェクト開始宣言】
以下の三枚のファイルを中枢として、このプロジェクトの作業を開始します。
まず task.md の目的に沿って、次のアクションを提案してください。

まとめ：3つのファイルが「あなた」を自由にする

AI時代において、真に価値があるのは「コードを書く速度」ではなく、**「方向を指し示す力」**です。

task.md、map.md、log.md。 この3つは、AIという暴れ馬の手綱です。これらが整ったとき、あなたは「ファイルの管理」や「文脈の維持」という雑務から解放され、本来注力すべき「創造的なアイデア」の実装に100%集中できるようになるでしょう。

さあ、エディタを開いて、まずは task.md を作ることから始めてみませんか？