A AEP AI AGENT EVIDENCE
AIエージェントの説明責任を、証明で支える

AIに任せた仕事を、あとから証明できる状態に。

AIエージェントが「何を見て、何を判断し、誰が承認したのか」を、あとから書き換えられない証明として残します。監査やトラブルの調査で、当時の根拠をそのまま示せます。

EVIDENCE TRAIL 検証できる状態
外部の情報を取得09:41

出どころ・内容・時刻をまとめて確定

その内容をもとに判断09:42

参照した証明と適用ルールを判断に紐づけ

責任者が承認09:43

本人の明示的な操作としてのみ記録

改ざんなし 出どころ一致 時刻を検証 判定できない項目も区別

接続方式:MCP + OAuth。お使いのエージェントから、サインイン中の組織と許可された範囲だけを呼び出せます。エージェント側の作り替えは不要です。

見た情報を、その場で固定する

参照したページやデータは後から変わります。取得した瞬間の内容を、出どころと時刻ごと残します。

判断と承認を、ひとつに結ぶ

どの情報とどのルールで決めたのか、誰が承認したのかを、判断そのものに紐づけます。

あとから、第三者が確認できる

証明は改ざんを検知できる形で保存され、監査担当や取引先が真正性を確認できます。

01 / 課題

ログは残っても、証拠にはなりません。

「そのとき本当にそうだった」と示せなければ、記録は説明の材料になりません。エージェントが自律的に動くほど、この差が問題になります。

01
参照した情報は、あとから変わる

価格、在庫、契約条件、ニュース。エージェントが見たページは差し替えられます。取得時点の内容が残っていなければ、判断が妥当だったことを示せません。

出どころと内容を切り離さずに確定する。
02
判断の理由が、後追いできない

結果だけが残っていても、どの情報とどのルールで決めたのかは復元できません。説明を求められたとき、当時の入力ごと示せる必要があります。

判断と、その入力集合を同時に固定する。
03
誰が承認したのかが、あいまいになる

時間が経つほど争点になります。承認は、権限を持つ本人が明示的に行った操作としてだけ残されるべきです。

別の依頼から承認を推測しない。
02 / できること

7つの証明で、AIまわりの事故を防ぐ

それぞれ別の問いに答えます。見出しをクリックすると、証明する内容と防げる事故が開きます。

01 取得した情報を証明する 外部から取り込んだ価格・在庫・条件・判定結果などを、出どころごと固定します。
証明する内容

取得元、応答内容の指紋、取得時刻、どのエージェントのどの作業だったかを、ひとつの証明として束ねます。取得元と結びついた証明か、手元のデータを封じただけの証明かも区別して残します。

防げる事故

別のページや応答へのすり替え、見ていない情報を使ったという主張、事故のときにどの応答が関係したのか特定できない状態。

02 情報の変化を証明する 契約条件や価格、連携先の設定が変わったことを、変更前後の対応で証明します。
証明する内容

変更前と変更後それぞれの証明、内容の指紋、比較の前提となる整え方、そして具体的な差分を1件にまとめます。欠けている内容を推測で埋めることはしません。

防げる事故

重要な変更の見落とし、古い契約や仕様を使い続けること、事故のあとで前後の内容を入れ替えられること。

03 情報の鮮度を確かめる 保存済みの情報を再利用してよいか、その時点で判断できたことを証明します。
証明する内容

信頼できる時刻、時刻の検証状態、評価した時刻、許容する経過時間と未来方向のずれを踏まえ、その情報が使える状態だったかを証明します。

防げる事故

期限切れの在庫や古い脅威情報での実行、検証されていない時刻を信じること、用途ごとの有効期限を無視すること。

04 判断の根拠を証明する 購買、支払い、許可・拒否など、業務や安全に影響する判断の理由を固定します。
証明する内容

参照した証明、適用したルールの評価結果、リスクの区分、判断結果の指紋を束ね、判断した時点の入力を固定します。思考の過程そのものは保存しません。

防げる事故

あとから根拠を差し替えること、必要な証明なしでの実行、どの情報が結果につながったのか説明できなくなること。

05 連携先の安全を確かめる エージェントが使う外部ツールの内容が、いつのまにか変わっていないかを証明します。
証明する内容

接続先の識別情報、通信の版、提供されているツール一覧を整えた形、そして前回の証明との関係を残します。

防げる事故

ツールの説明文に仕込まれた不正な指示、危険な引数の追加、同じ名前のまま中身が変わる気づかれない変更。

06 リリース内容を証明する どの版のエージェントが動いていたのかを、成果物ごと特定できるようにします。
証明する内容

指示文、ルール、利用モデル、連携ツール、権限、評価結果などの成果物名・指紋・サイズ・種別を、ひとつのリリース単位に束ねます。

防げる事故

未承認の指示文やルールの出荷、検証版と本番版の混同、事故のときに該当する版を失うこと、同じ版名の使い回し。

07 承認・却下を証明する 影響の大きい操作を、誰が承認または却下したのかを本人の操作として証明します。
証明する内容

認証済みの承認者、対象となる操作とルールの指紋、関連する判断の証明、そして承認か却下かの結果を束ねます。

防げる事故

承認なしの実行、承認後に別の操作へすり替えること、誰が何を許可したのかについて後から生じる混乱や否認。

できること、できないこと

証明があることは、その判断が正しかったという意味ではありません。情報源の内容が事実かどうか、ルールが適切か、判断や承認が妥当だったかは、別に評価する必要があります。AEPが担うのは、当時の根拠・時刻・関係者・設定を、あとから証明できる状態にすることです。

03 / 導入の流れ

サインアップしたら、すぐ使えます

STEP 01
サインアップ

メールアドレスで登録すると、その場で組織用の環境が作られます。

STEP 02
プランを選ぶ

証明を残す量に合わせて選択します。あとから変更できます。

STEP 03
エージェントを接続

発行された接続情報を設定するだけで、既存のエージェントから呼び出せます。

STEP 04
必要なときに確認

説明や調査が必要になった場面で、証明の真正性と時刻を管理画面から確認します。

04 / 活用例

AIエージェントを使うすべてのチームへ

業種ではなく、任せている操作の重さで必要になります。

セキュリティ

エージェントによる遮断や許可が、十分に新しい情報に基づいていたことを確認できます。事故対応では、どの情報がその判断につながったのかを追えます。

情報システム

指示文、ルール、利用モデル、権限をひとつの版として束ね、問題が起きたときに「どの版が動いていたか」を特定できます。

エージェント開発

連携ツールの内容が知らないうちに変わっていないかを記録し、外部から仕込まれた指示や危険な引数の追加に気づけます。

業務の自動化

支払い、公開、権限付与のように影響の大きい操作について、誰が何を承認したのかを残せます。

05 / 安全性

証明の仕組みそのものを、慎重に設計しています

証明が信用されるかどうかは、集め方と扱い方で決まります。範囲、秘匿、判定の扱いを、最初から狭く定めています。

許可された範囲だけで動く

利用は、サインイン中の組織と付与された権限の範囲に限られます。範囲外のデータ収集や公開は行いません。

認証情報は証明に残さない

パスワード、認証コード、APIキー、アクセストークンなどは、証明にも通知にも一切含めません。

確認結果を丸めない

「確認できた」「確認できなかった」「判定できない」を区別して返します。判定できないものを、有効として扱うことはありません。

承認は本人の操作としてのみ

別の依頼から承認を推測することはありません。権限を持つ本人の明示的な指示だけを、承認として残します。

06 / よくある質問

よくある質問

既存のAIエージェントをそのまま使えますか

はい。お使いのエージェントから、許可された範囲でAEPを呼び出す形で組み込みます。エージェント側の作り替えは必要ありません。

使い始めるまでに何が必要ですか

メールアドレスでのサインアップと、プランの選択だけです。営業とのやり取りや事前審査はありません。

証明は誰が確認できますか

サインインした組織と付与された権限の範囲で確認できます。証明の真正性は、権限を持つ担当者や第三者があとから確かめられます。

証明があれば、判断が正しかったと言えますか

言えません。証明は、当時の根拠・時刻・関係者・設定を確認できるようにするものです。情報源の内容が事実かどうか、ルールや判断が妥当だったかは、別に評価する必要があります。

認証情報や機密データが証明に含まれることはありますか

ありません。パスワード、認証コード、APIキー、アクセストークンなどは証明にも通知にも含めない設計です。

AIに任せる範囲が広がる前に、証明の土台を。