Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
第151回 雲勉 プロジェクトのドキュメントにおける課題をAmazon Bedrockで解決してみる
Search
iret.kumoben
January 17, 2025
Technology
0
71
第151回 雲勉 プロジェクトのドキュメントにおける課題をAmazon Bedrockで解決してみる
下記、勉強会での資料です。
https://youtu.be/CeN9sHB9GnA
iret.kumoben
January 17, 2025
Tweet
Share
More Decks by iret.kumoben
See All by iret.kumoben
第158回 雲勉 AWS CDK 入門 ~ プログラミング言語で書くインフラ Python 編 ~
iret
0
30
第157回 雲勉 AWSインフラ監視をNew Relicで行う際の個人的Tips
iret
0
36
第156回 雲勉 AWS on Windows入門
iret
0
70
第155回 雲勉 サーバレスアーキテクチャを 用いたコスト重視 AI サービス
iret
0
51
第154回 雲勉 AWS Codeシリーズ盛り上げ隊 ~ Codeシリーズは砕けない ~
iret
0
54
第153回 雲勉 トラシューが秒で終わる新機能 Amazon Q Developer operational investigations
iret
0
65
第150回 雲勉 AWS AppSyncではじめるGraphQL体験
iret
0
57
第152回 雲勉 シームレスなマルチリージョンへの移行と検討 ~Amazon EKSとAWS Global Acceleratorを使用した環境〜
iret
0
77
第149回 雲勉 AWS ベストプラクティスの最新と実際 AWS Well-Architected
iret
0
97
Other Decks in Technology
See All in Technology
数百台のオンプレミスのサーバーをEKSに移行した話
yukiteraoka
0
640
日本MySQLユーザ会ができるまで / making MyNA
tmtms
1
350
移行できそうでやりきれなかった 10年超えのシステムを葬るための戦略
ryu955
2
200
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
2k
Why Go?
xpmatteo
0
130
技術好きなエンジニアが _リーダーへの進化_ によって得たものと失ったもの / The Gains and Losses of a Tech-Enthusiast Engineer’s “Evolution into Leadership”
kaminashi
0
200
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
20k
コード品質向上で得られる効果と実践的取り組み
ham0215
2
200
製造業の会計システムをDDDで開発した話
caddi_eng
3
930
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
140
ソフトウェア開発におけるインターフェイスという考え方 / PHPerKaigi 2025
k1low
9
3.9k
[CATS]Amazon Bedrock GenUハンズオン座学資料 #2 GenU環境でRAGを体験してみよう
tsukuboshi
0
140
Featured
See All Featured
Music & Morning Musume
bryan
46
6.4k
Speed Design
sergeychernyshev
28
860
Measuring & Analyzing Core Web Vitals
bluesmoon
6
320
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.6k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
GraphQLの誤解/rethinking-graphql
sonatard
70
10k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
16
1.1k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.7k
Scaling GitHub
holman
459
140k
Into the Great Unknown - MozCon
thekraken
36
1.7k
Transcript
第151回 雲勉 プロジェクトのドキュメントにおける課題を Amazon Bedrockで解決してみる
講師自己紹介 2 矢原 亮汰 • DX開発事業部 • 2020年アイレットに新卒で入社 • 本日の対象者:
Amazon Bedrockに興味のある方/ドキュメントの運用でお困りの方 • ご質問は YouTubeのコメント欄で受け付けております。 後日回答させていただきます!
アジェンダ 3 1. プロジェクトにおけるドキュメントの課題 2. 生成AI導入前の解決したい課題の整理 3. 生成AIを利用した課題の対処法 4.
まとめ
1. プロジェクトにおけるドキュメントの課題 4
このような経験はありませんか? ケース① 5 色々な場所に情報が保存されていて、情報の更新が止まってしまう
このような経験はありませんか? ケース② 6 なぜこの仕様 なんでしたっけ? 仕様はドキュメントに書かれているが、 引き継いだプロジェクトで前任者がおらず、当時の経緯が残ってない・・・
このような経験はありませんか? ケース② 7 設計書 • システム上で決められたことは書かれている • 経緯が抜けていることが多い
◦ Whyの部分 サービスが運用に入ると「なぜこの仕様になったか?」という 疑問が生じることが往々にしてある 1年2年後には担当者が変わっていることが多い → 経緯に辿り着けず仕様を変更するのが怖い
このような経験はありませんか? ケース② 8 ただ、経緯を全て書くのはとても大変で工数がかかる メモ程度に書いていても後でその情報に辿り着くのが難しい
それぞれのケースの問題点 9 ケース① • ツールが乱立し情報を一元化されておらずドキュメントの 保守性が低い
ケース② • 欲しい情報に辿り着けない/情報が残っていない
2. 生成AI導入前に解決したい課題の整理 10
解消したい課題の整理 11 ケース① • ツールが乱立し情報を一元化されておらずドキュメントの 保守性が低い 改善したいこと
• 常に情報が最新化されている • 更新コストを下げる
解消したい課題の整理 12 ケース② • 欲しい情報に辿り着けない/情報が残っていない 改善したいこと •
欲しい情報を残す • 経緯の部分も含めて情報に辿りつきやすくする
解消したい課題の整理 13 ケース 問題点 対処法 ケース① 情報が様々なところにあり、更新が大変で保守性が低い 常に情報を最新化する 更新が楽になるような仕組みづくり
ケース② 欲しい情報が残っていない/情報に辿り着けない 欲しい情報を残す 情報に辿り着くための検索が容易になる仕組みづくり
解消したい課題の整理 14 ケース 問題点 対処法 ケース① 情報が様々なところにあり、更新が大変で保守性が低い 常に情報を最新化する 更新が楽になるような仕組みづくり
ケース② 欲しい情報が残っていない/情報に辿り着けない 欲しい情報を残す 情報に辿り着くための検索が容易になる仕組みづくり 生成AI(Amazon Bedrock)を利用して これらの問題の対処法の 1例をご紹介!
3. 生成AIを利用した課題への対処法 15
課題への対処法 16 ケース 問題点 対処法 ケース① 情報が様々なところにあり、更新が大変で保守性が低い 常に情報を最新化する 更新が楽になるような仕組みづくり
ケース② 欲しい情報が残っていない/情報に辿り着けない 欲しい情報を残す 情報に辿り着くための検索が容易になる仕組みづくり
常に情報を最新化する/更新が楽になる仕組みづくり 17 メインのツールを決め、表現が難しいものはサブツールを利用する
常に情報を最新化する/更新が楽になる仕組みづくり 18 Docusaurusとは • Meta社が作成したドキュメントサイトなどを 簡単に構築できるサイトジェネレータ
• Reactベースで作られている • Markdownでドキュメントを記載
常に情報を最新化する/更新が楽になる仕組みづくり 19 設計書をGitHubで管理 • フロントエンドやバックエンドのソースコードと同じリポジトリで管 理(Monorepo)
→ 同じPull Requestで設計書とソースコードの変更を確認できる → 仕様に対するやりとりなどをGitHub上に履歴として残せる → 変更しようとするときにブラウザであちこち遷移して確認する必要 がなくなり、更新が楽になる(更新のストレスが減る) → 設計書もレビューした状態で最新化できる → 設計書を生成AIに読み取られせて情報を最新化できる仕組みを 作れる / ├─ docs ├─ frontend └─ backend
常に情報を最新化する/更新が楽になる仕組みづくり 20 ドキュメントを一元管理し、テスト仕様書を生成AIで作成する
常に情報を最新化する/更新が楽になる仕組みづくり 21 ドキュメントを一元管理し、テスト仕様書を生成AIで作成する
常に情報を最新化する/更新が楽になる仕組みづくり 22 ドキュメントを一元管理し、テスト仕様書を生成AIで作成する
常に情報を最新化する/更新が楽になる仕組みづくり 23
常に情報を最新化する/更新が楽になる仕組みづくり 24
常に情報を最新化する/更新が楽になる仕組みづくり 25
常に情報を最新化する/更新が楽になる仕組みづくり 26
常に情報を最新化する/更新が楽になる仕組みづくり 27
課題への対処法(情報の最新化) 28 設計書 Bedrockから返された テストケース
4.課題への対処法(情報の最新化) 29
欲しい情報(経緯)を残す仕組みづくり 30 経緯を設計書に残しておくことで「なぜ?」の部分が少なくなる
欲しい情報(経緯)を残す仕組みづくり 31 経緯は参考情報として記載 • 載せすぎると邪魔な情報になる • トグルで表示・非表示を切り替えられるように
4. まとめ 32
まとめ 33 • 課題を見つけてそれを解決するのに生成AIを一つの選択肢として考える → OSSのツールなどで利用できるのを何も考えずに生成AIを使用するのはよくない(お金がかかる) •
ドキュメントとソースコードを近くで管理することで、これからの生成AIアップデートでより活用しやすくなる • 生成AIで開発プロセス・運用フローを楽にしよう!