業務プロセス自動化の領域で働き、AIエージェントを探究する中で—
研究を読み、ツールの動きを追い、チームがそれらをどのように
導入し始めているかを見ていると—ほとんどすべての真剣な
会話で、次の2つのテーマが繰り返し浮上してきました。ガバナンスと
責任（liability）です。
エージェントが重大な意思決定をしたとき、誰が責任を負うのか？
そのときの文脈（コンテキスト）が何だったかを、どうやって証明するのか？
エージェントが本来アクセスすべきでないデータに基づいて行動したら、どうなるのか？
記録の提示を求める規制当局に対して、どうすれば納得してもらえるのか？私は
ベテランのエージェントエンジニアではありません。これらの問いは
自動化とプロセス側から持ち込んだもので、AIエージェントが実運用で
どのように動くのか、そして本当の摩擦（フリクション）がどこにあるのかを
理解しようとしてきました。しかし、ガバナンスの問いは
深いハンズオン経験を要しなくても、認識できるものでした。
どこにでも現れていました。研究の中でも、コンプライアンスの会話の中でも、
ツールが提供するものと、本当の説明責任が実際に要求するものの間の
ギャップの中でも。
私は、これらの問いを本当に面白いと感じました。さらに、
既存のツールにはそれらに対する良い答えがなかったことも分かりました。
オブザーバビリティのプラットフォームは出力を記録します。
メモリストアは想起（リコール）を最適化します。どちらも、繰り返し
出てくる次の問いに合わせて設計されていませんでした。
「実際に何を、誰に対して、どうやって証明できるのか？」
Aevumは、私なりの「現時点での最善の答え」を形にしたものです。
最終版ではありません。分野は動きが速く、適切なアーキテクチャは
これからも進化し続けるでしょう。しかし、ガバナンスと
責任が実際に求める性質に基づいた、原則に沿った設計です。
前提条件としての同意（consent）、構造的な特性としての改ざん検知可能な
監査（audit）用のsigchain、そしてログを証拠へと変える仕組みとしての
決定論的リプレイ（deterministic replay）です。
What Aevum is
Aevumは、AIエージェント向けのオープンソースのコンテキストカーネルです。
それは、あなたのエージェントと、エージェントがアクセスするデータの間に
位置します。すべての読み取りと書き込みはポリシーにより統制されます。
すべての意思決定は、改ざん検知可能なsigchainに記録されます。
過去の任意のセッションを、決定論的にリプレイできます。
これはメモリストアではありません。オブザーバビリティのプラットフォームでもありません。
その両方の下にある、ガバナンスと監査可能性（auditability）のためのレイヤーです。
from aevum.core import Engine
from aevum.core.consent.models import ConsentGrant
engine = Engine()
engine.add_consent_grant(ConsentGrant(
grant_id="g1",
subject_id="user-42",
grantee_id="billing-agent",
operations=["ingest", "query"],
purpose="billing-inquiry",
classification_max=1,
granted_at="2026-01-01T00:00:00Z",
expires_at="2030-01-01T00:00:00Z",
))
result = engine.ingest(
data={"invoice_id": "INV-001", "amount": 1500.00},
provenance={
"source_id": "billing-system",
"chain_of_custody": ["billing-system"],
"classification": 1,
},
purpose="billing-inquiry",
subject_id="user-42",
actor="billing-agent",
)
print(result.audit_id) # urn:aevum:audit:0196...
print(result.status) # ok
print(engine.verify_sigchain()) # True
同意（consent grant）がないなら、操作はありません。警告ではありません。毎回、
エラーです。しかもカーネルのレベルで。絶対に無効化できない5つの障壁（危機検知、
分類の上限、同意、監査の改ざん不能性、来歴（provenance））は
ハードコードされています。設定、ポリシー、または管理者による上書きによって
無効化することはできません。
The replay distinction
LangSmithの「replay」は、新しいモデルバージョンに対してトレースを
再実行します。つまり再実行（re-execution）です。LangGraphのTime Travelは
チェックポイントを復元します。つまり状態回復（state recovery）です。
どちらも、リプレイ可能な監査成果物（audit artifact）を生成しません。
Aevumのリプレイは、ライブの
知識グラフではなく、不変な来歴グラフから読み取ります。engine.replayを同じ
audit_idで2回呼び出すと、経過した時間やライブグラフがどのように変わっていても、
同一のデータが返されます。この保証が、それをデバッグ用のツールではなく
コンプライアンスの証拠として有用にしているのです。
Why governance questions are becoming engineering questions
EU AI Act 第12条の施行は、2026年8月2日に始まります。高リスクAI
返却形式: {"translated": "翻訳されたHTML"}システムは、イベントの自動的で改ざん検知可能な記録をサポートする必要があります。
規制では形式は指定されていませんが、改ざん検知可能なハッシュ・チェイニングは、Article 12、Article
15（精度と堅牢性）、ISO/IEC 42001、およびSOC 2 PI1.2を同時に満たす実装です。
エージェント型AIアプリケーションに対するOWASPのTop 10（2025年12月）は、
メモリとコンテキストのポイズニング（ASI06）をトップリスクとして分類しています。Aevumの合意
（consent）強制は、この問題に対して構造的に対応しています——ポイズニングされたエントリは、
行為者（actor）、対象（subject）、そして目的（purpose）に対する有効な合意付与がなければ、
書き込むことができません。バリアは、モデルがデータを見る前に
カーネル・レベルで発火します。
これは将来の懸念ではありません。研究の中で何度も立ち上がった
ガバナンス上の問いが、いまや期限付きのエンジニアリング要件として
到来しています。
v0.3.0に入っているもの
- 5つのガバナンス対象の機能：
ingest、query、review、commit、replay barriers.pyにハードコードされた5つの絶対バリア- Ed25519 sigchain + SHA3-256ハッシュ・チェイニング
- インプロセスのCedarポリシー + OPA HTTPサイドカー対応
aevum-mcpによるMCP連携- エージェントの自律性レベルL1〜L5（DeepMindの分類法）、ポリシーで強制可能
- A2Aタスク形式の互換性
- 280のテスト、mypy strict、ruffクリーン
- Apache-2.0、テレメトリなし、完全にオフラインで動作
pip install aevum-core
ドキュメント：https://aevum.build/?utm_source=devto&utm_medium=post
GitHub: https://github.com/aevum-labs/aevum
Aevumがないもの（Aevum is not）
これはメモリ・ストアではありません——Mem0、Zep、またはあなた自身のストアと組み合わせてください。
これはオブザーバビリティ・プラットフォームではありません——OpenTelemetryへエクスポートします。
これはコンプライアンス報告書ジェネレーターではありません——証拠を作成し、
あなたのコンプライアンスチームがそれを解釈します。
これは現時点での最良の回答であり、最終版ではありません。
「replay（再生）」と「observability（可観測性）」の区別の背後にある概念は、
https://aevum.build/concepts/replay-vs-observability/にあり、Article 12
の実装ガイドはhttps://aevum.build/concepts/audit-trails/にあります。
フィードバック歓迎です——特に、別の観点から同じ
ガバナンス上の問いを検討している方からのものを歓迎します。
