100monkeys.ai

ブログ · ガイド · 2026年10月28日

AEGIS の実行ログを読む: 封印されたツール呼び出しが記録するもの

他の言語: English, Español, Português · 日本語のガイド一覧

開示: AEGIS は 100monkeys.ai が開発しているため、このガイドは作り手による説明として読んでください。AEGIS の公開ドキュメント、主に Deploying & Running Agents、CLI Reference、SEAL Protocol ページ、ゲートウェイの Observability ページをもとに当社の AI エージェントが下書きし、当社がレビューしました。この日本語版は英語の原文ガイドの翻訳です。以下のログ行、フィールド、コードはドキュメント自身の例で、このガイドのために取得した出力ではありません。引用は英語のまま示し、訳を添えています。

AEGIS by 100monkeys.ai, in beta は、各エージェントをそれぞれ隔離されたランタイムで動かし、ツール呼び出しを SEAL という署名付きプロトコル経由で送ります。このガイドでは1回の実行を外側から内側へ読みます。実行レコード、反復ログ、そして SEAL レイヤーが1回のツール呼び出し(許可でも拒否でも)について記録する内容です。

なぜ実行が単位なのか

Executions ページははっきりこう書いています。"Each execution is the unit of observability and replay in AEGIS. Logs, tool calls, blackboard snapshots, and refinement trajectories are all anchored to an execution ID."(各実行は AEGIS における観測と再生の単位である。ログ、ツール呼び出し、ブラックボードのスナップショット、改良の軌跡はすべて実行 ID に紐づく。)以下のどの手順もこの ID から始まります。実行は "Execute, Evaluate, Refine"(実行・評価・改良)のループを回し、"when the agent produces output that satisfies its evaluation criteria, when the iteration budget is exhausted, or when an unrecoverable failure occurs"(エージェントが評価基準を満たす出力を出したとき、反復の上限に達したとき、または回復不能な失敗が起きたとき)に終わります。

ステップ 1. 実行 ID を見つける

aegis task execute は開始時に ID を表示します(Execution started: <id>)。自分で開始していない実行は一覧で探します。

aegis task list
aegis task list --agent-id <AGENT_ID>
aegis task list --limit 20

スケジュール実行の実行 ID はスケジュールの実行履歴に載っています。ワークフローの実行は aegis workflow executions list で一覧できます。

ステップ 2. 実行レコードを読む

aegis task status <EXECUTION_ID> --output json

ドキュメントによれば、これは "returns the execution record, including status, start/end timestamps, total iterations, and each iteration's status and validation scores"(状態、開始・終了時刻、総反復数、各反復の状態と検証スコアを含む実行レコードを返す)。まず反復数を読んでください。合格した反復が1回ならクリーンな実行です。反復が複数あるなら、出力が検証に通らず改良されたということで、その理由はログに出ます。

ステップ 3. 反復ログを読む

aegis task logs <EXECUTION_ID>

実行が出力する内容の、ドキュメント自身の例です(行ごとにそのまま)。

[2026-02-23T10:00:01Z] Execution a1b2c3d4-1111-... Started
[2026-02-23T10:00:01Z] Iteration 1 Started
[2026-02-23T10:00:03Z] Tool: fs.write /workspace/solution.py (234 bytes)
[2026-02-23T10:00:04Z] Tool: cmd.run python /workspace/solution.py
[2026-02-23T10:00:05Z] Tool: fs.write /workspace/result.json (89 bytes)
[2026-02-23T10:00:06Z] Iteration 1 Completed
[2026-02-23T10:00:06Z] Validation: exit_code=PASS json_schema=PASS (score=1.0)
[2026-02-23T10:00:06Z] Execution a1b2c3d4-1111-... Completed (1 iteration, 5.2s)

3種類の行として読みます。ライフサイクル(開始、完了)、エージェントが行った呼び出しごとの Tool: 行、そして各バリデーターの判定とスコアを示す Validation: 行です。失敗だけを見るには --errors-only、詳細を見るには --verbose、実行中のものを追うには --follow を付けます。ワークフローでは、aegis workflow logs <EXECUTION_ID> --transitions が状態遷移だけを表示します。

ステップ 4. 各 Tool 行の裏にあるものを知る

Tool: 行の1つ1つが、SEAL を通った1回の呼び出しです。"Every tool call is wrapped in a SealEnvelope"(すべてのツール呼び出しは SealEnvelope に包まれる)。中身は、プロトコル(seal/v1)、security_token(アテステーション時に発行される JWT)、Ed25519 の signature、payload(MCP 形式の呼び出しなら JSON-RPC の tools/call)、container_id、整数の timestamp です。

呼び出しをあなたの実行に結びつけるのはトークンのクレームです。sub(呼び出し元)、scp(セキュリティコンテキストの名前)、wid(ワークロード)、そして exec_id。これは "ties every call in a session to one audit chain"(セッション内のすべての呼び出しを1本の監査チェーンに結びつける)ものです。つまりステップ 1 の実行 ID が、ログ行とそのエンベロープをつなぐ鍵になります。

ステップ 5. 呼び出しが許可された理由を読む

ゲートウェイは呼び出しを転送する前に9つのチェックを行います。プロトコルフィールド、トークンの署名と有効期限、呼び出し元の登録済み鍵、正規化されたメッセージに対するエンベロープ署名、30秒以内のタイムスタンプ、そして最後に scp で指定されたセキュリティコンテキストです。最後のチェックは拒否リストにあるものをすべて拒否し、ツール・パス・ドメイン・サブコマンドとレート制限に合う権限がある場合にだけ呼び出しを許可し、それ以外は "(default deny)"(既定で拒否)します。コンテキストはセッションの途中で変わりません。"callers cannot widen their context, switch contexts, or impersonate a different one"(呼び出し元はコンテキストを広げることも、切り替えることも、別のものになりすますこともできない)。

ステップ 6. 拒否を読む

拒否された呼び出しは、ログ上の無言の空白ではありません。SEAL Gateway では数値コードで応答します。よく見るものは次のとおりです。

ドキュメントは "switch on error.code, not on the status"(ステータスではなく error.code で分岐せよ)と書き、1つの落とし穴を挙げています。オーケストレーター自身の POST /v1/seal/invoke は、拒否に数値ではなく TOOL_NOT_ALLOWED のような文字列コードで応答します。

ステップ 7. 監査レコードを読む

SEAL Protocol ページは、各呼び出しが生む ToolCallAuthorized や PolicyViolationBlocked などのイベントと、それぞれが記録する内容を挙げています。エンベロープの署名・タイムスタンプ・jti、トークンの sub・scp・wid・exec_id、ツール名と "payload digest (not the full payload, payloads are not logged by default)"(ペイロードのダイジェスト。ペイロード全体ではない。ペイロードは既定では記録されない)、そして "the policy decision (ALLOW or DENY plus the deciding rule, if any)"(ポリシー判定。ALLOW か DENY と、決め手になったルールがあればそれ)。否認防止を与えるのは署名です。"only the holder of the ephemeral private key could have produced a valid signature"(一時的な秘密鍵の保持者だけが有効な署名を作れた)。

単体の SEAL Gateway では、これらの行は gateway_events テーブルにあります。まだ REST エンドポイントはなく、ドキュメントは代わりに SQL を示しています。

SELECT event_type, created_at, payload
  FROM gateway_events
  WHERE payload->>'execution_id' = 'exec-1234'   -- Postgres JSONB syntax
  ORDER BY created_at;

テーブルは追記専用なので、最後に送った ID より大きいものをポーリングして SIEM に送ってください。

ドキュメントが明示していないこと

次に読む

これらのログのほかにレビュー担当者が必要とするものは、本番環境の AI エージェントのためのトレーサビリティ・チェックリストをどうぞ。

100monkeys.ai から AEGIS をインストール