タグアーカイブ マイグレーション

ShopMagicで重複カラムエラーが出る原因とデータベース接頭辞の修正

ShopMagicで重複カラムエラーが出る原因とデータベース接頭辞の修正

ShopMagic 4.8.6以前のバージョンで、データベースアップグレード中に「カラムが重複しています(Duplicate column name ‘note_context’)」というエラーが発生する場合、原因はプラグイン内部のマイグレーションファイルでテーブル接頭辞が wp_ に固定されていることだ。バージョン4.8.7へのアップデートで修正されるが、すぐにアップデートできない場合は、データベースのオプション値を直接編集する緊急回避策でエラーを止められる。

なぜShopMagicで重複カラムエラーが発生するのか

なぜShopMagicで重複カラムエラーが発生するのか

ShopMagicには、プラグインが更新されるたびにデータベースのテーブル構造を自動調整する「マイグレーション」機能が備わっている。今回の問題は、マイグレーションファイル Version_42.php の17行目付近で発生する。このファイルは、note_context というカラムが既に存在するかどうかを確認するために SHOW COLUMNS クエリを実行するが、その際に対象テーブルを wp_shopmagic_automation_outcome_logs と決め打ちしてしまっている。

サイトのデータベース接頭辞(wp-config.php$table_prefix)がデフォルトの wp_ であれば問題は出ない。しかし、セキュリティや複数サイト運用の都合で接頭辞を abc123_ などに変更している場合、wp_shopmagic_automation_outcome_logs というテーブルは存在しないため、SHOW COLUMNS が失敗する。その結果、プラグインは「カラムが存在しない」と誤認し、note_context を追加しようとする。しかし実際には正しい接頭辞のテーブルに既に存在するため、ALTER TABLE が「カラムが重複しています」というエラーで失敗する。

さらに深刻なのは、このエラーによってマイグレーションチェーン全体が止まってしまう点だ。Version 42が失敗として記録されないため、後続のVersion 43から48のマイグレーションがいっさい実行されない。これにより、マーケティングリストやトラッキングメール関連のテーブルが不足し、気付かないうちに一部機能が不完全になる可能性がある。また、エラーはページが読み込まれるたびに繰り返し発生し、デバッグログを大量に汚染する。

カスタム接頭辞サイトでのエラー発生フロー
【Before】 SHOW COLUMNS FROM wp_shopmagic_… を実行
↓ テーブルが存在しないため失敗
【エラー】 プラグインが「カラム不在」と誤認し、ALTER TABLEで note_context を追加しようとする
↓ しかしカラムは既に存在する
【After】 修正後は $table_name を使って正しい接頭辞のテーブルを確認するため、エラーは発生しない
エラー発生時の流れ  修正後の動作

データベースエラーを解消するアップデート手順

根本的な解決策は、ShopMagicをバージョン4.8.7以降にアップデートすることだ。このバージョンでは、マイグレーションファイル内のハードコードされた wp_ が削除され、動的に正しいテーブル接頭辞を参照するように修正されている。

管理画面から自動アップデートする

WordPress管理画面の「プラグイン」→「インストール済みプラグイン」で、ShopMagicに利用可能なアップデートが表示されていれば、「今すぐ更新」をクリックする。アップデート後、データベースのアップグレードが正常に走り、エラー通知が消えていることを確認する。

手動でアップデートする

自動アップデートが利用できない場合は、公式リポジトリまたは有料版の提供元から最新のZIPファイルをダウンロードし、管理画面の「プラグイン」→「新規追加」→「プラグインのアップロード」から上書きインストールする。既存の設定やデータが失われることはないが、不安な場合は事前にサイト全体のバックアップを取得しておく。

アップデートできない場合の緊急回避策

アップデートできない場合の緊急回避策

何らかの理由ですぐにプラグインをアップデートできない場合、データベースのオプション値を直接書き換えることでエラーの無限ループを止められる。この方法は、マイグレーションVersion 42が「未完了」として記録されているために毎回実行される状態を、「完了」とマークするものだ。Version 42が実際に行うべきテーブル変更(カラム追加)はエラーを起こしながらも既に成功しているため、安全性は高い。

緊急回避の手順
STEP 1 必ずデータベース全体のバックアップを取る
STEP 2 phpMyAdminなどで wp_options テーブルを開く(接頭辞は環境に合わせる)
STEP 3 option_nameshopmagic_db の行を探し、編集する
STEP 4 option_valueWPDesk\ShopMagic\migrations\Version_42 に変更して保存する
注意: phpMyAdmin上ではバックスラッシュのエスケープ処理が自動で行われるため、入力時は WPDesk\ShopMagic\migrations\Version_42 とシングルバックスラッシュで入力する。保存後に LENGTH(option_value) が38(35ではない)であることを確認すれば、正しく保存されている。

変更を保存して管理画面を再度読み込むと、ShopMagicはVersion 42のマイグレーションが完了したと認識し、続けてVersion 43から48の未実行マイグレーションを順次処理する。これにより、不足していたテーブルが自動的に作成され、エラー通知も消える。なお、マイグレーション44では既存のオプトインメールデータを作成済みのマーケティングリストテーブルにコピーする処理が含まれるため、データ量によってはページの読み込みに時間がかかることがある。

よくある質問

エラーが解消された後、不足していたテーブルは自動的に作られるのか

アップデートまたはオプション値の書き換え後、ページを読み込んだタイミングで自動的に不足テーブルが作成される。Version 43から48のマイグレーションが順次実行され、マーケティングリストテーブルやトラッキングメールテーブルなどが生成される。特別な操作は不要だ。

データベース接頭辞をデフォルトのwp_に変更すれば直るのか

接頭辞の変更はサイト全体に影響を与える大掛かりな作業であり、推奨しない。テーブル名の一括置換やwp-config.phpの編集、シリアライズ化データの再計算などが必要になる。このエラーはプラグイン側の問題であり、ShopMagicをアップデートするだけで解決するため、そちらを優先する。

この問題はShopMagic以外のプラグインでも起きるのか

プラグインが内部でデータベース接頭辞をwp_に決め打ちしている場合、全く同じメカニズムでエラーが発生する。ただし、多くのプラグインはWordPressの$wpdb->prefixを用いて動的に接頭辞を取得するため、一般的な問題ではない。カスタム接頭辞を使用しているサイトで特定のプラグインだけがエラーを起こす場合、同様のハードコードが原因である可能性を疑うとよい。

phpMyAdminから直接オプション値を変更するのが不安だ

WP-CLIが利用できる環境であれば、wp option update shopmagic_db 'WPDesk\ShopMagic\migrations\Version_42' --format=plain というコマンドで安全に同じ変更が行える。phpMyAdminを使う場合でも、該当行の編集後すぐに管理画面を開き、エラー通知が消えたことを確認すれば問題ない。

この記事のポイント

  • エラーの直接原因は、マイグレーションファイル内でテーブル接頭辞が wp_ に固定されていること
  • カスタム接頭辞を使うサイトでは、毎回のページ読み込みでエラーが繰り返される
  • ShopMagicをバージョン4.8.7以降にアップデートすれば根本解決する
  • アップデートできない場合、shopmagic_db オプションを手動で進める緊急回避策がある
  • 回避策を取ったあと、後続のマイグレーションが自動実行され不足テーブルも作成される
Prisma Next早期アクセス開始、型安全DBコントラクトとエージェント連携

Prisma Next早期アクセス開始、型安全DBコントラクトとエージェント連携

Prisma Nextの早期アクセスが2026年5月22日に開始された。PostgresとMongoDBを対象に、データベース定義をコントラクトとして記述すれば、マイグレーションや型チェックをフレームワークが自動処理する。エージェントと連携する開発ワークフローにより、データ層の構築速度が大幅に向上する見込みだ。

開発者がコントラクトを書くと、あとはPrisma Nextがデータベースマイグレーション、クエリの型検査、エラー時の意味のあるメッセージを生成する。エージェントがコードを提案し、型検査を通過することで、安全なクエリが担保される仕組みだ。

1行のコマンドで始まるオンボーディング

1行のコマンドで始まるオンボーディング

新しいフレームワークを習得するには、ドキュメントを読み、小さなプロジェクトで試行錯誤を重ねる。慣れるまでに数週間を要することも多い。Prisma Nextはその学習曲線を1行のコマンドで解消する。npm create prisma@next を実行すれば、プロジェクトの骨組みと、エージェントを即座に専門家にする多数のスキルが自動生成される。

npm create prisma@next

ドキュメントを熟読する代わりに、エージェントがフレームワークの慣用句をリアルタイムに提示する。質問があればエージェントに尋ねればよく、コマンドの意味や設計の意図をその場で説明してくれる。まるで熟練者が隣で教えてくれているような体験だ。

従来のフレームワーク学習
STEP 1 ドキュメントを通読する
STEP 2 小さなサンプルを作成する
STEP 3 エラーを修正しつつ慣用句を覚える
Prisma Nextのオンボーディング
STEP 1 npm create prisma@next を実行
STEP 2 エージェントがプロジェクトとスキルを構築
STEP 3 質問があればエージェントに聞くだけ
従来は3週間かかっていた学習が、数分で開発を始められる状態になる。

既存プロジェクトへの導入

既存のプロジェクトに追加する場合もnpx prisma-next@latest initで簡単にセットアップできる。その後、エージェントに「読んでいる本を追跡する小さなアプリを構築して」と指示するだけで、スキーマ定義からクエリ作成までを自律的に進める。

コントラクトを書けばデータベース管理はフレームワーク任せ

コントラクトを書けばデータベース管理はフレームワーク任せ

Prisma Nextの中心にあるのが、アプリケーションとデータベースの間の契約であるコントラクトだ。開発者はモデルを定義するだけで、クエリの型検査や自動補完、そしてデータベースマイグレーションの計画と実行をフレームワークに委ねられる。

// contract.prisma
model Book {
  id       String   @id @default(uuid())
  title    String
  author   String
  addedAt  DateTime @default(now())
}
コントラクト(contract.prisma)
アプリケーション 依存関係 データベース 契約に従ってデータを保管
自動化されるタスク
クエリの型検査
自動補完
マイグレーション計画の生成
データベースとの整合性維持
開発者はコントラクトを編集するだけで、データベースとの一貫性が保たれる。

このコントラクトは可読性が高く、更新も容易だ。Prisma Nextではこれが唯一の真実の情報源となる。モデルを変更すると、フレームワークが自動的にマイグレーションを計画し、データベースが常にコントラクトを満たすように調整する。

エージェントによる機能追加の流れ

「著者テーブルを追加し、名前と経歴を持たせ、書籍と紐付けてほしい」といった自然言語での指示をエージェントに与えるだけで、コントラクトが更新される。エージェントは型検査を通過するまで内部でクエリの検証を繰り返し、最終的に安全なコードを出力する。

型安全クエリと高速な反復開発

型安全クエリと高速な反復開発

Prisma Nextのクエリはすべてコントラクトに対して型検査される。開発者(あるいはエージェント)がクエリを書くと、型エラーが即座にフィードバックされる。このループが高速なため、アプリケーションの出荷速度が格段に上がる。

const books = await db.orm.Book
  .where({ addedThisWeek: true })
  .all();

このクエリは、コントラクトで定義されたBookモデルに基づいて型が決定される。エージェントが生成したクエリも同じ型検査を通過するため、人間が書いたコードと同等の安全性が保証される。

クエリ作成の反復ループ
1 エージェントがクエリを書く
2 型検査による即時フィードバック
3 型検査を通過したクエリが確定
4 データベースが対応可能な安全なクエリ
エージェントはツール呼び出し内でこのループを自律的に繰り返す。

マイグレーションを記述する必要がなくなる

マイグレーションを記述する必要がなくなる

データベースのマイグレーションは、多くの開発者にとって最も苦痛を伴う作業の一つだ。構文を正しく記述し、エラーをデバッグし、本番環境で失敗した場合にはさらに時間を費やす。Prisma Nextでは、この負荷から完全に開放される。

マイグレーション作業の変化
従来の方法(Before)
SQLマイグレーションファイルを手動で記述
構文ミスやデプロイ時のトラブルシューティング
本番障害発生時に復旧作業
Prisma Nextの方法(After)
エージェントがコントラクトを編集
フレームワークがTypeScriptマイグレーションを自動生成
トランザクションで安全に適用(Postgres)
エージェントは意図を伝えるだけで、実際のマイグレーションコードは書かずに済む。

TypeScriptで書かれたマイグレーションファイル

生成されるマイグレーションファイルはTypeScriptで記述され、人間が確認しやすい形式だ。prisma-next migration plan を実行すると、ops.json とともにレビュー可能なマイグレーションが出力される。エージェントがSQLを生成するのではなく、フレームワークが決定論的に生成するため、信頼性が高い。

// migrations/app/20260515T0900_add_book_published_at/migration.ts
export default class M extends Migration {
  override describe() {
    return { from: "sha256:…prev", to: "sha256:…next" };
  }

  override get operations() {
    return [
      addColumn("public", "book", {
        name: "publishedAt",
        typeSql: "timestamptz",
        defaultSql: "",
        nullable: true,
      }),
    ];
  }
}

Postgresでは、マイグレーション全体が単一のトランザクション内で実行される。どこかで問題が発生してもロールバックされ、データベースは元の状態を保つ。MongoDBの場合は段階的に安全な手順で計画される。こうした保護機構によって、エージェントに安全に作業を委任できる。

並行ブランチでのマイグレーション競合を自動解決

並行ブランチでのマイグレーション競合を自動解決

複数ブランチで同時にマイグレーションを作成すると、マージ時に順序の衝突が起きることがある。Prisma NextはGitのコミットグラフのようにマイグレーション履歴を扱い、この問題を解消する。

ダイヤモンド型マイグレーショングラフの例
main
branch A のマイグレーション
branch B のマイグレーション
main(両方マージ後)
フレームワークはこの形状を理解し、正しい適用順序を自動的に判断する。prisma-next migration graph で可視化できる。

prisma-next-migration-review スキルをエージェントが活用することで、新しいマイグレーションがmainに到達した場合も、グラフを読み取り、ブランチをリベースし、migration planを再実行する。結果として、衝突なくクリーンにマージできる。複数のエージェントが並行して作業しても、特別な手順を覚える必要はない。

定期的なアップグレードとフィードバックの簡便さ

定期的なアップグレードとフィードバックの簡便さ

Prisma Nextは日々アップデートされており、アップグレードも簡単だ。エージェントに「prisma nextをアップグレードして」と指示するだけで、最新バージョンに更新してくれる。問題が見つかった場合も、エージェントに「これはバグだ」「この機能が欲しい」と伝えれば、適切な報告チャンネルを選び、構造化されたフィードバックを提出してくれる。

コミュニティでの成果発表も歓迎されている。Prismaの公式アカウントで紹介されたり、Prisma NextのREADMEにリンクが掲載される可能性もある。本格的にデプロイする場合、Prisma Postgresの無料枠を活用できる。なお、Prisma Nextはまだ本番環境向けではない。プロダクションには引き続きPrisma 7を推奨するが、一般提供時にはPrisma 8となる予定だ。

この記事のポイント

  • Prisma NextはPostgresとMongoDBに対応し、データベース定義をコントラクトとして扱う
  • 1行のコマンドでプロジェクトをセットアップし、エージェントが即座に開発を支援する
  • 型安全クエリにより、人間とエージェントのどちらが書いたコードも信頼できる
  • マイグレーションはフレームワークが自動生成し、トランザクションで安全に適用される
  • 並行ブランチでの競合もグラフベースの履歴管理で自動解決される