コンテキストスイッチングは作業の勢いを削ぎます。AIアシスタントがプロジェクトの途中で中断すると、次のセッションは「冷え切った」状態から始まります。リポジトリ構造の記憶もなければ、どのポートが稼働しているかの記憶もありません。昨日MoneroのRPCの調子が悪かったという認識すらありません。Daniel Ioniは、無骨ながらも有用なものを作り上げました。それは、AIシステムが手取り足取りの指示なしにMyZubster Gatewayの作業を再開できるよう、AI専用に書かれたテクニカルガイドです。これは、永続的な「合成メモリ（synthetic memory）」として機能します。生のソースコードを流し込む代わりに、システムの操作方法、障害のトラブルシューティング、そして破壊的な変更を加える前にオペレーターの権限を尊重する方法をマシンに教え込みます。
MyZubsterが実際に構築するもの
MyZubster Gatewayは、現実資産（RWA）のトークン化を中心とした分散型マーケットプレイスです。平易に言えば、物理的資産や伝統的な資産を、定義されたメタデータと所有権ルールに従ってオンチェーンで移動させるためのインフラストラクチャです。このプラットフォームは代替可能（fungible）な資産のトークン化を扱います。つまり、資産を分割、取引、追跡することができ、各ユニットには標準化されたメタデータが付与されます。
設計の中心にはプライバシーがあります。取引の決済はMoneroで行われます。プログラマブルな資産やNFTはTari上で動作します。全ての運用はTor Onion Serviceによって保護されており、ゲートウェイは検閲や地理的なブロックに対して耐性を持っています。セキュリティレイヤーはKali Linux上で動作し、DeepSeek AIセキュリティボットを使用しています。これは単なるログローテーションではなく、自動化された侵入検知やアノマリスキャンを想定しています。エスクローと紛争解決は、手動のバックオフィス業務ではありません。これらは自動化されており、取引条件によって紛争が発生した場合にはAIが仲裁を行います。
これらは表面的な部分に過ぎません。その裏側では、システムはRPCエンドポイント、ローカルデータベース、そしてNode.jsプロセスのネットワークで構成されており、これらが同期し続けなければマーケットプレイスの取引決済は停止します。
テクニカルスタックとその重要性
ゲートウェイはポート3002で待機しています。そこが入り口です。MoneroのウォレットRPCはlocalhost:18083にあり、ユーザーデータをパブリックチェーンのアナリティクスにさらすことなく、プライベートウォレットの操作、残高照会、送金処理を行います。TariのRPCはlocalhost:12820で応答し、プログラマブル資産レイヤーを管理します。これらのエンドポイントのいずれかが乖離したり停止したりすると、マーケットプレイスは停止します。
MongoDBは運用データストアとしてバックグラウンドで動作します。Node.jsはゲートウェイサービス自体を駆動します。フロントエンドのコードは、~/myzubster-frontendにある専用ディレクトリに格納されています。これは典型的な分散型スタックです。決済用のブロックチェーンノード、状態管理用のローカルデータベース、そしてインタラクション用の軽量なウェブレイヤーが、プライバシーツールによって包み込まれています。ここに装飾的な要素はありません。システムを自己完結させ、防御可能に保つために、すべてのポートとパスが選定されています。
システムの実行
ゲートウェイの起動は、単一のsystemdコマンドで行えます：systemctl start myzubster-gateway。無人の再起動後にサービスが静かに失敗するまでは、些細なことに思えるでしょう。その時は、ページングのノイズなしに直近50行のログを取得するために journalctl -u myzubster-gateway -n 50 --no-pager が必要になります。通常、その50行の中に答えがあります。MoneroのRPCが接続を拒否したのかもしれませんし、システムアップデート後にMongoDBがオンラインに戻らなかったのかもしれません。
セキュリティボットは /root/security_bot.py にあり、python3 /root/security_bot.py で起動します。セキュリティスクリプトをrootとして実行するのは、汎用サーバーでは行わないことです。モニタリングと自動応答に特化した、要塞化されたKali環境内であれば、それは運用モデルに適合します。DeepSeek AIの統合は、ボットが単にログをスキャンしているだけではないことを示唆しています。おそらく、侵害の兆候がないか、ネットワークの挙動や取引パターンを評価しているのでしょう。
フロントエンドの作業において、このガイドは推測の余地を完全に取り除きます。AIは正確な着地点を知っています：cd ~/myzubster-frontend。/var/www や /opt、あるいは散らばったホームディレクトリを探し回る必要はありません。このガイドはこれらのパスを正確に固定することで一貫性を強制します。これは、数週間にわたって複数のセッションや異なるAIインスタンスが同じサーバーに触れる場合に重要となります。
障害発生時
ゲートウェイがダウンした際、最初に行うべきはプロセスの偵察です。ps aux | grep node を実行して、Node.jsプロセスがまだ生きているか確認してください。もし消えていれば、ログを確認します。ログにデータベース接続エラーが表示されていれば、MongoDBが原因です。systemctl start mongod で起動してください。多くの分散型アプリケーションでは、ブロックチェーンノードを脆弱なコンポーネントとして扱いますが、実際には、不適切なシャットダウンや定期的なパッケージアップデートの後に最初に不安定になるのは、ローカルのMongoDBインスタンスであることが多いのです。
Monero RPCの問題は、異なるパターンを示します。残高の更新が止まったり、支払いトランザクションが保留（pending）状態で停止したりする場合は、ガイドに従って monero-wallet-rpc のステータスを確認してください。これは通常、ウォレットRPCプロセスが実行されているか、正しいデーモンに同期されているか、そして認証フラグがゲートウェイの期待値と一致しているかを確認することを意味します。ここでのトリアージは単純です。まずブロックチェーンの決済レイヤー、次にデータベース、最後にアプリケーションの順で確認します。この順序を無視すると、実際にはRPCポートが死んでいるだけなのに、Node.jsのログの中で実体のない原因を追い求めることになります。
AIによる本マニュアルの活用方法
このガイドはAIに対して4つの行動ルールを課しており、それらは本番環境において自動アシスタントがどのように失敗するかという理解に基づいています。
第一に、特定のセクションを参照すること。ユーザーが支払いの失敗をトラブルシューティングしている場合、AIはMonero RPCまたはエスクロー・サブシステムを明示的に挙げるべきです。そうすることで、ユーザーはどの部分に問題があるのかを正確に把握できます。第二に、正確なコマンドを提供すること。フラグを言い換えたり、パスを推測したりしないでください。第三に、論理的な次のステップを提案すること。プロジェクトの復旧は一連のシーケンスです。ポートの確認とセキュリティボットの間をランダムに行き来すると、時間を浪費するだけでなく、問題を悪化させるリスクがあります。第四に、サービスの再起動やデータの削除を行う前に、ユーザーの確認を求めること。自律性は、誤ってウォレットのキャッシュを消去したり、取引中にゲートウェイをダウンさせたりしない限りにおいて有用です。
生きたドキュメント
このガイドは、進化するように明確に設計されています。MyZubsterプロジェクトの成長に合わせて、AIがドキュメントを更新します。これにより、運用経験が組織知（institutional memory）となるフィードバックループが生まれます。小規模なチームや、タイムゾーンや睡眠サイクルが異なる中で運営される個人プロジェクトにおいて、これは通常シニアエンジニアの頭の中にしかない非公式な知識に取って代わるものです。ドキュメントは、あらゆる障害から学びます。
真の教訓
このようなAIプロジェクト復旧ガイドは、具体的で深刻な問題を解決します。それらは、生のドキュメントと文脈的な理解との間の溝を埋めるものです。MyZubsterにとって、それはマーケットプレイスがコンテキストの喪失、再起動、チームの交代に耐えられることを意味します。新しいセッションが始まるたびに、マシンがスタックを一から学び直す必要はありません。マシンに必要なのは、マニュアルを読み、正確なコマンドに従い、いつ立ち止まって質問すべきかを知ることだけです。
出典: AI Technical Guide: MyZubster Project Recovery Daniel Ioni 著
オプションの学習コミュニティ: GyaanSetu AI on Telegram