システムデザイン完全ガイド ⑥｜アーキテクチャの型

• ① 導入と土台
• ② ネットワークと通信
• ③ データを保存する
• ④ システムの部品箱
• ⑤ 壊れないシステム
• ⑥ アーキテクチャの型
• ⑦ 面接を突破する

CHAPTER 36モノリスとマイクロサービス

36.1まず結論

「初期はモジュラーモノリスにします。ドメインごとにモジュール境界を明確にし、
 モジュール間はインターフェース経由でのみ呼ぶ規約にします。
 こうしておけば、後から本当に必要になった部分だけをサービスとして切り出せます。
 分割の判断基準は、① スケール特性が大きく異なる、② デプロイ頻度が大きく異なる、
 ③ チームが独立して動く必要がある、のいずれかです。」

36.2サービス境界の引き方

ドメイン駆動設計 (DDD) の道具

• 境界づけられたコンテキスト (Bounded Context)：同じ「顧客」でも、営業コンテキストと配送コンテキストでは意味が違う → 別モデルにしてよい
• 集約 (Aggregate)：トランザクション整合性を保つドメイン境界。実装上のロック範囲や DB 行と必ず一致するわけではない
• コンテキストマップ：サービス間の関係（上流/下流、腐敗防止層）

❌ 「DB サービス」「ビジネスロジックサービス」「API サービス」
   → 1 つの機能追加に全部の変更が必要（＝分散モノリス）
✅ 「注文サービス」「在庫サービス」「決済サービス」
   → 各サービスが縦にフルスタックを持つ

36.3サービス間通信

36.4移行戦略：ストラングラーフィグ・パターン

モノリスを一気に置き換えるのは（ほぼ必ず）失敗します。

① モノリスの前にプロキシを置く
② 新機能・切り出す機能だけを新サービスにルーティング
③ 少しずつルーティング先を移していく
④ モノリス側の該当コードを削除
⑤ 最終的にモノリスが空になる（or 小さな核だけ残る）

段階1: 新サービスが旧 DB を直接読む（暫定。書きは旧のまま）
段階2: 新サービスが自分の DB を持ち、CDC で同期（両方に存在）
段階3: 書き込みを新サービスへ移す
段階4: 旧テーブルを削除

CHAPTER 37イベント駆動・CQRS・イベントソーシング

37.1イベント駆動アーキテクチャ

【命令 (Command)】「注文を作成せよ」 — 特定の相手に、実行を依頼する。拒否されうる
【イベント (Event)】「注文が作成された」 — 過去形。事実の通知。誰が聞くかは知らない

[注文サービス] ──OrderCreated──► [イベントバス]
                                    ├──► [在庫サービス] 引き当て
                                    ├──► [通知サービス] メール送信
                                    ├──► [分析基盤]    集計
                                    └──► [検索インデックス] 更新
       ↑ 新しい購読者を追加しても、注文サービスは一切変更不要

37.2CQRS（コマンドクエリ責務分離）

【書き込み側】                  【読み取り側】
正規化されたモデル              クエリに最適化された非正規化ビュー
トランザクション整合             結果整合
  │                                ▲
  └──── イベント / CDC ────────────┘

使いどころ

• 読み:書き比、クエリ形状、独立スケール、整合性要件が大きく異なる
• 読み取りが複雑（複数テーブルの JOIN、集計）
• 読み取りと書き込みでスケール特性が違う
• 同じデータを複数の形で見せたい（一覧用・詳細用・分析用）

書き込み: PostgreSQL の正規化テーブル（orders, order_items, users）
   ↓ CDC (Debezium) → Kafka
読み取り: Elasticsearch の非正規化ドキュメント（検索用）
          Redis の集計値（ダッシュボード用）
          BigQuery（分析用）

37.3イベントソーシング

【従来】現在の状態だけを保存
   account: {id: 1, balance: 900}     ← 過去の経緯は失われている

【イベントソーシング】出来事を追記していく
   [AccountOpened  {id:1}]
   [Deposited      {amount: 1000}]
   [Withdrawn      {amount: 100}]
   → 再生 (replay) すると balance = 900

現在の状態 = fold(すべてのイベント)

利点

• 完全な監査ログ（金融・医療で強力。「なぜこの状態になったか」が必ず分かる）
• タイムトラベル（任意の過去時点の状態を再現できる）
• 新しい読み取りビューを後から作れる（過去に遡って再構築できる）
• バグの修正後、イベントを再生して正しい状態を作り直せる

欠点（実務では重い）

• 現在の状態を得るのに再生が必要 → スナップショットは有力な最適化だが、イベント数、復旧時間、再構築コストに応じて導入する
• イベントスキーマの変更が極めて困難（過去のイベントは変更できない → アップキャスタが必要）
• クエリが難しい（CQRS とほぼセットで使う）
• GDPR の削除権と相性が悪い（暗号化消去：個人ごとの鍵を捨てることで実質削除する手法を使う）
• 学習コストが高く、チーム全員の理解が必要

37.4CDC（変更データキャプチャ）

MySQL binlog / PostgreSQL WAL
      │  Debezium などが読み取る
      ▼
   Kafka トピック（テーブルごと）
      ├──► Elasticsearch（検索）
      ├──► データウェアハウス（分析）
      ├──► キャッシュの無効化
      └──► 他のマイクロサービス

CHAPTER 38バッチ処理とストリーム処理

38.1バッチ処理

特徴: 有限のデータ（昨日のログ全部）を、まとめて処理する
   入力が固定でも、処理ロジックと出力先が冪等とは限らない
   → deterministic な処理、checkpoint、冪等な sink、再実行方針を設計する
   高スループット、レイテンシは時間単位

Map    : 各レコードを (key, value) に変換する。並列に実行できる
Shuffle: 同じ key を同じマシンに集める ← ここが最も重い（ネットワーク）
Reduce : key ごとに集約する

例: 単語カウント
  Map:    "the cat sat" → ("the",1), ("cat",1), ("sat",1)
  Shuffle: 同じ単語を同じ Reducer へ
  Reduce: ("the", [1,1,1,...]) → ("the", 1523)

38.2ストリーム処理

特徴: 無限に続くデータを、到着するたびに処理する
   レイテンシは秒〜ミリ秒
   状態を持つ処理（集計）が難しい ← 「いつ終わりか」が分からないから

38.3イベント時刻 vs 処理時刻（重要）

イベント時刻 (event time): 出来事が実際に起きた時刻（スマホでボタンを押した時刻）
処理時刻 (processing time): システムがそれを処理した時刻

→ 圏外だった端末のログが 3 時間後に届く、という状況が普通に起きる

ウォーターマークが 10:05 を超えた → 10:00〜10:05 のウィンドウを確定して出力する
その後に届いた 10:03 のデータ = 遅延データ (late data)
  → ① 捨てる  ② サイドアウトプットに送る  ③ 結果を訂正して再出力する

「モバイルからのイベントは遅延が大きいので、イベント時刻で集計し
 ウォーターマークを設定します。許容遅延は 10 分とし、
 それを超えたデータは別ストリームに退避して日次バッチで補正します。
 リアルタイムの数値は暫定値である旨を UI にも明示します。」

38.4Lambda / Kappa アーキテクチャ

                ┌─► バッチ層（正確・遅い）──┐
生データ ──────┤                            ├─► サービング層（統合ビュー）
                └─► スピード層（速い・近似）┘

• ✅ 速さと正確さの両立
• ❌ 同じロジックを 2 回実装する（バッチ用とストリーム用）→ 保守が地獄

生データ ──► ストリーム処理のみ ──► サービング層
（再計算が必要なら、ログの先頭からリプレイする）

• ✅ ロジックが 1 つだけ。Kafka の保持期間を長くしておけば再処理できる
• ❌ 大規模な過去データの再処理は時間がかかる

38.5データ基盤の全体像

【収集】アプリのイベント、CDC、ログ
    ▼
【転送】Kafka / Pub/Sub
    ▼
【保存】
  データレイク（S3/GCS + Parquet/Iceberg）: 生データ、安価、スキーマ後付け
  データウェアハウス（BigQuery/Snowflake）: 構造化、SQL、高速分析
    ▼
【処理】ELT（生のまま入れて、SQL で変換）が現代の主流。dbt など
    ▼
【利用】BI ダッシュボード、機械学習、レポート、逆 ETL

行指向: [id,name,age][id,name,age]...  → age だけ集計したくても全部読む
列指向: [id,id,id...][name,name...][age,age...] → age の列だけ読めばよい
      → 同じ型が並ぶので圧縮率も劇的に高い（10 倍以上）

CHAPTER 39マルチリージョンと災害対策

39.1なぜマルチリージョンにするのか

1. レイテンシ：日本のユーザーに米国から返すと +120 ms（第 1 章の光速の壁）
2. 災害対策：リージョン全体の障害に耐える
3. 法規制：データ主権（GDPR、中国、ロシアなど）
4. 可用性：単一リージョンの障害モデルを超える可用性目標を満たしたい

39.2構成パターン

EU ユーザーのデータ → 通常時は EU リージョンを優先する
US ユーザーのデータ → 通常時は US リージョンを優先する
→ 通常時の競合と越境を減らし、レイテンシも改善しやすい。
  ただし移住・フェイルオーバー・グローバル操作では例外を設計し、
  法的適合はデータ種別、処理者、移転根拠、削除・復旧手順まで確認する
→ ユーザーが移動・越境する場合の扱いを決める必要がある

39.3データ複製の選択

【同期複製（クロスリージョン）】
  書き込みに +100〜200 ms（大陸間 RTT）
  → 書き込みが遅くて許容できないことが多い
  → Spanner は Paxos + TrueTime でこれを実用化している（ただしレイテンシは正直に払う）

【非同期複製】
  書き込みは速い
  → フェイルオーバー時に直近のデータが失われる（RPO > 0）
  → 大半のシステムはこちらを選ぶ

39.4リージョン障害時の運用

① 検知（ヘルスチェック、複数の外部監視地点から）
② トラフィックを切り替える（GeoDNS、Anycast、グローバル LB）
③ Passive 側の DB を昇格（プライマリに）
④ 整合性の確認（未複製データの扱い）
⑤ 旧リージョン復旧後の再同期（split-brain の解消が最難関）

39.5データレジデンシー（法規制）

GDPR (EU)      : 域内拠点、域内の個人へのサービス提供・監視などで適用範囲を判断。
                 移転、削除権、アクセス権に条件がある
中国 (PIPL)    : データの種類、事業者、処理規模などに応じた越境・保存要件を確認
ロシア、インド等: それぞれの国内保存要件
医療 (HIPAA)、決済 (PCI DSS): 業界別の要件

CHAPTER 40セキュリティ

40.1認証と認可

認証 (Authentication): あなたは誰か   → パスワード、MFA、生体、証明書
認可 (Authorization) : 何をしてよいか → ロール、権限、ポリシー

アクセストークン（JWT、有効期限 5〜15 分）  ← 短命なので失効の問題を軽減
リフレッシュトークン（不透明な文字列、長命）← サーバー側で管理し、失効可能
                                            + ローテーション（使い捨て）で盗難検知

40.2OWASP Top 10 的な脆弱性（最低限）

GET /api/orders/12345
   ← このユーザーが本当に 12345 の所有者か毎回確認しているか？

脅威モデリング：境界・資産・悪用経路

コンポーネントを並べる前に、次の順で脅威を洗い出します。

1. 境界を描く：ユーザー、ブラウザ、API、ワーカー、DB、外部 SaaS、管理者、テナントの間で、信頼が切り替わる場所を示す
2. 資産と損失を定義する：認証情報、個人データ、決済、モデル・プロンプト、可用性、完全性を列挙する
3. 悪用経路を列挙する：認証情報の盗難、認可バイパス、リプレイ、SSRF、サプライチェーン、データ汚染、プロンプトインジェクション、内部者の誤操作を考える
4. 防御と検証を割り当てる：最小権限、入力・出力の検証、分離、レート制限、暗号化、監査、アラート、復旧手順を各脅威に対応づけ、残余リスクと受け入れ条件も記録する

特にマルチテナントと AI ツール実行では、モデルの出力や取得文書を命令ではなく untrusted input として扱います。テナント・ユーザー・操作ごとに能力を絞り、破壊的操作は dry-run や人間承認を経由させ、監査ログから「誰が、どのモデルの、どのツールで、何を変更したか」を再現できるようにします。

40.3暗号化と鍵管理

転送中 (in transit): TLS 1.2+ （内部通信も mTLS）
保存時 (at rest)   : ディスク暗号化 + 列レベル暗号化（PII、カード番号）
使用中 (in use)    : 機密コンピューティング（TEE）。特殊用途

データ → DEK（データ暗号鍵）で暗号化
DEK   → KEK（マスター鍵、KMS/HSM 内）で暗号化して一緒に保存
→ KEK のローテーションでは、保存済み DEK を新しい KEK で再ラップする。
  全データの再暗号化を避けられるが、
  鍵の世代管理・失効・バックアップ・復旧手順は必要

❌ 平文、MD5、SHA-256（高速すぎて総当たりされる）
✅ bcrypt / scrypt / Argon2id（意図的に遅く、メモリを食う）+ ソルト（自動付与される）

40.4ゼロトラストと多層防御

従来（境界防御）: 「社内ネットワークの中は安全」→ 一度侵入されたら終わり
ゼロトラスト   : 「すべてのリクエストを毎回検証する」
                ネットワーク位置ではなく、ID とデバイスの状態で判断

DDoS 対策（CDN / Anycast で吸収）
  → WAF（SQLi/XSS のパターン遮断）
  → レート制限
  → 認証・認可
  → 入力バリデーション
  → 最小権限（DB ユーザーに DROP 権限を与えない）
  → 監査ログ（誰が何をしたか）
  → 暗号化（漏洩しても読めない）

40.5DDoS 対策

「認証は OIDC で行い、アクセストークンは 10 分の JWT、
 リフレッシュトークンはサーバー側で管理してローテーションします。
 すべての API でリソースの所有者チェックを行い、URL の ID を信用しません。
 サービス間通信は mTLS で相互認証し、DB の認証情報は
 Secret Manager から短命の動的認証情報として取得します。」

CHAPTER 41プライバシーとコンプライアンス

41.1個人データの扱い

PII（個人識別情報）: 氏名、メール、電話、住所、IP、Cookie ID、位置情報、
                    デバイス ID、生体情報
機微情報          : 人種、信条、健康、性的指向、犯罪歴 → より厳格な扱い

41.2GDPR / 各国法が要求する機能

本体 DB     → 削除・匿名化する
レプリカ     → 伝播する
バックアップ → 保持期間中は変更せず、復元時に削除済み状態を再適用する設計もある
ログ         → PII を最小化し、保持期間・マスキングを適用
データレイク → 個人単位の削除・再生成・暗号鍵の分離を検討
イベントログ → 削除イベント、投影の再構築、暗号化消去を組み合わせる
検索インデックス、キャッシュ、CDN、第三者 SaaS → 削除伝播と監査を設計

ユーザーごとに個別の暗号鍵で PII を暗号化して保存する
削除要求 → その鍵を破棄する
→ その鍵で暗号化されたデータを復号できなくする。
  ただし共有データ、メタデータ、バックアップ、鍵のコピー、法的要件を別途確認する。

41.3データ分類とアクセス制御

Public       : 公開情報
Internal     : 社内限定
Confidential : 顧客データ（アクセスログ必須）
Restricted   : 決済情報、健康情報（暗号化 + 承認フロー + 監査）

CHAPTER 42コストの設計

42.1コストの内訳（クラウドの相場感）

計算 (Compute)     : 全体の 40〜60%
ストレージ          : 10〜20%
データ転送          : 10〜30% ← 見落とされがち。特にリージョン間・インターネット向け
マネージドサービス  : DB、キュー、監視（意外と高い）
監視・ログ          : ログの量に比例して爆発しがち

オブジェクトストレージ: 料金表から、保存容量・リクエスト・取り出しを分けて計算
インターネットへの外向き転送: 料金表から、データ量・宛先・無料枠を分けて計算
同一リージョン内の AZ 間転送: 料金表から、方向・サービス間転送を確認
CDN 経由の転送: CDN のリージョン、キャッシュヒット率、オリジン転送を含めて計算

42.2コスト最適化の手段

42.3設計におけるコストの考え方

「動画のサムネイルを全解像度で事前生成すると、生成コストとストレージが膨らみます。
 アクセス分布が上位コンテンツに偏るという仮説を、ログで検証します。
 偏りが確認できるならオンデマンド生成 + CDN キャッシュにします。
 生成回数、TTL、ヒット率、鮮度 SLO を測り、事前生成とのコストと体験を比較します。」

CHAPTER 43AI・機械学習・LLM・AI エージェントのシステム設計

43.1なぜ「AI / ML のシステムデザイン」が特別なのか

従来の Web システム（CRUD）と機械学習システムには、根本的な 4 つの違いがあります。

モデルライフサイクルと評価

本番の ML は「モデルを学習してデプロイしたら終わり」ではありません。データとモデルの版を追跡し、同じ入力から同じ特徴量・予測を再現できるようにします。

データ収集・同意確認
  → 品質検査（欠損、外れ値、ラベル漏洩、PII）
  → 学習・再現可能な実験
  → モデルレジストリ（モデル、特徴量、データ、コード、評価の版）
  → オフライン評価
  → シャドー / カナリア / A/B
  → 監視（品質、ドリフト、遅延、コスト、公平性、安全性）
  → 承認・ロールバック・再学習

オフラインの精度だけで本番品質を代表させず、オンラインのビジネス指標、ガードレール違反、セグメント別の性能、推論コストを分けて測ります。ラベルが遅い場合は代理指標と人手サンプルを併用し、データ削除・同意撤回・モデル更新が学習データと特徴量ストアへどう伝播するかも設計します。

43.2大規模推薦システム（Two-Tower モデルと 3 段階パイプライン）

Google YouTube、Instagram、TikTok などの推薦システムは、数億件のコンテンツから数十ミリ秒でパーソナライズされたフィードを生成します。これを 1 つの巨大なモデルで解くのは計算量的に不可能です。

10 億件の動画
    │
    ▼ ① Candidate Generation (Retrieval / 候補抽出)   [10〜20 ms]
数千件（1,000 件）  ← Two-Tower Model + ANN (ScaNN / HNSW)
    │
    ▼ ② Heavy Ranking (Scoring / 精密ランキング)      [20〜30 ms]
数百件（100 件）    ← 深層学習モデル (DLRM / Transformer) + 数千の特徴量
    │
    ▼ ③ Re-ranking & Policy (ビジネスロジック・多様性) [5 ms]
数十件（20 件）     ← 重複排除、探索と活用、鮮度ブースト、広告挿入
    │
    ▼
ユーザーの画面へ

1. Candidate Generation（Two-Tower Model / Dual Encoder）

• ユーザー Tower：ユーザーの閲覧履歴、検索クエリ、年齢、時間帯などを入力し、ユーザー埋め込みベクトル u（D 次元）を出力
• アイテム Tower：動画のタイトル、タグ、カテゴリ、制作者情報を入力し、アイテム埋め込みベクトル v（D 次元）を出力
• 検索の仕組み：アイテムベクトルはオフラインで事前計算してベクターインデックス（ScaNN / HNSW）に格納。オンラインリクエスト時、ユーザー Tower だけをミリ秒で計算し、ANN 検索で内積 u・v の上位 1,000 件を 10 ms 以内に抽出

2. Heavy Ranking（精密ランキングモデル）

• 抽出された 1,000 件に対し、リッチな特徴量（「このユーザーがこの作者の動画を過去に最後まで見た確率」「過去 10 分間のクリック数」など）を結合
• 深層学習ランキングモデル（DLRM、Wide & Deep、Transformer など）で、CTR（クリック率）や視聴完了時間を予測

3. Re-ranking（多様性とビジネスルール）

• 同じ作者の動画が連続しないように分散（MMR: Maximal Marginal Relevance）
• 「探索と活用（Exploration vs Exploitation）」：新着動画を一定割合混ぜてユーザーの反応をテスト

43.3特徴量ストア（Feature Store）の設計

推薦や不正検知では、モデルに渡す「特徴量（Features）」の管理がシステムの成否を分けます。

                   ┌─────────────────────────────────────────┐
                   │           Feature Store (Feast 等)       │
                   ├────────────────────┬────────────────────┤
                   │  オフラインストア  │   オンラインストア │
                   │ (BigQuery / GCS)   │ (Bigtable / Redis) │
                   └─────────┬──────────┴─────────┬──────────┘
                             │                    │
                   学習時（バッチ）      推論時（リアルタイム）
                   ・過去 1 年のログ     ・直近 5 件の閲覧履歴
                   ・Point-in-Time 一貫性・p99 < 5 ms の低遅延

43.4LLM 推論サービング基盤の基礎

ChatGPT や Gemini のような大規模言語モデル（LLM）の推論は、通常の Web サーバーとは全く異なるリソース制約を持ちます。

① Prefill（プロンプト処理）vs Decode（トークン生成）

② KV Cache と PagedAttention（最重要）

Transformer は過去の全トークンの Key と Value の行列（KV Cache）を保持して計算をスキップします。

KV bytes = 2 × layers × KV heads × head dim × sequence length
           × batch size × bytes per element

③ Continuous Batching（動的・インフライトバッチング）

• 静的バッチングの課題：10 人のリクエストをまとめた場合、一番長い出力（1000 トークン）が終わるまで、短い出力（10 トークン）の人も GPU を拘束し続ける
• Continuous Batching：1 トークン生成するイテレーションごとに、生成が完了したリクエストを即座に排出し、キューにある新しいリクエストを動的にバッチへ差し込む。スループットの向上幅は、出力長、バッチサイズ、スケジューラ、モデル、SLO を同じ条件で測定する

④ 投機的デコーディング（Speculative Decoding）

軽量なドラフトモデル（7B）が高速に 4〜5 トークンを先読み生成し、巨大なターゲットモデル（70B）が 1 回のフォワードパスで検証する。速度向上は受理率、モデル、負荷に依存する。

43.5RAG（検索拡張生成）の完全アーキテクチャ

LLM に最新情報や社内ドキュメントを参照させる標準パターンです。

[ユーザーの質問]
       │
       ▼
[① Query Rewriting / HyDE]（質問を検索しやすい形・仮想回答に変換）
       │
       ▼
[② ハイブリッド検索] ──┬──► [BM25 転置インデックス]
                      └──► [Embedding モデル] → [ベクター DB (HNSW)]
       │
       ▼
[③ RRF 統合]（上位 50 件を抽出）
       │
       ▼
[④ Cross-Encoder リランカー]（上位 5 件に高精度に絞り込み）
       │
       ▼
[⑤ コンテキスト圧縮 & プロンプト構築]
       │
       ▼
[⑥ LLM 推論サービング] ──(ストリーミング SSE)──► [クライアント]

セマンティックキャッシュ（Semantic Cache）

• プロンプトの完全一致（MD5）ではなく、Embedding の類似度で候補を探す方式。ただし、類似度の閾値はデータで検証する
• キャッシュキーにはテナント、ユーザー権限、モデル版、システムプロンプト、ツール、データ鮮度を含める。個人情報・高リスク回答を無条件に共有せず、コストとレイテンシの改善幅は実測する

43.6AI エージェントの本番システム設計

AI エージェントは「LLM に長いプロンプトを渡すこと」ではありません。モデルが計画を立て、ツールを呼び、結果を解釈し、状態を更新して次の行動を選ぶ制御ループです。手順が固定されているなら、自由なエージェントより通常のワークフローやステートマシンの方が安く、再現性が高く、検証しやすい、という判断から始めます。

① 基本ループと責任の分離

[要求 + ユーザー/テナント境界]
          │
          ▼
[ポリシー・能力チェック] ── 許可されたツールだけを公開
          │
          ▼
[計画 / ルータ] ──► [ツール実行（サンドボックス、期限、予算）]
          │                         │
          │                         ▼
          │                [結果の検証・副作用の確認]
          │                         │
          └──── [状態・監査ログへチェックポイント] ◄─┘
                         │
              継続 / ユーザー確認 / 完了 / 停止

モデルには「何を考えたか」ではなく、必要な構造化出力（ツール名、引数、根拠、次の状態）を返させます。認証・認可、予算、リトライ、監査、外部副作用の確定は、モデルの判断に任せず決定的な実行器で担保します。

② ツール契約（Agent–Computer Interface）

ツールは関数呼び出しの名前だけでは不十分です。各ツールに次の契約を持たせます。

「タイムアウトしたので再実行」は、外部で既に処理されたか分からない非原子的失敗を起こします。冪等キーで重複を抑え、再試行前に状態照会または事後条件（残高が減った、チケットが発行された等）を検証します。支払い、削除、送信、権限変更など不可逆操作は、明示的な確認・人間承認・二重チェックを要求します。

③ 状態、メモリ、長時間実行

「コンテキストに履歴を全部詰める」設計は、トークン費用・漏洩・コンテキスト上限で破綻します。少なくとも次を分離します。

• 作業コンテキスト：現在のターンで必要な短期情報。要約・圧縮・期限を持つ
• タスク状態：ステートマシン、実行 ID、試行回数、期限、チェックポイント、未完了ツールを永続化する
• 知識・長期メモリ：出典、テナント、権限、鮮度、削除状態、モデル版を付けた検索可能なデータ

ワーカーが落ちてもチェックポイントから再開できるようにし、同じステップを再実行しても結果が壊れないようにします。最大ステップ数、最大トークン、経過時間、外部 API の費用、並列数を上限にし、上限到達時は安全に停止してユーザーへ引き継ぎます。

④ セキュリティとプロンプトインジェクション

取得文書、メール、Web ページ、ツール応答に含まれる「指示」は、システムポリシーより下位のデータです。それらを命令として実行すると、秘密情報の持ち出し、越権操作、SSRF、データ汚染につながります。

• システム指示、ユーザー入力、取得データ、ツール結果を構造的に分離する
• ツールを能力（capability）単位で分け、不要な秘密・ネットワーク・ファイルにアクセスさせない
• 外部 URL は許可リスト、DNS 再解決、プライベート IP・メタデータサービス遮断を行う
• 出力だけでなく、引数・権限・副作用を決定的なポリシーエンジンで検査する
• テナント境界、削除、監査、保持期限を RAG・キャッシュ・メモリ・ログにも適用する

⑤ 評価・観測・運用

最終回答の正しさだけでなく、軌跡（trajectory）を評価します。代表的な指標は、タスク成功率、正しいツール選択・引数率、不要な呼び出し率、再試行・停止の適切さ、制約・ACL 違反率、人間への引き継ぎ率、p95/p99 レイテンシ、トークン・ツール費用です。

固定のゴールデンケース、過去トレースのリプレイ、敵対的入力、権限境界、長時間・部分障害を組み合わせます。LLM-as-a-judge は補助に留め、人手サンプルや決定的な検査（スキーマ、ACL、状態遷移、事後条件）で校正します。本番では、モデル版・プロンプト版・ツール版・入力要約・各呼び出し・判断結果を Trace ID で結び、カナリア、キルスイッチ、予算アラート、ロールバックを用意します。

⑥ 単一エージェント、ワークフロー、マルチエージェント

マルチエージェントにする場合も、各役割の入力・出力スキーマ、タイムアウト、予算、再試行、停止条件、責任者を定義します。共有の自由文メモだけで協調させず、中央のオーケストレータが権限と状態遷移を管理します。

「まず固定手順ならワークフローにします。探索が必要な部分だけエージェントにし、
 ツールは read-only と副作用ありに分けます。
 各呼び出しに期限・冪等キー・最小権限・事後条件を持たせ、
 タイムアウト時は状態照会してから再試行します。
 実行状態をチェックポイント保存し、ステップ数・費用・時間の上限で停止します。
 削除や決済は人間承認、全文書とツール結果は untrusted input、
 監査トレースとリプレイ評価でモデル更新をカナリアします。」