スケジューラーとタスク編成

スケジューラーの役割はただ一つです：「今、どのタスクを実行すべきか」を決定すること。スケジューラー自身はゲームの操作ロジックを持たず、同一インスタンス内でタスクを並列実行することもありません。タスクは常に1つずつ直列に実行されます。

スケジューラーは各実行サイクルの開始時に必ずディスク上の設定ファイルを再読み込みします。設定のホットリロードはタスクの境界で発生し、タスク実行の途中で突然設定が書き換わることはありません。

タスクを制御する主要フィールド

各タスクの実行を決定づけるパラメータは以下の3つです：

設定項目	意味と機能
`Scheduler.Enable`	スケジューラーの管理対象としてタスクを有効化するかどうか
`Scheduler.NextRun`	次回実行が許可されるスケジュール時刻（設定ファイル内に永続化）
`Scheduler.Command`	内部コマンド識別子（`alas.py` 内のメソッド名に対応）

NextRun の時刻が現在時刻以前であり、かつ Enable がオンである場合、そのタスクは「実行待ちキュー」に入ります。スケジューラーはキュー内から優先度に従って実行すべきタスクを1つ選択します。実行待ちタスクが存在しない場合は、最も近い未来に期限を迎えるタスクの時刻まで待機します。

NextRun を空にする＝即時実行

「次回実行時刻」フィールドをクリアすることは、過去の日時（2020-01-01 など）を設定することと同義です。これによりタスクを即座に待機キューの先頭へ押し出すことができます。

実行優先度の決定方法

デフォルトの優先順位は module/config/config_manual.py の _DEFAULT_SCHEDULER_PRIORITY で定義されています。ユーザーは設定画面からこれを任意にカスタマイズ可能です：

システム設定 → 一般設定 → カスタムタスク優先度

1行に1つのタスクコマンドを記述し、上にあるタスクほど高い優先度を持ちます：

text

Restart
Commission
Research
Reward
OpsiScheduling
Main

リストに含まれていないタスクは、デフォルトの優先順位に従って後方に配置されます。

優先度は実行中のタスクを中断しません

優先度は「複数のタスクが同時に期限を迎えている場合」にどちらを先に実行するかを決めるためのものです。一度開始されたタスクの所要時間はそのタスク自身が決定し、スケジューラーが途中で割り込み中断することはありません。

時間間隔とスケジュール

設定項目	役割
`SuccessInterval`	タスク正常完了時に、次回実行を何分遅延させるか（0 の場合はタスクが自律判断）
`FailureInterval`	タスク失敗時に、次回実行を何分遅延させるか（デフォルト：120分）
`ServerUpdate`	サーバーの日付変更時刻。デイリー任務等のスケジュール基準時刻

タスク内部では通常 task_delay(success=True/False) を呼び出して次回実行時刻を算出します。委託であれば数十分、研究であれば数時間、デイリー任務であればサーバー日付変更時刻へセットされます。

タスクのホarding（まとめ実行）

Optimization.TaskHoardingDuration が 0 より大きい場合、待機中のタスクは予定時刻に一定の「ホarding時間」を加算して待機します。例えば 12:00 に期限を迎えるタスクに10分のホardingを設定した場合、実際には最短でも 12:10 に実行されます。

細切れに発生するタスクをまとめて1回の起動で処理し、エミュレーターの起動回数を抑える効果があります。

プリヒート（事前起動）

Optimization.WarmupEnable を有効化すると、スケジューラーはタスク予定時刻の数分前にあらかじめエミュレーターとゲームを起動し、メイン画面で待機させます。

コールドスタートに時間がかかる低スペック PC や HDD 環境で、タスク時刻到来と同時に即座に操作を開始できるようにするための機能です。

アイドル待機時の動作

実行待ちタスクがない待機時間帯の動作は Optimization.WhenTaskQueueEmpty で設定します：

設定値	アイドル時の動作
`goto_main`	ゲームのメイン画面に戻って待機（デフォルト）
`close_game`	ゲームアプリを終了し、メモリを解放
`stay_there`	直前の画面のまま一切操作せず待機

待機時間が3時間を超え、かつ CloseEmulatorDuringLongWait が有効である場合、エミュレータープロセス自体をシャットダウンしてリソースを解放します。

エラー発生時の復旧フロー

スケジューラーはエラーの発生を前提として設計されています。例外の種類に応じて段階的な自動復旧が行われます：

発生した例外	自動復旧アクション
ゲームが起動していない	ゲームクライアントを起動
ゲーム画面のフリーズ・無反応	ゲームを強制終了して再起動。連続失敗時はエミュレーター全体を再起動
画面が認識不能	まずサーバーメンテナンスを照会。正常稼働中ならゲーム再起動、メンテ中なら待機
エミュレーターがオフライン	エミュレーターの再起動を試行（リトライ間隔を徐々に拡大しながら継続）
スクリプトコードの例外（`ScriptError`）	連続3回発生した場合にプロセスを安全停止
センシティブタスクの失敗	直ちにインスタンスを停止し、エラー現場を保存して通知を送信

スケジューリングが完全に停止するのは以下の4つのケースのみです：

ScriptError が連続して3回発生した場合（コード不具合と判定）。
センシティブタスクでエラーが発生した場合。
ユーザーからの停止操作またはアップデート指示を受けた場合。
初期化段階で設定ファイルやデバイスの捕捉に失敗した場合。

センシティブタスク

Scheduler.Sensitive はデフォルトで以下のタスクで有効化されています：

OpsiCrossMonth（月またぎセイレーン作戦処理）
OpsiObscure（秘密海域）
OpsiAbyssal（深淵海域）

これらの局面で不用意にゲーム再起動を繰り返すと、海域報酬の消失や状態不整合が発生するリスクがあるため、「安全に停止して人間の介入を待つ」アプローチをとります。

同一タスクの連続再起動上限

Error.TaskRestartLimit（デフォルト 3）により、同一タスクにおける連続リカバリ回数が制限されています。上限に達した場合：

当該タスクの NextRun を翌日のサーバーリセット時刻までスキップ延期。
エラー通知をプッシュ送信。
キューにある他のタスクの処理を継続。

実行監視（ウォッチドッグ）

ストーリー演出のフリーズや探索ループなど、ログ出力が継続しているもののゲーム進行が停止している状態を検知するための監視機能です：

設定項目	デフォルト	役割
`Error.WatchdogEnable`	オフ	ウォッチドッグ機能の全体スイッチ
`Error.WatchdogTaskEnable`	オフ	タスク個別タイムアウト検知
`Error.WatchdogTaskTimeout`	120分	単一タスクの許容所要時間。超過時はエミュレーターを強制再起動

燃料（石油）の自動管理

General.OilControl.Enable を有効にすると、燃料が目標上限値を超過した際に自動的に燃料消費タスクが割り込み実行されます：

期限が来ている通常出撃を優先実行。
出撃可能な海域がない場合、寮舎での食料購入を実行。
燃料が目標値以下に落ち着いた時点で、本来のスケジュール順序に復帰。

スケジューラーとタスク編成

タスクを制御する主要フィールド ​

実行優先度の決定方法 ​

時間間隔とスケジュール ​

タスクのホarding（まとめ実行） ​

プリヒート（事前起動） ​

アイドル待機時の動作 ​

エラー発生時の復旧フロー ​

センシティブタスク ​

同一タスクの連続再起動上限 ​

実行監視（ウォッチドッグ） ​

燃料（石油）の自動管理 ​

次のステップ ​