As AI-assisted development becomes the norm, AI coding tools are rapidly shifting from simple "code completion" to "autonomous agent development." This evolution is fast becoming the standard.By early 2026, major tools have all evolved toward a direction where "agents autonomously write, test, and fix code"—exemplified by Claude Code’s Agent Teams, Cursor’s parallel Subagents, GitHub Copilot’s Coding Agent, and Windsurf’s parallel Cascade.In this landscape, using Kiro might honestly feel a bit underwhelming.However, if we discuss this "unassuming" nature without breaking down which layer of development it addresses, Kiro risks being dismissed as merely a "weak IDE."This article is intended for developers who use Claude Code or Cursor daily. For those already reaping the benefits of agents, I want to organize the differences in the problems Kiro is trying to solve.First, let’s align our understanding of the starting point.The assessment that "Claude is superior in terms of overall raw capability" is likely based on practical observation rather than emotion. However, by early 2026, it’s fair to say that we are no longer in a situation where "only Claude is strong." The current reality is that major tools are evolving rapidly in distinct directions.Claude Code’s strength can be described in three layers.First is its massive context processing capability. With a context window of up to 1 million tokens (beta), it can fit design docs, implementation code, tests, logs, and diff histories into a single reasoning space. This moves the needle from "local optimization" toward "semi-global reasoning," making cross-dependency analysis and side-effect detection possible within realistic timeframes.Second is the autonomous execution loop. Partially automating the loop of Implementation → Testing → Error Reading → Root Cause Hypothesis → Fixing changes the very structure of productivity by expanding human cognitive bandwidth.Third is Agent Teams, released alongside Opus 4.6 in February 2026. A lead agent decomposes tasks, and multiple workers execute them in parallel within independent contexts. Sequential work that used to take hours now completes in minutes through parallelization. This is particularly effective for large-scale refactoring or feature implementations spanning multiple modules.Furthermore, with structured instructions via CLAUDE.md or AGENTS.md, tool integration through MCP, and context continuity between sessions via an automated memory system, it has evolved from a mere reasoning engine into an agent development platform.Cursor changed significantly with version 2.0. By integrating the proprietary coding model "Composer," it achieved four times the generation speed of previous versions. Even more noteworthy are the asynchronous Subagents. Multiple sub-agents run in parallel without blocking the parent agent, forming a tree structure where sub-agents can spawn further sub-agents. Test results in review articles have reported that migrating a router in an 8,000-line Next.js app was reduced from 17 minutes (sequential) to 9 minutes (parallel).https://myaiverdict.com/cursor-ai-review/With Background Agents, an agent can now work on an independent branch and open a Pull Request while the developer is busy with other tasks. It also features process control mechanisms like Plan Mode, Rules, and Hooks.GitHub Copilot’s Coding Agent creates a Draft Pull Request autonomously in the background simply by assigning an Issue to @copilot. Operating within the GitHub Actions environment, it automates everything from branch creation to commits and opening PRs. It can share project-specific instructions via AGENTS.md and link tools via MCP. It is designed to iterate on automatic fixes based on feedback from PR reviews.Windsurf released parallel multi-agent sessions in Wave 13. Using Git worktrees, multiple Cascade agents can operate simultaneously within the same repository without branch conflicts. SWE-1.5 demonstrated performance rivaling frontier models on SWE-Bench-Pro and was offered for free to all users for three months following its December 2025 release. Workflow automation via Cascade Hooks has also been added.The trend here is clear: all major tools are competing on "autonomy and parallelism of reasoning." Processing more files, faster, with less human intervention. This is the dominant competitive axis for AI coding tools in early 2026.As long as we evaluate based on this axis, Kiro currently occupies a late-comer position.That is exactly why we need to precisely understand what Kiro is actually optimizing for.While major tools optimize for "autonomy and parallelism of reasoning," Kiro optimizes for "state management of the development process."This may sound abstract, so let’s look at Kiro’s specific mechanisms.The core feature of Kiro is Spec (Specification-Driven Development). From natural language prompts, it generates three Markdown files in stages:requirements.md: Describes user stories and acceptance criteria using the EARS (Easy Approach to Requirements Syntax) notation. EARS was originally developed by Rolls-Royce for airworthiness regulation analysis of jet engines. it eliminates ambiguity through a structured format: WHEN [condition] THE SYSTEM SHALL [behavior].design.md: Documents technical architecture, sequence diagrams, and implementation considerations.tasks.md: Breaks down the implementation plan into discrete tasks, explicitly tracing each task back to specific requirements in requirements.md.Crucially, these three files are not independent documents; they are a linked structure. Changing requirements.md updates the design via "Refine" in design.md, which then maps new tasks to requirements through "Update tasks" in tasks.md. It is designed so that the impact of a spec change propagates structurally.In many projects, critical information exists only as implicit knowledge:This constraint stems from audit requirements; this cache design assumes future scalability; this async process requires order guarantees; this API depends on an external contract...Kiro’s "Steering" fixes these as Markdown files under .kiro/steering/. By default, it generates three files: product.md (product goals and business context), tech.md (tech stack and constraints), and structure.md (project structure and naming conventions).Steering files have three inclusion modes:always: Included in all interactions.fileMatch: Included only when matching specific file patterns.manual: Included only when explicitly referenced.This allows for controlling context window consumption while ensuring the AI receives the necessary premises. It is also designed for team deployment, allowing priority control between global and workspace Steering, and distribution via MDM like Jamf.Agent Hooks are triggers that automatically execute predefined agent actions in response to events like file creation, saving, or deletion. You can systematize routine tasks in an event-driven manner—such as automatically generating tests upon saving a file, syncing documentation when code changes, or running security checks.Looking at Spec, Steering, and Hooks together, it’s clear that Kiro isn’t just about generating spec docs. It’s about clarifying requirements (requirements.md), fixing design constraints (design.md + Steering), task decomposition and traceability (tasks.md), impact propagation during changes (Refine/Update tasks flow), persisting implicit knowledge (Steering), and automating routine processes (Hooks).In short, Kiro’s approach is not about making reasoning faster or stronger, but about clarifying the premises upon which reasoning depends and managing the development process as a state.This is the fundamental difference.LLMs are probabilistic reasoning models. They generate the most plausible output based on the given context. Whether you parallelize with Agent Teams or build tree structures with Subagents, each agent is performing "reasoning within a given context.""State management" here refers to a mechanism that explicitly maintains invariants, manages dependencies as a structure, and can recalculate the scope of impact when changes occur.While LLMs can refer to context, they only reason "within the provided scope." Any premise outside that context is treated as if it doesn’t exist.For example, consider a case where you change a rate-limiting specification. If you give the change to Claude Code, Agent Teams can simultaneously fix code, update tests, and modify documentation. However, if the consistency with future multi-tenant plans or audit requirements isn't in the context, they won't be part of the reasoning. Parallelization doesn't solve this.The issue here isn't the model's intelligence or speed, but "where the premises are held."Kiro fixes constraints in EARS format in requirements.md, documents design decisions in design.md, and persists project-specific premises in Steering. When specs change, the impact propagates structurally from requirements to design to tasks.While the major tools of 2026 compete on "how fast, autonomously, and in parallel reasoning can run," Kiro competes on "how structurally the context required for reasoning can be maintained." They are competing on different layers.This is the strongest counterargument, and it has gained even more weight from late 2025 into 2026.Specification-Driven Development (SDD) is no longer an approach exclusive to Kiro.GitHub released "Spec Kit" as open source. It’s a CLI tool that allows the same requirements → design → tasks flow as Kiro to be used across multiple agents like Claude Code, Cursor, GitHub Copilot, Gemini CLI, and Windsurf. It also supports requirement definition via EARS.Furthermore, each tool has begun to incorporate its own process control mechanisms. Claude Code has instruction structuring via CLAUDE.md and AGENTS.md. Cursor has Rules and Plan Mode. GitHub Copilot has AGENTS.md and custom agent definitions. Windsurf has Rules and Workflows.The argument that "if you want SDD, just use GitHub's Spec Kit with your tool of choice" or "process control can be done to some extent in any tool" is now quite realistic.So, what is Kiro’s differentiator?While GitHub's Spec Kit provides the "SDD workflow" in an agent-agnostic way, the synchronization between specifications and implementation remains a human responsibility. If you change a requirements.md generated by Spec Kit, the propagation of that impact to design.md or tasks.md is not automated.While Rules or AGENTS.md in other tools structure instructions for agents, they aren't mechanisms for managing the three-layer structure of specs, design, and tasks in a linked fashion within a single IDE.Kiro’s edge lies in the "seamless integration of Spec, Steering, and Hooks within the IDE." The flow of requirements.md change → design.md Refine → tasks.md Update → Task execution → Auto-verification via Hooks is completed within a single environment. Spec files are Git-manageable and can be reviewed and shared by the team.This is the difference between the "concept of SDD" and the "operation of SDD." While the concept can be realized with Spec Kit, the cost of maintaining it as a daily operation depends heavily on the degree of tool integration.Let's go further: "Isn't an expert engineer writing specs themselves and having Claude Code's Agent Teams implement them the ultimate setup?"That is indeed a powerful configuration, but the question is where the responsibility for state management lies.In this setup, judgments about "which invariants exist," "which design constraints are vital," and "which changes are breaking" remain as implicit knowledge on the human side. This rarely causes issues in short-term projects. However, as spec changes accumulate, members rotate, or maintenance occurs six months later, the degradation of implicit knowledge is inevitable.Kiro provides concrete mechanisms against this degradation. EARS format in requirements.md fixes acceptance criteria without ambiguity, each task in tasks.md traces back to a requirement number, and Steering persists project premises in a Git-manageable form. These are versioned, reviewable, and accessible even if the person in charge changes.To be fair, Kiro has clear limitations.The synchronization between Spec and implementation code isn't fully automated. As noted in reviews on Martin Fowler’s site, drift between specs and implementation remains a challenge. There are also reports of Spec granularity not fitting project scale—the "sledgehammer for a small nail" problem where four user stories and sixteen acceptance criteria are generated for a tiny bug fix.https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.htmlKiro’s default (Auto mode) uses routing based on the Sonnet 4 series, but Pro users and above can select Opus 4.6. It also features parallel execution via custom Subagents and an Autonomous Agent (preview). The gap in model performance and agent features is closing fast; Kiro’s differentiation will likely remain in its integration of process state management via Spec, Steering, and Hooks, rather than on the axis of "reasoning power and parallelism."Kiro's pricing ranges from Free (50 credits/month) to Power ($200/month), using a credit-based usage model.The evaluation criteria for AI coding tools in 2026 are clear.How many minutes did it take to implement with Agent Teams? How many files were modified in parallel with Subagents? How many hours after assigning an Issue to a Coding Agent was a PR opened? How many bugs were crushed simultaneously with parallel Cascade?On this axis, speed and autonomy are what look attractive. The impact of "Agent Teams modified 5 modules simultaneously" is overwhelmingly larger as an experience than "Requirements were structured in EARS notation."Conversely, Kiro’s value lies in preventing accidents: suppressing spec deviation, preventing missed dependencies, and making design constraints explicit. Generally, "the absence of accidents" is difficult to appreciate.As a result, Kiro isn't weak; it just stands in a "position that is hard to evaluate."Let’s translate this into a practical decision-making framework.First, we must acknowledge that in early 2026, AI coding tools are evolving rapidly in reasoning autonomy and parallelism. In terms of raw implementation speed on this axis, Kiro is not in the same league.So when do you need a Kiro-like approach? The criterion is "what is the primary bottleneck in this project?"The more the following conditions apply, the more rational it is to stick with Claude Code, Cursor, or GitHub Copilot:Limited scopeRelatively stable specificationsPoC or exploratory phasesSmall team with shared implicit knowledgeIn these cases, the bottleneck is "implementation speed." You gain more by maximizing agent reasoning and generation than by fixing the process.On the other hand, things change when you see these signs:Frequent specification changesNon-functional requirements introduced late in the gameHandovers or long-term maintenance are expectedInconsistencies between tests and specs begin to increaseThe labor to verify agent output starts to exceed the labor of implementationAt this point, the bottleneck shifts to "consistency maintenance." Here, where you fix the state matters more than the agent's reasoning capability.Having requirements fixed in EARS in requirements.md, tasks traced back to requirements in tasks.md, and project premises persisted in Steering becomes a safety net for your future self or your successor six months down the line.Whether you adopt Kiro as an IDE or incorporate Kiro’s philosophy into your toolchain via GitHub's Spec Kit is a separate decision. The important thing is to "recognize the existence of the layer called process state management."Claude Code is powerful. Cursor is fast. GitHub Copilot is deeply integrated with GitHub. Windsurf excels in parallelism. These are undeniable strengths. But that strength lies in "autonomy, speed, and parallelism of reasoning and implementation."Kiro is not flashy, but its value lies in the "structural fixation of process state."If you compare them simply without understanding this difference, Kiro will always lose. But if you change the evaluation axis, the view changes.In 2026, all AI coding tools are running toward "making reasoning faster, stronger, and more autonomous." Kiro cannot win on that competitive axis. However, phases dominated by reasoning and phases dominated by consistency maintenance costs are different things. The moment the latter becomes dominant, Kiro’s fixation of process state through Spec, Steering, and Hooks begins to show its worth.It’s not about superiority; it’s about a difference in layers. Recognizing that difference and choosing what your project needs might be the most realistic solution for 2026.

Why Kiro Looks Unassuming: Organizing Design Philosophy Differences in the Age of Claude Code and Cursor

生成AIによる開発支援が当たり前になりつつある現在、AIコーディングツールは「コード補完」から「自律的なエージェント開発」へと急速にシフトし、それが当たり前のようになってきています。Claude CodeのAgent Teams、Cursorの並列Subagents、GitHub CopilotのCoding Agent、Windsurfの並列Cascade。2026年初頭の時点で、主要ツールはすべて「エージェントが自律的にコードを書き、テストし、修正する」方向に進化しました。その中でKiroを触ると、正直に言って地味に見えるでしょう。ただし、その"地味さ"がどのレイヤーの話なのか...

Kiroはなぜ地味に見えるのか―Claude Code・Cursor時代における設計思想の差を整理する

Released by AWS Labs on GitHub in February 2026, Agent Plugins for AWS is a "plugin library that grants executable skill sets to AI agents," distinguishing itself from simple code completion or natural language assistance.In addition to being officially supported as a Claude Code plugin, this OSS can be installed and used via the official marketplace in Cursor. It supports the entire workflow end-to-end—from AI-driven design assistance, recommendations, and cost estimation to IaC generation and deployment to AWS. /         agent-plugins          Agent Plugins for AWSImportantGenerative AI can make mistakes. You should consider reviewing all output and costs generated by your chosen AI model and agentic coding assistant. See AWS Responsible AI Policy.Agent Plugins for AWS equip AI coding agents with the skills to help you architect, deploy, and operate on AWS. Agent plugins are currently supported by Claude Code.PluginsPluginDescriptionStatusdeploy-on-awsDeploy applications to AWS with architecture recommendations, cost estimates, and IaC deploymentAvailableInstallationClaude CodeAdd the marketplace/plugin marketplace add awslabs/agent-pluginsInstall a plugin/plugin install deploy-on-aws@agent-plugins-for-awsCursorUse the official Cursor marketplace to install the plugins from this repository. For additional information, please refer to the documentation.Open Cursor SettingsNavigate to Plugins, and in the search bar type awsSelect the plugin you want to install, and Click add to cursor, then select the scopeNow…View on GitHubIn that sense, existing CLI-based agents are capable of similar actions if we only consider the aspect of "execution." However, Agent Plugins differs in that it goes beyond mere task automation; it is provided as a capability layer that systematizes the design process.This article explores "what it achieves," "why it is important," and "what value it creates."Previously, development support using LLMs typically followed these patterns:Providing natural language advice in response to questions like, "How should I implement this architecture on AWS?"Humans designing and coding based on that advice.Deployment and testing performed manually by humans.In this flow, the AI's role is centered on "design assistance," while the actual application to the environment depends on humans.In contrast, "Agent Plugins for AWS" is a suite of plugins that allows AI agents to proactively handle everything from Design → Recommendations → Cost Estimation → IaC Generation → Deployment. This is qualitatively different from automation tools that simply suggest command completions or trigger a CLI via natural language.Many might think that with current tools like Claude Code or various AI CLIs, one can already:Generate IaCExecute the AWS CLIProceed to deployment without manual intervention...provided that agent mode is enabled with appropriate permissions. Many are likely already practicing this.If we look solely at "whether it can be executed," traditional CLI-based agent environments can perform similar tasks.So, what is the differentiator for "Agent Plugins for AWS"?In CLI-based automation, the agent reasons based on a prompt each time to generate and execute necessary commands. Design decisions and service selections tend to rely on the model's internal knowledge and the immediate context.In contrast, Agent Plugins for AWS is characterized by explicitly defining the AWS design workflow itself—Analyze, Recommend, Estimate, Generate, Deploy—as extended capabilities of the agent. This is not just a sequence of commands to execute a task; it is a capability that stages the entire design process.In other words, it represents a shift from a model that "executes operations thought up on the spot" to one that "internalizes the AWS design process as a structured capability."While mechanisms like Claude's Skills or Kiro Powers can indeed grant agents additional specialized knowledge or scripts, they act as modules to enhance behavior or knowledge for specific domains. They do not systematize the entire design workflow."Agent Plugins for AWS" takes a fundamentally different role by officially packaging the sequence from design to execution and providing it as a capability integrated with live data (pricing, documentation, etc.) via MCP.While recommendations and generation are possible via CLI execution alone, those judgments tend to rely on the model's internal training data.Agent Plugins connects via MCP servers to:awsknowledge (Official documentation)awspricing (Real-time pricing)aws-iac-mcp (IaC best practices)This structure ensures that design recommendations and cost estimates are tied to the latest official information and real-world data. The difference is not "whether it can be done," but "whether the information sources backing the judgment are systematically integrated."CLI automation is primarily about making "operations" more efficient.Service selection logicCost evaluation flowsIaC output patternsThis can be viewed as an attempt to "expand the design capability within the AWS domain" rather than just automating command execution.Structurally, Agent Plugins is positioned in the following layer:While CLI automation optimizes the "CLI / API Execution Layer," Agent Plugins adds an "AWS Domain Capability" intermediate layer above it. This design elevates the agent's capability stack rather than just adding another tool.CLI automation improves individual efficiency. Agent Plugins standardizes the design workflow. This difference may seem small but becomes significant at the organizational level:Reproducibility of designsConsistency in cost evaluationUniformity of IaC outputReviewable rationales for recommendationsAgent Plugins contributes to the "standardization of processes." Therefore, its differentiator is not "replacing the CLI," but "stacking AWS-specific capabilities on top of the CLI." If CLI automation is the "execution foundation," Agent Plugins is the "capability extension layer" built upon it.Agent Plugins for AWS is a collection of plugin modules that grant AWS-related functionalities to AI agents. According to the README, the goal is to provide skills that allow AI coding agents to assist with everything from AWS design and deployment to operations.Analyze: Analyzes source code and project structure to identify frameworks, dependencies, and data stores.Recommend: Suggests appropriate AWS service configurations and provides the reasoning.Estimate: References real-time pricing via the AWS Pricing MCP server to estimate the cost of the recommended setup.Generate: Converts the design into IaC (CDK or CloudFormation).Deploy: Reflects and executes the generated IaC in the AWS environment after user approval.This establishes a circuit for the AI agent to proactively drive the workflow from design to implementation and deployment.The Model Context Protocol (MCP) server is the crucial underlying mechanism supporting the utility of Agent Plugins. MCP is a standardized protocol for connecting AI models to external data sources and tools. AWS-side MCP servers provide official documentation, pricing, and best practices.MCP ServerRoleawsknowledgeAWS documentation, architecture guides, best practices.awspricingReal-time AWS pricing information.aws-iac-mcpIaC (CDK/CloudFormation) best practices.This allows the agent to refer to the latest live data rather than relying solely on the model's internal knowledge.In traditional cloud migration, humans had to handle multiple phases: analyzing current setups, selecting services, decision-making based on costs, designing IaC, and deploying."I want to optimize this project for an AWS serverless architecture and deploy it."The tacit knowledge of veteran designers often leads to siloing. Because Agent Plugins outputs the rationale for recommendations, costs, and IaC, knowledge sharing and reviews become much easier. This results in:Transparency in the design decision process.Formalization of best practices.Reduced learning costs for new members.Generated IaC and configurations can be integrated directly into CI/CD pipelines.Automatically validating IaC in pull requests.Attaching cost comparison reports to the review stage.Linking to automated deployment approval workflows.Model Errors and Recency: As stated in the official README, outputs may contain errors, and all results require human review.Security and Permissions: Careful design of AWS CLI and IAM settings is essential. Risks increase with excessive permissions; establishing proper approval flows for automated deployments is vital.Agent Plugins for AWS is a foundation for evolving AI agents from "explanatory assistants" into "orchestration engines for execution." The underlying MCP servers and ecosystem (Claude, Cursor, etc.) are continuously developing, potentially leading to further automation of cloud operations.Furthermore, AWS has announced the preview of the AWS MCP Server, a remote/fully-managed Model Context Protocol server. This suggests a direction where governance—such as authentication/authorization via IAM and log collection via CloudTrail—will be natively supported.https://aws.amazon.com/about-aws/whats-new/2025/11/aws-mcp-server/Agent Plugins for AWS is a significant evolution that moves the role of AI from "assistance" to "execution." By providing a foundation based on real-time data, consistent workflows, and reasoned support, it enables both productivity and quality in cloud design, migration, and operations.

Beyond Assistance: The Executive Power of "Agent Plugins for AWS"

2026年2月にGitHub上のAWS Labsからリリースされた Agent Plugins for AWS は、単なるコード補完や自然言語アシストとは一線を画す、「AI エージェントに実行可能なスキルセットを付与するプラグインライブラリ」です。このOSSは公式にClaude Codeプラグインとしてサポートされているのに加え、Cursorでも公式マーケットプレイスからプラグインをインストールして利用できるようになっており、AIによる設計支援・推奨・コスト試算・IaC化・AWSへのデプロイまで、ワークフロー全体を一気通貫で支援します。https://github.com/awsla...

AWS × AI エージェントの実行力：「Agent Plugins for AWS」を紐解く

この記事はMagicPodアドベントカレンダー2025の25日目です はじめにMagicPodについて語られるとき、ノーコードでE2Eテストが書けることや、国産ツールであることによる安心感がまず話題に上がることが多いでしょう。一方で、テスト自動化を「導入して終わり」ではなく「運用し続けるもの」と捉えた場合、本当に重要なのはいまの使いやすさよりも、プロダクトがどの問題を最重要視して進化しているかだと思います。本記事では、MagicPodの最近の機能追加や公式発信を材料にしながら、MagicPodはE2E自動化において、どの課題を本丸と捉えているのかなぜAI活用にこれだけ重心...

MagicPodはE2E自動化ツールから何へ進化しようとしているのか──機能追加の方向性から読み解く、テスト自動化に対する思想

前回の記事https://zenn.dev/genda_jp/articles/1c6794c31dc741https://zenn.dev/genda_jp/articles/802fdca6aed774https://zenn.dev/ikenyal/articles/b5fdf94cef916bこちらの記事の続きの話です。 レビューは「コードを見る場」ではないコードレビューというと、ロジックの正しさやバグの有無をチェックする場、というイメージを持つ人は多いと思います。もちろん、それは今でも重要な役割です。ただ、AIの活用が進んだ現在、レビューの重心は少しずつ変わっ...

AI時代だから、レビューで見るべき観点が変わる

前回の記事https://zenn.dev/genda_jp/articles/1c6794c31dc741https://zenn.dev/genda_jp/articles/802fdca6aed774こちらの記事の続きの話です。 技術的負債の正体はコードそのもの以外にも潜んでいる技術的負債という言葉を聞くと、複雑になりすぎたコードや、古くなったライブラリを思い浮かべる人は多いと思います。もちろんそれらも負債の一種ですが、実務で本当に厄介なのは、なぜその設計や判断に至ったのかを誰も説明できない状態です。コード自体は動いている。テストも通っている。それでも「なぜこうな...

AI時代だから、説明できない設計は陳腐化する

前回の記事https://zenn.dev/genda_jp/articles/1c6794c31dc741こちらの記事の続きの話です。 問いが噛み合わないとき、実は前提が噛み合っていないことが多い技術的な議論がうまく噛み合わない場面は、これまでも数多く出会ってきました。そういうとき、つい「意見が対立している」「知識量に差がある」といった理由で片付けてしまいがちです。しかし、実際に議論を振り返ってみると、多くの場合で問題になっているのはそこではありません。前提条件が共有されていないまま、結論だけを議論しようとしていることが原因になっているケースがほとんどです。前回の...

AI時代だから、前提を言語化しないと議論が壊れる

実装が詰まる原因は、コードの前にあることが多い実装が詰まったとき、ついコードの書き方や技術選定に原因を求めてしまいがちです。しかし、実際の体験を振り返ると、本当の原因はもっと手前にあることが少なくありません。それは「何を解こうとしているのか」「何を解かなくてよいのか」が、十分に整理されていないまま実装に入ってしまっている状態です。問いが曖昧なまま実装を始めると、途中で判断が揺れます。最初は正しいと思っていた設計が、少し要件を確認しただけで崩れることもあります。その結果、コードを書いては戻し、また書き直す、というサイクルに入ってしまいます。これは実装スキルの問題というより、問い...

AI時代だから、問いを整理してから実装する

こんにちは、コミュニティ活動としては AWS Community Builder 兼 AWS User Group Leaders 兼 Amplify Japan User Group運営メンバーの池田 @ikenyal です。!本記事は GENDA Advent Calendar 2025、AWS Community Builders Advent Calendar 2025 及び AWS AmplifyとAWS×フロントエンド #AWSAmplifyJP Advent Calendar 2025 の24日目の記事です。エンジニアとして日々の業務やタスク、時には業務外からの技術...

Amplify Japan User Group を通じて育んだ力 ─ 課外活動としてのコミュニティ運営参加の価値

こんにちは、AWS Community Builder 兼 AWS User Group Leaders 兼 Amplify Japan User Group運営メンバーの池田 @ikenyal です。!本記事は AWS Community Builders Advent Calendar 2023 、 AWS AmplifyとAWS×フロントエンド #AWSAmplifyJP Advent Calendar 2025 の1日目の記事です。日頃からAWS Amplifyのユーザーコミュニティの運営に携わっていますが、今日はその中でも大きなニュースをお届けします。日本初のAWS ...

AWS Amplify Conference 2026 by Amplify Japan User Group を開催します

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