取締役会・経営会議の議事録と決議の記録から「この件は決議済みか・どんな条件が付いたか」を根拠付きで返し、付議の要否の判断に使う

処理の起点を決める

起点は、部門の担当者が照会画面から照会を送ったことです。 画面は社内の ID でログインさせ、中継プログラムはその人の資格情報で検索を呼びます。 事務局の共通のアカウントで呼ぶと、閲覧制御が照会した人ではなく事務局の権限で働き、見てはいけない議案が回答に入ります。

照会は1件ずつ、送られたその場で処理します。 ただし部門へは直接返さず、事務局の確認待ちの一覧に載せます。事務局は一覧を1日2回見る運用にします。

取締役会と経営会議が開かれたときも、別の起点として動かします。 議事録が確定して文書管理の仕組みに登録されたら、議案単位に分けて取り込み、決議台帳に「変更した議案」の列を事務局が入れた時点で、検索と台帳の両方に反映します。

入力データを集める

質を決めるのは、決議台帳の「変更した議案」の列です。 これが無ければ、第5章の3番目のたどりができません。10年分の約4,000議案すべてに入れる必要はなく、照会の多い枠と方針の議案から始めます。

決議の区分を持たせるのは、報告と継続審議を決議と混ぜないためです。 経営会議で「検討状況を報告した」だけの議案は、決議があったことにはなりません。 照会への回答で「経営会議で審議済み」と書くと、決議済みと読まれます。

取締役会規程の付議基準は、検索のデータストアには入れません。 事務局が見立てを書くときに開くもので、モデルに付議の要否を書かせないためです。

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

議事録は、議案ごとに1つの文書として Cloud Storage に置き、メタデータ付きで取り込みます。 メタデータに、会議体、会議の日付、議案番号、決議の区分、閲覧の区分を持たせ、閲覧制御の情報（acl_info の閲覧できるグループ）も同じメタデータに書きます。

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

{
  "id": "BM-2024-07-03",
  "jsonData": "{\"body\":\"board\",\"meeting_date\":\"2024-07-25\",\"agenda_no\":\"BM-2024-07-03\",\"resolution_type\":\"approved\",\"access_class\":\"managers\"}",
  "content": { "mimeType": "application/pdf", "uri": "gs://minutes-search/board/BM-2024-07-03.pdf" },
  "acl_info": { "readers": [ { "principals": [ { "group_id": "[email protected]" }, { "group_id": "[email protected]" } ] } ] }
}

閲覧制御を有効にしたデータストアでは、閲覧の情報を議事録と同じバケットのメタデータで渡すとされています。閲覧の区分を変えたら、このメタデータを直して取り込み直します。

検索には、絞り込みと並べ替えと優先度の調整を組み合わせます。 絞り込みは resolution_type: ANY("approved","rejected") で報告と継続審議を外し、並べ替えは orderBy で会議の日付の新しい順にできます。orderBy の式は大文字と小文字を区別し、認識できない項目なら INVALID_ARGUMENT を返すとされています。

取締役会の決議を経営会議の決議より上に出したいときは、boostSpec の条件付きの調整を使います。 条件を絞り込みと同じ式で書き、−1から1の値で優先度を上げ下げできるとされています。経営会議で方針を決め、取締役会で正式に決議した議案は、取締役会の側を先に示すためです。

決議台帳は、検索ではなく表として読みます。 議案番号の対応は、機械的にたどるためのものだからです。

AIへ渡す前に整形する

1. 議事録を議案ごとに分ける … 1回の会議の議事録を、議案番号の見出しで分け、議案ごとの文書にします
2. 報告事項を区分する … 議事録の「報告事項」の見出しの下にある議案は、決議の区分を「報告」にします
3. 決議台帳に変更のつながりを入れる … 事務局が、変更した議案と変更された議案の番号を両方向に入れます
4. 閲覧の区分を決める … 議案ごとに、全社員・部長以上・役員と事務局、のような区分を決め、閲覧できるグループに置き換えます
5. 付議資料を議案に結び付ける … 付議資料のメタデータに同じ議案番号を入れます
6. 紙の議事録を電子化する … 古い議事録で紙だけのものは、スキャンしてOCRをかけてから分けます

1番目は、データストアの分割とは別に行います。 データストアの分割は断片の大きさで機械的に区切るので、議案の境目と断片の境目が合いません。 議案ごとに文書を分けておけば、1つの断片に2つの議案が混ざることがなく、閲覧制御も議案ごとに付けられます。

1. 確定した議事録だけを入れる … 署名または記名押印の済んだ確定版だけを取り込み、案の段階のものは入れません

6番目の電子化は、照会の多い年から進めます。 10年分をそろえてから始める必要はなく、検索に出ない年があることを照会画面に明記しておけば足ります。

3番目を軽く見ないでください。 「あわせて前回の枠を減額する」のように別の議案の中で変更したものは、議事録を読んだ事務局にしか分かりません。 会議の後に議事録を確定させるときに、変更のつながりを台帳に入れる手順を足します。

AIに処理させる

させるのは、照会の案件に当たる決議を見つけ、その決議の内容と付いた条件を、議事録に書かれた言葉のまま短く返すことです。

「現在の条件」を、最初の決議の条件と別の欄にするのが要です。 1つの文にまとめると、モデルは最初の決議の言葉と後の決議の言葉を混ぜ、「上限30億円（期限は2027年3月まで）」のように、どの時点にも存在しなかった条件を作ります。 欄を分け、現在の条件の欄には後の議案の出典を必ず付けさせます。

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

2行目が最も起きやすい失敗です。 「枠はいくら残っているか」と聞かれると、モデルは議事録の上限から付議資料の金額を引いて答えます。実行済みの金額は議事録に無いので、その答えは必ず外れます。 残りは書かせず、上限と、確かめる先を書かせます。

指示内容を固定する

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

あなたは取締役会と経営会議の事務局として、過去の決議を議事録から探す担当です。
読むのは事務局の担当者で、あなたの回答を確かめてから部門に返します。

【答え方】
1. 当たる決議：会議体、日付、議案番号、議案名
2. 決議の内容：議事録に書かれた決議の文を、そのまま書いてください
3. 付いた条件：金額の上限、期間、報告の義務などを、議事録の言葉のまま箇条書きで
4. 後の変更：この決議を変えた後の議案があれば、日付・議案番号・変えた内容を書いてください
5. 現在の条件：後の変更を反映した条件を、後の議案を出典にして書いてください

【厳守事項】
- 議事録に書かれていないことを書かないでください。審議の背景を推測しないでください。
- 条件の言葉を言い換えないでください。「原則として」「事前に」などの語を省かないでください。
- 報告事項や継続審議の議案を、決議として書かないでください。
- 枠の残りの金額を計算しないでください。
  「実行済みの金額は経理の記録で確認が必要です」と書いてください。
- 付議が必要か不要かを書かないでください。
- 最初の決議の条件と後の決議の条件を、1つの文にまとめないでください。
- 当たる決議が見つからないときは、
  「該当する決議は見つかりません。事務局が確認します」とだけ書いてください。

「付議が必要か不要かを書かない」を明記しないと、モデルは結びに見立てを書きます。 照会した部門はその1行だけを読みます。付議の要否は、会社法が取締役に委任できないとする重要な財産の処分や多額の借財などに当たるかを、規程と照らして事務局が決めることです。

中継プログラムは、台帳でたどった後の議案が出典に無いとき、検索の文に議案番号を足して作り直させます。 例えば「議案 BM-2024-07-03 の決議の内容と、それを変更した BM-2025-11-02 の内容を答えてください」のように、議案番号で後の議案を名指しします。

出力形式を固定する

answer メソッドの応答と台帳のたどりの結果を、中継プログラムが次の形に整えます。

{
  "inquiry_id": "",
  "requested_by": "",
  "status": "found | not_found | needs_review",
  "resolutions": [
    {
      "body": "board | management_committee",
      "date": "",
      "agenda_no": "",
      "title": "",
      "resolution_type": "approved | rejected",
      "decision_text": "",
      "original_conditions": [""],
      "amended_by": [ { "agenda_no": "", "date": "", "change": "" } ],
      "current_conditions": [ { "text": "", "source_agenda_no": "", "support_score": 0 } ]
    }
  ],
  "chain_complete": true,
  "answer_text": ""
}

1つ目の理由は、original_conditions と current_conditions を別に持てることです。 事務局の確認の画面では2つを左右に並べ、変わった条件に色を付けて示します。

2つ目は、chain_complete でたどりが終わったかを値で持てることです。

3つ目は、requested_by を残すことで、誰の権限で検索したかが後から分かることです。

システムへ連携する

文書管理の仕組みには書き込みません。 議事録の原本は確定したものだけを事務局が登録し、この構成は検索用の写しを読むだけです。

人が確認する

すべての回答を、事務局の担当者が確かめてから部門へ返します。

1. 出典の議事録を開く … 決議の文と条件が、議事録のとおりかを確かめます
2. 後の変更を確かめる … amended_by の議案を開き、現在の条件が正しいかを見ます
3. 閲覧の範囲を確かめる … 回答に、照会した人が見てよくない議案の内容が入っていないかを見ます
4. 付議基準と照らす … 取締役会規程の付議基準を開き、見立てを足します
5. 台帳の欠けを直す … chain_complete: false のものは、議事録を読んで台帳に変更のつながりを入れます

部門へ返す文面には、決議の文と条件を議事録の言葉のまま載せ、出典の会議体・日付・議案番号を必ず添えます。 部門の担当者が稟議書に根拠として書き写せるようにするためです。

5番目が、この構成を育てます。 照会のたびに台帳の欠けが埋まり、次に同じ枠を聞かれたときには、たどりが最後まで届きます。

例外に対処する

3行目は、閲覧制御が正しく働いている結果です。 照会した人には見えないので、事務局が見て、回答に書いてよい範囲を判断します。

記録を残す

• 照会の全文と日時、照会した人
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• 台帳でたどった議案の番号の並び
• check grounding API の結果
• 事務局が部門へ返した回答と、足した見立て
• そのときの決議台帳の変更のつながりの内容

最後の行を残すのは、台帳が後から埋まるためです。 回答した時点で台帳に入っていなかった変更が後で見つかったとき、どの回答をやり直すべきかが分かります。