proposal: スレッドスコープのデータプレーン導入によるツール↔Code Interpreter間の大容量データ受け渡し

## 背景 / 問題

Athena系ツール（`athena_query`, `s3_read`, `cloudtrail_query`, `time_series_forecast`）は取得した全データをツールレスポンスに同梱し、LLMコンテキストを経由して Code Interpreter へ渡している（chat-agent の system prompt `` / `TIME_SERIES_VISUALIZATION`）。

これにより2つの問題がある:

- **Hop 1 (Lambda→Gateway→Runtime)**: AgentCore Gateway の tool-call payload 上限 **6MB** が律速。大容量データに非対応。`athena_query` は結果1000行で暗黙に切り詰め（`GetQueryResults` 1ページのみ取得）。
- **Hop 2 (Runtime→Code Interpreter)**: LLM がコンテキスト上のデータを CI の Python コード文字列に埋め込む。トークンコスト・精度劣化・数値書き換えリスク。

ADR 0001 は `time_series_forecast` について S3 artifact 経路を検討し、Custom CI の execution role が Runtime 共有でクロスユーザー漏洩経路になるため却下し、レスポンス同梱を採択した。本提案は「ストレージをチャットスレッドスコープに限定する」ことで ADR 0001 の却下理由を回避し、全 Athena 系ツールに一般化する。

## 確認した最新機能・制約（2026時点）

- **Runtime managed session storage (preview)**: セッション隔離・1GB・14日idle失効・VPC不要。ただし **Runtime microVM 専用**で Lambda/CI からは不可視 → 単独では橋渡し不可。
- **BYO filesystem (S3 Files/EFS)**: セッション間共有のため隔離要件に不適。
- **Code Interpreter**: microVM隔離・10GBディスク・System CI は execution role なし。データ出入りは chat-agent の writeFiles/readFiles 経由のみ。
- **AgentCore に session 単位の AWS クレデンシャル払い出し組み込みは無い**（workload access token は first-party AgentCore サービス／outbound credential provider 向けで、IAM/S3 スコープの creds ではない）。Runtime execution role は session 間で共有される単一ロール。→ **per-session の IAM スコープは app 側で行う必要がある**。

## 提案アーキテクチャ（案1: S3ハンドオフ + 信頼ブローカー）

スレッドスコープ = **Runtime session ID**（プラットフォーム由来・allowlist済みヘッダ・LLM非制御）。chat-agent Runtime が「Gateway結果 / CIセッション / 信頼できるスレッドID」の3面に触れる唯一の信頼ブローカーである点を利用する。

1. **ツールLambda**: 結果を `s3://artifact/{sessionId}/{toolCallId}` に書き、レスポンスは `{ref, schema, row_count, summary, preview(先頭N行)}` のみ返す（数KB）。sessionId は chat-agent が Gateway 呼び出し時に custom header で伝播（`createBearerFetch` に追加、Gateway allowlist へ登録）。
2. **chat-agent**: MCPツールをラップし、`ref`+summary のみを LLM へ渡す。データはコンテキストに載らない。
3. **可視化時**: LLM は `ref` を指定して code_interpreter を呼ぶ。chat-agent の既存 CI ツール（`code-interpreter-tool.ts`）が `s3://.../{sessionId}/{ref}` を app 側 creds で取得し `writeFiles` で CI に投入。LLM の Python はローカルファイルを読む。

### per-session IAM スコーピング（STS session policy による動的スコーピング）

Runtime execution role には artifact bucket への直接 read を付与しない。代わりに:

- 専用の `artifact-access` role を用意し、chat-agent が **信頼できる Runtime session ID から session policy を動的生成して `sts:AssumeRole`**（実効権限 = ロールポリシー ∩ session policy の積集合）→ `arn:aws:s3:::artifact-bucket/{sessionId}/*` に絞った一時 creds で S3 を読む。
- 書き込み側 Lambda も、伝播された session_id で同様に自 prefix へ限定する。

これは SaaS マルチテナントの「token vending machine / 動的ポリシー生成」パターンそのもので、サービス非依存（S3 に適用可）。DynamoDB 固有の `dynamodb:LeadingKeys` とは異なり、S3 でも session policy で同等の per-tenant 隔離が可能。代替として、本リポジトリが既に `data-access` で使用している **S3 Access Grants**（prefix スコープの一時 creds 払い出し）も利用可能だが、揮発的な per-session prefix には session policy の方が軽量。

### セキュリティ根拠

- CI は S3 非アクセス（execution role 不要）→ ADR 0001 案A回避
- presigned URL / CI egress 不要 → ADR 0001 案B回避
- S3 キーは信頼 sessionID から app コードで導出（LLM 非制御）、読み取り主体も app コード
- さらに **IAM レベルで `{sessionId}/*` に session policy スコープ** → app のキー導出ミスやプロセス侵害があってもクロスセッションを IAM で遮断（多層防御）
- 元データは Athena 実行時に Lake Formation で FGAC 済み → 同一セッション内の読み戻しは権限境界内

## 代替案

- **案2 (最小)**: S3 を使わず chat-agent が MCP 結果を傍受し session storage/メモリに保持、ref+summary のみ LLM へ。Hop 2 のコンテキスト汚染のみ解消（6MB/大容量は未解決）。段階導入の第1歩。
- **案3**: Athena が出力する workgroup S3 CSV を再利用。chat-agent が project creds を redeem して読む。新規 bucket 不要で FGAC creds のまま読める。`time_series_forecast` のみ SageMaker 出力のため案1の artifact 書き込みが必要。

推奨: **案2 を第1PR・案1を第2PR とする段階導入**（Hop 2 の汚染を即解消しつつ、大容量対応へ無理なく到達）。

## スコープ / 影響

- 変更: `apps/gateway-tools/*`（レスポンス契約）, `apps/chat-agent/src/{index,code-interpreter-tool,prompt}.ts`, `apps/cdk`（artifact bucket, `artifact-access` role + session policy, header allowlist）, ADR 0001 の supersede
- 非対象（初期）: 100系列超のバッチ、多変量予測
- 要検討: artifact bucket の TTL/ライフサイクル、session policy サイズ上限（インライン2048字。単一 prefix 文なら十分収まる）、案2→案1 の段階導入順序

## Definition of Done（提案時点）

- [ ] 採用案の合意（案2→案1 の段階導入 / 案1単独 / 案3）
- [ ] ADR 作成（0001 を supersede、per-session IAM 動的スコーピングを明記）
- [ ] 実装・E2E 検証（大容量データで Gateway 6MB 超を確認、クロスセッション読み取りが IAM で拒否されることを確認）

Start by reading ADR 0001 and the proposed entry points in apps/gateway-tools/* and apps/chat-agent/src/{index,code-interpreter-tool,prompt}.ts, then inspect the relevant apps/cdk configuration. Done means the adoption path is agreed, a superseding ADR records it, and implementation plus E2E tests verify large-data handling and cross-session access denial.

Written by the indexing model from the issue text.