生成AIの開発ツールで学習管理システムを作ったものの、受講申込から修了判定までの運用条件は別に確認する必要がありました。バイオファウンドリ人材育成LMS M社で、実際の動作を基準に抜けた要件と例外経路を検証した事例です。
受講画面があり、申込ボタンは動きます。学習した内容が表示され、修了の可否も示されます。必要な機能は作られました。この状態で教育課程を運用してもよいのでしょうか。
バイオファウンドリ人材育成課程のためのLMS M社は、生成AIツールで構築したシステムでした。依頼した機能は実行できましたが、明示していなかった条件や例外がどこまで反映されているかは、整理されていない状態でした。
2026年に行った検証では、コードが作られた方法よりも、実際の教育業務の結果を基準にしました。「機能がある」と「必要な条件で正しく動作する」を区別することが出発点でした。
コードへの印象ではなく、実行結果を基準にしました
AIが書いたコードだというだけの理由で、成果物を低く評価する必要はありません。逆に、コードを速く作れたという事実が運用の準備を証明してくれるわけでもありません。
着手前に検証基準を合意しました。コードのスタイルや書き方を評価するのではなく、システムを実行して確認した動作で判断することにしました。
このアプローチは、責任をコードからユーザー体験へ移すことでもあります。内部の実装がどのような形であれ、教育の運用担当者が必要とする条件を満たさなければなりません。コードに処理する文があるという説明よりも、その条件で実際にどのような結果が出るかが重要でした。
生成AIの開発ツールを活用したシステムを検証するときも、この基準は同じです。ツールが何を作ったかよりも、組織が何を運用しようとしているかを先に説明できなければなりません。
受講申込から修了まで、一つのフローとしてまとめました
重要な検証フローは、受講申込、進度認定、修了判定でした。それぞれの画面だけを確認するのではなく、学習者が教育課程に参加して結果を得るフローとして見ました。
この3つの段階は互いにつながっています。申し込んだ利用者が誰か、どの学習が進度として認められるか、その結果が修了条件にどうつながるかによって、運用の結果が変わります。
たとえば、進度が画面に表示されているという事実だけで、修了判定も正しいとは言えません。表示された進度と修了を判断する条件が同じ基準に従っているかは、別に確認する必要があります。これは特定の不具合を見つけたという意味ではなく、機能一覧だけで検証範囲を決めると見落としやすい関係です。
プロジェクトでは、こうした重要フローをシナリオとして実行し、結果を残しました。各機能が存在するかを越えて、合意した動作を実際に確認するための方法でした。
定員超過と中途離脱も運用シナリオに入れました
正常な申込と学習完了だけでは、教育の運用を十分に説明できません。申込の定員が埋まったり、学習を終えない利用者が出たり、権限の異なる人がアクセスしたりすることがあります。
検証には、定員超過、中途離脱、利用者の権限差によるアクセス条件を含めました。最初に依頼した機能の正常経路の外でも、システムがどのような結果を出すかを確認したのです。
例外条件は、まれに起こることをすべて想像して入れる作業とは違います。サービスが実際に運用するルールを確認することです。定員と修了、権限は画面の外にある運用ポリシーのように見えますが、システムの結果を変える条件です。
こうした条件が実装の過程で明示されていなければ、開発ツールが組織の意図を代わりに知ることはできません。検証で条件を具体化する過程は、抜けた要件を見つける過程にもつながります。
説明と実行が違えば、実行結果を見直しました
コードに特定の処理が入っているという説明と、実行結果が食い違うことがあります。このとき説明をそのまま受け入れると、すでに動作していると仮定したまま検証を終えてしまうおそれがあります。
プロジェクトでは、合意した条件で実行した結果を判断の基準に置きました。期待した動作と違えば、要件の抜けや補完が必要な箇所として整理しました。
単におかしな画面を集めるのではなく、どの条件でどのような結果が出たかをシナリオ単位で記録しました。修正担当者が再確認でき、運用担当者もどのルールを決めるべきかを理解できる形が必要でした。
この記録は、生成AIの開発ツールを使う人にも役立ちます。次の修正依頼を「おかしいので直してほしい」ではなく、「この条件でこの結果が必要だ」と具体化できるからです。
納品したのは、リリースを検討できる根拠でした
検証を通じて、抜けた要件と追加確認が必要な領域を整理しました。実行したシナリオの結果と、確認できなかった範囲を併せて残しました。
すべての検証項目が揃っていない状態でリリースの可否を断定するよりも、判断に必要な事実を集めることが重要でした。どのフローを確認し、どの条件をさらに見るべきかが明らかになれば、次の作業も具体的に決められます。
既存システムを検証した結果は、補完すべき要件と次の確認範囲につながりました。その後の修正とリリース判断は、この記録をもとに別途進めるべき段階です。
開発が速くなるほど、作られた結果が業務の条件を満たしているかを確認する過程は、より明確でなければなりません。 M社では、実行できるコードと運用できる教育システムのあいだに何が残っているかを、記録として明らかにしました。
