株主から届く配当・株主優待・住所変更・株式の手続きの問い合わせに、株式取扱規程と株主名簿管理人の案内を根拠に回答案を作る

処理の起点を決める

時間主導型のトリガーで、10分ごとに動かします。 Apps Script の時間主導型のトリガーは、1分ごとから月1回まで設定でき、実行の時刻には少しばらつきがあるとされています。株主への返信は数分を争うものではないので、10分ごとで足ります。

対象は、共有アカウントの受信箱で「株主問い合わせ／未処理」のラベルが付いたスレッドです。フォームの送信と株主からのメールに、Gmail のフィルタでこのラベルを付けます。処理が終わったスレッドは「下書き済み」のラベルに付け替えます。 付け替えるのは下書きと記録が両方できたときだけで、未処理のラベルが残っている数が、そのまま処理されていない数になります。

トリガーは株式担当の共有アカウントで作ります。 インストール型のトリガーは作った人のアカウントで動くため、個人のアカウントで作ると、その人の受信箱を見ることになり、異動で止まります。

入力データを集める

質を決めるのは、2行目から4行目の文書が最新かどうかです。 優待の内容や株主名簿管理人の連絡先が変わったのに一覧が古いままだと、引用付きで古い案内を返します。 引用があることは、内容が正しいことを意味しません。文書ごとに版と最終更新日を持たせ、一覧の先頭に置きます。

株主名簿管理人の案内は、自社の手続きの言葉で書き直さずに持ちます。 たとえば三菱UFJ信託銀行の手続き用紙の案内には、「当社で開設されている『特別口座』で株式をお持ちの株主さまのみ、当社でお手続き可能です。証券会社で株式をお持ちの株主さまは、お取引の証券会社にお申出ください」とあります。この一文が、第3章の（a）を防ぐ根拠です。

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

GmailThread.createDraftReply は、スレッドの最後のメッセージの送信者に返信する下書きを作るメソッドです。HTML の本文も指定できます。下書きは同じスレッドに残るので、担当者は受信箱からそのまま開いて直せます。 Gmail のメソッドはすべて https://mail.google.com/ の権限を求めるため、スクリプトを承認するのは共有アカウントだけにします。

根拠の節は、種類ごとに対応表で選びます。 すべての文書を毎回渡すと、住所変更の問い合わせに優待の節が引用されるような、関係の薄い引用が混ざります。

AIへ渡す前に整形する

1. 署名と引用の除去 … 本文の末尾の署名と、> で始まる過去のメールの引用を除きます
2. 連絡先を伏せる … 本文に書かれた電話番号・住所・口座番号を [電話] [住所] [口座] に置き換えます。住所変更の問い合わせで新しい住所が書かれていても、回答案には要りません
3. 株主番号の扱い … 株主番号らしい数字の並びは [株主番号] に置き換えます。照会は人が株主名簿管理人に行います
4. 同じ株主の重複の確認 … 同じ送信者から直近の未処理があれば、まとめて1件として扱います
5. 件数の上限 … 1回の実行で20件までにし、残りは次の実行に回します。1回の実行は6分までです

2番目と3番目を、AIに渡す前にプログラムで行うのが要点です。 回答案を作るのに、株主の住所も株主番号も要りません。要らない情報は、外に出る経路そのものを作らないようにします。伏せた値は記録の表にも残さず、元のメールにだけ残ります。

AIに処理させる

1回目の呼び出しでは、問い合わせを振り分け、人に回す事情を拾います。

2回目の呼び出しでは、選んだ節だけを根拠に回答案を作ります。 質問の一覧の1つずつに答え、どの文にも引用を付けます。

2行目と3行目を、1回目の呼び出しで拾うのが要点です。 2回目の呼び出しに入ってから断らせると、断りの文と案内の文が混ざった回答案になります。拾ったものは、回答案を作らずに定型の文例で人に回します。

指示内容を固定する

1回目（振り分け）の指示は次のとおりです。

あなたは上場会社の総務部の株式担当として、株主からの問い合わせを
振り分ける立場です。回答は書かないでください。

【厳守事項】
- account_hint は、本文に「証券会社で持っている」「特別口座」などの
  記載があるときだけ securities_account か special_account にしてください。
  記載が無ければ unknown にしてください。推測しないでください。
- 次のどれかに当たれば、escalation に理由を入れてください。
  ・優待の今後の内容や継続、配当の今後の見通し、業績に触れる質問
  ・持株数、配当の支払状況、優待の発送の状況など、株主ごとの照会が要る質問
  ・相続、名義の変更など、個別の書類の判断が要る手続き
  ・苦情、または強い不満が書かれている
- questions には、本文の中の質問を1つずつ、株主の言葉に近い形で書いてください。
- 本文に書かれていない質問を足さないでください。

【問い合わせ】{inquiry}

2回目（回答案）の指示は次のとおりです。根拠の節は、引用を有効にした文書として別に渡します。

あなたは上場会社の総務部の株式担当として、株主への回答の下書きを書く立場です。
渡された文書（株式取扱規程、株主優待の案内、株主名簿管理人の案内）だけを
根拠に、質問の一覧の1つずつに答えてください。

【厳守事項】
- すべての文を、渡された文書の記載に基づいて書いてください。
  文書に無いことは書かず、「文書に記載がありません」と書いてください。
- 期限、金額、株数、電話番号、受付時間は、文書の記載をそのまま写してください。
- 手続きの申出先は、口座の区分の手がかり（{account_hint}）に従ってください。
  unknown のときは、証券会社の口座の場合と特別口座の場合の両方を、
  区別して書いてください。どちらかに決めつけないでください。
- 持株数、配当の支払状況、優待の発送の状況について書かないでください。
- 優待の今後の内容、配当の見通しについて書かないでください。
- 敬語は丁寧語を基本とし、1つの質問への答えを3文以内にしてください。
- あいさつと結びの文は書かないでください（定型の文例を後で付けます）。

【質問の一覧】{questions}

「unknown のときは両方を区別して書く」を明記しないと、多い方に寄せます。 個人株主の多くは証券会社の口座で株式を持っているので、何も言わなければ証券会社の案内だけを書きます。特別口座の株主にとっては、それが誤った案内になります。

「文書に記載がありません」と書かせるのは、空白を埋めさせないためです。 書けない質問を飛ばすと、担当者がその質問の存在に気づきません。

出力形式を固定する

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

{
  "category": "address_change | dividend | odd_lot | benefit | inheritance | share_transfer | other",
  "account_hint": "securities_account | special_account | unknown",
  "escalation": [
    { "reason": "undisclosed | holder_lookup | individual_procedure | complaint", "quote": "" }
  ],
  "questions": [ "" ]
}

escalation が空でなければ、2回目を呼びません。 定型の文例（「確認のうえ、改めてご連絡いたします」）で下書きを作り、記録の表に理由を書いて担当者に知らせます。quote には、その判断の根拠にした本文の一節を写させます。

2回目は、引用付きのテキストで受け取ります。 返ってくる内容は、文の塊ごとに引用の一覧が付いた形です。スクリプトはこれを次の表に組み直し、記録の表に書きます。

引用の無い文には、下書きの中で【要確認】の印を付けます。 あいさつと結びは定型の文例から付けるので、2回目の出力には含まれません。つまり、2回目の出力で引用の無い文は、すべて根拠の無い文です。

システムへ連携する

2回目の呼び出しで渡す内容は、次のような形になります（抜粋）。規程の条や案内の節を1つずつのブロックにし、文書の名前に版を入れます。

{
  "role": "user",
  "content": [
    {
      "type": "document",
      "title": "株主名簿管理人の案内（2026年10月版）",
      "source": {
        "type": "content",
        "content": [
          { "type": "text", "text": "諸届：住所変更、改姓・改名 …" },
          { "type": "text", "text": "特別口座：特別口座で株式をお持ちの株主さまのみ …" }
        ]
      },
      "citations": { "enabled": true }
    },
    { "type": "text", "text": "（2回目の指示と質問の一覧）" }
  ]
}

返ってくる引用の content_block_location のブロックの番号を、節の一覧の行に引き直せば、「どの文書の、どの節か」を担当者に見せられます。 2回目の呼び出しには output_config を付けません。文書の context には、引用の対象にしない補足（最終更新日、担当部署）を入れられます。

月180件で1件あたり2回の呼び出しなら、UrlFetchApp の1日の上限（Workspace のアカウントで10万回）には届きません。

人が確認する

1. 人に回す印のあるものを先に見る … 株主名簿管理人への照会、IRの担当への相談、相続の案内を行います
2. 【要確認】の文を読む … 根拠の無い文は消すか、文書を確かめて書き直します
3. 引用元の版を見る … 引用した文書の版が最新かを確かめます。優待の内容が変わった直後は特に
4. 口座の区分の書き分けを見る … unknown のときに両方の案内が書かれているかを確かめます
5. 直して送る … 送信は担当者が行います。直した箇所は記録の表に残します

3番目を省かないでください。 引用があると、正しい回答に見えます。古い版の文書から引用していれば、引用付きの誤った案内になります。

目標は、180件をならして1件5分です。 優待の基準日や手続き先のように文書どおりの回答で済むものは、読んで送るだけで終わります。

例外に対処する

いちばん多いのは、添付ファイルのある問い合わせです。 届いた用紙の写真や、配当金の計算書の画像を付けてくる株主は少なくありません。画像には株主番号や住所がそのまま写っているので、AI に渡しません。 本文だけで回答案を作り、添付を見るのは担当者です。

記録を残す

• 問い合わせの受信日時、スレッドの識別子、種類、口座の区分の手がかり
• 人に回した理由と、その根拠にした本文の一節
• 回答案の文ごとの引用（文書の名前・条・節・版、cited_text）
• 【要確認】の印の付いた文と、担当者がどう直したか
• 送信した日時と、送信した担当者

伏せた連絡先と株主番号は、記録の表に残しません。 元の値は Gmail のメールにだけ残ります。

種類ごとの件数と【要確認】の数を、月に1回数えます。 同じ質問で毎回【要確認】が出るなら、文書にその答えが無いということです。 IRサイトの案内に足すと、問い合わせそのものが減ります。