社員からの中期経営計画・方針・組織変更の質問に、社内に公表した資料だけを根拠にチャットで答え、答えられない質問を経営企画へ毎月まとめる

処理の起点を決める

起点は、社員がチャット画面で質問を送ったことです。 画面は社内の ID でログインさせ、中継プログラムはその社員の資格情報で検索を呼びます。 経営企画の共通のアカウントで呼ぶと、閲覧制御がその社員ではなく経営企画の権限で働き、管理職向けの説明資料が一般の社員への回答に入ります。

質問は1件ずつ、送られたその場で答えます。 回答を経営企画が確かめてから返す運用にはしません。月240件のうち7割は公表資料にそのまま答えのある質問で、それを止めると経営企画の手間が減りません。 確かめる対象は、第7章「人間の確認」で決める条件に当たるものだけにします。

月末の取りまとめは、別の起点として毎月最終営業日の夕方に動かします。 その月の未回答の質問と、社員が「役に立たなかった」を押した回答を集めます。

資料の取り込みは、公表の手続きが済んだときに動かします。 経営企画が公表資料の台帳に「公表済み」と公表日を入れた時点で、写しを Cloud Storage に置いてデータストアに取り込みます。台帳に入れない限り、検索には入りません。

入力データを集める

質を決めるのは、公表資料の台帳の効力の期間と「置き換えた資料」の列です。 これが無ければ、昨年度の計画と今年度の計画を見分けられません。組織変更の通知は、発表日ではなく発令日を効力の開始日にします。 発表から発令までの2〜4週間は、旧組織の窓口がまだ有効だからです。

全社会議の質疑の記録は、公表したものだけを入れます。 会議で口頭で答えた内容のうち、経営企画が文字に起こして社内ポータルに掲載したものが対象です。録音の文字起こしをそのまま入れると、言い直しや言い淀みが根拠になってしまいます。

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

資料は、1ファイルを1つの文書として Cloud Storage に置き、メタデータ付きで取り込みます。 メタデータに、資料の種類、版、公表日、効力の開始日と終了日、閲覧の区分を持たせ、閲覧制御の情報（acl_info の閲覧できるグループ）も同じメタデータに書きます。

資料1つ分のメタデータは、例えば次のような形です。

{
  "id": "MTP-2026-explainer-v2",
  "jsonData": "{\"doc_type\":\"midterm_plan\",\"plan_version\":\"FY2026\",\"published_date\":\"2026-05-20\",\"effective_from\":\"2026-05-20\",\"effective_to\":\"2099-12-31\",\"supersedes\":\"MTP-2025-explainer-v1\",\"audience\":\"all\"}",
  "content": { "mimeType": "application/pdf", "uri": "gs://plan-qa/plan/MTP-2026-explainer-v2.pdf" },
  "acl_info": { "readers": [ { "principals": [ { "group_id": "[email protected]" } ] } ] }
}

いま有効な版への絞り込みは、日付の比較で書きます。 絞り込みの式は日付の項目に >= や < の比較を使え、ANY() と AND を組み合わせられるとされています。比較に使う項目は、データストアのスキーマで索引可能にしておく必要があります。

effective_from <= "2026-10-07" AND effective_to > "2026-10-07"

日付は中継プログラムが質問を受けた日を入れます。 置き換えられた資料の effective_to は、新しい資料の効力の開始日にします。古い版を消さずに残すのは、「昨年度の計画からどう変わったか」という質問に答えるためです。 その質問のときだけ、中継プログラムが絞り込みを外して両方の版を検索させます。

AIへ渡す前に整形する

1. 公表の確認 … 台帳で「公表済み」で公表日が入っている資料だけを取り込みます
2. 版と効力の期間を入れる … 計画は年度、組織変更は発令日、FAQは公表日を効力の開始日にします
3. 置き換えた資料をつなぐ … 新しい資料の supersedes に古い資料のIDを入れ、古い資料の effective_to を閉じます
4. 閲覧の区分を決める … 全社員向け、管理職向けの2区分を基本にし、閲覧できるグループに置き換えます
5. スライドの資料に説明の文を足す … 図だけで数値目標を示したスライドは、ページの下に数値を文で書いた版を作ってから取り込みます
6. 社員の名前を外す … 全社会議の質疑の記録で、質問した社員の名前を消してから取り込みます

5番目を軽く見ないでください。 中期経営計画の説明資料は、数値目標をグラフで示すことが多く、文に書かれていない数値は検索に当たりません。 当たらないと「資料にありません」と答え、社員は経営企画に聞き直します。

1番目は人の手続きです。 未公表の資料がデータストアに入る経路を、台帳の「公表済み」という1つの関門に絞ります。 経営企画の共有フォルダを丸ごと取り込む設定にはしません。

AIに処理させる

させるのは、公表済みでいま有効な資料から質問に当たる記載を見つけ、資料の言葉に沿って短く答え、出典を示すことです。

answer メソッドの設定は次のようにします。

filteringLevel は、裏付けの度合いが基準に届かない回答を返さない設定です。 低い基準と高い基準を選べ、指定しなければ絞り込みはかからないとされています。方針の説明で、資料に無い言い換えが混ざるのを防ぐため、高い基準から始めます。

1行目と2行目が最も起きやすい失敗です。 「今後の組織はどうなりますか」と聞かれると、モデルは資料の方向性の記述から先を推測して書きます。推測はそれらしく聞こえるので、社員は事実として受け取ります。 資料に書かれていない先のことは、書かせません。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは経営企画部の担当として、社員からの中期経営計画・全社方針・組織変更の
質問に、社内に公表した資料だけを根拠に答えます。読むのは全社員です。

【答え方】
1. 資料の言葉に沿って、3〜5文で答えてください。
2. 数値目標・日付・組織の名前は、資料の表記のまま書いてください。
3. 組織変更は、発表日と発令日を区別して書いてください。
   発令日より前の質問には「発令日までは現在の組織のままです」と添えてください。
4. 答えられる部分と答えられない部分があるときは、答えられる部分だけを書き、
   最後に「残りは経営企画部に確認を依頼しました」と書いてください。

【厳守事項】
- 資料に書かれていないことを書かないでください。今後の見通しを推測しないでください。
- 資料の数値から計算した数値を書かないでください。
- 個人の異動・評価・給与・処遇の質問には答えず、
  「人事部の相談窓口にお問い合わせください」とだけ書いてください。
- 方針が良いか悪いかを書かないでください。意見には
  「ご意見として経営企画部に伝えます」とだけ書いてください。
- 昨年度以前の計画を、いまの計画として書かないでください。
  比べるよう求められたときだけ、版の年度を明記して両方を書いてください。
- 当たる資料が見つからないときは、
  「公表済みの資料に該当する記載が見つかりません。経営企画部に確認を依頼しました」
  とだけ書いてください。

「発表日と発令日を区別する」を明記しないと、モデルは発表された新しい組織を、もう有効なものとして答えます。 社員は新しい窓口に連絡し、発令前でまだ動いていない部署に問い合わせが届きます。

「計算した数値を書かない」は、一見無害に見える計算ほど危ういためです。 全社の売上目標と事業部の目標から比率を出すと、資料に無い数値が社内で独り歩きします。 計画の数値は、公表された形のままで伝えます。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて記録します。

{
  "question_id": "",
  "asked_at": "",
  "dept_code": "",
  "session_id": "",
  "question": "",
  "status": "answered | partial | escalated | redirected_hr | skipped",
  "answer_text": "",
  "citations": [ { "doc_id": "", "doc_type": "", "plan_version": "", "effective_from": "" } ],
  "grounding_score": 0,
  "skipped_reasons": [""],
  "user_feedback": "helpful | not_helpful | none"
}

1つ目の理由は、status で返すか回すかを値で決められることです。

2つ目は、citations に版と効力の開始日を持たせることです。 古い版が出典になっていれば、中継プログラムが escalated に切り替えます。絞り込みが漏れたときの最後の守りです。

3つ目は、dept_code で部署だけを残し、社員の名前を月次のまとめに出さないことです。 質問した社員は記録の上では分かりますが、経営企画に渡すまとめでは部署と件数だけにします。 社員が遠慮せずに聞けることが、このチャットの価値です。

システムへ連携する

月次のまとめは、記録から未回答の質問を集めて Gemini に渡し、似た質問を束ねさせます。 束ねた質問ごとに件数・部署・代表的な質問の文を並べ、件数の多い順に経営企画へ渡します。 束ね方の誤りは件数の誤りに直結するので、代表の質問と束ねた質問の一覧を並べて、経営企画が確かめられる形にします。

人が確認する

社員への回答を、すべて人が確かめることはしません。 確かめるのは次のものだけです。

1. 回された質問（escalated と partial） … 経営企画の担当者が1日1回見て、個別に答えます。答えた内容が今後もくり返し聞かれそうなら、FAQの候補に印を付けます
2. 「役に立たなかった」を押された回答 … 回答と出典を読み、資料の不足か版の取り違えかを見ます
3. 最初の1か月の answered … 運用を始めた月は、答えた回答を毎日20件ずつ抜き出して読み、推測や計算が混ざっていないかを確かめます
4. 月次のまとめ … 束ねた質問を読み、資料の追記、FAQの公表、全社会議での説明、人事への連絡に振り分けます

3番目を省かないでください。 最初の月に推測が混ざる型を見つければ、preamble を直して翌月から防げます。見つけないまま回すと、誤った説明が社内に広がってから気づきます。

人の確認を「条件付き」にしているのは、方針の説明が公表資料の写しで足りるからです。 公表した内容を公表した言葉で伝える限り、1件ずつの承認は要りません。承認が要るのは、資料の外に出る回答です。 それは escalated として必ず人に回ります。

例外に対処する

4行目は、閲覧制御が正しく働いている結果です。 一般の社員には見えない資料なので、経営企画が見て、答えてよい範囲を判断します。

記録を残す

• 質問の全文と日時、質問した社員と部署、セッションのID
• answer メソッドの応答の全文（回答、出典、裏付けの度合い、回答しなかった理由）
• status と、そう決めた条件
• 回答に使った資料の版と、そのときの公表資料の台帳の内容
• 経営企画が個別に答えた内容と、FAQの候補にしたかどうか
• 社員の「役に立った／役に立たなかった」の記録
• 月次のまとめと、経営企画の振り分けの結果

4つ目を残すのは、版が後から置き換わるためです。 計画の見直しのあとに「先月チャットでこう言われた」と問い合わせがあったとき、当時どの版を根拠に答えたかが分かれば、答えが誤りだったのか、計画が変わったのかを区別できます。

記録の閲覧は経営企画の担当者に限ります。 質問した社員の名前が入っているからです。