Windows ERROR_SERVICE_NEVER_STARTED (1073) 解説：未起動サービスエラーの検出と再構築編

【注意】 この記事は「原因の切り分け」と「安全なダメージコントロール」を目的にした技術解説です。データや業務影響が絡む環境で、自己判断の修復・復旧作業（強制再起動の反復、サービス再登録の乱発、レジストリ改変、上書きインストール等）を先に進めると、証跡消失や障害拡大につながることがあります。状況が読めない場合は、株式会社情報工学研究所のような専門事業者へ相談してください（問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831）。

　

第1章：またサービスが「未起動」？――朝イチ障害対応が始まる瞬間

「アラートが鳴ってる。けど、昨日の夜は何もしてない。…なんで今？」

サービス障害のしんどさは、エラーそのものよりも“説明のコスト”にあります。現場はまず復旧の段取りを組みたいのに、周囲は「で、いつ直るの？」と聞いてくる。しかもWindowsサービスは、プロセス・権限・依存関係・レジストリ・ファイル配置など、構成物が多く、原因が一点に収束しないことが普通です。

ここで大事なのは、いきなり「直しに行く」のではなく、影響を抑え込みつつ、再現と証跡を確保し、最短で原因候補を潰していくことです。特に「未起動」「起動できない」と見えるときほど、再起動の連打や“とりあえず再インストール”に走りがちですが、これが後で効いてきます。

症状 → 取るべき行動（先に結論だけ）

症状（見えている事象）	まずやる行動（安全な初動）	やらない判断（避けたい行動）
サービスが停止/未起動に見える	イベントログ採取、sc.exeで状態/構成確認、依存関係の洗い出し	再起動を繰り返す、手当たり次第に再登録/削除
起動しようとして失敗（タイムアウト/起動保留）	起動ログ/ExitCode確認、実行ファイル/ServiceDLLの存在確認、権限確認	バイナリ差し替え、レジストリの手修正を先に進める
依存サービスも連鎖停止	依存関係グラフ化、最下流（根本原因）のサービスを特定	上流だけ再起動して「直ったことにする」
構成変更直後/パッチ適用直後に発生	変更履歴の確定、構成差分の抽出、ロールバック可否の判断	原因不明のまま追加の変更を重ねる

---

「未起動」には2種類ある：状態の未起動と、試行されていない未起動

現場で混乱しやすいのが、「未起動」という日本語が同じでも、中身が違うケースがあることです。

• 状態として停止している：起動要求はされたが落ちた、停止指示で止まっている、依存停止で止まっている、など。
• そもそも起動が試行されていない：手動起動のまま誰も触っていない、トリガが来ていない、ブート後一度も起動要求が来ていない、など。

後者は「異常」ではなく「まだ出番が来ていない」だけのこともあります。この見極めができると、余計な復旧作業をしなくて済みます。

今すぐ相談すべき条件（依頼判断の目安）

• 業務影響（売上/決済/医療/物流/顧客対応）が発生していて、復旧のタイムリミットがある
• サービスの構成変更や再登録が必要そうだが、証跡や原因が固まっていない
• 関連ログが分散しており、現場での切り分けが“人依存”になっている
• データや監査対応（ログ保全、説明責任、復旧手順の記録）が必要

このあたりに当てはまる場合、一般論だけで押し切ると復旧が遠回りになりやすいので、早めに専門家の視点を入れるのが結果的に早いです。株式会社情報工学研究所への無料相談は、問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831 から可能です。

　

第2章：ERROR_SERVICE_NEVER_STARTED (1073) の正体――SCMが言っている“未起動”を翻訳する

まず、事実として押さえるべき点があります。Windowsのシステムエラーコード定義（WinError.h）では、1073 は「既にサービスが存在する」という意味で、「一度も開始が試行されていない」という意味の ERROR_SERVICE_NEVER_STARTED は 1077 として定義されています。つまり「(1073)」と「NEVER_STARTED」というラベルは、現場の二次情報やログ表示の都合で混ざっている可能性があります。

「え、じゃあ何を見ればいいの？」となりますよね。ここでポイントは、“数字だけ”に反応しないことです。何の操作（API/コマンド/監視ツール）が、どの文脈でそのコードを返したのかを確認します。サービス周りは同じ数字が、別の画面では別の説明文で出ることもあります。

このエラーが出る典型シーンを分解する

未起動系の文脈でよく出会うのは、だいたい次の3パターンです。

見えているメッセージ	起点（どの操作か）	意味（翻訳）
サービスが開始されていない/開始試行なし	監視/PowerShellで Win32ExitCode を参照	ブート後に起動要求が来ていない（異常とは限らない）
サービス作成に失敗（既に存在）	sc create / CreateService	同名サービスが残っている（削除済み扱い/削除待ち含む）
開始/停止制御で失敗	sc start/stop / StartService/ControlService	状態が前提と合っていない（停止しているのに制御、依存が止まっている等）

---

SCM（Service Control Manager）が管理しているのは「状態」だけではない

サービスは「起動しているかどうか」だけでなく、以下の構成物の集合です。

• サービス名/表示名、スタート種別（自動/手動/無効/遅延/トリガ）
• 実行パス（ImagePath）または ServiceDLL（svchost系）
• 依存関係（DependOnService / DependOnGroup）
• 実行アカウント（Log On As）とその権限
• 回復設定（障害時に再起動するか、コマンドを叩くか）
• セキュリティ記述子（SDDL）とレジストリ/ファイルACL

未起動に見える現象の多くは、プロセスの問題というより、この「構成物のどこか」が壊れていることが原因です。だからこそ、復旧は「再起動」ではなく「再構築」が必要になることがあります。

確認の入口：まずは“構成”を文字に起こす

最初にやるべきは、現状を文章化できる形に落とすことです。代表的には次のコマンドを、管理者権限で実行して記録します。

sc queryex "サービス名" sc qc "サービス名" sc enumdepend "サービス名"

ここで取れる情報（状態、PID、スタート種別、依存、バイナリパスなど）は、後の切り分けの軸になります。現場でありがちな失敗は、直す前にこの記録を取らず、後から「何が変わったか」が分からなくなることです。

　

第3章：最初の切り分け――手動/自動/遅延/トリガ起動で見え方が変わる

「サービスが未起動です」と言われたとき、まず頭の中で確認したいのが、そのサービスは“どう起動する設計”なのかです。ここがズレると、正しい状態を異常だと誤判定し、無駄な復旧作業が増えます。

StartTypeの差は“運用の前提”の差

Windowsサービスの起動方式は、運用の前提そのものです。代表パターンを整理します。

方式	現場での見え方	注意点
自動（Automatic）	起動していて当然。止まっていれば異常扱いされやすい。	ブート直後の依存未完了で失敗することがある（遅延の検討余地）。
自動（遅延開始）	ブート直後は止まって見える時間がある。	監視が“ブート直後”をどう扱うかで誤検知が起きる。
手動（Manual）	普段は止まっていても正常。必要時にだけ起動される。	「未起動」を異常と決めつけない。トリガや利用条件を確認。
無効（Disabled）	起動しないのが仕様。開始要求は失敗する。	“誰が無効化したか”が重要（意図/ポリシー/セキュリティ）。

---

トリガ起動（Trigger Start）という“待ち”の設計

最近のWindowsは、イベント駆動でサービスを起動する設計が普通にあります。ネットワーク接続、デバイス接続、特定のイベントなどがトリガになり、平常時は止まっている。これを知らないと「未起動＝故障」と早合点しがちです。

「じゃあ、いつ起動するはずなの？」を確認するには、運用設計書やアプリ側の仕様、タスクスケジューラ、依存サービス、そしてイベントログを合わせて見ます。ここで“仕様の確認”ができないと、復旧作業がブレます。

心の会話：監視ツールの赤が怖い

「監視が赤いと、何かしないと落ち着かない。とりあえず再起動…ってやりがちなんですよね。」

その感覚は自然です。ただ、サービスの起動方式が手動やトリガ前提なら、赤の意味は“停止”ではなく“設計との差分”に変わります。ここは監視側の閾値（ブート後猶予、手動サービス除外、トリガサービスの扱い）を見直す余地があります。運用の歯止めを設計で作る、という発想です。

最初の5分でやるチェック（短い順）

1. そのサービスの StartType（自動/遅延/手動/無効）を確定する（sc qc / サービス管理画面）。
2. 依存関係を見て、上流が止まっていないかを確認する（sc enumdepend / 依存タブ）。
3. イベントログで、同時刻に出ている 7000系・7023・7036 を拾う。
4. 実行ファイル/ServiceDLL が存在し、権限で弾かれていないか（パス/ACL）を確認する。
5. 実行アカウント（Log On As）の変更履歴やポリシー適用（GPO）を疑う。

ここまでで「仕様なのか」「異常なのか」の境界が見えます。境界が見えた時点で、次はログで原因を絞り込みます。

　

第4章：イベントログが答えを持っている――7000/7001/7023/7036の読み解き方

Windowsサービスの切り分けで強い味方になるのがイベントログです。ここを飛ばして“勘”で触り始めると、だいたい遠回りになります。

まず見る場所：Systemログ（Service Control Manager）

多くのサービス関連イベントは、Windowsログ > システム（System）に出ます。ソースが「Service Control Manager」になっているものを中心に、障害が起きた時刻周辺を拾います。

イベントID	典型的な意味	次の一手
7000	サービス開始失敗（理由は本文に出る：パス不正、アクセス拒否、ログオン失敗など）	本文のエラー文を一次情報として確保し、構成（ImagePath/権限/アカウント）へ分岐
7001	依存サービスが起動せず、対象も起動できない	依存の連鎖を辿り、根本原因のサービスへ降りていく
7023	サービスがエラーを返して終了（ExitCodeがヒント）	ExitCodeを記録し、アプリ/ドライバ/依存モジュールの問題へ分岐
7036	サービス状態変化の通知（開始/停止/一時停止など）	時系列の骨格として使い、直前の7000系と突き合わせる

---

ログが“薄い”ときの現実：監視は状態を見ているだけ

「イベントログに決定打がない」こともあります。特に“起動が試行されていない”場合、異常イベントが出ないことは普通です。このときは、監視が見ている指標（状態、応答、ポート、プロセス）と、サービスの設計（起動条件、トリガ、依存）を突き合わせます。

また、サービスがアプリケーションログや独自ログに原因を書いているケースもあります。Systemログだけで完結しない前提で、ログの所在を把握します。

PowerShellでログとサービス情報を“並べて見る”

現場で便利なのは、「サービスの状態」と「直近の関連イベント」を同じ目線で並べることです。例えば次のように、対象サービス名で絞って時刻順に見ます（環境に合わせて調整してください）。

# サービスの構成と状態 Get-Service -Name "サービス名" | Select-Object Name, Status, StartType
Systemログから SCM 関連の直近イベント（例：過去1日）
Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddDays(-1)} |
Where-Object { $_.Message -match 'サービス名' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Sort-Object TimeCreated

ここで大事なのは、取得したログや出力を“そのまま保全できる形”で残すことです。復旧後に「何が原因だったか」を説明できるかどうかは、次の改善（監視閾値、構成管理、運用ルール）に直結します。

この章のまとめ：イベントログは“犯人探し”ではなく“分岐条件”

イベントログの役割は、原因を一撃で当てることではなく、次にどこを見ればいいかの分岐を作ることです。7000系でパス/権限/依存へ、7023でExitCodeとアプリ側へ、7036で時系列へ。これができると、復旧が「運」から「手順」に変わります。

　

第5章：依存関係とログオンアカウント――「起動できない」を生む典型パターン

サービスが起動しないとき、最初に疑うべきは「そのサービス自身」ではなく、依存関係と実行アカウントです。ここが崩れると、エラーは表面上バラバラに見えますが、根っこは同じことが多いからです。

依存関係の連鎖は“下流の悲鳴”として現れる

イベントID 7001（依存サービスが起動しないため開始できない）は、上流のサービスが悪いというより、「依存先が起動できない」か「依存の定義がズレている」可能性を示します。ここでよく起きるのが、次のような連鎖です。

• ネットワーク関連（DNS Client / DHCP Client / NLA など）が不安定 → アプリ側サービスの起動が遅延・失敗
• RPC（Remote Procedure Call）系の基盤が不調 → 多数のサービスが芋づる式に開始不能
• 依存先のスタート種別が無効化されている → 下流が一斉に未起動に見える

つまり、アプリサービスを再起動しても、依存先が直らない限り状況は収束しません。ここでは「依存グラフの底」へ降りるのが最短ルートです。

依存関係の確認（構成の一次情報）

依存はGUIでも見られますが、記録に残る形で確認できることが重要です。代表的には以下を採取します。

sc qc "サービス名" sc enumdepend "サービス名"

PowerShellなら、依存している側・されている側の両方向を整理できます。

# このサービスが依存しているサービス (Get-Service -Name "サービス名").ServicesDependedOn | Select-Object Name, Status, StartType
このサービスに依存しているサービス（影響範囲を把握）
(Get-Service -Name "サービス名").DependentServices | Select-Object Name, Status, StartType

---

ログオンアカウントは「動く/動かない」を決める設計要素

サービスの実行アカウント（Log On As）は、単なる資格情報ではありません。そのサービスが触れる範囲（ファイル、レジストリ、ネットワーク、証明書、キーストア）を決める境界です。ここがズレると、起動自体は成功しても初期化で落ちる、起動前に弾かれる、という現象になります。

典型的な症状は、イベントID 7000 のメッセージに「ログオンの失敗」「アクセスが拒否されました」等が出たり、7023 で特定のExitCodeが付くパターンです。

よくある“アカウント起因”の原因

原因	起きること	現実的な対処の方向
パスワード変更/失効（ドメイン/ローカル）	サービスログオン失敗で開始できない	資格情報の再設定、運用上はgMSA等の利用検討
「サービスとしてログオン」権限（SeServiceLogonRight）がない	開始時点で拒否される	ローカルセキュリティポリシー/GPOの確認と付与
必要なリソース権限不足（ファイル/証明書/レジストリ）	起動後すぐ落ちる、初期化が完了しない	最小権限でのACL設計、実行ユーザーの棚卸し

心の会話：アカウント変更は“簡単そうで怖い”

「ローカルシステムに戻せば動くんじゃ…って誘惑、ありますよね。でも後で戻せなくなるやつだ、って分かってる。」

その警戒は正しいです。アカウントを強権限に寄せるのは短期的な鎮火にはなりますが、監査・侵害時の被害最小化・運用の説明責任の面で、後から効いてきます。現場では、まず一次情報（どの権限が足りないか）をログで確定し、必要な権限だけを足す方向が安全です。

この章のまとめ：依存とアカウントは“設計の前提”

未起動や開始失敗は、アプリの不具合というより「サービスを支える前提（依存とアカウント）が崩れている」ことで起きやすいです。ここを先に整えると、次の章で扱う“構成物（ImagePath/ServiceDLL）”の確認もスムーズになります。

　

第6章：ImagePathとServiceDLL――レジストリ整合性チェックで“実体”を特定する

サービスの復旧で事故が起きやすいのは、実体（どのバイナリが動くのか）が曖昧なまま触ることです。Windowsサービスは、見た目が同じ「サービス」でも、実体は大きく2系統に分かれます。

• 独立プロセス型：ImagePath に実行ファイルが指定され、そのEXEが起動する。
• 共有ホスト型（svchost等）：ImagePath は svchost を指し、実体は ServiceDLL 等の設定にぶら下がる。

ここを取り違えると、「ファイルは存在するのに動かない」「再登録したのに変化しない」といったノイズが増えます。

一次情報の場所：Servicesキー

サービスの構成は、レジストリの以下に集約されます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<サービス名>

ここにある代表的な値は、切り分けの軸になります。

値	意味	壊れると起きること
ImagePath	起動するバイナリ/コマンドライン	パス誤り/引用符不整合/引数崩れで開始失敗
ObjectName	実行アカウント（LocalSystem 等）	権限不足/ログオン失敗の原因に
Start	起動種別（自動/手動/無効 等）	監視誤検知や“起動されない”の根拠に
DependOnService	依存サービス	連鎖起動失敗（7001）につながる

---

ImagePathで多い落とし穴：引用符と実体ファイル

ImagePath はコマンドラインとして解釈されるため、スペースを含むパスの扱いでミスが起きやすいです。たとえば、引用符が欠けたままスペースを含むと、別の実行ファイルとして解釈されることがあります。結果として「ファイルが見つからない」「起動できない」になります。

確認の基本は、次の2点です。

• ImagePath に記載の実体ファイルが存在する（移動/削除/隔離されていない）
• パスの引用符と引数が意図通り（スペース、エスケープ、環境変数展開）

コマンドとしての見え方は、sc qc の BINARY_PATH_NAME が分かりやすい入口です。

sc qc "サービス名"

共有ホスト型（svchost）の場合：ServiceDLLとグループ

svchost系は、ImagePath が svchost.exe を指していても、それだけでは実体が分かりません。サービス名配下の Parameters に ServiceDLL がある、もしくは別の関連キーに紐づくケースがあります。

典型的には以下を確認します（環境により差があります）。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<サービス名>\Parameters ServiceDLL (REG_EXPAND_SZ など)

ServiceDLL のファイルが欠落していたり、更新で差し替わったDLLが署名要件や依存DLL不足でロードできないと、起動直後に落ちる・開始できないといった症状になります。

---

“実体の特定”を安全にやる順番

1. sc qc で BINARY_PATH_NAME を記録する（まず文字に残す）
2. サービスのレジストリキーで ImagePath / ObjectName / DependOnService を確認する
3. svchost系なら Parameters の ServiceDLL を確認し、ファイル存在とACLを確認する
4. 変更が疑われる場合は、変更履歴（パッチ、EDR隔離、運用作業）を突き合わせる

ここまでで「どのファイルが動くはずか」が確定すると、次の章の“権限で弾かれる”問題が見えやすくなります。

　

第7章：権限で詰む瞬間――ACL/SDDL・UAC・署名要件が起動を止める

サービス障害の中で、現場を一番消耗させるのが「アクセス拒否」です。原因の候補が広く、しかも“直したつもり”が再現しないことがある。ここで重要なのは、権限のレイヤが複数あることを整理し、どのレイヤで拒否されているかを特定してから手を入れることです。

権限は最低でも3レイヤある

• サービス制御権限（SDDL）：誰が開始/停止/変更できるか（サービス自体のアクセス制御）。
• 実体ファイル/フォルダのACL：EXE/DLLや設定ファイルを読める/実行できるか。
• レジストリACL：ServicesキーやParametersを読める/更新できるか。

さらに環境によっては、アプリ制御（AppLocker/WDAC等）、EDRのブロック、ドライバ署名要件などが追加されます。つまり「アクセス拒否」は一言では片付かず、どこが拒否したのかが本体です。

サービス制御（SDDL）の問題：開始できない/変更できない

サービスの開始・停止・構成変更は、サービスに設定されたセキュリティ記述子に従います。運用でよくあるのは、権限を絞った結果、必要なオペレーションができなくなるケースです。

症状としては、管理ツールやsc.exeで操作したときに「アクセスが拒否されました」となります。ここでは、サービスの制御権限と、実行しているユーザー（ローカル管理者か、UACで昇格しているか）が噛み合っているかを確認します。

---

ファイルACLの問題：実体が読めない/実行できない

ImagePathやServiceDLLが正しくても、実体ファイルにアクセスできなければ起動できません。特に“サービス用アカウント”で動かす設計の場合、対話ログオンでは通っても、サービス起動では落ちる、という現象が起きます。

よくある原因	見え方	切り分けの軸
EXE/DLLのアクセス権不足	開始直後に失敗、7000や7023が出ることがある	実行アカウントでの読み取り/実行権、継承の崩れ
設定ファイル/ログ出力先の書き込み権限不足	起動はするが初期化で落ちる、起動ループ	起動後に開くパス（config/log/temp）の権限
EDR/保護機能で隔離・ブロック	ファイルが存在するはずなのに見つからない/読めない	隔離ログ/検知履歴、パスの差し替え有無

UACの落とし穴：管理者でも“昇格していない”

ローカル管理者グループでも、UACによりトークンが分離され、昇格していない状態では操作が失敗することがあります。GUI操作では分かりにくく、コマンドを管理者として実行していなかっただけ、というケースも現場では起きます。

ただし、これは「昇格すれば終わり」という話ではありません。運用として、誰がどの権限でどの操作をできるかを決めておかないと、夜間対応が属人化します。ここは“場を整える”意味で、権限設計と手順化が効きます。

---

署名要件やアプリ制御：動かない理由がOS側にある

環境によっては、コード署名やアプリ実行制御が起動を止めることがあります。特にカーネルドライバ系（ドライバサービス）では署名要件が強く関係しますし、ユーザーモードでもWDAC（Windows Defender Application Control）やAppLockerのポリシーでブロックされることがあります。

この場合、サービス構成を触っても症状は収束しません。ポリシー側のログや、セキュリティ製品のイベントを確認し、拒否の根拠を一次情報として確保するのが先です。

この章のまとめ：権限は“どこで拒否されたか”を特定してから触る

権限問題は、手当たり次第に権限を広げると短期的には動いても、後で被害最小化や監査の観点でしわ寄せが来ます。サービス制御（SDDL）・ファイルACL・レジストリACL・ポリシー/EDRのどこが拒否したのかを特定し、必要な最小範囲で穴埋めする。これが運用の歯止めになります。

　

第8章：修復の実践――sc.exe / PowerShellで再登録・再構築・回復アクションを整える

ここまでで「依存」「実行アカウント」「実体（ImagePath/ServiceDLL）」「権限」のどこに論点があるかが見えてきます。第8章は、実際に手を動かす章です。ただし、作業の順番を間違えると、原因の特定が遠のいたり、後から説明できなくなったりします。目的は“とにかく動かす”ではなく、再現できる形で収束させ、次に同じ事故が起きない状態へ持っていくことです。

最初にやること：現状の構成をバックアップとして確保する

サービス構成の一次情報は、後で「何を変えたか」を示す根拠になります。作業前に最低限これを確保します。

• sc qc / sc queryex の出力（テキスト保存）
• 対象サービスのレジストリキー（Services配下）のエクスポート
• イベントログ（Systemの該当時刻周辺）の保存

レジストリのエクスポートは、GUIでもできますが、コマンドで残すと手戻りが少ないです。

reg export "HKLM\SYSTEM\CurrentControlSet\Services\サービス名" ".\サービス名.reg" /y

---

基本コマンド：状態確認と構成確認

現場で最も使うのは、次の3つです。これだけで「状態」「PID」「バイナリパス」「依存」「アカウント」の骨格が取れます。

sc queryex "サービス名" sc qc "サービス名" sc enumdepend "サービス名"

特に sc qc の BINARY_PATH_NAME は、ImagePath相当を確認する入口になり、引用符や引数の崩れに気づきやすいです。

起動できないときの“安全な分岐”

起動に失敗している場合、やることは大きく分けて4つです。

1. 依存サービスを起点に、根本原因を潰す
2. 実行アカウントと権限（SeServiceLogonRight/ACL）を整える
3. ImagePath / ServiceDLL の整合性（存在・パス・依存モジュール）を正す
4. 回復アクション（再起動/再実行/リセット）を“運用前提”に合わせて整備する

この順番は、途中で入れ替えると遠回りになりがちです。例えば「回復アクションを強くする」前に、依存やアカウントが壊れていると、失敗のループが増えるだけになります。

---

再登録・再構築の境界：sc delete は最後の手段にする

サービスの再構築を考えると、つい「削除して作り直す」に行きたくなります。しかし、sc delete は状態を消すだけでなく、復旧のための手がかり（元の構成）も一緒に削ってしまうことがあります。削除を考える前に、次の確認を挟むのが現実的です。

• 本当に同名サービスが“二重登録”になっていないか（監視/GUIの表示違い）
• 削除待ち状態（プロセスが掴んでいて消えない）ではないか
• レジストリのServices配下に残骸が残っていないか

どうしても作り直しが必要な場合は、先に reg export で構成の退避を行い、作業ログ（実行したコマンドと結果）を残します。

sc create / sc config の基本パターン

サービスの再作成・再設定は、次のように行います（環境に合わせて値を設定します）。

sc create "サービス名" binPath= "C:\Path\app.exe --arg1 --arg2" start= auto obj= "LocalSystem" sc config "サービス名" start= delayed-auto sc config "サービス名" obj= ".\svcuser" password= "********"

ここで重要なのは、sc.exe のパラメータは 「キー=値」形式で、キーの後ろにスペースが必要という点です。実務ではここを誤って「設定したつもり」になりやすいので、sc qc で必ず反映結果を確認します。

---

回復アクションを“現場の負担が減る形”にする

サービスが落ちたとき、何をもって正常復帰とするかは運用設計です。回復アクションは、短期的な収束（自動再起動）には効きますが、依存や権限が壊れている状態だと失敗を繰り返します。だからこそ、原因の切り分けとセットで整備します。

sc.exe では回復設定を次のように行います（例）。

sc failure "サービス名" reset= 86400 actions= restart/60000/restart/60000/""/0 sc failureflag "サービス名" 1

「何回再起動したら、どの時点で通知・エスカレーションするか」を決めておくと、夜間対応の心理的負担が減ります。再起動の無限ループは“沈静化”ではなく、障害を長引かせることがあるためです。

PowerShellでの状態確認と監視連携

PowerShellは、状態確認と“記録”に強いです。例えば、サービスの状態・スタート種別・依存を一覧し、ログと合わせて保存します。

$name = "サービス名" Get-Service -Name $name | Select-Object Name, DisplayName, Status, StartType | Format-List (Get-Service -Name $name).ServicesDependedOn | Select-Object Name, Status, StartType (Get-Service -Name $name).DependentServices | Select-Object Name, Status, StartType

さらに、Systemログから該当サービス名を含むSCMイベントを抜き出して、時系列で保存します。

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddDays(-3)} | Where-Object { $_.Message -match "サービス名" } | Select-Object TimeCreated, Id, LevelDisplayName, Message | Sort-Object TimeCreated | Out-File ".\scm_サービス名.log" -Encoding UTF8

---

この章のまとめ：修復とは“変更”ではなく“再現可能な再構築”

サービスの復旧は、単に開始できるようにする作業ではありません。構成の一次情報を残し、原因を潰し、回復アクションを運用に合わせ、次に同じ状況でも手順で収束できる形に整えることが本質です。ここまで整うと、次章の再発防止（構成管理と監視）に繋がります。

　

第9章：再発防止――構成管理と監視で「未起動」を先回りして潰す

サービスの未起動や開始失敗は、単発の事故に見えても、根っこは「構成のドリフト（意図しない変化）」で起きることが多いです。つまり、直すべきはサービスそのものより、変化を管理する仕組みです。現場のしんどさを減らすには、再発防止を“根性論”ではなく“仕組み”でやる必要があります。

再発の芽はだいたいここにある

• パスワード変更や資格情報の失効（サービスアカウント）
• Windows Updateやアプリ更新でのファイル差し替え（依存DLLの変化含む）
• EDR/セキュリティポリシーの更新でのブロック（署名・実行制御）
• GPOでの権限設定変更（SeServiceLogonRight、ローカル権限、ACL）
• 運用作業の属人化（手で直す → 次の変更で再び壊れる）

これらは、個別のサービスに閉じた問題ではなく、運用全体の問題です。だからこそ、一般論の「再起動」「再インストール」だけでは解決しません。

---

構成ドリフトを検知する：サービス設定の定期監査

まず現実的なのは、重要サービスについて「あるべき構成」をテキスト化し、定期的に差分を取ることです。例として、以下の項目はドリフトしやすく、障害に直結します。

• StartType（自動/遅延/手動/無効）
• BINARY_PATH_NAME（ImagePath相当）
• 実行アカウント（ObjectName）
• 依存関係（DependOnService）
• 回復アクション（failure actions）

PowerShellで定期的に抽出し、前回との差分を監視に載せると、「未起動」になる前に異常を見つけられます。

監視の設計：状態だけで赤にしない

未起動や停止を監視するとき、状態だけを見ると誤検知が増えます。特にトリガ起動や手動サービスでは、「止まっている」が正常であることがあるためです。そこで、監視は次のように“意味”で設計します。

監視したいこと	状態監視だけの弱点	現実的な補強
自動サービスが落ちた	再起動で一瞬戻ると見逃す	SCMイベント（7000/7023等）の収集と相関
依存が原因で起動できない	下流だけ赤くなり、原因が見えない	依存グラフと根本原因サービスの監視
手動/トリガサービスが未起動	仕様なのに赤くなる	「起動されるべきタイミング」を条件化（イベント/ジョブ/利用状況）

---

資格情報の事故を減らす：サービスアカウント運用の見直し

サービスのログオン失敗は、単純に「パスワードが変わった」だけでも発生します。ここで重要なのは、運用の設計として「資格情報の更新」を事故らせないことです。手作業での更新が多いほど、ミスが増え、復旧が遅れます。

現場では、アカウントの棚卸し（どのサービスがどのアカウントで動いているか）をまず行い、更新手順を統一します。環境によっては、グループ管理サービスアカウント（gMSA）の採用や、秘密情報管理（Vault等）との連携が検討対象になります。

心の会話：運用改善は後回しになりがち

「障害対応で疲れ切った後に“再発防止をやろう”って言われると、正直きつい。でも次も同じ夜を迎えるのはもっと嫌。」

この感覚は現場のリアルです。だから、再発防止は“気合い”ではなく、小さく始めて積み上げるのが現実的です。例えば「重要サービスだけ構成を毎日ダンプして差分を取る」「SCMイベントを中央集約して根本原因を追えるようにする」だけでも、次の障害の鎮火が早くなります。

この章のまとめ：未起動は“現象”、原因は“変化の管理”にある

未起動・開始失敗を減らすには、サービスを強くするより先に、構成管理・監視設計・資格情報運用を整えるのが近道です。ここまで整備できると、「直せる」だけでなく、「説明できる」「再現できる」状態になり、組織としての耐久力が上がります。

　

第10章：帰結――サービスは“状態”ではなく“構成物”、だから再構築できる設計にする

最後に、今回のテーマを一本の線で回収します。サービスが未起動に見えるとき、目に入るのは「Stopped」「Not started」「開始できません」などの状態情報です。しかし、障害の本体は状態ではなく、サービスを成立させている構成物のどこかが崩れたことです。

依存が崩れていれば起動できない。アカウントが崩れていればログオンできない。実体（ImagePath/ServiceDLL）が崩れていればロードできない。権限が崩れていれば拒否される。これらはどれも、再起動の回数では解決しません。だから「未起動」を見た瞬間にやるべきことは、反射的な再起動ではなく、構成物を特定し、順序立てて整えることです。

“再構築できる設計”とは何か

再構築できるとは、誰が担当しても同じ手順で同じ結果に到達できる、という意味です。具体的には次の3点が揃っている状態です。

• 一次情報が残る：sc qc / reg export / イベントログが保存され、原因の説明ができる
• 構成が再現できる：サービス定義（起動方式、依存、アカウント、回復設定）がテキスト化されている
• 運用の歯止めがある：変更は手順化され、監視は“意味”で赤くなるように設計されている

この3点があると、障害対応は「その場の技量」に依存しにくくなり、被害最小化が現実になります。

---

一般論の限界：現場は“環境差分”で詰まる

ここまでの内容は、Windowsサービス障害の典型パターンに沿った手順です。ただし、実際の現場では「環境差分」が強く効きます。例えば、同じサービスでも、次の違いで対処が変わります。

• ドメイン参加の有無、GPOの適用範囲
• EDR/実行制御（WDAC/AppLocker等）の有無と設定
• アプリの実装方式（独立EXEか、svchost配下か、ドライバか）
• ログの出方（System/アプリ独自ログ/ETWなど）
• 復旧優先度（停止できない、冗長化がある、監査が必要）

つまり、一般論だけで押し切ると、「動いたけど理由が分からない」「次の更新でまた壊れる」「説明責任に耐えない」という形で、後から火種が残ります。

終盤の判断：迷ったら“変化を増やさない”が安全

障害対応では、手を動かすほど状況が変わります。原因が確定しないまま変更を重ねると、後で「どの変更が効いたのか」が分からなくなります。だから、迷ったときは“変更を増やさない”ほうが、結果的に収束が早いことが多いです。

具体的には、一次情報の確保（構成・ログ・時系列）を固め、影響範囲と優先順位を整理し、必要な変更だけを小さく入れて検証します。ここで判断が難しい案件（業務影響が大きい、監査が絡む、セキュリティ製品が関与する、サービスが多段依存している等）では、株式会社情報工学研究所のような専門家に相談して、切り分けと復旧を並行で進めるほうが現実的です。問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831。

この章のまとめ：未起動は“直す”より“再構築できる”に寄せる

サービス障害を、単発のトラブル対応で終わらせないためには、状態の復旧だけでなく、構成の再現性・運用の歯止め・説明責任まで含めて整える必要があります。そうすることで、次の障害は「慌てるもの」から「手順で収束させるもの」に変わります。

　

付録：主要プログラミング言語でWindowsサービスを扱うときの注意点

Windowsサービスは、言語よりも「SCMとの契約（起動・停止・状態通知・ログ・権限・更新）」が本体です。言語ごとに落とし穴が違うため、実装・運用・配布の観点で注意点を整理します。

サービス実装で共通して重要なこと

• 起動直後にSCMへ状態を返す：初期化が長い場合は段階的に状態更新し、タイムアウトに注意する
• 停止要求を正しく処理する：強制終了に頼らず、データ整合性を保てる停止手順を実装する
• ログを運用が拾える形にする：Event Log、ファイルログ、ETWなど、所在と粒度を設計する
• 権限を最小化する：必要なファイル/レジストリ/ネットワーク権限を明確化し、ACLで穴埋めする
• 更新・ロールバックを設計に含める：バイナリ差し替え時の失敗を前提に、復旧手順を持つ

---

言語別の注意点（実装・配布・運用）

言語/実装系	よくある落とし穴	現実的な対策
C / C++（Win32 API）	ServiceMain/Handlerの実装ミスで停止要求を無視、初期化が長くタイムアウト、Unicode/権限/例外処理の不備で7023になりやすい	状態通知（SERVICE_START_PENDING等）を段階的に行う、例外/エラーコードをログに残す、依存DLLの配置と署名要件を管理する
C# / .NET（ServiceBase / Worker Service）	.NETランタイム/Hostingの前提差分、ログ出力先が散らばる、サービス停止時にバックグラウンド処理が残る	長い初期化は段階化、停止トークンで確実に終了、Event Logやファイルログの所在を統一、配布方式（self-contained等）を設計で確定
Java（Windowsサービス化：ラッパ/プロセスマネージャ）	JRE/JDKの更新で挙動が変わる、サービスとしての停止が乱暴になりがち、パスや環境変数依存で起動失敗	サービスラッパの標準化、JRE同梱/固定、停止手順（graceful shutdown）を明示、環境変数依存を削減してImagePathを安定化
Go（Windows Service対応）	単一バイナリで楽だが、ログ設計が薄いと切り分けが難しい、サービス制御ハンドラの実装が雑だと停止要求に弱い	Event Log/ファイルログを設計で必須化、停止要求の処理（context cancel等）を徹底、依存（証明書/設定ファイル）の配置と権限を明確化
Rust（Windows Service対応）	安全性は高いが、運用ログが弱いと原因が追えない、依存DLL/暗号ライブラリ周りの差分で起動時に落ちる	ログの所在と粒度を決める、起動失敗時のエラーを確実に記録、署名や暗号基盤（証明書ストア）の前提を文書化
Python（pywin32等）	実行環境（Python本体/ライブラリ）に依存しやすい、パス/仮想環境の差分で起動できない、更新で急に壊れる	配布形態（同梱/固定）を決める、依存の凍結（requirements固定）と更新手順を整備、ログと例外の記録を必須化
JavaScript / Node.js（サービス化ツール利用）	Node本体更新で挙動が変わる、npm依存が多く再現性が落ちる、ログが標準出力だけだと追えない	Nodeバージョン固定、依存ロックと配布の再現性確保、ログをEvent Logやファイルへ、サービス停止処理を実装で保証
PowerShell（サービスではなく運用スクリプト/ジョブ）	サービスとして常駐させると管理が難しい、権限と実行ポリシー差分で失敗、ログが残らないと追えない	常駐が必要ならサービス化より専用実装を検討、タスクスケジューラ等に寄せる、ログ（Transcript/イベント）を前提に運用設計
バッチ / Bash（補助用途）	エラー処理が曖昧だと回復アクションと噛み合わない、環境変数やカレントディレクトリ依存で壊れる	補助に徹し、成功/失敗を明確に終了コードで返す、絶対パスで実行し、実行アカウント権限を明文化

---

案件ごとに変わる論点：ここが“相談ポイント”になりやすい

• サービスアカウント設計（最小権限、GPO、資格情報更新、監査対応）
• セキュリティ製品・実行制御との整合（署名、WDAC/AppLocker、隔離時の復旧手順）
• 更新とロールバックの仕組み（停止できない環境での展開方式、手順と証跡）
• ログの設計と保全（説明責任、障害解析、再発防止のための一次情報）

これらは一般論だけで決めると、現場の制約（止められない、監査がある、構成が複雑）で詰まりやすい領域です。具体的な案件・契約・システム構成に踏み込んだ判断が必要なときは、株式会社情報工学研究所への相談・依頼を検討すると、切り分けと収束が早くなります。問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831。

　

第8章：修復の実践――sc.exe / PowerShellで再登録・再構築・回復アクションを整える

ここまでで「依存」「実行アカウント」「実体（ImagePath/ServiceDLL）」「権限」のどこに論点があるかが見えてきます。第8章は、実際に手を動かす章です。ただし、作業の順番を間違えると、原因の特定が遠のいたり、後から説明できなくなったりします。目的は“とにかく動かす”ではなく、再現できる形で収束させ、次に同じ事故が起きない状態へ持っていくことです。

最初にやること：現状の構成をバックアップとして確保する

サービス構成の一次情報は、後で「何を変えたか」を示す根拠になります。作業前に最低限これを確保します。

• sc qc / sc queryex の出力（テキスト保存）
• 対象サービスのレジストリキー（Services配下）のエクスポート
• イベントログ（Systemの該当時刻周辺）の保存

レジストリのエクスポートは、GUIでもできますが、コマンドで残すと手戻りが少ないです。

reg export "HKLM\SYSTEM\CurrentControlSet\Services\サービス名" ".\サービス名.reg" /y

---

基本コマンド：状態確認と構成確認

現場で最も使うのは、次の3つです。これだけで「状態」「PID」「バイナリパス」「依存」「アカウント」の骨格が取れます。

sc queryex "サービス名" sc qc "サービス名" sc enumdepend "サービス名"

特に sc qc の BINARY_PATH_NAME は、ImagePath相当を確認する入口になり、引用符や引数の崩れに気づきやすいです。

起動できないときの“安全な分岐”

起動に失敗している場合、やることは大きく分けて4つです。

1. 依存サービスを起点に、根本原因を潰す
2. 実行アカウントと権限（SeServiceLogonRight/ACL）を整える
3. ImagePath / ServiceDLL の整合性（存在・パス・依存モジュール）を正す
4. 回復アクション（再起動/再実行/リセット）を“運用前提”に合わせて整備する

この順番は、途中で入れ替えると遠回りになりがちです。例えば「回復アクションを強くする」前に、依存やアカウントが壊れていると、失敗のループが増えるだけになります。

---

再登録・再構築の境界：sc delete は最後の手段にする

サービスの再構築を考えると、つい「削除して作り直す」に行きたくなります。しかし、sc delete は状態を消すだけでなく、復旧のための手がかり（元の構成）も一緒に削ってしまうことがあります。削除を考える前に、次の確認を挟むのが現実的です。

• 本当に同名サービスが“二重登録”になっていないか（監視/GUIの表示違い）
• 削除待ち状態（プロセスが掴んでいて消えない）ではないか
• レジストリのServices配下に残骸が残っていないか

どうしても作り直しが必要な場合は、先に reg export で構成の退避を行い、作業ログ（実行したコマンドと結果）を残します。

sc create / sc config の基本パターン

サービスの再作成・再設定は、次のように行います（環境に合わせて値を設定します）。

sc create "サービス名" binPath= "C:\Path\app.exe --arg1 --arg2" start= auto obj= "LocalSystem" sc config "サービス名" start= delayed-auto sc config "サービス名" obj= ".\svcuser" password= "********"

ここで重要なのは、sc.exe のパラメータは 「キー=値」形式で、キーの後ろにスペースが必要という点です。実務ではここを誤って「設定したつもり」になりやすいので、sc qc で必ず反映結果を確認します。

---

回復アクションを“現場の負担が減る形”にする

サービスが落ちたとき、何をもって正常復帰とするかは運用設計です。回復アクションは、短期的な収束（自動再起動）には効きますが、依存や権限が壊れている状態だと失敗を繰り返します。だからこそ、原因の切り分けとセットで整備します。

sc.exe では回復設定を次のように行います（例）。

sc failure "サービス名" reset= 86400 actions= restart/60000/restart/60000/""/0 sc failureflag "サービス名" 1

「何回再起動したら、どの時点で通知・エスカレーションするか」を決めておくと、夜間対応の心理的負担が減ります。再起動の無限ループは“沈静化”ではなく、障害を長引かせることがあるためです。

PowerShellでの状態確認と監視連携

PowerShellは、状態確認と“記録”に強いです。例えば、サービスの状態・スタート種別・依存を一覧し、ログと合わせて保存します。

$name = "サービス名" Get-Service -Name $name | Select-Object Name, DisplayName, Status, StartType | Format-List (Get-Service -Name $name).ServicesDependedOn | Select-Object Name, Status, StartType (Get-Service -Name $name).DependentServices | Select-Object Name, Status, StartType

さらに、Systemログから該当サービス名を含むSCMイベントを抜き出して、時系列で保存します。

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; StartTime=(Get-Date).AddDays(-3)} | Where-Object { $_.Message -match "サービス名" } | Select-Object TimeCreated, Id, LevelDisplayName, Message | Sort-Object TimeCreated | Out-File ".\scm_サービス名.log" -Encoding UTF8

---

この章のまとめ：修復とは“変更”ではなく“再現可能な再構築”

サービスの復旧は、単に開始できるようにする作業ではありません。構成の一次情報を残し、原因を潰し、回復アクションを運用に合わせ、次に同じ状況でも手順で収束できる形に整えることが本質です。ここまで整うと、次章の再発防止（構成管理と監視）に繋がります。

　

第9章：再発防止――構成管理と監視で「未起動」を先回りして潰す

サービスの未起動や開始失敗は、単発の事故に見えても、根っこは「構成のドリフト（意図しない変化）」で起きることが多いです。つまり、直すべきはサービスそのものより、変化を管理する仕組みです。現場のしんどさを減らすには、再発防止を“根性論”ではなく“仕組み”でやる必要があります。

再発の芽はだいたいここにある

• パスワード変更や資格情報の失効（サービスアカウント）
• Windows Updateやアプリ更新でのファイル差し替え（依存DLLの変化含む）
• EDR/セキュリティポリシーの更新でのブロック（署名・実行制御）
• GPOでの権限設定変更（SeServiceLogonRight、ローカル権限、ACL）
• 運用作業の属人化（手で直す → 次の変更で再び壊れる）

これらは、個別のサービスに閉じた問題ではなく、運用全体の問題です。だからこそ、一般論の「再起動」「再インストール」だけでは解決しません。

---

構成ドリフトを検知する：サービス設定の定期監査

まず現実的なのは、重要サービスについて「あるべき構成」をテキスト化し、定期的に差分を取ることです。例として、以下の項目はドリフトしやすく、障害に直結します。

• StartType（自動/遅延/手動/無効）
• BINARY_PATH_NAME（ImagePath相当）
• 実行アカウント（ObjectName）
• 依存関係（DependOnService）
• 回復アクション（failure actions）

PowerShellで定期的に抽出し、前回との差分を監視に載せると、「未起動」になる前に異常を見つけられます。

監視の設計：状態だけで赤にしない

未起動や停止を監視するとき、状態だけを見ると誤検知が増えます。特にトリガ起動や手動サービスでは、「止まっている」が正常であることがあるためです。そこで、監視は次のように“意味”で設計します。

監視したいこと	状態監視だけの弱点	現実的な補強
自動サービスが落ちた	再起動で一瞬戻ると見逃す	SCMイベント（7000/7023等）の収集と相関
依存が原因で起動できない	下流だけ赤くなり、原因が見えない	依存グラフと根本原因サービスの監視
手動/トリガサービスが未起動	仕様なのに赤くなる	「起動されるべきタイミング」を条件化（イベント/ジョブ/利用状況）

---

資格情報の事故を減らす：サービスアカウント運用の見直し

サービスのログオン失敗は、単純に「パスワードが変わった」だけでも発生します。ここで重要なのは、運用の設計として「資格情報の更新」を事故らせないことです。手作業での更新が多いほど、ミスが増え、復旧が遅れます。

現場では、アカウントの棚卸し（どのサービスがどのアカウントで動いているか）をまず行い、更新手順を統一します。環境によっては、グループ管理サービスアカウント（gMSA）の採用や、秘密情報管理（Vault等）との連携が検討対象になります。

心の会話：運用改善は後回しになりがち

「障害対応で疲れ切った後に“再発防止をやろう”って言われると、正直きつい。でも次も同じ夜を迎えるのはもっと嫌。」

この感覚は現場のリアルです。だから、再発防止は“気合い”ではなく、小さく始めて積み上げるのが現実的です。例えば「重要サービスだけ構成を毎日ダンプして差分を取る」「SCMイベントを中央集約して根本原因を追えるようにする」だけでも、次の障害の鎮火が早くなります。

この章のまとめ：未起動は“現象”、原因は“変化の管理”にある

未起動・開始失敗を減らすには、サービスを強くするより先に、構成管理・監視設計・資格情報運用を整えるのが近道です。ここまで整備できると、「直せる」だけでなく、「説明できる」「再現できる」状態になり、組織としての耐久力が上がります。

　

第10章：帰結――サービスは“状態”ではなく“構成物”、だから再構築できる設計にする

最後に、今回のテーマを一本の線で回収します。サービスが未起動に見えるとき、目に入るのは「Stopped」「Not started」「開始できません」などの状態情報です。しかし、障害の本体は状態ではなく、サービスを成立させている構成物のどこかが崩れたことです。

依存が崩れていれば起動できない。アカウントが崩れていればログオンできない。実体（ImagePath/ServiceDLL）が崩れていればロードできない。権限が崩れていれば拒否される。これらはどれも、再起動の回数では解決しません。だから「未起動」を見た瞬間にやるべきことは、反射的な再起動ではなく、構成物を特定し、順序立てて整えることです。

“再構築できる設計”とは何か

再構築できるとは、誰が担当しても同じ手順で同じ結果に到達できる、という意味です。具体的には次の3点が揃っている状態です。

• 一次情報が残る：sc qc / reg export / イベントログが保存され、原因の説明ができる
• 構成が再現できる：サービス定義（起動方式、依存、アカウント、回復設定）がテキスト化されている
• 運用の歯止めがある：変更は手順化され、監視は“意味”で赤くなるように設計されている

この3点があると、障害対応は「その場の技量」に依存しにくくなり、被害最小化が現実になります。

---

一般論の限界：現場は“環境差分”で詰まる

ここまでの内容は、Windowsサービス障害の典型パターンに沿った手順です。ただし、実際の現場では「環境差分」が強く効きます。例えば、同じサービスでも、次の違いで対処が変わります。

• ドメイン参加の有無、GPOの適用範囲
• EDR/実行制御（WDAC/AppLocker等）の有無と設定
• アプリの実装方式（独立EXEか、svchost配下か、ドライバか）
• ログの出方（System/アプリ独自ログ/ETWなど）
• 復旧優先度（停止できない、冗長化がある、監査が必要）

つまり、一般論だけで押し切ると、「動いたけど理由が分からない」「次の更新でまた壊れる」「説明責任に耐えない」という形で、後から火種が残ります。

終盤の判断：迷ったら“変化を増やさない”が安全

障害対応では、手を動かすほど状況が変わります。原因が確定しないまま変更を重ねると、後で「どの変更が効いたのか」が分からなくなります。だから、迷ったときは“変更を増やさない”ほうが、結果的に収束が早いことが多いです。

具体的には、一次情報の確保（構成・ログ・時系列）を固め、影響範囲と優先順位を整理し、必要な変更だけを小さく入れて検証します。ここで判断が難しい案件（業務影響が大きい、監査が絡む、セキュリティ製品が関与する、サービスが多段依存している等）では、株式会社情報工学研究所のような専門家に相談して、切り分けと復旧を並行で進めるほうが現実的です。問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831。

この章のまとめ：未起動は“直す”より“再構築できる”に寄せる

サービス障害を、単発のトラブル対応で終わらせないためには、状態の復旧だけでなく、構成の再現性・運用の歯止め・説明責任まで含めて整える必要があります。そうすることで、次の障害は「慌てるもの」から「手順で収束させるもの」に変わります。

　

付録：主要プログラミング言語でWindowsサービスを扱うときの注意点

Windowsサービスは、言語よりも「SCMとの契約（起動・停止・状態通知・ログ・権限・更新）」が本体です。言語ごとに落とし穴が違うため、実装・運用・配布の観点で注意点を整理します。

サービス実装で共通して重要なこと

• 起動直後にSCMへ状態を返す：初期化が長い場合は段階的に状態更新し、タイムアウトに注意する
• 停止要求を正しく処理する：強制終了に頼らず、データ整合性を保てる停止手順を実装する
• ログを運用が拾える形にする：Event Log、ファイルログ、ETWなど、所在と粒度を設計する
• 権限を最小化する：必要なファイル/レジストリ/ネットワーク権限を明確化し、ACLで穴埋めする
• 更新・ロールバックを設計に含める：バイナリ差し替え時の失敗を前提に、復旧手順を持つ

---

言語別の注意点（実装・配布・運用）

言語/実装系	よくある落とし穴	現実的な対策
C / C++（Win32 API）	ServiceMain/Handlerの実装ミスで停止要求を無視、初期化が長くタイムアウト、Unicode/権限/例外処理の不備で7023になりやすい	状態通知（SERVICE_START_PENDING等）を段階的に行う、例外/エラーコードをログに残す、依存DLLの配置と署名要件を管理する
C# / .NET（ServiceBase / Worker Service）	.NETランタイム/Hostingの前提差分、ログ出力先が散らばる、サービス停止時にバックグラウンド処理が残る	長い初期化は段階化、停止トークンで確実に終了、Event Logやファイルログの所在を統一、配布方式（self-contained等）を設計で確定
Java（Windowsサービス化：ラッパ/プロセスマネージャ）	JRE/JDKの更新で挙動が変わる、サービスとしての停止が乱暴になりがち、パスや環境変数依存で起動失敗	サービスラッパの標準化、JRE同梱/固定、停止手順（graceful shutdown）を明示、環境変数依存を削減してImagePathを安定化
Go（Windows Service対応）	単一バイナリで楽だが、ログ設計が薄いと切り分けが難しい、サービス制御ハンドラの実装が雑だと停止要求に弱い	Event Log/ファイルログを設計で必須化、停止要求の処理（context cancel等）を徹底、依存（証明書/設定ファイル）の配置と権限を明確化
Rust（Windows Service対応）	安全性は高いが、運用ログが弱いと原因が追えない、依存DLL/暗号ライブラリ周りの差分で起動時に落ちる	ログの所在と粒度を決める、起動失敗時のエラーを確実に記録、署名や暗号基盤（証明書ストア）の前提を文書化
Python（pywin32等）	実行環境（Python本体/ライブラリ）に依存しやすい、パス/仮想環境の差分で起動できない、更新で急に壊れる	配布形態（同梱/固定）を決める、依存の凍結（requirements固定）と更新手順を整備、ログと例外の記録を必須化
JavaScript / Node.js（サービス化ツール利用）	Node本体更新で挙動が変わる、npm依存が多く再現性が落ちる、ログが標準出力だけだと追えない	Nodeバージョン固定、依存ロックと配布の再現性確保、ログをEvent Logやファイルへ、サービス停止処理を実装で保証
PowerShell（サービスではなく運用スクリプト/ジョブ）	サービスとして常駐させると管理が難しい、権限と実行ポリシー差分で失敗、ログが残らないと追えない	常駐が必要ならサービス化より専用実装を検討、タスクスケジューラ等に寄せる、ログ（Transcript/イベント）を前提に運用設計
バッチ / Bash（補助用途）	エラー処理が曖昧だと回復アクションと噛み合わない、環境変数やカレントディレクトリ依存で壊れる	補助に徹し、成功/失敗を明確に終了コードで返す、絶対パスで実行し、実行アカウント権限を明文化

---

案件ごとに変わる論点：ここが“相談ポイント”になりやすい

• サービスアカウント設計（最小権限、GPO、資格情報更新、監査対応）
• セキュリティ製品・実行制御との整合（署名、WDAC/AppLocker、隔離時の復旧手順）
• 更新とロールバックの仕組み（停止できない環境での展開方式、手順と証跡）
• ログの設計と保全（説明責任、障害解析、再発防止のための一次情報）

これらは一般論だけで決めると、現場の制約（止められない、監査がある、構成が複雑）で詰まりやすい領域です。具体的な案件・契約・システム構成に踏み込んだ判断が必要なときは、株式会社情報工学研究所への相談・依頼を検討すると、切り分けと収束が早くなります。問い合わせフォーム：https://jouhou.main.jp/?page_id=26983 ／電話：0120-838-831。