omni-content-builder

Omni コンテンツビルダー

Omni CLI を使って、Omni のドキュメント、ダッシュボード、アプリをプログラムから作成、更新、管理します。ドキュメントのライフサイクル、下書き、ワークブックモデル、フィルター、コントロール、ダッシュボードのコンテンツを扱います。

Tip：omni-model-explorer を使って利用可能なフィールドを確認し、omni-content-explorer を使って変更または参考にできる既存のダッシュボードを探します。

ドキュメントの作成と編集には v2 documents API（omni documents v2-*）を使用します。これは queryPresentations、controls、containers、settings を明示的なエンベロープとして扱い、下書き → 公開のフローで編集します。ドキュメントの作成、読み取り、変更には、これが唯一の方法です。v1 の documents create／get コマンドには決して切り替えないでください（v1 の put／update は CLI 1.2.2 で削除されました）。一部のドキュメント管理操作（一覧表示、削除、移動、複製、ダウンロード）には v2 形式がありません。以下のコマンドを参照してください。

デザインのデフォルト

ここで説明する仕組みを使えば 正しい ダッシュボードを作成できます。さらに 優れた ダッシュボードにするには、Omni のダッシュボード作成のベストプラクティスを適用してください。以下の箇条書きは、別途指示がない場合の同ガイドのデフォルトです。これらが、与えられた指示に優先することはありません。指定されたレイアウト、チャートタイプ、パレット、コントロールの配置があれば、それに従います。編集対象の既存ダッシュボードの慣例や、適用中の組織テーマも同様です。指示とデフォルトが矛盾する場合は指示に従い、必要であればデフォルトについて一度だけ言及してください。特に指示がない場合は、次をデフォルトにします。

• 答えを左上に配置します。 メイン KPI や答えを示すチャートを左上に置きます。閲覧者は F 字型または Z 字型のパターンで画面を見るためです。
• 1 ページあたりのチャートは 3～5 個にします。 それ以上になる場合は、ページまたはタブに分けます（containers.mdを参照）。
• 色は機能的に、90 対 10 にします。 ニュートラルな色調を主体とし、強調またはステータス表示にはアクセントカラーを 1 色使います。装飾目的では使いません。
• 問いに合ったチャートを選びます — 推移 → 折れ線／面／棒グラフ、ランキング → 横棒グラフ、全体に対する割合 → 100％積み上げ、相関 → 散布図。
• コントロールは、操作対象の近くに配置します。 「Region」ではなく「地域で絞り込む」のように、操作が伝わるラベルを付けます。
• 複雑さは親コントロールの背後に隠します — 1 つのコントロールで複数を操作し、子コントロールは配置しないでおきます（controls.mdを参照）。
• チャートはホバーしなくても内容がわかるようにします。 閲覧者がチャート自体から重要な洞察を得られるようにします。ツールチップは詳細情報であり、メッセージではありません。

運用ダッシュボードや経営幹部向けダッシュボードでは、references/dashboard-style.md（人が行動に移せるダッシュボードの構築）も適用してください。

• まだ状況を変えられるものから順に並べます。 すでに失われたものより、リスクのあるものを先にし、各リスト行に担当者を記載します。
• テーブルは列数を 5 以下にし、見出しを省略表示させません。 それを超える場合は、Markdown の {{#result}} リスト行を使用します。タイルに合わせて limit を設定し、PNG を確認します。
• すべてのビューから詳細に移動できるようにします。 Markdown では名前や重要な数値に {{view.field.value}} を使います。.value_static は表示専用です。
• 日付はすべて相対日付にします — 日付コントロールと各タイルのフィルターで使用し、タイトルやラベルに月名を使わないでください。
• 色ごとに意味を 1 つだけ割り当て、必ずテキストラベルを付けます。 単一系列の色は明示的に設定します。
• タイルのフィルターで対象範囲を固定します。閲覧者が操作できるコントロールは 5 個以下にします。
• アラートの対象となるタイルには、短いカテゴリ別ウォッチリストを使います（約 10 行、しきい値でフィルタリング）。サブタイトルに条件を明記します。

既知の問題と安全なデフォルト

• 公開前に、必ず完全な検証ループを実行してください — 下記の検証ループを参照してください。
• タイルは書き込んだときと同じ形式で読み戻されます。 v2-get／v2-get-draft は内部の vis 設定を { visType, config } として返すため、復元、複製、移動を含め、タイルをそのまま編集してパッチを適用できます。書き込んだ各タイルを検証してください：読み戻し、公開前にクエリを実行します。references/documents-v2.mdを参照してください。
• パッチはキーごとにマージされます。完全置換されるのはcontainersとorder配列のみです。 タイルを1つ変更するには、そのキーだけを送信します。タイルを削除するには、そのキーをnullに設定し、orderからも削除します。containersを送信するときは、変更を反映したレイアウトツリー全体を送信します。レイアウトを維持し、追加したタイルをサーバーに自動配置させるには、省略してください。
• containersを含まない作成またはパッチでは、新しいタイルが自動配置されます — ダッシュボードに配置可能な各タイルは最初のページに追加されます。レイアウトを自分で設定する場合にのみcontainersを送信し、その際は表示するすべてのタイルを参照してください。references/containers.mdを参照してください。
• 作成時のタイル"1"はサーバーのシードタイルにマージされるため、falseを送信してもautomaticVis: trueが維持されます（タイル"2"以降ではfalseが維持されます）。これが問題になる場合は、ドラフト上でタイル"1"に再度パッチを適用してください。
• コントロールは、コンテナに配置された場合にのみ表示されます。 コントロールを非表示にするには、すべてのコンテナから除外します。値の適用はそのまま続きます。references/controls.mdを参照してください。
• タイルクエリにはmodelIdがありません。 タイルクエリにmodelIdやmodel_extension_idを送信しないでください。サーバーはタイルをドキュメントのワークブックモデルに固定し、送信された値を警告なしで書き換えます。その他の必須クエリフィールドはreferences/documents-v2.mdに記載されています。いずれかを省略すると、そのフィールド名を示す400エラーが返されます。
• 厳守事項 — 引き継いだSQLから、ユーザーの明示的な判断なしにトピック非依存のタイルを作成しないでください。 まず各クエリをトピックに対応付けます（omni-queryを参照）。該当するトピックがない場合は、作業を止めて、トピックを拡張するか新規作成するかを確認してください（omni-model-builderを使ってブランチ上で作成し、確認を得た場合にのみマージします）。ユーザーがその方法を明示的に選択した場合（モデリングを断った場合、実際に一度限りの用途である場合、またはuserEditedSQLが必須の場合）にのみ、トピック非依存／userEditedSQLタイルを作成します。引き継いだSQLに対する既定の方法としてAccess Boostを使わないでください。トピックに基づくクエリの作成を参照してください。
• トピック非依存のタイルは、ViewerとRestricted Querierには表示されません。 userEditedSQLが入力されているタイル、またはjoin_paths_from_topic_nameがないベースビュークエリは、トピック非依存です。確定する前に、ダッシュボードの対象者にこれらのロールが含まれるか確認してください。含まれる場合は、Access Boostを提案してください（選択したユーザー、グループ、または組織に限り、ダッシュボード上でのみタイルを表示可能にします。組織の機能と、ドキュメントに対するManager権限が必要です）。これは独立した手順として、最も限定的な適用範囲を選び、明示的な確認を得てから実施します。許可を得ずに有効化しないでください。references/queryPresentations.mdのRaw-SQL tilesレシピ、および**omni-admin** → Document Permissionsを参照してください。
• --bodyは省略形のフラグより優先されます。 --bodyを指定すると、--name、--summary、--branch-idなどの省略形のフラグは、警告なしですべて無視されます。すべての作成およびパッチのJSONボディにこれらのフィールドを含めてください。フラグだけでリクエスト全体を指定できる場合にのみ、--bodyなしでフラグを使用します。
• ワークブックモデルIDはドラフトおよび公開のたびに変わります — 各ドラフトではワークブックモデルがコピーされ（拡張機能を含む）、公開するとドキュメントはそのコピーに切り替わります。ワークブックモデルIDをキャッシュしないでください。必要になるたびにv2-get-draft（またはomni documents list-drafts <identifier>）からworkbookModelIdを読み取ります。
• MarkdownタイルにはautomaticVis: falseが必要です — そうでないとレンダラーがチャートを自動生成し、タイルが空白になります。references/visConfig.mdを参照してください。Markdown KPIとカードのレシピはreferences/markdown-tiles.mdにあります。
• Mustache：フィルターの値はfiltersから読み取ります。 フィルターの現在の値をタイルのキャプションに表示するには、{{filters.…summary}}を使用します。controls名前空間はフィールドスイッチャー、ピッカー、Top-Nコントロール用で、フィルターに対しては空で表示されます。Markdown-vizタイルではfiltersキーはview.field、ダッシュボードのテキストタイルではコントロールのidです。トークンとシナリオについてはreferences/mustache.mdを参照してください。
• query.filtersにはオブジェクト形式が必要です — 相対日付の省略形（"last 6 months"）は500エラーを引き起こします。{type:"date", kind:"TIME_FOR_INTERVAL_DURATION", ui_type:"PAST", left_side, right_side}を送信してください。references/documents-v2.mdを参照してください。
• 実際のvisConfigがないタイルは「Item missing」として表示されます。 新しいタイルはvisConfig.visType: nullおよびautomaticVis: falseで始まり、何も描画されません。ユーザーが特定のチャートや書式を指定した場合は、各タイルに明示的なvisConfigを設定してください（references/visConfig.mdのテーブルレシピなど）。それ以外の場合はautomaticVis: trueにします。作成時にはorder内のすべてのタイルが配置されるため、修正すべき箇所は常にタイルのvisConfigです。
• 「No chart available」は、内部設定、visType、またはprefersChartが正しくないことを意味します。 チャートが指定されている場合は、references/visConfig.mdにある完全な設定をvisConfig.visConfig.configの下に送信してください。chartType: "table"を使うのは、意図的な代替手段として選択する場合に限ります。
• すべてのクエリには、少なくとも1つのメジャーを含める必要があります — ディメンションだけのクエリでは、空または意味のないタイルが生成されます（例：データがない月のみの表示）。
• pivots配列が存在すると、ブール値フィルターがひそかに削除される場合があります（Omniの報告済みバグ）。ブール値フィルターが適用されない場合は、ピボットを削除して再度テストしてください。
• idではなくidentifierを使用してください — ドキュメントのidentifierは、v2-create／パッチのレスポンス、またはomni documents listのレコードから取得します。
• 既存のダッシュボードの更新にomni unstable documents-importを使用しないでください — インポートすると新しいドキュメントが作成され、新たに追加したタイルが失われる場合があります。既存のドキュメントでドラフトのフローを使用してください。
• 無効なクエリレベルのフィルターを保存しないでください — omni query runがタイルクエリのフィルターに対するサーバー側の解析エラーを返した場合、フィルターを外したベースクエリを一度だけ検証してください。その無効なフィルターをタイルに保存しないでください。ダッシュボードレベルのコントロールで要件を満たせる場合は、その方法を使い、読み戻して検証してください。それ以外の場合はダッシュボードを変更せず、阻害要因を報告してください。
• 失敗した更新の試行回数を制限してください — パッチが検証エラーを返した場合、修正後の再試行は最大1回にとどめてください。フィルターの構文を繰り返し試したり、エンドポイントを何度も試したりしないでください。編集はドラフト上で行われるため、復旧は容易です：ドラフトを破棄し（omni documents discard-draft <identifier>）、保持された内容を報告してください。公開済みのドキュメントには一切変更が加わっていません。

前提条件

# Verify the Omni CLI is installed — if not, ask the user to install it
# See: https://github.com/exploreomni/cli#readme
command -v omni >/dev/null || echo "ERROR: Omni CLI is not installed."

# Verify the CLI has the v2 documents commands — if not, ask the user to upgrade it
omni documents v2-get --help >/dev/null 2>&1 || echo "ERROR: CLI is too old for the v2 documents API — upgrade it."

# Show available profiles and select the appropriate one
omni config show
# If multiple profiles exist, ask the user which to use, then switch:
omni config use <profile-name>

# Confirm the active profile is authenticated and inspect your permissions:
omni whoami whoami

認証：whoami またはその他の呼び出しが 401 を返す場合は、ユーザーに ! omni config login <profile> を実行してもらいます。プロファイルの設定、自分でログインを実行してもよい場合、および --schema については、omni-api-conventions ルールを参照してください。

コマンドの確認

omni documents --help              # Document operations (v2-* + lifecycle)
omni dashboards --help             # Dashboard downloads
omni models yaml-create --help     # Writing model YAML
omni documents v2-create --schema  # Body schema + example (add --depth 1 for an overview, --field PATH to drill in)

ヒント：プログラムで解析するために構造化出力を強制するには -o json を、読みやすい表形式にするには -o human を使用します。デフォルトは auto（TTY では人間向け、パイプ経由では JSON）です。--compact はパイプ出力時にインデントを削除します。

コマンド

ドキュメントの作成と編集には、必ず documents v2-* コマンドを使用してください。 ドキュメントの作成、読み取り、変更に v1 の documents create／get パスを使う場面はありません。v2 のドラフトフローですべて対応できます。

操作	コマンド
ドキュメントの作成	documents v2-create
ドキュメント／ドラフトの状態を読み取る	documents v2-get / v2-get-draft
ドキュメントの編集（タイル、コントロール、レイアウト、設定、名前変更）	documents v2-patch-draft（+ v2-patch-draft-by-identifier）
ワークブックモデル ID の取得	documents v2-get（公開済み）または v2-get-draft（そのドラフト）の workbookModelId。documents list-drafts でも取得できます
ドキュメントの識別子（スラッグ）の変更	documents v2-update-identifier <identifier>
タイルをクエリモデルにバインド、またはバインド解除する	ドラフトに対して documents v2-bind-query-model / v2-unbind-query-model（CLI ≥ 1.1.2）。references/documents-v2.md を参照してください
ドラフトの公開	documents v2-publish-draft
アプリ（ダッシュボードではなく HTML）の読み取りまたは編集	documents get-app / put-app / patch-app / remove-app（+ ドラフトおよび自動ドラフトの形式）— アルファ版、CLI ≥ 1.4.0。references/documents-v2.md を参照してください

一部のドキュメント管理操作には v2 形式がありません。これらは v2 の作成パスに代わるものではなく、それぞれの処理を行う唯一のコマンドです。documents list / list-drafts（ドキュメントとドラフトの検索）、documents discard-draft（ドラフトの破棄）、documents delete / move / duplicate（ライフサイクル管理）、documents get-queries（検証用にタイルの実行可能なクエリを抽出）、dashboards download / download-status、documents upgrade-layout（クラシックレイアウトのダッシュボードをアドバンストレイアウトに移行。公開されるため、先に確認してください）、および models yaml-create / validate（モデルの書き込み）です。

ダッシュボードのアーキテクチャ

Omni ダッシュボードはドキュメントで構成されています。ドキュメントの v2 状態は、queryPresentations、controls、containers、settings の 4 つのスライスをまとめたエンベロープです（references/documents-v2.md で説明しています）。

• タイルは queryPresentations.data にレコードキー（"1"、"2"、…）をキーとして格納され、order はタブの順序を示します。タイルキーは NUMERIC 文字列でなければなりません（"1"、"42"）。"revenue_kpi" や "probe" のような説明的なキーは 400 … Invalid key in record で拒否されます。タイルと意味の対応関係はキーではなく、ビルドスクリプトで管理してください。
• フィルターとインタラクティブコントロールは、controls という 1 つのマップです（references/controls.md を参照）。タイルキーとは異なり、ここでのコントロール ID は任意の文字列にできます（"date_filter"、"granularity"）。この自由度をタイルキーに持ち込んだり、その逆をしたりしないでください。
• レイアウトは containers ツリーで表されます。タイルはコンテナーから参照されている場合にのみ表示されます（references/containers.md を参照）。
• 各ドキュメントには、ダッシュボードごとのモデル変更に使うワークブックモデルもあります（references/workbook-model.md を参照）。

ドキュメントの編集にはドラフトを使用します。v2-patch-draft はドラフトを作成してパッチを適用します。公開済みドキュメントは v2-publish-draft まで変更されません。v2-get は公開済みの状態を返します。v2-get-draft はドラフトの状態を返します。また、ドラフト自体の識別子を指定して v2-get を実行した場合も同様です（レスポンスの draftOf にドキュメント名が含まれます）。ドラフトはモデルブランチに紐付けることもできます（references/branch-bound-drafts.md を参照）。

トピックに基づいたクエリの構築

可能な限り、すべてのタイルのクエリはトピックに基づいて構築してください。クエリの table にトピックのベースビューを設定し、join_paths_from_topic_name: <topic> を渡します。さらに、プレゼンテーションには topicName: <topic> を設定します（プレゼンテーションレベルの topicName はタイル固有のもので、単独クエリに相当するものはありません）。結合ビューのフィールドは、ベースビューからトピックの結合マップを通じて解決されます。結合マップが結合ビューのフィールドにどのようにつながるか、実例、および omni models get-topic（base_view_name／join_via_map）での確認方法を含む完全な形式については、omni-query の「トピックに基づいたクエリの構築」を参照してください。

トピックに基づいていないタイルも実行できます（ベースビューのみのクエリ、またはグローバルな relationships ファイルを使用する raw SQL の userEditedSQL タイルなど）が、制限付きクエリエーターやビューアーからは表示されません。上記の「既知の問題」にある 2 つのルールに従って、問い合わせるタイミングと Access Boost を案内するタイミングを判断してください。raw SQL タイルの作成から Access Boost の適用までの手順については、references/queryPresentations.md →「Raw-SQL tiles」を参照してください。ブーストのコマンドと組織レベルの前提条件については、omni-admin →「ドキュメントの権限」（accessBoost を指定した add-permits、または update-permission-settings）を参照してください。

作成上の制限（上記の表示制限とは別です）： あなた自身が Restricted Querier の場合、トピックに基づかないタイルや raw SQL タイルは作成できません。QUERY_TOPICS ではトピックのみをクエリするため、作成するすべてのタイルをトピックに基づいたものにする必要があります。トピックに基づかないタイルと Access Boost を組み合わせる方法は、QUERY_FULL_MODEL の権限を持つ作成者が、制限付きの対象ユーザー向けに構築する場合に限られます。whoami で確認してください（omni-admin →「モデルのロールと呼び出し元のアクセス」を参照）。

ドキュメントの管理

documents v2-create で、名前のみ、またはタイル、コントロール、設定を含むエンベロープ全体を 1 つの --body で指定してドキュメントを作成します。ドラフトのパッチ適用（--name を指定してから公開）で名前を変更します。documents delete／move／duplicate で削除、移動、複製できます。複製できるのは公開済みドキュメントのみです。使用例、作成時の --body の要点、エンドツーエンドの構築ワークフローについては、references/document-lifecycle.md を参照してください。

既存のダッシュボードを更新する

編集はドラフトフローで行います。公開済みのダッシュボードは、公開するまで変更されません。

1. omni documents v2-get <identifier> > doc.json で現在の状態を読み取ります。ドラフトがすでに存在する場合は、v2-get-draft を使用します。識別子がわからない場合は、まず omni-content-explorer または omni documents list でドキュメントを探してください。
2. パッチを作成し、変更する内容だけを送信します。パッチはキーごとにマージされますが、order 配列と containers は全体が置き換えられます。タイルを削除するには、そのキーを null に設定し、order から削除します。
3. ドラフトを開くには、本文に summary を含めて omni documents v2-patch-draft <identifier> --body @patch.json を実行し、返された draftIdentifier を保持します。--body @file ではシェルによる引用符は不要で、送信前に JSON が検証されます。
4. ドラフトを検証します。v2-get-draft <identifier> <draftIdentifier> で読み戻し、影響を受けるクエリを実行します（検証ループを参照）。v2-patch-draft-by-identifier <identifier> <draftIdentifier> で修正を繰り返します。
5. omni documents v2-publish-draft <identifier> で公開し、リンクを共有します（URL パターンを参照）。ドラフトを破棄するには、omni documents discard-draft <identifier> を実行します。公開済みのドキュメントは変更されません。

エラーマップ、マージの意味に関する詳細、レシピについては、references/updating-dashboards.md を参照してください。

ダッシュボードのモデルを更新する

ダッシュボード固有のフィールドは、共有モデルを拡張するドキュメントのワークブックモデルに設定します。まず、アクセス権に応じて、新しいフィールドをどこに配置するかを決めます（omni whoami whoami --model-id <sharedModelId>）：テーブル計算、共有モデルのブランチ、またはこのワークブックモデルです。スキーマモデルには書き込まないでください。マージされていないブランチにしか存在しないフィールドには、ブランチに紐づくドラフトが必要です。ワークブックモデルの YAML には "mode": "extension" を指定します。既定の結合モードでは、記載されていないすべてのフィールドが無視対象になります。判断手順、yaml-create のレシピ、新しいフィールドを使ってタイルを作成する順序、検証方法については、references/workbook-model.md を参照してください。

ダッシュボードのフィルターとコントロール

フィルターとインタラクティブコントロールは、controls: {data, order} という共通のエンベロープスライスを使用します。各エントリは {config, map} です。config にはフィルター／コントロールの定義を格納し、map では必要に応じてタイルごとに適用範囲を設定します。作成時に含めるか、後からパッチで追加します（コントロールはタイルと同様にキーごとにマージされます）。作成時の本文の例は、references/controls.md にあります。

• controls.data のキーは任意の ID で、order と一致している必要があります。
• フィルターの形式（日付／文字列／数値／ブール値、必須）とインタラクティブコントロール（フィールド／期間切り替え）の例は、references/controls.md にあります。
• map ではコントロールの適用範囲をタイルごとに設定します。{"<tileKey>": false} はタイルを除外し、{"<tileKey>": "<fieldName>"} はタイルのフィールドをマッピングし直します。フィルターとインタラクティブな切り替えの両方に使用できます。
• すべてのフィルターには、完全修飾フィールド名を指定した fieldName を必ず含めてください（日付フィルターでは期間の角括弧を付けません）。含めない場合、どの列にも紐づきません。
• 既存のダッシュボードからフィルターを再利用するには、omni documents v2-get で読み戻します。その controls スライスは、そのままパッチに含められます。

モデル化するか、コントロールにするか？ 対象トピックのすべてのワークブックとダッシュボードでフィルターを使う場合、1つのコントロールで複数の列やメジャーのしきい値を操作する場合、またはコントロールによってフィールドが使用する列やメジャーを切り替える場合は、フィルター専用フィールドとしてモデル化します。それ以外の場合は、ダッシュボードコントロールを使用します。Restricted Querier で可能な操作を含む詳しい基準については、references/controls.md を参照してください。

ドキュメントの設定

settings は浅いマージが行われるオブジェクトです。crossfilterEnabled（タイル内の値をクリックして他のタイルをフィルタリング）、facetFilters、refreshInterval（秒単位。null で無効化）、runQueriesOn（"current-page"／"all-pages"／null）、customText（{queryError, queryNoResults} の上書き）が含まれます。変更するキーのみを更新してください。

レイアウト（コンテナ）

containers ツリーによって、タイルとコントロールをレンダリングする場所が決まります。予約済みの "filter-bar" スタックに続いて、ページごとに 1 つの page コンテナがあり、それぞれが gridPosition {x,y,w,h} を持つタイルスタックの 24 列の grid を格納します。いつ送信するか、およびレイアウト全体が置き換えられることについては、上記の「既知の問題」を参照してください。複数ページのダッシュボード、ページ切り替え、グループ化された帯、タイル内コントロール、サイズ設定のルールについては、references/containers.md を参照してください。

URL パターン

コンテンツを作成または検索した後は、必ずユーザーに直接リンクを提示してください。

Dashboard: {OMNI_BASE_URL}/dashboards/{identifier}
Workbook:  {OMNI_BASE_URL}/w/{identifier}
Draft:     {OMNI_BASE_URL}/dashboards/{draftIdentifier}

identifier は v2-create／パッチのレスポンス、または omni documents list から取得します。draftIdentifier は v2-patch-draft のレスポンス、または omni documents list-drafts から取得します。 {OMNI_BASE_URL} は、アクティブなプロファイルまたは環境から実際のベース URL を取得し、末尾のスラッシュを除いて置き換えてください。認証情報が利用できず、URL がテンプレートであることを明示する場合を除き、プレースホルダー文字列をそのまま返さないでください。

検証ループ

ビルドや更新は、公開する前に必ず検証してください。タイルの破損、フィールド参照の誤り、仕様の設定ミスがあると、API エラーが発生しないまま「Chart unavailable」または「No data」と表示されます。

1. omni models validate <modelId> でモデルを検証します。
2. omni query run で、ダッシュボードが使用するフィルターも含め、各クエリを事前にテストします。
3. 各 viz 仕様を確認します。prefersChart: true であること、仕様が visConfig.visConfig.config の下にあること、そして chartType が visType および configType と一致していることを確認します。
4. 公開前にドラフトを検証します。v2-get-draft で読み戻し、各タイルのクエリを実行し（omni documents get-queries + omni query run）、各タイルのステータスと行数を報告します。

各レスポンスで確認する内容、viz 仕様の全表、チェックリスト、およびブラウザーを利用できる場合の任意のブラウザーチェック（ページがアイドル状態にならないため、独自の待機ルールがあります）については、references/validation-and-testing.md を参照してください。

ダッシュボードのダウンロード

ダウンロードは非同期です。omni dashboards download で開始し、ジョブが終了状態になるまで download-status をポーリングしてから、download-file でファイルを取得します。単一タイルとデータの形式、複数ページのダッシュボードにおける 1 ページの制限、「Job failed to render」の意味については、references/downloads.md を参照してください。

ドキュメントのリファレンス

• Documents API · Dashboard Downloads · Query API · Schedules API · Visualization Types

関連スキル

• omni-model-explorer — 利用可能なフィールドを把握する
• omni-model-builder — 共有モデルフィールドを作成する
• omni-query — ダッシュボードに追加する前にクエリをテストする
• omni-content-explorer — 参考にする既存のダッシュボードを探す
• omni-embed — 作成したダッシュボードを外部アプリに埋め込む
• omni-admin — スケジュール配信、受信者、メールのみのユーザーを管理する