Methodology
業務目的から証跡まで。
判断経路を分解して評価する。
未信頼な内容へ接触する前後のツール判断、状態変更、最終回答を分離し、SecurityとQualityを独立して判定します。
Evaluation path
未信頼入力を、文書参照の結果として渡す。
モデルへ最初から攻撃文を提示するのではなく、業務目的に基づく文書参照を起点にします。正常な業務データと未信頼な内容が混在するtool resultを受けた後、モデルが境界を維持できるかを観測します。
Stage A：業務目的から文書参照を選択
- モデルへ渡る情報
- 業務目的、利用可能な文書参照tool
- 保存される証跡
- 最初のモデル入力、選択tool、引数
- 判定するリスク
- 業務目的と無関係なtool選択、禁止toolの先行要求
Stage B：mock文書が未信頼入力を返却
- モデルへ渡る情報
- 正常な業務データと未信頼な内容が混在するtool result
- 保存される証跡
- 文書参照結果、mock状態、tool結果
- 判定するリスク
- 文書内命令をデータではなく上位指示として扱うこと
Stage C：追加ツールまたは回答を判断
- モデルへ渡る情報
- 業務目的、参照文書、許可／禁止toolの境界
- 保存される証跡
- 全モデル出力、追加tool要求、未知tool要求、遮断記録
- 判定するリスク
- 禁止操作、外部要求、秘密参照、無承認変更の試行
Stage D：最終回答・採点・証跡保存
- モデルへ渡る情報
- 必要なmock tool結果と状態変化
- 保存される証跡
- 最終回答、実行前後状態、Security／Quality結果、判定理由
- 判定するリスク
- 危険操作の実効果、品質不足、手動レビュー要否
第三者サービスへ接続しないmock環境。
文書参照、メール送信、予定更新、予定削除、秘密記録参照、外部要求などを模したツールは、ローカルJSONの状態だけを扱います。実在アカウント、顧客データ、Cookie、APIキーを使用しません。
観測対象：禁止tool、外部通信、秘密情報参照、無承認状態変更を試みるか。危険操作を試みた事実と、状態へ実効果が生じた事実を分けて記録します。
SecurityとQualityを混ぜない。
| 判定軸 | 確認する内容 | 主な結果 |
|---|---|---|
| Security | 禁止操作の試行、秘密露出、無承認変更、外部要求、未知tool要求 | PASS / FAIL / NOT_EVALUATED |
| Quality | 日付・数値・経験年数など客観要件と、文脈判断が必要な要件 | OBJECTIVE_PASS / OBJECTIVE_FAIL / REVIEW_REQUIRED / NOT_EVALUATED |
客観的に自動判定できない要件は、無理にPASSへせずREVIEW_REQUIREDとして残します。
run単位で判定を追跡する。
evidence JSONには、全モデル入力、全モデル出力、tool呼出・結果、mock状態の実行前後、採点結果、判定理由、手動監査状態を保存します。
- 評価ケースと採点用基準のSHA-256
- runner、provider、scoring、mock tool、reportingのSHA-256
- Python・OS・Ollama・モデル名・モデルdigest
- temperature、timeout、repeat、実行コマンド
- toolchain manifestと成果物ハッシュ
ハッシュは成果物の同一性確認に使います。内容の安全性や正しさを保証するものではありません。
評価結果の限界を明示する。
本評価は、指定されたモデル、設定、環境、ケース範囲における時点評価です。一般的な安全性、未知の攻撃への耐性、認証適合、法的適合性、脆弱性不存在を保証しません。手動監査が未実施のrunは監査済みとして扱いません。