【20260402 AI×DevOpsStudy #10】AI駆動開発で人事管理アプリの作成をした話 × ClaudeCode SKILLs & Rules

■AI×DevOps Study #10 の概要
2026年4月2日に開催した「AI×DevOps Study」第10回の勉強会資料です。

「AI×DevOps Study」は、AI駆動開発やそこに関係するマイクロサービスについて理解を深める場になります。
株式会社ScalarではAIを使ったチーム開発を進めており、参画しているメンバーや協力会社の方から、具体的なAI駆動開発を実施する方法、その中で生まれたマイクロサービスアーキテクチャを使用したAI駆動開発の事例や実際に使えるエージェントについてお話頂き、参加者の皆様と知識の共有や交換を目的としています。
（弊社製品であるScalarDBも絡んだお話も一部出てきますが、汎用的な内容となっておりますのでフラットにお楽しみいいただけます）

■今回のテーマ
「AI駆動開発で人事管理アプリの作成をした話 × ClaudeCode SKILLs & Rules」

Claude Codeを活用し、人事管理アプリをJavaやSpring Boot、Next.jsで実装しました。AI駆動開発時の重要な点として、

1.ドメインを区切って1人の人間ががFE〜Backendまで実装できる環境を整備する
2.AIが生成したコードの品質管理

が挙げられます。

1についてはFE・BEそれぞれの実装規約をRulesとして定義することで、担当領域外の知識がなくても画面からAPIまで一気通貫で実装できる環境を実現、2についてはJava 21・Spring Bootの使用規約をSKILLsおよびRulesとして定義することで、AIが生成するコードの品質を安定させました。

今回は、本AI駆動開発の内容やどのような手順・手順で開発を進めたのかをお伝えします。

■登壇者情報（敬称略）
mini-worker
株式会社Scalar所属のソフトウェアエンジニア。2018年からメールマガジン開発・運用（Kotlin / SpringBoot / PHP / JavaScript）、スタートアップ企業の情報や、ビジネスアイデアを共有するためのシステム「STARTUP DB」の立ち上げなどを経験。2022年-2025年には某ECサイトの社内管理システムの開発を担当し、マイクロサービスアーキテクチャを現場レベルで叩き込まれました。最近はAIをどう現場で使いこなすかにハマっていて、Skills・Rulesを自作しながら、毎日アプリ作ってはレビューしてを繰り返してます。

■関連コンテンツ
Youtube
www.youtube.com/@scalar-labs

Zenn ブログ
https://zenn.dev/p/scalar_sol_blog

Transcript

1. AI駆動開発で⼈事管理アプリの 作成をした話 2026年4⽉2⽇ 株式会社Scalar ⽒名 mini-worker
2. 本⽇のAgenda 2 1. はじめに 2. 前提 3. AIでの開発に必須の道具たち 4. 開発フロー 5. Demo 6. 今後の想定課題とNextAction 7. まとめ
3. はじめに 3
4. ⾃⼰紹介 名前：mini-worker 所属：株式会社Scalar ビジネスソリューション本部 最近の興味 • AI駆動開発、AIがどう世の中を変えていくのか • 業務中はZennのブログ記事の材料になりそう なことを⽇々探している ◦ https://zenn.dev/miniworker • 健康的に痩せる⽅法を⽇々模索中 4 これまでの経歴 • 2018.04 ◦ 新卒からエンジニアのキャリアをStart ◦ メールマガジンの開発、スタートアップ 企業の情報を共有するためのシステム 「STARTUP DB」の⽴ち上げなどに従事 • 2020.09 ◦ ECサイトの管理画⾯/ユーザ画⾯/加盟店 管理画⾯の開発〜運⽤まで経験 • 2022.05 ◦ フードデリバリーシステムの基幹システ ムを開発〜運⽤まで経験 • 2026.02 ◦ ScalarにJoin！
5. 今⽇話すこと 1. AI駆動開発で⼈事管理アプリをFE/BFF/BEを⼀通で実装した経験 2. AI開発時のマインドセット： a. ①設計‧計画段階に時間を⼀番使う b. ②全てをAIにやらせない、⼈間の作業も必須 3. AI開発に必須の道具たち：Claude Codeを利⽤して、CLAUDE.md、 Rules、SKILLsの活⽤ 4. 開発フロー：システムをドメインごとに区切り、機能ごとに実装し、 FE/BFF/BEの実装〜動作確認を⼀貫して1⼈の⼈間⾏う必要性 5
6. 前提 6
7. 現在の⼀般的な開発体制 • 機能ごとにFE/BFF/BEが完全に分業 • FE/BFF/BEの担当者が複数機能を跨っ て、⾃分の担当領域のみを実装 • １つの機能を実装するためにFE/BFF/BE の担当者でインターフェースの認識合わ せやミーティングに時間を使⽤ • 機能の実装には、各チーム‧領域の⾜並 みをそろえていく必要がある 7
8. AI時代の縦割り開発 • 専⾨ではなかった領域もAIによって実装可能 になるため、これまでの分業体制ではなくな る • １機能＝１担当者になるため、機能AはAさん が担当、機能BはBさんが担当と割り振れるよ うになる。それぞれ別Sessionで実装可能に なるため、並列での開発が実現可能になる。 • ただしこれを実現するには”ドメインごと”に システムが正しく区切られている必要があ る。 （今回はDDDなどについては詳しく説明しま せんが”ドメインごとに区切る”必要があるこ とは覚えておいてください） 8
9. AI駆動開発で、設計‧計画段階が重要な理由 • 同じ機能でも、セッションごとに違うアプローチで書いていたり、使わなくて いいライブラリを使い始めるためいきなりコードを書かせると出⼒がブレる • ブレをなくすために必要なこと →先にmdファイルでドメインモデル/ APIの設計/ コーディングルール‧アン チパターンなどレイヤーごとにmdファイルを切り出しておくことで、  ①実装のブレがなくなる。  ②コンテキストの節約ができる。 毎回AIに1から説明しなくても、 『このファイルを読んで作業して』と渡すだけで済みます。 • AIを使えば使うほど、設計の⽢さがコードに直撃します。間違った設計のまま 突き進んだときのダメージが、⼈間が書いていた時代と⽐べて桁違いに⼤きい ため、設計‧計画段階がより重要になってきます。 9
10. ⼈間の作業とAIの作業の棲み分けはどこにあるのか？ この棲み分けの詳細は、 後ほど『開発フロー』のセクションで具体的に説明します。 10 ⼈間がやることは、レビューや動作確認で最終判断すること。 AIがやることは、設計書の作成、設計書を読んでコードを書くこ と、レビューで指摘を出すこと。
11. AIでの開発に必須の道具たち 11
12. 5つの道具 • 本⽇はClaudeを使って開発していく⼿順 を紹介します • Claudeを使って開発する際に必要な道具 ◦ CLAUDE.md ◦ Rules ◦ Skills ◦ MCP ◦ Compound Engineering 12
13. CLAUDE.mdとは？ • プロジェクト全体の方針書で、Claude Codeを起動したときに常に読み込まれ るファイル • このプロジェクトは何を作っているか、使っている技術スタックは何か、コードを書 くときの基本方針、あとは参照してほしいドキュメントの場所、のような内容を記載 • ポイント： 短く保つ。 長くなりすぎるとAIが全部読み込めなかったり、重要なルールが埋もれるため詳 細はRulesに切り出す、というのが基本的な考え方。 13
14. CLAUDE.mdに実際に書いている内容 ※一部抜粋 • 技術スタック • Spring Dataの制約、サポートされていない SQL / DB 機能 ◦ 実装のOK/NGパターンの記載 • プロジェクト構造 ◦ tree 形式で記載 • 仕様書 ◦ `../HRM_data_model.md` など仕様書のリンクを記載 • コーディング規約 ◦ `.claude/rules/`のリンクを記載 • モデル選択ガイドライン ◦ タスクに応じてモデルを使い分け 14
15. Rulesとは？ • Rules＝CLAUDE.mdの肥大化対策として生まれたファイル群 • 『このパターンは使わない』『このライブラリはこう使う』といった詳細なルールをRules に切り出すことで、CLAUDE.mdをスリムに保てる • paths: *.java形式でファイルパスを指定することで、Javaのファイルを触るとき だけRulesを適用させる制御ができます • 例：私の場合、.claude/rules/repository.mdというファイルに実装の OK/NGリストを記載しました。『このメソッドは使わない』などのように具体的な禁止事 項を書いています（次のSlide参照） 15
16. Rulesに実際に書いている内容 ※一部抜粋 • `paths: "src/**/repository/**/*.java"` で Repositoryの実装でのみ呼び出されるように記載 • 基本的なRepositoryの実装⽅法/Entity定義 ◦ 具体的なコードを記載 • 禁⽌事項 • チェックリスト 具体的なコードを記載することで⽣成されるコードを統⼀ 16
17. Skillsとは？ • AIに専門知識を教える仕組み • .claude/skills/{skill-name}/SKILL.mdというファイルを生成し`name: {skill-name}`と記載することでSKILLを作成 • 使われるタイミングは、実装フェーズなどでAIが必要なSkillを参照して実装してくれま す。または/{skill-name}とスキル名を直接指定することで呼び出せる • Atomic Designのコンポーネント設計など、プロジェクト固有の知識を渡せる のが強 み https://code.claude.com/docs/ja/skills 17
18. MCPとは？ MCP(Model Context Protocol)とは…Claude Codeを外部ツールと連携させる仕組み • Context7 ◦ ドキュメントをリアルタイムで参照できるツール。これがないと Claudeが自律的に調査するときに古い ドキュメントを参照してしまう。 • Serena ◦ コードの構造を解析してくれるツール。大きなリポジトリで『このメソッドどこで使われてる？』みたいな ことを調べるのが得意。 • Playwright ◦ ブラウザの自動操作ができるツール。 18
19. 補⾜：おすすめPlugin • Claude Mem ◦ Sessionを閉じると会話の記憶がリセットされるため、Claude Memを入れておく ことで次にSessionを開いたときに過去の作業内容を引き継いげて、コンテキス トの永続化が可能になる ◦ 詳細はZennブログに記載しています↓ ▪ Claude Codeのトークン枯渇問題をClaude-Memで解決した話 19
20. Compound Engineeringとは？ https://github.com/EveryInc/compound-engineering-plugin • Every社が提供しているAIコーディングの開発支援プラグイン • ワークフロー：(Ideate→ )Brainstorm → Plan → Work → Review → Compound 20 私の場合、Planフェーズは coding-agent-for-scalardbで代替しており、 Work・Review・Compoundを中心に使っていま す。※BrainstormとIdeateは最近追加されたコマン ドのためまだ使ったことがないです
21. 開発フロー 21
22. 全体フロー • 「はじめに」と「前提」の部分で『設計‧計画段階に時間を使おう、全てをAIにやら せない』と⾔いましたが、具体的にどういうサイクル‧どのように役割を分けて開発 するのかをここで説明していきます • 4つのステップで開発を進めていきます 設計 → 実装 → レビュー → 蓄積 • ⼈間がやることとAIがやることが分かれていて、設計の作成はAIが⾏い確認は⼈間、 実装はAIが主役、レビューは⼈間とAIで⾏い、蓄積はAIが整理→⼈間が確認して進め ていきます 22
23. 設計: ①mdファイルを作る • ⼀番⼤事なのは、実装前に細かい指⽰出し⽤のmdファイルを作っておくこと • 具体的に何を書くのか？ ◦ ドメインモデル、API設計、セキュリティ設計、エラーハンドリングの⽅針、のようにレイ ヤーごとにファイルを分けて書きます。1つのファイルに全部書くのではなく、レイヤーごと に切り出すことが重要です！ • 実装時に『このファイルを読んで実装して』と渡すだけで、毎回1から説明せ ず即実装に⼊れます。コンテキスト節約‧トークン削減‧実装のブレ防⽌が 同時に実現できます💯⭕ 23 そもそもなぜmd（Markdown）形式？ md形式で渡すと構造を理解した上でコーディングしてくれるためmd形式が推奨
24. 設計② coding-agent-for-scalardb • 今回はCompound Engineeringの/ce:planコマンドの代わりに coding-agent-for-scalardbというAgentを使います。今回実装した、「人事管理アプ リ」では弊社製品のScalarDBを使っていてScalarDB固有のコーディングルールが あるため、このAgentで代替します。 • Step 1から13まで順番に実⾏することで、設計ドキュメントを13個⾃動⽣成さ れます。ドメインモデルからAPI設計、セキュリティ設計、オブザーバビリ ティの設計まで⼀通り⽣成してくれます。 https://github.com/wfukatsu/coding-agent-for-scalardb 24 ⽣成されたmdファイルは必ず⽬を通してレビューをし、内容がおかしいところは必 ず修正してください。 ※全部AIに丸投げではなくて、⽣成物は必ず⼈間が確認してください。
25. 補⾜：ScalarDBの説明 • 弊社Scalarで開発している異種 DB をまたいで ACID トランザクションを実現する DB ミドルウェア。ローカル環境とクラウド環境のデータベースの差異を吸収し、AIが開 発する環境と実⾏する環境の同⼀性を担保できます。 • 今回開発した⼈事管理アプリではこのミドルウェアを利⽤して開発 • 開発にあたり、独⾃のコーディングルールなどがあるため coding-agent-for-scalardb を使ってPlanフェーズを代替 https://scalardb.scalar-labs.com/ja-jp/docs/latest/overview 25
26. 実装 • ここで使うのがCompound Engineeringの/ce:workです。 • 設計フェーズで作成したmdファイルを読ませて/ce:workを実行することで、AIが設計書を 理解した上でコードを書いてくれます。 • このとき、Rulesが一緒に読み込まれます 。前述したように、path: *.javaで指定した Rulesが自動で読み込まれて、アンチパターンを避けながらコードを書いてくれます。 • またSkillsも読み込まれます 。ScalarDBの実装パターンとやプロジェクト固有の知識をAIが 参照しながらコードを書いてくれるので、一貫性のある実装になります。 • 実装の順番は、API → Frontend → BFFの順で4つのステップ（設計→実装→レビュー→ 蓄積）を実行しサイクルを回す方法がおすすめです！私もその方法で実装しました。 26
27. レビュー: ①コードレビュー • コードレビューで使うのが/ce:reviewです。実行すると、AIがコードを読んで CRITICAL・MEDIUM・LOWの3段階で修正すべき対象 を出してくれます。 • CRITICALはセキュリティ上の問題など必ず直すことが推奨されるレベル、MEDIUM はパフォーマンスや保守性の観点での改善提案。LOWは直せたらよいくらいのも の、というレベル感です。 • AIが出した指摘を一個一個コードを見て確認して、直すのか・努力義務扱いにする のかを人間が判断するのが Bestです。 • 個人的な感想：CRITICAL/MEDIUMはすぐ直すべきレベルの指摘が入っておりその 場ですぐ直すことが多いです。LOWは努力義務レベルの指摘が多く直すほどではな いものもありました。 27
28. レビュー: ②動作確認＋デバッグ • 動作確認は自分の手でアプリを動かして、目視で確認してください。画面を触って、ボタ ンを押して、データが正しく返ってくるか、エラーが出ていないかは実装者自身で確か めてください。 • バグやエラーが見つかったときに役に立つのがMCPの紹介で話したPlaywrightで す。ブラウザを自動操作してどこで何が起きているかを特定してくれます。 28 💡補足:実装のときにログを仕込んでおくとデバッグが楽になるため、実装の段階から ログの設計を意識しておくのがおすすめ💡
29. レビュー: ②動作確認＋デバッグのまとめ 　　　　　　　動作確認：人間が手作業＋目視 　　　　　　 　　　　　　　デバッグ：Playwrightで自動操作して原因特定 29
30. 蓄積：Compoundで知⾒を残す • /ce:compoundを実行することでこれまでに得た知見、踏んだ罠、解決策などを自 動で整理して、docs/solutions/というフォルダに生成 • 次に/ce:planを実行したとき、AIがdocs/solutions/を読んで計画を立てる • それによって同じ間違いを繰り返さなくなる 30
31. 開発フローまとめ • 設計段階ではmdファイルをレイヤーごとに作る、実装は/ce:workでAIに書かせ る、検証はAIのレビューと人間の目視確認の2段階、蓄積は/ce:compoundで知見 を残す、サイクルで開発を進めてください。 • 繰り返しになりますが、設計なしでいきなり /ce:workはダメです。 31
32. デモ(デモ動画はYoutube参照) 32
33. 今後の想定課題とNextAction 33
34. 課題①既存コードを壊さない実装 • 防衛線①は RulesとSkillsで事前予防する ◦ アンチパターンとコーディングルールを Rulesに書いておくことで、そもそも壊すようなコードを AIに書 かせない。これが一番シンプルで効果的な予防策です。 • 防衛線②は /forkを使う ◦ forkとはClaude Codeの機能で、現在のSessionから別の世界線を作れるイメージです。本線のコー ドとSessionはそのままで、別世界線でコードを修正する。うまくいったら /resumeで本線に持ち込 み、失敗したら/rewindで全部なかったことにできます。 34
35. 課題②既存コードを壊さない実装 • 防衛線③は指示を詳細に絞る ◦ コード修正で指示を出す時に『この APIを修正して』ではなく、『 UserServiceクラスのcreateUser メソッドだけ修正して』のように、クラス名・メソッド名・エンドポイントまで具体的に指定する。 Frontend だったら、Storybookの部品レベルで指定する。そうすることで、 AIが予期せぬ範囲まで修正するのを 防げます。 • 補足：このときにLSPの設定をOnにしておくのが大事です 。 ◦ LSPとは？Language Server Protocolの略で、コードの抽象構文木を理解してくれる機能です。 LSP がOnだと指定したクラス以外も構造を辿って AIが適切に修正してくれます。 OffだとAIがgrepでコード 調査して、トークンを大量に使うので注意してください。 35
36. NextAction①テストとTDD • 今の開発フローだと、実装してからレビュー、という順番なのですが、これをテスト ファーストに変えたいと思っています。 • 具体的には、テストを書く Agentと実装する Agentを別Sessionに分けるという方法 で進めていきたいです。同じSessionで『テスト書いて、次に実装して』とやるとAIがテ ストに合わせて実装をサボり始めるため、それを防ぐために、テスト担当と実装担当 を分離します。 • これはまだ試行中のため、成果が出たら勉強会の題材にしたいです。 36
37. NextAction②仕組みで品質を守る • 『AIのコードって品質大丈夫なの？』『ジュニアエンジニアとAI駆動開発するのが 怖い』という方へのアンサーです。 • 結論から言うと、品質は仕組みで守る のが一番です。AIの出力を信じるだけで はなく、仕組みとして品質を担保します。 • 手段としては3つ ◦ Pre-pushフックで Lintとユニットテストを必須にする 。コードをpushする前に自動でチェックが 走って、通らないとpushできない仕組みにする。 ◦ SAST・DASTを導入する 。SASTは静的解析でコードのセキュリティ問題を検出、 DASTは実際 に動かしてセキュリティの脆弱性を検出します。 ◦ カバレッジ閾値でマージ不可にする 。テストのカバレッジが一定以下（カバレッジ 90％など）だと マージできない設定にする。 37
38. まとめ 38
39. 今⽇のまとめ • AIでの開発は、 設計に時間をかけてフェーズごとにmdファイルに落とし込もう！ • 実装はAIに任せて、レビューや動作確認は⼈間の⽬で確認。 ⾃分の⼿で動かしてみることも忘れずに💡👀󰠁 • AI時代の今、"当たり前"や"常識"は⽇々変わっていきます。 それも楽しみながら学んで新しい⼿法を試してみるのが重要です。 39
40. 宣伝 • ScalarのメンバーでZennブログを更新中！3⽉は毎⽇投稿頑張りました ◦ https://zenn.dev/p/scalar_sol_blog • 4/9 に、今回実装した⼈事管理アプリをAWSにDeployした過程を発表します！ ◦ https://scalar.connpass.com/ • 4/23 18:00- オフラインのイベントを⾏います！ぜひお越しください ◦ ⾃社の業務におけるClaude CodeなどのAI活⽤事例紹介（ハイブリッド開催） • 今回の勉強会の内容はYoutubeに載せています。⾒逃した⽅いたらぜひご覧く ださい。 ◦ https://www.youtube.com/@scalar-labs/videos 40
41. 参照リンク集 • ScalarDB • Compound-engineering • coding-agent-for-scalardb • how-to-structure-claude-code-for-production • turning-claude-code • how-we-integrated • https://docs.claude-mem.ai/introduction 41
42. GitHub scalar-labs/scalardb connpass Scalar Please give us a star on GitHub! AIxDevOps Study 毎週⽕曜開催