ジョブを時間で動かすのではなく、目標達成まで動かす

AIを業務に入れると、最初は「毎日何時に実行するか」を考えがちです。

たとえば、朝に商品登録をする。昼にレポートを作る。夜にブログや動画を生成する。
従来のシステム運用では、cronのような定時実行が自然な考え方でした。

しかし、AIワーカーを事業で使い始めると、定時実行だけでは足りません。

大事なのは「何時に動いたか」ではなく、「今日の目標を達成したか」です。

今回、社内で使っているAIジョブ運用を見直し、192.168.0.2で動いていたHermesの時刻ベース実行から、192.168.0.3を統合管理サーバとするkdeck + RQDB4AIの目標達成型運用へ移行しました。

定時実行は、起動しただけで満足しやすい

定時実行の問題は、ジョブが「起動した」ことと、事業上の「成果が出た」ことが混ざりやすい点です。

たとえばAIxECの商品登録なら、ジョブが動いたこと自体には意味がありません。

必要なのは、未登録の商品が実際に登録されたか。
ランキングや候補が取得できたか。
APIで弾かれていないか。
登録件数が目標に届いたか。

Horizonなら、動画生成ジョブを起動しただけでは足りません。
記事ができ、動画ができ、YouTubeに投稿され、AIxSNSで告知されて、初めて業務として完了です。

つまり、AIワーカー運用では「起動ログ」ではなく「成果ログ」を見る必要があります。

.3を統合管理サーバにした理由

今回の構成では、192.168.0.3をkdeck統合管理サーバにしました。

kdeckは、スマホやPCからAIエージェント、ジョブ、各サーバの状態を見るための入口です。
RQDB4AIは、実際にジョブをキューへ入れて、workerで処理するための実行基盤です。

役割を整理すると、次のようになります。

kdeck: 何を達成したいかを見る司令塔画面
RQDB4AI: ジョブを安全に並べて実行するキュー基盤
各アプリ: AIxEC、URL2AI、Horizon、buzbloggerなどの実処理ロジック
各サーバ: Ollama、API、動画生成など、それぞれの得意領域を担当

以前は、192.168.0.2のHermesが時刻になったらジョブを投入する形でした。

これは単純でわかりやすい一方、事業目標を見ていませんでした。

朝9時にmarket-pipelineを動かした。
でも500件登録できなかった。
APIが403で弾かれた。
Ollamaが混んでいた。
それでも次の時刻まで待つ。

この運用では、事業が進みません。

目標達成型のジョブ運用に変える

今回の考え方は、定刻ではなくGoalです。

たとえばmarket-pipelineなら、1日の目標を新規2000件とします。

1回で500件を狙う。
500件に届かなければ、別ジャンルや別条件で再実行する。
ただし、楽天APIやOllamaへ負荷をかけすぎないようにcooldownを挟む。

そして、market-pipelineがcooldown中なら、他のジョブを止める必要はありません。

つまり、

目標未達なら再実行する
実行中なら重複投入しない
cooldown中なら別の仕事を進める
成果が出た件数を記録する
失敗理由を残す

という運用です。

これは、人間のマネージャーに近い考え方です。

「9時だから作業する」ではなく、「今日の目標が終わっていないから、次に何をすべきか考える」という形です。

経営者にとって重要なのは、AIが働いているかではなく、会社が前に進んでいるか

AI活用の現場では、AIが動いているだけで安心してしまうことがあります。

しかし経営者が見るべきなのは、AIの稼働時間ではありません。

見るべきなのは、事業の前進です。

商品が増えたか
記事が公開されたか
動画が投稿されたか
SNS告知が出たか
エラーが解消されたか
未達の理由がわかるか

このように、AIワーカーの成果を経営指標に近づけていく必要があります。

kdeckとRQDB4AIを組み合わせることで、AIジョブを単なる自動実行ではなく、目標達成のための業務運用に近づけられます。

AIエージェントは万能ではない。だから運用基盤が必要

今回の移行では、Hermes agentの使い方についても見直しが必要だとわかりました。

Hermesを単なるcronの代わりに使うだけでは意味がありません。

本来、AIエージェントに期待したいのは、状況を読んで、失敗理由を考え、必要なら別サーバの担当エージェントへ調査を依頼するような判断です。

一方で、日々の基本的な自動運転は、安定したPython runnerで行う方が確実です。

そのため、現時点では次のように整理しました。

通常運転: Python runnerがRQDB4AIへジョブを投入し、結果を監視する
実行基盤: RQDB4AIがジョブをキューで管理する
状態画面: kdeckがGoal、進捗、実行中ジョブを表示する
AI判断: HermesやOpenClawは、未達や障害時の調査・作戦変更に使う

AIにすべて任せるのではなく、AIが力を発揮しやすい場所と、機械的に安定させる場所を分けることが重要です。

これは小さな業務改善ではなく、会社の運転方法の変更

今回の変更は、単にジョブ管理画面を作ったという話ではありません。

会社のシステム運用を「時間で回す」から「目標で回す」へ変える試みです。

営業でも、ECでも、コンテンツ運用でも同じです。

大事なのは、作業予定ではありません。
成果です。

AIワーカーが増えるほど、経営者は「どのAIが動いているか」ではなく、「会社のどの目標がどこまで進んでいるか」を見たくなります。

kdeckとRQDB4AIは、そのための土台です。

AIを導入するとは、単に文章やコードを生成することではありません。

会社の作業を、目標に向かって自動的に進める仕組みを作ることです。

そして、その進み具合を経営者が見て、必要なときに判断できる状態にすることです。

VWorkでは、このようなAI活用を、実験ではなく日常業務の運用として育てていきます。