はじめに
OutSystemsでは、Aggregate・カスタムSQL・サーバーアクションなどに対して、処理結果を一時的に保持するキャッシュ機能Cache in Minutes が提供されています。
本記事では、OutSystems公式ドキュメントおよびフォーラムの情報を参考に、Cache in Minutes の基本仕様やキャッシュの破棄条件、実運用上の留意点を整理します。
Cache in Minutes の概要
Cache in Minutes は、クエリやアクションの実行結果を指定時間（分単位）キャッシュとして保持する設定です。Aggregate・Advanced SQL・サーバーアクション等で使用可能で、再実行時のパフォーマンス改善やデータベース負荷の軽減に効果があります。
設定された時間内は、同一の入力パラメータに対して前回の実行結果を返すため、DBアクセスを省略できます。
設定可能な最大値について
公式ドキュメント上は Cache in Minutes の最大値に関する明記はありません。ただし、OutSystemsフォーラムでは .NET における int.MaxValue（= 約2,147,483,647分、約4100年）まで設定可能とのやりとりがあります。
💬 OutSystemsフォーラム：「Maximum number for Cache in Minutes」
一方で、たとえ極端に長い値を設定したとしても、後述のようにシステム都合でキャッシュが破棄されることがあるため、設定値＝保証期間とは限りません。
キャッシュが破棄される条件
Cache in Minutes を設定していても、以下の条件に該当する場合はキャッシュが破棄されます。
1. 指定時間の経過（クエリ単位）
最も基本的な挙動です。設定された時間を過ぎると、対象クエリやアクションのキャッシュは自動的に無効になります。
2. モジュールのパブリッシュ（モジュール単位）
モジュールの再パブリッシュ時には、そのモジュールに関連付いたすべてのキャッシュが削除されます。開発や本番デプロイ時にはこの挙動を意識しておく必要があります。
3. InvalidateCache の呼び出し（モジュール単位）
InvalidateCache を呼び出すことで、対象モジュールのキャッシュを明示的に破棄できます。データ更新後の整合性確保の手段として有効です。
4. フロントエンドメモリの不足（クエリ単位）
キャッシュはFE（Front-End）サーバーのメモリ上に保持されており、メモリ不足が生じた場合、使用頻度の低いキャッシュから優先的に破棄されます。設定された保持時間内でもキャッシュが削除される可能性があるため、この点は特に留意が必要です。
キャッシュの保存場所とスコープ
キャッシュは各フロントエンドサーバーの メモリ 上に保存されます。OutSystemsのロードバランサー構成下では、ユーザーからどのサーバーが利用されるかは透過的に管理されており、開発者が保存先を意識する必要は基本的にありません。
また、キャッシュは ユーザー単位ではなく、アプリケーション単位（FE間で共有） で扱われるため、同一ユーザーがアクセスしているからといって、常に同じキャッシュが参照されるとは限りません。
運用上の留意点
実務において Cache in Minutes を利用する際は、以下の点を念頭に置いて設計・実装することを推奨します。
-
キャッシュは永続的ではない
FEの再起動やパブリッシュ時にキャッシュは破棄されるため、長期的な保持や永続性のあるキャッシュ用途には向きません。 -
リアルタイム性が求められるデータには不向き
キャッシュを通じて古いデータが返される可能性があるため、常に最新データが必要な処理では設定を避けるべきです。 -
InvalidateCache との併用を検討する
DB更新処理の直後などでは、InvalidateCacheによりキャッシュを明示的に破棄することで、表示データとの整合性が保てます。
参考リンクまとめ
まとめ
Cache in Minutes は、OutSystemsアプリケーションにおけるパフォーマンス最適化手段のひとつとして有効ですが、挙動を正しく理解したうえで運用することが重要です。
設定値どおりにキャッシュが残り続けるとは限らない点や、共有キャッシュであること、フロントエンドのリソースに依存することなどを踏まえ、用途に応じた設計と制御の実装を行うことが、トラブルの防止と品質向上につながります。