xyOpsとは：Cronicle後継のジョブ管理＋サーバー監視OSS｜構成・15種トリガー・移行手順

ジョブスケジューラを入れると、次に監視が要る。監視を入れると、アラートの通知先とインシデントの記録が要る。結局 cron＋監視SaaS＋課題管理の3系統を別々に運用することになる——xyOps（pixlcore/xyops）は、その3つを最初から1つのシステムに束ねたセルフホスト型の運用プラットフォームです。開発者はジョブスケジューラ Cronicle の作者である Joseph Huckaby 氏で、公式ドキュメントは Cronicle を「spiritual predecessor（精神的な前身）」と位置づけています。

2025年12月末に公開され、2026年7月25日時点でGitHubスター4,658・フォーク454。リリースは156本を数え、直近版は2026年7月22日の v1.0.85 です。ライセンスは BSD-3-Clause で、READMEは「無料ティアにすべてのアプリ機能が含まれる」と明言しています。この記事では、公式リポジトリとリポジトリ内の53ページの公式ドキュメントを一次ソースに、xyOpsの正体・Cronicleからの移行・構成・セルフホスト時に最初に確認すべき点・導入前に知っておくべき弱点を整理します。

この記事ではセルフホスト型のジョブ管理・監視OSSとしてxyOpsを解説します。自動化ツール全般のカバレッジは AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

xyOpsとは何か：ジョブ管理と監視を1つに束ねたOSS

xyOpsのREADMEは自らを「job scheduling, workflow automation, server monitoring, alerting, and incident response」を1つのまとまったプラットフォームに統合したもの、と説明しています。要素だけ並べると欲張りな寄せ集めに見えますが、設計の主眼は機能数ではなくそれらが互いに参照し合うことにあります。READMEの表現を借りれば、アラートのメールにはそのサーバーで走っていたジョブが載り、ワンクリックでその瞬間のプロセス・CPU負荷・ネットワーク接続のスナップショットが開き、ジョブが失敗すればログと履歴とメトリクスを添えてチケットが起票される——検知から解決までを同じシステムの中で追える、という発想です。

用語は少なく、覚えるのは6語です。Conductor（司令塔。UI・スケジューラ・API・データ保存を持つ本体）、xySat（各サーバーに常駐する軽量エージェント）、Event（何を・どこで・いつ実行し、どう後始末するかの定義。再利用可能なテンプレート）、Job（Eventの1回の実行）、Trigger（起動条件）、Limit（暴走を止めるガードレール）。ワークフローは「グラフを内蔵したEvent」として扱われ、実行されると親ジョブが立ち、そこから子ジョブが枝分かれしていきます。

ライセンス面は素直です。BSD-3-Clauseで、リポジトリの LONGEVITY.md には「xyOpsは常にオープンライセンスであり、常にOSI承認のものである。rug pull（後からの方針転換）はしない」という趣旨の誓約が置かれています。有料プランは Professional／Enterprise の2段で、公式の説明では機能のロック解除ではなくサポート契約（私設チケット、応答時間の保証、SSO導入支援、エアギャップ導入支援など）です。無料ティアに全機能が入る、という前提はREADMEにも公式比較ドキュメントにも繰り返し書かれています。

もう1つ、セルフホスト派に効く設計判断があります。公式の trust.md は「xyOpsはテレメトリを送らない」と明記し、製品分析・トラッキング・PixlCoreへのコールホームを行わないと列挙しています。その上で、GitHubのリリースAPIを見に行く更新確認、xySatパッケージのダウンロード、プラグインMarketplaceのカタログ取得といった任意の外向き通信を表にして、それぞれ multi.enable_version_checks・satellite.enable_version_checks・marketplace.enabled などの設定キーで止められることまで書いています。エアギャップ運用向けに、外向き通信を許可IPレンジに限定するairgapルールがあり、そのルールは接続済みのワーカーにも伝搬すると説明されています。

Cronicleとの関係と移行：後継だが本家も現役

xyOpsを検討する人の多くは、Cronicleユーザーです。Cronicle（jhuckaby/Cronicle）は2016年公開のジョブスケジューラで、2026年7月25日時点でスター5,785・フォーク500。xyOpsの公式ドキュメントには cronicle.md という専用章があり、Cronicleを「spiritual predecessor」と呼んでいます。ここで大事なのは、Cronicleが廃止されたわけではないことです。Cronicleリポジトリは2026年7月17日にもpushされており、xyOpsを「Cronicle v2」と呼ぶ書き方は公式の表現ではありません。同じ作者が、別の設計で作り直した後継プロジェクト——というのが正確な理解です。

移行は「エクスポート→インポート」ですが、順番に罠があります。公式手順は先にすべてのワーカーサーバーをxyOps側に登録しておくよう指示しています。理由は、Cronicleのイベントがホスト名で直接サーバーを指定できるのに対し、xyOpsはサーバーの扱いが異なるためで、インポート時にCronicleのターゲットとxyOpsのサーバーを突き合わせる処理が入るからです。また、一括インポートは破壊的で、既存データを消し、走っているジョブを中断し、キューをフラッシュし、スケジューラを自動的に一時停止します。

互換モードは、既存のCronicleプラグインをコード変更なしで動かすためのスイッチです。satellite.config オブジェクトに cronicle: true を入れるか、環境変数で渡します。設定変更後はクラスタ全体に反映させるため再起動が必要、と公式に注記があります。

# 既存のCronicleプラグインをコード変更なしで動かす互換モード
# （satellite.config オブジェクト内に cronicle: true を入れるのと同等）
XYOPS_satellite__config__cronicle="true"

# UIの名前とロゴをCronicle表記に戻す（client オブジェクト内の設定）
XYOPS_client__name="Cronicle"
XYOPS_client__logo_url="/images/cronicle-logo.png"

設計思想の違いが最もはっきり出るのが detached job の扱いです。Cronicleでは「サーバー側で切り離して実行し、親が落ちても走り続ける」モードが必要でした。xyOpsはワーカー側に常駐する小さなサテライトバイナリを置く構成なので、そもそも切り離す必要がありません。公式ドキュメントは、サテライトのアップグレードは段階的に展開され、各ワーカーは走っているジョブが全部終わるまで待ってから自己更新する、と説明しています。さらに、プライマリのxyOpsサービスを止めても走っているジョブは中断されず、Conductorが落ちている間に完了したジョブは、Conductorが戻ってくるのを待って結果を報告するとされています。

なお、ジョブスケジューリングの周辺には日本語情報の多い選択肢もあります。データパイプライン寄りの用途なら Kestra：データパイプラインとワークフロー自動化のオープンソースプラットフォーム や Prefect：データパイプラインのワークフロー管理とスケジューリングプラットフォーム の系統が近く、外形監視だけが目的なら Checkmateとは：稼働監視OSSをDockerでセルフホスト｜Uptime Kuma比較と実測 のような専用ツールのほうが素直です。xyOpsが噛み合うのは、それらを別々に立てたくないケースです。

構成：ConductorとxySatの2階建て、ストレージは選べる

xyOpsのクラスタは2種類のノードでできています。Conductorは本体で、スケジューラ・ルーティング・ストレージ・UI／APIを担います。Serverはワーカーで、xySatエージェントが常駐し、Conductorへの永続的なWebSocket接続を維持しながらメトリクスを送り、指示されたジョブを実行します。ワーカーは物理サーバー・VM・コンテナのいずれでもよく、Linux・macOS・Windowsに対応します（一部のメトリクスはWindowsで取得できないと明記あり）。

冗長化は「Conductorを複数台にする」形で行います。1つがプライマリ、残りはホットスタンバイで、xySatはConductorの一覧を常に最新に保ちます。プライマリへの接続が切れたワーカーは自動でバックアップにフェイルオーバーし、選出（election）後に新しいプライマリへ再接続します。ホスティングのドキュメントには「Preferred Conductors」「Election Ranking」「Active Primary Handoffs」といった節があり、どのConductorを優先するかのランキング設定まで用意されています。

ストレージは1つに固定されていません。既定はSQLiteとファイルシステムのハイブリッド（JSONレコードはSQLite、ファイルはファイルシステム）で、公式ドキュメントの storage.md にはSQLite＋NFS、MinIO、RustFS、Redis＋NFS、Redis＋S3、Postgres＋NFS、Postgres＋S3、Postgres SSL（AWS RDS含む）といった組み合わせが章立てで並びます。実際 package.json の依存にも better-sqlite3・pg・ioredis が入っており、ドキュメントの記述と実装が一致しています。

ジョブの実行単位はプラグインです。xyOpsのプラグインは Event／Action／Trigger／Monitor といった種類に分かれ、いずれもJSON over STDIO（公式には XYWP と呼ばれるワイヤープロトコル）でxyOpsと会話します。ジョブ開始時に1つのJSONドキュメントがSTDINへ渡され、スクリプト側は {"xy":1,"progress":0.5} のようなメッセージをSTDOUTに書けば進捗・ステータス・出力データ・添付ファイル・最終結果を返せます。認識されない出力は普通のログとして拾われ、STDERRは生テキストとして記録されます。

一番よく使うのは組み込みの Shell Plugin で、シェバン行さえ書ければ /bin/sh 以外の言語も動きます。公式ドキュメントは Node.js・Python・Perl・PHP・Ruby・PowerShell を例示しています。進捗報告にはショートハンドもあり、50% のように数値だけを1行出せばプログレスメーターが動きます。JSONを覚えなくても始められる、という設計です。

cronを超える15種類のトリガーと10種類のリミット

スケジューラの心臓部はトリガーです。xyOpsのトリガーは「有効／無効」と「種類」を持つ小さな定義オブジェクトで、1つのイベントに複数を合成できます。スケジューラはConductor上で毎分評価され、秒単位の精度も選べます。種類は次の15種類です。

cronでは表現しづらいものだけ抜き出すと、性格がわかります。Catch-Up は停止していた間に流れてしまったジョブを後から必ず実行するモード。Blackout はメンテナンスや長期休暇のように「この時間帯は動かさない」窓を宣言するもの。Range は開始日・終了日の範囲指定。Precision は分単位を超えて秒を指定する起動。Magic Link はURLを叩くと走る起動口で、Keyboard はUI上のキー操作、Startup はサービス起動時の実行、Every Nth はN回ごと、Delay は遅延、Quiet は静かに走らせる指定です。タイムゾーンはScheduleとPluginトリガーで指定でき、Range・Blackout・Intervalの時刻は絶対時刻として扱われる（＝タイムゾーン非依存）と明記されています。

もう一方の柱がリミットです。ジョブを止める仕組みが10種類あり、イベント単位・カテゴリ単位・ユニバーサル（全体既定）で継承と優先順位が定義されています。

ここに、公式ドキュメントが Getting Started の中でわざわざ節を割いている落とし穴があります。同時実行の上限に達したジョブは、既定では待たずに即エラーで落ちます。 待たせたいなら Max Concurrent Jobs と Max Queue Limit を必ずペアで設定する、という設計です。たとえば「同時1本・待ち25本まで」と組めば、走っている1本があれば次はキューに入り、25本溜まった時点でそれ以降の起動が拒否されます。Webhook起動・繰り返しワークフロー・multiplex・混み合ったスケジュールなど、ワーカーが受け取れる速度よりジョブの発生が速くなる場面では、この組み合わせが実質必須になります。

ワークフローに進むと、ノードの種類として Trigger／Event／Job／Action／Limit／Controller／Note が用意されます。Controllerには Split（分割。アイテムのフィルタとバッチサイズ指定つき）、Join（合流）、Repeat（繰り返し）、Multiplex（複数サーバーへの同一ジョブ展開）、Decision（条件分岐）、Wait（待機）があり、既定では並列に走ります。並列度はリミットノードで縛る、という役割分担です。

とはいえ、公式ドキュメント自身が「単純にAの後にBを走らせたいだけならワークフローは要らない」と書いています。イベントのActionに Run Event を1つ足せば連鎖は作れます。ワークフローは、分岐・合流・ファンアウト・複数ステップを目で見て編集したいときの道具、という整理です。

監視からチケットまで：1本でつながる部分が本題

xyOpsを他のジョブスケジューラと分ける最大の差は、ここから先です。ワーカーは2種類の粒度でメトリクスを出します。1つは毎秒の「quick」メトリクス（CPU・メモリ・ディスク・ネットワーク）、もう1つは毎分のモニターです。

Monitor は「サーバーの数値1つを時系列で追う」定義で、ライブデータから値を取り出す式、文字列から数値を抜く正規表現、データ型（integer／float／bytes／seconds／milliseconds）を指定します。値は時・日・月・年の複数解像度で保存され、グラフとアラートの材料になります。前回値との差分（delta）を取るモード、経過秒で割ってレートにするモード、特定のサーバーグループだけで評価するスコープ指定もあります。

Alert は定義（definition）と発火（invocation）を分けて扱います。評価はConductor上で毎分、サーバーごとに行われ、式はJavaScript形式で、作成・更新時とテストダイアログで事前にコンパイルされ構文エラーは弾かれます。連続してN回真になるまで発火しない「ウォームアップ」と、連続してN回偽になるまで解除しない「クールダウン」を指定できるため、瞬間的なスパイクで鳴り続ける事故を抑えられます。そして重要なのがジョブ制御です。アラートが上がっている間は新規ジョブの起動を止める、あるいは走っているジョブを全部中断する、という設定ができます。「ディスクが埋まりかけているサーバーに新しいバッチを投げない」を仕組みとして書ける、ということです。

Snapshot は障害調査のための「その瞬間の丸ごと保存」です。含まれるのは、CPU・メモリ・ロード・OS情報・稼働時間といった基本値に加えて、全プロセス一覧とプロセス統計、リッスン中を含むアクティブなネットワーク接続、ネットワークインターフェイスと統計、ディスクマウントとファイルシステム統計、モニターの計算値と差分、プラグインの生出力。さらに直近60秒ぶんの毎秒メトリクスと、その時点で動いていたジョブとアラートのIDまで紐づきます。グループ単位のスナップショットなら、オンラインの全メンバーに加えて直近1時間以内にオフラインになったサーバーも記録されるため、フリート全体の突き合わせができます。保持数は既定で10万件が上限で、毎晩剪定されます。作成は手動・API・アクション経由のほか、「Watch」として一定時間、毎分撮り続けることもできます。

Ticket は軽量な課題管理です。種類（issue／feature／release／change／maintenance／question／other）、状態（draft／open／closed）、担当者・CC・任意の通知先メールアドレス、期限（過ぎると担当者へ毎日リマインド）、Markdownの本文、ファイル添付、変更・コメント履歴を持ちます。ジョブやアラートから自動作成されるとき、カテゴリ・タグ・サーバーは元のジョブから引き継がれます。おもしろいのは逆向きの機能で、チケットからジョブを起動できます。チケットに紐づけたイベントのスタブがあり、添付ファイルはそのジョブの入力として渡されます。「ランブックをチケットに書き、その場から復旧ジョブを叩く」という運用が想定されています。

xyOpsをセルフホストするとき最初に確認すること

公式のQuick-StartはDockerです。ポイントは3つあり、いずれも「後から直すと面倒」な種類のものです。1つ目、ホスト名は実際に解決してネットワーク上で到達できる名前にすること。ワーカーはこの名前でConductorに繋ぎ、XYOPS_masters の値もこれと一致させます（Conductorが1台なら1つだけ書く）。2つ目、base_app_url は人間がクリックするURLであってサーバー間通信のホストではありません。メール・チケット・アラート・Webhookペイロードに埋め込まれる絶対URLの生成に使われます。3つ目、XYOPS_xysat_local は同じコンテナ内にxySatを立てる指定で、テストやホームラボには便利ですが本番非推奨と明記されています。

# 公式ドキュメント hosting.md の Quick-Start（docker compose 形式）
services:
  xyops01:
    image: ghcr.io/pixlcore/xyops:latest
    container_name: xyops-conductor-01
    hostname: xyops01.internal.example.com   # 実際に解決できる名前にする
    init: true
    restart: unless-stopped
    environment:
      XYOPS_xysat_local: "true"              # 本番非推奨。検証用に同一コンテナでジョブを走らせる
      XYOPS_masters: "xyops01.internal.example.com"
      TZ: Asia/Tokyo                         # ログのローテーションと日次集計の基準
    volumes:
      - xy-data:/opt/xyops/data
      - ./xyops01-conf:/opt/xyops/conf       # config.json / overrides.json はここ
      - ./xyops01-logs:/opt/xyops/logs
      # - /var/run/docker.sock:/var/run/docker.sock  # 任意。Docker Plugin と Marketplace 用
    ports:
      - "5522:5522"                          # Web UI / API
      - "5523:5523"                          # サテライト接続
volumes:
  xy-data:

起動したら http://<ホスト名>:5522/ を開きます。初期管理者は admin / admin で、初回ログイン時に変更を求められます。ワーカーから見て到達できるかは /health で確認できます。ここが通らないうちにワーカーを追加しても、多くの機能が正しく動きません。

セルフホストで放置しがちな点を、公式の記述に沿って確認コマンドの形にまとめます。以下はいずれも「攻撃の再現」ではなく、自分の環境の状態を読むだけのコマンドです。

# 1. Conductorに到達できるか（ワーカー側から実行する）
curl -fsS http://xyops01.internal.example.com:5522/health && echo " -> reachable"

# 2. 5522/5523 を意図せず外部公開していないか（ホスト側で待ち受けを確認）
ss -ltnp 2>/dev/null | grep -E ':(5522|5523)\b' || netstat -an | grep -E '\.(5522|5523)\b.*LISTEN'

# 3. docker.sock をコンテナに渡しているか（渡していれば実質ホスト権限に近い）
docker inspect xyops-conductor-01 --format '{{range .Mounts}}{{.Source}} -> {{.Destination}}{{"\n"}}{{end}}' | grep -i docker.sock

# 4. 初期パスワードのまま放置していないか（変更済みならログイン画面で admin/admin が弾かれる）
#    設定の実体はマウントした conf ディレクトリ側にある
ls -la ./xyops01-conf/ && grep -c "secret_key" ./xyops01-conf/config.json

本番前のハードニングは、Webサーバー層の設定が中心です。公式の scaling.md は「Security Checklist」として、プラグインを非特権ユーザー／グループで動かす（default_plugin_credentials でプラグイン種別ごとに既定のUID/GIDを指定できる。Marketplace由来のプラグインは自前のUID/GIDを指定できず、必ずこの既定が使われる）、受信IPをCIDRでホワイトリスト化する、有効なHostヘッダを本番ドメインに限定する、HTTPSを有効化して必要ならHTTPからのリダイレクトを強制する、既定1GBのアップロード上限を実態に合わせて下げる、同時接続数・各種タイムアウトを絞ってslow loris系を緩和する、CSP／HSTSなどのレスポンスヘッダを付ける、といった項目を並べています。マルチConductor構成をnginx越しに組む場合のレート制限例（limit_req_zone で100リクエスト/秒/IP）まで載っています。

規模が出てきたときのチューニングどころも明示されています。Node.jsのヒープは NODE_MAX_MEMORY（既定4096MB）で調整、ストレージのRAMキャッシュは既定でおよそ100MB／10万アイテムなので大規模では5〜10倍を検討、毎秒メトリクスのQuickMonやジョブのネットワーク監視は負荷が高ければ無効化できる、履歴は db_maint の max_rows 系で上限を切って無限成長を防ぐ——といった具合です。

弱点・ライセンスと、他ツールとの立ち位置

ここまで機能の話を続けてきたので、採用判断に必要な都合の悪い側を先に並べます。ベンダー資料には載らない種類の情報です。

まずバス係数1。GitHubのコントリビューター一覧はJoseph Huckaby氏のみ（2,934コミット）で、他のコミッターはいません。加えて CONTRIBUTING.md は「機能PRは受け付けない（ただし他の貢献方法はたくさんある）」と明言しています。品質管理としては筋が通っていますが、外部の手が入って継続するタイプのプロジェクトではないということです。反対側の材料として LONGEVITY.md の「常にオープンライセンス・常にOSI承認、rug pullはしない」という誓約と、Cronicleを10年動かしてきた実績があります。どちらを重く見るかは、そのジョブが止まったときに誰が困るかで決まります。

次に若さ。公開は2025年12月末で、この記事の時点で約7ヶ月。156リリースという更新速度は健全さの証拠でもありますが、バージョンが v1.0.85 まで週に何度も動いている状態でもあります。package.json には "private": true が入っており、npmパッケージとして配布する前提ではありません（配布はDockerイメージとサテライトのバイナリ）。商標として xyOps™・xySat™・PixlCore™ が主張されているため、フォークして別名で配る場合はBSD-3-Clauseとは別に商標の扱いを確認する必要があります。

AI関連の位置づけも正直に書きます。 xyOpsはLLMやAIエージェントの機能を持ちません。リポジトリのファイル構成を見ても、AI・LLM・MCP関連の実装は見当たりませんでした。一方で、任意の言語のスクリプトをJSON over STDIOで実行し、シークレットを環境変数として配り、同時実行数・CPU・メモリの上限とリトライを持ち、失敗時に通知とチケットを出す——という性質は、AIエージェントのバッチ処理を並べる実行基盤としても設計上は噛み合います（本記事では実機で検証していないため、ここは公式ドキュメントの機能記述から読み取れる範囲の話です）。AIワークフローそのものをノードで組みたいなら n8n とは？始め方・使い方・AIエージェント自動化まで実例で解説する定番ワークフローOSS完全ガイド のようなAIノードを持つツールのほうが直接的です。

他ツールとの関係については、リポジトリ内に compare.md という109KBの比較ドキュメントがあり、n8n・Rundeck・Inngest・Windmill・Kestra・Trigger.dev・Prefect・Make・Zapier の9製品を対象に、ポジショニング・機能モデル・有料ティア・サポート・運用カバレッジ・公平なユースケースまで章立てで並べています。ただしこれはxyOps側が書いた対抗比較であり、中立な第三者評価ではありません。競合の価格や機能ゲートの記述をこの文書だけを根拠に引用するのは避けるべきで、本記事でも競合の料金には踏み込みません。読む価値があるのは「xyOps自身が、自分の得意分野をどこに置いているか」という主張の部分です。要約すると次の整理になります。

参照ソース

・pixlcore/xyops（公式リポジトリ・README） — 製品定義、無料/有料ティアの説明、公式動画・コミュニティのリンク、BSD-3-Clauseライセンス表記
・xyOps 公式ドキュメント（docs.xyops.io） — Getting Started・Triggers・Limits・Monitors・Alerts・Snapshots・Tickets・Servers・Workflows・Plugins・Hosting・Storage・Scaling・Trust・Cronicle移行の各章（リポジトリ内 docs/ の53ファイルと同一内容）
・pixlcore/xyops CHANGELOG.md — 156バージョン分のリリース履歴と v1.0.85（2026年7月22日）の内容
・jhuckaby/Cronicle（前身プロジェクトの公式リポジトリ） — 同一作者・2016年公開、2026年7月時点でも更新が続いていることの確認
・xyOps Overview（PixlCore公式YouTube） — ワークフローエディタ・サーバー一覧・ジョブのライブログの実画面