Deltalyze Platformが目指す、データと意思決定の即時連結

01可視化の後に残る意思決定の遅れ

多くの組織では、数値の収集と表示までは自動化されても、異常の解釈、関係者への確認、対応方針の決定はメールや会議に戻ります。

必要なのは画面の追加ではなく、指標の変化がどの業務イベントを意味し、誰がどの基準で判断するかを結び付けることです。

遅れは実際に測れます。EC事業者を対象にした調査（メルカート、2026年5月公表）では、経営会議で複数のデータをまたぐ集計を求められたとき、2〜3日以上かかると答えた企業が38.0%、1週間以上かかるか算出できないと答えた企業が10.5%ありました。データの分断が競合との差を広げる要因になると感じている企業は58.0%です。この調査はEC事業者に限られており、そのまま他業種に当てはめることはできません。ただし、可視化の後に残る遅れが数字として出ている例として参照する価値があります。

遅れが生じる場所は、おおむね次の4つに分けられます。自社のダッシュボードを1つ取り上げ、どこで止まっているかを確かめると、手を入れる箇所が絞れます。

• 解釈の切れ目: 数値の変化が、現場で何が起きたことを意味するのかが書かれていない
• 担当の切れ目: 最初に確認する人と、方針を決める人が決まっていない
• 基準の切れ目: どの条件なら対応し、どの条件なら様子を見るかが人によって違う
• 戻りの切れ目: 決めた対応の結果が記録されず、次の判断に使われない

02指標ごとに「判断ルール」を1枚書く

4つの切れ目をまとめて埋める道具が、判断ルールです。判断ルールとは、1つの指標について、変化の意味、判断者、判断基準、選択肢、実行先、結果の戻し先を1枚にまとめた取り決めを指します。ダッシュボードの画面ごとではなく、指標ごとに書くのがポイントです。

下のテンプレートをコピーし、記入欄を埋めてください。すべての欄が埋まらない指標は、まだ判断に使える状態ではありません。埋まらなかった欄が、そのまま関係者と合意すべき論点になります。

記入するときは、担当と判断者を個人名ではなく役職名で書きます。異動や休暇で人が替わっても、ルールをそのまま使えるようにするためです。判断基準は、できる限り数値や「はい、いいえ」で答えられる条件にします。

期限の欄も空けないでください。期限がない判断ルールでは、判断が遅れても誰も気づきません。シグナルが出てから判断するまでの時間を決めておけば、期限を過ぎた件を数えるだけで、遅れがどの流れで起きているかを確かめられます。

AIに任せる範囲の欄には、下書きまでなのか、選択肢の提案までなのかを書きます。ここを先に決めておくと、後で生成AIを組み込むときに、どこまでを自動化してよいかで議論が止まりにくくなります。

03記入例: 経理の債権管理（入金遅延のシグナル）

以下は架空の例です。経理部門の債権管理で、入金の遅れを指標にした場合の判断ルールを埋めています。表中の日数や金額は説明のための例であり、推奨値ではありません。

この例で大事なのは、同じ「未入金」というシグナルでも、消し込み漏れと得意先の遅延とで、判断者も打ち手も変わることです。判断ルールがないと、この切り分けを毎回メールで確認することになり、そこで日数が過ぎていきます。

記入例の判断基準は、1回目と2回目以降で打ち手を分けています。このように過去の対応履歴を判断基準の条件に入れると、結果の戻し先に記録が残っていることが前提になります。判断ルールの欄どうしがつながっているため、どこか1つを空けると、ほかの欄も機能しなくなります。

04プロセス、データ、役割を共通モデルにする

判断ルールを何本か書くと、同じ業務ステップに複数の指標がぶら下がることに気づきます。そこで、業務ステップに、入力データ、成果物、担当、承認者、判断基準、利用するAIを関連付けます。これにより、画面単位ではなく業務の目的から変更影響を追えます。

例えば、請求書の発行ステップの担当を変えると、入金遅延の判断ルールの一次担当にも影響が出ます。業務ステップと判断ルールが結び付いていれば、この影響を変更前に洗い出せます。業務ステップの洗い出し方は、業務棚卸のやり方で詳しく説明しています。

AIが作成した提案は、確定済みの業務状態と分けて管理します。レビューと承認を経て初めて運用データへ反映します。

05判断根拠を次の実行へ渡す

アラートには数値だけでなく、関連する事実、過去の類似事象、対応候補、確度を添えます。責任者は根拠を確認し、採用、修正、保留を選びます。

決定内容はタスクやシステム処理へ渡され、完了結果が元の判断へ戻ります。この循環が、分析と現場を一つの運用にします。

対応案の下書きは、生成AIに任せやすい作業です。下の依頼文は、判断ルールと参照データを渡し、判断者が読む下書きを作らせるためのものです。出力の冒頭に「下書き（未承認）」と書かせることで、AIの出力が確定した判断と混ざるのを防ぎます。

アラートに添える情報は、次の4つを目安にしてください。どれかが欠けると、判断者は結局メールで確認を始めることになります。

• 関連する事実: シグナルの元になったデータと、その取得日時
• 過去の類似事象: 同じ判断ルールで過去に下した判断と、その結果
• 対応候補: 判断ルールに書いた選択肢のうち、今回当てはまるもの
• 確度: 事実と推測の区別と、確認が足りていない点

あなたは経理部門の債権管理を補助するアシスタントです。
以下のアラートについて、判断者が読む「対応案の下書き」を作ってください。

# アラート
{指標名と、変化した値}

# 判断ルール
{上の判断ルール表を貼り付ける}

# 参照データ
{関連する請求、入金明細、過去の対応履歴}

# 出力の形
1. 何が起きている可能性があるか（事実と推測を分けて書く）
2. 判断基準のどれに当たるか、当たらないか
3. 対応の選択肢ごとの理由と、決める前に確認すべきこと
4. 確度（高、中、低）と、その理由

# 制約
- 判断ルールにない選択肢を勧めない
- データにない数値を作らない。不明な点は「不明」と書く
- 出力の冒頭に「下書き（未承認）」と明記する

06AIドラフトと正式状態を分ける

AIの出力は便利ですが、事実や承認済み情報と混在させないことが重要です。下書き、レビュー中、承認済み、実行済みを明示し、各状態で許される操作を制御します。

誰が何を変更したかを追跡し、元に戻せることが、業務基盤としての最低条件です。

下の表は、判断ルールに沿って動く1件の対応が、どの状態を通り、誰が何をできるかを整理したものです。自社の職務分掌に合わせて「変更できる人」の列を書き換えて使ってください。AIが変更できるのは下書きの状態だけにしておくと、承認の記録が人の判断として残ります。

07構想から段階的な実装へ

最初から全社の業務を載せるのではなく、意思決定の遅れが事業へ影響する一つの流れを選びます。現状、あるべき状態、必要データ、責任分界を合意してから実装します。

最初の1本は、シグナルの発生頻度がある程度あり、判断の遅れが資金繰りや顧客対応に直接響く流れを選ぶと、効果を確かめやすくなります。次の3つの問いに「はい」が多い流れほど、最初の1本に向いています。

1つ目は、そのシグナルが月に数回以上出るかどうかです。2つ目は、判断が数日遅れると、入金、支払、顧客への回答などの期日に響くかどうかです。3つ目は、判断者が1人か2人に絞れるかどうかです。判断者が多い流れは、ルールの合意に時間がかかるため、2本目以降に回します。進め方は次の5つのステップです。

業務全体の流れをまだ整理していない場合は、AIを入れる前に業務を可視化する方法から始めると、対象の流れを選びやすくなります。

Deltalyze Platformは、ここまで述べた業務プロセス、データ、役割、AI、判断基準を一つの運用モデルとして扱うことを目指しています。Deltalyzeは、業務設計、プラットフォーム実装、利用者の定着を別々の案件にせず、一つの改善サイクルとして支援します。