各部門の月次報告に書かれたリスク・懸念の記述を拾って種類と影響の大きさで分類し、全社のリスク一覧の更新案と前月からの変化を経営企画にまとめる

処理の起点を決める

処理は、毎月8日の7時台に動く時間主導型のトリガーを起点にします。 ScriptApp.newTrigger() に timeBased()・onMonthDay(8)・atHour(7) を続けて作ります。公式のページでは、時刻は少しずれることがあり、9時に設定すると9時から10時のあいだで選ばれ、その時刻が保たれるとされています。経営企画の始業までに更新案ができていれば足ります。

8日にするのは、7日の提出の締めを待つためです。 7日が土日に当たる月も、提出の締めは変えず、8日に動かします。遅れて出た報告は、経営企画がメニューから「この部門だけ再処理」を実行して足します。 再処理ではその部門の更新案だけを書き換え、ほかの部門の承認の印は触りません。

未提出の部門は、8日の時点で一覧の最初に出します。 未提出は経営企画が部門に催促します。スクリプトから部門に催促のメールは送りません。催促は人の関係の話で、毎月同じ文面が届くと読まれなくなるからです。

入力データを集める

質を決めるのは、いちばん下の2つです。 種類の説明と影響の目安が書かれていなければ、AIの分類は担当者の頭の中と同じく揺れます。目安は、経営企画が過去の一覧の付け方を見直して文にします。 たとえば影響の「大」を「売上の1％以上、主要顧客の取引停止、許認可に関わる法令違反、1日以上の基幹業務の停止のいずれか」のように書きます。

一覧から渡すのは、その部門が主管の行と、全社共通の行だけです。 120行を全部渡すと、AIは似た名前の別の部門の行に結び付けがちです。部門をまたぐ懸念は全社共通の行に結び付くように、一覧の側で共通の行を決めておきます。

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

処理は、次の順で行います。

1. 20部門のフォルダから、ファイル名が「月次報告_YYYYMM_部門名」の前の月のものを探す
2. 無ければ未提出として一覧に載せる（AIは呼ばない）
3. 本文の段落を見て、リスク・懸念の欄の段落を集める
4. 欄が見つからなければ「様式の見出しが違う」として載せる（AIは呼ばない）
5. 欄の文が「特になし」「該当なし」だけなら、記述0件として扱う（AIは呼ばない）
6. 段落ごとに番号を振る（P-03-01 など）
7. 部門ごとに Gemini API を呼び、JSON を受け取る
8. 根拠の文が欄の本文に含まれるかを文字列で確かめる
9. 前の月の結び付きと比べ、変化を規則で決める
10. 更新案のシートに書き、経営企画に知らせる

9番目の変化は、次の5つに決めます。

「記述が消えた」と「解消の記述あり」を分けるのが、第1章で書いた区別です。 前者は部門に確かめる項目、後者は経営企画が状態を「解消」にするかを決める項目です。記述が消えただけで状態を変えることはしません。

AIへ渡す前に整形する

1. 欄の外を渡さない … 業績や活動の段落は渡しません。売上の数字や取引先の名前が、リスクの記述と混ざらないようにします
2. 段落に番号を振る … AIには根拠をこの番号と、段落の中の文の写しで返させます
3. 個人の名前を伏せる … 欄の中に社員や取引先の担当者の名前があれば、部門の一覧と取引先の一覧の名前で「社員」「先方の担当者」に置き換えます
4. 前の月の結び付きを添える … 前の月にこの部門の記述が結び付いた一覧の番号と名称を添えます。AIは「先月からの続き」を見分けやすくなります
5. 長すぎる欄を分ける … 欄が数千字を超える部門は、段落の区切りで2回に分けて呼びます

3番目は、リスクの記述に人の事情が書かれることがあるからです。 「担当者の退職で引き継ぎが滞る」のような記述は、リスクとしては「人材・労務」の話で、誰が辞めるかはリスク一覧に要りません。

AIに処理させる

させるのは、欄の記述を1件ずつのリスクに分け、それぞれを種類と影響の大きさに分類し、既存の行への結び付きを返すことです。

種類は、経営企画が決めた10の語彙から選ばせます。 法令・コンプライアンス、情報セキュリティ、人材・労務、取引先・調達、品質・製品、財務・為替、システム障害、災害・事業継続、評判・顧客、その他です。語彙を固定すると、第3章の（b）で書いた「同じ懸念が担当者で別の種類になる」揺れが消えます。

5行目が、この構成でいちばん守るべきことです。 「為替の動きが気になる」とだけ書かれた記述を渡すと、AIは一般論から「影響は大きい」と書きがちです。記述に規模や範囲の手がかりが無ければ、影響の案は unknown にさせます。 経営企画は unknown の記述を部門に聞き返し、次の月から書き方をそろえてもらいます。

指示内容を固定する

あなたは会社の経営企画部で、部門の月次報告のリスク・懸念の記述を、
全社のリスク一覧に照らして仕分ける担当です。
リスクの評価を確定する立場ではありません。仕分けの「案」を出します。

【入力】
- 部門名、対象の月
- リスク・懸念の欄の段落（paragraph_id 付き）
- この部門が主管の一覧の行と、全社共通の行（番号・名称・種類・説明）
- 前の月にこの部門の記述が結び付いた行の番号と名称
- 種類の語彙（10個）と、影響の目安（high / medium / low の説明）

【してほしいこと】
1. 段落の中の懸念を1件ずつに分ける（1つの段落に複数あれば分ける）
2. 各件に、種類の語彙から1つを選ぶ
3. 各件に、影響の目安に照らして high / medium / low / unknown を選ぶ
4. 各件に、結び付く一覧の行の番号を1つ選ぶ。無ければ new、
   2つ以上の行に同じくらい近ければ unclear とし、候補の番号を並べる
5. 記述に解消・完了の旨が書かれていれば resolved_stated を true にする
6. 各件に、根拠の paragraph_id と、根拠にした文をそのまま写す

【厳守事項】
- 影響の目安に当てはめる手がかり（金額、顧客、法令、停止の長さ）が
  記述に無ければ、impact を unknown にしてください。推し量らないでください。
- 根拠の文は、段落の文字をそのまま写してください。言い換えないでください。
- 前の月にあった行が今月の記述に無いことについて、何も書かないでください。
  それは別の仕組みで扱います。
- 対応策や優先順位を書かないでください。
- 個人を特定できる記述を書かないでください。

【部門の記述】{paragraphs_json}
【一覧の行】{register_rows}
【語彙と目安】{vocab}

「根拠の文をそのまま写す」は、第7章のデータの取得方法の8番目のための指示です。 写した文が欄の本文に含まれているかを文字列で確かめるので、言い換えられると照合に落ちます。 落ちた件は、AIが記述に無いことを書いた疑いとして経営企画に回ります。

「前の月にあった行が今月無いことについて書かない」は、役割を分けるための指示です。 前の月の結び付きを渡しているので、AIは「R-041 は今月言及が無く、解消したと考えられる」と書きたくなります。それは規則の「記述が消えた」の仕事で、解消かどうかは部門に聞くまで分かりません。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "department": "",
  "month": "",
  "items": [
    { "item_no": 1,
      "summary": "",
      "category": "compliance | infosec | people | supply_chain | quality | finance | system | bcp | reputation | other",
      "impact": "high | medium | low | unknown",
      "match": "existing | new | unclear",
      "register_ids": [""],
      "resolved_stated": false,
      "evidence": { "paragraph_id": "", "quote": "" } }
  ]
}

スキーマでは category・impact・match を enum で縛り、evidence を required にします。quote が欄の本文に含まれない件は、更新案に「根拠の照合に失敗」と出し、承認できない状態にします。

理由の1つ目は、分類と変化を別の層に置けることです。 AIの JSON は今月の記述の分類だけで、前の月との比較は規則が更新案のシートの列で出します。 AIの答えが月によって揺れても、変化の判定の仕方は変わりません。

2つ目は、unclear で迷いを残せることです。 近い行が2つあるときに1つを選ばせると、外れたときに気づけません。候補を並べて返させ、経営企画が選びます。 選んだ結果を、次の月の前の月の結び付きとして渡します。

3つ目は、impact を案として持てることです。 一覧の影響の列は人が決めた値のままにし、更新案のシートに「AIの案」「一覧の値」を並べます。差がある行だけを見れば、見直すべき行が分かります。

経営企画に届く知らせは、更新案のシートの要点です。

【9月分 リスク・懸念の仕分け（20部門中19部門提出／未提出：海外営業部）】
■ 新規の候補 3件
  調達部「主要部品の仕入先1社が値上げを通知。代替先は未認定」
    → 取引先・調達／影響の案 medium／根拠 P-07-02
■ 影響の案が上がった 2件
  R-041 基幹システムの保守期限（情報システム部）low → medium
■ 記述が消えた 4件（部門に確認してください）
  R-018 物流費の上昇（物流部）：8月まで記述あり、9月は記述なし
■ unclear 1件／根拠の照合に失敗 0件／影響 unknown 5件

システムへ連携する

API キーはスクリプトのプロパティに置き、スクリプトの編集の権限は経営企画の2名に絞ります。 公式の割り当てでは、1回の実行は6分まで、URL Fetch の呼び出しは Google Workspace のアカウントで1日10万回です。部門ごとに1回、月20回ほどの呼び出しです。 6分を超えそうなときは、終わった部門を記録して続きのトリガーで残りを処理します。

月次報告のドキュメントには書き込みません。 部門の報告は部門のものです。一覧への反映も自動では行わず、経営企画がメニューを実行したときに、承認の列に印のある行だけを書きます。

人が確認する

1. 未提出と様式の違いを片付ける … 未提出は催促し、見出しの文字が違う報告は様式を直してもらってから再処理します
2. 根拠の照合に失敗した件を見る … 本文を開き、記述に本当にあるかを確かめます
3. 新規の候補と unclear を決める … 既存の行に寄せるか、新しい行にするかを決めます
4. 影響の案が一覧の値と違う行を見る … 一覧の値を変えるかを決めます。変えるときは、根拠の文を委員会の資料に添えます
5. 記述が消えた行を部門に聞く … 解消したのか、書き忘れか、まだ続いているのかを確かめます
6. 承認の列に印を付けて反映する

承認しなかった案には、理由を一言残します。 「既存の R-018 に寄せる」「影響は low のまま」のような短い書き込みで足ります。この書き込みが半年分たまると、どの種類で案が外れやすいかが分かり、目安の書き直しの材料になります。

目標は、20部門をならして1部門9分です。 継続の行は流し見るだけ、新規の候補と影響の案の変化は数分、記述が消えた行の聞き取りは部門とのやり取りで十数分です。unknown が多い部門には、影響の目安を添えて書き方を頼みます。

例外に対処する

3行目を省かないでください。 「特になし」の部門を処理から外すだけにすると、先月まで書かれていた懸念が黙って消えます。 第3章の（d）で書いた見落としは、まさにこの形で起きます。

記録を残す

• 更新案のシート：月ごとのタブに、部門、記述の番号、要約、種類、影響の案、結び付き、根拠、変化、承認の結果と承認した人
• 全社のリスク一覧の変更の履歴（いつ、どの行の、どの列を、どの更新案で変えたか）
• AIに渡した段落の番号と、返った JSON の全文
• その月に使った種類の語彙と影響の目安の版
• 未提出と様式の違いの記録

目安の版を残すのは、目安が委員会で変わるからです。 影響の「大」の線を下げた月は、high の案が増えます。版が残っていないと、リスクが増えたのか線を下げただけなのかを説明できません。