Shuichiro Ogawa
English

Notes ・ updated 2026-08-07

概要

本ノートの問いは、「シナリオベースでシステム設計を学べるサービスはあるか」である。 分析枠には Goal-Based Scenario（GBS。Schank らの学習環境設計フレームワーク）の7要素（learning goals、mission、cover story、role、scenario operations、resources、feedback）を使う。 理論と学術文献の側は goal-based-scenario が扱っており、本ノートはその産業側の対になる。 ベンダー公式と第三者の2系統で 28 データ点を収集した（台帳は source/review/system-design-scenario-learning/industry.md）。 7要素への照合は本ノートの分析であり、各サービスの自称ではない。

結論を先に言うと、シナリオ（物語、役割、ミッション、フィードバック）を備えた学習サービスは産業に多数あるが、「システム設計」そのものを scenario operations（学習者の中心活動）にするものは少ない。 多くのサービスの操作は運用（構築作業、インシデント対応）であり、設計判断を操作にするのは Architectural Katas と AWS SimuLearn を筆頭に一握りである。 また GBS の7要素のうち resources（専門家の経験談を必要になった瞬間に提供する）を実装したサービスは見つからなかった。

設計を操作にするシナリオ演習

設計判断そのものを学習者の活動にする演習は、以下で確認できた。

Architectural Katas（Ted Neward 創案、Neal Ford が整備）が最も完全な形である。 架空顧客の曖昧な要件（例として「サンドイッチチェーンがオンライン注文システムを欲しがっている」）をチーム 3〜5 名のアーキテクト役が受け取り、顧客役を演じるモデレーターに質問して要件を詰め、アーキテクチャを設計して発表し、他チームの批評と投票を受ける。 Neward は創案の動機を「アーキテクトはキャリアで数回しか設計の機会を得られない。練習の場が要る」と述べており、これは GBS が前提にする learning by doing の問題意識と一致する。 無料で自己主催でき、O’Reilly の競技イベント版では審査員（Neal Ford、Mark Richards ら）のフィードバックが付く。

AWS SimuLearn は、生成 AI が演じる仮想顧客と対話して要件を聞き出し、アーキテクチャを提案する演習である。 対話に連動してアーキテクチャ図がリアルタイム更新され、技術的正確性に加えてコミュニケーションと顧客フォーカスまで多軸で評価される。 「要件収集から提案まで」という設計の前半工程を操作にしている点で、構築ラボとは質が違う。 一部の学習プランは無料で常時利用できる。

AWS Cloud Quest は 3D 仮想都市の市民の課題を解決する RPG で、各クエストが Learn、Plan、Practice、DIY の 4 段階を持つ。 Plan 段階でアーキテクチャ設計を行うため、設計要素は含むが、中心は後続の構築である。 Microsoft Learn の Challenge project 形式は、顧客を選んで planning workbook に沿ってアーキテクチャ分析と設計文書を作る点で設計演習だが、評価はクイズ合否にとどまる。

運用を操作にするシナリオ演習

シナリオ構造が最も豊かなのは、実は設計ではなく運用の演習である。

AWS GameDay は架空企業 Unicorn.Rentals（世界最大の神話生物レンタル会社）を舞台に、崩壊した経営陣が残した断片的なドキュメントだけを手掛かりに、新入社員としてシステムを安定化させるチーム対抗演習である。 リアルタイムのリーダーボードと、ベストプラクティス未達への減点がフィードバックを与える。 ただしイベント限定開催で、常時使える教材ではない。

KodeKloud Engineer は架空企業 xFusion Corp Industries の SysAdmin として採用され、チケットシステムからタスクを受けて解決する無料のロールプレイ型プラットフォームである。 物語、役割、ミッション、自動判定が揃うが、タスクは既定インフラ上の操作であり、設計判断は含まれない。

Google SRE の Wheel of Misfortune は、実際の過去インシデントを再演するロールプレイで、GM がシナリオを提示し、オンコール役が診断と緩和を口頭で進め、GM がリアルタイムで応答を返す。 過去の実インシデント（postmortem）を教材にする点は、GBS の理論的基盤であるケースベース推論（専門家のケースから学ぶ）に産業実践が独立に到達した形として読める。 商用では Uptime Labs が、AI が演じるステークホルダー（CEO、CTO、CS）から圧力を受けながらインシデントマネージャー役を務めるシミュレーターを提供し、40 以上のメトリクスでスキルギャップを分析する。 PagerDuty は内部のインシデント対応訓練（6 役の役割体系、実インシデントの再現録音）を無料公開している。 セキュリティ分野では TryHackMe SOC Simulator と Hack The Box が架空組織の物語と役割を備えており、シナリオ設計の参考事例になる。

カバーストーリーの産業定着

架空企業という装置は、3 大ベンダーの演習教材に定着している。 AWS は Unicorn.Rentals、Google Cloud は Cymbal シリーズ（Cymbal Bank は国立リテール銀行という設定で、Challenge Lab は「Cymbal Bank のクラウドエンジニア」という役割を学習者に与える）、Microsoft は Contoso を使い、Applied Skills のラボでは上司や顧客からの依頼を模したメール受信インターフェースでタスクが届く。 つまり cover story と role は、産業の学習設計で標準装備になっている。 一方でこれらの物語は動機づけと文脈付与のためにあり、GBS が理論的に要求する「期待の失敗（expectation failure）が学習を駆動する」設計とは接続されていない。

例外的に、Cloud Resume Challenge（Forrest Brazeal）は物語を持たないが、「指示を意図的に不足させ、学習者が夜中に調べ物の穴に落ちるように設計した」と創案者が明言しており、期待の失敗を意図的に組み込んだミッション駆動設計として GBS 的に最も興味深い。 フィードバックも自動採点ではなく、完了者への本人によるコードレビューとコミュニティのピアレビューである。 この「意図的な失敗の学習設計」の系譜（学習科学の理論と産業実装）は failure-driven-learning で別途整理した。

GBS 7要素での照合

主要サービスを7要素に照らすと次のようになる（○=確認、△=部分的、−=なし。learning goals は全サービスが暗黙に持つため列から省いた）。

サービスmissioncover storyrole操作=設計かresourcesfeedback
Architectural Katas○○○○−（モデレーターへの質問のみ）○ ピア批評＋投票
AWS SimuLearn○○○○（要件→提案）△（ガイド付きラボ）○ 多軸リアルタイム
AWS Cloud Quest○○○△（Plan 段階のみ）△（Learn 段階の動画）○ 自動検証＋バッジ
AWS GameDay○○○△（運用中心）−○ リーダーボード＋減点
Cymbal Challenge Lab○○○−（構築）−○ 自動採点
MS Applied Skills○○○−（設定）−○ 自動採点
KodeKloud Engineer○○○−（運用）−○ 自動判定
Wheel of Misfortune○△（実事例）○−（対応）△（postmortem＝実ケース）○ GM の即時応答
Cloud Resume Challenge○−−△（構成選定）−○ 人間レビュー
Uptime Labs○○○−（対応）−○ 多軸レポート

この照合から2つの構造的欠落が見える。 第一に、設計と物語の組み合わせが希少である。 物語と役割が豊かなサービス（GameDay、KodeKloud Engineer、Cymbal）ほど操作は運用と構築に寄り、設計を操作にするサービス（Katas、SimuLearn）は物語装置が比較的簡素である。 両方を備えるのは SimuLearn がほぼ唯一で、それも仮想顧客との対話という一場面に限られる。

第二に、resources の不在である。 GBS は「専門家の経験談（ストーリー）を、学習者が失敗して必要とした瞬間に提供する」ことを要素として要求するが、これを実装したサービスは確認できなかった。 最も近いのは Wheel of Misfortune が実インシデントの postmortem を教材化する形だが、これは事前に GM が語る筋書きであり、失敗の文脈での just-in-time 提供ではない。 各サービスのフィードバックは自動採点（合否、減点、リーダーボード）が主流で、GBS が求める「失敗の文脈でのコーチングと類似事例の提示」は、SimuLearn の多軸評価と GM 形式の人間対応が部分的に担うにとどまる。

学生教育への含意

学生にシステム設計をシナリオベースで学ばせるという目的に対しては、既製サービスを1つ選ぶより、GBS の7要素を設計チェックリストにして組み合わせる方が現実的である。 設計を操作にする核としては Architectural Katas が無料で自己主催でき、教員がモデレーター（顧客役）を務めれば cover story と role の付与も要件の質疑もその場で調整できる。 AI 対話型の要件収集は SimuLearn の無料プランで補え、欠けている resources 要素は、教員が実務の事例（公開されている障害報告や設計文書）を「失敗した瞬間に出す」運用で自作することになる。 この組み立ての妥当性を効果の面で確かめたければ、GBS の実証研究の現状（準実験に偏り、メタ分析未確定）を goal-based-scenario で確認した上で設計するのがよい。 正しい設計の参照とレビューの道具は system-design-learning-tools-industry、構成の帰結を見せるシミュレータは system-architecture-simulation-learning-industry が扱っている。

空白（未充足の論点）

  • 「システム設計を scenario operations とし、物語と役割を備え、専門家ストーリーを just-in-time で提供する」GBS の完全実装に相当するサービスは未発見である。
  • Architectural Katas の学習効果を検証した調査は見つからなかった（形式の記述と創案者の意図のみ）。
  • ベンダー演習（GameDay、Cloud Quest、SimuLearn）の教育機関向け提供条件は公式ページから確認できなかった。
  • 各サービスが GBS などの学習理論を参照して設計されたかどうかの一次証言は得られていない。物語・役割・ミッションの装備は理論と独立の産業的収斂とみるのが現状の証拠に合う。
  • シナリオ型演習の教育効果を示す独立調査は存在しない。効果検証は goal-based-scenario の学術系統の領分である。

参照文献

すべて 2026-08-07 アクセス。台帳の詳細（方法論、ポジション判定、要一次検証の全項目）は source/review/system-design-scenario-learning/industry.md を参照。GBS の7要素の学術的根拠（Schank, Berman & Macpherson 1999 ほか）は goal-based-scenario の参照文献を正とする。

ベンダー公式（T1v）

第三者（T3）

← Notes 一覧 ・ ホーム