第151回 雲勉 プロジェクトのドキュメントにおける課題をAmazon Bedrockで解決してみる

下記、勉強会での資料です。
https://youtu.be/CeN9sHB9GnA

Transcript

1. 第151回 雲勉 プロジェクトのドキュメントにおける課題を Amazon Bedrockで解決してみる 

2. 講師自己紹介 2
 矢原 亮汰 • DX開発事業部
 • 2020年アイレットに新卒で入社 • 本日の対象者： Amazon Bedrockに興味のある方／ドキュメントの運用でお困りの方 • ご質問は YouTubeのコメント欄で受け付けております。
 後日回答させていただきます！
 

3. アジェンダ 3
 1. プロジェクトにおけるドキュメントの課題 2. 生成AI導入前の解決したい課題の整理 3. 生成AIを利用した課題の対処法 
 4. まとめ

4. 1. プロジェクトにおけるドキュメントの課題 
 4
5. このような経験はありませんか？ ケース① 
 5
 色々な場所に情報が保存されていて、情報の更新が止まってしまう 

6. このような経験はありませんか？ ケース② 
 6
 なぜこの仕様 なんでしたっけ？ 仕様はドキュメントに書かれているが、 
 引き継いだプロジェクトで前任者がおらず、当時の経緯が残ってない・・・
7. このような経験はありませんか？ ケース② 
 7
 設計書
 • システム上で決められたことは書かれている 
 • 経緯が抜けていることが多い 
 ◦ Whyの部分 
 サービスが運用に入ると「なぜこの仕様になったか？」という 
 疑問が生じることが往々にしてある 
 1年2年後には担当者が変わっていることが多い 
 → 経緯に辿り着けず仕様を変更するのが怖い 

8. このような経験はありませんか？ ケース② 
 8
 ただ、経緯を全て書くのはとても大変で工数がかかる 
 メモ程度に書いていても後でその情報に辿り着くのが難しい 

9. それぞれのケースの問題点 
 9
 ケース①
 • ツールが乱立し情報を一元化されておらずドキュメントの 
 保守性が低い 
 
 ケース②
 • 欲しい情報に辿り着けない／情報が残っていない 

10. 2. 生成AI導入前に解決したい課題の整理 
 10
11. 解消したい課題の整理 
 11
 ケース①
 • ツールが乱立し情報を一元化されておらずドキュメントの 
 保守性が低い 
 改善したいこと 
 • 常に情報が最新化されている 
 • 更新コストを下げる 

12. 解消したい課題の整理 
 12
 ケース②
 • 欲しい情報に辿り着けない／情報が残っていない 
 改善したいこと 
 • 欲しい情報を残す 
 • 経緯の部分も含めて情報に辿りつきやすくする 

13. 解消したい課題の整理 
 13
 ケース 問題点 対処法 ケース① 情報が様々なところにあり、更新が大変で保守性が低い 常に情報を最新化する 更新が楽になるような仕組みづくり ケース② 欲しい情報が残っていない／情報に辿り着けない 欲しい情報を残す 情報に辿り着くための検索が容易になる仕組みづくり
14. 解消したい課題の整理 
 14
 ケース 問題点 対処法 ケース① 情報が様々なところにあり、更新が大変で保守性が低い 常に情報を最新化する 更新が楽になるような仕組みづくり ケース② 欲しい情報が残っていない／情報に辿り着けない 欲しい情報を残す 情報に辿り着くための検索が容易になる仕組みづくり 生成AI（Amazon Bedrock）を利用して これらの問題の対処法の 1例をご紹介！
15. 3. 生成AIを利用した課題への対処法 
 15
16. 課題への対処法 
 16
 ケース 問題点 対処法 ケース① 情報が様々なところにあり、更新が大変で保守性が低い 常に情報を最新化する 更新が楽になるような仕組みづくり ケース② 欲しい情報が残っていない／情報に辿り着けない 欲しい情報を残す 情報に辿り着くための検索が容易になる仕組みづくり
17. 常に情報を最新化する／更新が楽になる仕組みづくり 
 17
 メインのツールを決め、表現が難しいものはサブツールを利用する
18. 常に情報を最新化する／更新が楽になる仕組みづくり 
 18
 Docusaurusとは 
 • Meta社が作成したドキュメントサイトなどを 
 簡単に構築できるサイトジェネレータ 
 • Reactベースで作られている 
 • Markdownでドキュメントを記載 

19. 常に情報を最新化する／更新が楽になる仕組みづくり 
 19
 設計書をGitHubで管理 
 • フロントエンドやバックエンドのソースコードと同じリポジトリで管 理（Monorepo） 
 
 → 同じPull Requestで設計書とソースコードの変更を確認できる 
 → 仕様に対するやりとりなどをGitHub上に履歴として残せる 
 → 変更しようとするときにブラウザであちこち遷移して確認する必要 がなくなり、更新が楽になる（更新のストレスが減る） 
 → 設計書もレビューした状態で最新化できる 
 → 設計書を生成AIに読み取られせて情報を最新化できる仕組みを 作れる
 / ├─ docs ├─ frontend └─ backend
20. 常に情報を最新化する／更新が楽になる仕組みづくり 
 20
 ドキュメントを一元管理し、テスト仕様書を生成AIで作成する 

21. 常に情報を最新化する／更新が楽になる仕組みづくり 
 21
 ドキュメントを一元管理し、テスト仕様書を生成AIで作成する 

22. 常に情報を最新化する／更新が楽になる仕組みづくり 
 22
 ドキュメントを一元管理し、テスト仕様書を生成AIで作成する 

23. 常に情報を最新化する／更新が楽になる仕組みづくり 
 23

24. 常に情報を最新化する／更新が楽になる仕組みづくり 
 24

25. 常に情報を最新化する／更新が楽になる仕組みづくり 
 25

26. 常に情報を最新化する／更新が楽になる仕組みづくり 
 26

27. 常に情報を最新化する／更新が楽になる仕組みづくり 
 27

28. 課題への対処法（情報の最新化） 
 28
 設計書 Bedrockから返された 
 テストケース
29. 4．課題への対処法（情報の最新化） 
 29

30. 欲しい情報（経緯）を残す仕組みづくり 
 30
 経緯を設計書に残しておくことで「なぜ？」の部分が少なくなる
31. 欲しい情報（経緯）を残す仕組みづくり 
 31
 経緯は参考情報として記載 
 • 載せすぎると邪魔な情報になる 
 • トグルで表示・非表示を切り替えられるように 

32. 4. まとめ 
 32
33. まとめ
 33
 • 課題を見つけてそれを解決するのに生成AIを一つの選択肢として考える 
 → OSSのツールなどで利用できるのを何も考えずに生成AIを使用するのはよくない（お金がかかる） 
 
 • ドキュメントとソースコードを近くで管理することで、これからの生成AIアップデートでより活用しやすくなる 
 
 
 • 生成AIで開発プロセス・運用フローを楽にしよう！