AIエージェントの
安全設計

役割を分けると、AIは署名要求を作成し、ポリシーエンジンが条件を確認し、署名者が実行する形になります。AIが署名鍵に触れない構成にしておけば、AI側の誤動作やプロンプトインジェクションが起きても、資産移転の可否はポリシーと署名者の側で止められます。

あわせて、秘密鍵がログ、メモリ、エラーメッセージ、チャット履歴へ出ないことを確認します。本記事では、鍵の具体的な保管手順や個別企業の構成は扱いません。運用中のAIエージェントの権限設計についてはAIエージェントで会社を回すでも触れています。

シミュレーション結果は、人間が理解できる日本語へ変換します。ただし、自然言語の要約だけで承認しません。要約は元データの一部を落とすため、元のトランザクションデータと差分もあわせて保存し、後から突き合わせられるようにします。

シミュレーションは、署名前に気づける範囲を広げる工程であって、結果を保証するものではありません。シミュレーションはある時点の状態を前提にした試算です。送信までに状態が変われば結果は変わりますし、MEVやフロントランのように、送信後の他者の行動で結果が変わる要因は事前に確定できません。許容する最小受取量や有効期限を取引自体へ埋め込み、送信直前にもう一度確認する、pendingのトランザクションとnonceの状態を把握する、といった対策を併用します。

外部データを条件に使う取引では、価格や状態の取得元が止まったり、想定と違う値を返したりする場合があります。外部データの扱いはブロックチェーンのオラクル問題で整理しています。トランザクションやガスの基本仕様は、Ethereumの開発者ドキュメントのTransactionsとGasを参照してください。

当社は、異常系が通らない状態では本番へ進めない方針で設計しています。正常系だけを確認したPoCは、動くことは示せても、事故時に何が起きるかを示せません。PoCを始める前の撤退基準の決め方はPoCを始める前に決めるべき撤退基準、事業化に至らない典型的な原因はPoCが事業化につながらない5つの原因で整理しています。

Netsujoでは、AIエージェントとブロックチェーンを組み合わせる場合、まずLevel 1から3で検証します。AIは読み取り、提案、シミュレーションを担当し、署名と資産移転は別のポリシーと承認へ分離します。

PoCの段階から、停止条件、責任者、監査ログ、本番移行の判定基準を設計します。自律性を高めることより、損失を限定し、経緯を説明でき、止められることを優先します。

ここに書いた段階や条件は当社の設計方針であり、業種・資産・規制環境によって適切な水準は変わります。適用にあたっては、個別の法務確認と第三者による実装監査を併用してください。