学生がLLMと一緒に業務システム開発やってみた

学生がLLMと一緒に業務システム開発やってみた ＠はこだて未来大×企業エンジニア 大LT2026（2026/06/20） Jugesuke

自己紹介 Jugesuke 情報アーキテクチャ領域 M1 公共交通オープンデータをｺﾈｺﾈしたり まちあるきをしたりしています Web: aboutme.jugesuke.net Twitter: twitter.com/jugesuke 2

• http://aboutme.jugesuke.net
• http://twitter.com/jugesuke

今日の話題 3

学生がLLMと一緒に 業務システム開発やってみた 4

どんなシステム？ - 機能一覧 利用者 : イベント出展者 利用ｼｰﾝ: イベント会場 主要機能: オフライン対応POS、 複数拠点の在庫管理、棚卸資産評価 対象業務: 出展物の発注から、 イベント準備、当日販売、終了後の 〆作業、会計処理までを一貫で管理 5

どんなシステム？ 6

どんなシステム？ 7

どんなシステム？ 8

どんなシステム？ 9

どんなシステム？ 10

どんなシステム？ 11

なぜこんなことを？ 12

どんなシステム？ - 機能一覧 利用者 : イベント出展者 利用ｼｰﾝ: イベント会場 主要機能: オフライン対応POS、 複数拠点の在庫管理、棚卸資産評価 対象業務: 出展物の発注から、 イベント準備、当日販売、終了後の 〆作業、会計処理までを一貫で管理 13

どんなシステム？ - 機能一覧 利用者 : イベント出展者 利用ｼｰﾝ: イベント会場 主要機能: オフライン対応POS、 複数拠点の在庫管理、棚卸資産評価 対象業務: 出展物の発注から、 イベント準備、当日販売、終了後の 〆作業、会計処理までを一貫で管理 14

実は本を頒布していて...... 15

どんなシステム？ - 機能一覧 利用者 : 自分 利用ｼｰﾝ: 同人誌即売会 主要機能: オフライン対応POS、 複数拠点の在庫管理、棚卸資産評価 対象業務: 出展物の発注から、 イベント準備、当日販売、終了後の 〆作業、会計処理までを一貫で管理 16

同人誌即売会 同人誌頒布って やることがほぼ ビジネスと一緒 17

どんなシステム？ - 機能一覧 利用者 : 自分 利用ｼｰﾝ: 同人誌即売会 主要機能: オフライン対応POS、 複数拠点の在庫管理、棚卸資産評価 対象業務: 出展物の発注から、 イベント準備、当日販売、終了後の 〆作業、会計処理までを一貫で管理 18

今日の話題 どうやって進めたか お話します 19

進め方 20

開発の流れ 要件定義 ▼ 設計 ▼ コーディング ▼ テスト ▼ リリース 21

開発の流れ 要件定義 ▼ 設計 ▼ コーディング ▼ テスト ▼ リリース 22

よくある進め方 やりたいことを 聞き出す つくる人 つかう人 23

今回は...... やりたいことを 聞き出す つくる人 つかう人 24

やりづらい 25

AIに聞き取り・言語化をさせる Claude Code やりたいことを 聞き出す つかう人 仕様書 まとめる 仕様を参照する つくる人 26

実際の仕様書 27

気を付けるべきこと ● LLMが先走って合意していない仕様を勝手に確定させることが あるので、編集結果を見ながら、意図と異なるものが混入しな いようにきちんと管理する、Planをみながら文句を言う ● CLAUDE.mdで、進め方の方針を明示して、ガードしておく ○ 「Claudeは情報・選択肢・メリットデメリットの提供にとどめる。 最終判断はすべてユーザが行う。」と明記すると上手くいった 28

仕様書をまとめておくと良いこと ● Claudeはステートレス。毎回仕様書を読むように指示しておく と、何度も仕様を教える必要がなくなる。 ● 人間も数日経つとステートを維持できなくなる。 「昨日の自分は別人と思え」。記憶に頼らない。 ▶ 結局人間の共同開発とやることはあまり変わらない 信頼できる情報ソースとして仕様書を維持する 29

実装 30

開発の流れ 要件定義 ▼ 設計 ▼ コーディング ▼ テスト ▼ リリース 31

実装の分担 Claude Code 人間 ● ● 仕様の最終決定をする 一度決めると変更が難しいコアの 部分 = ビジネスロジックを書く ● ● ● よくあるコードを高速に実装 試行錯誤のコストが低い = 使っ てみないとわからないUIを担当 わかりきった実装が得意 = 仕様 からテストを作ってもらう 32

実装の流れ - バックエンド Claude Code 人間 ● ● 仕様書を見ながら、 バックエンドシステムを実装する 仕様におかしなところがあれば、 訂正する ● ● コードを見て、仕様書と相違がな いか確認する 仕様書をもとに、テストを書いて 正しさを担保する 33

実装の流れ - バックエンド ● Jugesukeはバックエンドをやっていたので、 AIに任せるより自分で書いたほうが楽 ● ロジックを自然言語で説明するより、 とっとと書いちゃった方が早い ● 作っている間に仕様の問題に気づいたり、 筋がいい方法を思いついたりするので、 自分で書いたほうが進めやすい 34

実装の流れ - フロントエンド Claude Code ● ● ● 仕様書とWebAPI仕様を見ながら、 UIを実装する とりあえずありそうなUIを作る FBをもとにUIをブラッシュアップ 人間 ● ● ● できた画面を見て、 ダメそうなら差し戻す 2パターン見たくなったら 両方見せろと言う いい感じになったらOKと言う 35

実装の流れ - フロントエンド ● Jugesukeが実装してもよいが、大変 ● よくあるWebアプリの実装になるので、 コーディングエージェントが得意な分野 ● 壊れても致命的な影響は少ない ● 自然言語で修正出来たほうが嬉しさがある ちょっと右、とか ● 完成品を作ってすぐ確認・修正という イテレーションを高速に回すことが出来る 36

LLMに2種類のUIを作らせてセルフABテストをする 37

会場で稼働させてみる 最終的に積み上げ式を採用 実際にイベント運用で両方試してみて、 より打ちやすかったのがこちら ▶ 実際に運用しないとわからない 使いやすさをプロダクトに反映できた 38

リリース 39

リリースの流れ ● ● ● ● 仕様書を書く ▶ 実装 ▶ リリース の 流れを、MVPを積み上げる形で徐々に 実装していく 微妙な所があれば適宜修正リリース Cloudflare Workerを利用していて、 PRの時点でPreviewビルドが出来るの で、本番データを使っても問題く動 作するかを確認しながら進める 常にMasterブランチがデプロイされ ている ▶ 通常の開発と同じ 40

今後の展望 41

今後の展望 ● Jugesukeは1人だが、 Claudeは何人でも呼べるので、 並行して開発を進められるようにしたい ○ 実装待ちの時間がもったいない ○ 機能別に同時進行に進めるなど？ ○ 承認するJugesukeが障害点になる？ ● 欲しい機能はまだまだあるので、 もっと拡張したい 42

学生がAIと一緒に業務システム開発やってみた ＠はこだて未来大×企業エンジニア 大LT2026（2026/06/20） Jugesuke