新規機能の開発時、ビジネス側やクライアントから共有されるExcelのマスタデータ。画面表示に必要な情報は揃っているものの、「これをFirestore（NoSQL）で扱うには、データベース設計的にちょっと厳しいな……」と頭を抱えた経験はありませんか？
今回、Codex（AI）にプロジェクト固有のFirestore設計ルール（SKILL.md）を読み込ませてデータ成形をお願いしたところ、人間が気づかなかった運用上の考慮（ステータス管理や並び順フラグなど）を先回りして提案され、めちゃくちゃ感動しました。
その時のプロンプトや、なぜAIがそんな神提案をしてくれたのか、裏側の仕組みをブログとしてまとめます。
1. 投げたプロンプトは、ほぼ1行
クライアントから届いたExcelデータをどう成形すべきか迷ったため、私はCodexに対し、以下のようにプロジェクト固有のFirestore専用スキル（SKILL.md）のパスを添えて、シンプルに指示を出しました。
クライアントからマスタデータをもらいました。
firestoreで使えるようにするためidなど不足している列があるはずです。
どのように作ればいいか教えてください。
[$firebase-firestore]
この、ほぼ1行の指示に対して、CodexはExcelのデータ構造を読み解いた上で、「status カラム（公開/準備中/非表示）を追加しましょう」「表示制御用に is_active（有効/無効フラグ）を定義しましょう」 と、私がまだ考えてもみなかった運用フェーズを見据えたカラムの追加を次々と提案してくれたのです。
2. なぜAIは「先回りの神提案」ができたのか？
AIに普通に「Firestoreのデータ構造を考えて」と頼むと、インターネット上にある一般的なNoSQLの知識で広く浅い回答しか返ってきません。
しかし、今回Codexが「超優秀なFirestore専門のバックエンドエンジニア」として動いてくれた背景には、「スキル（SKILL.md）」という仕組みがありました。
① SKILL.md とは何か？
これは、AIに「特定の役割やプロジェクト固有の専門知識」を学習させるための設定ファイル・プロンプト指示書です。
プロジェクトごとに「IDはこういう命名規則にする」「ネスト（階層化）は3階層まで」「ドキュメントの肥大化を防ぐために参照（Ref）を使う」「1ドキュメントの上限1MBを意識する」といったローカルルール（前提条件）や制約があるはずです。それをまとめた“秘伝の書”が SKILL.md です。
② 「firebase-firestore スキル」が有効化したAIの脳内
このスキルファイルを指定して指示を出したとき、AIの頭の中は以下のような人格に切り替わっています。
🧠 AIの思考イメージ: 「よし、いま私は『
firebase-firestoreスキル』が有効化されたぞ。手元にあるSKILL.mdを読んだから、このプロジェクトにおけるFirestore設計の正解ルート（データモデル前提）が分かった。この独自ルールとFirestoreの制約に違反しないように、Excelデータをどう変換すべきか逆算して考えよう」
ネットの一般論ではなく、「このプロジェクト専用のコンテキスト」を完璧にインストールした状態でExcelを見てくれたからこそ、あの提案が生まれたわけです。
3. 具体的にどういう「Firestoreの前提」に沿ってくれたのか？
実際にCodexが提案してきた内容を振り返ると、まさにFirestore特有の性質やベストプラクティスを網羅したものでした。
🔑 名前依存から「システム用英語ID」への脱却
クライアントのデータは、往々にして「日本語の名称」だけでデータが繋がっています。しかし、それをそのままFirestoreのドキュメントIDに使うと、URLエンコードで文字化けしたり、後からクライアントが「日本語の名称をやっぱり変えたい」と言い出した瞬間にリレーションが全て崩壊します。
- AIの提案: 日本語表記とは完全に切り離した、システム管理用のユニークな英語ID（例:
group_alpha,layer_01）をマスタに定義することを提案。これにより運用の変更に強い構造になりました。
🔄 1行＝1リソースの「リレーショナルな形」への変形
当初のExcelは1階層に1行のデータ構造でしたが、将来的に「1つの階層に複数のアセットを紐づけたい」という要件が発生するのを見越し、1行＝1リソースとして扱える形への変更を提案されました。
- AIの提案: Firestoreで「サブコレクション」にするか「配列（Array）」にするかを制御しやすくし、データの重複を避けるための先回り設計。
🚦 クエリを最適化する「status カラム」の追加（一番感動したポイント）
Firestoreは、RDB（リレーショナルデータベース）に比べて複雑な条件のクエリ（検索）があまり得意ではありません。
- AIの提案: 画面側で
where("status", "==", "published")のように、超軽量かつシンプルなクエリ一発で画面制御ができるよう、マスタ側に最初からpublished/coming_soon/hiddenといった状態フラグ（statusやis_active）を持たせることを提案。
4. まとめ：AIに「文脈（ルール）」を渡す価値
今回の体験で強く感じたのは、「AIに適切なコンテキスト（設計ルールや制約）を最初に渡しておけば、人間がウンウン唸って設計するよりも遥かに打率高く、美しいデータモデルを先回りして作ってくれる」ということです。
「一般的な情報で適当に型を合わせました」ではなく、指定した SKILL.md を100%読み込んで、仕様を満たすようにExcelデータを綺麗に整えてくれたCodexの賢さには本当に感動しました。
NoSQLへの移行やマスタデータの構造化で悩んでいる方は、ぜひプロジェクトの共通認識をドキュメント（SKILL.md）化し、AIに「専門スキル」としてインプットした上で協働してみてください。開発のスピードと質が爆上がりすること間違いなしです！