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
94
第151回 雲勉 プロジェクトのドキュメントにおける課題をAmazon Bedrockで解決してみる
下記、勉強会での資料です。
https://youtu.be/CeN9sHB9GnA
iret.kumoben
January 17, 2025
Tweet
Share
More Decks by iret.kumoben
See All by iret.kumoben
第168回 雲勉 JITNAの使い方とハマったポイントについて語る回
iret
0
13
第167回 雲勉 エージェント開発を加速する Agent Development Kit 入門
iret
1
25
第166回 雲勉 コードを読んで理解する AWS Amplify Gen2 Backend
iret
0
29
第165回 雲勉 Google Agentspace について
iret
0
24
第164回 雲勉 Agent Development Kit と MCP Toolbox for Databases で MCP 連携してみた
iret
1
45
第163回 雲勉 CircleCIで複数リポジトリ間のパイプラインを連携する
iret
1
35
第162回 雲勉 比較して学ぶ AWS Amplify Gen 2
iret
0
49
第161回 雲勉 Amazon Kinesis Data Streams と Amazon Data Firehose を使ってみよう
iret
0
47
第160回 雲勉 それ、AWS Step Functions で置き換えれん?
iret
0
74
Other Decks in Technology
See All in Technology
Core Audio tapを使ったリアルタイム音声処理のお話
yuta0306
0
170
SmartNewsにおける 1000+ノード規模 K8s基盤 でのコスト最適化 – Spot・Gravitonの大規模導入への挑戦
vsanna2
0
110
生成AIで小説を書くためにプロンプトの制約や原則について学ぶ / prompt-engineering-for-ai-fiction
nwiizo
6
3.9k
KiCadでPad on Viaの基板作ってみた
iotengineer22
0
260
GeminiとNotebookLMによる金融実務の業務革新
abenben
0
250
AWS認定を取る中で感じたこと
siromi
1
150
How Community Opened Global Doors
hiroramos4
PRO
1
140
Connect 100+を支える技術
kanyamaguc
0
170
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
2
15k
Flutter向けPDFビューア、pdfrxのpdfium WASM対応について
espresso3389
0
110
一体いつからSRE NEXTがSREだけのカンファレンスだと錯覚していた? / When did you ever get the idea that SRE NEXT was a conference just for SREs?
vtryo
1
140
「Chatwork」の認証基盤の移行とログ活用によるプロダクト改善
kubell_hr
1
240
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
22k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
730
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
The World Runs on Bad Software
bkeepers
PRO
69
11k
Practical Orchestrator
shlominoach
188
11k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
17
950
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
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で開発プロセス・運用フローを楽にしよう!