FLECT-DEV-TEAM / FLECT-DEV-TEAM/codex-realtime-voice-agent
U2: フォールバック言語 (ko/zh/es/fr/de) yes/no 判定の網羅性ハードニング
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## 背景
i18n 実装の Phase 1 で `decision.ts` の `auto` 経路に ko/zh/es/fr/de の **最小 yes/no トークン**マッチャを導入した(spec R-D7)。安全側設計(非対称マッチ: refuse は寛容・accept は保守的)で第一段階の安全性は確保したが、トークン表は最小限のため正当な yes/no 表現の多くが `null`(model 経路)に落ちる UX の限界がある。
「まずは許容しないと進められない」「ハードニングは今後の残課題」として spec v3 で確定(2026-05-19)。本 Issue でその継続トラッキングと段階的実施を管理する。
## 現状の限界(主な事象)
1. **表外の自然な承認/拒否が再確認ループに**: ko 「알겠습니다」/「좋습니다」, zh 「没问题」/「行」, es 「claro」/「por supuesto」, fr 「ouais」/「bien sûr」, de 「klar」/「sicher」 等の自然表現が `null` 扱い → 再 prompt
2. **フォールバック言語の質問判定が ja/en 規則のまま**: `?` がない場合に固有文法手がかり(ko `요?`/`까?`, zh `吗`, es `¿…?`, de `kann ich` 等)を拾えない
3. **承認 prompt が英語で発話される**: `autoStrings = enStrings spread` 設計のため、会話言語=es でも prompt は英語(spec の Non-Goal「ko/zh/es/fr/de の完全 prompt 対応」に基づき意図的)
4. **ja の broad negation で over-refuse**: 「問題ない」「構わない」「間違いない」等が refuse 化(spec R-D5 安全側設計として意図的に許容)
## 段階的アプローチ(Stage 0-3)
### Stage 0: 判定結果のログ収集メトリクス追加(データなしでも先行可)
ハードニングの意思決定基盤として、判定結果を構造化ログに残し、null 率・refuse 率・clarification 回数を計測可能にする。
→ サブイシュー(下記 task list 参照)
### Stage 1: トークン表の網羅性向上(Stage 0 データ蓄積後)
実利用ログから ko/zh/es/fr/de で頻出する yes/no 表現を抽出し、`decision.ts` のトークン表を拡張。各拡張に対して `decision.test.ts` に表駆動テストを追加。安全性原則(refuse 寛容・accept ko/zh 全文一致・es/fr/de 単語境界+短文)は維持。
### Stage 2: フォールバック言語の質問判定拡張(必要に応じて)
`isUserQuestion()` を言語別に拡張: ko の文末 `요?`/`까?`、zh の `吗`/`呢`、es の `¿`、fr の倒置、de の `kann ich`/`darf ich` 等。spec R-D8(質問判定は yes/no より優先)の原則は維持。
### Stage 3: 承認 prompt のフォールバック言語サポート(要件次第・spec 改訂必要)
`voice-strings.ts` に ko/zh/es/fr/de 専用束を追加。各束(instructions/spokenInput/outcomes/summarize)を人手翻訳。**spec の Non-Goal「`ko/zh/es/fr/de` の完全プロンプト対応」を撤回することになるため `/feature-revise` で spec 改訂が必要**。
## 実施判断(フローチャート)
```
リリース → 実利用ログ収集 (Stage 0)
↓
判定 null 率 / refuse 率 / clarification 回数 を測定
↓
特定言語で問題顕在化?
├ No → 何もしない (現状で十分)
└ Yes → どのレベル?
├ 軽い (取りこぼし数件) → Stage 1 のみ
├ 中 (質問認識ミス含む) → Stage 1+2
├ 大 (承認 prompt の言語不整合) → Stage 1+2+3 (spec 改訂)
└ 極大 (架構限界) → 言語別 matcher 昇格を別 Issue 化
```
## 安全性原則(継続維持・絶対)
ハードニング作業全体を通じて以下を絶対維持:
- accept の非対称マッチ規律: ko/zh は全文一致のみ、es/fr/de は単語境界+短文 gate
- bare 単一 CJK/Hangul 文字の部分一致 accept は禁止(spec R-D5 — 誤 accept は実行承認に直結)
- refuse は部分一致+否定優先(安全側に倒れる)
- 判定不能は `null` → model clarification(安全側)
## 参照
- spec: `tasks/feature-plans/2026-05-19-i18n-localization.spec.md`(Non-Goal, R-D5, R-D7, R-D8)
- ローカル follow-up planning doc(gitignore 配下): `tasks/feature-plans/2026-05-19-i18n-fallback-yesno-hardening.followup.md`
- 関連 Issue: #2 (U5 実機検証・完了)
- 関連実装: `server/src/i18n/decision.ts`, `server/src/i18n/voice-strings.ts`
## サブイシュー
- [ ] #4 Stage 0: decision.ts 判定結果のログ収集メトリクス追加
Contributor guide
No contributing guide indexed for this repository
Research direction
Start with sub-issue #4 and read server/src/i18n/decision.ts, the referenced spec, and the follow-up planning document. Measure null rates, refuse rates, and clarification counts before deciding whether to extend decision.ts and its tests, expand isUserQuestion(), or revise the prompt requirements. Done is determined by the observed language-specific impact and the applicable Stage 0–3 scope.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- internationalization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100