ソロ build は、仲間が space を作ることや target を仕留めることを前提にできません。全ての stat を最大化する必要はなく、安定した主行動、離脱の方法、crowded な部屋でも使える inventory plan が必要です。最も頻繁な失敗を一つ選び、次の部品でその失敗を解決します。
最初から完成した list をコピーせず、目的と limitation を明記します。Artifact と Tablet を置く space が移動を妨げないか、攻撃を外した後に戻れるかを同じ条件で確かめます。
ソロの仕事を一つ選ぶ
今の run の目的を first clear、安定した探索、boss practice、achievement のどれかにします。目的が違えば許容できる risk も変わります。Weapon ガイドで主行動の射程と recovery を先に確認し、build の役割を決めます。
最初の試験を小さくする
一つの weapon、一つの Artifact、一つの Tablet の仕事だけを確認します。chapter、room、mode、version を記録し、同時に複数の部品を変えません。短い試験で移動が安定すれば、次の reward を追加します。
よくあるソロ失敗を覆う
damage が足りない場合でも、距離や timing の失敗を damage だけで隠しません。外した後の retreat、回復を使う window、inventory の空間、敵が増えたときの fallback を順に確認します。どれかが欠けるなら、その欠けた仕事を次の試験の中心にします。
version note
patch や platform が変わると、過去の成功条件がそのまま残るとは限りません。日付、version、save、chapter を build note に残し、変更後は最小の action から再試験します。確定した範囲と community lead を別の label にします。
ソロの fallback
予定した combo が出ない、reward が違う、敵の opening を逃した場合に、単独で run を続ける方法を一つ持ちます。最適な攻撃を失っても安全な移動が残る build は、瞬間的な damage が高いだけの案より再現しやすい場合があります。成功と失敗の両方を記録します。
ソロでの安定性を比べるときは、最速の clear だけを指標にしません。攻撃を外した後にどれだけ安全に戻れるか、混雑した inventory をどの程度整理できるか、次の部屋へ入る前に判断をリセットできるかを含めます。これらの条件が一つでも欠けた場合は、build を捨てるのではなく、その条件を補う小さな変更を試します。
一つの run で得た成功を最終形として公開せず、同じ目的で別の room を試します。結果が安定しないなら、weapon、Artifact、Tablet、chapter のどこが差を作ったかを切り分けます。solo の recommendation は、特定の player の速さではなく、記録された条件で別の player が再現できることを中心に書きます。
build の変更は一度に一つだけにし、前の状態へ戻れるようにします。比較できる記録があれば、patch 後の再試験も短く始められます。
最終的な page では、採用した部品だけでなく保留した案も短く説明します。保留の理由が space、timing、再現性のどれか分かれば、読者は自分の目的に合わせて安全に選べます。