手動で設定したくないですか？このページへのリンクを Devin セッションに貼り付けて、必要な設定をすべて行うよう依頼してください。あなたのチームは数週間にわたって `!db-migration` プレイブックを使っています。カラム名の変更やインデックスの追加は問題なく処理できましたが、他のテーブルから参照されているカラムを削除しようとしたところ、直近 2 回のセッションはマイグレーションの途中でクラッシュしました。各セッションを開いて、失敗したポイントを確認します。このケースでは、セッション 3 と 4 がどちらも同じステップでエラーになっています: ``` ERROR: 他のオブジェクトが依存しているため、カラム "account_id" を削除できません DETAIL: テーブル orders 上の制約 fk_orders_account_id はカラム account_id に依存しています HINT: 依存オブジェクトも削除するには、DROP ... CASCADE を使用してください。 ``` ここから明確な示唆が得られます: このプレイブックには、破壊的な操作の前に外部キー依存関係を確認するステップがありません。スタンドアロンのテーブルだけを操作した 2 つのセッションは成功し、そうではなかった 2 つのセッションは失敗しました。 [app.devin.ai](https://app.devin.ai/?utm_source=docs\&utm_medium=use-case-gallery) にアクセスし、入力ボックスの下にある **Advanced** をクリックします。**Improve Playbook** タブを選択します。プレイブックのドロップダウンから `!db-migration` を選び、**session multi-dropdown** から 4 つすべてのセッションを選択します — 成功したものと失敗したものの両方です。成功したセッションも含めることで、プレイブックがうまく機能している部分だけでなく、どこで破綻しているかも Devin が把握できます。 ```txt Improve the db-migration playbook theme={null} 私たちの !db-migration プレイブックは単純なテーブル変更では動作しますが、セッションが外部キー制約にぶつかると失敗します。セッション 1 と 2 はスタンドアロンテーブルで成功しましたが、セッション 3 と 4 は FK エラーでクラッシュしました。 4 つすべてを分析してください。成功したセッションが何を違って行ったか（外部キーの参照を受けていないスタンドアロンテーブルにのみヒットしていた点）を突き止めてください。そのうえで、プレイブックを次のように更新してください: 1. すべての DROP または ALTER の前に、information_schema をクエリして外部キー依存関係を調べる 2. 外部キーが存在する場合、ALTER TABLE ... DROP CONSTRAINT 文を生成して先に実行する 3. マイグレーションが途中で失敗した場合に削除した制約を再作成するロールバックステップを追加する ``` このプロンプトが効果的な理由は次のとおりです: * **具体的な失敗を特定している** — 「たまに失敗する」ではなく「外部キー制約」 * **成功と失敗を対比している** — Devin はセッションのトランスクリプトを比較し、どこで分岐したかを確認できる * **具体的な修正案を列挙している** 一方で、あなたが見落としている問題を Devin が挙げられる余地も残している Devin は 4 つすべてのセッションのトランスクリプトを読み、失敗が成功と分岐した箇所を特定し、ピンポイントな修正を提案します。出力はプレイブックのチェンジログのような見た目になります: ``` ## Analysis セッション 1-2 は、外部キー参照を受けていないテーブルだけを変更したため成功しました。セッション 3-4 は orders テーブルと invoices テーブルが対象カラムへの FK 参照を持っていたため、ステップ 4（"古いカラムを削除する"）で失敗しました。 ## Changes to !db-migration ステップ 3a を追加: "カラムを削除する DROP または ALTER の前に、 information_schema.key_column_usage をクエリして依存する外部キーを列挙する。もし存在する場合は ALTER TABLE ... DROP CONSTRAINT 文を生成して先に実行する。ロールバック用に元の制約の DDL を保存しておく。" ステップ 7 を追加: "ロールバック手順 — 外部キーの削除以降の任意のステップが失敗した場合、ステップ 3a で保存した DDL を使って削除した制約を再作成する。" Advice セクションを更新: "常にまずステージングデータベースに対してマイグレーションを実行してください。FK チェーンは想定よりも深い場合があります — テーブル A のカラムがテーブル B から参照され、さらにテーブル C から B が参照されている可能性があります。再帰的にクエリしてください。" ``` プレイブックは自動的に保存されます。何かおかしな点があれば、同じセッション内で返信します — たとえば「破壊的なマイグレーションを実行する前に #database Slack チャンネルに通知するステップも追加して」といった具合です。現在の Devin セッションから離れる必要はありません。プレイブックの更新が保存されたら、同じセッションを使って、以前失敗したのとまったく同じシナリオに対して更新済みプレイブックをテストする標準の Devin セッションを起動します: ```txt Test the updated playbook theme={null} 更新されたプレイブックをテストしてください。 !db-migration プレイブックを使って、users テーブルから legacy_account_id カラムを削除してください。このカラムは orders.account_id と invoices.billing_account_id から参照されています — プレイブックはこれら外部キーの依存関係を自動的に処理する必要があります。 ``` このセッションが成功すれば、修正は有効です。新たなエッジケース (たとえば循環する外部キー参照) に当たった場合は、そのセッションを Improve Playbook タブに再度入力して、もう一度改善サイクルを回してください。

{title}