年度計画のヒアリングをAIとの対話で行い、数字の前提と根拠を埋めてから提出させる

処理の起点を決める

部門の担当者が、提出の前に計画の下書きをエージェントへ渡したときを起点にします。

提出の前に置くことが、この構成の要です。 提出後に使っても、経営企画の作業は減りません。「提出の前に必ず通す」を運用のルールにしてください。

ルールにするだけでは定着しません。経営企画側で「エージェントを通していない計画は受け付けない」とするのが確実です。 強制に見えますが、部門にとっても差し戻しが減るため、1回経験すれば納得されます。

窓口は Teams にしてください。 予算管理システムの中に組み込めればそれが理想ですが、製品によっては難しくなります。部門の担当者がすでに使っている場所に置くことのほうが、統合の美しさより重要です。

2つ目の起点として、四半期の見直しの時期があります。 年度計画と同じ様式で、前提の変化を聞きます。「年度計画のときの前提が、いま変わっていないか」を確認する形です。

3つ目の起点は、スケジュールによる集計です。 提出の期間中は毎日、通常期は週次で、まだ通していない部門と、対話の往復が多かった部門を集計して経営企画へ渡します。

入力データを集める

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

必須項目のチェックリストが、この構成の質を決めます。 12項目それぞれについて、次の形で持ってください。

「曖昧とみなす表現」の列が、この構成でもっとも効きます。 「前年並み」とだけ書かれていることを検出できるかどうかで、価値が変わります。各項目に3〜5個ずつ挙げてください。

「記入例」も必ず書いてください。 対話で聞き出すとき、例を示せると答えやすくなります。経験の浅い担当者には、これがそのまま教育の材料になります。

過去の計画と実績： 直近3年分を持ちます。計画と実績の差が大きかった項目は、前提の置き方に問題があった可能性があります。

「3年連続で同じ前提」は、実は要注意です。 「稼働率は前年並みで推移」が3年書かれているなら、前提を考え直していない可能性があります。

外部環境の前提： 全社で統一する数字です。金利、物価上昇率、人件費の上昇率など。 これを配っているのに、部門が独自の前提を使っていることがあります。照合の対象にしてください。

過去の指摘： 運用を始めてからたまります。最初は空で構いません。 1年分たまれば、部門ごとに抜けやすい項目が見えます。

AIへ渡す前に整形する

1. 部門の種類の判定 … 運営部門か管理部門かを判定します。種類によって必須項目が変わります
2. 必須項目の対応づけ … 計画書の欄と、チェックリストの12項目を対応づけます。部門が様式を崩している場合があるため、欄の名前だけでなく内容からも対応づけます
3. 数値の抽出 … 売上、稼働率、単価、費用の各項目の数値を取り出します
4. 前年比の計算 … 過去の実績と比べた増減率を計算します。この計算はシナリオ側で行い、AIには結果を渡します
5. 外部環境の前提との照合 … 部門が使っている前提と、全社で配った前提を突き合わせます
6. 未公開情報の確認 … 新規の投資、組織の変更など、公表前の情報が含まれる計画は、対象から外すか該当部分を伏せます

4の計算をシナリオ側で行うことが重要です。 数値をAIに渡すと、検算を始めて桁を間違えることがあります。計算は確定させ、AIには判断だけをさせてください。

6の確認は、上場企業では特に重要です。 年度計画には、公表前の投資や事業の再編が含まれることがあります。外部のAIサービスへ渡してよい範囲を、先に決めてください。

AIに処理させる

2つの工程に分けます。

（1）抜けと曖昧さを見つける工程

（2）対話で聞き出す工程

数字の妥当性を判断させません。 「この目標は高すぎます」「達成は難しいと考えられます」といった記述を出させないでください。目標の水準は経営の判断です。

将来の予測もさせません。 「市況から見て稼働率は下がる見込みです」といった記述も禁じます。外部環境の見通しは経営企画が配るものです。

数字の計算もさせません。 前年比、構成比、合計は、シナリオ側で計算します。

指示内容を固定する

対話の方針は、会話の冒頭で固定します。

あなたは経営企画部で年度計画の取りまとめを支援する担当者です。
部門が作った計画の下書きについて、書かれていない前提を聞き出し、
経営企画のレビューに回せる状態に整えることが役割です。

【厳守事項】
- 数字の妥当性を評価しないでください。
  「この目標は高すぎます」「達成は難しいと思われます」「妥当な水準です」
  と書かないでください。
  **目標の水準は経営が判断することです。**
- 将来の予測をしないでください。
  「市況から見て下がる見込みです」「金利は上昇すると考えられます」
  と書かないでください。
  外部環境の前提は、経営企画が配った資料に書かれているものだけを使ってください。
- 数字を計算しないでください。
  前年比、構成比、合計はすでに計算済みです。
  与えられた数値をそのまま使ってください。
- 計画を承認しないでください。
  「これで問題ありません」と言わないでください。
  最後に「経営企画のレビューへお進みください」と伝えてください。
- 質問は1つずつしてください。抜けが5つあっても、一度に5つ聞かないでください。
  1つ答えてもらってから次を聞いてください。
- 質問には必ず記入例を添えてください。
  「稼働率の前提を教えてください」ではなく、
  「稼働率の前提を教えてください。たとえば『期首94％、期末96％。3階の空室は
   第2四半期に埋まる見込み』のように、時期と根拠が分かる形でお願いします」
  と聞いてください。
- 同じ項目を3回聞いても具体的な答えが出ない場合、それ以上聞かずに
  「この項目は未確定としてレビューに回します」と伝えて次へ進んでください。
  **しつこく聞くと、次から使ってもらえなくなります。**
- 回答を評価しないでください。「良い計画ですね」と言わないでください。
- 部門の担当者を評価しないでください。
  「前提の整理が不十分です」と書かないでください。
- 全社で配った外部環境の前提と違う数字が使われている場合、
  どちらが正しいかを決めず、「全社の前提は◯◯ですが、こちらは△△となっています。
  理由を教えてください」と聞いてください。

抜けを見つける側の指示は次のようになります。

下の計画の下書きについて、必須項目の記載の有無と曖昧さを判定してください。

【厳守事項】
- 判定は、下の「必須項目のチェックリスト」に照らして行ってください。
  一般的な事業計画の書き方で補わないでください。
- 記載があるかどうかと、書くべき粒度に達しているかを分けて判定してください。
  「前年並み」とだけ書かれている場合、present は true、sufficient は false です。
- 曖昧と判定した場合、チェックリストの「曖昧とみなす表現」のどれに当たるかを示してください。
- 部門の種類によって必須かどうかが変わる項目は、下の種類に従ってください。
- 計画に書かれていない前提を推測で補わないでください。
- 数字の妥当性、目標の水準について書かないでください。

【部門の種類】
{department_type}

【計画の下書き】
{plan_draft}

【必須項目のチェックリスト（項目名 / 定義 / 書くべき粒度 / 曖昧とみなす表現 / 記入例 / 種類による要否）】
{checklist}

【計算済みの数値（前年比・構成比・過去3年の実績との比較）】
{computed_figures}

【全社で配った外部環境の前提】
{corporate_assumptions}

【この部門で過去によく指摘された項目（上位5件）】
{frequent_findings}

「一度に5つ聞かない」の指示が、この構成でもっとも重要です。 抜けを一覧で突きつけられると、部門の担当者は圧倒されます。1つずつ答えるほうが、結果として早く終わります。

「3回で切り上げる」も必須です。 部門がまだ決めていない前提があります。「大口テナントの更新の意向がまだ分からない」という状態は正常です。 そこをしつこく聞くと、次から使われなくなります。未確定のままレビューに回し、経営企画が判断すればよいことです。

「数字の妥当性を評価しない」の指示は、この構成の性格を決めます。 AIが「この目標は高すぎます」と言えば、部門はそれに引きずられて目標を下げます。計画の水準は、経営の意思が入るところです。

OpenAI の Responses API では、previous_response_id を指定して応答を連鎖させます。 前の応答の文脈がモデルに渡され、過去のやり取りを自分で連結する必要がありません。ただし、連鎖した一連の応答の入力トークンはすべて入力として課金されます。 対話が長くなるほど費用が伸びます。

Conversations API を使えば、会話を持続的な識別子を持つオブジェクトとして保持できます。 部門の担当者が途中で中断して、後日続きを答える形に向きます。年度計画の作成は数日にわたるため、この方式が実務に合います。

出力形式を固定する

{
  "plan_id": "",
  "department": "",
  "department_type": "operation | admin",
  "fiscal_year": "",
  "items": [
    {
      "item_name": "",
      "required": true,
      "present": false,
      "sufficient": false,
      "original_text": "",
      "vague_expression": "",
      "reason": "",
      "filled_by_dialogue": "",
      "status": "ok | filled | undetermined | not_required"
    }
  ],
  "yoy_explanations": [
    { "metric": "", "yoy_rate": "", "breakdown_present": false, "breakdown_text": "" }
  ],
  "assumption_conflicts": [
    { "item": "", "corporate_value": "", "department_value": "", "reason_given": "" }
  ],
  "dialogue_turns": 0,
  "undetermined_items": [],
  "formatted_plan": "",
  "ready_for_review": true
}

present と sufficient を分けていることが、この構成の核です。 「稼働率の前提：前年並み」は present: true かつ sufficient: false です。この2つを1つにすると、「書いてあるから問題なし」として通ってしまいます。

yoy_explanations を独立させている理由があります。 前年比の増減に内訳が書かれているかは、計画のレビューでいちばん問われる点です。項目の有無とは別に管理する価値があります。

assumption_conflicts は、全社の前提との食い違いです。 人件費の上昇率を全社で3％と配っているのに、部門が1％で計算していることがあります。どちらが正しいかを決めず、理由を聞いて並べます。

undetermined_items は、対話でも埋まらなかった項目です。 これがあること自体は問題ではありません。経営企画が「この前提が未確定のままでよいか」を判断します。

formatted_plan は、埋まった内容を様式に整えたものです。 部門の担当者はこれをコピーして計画書を更新します。自動で計画書を書き換えないでください。 内容を確認してから反映します。

システムへ連携する

対話の結果は、部門の担当者へ返すだけです。 計画書への自動反映はしません。

理由は、部門が内容を確認する機会を残すためです。 対話の中で答えた内容が、意図どおりに整形されているとは限りません。コピーして貼るという一手間が、確認の機会になります。

予算管理システムへの書き戻しも行いません。 計画の提出は部門が行います。

経営企画への報告は、スケジュールで自動化して構いません。 Make のシナリオを平日の朝に走らせ、「まだ通していない部門」「対話の往復が多かった部門」を一覧にします。 提出の期間中は毎日、通常期は週次に切り替えます。

この切り替えは、シナリオの実行の間隔を変えるだけです。 毎日・平日・毎週・毎月・指定した日付から選べるため、時期によって設定を変える運用ができます。

人が確認する

経営企画のレビューは、必ず残します。

この構成が減らすのは「前提の聞き出し」であって、「計画の評価」ではありません。対話を通ったことは、計画が妥当であることを意味しません。

経営企画が見るべきものが変わります。

確認を速くするための設計が効きます。

• undetermined_items を計画書の先頭に表示する
• dialogue_turns が多い計画に印を付ける（下書きの完成度が低かった）
• assumption_conflicts を目立つ形で示す
• 同じ部門の過去の undetermined_items を併記する
• 過去3年の計画と実績の乖離を併記する

2つ目が効きます。 対話の往復が20回を超えた計画は、下書きの段階でほとんど書かれていなかったということです。その部門には、計画の作り方そのものを説明する必要があります。

5つ目も重要です。 過去3年、計画を大きく外している部門は、前提の置き方に構造的な問題がある可能性があります。 そこは対話では解決しません。経営企画が直接見るべき部分です。

例外に対処する

「提出前に通さず出してくる」への対処が、定着の分かれ目です。 運用のルールだけでは守られません。経営企画側で「通していない計画は受け付けない」とするのが確実です。

記録を残す

この記録は、計画の様式を改善する材料になります。

• 対話の全文（何を聞き、どう答えたか）
• 抜けていた項目と、曖昧だった表現
• 未確定のまま残った項目
• 対話の往復数
• 全社の前提との食い違いと、その理由
• 経営企画がレビューで追加で指摘した内容
• 計画と実績の乖離（期末に振り返る）

「経営企画がレビューで追加で指摘した内容」が、この構成を育てます。 エージェントが見つけられなかった抜けが、ここに記録されます。同じ指摘が繰り返されるなら、チェックリストにその項目を追加します。

最後の項目は、1年後に効きます。 計画と実績が大きく外れた項目について、そのときの前提がどう書かれていたかを振り返ってください。 「前年並み」としか書かれていなかった項目が外れているなら、その項目の粒度を上げるべきです。

対話の全文には、未公表の経営情報が含まれます。 新規の投資、組織の変更、大口の取引先の動向。保管場所を経営企画部に限定し、閲覧範囲も絞ってください。

人事評価に使わないことも、運用として明示してください。 「抜けが多い」ことが評価に響くと、対話を通さずに提出するようになります。部門の担当者にとって、これは自分の仕事の質を測られる場ではありません。

上場企業では、未公表の決算情報に当たる内容が含まれることに注意してください。 外部のAIサービスへ渡してよい範囲を、法務・IRの担当と決めてください。