海外投資家から届く英文の問い合わせに、開示済みの資料だけを根拠に回答案を作る

処理の起点を決める

IR窓口のメールボックスに新しいメールが届いたことを起点にします。 Office 365 Outlook コネクタの新着メールのトリガー（When a new email arrives (V3)）を使い、監視するフォルダーを、IR窓口あての英文メールを振り分けたフォルダーに絞ります。受信トレイ全体を見張ると、社内の連絡や営業メールまで回答案の対象に入ります。

1日1回の定時実行にはしません。 1通ずつ動かせば、担当者が確認リストを開いた時点で訳と要点と回答案がそろっています。

トリガーには、まれに最大1時間ほどの遅れが出ることがあるとされています。IRの回答は分単位を争うものではないので、設計上の問題にはしません。 回答までの日数は受信日時から数えます。

入力データを集める

質を決めるのは、資料の目録です。 「公表状態」が published で公表日が今日以前の資料だけを入力に使います。この列が、AIに渡してよい資料を分ける唯一の門です。

公表済み資料のテキストは、公表したときに1回だけ書き出します。 PDFからテキストを取り出す方法は利用環境に応じた個別実装になりますが、どの方法でも1ページごとに [doc=FY2026Q1_presentation_en p=12] のような印を付けて保存します。 この印が、回答案に添える根拠のページになります。

英語版がある資料は英語版を渡します。 日本語版から訳した文より、自社が英語で公表した文のほうが、投資家が自分で確かめられる根拠になるからです。

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

メールの本文と送り主は、トリガーの出力からそのまま取れます。添付ファイルはトリガーでは取り込まず、必要なときだけ添付ファイルの取得のアクションで取り出します。 添付は回答案の根拠にはしません。

どの資料を渡すかは、決算期と話題で決めます。 既定では、最新の決算期の決算短信と決算説明資料、直近の統合報告書、英文IRサイトの配当方針と中期経営計画のページを渡します。前の期との比較を聞かれたときだけ、前の期の同じ資料を足します。 何でも渡すと、古い期の数字を最新の数字として引く失敗が増えます。投資家の一覧は照合に使うだけで、AIには渡しません。

AIへ渡す前に整形する

1. 本文の整理 … 署名、免責文、過去のやり取りの引用部分を取り除きます。引用部分の過去の回答を根拠のように扱うのを防ぐためです
2. 沈黙期間の確認 … 受信日が決算発表前の沈黙期間に入っていれば、すべての質問を escalate 扱いにする印を付けます
3. 資料の選定 … 目録から、公表状態が published で公表日が今日以前のものだけを選びます
4. ページ印の確認 … 渡すテキストの全ページに印があるかを確かめます。印の無いページからは根拠のページが書けません
5. 分量の確認 … 渡す資料の合計が大きすぎる場合は、統合報告書を話題に関係する章だけに絞ります
6. 重複の確認 … 同じ送り主から直近に同じ件名のメールがあれば、前の問い合わせにひもづけます

2番目を軽く見ないでください。 沈黙期間中は、公表資料で答えられる内容でも、答えるかどうか自体をIR責任者が決めます。 自社のディスクロージャーポリシーにある沈黙期間の日付を、そのまま一覧に入れます。

AIに処理させる

させるのは、訳すこと、質問に分けること、区分を付けること、answerable の質問にだけ根拠付きの回答案を書くことの4つです。

区分の付け方は、次の基準で決めます。

迷ったときに answerable を選ばせないのが、この表の要点です。 escalate が増えても人の確認が1件増えるだけですが、answerable の増えすぎは未公表の情報の入口になります。

2行目がいちばん起きやすい失敗です。 資料に売上高が2期分あれば、AIは伸び率を計算して書き添えます。資料に無い伸び率なら、公表していない数字を1人の投資家に渡したことになります。

指示内容を固定する

あなたは上場企業のIR担当者で、海外投資家から届いた英文の問い合わせに
回答案を用意する立場です。渡された公表資料だけを根拠にしてください。

【してほしいこと】
1. 問い合わせ全体を日本語に訳し、3行程度の要点にまとめる
2. 質問を1つずつに分け、話題を付ける
   （results / mid_term_plan / dividend / esg / other）
3. 質問ごとに区分を付け、理由を日本語で書く
   - answerable ... 答えが【公表資料】の文にそのまま書いてある
   - escalate ..... 【公表資料】に答えが無い、業績予想より先の見通し、
                    期中の足もとの状況、進行中の案件・取引先に触れる
   - not_ir ....... 面談の申し込み、採用・営業などIRの回答ではないもの
   迷ったときは escalate を選んでください。answerable を選ばないでください。
4. answerable の質問にだけ、英文の回答案を書く

【厳守事項】
- 回答案の各文は、【公表資料】のどこかの文に基づいていなければなりません。
  各文に、根拠にした資料の印（doc と p）と、根拠の文をそのまま写した引用を付けてください。
  引用できない文は回答案に入れないでください。
- 数字は【公表資料】に書かれているとおりに写してください。
  前年比、伸び率、差額、通貨の換算など、書かれていない数字を計算して出さないでください。
- 「順調」「計画どおり」「強い」など、【公表資料】に無い評価を足さないでください。
- 【公表資料】に書かれていないことを、一般的な知識や推測で補わないでください。
  資料に答えが無い質問は、回答案を書かずに escalate にしてください。
- escalate と not_ir の質問には、英文の回答案を一切書かないでください。
  draft_en は null にしてください。
- 【回答しない話題】に当たる質問は、資料に記載があっても escalate にしてください。
- 【沈黙期間】が true のときは、すべての質問を escalate にしてください。
- 過去のやり取りの引用部分に書かれた内容を、根拠にしないでください。
- 宛名と結びの文は書かないでください。フローの側で付けます。

【問い合わせ】{mail_body}
【受信日】{received_date}
【沈黙期間】{quiet_period}
【回答しない話題】{no_answer_topics}
【公表資料】{published_texts}

「迷ったら escalate」を明記しないと、AIは答えるほうを選びます。 何も言わなければ、資料の近い記述を寄せ集めて答えを作ります。禁じるのは、寄せ集めて答えにすることそのものです。

「計算して出さない」を独立させているのも同じ理由です。 「資料にあることだけ」では、資料の2つの数字から出した伸び率を「資料に基づく」と考えます。

宛名と結びを書かせないのは、回答案を質問ごとの部品として扱うためです。 1通の回答はフローの側で組み立て、escalate の質問には定型の一文（「追ってご連絡します」など）を入れます。1通まるごと書かせると、escalate の質問に触れた文が紛れ込みます。

出力形式を固定する

Azure OpenAI の構造化出力を使い、次の形のJSONで受け取ります。 Chat Completions API なら response_format、Responses API なら text.format にスキーマを定義し、strict: true を指定すると、渡したスキーマに沿った応答が返るとされています。

{
  "inquiry_id": "",
  "summary_ja": "",
  "translation_ja": "",
  "questions": [
    {
      "q_no": 1,
      "original_en": "",
      "topic": "results | mid_term_plan | dividend | esg | other",
      "route": "answerable | escalate | not_ir",
      "route_reason_ja": "",
      "draft_en": [
        { "sentence": "", "doc": "", "page": 0, "quote": "" }
      ]
    }
  ]
}

escalate と not_ir の質問では、draft_en は null になります。

1つ目の理由は、route を draft_en より前に置けることです。 構造化出力は、渡したスキーマと同じ順序でキーを出力するとされています。区分を先に決めさせてから回答案を書かせる順にしておけば、書き始めてから区分を後付けで合わせることが起きにくくなります。

2つ目は、根拠を文ごとに持てることです。 draft_en を文の配列にし、1文ごとに doc と page と quote を持たせます。フローの側で、quote の文字列が、その doc と page のテキストに実際にあるかを照合します。 無ければその文を赤で示し、担当者が確かめるまで送れない状態にします。

3つ目は、数字の照合ができることです。 sentence の数字が同じ文の quote に無ければ、AIが計算したか書き換えたかのどちらかです。

スキーマには制約があります。すべての項目を required に含め、省略してよい項目は null との共用体で表します。 draft_en の型を配列と null の共用体にするのはこのためです。各オブジェクトには additionalProperties: false を設定し、プロパティは合計100個まで、ネストは5階層までに収めます。配列の maxItems や文字列の maxLength は使えないので、件数や長さは受け取った後にフローで数えます。

システムへ連携する

送信のアクションは、このフローに入れません。 コネクタにはメールを送るアクションもありますが、使うのは下書きを作るアクションまでです。

資料の目録とテキストへは、読み取りしかしません。 公表状態を published に変えるのは公表した日の担当者の作業で、フローには書き換える権限を持たせません。 ここを自動にすると、公表前の資料が根拠に入る経路ができます。

人が確認する

人が見るのは全件です。ただし、見る場所を絞ります。 回答は1通ずつ外に出るので、低信頼のものだけを人に回す設計にはしません。

1. 区分を先に見る … escalate と not_ir が正しいかを確かめます。answerable になっている質問のなかに、未公表の話題に触れるものが無いかを最初に見ます
2. 照合で外れた文を見る … 赤で示された文を、根拠のページと並べて読みます。直せなければ、その文を消します
3. 英文を整える … 言い回しを自社の定型に合わせます。数字と根拠の引用には手を入れません
4. escalate をIR責任者が判断する … 答えるか、答えないか、どう答えるかを決めます
5. IR室長が確認して送る … 組み立てた回答を下書きに置き、担当者が送信します

1番目を省かないでください。 区分の誤りは、英文をいくら整えても直らず、送った後では取り返しがつきません。

IR責任者が答えると決めた escalate の質問は、その答えを回答の方針に書き戻します。 別の投資家にも同じ範囲で答えられるようにするためです。

例外に対処する

上から2行目は、思ったより多く出ます。 質問を表にしたファイルを添付し、本文は挨拶だけという運用会社があります。添付を読ませる処理を足す前に、そうした相手が何社あるかを数えてください。

記録を残す

• 受け取ったメールの本文、送り主、受信日時
• そのとき渡した資料の一覧 … 資料名、決算期、公表日、テキストのファイル
• 生成AIが返したJSONの全文（訳、要点、質問ごとの区分と理由、回答案と根拠）
• 照合の結果 … 引用が見つかったか、数字が一致したか
• 人が直した記録 … 区分を変えたか、どの文を消したか、どの文を足したか
• escalate の質問にIR責任者が下した判断と、その理由
• 送った回答の全文、送信日時、送信者

2つ目の「渡した資料の一覧」は、開示の公平さを説明するために残します。 問われたとき、その回答がその日に公表されていたどの資料のどのページに基づくかを示せるようにしておきます。