AWS re:Invent 2025に参加してきました。参加したセッションのレポートをまとめていきます。
Accelerate trusted AI development with AWS responsible AI practices
なぜ責任あるAI（responsible AI）が必要なのか
超高層ビルの設計において、強固な基礎や安全システムが建物の高さを支えるように、AIにおいても責任あるAIのプラクティスはイノベーションを阻害するものではなく、自信を持って開発を進めるためのガードレールとなる。
AI開発環境の変化
- ユースケースと技術の増加: ユースケースが増え、基盤モデルやエージェント技術などの選択肢が広がっている
- 規制の強化: EU AI法、コロラド州やカリフォルニア州の規制、ISO 42001など、開発者が準拠すべき基準が増加している
従来のソフトウェア開発とAI/ML開発の違い
| 特徴 | 従来のソフトウェア | AI/MLソフトウェア |
|---|---|---|
| ロジック | Rule-basedなロジック | データ内の相関関係を用いた統計的推論 |
| 入力 | 人間が理解できるコード言語 | 人間が言葉で表現できない相関関係を含むデータセット |
| テスト | リリース時に動作が保証される | データの分布に対する仮定に基づくため、継続的なテストが必要 |
| パフォーマンス | 全入力に対し一貫して動作 | データセットに依存し、特定の指標が改善しても他が悪化する可能性がある |
| 説明可能性 | 出力に対する説明は通常1つ | 複数の説明が存在し得る |
AWSのフレームワークの概要
-
設計原則
-
主要な決定事項を、「検討すべき質問」として定義
-
「推奨事項」ではなく、「実装上の考慮事項」を提供
- 解決策はユースケースに依存するため
-
コンプライアンスのチェックリストではなく、リスク特定と考慮を促すもの
-
-
構造
- 8つの重点分野、28個の質問、100以上のベストプラクティスで構成
- AWS Well-Architected Tool内の「Responsible AI Lens」として利用可能
- ワークロードに応じたレポートの出力が可能
- 包括的なホワイトペーパーとしても提供されている
開発ライフサイクルの3段階
- 利点とリスクの特定: 顧客へのメリットと潜在的なリストを特定
- リリース基準と開発: システムの目標設定、データセット構築、システム設計、評価
- デプロイと運用: ユーザーガイダンス、透明性レポート、継続的なモニタリング
ケーススタディ: 不動産物件説明生成AI
架空のビジネスオーナー「Sam」が、不動産物件の説明文を自動生成するGenerative AIシステムを構築する過程を通じて、フレームワークの適用方法を解説。
課題と背景
- 目標: 低品質で一貫性のない物件説明を改善して、ユーザー体験を向上させる
- リスク: 公正住宅政策（Fair Housing Policy）への違反により、訴訟や評判の低下、罰金のリスクがある
- 差別的表現や虚偽の記載など
重要なdecision point
-
リスク評価の実施
- 手法: 有害事象を特定して、「発生確率」と「重大度」のマトリクスを用いて、リスクレベルを決定
- 例: 身体障害者向けアクセシビリティに関する不正確な情報を、重大リスク（policy違反）と判断
-
リスクの発見方法
- 各リスクをシステムの文脈（公平性、プライバシーなど）に合わせて具体的に検討し、組織内で認識を合わせる
-
リリース基準の設定
- 問題: 単に「平均パフォーマンスが良い」だけではリリース基準として不十分
- 解決策
- 多角的な指標: 正確性だけではなく、ハルシネーション率、堅牢性などを測定
- LLM as a judge: LLMを審査員として使いつつ、人間による検証も組み合わせる
- 統計的アプローチ: スコアを二項分布（合格/不合格）に変換して、「信頼区間（Confidence Interval）」を用いて評価
- e.g. 「ハルシネーション率が0.1%以下であることに95%の自信がある」という状態を目指す
-
評価用データセットの構築
- 失敗例: 既存の物件データをそのままAIで評価・フィルタリングして学習データにした結果、個人情報（PII）の漏洩や、有用なデータの欠落が発生した
- 教訓:
- 品質保証のための「人間による評価（Human Evaluation）」が不可欠
- 統計的な検出力を確保するために、十分なデータセットサイズが必要
-
プライバシーと設計戦略
- PIIが混合した場合、以下の3つの設計戦略で対処:
- Baking: 最小権限の法則に基づき、そもそも不要なPIIを入力しないようにシステムを制限・設計する
- Filtering: PII除去フィルターや、Human-in-the-loopによって入出力をブロックする
- Guiding: システムのリスクや限界を説明し、ユーザーへの透明性を担保する
- PIIへのアクセスを制限する（データ段階での対処）ことが第一歩
- PIIが混合した場合、以下の3つの設計戦略で対処:
-
基準を満たせない場合での対応
-
特定の基準（e.g. ハルシネーション率）を満たせない場合、安易に基準を下げるべきではない
- プロセスを遡る
- 評価データは十分か？
- 設計や緩和策（ガードレールなど）を追加できないか？
- ユースケースのスコープを狭める必要はないか？
- プロセスを遡る
-
トレードオフの考慮: ガードレールを強化しすぎてブロック率が高まると、ユーザー体験が悪化するので、バランスが必要
-
結論
- 明示的な意思決定: Lensを使用して決定を明確に行う
- 初期段階からの適用: 開発の後工程で修正するより、初期段階でリスクに対処する方が効率的
- 反復的なプロセス: 開発中に新しいリスクが見つかった場合、前の行程（リスク評価やデータ計画）に戻って修正を行う