Steamのトレーディングカードを集めたいと思いながらも、
「ゲームを起動したまま放置するのが面倒」「PCを占有したくない」「複数タイトルや複数アカウントを管理しきれない」
――そのような悩みを抱えていないでしょうか。
ArchiSteamFarmは、そうした課題を一気に解決できる、Steamトレーディングカード自動収集ツールです。正しく設定すれば、ゲームを実際に起動することなく、カード回収を自動で進めることができ、Steamレベル上げやバッジ作成を効率化できます。一方で、初期設定やSteam Guard認証、IPCやUIの扱いに不安を感じ、「難しそう」「アカウントが危険ではないか」と感じて導入をためらう方も少なくありません。
本記事では、初心者がつまずきやすいポイントをあらかじめ回避しながら、ArchiSteamFarmを安全かつ確実に使いこなすことを目的に、導入から設定、運用、トラブル対処までを体系的に解説します。GUIを使った設定方法を中心に、設定ファイルの考え方や放置運用のコツ、注意すべきリスクまで網羅しています。
「まずは1アカウントで安全に動かしたい方」
「できるだけ手順通りに失敗せず設定したい方」
「カード収集を放置で安定運用したい方」
そのような方にとって、本記事が最短かつ安心して導入できる実践ガイドとなるよう構成しています。ここから順を追って確認していきましょう。
※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。
ArchiSteamFarmでできることと注意点
Steamトレーディングカード自動収集の仕組み
ArchiSteamFarm（以下ASF）は、Steamクライアントが提供している「ゲームをプレイしている状態」を、サーバー側の仕組みに沿って再現し、トレーディングカードのドロップ（入手）を自動的に進めるためのツールです。Steamのカードは、対象ゲームを起動して一定時間プレイ（または放置）することで順次ドロップしますが、ASFはこの「起動・プレイ状態」を自動化し、実際にゲーム画面を開かずにカード収集を進められます。
ポイントは、ASFが「ゲームを起動しているように見せる」ことにより、Steam側の仕組みが想定しているドロップ条件を満たしていく点です。ユーザーがやるべきことは大きく分けて次の3つです。
ASFにSteamアカウントでログインできるようにする
カードを落としたいゲーム（カード対象の所有ゲーム）がある状態にする
ASFが正しく稼働して、カード収集が進むのを確認して放置運用へ移行する
またASFは、1アカウントだけでなく、複数アカウントを「ボット」として分けて管理できます。たとえば、メインアカウントとサブアカウントを分離してカード回収を進める、家族アカウントを同一端末で管理する、といった運用が可能です。複数運用を行う場合でも、基本の考え方は「ボットごとに設定ファイルを用意し、ログインと収集を個別管理する」と覚えておけば問題ありません。
利用前に知っておきたい制約とリスク
ASFは便利な一方、運用の前に把握しておきたい注意点があります。特に、アカウントの安全性と設定の扱いは最優先です。
資格情報（ログイン情報）の扱いが最重要です
ASFはSteamにログインして動くため、設定ファイルや認証に関する情報の管理が甘いと、アカウントリスクが一気に高まります。設定ファイルをクラウドに丸ごと置く、他人に送る、共有PCで放置する、といった行為は避けてください。Steam Guard（メール認証・モバイル認証）で詰まりやすいです
初回ログイン時や環境が変わったときは、Steam Guardの確認が必ずと言ってよいほど発生します。慌てて試行を重ねると制限がかかる場合があるため、丁寧に対応する必要があります（後述します）。IPCやASF-uiの外部公開は避けるべきです
ASFにはUI操作（ASF-ui）がありますが、これはIPC（ローカルのWebサーバー機能）を介して提供されます。ネットワークに公開する設定を誤ると、第三者がアクセスできる状態になり得るため、ライトユーザーは「ローカル運用」を原則にしてください。更新の影響を受けやすい分野です
Steam側の仕様変化やASF側の更新により、挙動が変わる可能性があります。特に認証やUI周りは更新が入りやすいため、導入後も「公式リリース」「公式Wiki」を基準に追従する姿勢が重要です。
ここまでを踏まえ、この記事では「最短で動かす」だけでなく、安全に放置運用へ持っていくための設計として解説します。
ArchiSteamFarmの導入手順
ダウンロード先とビルドの選び方
ASFの入手先は、基本的に公式GitHubのReleasesを基準にしてください。非公式配布サイトや不明なミラーから入手すると、改変物や古いバージョンを掴むリスクが増えます。導入の第一歩は「正しい入手元」を固定することです。
ビルド（配布ファイル）の選び方は、利用環境によって変わります。判断軸は次の通りです。
OSに合った配布物を選ぶ
WindowsならWindows向け、LinuxやmacOSなら対応する配布物、または汎用ビルドを検討します。初心者は“動かしやすい構成”を優先する
まずは「起動できるか」「ログインできるか」「カードが落ちるか」を確認するのが目的です。最適化（Dockerやサーバー常駐）は、動作確認後に段階的に移行する方が失敗しません。更新と互換性を前提に考える
ASFは更新が入りやすい分、古い手順を当てはめると詰まりやすいです。導入時点で最新の公式情報を参照し、古いブログ記事の断片だけで進めないことが安定運用の近道です。
なお、ASFは.NETランタイム上で動作する構成です。OS別のビルドを使う場合もありますが、環境によっては.NET関連の要件が絡むため、起動時にエラーが出たら「ランタイム」「依存関係」を疑うのが基本です。
起動に必要なランタイムと初回起動の確認
ASFを起動した際、まず確認すべきは「正常にプロセスが立ち上がり、設定ファイルを読み込める状態になっているか」です。初回起動での確認観点を整理します。
初回起動で見るべきポイント
コンソール画面が開き、すぐに終了しない
重大な例外（例：ランタイム不足、DLL不足）で停止していない
configフォルダが生成される、または設定ファイルを配置できる構造になっているASF-ui（後述）を利用する場合、UIが有効になっていそうか（IPC設定次第）
起動に失敗する場合、初心者が最も多く踏むのは次の2パターンです。
.NETランタイムの不足・不整合
エラー文に“runtime”“framework”“dotnet”などが出る場合は、ランタイムの不足が濃厚です。まずは公式の互換性・要件に沿って環境を整え、起動を通してください。ファイル配置や解凍ミス
zipの解凍が不完全、権限のない場所（例：特殊な保護フォルダ）に置いている、実行ファイルだけを抜き出している、といったケースです。解凍後のフォルダ一式を、権限の問題が少ない場所に配置するのが確実です。
初回起動が通ったら、次は設定です。ASFの設定は「正しい設定ファイルを置けるか」でほぼ決まります。
ArchiSteamFarmの設定方法を選ぶ
ASFの設定は大きく2階層です。
ASF.json（グローバル設定）：ASF全体の挙動（例：IPCの有効化、ログ設定など）
BotName.json（ボット設定）：アカウント単位（ボット単位）の設定（ログイン、動作方針など）
この構造を理解すると、設定トラブル時の切り分けが簡単になります。たとえば「UIに入れない」はASF.jsonやIPC寄り、「ログインできない」はBotName.json寄り、という具合です。
まずは設定方法を選びます。以下の比較表を基準にしてください。
| 設定方法 | 難易度 | 向く人 | 強み | 注意点 |
|---|---|---|---|---|
| ASF-ui | 低〜中 | GUIで完結したい | 画面操作で設定・管理しやすい | IPCの安全運用が前提 |
| WebConfigGenerator | 低 | まず確実に設定ファイルを作りたい | ブラウザで手順に沿って生成できる | 生成後の配置ミスに注意 |
| 手動JSON | 中〜高 | 細かい管理をしたい | 仕様を理解して最小構成にできる | キー名ミスや型ミスで動かない |
初心者の最適解は、多くの場合「ASF-ui」または「WebConfigGenerator」です。手動JSONは、理解が進んでからでも遅くありません。
ASF-uiで設定する流れ
ASF-uiは、ASFが提供するWeb UIで、ボットの作成・設定・状態確認などを画面で行えるのが特徴です。CLIだけで進めるのが不安な方には向いています。
ASF-ui利用の基本手順
ASFを起動する
ローカル環境でASF-uiへアクセスする（IPCが有効な場合）
画面の案内に従い、ボットを作成する
ログイン情報や必要な項目を入力し、保存する
ASFのコンソールログで、設定が読み込まれたことを確認する
この段階で大事なのは、UIを外部公開しないことです。ライトユーザーは「同一PC内でアクセスする」設計を守るのが安全です。ネットワーク越しにアクセスしたくなる場合もありますが、アクセス制御や公開範囲を誤ると危険性が跳ね上がります（IPCの章で詳説します）。
また、ASF-uiで設定しても、結局は内部的に設定ファイル（JSON）が生成されます。つまり、UIは“編集手段”であって、最終成果物は設定ファイルです。よって、次の「WebConfigGenerator」や「手動JSON」の理解も、運用の安定に繋がります。
WebConfigGeneratorで設定ファイルを作る流れ
WebConfigGeneratorは、ブラウザで入力項目を埋めていくと、ASFの設定ファイル（主にボット設定）を生成できるツールです。初心者の最大のメリットは、キー名や型を間違えにくい点です。
WebConfigGeneratorでの基本手順
WebConfigGeneratorを開く
ボット設定を作成する（ログイン情報・基本方針を入力）
生成されたJSONを取得する
ASFの
configフォルダに配置するASFを再起動し、ボットが読み込まれたことを確認する
ここで詰まりやすいポイントは「配置先」です。ASFは決まったフォルダ・命名規則で設定を探します。たとえばボット設定は BotName.json のように、ボット名がファイル名になります。保存したファイルの名前が意図と違うと、ASFが読み込まずに“ボットが存在しない”状態になります。
配置ミスを防ぐチェック
configフォルダ直下に置いているか拡張子が
.jsonになっているか（例：BotName.json.txtになっていないか）ファイル名（ボット名）が想定どおりか
文字コードや改行が崩れていないか（通常は問題になりませんが、特殊編集で壊れる場合があります）
まずは1つのボットだけ作って動かし、安定したら増やすのが鉄則です。
手動JSONで設定する最小構成
手動JSONは、自由度が高い反面、初心者がミスしやすい方法です。ただし、最低限の理解は持っておくと、トラブル時の復旧が早くなります。ここでは「最小限の考え方」に絞って説明します。
ASF.json：ASF全体の設定
例：IPCを使うか、ログをどう出すか、など。BotName.json：ボット（アカウント）ごとの設定
例：Steamログイン、ボットの動作方針、2FA関連、など。
手動で作る場合のコツは「公式が示すサンプルや、UI/Generatorが生成したファイルを土台にする」ことです。ゼロから書くより、生成済みの正常ファイルを最小限に削って理解する方が安全です。
また、JSONで多い失敗は次の通りです。
カンマの付け忘れ、余計なカンマ
ダブルクォート漏れ
true/false の綴りミス
数値なのに文字列、文字列なのに数値、といった型の不整合
「起動しない」「読み込まれない」場合は、まず生成物（UI/Generator）と見比べるのが確実です。
Steamログインと2FAを安全に通す
Steam Guardで詰まる典型パターン
ASFの導入で最も時間が溶けやすいのが、Steam Guard（メール認証・モバイル認証）です。ありがちな詰まり方を先に整理します。
典型パターン1：認証コードを求められる
初回ログイン
IPや環境が変わった
Steam側で安全確認が入った
この場合は、表示される指示に従って、メールまたはモバイルのコードを正しく入力します。
典型パターン2：何度もコード入力を求められ、ループする
コードの入力ミス
期限切れコードを入れた
過剰な再試行
Steam側で一時的な制限
この場合、焦って連打すると状況が悪化しやすいです。いったん落ち着いて、入力経路（メールかモバイルか）と、コードの有効期限を確認してください。
典型パターン3：突然ログインが弾かれる
パスワード変更直後
端末・ネットワーク側のセキュリティソフトの干渉
一時的なSteam側の認証制限
ログイン関連は「Steam側の状態」に強く依存するため、ASFの設定だけでなく、Steamクライアントやブラウザで通常ログインが通るかも確認すると切り分けが進みます。
ここで重要なのは、Steam Guardはセキュリティ機構であり、試行過多は不正アクセスに見えるという点です。成功するまで何十回も繰り返すのではなく、原因を1つずつ潰すやり方が安全です。
ASFの2FA機能を使う判断基準
2FA（2段階認証）は、Steamアカウントの保護に非常に重要です。一方で、ASF側で2FAをどう扱うかは、目的により判断が変わります。基本方針は次の通りです。
カード収集だけが目的の場合
まずは既存の2FA運用（Steamアプリ等）を維持し、ASFは「通常ログイン＋必要時に認証コード対応」で動かすのが無難です。ここで安定稼働を優先します。ASF側の2FA機能が必要になる場合
一部の運用や機能で、ASF側で2FAを扱う設計が必要になる場合があります。その場合は、公式の2FA関連の説明に沿って導入してください。誤った取り扱いをすると、コード生成や認証の整合が崩れ、ログインループの原因になります。
どちらにせよ、ライトユーザーが優先すべきは「安全」です。2FAの設定をむやみにいじるより、まずは「ログインが通る状態」「カードが落ちる状態」を確立し、その上で必要が出たら拡張するのが堅実です。
カード収集の開始と運用
自動収集の基本動作と開始の考え方
ASFのカード収集は、基本的に次の条件を満たすと進みます。
ボットがSteamにログインできている
カード対象ゲームがライブラリに存在する
ドロップの余地が残っている（すでに上限まで落ちていない）
ASFが対象ゲームの「プレイ状態」を作れている
ここで誤解が起こりやすい点を明確にします。
“起動していれば必ず落ちる”とは限りません
カードには上限があり、すでにそのゲームのドロップ分を取り切っていると落ちません。また、対象ゲームがカード対象ではない場合も落ちません。“落ちない＝ASFが壊れている”とは限りません
多くは「ドロップの前提条件が満たされていない」ことが原因です。後述のチェックリストで確認すると、原因を切り分けやすいです。
運用のコツは、初回だけは必ずログを見て「収集が開始された」「対象ゲームをプレイ中として扱っている」ことを確認し、その後放置に移行することです。最初から無人運転にすると、詰まっていても気づかず時間だけ経過します。
よく使うコマンド例と運用ルール
ASFはCLIコマンドでも操作できます。コマンドはバージョンや設定により扱いが変わる場合があるため、ここでは「運用ルール」と「典型的な使い方の考え方」に焦点を当てます。
運用ルール（安定稼働のための基本）
認証が絡む操作は慎重に行い、失敗時に連続試行しない
収集開始後は、不要な再起動をしない（ログイン回数を増やすと認証要求が増えやすい）
アップデートは「まず1ボットで検証→問題がなければ全体適用」の順で進める
収集が止まったら、最初にログ（エラー・警告・認証要求）を見る
よくある運用イメージ
起動 → ボットログイン確認 → 収集開始 → 放置
問題発生 → ログ確認 → 必要ならボットのみ再起動/設定修正 → 再開
ツール運用で重要なのは「操作を増やさない」ことです。とくにSteam Guard周りは、操作が多いほど認証が増え、つまずき要因が増えます。最小限の操作で長時間安定させる設計が正解です。
複数アカウント運用の要点
複数アカウントを運用する場合、ボット設定ファイルを増やして管理します。ここでは、ライトユーザーが失敗しないための要点をまとめます。
要点1：命名規則を決める
例：
Main.json、Sub1.json、Sub2.jsonのように、役割が分かる名前にします。
どのボットがどのアカウントか分からなくなると、トラブル時の復旧が難しくなります。
要点2：2FAの管理をアカウント単位で整理する
2FAの有無、コードの受け取り先、復旧手段などをアカウントごとに整理します。
複数アカウントで混線すると、認証失敗ループの原因になります。
要点3：障害が起きたら“全体”ではなく“ボット単位”で切り分ける
たとえば1つのボットだけログインできないなら、設定・認証・アカウント状態の問題です。
全体が落ちているなら、ASF本体・ネットワーク・PC環境の問題です。
複数運用は便利ですが、まずは単体運用で安定させてから段階的に増やすのが安全です。
IPCとASF-uiを安全に扱う
IPCとは何かと既定ポート1242
IPCは、ASFが提供するUI（ASF-ui）や外部連携のために、ローカル環境でHTTPサーバーを立てる仕組みです。これにより、ブラウザから状態確認や操作が可能になります。既定では ポート1242 が使われることが多く、アクセス先としては http://localhost:1242/ のような形になります（実際のURLは設定や環境により変わります）。
IPCは便利ですが、仕組みを理解しないまま触ると危険です。特に「LAN内の別端末からも触れるようにしたい」といった要望があると、外部公開に近い設定を行いがちですが、ライトユーザーには推奨しません。
ポート変更と外部公開を避ける理由
ライトユーザーが守るべき原則は、次の一文に尽きます。
ASF-uiはローカルで使い、外部には公開しない。
理由は明確です。
UIやAPIが外部から触れる状態になると、悪意あるアクセスの対象になり得る
認証やアクセス制御を正しく設定できないと、アカウント運用上の事故に直結する
「一時的に公開したつもり」が、ルータ設定やPC設定により恒常的公開になりやすい
ポート変更は、ローカル運用でも必要になる場合があります（他ソフトと競合する等）。その場合も、公開範囲はローカルに閉じたまま変更するのが安全です。変更後にUIへアクセスできない場合は、ファイアウォールやセキュリティソフトがローカル通信を遮断している可能性もあるため、例外設定や許可を検討してください。
拡張運用：プラグインとDocker
プラグイン導入の基本
ASFにはプラグイン機構があり、機能拡張が可能です。ただし、プラグインは便利な反面、導入すると「問題発生時の原因箇所」が増えます。よって、初心者は次の順で進めるのが安全です。
標準機能のみで「ログイン」「カード収集」「放置運用」が安定する
追加でやりたいことが明確になる（例：監視、通知、独自連携など）
必要なプラグインだけを選び、導入後に挙動を確認する
プラグイン導入時は、更新や互換性にも注意が必要です。ASF本体の更新に追従していないプラグインは不具合の原因になります。トラブル時には、まずプラグインを無効化して標準機能で再現するかを見ると、切り分けが早くなります。
Docker運用が向くケース
Docker運用は、ASFを「PC上のアプリ」ではなく「コンテナとして常駐」させたい場合に向きます。たとえば次のようなケースです。
自宅サーバー（ミニPC、NAS等）で24時間稼働させたい
メインPCを常時起動したくない
環境差異を減らして再現性の高い運用をしたい
OSアップデートや依存関係の影響を受けにくくしたい
一方で、Dockerはネットワークやボリューム（永続化）などの概念が加わるため、初心者には難易度が上がります。カード収集だけが目的なら、まずは通常運用で安定させ、必要性が出てから移行する方が確実です。
トラブルシューティング
起動しないときのチェックリスト
起動しない場合は、原因の多くが「ランタイム」「ファイル配置」「権限」に集中します。以下の順で確認してください。
.NETランタイム要件を満たしているか（エラー文にruntime/frameworkがあれば最優先）
配布物の種類がOSに合っているか（Windows/Linux/macOSの取り違えがないか）
zipの解凍が不完全ではないか（フォルダ一式が揃っているか）
置き場所の権限は適切か（保護フォルダ、読み取り専用、実行不可の場所ではないか）
セキュリティソフトが実行ファイルを隔離していないか
まず“何も設定しない状態”で起動するか（設定が壊れている可能性を切り分ける）
最後の項目は重要です。設定ファイルが壊れていると、起動直後に読み込みで落ちることがあります。config を一時退避して起動し、起動が通るかで切り分けると原因が見えます。
ログインできないときのチェックリスト
ログインできない場合は「認証」「資格情報」「Steam側状態」の3方向で見ます。
SteamのID/パスワードが正しいか（Steamクライアントで通常ログインできるか）
Steam Guardの入力経路は正しいか（メールかモバイルか）
コードの入力ミス、期限切れ、試行過多がないか
パスワード変更直後で、追加認証が必要になっていないか
セキュリティソフトやネットワーク制限で通信が阻害されていないか
ボット設定ファイルの読み込み自体に失敗していないか（ログに警告が出ていないか）
詰まった際は、「同じ操作を繰り返す」のではなく、Steam側で通常ログインが可能か、認証コードの受け取りが正常か、を確認する方が早いです。
カードが収集されないときのチェックリスト
「ログインできているのにカードが落ちない」はよくある症状です。原因の大半は前提条件です。
そのゲームがトレーディングカード対応か
すでに当該ゲームのドロップ上限まで回収済みではないか
ボットがプレイ状態を作れているか（ログで対象が選ばれているか）
Steam側で制限（地域、アカウント制限等）がかかっていないか
ネットワークやPCのスリープで実質停止していないか
特に「回収済み」が原因の場合、ASFの不具合ではありません。先に「そのゲームに回収余地があるか」を確認するのが最短です。
ASF-uiにアクセスできないときのチェックリスト
UIが見られない場合は、IPC設定とアクセス経路を疑います。
IPCが有効になっているか（無効ならUIは出ません）
ローカルからアクセスしているか（外部からアクセスしようとしていないか）
既定ポート（例：1242）や設定したポート番号が正しいか
ファイアウォールやセキュリティソフトがローカル通信を遮断していないか
競合する別アプリが同じポートを使っていないか（競合時はポート変更を検討）
UIが使えない場合でも、WebConfigGeneratorで設定ファイルを作って運用する代替ルートがあります。UIにこだわりすぎず、目的（カード収集）に戻って最短の手段を選ぶのが確実です。
よくある質問
ASFは安全ですか
ASFはオープンな形で提供され、公式リリースが明確に存在します。ただし「安全かどうか」はツール単体だけで決まらず、運用次第で大きく変わります。安全性を高める要点は次の通りです。
公式リリースから入手する
設定ファイルや認証情報を第三者に渡さない
IPC/ASF-uiを外部公開しない（ローカル運用を徹底する）
アップデート時は段階適用し、異常があればロールバックや原因切り分けを行う
この4点を守れば、ライトユーザーとしてのリスクは大幅に下げられます。
Steamの規約的に問題はありますか
この質問は非常に多いですが、最終的にはSteam側の規約や運用ポリシーに依存します。一般論としては、アカウント運用に関わる自動化は常に慎重に扱うべき領域です。本記事では、少なくとも次の観点でリスクを増やさない運用を推奨します。
不審な挙動に見える操作を増やさない（認証試行の連打、頻繁な再起動など）
IPCの外部公開など、管理画面を外部へ晒す行為を避ける
認証情報の漏洩を防ぐ
規約解釈が必要な場合は、Steamの公式情報を必ず確認してください。
2FAは必須ですか
Steamのセキュリティとしては、2FAは強く推奨されます。ASF運用においても、2FAが有効なアカウントでは追加認証が必要になる場面が出ます。まずは既存の2FA運用を維持し、安定稼働を優先するのが堅実です。ASF側で2FA機能を取り込むかどうかは、用途が明確になってから判断するのが安全です。
ポート1242は開けてもよいですか
ライトユーザーには推奨しません。ポートを外部に開放するということは、ネットワーク越しにUIやAPIへアクセスされ得る状態を作ることです。アクセス制御や公開範囲の設計を誤ると重大な事故に繋がります。基本は「ローカル運用」で完結させてください。
複数アカウントはどう設定しますか
ボット設定ファイル（BotName.json）をアカウントごとに用意し、ボットとして追加していきます。最初は1アカウントで動作確認し、ログイン・収集が安定したのを確認してから、2つ目以降のボットを追加するのが安全です。命名規則と2FA管理を整理すると、運用トラブルが激減します。
収集が止まった時はどこを見ますか
最初に見るべきはASFのログです。ログに「認証要求」「通信エラー」「設定読み込みエラー」などが出ていないかを確認し、症状に応じて次の順で切り分けてください。
ボットはログイン状態か
認証要求が出ていないか
対象ゲームにドロップ余地があるか
ネットワークやスリープで停止していないか
UI/IPCの問題なのか、収集の問題なのか
まとめと次にやること
ASFは、Steamトレーディングカード収集を自動化し、放置運用に持ち込める強力なツールです。ただし、成功の鍵は「最短で動かす」よりも、安全に長期間安定させる設計にあります。
本記事の要点は次の通りです。
設定は「ASF.json（全体）」と「BotName.json（アカウント）」の2階層で理解する
初心者はASF-uiまたはWebConfigGeneratorで設定ファイルを作成し、1アカウントで安定稼働を確認する
Steam Guardは試行過多がリスクになるため、落ち着いて原因を切り分けながら対応する
ASF-uiは便利だが、IPCの外部公開は避け、ローカル運用を原則にする
収集が止まったらログを起点に、認証・前提条件・環境の順で確認する
次にやることとしては、次の手順が最も失敗しにくいです。
公式リリースからASFを入手し、初回起動を通す
ASF-uiまたはWebConfigGeneratorでボット設定を1つ作り、ログインを確認する
カード収集が進むことをログで確認し、放置運用へ移行する
安定後、必要があれば複数ボット、プラグイン、Dockerへ段階的に拡張する
仕様変更やアップデートで挙動が変わる可能性がある領域ですので、運用中に違和感が出た場合は、必ず公式Wikiや公式リリース情報を基準に確認し、手順を最新化してください。