触って覚えるAWS - コミュニティを通じて学びのサイクルを作る方法
210 Views
July 04, 26
スライド概要
JAWS-UG 福井の登壇スライドです
Developer
関連スライド
各ページのテキスト
触って覚える AWS コミュニティを通じて学びのサイクルを作る方法 岡本秀高 JAWS-UG福井 / 2026.07.04
自己紹介 Hidetaka Okamoto (岡本秀高 ) ● CircleCI Senior Field Engineer ● AWS Community Builder ( Serverless | 3年目 ) ● AWS CDKをぶん回すのが好きです ● TypeScript / React / Hono / LangChain.js 2
AWS の知識や情報を 効率的に⼿に⼊れる⽅法
AWS Knowledge MCP サーバー
おしまい
ほんとうに？
経験と 結びつかない Knowledgeは 敬遠されがち ● ● ● ● ● ● 机上の空論 コタツ記事 絵に描いた餅 出⽻守 象⽛の塔 事後孔明
Why ?
A: Exception ( 例外 )
理屈だけでは 例外に 弱くなる
ファスト＆スローで考える Daniel Kahneman『Thinking, Fast and Slow』(2011) System 1（速い思考） System 2（遅い思考） 経験に基づく直感的判断 意識的・論理的な分析 エラーログを一瞥して ログを全文読み、ドキュメントを検索し、 候補を列挙し、照合する 「あ、これ DNSだな」 パターンが内面化されているため 意識的な分析を経ずに結論に到達 正確だが、遅くてコストが高い 現在のAIエージェントは、 Sytem1はモデルに依存しがち
人間のSystem 1でAIのSystem 2を指揮する 人間の System 1 「これはDNS周りだ」 ▶ AIのSystem 2 ▶ 高精度 × 高速 DNS関連に集中して 経験 × 網羅性 網羅的に検証 トークン効率も高い 探索空間を劇的に狭める ❌ 「AIに全部調べさせる」 ✅ 「触って覚えた人が AIを指揮する」 探索空間が広すぎて、トークンも時間も浪費する。 System 1なしのSystem 2単独稼働。 経験がSystem 1を形成し、 AIの探索を的確に絞り込む。
⼈間は 何を判断すべきか
AWS Lambda
10年間で1,000本( Qiita / Zenn 除外 )以上記事を書いています 年 100 記事 = 週2記事ペース
自分のブログで記事を書くことに対する「大変さ」 SEO分析 どの記事が読まれているか把握しきれない SNS拡散 どの過去記事を同紹介すればいい・・・？ コンテンツ最適化 要約やタグづけなどがだんだん手間に サーバーとCMS管理 WP本体/プラグインの更新・監視が手間 「記事を書く」以外の作業に 追われると、 書きたいときに 書きたいことが 書けなくなる
執筆に関連した AIエージェント & エージェントを整備 WordPress (EC2) 記事 pub/upd/del ▶ EventBridge Bus: wp-kyoto content-enrichment Lambda +α ▶ 境界線① 記事の後処理 ▶ SNS Topic post-to-x x-post-bot Lambda ▶ + Secrets Manager 境界線② Xへの投稿実施 blog-marketing automation EventBridge日次 → SNS pub
執筆に関連した AIエージェント & エージェントを整備 WordPress (EC2) 記事 pub/upd/del ▶ EventBridge Bus: wp-kyoto content-enrichment Lambda +α ▶ 境界線① 記事の後処理 ▶ SNS Topic post-to-x x-post-bot Lambda ▶ + Secrets Manager 境界線② Xへの投稿実施 blog-marketing automation EventBridge日次 → SNS pub ga-reporter Q: AWS Lambdaの関数は、いくつ作るべきか？
Lambdaひとつでも、考えることは多い 実⾏は⾮同期か同期か -> SNS / EventBridgeを⼊れるか否か？ 記事公開時と、過去記事シェアの２系統でX投稿処理がある、まとめるか？ まとめるなら、どこでコードを共通化？ わけるならば、どこを境界線にして、なにをInterfaceにすべきか？ そもそもLambdaでやるべきか？ Docker コンテナではだめなのか？
AI は情報と視点をくれる。 ただし判断と責任は⼈間のもの
例えばこんなアーキテクチャ W WordPress (webhook) API Gateway Lambda A 記事取得 SNS Topic content-ready filter:immediate Lambda D 過去記事選定 EventBridge Scheduler filter:なし(全件) X S3 Vectors embedding Lambda B ベクトル化 Lambda C 投稿処理 投稿先 (X等)
みんな どうしてるんだろう？
まずは 公式の ベスプラ に倣う https://aws.amazon.com/jp/architect ure/well-architected/
https://aws.amazon.com/jp/architecture/well-architected/
Serverless Lensの設計原則（一部・意訳版） ⾼速、シンプル、単⼀、そしてステートレス イベントを利⽤してトランザクションをトリガーする 障害だけでなく、重複実⾏も想定する 総リクエスト数ではなく、同時リクエスト数にて設計する
理解を深めることで、AIへの「問い」が深くなる
IaC管理とCI/CDで、気軽に検証できる状態を作る
そして 気軽に突然 壊れる
動かしてみる、失敗してみることでしか学びは得られない 失敗したことはそのまま学びになる うまく⾏ったことは、⾃信になる 「とりあえず試してみる」ことのコスパは意外とよい だから某C社や某K社とかがアウトプットを⼤量にやる
学習そのものを継続して積み増していく姿勢が、 長く現場で使える力になる。 ―『達人プログラマー』知識のポートフォリオ
学びはアウトプットから始まる～対話型社会の時代の新たな学び方～ https://www.works-i.com/research/report/item/wr2019_012.pdf
https://www.works-i.com/research/report/item/wr2019_012.pdf
アウトプットのコツは、難しく考えないこと ● 自分のために書く ○ 困ったこと ○ 頑張ったこと ○ ドヤりたいこと ● 自分以外読まないと思って書く ○ 読まれるか不安だから書けなくなる ○ 読まれない ■ 読まれたくないのだけ読まれる ○ 好き放題やってる深夜番組のつもりで
Q: アウトプットが歓迎され、 その直後にカジュアルな形で フィードバックを聞く場もある そんな都合のいい場所とは？