見出し画像

MHXXの護石スナイプ手法の考察と待ち時間短縮手法の提案

(2026/03/13追記:本文は追記の後にある)
護石スナイプおよび提案した手法については,筆者自身も最初に仕組みを理解した際には脱力を伴う複雑な気持ちを覚え,自分にとってはゲーム体験が損なわれると感じた.一方で,護石スナイプが可能という情報が公開された以上その状況を元に戻すことはできず,その後は本作を純粋にアクションゲームとして楽しもうという気持ちの整理を行った.筆者自身も,長年地道に行っていた作業が別の方法によって大きく効率化される経験をこれまでに何度もしており,護石スナイプやこのノートに記載の内容に対して複雑な感情を抱く人がいることも理解している.

本ノートは攻略情報の提示ではなく,仕組みと手法についての技術的な整理および報告を目的としている.手順だけ端的にわかりやすく書いていないのは,そういった理由である.むしろ,あえて読みにくくしている.文章を正しく理解でき,自己で責任を取れる人のみが実行可能であるべきであると判断したためだ.また,このため記事タイトルも修正をすることとした.

本ノートでは,人力での実行を含めた大まかなスナイプの概要と,マイコンを用いる大まかな手順.およびその検証結果をもとに,人力でも再現可能な手順について併せて提案している.人力での手法は,価値基準の違いや技術的に導入が困難である場合に,障壁を下げる意図で記載している.加えて,人力で可能な方が望ましいという考えがある.なお,Nintendo Switch 利用規約を再確認した結果,マイコンの具体的な使用手順の掲載は適切ではないと判断し,実装コードは削除した.

本ノートで示した手法(スナイプ,マイコンの使用)を実行するかどうかは,各人の価値観や遊び方に委ねられるものと考えている.まず,公式に推奨される遊び方ではない.法律の観点では,本記事で扱うマイコンなどの使用が直ちに違法と評価されるとは一般には考えにくいが,利用方法や状況によって評価が変わる可能性はある.また,Nintendo Switchの利用規約では,任天堂が許諾していない周辺機器の使用や想定されていない利用方法が禁止されており,マイコンなどの外部入力装置は解釈によっては規約違反とみなされる可能性がある.またゲームコミュニティにおいては,このようなスナイプや自動入力の扱いについては立場が分かれるところだが,一般には好ましくない行為とされる.本ノートの主目的は,このような手法の是非そのものを論じることではなく,乱数調整の手法とその改善について技術的観点から整理することにある.

なお,実世界(自然科学)を対象とする研究とゲームを対象とする研究では,倫理的配慮の前提が大きく異なる.実社会では一般に成果が重視される一方で,ゲームを含む趣味や娯楽の領域では努力や過程そのものに価値が置かれることが多い.初稿の段階では,こうした点への認識と配慮が十分でなかったことをお詫びする.

記事の削除も考えたが,記事を削除すると議論の経緯や文脈が失われ,断片的な情報だけが拡散する可能性がある.そのため,必要な修正や補足を加えた上で公開を維持する方が適切と判断した.

(2026/03/13 追記2)
apmnnn氏より,本記事に関する技術的な情報提供(本記事コメント参照)があり,記事内の情報の修正を一部行った.特に,continue連打法に関して,人力での実行を目標として研究を進め,頂いた情報と筆者自身による追加実験をまとめた補足を書いた.


2026年3月初頭にMHXXにおいて護石のスナイプ手法が確立された (情報が一般に公開された).護石(お守り)のスナイプとは,消費乱数の調整(乱数調整)によって,マカ錬金で出る護石を調整する手法である.これは,護石のパラメータの決定が疑似乱数 (乱数生成器はXorshift法) に基づいており,かつ乱数の初期seed値がソフトによらず固定であることから実現可能となっている.乱数の消費は,1フレームごとに1消費される(他にも消費要因がある)ので,手動でもゲーム起動からマカ錬金投入までの時間を調整することで原理上は可能である.しかし,1フレーム単位での操作精度を要求され,試行回数を増やせば解決できるが,手動では容易ではない.ただ,できないわけではなく,乱数消費量が小さい場合に限り,手動での成功者も多数存在する.あくまで手動は安定しないということである.

本ノートでは,スナイプを安定させるために,本ノートでは,マイコン(Arduino Leonardo)を用いた Nintendo Switch 上での MHXX の入力制御の考え方について紹介する.マイコン制御の説明の前に,スナイプを行う上で手動とマイコン使用で共通する問題や手順について説明をしておく.また,マイコンを用いた実験結果によって得られた待ち時間短縮の手法を紹介する (continue連打法).もちろん,手動で成功させる方がNintendo Switchの規約上望ましいのは確かである.本ノートで紹介するマイコンの使用法は,理想的な入力制御を行う方法の一例として示すものである.

誤解されやすい点を先に述べておく.マイコンを用いてボタン入力のタイミングを精密に制御しても,結果が完全に決定されるわけではなく,最終的には一定の不確定要素が残る.不確定要素はマイコンの制御,ゲームのハード的な要因(熱など),ソフトウェアの実装の3つの要因に分けられ,ソフトの面では必ずしも確率的挙動を取るわけではないようだ.

次に,任意の護石を(それこそセーブデータの改造のように)得られるわけではない.スナイプが実現可能な時間(消費乱数,フレーム数)の範囲にある護石が得られるのみである.このため,ブラキ炭鉱をして抽選回数を増やすことで,目当ての護石を得る確率を上げる手法が現時点で無意味になるわけではない.また,筆者はその遊び方を否定しない.

なお,自分自身はゲーム自体のバイナリ解析などは行っておらず,他の人によって公開された情報(これが実際にバイナリ解析から得た情報のかも同様に不明)から推定しているだけであるので,内容の誤りがある可能性が高いことは注意してほしい.基本的には以下の記述を参照した.

筆者自身はどのゲーム内コミュニティにも属さず,参考にした記事やリポジトリを作成された方々との個人的繋がりはないことを明記しておく.


護石スナイプの是非について

初めに護石スナイプに対する筆者の考えを述べておく.この記事を書いている以上,筆者はスナイプ許容側であるが,否定派の考えも理解できる.このため,スナイプが世に出てしまったことの是非について議論する.本題は次の節からであるが,できればこの節を一読いただき,筆者の議論を踏まえたうえで各人で是非を判断していただきたい.

乱数調整と改造の違い

まず,護石スナイプ(乱数調整)を改造と類似するものとして扱う人も多くいるが,両者は決定的に異なる.一番の違いは,内部データの書き換えがないため,セーブデータを破損させる心配がないということである.ここでの「セーブデータ」は自分のものだけでなく,オンライン通信した際に共に遊ぶプレイヤーのものも含む.もちろん,セーブデータの書き換えは刑事罰に問われうるため,違法性という観点でも大きく異なる.また,MHというゲームは対人戦 (PvP) ではなく,モンスターに対するPvEである.このため,これらからスナイプで得られた良い護石を使用しても他のプレイヤーに一切悪影響が無い.もちろん,心理的悪影響の存在はあるだろう.TAなどでは同一の装備を使用できるようになれば,純粋な腕前で競争ができるようになる.それが健全なのかどうかも各人の価値観による.

なお,護石や発掘武器などの乱数調整(スナイプ)はMH3GやMH4 (G) などにも存在した.乱数調整と改造の比較や同一視などに関しては,MH以外では有名なところでポケモンなどでも長い論争の歴史があるので,それらも調べて総合的に判断を行ってほしい.ポケモンに関してはPvPなので,乱数調整が容易であった4, 5世代では特に問題となった.総合して,筆者としては,乱数調整と改造は上述の理由などから明確に異なると考えている.とはいえ,乱数調整が推奨される行為であるとは言えない.

ゲームに関する解析の是非

次に,ゲームを解析することの是非についてである.まず,カプコンの利用規約は以下である.

本プログラムの使用にあたり、お客様は、以下の行為を行ってはなりません。

①本プログラムの全部または一部の複製(但し、本プログラムのインストールのために必要な複製は除きます。)、改変、改造、翻訳、解析、リバースエンジニアリング、コードの抽出等、カプコンの知的財産権を侵害するおそれのある行為。

https://game.capcom.com/eula/jpn.html

ゲームのプログラム自体を解析するバイナリ解析は明確に禁止されている.また,解析,リバースエンジニアリングの定義は曖昧であり,ゲーム内での情報のみからの推定を許容するのかは解釈に依存する.護石スナイプに関して公開された情報が,実際どのように得られたかは不明であるとしか言えない.フレーム数に対する護石を計算するコードを書かれたapmnnn氏は次のように記載している.

このプログラムは完全にゲームの動作を解析して作っている訳ではないので、再現不足により実際のゲームの結果とは異なる結果が表示されるかもしれません。

https://github.com/apmnnn/mhxx-rng

どこまでこの記載を信用するかによるが,ゲームの内部プログラム自体を解析していない可能性もあるだろう.ブラックボックスとして扱う場合,初期乱数が共通であり,マイコンなどで同一の動作を行えばほぼ決定論的に護石が決まったことが解析を容易にしたと考えられる.これにより,地道な実験と研究済みの過去のMHでの護石排出のアルゴリズムに類似する手法から推定されたとも考えられる.何にせよ本作は発売から9年が経とうとしており,解析にかけられる時間も多分にあっただろう.また,乱数生成器にXorshift法が用いられていた.高速な疑似乱数生成器だが,状態遷移がXORとビットシフトのみからなる線形変換であり,出力から内部状態を復元できることも解析できた要因だろう.もちろん,出力から護石に変換するまでの過程は非線形変換であるので推定は容易ではないが,第1スキルを足掛かりにすれば推定は可能なのではないかと考えられる.第1スキルの同定法は以下のようだ.

①乱数を一つ進める。

乱数を第1スキルとなりうるスキルの個数で割った余りを◯とする。第1スキルとなりうるスキルの内、ID順に並べた時に前から◯+1番目のものを第1スキルに決定する。

https://github.com/apmnnn/mhxx-rng/blob/main/docs/charm_generation.md

第1スキルの個数はゲーム内の情報のみから数えることが可能であり,スキルのID順は装備屋で売られている装飾品の並びがほぼ同一であることから,1つ目の計算法は比較的容易に分かる.剰余の列のみから探索することは十分に可能な範囲だろう.また,単一の護石の情報は連続する複数の乱数に基づいていることから,時間の制御が無くても分かることは多い.とはいえ,容易ではないことは確かであり,実際にどうやって知ることができた,あるいは導き出したのかは不明である.また,護石の初期乱数が時間やキャラ,ゲームハードなどに依らないように実装したのは,MH3Gでのお守りテーブルバグによるユーザー間の不公平があったからなのではないかと考えている.いずれにせよ,決定論的に護石が決まることはゲームのバグではなく仕様である.

改造プレイヤーの判別などについて

最後に,ゲームデータ自体の改造プレイヤーとの区別が付きにくいという懸念点だが,これは同意する.改造を行ったプレイヤーあるいは改造クエストに参加したプレイヤーとオンラインプレイしないようにするのは,自己のデータを保護するために必須である.しかし,旧来から運によってよい護石を入手したが改造と間違われたという事例もあった.結局のところ護石だけではなく,ハンター名,チャットの発言,挙動(通常ではありえない動きや,ゲームの進行が正常でないなど),護石以外の装備(例えばHR解放前でGXミラルーツ装備など), HRに見合わないプレイ時間(ギルドカードを見るか,「プレイ記録の公開」を非公開にしていないユーザーならSwitchのホーム画面から確認可能)などの情報を合わせて判断し,疑わしければ罰するの精神でキックおよびブロックして対処を行うことを勧める.あるいは信用できるユーザーとのみプレイを行うことを勧める.


フレーム数と護石の対応

フレーム数について

ここから本題に入ることとする.この記事で指すフレーム数とは,実際は消費すべき乱数値の数である.1フレーム (MHXXは30 fpsなので1/30 s ≈ 33 ms) に1つ消費するので便宜上フレーム数と呼んでいるが,ロードなど他の要因でも消費される (後述).このため,フレーム数がそのままゲーム選択から護石投入までの時間と等しくなるわけではない.

機種やゲームの保存場所(パッケージ版かダウンロード版か)によって使用されている初期乱数値は変化しないため,任意の環境で護石のスナイプは可能である.ただし,ロード時間が異なり,小さいフレーム数の護石 (1716 framesの斬味5 痛撃4 S3など) は最速でも間に合わない可能性があり,また進行するフレーム数の安定性から,基本的にはSwitch2 + ダウンロード版を推奨する.

スナイプの一番の難点は,ゲーム開始におけるロード時 (Continueおよびセーブデータ選択における) の乱数消費量が一定ではないという点である (ただし,乱数消費は決定論的操作である.詳細は本ノートにおける「Continueによる固定点 (合流地滞) への数値的吸引」を参照).また,マイコンとゲーム機の双方が毎回完全に同一の動作をするわけではない.よって,複数回施行したフレーム数の最頻値で,指定した待ち時間を評価するべきである.

フレーム数と護石の対応の解析

筆者はapmnnn氏によって https://github.com/apmnnn/mhxx-rng  で公開されているコード(関数)を利用してフレーム数と護石の対応についての解析を行っている.

(2026/03/15 追記)
apmnnn氏のコードを元に,一般向けに使用しやすいツールを作成された方もいるようだ.2026/03/15時点ではapmnnn氏の実装された全ての関数の機能を使用することはできないので,プログラミングに慣れている人はapmnnn氏のコードをそのまま利用することをお薦めする.

apmnnn氏によって実装されたコードに話を戻す.コード (mhxx-rng.ipynb) はPython 3.xで書かれており,ライブラリとしてはNumPy, Numbaが必要.誰でも利用可能なようにGoogle Colabで使用できるようにコードが記述されている.Google ColabはGoogleのサーバー上でコードを実行できるサービスであり,自分のパソコンにPython環境を入れる必要がない.しかし,取り回しが不便なので,筆者はlocalのPython環境でコードを実行している.Pythonに関しては機械学習で主に使用されている言語であることからインターネット上での文書が充実しており(そのためLLM内の知識も豊富),本体およびライブラリのインストールに関してはここでは紹介しない.

再実行が多いので,筆者はJupyter note (.ipynbファイル) をJupyter Labから使用している.最初に実行すべきコード (mhxx-rng.ipynb の2-4セル目) を全てutils.pyという名称のファイルに入れ,以下のようにして変数を読み込んでいる.面倒なので特段コードの追記はしていない.

%run utils.py

1セル目の使用法に関しては,https://github.com/apmnnn/mhxx-rngを参照してほしい.Pythonが少しは分かっていないと難しいかもしれない.また,見落としやすいが,護石の名称は,以下の略記を使用されている.

'毒 ','麻痺','睡眠','気絶','聴覚','風圧','耐震','だる','耐暑','耐寒',
'寒冷','炎熱','盗み','対防','狂撃','細菌','裂傷','攻撃','防御','体力',
'火耐','水耐','雷耐','氷耐','龍耐','属耐','火攻','水攻','雷攻','氷攻',
'龍攻','属攻','特攻','研師','匠 ','斬味','剣術','研磨','鈍器','抜会',
'抜減','納刀','納研','刃鱗','装速','反動','精密','通強','貫強','散強',
'重強','通追','貫追','散追','榴追','拡追','毒追','麻追','睡追','強追',
'属追','接追','減追','爆追','速射','射法','装数','変則','弾節','達人',
'痛撃','連撃','特会','属会','会心','裏会','溜短','スタ','体術','気力',
'走行','回性','回距','泡沫','ガ性','ガ強','KO','減攻','笛 ','砲術',
'重撃','爆弾','本気','闘魂','無傷','チャ','龍気','底力','逆境','逆上',

'窮地','根性','気配','采配','号令','乗り','跳躍','無心','我慢','SP',
'千里','観察','狩人','運搬','加護','英雄','回量','回速','効果','広域',
'腹減','食い','食事','節食','肉食','茸食','野草','調成','調数','高速',
'採取','ハチ','護石','気ま','運気','剥取','捕獲','ベル','ココ','ポッ',
'ユク','龍識','飛行','紅兜','大雪','矛砕','岩穿','紫毒','宝纏','白疾',
'隻眼','黒炎','金雷','荒鉤','燼滅','朧隠','鎧裂','天眼','青電','銀嶺',
'鏖魔','真紅','真大','真矛','真岩','真紫','真宝','真白','真隻','真黒',
'真金','真荒','真燼','真朧','真鎧','真天','真青','真銀','真鏖','北辰',
'斬術','食欲','職工','剛腕','祈願','裏稼','刀匠','射手','状態','怒 ',
'回術','居合','頑強','剛撃','盾持','潔癖','増幅','護収','強欲','対鋼',

'対霞','対炎','胴倍','秘術','護強'

なお,2026/03/14時点では2個目のスキルが空白の場合にフレーム数を調べる機能が(関数の中身を確認したところ)ない.コードを追加で書くことも面倒なので2番目以降の2つスキルがある護石を調べてそのフレーム周辺の護石を確認することで1番目の護石のフレームを確認している.より確実に同定する場合は,jujupush関数などを用いて風化したお守りと古びたお守りの全てを確認する.他にもapmnnn氏は有用な関数を作成されているので,慣れたら関数の一覧 (https://github.com/apmnnn/mhxx-rng/blob/main/docs/functions.md) を眺めるとよいだろう.

護石の並び順による出やすさの違い

1番目と2番目の風化したお守り由来の護石は1番目の護石のスキル数が1つである場合は4フレーム,2つである場合は6フレーム離れている.これは,内部のアルゴリズム的にそうなっているようだ (以下の引用において,6と7で1つずれているが内部処理の影響であると思われる).

第2スキルの付与の有無によって、乱数の進行量は4か7かで違ってきます。

https://github.com/apmnnn/mhxx-rng/blob/main/docs/analysis.md

この事実は,護石を探す場合に必要となることも多いが,それよりも重要なのは護石の出やすさに影響するという点である.1回の護石投入時に,1番目と2番目の両方で出る護石と,1番目でしか出ない護石(孤立お守り)がある.標的護石のフレーム数を基準の0 (カッコ内は基準からのフレーム数の差)とすると,護石には出やすさに関して次の3パターンが存在する.

3か所のフレームから狙える場合
スキル2個 (-6), スキル1個 (-4), 標的護石 (0) という並び
例:貫強3 会心5 S3 (7934 frames)
  -6 鈍器 2 雷攻 13 S0 ⇐ 当たり
  -4 風圧 8 ◯◯---- S0 ⇐ 当たり
  0 貫強 3 会心 5 S3    ⇐ 当たり

2か所のフレームから狙える場合
スキル2個 (-6), スキル2個 (-4), 標的護石 (0)
あるいは
スキル1個 (-6), スキル1個 (-4), 標的護石 (0) という並び.
例:痛撃6 達人10 S3 (296260 frames)
  -6 通強 4 爆弾 8 S0 ⇐ 当たり
  -4 窮地 6 笛  8 S0
  0 痛撃 6 達人 10 S3 ⇐ 当たり
例2: 痛撃6 斬味7 S3 (7016153 frames)
  -6 重強 6 ◯◯---- S3
  -4 納研 5 ◯◯---- S1 ⇐ 当たり
  0 痛撃 6 斬味 7 S3    ⇐ 当たり

1か所のフレームから狙える場合 (孤立お守り)
スキル1個 (-6), スキル2個 (-4), 標的護石 (0) という並び.
例:連撃5 達人10 S3 (15069320 frames)
  -6 底力 3 ◯◯---- S1
  -4 狂撃 3 重撃 4 S0
  0 連撃 5 達人 10 S3 ⇐ 当たり

当然であるが,1か所のフレームからしか狙えない場合が最も困難である.連撃5 達人10 S3の入手が難しいのは,単にフレーム数が遠いだけでなく,孤立お守りである点も理由として挙げられる.護石を狙う場合には,こうした点も考慮し,狙いやすいフレームを優先すると良いだろう.


待ち時間調整でスナイプする場合の手順と考察

ここでは,待ち時間調整のみでスナイプを行う場合の手順を紹介する.長い待ち時間の護石を狙う場合,後述する「continue連打法」を確認してほしい.また,待ち時間のみで調整を行う場合も,continueによってどのような乱数値消費の挙動が生じるかは理解しておいた方がよいので,本ノートに記載の「Continueによる固定点 (合流地滞) への数値的吸引」は一読いただきたい.

セーブデータの事前準備

  • ココット村でセーブしてゲームを終了しておく.

  • マカフシギ錬金術用の女王 (レア5), 王 (レア6), 龍 (レア7) の護石を,投入する数に合わせて3~30個用意.必要でないものを先頭にすること.十分に女王, 王の護石があれば問題ない.

  • そのまま,ケルビマラソンをする場合は持ち物にケルビの角を3~30個入れておく.

  • 必須ではないが,Switch本体の計算量を下げるため,オトモは連れない方がよいだろう.未確認だが,余計な乱数値が消費される可能性もある.

  • 装備に関しても任意で問題ないだろうが,計算量を下げるために裸 + 範馬刃牙双剣がよい可能性もある.

  • 「本日の調査対象」などを決定するために乱数が消費される可能性もあるので,一度ゲームを開始して決定づけた後の方が良いかもしれない.同様に,検証していないが,5時・17時をなるべく跨がないようにした方が良いかもしれない.

Switch本体の事前準備

  • 不用意な通信を避けるため,機内モードに設定する.

  • 長時間待つ場合は設定からスリープで落ちないように変更する

ゲーム開始からの手順

以下が,様々な調査から改善を加えた,待ち時間のみでスナイプする場合の方法である (将来的により良い方法が見つかるかもしれない).まず,タイムスケジュールの図を示す.調整するのは,ゲームデータの選択画面での待ち時間と,マカ錬金を投入する際の待ち時間の2か所である.マイコン使用の場合,後者の待ち時間で最後の数フレームの調整を行う.

画像
待ち時間の調整のみでスナイプを行う場合のタイムスケジュール.赤文字の部分は求める護石に応じて調整する.

ここから文字での説明である.

  • 事前準備を行った後にゲームを終了し,Switchのホーム画面でMHXXを選択するところから開始.

    • 乱数の決定時刻はゲーム選択後の暗転時からだが,ゲームのロード時間がほぼ一定である場合は,ゲーム選択と同時(要するに制御しやすいタイミング)にタイマーをスタートさせるとよいだろう.

  • ゲームを起動し,「ゲームデータの選択」画面 (Continueを押した後) までAボタン連打.

  • 「ゲームデータの選択」画面で希望の護石に合わせてフレームを消費する.

    • Continueで概ね700程度消費されるが,これは確率的ではなく,700程度に加え,一定の条件(まだ未確定)になるまで追加で消費が行われる.そのため,Continueを押す前で待たない方がよい.

    • 未検証だが,乱数消費の観点から「このキャラクターでよろしいですか」に対して「はい」を押す手前で止めるのが最良ではないかと考えている.

    • ゲームを開始した後で待たない方が良いのは,拠点(村)において時間経過以上のフレーム数が消費されるためである.しかし,後述の通り,データのロード時にも決定論的フレーム消費があるため,数フレーム程度を村で調整せざるを得ない場合がある.もちろん,この調整は手動では難しいと思われる.

    • 手動の場合はぎりぎりまで「ゲームデータの選択」画面で粘ることは難しいので,マカ錬金の投入画面で1-2秒残る程度に調整するとよいと考えられる.

  • 待ち時間の消費後はAボタン連打してキャラクター選択.

    • ゲームのロード時に追加で166から170程度の乱数消費が発生する.Continueを押す場合と同様に,この乱数消費量は確率的ではなく,押す前の乱数値に対して決定論的に補正量が決まる.どのような式により補正が入るかは現状明らかとなっていない.

  • ココット村入口から開始.左斜め前にダッシュしてマカ錬金屋さんに話しかける.マカフシギ錬金術を選択し,護石を投入.

    • 護石投入時の乱数消費量(投入時までの経過時刻と同一ではないことに注意)が重要であり,それ以降は結果に影響しない.

    • 手動での最終的な調整,あるいはマイコンでの最終的な数フレームの調整を投入直前に行う.

  • 護石投入後,ケルビマラソンに移行.鑑定のため右斜め前にダッシュして,受付嬢から下位 Lv1「森の中のケルビ」を受注.門からクエスト出発.

  • ケルビの角を納品.報酬は売却し,セーブせずに終了.

  • 複数投入している場合は,ケルビマラソンを続ける.

  • ココット村に戻ったらマカ錬金屋さんか自宅のルームサービスに話しかけて護石を確認する.

以下は全体的な補足である.

  • まず,最速起動・最速操作から1秒以下の猶予しかないが,斬味5 痛撃4 S3 (1716 frames) を狙うとよい.難しい場合は時点の逆上5, 達人9 S3 (4418 frames) などであろうか.

  • 基準となる試行で得られた秒数に,フレーム数の差分を秒に変換したものを加算して,他の護石を狙う秒数を決定する.複数の護石セットを錬金に投入してもよいが,基本的に1セット目の1番目の護石に対応するフレームを参照するべきである.

  • 2 or 3つ目のタイマーあるいはラップ機能を用いてさらに安定させる場合,continueを押したタイミングと,キャラクター選択で「はい」を押したタイミングで記録を行うとよい.


Continue連打による待ち時間短縮法の手順と考察

次に,Continue連打を用いた待ち時間短縮法について紹介する.記事の公開後,後方視的に同様の手法にたどり着いている人を複数観測したが,筆者自身は以下にapmnnn氏が記載している事項が発想の元となった.

タイトル画面で「continue」を押した時、700±30ほど追加で進みます。押す度に進みます。

https://github.com/apmnnn/mhxx-rng/blob/main/docs/rng.md

本作に限らず,乱数調整を行う場合,安定的に乱数値を消費できる手法というのは重要である.太字箇所の記述をそのまま解釈するなら,continueを押すだけで 700 frames ≈ 23 secに相当するフレームを進めることができるのである.これは繰り返し行えるので,ゲームモード選択とゲームデータ選択をA, B, A, B…と連打して行き来すれば短時間で乱数を大幅に消費できることを意味する.

Continue連打によって乱数消費できることの確認

apmnnn氏の記載内容が正しいか確認するため,対照実験を行った.まず「A 100 ms 押す」→「100 ms 待機」→「B 100 ms 押す」 → 「100 ms待機」の計400 msを一周として繰り返すコードを作成した.これを同じ時間待つだけのdelay関数を対照試行とし,フレーム数を比較した.

まず,continue連打を20回行った場合,8000 ms = 8 secかかる.結果は以下の通り.

  • 連打試行:15252 frames (特攻 5 装速 6 S0 RARE10)

  • 対照試行:1952 frames (底力 2 ◯◯---- S1 RARE8)

1回の消費フレームの平均値は (15252 - 1952) / 20 = 665 frames であった.これは,apmnnn氏が記載の概ね700 framesと大きくはずれない.

次に,continue連打を400回行った場合,160000 ms = 160 secかかる.結果は以下の通り.

  • 連打試行:287329 frames (護石 6 真燼 3 S2 RARE10)

  • 対照試行:6507 frames (加護 6 ◯◯---- S1 RARE9)

1回の消費フレームの平均値は (287329 - 6507) / 400 = 702 frames であった.これにより,MHXXにおける需要が高い,痛撃6 達人10 S3  (296260 frames) をスナイプするのに2時間44分待機しなければならなかったところを,3-5分程度に短縮することができる.

また,スナイプはしないが,ケルビマラソンやシャガルマラソンなどでマカ錬金を行う場合も,起動時にcontinueを連打することで,より新しい護石を入手する確率があがる.これもバグというよりは仕様であり,完全に白を保ちたい人にも実行可能な範囲の操作だろう.

なお,当初はContinueによる乱数値消費が確率的操作だと思って上のような記述をしたが,実際には決定論的操作である.詳細は「Continueによる固定点 (合流地滞) への数値的吸引」を参照.

Continue連打法の手順

ここでContinueを用いたスナイプ手法を整理しておく.調整するのは,Continue連打の回数 (> 1000フレームの調整),ゲームデータの選択画面での待ち時間 (数百フレームの調整),マカ錬金を投入する際の待ち時間 (数フレームの調整) の3か所である.

画像
Continueを使用する場合のスナイプ手順.赤字の箇所を調整する.

以下は,Continue連打を用いる場合に特異的な手順の補足である.その他は通常のスナイプ手法と同様である.

  • ゲーム開始時にタイマースタートし,ゲームモード選択画面とゲームデータ選択画面を交互に遷移するようにcontinue連打を行う.この際,一切休憩をせずに同じテンポで決まった時刻まで決まった回数continue連打を行うのが最良である.手動でもズレは固定点への吸引によってある程度許容されるはずである.もちろん,continue連打は苦行である.同様に,固定点への吸引を利用すると,概ね決まった時刻に休憩を取ることで対処できる可能性がある.

  • 最後のcontinueを押したタイミングで2番目のタイマーをスタートするか,ラップを計測する.ゲームデータ選択画面で可能な限り待ち,時間が近づいたらA連打でキャラクター選択を行う.3番目のタイマーを使用する場合はキャラクター選択で「はい」を押したタイミングに合わせる.

  • ココット村から開始後,最速でマカ錬金屋に向かい,余裕をもって護石の投入時刻をタイマーに合わせる.マイコン使用の場合は,ここで最後のフレームの微調整を行う.

Continue連打法を応用した事例:痛達理論値の入手

マイコン使用ではあるが,ゲームモードの選択画面で事前に30000 ms待機し,continueを410回連打 (400 ms周期),再度ゲームモードの選択画面で33360 ms程度待った後に準最速でマカ錬金を入れることで痛撃6達人10S3を入手することができた.なお,これは初回の成功時の手法であるが,後述するようにゲームモードの選択画面 (continue前) で待機することはあまり良くないことが分かった.

画像
実際に得られた護石

マカ錬金への投入時刻はゲーム開始から4分17秒であった.2時間44分待たなければいけなかった従来手法と比較して大幅な時間の短縮となった.

興ざめなのは確かであり,筆者は仮説が当たってしまったことに対して脱力した.憧れだったゴール装備を組んでみて,抱いた感情は虚無である.仕事終わりに野良マルチで炭鉱や超特の手伝いを頑張り,ようやく入手した護石をいくつもリストラするのは複雑な気持ちだった (炭鉱勢やTA勢に比べれば大したことはないだろうが,一応2つのセーブデータで赤冠をつけ,超特もソロで全種倒し,勲章も最小金冠以外は埋める程度にはやりこんでいた).

しかし,この劇的な結果を見て,感情は一旦切り離し,とりあえず報告はしておこうと思ったのが本ノートを書いた主要因である.取扱いに注意が必要な情報であるという認識は当初からあったが,筆者は機密事項でない限り,分野の発展のため報告や公開を行う文化に染まりすぎていた.それがゲームという異分野においても当てはまるとは限らないという認識が足らず,深く反省するところである.

なお,スナイプの手法公開から十分に時間が経ったこともあり,Continue連打を使用せず,待ち時間の調整のみで手動での入手を実現した方も複数観察している (自己申告を信用すればではあるが).

2026/03/15時点で公開されていた,手動での成功動画を紹介しておく.

繁体字版でのMHGUでの動画も紹介しておく (こちらは完全人力ではないようだ).少し追加でフレーム調整が必要とのこと.

Continueによる固定点 (合流地滞) への数値的吸引

ここからは,continue連打でなぜ安定するのかの考察である.重要事項は,ここより上にまとめたので,以降は必要に応じて読むことにしてほしい.

もし,continueが確率的操作なら,連打した場合の乱数値が取りうる状態数は発散する.このことを確率過程の観点から考えよう.まず,continueでのフレームの進行量が確率的であると仮定し,確率変数 X_k で表す.フレーム進行量は独立同分布に従い,\mathrm{E}(X_k)=\mu, \mathrm{Var}(X_k)=\sigma^2とする.この場合,n 回目までの逐次和 S_n = \sum_{k=1}^n X_k はドリフト項のついたランダムウォークとなりうる.そして分散は \mathrm{Var}(S_n) = n\sigma^2 となり,continue回数 n に比例して増大するはずである.もちろん,フレーム数は離散値を取りうるため,各ステップでの量子化の影響もあるだろうが,それでも逐次和(フレーム数)の分散は発散する.このため,筆者も直感的には発散するから無意味と考えていたが,検証を行ったところcontinueを繰り返しても分散は想定より増えなかった.自分が何かを勘違いしていると思い,continue回数の平均値を計算して,安定性が大数の法則によるものと初めは思い込んでいた.しかし,(apmnnn氏に指摘いただいた通り) 大数の法則はあくまで平均の分散 \mathrm{Var}(S_n/n) = \sigma^2/n に関するものであり,上記の通り和の分散 \mathrm{Var}(S_n)=n\sigma^2に関しては収束しない.

このため,continue時の挙動が確率的であると仮定すればcontinue連打法は成立しないはずだが,実際は成立してしまう.よって,確率的ではなく決定論的操作が行われていると推察される.

ここで,apmnnn氏が記載の「continue時のフレーム進行が700±30」という情報が正しいのか,どういう意味なのか,確率的なのか,確率的であればどのような分布に従うのかといったことを検証するため,continue回数を1, 10, 100回とし,それぞれ10回試行した際のフレームを調べた実験結果を示す.条件は,Switch2, ダウンロード版,装備なし,範馬刃牙双剣,オトモなし,機内モード,ミュートであり,continue連打後は最速でマカ錬金に向かう.

画像

Continueが1回の8試行目を除き,ほぼ平均値の近傍に収束しており,分散は想定以上に小さい.特に100回continueした際の各群におけるフレーム数の最大値と最小値間のフレームは当確率で出現していない(下一桁が3,4,8,9しか出ない).なお,安定化のため,各群での待ち時間は少し調整しているので,各群の平均値にはあまり意味がない.

apmnnn氏が記載のcontinueでの700±30というのは,平均 700, 標準偏差 30の正規分布に従うなどではなく,概ね700進行するが30程度は補正が入る可能性があるということであったのだろう.

筆者はこれにより,以下の記述の意味がようやく理解できた.

continueを押すと、非常に不安定な量の乱数が進行します。しかし、近いフレームであれば、同じ乱数位置に着地します。なので、数フレームのズレは気にしなくてもいいです。

また、continueを押した時の乱数の進行量の多寡は押すタイミングの早さとはあまり関係がありません。より早い段階でcontinueを押したにも関わらず、より多くの進行量、より後ろの乱数に着地することもあるということを心に留めておいてください。

https://github.com/apmnnn/mhxx-rng

この決定論的操作により,正確な数学用語の使用ではないが「固定点 (fixed point)」ないし, (apmnnn氏の表現では) 「合流地帯」への数値的吸引がcontinue時に生じていると考えられる.

固定点への数値的吸引の例として,筆者の痛達理論値を取得する際の実験結果を紹介する.最初の実験では,ゲームモード選択画面で一定時間待ち,continue連打の後に最速でゲームを開始するという枠組みを取っていた.しかし,continue連打をする前の遅延の長さによらず,同じ乱数値(フレーム)に到達することがあった.以下では,同じフレームに到達した条件同士を同じ色(白は異なる)で塗っている.

画像
試行番号,Continueの回数,Continue前に待った時間,結果のフレーム数

オレンジのフレーム295968は特に典型的で,15000 ms = 450 framesも小さくしたのにも関わらず,同じフレームに到達している.当時は原因が全く分からず,このcontinueによる謎の吸引現象への対処を考えた結果,continue後の遅延を制御することにし,その結果として目的のフレームに到達しやすくなった.

なお,数値的吸引は,時間的に超過する場合と不足する場合で対称性を持つかは現時点で不明である (ceiling/floorなのか, roundなのか).また,マイコンを用いるとcontinueの周期をほぼ正確に制御することができるが,continueの周期によってフレームの制御などが変化する可能性もある.これらは未解決問題として残っている.

この数値的吸引は,筆者だけで観察されたものではない.同じ挙動がapmnnn氏からの情報提供やX上の投稿からも確認された.apmnnn氏からのコメントを引用する.

continueを押したときやセーブデータのロードの際に移動する乱数の量は、その直前の乱数位置のみによって決定論的に決まります。そして、内部では(天運の錬金のお守りの種類を決めるときのように)何らかの条件を満たすまで乱数を進め続ける処理が混じっているのではないかと推測しています。3Dモデルの処理が関連しているかは不明です。

これにより、continueを押す前の乱数位置を手前に変えたにも関わらず押した後の乱数位置が後ろになったり、continueを押す前の乱数位置が隣り合っていれば、しばしば押した後の乱数位置が同じになる、という現象が起こるのではないかと推察しています。

https://note.com/preview/nf4a06271c16a?prev_access_key=55cf1b584dcde954f5e84d3d1bc31178

ここで,「天運の錬金のお守りの種類を決めるときのように」とは次のことを指すだろう.

②rand(w,2)を100で割った余りが10未満なら、最初のお守りをなぞのお守りに、55未満なら光るお守りに、85未満なら古びたお守りにする。

85以上ならrand(w,3)を計算し、再び先程と同様に判定し、最初のお守りの種類を決める。85未満になるまでrand(w,◯)の◯を進め、これを繰り返す。

https://github.com/apmnnn/mhxx-rng/blob/main/docs/melding.md

これらから,continueを押した際に,単に700程度進むだけでなく,何らかの条件を満たすように調整する処理(丸め込みなど)が含まれているというのが仮説である.この補正がどのようなものかまだ判明はしていないが,上述のcontinue前の待ち時間を変えた実験結果から,continue後の乱数値を700n + m (mは一定値) に丸め込む性質があるのかもしれないが,そう単純ではないかもしれない.

このため,ゲームモード選択で待ち時間を調整するのではなく,ゲームデータ選択画面で待ち時間を調整する方がよい.ゲームデータ選択画面で乱数が大きく不規則に動くことはないようだ.

セーブデータのロードの際に移動する乱数の量は、その直前の乱数位置のみによって決定論的に決まります。

また、continueを押した後、セーブデータの選択画面では時間経過以外で乱数は進行しません。3Dモデルの表示や動きによる乱数への影響はないものと思われます。経験則ですが、少なくとも1日ほどの放置で、熱や通信などの外的負荷なしに乱数が想定よりずれることはありませんでした。
なお、セーブデータのロードによる乱数の進行は166〜170ほどで、continueによるブレに比べかなり小さいです。

https://note.com/preview/nf4a06271c16a?prev_access_key=55cf1b584dcde954f5e84d3d1bc31178

仕組みについては謎が残るが,いずれにせよcontinue連打をし終わった後,ゲームデータ選択画面で待ち時間の調整を行うのがよいと結論付けられる.ただし,最後の数フレームの調整はどうしてもデータロード後に行わざるを得ない.ゆえに3番目の調整点として,マカ錬金投入直前に数フレームの時間調整を行う.

補足:Arduino Leonardoによる入力制御

最後に補足として,手法の改善方法を考えるために使用したマイコン (Arduino) の使用法を記載しておく.調べればすぐに出てくるが,注意事項等を併記していない文書も多く,ここに残しておく.

Arduino Leonardoをコントローラとして使用する場合の注意点

Arduinoはマイコン(電子機器を制御する小型のコンピュータ)であり,Arduino Leonardoはその中でUSBを介した接続が可能なモデルである.このため,特別な機器を挟まずにPCとSwitchの双方に接続可能である.

マイコンを用いた入力制御には利用規約において注意すべき点があるため,以下に整理しておく.Nintendo Switch2(Switch も同様)の利用規約第1条(3)には次のような記載がある。

第1条 使用許諾
(3) 本ゲーム機本体、周辺機器、本ソフトウェアを不正に改造しないこと、および任天堂の許諾を受けていない本ゲーム機の周辺機器およびソフトウェア等を使用しないこと

https://support.nintendo.com/jp/legal-notes/switch2-eula/index.html

任天堂ライセンス製品として提供されているコントローラには,一般に連射機能を備えたものがある.一方で,それ以上のマクロ機能を持つコントローラやマイコン(Arduino など)を用いた入力装置については,解釈によっては未許可の周辺機器の使用に該当し,規約違反とみなされる可能性がある.

コントローラの操作方法には,手動操作,連射機能付きコントローラ,マクロコントローラ,マイコンなど,段階的に自動化の度合いが異なる方法が存在する.どこまでの自動化を許容するかはゲームの種類や性質,また規約の解釈によっても異なる.本作は競技性のあるPvPタイトルではなく買い切り型のゲームであり,本ノートで扱う内容もオンラインではなくオフラインでの操作を前提としている.ただし,ゲームは基本的に人間による操作を前提として設計されているため,このような自動入力は公式に想定された遊び方ではないことは確かである.マイコンの使用については様々な考え方があり,本ノートはその是非について判断を示すものではない.一般に,マイコンの使用は法的に違法と評価される可能性は高くない一方,上記のように規約上は解釈によってグレーとなり得る.またゲームコミュニティにおいても評価は分かれており,一般に好ましくない行為とされうる.したがって,このような手法をどこまで許容するかは最終的には各人の価値基準や遊び方に委ねられると考えている.

Arduino Leonardoの使用手順

以上のことを念頭に置き,以下のArduinoについての記載を読んで欲しい.まず,Arduinoを使用する場合,事前の調整を除いた使用手順は,以下の2ステップである.

  1. Arduino LeonardoとPCをUSB接続し,Arduino IDEを介してコード(操作)をArduino Leonardoに書き込む.

  2. コードが書き込まれたArduino LeonardoをPCから外し,SwitchにUSB接続する.すると自動で書き込まれたコード(操作)が実行される.

Arduinoはオープンソースハードウェアであり,純正品以外も販売されている.純正品が最も信頼できるが,安価な代替品を使用しても大きな問題はない.価格としては2000円程度で,通常のProコンよりも安価に購入できる.

筆者は以下の互換機を購入した.USBケーブルも付属しているが,PC/Switchに接続する側の端子はUSB Type-Aであることに注意してほしい.筆者は,Switchのドックを使用しないので,USB Type-AとType-Cの変換コードも購入した.

次に,Arduino Leonardoにコードを書き込むため,PCにArduino IDEをインストールする.ここから,Arduino LeonardoをSwitchコントローラーとして認識させるまでの流れは,主にポケモンの操作自動化を対象として様々な記事が作成されている.Switchの操作には NintendoSwitchControlLibrary を用いる.導入などに関しては,このライブラリを作成されたレフマーナ氏による以下の記事を参照してほしい.Arduino Leonardoの使い方を含め,画像付きで分かりやすい.

記事を参考にして,Switchへの入力がArduino Leonardoから制御できるようになれば,Arduino Leonardoのコード以外の事前準備は終了である.

スナイプの手法自体は手動の場合と変わらないので,もしマイコンを利用する場合はコードは各々で実装してほしい.要するにココット村に合わせ,任意の遅延を含む,1回のマカ錬金とケルビマラソンを行うコードを書けばよい (前述の通り,Nintendo Switch規約を見直したためコード自体は削除した).

とても局所的なコードなら許容されると考え,移動の上で数値の調整がやや面倒な個所のみ示しておく.いずれの移動においても, NintendoSwitchControlLibraryのラッパー元であるSwitchControlLibraryのコマンドを用いて,Rボタンを長押しにしておく.

  • ゲーム開始から,マカ錬金屋さんまではLスティックの操作を tiltLeftStick(100, Stick::MIN, 3200) で指定すればよい.

  • マカ錬金屋さんから受付嬢まではLスティックの操作を
    tiltLeftStick(Stick::MAX, Stick::MIN, 1500) で指定すればよい.


長々と書いたが,このノートが何かの助けになれば幸いである.最後ではあるが,このノートを読んで実行したことによって生じた不利益に関して筆者は責任を一切負わない.自己責任でお願いする.



ピックアップされています

お気に入りnote

  • 43本

コメント

5
コメントするには、 ログイン または 会員登録 をお願いします。
ナトりん(塩化ナトリウム)のプロフィールへのリンク

記事を拝読させていただきました。 数学的知見においては私は乏しいのですが、既存の「MHXXにおける乱数とお守りの決定法」に関する資料から発展した「continue連打による新手法」について分かりやすくかつ詳細に記述されていると感じました。 追記前と追記後とをそれぞれ読ませていただいており…

apmnnnのプロフィールへのリンク
apmnnn

こんにちは。 マイコンを用いた自動化の検証や、新手法の提案、そして丁寧で詳細な解説をありがとうございます。大変興味深く読ませていただきました。 記事を拝見し、私から3つほど補足・考察を共有させていただきたいことがあります。 ①乱数の進行を待機するのはcontinueを押した後の方が良…

匿名のプロフィールへのリンク
匿名
@匿名 さん

③ 遠いフレームを,continue連打を使わず長時間放置する場合,確かにそうであると思います. ただ,私はcontinue連打法に拘ったため,不安定性から長いフレームの際のパラメータを統計的手法で最適化できるのではないかと考えており,数式を書いたりと試行錯誤しておりました. 個人的な話をして…

MHXXの護石スナイプ手法の考察と待ち時間短縮手法の提案|匿名
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1