Business Central のイベントとトリガーの違い（AL）：開発者のためのタイミングガイド

By Mirko Peters · 2026-08-22

AL でカスタムのビジネスロジック、検証、転記チェックを実装する際に、トリガーとイベントサブスクライバーをいつ使い分けるかを理解し、Business Central AL 開発を使いこなしましょう。

Automatically translated with AI from the original post. Read the English original

Microsoft Dynamics 365 Business Central の AL 開発において、トリガーとイベントの違いを理解することは、保守しやすくクリーンな拡張機能を書くうえで欠かせません。適切な実行の仕組みを選ぶことで、検証ルールを正しいタイミングで実行でき、不正なデータ入力を防ぐとともに、標準アプリケーションのコードを複製することなく、クラウドの更新をスムーズに保てます。

重要なポイント

• トリガーは特定の AL オブジェクトに組み込まれており、オブジェクトのイベントやデータ変更が発生した時点で、すぐにコードを実行します。
• イベントサブスクライバーを使うと、標準アプリケーションのコードを変更したり、大量のネイティブ処理をコピーしたりすることなく、拡張機能からシステム全体の通知を受け取れます。
• 「on before」と「on after」のどちらのイベントを選ぶかによって、カスタムコードがトランザクションを阻止できるか、完了したアクションに反応するだけかが決まります。
• 適切なタイミングで処理すると、検証ルールがエラーを早期に検出できる一方で、販売注文の転記など負荷の高い処理中のパフォーマンス低下も防げます。

Business Central におけるカスタムロジックのアーキテクチャ

Microsoft Application Language（AL）を使って Dynamics 365 Business Central を拡張する場合、コードを書くことは課題の半分にすぎません。本当の難しさは、そのコードをどこで、いつ実行させるかを決めることにあります。顧客レコードに簡単なリワードレベルのフィールドを追加する場合も、請求書の作成前に複雑なコンプライアンスチェックを適用する場合も、拡張機能の長期的な安定性は、システムにどのようにフックするかによって決まります。

従来の開発モデルでは、標準アプリケーションのコードを直接書き換えることがよくありました。ドキュメントの転記前にチェックを実行したい場合は、コアの転記ルーチンに直接ロジックを挿入していたのです。その方法は一時的には機能しましたが、Microsoft の主要な更新のたびに、大変な調整作業が発生していました。現在の Business Central 拡張機能の開発は、モジュール式のアプリベースのモデルに基づいています。標準ルーチンを書き換える代わりに、開発者は組み込みの接続ポイント（具体的にはトリガーとイベント）を使い、標準アプリケーションのコードと安全に組み合わせてカスタムロジックを実装します。

AL トリガーを理解する

トリガーとは、特定の操作が行われたときに自動的に実行されるコードを記述できる、AL オブジェクト内の定義済みの場所です。テーブル、テーブル拡張、ページ、ページ拡張、レポート、コードユニットなど、標準オブジェクトとカスタムオブジェクトの両方に、こうしたネイティブの箇所が用意されています。

実際の例を考えてみましょう。組織が顧客レコードにカスタムの Reward ID フィールドを追加したとします。ユーザーがドロップダウンリストからリワードレベルを選択したときに、顧客アカウントがブロックされていないか、または付随する属性を更新する必要があるかをすぐに確認させたいとします。その特定のフィールドに対して OnValidate トリガーを使用すると、ユーザーが変更を加えた瞬間にコードが実行されます。

トリガーを使うべき場合

トリガーは、業務ロジックが単一のオブジェクトとその直近のコンテキストだけに属する場合に使うのが最適です。たとえば次のような場合です。

• カスタムの日付フィールドが、許容される事業四半期の範囲内にあることを検証する。
• 新規レコード用のカードページが開いたときに、初期化処理を実行する。
• 主要なオプションの選択が解除されたときに、依存するフィールドの値をクリアする。

トリガーはホストとなるオブジェクトに厳密にスコープされるため、局所的なコードは見つけやすく、読みやすく、長期にわたって保守しやすい状態を保てます。

Business Central のイベントとサブスクリプションを活用する

トリガーは局所的な処理を担いますが、売上伝票の転記、在庫の出荷、財務仕訳の生成といった複数のステップからなる大規模なプロセスには、より高度なアプローチが必要です。大規模な転記ルーチンの途中に検証コードを単純に差し込むと、拡張機能モデルを壊してしまいます。

ここで役立つのが、イベントとイベント サブスクライバーです。イベントは、標準の Business Central アプリケーションが発行する公式の通知と考えてください。システムは、'レコードが挿入されようとしている' や '販売伝票が転記されようとしている' といった重要な節目を通知します。拡張機能は、イベント サブスクライバー プロシージャを使ってこれらの通知を受け取ることができます。

Business Central が指定されたイベントを発行すると、サブスクライブしているプロシージャが起動し、カスタムのルールを実行して、処理を続行させるか、わかりやすいエラーメッセージを表示して停止させます。重要な点として、拡張機能が基盤となる転記エンジンをコピー、貼り付け、書き換えする必要はありません。

タイミングの重要性: OnBefore と OnAfter の違い

AL でイベント サブスクライバーを作成するときは、命名規則によって実行タイミングがわかります。このタイミングを理解することは、システムの信頼性にとって極めて重要です。

• OnBefore イベント: 標準の処理が完了またはコミットされる直前に実行されます。ブロック処理や検証チェックを行うのに理想的な位置です。売上伝票に必須のコンプライアンス文書が不足している場合、OnBefore の転記イベントでその不備を検出し、トランザクションを中止して、役立つ警告メッセージを表示できます。
• OnAfter イベント: 標準の処理が正常に完了した直後に実行されます。完了した処理に反応する必要がある場合に使用します。たとえば、フォローアップのタスクを自動作成する、外部のログ テーブルを更新する、注文の転記が完了したらアカウント マネージャーに通知する、といった用途です。

実行が遅すぎるルールでは不正なトランザクションを防げず、実行が早すぎるルールでは標準ルーチンで計算される必要なデータがまだ揃っていない可能性があります。ロジックを適切なイベントのシグネチャに対応づけることで、こうした落とし穴を回避できます。

まとめ

オブジェクト トリガーとイベント サブスクライバーのバランスを習得すると、Business Central 拡張機能への取り組み方が変わります。フィールドの検証には局所的なトリガーを、システム全体にかかわるプロセスにはイベント サブスクライバーを活用することで、クラウドの更新に対して カスタマイズを堅牢に保ちつつ、環境の高速性と安全性も維持できます。

モダンなアプリケーション設計の原則について詳しく知り、エキスパートによるアーキテクチャの解説を聞くには、M365 FM Podcast の エピソード全編を聴いてください。クラウド アーキテクトや開発者が、実際のビジネスで成果を出すために Microsoft エコシステムをどのように最適化しているかをぜひご覧ください。

よくある質問

AL におけるトリガーとイベント サブスクライバーの主な違いは何ですか？

トリガーは、特定の AL オブジェクト (テーブルのフィールドやページなど) の内部に直接組み込まれた、事前定義のコード実行ポイントです。一方、イベント サブスクライバーは、拡張機能内にある独立したプロシージャで、ベース アプリケーションや他のオブジェクトが公開する通知を受け取ります。元のコードを変更する必要はありません。

イベント サブスクライバーで販売伝票の転記を阻止できますか？

はい。転記処理に紐づく 'on before' イベント サブスクライバーを使えば、カスタムコードで業務条件を評価し、エラーメッセージを表示して、転記ルーチンがエントリを確定する前にトランザクションを停止できます。

イベント サブスクライバーの代わりにテーブル フィールドの検証トリガーを使うべきなのはどのような場合ですか？

業務ルールが、特定のフィールドの値の変更にのみ厳密に関連している場合は、テーブル フィールドの検証トリガーを使用します。たとえば、カスタムの Reward ID が存在するかどうかを確認する場合や、ユーザーの入力直後に関連するステータス フィールドが即座に更新されるようにする場合です。

AL でイベント サブスクライバーを作成する際、実行タイミングがなぜ重要なのですか？

実行タイミングによって、コードが中核となる処理の完了前に動くか完了後に動くかが決まります。ルールが早すぎるタイミングで動くと、必要なデータがまだ設定されていない可能性があります。逆に遅すぎるタイミングで動くと、無効なトランザクションをブロックする機能を失ってしまいます。