社内で決まったこと・起きたことの報告から、適時開示が要るかの一次判定と根拠の基準を示し、開示の担当が確かめる論点をまとめる

処理の起点を決める

報告の申請が開示グループに届いたことを起点にします。 申請の仕組みから通知を受けるか、Python のスクリプトを5分おきに動かして新しい申請を拾います。1日1回のまとめての処理にはしません。 発生事実は、その発生を認識した時点での開示が必要とされているからです。

夜間や休日に届いた報告も、届いた時点で処理します。 確認票ができたら、開示グループの当番に通知します。ガイドブックは、立会時間中であるか否かを問わず直ちに開示を行うよう求めています。

報告者が申請を差し替えたときは、最初から処理し直します。 金額の見込みが後から書き足されることが多く、差し替え前の確認票を見て判断すると、古い数値で決めることになります。

入力データを集める

質を決めるのは、2つ目の開示項目の一覧です。 ガイドブックの全文をAIに渡すと長く、どの項目に当てたかの番号もぶれます。項目ごとに、ガイドブックの説明と軽微基準を短く切り出した一覧を作ります。

4つ目の取引先の区分は、取引先との取引停止の判定に使います。 ガイドブックは、主要取引先を直前事業年度の売上高又は仕入高が売上高総額又は仕入高総額の10％以上である取引先としています。報告に相手先の名前があっても、主要取引先かどうかは一覧を引かないと分かりません。

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

財務の数値の一覧は、決算が確定したら必ず更新します。 「直前連結会計年度」が切り替わったのに古い数値で計算すると、基準の金額がずれます。一覧には、どの年度の数値かと更新日を必ず持たせ、確認票に印字します。

AIへ渡す前に整形する

1. 報告の正規化 … 申請の各欄をテキストにし、金額の欄の単位（千円・百万円・億円）をそろえます
2. 添付資料のテキスト化 … PDFはテキストにします。取締役会の資料は、決議事項の部分だけを取り出します
3. 子会社の判定 … 報告者の所属から、上場会社の件か子会社等の件かを決めます。項目の候補が変わるからです
4. 相手先の照合 … 相手先の名前を取引先の区分の一覧と照らし、主要取引先かを付けます
5. 候補の絞り込み … 決定事実か発生事実か、上場会社か子会社等かで、AIに渡す項目の一覧を絞ります
6. 年度の割り付け … 「3年以内に開始する各連結会計年度のいずれか」で見る項目のために、決定や発生の日がどの連結会計年度に属するかを、自社の決算期から計算して付けます

1番目の単位をそろえる処理を軽く見ないでください。 報告者は「300」とだけ書くことがあります。百万円の300と千円の300では、軽微基準の判定が正反対になります。 単位が書かれていない金額は、取り出しはしても計算には使わず、質問に回します。

AIに処理させる

させることは2つです。1つ目は当てはめと事実の取り出し、2つ目は足りない情報と論点の書き出しです。

1つ目は、報告を読み、開示項目の候補を番号で選ばせ、計算に要る事実を取り出させます。

金額の「意味」を取り出させるのが要です。 報告の「年5億円の取引」は、売上高の増加見込額なのか、契約の総額なのか、相手先から受け取る対価なのか。軽微基準は項目ごとに比べる数値が違うので、金額の意味を取り違えると、正しい計算でも結論が誤ります。

2つ目は、1つ目の結果と計算の結果を受けて、開示の担当が確かめる論点と、報告者への質問の下書きを書かせます。

3行目と4行目が、いちばん起きやすい失敗です。 金額の見込みが空の報告を渡すと、AIは文脈から「数千万円程度と思われる」と書き、それをもとに「軽微基準未満」と結論しがちです。 金額は作らせず、空なら空として計算から外し、区分を「情報が足りない」にします。

指示内容を固定する

1つ目（当てはめと事実の取り出し）の指示です。

あなたは上場会社の開示グループで、社内の報告を受けて
適時開示の要否の検討の準備をする担当です。

【すること】
1. 報告の内容が当たりうる開示項目を、項目の一覧から番号で選んでください。
   当たりうるものはすべて挙げてください。迷ったものも挙げてください。
   一覧にない番号は書かないでください。
2. 選んだ項目ごとに、軽微基準の計算に要る事実を報告から取り出してください。

【取り出す事実】
- amount: 報告に書かれた金額。数字と単位をそのまま写してください。
- amount_meaning: その金額が何の金額か。
  sales_increase / sales_decrease / loss / claim_value /
  acquisition_price / contract_total / unknown から選んでください。
- period: 金額がどの期間の見込みか。書かれていなければ空にしてください。
- counterparty: 相手先。
- decision_body: 決定した機関。「方向を確認」「検討を開始」は unclear にしてください。
- decided_or_recognized_on: 決定した日、または発生を認識した日。

【厳守事項】
- 報告に書かれていない金額を推定しないでください。空のままにしてください。
- 単位が書かれていない金額は、amount に数字だけを写し、
  missing_info に「単位」と書いてください。
- 開示が要るかどうかの結論は書かないでください。
- evidence には、根拠にした報告の文をそのまま写してください。

【報告】{report}
【開示項目の一覧（候補を絞ったもの）】{items}

2つ目（論点と質問）の指示です。

次の報告について、当てはめの結果と軽微基準の計算の結果を読み、
開示の担当が確かめるべき論点と、報告者への質問を書いてください。

【論点の書き方】
- 論点は1つずつ、「何を確かめるか」と「なぜ確かめるか」を書いてください。
- 軽微基準の範囲に収まっている項目についても、
  バスケット条項の検討が要るかを論点に入れてください。
- 決定の機関が unclear のときは、業務執行を実質的に決定する機関の
  決定に当たるかを論点に入れてください。

【質問の書き方】
- 報告者が答えられる具体的な質問にしてください。
  例：「売上高の増加見込額を、今期・来期・再来期の年度ごとに教えてください」
- 1つの質問で1つのことを聞いてください。

【してはいけないこと】
- 「開示は不要です」「開示が必要です」と書かないでください。
- 計算の結果を書き換えないでください。

【報告】{report}
【当てはめの結果】{mapping}
【軽微基準の計算の結果】{threshold_results}

1つ目の指示で amount_meaning を選択肢にしているのは、計算のプログラムが、金額の意味ごとに比べる基準を選ぶからです。 contract_total（契約の総額）は、売上高の増加見込額とは限りません。意味が contract_total や unknown なら、計算には使わず質問に回します。

2つ目の指示で、軽微基準の範囲の項目にもバスケット条項の論点を書かせているのは、ガイドブックがその検討を常に求めているからです。

出力形式を固定する

2つの呼び出しとプログラムの結果を、次の形のJSONにまとめて確認票にします。

{
  "report_id": "",
  "entity": "parent | subsidiary",
  "fact_type": "decision | occurrence",
  "candidates": [
    { "item_id": "", "amount": "", "unit": "", "amount_meaning": "sales_increase",
      "period": "", "counterparty": "", "evidence": "",
      "threshold": { "base": "consolidated_sales", "base_value": 0,
                     "rate": 0.1, "threshold_value": 0, "fiscal_year": "" },
      "comparison": "above | below | not_computable" }
  ],
  "decision_body": "", "decision_body_status": "clear | unclear",
  "missing_info": [],
  "issues": [ { "point": "", "why": "" } ],
  "questions_to_reporter": [],
  "screening": "likely_required | basket_review | insufficient_info | no_item_matched"
}

1つ目の理由は、計算の根拠が欄で残ることです。 threshold に、どの数値（base）の何％（rate）で、どの年度（fiscal_year）の数値を使ったかを残します。後から「なぜ開示しなかったか」を問われたとき、計算をそのまま示せます。

2つ目は、screening を規則で決められることです。

not_computable を below と同じに扱わないのが、この表の要です。 ガイドブックは、軽微基準に該当するかどうか明らかでない場合にも開示が義務付けられるとしています。計算できないものは、開示が要る側に寄せて人に回します。

構造化出力は、enum の値の大文字・小文字が保証されないとされているので、大文字・小文字を区別せずに比べます。拒否や max_tokens での打ち切りではスキーマに合わない出力になりうるので、stop_reason を見て、打ち切りなら呼び直し、それでも失敗なら確認票に「自動の判定なし」と出して人に回します。

システムへ連携する

通知に報告の中身を書かないのは、未公表の重要な情報だからです。 通知は件名と区分だけにし、中身は確認票を開いて読みます。

人が確認する

開示の担当が全件を確かめます。 見る順番を決めておきます。

1. likely_required を最初に見る … 計算の根拠（base、rate、fiscal_year）と金額の意味を確かめ、責任者に上げます
2. insufficient_info を次に見る … 質問の下書きを直して報告者に送ります。答えを待つ間も、責任者には件名を知らせておきます
3. basket_review と no_item_matched を見る … 当てはめの漏れがないかと、バスケット条項の論点を読みます
4. 判断を記録する … 責任者の判断と理由、東京証券取引所に相談したかを残します

1番目と2番目は、届いた日のうちに見ます。 「直ちに」の要請に対して、この構成が縮めるのは準備の時間です。準備ができても人が開かなければ、時間は縮みません。 当番を決め、通知を受けたら確認票を開く運用にします。

例外に対処する

最後の行は、計算の式だけでは足りない場合です。 ガイドブックは、直前連結会計年度の連結経常利益が連結売上高の2％に満たない場合などに、利益が少額の場合の開示基準の特例があるとしています。特例に当たるかをプログラムで判定し、当たるなら式を切り替えるか、人に回します。

記録を残す

• 報告の版と、届いた日時
• 使った開示項目の一覧の版と、財務の数値の年度・更新日
• 2回の呼び出しの指示と応答の全文、使ったモデル
• 軽微基準の計算の式と結果
• 責任者の判断と理由、東京証券取引所への相談の有無と日時
• 開示した場合は開示の日時、しなかった場合はその理由

5つ目と6つ目は、開示しなかった判断の記録として最も大事です。 後から開示の遅れを問われたときに、いつ報告が届き、いつ何を見て、なぜそう判断したかを示します。記録は開示グループだけが見られる場所に置き、閲覧の記録も残します。