ディレクトリ構成と設定ファイルから考えるSIerのVibe Coding

Transcript

1. ディレクトリ構成と設定ファイルから考える SIerのVibe Coding 2025.09.12 Satoshi Kaneyasu
2. 2 発表者自己紹介 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス部 在住：広島（フルリモート） 担当：DevOps、技術支援、PM、SM SNS(X)：@satoshi256kbyte • 2025 AWS Community Builders • 2025 Japan AWS Top Engineers (AI/ML Data Engineer) • 2025 Japan AWS All Certifications Engineers • 認定スクラムマスター • PMP
3. 3 目次 1. AIと協力する開発スタイル – Vibe Coding 2. AIに知識を補完する - MCP Serverの導入 3. AIに設計書を読ませる - コンテキストの活用 4. Vibe CodingとGitHub Actionsによる自動チェック 5. まとめ
4. AIと協力する開発スタイル Vibe Coding
5. 5 AIと協力する開発スタイル – Vibe Coding ◼ Vibe Codingは、自然言語でAIに指示を出してソフトウェアを開発する手法です ◼ AIがコードを生成し、開発者はそのコードをレビュー・修正しながら 開発していきます AI 開発者 ソースコード
6. 6 Vibe Codingの種類 ◼ Vibe Codingができるツールは、一般的にチャット欄で入力するタイプ とコマンドで入力するスタイルがあります。 コマンドタイプ Amazon Q Developer CLI チャット入力タイプ GitHub Copilot Agent Mode
7. 7 ツールを絞る ◼ 2025年9月現在Vibe CodingなどのAIを活用した開発ができるツールは 多数存在します ◼ 私の担当プロジェクトでは、Amazon Q Developerをメインとし、GitHub Copilot Agent Modeをサブで使用しています ◼ この選択がベストとは言い切れませんが、現実問題として検証しきれないので、現 在はこの2つ突き詰めていく方針です 次のページから別の話題に移ります
8. 8 Vibe Codingの効果 ◼ 間違いなく生産効率は向上しています ◼ 最大のメリットは、 まずは生成AIでできるところまで作ってみるという選択肢が生まれたことです ◼ これにより、PMとして頭が痛い「メンバーがタスクに及び腰になる」という悩みが軽減 されています ◼ ちなみに生成AIを使うことでコーディング能力が下がる？という説については、 私は「楽になる分数をこなして経験を積むしかない」と思っています
9. AIに知識を補完する MCP Serverの導入
10. 10 プロジェクトのディレクトリ構成
11. 11 プロジェクトのディレクトリ構成
12. 12 MCP Serverとは？ AIが外部のツールやデータにアクセスするための仲介役となるツールです 導入することによりAIの回答の精度を向上させることができます 利用者 Amazon Q Developer MCP Server AWS 公式ドキュメント AI モデル 問い合わせ 回答
13. 13 MCP Serverの選定と設定ファイル ◼ 私のプロジェクトではAWSの公式MCP Serverを導入しています ◼ MCP Serverを追加する場合は、フリーソフトやOSSのツールの選定と 同じようにPMの判断を仰ぐとしています
14. 14 MCP Serverの設定ファイルそのものはGit管理対象外 ◼ MCP Serverは大体複数の動かし方があります ◼ AWSの公式MCP Serverの場合は、uv(Python)・Dockerの2つの動か し方があります ◼ チームメンバーが扱いやすい方法で動かせるように、サンプルファイ ルを2つ用意しています 開発者はどちらかのサンプルをリネームしてmcp.jsonにする mcp.jsonそのものは.gitignoreでGit管理対象外にする 個人の設定内容をみんなが使うGitにアップロードしない 次のページから別の話題に移ります
15. AIに設計書を読ませる コンテキストの活用
16. 16 コンテキストとは？ ◼ コンテキストとは、「文脈」「背景」です ◼ 生成AIにおいては、回答してもらうために渡しておく事前情報 ◼ 例えば、要件定義や規約をコンテキストとして渡しておくと、生成AIそれを尊重した 回答をしてくれます
17. 17 Gitリポジトリの中に設計書を置き、コンテキストとする
18. 18 コンテキストの例 – 命名規約
19. 19 コンテキストの例 – 技術スタック
20. 20 コンテキストとその効果の感覚 コンテキスト 効果の感覚 備考 新規作成時 既存改修時 プロダクト概要 ◦ △ 技術スタック ◦ ◦ 書かないと安定しない データベース設計 ◦ ◦ 書かないと安定しない 実装ガイド ◦ ◦ 書かないと安定しない セキュリティガイド △ △ 他のツールでカバーする前提 テストガイド 不明 不明 十分に活用できていない 開発規約 ◦ ◦ 書かないと安定しない アーキテクチャ決定記録 × × まだ活用できていない
21. Vibe CodingとGitHub Actionsに よる自動チェック
22. 22 レビュアーの負荷の上昇 ◼ Vibe Codingを導入したことにより、レビュアーの負荷は上昇していると感じます ◼ 例えば理由は以下のものがあります ① 生成AIが開発者のスキルを補完するため、今までにないコードがあがってくる ② 生成AIが低品質・規約違反のコードを生成する ③ 生成AIが過剰なドキュメントを書く
23. 23 生成AIが低品質・規約違反のコードを生成する理由 ◼ この私がAWSを用いたシステム開発をしているからこその悩みかもしれません ◼ 現状生成AIは、インフラ・バックエンド・フロントエンドなど複数の領域・技術を組み 合わせて開発が苦手のようです ◼ コンテキストを充実化させることで苦手なところは軽減させられますが、 それでも低品質（主につながらないという形で現れる）、規約違反は完全には防 げません AWSで動かすシステムのため、 GitリポジトリにはAWSを操作するIaCとアプリケーションのコードが混在する
24. 24 GitHub Actionsでプルリクエスト前にできる前のチェックを行う Lint ソースコードの構文・整合性チェック Unit Test SCA 使用ライブラリの脆弱性チェック SAST セキュリティ観点の静的なコード解析
25. 25 現状、過剰なドキュメントの対策は打てていない ◼ 生成AIにREADMEを書かせたりすると、頼んでいないトラブルシューティングなどを 書くことがあります ◼ 過剰なドキュメントはメンテ負荷になるので、レビューで指摘しなければなりません ◼ 生成AIが過剰なコード、過剰なドキュメントを出力するのを抑制する術は私の方で は確立できていません、コンテキストで禁止してもあまり効果が見られません ◼ 一説には生成AIは否定の指示が苦手とも聞きます ◼ 当面、過剰な成果物はレビュアーがチェックするしかないと考えています
26. まとめ
27. 27 まとめ ⚫ 生成AIによるVibe Codingは確実に生産性を向上させています ⚫ まずは生成AIでできるところまで作ってみるという選択肢が生まれたのが大きいです ⚫ MCP Serverの設定、コンテキストとしての設計書をしっかりとGitリポジトリに含める ことで、より生成AIの精度をあげて恩恵を受けやすくすることができます ⚫ 一方で生成AIによりレビュアーの負荷が高まっている側面があるので、GitHub Actionsなどで自動チェックを走らせて負荷を軽減させています