情シス向け 実装メモ

このページは、メイ（画面はこちら）の実装メモです。対話相手はサステナ担当者（取引先や銀行からESGを問われ、社内では経営が動かない板挟みの人）で、翻訳カードと「役員会に出す1枚」は担当者が経営を動かすための道具です。本番実装の出発点として、以下を確認してください。

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

このプロトタイプ本番で必要なこと
APIキーサーバ側の環境変数（ANTHROPIC_API_KEY）。ブラウザ → /api/mei → Claude API で中継。キーはクライアントに一切出さない同左。加えて認証とレート制限
制度データHTML内に定数として直書き（REGULATIONS）DBまたは設定ファイルに分離。更新履歴と有効期間を持たせる
会話履歴D1（mei-db）の consults に1往復1行で保存。合言葉の名前（会社）・業種・規模・発言・応答・同意した文面の版を持つ。保存には画面での同意が必須（x-mei-consent）保存期間は3年（1日1回、3年を過ぎた行を自動削除）。会社ごとの削除依頼にはリミーが個別に対応
認証なし必須。顧客企業単位のアクセス制御
ログなし入出力とモデルID・バージョンを保存。誤答時に追跡できるように
出力の検証サーバ側で JSON 正規化＋出典チェック。出典なしは1回再生成させ、それでも無ければ差し戻す加えて制度データにない数値の検出

2. Claude API に何を渡すか

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

確認が必要な項目

企業プロフィールと担当者の発言は、顧客企業の非公開情報にあたる場合があります。Claude API のデータ保存期間と学習利用の扱いを提供元の最新の契約条件で確認し、顧客への説明資料に反映してください。

また、担当者が会話の中で個人が特定できる話（「Aさんが辞めた」等）をする可能性があります。送信前にマスキングするか、システムプロンプトで個人名を扱わないことを明示するかを決めてください。本プロトタイプは未対応です。

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

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

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

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

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

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

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

層担当誰が作るか
制度データ構造化された事実（条文・施行日・適用範囲・統計値・出典・時点）人が更新。年3〜6回
計算閾値判定（101人以上か）・期限算出（決算月＋3か月）・規模帯の選択コード。LLMに渡さない
LLM経路の判断・言い回し・会話の運び上の2つだけを 材料に。出典必須
検証出典があるか／制度データにない数値を出していないかサーバ側。不備は差し戻す

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

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

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

監視対象発行元更新周期
改正女性活躍推進法厚生労働省随時
企業内容等の開示に関する内閣府令金融庁随時
SSBJ基準・適用範囲の政令／内閣府令金融庁随時（適用範囲がここで確定）
人的資本可視化指針内閣官房随時
雇用均等基本調査厚生労働省年次
賃金構造基本統計調査厚生労働省年次

工程は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 の各欄は、埋められないとき空文字にします。推測で埋めさせないこと。空欄のまま出すほうが、もっともらしい嘘より安全です。

6b. 相談の型（他社の相談をメイに活かす仕組み）

生の相談は他社に渡しません。2社以上の相談から、会社名・数字・固有の事情を外した「相談の型」を案として作り（patterns, status=draft）、リミーが承認したもの（approved）だけをシステムプロンプトに入れます。型は根拠ではなく、問い返しと言い回しの参考としてだけ使わせ、cites には入れさせません。承認を挟むのは、匿名化の漏れと、相談文に紛れた指示がそのまま他社の応答に効くことを防ぐためです。

7. 画面について

2026-10-02 に、担当者本人が初めてでも使えるよう、明るい配色の3ステップ構成（①会社のこと → ②相談 → ③まとめカード）に作り直しました。

「答えの確かさ」「根拠」「制度データの確認日」は、引き続きカードの上に常に出しています。生成AIの回答で利用者が最初に知りたいのは「どのくらい確かか」で、本文に埋め込むと読み飛ばされるためです。