各部門の月次KPIの実績を集め、目標との差が大きい項目について説明文の下書きを作り、部門長の承認に回す

処理の起点を決める

経営企画が、入力の締めを確かめてから手動で起動します。 起動のときに対象の年月を入力し、フローはその年月の項目だけを扱います。月初の決まった日時に自動で動かすことはしません。 部門の入力が遅れた月に自動で動くと、未入力の項目について「メモがありません」という下書きが部門長に届き、承認の依頼が無駄に増えます。

起動の前に、未入力の部門を確かめます。 KPI のリストを Get items で引き、実績か理由のメモが空の項目を数えて Teams に出す小さなフローを別に用意し、経営企画はその数が0になったのを見てから本体を起動します。 未入力のまま起動したい月は、未入力の項目を飛ばす設定で起動します。

同じ年月で2回起動したときは、すでに下書きのある項目を飛ばします。 下書きの列が空でない項目は対象から外し、承認待ちの依頼が二重に届かないようにします。

入力データを集める

質を決めるのは、KPI の定義のリストの「良い向き」の列です。 解約率、一次回答までの時間、1件あたりの獲得の費用は、下がるほうが良い項目です。この列が無いと、フローは差の符号から良化か悪化かを決められず、第3章の（c）がそのまま残ります。

説明が要る差の基準も、KPI ごとに持ちます。 新規の MRR は目標との差が10％、解約率は0.3ポイントのように、率で見る項目とポイントで見る項目があります。 基準を全社で一律にすると、小さな率の KPI が毎月すべて説明の対象になります。

この表は経営企画だけが書き換えます。 基準を部門が自分で緩められると、説明の要る項目が月ごとに減っていき、経営会議で見るべき差が資料から消えます。 基準を変えた年月も列に残します。

データの取得方法を決める

Get items の Top Count は、既定ではすべてとされています。 全社で約120項目なので1回で取り出せますが、過去の月のデータが積み上がっても対象の年月で絞るので、取り出す件数は増えません。

計算は、取り出した後にフローの式で行います。 目標との差（実績 − 目標）、達成率（実績 ÷ 目標）、前月との差を項目ごとに計算し、良い向きの列と差の符号から「良化」「悪化」を決めます。 説明が要るかどうかは、差が基準を超えたかどうかで決めます。

AIへ渡す前に整形する

1. 未入力の項目を外す … 実績が空の項目は対象にせず、経営企画の一覧に残します
2. 単位をそろえる … 率は％、金額は千円、時間は時間に、KPI の定義の単位でそろえます
3. 数値を文字列に直して渡す … 小数の桁を KPI の定義で決め、AIには表示する形の文字列で渡します
4. 理由のメモの長さを見る … 空のメモ、一言のメモ、長いメモに印を付けます

3番目は、文と表の数字を一致させるためです。 数値のまま渡すと、AIが桁を丸めたり「約」を付けたりします。資料の表に出る形の文字列を渡し、そのまま写させます。

AIに処理させる

させるのは、渡された数値と部門のメモだけから説明文を下書きし、メモに無い点を挙げることです。

説明文の順を決めておくのは、第3章の（d）への答えです。 差の事実、要因、対応の順に2〜3文と決めれば、誰が承認しても資料の形がそろいます。

向きの食い違いは、AIに直させずに印だけを付けさせます。 メモに「悪化」と書かれていて、フローの判定が良化なら、どちらが正しいかを部門長が承認のときに確かめます。 AIが黙ってフローの判定に合わせて書き直すと、部門の認識の誤りが資料の外に消えます。

2行目がいちばん起きやすい失敗です。 「新規の MRR が目標を下回った」と渡すと、AIは「市場環境の変化」「競合の値下げ」のような、どの月のどの会社にも当てはまる要因を足します。 それらしく見えるので、承認の画面でそのまま通りがちです。

指示内容を固定する

あなたは経営企画の担当で、経営会議の資料に載せる KPI の説明文の
下書きを書きます。下の数値と、部門が書いた理由のメモだけを使って
ください。推測で要因を足さないでください。

【書き方】
- 2〜3文で書いてください。順は、差の事実、要因、対応です。
- 差の事実には、下の「実績」「目標」「差」「達成率」の文字列を
  そのまま使ってください。数値を丸めたり、言い換えたり、計算したり
  しないでください。
- 要因と対応は、部門のメモに書かれていることだけを書いてください。
  メモに無い要因（市場環境、競合、季節要因など）を足さないでください。
- メモが空の場合は、差の事実だけを書き、要因は書かないでください。
- 語尾は「〜しました」「〜です」にそろえてください。

【要確認の点】
- 差のうちメモで説明されていない部分、要因の影響の大きさ、
  対応の時期が書かれていなければ、open_points に1項目ずつ挙げてください。

【向き】
- この KPI は「{good_direction}」です。フローの判定は「{judgement}」です。
- メモの「良化」「悪化」「上がった」「下がった」などの表現が判定と
  食い違う場合は direction_mismatch を true にし、その文を写してください。
  説明文は判定に合わせて書き直さず、メモの表現も使わないでください。

【厳守事項】
- 施策の提案、目標の見直し、部門や担当者の評価を書かないでください。
- メモに個人の名前があっても、説明文には書かないでください。
- メモに他の KPI のことが書かれていても、この KPI に関係する文だけを
  根拠にしてください。
- evidence に、要因と対応の根拠にしたメモの文をそのまま写してください。
- Don't include JSON markdown in your answer.

【KPI】{kpi_name}（{definition}）　【部門】{department}
【実績】{actual}　【目標】{target}　【差】{diff}　【達成率】{rate}
【前月】{prev}　【過去3か月】{trend}
【部門の理由のメモ】{memo}

「メモに無い要因を足さない」に例を添えているのは、例が無いと効きにくいからです。 「市場環境」「競合」「季節要因」は、AIがいちばん足しやすい要因です。名前を挙げて禁じます。

向きが食い違ったときに「メモの表現も使わない」としているのは、承認の画面で部門長に気づいてもらうためです。 説明文からは良化・悪化の語が消え、direction_mismatch の印が承認の依頼の本文に出ます。

出力形式を固定する

プロンプトの出力は、Custom の JSON 形式として次の例で固定します。

{
  "draft": "新規の MRR は 1,820千円で、目標 2,400千円に対し 580千円下回りました（達成率 75.8％）。部門のメモでは、予定していた大口の顧客2社の契約が翌月にずれたことが挙げられています。契約は翌月の上旬に締結の見込みです。",
  "evidence": [
    { "text": "大口2社の契約が来月にずれ込み" },
    { "text": "来月上旬に締結予定" }
  ],
  "open_points": [
    { "point": "差の 580千円のうち、2社の契約が占める金額" }
  ],
  "direction_mismatch": false,
  "mismatch_text": ""
}

evidence と open_points をキー付きの配列にしているのは、キーの無い配列が定義できないからです。 ["abc", "def"] の形はできず、[{"text": "abc"}] の形にします。

項目に分けて受け取る理由の1つ目は、承認の依頼の本文を組み立てられることです。 承認の Suggested Text には draft だけを入れ、依頼の本文に open_points と direction_mismatch を並べます。 部門長は、何を書き足すべきかを見てから文面を直せます。

2つ目は、open_points の数で経営企画の確認の順を決められることです。 承認された文面でも open_points が残ったまま承認された項目は、経営会議の前に経営企画が部門長に一声かけます。

システムへ連携する

承認された文面と、直す前の下書きの両方を書き戻します。 KPI のリストに「下書き」「承認された文面」「承認者」「承認の日時」の列を持たせ、どこが直されたかを後から比べられるようにします。

KPI のリストに足す列は次のとおりです。

部門が書く列と、フローが書く列を分けます。 部門の入力の画面からは、フローが書く列を隠しておき、部門が下書きの列を直接書き換えて、承認を通らない文面が資料に入ることを防ぎます。

承認の依頼は、項目ごとに部門長へ出します。 1部門で10項目あれば10件の依頼が届きます。ループの中で承認を待つ作りにすると、前の項目の承認が返るまで次の依頼が出ない形になりうるので、項目ごとに別のフローを起動するなど、依頼を並べて出せる作りを利用環境に合わせて設計します。

Teams への知らせは、経営企画の標準のチャネルに出します。 投稿できるメッセージは約28KBまでで、プライベートチャネルには投稿できないとされています。進み具合は「承認済み 42／60」のような件数だけを出し、説明文の本文は載せません。

人が確認する

1. 部門長が下書きを直して承認する … 要因と対応が部門の認識と合っているか、open_points を書き足すかを決めます
2. 向きの食い違いの印を確かめる … direction_mismatch が true の項目は、メモと判定のどちらが正しいかを確かめます
3. 却下された項目 … 部門長が却下すると、経営企画に戻り、部門の担当と話して書き直します
4. 経営企画の読み直し … 承認された文面を資料に並べ、項目をまたいで重複や矛盾が無いかを見ます

2番目を省かないでください。 向きの取り違えは、経営会議で経営陣が最初に気づく誤りで、資料全体の信頼を下げます。

目標は、60件をならして1件12分です。 経営企画の時間として、起動、却下された項目の書き直し、open_points の残った項目の声かけ、資料への並べ直しを含めています。部門長が承認に使う時間は、Before の往復にも含めていないので、After にも入れていません。

例外に対処する

最後の行は、SaaS の会社でよく起きます。 解約率の分母を「月初の契約数」から「月中の平均」に変えた月に、前月との差をそのまま渡すと、定義の変更による差を要因として書きます。

記録を残す

• フローの実行ごとの対象の年月と、起動した人
• 項目ごとに渡した数値の文字列と、部門のメモの全文
• AIが返した JSON の全文（draft、evidence、open_points、direction_mismatch）
• 承認された文面と、直す前の下書き
• 承認者、承認の日時、却下の理由

4つ目が、プロンプトを育てる材料です。 下書きと承認された文面を月に一度見比べ、部門長が毎回消している言い回し、毎回足している情報を拾って指示に反映します。