# Day 6：失敗しても元に戻る、全部が一本で見える（約4分）

**ねらい：** 差別化の核である「書き込んだ後の整合性（補償）」と「一本のトレース」を、実際の画面で見せる。評価で分かったことも伝える。
**映すもの：** `TransferSagaRoute.java`、台本版デモの場面6・9、Grafana の Explore（Tempo）とダッシュボード、評価レポート。

| 時間 | 画面 | ナレーション | テロップ |
| --- | --- | --- | --- |
| 0:00 | タイトル画面 | 今日の結論です。エージェントが書き込んだ後に何かが失敗しても、統合層が元に戻します。そして、その一部始終が一本のトレースで見えます。 | Day 6：補償と可観測性 |
| 0:13 | `TransferSagaRoute.java` のコメント図 | Camel のルートはこうなっています。まず基幹で資金を拘束。次に振替。振替が失敗したら2回まで再試行し、それでもだめなら拘束を解除します。これが補償です。基幹側の API は ID で冪等なので、再試行しても二重には計上されません。 | 拘束 → 振替 → 失敗なら解除 |
| 0:36 | ターミナル：場面6 | 基幹に障害を1回だけ注入すると、再試行で吸収して振替は成功します。障害を続けると、状態は COMPENSATED。利用可能額は、振込前とまったく同じです。 | 障害1回は吸収、続けば補償 |
| 1:07 | Grafana Explore（Tempo）：振込のトレース | Grafana で、このトレースを開きます。エージェント、LLM、ツール、Camel の Saga、基幹の API まで、一本につながっています。エージェントが MCP の呼び出しごとに traceparent を送り、ツール側はそれを親にスパンを作っています。 | 一本のトレース |
| 1:48 | トレースの時間軸を拡大 | 所要時間の内訳もすぐ分かります。この例では LLM が25秒、ツールと基幹は合わせて0.1秒。遅いと言われたとき、どこを直せばよいかが一目で分かります。 | 遅さの原因が一目で分かる |
| 2:03 | Grafana ダッシュボード | ダッシュボードでは、ガードレールで止めた件数、補償した振込、承認待ちの件数が見えます。運用部門が引き取るための画面です。 | 運用が引き取れる画面 |
| 2:30 | ターミナル：場面9 | 監査証跡は、前の記録のハッシュを含めて連鎖させています。1件書き換えると、検証で「何番の記録が改ざんされた」と分かります。すべての記録にトレース ID が付くので、監査から経緯へ辿れます。 | 改ざんを検出 |
| 3:04 | 評価レポート（S1 の行） | 最後に評価です。LLM 版で8ケースを流し、安全性の違反は0件でした。ただし注入攻撃のケースでは、モデルは実際に振込を依頼してしまいました。止めたのは、承認のしきい値という統制です。 | モデルは攻撃に乗る。統制が止める |
| 3:22 | 締め | ここまでで、7つの統制がすべて動きました。明日は、これを顧客の診断に使える「型」にします。 | 次回：アセスメントキット |

**収録メモ：** トレースの ID は台本版デモの出力（`trace:` の URL）からそのまま開ける。LLM 版は1回25秒ほどかかるため、待ち時間はカット編集する。