お世話になっております
　返信が大幅に遅れ、誠に申し訳ありません

> 2系も4系も管理画面で商品登録を行う流れは同じで
> １．商品を新規登録
> ２．商品規格を編集
> の流れかと思います。
　はい

> 通常であれば、「１．商品を新規登録」が完了した時点で
> dtb_productとdtb_product_class(2系の場合、dtb_productsとdtb_products_class)に1件ずつレコードが登録されると思います。
　ええ

> この時、dtb_product_classテーブルにはclass_category_id1=null, class_category_id2=null(2系の場合、dtb_products_classテーブルにはclass_category_id1=0, class_category_id2=0)
> のレコードが登録されていると思います。
　はい、そしてこのレコードが「デフォルト商品規格」であり、また、
> ※規格を持たない商品もdtb_product_classテーブルにレコードを持つ仕様。
とのことで、特に規格に対して操作することが皆無だったとしても、このレコードは存在している、ということですよね？

> 続けて「２．商品規格を編集」が完了した時点で
> 規格の組み合わせとチェックボックスの内容を基に
> dtb_product_classテーブルへ必要なレコードを追加していると思います。
> (2系の場合、dtb_products_classテーブル)
　ええ

> ここで「１．商品を新規登録」で既に登録されているclass_category_id1=null, class_category_id2=nullのレコードに対して
> 4系の場合、visible=0に変更していると思います。
> ※今回の問題はここでエラーが発生する事
　はい、仰る通りです

> 規格を持たない商品用のレコードを非表示にする事が目的と思いますが
> 2系の場合、dtb_products_classテーブルのclass_category_id1=0, class_category_id2=0のレコードに対して
> del_flg=1の変更を行っているようです。
　こちらも、返信するまでの間、多分そうではないかと思うに至りました

> ここで少し気になったのですが
> 2系のサイトを構築する際、何度か移行作業を行っていたりしていないでしょうか？
　この度、返信が遅れたのは、この部分から気付きがあったからでした
　弊サイトは、一番初めは業者様にて構築をお願いしたのでした
　構築環境を用意して頂き、そこにこちらが商品登録をしていきました
　そして最終的に、その構築環境をまるごと、今の環境に入れ（直し）て頂いたのです
　大変お恥ずかしいのですが、このご返信を戴いて、こういった経緯を思い出すに至ります（本当に申し訳ありません）

　その業者様が、例えばこちらに提供して下さった構築環境以前に、例えば（業者様側の）ローカルでテンプレートを含め構築されていらっしゃったとしても、最終的にはこちらが商品登録をしていくので、こちらに提供して頂いた環境こそが、
　　商品データが入っている一番の先祖（オリジナル）
だと考えます

　幸い、その構築環境のデータベースはまだ生きており、
　　SELECT `product_class_id` FROM `dtb_products_class` WHERE `classcategory_id1`=0 AND `classcategory_id2`=0 AND product_id = XXX
で色々見ましたが、このオリジナルの時点で、既にこのレコードは「あったりなかったり」の状態でした

> あくまで予想ですがデータ移行の際、del_flg=1のレコードは不要と判断して破棄していたりすると
> レコードの欠落は発生してしまうかと思います。
> もしくはサイト構築時のデータ投入時に規格商品のclass_category_id1=0, class_category_id2=0のレコードを追加しなかったのかもしれませんが。
　最初は、バージョン違いですが、
　　複製した商品で、「規格の初期化」ができない · Issue #1383 · EC-CUBE/ec-cube · GitHub
　　https://github.com/EC-CUBE/ec-cube/issues/1383
といったことも含め、イレギュラーなことが起きたのかなと思いつつも、そういったバグ的なものがなければ、【なるべきしてなった】と思います
　そこで考えたのは、ご指摘の様に、業者様が本番環境に移行させる際に、文字通り「del_flg=1」、つまり削除フラグが 1 なので、当該レコードを破棄されたのかも知れません

　こちらの事情となってしまいますが、この業者様とは今は交流がない為、確認のしようがありません
　また、仮に聞けたとしてデフォルト規格のレコードを業者様が削除されたとしても、元のデータが戻って来る訳でもありません
　犯人探しをしたいのではなく、兎に角この状況を何とかしたいというのが目的なので、オリジナルがこの状態だともうデータは取り戻せないと結論するに至りました

　そこで、もしもに備え、EC-CUBE 4 の環境を更に別に用意し、既存の商品を全て【廃止】し、商品をゼロから登録することと致しました

　この返信までの間、経緯を思い出し、色々調べ、オリジナルデータから結論を出し、別環境構築後、約 150 の商品データを登録するところまで来ました
　ご返信の通り、規格の分類数が多い程、組み合わせは膨大になります
　オリジナルデータにデフォルト規格のレコード欠落がなければまだしも、数百もある商品のデータからテーブルを逐一見るよりはゼロから再登録した方が賢明と判断したのです

　ですが「再登録することにしました」で終わってはまだ納得がゆかず、ある程度の数の登録をこなして、改めて確認しようと決めていました

　既述の通りですが、150 余の登録を済ませた現状で、任意にどの商品を引っ張っても「デフォルト規格のレコード」は存在し、管理画面上でも「商品規格登録をするとエラーが出る」ことがありません

　結果論で言えば、デフォルト規格のレコードが欠落した確実な理由や、それを復元する方法を導き出せず、最初から登録し直すという意味では「仕方なくこうした」感が強く、しかも多くの時間が掛かってしまいました
　ですが EC-CUBE の内部ロジックをより理解することが出来ましたし、何よりも「運営に於ける教訓」を得ることが出来ました
　多くの時間苦労した分、こういったことを忘れることはないと思います

　また、素人故に多くの技術資料に触れることが出来、株式会社シロハチ様のサイトも沢山拝見しました
　ここまでに至れたのは、株式会社シロハチ様のご返信によるお導きがあったに他なりません

　こういう形での解決となりましたこと、報告申し上げます
　返信が遅れてしまったことの非礼をお詫びし、心より御礼申し上げます

　末筆ではありますが、株式会社シロハチ様の今後益々のご発展とご活躍を心よりお祈り申し上げます