Microsoft developer platformのAgents関連更新では、2026年5月5日に ArchiveTask メソッドが追加されました。結論から言うと、これは既存のAgent Taskを「削除」する機能ではなく、Agent Task レコードの Archived フラグを立てて運用上の整理に使いやすくする変更です。現時点では OnPrem スコープのため、主にBusiness Centralのオンプレミス環境や、オンプレ前提でAgents SDKを拡張しているAL開発者が確認すべき更新です。(GitHub)
Microsoft Learn上のBusiness Central Agents関連ドキュメントはプレビュー機能として説明されており、Agent TaskはALコードから作成・追跡・停止・再開などを行える領域です。今回の ArchiveTask は、そのライフサイクル管理に「アーカイブ」という整理操作を加える位置づけで捉えると分かりやすいでしょう。(Microsoft Learn)
Microsoft developer platformのAgents更新で追加されたArchiveTaskとは
今回の変更は、Microsoftの BCApps リポジトリにあるBusiness Central向けSystem ApplicationのAgents SDKに対する更新です。PRの要約では、AgentTask codeunitに既存タスクをアーカイブする ArchiveTask メソッドを導入し、現時点ではオンプレミス向けにスコープされていると説明されています。(GitHub)
追加された公開側のメソッドは、codeunit 4303 "Agent Task" にあります。
[Scope('OnPrem')]
procedure ArchiveTask(AgentTaskID: BigInteger; UserConfirm: Boolean)引数の意味はシンプルです。
| 引数 | 型 | 意味 | 実務での見方 |
|---|---|---|---|
AgentTaskID | BigInteger | アーカイブ対象のAgent Task ID | External IDではなく、タスクレコードのIDを渡す |
UserConfirm | Boolean | 確認ダイアログを表示するか | 画面操作なら true、バッチ処理なら慎重に false を検討 |
内部実装では、対象の Agent Task レコードを取得し、すでに Archived = true の場合は何もせず終了します。未アーカイブの場合は、必要に応じて確認ダイアログを表示したうえで Archived := true にし、レコードを更新します。(GitHub)
重要なのは、ArchiveTask はタスクのステータスを Stopped や Completed に変えるメソッドではない点です。あくまでアーカイブ状態を示すフラグを更新する操作として理解してください。
何が変わったのか
今回の変更点を、開発者が確認しやすい形で整理すると次の通りです。
| 項目 | 変更内容 | 確認すべきポイント |
|---|---|---|
| 追加メソッド | Agent Task codeunitに ArchiveTask が追加 | 自社拡張で利用できるシンボルに含まれているか |
| 対象 | 既存のAgent Task | 新規作成ではなく、既に存在するタスクの整理に使う |
| スコープ | [Scope('OnPrem')] | SaaS環境向け拡張で前提にしない |
| 処理内容 | Archived フラグを true に更新 | 削除・停止・再実行制御とは分けて扱う |
| 冪等性 | 既にアーカイブ済みなら終了 | 二重実行してもエラーになりにくい設計 |
| テスト | 停止済みタスクのアーカイブ、アーカイブ済みタスクの再アーカイブが追加 | 自社側でも状態別テストを追加する |
PRでは3ファイルが変更され、AgentTask.Codeunit.al、内部実装の AgentTaskImpl.Codeunit.al、テスト用の AgentTaskManagementTest.Codeunit.al に追加が入っています。Files changedでは合計111行の追加として表示されています。(GitHub)
誰が対応すべきか
今回の更新は、すべてのMicrosoft developer platform利用者に影響するものではありません。対象はかなり明確です。
対応優先度が高いケース
次のいずれかに当てはまる場合は、早めに確認してください。
| 対象者・環境 | 対応が必要な理由 |
|---|---|
| Business Centralのオンプレミス環境でAgents SDKを使っている | OnPrem スコープのため、利用候補になる |
| ALでAgent Taskの停止・再開・一覧管理を実装している | アーカイブ処理を標準メソッドに寄せられる可能性がある |
| 独自テーブルでAgent Task IDを保持している | アーカイブ後の表示・検索・再処理ルールを整理する必要がある |
| 管理画面やバッチで古いタスクを整理している | 手動フラグ更新より ArchiveTask 利用を検討できる |
| Version 29.0系の変更を追っている | PRはVersion 29.0マイルストーンに紐づいている (GitHub) |
すぐに対応しなくてよいケース
SaaS環境だけを対象にした拡張、またはAgent Taskをまだ使っていないプロジェクトでは、今すぐコード変更する必要は低いです。ただし、将来的にAgents機能を導入する予定があるなら、「タスクをどう閉じるか」「古いタスクをどう整理するか」は設計段階で決めておくと後戻りを減らせます。
ArchiveTaskを使うべき場面
ArchiveTask が役立つのは、「タスクを履歴として残しつつ、通常の運用対象から外したい」場面です。
たとえば、以下のようなケースです。
| 活用シーン | ArchiveTaskが向いている理由 |
|---|---|
| 処理済みの問い合わせタスクを整理する | 削除せず、履歴として残せる |
| 停止済みタスクを管理画面から片付ける | 再開対象と整理済みを分けやすい |
| 外部システム連携で完了後のタスクを非表示扱いにする | Archived フラグを条件に一覧制御できる |
| 長期運用でAgent Taskが増え続ける | 運用上の棚卸しルールを作りやすい |
一方で、次のような用途では慎重に扱うべきです。
| 避けたい使い方 | 理由 |
|---|---|
| 実行中タスクを無条件にアーカイブする | 実装上の状態不整合や運用混乱を招く可能性がある |
| エラー調査前にアーカイブする | ログ確認や原因分析の対象から見落とすおそれがある |
| 削除の代わりとして扱う | レコード削除ではなく、アーカイブフラグ更新である |
| SaaS拡張でも使える前提で実装する | 現時点では OnPrem スコープ |
実装コードを見る限り、ArchiveTask 自体は「停止済みタスクだけを対象にする」という明示的なチェックを持っていません。ただし、追加テストでは停止済みタスクのアーカイブが確認されています。実務では、画面やバッチ側で「停止済みまたは完了済みだけをアーカイブする」といったガードを入れるのが安全です。(GitHub)
実装時に確認すべきポイント
AgentTaskID と External ID を混同しない
ArchiveTask に渡すのは AgentTaskID: BigInteger です。Business CentralのAgents SDKでは、外部システムとの紐づけに External ID を使う場面がありますが、今回のメソッドに直接渡す値はExternal IDではありません。
メールスレッドID、問い合わせ番号、外部ワークフローIDなどを External ID として管理している場合は、まず該当する Agent Task レコードを取得し、その Id を ArchiveTask に渡す流れになります。
UI操作では確認ダイアログを出す
UserConfirm を true にすると、ユーザー確認を挟めます。管理画面のボタンからアーカイブする場合は、誤操作を避けるため true が基本です。
AgentTaskCU.ArchiveTask(AgentTaskRecord.Id, true);一方、夜間バッチや定期的な整理処理で大量のタスクを処理する場合、確認ダイアログは運用に向きません。その場合は false を使うことになりますが、対象条件を厳しく絞る必要があります。
AgentTaskCU.ArchiveTask(AgentTaskRecord.Id, false);権限と機能アクセスを確認する
公開側の ArchiveTask では、内部処理を呼ぶ前に FeatureAccessManagement.AgentManagementAllowed(true) が呼ばれています。つまり、単にメソッドが存在するだけでなく、実行ユーザーや実行コンテキストがAgent管理操作を許可されているかも確認が必要です。(GitHub)
確認すべき項目は次の通りです。
| 確認項目 | 見るべき内容 |
|---|---|
| 実行ユーザー | Agent管理に必要な権限を持つか |
| 実行元 | UI操作、ジョブキュー、管理用コードユニットのどれか |
| 対象環境 | オンプレミス環境か |
| シンボル | 利用中のアプリ・プラットフォームで ArchiveTask が参照できるか |
| テスト | 権限不足、存在しないTask ID、既にアーカイブ済みのケースを確認したか |
移行の考え方
今回の更新は、新しいメソッドの追加です。既存コードを壊す変更ではないため、通常は「緊急の移行」ではなく「標準APIに寄せられる箇所を見直す」タイプの対応になります。
特に、これまで独自に Agent Task レコードの Archived フィールドを更新していた場合は、将来的な保守性を考えて ArchiveTask への置き換えを検討できます。
| 既存実装 | 見直し方 |
|---|---|
AgentTask.Archived := true; AgentTask.Modify(true); を直接実行 | オンプレ環境なら AgentTaskCU.ArchiveTask() へ置き換えを検討 |
| 管理画面で古いタスクを非表示にしている | Archived 条件の扱いを明文化 |
| バッチで完了済みタスクを整理している | 完了・停止・作成日などの条件を追加 |
| エラー調査用に全タスクを表示している | アーカイブ済みも検索できる導線を残す |
注意したいのは、アーカイブしたタスクを戻すための標準メソッドが今回のPRで追加されたとは確認できない点です。運用上「アーカイブ取り消し」が必要な場合は、管理手順や権限、監査ログの扱いを事前に決めてください。
安全な実装例
オンプレミス環境で、停止済みタスクだけをアーカイブする例です。実際の本番コードでは、メッセージ文言をLabel化し、権限やログ出力もプロジェクトの規約に合わせてください。
local procedure ArchiveStoppedAgentTask(AgentTaskId: BigInteger)
var
AgentTaskRecord: Record "Agent Task";
AgentTaskCU: Codeunit "Agent Task";
begin
if not AgentTaskRecord.Get(AgentTaskId) then
Error('指定されたAgent Taskが見つかりません。');
if AgentTaskRecord.Archived then
exit;
if not AgentTaskCU.IsTaskStopped(AgentTaskRecord) then
Error('停止済みのAgent Taskのみアーカイブできます。');
AgentTaskCU.ArchiveTask(AgentTaskRecord.Id, true);
end;この例で重要なのは、ArchiveTask を呼ぶ前に状態チェックを入れていることです。メソッド自体がシンプルなフラグ更新である以上、「どの状態ならアーカイブしてよいか」は呼び出し側の業務ルールとして設計する必要があります。
設定確認チェックリスト
開発環境や検証環境で、次の順に確認すると抜け漏れを減らせます。
| 手順 | 確認内容 | 判断基準 |
| -: | ————————– | ———————————– |
| 1 | 対象環境がオンプレミスか | OnPrem スコープのメソッドを利用できる環境である |
| 2 | シンボルに ArchiveTask が含まれるか | ALで Codeunit "Agent Task" から参照できる |
| 3 | 呼び出し元の権限が足りるか | Agent管理操作でエラーにならない |
| 4 | 対象タスクの条件を決めたか | 停止済み、完了済み、一定期間経過などの条件がある |
| 5 | UserConfirm の使い分けを決めたか | UIは true、バッチは条件を絞って false |
| 6 | 一覧や検索の条件を確認したか | アーカイブ済みを非表示にするか、検索対象に残すか |
| 7 | 監査・調査手順を用意したか | アーカイブ後も必要な履歴にアクセスできる |
よくある誤解と注意点
ArchiveTaskはタスク削除ではない
ArchiveTask は Archived フラグを true にする処理です。タスクレコードそのものを削除するわけではありません。削除処理の代替として説明すると、運用担当者が誤解しやすくなります。
StopTaskやRestartTaskとは役割が違う
Agent Taskのライフサイクル管理では、停止、再開、状態確認といった操作があります。Microsoft Learnでも、タスクの状態確認、停止、再開などの管理例が示されています。ArchiveTask はこれらの状態制御とは別に、整理・保管のために使う操作です。(Microsoft Learn)
既にアーカイブ済みでもエラーにしない
内部実装では、対象タスクがすでにアーカイブ済みならそのまま終了します。これはバッチ処理や再実行に強い設計です。ただし、「二重実行されたことをログに残したい」運用では、呼び出し側で Archived を事前チェックして記録する必要があります。
SaaS環境での利用可否を決め打ちしない
今回のメソッドは [Scope('OnPrem')] です。SaaS向けのAppSourceアプリやクラウド前提の拡張では、利用できる前提で設計しないほうが安全です。将来スコープが変わる可能性はありますが、現時点の実装とPR説明ではオンプレミス向けと見るべきです。(GitHub)
運用設計で決めておきたいルール
ArchiveTask は便利なメソッドですが、導入するだけでは運用は整いません。次のルールを先に決めておくと、管理画面やバッチ処理の実装がぶれにくくなります。
| ルール | 例 |
|---|---|
| いつアーカイブするか | 完了から30日後、停止済みで調査不要になった後 |
| 誰がアーカイブできるか | Agent管理者、運用管理者のみ |
| どの状態を対象にするか | 停止済み、完了済み、エラー調査完了済み |
| アーカイブ済みを表示するか | 通常一覧では非表示、詳細検索では表示 |
| 誤操作時の対応 | 管理者が手順に沿って確認し、必要なら復旧処理を行う |
| ログを残すか | バッチ処理では実行件数、対象条件、実行ユーザーを記録 |
特におすすめなのは、「アーカイブは終端状態ではなく、表示・整理の状態」と定義することです。停止や完了はタスク処理の状態、アーカイブは運用上の整理状態と分けると、後から仕様を説明しやすくなります。
まず確認すべきこと
今回のMicrosoft developer platformのAgents更新は、Business CentralのAgent Task管理を少し実用寄りにする変更です。ArchiveTask によって、不要になったタスクを削除せずに整理しやすくなります。
対応の優先順位は次の通りです。
| 優先度 | やること |
|---|---|
| 高 | オンプレミス環境で ArchiveTask が参照できるか確認する |
| 高 | 自社のAgent Task管理画面やバッチに影響があるか確認する |
| 中 | 直接 Archived を更新している独自実装を洗い出す |
| 中 | 停止済み・完了済みなど、アーカイブ対象条件を決める |
| 低 | SaaS環境では今後のスコープ変更に備えて情報を追跡する |
すぐにコードを書き換えるよりも、まずは「自社ではAgent Taskをいつ、誰が、どの条件でアーカイブするのか」を整理してください。そのうえでオンプレミス環境に限定して、標準の ArchiveTask を使う実装へ寄せていくのが安全です。
コメント