Shipping AI Agents — Lessons from Production

Transcript

1. 01 — Shipping AI Agents AI Agents Lessons from Production Yuichi Watanabe — Nulab, Inc. AI DEV DAY FUKUOKA · 2026·04·24
2. 渡邉 祐一 / Yuichi Watanabe Nulab, Inc. — Principal Engineer / AI Integration Unit Lead • Principal Engineer / AI Integration Unit Lead ヌーラボで AI 機能の企画・設計・実装をリード • Datadog Design Partner LLM o11y・Security プレビュー機能の先行利用・フィードバック • Mastra Contributor 業務で使う OSS への貢献を大切に SPEAKER 02 —
3. Backlog AIアシスタント FEATURES 課題の作成・要約 / ナレッジ検索 / 週次報告 / プロジェクトの リスク抽出 RELEASE 2026·03·05 正式リリース BEHAVIOR 読み取りは自律的 / 書き込みは人間が承認 本日の前提となるプロダクト 03 —
4. 2026·03·05 　Backlog AIアシスタント 正式リリース 動かすことと、 届けること 届けることの間に。 実務で試行錯誤して得た、 AI エージェントをプロダクションにリリースするための 実践的な観点とノウハウを共有します。 問題提起 04 —
5. 今日の話は、すべてこの図のどこかで起きている User → Gateway AuthN / AuthZ → AI Agent → LLM → Tool Internal API ① Security ② Safety & Reliability ③ Observability ④ Cost ⑤ Terms システム全体像 05 —
6. CHAPTER 1 ① Security ① Security ② Safety & Reliability ③ Observability ④ Cost ⑤ Terms 06 —
7. ① セキュリティ · HOOK WAF と入力バリデーションだけでは守れない。 従来とは違う脅威モデル。整理すると、4 つの問いに分けられる。 WHO 権限の境界 誰のための呼び出しか? LLM にアイデンティティを渡さ ない 01 WHAT データの破壊 何を扱うか? LLM が生成した値はデータを壊 しうる 02 WHERE 漏洩経路 どこから漏れるか? フレームワークのデフォルト出力 をサニタイズする 03 HOW 意味ベース防御 決定論で取れない脅威に は? LLM-as-a-Judge — 意味を突く 攻撃に意味を読む防御を 04 07 —
8. WHO · 権限の境界 アイデンティティは LLM に渡さない 検証済みヘッダ・JWT・セッションなど、LLM の手の届かない層で確立する。 ❌ Anti-pattern LLM が自己申告できる const inputSchema = z.object({ userId: z.string(), issueId: z.string(), }); // LLM が自己申告できる ✅ Pattern サーバー側 context から取得 const inputSchema = z.object({ issueId: z.string(), }); // 実装内 const userId = ctx.get("userId"); 伝統的な認可 = 悪意ある攻撃者を防ぐ設計。 AI 時代は 意図せず LLM 自身が越境するシナリオも防ぐ設計が必要。 08 —
9. WHAT · データの破壊 LLM 出力はバイト単位で疑う 例: gpt-oss-120b が稀に \x00 を混入 → PostgreSQL が拒否 VERCEL AI SDK wrapLanguageModel middleware を挟む仕組み const sanitized = wrapLanguageModel({ model, middleware: [nullByteSanitizer()], }); 全モデル出力に一元適用。モデル追加時もサニタイズが継続する。 09 —
10. WHERE · 漏洩経路 フレームワークのデフォルト出力を 2 層で遮断 外部フレームワークには、自分で書いていないログ・ストリーム経路がある。 LOG 層 redaction Framework default log ↓ redact App log STREAM 層 sanitizeChunk SSE SSE chunk ↓ sanitize Client デフォルトで何が出ているかを把握した上で、両方の経路を塞ぐ。 10 —
11. HOW · 意味ベース防御 意味を突く攻撃には、意味を読む防御を LLM-as-a-Judge を 3 箇所に挟み、入出力とツール引数を評価する。 User Input ▲ Input Judge → LLM ▲ Output Judge → Tool Call ▲ Tool Call Judge Monitoring-only から段階導入。 レイテンシとコストを見ながら Blocking に切り替える。 採用: Datadog AI Guard 実装詳細 → 2026·06 Datadog Dash NYC 11 —
12. ASSUME BREACH · 侵害前提の設計 "Don't reveal X" は願望であって、セキュリティではない LLM-as-a-Judge は確率的評価 — 100% の保証はない。 Prompt Injection が防御をすり抜けるケースは起こりうる。 RULE 1 機密値はプロンプトに書かない API キー・内部 URL・顧客 ID をシステムプロンプト に埋め込まない。 RULE 2 ツール実行時にサーバー側で注入 LLM には ID だけ渡し、実値はサーバーが解決して ツール呼び出しに差し込む。 プロンプトが漏れても実害がない構造にする。 12 —
13. CHAPTER 2 ② Safety & Reliability ② Safety & Reliability ① Security ③ Observability ④ Cost ⑤ Terms 13 —
14. ② 安全性と信頼性 · 概念整理 独立した 2 つの品質軸 SAFETY 安全性 100% 動いていても、正しい動作をするか? AI 自身の誤判断から守る設計 RELIABILITY 信頼性 そもそも動き続けるか? AI の停止・障害から守る設計 どちらも壊れる前提で、両方を設計する。 X 14 —
15. ② SAFETY · HUMAN-IN-THE-LOOP 重要操作は人間を安全境界に、判断と実行を分離する Server 実体を保持 User ID のみ扱う ① 書き込みツール呼び出し検知 ↓ ② 引数 Snapshot を永続化 ID 発行 → ③ 承認 UI (ID 表示) 承認待ち ↓ ⑤ ID で引数を再解決 ID 返却 ← ④ 承認クリック ↓ ⑥ ツール実行 15 —
16. ② RELIABILITY · クロスリージョン FB LLM プロバイダは単一障害点 AI は止まる前提で、代替経路をあらかじめ持つ。 User → Agent → ✕ 障害検知 Secondary LLM 別リージョン / 別プロバイダ ⚠ FB 先のコスト・レイテンシ・品質特性はプライマリと同じではない ⚠ 切替中をユーザーに明示するか、透過的にするかの判断 Primary LLM 16 —
17. CHAPTER 3 ③ Observability ③ Observability ① Security ② Safety & Reliability ④ Cost ⑤ Terms 17 —
18. ③ 可観測性 · HOOK APM の外側に、AI エージェント固有の可視化対象がある 従来 · APM システムが止まっていないか? ・CPU / メモリ ・レイテンシ / エラー率 + 追加 AI エージェント · LLM O11Y 正しい道筋で動いているか? ・今なぜそのツールを呼んだのか ・いつ過剰なループに入ったのか ・品質は上がったのか下がったのか 18 —
19. ③ 可観測性 · PILLAR 1 / 実行を見る エージェンティックループのトレース AVG INVOCATIONS / STREAM 3.06 3.06 LATENCY ⌀ 12.3s / inv · 37s total ベンダー中立な選択肢 Datadog LLM o11y Langfuse LangSmith Arize Phoenix OTel GenAI 19 —
20. ③ 可観測性 · PILLAR 2 / 品質を測る LLM-as-a-Judge で継続的な Eval ① セキュリティで安全性の判定に使った技術を、ここでは品質の判定に応用する オフライン 回帰テストスイートの LLM 版 いつ プロンプト / モデル変更前 対象 代表的な入力 数十〜数百件 役割 Go/No-Go の根拠 オンライン APM の品質版 いつ 本番トラフィックで継続 対象 応答をサンプリング採点 役割 想定外の変化を検出 / 監視 メトリクス例: 正確性 / 有用性 / 一貫性 — Judge がスコアを採点 20 —
21. CHAPTER 4 ④ Cost ④ Cost ① Security ② Safety & Reliability ③ Observability ⑤ Terms 21 —
22. ④ コスト管理 · HOOK LLM コスト — 使う側と提供する側で、見える景色が違う 消費者体験 月 $20 で使い放題 ・Claude Pro ・ChatGPT Plus ・Google AI Pro LLM プロバイダ側の経済圏 ≠ ギャップ 提供者現実 従量で積み上がる ・入力トークン課金 ・出力トークン課金 ・モデル別単価 AI エージェント提供者の世界 このギャップこそ、コスト管理章の出発点。 22 —
23. ④ コスト管理 · 現実 Input : Output = 47 : 1 47 : 1 本番 1 STREAM の平均 Input 約 98% 1 STREAM あたり 複数回の invocation で Input が累積 なぜこうなる? ReAct ループで 会話履歴 + ツール結果が毎回再注入さ れる構造。ループが深いほど入力トークンが累積す る。 回数課金の感覚で見積もると 2 桁ずれる。 ※ この実測値は ③ 可観測性のエージェンティックループ o11y があっ て初めて見えた。 Output 約 2% 23 —
24. ④ コスト管理 · 対処 スケールの違う 5 つのレバー スケール レバー 設計 効果 1 推論 ① モデル選定 タスク適材適所 短い生成 → 軽量 / 要約 → 中程度 / エージェント中核 → 高性能 Backlog も Bedrock 上で複数モデルを組み合わせ 10〜100 倍 ② Reasoning budget Extended Thinking 推論専用トークンに上限を設定 「最大まで使える」≠「最大まで使うべき」 過剰推論 の回避 1 セッショ ン ③ Loop iteration budget ReAct 最大回数 エージェントループの最大回数を制限 承認フローが個別操作の境界、Loop budget が全体の境界 暴走防止 ④ Message history cap 会話履歴の上限 直近のメッセージのみ context に含める ReAct で毎回再注入される履歴を有限化 Input 抑 制 1 テナント / 月 ⑤ 月次クレジット テナント単位の利用上限 Premium 2,000 credits / 月 · Platinum 5,000 credits / 月 テナント 境界 24 —
25. CHAPTER 5 ⑤ Terms ⑤ Terms ① Security ② Safety & Reliability ③ Observability ④ Cost 25 —
26. ⑤ 規約 · HOOK 普通のソフトウェア契約にはない、3 つの論点 技術で守れないものを契約で明文化 — それだけでなく、AI 特有の事実を規約で受け止める。 01チェーン責任 自社だけでなく、サブベンダーも巻 き込む約束 02確率性の受容 LLM の非決定性を規約で引き受け る 03責任の所在 人間 vs AI エージェントの操作主体 を区別 ※ 利用規約は法務部門が中心となって整備。技術チームは観点を共有・フィードバックする形で関わる。 26 —
27. ⑤ 規約 · ① チェーン責任 AI を"使う側"の 3 重のコミットメント 自社の約束 + サブベンダーへの約束 + 自社アクセスの自制 第 4 条 · AI 学習禁止 — 自社 「当社は、本データを AI モデルの機械学習または再学習のために利用することは一切ありません」 第 4 条 後段 — サブベンダーへ波及 「利用する第三者のサービスにおいても、本データが学習に利用されない設定を適用するものとします」 Anthropic / Bedrock / OpenAI にも no-train 設定を適用する責任を元請けとして負う 第 4 条 · 原則非アクセス 「当社は、原則として本データにアクセスしません」 例外は障害対応 / セキュリティ脅威対応 / 品質検証 / ユーザー依頼などに限定列挙 27 —
28. ⑤ 規約 · ② 確率性の受容 免責 + 禁止の両面で、確率性を受け止める AI の確率性 → 免責（類似物 + ハルシネーション） + 禁止（Prompt Injection） 第 3 条 · 出力の権利 — 類似物を許容 「他の契約者に対して同一または類似の出力データが生成される可能性があることを予め承諾するも のとし、排他的な権利を主張しない」 決定論的コードの契約ではあり得ない条文 — LLM の確率性を契約として受け止める 第 9 条 · 非保証 ハルシネーション免責 不正確・不適切な内容が出力されうる旨を明記 / 医療・法 律・金融の代替とならない 第 8 条 · 禁止事項 Prompt Injection 禁止 技術的に防ぐ対象を、契約上も禁止として位置づける（① セキュリティと連動） 28 —
29. ⑤ 規約 · ③ 責任の所在 条文 + 実装、それぞれの役割 規約設計はエンジニアリングの延長にある設計対象の一つ。 条文で 第 6 条 · ベンダー固定回避 「等を含みますがこれらに限られません」 特定ベンダーに固定されず、将来の構成変更の余地を確 保 第 9 条 · サブベンダー障害の免責 「第三者サービスの障害、仕様変更、もしくは提供終了」 依存構造を隠さず明記することが透明性 実装レベルで 操作主体の区別 「この操作は本当にユーザー本人か? エージェントの代行 か?」 · human · agent 法的問い合わせ / インシデント対応 / 機能改善で使える、 AI エージェント時代の新しい責任の単位 29 —
30. Takeaways CLOSING 30 —
31. LLM o11y で、 見えないものを可視化する ③ Observability ④ Cost LESSON 1 選ばないという 選択肢はない LESSON 1 “ ” 31 —
32. 揺らぐ AI に、 境界を引き、備える ① Security ② Safety & Reliability ④ Cost LESSON 2 Don't reveal X は セキュリティではなく、願望 LESSON 2 “ ” 32 —
33. コードの外側にも 設計を持ち込む ⑤ Terms LESSON 3 コード + 条文 + 監査ログ = 一つのシステム LESSON 3 “ ” 33 —
34. 34 — Thank you Thank you AI Dev Day in Fukuoka · 2026·04·24 · Engineer Cafe GITHUB @vvatanabe X @vvvatanabe