GitHub Copilotがあなたのデータベース設計を台無しにしている
47個のテーブルがあるRailsのスキーマを眺めている。リレーションシップはスパゲッティのように絡み合っている。金曜日までに新機能が必要だ。あなたはスキーマをCopilotに貼り付け、マイグレーションを作成するよう依頼する。
AIは一見正しそうなコードを提示する。あなたはそれをリリースする。3週間後、循環参照が発生し、チェックアウトフローがクラッシュする。
これはCopilotの失敗ではない。「コンテキスト・コンポスティング（Context Composting）」だ。
あなたは、AIが一度のプロンプトで理解できるようなデータベースを設計している。アプリケーションの要件に合わせて設計しているのではない。
Qiitaのある日本人開発者が、チームによるAIの使い方の違いについて指摘していた。多くの欧米の開発者は、AIに与えるコンテキストを減らすことでトークンを節約しようとする。彼らは短いプロンプトや、ごく小さな断片を使用する。
一方、一部の日本のチームは、コンテキストをアーキテクチャ上の資産として扱っている。彼らはスキーマドキュメントをAIのための足場（スキャフォールディング）として利用する。モデルがビジネスルールや状態遷移を理解できるように、意図的にコメントを記述するのだ。
これが罠を生む。
あるスタートアップが「Copilotファースト」の設計思想を採用しているのを目にした。彼らはAIが簡単にスキャンできるように、リレーションシップを簡略化し、インデックスを追加していた。
その結果は悲惨なものだった：
- AIが複雑な関連性を扱えなかったため、テーブル数が30%増加した。
- クエリのパフォーマンスが低下した。
- 分析クエリが40%遅くなった。
彼らはAIの読みやすさを最適化し、システムのパフォーマンスを犠牲にしたのだ。
AIにアーキテクチャを支配させてはいけない。バランスを保つために、以下のステップに従ってほしい：
- 決定事項を2回記録する。AI用のバージョンと、人間に対して「なぜそうしたか」を説明するバージョンの2つを書く。
- 毎週、AIが作成したマイグレーションを1つ手動でレビューする。すべての外部キーとインデックスを追跡する。
- 「AIの限界（AI ceiling）」を把握する。AIが失敗する前に、1回のセッションでどれだけのテーブルについて論理的に検討できるかを記録しておく。
- 四半期ごとにスキーマ監査を行う。AIがなかったとしても、人間のアーキテクトがこのように設計するかどうかを自問する。
AIのために設計するという圧力は強まっていく。フレームワークも「AI最適化」されたパターンを提供し始めるだろう。
最良の開発者とは、AIに抵抗する者ではない。AIが自分を誤った方向へ導こうとしているときに、それに気づけるほどアーキテクチャ思考を鋭く保ち続ける者のことだ。
あなたのチームは、AIのコンテキストを中心にアーキテクチャを設計し始めていますか？それが本番環境に適用されたとき、どのような代償を払いましたか？
Optional learning community: https://t.me/GyaanSetuAi