jev-diagram-lt.pdf

Transcript

1. 構成図の作成に を使ってみた AWS Jev
2. 与那嶺 創（よなみね そう） クラスメソッド株式会社 クラウド事業本部コンサルティング部 ソリューションアーキテクト 2026 Japan AWS Top Engineers 2026 AWS Community Builders 好きなAWSサービス Kiro、Amazon Managed Grafana ピザのアイコンで ブログ書いてます 2
3. みなさんは業務の中で 図を描くことがありますか？
4. 図を描くと頭がスッキリしますよね？ 私は業務で分からないことがあれば、まず図に起こして考えます。 でも、図を描くのをAIに任せたい日もあります。 4
5. ちょっと業務を 覗いてみましょう！
6. Kiro に構成を相談 会議の録音をアップしたら、文字起こしして、 あとでブラウザで読めるようにしたい。 どんな構成がいいかな？ Kiro 録音を S3 に置くと、S3 の通知で Lambda が動き、 Transcribe で文字起こしします。 6
7. 文字起こしは、そのまま読める？ Kiro 完了を EventBridge で受け、Lambda で整形し、 Bedrock で校正して S3 に保存します。 7
8. あとで読むときは？ Kiro 画面は CloudFront から S3 で配信し、 API Gateway（Cognito 認可）経由で返します。 いいね、それでいこう！ 8
9. このやり取りの結果を 図にしてほしい…
10. じゃあ AIに 構成図を描かせてみよう
11. Opus 5.5 に「図を描いて」と頼んでみた ⾳声⽂字起こしの構成（アップロード‧整形‧閲覧） 取り込みと⽂字起こし ⼿元の端末 （aws cli） アップロード ⾳声と会議情報を アップロード 作成のみ ジョブ起動 meta.json ① ② S3 ⾳声バケット AWS Lambda （バージョニング有効） ‧ ルールで起動 ④ Amazon Transcribe ジョブ起動 イベント通知は の作成のみ （プレフィックスと サフィックスで絞り込み） ⾮同期ジョブ （S3⼊⼒‧S3出⼒） Transcribe S3 meta.json incoming/<meeting-id>/ audio.m4a meta.json 完了イベント ③ 校正 ⑤ Amazon EventBridge ⑥ AWS Lambda ジョブ完了イベント Amazon Bedrock 整形‧完了処理 （決定的処理、 話者ごとに結合） 校正（句読点‧ 誤認識の修正、 事実は変えない） 保存 ⑦ S3 結果バケット 会議IDごとに⽣JSON‧ 整形済み‧校正済み版 会議登録 ⑧ Amazon DynamoDB 会議ID‧タイトル‧ ⽇時‧参加者 閲覧（Cognitoで認証） 画⾯の取得 OAC ⑩ Amazon CloudFront S3 ディストリビューション （配信） ブラウザ （閲覧者） ⑬ 参加者判定 静的Webアプリ からのみ読み取り OAC 付き JWT ⑪ 取得要求 ⑫ Amazon API Gateway 、 認可 ⑭ AWS Lambda HTTP API JWT 検証 JWT 閲覧API（参加者か判定、 トークンのemailと照合） S3 ⾮公開バケット ⽂字起こしを保存 ログイン ⑨ Amazon Cognito ユーザープール（Hosted UI、 サインアップ無効、MFA有効） 11
12. 使ったクレジットは… 19.6 クレジット！！ この図に対してこれだけかかるなら、自分で描きます
13. 構成図を作るskillを作ってみた
14. 妥協したくないので skillを細かく調整 要素は同じ高さに揃えて直線でつなぐ 折れ線はアイコンの側面か上面から出す AWSの仕様どおりかを毎回aws-mcpで確かめる 図はSVG（コード）で描くことで静的チェックできるようにした 機械的なチェックを入れてOKになるまで直す 14
15. skill を使って描いてみた ⾳声の⽂字起こしと閲覧Webアプリ構成 (AWS) AWS Cloud Region (ap-northeast-1) ⽂字起こし 静的サイト Amazon Bedrock S3 校正 静的Webアプリ 保存 User S3 ⾳声ファイル AWS Lambda ジョブ起動 Amazon Transcribe Amazon EventBridge AWS Lambda 整形 Amazon CloudFront 閲覧と認証 S3 ⽂字起こし Amazon DynamoDB 会議‧参加者 AWS Lambda ⽂字起こしの取得 Amazon API Gateway Users Amazon Cognito 15
16. で、消費クレジットは？？ 10.7 クレジット
17. もう少しクレジットの消費を抑えたい…
18. 安価なモデルで同じ品質の構成図が描けないか？ 模索してみた
19. やったことは2つ 機械的なチェックルールを 大量に作る サンプルの構成図を 複数用意する 19
20. これで構成図はめちゃくちゃ良くなった
21. Haiku 5.5 に作らせた構成図がこれ ⾳声の⽂字起こしと閲覧Webアプリ構成 (AWS) AWS Cloud Region (ap-northeast-1) ⽂字起こし 静的サイト Amazon Bedrock S3 校正 静的Webアプリ 保存 User S3 ⾳声‧meta AWS Lambda ジョブ起動 Amazon Transcribe Amazon EventBridge AWS Lambda 整形 Amazon CloudFront 閲覧と認証 S3 ⽂字起こし AWS Lambda Amazon API Gateway Amazon DynamoDB Amazon Cognito ⽂字起こしの取得 会議‧参加者 Users 21
22. 消費したクレジットは… 2.49 クレジット の クレジットの、約4分の1でした。 Opus 10.7
23. 機械的にはチェックできない箇所もあった 線の重なりや向き チェックできる 置き場所が正しいか チェックできない 意味的な正しさは、モデルが描画を見て判断しています。 ここに少しクレジットがかかっていると思われます。 23
24. 安価に人間っぽく 判定できるJevを試してみた
25. 安価なモデルで生成して Jevが判定する 安価な モデルで生成 → 静的 チェック による 判定 Jev → だけ 直す NG → 最後は 人が見る 25
26. を入れて クレジットは減った？ 出力は速くなった？ Jev
27. 実験内容 項目 条件 題材 回数 描き方 内容 、 ＋ 、 、 ＋ 文字起こし、RAG、3層Web 4条件 × 3構成 × 3回 ＝ 36回 1回ごとに新しいサブエージェント Opus Opus Jev Haiku Haiku Jev 27
28. 実験結果
29. 私目線で 生成された構成図は どれも合格点でした
30. 文字起こしの構成を 4条件で3回ずつ描いた図 ＋ Haiku Jev Haiku ＋ Opus Jev Opus 30
31. Jev を入れると クレジットは増えた ＋ Opus → Opus Jev +3% ＋ Haiku → Haiku Jev +24% 回あたりの平均クレジットの増え方。 は → 、 は → 。 1 Opus 14.61 15.08 Haiku 2.57 3.19 31
32. Jev を入れても 速くはならなかった 秒 ＋ Opus → Opus Jev +16 秒 ＋ Haiku → Haiku Jev +9 回あたりの平均の所要時間。 は → 秒、Haikuは218→227秒。 1 Opus 196 212 32
33. どちらも Jevの有無で大きな差は出ませんでした Opus 項目 ＋ Opus Opus Jev Haiku Haiku Jev 平均の消費クレジット 14.61 15.08 平均の所要時間 196秒 212秒 Haiku 項目 ＋ 平均の消費クレジット 2.57 3.19 平均の所要時間 218秒 227秒 33
34. 今回の条件においては Haiku + skill > Haiku + skill + Jev でした
35. 考察
36. なぜJevの効果が出なかったのか の評価基準が曖昧だった 静的チェックが充実していた Haiku 5.5が安くて速くて賢かった Jev 36
37. 今回は Haiku 5.5が優勢だった が悪いのではなく、 使いどころとチューニングの問題だと思います。 Jev
38. おしまい