Antigravity でコードを書いていると、ふとした場面でこう思うことがあります。「あのとき、なんでこの設計にしたんだっけ？」
AIとのセッションの中で生まれた判断 — データベースのスキーマ選択の理由、ライブラリを選ばなかった経緯、あのAPIの癖 — これらはセッションを閉じた瞬間に揮発します。次のセッションでAIに尋ねれば、それなりの答えは返ってくる。でも、あのときの文脈はもう戻ってきません。
Obsidian を Antigravity のサイドキックとして使い始めてから、この「揮発する文脈」問題がかなり改善されました。2014年から個人開発でアプリとサイトを並行運用していると、数ヶ月前の設計判断に立ち返る場面が本当に多く、この仕組みには日常的に助けられています。今回は、私が実際に使っているワークフローを共有します。
なぜ Obsidian なのか
Obsidian の核心は「ローカルに保存された Markdown ファイルとリンク構造」にあります。データはすべて自分のマシン上にあります。このシンプルさが、Antigravity との相性を生み出します。
Antigravity はローカルのファイルを直接参照できます。Obsidian の Vault を Antigravity のワークスペースに含めれば、AIは自分の「記憶」として書き込まれた Markdown ノートを参照しながらコードを書けるようになります。
セットアップ — Vault をプロジェクトに隣接させる
フォルダ構成はシンプルにします。
my-project/
├── src/
├── package.json
└── .notes/ ← Obsidian Vault をここに置く
├── decisions/ ← アーキテクチャ決定記録（ADR）
├── patterns/ ← コーディングパターンのメモ
├── bugs/ ← ハマったバグと解決策
└── context/ ← プロジェクト全体像のメモ
.notes/ はプロジェクトルートに置き、Obsidian の Vault として開きます。.gitignore に含めるかどうかはチームの方針次第ですが、個人プロジェクトではリポジトリに含めて履歴管理しています。
アーキテクチャ決定を記録するパターン
Antigravity で設計上の判断をしたとき、そのまま流してしまわずに記録を残します。
たとえばデータ取得方法を検討したセッション後、以下のようなノートを作ります。
# ADR-001 データ取得に Zustand ではなく SWR を選んだ理由
## 背景
ユーザーダッシュボードのデータ取得層を設計中。Zustand とSWR が候補に上がった。
## 決定
SWR を採用する。
## 理由
- キャッシュ無効化のロジックを自前で書く必要がない
- フォーカス時の再取得が UX 上有利
- Antigravity との会話の中で「変更頻度の高いデータが多い」という特性が明確になり、SWR の設計思想と一致
## 却下した選択肢
Zustand — グローバル状態管理には向くが、サーバーデータのキャッシュには過剰
## 次のセッションで参照すべき文脈
`src/hooks/useUserData.ts` の設計はこの判断に基づいている。
変更する場合はキャッシュ戦略から見直すこと。このノートを .notes/decisions/ADR-001.md に保存しておくと、次のセッションで以下のように Antigravity に伝えられます。
.notes/decisions/ADR-001.md を参照した上で、useUserData フックを拡張してください。
SWR の選択理由を尊重しながら、リアルタイム更新の仕組みを追加したいです。
AIは ADR の文脈を読んだ上でコードを生成します。「なぜ SWR なのか」を一から説明する必要がなくなります。
バグパターンの蓄積 — 同じ罠を踏まない
開発中に遭遇したバグとその解決策を .notes/bugs/ に蓄積します。
# React Native の AsyncStorage + iOS 16 での競合状態バグ
## 症状
初回起動時に設定値が読めない。2回目以降は正常。
## 原因
AsyncStorage の読み取りと初期状態設定の順序が非同期で競合していた。
## 解決策
useMemo ではなく useEffect + setLoading パターンで初期化を明示的に遅延させる
## 参照コード
src/hooks/useSettings.ts (v2.1 以降)このノートが育っていくと、新機能を追加するセッションの冒頭でこう伝えられます。
新しい設定項目を追加します。.notes/bugs/ の過去のバグパターン（特にAsyncStorage関連）を
確認した上で、同じ問題が起きない実装にしてください。
Antigravity の出力をそのままノートに変換する
Antigravity が生成したコードの説明やアーキテクチャ提案を、そのままノートとして保存するプロンプトを使っています。
今の実装方針を Obsidian ノート形式で整理してください。
以下の構成で Markdown を出力してください。
# [モジュール名] の設計メモ
## 採用した方針
## 設計上のトレードオフ
## 依存しているライブラリとバージョン
## 次のセッションで伝えるべき文脈
出力された Markdown を .notes/patterns/ にペーストするだけです。3分かかりません。でも2週間後に「あのモジュールどうなってたっけ」となったとき、この3分が数時間を節約します。
コンテキストサマリーを定期的に作る
Obsidian の context/project-overview.md を定期的に更新します。これは Antigravity のセッション冒頭に読み込むプロジェクト全体像です。
# プロジェクト概要（2026-04-25 時点）
## 現在の状態
- iOS/Android 壁紙アプリ。App Store リリース済み。
- 主要機能: カテゴリブラウズ、お気に入り、動的壁紙
## 直近の変更点（過去2週間）
- 課金フローを RevenueCat に移行完了（ADR-012 参照）
- プッシュ通知基盤を Firebase に統合
## 未解決の問題
- Android の一部端末でスクロールパフォーマンスが低い（bugs/android-scroll-lag.md）
## 次の開発フェーズ
- ウィジェット機能の追加新しいセッションを始めるとき、このファイルを Antigravity に読ませてから作業を開始します。「前回の続きから」という感覚でAIと会話できるようになります。
実際に使って感じた変化
このワークフローを2ヶ月続けてみて、変わったことが2つあります。
ひとつは、Antigravity への指示が短くなりました。「あの件はノートに書いてあるから参照して」で済むようになり、セッション冒頭の説明コストが減りました。もうひとつは、自分自身の理解が深まりました。ノートに書き起こす過程で「なぜそうしたのか」を言語化する習慣がつき、設計の判断に自信が持てるようになりました。
AIに全部任せると、コードはできるけど理解が薄い、という状態になりやすい。Obsidian を挟むことで、その状態を少し防げている気がしています。
最後に、運用を続けるコツを1つだけ。ノートの「書式」を整えることに時間を使わないことです。私も最初はテンプレートを凝りすぎて続かなくなりかけました。ADR・バグ・設計メモの3種それぞれ見出し4つ程度の最小構成にしてから、無理なく続くようになりました。検索は Obsidian のリンクと Antigravity の grep が補ってくれるので、書く側は「将来の自分への置き手紙」くらいの気軽さで十分です。
ツールは何でもいいです。Obsidian でなくても、Notion でも、シンプルなテキストファイルでも。大切なのは「セッションをまたいで文脈を持ち続ける」仕組みを持つことだと思います。お読みいただきありがとうございました。