JAWS-UG_AI_ML_LT資料_20260929.pdf

Transcript

1. 社内利用を想定してKiro CrewをPrivate SubnetのEC2に構築してみた 2026/9/29 JAWS-UG AI/ML 支部 〜 JAWS-UG AI/ML #43：AIエージェントとAI-DLCで加速する！AI/ML実践LT大会 〜
2. 自己紹介 ▪名前：岡本 正義（→ジャスティス→ジャス） ▪仕事：某エレベータ製造会社 ▪職種：社内SE ▪AWS歴：３年くらい ▪保有資格：2026 Japan All AWS Certifications Engineers ▪最近頑張ってること：Qiitaの毎週投稿（https://qiita.com/jus1730） ▪好きなAWSサービス：Amplify、Kiro ※本日の発表は個人的な成果に基づくものであり、所属組織を代表するものではありません @jus1730
3. 今回のゴール 普段の業務で AI活用を広めたい チームの業務効率化の推進、生産性の向上 Kiro Crew に注目 会話で頼める “運用アシスタント ”型なら広めやすい Kiro Crewを“社内で使える形 ”にする ローカルではなく、「ちゃんとした置き場所」を用意してあげる
4. Kiro5兄弟 Kiro IDE Kiro CLI 人が主導して Kiroを「コマンド」 開発する場所 として使う Kiro Web & Mobile Kiro Crew Kiro管理のクラウドへ 自分たちの環境に 仕事を任せる Kiroを「住まわせる」 Kiro Crew：Kiro CLI がベースのマルチエージェント運用プラットフォーム
5. Kiro Crew -実際の画面 -
6. なぜ Kiro Crew なのか ① IDEは適さない 現場のニーズは “ガッツリ開発 ” ではなく “業務効率化 ” • コードを常時編集する前提の IDEは、非開発者の日常業務にはオーバースペック • やりたいのは「調査・集計・定型作業の自動化」＝会話で頼めること • ゆくゆくはアラート検知や時間起動などをトリガーに定常業務を任せたい
7. なぜ Kiro Crew なのか ② Web版は適さない 業務データを扱う → インターネット直結・外部 SaaSはハードル高い • 一般公開の Web版に業務情報を通すのは、セキュリティ的に難しい • データもエージェントも “自社が管理する環境 ” に置きたい
8. なぜローカルじゃないのか ① 会社PCにデータを置きたくない 業務データをローカルに残すのは好ましくない ② 会社PCはスペック不足 メモリが足りず、エージェントを常時動かすのは厳しい ③ Windows前提の壁 会社PCはWindowsが基本。だがエージェントはLinux前提の挙動もある →サーバ側に集約して動かすのが素直 Private Subnet に閉じた Kiro Crew を構築してみる
9. 今回の位置づけ まずは 個人環境 で試作 ・なるべく費用をかけない 構成で作る
10. AWS アーキテクチャ図 リソース 役割 CloudFront 単一の入口 (既定ドメイン・PAYG) Lambda@Edge エッジでCognito認証 (viewer-request) Cognito ユーザー認証 VPC origins CloudFront→EC2直結 (ALB不要) EC2 (r6a.large) Kiro Crew 本体 (Private) EC2 (t4g.nano) NAT インスタンス (アウトバウンド) Lambda (ops) EC2の起動/停止
11. 工夫したポイント① ALBレス CloudFront VPC origins で、ALBを立てずに Private EC2へ直接到達 • 従来はALB必須だったが、 VPC originsでCloudFront→Private EC2が直結できる • ALB分の構成とコストが減り、構成がシンプルに • OAC（Origin Access Control）で、EC2はCloudFront経由のみ許可
12. 工夫したポイント② 認証周り Lambda@Edge (cognito-at-edge) で、エッジに Cognito認証を挟む • CloudFrontのエッジで認証チェック → 未認証はCognitoログインへ誘導 • アプリ側に認証を作り込まなくても、手前で守れる • Cognito User Poolでユーザー管理。個人利用なのでユーザーは１人だけ
13. 工夫したポイント③ コスト削減 個人環境は使う時だけ起動 → EC2 の起動・停止をワンクリックで • コンソールから止めたり、スクリプトを流して止めるのは面倒 • 既存の CloudFront + Cognito に /ops ページを相乗り • ボタン → Lambda Function URL → EC2 を起動/停止
14. Tips:メモリ設計の落とし穴 サブエージェントを立てると、 8GiBではメモリ不足で起動できなかった • Crewは“空きRAMが4GB未満なら起動しない ”判断を持つ t3a.large(8GiB)はCrew本体で埋まり空き約 1.4GiB → 拒否 • swapでは効かない。見ているのは物理 RAMの空き RAMそのものを増やすしかない • r6a.large(16GiB)へ変更 → 空き約11GiBで起動成功
15. コスト試算 項目 構成 EC2 Crew r6a.large（2vCPU/16GiB） EBS ① 最大 （常時稼働） ② 個人利用 （200Hr/月） 約 $100 約 $27 gp3 68GB $6.5 $6.5 EC2 NATインスタンス t4g.nano 約 $5 約 $1 その他 CloudFront/Cognito/Lambda等 ほぼ $0 ほぼ $0 約 $110/月 約 $35/月 合計（概算） ※ALB + NAT Gateway の場合： ALB 約 $18/月 + NAT Gateway 約 $45/月 →基本的に常時稼働
16. 社内展開の方針 今回（個人・1人）＝ ✅実証済み 1台のEC2にCrew。CloudFront + Cognito で認証付きHTTPS → 1人分の“認証・到達の型”ができた。これが多重化の土台 社内展開（数十人）＝ 1人1環境へ ECS / EC2複数台でセッション隔離、 Cognitoで振り分け → 共通NAT・IaC化・監査ログを前提に運用へ → 1台のEC2に相乗りは、利用者ごとにkiro-cliログインが必要となり手強い Crew公式もmulti-instanceで”セッションは隔離せよ”としている
17. まとめ ① 業務効率化で AI活用を 社内・非公開なら Kiro Crew × Private EC2 が適切 ② 構成をシンプルに CloudFront VPC origins + Lambda@Edge & Cognito ＝ ALBレスで認証付き ③ ランニングコストを抑える 起動/停止ボタンで使う時だけ課金（常時 約$110 → 個人利用 約$33） ④ 社内展開は最初から分ける 1人1環境でセッション隔離（Crew公式も同じ結論）