IntroductionPotty training can be quite a trial for parents. Our family was no exception—we were stuck. At daycare our child could go frequently, but at home the toilet was boycotted. Sometimes the motivation appeared, but it just wouldn’t stick as a habit. That’s when I thought, “If this is a motivation problem, maybe a little ‘mechanism’ could change the situation,” which became the spark for this project.There are plenty of commercial potty-training products, but kids get used to them quickly and the motivation fades. So I decided to make an original device that shows a favorite animal character and praises the child. If the novelty wears off, I can add more animal variations—or switch to vehicles or something else—so the device can keep their interest almost indefinitely.It also happened to be a period when I was evaluating Kiro (an AI IDE), and I wanted to test its capabilities. I usually develop web applications and rarely do embedded development with hardware, but I hoped that with AI’s help I could pull it off.In the end, I could rely on Kiro far more than expected and let AI handle almost every step. From tech selection and implementation to debugging—and even generating images and audio—what would normally take a few days was finished in about an hour on a Sunday morning. That was astonishing.In this post, I’ll review the development process, share what it was like to build with Kiro, highlight where human judgment matters, and reflect on what AI-driven development could look like going forward.It’s a “Potty-Training Cheer Device” using an M5Stack Grey. It’s a palm-sized gadget packed with features kids love.The usage is simple: when the child succeeds at the toilet, they press a button. Then an animal character (rabbit, penguin, or cat) appears at random on the screen and plays a sound.The UI is in Japanese, with easy-to-read hiragana like “といれ できた？” (“Did you use the toilet?”) and “すごい！” (“Great!”). Even if they haven’t learned hiragana yet, hearts and star symbols are displayed so they can still react to those in addition to the animals.Functionally, the device automatically counts successes and saves the count to EEPROM, so the record persists even if power is turned off. On special counts—first time, fifth time, tenth time, etc.—a celebratory screen with a rainbow background is shown to help maintain motivation.For practicality, I added a volume control, a battery level check, and a long-press reset. The battery check was especially helpful while I was still getting used to the M5Stack; when behavior seemed odd during development, I could quickly assess the state by pressing the left and middle buttons simultaneously.I kept the operation as simple as possible, used clear Japanese for the display, and chose catchy electronic sounds—prioritizing usability from a child’s point of view.This time I took the reverse approach from typical development. Normally, a human would prepare some requirements and development policy—say, in a file like AGENTS.md . But to test Kiro’s abilities, I intentionally prepared nothing. I started only by telling it that I wanted to make a potty-training device for my child, that I had an M5Stack Grey, and roughly how old the child is.Kiro is known as an “AI IDE that’s good at planning,” so I expected a structured spec-writing process like:Requirements (requirements.md) — user stories and EARS-style acceptance criteriaDesign (design.md) — architecture, data flow, and rationale for tech choicesImplementation plan (tasks.md) — stepwise implementation and task breakdownIn practice, Kiro chose a more hands-on approach rather than waterfall-style documentation.I can only speculate about the reasons:No explicit request to write specs — My vague “I want to try Kiro’s capabilities” may not have triggered a formal spec process.Prototyping context detected — It likely recognized this as a personal, experimental project and avoided heavyweight enterprise-style process.Reading my expectations — It might have sensed “I want something working quickly,” prioritizing implementation over documents.Learned behavior as an AI IDE — From similar projects, it may have learned that implementation-first often yields higher satisfaction for solo developers.Looking back, it felt appropriate. If we had started with a detailed requirements doc, we might have wasted time on unknowable questions like “a UI kids will love” or “electronic tones that resemble animal calls.” Those are better answered by building and testing.That said, we didn’t fully exploit Kiro’s strength in planning. Ideally we could have done structured spec → staged implementation to leverage Kiro’s advantages.Instead of large requirements and design docs, Kiro created lean, practical docs incrementally:setup.md — concrete steps for environment setuptesting.md — how to verify behavior and debugvoice_creation.md — automating voice file generationimage_preparation.md — image generation and format conversiontroubleshooting.md — common issues and fixesThis was spot-on for solo prototyping. In a big company, requirements and design docs matter; for a small one-person prototype, “how to set up,” “how to test,” and “what to do when things break” are far more valuable.Rather than perfect docs first, we organized information as working code emerged. When we needed sounds, we created voice_creation.md . When “Mac doesn’t recognize the device,” we expanded troubleshooting.md .It felt like Kiro understood my development style and context and chose an optimal approach. Whether that was intentional or simply a bias toward implementation is hard to say.One thing I noticed: the reasons behind Kiro’s choices aren’t always clear. I can’t tell whether it chose implementation-first due to nuanced situational judgment or simply because code generation is a strong suit. This opacity can be a challenge in AI-driven development, where a human developer would normally explain their rationale.We started with the vague idea of “a gadget where pressing a button does something.” As Kiro proposed features and I saw them working, more concrete requirements surfaced.Kiro built something minimal, I tried it, then I gave feedback. For example, the “smart random” logic—preventing the same character from appearing twice in a row—came from me noticing during testing that kids might get bored without change.The long-press reset was also my suggestion, considering I’d be developing on the same device I’d be using in real life.Traditional development fixes requirements (to some degree) before implementation. Kiro suggested, “Let’s build the basics first and improve as we go.” That proved highly effective. Seeing something real made it easy to spot improvements like “use larger text here” or “a volume control would help.”Especially in solo projects, the motivation to “just make it run” can outweigh careful up-front planning. This approach created a positive loop: get it running fast, then keep improving.Kiro generated everything consistently—from PlatformIO settings and C++ for M5Stack to Python scripts for image generation. I didn’t write a single character of code.It selected and configured appropriate libraries: M5Stack libraries, ESP8266Audio for audio playback, and SPIFFS for the filesystem. The platformio.ini—from board selection to library dependencies—was completed without my intervention.We added fallbacks when asset files were missing and handled audio playback failures—folding in feedback from real-device testing.The implementation accounted for the ESP32’s limited memory: proper freeing of dynamically allocated memory, chunked reads for large files, and other embedded-specific considerations.Automatic generation for images and audio was especially helpful.Finding or crafting assets takes time, so automation was practically a must-have. It also matters for future extensibility when adding more assets.At first I planned to render Japanese text like “といれ できた？” and “すごい！” directly on the M5Stack. But out of the box, M5Stack can’t display Japanese fonts without extra libraries.While Kiro initially claimed “this will display Japanese,” it was garbled. I directed it to follow a blog post to support Japanese, but after multiple failed attempts, I pivoted: “Let’s render the text to images instead,” which avoids Japanese font support on-device. Kiro then generated a Python script to produce BMPs that display well on M5Stack. For a personal, kid-facing project, pixel-perfect beauty wasn’t required—the results were readable and “good enough.”I asked for automatically generated animal-like calls—but this fell short of expectations.Kiro synthesized plausible effects in Python, but they didn’t quite sound like animal calls. It tried techniques like ADSR envelopes for natural attack/decay and frequency changes tailored to each animal’s “character,” but in the end, the sounds didn’t truly feel like calls. Still, I appreciated the attempt to generate audio mathematically without external libraries.It also generated spoken lines like “すごい といれ できたね” as audio files.The loop of “run what Kiro built → test → give feedback” progressed as follows:Initialize the PlatformIO project — M5Stack-specific configurationBasic display — simple “Hello World”-level verificationAudio playback — play a simple audio fileImage display — show Japanese text as imagesRandomization — character selection logicPersistence — saving success countsSpecial features — celebration screen and battery checkThe beauty of this flow: you have something working at each stage. If text appears on the M5Stack screen, wiring is likely correct. If sound plays, the speaker and library settings are likely correct.Kiro consistently took the “get it working first, then improve it” approach. Rather than chasing perfection, it raised quality step by step—very much like an experienced developer.That human-like flow kept collaboration smooth. Kiro didn’t try to create a perfect solution in one shot; it suggested iterative steps. When problems occurred, its behavior resembled an experienced engineer: investigate based on the symptoms I shared, fix the issue, and document it—exactly how you’d want someone to handle a bug ticket.Working incrementally with continuous verification felt like pairing with a human developer, giving me a glimpse of a new mode of AI pair programming.Not everything should be left to AI. There were several moments where human judgment mattered.Kiro proposed many features, but humans must set priorities. We adjusted the implementation order based on child usability and actual need, even though features like Wi-Fi connectivity and cloud sync sounded attractive.For potty training, Wi-Fi isn’t essential; reliability and simplicity matter more. Practical choices—handling dead batteries or preventing accidental resets—trumped data sync.Humans are best at imagining real usage contexts and balancing technical possibilities with real-world constraints. That role still belongs to us.The M5Stack has unit variance; SPIFFS has size limits; power management has quirks. These are things you only notice on real hardware. A human needs to observe them and report back to Kiro.For example, when a heart image didn’t display, I first suspected code issues. But it turned out SPIFFS might not have uploaded the file correctly. After I shared serial logs and error messages, Kiro proposed stepwise debugging, and we solved it by adding file-existence checks and fallbacks.This kind of cooperation—human observation on a real device plus AI-suggested fixes—worked very well.Color choices, layout, and sound length—these sensory judgments were made by me. Kiro can implement technically correct solutions, but the question “Will a child enjoy this?” is where human sensibility shines.The initial effect sounded like a warning beep—attention-grabbing but not pleasant. Noticing and adjusting that is still a human strength.Compared to conventional development, several areas improved dramatically—especially the time from initial research to a working prototype.How to use the M5Stack, set up PlatformIO, and work with ESP8266Audio—Kiro provided the right information instantly, not just API references but project-ready sample code. I could move straight to verification.It also covered tricky integration details that usually bite beginners—like memory management when using ESP8266Audio with SPIFFS and settings for the M5Stack’s built-in speaker.The “get something working” phase was vastly faster. Kiro generated basic functionality in minutes, and I could test on the M5Stack right away.Previously, I’d have to hunt for sample code, adapt it, resolve build errors, and so on. This time, I started with runnable code and focused immediately on validating features.Image generation, audio generation, format conversion—tasks that normally require separate tools or manual work—were delivered as automation scripts.For example, the script that converts Japanese text into M5Stack-friendly BMPs handled font choice, sizing, background color, and format conversion. Otherwise I’d have been manually crafting each image in an editor.This project made me feel how impactful tools like Kiro can be on development. Especially for solo work and small prototypes, AI can dramatically improve efficiency.Hardware projects used to feel daunting—particularly for those without embedded experience. With AI helping from tech selection to implementation, even web engineers can take on hardware.At the same time, the importance of human decisions became clearer: defining requirements, prioritizing, judging quality—especially designing from the actual user’s perspective (in this case, a child). With the right division of labor between AI and humans, we can make better things.What intrigued me most was not just the technical implementation, but how AI also raised the product’s overall completeness—image generation, voice synthesis, and documentation included. It suggests that even solo developers can ship something reasonably polished, quickly.This started as a small, everyday parenting challenge—potty training—but turned into a great hands-on exploration of the possibilities and challenges of AI-driven development. Most importantly, from the very day we finished, our child started going to the toilet. They’re eager to press the button—“Can I press it?”—and it’s clearly boosting motivation. I truly felt how technology can improve parenting.As technology advances, the distance from idea to implementation keeps shrinking. Little sparks like this can now take shape in just a few hours over a weekend. That means many more opportunities to unleash individual creativity—and many more diverse, delightful products appearing in the world.

Solving Parenting Pain Points with Generative AI — A Potty-Training Support Device Built with Kiro and M5Stack

はじめに子どものトイレトレーニング、親にとって結構な試練です。我が家も例に漏れず、トイトレ停滞中でした。保育園では高頻度でトイレに行けているようですが、家のトイレはボイコット。たまにやる気を出してくれるときもありますが、なかなか習慣化しません。そんな時、「これはやる気の問題だろうから仕掛け作ったら状況変わるかも」と思い立ったのが今回の開発のきっかけです。市販のトイトレ用品も色々ありますが、きっとすぐに慣れてモチベーション戻っちゃいそう。それなら、子どもの好きな動物キャラクターが出てきて褒めてくれる、オリジナルの装置を作ってみようと考えました。そして、飽きたり慣れてきたらその動物の...

生成AIで子育ての困りごと解決 - KiroとM5Stackで作るトイレトレーニング支援デバイス

IntroductionIf your goal is to compress the design → release → improvement loop and ship an MVP as fast as possible, a pragmatic approach in 2025 is to lean on three AWS tools that work well together.Amplify Gen 2A code-first platform where defining requirements in TypeScript (data models / auth / functions) automatically provisions the AWS resources you need.KiroAWS’s agentic AI IDE (preview) that runs the pipeline end-to-end: spec → design → coding → tests → documentation.Amazon Q DeveloperYour IDE “pair-programmer” for code understanding, doc/test generation, and design guidance.This article explains how to combine these three to shorten the path to MVP for both startups and enterprise innovation teams.Amplify Gen2 puts the “write requirements in TypeScript = the infra stands up” experience front and center. From your laptop, npx ampx sandbox launches a personal cloud sandbox; changes under amplify/ are applied in real time (via CDK hot-swap). You also get full-stack PR previews per pull request.Key takeaways:In the first few days, you can keep the requirements ↔ implementation loop unbrokenUse Sandbox + PR previewsFuture headroom is handled with CDKGen2 is continuous with CDK, so extensions live in the same repositoryDocs:https://docs.amplify.aws/react/deploy-and-host/sandbox-environments/setup/https://docs.amplify.aws/react/deploy-and-host/fullstack-branching/pr-previews/https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/pr-previews.htmlFor a small team, being up and running in ~30 minutes is a big deal. A Japanese health-tech startup, KAKEHASHI Inc., publicly documented how they hosted multiple apps on Amplify Console, offloading CI/CD and hosting to AWS and shortening their development cycle. It predates Gen2, but the hosting × CI/CD value carries over today.On costs, there’s a tailwind: new accounts get up to $200 in Free Tier credits, which materially lowers the cost of learning and early experiments.Refs:https://aws.amazon.com/jp/blogs/startup/casestudy_kakehashi/https://aws.amazon.com/jp/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan/If you need multiple PoCs running in parallel across departments, create owner-scoped sandboxes and institutionalize “build and discard.” With ampx sandbox, every save is applied immediately, so requirement validation moves fast.Governance hinges on the fact that Gen2 backends are CDK-based. That aligns cleanly with Control Tower / GuardDuty and lets you add VPC / PrivateLink / legacy integrations in the same stack. The flip side: Amplify’s autogenerated resource names can be noisy in audit logs—define naming conventions and tag standards up front and wire them into CI.Costs follow the startup case: the Free Tier credits are handy for early exploration at the department level.Refs:https://docs.amplify.aws/react/deploy-and-host/sandbox-environments/setup/https://aws.amazon.com/jp/about-aws/whats-new/2025/07/aws-free-tier-credits-month-free-plan/Amplify AI Kit adds AI routes—Conversation and Generation—as TypeScript definitions. In minutes, you get a front-end scaffold and a Bedrock connection. The design is intentionally TypeScript-first, not a one-off magic CLI incantation.Fastest setup:Scaffold with npm create amplify@latestReflect changes instantly with npx ampx sandbox (hot-swap)Add AI routes in TypeScript and wire up BedrockIterate using the previewRefs:https://aws.amazon.com/jp/blogs/news/build-fullstack-ai-apps-in-minutes-with-the-new-amplify-ai-kit/https://docs.amplify.aws/react/ai/https://docs.amplify.aws/react/deploy-and-host/sandbox-environments/setup/Let’s recap what each tool owns:Kiro — draws the blueprint and work planSpec-driven pipeline that runs requirements → design → coding → tests → docs end-to-end-MCP support to connect external knowledge bases and tools (preview)Amplify — the land and utilities to run itHosting, CI/CD, auth, data, plus Sandbox and PR previews to keep the loop turningAmazon Q Developer — your teammate on the groundCode understanding, doc/test generation, design guidanceIn short: Kiro drives design→code aggressively forward, but where you run it safely is a separate question. Amplify gives you a production-grade cloud execution base quickly, and Q Developer keeps daily improvements flowing. Together, they close the design → release → improvement loop.A minimal example flow:Scaffold: npm create amplify@latest and write backend requirements in TypeScriptInstant verify: npx ampx sandbox and hot-swap on every saveReview: use full-stack PR previewsAdd AI: define AI routes with Amplify AI Kit in TypeScript and connect BedrockThicken in the IDE: firm up specs/tests with Kiro; generate docs/tests with Amazon Q DeveloperStartups can accelerate hypothesis testing with Amplify + AI Kit, and Free Tier credits make new bets cheaper.Enterprises can balance speed × governance with owner-scoped sandboxes plus naming/tag standards.Kiro (design) × Amplify (execution) × Q Developer (improvement) shortens the distance to MVP. They’re complementary, not substitutes.

Fastest MVP with Amplify Kiro Amazon Q Developer —Practical playbook for startups and enterprise innovation teams—

はじめに「設計 → リリース → 改善」のプロセスを最速で実施する、つまり最短MVPを実施するための方法としてAWSの3つのツールを使う方法を見ていきましょう。2025年時点で、AWS縛りで最短でプロトタイプを動くものにするなら、このツールの組み合わせが考えられます。Amplify Gen 2TypeScriptで要件（データモデル／認可／関数）を書けば、必要なAWSリソースが自動でそろう“コードファースト”基盤KiroAWSが提供するAgentic AI IDE（プレビュー版）仕様（Spec）を中心に、設計 → コーディング → テスト → ドキュメント作成...

Amplify × Kiro × Amazon Q Developerで最短MVP：スタートアップと大企業における実戦設計

現在、以下のようなキャンペーンが実施されているのでAmazon Q CLIを試してみました。https://aws.amazon.com/jp/blogs/news/build-games-with-amazon-q-cli-and-score-a-t-shirt/「技術知識ゼロ」でもゲームが実際に作れてしまうレベルでした。動画収録のために使ったQuickTime Playerの録画停止のショートカットを知っているか、が一番難易度が高いのではと思うくらいです。 環境構築こちらの記事の「ステップバイステップガイド」にあるStep 2の手順を実施します。「開発環境構築」というよりも...

Amazon Q CLIで技術知識ゼロでゲームを作ってみる

When AWS Amplify debuted in 2017, even “just adding a login page” meant wrestling with CloudFormation templates and IAM policies. Eight years of steady releases have chipped away at those manual chores and debugging marathons. Today you can spin up a prototype on par with well-known SaaS products—often in a single weekend—using Amplify alone.This post walks through that journey, highlighting what each release simplified and which kinds of products suddenly became feasible. Use it as a retrospective or as a compass for planning your own adoption.Year-MonthFeature UpdateWhat It UnlocksProduct You Can Now Ship FastHow We Did It Before2017-11Amplify CLIOne-command creation of Cognito, API Gateway, S3, etc.Todoist-style auth-enabled task tracker MVPHand-written SDK calls plus IAM policies2018-11Amplify Console (CI/CD & Hosting)git push → build → CloudFront deployDeveloper docs updated dailyWire S3, CloudFront, CodePipeline by hand2019-12DataStore (offline sync)Managed diff sync between device & cloudWhatsApp-like chat / field-inspection appIndexedDB / SQLite and custom sync layer2021-11GraphQL Transformer v2@primaryKey, @index, etc. for complex modelsShopify-style multi-tenant SaaSEdit resolvers & hand-manage DynamoDB GSIs2021-12Amplify Studio × FigmaAuto-gen React components & mock dataSquarespace-like LP builderRecreate in Storybook, compare screenshots2022-11Next.js SSR / ISR SupportProd-ready SSR/ISR after next buildAirbnb-like search UICraft Lambda@Edge & CloudFront configs2023-06Monorepo (Nx / Turborepo) SupportDiff builds + caching across workspaceUber-style micro-frontendsMany Amplify apps & too many webhooks2024-05Amplify Gen 2 (GA, code-first)Type-safe DB/Auth/Func in a TS fileNotion-like permissioned docsCloudFormation nesting nightmares2024-11Amplify AI Kit (Bedrock)Chat/summary in a few lines of codeDuolingo-style AI explainer modeDIY API Gateway → Lambda → Bedrock2025-03WAF IntegrationOne-click OWASP rule setsPayment-ready e-commerceExternal CloudFront-WAF stack2025-03Deploy Skew ProtectionAuto pin clients to one JS versionTikTok-scale SPA updatesS3 versioning + header gymnastics2025-05Upgraded Build InstancesLarge/XLarge build nodesAstro / huge monorepos build fastFixed 8 GiB / 4 vCPU time-outsThe CLI collapsed the Cognito, API Gateway, and S3 boilerplate into an interactive wizard. Even Amplify first-timers could build a login-ready web app in half a day. Most important: the CLI autogenerates least-privilege IAM roles, eliminating the old routine of chasing 403s and puzzling over stray 500s in CloudWatch logs.      Connect your GitHub repo and Amplify wires up build, test, deploy, and global CDN caching. A merge to main shows up worldwide within minutes—perfect for daily-updated docs sites. Before this, every release meant manual S3 uploads, CloudFront invalidations, and the occasional “white screen” due to stale JS.      DataStore automates diff sync and conflict resolution between local storage and AppSync. You can now build offline-first field apps or chat systems that replay queued changes once a signal returns. Custom implementations once burned days on timestamp collisions and edge-case testing.      With directives like @primaryKey and @index, intricate schemas live entirely in GraphQL. Design docs are code, so no more “What does the real table look like?” meetings. In v1 we edited resolvers by hand, added GSIs, and watched CloudFormation templates balloon until code reviews stalled.      Import a Figma design into Amplify Studio and out comes React components plus mock data. Designers tweak colors or spacing; a pull request appears moments later. The Storybook-screenshot-manual-fix loop that used to choke sprints is gone.      Amplify Hosting officially supports Next.js 12/13, so SSR, ISR, middleware, and image optimization all “just work” after next build. Dynamic-inventory e-commerce and travel sites can now manage cache lifetimes in seconds without caring about Edge Lambda order or us-east-1 quirks.      Amplify detects npm/Yarn/pnpm workspaces, Nx, or Turborepo setups, then runs diff builds with caching. One repo holds shared code, types, and libraries; multiple SPAs flow through the same pipeline. We used to duplicate Amplify projects and hit GitHub’s webhook limit—maintenance hell.          docs.aws.amazon.com          Amplify Gen 2 (2024-05)Define data models, auth rules, and functions in TypeScript and deploy—type safety end-to-end. Business logic and schema live together, making reviews and refactors painless. Field-level permissions à la Notion are doable without touching CloudFormation.      Bundled chat UI components and typed clients let you call Amazon Bedrock LLMs in minutes. Combine history, summaries, and feedback to prototype a Duolingo-style learning app in a few days. The old stack—API Gateway→Lambda→Bedrock plus CORS and token juggling—is history.      Choose a Web ACL in the console and SQLi/XSS protections snap on in minutes. PCI-DSS-grade e-commerce now needs no extra CloudFront layer. Previously we juggled external WAF stacks and risked downtime at every CNAME switch.  During rolling deploys, browsers are pinned to one JS bundle, preventing “white screens” even under high-frequency releases. We used to cobble together S3 versioning and custom headers, and 404s still leaked through.      Large (16 GiB/8 vCPU) and XLarge (32 GiB/16 vCPU) build nodes slash wait times for Astro sites and giant monorepos. Pricing scales by build-minutes × instance factor, so you can upsize only for monthly big releases and stay cost-efficient. Goodbye to endless timeout retries.      Year after year, Amplify has folded one more “time-sucking chore” into a managed feature. By 2025 it’s a weekend-friendly platform for spinning up prototypes that feel like production-grade SaaS. Hope this timeline helps you map the landscape and pick the right entry point for your own projects.

AWS Amplify Evolution Timeline — 2017 to 2025

AWS Amplifyが世に出た2017年、まだ「ログイン機能を付けるだけ」の開発でもCloudFormationとIAMに翻弄されていた開発者は少なくありませんでした。それから8年あまり、毎年のアップデートは“手作業とデバッグに費やす時間”を少しずつ奪い取り、気がつけばAmplifyだけでも有名サービス級のプロトタイプを立ち上げられる環境が整いました。本記事では、その軌跡を「機能が増えた瞬間に何が楽になり、どんなプロダクトが短期間で形になったか」という観点で時系列にまとめています。振り返りの指針や導入判断の材料として、ぜひ活用してみてください。年月機能アップデート新しく出来...

AWS Amplify 進化年表【2017〜2025】

AWSにはアプリケーション開発を支援するツールとして、AWS App Studio、Amplify Gen1、Amplify Gen2の3つがあります。一見すると「同じようなものが3つ乱立している」と見えることもあるでしょう。一部の情報だけを比べると似ているように思えるかもしれませんが、実はそれぞれに明確な違いがあり、適したユースケースが異なります。本記事では、この3つのツールの特徴や違いをまとめ、どのような場面でどのツールを選ぶべきかを解説します。まずは、それぞれの概要を簡単に見ていきましょう。 1. AWS App Studio：迅速なプロトタイピングを実現https:...

AWS App Studio、Amplify Gen1、Amplify Gen2の違いまとめ

This article is an English translation of "AWS Amplify Gen2への道標：Gen1からの“考え方シフト”でAWS連携型の現代的フロントエンドCI/CD基盤へ" which was originally published in Japanese.Hello everyone, this is Ikeda (@ikenyal)—an AWS Community Builder, AWS User Group Leader, and core member of the Amplify Japan User Group. I serve as an EM at GENDA Inc. and as Director/CTO at ZINE Inc.Here, I’ve compiled information that may help those who’ve been using Amplify Gen1 for a long time and are now considering migrating to Gen2.There may be plenty of people who have been using Amplify by just “clicking a few buttons to deploy” and called it good. But now that we’re moving into a new generation—“Gen2”—let’s explore Gen2-specific concepts and setup methods that differ from the past.Amplify, which was once mainly a simple hosting and deployment tool, has evolved into a more modern CI/CD platform in Gen2. Its integration with AWS resources such as CloudFront, S3, and IAM is clearer, enhancing extensibility, speed, and security.In this article, I’ll introduce key points you should know when moving from Gen1 to Gen2, along with links to official documentation and other reference materials. Lastly, I’ll touch on a much-anticipated new update: WAF support, which was just implemented a few days ago.If you’ve been mastering Gen1 but haven’t yet tried Gen2, I hope this provides that “Aha, so that’s how it works!” moment.Gen1:For many users in the Gen1 era, the main approach was: “Deploy following a set pattern prepared by Amplify.” It was easy and straightforward, but as operations grew more complex, you may have felt the limitations of scalability and flexibility. Some users managed advanced setups by extending Amplify as far as possible, but that took a certain level of expertise.Gen2:With Gen2, Amplify has evolved into “a highly tunable service that’s part of the broader AWS infrastructure.” Integration with AWS resources like CloudFront, S3, and IAM is more transparent, making it easier to handle monorepo structures and more complex projects. The build and deployment processes have been updated, and improved caching strategies and environment variable management have greatly boosted performance, scalability, and operability.In short, think of Amplify not just as a “simple hosting tool,” but rather as a “CI/CD platform that integrates seamlessly with AWS, enabling fast and flexible frontend operations.”References:  AWS Amplify Hosting - User GuideIntroducing the Next Generation of AWS Amplify’s Fullstack Development ExperienceGen1:You might have worried about performance lags as traffic increased, and experienced longer build times. The caching strategy was limited, so in projects with complex dependencies, inefficiencies could be quite noticeable.Gen2:Gen2 introduces a completely redesigned build and deployment system, supporting fast, stable operations even for monorepo structures and multi-framework projects. An intelligent caching strategy is introduced to avoid rebuilding unchanged parts, reducing build times. Plus, with CDN optimizations via CloudFront and compatibility with modern toolchains, it can handle significant simultaneous user traffic without noticeable response delays.Key Mindset Shift:In Gen1, you might have been “building and deploying everything,” whereas in Gen2, you’ll think “build and deploy only what’s changed for a faster release cycle.”Gen1:Many operations relied on amplify.yml for build commands and environment variables, but flexibility was limited. Managing environment variables or controlling caching could be challenging in more sophisticated scenarios.Gen2:The build process is more refined, and handling environment variables and cache strategies has improved. Settings from Gen1 might not transfer directly to Gen2, so it’s essential to review and align with the official docs. By doing so, environment variables can be managed more safely and clearly, and appropriate cache policies can help shorten build times and optimize deployment flows.Key Mindset Shift:Instead of “we’ll just fit into the environment provided,” think “let’s tune Amplify’s settings to match our own build and deployment requirements.”Gen1:IAM roles and policies were often handled behind the scenes. Aligning with more complex requirements meant you might have to dive into CloudFormation directly, which could be daunting.Gen2:It’s now easier to understand and apply IAM and permission settings via the Amplify CLI or console. In addition, when integrating Amplify with backend services like GraphQL API, Lambda, and DynamoDB, Gen2 has further optimizations, making it easier for developers to focus on business logic and UX improvements.Key Mindset Shift:Move from “managing permissions within Amplify’s unique environment” to “seamlessly using AWS standard permission management through Amplify.”Gen1:Amplify was somewhat of a “black box.” You could use it without really understanding AWS resources, but you’d quickly run into limitations if you needed significant customizations.Gen2:Amplify is most effective when viewed as part of your wider AWS infrastructure. You can now fine-tune cache and security settings, set up redirects or headers for specific paths, and more at the AWS resource level (CloudFront, S3), leading to a better user experience and improved SEO.Key Mindset Shift:Reframe your thinking from “Amplify = a simplified gateway to AWS services” to “Amplify + AWS as a comprehensive CI/CD platform.”Moving from Gen1 to Gen2 might sound like a hassle, but think of it as the perfect chance to review your entire project. This could include:Improving your CI/CD pipelineReconsidering your testing strategyOptimizing the staging and production deployment flowBy stepping away from the “it works for now” mentality, you can build a more efficient, modern development and operational environment.You can minimize risk by taking a step-by-step approach based on official documentation. Embrace the excitement of adopting the “next generation of AWS hosting” as you go along.Finally, let’s introduce a hotly anticipated topic in the Amplify community. On December 18, 2024, Amplify Hosting gained WAF (Web Application Firewall) support. Previously, you had to manage WAF separately—like applying it through CloudFront on your own or leveraging solutions outside of Amplify. But now, you can directly apply WAF policies to Amplify Hosting itself.This simplifies defense against common web attacks (SQL injection, XSS, etc.) using Amplify alone.References:  GitHub Issue #36 regarding Amplify Hosting WAF supportAWS WAF Official DocumentationGen2 transforms Amplify into a faster, more flexible AWS frontend CI/CD platform.Multiple improvements have been made in performance, scalability, build processes, environment variable management, and permission handling.Viewing Amplify as an integral part of AWS—and optimizing resources at the AWS level when needed—will be crucial going forward.With WAF support added on December 18, 2024, Amplify offers even more robust security out of the box.Building on your existing Gen1 knowledge, leverage the official guides and documentation to make the leap to Gen2. It’s more than a simple version upgrade—it’s a new frontier in frontend development and operations. This is the perfect opportunity to explore Gen2—give it a try and experience the potential for next-level, modern workflows!

A Roadmap to AWS Amplify Gen2: Shifting Your Mindset from Gen1 to a Modern, AWS-Integrated Frontend CI/CD Platform

こんにちは、AWS Community Builder 兼 AWS User Group Leaders 兼 Amplify Japan User Group運営メンバーの池田 @ikenyal です。株式会社GENDA でEMをしつつ、株式会社ZINE で取締役CTOをしています。!本記事は GENDA Advent Calendar 2024、AWS Community Builders Advent Calendar 2024 及び AWS AmplifyとAWS×フロントエンド #AWSAmplifyJP Advent Calendar 2024 の21日目の記事です。本...

AWS Amplify Gen2への道標：Gen1からの“考え方シフト”でAWS連携型の現代的フロントエンドCI/CD基盤へ

This article is an English translation of "持続可能なコミュニティ運営を目指して〜Amplify Japan User Group 2023年の運営体制改善" which was originally published in Japanese.Hi, I'm @ikenyal, AWS Community Builder, AWS User Group Leaders and Amplify Japan User Group Steering Member. I work as an EM at GENDA Inc. and as a Director, CTO at ZINE INC.My focus as an AWS Community Builder, in addition to my day job and side business, is the management of the Amplify Japan User Group. In this article, I would like to introduce the efforts I have made to improve the management system of Amplify Japan User Group in 2023. We will introduce some of the challenges that arise and how we are trying to maintain sustainability of the community organization, which is not a business, but a group of volunteers.If you are wondering "What is AWS Community Builder? please also refer to this article 挑戦権は誰にでもある、日本からもAWS Community Buildersを目指してみよう (in Japanese)!Community management differs from that of a typical company in that it is a volunteer-based organization. The members of the management team have their own day jobs, side jobs, and private lives, but they also participate in the management activities as volunteers.Therefore, unlike a job, it is not mandatory, and there will be a need to have each individual work in his or her own spare time. This is a feature and a potential problem for the continuity of community management.In fact, the Amplify Japan User Group also experienced issues due to this problem, and there was a period of stagnation in its activities. This stagnation resulted in a lack of meetups and community improvement activities, and the growth of the community itself stagnated and eventually declined.To stem the tide, the Amplify Japan User Group has redesigned its management structure this year.We focus on maintaining the continuity of the management system, as well as the community itself. We believe that if this is maintained, community activities will naturally continue and be activated.In the Amplify Japan User Group, the change in community management from an AWS-driven state to a community-driven state was one of the reasons for the stagnation of the management structure.Until the community was able to stand on its own, AWS employees took the lead in organizing the meetups. However, as the community gradually becomes established, there is a need to switch to community-led management at some point. Of course, while switching the initiative, AWS employees will continue to provide support.The timing was right for the Amplify Japan User Group around 2021, and while we continued to host the event, we changed the name of the event to the current "Amplify Boost Up" and tried to steer the event toward community-driven activities.However, at that time, we did not make any major changes to the operation structure or mechanism, but switched only close to the mindset of "let's keep the AWS employees' lead low key and let the rest of the operation members do their best".COVID-19 was still having a large impact, and our activities were limited to holding ongoing online events and interacting with each other on Slack. Even in these limited activities, events were being held less frequently, and Slack was becoming more like a place to see bot posts, with almost no postings. The aforementioned mind-switching alone made it difficult to maintain that mind-switching, and the management tasks tended to remain static.After such a period of time, in 2023, we decided to restart the operation of the event, and since the onslaught of COVID-19 had passed and the number of hybrid online/offline events was increasing, we decided to restart the community event as a hybrid event, and at the same time, we improved the operation of the event to avoid a similar situation. We restarted the event with an improved management system to avoid a similar situation.In order to achieve sustainable community management, we have implemented several operational structure improvements, some of which are shown below as examples.Although it is a natural thing to do, we have again clarified the members of the management team.Community management is solely a volunteer-based activity. Therefore, it should be allowed that there may be periods of inactivity due to work or personal circumstances. With this in mind, until then, people who were interested in the management would join the Slack channel where the management members gathered, and the management member management was close to just that. As a result, the situation became "There are many members in the Slack channel, but who are the members who are actually involved in the management and can share the tasks? The management members themselves were becoming unclear.The adverse effects of this condition were the following eventsWhen someone asks for an opinion or reaction on Slack, we don't know if the unrespondent forgot to respond or is inactive and unwilling to respond, and we have to keep reminding them.This results in an atmosphere of "it seems okay not to respond".Since only a few more members of this obscure management team will be involved, there will be no sense of unity as a team.In order to solve these problems, we have started to take inventory and clarification of the management members by periodically confirming their willingness to participate as management members once a year.Leaving the operation is not a negative thing. Since work and personal situations change, by making it easier to express your intention to continue or stop as a management member each year, you can avoid the awkward situation where you are too busy to show up and participate in the management more easily.Then, by constantly updating the management member ledger maintained within the operation, we were able to maintain that all members of the operation are Active.The previous management organization did not have regular management meetings, but rather set them up as needed, such as prior to an event.As a result, decision-making was not progressing during periods when meetings were not being held, although of course this could be done to some extent on Slack. This led to a vicious cycle in which events were not planned and the need for meetings declined.If we are in a state of "no agenda," it could be an indication that there is nothing moving as a community. For this reason, we decided to make the management meeting a regular meeting, to be held monthly. In doing so, we have also established a mailing list of management members by clarifying the above-mentioned management members, and we send calendar invitations to the mailing list.Management meetings, which tended to be held irregularly in the past, are now scheduled on a regular schedule, creating an opportunity to move forward as a community and a rhythm for such meetings. In addition, the act of checking everyone's schedule and setting up a meeting each time was expensive to coordinate. Therefore, being able to block each person's schedule in advance as a regular schedule has been very effective.The Amplify Japan User Group does not have a specific budget, so we need to make sure that the tools we use in our operations can be covered by free ones. In parallel with the organization of the regular meetings mentioned above, we also organized the tools. In addition, a ledger has been created by clarifying the members of the management team, and we are now organizing the tools, including their authorization.Here are two examples of the tools we use. We need a management tool for documents used within the management team, such as management meeting memos and management member ledgers. Since we do not have a budget, We decided to use GitHub because it is free of charge regardless of the number of users to be invited, and because it can be set to be private.The Amplify Japan User Group already had a GitHub Organization for use with source code for the community site and CFP for meetups. Therefore, while using GitHub's Free plan, we created a private repository for the management team, and we use GitHub Discussions in that repository to manage documents.Until then, the base was based on the granting and revoking of privileges to related tools and mailing lists. Therefore, in addition to management of operating members, a ledger was maintained for tools, and the status of authorization grants was visualized.In the above GitHub Discussions, "アナウンス" (it means "Announcements") places ledgers and other documents that should always be referenced. One of the most significant tool maintenance changes was the switch from Slack to Discord as the communication tool in the community.Due to a lack of budget, we could not afford a paid plan for Slack, and as a result, the past logs were hidden because it was a free version. To improve this situation, we switched from Slack to Discord.Logs of questions and discussions within the community can now be utilized, including those from the past, as they are important community assets in themselves.In addition to the above, we also use Google Group, YouTube, connpass, Slido, etc.The management team is engaged as volunteers, so they need some motivation to keep it going.Of course, the community management activities themselves can be one of the achievements to be certified as AWS Community Builder or AWS User Group Leaders, and in fact, many AWS Community Builders and AWS User Group Leaders are on the management team.However, this is the only situation in which each individual must feel motivation on their own. Therefore, it was not possible to create motivation derived from a sense of unity as a team of management members.Therefore, we produced management T-shirts, although each member had to pay for his or her own T-shirt. Please note that the management members are wearing these T-shirts at the meetups.In community management, there are times when the workload is temporarily high, such as during events, but it is important to create a system and structure that will allow for continuous operation during normal times. This is because everyone involved has other jobs and private lives, and the community is made up of volunteer activities in addition to these.How to create and maintain a lean and efficient management organization that is built on such good intentions is an important issue for the survival of the community.The Amplify Japan User Group is now well organized, and I would like to contribute to the development of the community itself by further enhancing the sense of unity and motivation of the management as the finishing touch to the group.

Aiming for sustainable community management - Improvement of Amplify Japan User Group's management system in 2023

こんにちは、AWS Community Builder 兼 AWS User Group Leaders 兼 Amplify Japan User Group運営メンバーの池田 @ikenyal です。株式会社GENDA でEMをしつつ、株式会社ZINE で取締役CTOをしています。!本記事は 技術広報 Advent Calendar 2023 及び GENDA Advent Calendar 2023 の23日目の記事です。登壇資料や外部公開するスライドをアップロードできるサービスはいくつもありますが、その中でも、Speaker Deckを主に利用しています。しかし、Speak...

GoogleスライドでもSpeaker Deckで日本語フォントを崩さないアップロード手順

こんにちは、AWS Community Builder 兼 AWS User Group Leaders 兼 Amplify Japan User Group運営メンバーの池田 @ikenyal です。株式会社GENDA でEMをしつつ、株式会社ZINE で取締役CTOをしています。!本記事は AWS Community Builders Advent Calendar 2023 、 AWS AmplifyとAWS×フロントエンド #AWSAmplifyJP Advent Calendar 2023 及び GENDA Advent Calendar 2023 の8日目の記事です。...

持続可能なコミュニティ運営を目指して〜Amplify Japan User Group 2023年の運営体制改善

こんにちは、AWS Community Builder 兼 AWS User Group Leaders 兼 Amplify Japan User Group運営メンバーの池田 @ikenyal です。!本記事は AWS Community Builders Advent Calendar 2022 の25日目の記事です。このAdvent Calendarでは、AWS Community Buildersに参加している、AWSを愛する皆の、皆による、皆のためのアドベントカレンダーです。そう言われても「AWS Community Buildersとは何者？」と思われる方も多くい...

挑戦権は誰にでもある、日本からもAWS Community Buildersを目指してみよう

こんにちは、株式会社ZINE 取締役CTOの池田 @ikenyal です。!本記事は Qiita x 日本CTO協会共催！あなたの自己変革について語ろう！ Advent Calendar 2022 の10日目の記事です。日本CTO協会のAdvent Calendarでは、協会が定めている下記4つのバリューに関する内容を会員が発信しています。Give First / あなたの当たり前は誰かの学びThink Big, Start Small / 大きく考え、小さく一歩目を踏み出すFail Fast, Learn Fast / 早く失敗し、早く学ぶAlways Day On...

日本CTO協会へ個人会員として入会、そしてプロボノスタッフとして携わるようになった2022

本記事では、以下のフレームワークやツール等を利用した例で、AWS Amplifyを使った開発の流れを「amplify-sample」というサンプルアプリケーションの開発に沿って紹介します。AWS AmplifyReactReduxTypeScriptFigmaAmplify Studio React x Redux x TypeScript のアプリケーション作成とデプロイ アプリケーションのテンプレートを出力「amplify-sample」というアプリケーションを作成します。npxは、npmの5.2.0以降から同封されているコマンドです。コマンドがインストー...

AWS Amplify x Amplify Studio x Figma で開発効率UP

2022年5月より、株式会社GENDAでEMとして従事し、テックブログを立ち上げました。私は、前職の株式会社ZOZOテクノロジーズ（現株式会社ZOZO）のテックブログの運用を担当し、記事の技術的バリューのクオリティ担保だけでなく、日本語の編集・校正も担当し、年間100本以上の記事編集を2年ほど行っていました。その経験もあるため、今回はGENDAのテックブログの立ち上げに携わっています。本記事では、そのテックブログ立ち上げの設立経緯と意図を紹介します。https://techblog.zozo.com/entry/2020-techblog-summaryhttps://blog.ge...

「GENDA Creators Blog」開設しました

Amplify + Vue + GitHubを用いてWebアプリの自動デプロイ環境を構築を構築します。手動デプロイ、自動デプロイ、ブランチ名規則による自動デプロイ、プルリクエストによる自動デプロイの設定をします。前提AWSアカウントは所持しているローカル環境...

Amplify + Vue + GitHubでWebアプリの自動デプロイ環境を構築し、開発を始められる状態にする手順

この記事は、ZOZOテクノロジーズ #1 Advent Calendar 2019 24日目の記事です。昨日は @sonots さんの「書き込みがあるワークロードにおける ZOZOTOWN マルチクラウド構想とその検討停止について」の記事でした。はじめにこんにちは、...

CTO室はじめました 〜新設CTO室が1年目にやったことと課題

Flutterの準備https://flutter.dev/docs/get-started/install に従ってFlutterの準備をするパッケージインストールhttps://flutter.dev/docs/get-started/install から該当...

Flutter環境もない状況からFlutter Webの環境を構築

Evernoteで添付ファイルも扱いたいが、上限の200Mを超過する場合に、ファイルを分割する際のコマンド。分割split -b 200m ファイル名 splited.結合cat splited.* > file