Amazon Bedrockで実現する新たな学習体験
〜AtamaPLUSが示すAI教育アプリの本番運用実践知〜
講演者
前田氏（AtamaPLUS）
VPoE・技術部署責任者
企業情報
EdTechスタートアップ（8期目）
AI教材「atama+」提供
講演概要
EdTechスタートアップのAtamaPLUSが開発・運用する「AIステップ解説」機能について、 開発から本番環境での運用まで、実践的な知見が包括的に紹介された講演です。 生成AIアプリケーションを「作る」ことから「安全に提供し続ける」ことへのフォーカスシフトを通じて、 教育ドメイン特有の課題解決と、他業界にも応用可能な本番運用のベストプラクティスが語られました。
講演の特徴: RAGやエージェント等のトレンド技術よりも、 実際にユーザーが使うアプリケーションの運用面での「泥臭い工夫」に焦点を当てた実践的内容
生成AI時代における教育業界の危機感と機会
AtamaPLUSの事業背景
企業概要
ミッション
「教育に 人に 社会に 次の可能性を」
事業内容
- • AI教材「atama+」を全国の塾・予備校に提供
- • 自社塾運営
- • 創業8期目のEdTechスタートアップ
技術特徴
一人一人の学習データから得意・苦手を分析し、カリキュラムをパーソナライズ
これまでの挑戦
- • 河合塾との模試オンライン受験システム
- • 大学入試方式変革プロダクト
- • 教育業界での継続的技術革新
2022年末の転換点：ChatGPT登場による危機感
スタートアップとしての危機感
「破壊的イノベーションが世の中をどんどん変えていこうとしている中で、スタートアップとしては、 そのトレンドに乗らないと、最悪死んでしまうということが全然考えられる」
認識した変化
- • 技術的・社会的特異点の発生
- • あらゆる業界のディスラプション
- • 教育業界への大きな影響予測
教育特有の課題
- • 生成AIの確率的挙動への疑問
- • 教育との親和性検証必要
- • 真の価値提供内容の模索
対応の困難さ
- • 「ラフに手を出す」ことの危険性
- • 何かやらねばという焦燥感
- • 約1年間の試行錯誤期間
AIステップ解説：教育課題に特化したAI活用
学習における根本課題の発見
従来の学習体験の限界
基本的な学習サイクル
問題を解く
→解説を読む
→繰り返し
解説理解の課題
- • 式変形過程の省略
- • 突然出現する公式
- • 使用理由の不明確さ
学習への影響
- • 本質的理解の欠如
- • 知識の抜け落ち
- • 学力向上の阻害
生成AIとの親和性
- • 個別最適化解説
- • 理解度に応じた詳細化
- • 躓きポイントの特定
生成AIとの親和性発見
「解説っていうものをもっと親切に、その生徒さんがどこで詰まっているのかっていうのも含めて、 理解度に合わせて、個別最適化して提供できないか」
AIステップ解説の機能設計
基本アプローチ
- • ChatGPT風のフリー質問機能ではなく、解説の詳細化に特化
- • 学習コンテンツデータをコンテキストとして活用
- • ユーザーの「自分が何を分からないか」の言語化コスト極小化
システム動作フロー
1
チャンク分割
解説文を意味のある塊に自動分割
2
段階的提示
チャンクごとに理解確認を実施
3
適応的詳細化
理解状況に応じて追加解説を生成
4
選択肢提示
予想される躓きポイントに対応した選択肢提供
ユーザー体験
ワンタップ詳細化個別最適化シームレス体験
2か月強での高速開発アプローチ
組織的工夫
有志チーム編成
- • メイン業務と並行開発
- • 少数精鋭による機動力
- • 組織承認プロセス回避
価値検証重視
PR/FAQ手法活用
- • 開発前の価値明確化
- • プレスリリース・FAQ事前作成
- • 早期ユーザーヒアリング
アーキテクチャ工夫
シンプル・独立設計
- • 既存APIサーバー非依存
- • 別コンポーネント切り出し
- • クライアント側データ渡し
Amazon Bedrock選定理由
統一API
複数基盤モデル（Claude、Nova等）の統一アクセス
AWS連携
IAMロール経由でのクレデンシャル不要接続
運用機能
ロギング、推論監視等の非機能要件充実
本番運用における3つの技術的工夫
1コスト課題の解決
変動費構造リスクの認識
「生成アプリケーションってめちゃくちゃ変動費構造。使えば使うほどトークンコストを消費していって、 原価が圧迫されて、最悪赤字構造になる」
サービス事業者のジレンマ
開発側: たくさん使って欲しい
事業側: 使われるほど困る（コスト圧迫）
プロンプトキャッシングによる解決
実装概要
- • 実装時期: 2024年4月
- • TTL: 5分間キャッシュ
- • 対象: システムプロンプト部分
- • 効果: 約70%コスト削減
技術詳細
システムプロンプト（キャッシュ対象）
├─ 問題データ（固定）
├─ 解説データ（固定）
└─ 指示内容（固定）
ユーザープロンプト（都度課金）
└─ ユーザーとの実際のやり取り
2運用課題：LLM as a Judge活用
モデル変更頻度の高まり
更新頻度: 月1回ペースでの新基盤モデルリリース
Claude 3.5 Sonnet v2 → Amazon Nova → Claude 3.5 Sonnet → Claude 4 等
LLM as a Judge実装
技術選択
- • Amazon Bedrock Evaluationsではなく
- • LangChainのOSS「OpenEvals」を使用
- • 実際のユーザーやり取りデータ活用
評価プロセス
1
データセット準備2
モデル比較実行3
自動評価・判定3可観測性：アプリケーションレイヤー監視
生成AIアプリケーションの特性
- • 機械学習アプリケーションの進化系
- • 通常のロジカルアプリケーションより振る舞いの安定性が低い
- • 確率的挙動によるセッションごとの監視必要性
Amazon Bedrockログの限界
- • Bedrock ↔ Claude間のログのみ
- • アプリケーションレイヤーのメタデータ付与困難
- • セッション特定等の詳細分析に制約
Datadog LLM Observability
- • 既存監視基盤との統合
- • 関数wrap/デコレーターでの簡単計装
- • ユーザーセッション識別情報追加
- • レイテンシ・コスト・トークン一元管理
教育ドメイン特有の品質保証
教育サービスとしての責任
「教育サービスとして生徒さんに提供するという上で、外せない責任があります。 学術的に正しい回答を生成して、提供しないと、よく分からない回答を解説を得られて、 生徒さんを混乱させてしまうというリスクがある」
AIプロダクト品質保証ガイドライン活用
参考基準
AIプロダクト品質保証コンソーシアムのガイドライン
重点評価軸
- • 回答性能・事実性: 教育コンテンツの正確性重視
- • 誠実性: 生徒への適切な学習支援確保
- • セキュリティリスク: 自由入力なしで低リスク
ユーザーフィードバック収集
解決率モニタリング
- • 解説終了時の2択アンケート
- • 「理解できたかどうか」の継続収集
- • 解決率75%のKPI設定・定期監視
改善サイクル
機能利用 → 理解度FB → 定期分析 → プロンプト改善
ドメインエキスパート検査体制
社内リソース活用
- • AtamaPLUS社内の学術エキスパート活用
- • コンテンツ制作チームの専門知識利用
- • 怪しい回答発見時のプロンプト調整プロセス
専用ツール開発
- • ユーザーやり取り内容参照UI開発
- • ドメインエキスパートによるレビュー環境
- • 安全なレビュー環境（個人情報非含有）
実現可能性の条件
自由入力なし個人情報非含有セッション構造化
AWS Generative AI Innovation Centerとの協業
支援プログラムの概要
プログラム特徴
- • 生成AIアプリケーション本番運用特化支援
- • AWS内の専門家による直接支援
- • 実践的な開発支援（理論ではなく実装レベル）
支援内容の実践性
「実際に今こんな開発してるんですよねっていうのを、コードを渡して、プロンプト渡して、 実際のデータも渡して、それをもとに専門家の方からアドバイスをいただける」
1. 回答品質向上支援
課題
数学の増減表で上に凸・下に凸を必ず逆にする事象
支援内容
実際のプロンプト・データのスペシャリストレビュー
結果
具体的改善提案の実装・品質向上実現
2. コスト削減アーキテクチャ支援
課題
変動費コストによる事業リスク
支援内容
アーキテクチャ大幅改善提案・キャッシュ活用戦略
提案
固定費構造割合増加によるコスト構造改善
現状: 開発体制確保できず未実装（但し実装価値の高い提案を受領）
組織のAI活用戦略への応用ポイント
生成AI導入の段階的アプローチ
Phase別実装ロードマップ
1
価値仮説の明確化
- • ドメイン特有課題の特定
- • 生成AIとの親和性検証
- • PR/FAQ手法による価値明文化
2
高速プロトタイピング
- • 有志チーム編成による機動力
- • 既存システム依存度最小化
- • マネージドサービス活用
3
本番運用設計
- • 変動費コスト構造検討
- • 品質保証プロセス組み込み
- • 可観測性・監視体制整備
ドメイン特有要件への対応指針
教育業界の示唆
- • 正確性重視: 学術的正確性の外部検証体制
- • 安全性確保: 自由入力制限による予測可能性向上
- • 継続改善: ユーザーフィードバック収集・KPI設定
他業界への応用
- • 医療: 診断支援での正確性・専門家検証
- • 金融: 投資助言での法的適合性・専門家監修
- • 法務: 契約書分析での法的正確性・弁護士監修
技術選択の実践的考慮事項
Amazon Bedrock選択要因
- 1. 開発効率: 統一API・認証周り整備済み
- 2. 運用負荷: ログ取得・監視機能標準装備
- 3. コスト管理: プロンプトキャッシング等の最適化機能
- 4. 専門支援: AWS Innovation Center連携
運用監視の重要性
- • アプリケーションレイヤーでの独自監視実装
- • LLM as a Judgeによるモデル変更自動化
- • ドメインエキスパートとエンジニアの協業体制
まとめ：AI教育アプリ開発・運用の実践知
前田氏が示すAI実装の現実解
1. 「作る」から「提供し続ける」へのシフト
「生成AIのアプリケーションを作って、世の中に公開して使ってもらうみたいなことは、かなりスピーディにできる時代。 ただ、生成AIってかなり確率的な振る舞いをするので、これをそのままユーザーに使ってもらって大丈夫なんだろうか」
2. ドメイン事業者としての責任
- • 技術的可能性と事業的責任のバランス
- • ユーザー価値提供への徹底的こだわり
- • 段階的品質保証プロセスの構築
3. 実践的工夫の積み重ね
- • トレンド技術追求より運用課題解決重視
- • 「泥臭い工夫」による安定サービス提供
- • 継続的改善サイクルの仕組み化
AtamaPLUSの成果と今後展望
定量的成果
- • 2か月強での開発・リリース実現
- • 約70%のコスト削減（プロンプトキャッシング活用）
- • 解決率75%のKPI達成・継続監視
今後の展望
「この技術によって、やっぱりこれって教育の世界をめちゃくちゃ変えるポテンシャルがある技術だなっていうのを確信した」
「教育に 人に 社会に 次の可能性を」の世界実現への継続的挑戦
AI実装成功の要因・持続可能なAI事業の要件
成功要因
- 1. 明確な価値仮説: ドメイン課題×AI親和性の的確な見極め
- 2. 高速検証: 有志チーム・シンプル設計による迅速価値検証
- 3. 本番考慮: コスト・品質・監視の事前設計と継続改善
- 4. 専門支援: ベンダー支援プログラムの積極活用
持続可能性要件
- • 変動費コスト構造への早期対応
- • ドメイン専門家との協業体制構築
- • ユーザーフィードバック収集・分析の仕組み化
- • 技術進化に対応した継続的運用改善
「技術的可能性の追求と事業的責任の両立こそが、
真に価値あるAIサービスを生み出す鍵である」