株式会社スマートエイトは、業務システム開発会社Kと、そのシステムの発注元の計3名に、計12時間の生成AI研修「業務自動化コース」を実施しました。長く稼働しているシステムを止めずに直すために、直す前に自動テストと自動検査の「安全網」を張る手順を、受講者が自分の手で組んでいます。
応用編の演習では、導入先ごとに画面を複製した教材アプリで、1つの共通仕様の修正を12の画面へ一括で広げ、自動検査をすべて通しました。最終回のアンケートでは、「今後の業務で活用できそう」が5点満点で平均4.7です。
基本情報
- 業種：大学向けの業務システムの開発
- 受講者数：3名。開発会社の2名と、システムの発注元の1名
- 受講者のAI経験：開発にClaude Codeが欠かせない人から、チャットで相談する程度の人まで
- 研修期間：2026年7月、計12時間
- 提供サービス：Claude Codeの生成AI研修「業務自動化コース」
事前にご相談頂いた課題
課題①：1つの共通仕様の変更が、導入先ごとの画面に波及していた
導入先の大学ごとに画面を複製して運用しているため、共通の仕様を1つ変えると、複数の画面に修正が広がります。どの画面を直すべきかの確認に、毎回時間がかかっていました。発注元は、項目の追加のような軽い変更を、もっと速く出せる状態を求めていました。
課題②：壊していないかの確認が、すべて人の手作業だった
自動テストが無く、動作の確認は手作業でした。テスト環境と本番環境への反映や、バックアップの取得も手作業です。直すたびに、ほかの所を壊していないかの確認が積み上がっていました。
課題③：AIで速く書くほど、レビューが詰まる懸念があった
開発会社には、Claude Codeが開発に欠かせない受講者もいました。そのぶん、どこまで・どの基準で見るかを決めないと、速く書けてもレビューが終わらなくなるという懸念がありました。コードを読まない立場でも、セキュリティの品質を客観的な基準で示せる方法を知りたい、という要望も出ていました。
課題要因（なぜ従来のアプローチでは解決しなかったか）
- 稼働中のシステムなので、作り直す選択肢が取れなかった
- 生成AIの活用例は新しい開発環境に偏っていて、長く動いているシステムの保守で参考にできる前例がほとんど無かった
- 壊したら気づける自動テストや自動検査が無いまま速く書いても、確認とレビューが人に積み上がるだけだった
選んだアプローチ
生成AI研修「業務自動化コース」を、計12時間で行いました。Claude Codeを使い、直す前に「安全網」を張り、その上で直す順に進めます。
題材には、導入先ごとの画面の複製・自動テストなし・手作業のリリースという同じ悩みを仕込んだ、架空の教材アプリを使いました。本番のシステムには触れていません。
なぜこのアプローチか
- 保守が遅いのは、直すこと自体より「壊していないか」の確認に時間がかかるため。確認を機械に任せる安全網を先に張れば、AIで速く直しても怖くない
- 本番のシステムに触れない教材なら、壊す心配なく最後までやり切れ、身につけた手順をそのまま自社のシステムに当てられるため
- 一次の検査を機械に、レビューをAIに任せ、最後の受け入れだけを人が決める分担にすれば、レビューの詰まりを解けるため
研修の全体設計
座学より、受講者が自分の環境で手を動かす演習を中心に進めました。
段階 | テーマ | 内容 |
|---|---|---|
基礎編 | AIへの渡し方と品質の考え方 | 曖昧な指示と定義つきの指示の比較、設定ファイル・手順の登録・サブエージェント・外部連携というClaude Codeの構造、繰り返す作業の手順化、テストの段階と承認テスト、移行の戦略 |
実践編 | 教材アプリに安全網を張る | AIの読みと機械の解析の突き合わせ、承認テストで今の動きを固定、CIを組む作業、セキュリティの静的解析、品質ダッシュボード、単体テスト、4観点のAIレビュアー |
応用編 | 安全網の上で直し、自社へ広げる | 共通仕様の不具合の全導入先への一括修正、AIレビューのCIでの並列実行、課題を書いたIssueを起点にした開発の自動化、自社のシステムへ広げる段取りの設計 |
承認テストは、今の画面の出力を正解として固定し、変わったら知らせるテストです。CIは、変更を登録するたびに検査を自動で走らせる仕組みで、AIレビューは「セキュリティ・品質・構造・読みやすさ」の4観点で行います。
結果
定量成果（最終回の研修アンケート／3名）
- 満足度：4.3／5.0
- 理解度：4.0／5.0
- 今後の業務で活用できそう：4.7／5.0
「活用できそう」の得点は、満足度より高く出ました。
研修で受講者が組んだ仕組み
どれも教材アプリの上で、受講者が自分で組みました。
研修前の課題 | 受講者が研修で組んだ仕組み |
|---|---|
共通仕様の1つの変更が、複数の画面に波及する | 直すべき箇所を機械で洗い出す仕組み。複製した画面どうしの静かなずれも見つける |
自動テストが無く、動作の確認は手作業 | 変更でほかが壊れていないかを自動で確かめる仕組み。承認テスト・単体テスト・セキュリティ検査・静的解析を、CIでまとめて走らせる |
反映の前の確認も手作業 | 変更を登録するたびに検査が自動で走り、AIが4観点でレビューする仕組み。指摘は「要対応」と「提案」に分けて返る |
事例：応用編の演習で、共通仕様の不具合を12の導入先へ一括で直す
Before：申込の受付で、満席でも申し込めてしまう不具合を、全導入先の一覧画面へ素直に一括で直すと、全体の検査は赤（失敗）になりました。ところが、画面の形が違う導入先では、修正が抜けているのに検査が緑（合格）のまま通りかけていました。承認テストが固定していたのは、12の導入先のうち3つだけだったためです。赤が出ない所で壊れるのが、安全網の無い怖さです。
After：先に承認テストを全導入先へ広げ、4観点のAIレビュアーに取りこぼした導入先を名指しさせてから直します。承認テストがすべて緑になり、AIレビューの要対応の指摘がゼロになれば、どの画面も壊さずに修正が全導入先で効いたことを機械で確かめられます。網を広げてから直すのが、研修で身につけた順番です。
研修後の変化
研修のあと、開発会社の受講者は、研修で組んだCIとAIレビューを自社の開発に当てていく4段階の計画を自分で描き、発注元と方向性を合意しています。
土台を整えたうえで、2段目で研修で組んだ検査とレビューを実際の開発で試し、4段目で開発から反映までを通しで整える順番です。
受講者の声
研修のアンケートに書かれた声から、3つを紹介します。
「AIレビュー 結構考えて個別でレビューさせていたので、GITで行えるのは便利と感じた。」 ― 受講者
「Issueを使った自動開発の仕組みは知らなかったので非常に良かったです」 ― 受講者
「開発手法等はすぐに取り入れられそうだった。」 ― 受講者
