技術と信頼性

データの流れ

取り込む

OAuth 2.0の読み取り専用スコープ（drive.readonly / gmail.readonly / calendar.readonly）で接続します。対象はお客さまが指定したフォルダ・許可した取引先ドメイン・カレンダーに限定され、書き込み権限は要求しません。

ためる

抽出された1件ごとに、出典（元文書と該当箇所）への参照を必須で保持します。出典のない情報は作りません。保存はPostgreSQL上でテナントごとに行レベルで分離し、検索には埋め込みベクトル（pgvector）を使います。

渡す

業務単位でコンテキストパックに編成し、チームが使うAIの前段に差し込みます。全文を照会対象にする検索型と違い、AIに渡るのは編成された1枚だけです。

記録する

どのカードがどのパックに編成され、どの出力に使われたかを、出力先つきの参照ログとして記録します。インシデント時・監査時に、情報の経路を後から追跡できます。

データモデルの設計

“今の正解”を保つという目的は、データモデルの設計に直接現れています。

系譜（supersession）

情報の更新は上書きではなく系譜として残します。各カードは有効期間（valid_from / valid_until）と後継カードへの参照（superseded_by）を持ち、「いつ、何が正解だったか」を遡れます。同じ判断の古い版と新しい版が混在するときは、上書きを検出して新しい版だけをパック編成の対象にします。古いドラフトが“今の正解”として拾われることを、構造で防ぎます。

鮮度スコア

型別の半減期で減衰するスコアを持ち、参照・矛盾の検出・担当者の退職などで増減します。古くなった情報は、自動でパック編成の対象から退きます。

効力発生日と可視化日の分離

発令前の人事情報などは、効力発生日と「見えてよい日」を別の属性として持ちます（embargo）。効力発生前の情報がパックに編成されることは、データモデルの層で禁止されています。

知識の型

取り込んだ情報は、全文のまま溜めるのではなく、型を持ったカードとして構造化されます。

ルール（適用）

「値引きは原則15%まで」のように、従うべきもの。パックでは適用対象として、その業務の文脈つきで渡されます。

判断（参照）

過去の賭けと、その結果。一般化せず、案件に固定したまま参照材料として渡します。ルールは適用・判断は参照、という区別を型のレベルで強制するのが、この型システムの中心原則です。

事実

人・案件・体制など。人事台帳系のデータは参照のみで、複製を持ちません。情報の出所となった人の在籍状況も一級の属性として持ち、退職時には関連カードの鮮度に反映されます。

裁定

正解が2つある状態そのもの。人が決着をつけるまで「未確定」の型として明示的に扱い、確定情報と混ざりません。

導入にあたって、重いオントロジーを先に構築していただく必要はありません。オントロジー先行の導入は、運用が週30分に収まらなくなるためです。TobariAIは軽量な型システムから始め、正しさは出典と系譜（supersession）で保ちます。

AIモデルとデータの扱い

• 学習非利用
  取り込んだ情報が、AIモデルの学習に使われることはありません。API経由・学習非利用の契約条件を満たすモデルだけを使用します。
• ゼロデータ保持（ZDR）
  お客さまのデータを扱う段階では、ZDR（Zero Data Retention）契約を締結したモデルに限定します。利用可能なモデルはホワイトリストで管理し、条件を満たさないモデルはシステム側で選択できない仕組みにします。「学習非利用」と「ゼロ保持」は別の契約項目として、それぞれ分けて説明します。
• DPA（データ処理契約）
  「一切どこにも残らない」という言い方はしません。プロバイダ側の不正利用監視など、契約上の例外保持は存在します。約束できる範囲をDPAで明確にし、その範囲を守ります。確認したい項目があれば、契約前にそのままお尋ねください。
• 観測ログの扱い
  プロンプト・出力の運用監視ログも「データが残る場所」として扱います。顧客データ期は、観測基盤を自社管理（セルフホスト）またはマスキング前提で構成する設計です。
• 第三者審査
  Gmail連携の提供に必要な第三者セキュリティ審査（CASA）への準備を進めています。

保管と分離

• お客さまごとにデータを論理分離し、データベースの行レベルセキュリティ（RLS）で強制します。他社のデータと混ざることはありません。
• 転送時はTLSで暗号化し、保存時は暗号化されたストレージに置きます。OAuthトークンなどの認証情報は暗号化して保管します。
• 契約終了時・削除のお求めに応じて、取り込んだデータ・抽出されたカード・埋め込みベクトルまで、派生情報を連鎖して削除します。

人の関与

裁定は人

正解が2つに割れたとき、どちらを正とするかを決めるのは人です。AIは矛盾ペアの検出と提示までを担い、決着を自動で確定することはありません。

前提の見直しも人

大きな判断の前提が変わったときの確認は、人に届きます。日々の取り込みと更新はAIが担い、人の関わりは週30分以内に収まる設計です。

社内チャット（Slackなど）への対応は順次提供の予定です。対象はopt-inされた業務チャンネルの決定事項に限り、DM・雑談チャンネルは読みません。誰が誰と、どのくらいやり取りしたかという関係性のデータは、抽出も分析もしません。

自動更新の検証

「今も正しいか」の判定を機械に任せる以上、その判定がどう検証されているかまでが信頼の対象だと考えています。

危険な方向の誤りをゼロに

判定の誤りには2つの方向があります。安全な方向（確認が一度多く人に届く）と、危険な方向（決まっていないこと・撤回されたことを“今の正解”として扱う）。検証では、危険な方向の誤りがゼロであることを合格条件にしています。

ネガティブコントロール

判定のテストには、決して“確定”と答えてはいけない引っかけ（無関係な議題・否決された案・方針と正反対の内容）を意図的に混ぜます。健康な検体を混ぜて検査キットの信頼性を確かめる、医学の検証と同じ方法です。機械が中身を見ずに何でも肯定していないかを、ここで確かめます。

「まだ決まっていない」を第3の状態に

実行された・撤回された、に加えて「まだ決定に至っていない」を独立の状態として扱います。最新の候補が出ているだけの案件を“決まった”と早合点しないことを、検証の項目に含めています。