結論：レッドストーンとコマンドブロックは移行されますが、動作の一致は保証されません
レッドストーン回路やコマンドブロックを含むJava版ワールドを統合版 (Bedrock) に変換すると、ブロック自体はほとんど移せますが、実際に動かしたときの挙動がJava版と同じである保証はありません。原因は変換ツールではなく、両エディションのゲーム仕様がそもそも異なる点にあります。
- レッドストーンの時間挙動が違う。 Java版と統合版 (Bedrock) ではレッドストーンの更新順序や信号伝播のタイミングが異なり、正確な時間挙動に依存する回路（高速クロック、タイマー、フライングマシンなど）は容易に異なる結果になります。
- ピストンとオブザーバーの挙動に差がある。 ピストンの押し出し/引き戻しのタイミングやオブザーバーの発火方法は両エディションで完全には一致せず、無音ピストンドアや瞬間回路などはより動かなくなりやすいです。
- コマンドブロックの構文に互換性がない。 Java版と統合版ではコマンド構文、セレクター、一部のコマンドが一対一で対応せず、コマンドブロック内のロジックは統合版で動かすために書き換えが必要になることがあります。
そのため TopoBlocks はレッドストーンの100%等価を保証しません。これは仕様レベルの制約であり、手抜きではありません。両エディションの根本的な違いをまず理解したい場合は、Java版と統合版 (Bedrock) の違いをご覧ください。
変換が行うこと・行わないこと
変換は、レッドストーン回路、ピストン、オブザーバー、リピーター/コンパレーター、そしてコマンドブロック自体を可能な限り移行し、それらの位置と接続関係を保持します。一方で、回路の時間挙動を代わりに書き換えることはしませんし、Java版のコマンド構文を統合版で動く等価なコマンドに自動翻訳することもしません。これらの対応できない部分は項目別の変更レポートに記載し、どこが変更され、どこを手動で対応する必要があるかを明確に伝えます。黙って破棄したり、成功したように装ったりはしません。
支払い前には互換性スコアが表示されます。レッドストーン/コマンドの比重が大きいワールドでは、これを基に変換する価値があるか、変換後にどの程度やり直しが必要になりそうかを判断できます。変換は都度払いで、失敗時は自動返金され、価格はアプリ内の表示が正となります。さらに重要な点として、変換はソースファイルを決して上書きしません。元のJava版ワールドはハッシュとともに保持され追跡可能で、出力されるのは新しい統合版 (Bedrock) の .mcworld です。レッドストーンのやり直しが元のワールドに影響することもありません。「何が移行でき、何ができないか」の完全な一覧は、Java版から統合版へ、何が移行でき何ができないかをご覧ください。
変換後にレッドストーンとコマンドを調整する方法
- 項目別レポートと照合して確認する。 まずレポートで「変更」または「手動対応が必要」と記されたレッドストーン回路とコマンドブロックを確認し、把握してからゲームに入ります。
- 主要な回路を優先的に実機テストする。 統合版 (Bedrock) に入ったら、最も時間挙動に依存する部分（クロック、ピストンドア、自動農場）を先にテストします。これらが最も調整を要する可能性が高いです。
- 統合版のルールに合わせて微調整する。 レッドストーンの時間挙動の問題は、多くの場合リピーターの遅延を組み直すか回路構造を変更する必要があります。コマンドブロックは統合版の構文に合わせてセレクターやコマンドを書き換えます。
ワールドの内容が純粋なレッドストーンよりもデータパック/リソースパック中心の場合は、別の仕組みで処理方法も異なります。データパック/リソースパックを統合版にどう扱うかをご覧ください。Java版 → 統合版の流れ全体を体系的に理解したい場合は、詳細チュートリアルJava版から統合版へを参考にしてください。