VTIGER CRM OSS STANDARD GUIDE
自動処理を動かすには、
「定期的に起動する仕組み」も必要です。
「メール通知を設定したのに届かない」「メールコンバーターは手動なら動く」。こうしたときは、業務の設定に加えて、自動処理を定期的に動かす仕組みも確認します。
Vtiger CRM OSSでは、サーバー側のcronと、CRM側のスケジューラーが組み合わさり、実行対象の処理を確認します。cronはCRMを定期的に起動し、スケジューラーは登録された処理の状態や間隔をもとに実行を管理します。
この記事でわかること
cronとスケジューラーの役割の違い、実行間隔の考え方、設定画面で見る項目、自動処理が動かないときの確認順を図解します。
対象：Vtiger CRM OSS 8.4系の標準実装。画面名・翻訳・ジョブの一覧は、導入環境や設定により異なります。cronは主にLinux系サーバーの仕組みとして説明し、図・時刻は理解のための例です。
1. cronとスケジューラーの違い
二つはどちらも時間に関係しますが、役割が違います。cronは「定期的に呼び出す側」、スケジューラーは「呼び出されたときに、どの処理を実行するか判断する側」と考えるとわかりやすくなります。
cron：定期的にCRMの実行入口を呼び出す
設定した周期で、Vtigerの定期処理を起動する。
スケジューラー：状態・間隔・順序を確認する
登録されたジョブを確認し、実行できるものを動かす。
| 確認する場所 | 主な役割 | 設定・確認する人の例 |
|---|---|---|
| サーバー側のcron | 決まった周期で、CRMの定期処理を起動する。 | サーバー管理者、保守担当者 |
| CRM側のスケジューラー | 各ジョブの有効・無効、実行間隔、順序、開始・終了の記録等を管理・確認する。 | CRM管理者 |
| 各機能の業務設定 | どの条件で、何をするかを決める。例：メールの受信条件や通知の宛先。 | CRM管理者と業務担当者 |
CRM画面でジョブを有効にしても、サーバーから起動されなければ定期処理は進みません。逆に、cronが動いていても、対象ジョブが無効だったり、処理するデータがなかったりすると、期待した結果は出ません。
2. どのような自動処理を動かすか
スケジューラーには、導入された機能に対応するジョブが登録されています。主な例を、業務の動きと合わせて見てみましょう。
| ジョブの例 | 主な役割 | 結果として確認すること |
|---|---|---|
| Workflow | 待ち行列に入ったワークフロータスクや、日時指定のワークフロー等を処理する。 | 対象・実行時点・条件に合うタスクが処理されたか。 |
| SendReminder | 予定等で設定された、対象のメールリマインダーを処理する。 | 通知対象や時間設定に合い、メールが届いたか。 |
| MailScanner | メールコンバーターで設定したメールボックスをスキャンする。 | 条件に合う受信メールが、作成・更新等につながったか。 |
| RecurringInvoice | 受注の定期請求設定等に基づき、対象の請求レコードを作成する。 | 対象期間・周期に合う請求が作られたか。作成と顧客への送信は分けて確認する。 |
ワークフローのすべてが、同じタイミングで動くわけではありません。
標準には、保存時等にその場で実行するタスクと、待ち行列へ入れて後から処理するタスクがあります。「ワークフローを作ったら全部cron待ち」とまとめず、タスクの種類と設定を確認します。
また、スケジューラーは任意の業務処理を文章で登録する画面ではありません。基本は、機能やモジュール側で用意・登録されたジョブを管理するものです。追加の自動処理が必要なら、標準ワークフローで対応できるか、拡張が必要かを整理します。
3. スケジューラー画面の見方
管理者がCRM設定の「Scheduler」「スケジューラー」等を開くと、ジョブの一覧を確認できます。有効状態だけでなく、開始・終了の記録が更新されているかも見ましょう。
| 項目 | 意味・確認すること |
|---|---|
| ジョブ名 Cron Job | 何の定期処理か。業務機能と対応させて確認する。 |
| 実行間隔 Frequency | CRM側で、そのジョブをどのくらいの間隔で実行対象にするか。時・分の表示は、特定の時計時刻とは分けて読む。 |
| 状態 Status | 有効・無効・実行中等。参照した8.4系にはエラー状態を扱う処理もある。 |
| 最終開始 Last Start | 直近にジョブが開始した記録。起動のたびに全ジョブの値が変わるとは限らない。 |
| 最終終了 Last End | 直近にジョブの終了処理へ到達した記録。メール到達や業務上の成功件数を直接表すものではない。 |
| 順序 Sequence | 登録されたジョブを確認・実行する順序。前の処理の時間や停止が、後ろの処理へ影響する場合がある。 |
通常の終了処理では、実行中の状態から有効状態へ戻る実装です。長く「Running」のままの場合は、実際に処理が続いているのか、途中で止まった記録が残っているのかを分けて確認します。
一覧の時間表現や状態の表示は、翻訳・設定・版で異なります。編集できる間隔には画面側の下限等があるため、設定できる範囲を確認して変更します。
4. 二つの実行間隔を理解する
cronの起動間隔と、CRM内のジョブの実行間隔は別の設定です。cronが頻繁に呼び出しても、ジョブは毎回動くとは限りません。逆に、cronの起動が少なければ、CRM側だけ短くしても、その間に処理は始まりません。
概念例：cronは5分ごと、あるジョブの間隔は15分。09:00に開始済みで、短時間で終了したと仮定します。
cronが起動
ジョブの間隔に
まだ達していない
cronが起動
再び状態と
経過時間を確認
cronが起動
状態・間隔等の
実行条件を満たす
たとえば、CRM側で15分の間隔にしていても、サーバーからの起動が1時間ごとなら、15分ごとに確認する機会はありません。自動処理を早くしたいときは、両方の設定と、実際にかかる処理時間を合わせて見直します。
業務側の「何時に実行するか」「いつから処理可能か」も別にあります。予約されたタスクは、その時刻を迎えてから定期処理で拾われる場合があるため、指定時刻と実際の処理時刻に差があることを前提に設計しましょう。
5. 設定から結果確認までの進め方
自動処理は、サーバーとCRMの設定をつなぎ、実際の業務結果まで確かめて完了にします。
- 動かしたい業務とジョブを対応させる
受信メールの取り込み、リマインダー、待ち行列のメール通知等、目的を一つ決めます。対応するジョブと、機能側の条件・対象データを確認します。
- サーバー側の定期起動を設定する
サーバー管理者が、実行ユーザー、起動周期、実行するPHP、CRMの設置先等を確認します。標準のcron/vtigercron.shは、CRMのディレクトリへ移動し、PHPでvtigercron.phpを実行する構成です。
- CRM側の状態・間隔を確認する
必要なジョブを有効にし、画面で設定できる間隔と順序を確認します。短くする場合は、処理量と実行時間を見ながら調整します。
- 少数の対象で、起動から処理まで試す
管理者が実行出力やログを確認し、該当ジョブの開始・終了と、レコード作成・更新・メール到達等を確かめます。手動実行も実データを処理するため、対象を把握して行います。
- 次の自動起動でも動くことを確認する
手動で一度動いたことだけで終わらず、定期起動で新しい対象を処理できるか確認します。止まったときに見る場所と、相談する担当も決めておきます。
Web画面と、cronから使うPHPは同じとは限りません。
ログインや画面操作ができても、定期実行側でPHPの版・拡張・設定ファイル・権限等が異なると処理が失敗することがあります。実際にcronが使う環境で確認します。
OSやホスティング環境によって、cronに相当する設定方法は異なります。Windows等ではタスクスケジューラなど、環境に合った定期起動方法を管理者が確認します。本文は個別サーバーへそのまま適用する設定コマンドの手順ではありません。
6. 動かないときの確認順
「自動処理が動かない」を一つの問題にせず、起動・ジョブ実行・業務結果の三つに分けると、確認する場所を絞れます。
起動したか
サーバー側を見る定期起動の記録、実行パス、
PHP、ユーザー、権限を確認。
ジョブが動いたか
CRMと実行ログを見る有効状態、間隔、実行中、
開始・終了、エラーを確認。
仕事が進んだか
機能と結果を見る対象データ、条件、宛先、
保存内容やメール到達を確認。
| 症状 | 最初に確認すること |
|---|---|
| 複数のジョブの記録が古い | サーバーからの起動自体が続いているか。実行パス、PHP、DB接続等の共通部分。 |
| 特定のジョブだけ動かない | 無効状態、間隔未到達、実行中の記録、そのジョブ固有のエラーや対象データ。 |
| Runningが長く続く | 実プロセス、開始時刻、処理量、実行ログ。動作中なのか、異常終了の記録なのか。 |
| 終了記録は新しいが結果がない | 処理する対象があるか、機能側の条件・予定時刻・宛先・接続先が正しいか。 |
| 手動なら動く | 自動起動時の実行ユーザー、PHP・拡張、作業ディレクトリ、権限と実行周期。 |
| 動くが遅い・処理が重なる | サーバー起動間隔とジョブの間隔、処理時間、先行ジョブ、定期起動の二重登録等。 |
標準の実行入口には、「すでに実行中」「まだ実行間隔に達していない」等の場合に見送る処理があります。ログの見送り表示は、必ずしも異常とは限りません。
Runningの表示だけを見て、すぐに再実行しないようにします。
実際の処理が残っていると、同じ仕事を重ねて行う可能性があります。プロセスとログを確認し、原因や処理済み範囲を把握してから、復旧方法と再実行の対象を決めます。
確認を依頼するときは、「どのジョブが」「いつから」「期待した何が起きないか」と、直近の開始・終了・実行ログをそろえると、対応を進めやすくなります。
7. よくある質問
Q. スケジューラーを有効にすれば、自動処理は動きますか？
サーバーから定期的にCRMの実行入口を呼び出す設定も必要です。CRM側の有効状態だけでなく、サーバー側の起動と実行記録を確認します。
Q. cronが起動するたびに、全ジョブが動きますか？
各ジョブの状態や経過時間等を判定します。無効、すでに実行中、間隔に達していない場合等は見送られるため、起動回数と実行回数は一致するとは限りません。
Q. 実行間隔は、短くするほどよいのでしょうか？
必要な反映時間と処理量に合わせて決めます。サーバー起動の周期や実行時間も関係するため、CRM側だけ短くしても期待どおりに速くなるとは限りません。
Q. ワークフローの処理は、すべてcron待ちですか？
標準には即時実行するタスクと、待ち行列へ入るタスクがあります。使っているタスクの種類、実行条件、遅延や日時指定の設定を確認します。
Q. 最終終了が新しければ、メール送信も成功していますか？
終了記録はジョブの終了処理へ到達したことを示す情報です。対象がなかった場合もあるため、タスクの結果、送信設定、宛先と到達を別に確認します。
Q. ブラウザでcronのURLを開けば、定期実行の代わりになりますか？
標準にはCLI実行や認証状態の判定があります。URLを一度開くことは、継続した定期起動の設定にはなりません。サーバー管理者が、環境に合う起動方法を設定します。
Q. 停止していた間の処理は、再開すればすべて補われますか？
対象や再実行の扱いはジョブごとに異なります。再開前に、未処理の待ち行列、対象期間、すでに作成・送信された内容を確認し、処理漏れと重複を見直します。
8. 自動処理を、日々の業務で使える仕組みへ
自動処理は、条件を作るだけでなく、動かす環境、実行の記録、結果の確認までそろえて運用します。「何を自動化するか」と「止まったら誰が気付くか」を合わせて決めることが大切です。
業務に合うタイミングへ
すぐに必要な処理と、定期的でよい処理を整理し、反映時間と処理量に合う設定を考えます。
結果を確認できる運用へ
開始・終了だけでなく、担当者が見る情報や通知、止まったときの確認先も整えます。
vtplusは、Vtiger CRM OSSを基盤に、自社の業務に合わせた活用を支援するサービスです。標準のワークフローやメールコンバーター等を活かしながら、処理の条件・タイミング、担当者への通知、結果の確認方法、運用や保守の役割分担を整理できます。追加の自動化や状況の見える化が必要な場合も、要件に合わせて対応方法を検討します。
「通知が届くまで時間がかかる」「手動なら動くが、自動では動かない」。そんな課題から、業務設定と動作環境をつないで見直してみませんか。
NEXT STEP
自動化の設定を、
日々、仕事が進む仕組みへ。
「何を、いつ動かす？」「結果をどこで確認する？」「止まったときは誰が対応する？」。自社の自動処理と運用を整理するところから、相談できます。