osFoundry / Platform
アプリcronジョブ
アプリ単位で繰り返しタスクをスケジュール。cron記法、リトライ、観測可能な実行。
概要
アプリのcronジョブを使うと、osFoundry内の特定のアプリに対して定期的な処理をスケジュールできます。スクリプトを起動しっぱなしにしたり、手作業で実行を思い出したりする代わりに、アプリそのものにスケジュールを紐づけて、決めた間隔で自動的に走らせます。各ジョブは標準的なcron構文で定義するため、`0 * * * *` は1時間ごと、`30 6 * * 1-5` は平日の6:30に実行されます。スケジュールがアプリに属しているので、ジョブの実行に必要なもの、つまりロジックや環境、鍵は、別に切り離されたスケジューラーではなくアプリと一緒に移動します。
内部では、スケジュールされた各実行が観測可能な単位として扱われます。実行が失敗すると、ジョブは処理を黙って捨てるのではなくリトライし、すべての試行が記録されるので、何がいつ走り、成功したかどうか、何を生成したかを確認できます。この実行履歴があるかどうかが、発火しているはずと期待するだけのcron行と、実際に検証できるスケジュールとの違いになります。osFoundryはBYOK（自分の鍵を持ち込む）方式のデスクトップワークスペースなので、これらのジョブは自分のAPIキーで接続したモデルやサービスに対して実行されます。定期ジョブにかかるコストに再販業者のマージンは乗りませんし、ワークスペースがローカルファーストである以上、アプリとそのスケジュールはベンダーのサーバーではなく自分のデバイス上に置いておけます。
これが最も効くのは、アプリにたまっていく地味で反復的な作業です。決まった間隔でデータを取り込む、出力を作り直す、チェックを走らせる、タイマーでエージェントのタスクを起動する、といった処理です。cronは「いつ」を精密に制御し、リトライは一時的な失敗に対してスケジュールを頑健にし、実行ログは全体を監査可能にします。これはosFoundryの他の要素、つまりチャットとエージェント、アプリ、コード、ナレッジとデータのすぐ隣に位置するため、スケジュールされたアプリのジョブは、独立した自動化のサイロではなく、すでに使っている同じワークスペースに結果を流し込めます。
主な機能
- 標準的なcron構文でスケジュールを定義。単純な1時間ごとの実行から、平日のみや月境界の式まで表現できます
- スケジュールを特定のアプリに紐づけ、そのロジックと環境、鍵を一つの単位としてまとめて実行します
- 失敗した実行を黙って捨てるのではなく、自動でリトライします
- 観測可能な実行履歴。各実行の時刻、ステータス、出力を確認し、スケジュールが実際に発火したことを裏付けられます
- BYOKかつローカルファースト。自分で接続したモデルと鍵に対してジョブが走り、席課金も再販マージンもありません
活用例
- データエンジニア: cronでアプリを1時間ごとに走らせてデータセットを取得・更新し、実行ログで各同期の完了を確認する
- 運用リード: 平日の朝にアプリのジョブでレポートを再生成し、ソースが一時的に使えなくても自動でリトライさせる
- 個人開発者: 夜間のcronに定期エージェントタスクを載せ、自分のマシン上で自分のAPIキーを使って定型作業を無人で走らせる
よくある質問
osFoundryはどのcron構文を使いますか？
標準的なcron式です。分、時、日、月、曜日の5つのフィールドで指定します。したがって `0 * * * *` は毎時0分、`30 6 * * 1-5` は平日の6:30に実行されます。スケジュールはアプリごとに設定します。
スケジュールされた実行が失敗するとどうなりますか？
ジョブは処理を黙って捨てるのではなくリトライし、すべての試行がアプリの実行履歴に記録されます。どの実行が成功し、どれが失敗し、それぞれが何を生成したかを確認できます。
ジョブはどこで実行され、コストはどうなりますか？
osFoundryはローカルファーストでBYOK方式のデスクトップワークスペースなので、スケジュールされたアプリのジョブは、自分のAPIキーで接続したモデルやサービスに対して実行されます。その利用に再販マージンは乗らず、スケジューリングのための席課金もありません。