LASSIC Media らしくメディア
Rundeckで運用自動化基盤を外注構築
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Rundeckは手順書（ランブック）をジョブとして登録し、権限を持つメンバーがセルフサービスで実行できる運用自動化基盤です
- 属人化したcronスクリプトや手作業の運用手順を、ACL（アクセス制御ポリシー）で権限を委譲したジョブに置き換えられます
- 構築には認証連携・ノード管理・ACL設計など専門知識が必要で、外注と内製それぞれに向くケースがあります
目次
Rundeckとは — 手順書をジョブ化する運用自動化基盤
Rundeckとは、運用の手順書（ランブック）をジョブとして登録し、Webコンソール・コマンドラインツール・WebAPIから実行できるオープンソースの運用オーケストレーションツールである*1。Apache License 2.0で公開されており、PagerDuty社が開発を主導している*1。
Rundeckの中核機能は3つある。第一に、入力オプション・処理ステップ・ノードフィルターで構成されるジョブ（Job）としての手順の定義*1。第二に、SSH・WinRM等でリモートホストへコマンドを実行するノード管理。第三に、実行権限を細かく制御するACL（Access Control List）によるセルフサービス化である*2。
これら3つが揃うことで、これまで管理者しか実行できなかった運用手順を、権限を絞った形で現場担当者に開放できるようになる。次章では、この仕組みが解決する具体的な運用課題を見ていく。
手作業運用とcron乱立が抱える課題
現場によっては、サーバーの再起動・バッチ処理・ログクリーンアップといった定型作業が、個々のサーバーに仕込まれたcron（Linuxの定時実行スケジューラ）や、担当者が手元で実行するシェルスクリプトとして積み重なっている。作業の全体像が誰の頭にもなく、属人化が進んでいるケースが見られる。
この状態には複数のリスクがある。まず、cronの登録内容が各サーバーに分散し、どのサーバーに何が設定されているかを俯瞰できない。担当者の異動・退職によって、手順の意図や実行条件が失われることも起こりうる。また、手作業実行では「誰がいつ何を実行したか」の記録が残らず、障害発生時の原因追跡に手間がかかる。
さらに、権限管理の面でも課題が生じやすい。手順の実行にサーバーへのSSHログイン権限が必要な場合、実行を頼みたい担当者ごとにサーバー権限を個別付与することになり、権限の肥大化を招く。結果として、限られた管理者だけが手順を実行できる状態が固定化し、日常的な運用作業のたびに管理者の手が止まる。
Rundeckは、こうした分散した手順を1つのジョブ管理基盤に集約し、実行権限をロール単位で委譲することで、この構造そのものを見直す手段になる。次章ではジョブの構成要素を具体的に見ていく。
ジョブの構成要素とセルフサービス実行の仕組み
Rundeckにおけるジョブとは、プロセスをカプセル化した構成であり、入力オプション・処理ステップ（ワークフロー）・ノードフィルター式・実行制御パラメータで構成される*1。ワークフローは、ジョブが実行するステップの並び方と、並列実行やエラー処理の制御方法を定義する*1。
ジョブオプションとノードフィルター
ジョブオプションは、ユーザーがジョブ実行時に入力する値で、デフォルト値やメニュー選択を設定できる*1。例えば「対象環境（本番／検証）」や「再起動対象のサービス名」をオプションとして持たせれば、実行担当者は画面上の選択肢から値を選ぶだけでよく、コマンドの構文を覚える必要がなくなる。
ノードフィルターは、ジョブの実行対象ノードを指定する式である*1。タグや属性で対象サーバーを絞り込めるため、「本番Webサーバー群のみ」「検証環境の特定ホストのみ」といった指定が可能になる。
ジョブグループとUUIDによる管理
ジョブはグループで論理的に整理でき、この単位はアクセス制御ポリシー（ACL）定義にも活用される*1。加えて各ジョブには一意の識別子（UUID）が割り当てられ、ジョブ名を変更しても同じジョブとして追跡できる。インスタンス間でジョブを移行する際にもこのUUIDが役立つ*1。
セルフサービス実行という考え方
ジョブ化された手順は、Webコンソールの「実行」ボタンから起動できる。これにより、これまで管理者に依頼していた定型作業を、権限を持つ担当者が自分自身で実行できるようになる。Rundeck公式は、この仕組みを「DevOpsやプラットフォームエンジニアリングチームにセルフサービス自動化の能力を与える」ものと位置づけている*3。
ただし、誰でも何でも実行できる状態は望ましくない。次章で扱うACL設計が、セルフサービス化を適切な統制のもとで運用するための前提になる。
ACLによる権限委譲 — 誰に何を実行させるか
Rundeckのアクセス制御ポリシー（ACL）は、ユーザーとユーザーグループに対し、Rundeckのリソース（プロジェクト・ジョブ・ノード・コマンド・API等）へのアクセス権限を付与する仕組みである*2。認証メカニズムから取得したユーザーのグループ・ロール情報に基づいて、実行可否が判定される*2。
2つのコンテキストで定義するACL
ACLポリシーは、アプリケーションコンテキストとプロジェクトコンテキストの2種類で定義する必要がある*2。アプリケーションコンテキストはプロジェクトの表示可否や新規プロジェクト作成権限を管理し、プロジェクトコンテキストはプロジェクト内でのジョブ実行やノード操作を制御する*2。ユーザーがプロジェクトを見るためには、両方のレベルでの許可が必要になる点に注意が必要である*2。
ロールベースのきめ細かい制御
Rundeckは、ユーザーを一部の操作のみに制限するロールベースの権限制御をサポートしている*2。ユーザーのグループメンバーシップと、そのグループに付与されたアクセス権限を組み合わせることで実現される。管理者は、ジョブグループ名やノードタグといった条件によるフィルタリングを組み合わせ、細かい単位で権限を設定できる*2。
例えば「アプリ運用チームは特定グループのジョブのみ実行可能」「インフラチームは全ジョブの実行と参照が可能だが定義変更は不可」といった、部署・役割に応じた権限設計が行える。
拒否ルールが優先される設計
ACLの評価では、拒否（deny）ルールが先に評価され、許可（allow）ルールより優先される*2。拒否ルールが一度マッチすると、許可ルールが存在してもアクセスは拒否される*2。この設計により、誤って過剰な許可を与えてしまうリスクを、拒否ルールで抑え込める。
ACLの粒度設計を誤ると、意図せず本番環境への実行権限が広く開放されてしまう恐れがある。プロジェクト・ジョブグループ・ノードタグをどう切り分けるかは、構築時にもっとも設計力を要する部分である。
ノード管理とSSH・WinRM実行
Rundeckにおけるノードとは、物理または仮想の、ネットワークにアクセス可能なホストリソースを指す*4。各ノードは一意の名前を持ち、ホスト名・ユーザー名などの基本属性に加え、任意の名前付きキー・バリューペアを持つように拡張できる*4。この属性・タグを使い分けることで、ジョブの対象ノードを柔軟に絞り込める。
ノードソースとリソースモデル
Rundeckインスタンスにノードを追加する際は、リソースモデルソース（Resource Model Sources）の設定を行う*4。クラウドのインベントリAPIやファイルベースの定義など、複数の方式でノード一覧を取り込める仕組みが用意されている。
SSH実行とWinRM（PowerShell）実行
Rundeckは、Linux・Unix系ノードへのリモートコマンド実行にSSHプロトコルを使用する*5。公開鍵・秘密鍵認証とパスワード認証の両方に対応し、SSH-J・OpenSSH・Bastionsshなど複数の実装をノードエグゼキュータプラグインとして選択できる*5。
Windowsノードに対しては、WinRM（Windows Remote Management）を使ったコマンド実行に対応し、ネイティブなPowerShellスクリプトの実行や、Windows認証方式との連携が可能である*5。混在環境（LinuxサーバーとWindowsサーバーが共存する運用基盤）でも、1つのRundeckインスタンスからジョブを実行できる。
ノードエグゼキュータはプロジェクトレベルで既定値を設定でき、個々のノード属性で上書きすることもできる*5。クラウド環境ではAWS SSM（Systems Manager）を使った実行プラグインも用意されており、SSHの鍵管理を避けたい構成でも運用しやすい設計になっている*5。
Ansible等の既存自動化ツールとの連携
Rundeckは、既存の自動化ツールを置き換えるのではなく、その実行を統合的に管理するオーケストレーション層として使われることが多い。公式ドキュメントには、Ansibleモジュールを実行するステップ、Ansible playbookをインラインで実行するステップ、Ansible playbookファイルを実行するステップという3種類の組み込みプラグインが用意されている*6。
これにより、既存のAnsible playbookをそのままRundeckのジョブに組み込み、実行トリガー（スケジュール実行・セルフサービス実行・API経由の実行）とアクセス制御をRundeck側に一元化できる。Ansibleは構成管理（サーバーのあるべき状態を定義し適用する仕組み）を担い、Rundeckは「誰が」「いつ」「どの範囲に」その処理を実行してよいかを制御する、という役割分担になる。
この連携は、IaC（Infrastructure as Code、インフラ構成をコードで管理する手法）ツールでインフラを構築した後の運用フェーズで特に効果を発揮する。構築済みのインフラに対する日常的なメンテナンス作業（サービス再起動・設定リロード・バッチ実行）を、構築時のコードとは別に、運用担当者が実行できるジョブとして切り出せるためである。
監査ログと実行履歴 — 誰が何を実行したかの記録
セルフサービス実行を統制のもとで運用するうえで欠かせないのが、実行履歴の記録である。Rundeckは、ジョブの実行ごとに実行者・実行時刻・対象ノード・実行結果（成功／失敗）・出力ログをWebコンソール上で確認できる仕組みを備えている。手作業運用では残らなかった「誰が何を実行したか」が、ジョブ化によって自動的に記録の対象になる。
この記録は、障害発生時の原因調査を効率化するだけでなく、権限委譲を進める際の心理的な抵抗を下げる効果もある。実行担当者からすれば「実行内容が記録される」という前提があることで、誤操作への注意が働きやすくなる。管理者からすれば、権限を広げても実行内容を後から追跡できるという統制上の拠り所になる。
監査要件が厳しい業種（金融・医療・公共分野等）では、実行ログの長期保管・外部ログ管理システムへの転送が求められる場合がある。Rundeckは複数のプラグインを通じて、実行ログをストレージや外部のログ管理基盤と連携させる仕組みを提供している*7。構築時には、自社の監査要件に対してログ保管期間・転送先・アクセス権限をどう設計するかを確認しておく必要がある。
OSS版と商用版の違い・外注と内製の判断軸
Rundeckには、Apache License 2.0で公開されているオープンソース版と、PagerDuty社が提供する商用版（Rundeck Enterprise）が存在する*1*3。OSS版はジョブスケジューリング・インフラ管理・基本的なセルフサービス機能を備え、コミュニティ主導で開発が進む*3。商用版は、高可用性構成・レジリエントなデプロイメント、閉域環境から統制のもとでリモート実行できるEnterprise Runner、電話・メール・専用ポータルでの技術サポート、高度なオーケストレーション機能・プレミアムプラグインを追加提供する*3。
商用のランブック自動化ツール（他社製品）と比較すると、Rundeckはソースコードが公開されており、プラグイン開発によって拡張できる点が特徴である。一方で、構築・運用のすべてを自社で担う前提となるため、認証連携・ACL設計・ノード管理・高可用性構成を含めた技術的な実装力が求められる。
比較表：手作業運用とRundeck自動化
| 観点 | 手作業・cron運用 | Rundeckによる自動化 |
|---|---|---|
| 手順の在り処 | 担当者個人・各サーバーに分散 | ジョブとして一元登録・グループ管理 |
| 実行できる人 | サーバー権限を持つ管理者に限定 | ACLで委譲された担当者がセルフサービス実行 |
| 実行記録 | 残らない、または個別ログのみ | 実行者・時刻・結果を自動記録 |
| 対象OS | Linux系はcron、Windows系は別途対応が必要 | SSH・WinRMで混在環境を一元管理 |
| 既存資産の扱い | シェルスクリプトが個別に増える | 既存スクリプト・Ansible playbookをジョブに組込み |
失敗コストと必要スキルの目安
ACL設計を誤ると、想定外のユーザーに本番ジョブの実行権限が渡り、誤操作による障害が発生するリスクがある。反対に権限設計を過度に厳格にすると、セルフサービス化の効果が失われ、結局は管理者への依頼が残ってしまう。ACLは一度設計して終わりではなく、組織変更・チーム構成の変化に応じた継続的な見直しが必要である。
内製で構築する場合、認証基盤（LDAP・SAML等）との連携設計、ACLポリシーの記述、ノードエグゼキュータの選定・SSH鍵管理、既存Ansible資産の統合という一連の作業を担える技術者が必要になる。導入初期は特に、ジョブ設計とACL設計の両方を並行して検討できる要員の確保が課題になりやすい。
外注と内製の判断軸
自社に運用オーケストレーション基盤の構築経験を持つ技術者が確保できていれば、内製での構築・運用も選択肢になる。一方で、認証連携やACL設計の初期構築を短期間で仕上げたい場合や、既存のSSH鍵管理・監査要件を踏まえた設計を専門知見をもとに固めたい場合は、構築を外部パートナーに委託する意義が大きい。
構築後の運用フェーズでは、ジョブ追加・ACL見直し・ノード追加が定常的に発生する。構築を外注した場合でも、運用の一部を自社の運用担当者が引き継げるように、ジョブ定義やACLポリシーをドキュメント化しておくことが望ましい。
LASSICのIT事業部では、元請（プライムベンダー）としてシステム保守・運用を受託しており、をもとに、運用自動化基盤の構築と既存手順のジョブ化についての相談に対応している。ACL設計・ノード管理・既存Ansible資産の統合を含めた構築範囲の整理は、IT開発支援サービスページから相談できる。
まとめ：Rundeck導入で押さえる3つの判断軸
本稿では、Rundeckによるランブックのジョブ化、ACLを使ったセルフサービス実行への権限委譲、ノード管理とSSH・WinRM実行、Ansible等との連携、監査ログの記録、OSS版と商用版の違いを整理した。要点を3つに集約する。
第一に、Rundeckは属人化した手順書をジョブとして一元管理し、実行権限をACLで委譲することで、手作業・cron乱立から脱却する手段になる。第二に、セルフサービス実行を統制のもとで機能させるには、ジョブグループ・ノードタグを単位にした緻密なACL設計と、実行履歴を残す監査ログの仕組みが前提になる。第三に、構築には認証連携・ACL設計・ノード管理の技術力が求められるため、内製の体制状況に応じて外注との組み合わせを検討することが要点である。
よくある質問
Rundeckとcronの違いは何ですか？
cronは各サーバーに個別設定する定時実行スケジューラで、実行記録や権限管理の仕組みを持ちません。Rundeckはジョブという単位で手順を一元管理し、スケジュール実行に加えてセルフサービスでの手動実行、ACLによる権限委譲、実行履歴の記録までを1つの基盤で提供します。複数サーバーに分散したcron設定を統合管理したい場合に適しています。
ACLはどの単位で設定できますか？
ACLはアプリケーションコンテキストとプロジェクトコンテキストの2種類で定義します*2。プロジェクトコンテキストでは、ジョブグループ名やノードタグといった条件でユーザーグループごとに実行・参照・編集の権限を細かく設定できます。拒否ルールは許可ルールより先に評価され、優先されます*2。
WindowsサーバーもRundeckで管理できますか？
WinRM（Windows Remote Management）を使い、Windowsノードに対してPowerShellスクリプトを実行できます*5。LinuxノードはSSHで実行するため、1つのRundeckインスタンスからLinuxとWindowsが混在する環境を一元的にジョブ管理できます。
既存のAnsible playbookはそのまま使えますか？
Rundeckには、Ansible playbookファイルを実行するステップ、playbookをインラインで実行するステップ、Ansibleモジュールを実行するステップが組み込みプラグインとして用意されています*6。既存のplaybookをジョブのステップに組み込み、実行トリガーとアクセス制御をRundeck側に統合できます。
構築を外注する場合、どこまで内製に引き継げますか？
ジョブ定義・ACLポリシー・ノード設定はドキュメント化できる範囲であり、構築後の運用担当者への引き継ぎが可能です。初期の認証連携設計・ACL設計・既存Ansible資産の統合部分を外部パートナーに依頼し、日常的なジョブ追加やACL微調整を自社運用に引き継ぐという役割分担がよく使われます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Rundeck（GitHubリポジトリ）「rundeck/rundeck」— Apache License 2.0で公開されたオープンソースのランブック自動化サービスであることを示す。URL: https://github.com/rundeck/rundeck
- *2 出典：Rundeck公式ドキュメント「Access Control Policy」（Authorization）— ACLの二重コンテキスト構造・ロールベース制御・拒否ルール優先の仕様を示す。URL: https://docs.rundeck.com/docs/administration/security/authorization.html
- *3 出典：Rundeck公式サイト（rundeck.com）— Rundeckの概要、セルフサービス運用、OSS版と商用版（Rundeck Enterprise）の機能差を示す。URL: https://www.rundeck.com/
- *4 出典：Rundeck公式ドキュメント「Nodes」（Manual）— ノードの定義・属性・タグ・リソースモデルソースの仕組みを示す。URL: https://docs.rundeck.com/docs/manual/05-nodes.html
- *5 出典：Rundeck公式ドキュメント「Node Execution」（Projects）— SSH・WinRM実行方式、ノードエグゼキュータプラグインの仕様を示す。URL: https://docs.rundeck.com/docs/manual/projects/node-execution/
- *6 出典：Rundeck公式ドキュメント「Plugins – Full List」（Manual）— Ansibleモジュール・playbook実行の組み込みプラグイン一覧を示す。URL: https://docs.rundeck.com/docs/manual/plugins/full-list.html
- *7 出典：Rundeck公式ドキュメント「Plugins」（Manual）— 実行ログのストレージ連携・外部ログ管理基盤との統合プラグインの存在を示す。URL: https://docs.rundeck.com/docs/manual/plugins/
