一般的な Web アプリのリスクに加えて、本製品には性質上避けられない 2 つのリスクがある。

R1 は「ユーザーが気をつける」で解決しない。 本人が気づかずに貼り付けるから混入するのであり、システム側で除去する以外に方法がない。

  ✗ してはいけない       ブラウザ ──[APIキー]──▶ OrcaRouter
                              ↑ DevTools で誰でも見える

  ✓ 本製品               ブラウザ ──▶ enebular 関数 ──[APIキー]──▶ OrcaRouter
                                          ↑ envVars にのみ存在

CI にキーを置かない構成にしたのは、漏洩経路そのものを減らすため。 CI が知る必要のあるシークレットは enebular のアクセスキーだけになる。

サーバ側で必ず検証する。 フロントの検証は UX のためのものであり、防御ではない。

実装は packages/shared/src/schemas/ の Zod スキーマ。 FE と BE が同じスキーマを参照するため、検証内容がずれない。

20,000 文字の上限は UX のためだけではない。 LLM への入力トークン数の上限であり、そのままコストの上限になる。 入力バリデーションとコスト管理がここで一致している。

すべてのセッション操作で、データストアのメインキーに ownerId を含める。

// 他人の sessionId を渡されても、キーが一致しないので 0 件しか返らない
getItem(sessions, { ownerId: ownerIdOf(authUser), sessionId: req.params.id })

パラメータの sessionId だけでは引けない構造にすることで、 アクセス制御の書き忘れが「情報漏洩」ではなく「見つからない」に着地する。

ログの目的は運用とコスト把握であり、入力内容の再現ではない。 デバッグに本文が必要な場面はあるが、それは開発環境（MOCK_MODE または LOG_LEVEL=DEBUG）に限定し、本番では出さない。

// ✗ 入力がそのままログに乗る
catch (e) { console.error('failed', { input: req.body, error: e }) }

// ✓ 入力の「形」だけを残す
catch (e) { console.error('failed', { errorTextLength: body.errorText.length, code: e.code }) }

例外を握りつぶさず、かつ入力を残さない。 エラーメッセージに入力値を埋め込まないのが原則。

エラーログには認証情報が混入する前提で扱う。 データストアに保存する前・LLM に送る前にマスクする。

マスキングはクライアントとサーバの二段で行う。

  ┌─ ブラウザ ──────────────────────────────────┐
  │  ユーザー入力                                 │
  │      │                                       │
  │      ▼                                       │
  │  ┌─────────────────────┐                     │
  │  │  マスキング（決定的） │  貼り付けた瞬間に実行 │
  │  └──────┬──────────────┘                     │
  │         ▼                                     │
  │  ┌─────────────────────┐                     │
  │  │  プレビュー表示       │  利用者が追加で伏せる │
  │  └──────┬──────────────┘                     │
  └─────────┼───────────────────────────────────┘
            │  マスク済みテキストのみ送信
            ▼
  ┌─ サーバ ────────────────────────────────────┐
  │  ┌─────────────────────┐                     │
  │  │  マスキング（再実行） │  ← ここが正。冪等     │
  │  └──────┬──────────────┘                     │
  │         ├──▶ データストアへ保存               │
  │         └──▶ LLM へ送信                       │
  └─────────────────────────────────────────────┘

同じ純関数（packages/core/src/masking.ts）を両側で使う。 外部依存も Node API も持たない文字列処理なので、esbuild でフロントにもバンドルできる （ADR-012）。生テキストはブラウザから出ない。

クライアント側のマスクは UX のためであり、保証ではない。 正はサーバ側の再実行である。クライアントは信用せず、冪等なので二重適用しても無害。 「クライアントで消しているから安全」という説明はしない。

手動マスク（利用者が選んで伏せる）は、原理的にクライアントでしか実装できない。 どの範囲を伏せたいかはサーバには分からないため。この制約から二段構成が決まっている。

表示は 2 段階に分かれる。 難易度が違うため、実装上も分けて扱う。

A の実装のためにフロントエンドへバンドラを入れた（ADR-013 の改訂）。 「同じ純関数を両側で使う」を守るには、packages/core/src/masking.ts を ブラウザへ届ける手段が要る。正規表現を書き写す案は採っていない。 表示と実体がずれたマスキングは、無いより悪い。

除外語（MASK_WORDS）はサーバにしか無く、クライアントには渡していない。 どの社名を扱っているかがブラウザから読めてしまうため。 その分、プレビューで消えない固有名詞は利用者が手で書き換える導線に寄せている。

A は確認画面（モーダル）ではなく常時表示のパネルとする。 追加のクリックが 1 回でも増えると、デモの尺と NFR-P1 に影響するため。 A はマスキング関数を呼んで表示するだけなので実質ゼロリスク。 B は選択範囲の取得と置換が入るため、Day 4 が詰まった場合の削り対象になり得る。

ブースの想定問答は A だけで成立する文面にしておく（「伏せた内容を送信前に画面に出しているので、 送る前にご自身で確認できます」）。B が入った時点で「さらに、自分で追加で伏せることもできます」を足す。

絶対パスはユーザー名部だけでなく、プレフィックス全体を伏せる。

  Before:  at /Users/tanaka/projects/acme-corp/src/invoice.js:42
  After:   at <path>/invoice.js:42

ユーザー名部だけを置換する方式では、中間ディレクトリに残る顧客名・プロジェクト名が そのまま LLM へ送られる（例: acme-corp）。クライアント別のディレクトリ構成や モノレポでは珍しくなく、スタックトレースは本製品のコア入力であるため混入経路として最も確実になる。

強く伏せても診断精度は落ちない。 診断に効くのはエラーメッセージ・ファイル名・行番号であり、 ディレクトリ階層ではない。実装原則 #4（過剰にマスクしてよい）にそのまま沿う判断である。

「利用者が入力するテキスト」はすべて対象とする。 画面ごとの例外を作らない。

判断基準は「その入力が LLM に届くか」。 原因宣言と振り返りは自由記述であり、 マスキングを通さないと素通りする。

プレビューを出すのはエラー投稿画面のみ。 原因宣言は利用者が自分の言葉で書くため 混入リスクが構造的に低く、体験の山場にパネルを足すと煩雑になる。 マスキング自体はすべての入力に適用する。

正規表現では固有名詞を検出できない。 「Acme 社の決済 API」を機械的に特定する手段がないため。 ここを「自動で消せる」と書くと、反例を 1 つ出された時点で説明が崩れる。 できないことをできると書かない。

なお §2.5 / UC-10 の匿名化（実務セッション → 問題集への登録, FR-35）は 保存後の二次処理であり LLM を使えるため、本節とは別の手段が取れる。 こちらは v0.2 で、登録は draft から始め人の目視確認を必須とする（Q-13）。

除外語リストをクライアントに配ると、その語リストが閲覧可能になる。 v0.1 は招待制の限定公開のため許容するが、FR-41 の組織辞書は認証後にのみ取得する。

実装は packages/core/src/masking.ts（純関数）。フロントとサーバの両方が同じものを import する。

「マスキングしているから安全」とは書かない。 正規表現で検出できない形式の秘匿情報は残りうる。 利用者が判断できるよう、何をしていて、何を保証していないかを正直に書く。

公開 URL に無制限のサインアップを置かない。理由は 2 つある。

パスワードを平文で保存しない、Cookie を HttpOnly にする、といった基本は当然として、 この製品でいちばん守るべき資産は「ユーザーが貼り付けた業務コード」である。 認証の強度より、§2・§3 の入力の扱いの方が本質的に重要。

連打防止をフロントだけで実装すると、ボタンを押さずに直接 API を叩けば無効化できる。 サーバ側の冪等性がなければ、1 回の操作で LLM を何度でも呼ばせられる。

フロントの制御は UX、サーバの冪等性が防御。 両方を実装する。

カウンタはデータストアの既存アイテム内に持ち、 レート制限のためだけにアクセス枠を消費しない（turns.length などで判定できる）。

LLM の出力は信頼できない入力として扱う。 ユーザーが貼り付けたエラーテキストに <script> が含まれていれば、 LLM がそれを引用した文を生成しうる。

// ✗ LLM 出力をそのまま HTML として挿入
optionEl.innerHTML = option.label

// ✓ テキストとして挿入
optionEl.textContent = option.label

フレームワークを使わない構成（ADR-013）では、 React のような自動エスケープがない。ここは意識して守る必要がある。

正直に列挙する。やっていないことを「やった」と書かない。