エージェントに結果を伝える。検証を依頼する

なぜエージェントネイティブなのか？

screenRIG は制御プレーンから自律エージェント向けに構築されました。公式プラグインはエージェントにメディア、プレイリスト、スクリーン、アプリケーション、再生証跡の構造化コマンドを提供します。結果は JSON エンベロープで、すべてのエラーは次の手順を示し、再試行された書き込みは冪等キーを再利用し、公開はプレーヤーが実際にコンテンツを再生しているか報告します。エージェントはスクリーンタスクを実行し、結果を検査し、同じツールで修正できます。エージェントネイティブとは。

Claude、Codex、Grok、または Grok Bot からこれを実行するにはどうしますか？

すべてのサポートされるエージェントは同じ公式プラグインを使用します。端末エージェント（Claude Code、ChatGPT Codex、Grok Build）はマーケットプレイスコマンドでインストールします。Meta Muse、Grok Bot、ChatGPT dots、Gemini Spark、Hermesはチャットプロンプトからインストールします。セットアップは最初のステップだけ異なり、エージェントのガイドに従ってください：Meta Muse、Grok Bot、ChatGPT dots、Claude Code、Hermes、ChatGPT Codex、Gemini Spark、またはGrok Buildの開始。公開ワークフローはどこでも同じです。

エージェントでのscreenRIGの使い方

コンテンツ、対象スクリーン、レイアウトや寸法、タイミング、完了時に欲しい証拠を説明してください。アセットとソースの事実をエージェントに提供してください。

プラグインのインストールが必要な場合、以下を貼り付けてください：

I authorize you to install the official screenRIG plugin from https://github.com/screenrig/plugin.

次にスクリーンタスクを与えます。例：

添付のロゴと営業時間を使って歓迎スクリーンを作成。ロビースクリーンに公開し、スクリーンショットを表示して再生を確認。

例示的なリクエストのみ。エージェントは提供された実際のアセット、事実、スクリーンを使用する必要があります。

コマンドがnot_enrolledを返す場合、このインストールにはまだアカウントがありません。screenrig agent enroll --email ADDRESS --organization NAMEで作成してください。すでにアカウントがある場合は代わりにscreenrig loginを実行します：ダッシュボードのアドレスとコードを表示し、ユーザーが自分のプロジェクトのサインインを承認します。読み取り専用、提案、管理のいずれかと、エージェントが得る権限領域：screens、content、playlists、advertising、reports、project。読み取り専用はリストと読み取りのみ。提案はメディアアップロードと変更提案を含み、ユーザーがレビューしてから再生。管理は変更、公開、支出も可能。承認外のコマンドは403 forbiddenを返し、読み取り専用セッションの変更は403 insufficient_accessを返します。サインインの仕組み。その他の初回実行エラーは最初の実行が失敗したときにマッピング。

タスクを準備

ソース資産と事実をエージェントが利用できるようにします。対象のPlayer、寸法、タイミング、完了条件を特定します。公開ワークフローは対応エージェント間で同じで、インストールの違いは開始にあります。

キオスクアプリにはブラウザー SDKを使用します。スケジュールや時間帯には、スクリーンのタイムゾーンと希望する曜日・時間帯を指定してください。

エージェントが継続的に行うこと

エージェントは既存のメディアをアップロードし、完成度の高いデザインを生成し、変化するテキスト用に組み込みカードを配置し、ライブビデオ、ウェブページ、アプリケーションを公開します。その後、playlist init でプレイリストを準備し、screen publish で公開します。既存のプレイリストを変更するには playlist show --output と playlist update を使用します。CLI ワークフローリファレンスを参照してください。

ポスターとメニューにはページ全体の生成を使用します。変化するテキスト、表、ボードには組み込みカードを使用します。アニメーションは選択に影響しません。作成の判断ガイドを読む。

アプリケーションの場合、エージェントが特定のイベントで動作する必要があるときはemit、診断にはlog、リリースをまたいで状態を保持するにはkvを使用します。SDK リファレンスを読む。

エージェントはどのようにフリートを運用しますか？

目的でスクリーンにタグを付け、場所でフォルダーに入れ、タグまたはフォルダーをターゲットにします。プレーヤーがペアリングされると、エージェントがスクリーンに名前を付けタグ付けします：screen pair CODE、次にscreen tag scr_ID --add Lobby,Floor2。各スクリーンは最大16個のタグを持ち、最大1つのフォルダーに入ります（screen move scr_ID --folder sfd_ID）。

1. 01

   一度だけ公開します。 playlist createがプレイリストを作成し、screen assign --tag Lobby --playlist-id IDが一括操作で全アクティブなロビー画面を指し示します。

2. 02

   フリートに対して操作します。 screen reload、screen toast、screen tagは同じ--tagまたは複数のスクリーンIDを受け取ります。1つのフリートコマンドはスクリーン数の上限なしで1回の課金アクションです。CLIは自動的に結果ページを追跡し、制御予算のリセットを待ち、同じアクションキーを維持します。応答はすべてのスクリーンをokまたはそれぞれの問題付きでリストし、エージェントはどのスクリーンが失敗したかを正確に報告し、IDで操作します。

3. 03

   画面で検証。 screen screenshot --tag Lobby --output lobby-shots はタグ付けされたすべてのスクリーンを1つのディレクトリにキャプチャします。各画像を確認してからフリートの更新を報告してください。

4. 04

   切断を監視。 events follow を開いたままにします。screen.offline はスクリーンが60秒間オフラインになったときに届き、screen.online は復帰時に届きます。両方ともリッスンストリームで無料です。

フリートコマンドを読む。

エージェントはどのように時間帯やテイクオーバーを管理しますか？

プレイリストスケジュールは時間帯でスクリーンの再生内容を変更します。キャンペーンはフリート全体を、その日付または時間の間、1つのプレイリストに切り替えます。テイクオーバーはすべてを中断し、告知後に自動終了します。

1. 01

   スクリーンを時間帯で分けます。 各時間帯に1つのプレイリストをplaylist createで作成し、screen assignでデフォルトを割り当て、スクリーンにタイムゾーンを設定してください。エントリをファイルに書き込み、screen schedule set scr_ID --file dayparts.jsonを実行するか、カフェのスクリーンごとに--tag Cafeを実行します。screen showはeffective_playlistとそのsource、untilを報告し、エージェントはどの時間帯がライブでいつ変更されるかを確認できます。

2. 02

   フリート全体でキャンペーンを実行します。 ランチメニューをすべてのnorth店舗で表示する場合、campaign create --name Lunch --playlist-id pl_LUNCH --tag north --window mon-fri@11:00-14:00が各スクリーンをそれぞれの現地時間の11:00に切り替え、14:00に戻します。後からnorthタグを付けたスクリーンにも同様に適用されます。各スクリーンにはデフォルトプレイリストとタイムゾーンが必要です。campaign screens cmp_IDはキャンペーンが届くすべてのスクリーンを、その状態（playing、pending、next_start付きのwaiting、outranked、blocked）とともに一覧表示し、campaign explain scr_IDはあるスクリーンがキャンペーンを再生しない理由を示します。プロモーションの日付には--fromと--untilを、毎月や単発の日付には--monthly、--date、--exceptを、誰かがスクリーンを操作している間だけ再生するレベルには--on-touchを、2つのキャンペーンが同時に条件を満たしうる場合は--priorityを使います。キャンペーンの変更にはManageアクセスが必要です。

3. 03

   緊急時や開始時に引き継ぎます。screen takeover --tag Lobby --playlist-id pl_NOTICE --for 30m --reason "Fire drill"はすべてのロビー画面にキャンペーン、スケジュール、割当より先に1つのプレイリストを表示します。固定終了には--untilを、screen takeover clear --tag Lobbyまで保持には--until noneを使います。

4. 04

   検証と監視。 テイクオーバーがライブになったら screen screenshot --tag Lobby をリクエストし、イベントログの screen.takeover_started、screen.takeover_ended、screen.playlist_switched を追跡します。screen.playlist_unavailable はスケジュールされたplaylistが表示できなかったことを意味します。

スケジュールとテイクオーバーコマンドとキャンペーンコマンドを読む。スプレッドシートから多数のスクリーンをスケジュールするには、スケジュールインポートを使用します。

下書き、テストと昇格、履歴

再生内容の変更は、下書きとして始め、まず数台のテスト用スクリーンに届け、実行前に確認し、履歴から元に戻すことができます。

1. 01

   下書きを作る。campaign create --pausedはどのスクリーンにも届かないキャンペーンを作り、screen schedule setファイル内のスケジュールエントリに"paused": trueを指定すると、そのエントリも同じになります。下書きはどのスクリーンのスタックにも入らず、カレンダーでは破線で表示されます。

2. 02

   変更の前に確認します。campaign previewはcampaign createまたはcampaign updateのフラグを受け取り、screen schedule preview scr_ID --file FILEはスケジュールファイルを受け取ります。どちらも何も書き込みません。それぞれ、そのレベルを得る、または失うスクリーンと、変更前後のカレンダーを1週間分（--calendar-fromと--calendar-toを指定すれば最大93日分）表示します。campaign preview cmp_ID --publishは下書きの公開をプレビューします。

3. 03

   テストする。campaign publish cmp_ID --test-folder sfd_TESTまたは--test-screen scr_A,scr_Bは、それらのスクリーンに限って下書きの一時停止を解除します。screen screenshotで確認します。テストオプションなしのcampaign publish cmp_IDは、本来のオーディエンスに届けます。

4. 04

   本番に昇格する。campaign promote cmp_ID --revision Nは、campaign revisions cmp_IDが一覧表示する一時停止のリビジョンである下書きのリビジョンNのオーディエンスをキャンペーンに与え、実際のスクリーンに届くようにします。

5. 05

   履歴を読んで復元する。campaign revisions cmp_IDとscreen schedule revisions scr_IDは、すべてのバージョンを新しい順に一覧表示します。campaign restore cmp_ID --revision Nとscreen schedule restore scr_ID --revision Nは、以前のバージョンを新しいリビジョンとして前方にコピーし、ほかのリビジョンはそのまま残します。Proposeセッションからのスケジュールの復元は、screen schedule setと同じく、人の承認を待ちます。キャンペーンの復元にはManageアクセスが必要です。

ダッシュボードにも同じ操作があります。履歴ビューには変更が一覧表示され、「復元」と「元に戻す」を使えます。公開、昇格、復元の前には、その前後の状態が確認用に表示されます。

キャンペーンのコマンドとスケジュールのコマンドを読む。

エージェントは再生証明をどのように報告しますか？

画像や動画のすべての可視開始は再生記録です。エージェントは期間の正確な再生をクライアント、広告主、監査人に渡せます。

1. 01

   期間を選択してください。 レポートは最大31日間の再生を対象とし、--screen-id、--media-id、または--tagで絞り込みます。カレンダー期間にはRFC 3339の日時を、期間には7dのような経過時間を使用してください。

2. 02

   エクスポート。 screenrig playback plays --format csv --from 2026-09-01T00:00:00Z --to 2026-10-01T00:00:00Z --tag Lobby --output september-lobby.csv は請求リクエストごとに再生ごとに1行を書きます。screenrig playback list --format csv --day-from 2026-09-01 --day-to 2026-09-30 は日別合計を追加します。

3. 03

   チェックして引き渡す。 エンベロープは rows、bytes、sha256 を報告します。ファイルと共に引用してください。途中でストリームが失敗した場合は、error.next に従い、残りの範囲を別ファイルにエクスポートします。

再生コマンドを読む。

エージェントはどのようにヘルスチェックを行い、ディスプレイの稼働時間を設定しますか？

ヘルスレポートとディスプレイ制御で、エージェントが現地に誰もいなくてもスクリーンを稼働・消灯できます。

1. 01

   トリアージ。 screenrig alerts list は現在未解決のものを、スクリーンと条件ごとに 1 件のアラートとして表示し、screenrig screen list --human は注意が必要なスクリーンを HEALTH 列に表示します。screenrig screen show scr_ID で詳細レポートを確認：ディスプレイ接続、温度、バッテリー、稼働時間、クラッシュ、レポートの古さ。最後の停止の推定原因も、screenRIG が判断できる場合に表示します：デバイスの再起動、Player の再起動またはクラッシュ、スクリーンのネットワーク、screenRIG 側の中断。screenrig alerts ack ID は誰かが対応中のアラートを確認済みにし、alerts snooze ID --for 4h は 4 時間後まで保留にします。screen_offline、display_disconnected、running_hot、not_playing、crashing 向けの 通知 を作成すると、通知メッセージでこの作業が始まります。

2. 02

   影響の少ない順に対処します。 screen reload はコンテンツを更新します。Player が restart_app を宣言している場合、screen restart-app scr_ID は Player アプリケーションを再起動します。clear_cache を宣言している場合、screen clear-cache scr_ID はキャッシュをクリアしてコンテンツを再ダウンロードします。reboot を宣言している場合、screen reboot scr_ID はデバイスを再起動します。フリートには --yes が必要です。オフラインのスクリーンには、24時間以内に復帰すればいずれも送信されます。定期的な再起動には、screenrig screen reboot-schedule set --tag Cafe --window "Mon-Sun 04:00-04:30" を使うと、screenRIG が各スクリーンのタイムゾーンでウィンドウの開始時に再起動します。その時刻にオフラインだったスクリーンは、ウィンドウが終わるまでのみ再起動を保持し、10分以内に完了した再起動ではオフラインアラートは発生しません。screen update-software scr_ID は、Player が update を宣言している場合に最新の Player リリースをインストールします。ディスプレイが外れている場合は通常、現地での対応が必要です。その旨をレポートに記載してください。

3. 03

   営業時間外の電源を設定します。 営業時間をファイルに書き込み、screenrig screen display-schedule set --tag Cafe --file hours.json を実行します。Player はその時間外にディスプレイをオフにします（オフラインでも）。一時的には screen display scr_ID --power on --for 2h がスケジュールを次の境界または指定時間まで上書きします。screen display-idle scr_ID --after 300 --wake touch,presence は、誰も使っていないスクリーンを暗くし、誰かが触れるか近づくと再び点灯します。

4. 04

   確認します。 screen show は Player が達成したディスプレイの電源状態を報告し、screen.display_changed と screen.reboot_requested はイベントログに表示され、commands のコマンドは原因とともに done または failed で終わります。

5. 05

   画面を確認します。 screenrig screen show scr_ID は、スクリーンがオンラインで最新のコンテンツを持っているのに、ループが許す時間より長く画像または動画の開始が screenRIG に届いていない場合に Playlist stalled を表示し、screenRIG がループ全体を覆う一連のスクリーンショットを撮り、そのすべてが単一の無地の色、またはすべて同じ画像だった場合に Blank screen または Frozen picture を表示します。loop_stalled、glass_blank、glass_frozen の通知がそれを知らせ、screen screenshot は画像1枚が無地かどうかを報告しますが、それだけでは判定になりません。これらの確認は、ディスプレイがオフのスクリーン、テイクオーバー中のスクリーン、静止画1枚またはビデオウォールを表示しているスクリーン、再生番号を送らないプレーヤーについては何も判断しません。そのため、静かなスクリーンが再生中である証拠にはなりません。

デバイスの健康状態と電源コマンドを読む。

何かが起きたときにアラートを受け取ったり、エージェントを起動したりするにはどうしますか？

通知は、画面がオフラインになったとき、ディスプレイを失ったとき、高温になったとき、バッテリーで動作しているとき、コンテンツを保存できないとき、コンテンツの更新で止まったとき、再生せずにエラーを表示したとき、クラッシュを繰り返すとき、プレイリストが進まなくなったとき、真っ黒になったとき、または固まったときに、メールの送信、Slack・Teams・PagerDuty・Telegram への投稿、または署名付き HTTPS リクエストの送信を行います。ストリームを誰も見ていなくても、人が気づき、またはエージェントが作業を始めます。すべてのプロジェクトは、画面が 10 分間オフラインのときにすでにオーナーへメールを送り、通知メールと画面の通知は無料です。

5 分以内に同じ状態になった 3 台以上の画面が、ネットワーク、場所、モデル、Player のバージョン、またはタグを共有している場合、メールとチャットやアラートツールのメッセージでは、共有しているものと台数を示す 1 件の通知と 1 件の復旧通知になります。署名付き Webhook は引き続き画面ごとに 1 回 POST します。復旧メッセージは、screenRIG が実際に確認できたときだけ画面の復帰を伝えます。停止・真っ黒・フリーズした画面が、オフラインになった、またはディスプレイが消えたために単に確認されなくなった場合は、アラートが閉じられ、復旧メッセージは送られません。

1. 01

   人にメールを送ります。 screenrig notifications create --email owner --conditions screen_offline,display_disconnected はプロジェクトオーナーにメールを送ります。プロジェクトメンバーも含めるには、owner の後にそのユーザーIDを追加します。--tag Lobby でタグ付きスクリーンに限定でき、通知メッセージは --hold 分（デフォルトは10分）待機するため、短時間で再接続した場合は通知されません。スクリーンが復旧すると、解決済みのメールが続きます。各メールには、その受信者だけに有効な配信停止リンクがあり、screenrig notifications resubscribe ID --user USER_ID でその人にメールを再開できます。代わりにエージェントや別のシステムを起動するには、Webhook を使います。

2. 02

   チャットまたはページャーに投稿する。 screenrig notifications create --slack - --conditions screen_offline は Slack チャンネルに投稿し、--teams、--pagerduty、--telegram は同様に Teams、PagerDuty、Telegram に投稿します。Slack には受信 Webhook の URL、Teams には Workflows Webhook の URL、PagerDuty には Events API v2 のルーティングキー、Telegram にはボットトークンと --telegram-chat CHAT_ID を渡します。- を指定すると stdin の 1 行から認証情報を読み取るため、シェルの履歴に残りません。screenRIG はそれを封印し、マスクした destination_hint だけを表示します。障害ごと、画面ごとに 1 回投稿し、PagerDuty はそれに対してインシデントを 1 件だけ開き、そのメッセージが送信された後に復旧メッセージが続いてインシデントを解決します。screenrig notifications test ID はテストメッセージを投稿し、PagerDuty では情報イベントを開いてすぐに解決します。

3. 03

   レシーバーを実行します。 ポート443または8443で制御する任意のHTTPSエンドポイント：小さなサービス、サーバーレス関数、エージェントやボットプラットフォームのインバウンドトリガー。WebhookシークレットでScreenRig-Signatureを検証し、ScreenRig-Event-Idで重複排除し、10秒以内に2xxで応答します。

4. 04

   購読します。screenrig notifications create --webhook https://HOST/PATH --conditions screen_offline,crashingは署名シークレットを一度だけ返します。受信側のシークレットストアに保存してください。生のプロジェクトイベントも受信するには--events application.eventを追加します。screenrig notifications test IDは経路を証明するために、署名付きテストPOSTを1件送信します。

5. 05

   引き渡し。 受信側は通知メッセージをタスクとするエージェント実行を開始します：スケジュールまたはオンデマンドのエージェントジョブをトリガーするか、Grok Bot や screenRIG プラグインを持つ他のエージェントが動作するチャットに通知メッセージを投稿します。例：「スクリーン scr_LOBBY が14:02にオフラインになりました。確認して報告してください。」その後、エージェントは通常通りプラグインを通じて screen show、screen reload、スクリーンショットを使って作業します。

6. 06

   健全に保つ。 screenrig notifications deliveries ID はすべての試行を一覧表示し、通知が送信されなかった理由も示します。72時間連続で失敗した通知は無効化されます。screenrig notifications update ID --enable は現在のイベントから再開します。--snooze 2h はメンテナンス中の通知メッセージを一時停止します。

7. 07

   メンテナンス中はスクリーンをミュート。 screenrig alerts mute --tag Lobby --for 2h --note "Rewiring" は、最長30日間、これらのスクリーンのアラートが対応を求めないようにし、通知がそれらについて送信されないようにします。screenrig alerts mutes でミュート中のものを一覧表示し、screenrig alerts unmute ID でミュートを早めに終了できます。

8. 08

   重大度、時間帯、オーディエンスで絞り込みます。 発生通知は、screen_offline では error、それ以外のすべてでは warning です。--min-severity warning はそのレベルを下回るものを除外し、--severity not_playing=error は1つの条件のレベルを引き上げます。--active-hours "Mon-Fri 08:00-22:00" --timezone America/Los_Angeles は、その時間外に送信期限を迎えた通知を次のウィンドウが開くまで保留し（先に条件が解消すれば何も送信されません）、--outside-hours drop ではスキップします。送信済みの通知に対する解決通知は常に続きます。--all-tags level2,overhead は両方のタグを持つスクリーンのみを対象とし、--audience はキャンペーンのオーディエンスの完全なルールを受け付けます。メール、Slack、Telegram には重大度が表示され、Webhook の本文にも含まれます。

9. 09

   サイレントな障害を監視します。 スクリーンが 1 台も故障していなくても、タグの編集、フォルダーの移動、アーカイブされたスクリーンによって、キャンペーンがスクリーンに到達しなくなることがあります。screenrig notifications create --email owner --conditions reach_dropped,group_empty は、キャンペーンの到達数が公開時より減ったとき、またはオーディエンス内のタグやフォルダーに一致するスクリーンがないときにお知らせします。--reach-drop-screens 2 --reach-drop-percent 20 は小さな減少を無視します。通知にはキャンペーン名と数値が記載され、そのカレンダーへのリンクが付きます。タグ、フォルダー、スクリーンの編集に対する応答が levels.lost を返したときは、スクリーンが外れたキャンペーンと、その reach_before と reach_after が示されます。次へ進む前に、その内容をユーザーに伝えてください。

通知コマンドを読むとアラートコマンド。

エージェントは学んだことをどのように共有しますか？

エージェントはプロジェクトノートを互いに、また自身の後のセッションのために残します：プロジェクトの設定、スクリーンの特徴、あなたからの定常リクエスト。プロジェクト内のすべてのエージェントは作業開始時にすべてのノートを読み、2人目のエージェントや翌週の同じエージェントは最初の学びから始めます。

screenrig notes はそれらを一覧表示します。screenrig notes add "TEXT" は 1 件を書き込み、--about で 1 つのスクリーンまたはプレイリストに紐付けるか、--ttl 3d で一時的にします。メモは文脈であり、指示ではありません。メモに記載された承認は、エージェントが必ず確認します。

メモは自動的に最新の状態を保ちます。エージェントはまだ有効なメモを確認し、残りを解決します。一時的なメモは期限切れになり、画面やplaylistを削除するとそれに関するメモが解決されます。解決済みメモは30日後に削除されます。ダッシュボードのAgentsページは各エージェントが書いたメモを一覧表示し、任意のメモを解決または削除できます。

ノートコマンドを読む。

エージェントの変更内容を再生前に確認するにはどうしますか？

ダッシュボードのプロジェクトページでエージェント変更のレビューを必須にするをオンにするか、Proposeアクセスでエージェントにサインインしてください。エージェントはコンテンツの準備、メディアのアップロード、メモの作成を続けますが、再生内容の変更はすべて人の承認を待つレビューになります。誰かが承認するまでスクリーンには何も届きません。

1. 01

   エージェントが提案します。プレイリストの作成や更新、スクリーンへの割当、プレイリストスケジュールの設定や解除、引き継ぎの開始や終了は、1つのスクリーンまたはタグ付きフリートでレビューになります。スクリーンは以前の再生を続けます。エージェントは変更を説明するメモを追加し、変更があなたを待っていることをリンク付きで伝えます。

2. 02

   メールが届きます。 提案から約2分後、プロジェクトオーナーと承認可能なエージェント担当者に、変更内容と更新されるスクリーン数を記載したメールが届き、変更を確認ボタンが付いています。エージェントがメモを残した場合はメールに記載され、レビューで確認できます。複数の変更が同時にある場合は1通のメールにまとめられ、レビューを開くボタンが付きます。1つの変更に対する編集の連続は最新バージョンのメール1通にまとめられます。リンクを開いても承認はされません。

3. 03

   レビューで決定します。 ダッシュボードのレビューページにはすべての保留中の変更が一覧表示され、決定済みは下に表示されます。プレイリストの変更はライブと提案されたプレイリストを並べて表示し、ページは追加、変更、削除とマークされます。承認でスクリーンに反映され、変更を依頼はエージェントにメモを送り、再提案を促します。拒否は理由を付けて終了します。新しいプレイリストとスクリーン割り当てが一緒に保留中の場合、プレイリストの承認時に割り当ても承認できます。大規模フリートの変更はバックグラウンドで適用され、レビューは各スクリーンの結果を表示します。

4. 04

   エージェントがフォローアップします。エージェントはscreenrig reviews show IDまたはそのイベントで決定を読み、変更要求や拒否後に修正し、承認後にスクリーンを確認します。

プロジェクトオーナーは常に承認でき、各メンバーは、ユーザーページでオーナーがそのメンバーの承認可能をオフにしない限り、承認できます。承認できないメンバーのエージェントは、最大でも提案で作業します。提案は、作成後にライブのプレイリストが変更されると古くなります。エージェントは新しいバージョンの上に再度提案します。プレイリスト変更の承認も、tag、folder、all セレクターが、提案時には見えなかったメディアを再生するようになる場合には古くなります。保護とマークされたフォルダーは、そのスクリーンに及ぶすべての変更を2人目の承認者に送ります。スクリーンフォルダー単位の権限を参照してください。

メディアの変更も待機中です。新規アップロードは人が承認するまでタグ、フォルダー、すべてのプレイリストで再生されず、エージェントが承認済みメディアを再タグ付けまたは移動すると、変更が承認されるまでスクリーンは承認済みのまま再生します。各アイテムはタグとフォルダーの前後を示す独自のレビューを持ち、参加または離脱するプレイリストとそのスクリーン数をリストします。承認はすべてに適用し、拒否や変更要求は再タグ付けまたは移動されたアイテムを承認済みに戻し、拒否されたアップロードはスクリーンに表示されません。承認済みメディアの置換ファイルや復元したバージョンも同様に待機し、人が承認するまで古いファイルが再生され続けます。広告ネットワークは同じレビュー画面で購入者のクリエイティブをレビューします。アクセスレベルとレビュー設定・レビューコマンド。

完了とみなされる条件

意図したプレイリストが意図したスクリーン、またはフリート内のすべてのスクリーンに割り当てられていることを確認。タグ付きスクリーンごとにスクリーンショットを要求し、再生記録を検査し、関連イベント（screen.offlineを含む）を確認。観察結果と残る不確実性を報告。レビュー待ちの変更はまだ画面に反映されていません：レビューリンクを報告し、決定後に再確認。

成功したコマンドはその証拠の一歩です。物理的なスクリーンが意図した結果を表示したことを単独で証明しません。

フィルム / エージェントが再生中と認識する仕組み

1:17