Human-AI Interaction設計 — confidence、根拠表示、訂正、承認、undo等のAI特有UIを、能力限界・不確実性・可逆性・人間統制の観点から設計する。

AI業務UIでは、生成結果を表示できることと、利用者がAIの能力・限界を理解し、誤りを発見し、訂正・却下・承認・undoできることは別問題である。特にAgent/自動実行では、UI上の「承認」が何を承認するのか、実行後に何を戻せるのか、根拠表示が何を保証しないのかを明示しないと、automation bias・誤操作・過信を増幅し得る。

Enterprise AI Core: human oversight / interaction contract / recoverability / provenance UX。 Organization overlay: approval authority、role、risk tier、accessibility、training。 Governance: human factors monitoring、incident/recovery。 Implementation: UI state machine、action preview、correction/undo、evidence panel。

Q1. Human-AI UIは通常UIに加えて、AIの能力・不確実性・根拠・訂正・却下・承認・可逆性をfirst-class stateとして持つべきか。 Q2. confidence表示はいつ有用で、いつ誤った確信や数値の過大解釈を生むか。 Q3. Agentの承認/undoを「ボタンがある」ではなく、実際のside effect境界・rollback可能性まで含む契約として設計できるか。

• source class: primary research / author-maintained design guidance exact title: Guidelines for Human-AI Interaction / HAX Toolkit author/org: Microsoft Research / Microsoft canonical URL: https://www.microsoft.com/en-us/haxtoolkit/ai-guidelines/ publication/update/access: underlying CHI research 2019; toolkit accessed 2026-09-16 version: 18 Guidelines; current web toolkit evidence label: RESEARCH + VERIFIED_SPEC supporting locator: Guidelines 7-11; especially Support efficient dismissal, Support efficient correction, Scope services when in doubt, Make clear why the system did what it did relation: support established: human-AI interaction guidance explicitly treats AI failure/uncertainty as normal operating conditions and recommends invocation/dismissal/correction, graceful scoping when uncertain, and explanation access.

• source class: author-maintained implementation pattern exact title: Pattern 9C: Undo automated actions org: Microsoft HAX Toolkit canonical URL: https://www.microsoft.com/en-us/haxtoolkit/pattern/g9-c-undo-automated-actions/ access: 2026-09-16 version: current web pattern evidence label: VERIFIED_SPEC + OSS_PRACTICE-like design practice relation: support / limit supporting locator: Problem / Solution / Use when / Common pitfalls established: automated alteration should be communicated and reversible; repeated correction can become costlier than doing the task manually, so correction UX alone does not rescue a persistently poor AI feature.

• source class: author-maintained design guidance exact title: People + AI Guidebook org: Google PAIR canonical URL: https://pair.withgoogle.com/old-gb/ publication/access: published 2019-05-08; accessed 2026-09-16 version: six-chapter guidebook evidence label: RESEARCH + SOURCE_REPORT relation: support / limit supporting locator: Mental Models; Explainability + Trust; Feedback + Control; Errors + Graceful Failure established: human-centered AI design separates expectation setting, explainability/trust, feedback/control, and graceful failure; confidence presentation is a design decision rather than a universal requirement.

• source class: standards/risk framework exact title: Artificial Intelligence Risk Management Framework (AI RMF 1.0) author/org: NIST / Elham Tabassi canonical URL: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10 publication/access: 2023-01-26 / accessed 2026-09-16 version: NIST AI 100-1; revision process active as of 2026 label: VERIFIED_SPEC + PRODUCT_VOLATILE(for revision status) relation: context / governance supporting locator: Govern / Map / Measure / Manage framework scope established: trustworthy AI risk management covers design, development, deployment and use; current NIST page states AI RMF 1.0 is under revision, therefore future-book wording must pin framework version.

• source class: current NIST monitoring report exact title: Challenges to the Monitoring of Deployed AI Systems org: NIST canonical URL: https://www.nist.gov/news-events/news/2026/03/new-report-challenges-monitoring-deployed-ai-systems publication/update/access: 2026-03-09 / updated 2026-03-18 / accessed 2026-09-16 version: report/news surface current label: RESEARCH + SOURCE_REPORT relation: limit / context supporting locator: Human Factors Monitoring; highlighted gaps/barriers/open questions established: deployed-AI monitoring explicitly includes human-system interaction/transparency and notes insufficient research on human-AI feedback loops and burden/scaling of human-driven monitoring. Thus human oversight is not costless or automatically effective.

• AI UIの最小契約は「出力表示」ではなく、EXPECTATION / EVIDENCE / UNCERTAINTY / CORRECTION / DISMISSAL / APPROVAL / REVERSIBILITY / ESCALATION / FEEDBACKを別stateとして扱うべきである。
• confidenceは万能な真実確率ではない。model score、classifier probability、retrieval score、self-reported confidence、rule-based risk tierを同じ「信頼度%」へ潰さない。calibration evidenceがない生成AI自己申告値を正答確率として表示しない。
• 根拠表示は「なぜこの結果か」を理解・検証する補助であり、根拠が表示されたこと自体は正しさを保証しない。引用/evidence provenanceとmodel explanationを分離する。
• 訂正・dismiss・undoはAIが誤る前提のrecovery surfaceである。頻繁な訂正が必要ならUX改善だけでなくfeature disable / deterministic fallback / human-onlyへ戻す判断を含む。
• Agent承認は、提案内容、対象resource、権限、不可逆side effect、費用、実行時刻/expiry、承認後の変更有無を明示して初めて意味を持つ。承認後にpayload/tool targetが変化する場合は再承認が必要という設計をCore候補とする。

• confidence numberはcalibrationされていなければ過信を誘う。数値表示を一律推奨しない。
• explanationはtruth proofではない。もっともらしい説明やcitation UIが誤りを覆い隠す可能性を残す。
• human-in-the-loopは万能な安全策ではない。approval fatigue、automation bias、time pressure、専門知識不足、rubber-stampingがfailure modeになる。
• undoは外部送信、削除、決済、第三者API等で完全可逆とは限らない。「undo button」と「compensating action」を区別する。
• feedbackを収集できても、即座にmodel学習へ反映することは別のgovernance/privacy問題である。

製品固有UIはplan/surface/role/admin setting/region/rolloutに依存し得る。Coreは特定provider UIの存在を前提にせず、action riskとreversibilityから必要interactionを決める。実際のapproval/undo/citation/confidence surfaceは公開直前にprovider別再確認する。

PROPOSAL: HUMAN_AI_INTERACTION_CONTRACT。 最低fields: interaction_id; user/role; AI capability disclosed; input/context provenance; output artifact; evidence refs; uncertainty type/source/calibration status; proposed action diff; target resource; side-effect class; risk tier; approval requirement/approver; approval payload hash; expiry; execution receipt; correction/dismissal; undo/compensation capability; escalation route; feedback disposition; UI/version. Action state machine候補: DRAFT → REVIEWABLE → APPROVAL_REQUIRED → APPROVED(payload hash固定) → EXECUTING → COMMITTED → REVERSED/COMPENSATED/ESCALATED。payload/target/permissionが承認後変化した場合はAPPROVAL_REQUIREDへ戻す。

TEST_PROFILE（未実施）: 正答、部分誤り、根拠不一致、高/低不確実性、誤った高confidence、irreversible action、approval payload変更、undo可能/不可能、連続approval fatigueを含むfixtureを作る。評価: task completion、error detection rate、unsafe approval rate、correction time、recovery success、false confidence reliance、citation verification、approval fatigue、accessibility、user comprehension。UI A/Bだけで安全性を断定せず、risk-tier別に測る。

Security: approvalはauthorizationの代替ではない。tool/API側least privilegeを維持。 Privacy: explanation/feedback UIに秘密情報や不要なchain-of-thoughtを露出しない。必要なのはevidence/provenanceとdecision-relevant rationale。 Audit: proposed payloadとapproved payload hash、executor、result、rollback/compensationを記録。 Cost/Operability: human review時間・訂正時間・approval latencyをAI運用原価/SLOへ含める。human oversightを無料capacityとして扱わない。

「AI特有のUIでは、結果を見せるだけでなく、何ができるか・何を根拠にしたか・どこに不確実性があるか・誤ったときにどう訂正/却下/復旧できるかを設計する。confidenceは正答確率とは限らず、根拠表示も正しさの保証ではない。外部作用を伴うAgentでは、承認対象を固定し、実行後のundoまたは補償手段まで含めて人間統制を設計する。」

• EA-098をEA-015監査証跡、EA-016 Evals、EA-092 BCP、EA-094 SLOと接続する。
• provider mapping時はChatGPT/Gemini/Copilot/Claude等のapproval、citation/evidence、confidence/uncertainty、undo/history、feedback surfaceをas-of付きで別採集する。
• approval payload hash、reversibility class、human-review costをCore schema候補として検討する。
• HAX/PAIRは設計研究・実践ガイドとして使用し、法的適合や製品保証へ外挿しない。

/ STOP_CONDITION

生成AIconfidence UIのtask別最適提示方式、cross-provider current approval/undo surface、実組織でのapproval fatigue閾値、risk-tier別human review capacity、NIST AI RMF改訂版の確定内容。

HAX/PAIR/NISTの基礎根拠、counterevidence、Core contract、未実施TEST_PROFILEまで揃ったためEA-098の初回bounded packetは完了。公開後Workではcurrent provider UIとNIST改訂版のみ再pinし、tenant固有値は実測する。

---