ESG を 財務に 入れ込むメイ

情シス向け 実装ノート

このファイルは単体で動くプロトタイプです。ブラウザで開けばそのまま使えます。対話相手はサステナ担当者（取引先や銀行からESGを問われ、社内では経営が動かない板挟みの人）で、翻訳カードと「役員会に出す1枚」は担当者が経営を動かすための道具です。本番実装の出発点として、以下を確認してください。

1. 構成 — プロトタイプと本番の違い

2. Claude API に何を渡すか

1リクエストで送るのは以下だけです。従業員個人のデータは一切送りません。

• システムプロンプト（メイの役割＝サステナ担当者の壁打ち相手・会話の型・禁止事項・出力形式）
• 制度データ（法令・府令・官公庁統計。公開情報のみ）
• 企業プロフィール（業種・従業員数・上場区分・決算月）
• 会話履歴（担当者の発言とメイの応答）

3. ガードレールがどこで効いているか

誤答を防ぐ仕掛けは3層です。実装時にどれも省かないでください。

1. 入力の制限 — 参照させる制度データを REGULATIONS に限定し、「ここにない制度・数値は語らない」とシステムプロンプトで指示
2. 出力の構造 — 事実（seen）と解釈（meaning）を別の欄に分離。混ざらないこと自体がガードレール
3. 出典の強制 — 制度に触れた応答は cites を必須にする。空なら差し戻す

画面右上の「確度」「出典」の計器は、この3層目を可視化したものです。confidence が unknown のときに断言させないことが、信頼性設計の中心にあります。

3b. 何をコードでやり、何をLLMにやらせるか

本プロトタイプは、APIキーなしでも動く必要があるため、TOPICS という固定応答の層を持っています。これはデモ系統のための実装であり、本番の推奨構成ではありません。語句一致で振り分ける層をLLMの手前に置くと、系全体の精度がその振り分けの精度で頭打ちになります（実際、開発中に3件の誤振り分けが出ました）。また、固定応答を書き足していくことは「基準の解釈を自前で作り込まない」という本プロダクトの方針にも反します。

本番で切り分けるべき境界は「LLMの手前か後か」ではなく、計算か、言語かです。

閾値の比較と日付の計算をLLMにやらせないこと。ここは静かに誤り、しかも誤りがもっともらしく見える箇所です。コードで計算し、その結果を事実としてLLMに渡してください。ガードレールは「LLMを迂回すること」ではなく、材料を制限し、出典を強制し、出力を検査することです。迂回は制限の代用になりません。

4. 制度データの更新運用 — 検知は自動、承認は人

参照する情報は要件定義で確定しています。監視対象は次の6本のみで、これ以外は見ません。「何を、どの形で見るか」が決まっているため、監視は小さく閉じた仕事になります。

工程は3つに分け、最後だけ人が持ちます。

1. 検知（自動） — 上記6本の変更を定期的に確認する。「見に行くのを忘れる」が最大のリスクであり、自動化して最も得をするのはここ
2. 起草（自動） — 何がどう変わったか、原文の引用つきで変更案を作る
3. 承認（人） — 原文に当たって確認し、データを書き換える。ここは省かない

書き換えを自動化しない理由は、この制度データが全回答の土台だからです。ここが壊れると、すべての回答が出典つきで、自信をもって誤ります。出典があるぶん疑われにくく、発覚も遅れます。一方で項目は定義済みなので、承認作業は「3つのフィールドが合っているか」の確認で済みます。承認が不要になるのではなく、承認が安くなるという関係です。

各エントリの asOf（最終確認日）は画面右上の鮮度計に出しています。6か月で琥珀、12か月で警告に変わります。古いデータが静かに正しい顔をしている状態を作らないための表示です。

5. システムプロンプト

サーバ側 functions/lib/knowledge.ts にあります。制度データと一緒にサーバで組み立て、クライアントには出しません。閾値判定と期限計算は functions/lib/facts.ts がコードで行い、結果を事実として渡します。

6. 出力スキーマ

{
  "say":   "担当者への発話。3文以内。",
  "cites": [{ "label": "制度名・調査名", "detail": "施行日・数値・時点" }],
  "card": {
    "seen":     "いま外からどう見えているか（事実のみ）",
    "gap":      "何が抜けているか",
    "meaning":  "経営から見た意味。担当者が役員会でそのまま言える一文",
    "deadline": "いつまでに",
    "money":    "いくらの話か（仮置きなら明記）",
    "kpi":      "見るべきKPI（3つまで）",
    "action":   "次の一手（90日）。担当者が経営に決めてほしいことの形"
  },
  "ask":        ["担当者が次に言いそうな返答の候補", "もう一つ"],
  "confidence": "high | need_client_data | unknown"
}

card の各欄は、埋められないとき空文字にします。推測で埋めさせないこと。空欄のまま出すほうが、もっともらしい嘘より安全です。

7. 画面の意匠について

暗い管制画面の様式を採っていますが、装飾のためではありません。確度と出典の状態を計器として常時表示するためです。生成AIを業務に使うとき、利用者が最初に知りたいのは「この回答はどのくらい確かか」であり、それを本文に埋め込むと読み飛ばされます。独立した計器に出すことで、読まずに分かる状態を作っています。

なお本画面は単一の配色で確定しており、閲覧環境の明暗設定に影響されません。商談での見え方を一定に保つためです。