!追記（2026年6月16日）。本記事の公開後、Anthropicが当初6月15日に予定していたこの変更を見送ると、対象ユーザー宛のメールで案内しました。現時点では、Agent SDKや claude -p の利用はこれまでどおりサブスクリプションの使用枠で動き、請求すべきクレジットもありません。サブスクリプションの使用枠も変わっていません。今後実施する際は、施行前に事前告知するとのことです。そのため、以下で解説する「対話と自動化の分離」は、いったん見送られた状態です。分離の方向性そのものが撤回されたのか、設計を見直したうえで時期を改めて実施されるのかは、現時点の案内からは読み取れま...

Claudeで自動化していた処理、今日（6/15）から一部が従量課金に。不要な課金を防ぐ確認手順

Update (June 16, 2026): After this article was published, Anthropic emailed eligible users to say it is not making this change, which had been set for June 15. For now, Agent SDK and claude -p usage continues to work with your subscription exactly as before, and there is no credit to claim. Subscription usage limits are unchanged. Anthropic says it will give advance notice before any future change takes effect.So the "conversation vs automation" split described below is postponed for now. Whether the direction itself is withdrawn, or will return on a revised plan and timeline, is not clear from the current notice. The body below remains as an explanation of what was originally announced. Note that the official help page had not been updated at the time of writing and still shows the June 15 date.A change to Claude's paid plans takes effect today, June 15, 2026. Your monthly fee is not going up. What changes is that usage which used to come out of a single pool splits into two: the part where a person is in a conversation, and the part where a program runs on its own. The details are in Anthropic's help center, and every number and scope in this post comes from that page.Starting June 15, 2026, Claude Agent SDK and claude -p usage no longer counts toward your Claude plan's usage limits. Your subscription usage limits stay the same and stay reserved for interactive use of Claude Code, Claude Cowork, and Claude.https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-planThe side that gets affected is the second one. If you have been running automation inside your subscription plan, part of that usage leaves the flat-rate pool today and starts metering. To be precise, what you spend beyond a newly granted monthly credit either bills at standard API rates or stops. If you only chat through the app or the terminal, nothing changes for you.The first thing to get right is which of your own usage is in scope. Get this wrong and you risk either stopping automation you wanted to keep running, or triggering charges you did not expect. This post gives you a checklist to avoid surprise charges as a same-day fix, then connects it to the larger question of how to design your automation from here.There is one line to draw: is a person typing and waiting for a response, or is a program calling Claude on their behalf? The former keeps using your subscription usage limits exactly as before. The latter is what the new monthly credit covers.Here is the official breakdown.How you use itWhat happens from June 15Claude conversations on web, desktop, or mobile appsStays on subscription. No changeInteractive Claude Code in the terminal or IDEStays on subscription. No changeClaude CoworkStays on subscription. No changeclaude -p (non-interactive mode)Moves to the monthly creditClaude Agent SDK (Python or TypeScript)Moves to the monthly creditClaude Code GitHub Actions integrationMoves to the monthly creditThird-party apps that authenticate through the Agent SDKMoves to the monthly creditIf you open the app and chat, or type into Claude Code in the terminal and wait for replies, June 15 looks the same as before. Those keep drawing from your subscription usage limits and never touch the new credit. If that is you, there is nothing to do today.The dividing line is whether you operate Claude by hand or have code operate it for you. Running claude -p from a shell script or cron, having a homegrown app built on the Agent SDK, wiring Claude Code into a GitHub Actions CI step. If any of these sound familiar, the checklist below is for you.Before the checklist, the background helps you make the call. Note that Anthropic has not stated the reason outright; what follows is my reading of what the announcement implies.The flat-rate subscription pool let programmatic use, which should run on metered API pricing, run far more cheaply than it otherwise would. Unlike a conversation, automation is not bound by human typing speed. A script or an agent fires requests back to back without pausing, so token consumption climbs even within the same monthly fee. The flat pool absorbed that non-stop consumption. Run the same work through metered API pricing instead, and the gap widens the longer it runs.In other words, the flat-rate plan was effectively subsidizing the cost of automation. Conversation has a natural ceiling because the human pauses; automation has no such brake. Keep both in the same pool, and the heaviest automation users get the biggest discount, while the gap between cost and price keeps growing.Read the split as ending that subsidy and it makes sense. The conversational part stays inside the flat rate; the part where code runs on its own moves toward metering that tracks real cost. Conversation and automation went into separate wallets because their cost structures were different to begin with. It is less a price hike than a separation of things that had been mixed together.This reading carries into the decisions later in the post. Automation is no longer an extra bundled into a flat rate; it has become something you design with cost in mind.To sort out whether you are in scope and to avoid surprise charges or unexpected stops, here is what to check today. Go through it in order and you will know which side you are on and what to set.First, check whether your day-to-day use is interactive or non-interactive. Chatting on the app or web, typing into Claude Code in the terminal or IDE and waiting for a reply, Claude Cowork. If that is all, you are out of scope and the rest is unnecessary. Most people stop here.Second, find every place that runs on its own. Are you calling claude -p from cron or a shell script? Is there a homegrown script or app (Python or TypeScript) built on the Agent SDK? Is Claude Code wired into CI, GitHub Actions in particular? All of these are in scope. The ones running quietly in the background are the easiest to miss, so it is worth opening your job definitions, crontab, and repository workflows once to check.Third, check the authentication path of any third-party tools. If an editor extension or an external agent tool is linked to your Claude account and authenticates through the Agent SDK on your subscription, it is in scope. Even if you never wrote claude -p yourself, a tool making non-interactive calls behind the scenes counts.Fourth, check whether those authenticate via subscription or an API key. Automation that already authenticates with a Claude Platform API key is out of scope for this change. Pay-as-you-go billing continues, unaffected by the monthly credit. This is the final fork for whether you are in scope.If you only use it interactively, there is nothing to do today. Only if you fall into automation, third-party tools, or the Agent SDK, and you are running on subscription authentication, do you move on to the next step.What you do divides into two stages on a time axis: the same-day fix you finish today, and the deeper rework you take your time over. The first keeps automation from stopping, but it is a stopgap; the real solution is in the second.Eligible plans get a monthly credit. Officially it is called the "Agent SDK credit," but it is not limited to people writing the SDK directly. The claude -p calls in cron or CI, the GitHub Actions integration, and the third-party tools you checked above all draw from this same credit. Even if you never touch the SDK, if something runs Claude non-interactively, you are in scope. The credit equals your plan's monthly fee.PlanMonthly creditPro$20Max 5x$100Max 20x$200Team (Standard)$20Team (Premium)$100Enterprise (usage-based)$20Enterprise (seat-based Premium)$200Enterprise (seat-based Standard)$0On seat-based Enterprise plans, Premium seats are eligible but Standard seats are not. You claim the credit once through your account (a one-time opt-in), and it refreshes automatically each billing cycle after that. From June 15, eligible users are said to receive an email with claim instructions.Here the path forks. If you plan to keep using automation, the first move is to not miss that email and claim the credit. If instead you would rather avoid being charged for automation, or you are fine letting it stop, there is no rush to claim. It starts with deciding whether you will keep running automation at all.Next, decide what happens once the credit runs out. Agent SDK usage draws from this credit first, and what happens beyond it depends on a setting. With "Extra Usage" enabled, the overage bills at standard API rates and automation keeps running. Without it, requests stop the moment the credit is exhausted and stay stopped until it refreshes.For a production workflow you cannot afford to stop, enabling extra usage to keep it running is the safer choice, though it leaves room for an unexpectedly large bill. For experimental automation that can stop without hurting, you might deliberately leave it off and let the credit act as a spending ceiling that is never crossed. You weigh "how bad is it if it stops" against "how scared am I of surprise charges."While you are at it, note the credit's constraints. It is granted per user and cannot be pooled or shared across a team. It resets monthly and unused credit does not roll over. If your team runs automation, the idea of "everyone drawing from one person's credit" does not work, and that is worth keeping in mind.The quick fix was about getting by within the credit you are given. The deeper rework is reconsidering, from the ground up, which authentication path your automation rides on.Anthropic positions the monthly credit as "sized for individual experimentation and automation." Read the other way, shared production automation is not expected to fit within the credit. In fact, Anthropic points teams running production automation to a Claude Platform API key. API-key usage is out of scope for this change: pay-as-you-go continues and no monthly credit is granted.This is where the earlier "automation is no longer an extra" reading pays off. When you build automation, which path you put it on, subscription auth or API-key auth, has become a design decision that shapes both cost structure and behavior at the limit.Auth pathHow cost readsWhen you hit the limitSubscription auth (Agent SDK credit)Monthly credit equal to your plan fee, resets monthlyStops if extra usage is off, continues at standard API rates if onAPI-key auth (Claude Platform)Consumed pay-as-you-go from prepaid credit balanceStops when the balance runs out, can continue via auto-reloadFor light experiments or personal helper automation, the subscription credit covers it. The way it stops when the credit runs out works as a spending ceiling you never cross. For production automation that hurts when it stops, or workflows shared across a team, API-key auth is easier to handle: consumption shows up directly as billing so it reads cleanly, and you can manage the balance with auto-reload and usage alerts. Both stop when the balance runs out, but subscription auth is a flat pool tied to your plan fee, while the API key is a balance you fund yourself. To run something steadily in production, the API key, whose ceiling is not pinned to your plan fee, gives more operational freedom.A few objections come to mind against the picture above. Let me raise them and answer each.So why not put everything on an API key and stop worrying about two wallets?There is something to this. Unify on an API key and conversation and automation both run on the same pay-as-you-go billing, with no need to watch a subscription credit and an API balance separately. But for conversation, moving to an API key tends to cost more. The subscription is designed so that, within your usage limits, conversation runs flat-rate and effectively unlimited. Move that to metered API pricing and every single conversational turn that used to be covered by your monthly fee turns into per-token billing. Keep conversation on the subscription's flat rate and split only the heavy automation onto an API key. That is the realistic landing point.My automation is light, so it fits within the credit I am granted, right?In many cases, yes. If you only run a script now and then, the granted credit is enough. The problem is estimating "it probably fits" without knowing your own consumption. If you keep an agent running constantly or call it often in CI, you can use up the credit faster than expected. Even when the judgment that it fits turns out right, it is safer to confirm the basis once. Take the run frequency you found in the checklist and reconcile it against actual consumption on the billing screen after the change takes effect.Whatever you call it, is this not a price hike in the end?For users who ran heavy automation on the flat-rate pool, it is indeed a real increase in burden, because the part that was cheap moves closer to real cost. But this is closer to correcting a distortion than an unreasonable hike. Until now the flat-rate subscription subsidized the cost of automation, and the heavier the user, the larger the benefit. The split moves things toward how they arguably should be: conversation flat, automation at real cost. Conversation-centric users see no change in usage limits or feel; the ones affected are limited to the layer that had been benefiting most. It is not an across-the-board hike but the removal of a subsidy that had been riding along.Once the checking and the fix are done, what remains is a design question. This change is a good moment to revisit how you design your automation.Even before this, there was a split in practice: API keys for automation built into production systems, subscription-authenticated Claude Code for scripts at hand. But as long as you ran on subscription auth, that choice never showed up in cost, because the flat pool absorbed it. From June 15, the choice of path feeds straight into cost and availability.The more you build and run your own agents, the bigger the impact. There are three axes to judge by.Does it hurt if it stopsDo you need consumption to be readableIs it shared across a teamAgainst these three, you sort which workflows stay on the subscription credit and which move to an API key. Light experiments that can stop use the credit as a spending ceiling; production or shared workflows you cannot stop go on an API key where consumption reads cleanly. The change is a good occasion to inventory your automation once.Put plainly, the era of treating automation as something that "just runs, loosely, inside a flat rate" ends here. Until now, running an agent left its cost dissolved into the flat rate, out of sight. From here, cost follows automation everywhere. Since it costs more the more it runs, you will weigh, from the design stage, whether a given automation earns its cost.The same-day fix is simple. Check whether you are affected, and if so, claim the credit and decide how it stops. That is all. What remains beyond it is the homework of how to watch the cost and value of your automation. The cost of automation, which had been hidden inside the flat rate, has come into the open. That, I think, is the real substance of this change.

Your Claude automation starts metering today (June 15). A quick checklist to avoid surprise charges

Datadog and AWS Shipped Ops Agents on the Same Day. What Are They Fighting Over?

アメリカ現地時間の2026年6月9日、二つの大きな発表が同じ日に重なりました。ニューヨークで開催されたDatadogの年次イベントDASH 2026のキーノートで、Bits AIファミリーが大幅に拡張されました。Detection、Investigation、Remediation、Infrastructure、Code、Release、Testing、Data Analysis、Chat、Memories、Evals。エージェント単位で数えると10種類を超え、合計100以上の新機能がまとめて発表されています。発表の全体像はキーノートのまとめ記事に整理されています。https://w...

DatadogとAWSが同じ日に出した“Opsエージェント”は、何を奪い合っているのか

Why Coding Stays in Human-AI Collaboration: A Paradox in Stanford's 51 Deployments

「AIを導入したのに成果が出ない」という声と、「AIで開発が劇的に速くなった」という声が、同じ2026年に並んで聞こえてきます。この落差はどこから来るのか。Stanford Digital Economy Labが2026年4月に公開した「The Enterprise AI Playbook: Lessons from 51 Successful Deployments」は、この問いに実データで迫った研究です。41組織・9業種にわたる51の本番展開事例を、構造化インタビューと社内資料をもとに5ヶ月かけて分析し、成功と失敗を分けた要因を整理しています。https://digitalec...

Stanford 51事例が示す、コーディングがAIと協働に留まる理由

After migrating to a new Android phone, a few specific apps stopped launching. Amazon Shopping and Kindle would freeze on a blank white or black screen for a while, then close on their own. Reinstalling, clearing storage, updating the OS — none of it helped. Going through the usual support steps changed nothing.What finally fixed it was clearing the storage of every Amazon app at once. Tracing the cause through ADB logs, it turned out that authentication data shared across multiple apps had become inconsistent, and the auth-retrieval step at startup was deadlocking.The incident itself happened with a specific Pixel-and-Amazon combination, but structurally it's a pattern that can hit any app where "authentication data shared across apps" meets "many subsystems initialized in parallel at startup for speed." It's worth knowing about whether you design SDKs, build apps, or handle ops and support, so I'm leaving it here as a case study.Note: This happened on my own device, with my own account. I'm reading the diagnostic output that the OS itself wrote out — not decompiling any app.Right after migrating data to a Pixel 10a, only certain apps refused to launch.Affected: Amazon Shopping, KindleSymptom: open the app, it freezes on a blank white or black screen for about ten seconds, then closes on its ownEverything else: other apps work fineThe officially suggested remedies are generic — "reinstall the app," "clear the cache," "update the OS" — and none of them worked. When the root cause is in the OS or the data migration rather than the app itself, the standard support path has a hard time isolating it.At first I couldn't even tell whether it was an OS problem, an app problem, or an Amazon account problem.I tried all the standard fixes.Reinstalling the affected appsClearing storage of just the affected appsClearing the cache of the affected appsUpdating every app in the Play StoreUpdating the OSRestarting the deviceThe affected apps still wouldn't launch, no matter what.The key realization: as long as you think of it as "a problem with one app," you won't fix it. Reinstalling just the affected app, or clearing just that app's storage, changes nothing. If that's the case, the cause probably isn't contained within a single app.Only once you reframe it as "a problem across a group of apps" does the solution come into view.Let me start with a hypothesis built only from public information. I'll back it up with logs in the second half.Amazon's Login with Amazon SDK has a mechanism that lets other apps reuse the Amazon Shopping app's logged-in state. This is documented officially.https://developer.amazon.com/docs/login-with-amazon/customer-experience-android.htmlAccording to the docs, if the user is already signed in to the Amazon Shopping app, an app that integrates Login with Amazon won't ask them to re-enter account details — the SDK recognizes and reuses the auth state of the Amazon Shopping app or the Fire OS device. That's single sign-on (SSO). The SDK's internal package name is com.amazon.identity.auth.map.device, which also appears in Amazon's official migration guide.https://developer.amazon.com/docs/login-with-amazon/upgrade-android-sdk.htmlWhat we can say from this is that Amazon's authentication layer (referred to internally in the SDK as MAP) is designed so that other apps can reference the Amazon Shopping app's logged-in state. What the docs directly describe is SSO for apps using Login with Amazon, but it's reasonable to think that Amazon's own apps such as Kindle and Prime Video share the same auth layer too.The hypothesis, then: during data migration, only part of the authentication data was carried over in a corrupted state, and the startup process that tries to fetch that shared data is getting stuck. If that's right, it explains why nothing short of wiping the apps that hold the shared data will fix it.That said, specifics like "the first-installed app holds the auth data as the representative" or "only one particular app is the source" can't be asserted from public information. I'll check how solid the hypothesis is by reading the ANR trace in the second half.Here's the fix up front. The concrete steps:Open Settings > Apps > See all XX appsList every Amazon app installedFor each one, run Storage & cache > Clear storageOnce they're all cleared, restart the deviceThen open Amazon Shopping or Kindle — if a login screen appears, you're goodExamples of apps to target:Amazon ShoppingKindleAmazon Prime VideoAmazon MusicAmazon PhotosAmazon AlexaThe important point is that what you need to wipe is not "the app that's failing" but "every app that shares the authentication data." In my case, the one that finally did it was clearing Prime Video's storage. It was an app I barely ever opened, and until I cleared it, clearing the other Amazon apps did nothing. It may well have been the source of the shared data.Migration tools restore apps automatically from the old device's app list. As a result, you can end up with Amazon apps you haven't used in ages — ones you've forgotten you ever installed. In the user's mind it's an "app I don't use," but in the authentication-sharing network it's a full-fledged node, and the corrupted data sitting there drags down the apps you are launching. The instinct to "only clear the app that's failing" or "only clear the apps I actually use" backfires here.Now the main part. Let's verify whether this really is a shared-auth deadlock, using the ANR (Application Not Responding) stack trace.The first thing to establish: what's killing the app is an "ANR," not a "crash." A crash throws an exception and the process drops immediately; an ANR is the system force-closing the app after the main thread has failed to respond for some time (roughly several seconds to ten). Freezing on a blank screen and then closing is the classic ANR symptom — not an exception, but a timeout while waiting for a response.Since this was happening on my own device with my own account, I connected the Pixel to a Mac over ADB and pulled the diagnostic log (the stack trace) that the OS wrote out when the ANR occurred. Again, I'm not decompiling the app — just reading the diagnostic output the OS left behind.adb shell dumpsys dropbox --print data_app_anr | \  grep -A 200 "Process: com.amazon.mShop.android.shopping"The "DropBox" in dumpsys dropbox refers to DropBoxManager, the Android system-log mechanism that stores diagnostic entries (crashes, ANRs, and so on) over time. It has nothing to do with the cloud storage service of the same name. --print data_app_anr pulls only the entries tagged as app ANRs, filtered here by Amazon Shopping's process name.The trace recorded several threads running in parallel at startup. The key part: they were waiting on each other's locks. Let's read them in order.The main thread was stuck while running a startup task called AndroidComponentDetectTask."main" prio=5 tid=1 Blocked  at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(...)  - waiting to lock <0x00eb4d79> held by thread 37  at com.amazon.platform.service.ServiceRegistryImpl.getService(...)  at com.amazon.mShop.appStart.AndroidComponentDetectTask.apply(...)  ...  at android.app.ActivityThread.handleBindApplication(...)It's trying to acquire a lock, <0x00eb4d79>, and waiting for thread 37 to release it. This lock is one the Service Registry (the common registry where each subsystem registers and retrieves itself) takes internally when fetching or creating a service. On Android the main thread is the UI thread, so when it stops here, nothing gets drawn and the screen stays blank.The error-reporting init task (thread 36) was waiting on the exact same lock as main."StagedExecutor2-pool-19-thread-1" prio=5 tid=36 Blocked  at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(...)  - waiting to lock <0x00eb4d79> held by thread 37  at com.amazon.platform.service.ServiceRegistryImpl.getService(...)  at com.amazon.mShop.sam.log.SAMLogManager.initialize(...)  at com.amazon.mShop.errorReporting.ErrorReporter.startSession(...)Also waiting on <0x00eb4d79>. This Service Registry lock is a congestion point that multiple threads fight over at startup.The problem thread is thread 37. It was holding <0x00eb4d79> (the Service Registry lock) while trying to acquire another lock, <0x004a4835>, and getting stuck."StagedExecutor3-pool-20-thread-1" prio=5 tid=37 Blocked  - waiting to lock <0x004a4835> held by thread 62  at com.amazon.identity.auth.device.api.MAPAccountManager.getAccount(...)  at com.amazon.mShop.minerva.MinervaWrapperMAPClient.fetchAndSetAccountAttributeForTeen(...)  at com.amazon.mShop.minerva.MinervaWrapperMAPClient.<init>(...)  at com.amazon.mShop.minerva.MinervaWrapperServiceImpl.initializeMinervaClientIfNeeded(...)  at com.amazon.platform.service.ServiceRegistryImpl.instantiateService(...)  at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(...)  - locked <0x00eb4d79>Reading bottom to top, the sequence is:The Service Registry takes its internal lock <0x00eb4d79> to create a service (at this moment, main and thread 36 are made to wait)Still holding that lock, it proceeds into initializing the metrics SDK (Minerva) clientInside that, it calls MAPAccountManager.getAccount to fetch the currently logged-in accountThe auth SDK (MAP) tries to take another lock, <0x004a4835>, internallyBut that lock is held by thread 62 and never comes backThread 37 sits in the decisive position that triggers the deadlock: holding the Service Registry lock while frozen waiting for auth data. Because it won't release the lock it holds, main and thread 36 — which are waiting on it — stall in turn.On top of that, thread 27 (Weblab, fetching A/B-test flags) was also waiting on the same auth lock <0x004a4835> as thread 37."StagedExecutor1-pool-15-thread-1" prio=5 tid=27 Blocked  - waiting to lock <0x004a4835> held by thread 62  at com.amazon.identity.auth.device.api.MultipleAccountManager.getAccountForMapping(...)  at com.amazon.mShop.sso.SSOUtil.getCurrentAccountFromDisk(...)  at com.amazon.mShop.core.features.weblab.WeblabServiceImpl.getTreatmentAndCacheForAppStartWithTrigger(...)Weblab also needs auth information at startup, and via getAccountForMapping it's waiting on the same auth lock to be released. Note that thread 37 reaches the lock through MAPAccountManager and thread 27 through MultipleAccountManager — two different APIs converging on one internal lock.Laid out, the dependencies look like this:What stands out is that the tasks meant to run in parallel at startup (metrics, error reporting, A/B testing, component detection) all ultimately converge on a single point: "fetching the MAP auth data." Minerva and Weblab are supposed to be independent features, yet somewhere in initialization each one reaches for the same auth SDK to find out "who is logged in right now."That auth-data retrieval never returns, because the shared data is corrupted. Every task that needs auth stalls; and because the task holding the Service Registry lock has stalled, even tasks unrelated to auth (main, error reporting) get dragged down. That's the full chain that leaves the screen blank until the ANR fires.Following thread 62 — the one stuck while holding the auth lock — it was sending a query to another process via a ContentProvider and waiting for the response. A ContentProvider is Android's mechanism for sharing data between apps, and Amazon's apps appear to use it to pass authentication data around. It seems thread 62 was stuck holding the auth lock because one of the sharing sources never returned a response. Which app, and why it didn't respond, can't be pinned down from this trace alone. But the structure — "go fetch the shared auth data from the source, and it never comes back" — is consistent with the fact that wiping every Amazon app's storage fixed it.Strictly speaking, this isn't a circular wait where two threads grab each other's locks (the textbook deadlock). It's a hang: a thread holding a lock freezes waiting on an external process, and the threads waiting on it stall in a chain. But since the outcome — "stuck holding a lock, with everyone waiting on it blocked forever" — is no different from a deadlock, I'm calling it a deadlock in this article.The textbook lessons — "acquire locks in a consistent order," "don't block the main thread" — apply here too, of course. But what the trace really surfaced is the pitfall that emerges when well-intentioned design decisions pile up. Parallelization for speed, auth lookups for functionality, cross-app data sharing for convenience. Each is reasonable on its own, but stacked together they become the following three pitfalls.Initializing subsystems in parallel to speed up startup looks like a correct optimization. Indeed, the trace recorded several init tasks running concurrently on separate threads — metrics, error reporting, A/B testing, component detection.The thing is, many of them internally call the same shared operations: "register with the Service Registry" and "fetch the current logged-in account." Even run in parallel, they end up serialized on the shared resource's lock. On its own that just makes startup slower — but when the thread holding a lock stalls on something else, everyone waiting gets swept up all at once, as happened here.Parallelization aimed at speed becomes effectively serial under shared-resource contention, and in the worst case deadlocks. The most dangerous spot is the assumption that "it parallelized, so it must be faster." When you add startup tasks, you have to look at how each one touches shared resources (registry, auth, settings store) as a set — otherwise you not only fail to get the scaling benefit, you raise the odds of a deadlock.The most surprising thing in the trace was that both metrics and A/B testing — features that look unrelated to auth — were reaching for "who is logged in right now" during initialization. Metrics wants to attach user attributes; A/B testing wants to bucket by account. The reasons are each fair enough, but the result is that the auth SDK has become an implicit dependency point for the entire app.When auth-data retrieval jams at a single point, it's not auth itself that stops — it's every feature that referenced auth, stalling in a chain. You need to recognize that auth isn't "a concern around the login screen" but "a critical path of the entire startup sequence." If you count how many subsystems call auth-data retrieval at startup in your own app, the number may be higher than you'd imagine.A design where multiple apps share authentication data is convenient for users — sign in once and you don't need to log in again on the other apps. The problem is that "who owns this shared data, and who fixes it when it breaks" is left implicit.Suppose there's an implicit rule like "the first-installed app is the representative." If migration doesn't reproduce the install order or state, the ownership relationship goes adrift. The owner sits there holding corrupted data while other apps go to reference it. The fact that nothing was fixed until I cleared Prime Video this time may have this ownership ambiguity in the background. Shared data needs a fallback — another app taking over, or safely regenerating the data — for when the owner disappears or its data breaks.Even if you're not in a position to change the design, knowing this structure changes how fast you can respond.For support: keep in mind that "please reinstall" only works when the problem is contained within a single app. For a post-migration report of "only certain apps won't launch," suspect that migration left the shared data corrupted, and being able to offer the next move — "clear storage for the related apps as a group" — changes the opening response. Even just asking "did this start right after switching phones?" up front can sometimes narrow the investigation considerably.For users: think of the cleanup target as "every app from the same provider," not "the app that's giving you trouble." Keeping in mind that even an app you don't use is a node in the sharing network, and that corruption there causes collateral damage, raises your odds of getting out of it on your own.It's not just Amazon — there are plenty of designs where multiple apps share authentication information.Sharing auth tokens across apps via Android's standard AccountManagerSharing login information across same-signature apps through a ContentProviderGroups of apps with a common account platform (cross-app login across several apps from the same company, for example)When these combine with a design that "initializes many subsystems in parallel at startup," the same conditions line up as in this case: when the shared data breaks, every app chain-fails to launch, and a single reinstall won't fix it. If your own app group meets these two conditions, it's worth checking once how you guarantee consistency across a device migration, and how you degrade or regenerate when the sharing source breaks.If you run into apps not launching after switching phones, first try "if a single clear doesn't fix it, clear the group of related apps." That's the shortest fix from the user's side. When the sharing source is broken, you have to wipe the source along with the rest.From the design side, the three pitfalls this trace surfaced are worth remembering: parallel init can backfire on shared resources; auth tends to become an implicit critical path for every feature; and ownership of shared data goes adrift during migration. Each is a "well-intentioned design" on its own, yet combined they produce an app that won't start."Please reinstall" only holds up as a universal fix for designs contained within a single app. For apps that hold shared data and carry a complex startup sequence, the same symptom recurs even after reinstalling. Just knowing this one structure makes a real difference in how fast you respond the next time you hit the same incident.

"Reinstalling Won't Fix It": A Cross-App Shared-Auth Deadlock After Switching Phones

新しいAndroidスマートフォンに機種変更したあと、特定のアプリだけが起動しなくなる事象に遭遇しました。AmazonショッピングとKindleが、真っ白・真っ黒な画面でしばらく固まったあと勝手に閉じる。再インストールしても、ストレージを削除しても、OSをアップデートしても直らない。一般的なサポート手順をひととおり試しても、状況は変わりませんでした。最終的に、Amazon系アプリ群を全部一括でストレージ削除することで解決しました。原因をADBログから追ったところ、複数アプリで共有している認証データの整合性が壊れていて、起動時の認証取得処理がデッドロックしていることが分かりました。事象...

「再インストールでは直らない」スマホ機種変で起きたアプリ間共有認証データのデッドロック

On April 22, 2026, AWS added a "managed agent harness" (preview) to Amazon Bedrock AgentCore. With this feature, you declare the model, system prompt, and tools as configuration, and the agent runs—the orchestration code lives on the AWS side as managed.https://aws.amazon.com/blogs/machine-learning/get-to-your-first-working-agent-in-minutes-announcing-new-features-in-amazon-bedrock-agentcore/What stands out about this release is less the feature itself and more AWS's adoption of the term "agent harness." Since Martin Fowler wrote his harness engineering essay in February 2026, Anthropic and OpenAI have started using "harness" officially, and now a cloud vendor has applied the same word to its own service.https://martinfowler.com/articles/harness-engineering.htmlFrom the perspective of someone who has been assembling a harness by hand, the question becomes: what does managed harness take over, and what stays in my hands? This article sorts out that dividing line. Drawing on experience running business-automation agents with Claude Desktop, multiple MCP servers, and Markdown-based knowledge, I lay out the correspondence with AgentCore managed harness.A few "tried it out" articles have already been published, so this article positions itself as the prequel: it offers material for deciding whether to adopt, not adopt, or how to phase in. Drawing on the official blog, documentation, and existing explanatory articles as sources, I sort out the correspondence and the judgment criteria that emerge from self-built operation.The official blog mentioned above lays out the structure: every agent has an orchestration layer, and running that layer requires compute, a sandbox to safely execute code, tool connections, persistent storage, and error recovery as the underlying infrastructure—bundled together, they form the agent harness. Managed harness is AWS providing this harness as a managed offering, where the user declares the model, system prompt, and tools as configuration, and a working agent is the result.Let me first align on what the word "harness" refers to. The term gets used both for what the vendor builds in (internal) and for what the user assembles around the agent (external), and the meaning shifts with context. In addition to Fowler's framing, watany has organized the internal/external confusion in a Zenn article.https://zenn.dev/watany/articles/d8b692bbca65a3This article is written from the position of "someone who has been assembling the external environment by hand"—the user-side harness, in operation. AgentCore managed harness can be read as the vendor-side internal harness now offered as managed, but from the user's perspective, it can also be read as: part of what we used to build for ourselves can now be delegated. This duality is the starting point for thinking about where responsibilities split with self-built operation.Let me map my self-built harness to AgentCore's components. The environment I've been operating consists, broadly, of three elements, and I'll lay out how each one corresponds to something on the AgentCore side.Self-built harnessAgentCore sideDegree of correspondenceMarkdown knowledge files (under agents/, knowledge/)AgentCore MemorySimilar role; persistence and retrieval mechanisms differMCP servers (task management / calendar / chat / document management, etc.)AgentCore GatewayMCP is becoming the standard, so they're closeClaude DesktopAgentCore RuntimeThe execution base for the agent loop, at a different scale(none)AgentCore IdentityNot implemented in self-built(none)AgentCore PolicyNot implemented in self-built(none)AgentCore ObservabilityNot implemented in self-built(none)AgentCore EvaluationsNot implemented in self-builtThe top three are the correspondence between "what I assembled by hand" and "what AgentCore provides as managed for the same role." The bottom four are blank layers in the self-built harness—components AgentCore offers that aren't covered by my operation.The natural question here is whether these four blank layers are "things I didn't write because I didn't need them" or "things I wanted but had given up on." The two are different. For the former, introducing managed harness yields little value; for the latter, it brings value.Let me go through the four layers in order.Identity is for managing authentication and permissions when multiple users access the agent. Since my self-built harness runs on a personal device, authentication can rely on the device login, and per-agent authentication wasn't necessary. This is unnecessary "as long as it's just me." The moment you try to share an agent across an organization, controlling who can call which MCP for what becomes a problem, and the gap surfaces in the form of resignation.Policy is the mechanism for declaratively defining boundaries when the agent calls tools. It's based on Cedar, AWS's open-source policy language, and you can generate policies from natural language. In my self-built harness, I draw loose boundaries through MCP server scopes and by documenting "what not to do" in the knowledge files—but this is discipline, not enforcement. I had wanted to write strong, enforceable boundaries, but didn't have the motivation to build a Cedar-equivalent system myself, so I had given up on this area.Observability is the mechanism for emitting agent execution logs, traces, and metrics to CloudWatch for visualization. In my self-built harness, I have the conversation history in Claude Desktop and individual logs from each MCP server, but no mechanism to track "which agent called what when, and how it failed" across the board. For solo use, looking at the chat screen suffices, but this becomes necessary in organizational deployment, and falls into the resignation category.Evaluations is the mechanism for continuously evaluating the agent's response quality, with built-in evaluators for dimensions like helpfulness, tool-selection accuracy, and correctness. In my self-built harness, I check subjectively through knowledge-file improvement history and daily work logs, but I have no quantitative quality monitoring. For solo use, subjective is enough; but for organizational operation or paid services, this becomes essential.Looking back at the four layers, only Identity falls into "unnecessary as long as it's just me," while the other three fall into "would have been nice, but had given up on as self-built." The fact that the meaning of "blank" differs by layer affects the judgment of whether to adopt managed harness.When you use managed harness, what stops being something you write, and what continues to require writing? This can be derived as fact from the official blog and documentation, so let me sort it out first.What managed harness takes over is the following range:The agent loop: calling the model, selecting tools, returning results, managing context, and recovering from errorsA microVM, filesystem, and shell isolated per sessionTool-connection orchestration via AgentCore GatewayThe framework portion based on Strands AgentsConversely, what users still need to write even when using managed harness is the following range:Which model to useWhat to write in the system promptWhich tools to make callableWhat goes into AgentCore Memory and what doesn'tWhat boundaries to declare in AgentCore PolicySince declaration-based configuration suffices, the amount of code drops significantly. However, the five items above are simply "what you write as configuration changes"—the judgments themselves don't go away. They just shift into the form of the harness.json configuration file. Reading preview validation articles by people who have actually tried managed harness, you'll see that harness.json lists the model and tool list as declarations, while a separate system-prompt.md file holds the system prompt.https://dev.classmethod.jp/articles/bedrock-agentcore-managed-harness-preview/https://github.com/aws-samples/sample-AgentCore-Managed-Harness-NewsThis looks like what was previously written as Markdown system-prompt files and MCP connection definitions in the self-built harness, repackaged into AWS's configuration file format.In other words, what managed harness takes over is "the labor of writing orchestration code," not "the judgment of designing the agent." Design judgments still rest with the user. AWS expresses this as removing the infrastructure barrier, but the non-infrastructure part—"what is this agent for, and how far should it be allowed to go"—remains on the human side, whether it's managed or self-built.This distinction is an important perspective when judging whether to adopt managed harness. The pitch "you don't have to write code" is accurate, but reading it as "you don't have to think" makes it inaccurate.When you operate a self-built harness, you accumulate judgments about "where it's okay to move things, and where you must not." These don't go away when you adopt managed harness. The place where they appear shifts to the contents of harness.json, but the judgments themselves continue to rest on the human side. Let me name a few representative ones.Knowledge file granularity. Whether to split your Markdown knowledge "by role" or "by task" is a judgment that, once made, eases subsequent operation. Splitting by role lets agent dispatch fall naturally out of context. Splitting by task scatters cross-task knowledge. There's no simple winner; the optimum depends on the number of agents you operate and how tasks overlap. Even with managed harness, the same question—what to combine in Memory and what to separate—remains.MCP server combination design. This is the line between "how far to wire up as tools via MCP" and "how far to handle through local file operations." For example, task management is better suited to MCP via API for automation, while sensitive tasks are safer kept as local file operations—judgments that emerge through use. Managed harness's Gateway has to answer the same question, just translated into declarations in a tool list.Agent-to-agent responsibility split. This is the design choice between having a coordinator agent that judges context and dispatches to specialist agents, or calling specialist agents directly from the start. The coordinator style depends on context-judgment accuracy; the direct-call style puts the discrimination burden on the user. This too remains as a design judgment in managed harness, in the form of how to arrange and connect multiple harnesses.These three are judgments that are hard to articulate without operating self-built first. If you start from managed harness, these judgments end up looking "as if they were optimally placed from the beginning." In reality, you've just fixed the premises, but inside fixed premises, the existence of design judgments themselves becomes harder to see.Here's a counterargument I anticipate: "If we just use managed harness from the start, we won't need to build anything ourselves."I partially agree with this counterargument. If you're building a new agent for organizational production from zero, going in through managed harness is faster, I think. However, the design of an agent to run in production rarely "is visible from the start." Only by actually using the agent do the granularity of knowledge, the over- and under-supply of tools, and the boundaries of responsibility come into view. Whether you run this discovery flow on top of a managed harness with set boundaries, or on a self-built harness with high freedom, changes the amount of learning you get.Another perspective: judgments gained from self-built operation can be reused as a blueprint when you migrate to managed harness. If you go into managed harness without a blueprint, you can produce something that appears to work, but a system remains where it's hard to explain why it was structured that way. Whether "let's just put it on managed harness and improve it as we go" works depends on whether one person is improving or multiple people are improving. For one person, the iteration speed gap between self-built and managed may be small; but at the stage where multiple people improve, the declarative changes in harness.json and the deploy-unit iteration cycle start to take a toll as operational debt.Whether to adopt managed harness can naturally branch by operational scale. Let me go through three stages.In the personal-use stage, where one person is using the agent, the self-built harness is often sufficient. The editing and use of knowledge files are tightly coupled, and the iteration of "rewrite Markdown the moment you notice something while using it" runs fast. Both Identity and Observability are hard to recognize as gaps as long as you're operating solo, and end up in the "would-be-nice-to-have, maybe" zone. In the experimental stage, this freedom directly translates into learning speed.At the stage of expanding to organizational operation where multiple people use the agent, the four blank layers all surface as problems at once. You need audit logs of who used which agent how (Observability); you start running into situations where shared environments must not allow tools to be called freely, so boundaries become necessary (Policy); you need to manage credentials per member (Identity); you want to continuously measure agent response quality (Evaluations). At this stage, the value of managed harness comes to the fore. Comparing the labor of writing the four layers yourself versus putting them on AgentCore, the latter becomes practical.In the transition phase, you can take a hybrid strategy. Continue the personal exploration stage with a self-built harness, and put only the confirmed paths used in organizational operation onto managed harness. Move agents whose design has settled to AgentCore in order, and keep agents that are still being learned on while running close at hand.There's also a guideline for the order of adoption. The first things needed for organizational deployment are Identity and Observability, then Policy, and finally Evaluations. Without Identity, sharing itself doesn't get established. Without Observability, the organization can't make operational judgments. Policy is often too late after an incident, so placing it early in organizational deployment is safer. Evaluations can come in the order of "after operation gets going, then introduce quality measurement"—that's fine.The harness was originally a concept lying at the boundary between those who build agents and those who use them. With AWS releasing managed harness, part of what we used to assemble by hand has shifted into a mechanism that runs simply by declaring it as configuration. The fact that layers like Identity, Observability, and Policy—which I had given up on as self-built—have come within reach is no small thing.Even so, design judgments such as "what is this agent for," "what to leave in the knowledge," and "how far to grant tools authority" haven't been put into a form you can declare as configuration. The basis of these judgments will continue to live in the commit history and work logs of one's own repository. The experience of having built a self-built harness leaves behind, in your hands, knowledge that doesn't lose its value when you migrate to managed. With the arrival of managed harness, the boundary between "the layers we build ourselves" and "the layers only human judgment can carry" has become more clearly visible than before, you might say.

What AgentCore Managed Harness Takes Over, What It Leaves to You

2026年4月22日、AWSはAmazon Bedrock AgentCoreに「managed agent harness」（プレビュー）を追加しました。モデル / システムプロンプト / ツールを設定として宣言するだけでエージェントが動く仕組みで、オーケストレーションコードはAWS側がマネージドで持ちます。https://aws.amazon.com/blogs/machine-learning/get-to-your-first-working-agent-in-minutes-announcing-new-features-in-amazon-bedrock-agentcore...

自前ハーネスを持つ意味: AgentCore managed harnessとの分業線

Claude Managed Agents: The Layer That Disappears, The Layer That Stays — A View from Business Automation Agents

2026年4月8日、AnthropicがClaude Managed Agentsを公開しました。公式は「meta-harness」と位置付けており、ブログでは「p50 TTFT 60%減・p95 90%減」というインフラレベルの改善が報告されています。TTFTはリクエストから最初の応答が返るまでの時間で、p50は中央値、p95は最も遅い5%を含む側の遅延を指します。中央値で6割短く、遅い側でも9割短くなった、ということです。マイナーな最適化では出ない、アーキテクチャ変更レベルの効果といえる数字です。Notion、Rakuten、Asana、Sentry、Vibecodeといった企業が早...

Claude Managed Agents で消える層、残る層: 業務自動化エージェントの視点から

In April 2026, Google Labs released a spec called DESIGN.md. It's a design system specification readable by AI agents, packaged with a CLI validator: npx @google/design.md lint.With DESIGN.md in the picture, we now have three different file types for instructing AI agents. AGENTS.md has been spreading as an industry standard since 2025 (jointly developed by OpenAI, Google, Sourcegraph, Cursor, and Factory; donated to the Linux Foundation in December 2025). SKILL.md sits at the core of Anthropic's Claude Skills. And now DESIGN.md. The three handle different concerns and don't overlap.This article is for developers using coding agents like Claude Code, Cursor, or Codex in their work, and for tech leads operating natural-language instruction files like CLAUDE.md and style guides. If your team is doing Spec-Driven Development (SDD), this should also reach you.What I want to lay out is two things: how AI instructions are starting to split across three layers — behavior, individual tasks, and visual appearance — and how that connects with SDD as a parallel movement.A few years into the ChatGPT era, most engineers have written some form of "rules I want the AI to follow" in a Markdown file. CLAUDE.md, styleguide.md, CONTRIBUTING.md, internal coding conventions. The locations vary, but the format is roughly the same: unstructured natural language.A writing-style-guide.md file I've been building over the past few months is a typical example. It's a style guide I use when writing technical articles with Claude — a list of patterns common in AI-generated text, written down as forbidden phrases. By making Claude Desktop read it every session, the tone of my output stays consistent. It's part of a personal repository (ikenyal-ai-agents) I use as the harness for my business automation agents — the one I covered in my previous post.https://dev.to/aws-builders/harness-engineering-with-nothing-but-markdown-g6bThe file contains roughly 150 lines: rules like "don't use em dashes," "avoid invitations like 'let's try…!'," "drop AI-style preambles like 'what's interesting is…'." The same repository has 15 instruction files under agents/, organized by team and role: executive-assistant.md, sre-support.md, qa-support.md, accounting.md. Each describes "the assumptions to operate under as this role" in plain natural language.This approach has clear benefits. You can articulate tone, stance, and implicit rules. New team members can read the files and pick up the expectations. With CLAUDE.md, Claude Code reads it every session, so persona-level instructions land consistently.There are limits, too. First, validation falls on humans. Whether a rule was followed or not gets decided by a human reading the output. Second, individual judgment leaks in. "Write politely" means different things to different reviewers.The third limit is the actual subject of this article. Rules that are formally verifiable (forbidden phrases, em-dash usage, specific pattern matches) and rules that require judgment (tone, structural choices, how to open with empathy) sit in the same file. So even the verifiable parts end up depending on human review. That's the problem the three new file types are addressing.On April 10, 2026, Google Labs published the DESIGN.md specification at google-labs-code/design.md. As of early May, the repo has over 11,000 stars. It's the reference implementation for Google Stitch (stitch.withgoogle.com), an AI-driven UI generation product.https://github.com/google-labs-code/design.mdThe specification doc lives on the Stitch side.https://stitch.withgoogle.com/docs/design-md/specificationWhat DESIGN.md covers is the design system specification. You write machine-readable design tokens in YAML at the top of the file (colors, typography, spacing, components), and human-readable design intent in the Markdown body underneath. Both live in the same file.---name: Heritagecolors:  primary: "#1A1C1E"  tertiary: "#B8422E"typography:  h1:    fontFamily: Public Sans    fontSize: 3rem---## OverviewArchitectural Minimalism meets Journalistic Gravitas.## Colors- Primary (#1A1C1E): Deep ink for headlines and core text.- Tertiary (#B8422E): "Boston Clay", the sole driver for interaction.The headline feature of this format is the CLI validator that ships with it.npx @google/design.md lint DESIGN.mdThis checks token reference integrity, WCAG contrast ratios, and structural rule compliance, returning the result as JSON. Wire it into CI and you can verify design system consistency on every pull request. There's also a diff command that compares two DESIGN.md files and returns token-level changes in a structured form. Design system version control — historically a manual process — gains a verifiable layer.For Japanese UIs, the Google Labs spec alone falls short. It doesn't define the typography requirements specific to Japanese (CJK font fallback chains, line height, letter-spacing, kinsoku shori, mixed typesetting). The gap is filled by kzhrknt/awesome-design-md-jp, which publishes Japan-localized DESIGN.md files for over 10 services including Apple Japan, SmartHR, freee, note, MUJI, Mercari, LINE, and Toyota. For Japanese products, using both the Google Labs spec and the Japan edition together is the practical approach.https://github.com/kzhrknt/awesome-design-md-jpWhat DESIGN.md carries is the design system that used to be scattered across Figma files and style guide PDFs, now consolidated into a single file with both machine-readable and human-readable parts. Think of it as the spec foundation that lets AI agents generate UIs with a consistent look every time.While DESIGN.md covers "appearance," SKILL.md and AGENTS.md cover "behavior" — defining what the agent is trying to do, how it should proceed, and what it must not do.SKILL.md is the file format standardized by agentskills.io as part of the Agent Skills open standard. Anthropic's Claude Skills is one implementation of this standard; the same SKILL.md works across Claude Code, Claude.ai, and the Agent SDK. Because it's standards-compliant, the same file is also readable by other agents like OpenClaw and Hermes. The structure: declare metadata (skill name, description, allowed tools) in the YAML at the top of the file, and write the task procedure or domain knowledge in the Markdown body below.https://agentskills.io/homeA clear example of SKILL.md is conorbronsdon/avoid-ai-writing. It's an English-only skill that detects and rewrites AI patterns in English text — transition phrases like "Moreover," significance inflation like "watershed moment," and roundabout verb constructions like "serves as." It uses a 100+ word replacement table organized into 3 tiers (Tier 1 always replaces, Tier 2 flags when 2+ words appear in the same paragraph, Tier 3 flags only at high density), and audits 36 pattern categories. Two modes: detect and rewrite.https://github.com/conorbronsdon/avoid-ai-writingWhat sets it apart from a one-shot prompt is the structured audit it returns. In rewrite mode, you get four discrete sections: identified issues, the rewritten text, a summary of changes, and a second-pass audit. What changed and why becomes transparent.AGENTS.md covers the agent's overall behavior. Project assumptions, roles, prohibitions, escalation rules. As I mentioned at the top, it started with the Amp team at Sourcegraph; today OpenAI, Google, Cursor, and Factory jointly drive it, and it was donated to the Linux Foundation in December 2025. Think of CLAUDE.md as the Claude-specific version of AGENTS.md. Claude Code reads CLAUDE.md rather than AGENTS.md in its spec, but the pattern recommended by agents.md is to make AGENTS.md the actual file and symlink CLAUDE.md to it. In the personal repository I introduced earlier, the files under agents/ belong to this layer.SKILL.md and AGENTS.md cover different ranges. AGENTS.md handles "overall context and boundaries." SKILL.md handles "an executable unit for a specific task."The avoid-ai-writing English style auditor I mentioned is a specific task, so it ships as SKILL.md. A file like agents/genda/qa-support.md, which describes the assumptions and engagement style of a QA role, defines the agent's boundary — that goes on the AGENTS.md side.The shared concern of these formats is "behavior and procedure," not visual appearance. What the agent knows, what it's tasked with, what it must avoid. That's a movement to fix these in a verifiable form.Lining up the three file types, the layers each one handles become clear.LayerFormatWhat it carriesExamplesBehaviorAGENTS.md / CLAUDE.md (natural language + rules)Overall context, roles, prohibitionsCLAUDE.md, role-specific files like agents/genda/qa-support.mdIndividual taskSKILL.md (YAML at top + Markdown body)Reusable tasks, procedures, domain knowledgeavoid-ai-writing, in-house procedure skillsAppearanceDESIGN.md (YAML at top + Markdown body)Design system spec, verifiable visual rulesThe Google Labs reference, individual service files in kzhrknt/awesome-design-md-jpThe three are complementary, not competing. CLIs like bergside/typeui are emerging as tools that can generate or update either SKILL.md or DESIGN.md, depending on what you choose — a sign of tooling that assumes the division of labor.https://github.com/bergside/typeuiWhat's actually different across the layers is "where to place the balance between machine-readable and human-readable." AGENTS.md skews almost entirely human-readable; over-structuring it would block the contextual judgment and nuance it needs to convey. SKILL.md is partially structured by the YAML at the top, but the body stays human-readable — task granularity has to be readable by humans before it can be instructed. DESIGN.md puts machine-readable design tokens in the top YAML and human-readable design intent in the body, with the two cleanly separated.The center of gravity between "machine-readable" and "human-readable" sits in different places per layer. That's just the standard structuring principle — "manage things at different layers in different files" — applied to AI agents. The file names themselves spell out the division: AGENTS.md ("instructions to the agent"), SKILL.md ("a reusable skill"), DESIGN.md ("the design system"). The names match what each one carries.Teams that have been packing all their "AI rules" into a single CLAUDE.md now face a split decision. Open up your CLAUDE.md and run these questions against it — splits start to surface:Is there a section writing design system rules? → If yes, that goes to DESIGN.mdAre specific task procedures in there (monthly aggregation, test review, contract review)? → If yes, those go to SKILL.mdWhat's left is overall agent context and boundaries (roles, prohibitions, escalation criteria) → that's the AGENTS.md equivalent that staysThe three-layer split works as a framework for splitting your file.Stepping back to look at the bigger picture: how does the three-layer split relate to the broader movement of "specs for AI"?SDD is a development style where you write the spec — requirements, design, tasks, implementation — before generating the code. The underlying idea: "specs aren't disposable scaffolding, they're executable artifacts that produce code." AWS's Kiro provides a workflow that generates requirements.md, design.md, and tasks.md in order under .kiro/specs/{feature}/. GitHub's Spec Kit (over 90,000 stars) supports the same flow with slash commands like /specify, /plan, /tasks, /implement. The EARS notation (Easy Approach to Requirements Syntax) used by Kiro reduces ambiguity by formatting requirements into 5 fixed templates. SDD has spread quickly between 2025 and 2026.https://kiro.dev/https://github.com/github/spec-kitThe three-layer split (AGENTS.md / SKILL.md / DESIGN.md) and SDD look like separate movements on the surface. The SDD community concentrates on Kiro and spec-kit usage; the DESIGN.md side concentrates on formal specs and validation tooling. You don't see many articles bridging the two.But put their philosophies side by side and the overlap is striking.#Shared philosophySDD (Kiro etc.)DESIGN.md / SKILL.md / AGENTS.md1Specify before implementingrequirements → design → tasks → implementationbehavior → implementation, appearance → implementation2Mix machine-readable + human-readablerequirements.md (EARS notation) + natural languageYAML at top + Markdown body3Persistent context for the AIreference .kiro/specs/{feature}/ every timereference DESIGN.md / AGENTS.md every time4Reduce ambiguity through structured syntaxEARS notation structures requirements (5 templates)lint validates WCAG contrast ratios and structural rules5Fix "decisions made" as a placespec files are where decisions livespec files are where decisions liveBoth sit inside the larger "specs for AI" movement and share the same underlying philosophy.That said, they're not the same thing. The biggest difference, in one phrase: time horizon.#AxisSDDDESIGN.md / SKILL.md / AGENTS.md1Time horizonDescribes "what to build next"Describes "rules that already exist"2ScopeSingle feature / project lifecyclePersistent rules and styles3Update rhythmNew per feature → consume → archiveLong-term maintenance, gradual growth4SubjectRequirements, design, tasks (procedure for action)Rules for behavior, individual tasks, appearanceSDD specs describe "what we're going to build." requirements.md is "what this feature needs to satisfy"; design.md is "how to implement this feature"; tasks.md is "how to break the feature into work." Once the feature ships, they finish their job and get archived.The three-layer specs describe "what should always hold." DESIGN.md provides the color and typography rules every time you generate a UI; AGENTS.md provides the agent's assumptions across every session. They get maintained long-term and grow incrementally.This time-horizon difference is why the two don't compete. Transient specs and persistent specs coexist in the same project. They can also reference each other. Imagine writing "use {colors.tertiary} for the button" inside .kiro/specs/checkout-feature/design.md — that lets a transient feature spec reference a color token from a persistent DESIGN.md. The pattern isn't widely established yet, but the structure fits cleanly.One thing worth noting: as of May 2026, the active areas of SDD (the Kiro community and similar) and the active areas of DESIGN.md / SKILL.md / AGENTS.md haven't really crossed paths. The SDD side concentrates on "how to build a feature"; the three-layer side concentrates on "how to deliver the rules."You don't have to be doing SDD to start with the three-layer split — the split alone gets you to the door of "specs for AI." If your team is already on SDD, start referencing DESIGN.md tokens from inside your feature specs and you avoid maintaining the same rules in two places. The two movements look set to converge in the next phase.The discussion of the three-layer split tends to drift toward "shouldn't we just spec everything," but in practice, that doesn't happen.Rules that can't be formally verified stay as natural-language documents. Tone, structural choices, cultural nuance. Things like "how to open an article with empathy" or "how to give an ending the right amount of resonance" — judgment-based qualities. The cost of speccing them isn't the issue; the essence falls out when you try.The judgment is straightforward: "is this formally verifiable?"Color contrast ratios (verifiable) → DESIGN.mdWord substitutions like "leverage → use" (verifiable) → SKILL.mdTone (soft assertions, not textbook-sounding), overall stance (not teaching, just organizing) and similar (not verifiable) → stays in AGENTS.md / CLAUDE.mdFor small teams, "one natural-language file" is often enough. If CLAUDE.md alone is keeping things running, there's no need to force a split. The trade-off between the cost of speccing and the load of operating it depends on team size and how long the operation has to last.The three-layer split is something you adopt incrementally, just like SDD — you don't need to spec everything at once. Start with the complex areas, the areas where verification helps most.In other words, the three-layer split isn't a goal. It's an option you adopt when the situation calls for it.A few options come into view from this overview.A reasonable first move is to open your CLAUDE.md or style guide and sort it into "formally verifiable" and "judgment-based" sections. Color and typography rules, word substitution lists, structural rules. If a useful amount of verifiable content sits there, pick one to break out into either DESIGN.md (appearance) or SKILL.md (task). Don't try to split everything at once — start with the most independent piece.Pulling in external skills is another route. Drop a ready-made SKILL.md like avoid-ai-writing into ~/.claude/skills/ and your stance as a writer doesn't change — only the verification gets handed off to the machine.Teams already running Kiro or spec-kit are probably at the stage where they could try referencing DESIGN.md tokens from inside .kiro/specs/{feature}/design.md. The cross-reference between feature specs and persistent specs is still a thin area in terms of public examples.The shared stance: don't try to spec everything at once. Document split → operational trial → speccing — staged migration is the realistic path. The three-layer split isn't a finished form. It's a movement still in progress, and that's the safer way to read it.AI rules started splitting from a single natural-language document into three spec formats. That's another side of the same movement as SDD.Not everything becomes a spec, but managing different roles in different files — that ordinary structuring is starting to apply to AI agents, too.

AGENTS.md, SKILL.md, DESIGN.md: How AI Instructions Split into Three Layers

2026年4月、Google Labsが DESIGN.md という仕様を公開しました。AIエージェントが読めるデザインシステムの仕様で、npx @google/design.md lint というCLI検証ツールがセットになっています。DESIGN.md の登場で、AIエージェントに渡す指示書ファイルが3種類目に揃いました。2025年から業界標準として広がってきた AGENTS.md（OpenAI・Google・Sourcegraph・Cursor・Factoryらが共同で策定、2025年12月にLinux Foundationへ寄贈）、Anthropic Claude Skills...

AIに渡す指示書の役割分担: AGENTS.md/SKILL.md/DESIGN.mdと仕様駆動開発の現在地

If coding agents aren't your primary battlefield, "harness engineering" probably feels like a distant concept. Scrolling through a timeline full of articles written for Claude Code and Codex users, you may have thought, "This isn't about me."My own agent use wasn't centered on coding either, so none of the articles out there seemed to apply to my case. But looking back, I'd been doing the same thing — it just didn't have a name yet.I've been running a business automation agent via Claude Desktop (through MCP servers) for several months now. It gathers information across multiple work tools like Slack, Confluence, and Google Calendar, switches judgment criteria based on context, and produces outputs accordingly. What the agent refers to goes beyond surface-level rules — accumulated knowledge such as understanding of organizational structure, past decision-making history, and writing style guidelines forms the foundation for its judgment.I haven't written a single line of code. All I write is Markdown. And most of that Markdown is generated by the agent itself — I just approve or give revision instructions through chat. I almost never open the files directly to edit them.This article isn't for people already practicing harness engineering. It's for those who've heard the term but thought, "That's a coding thing, right?" — I'm sharing the structure I've found. Each example includes a ready-to-use sample, so if you're running a business automation agent with MCP, you can try them as-is.Let me set the foundation.Mitchell Hashimoto, co-founder of HashiCorp, gave the name "Engineer the Harness" to a practice he'd cultivated in his AI agent workflow, in a February 2026 blog post. The approach: when an agent makes a mistake, instead of fixing the prompt, build an environment where the same mistake can't happen again.https://mitchellh.com/writing/my-ai-adoption-journeyDays later, OpenAI published a practice report titled "Harness engineering." A small engineering team spent five months building a product using only Codex agents with zero hand-written code, and the repository reached roughly one million lines. The back-to-back publication of Hashimoto's blog and this report cemented "harness engineering" as a term.https://openai.com/index/harness-engineering/In the coding agent context, this translates to implementations like banning specific patterns with ESLint, defining commands in AGENTS.md, and running automated reviews via pre-commit hooks.From "asking" (prompts) to "building" (environment). That's the core.Up to this point, the story seems confined to the world of coding agents. But in 2025, MCP became widespread and rapidly expanded the practical scope of non-coding agents. Once agents gained direct access to business tools like Slack, Confluence, Google Calendar, and Jira, the risk of "agents making mistakes on their own" spilled beyond coding. Harnesses are no longer just for coding agents.When you incorporate agents into business workflows, you run into experiences like these.You write "don't make financial judgments" and it makes them anyway. You write "don't post directly to Slack — create a draft" and it tries to post. You write "commit and push at the end of the session" and it forgets.Each time, I'd rewrite the prompt. Under the assumption that "if I write it more clearly, it'll understand."At some point, I realized the assumption itself was wrong. No matter how much you polish a prompt, the agent makes the same mistake in the next session. Instructions get buried in long contexts. When the session ends, memory disappears entirely. Requests are volatile.Stop expecting the agent to remember. Change the environment instead. Looking back, this was the entry point to harness engineering.When I lined up what I'd been doing in my repository, the same structure as coding agent harnesses emerged.Coding Agent EnvironmentNon-Coding Agent EnvironmentESLint / TypeScript strict type enforcementProhibited actions section under agents/AGENTS.md command definitionsContext routing rules in instruction filesPre-commit hooksMandatory actions at session endCI gates (can't merge unless tests pass)Forced knowledge accumulation rules under knowledge/The materials on each side are completely different. One uses linters and hooks, the other uses Markdown files. But the design intent is the same: building an environment outside the agent where the agent can behave correctly.One prerequisite to note: most AI chat tools have a designated place for instruction files that are automatically loaded at session start. In Claude Desktop it's Project Knowledge; in ChatGPT it's Custom Instructions. What I call "instruction files" in this article are Markdown files placed in this mechanism. Unlike writing in the prompt each time, they're automatically placed in a position that's hard to bury even as conversations grow longer.Here are three concrete examples, each with a ready-to-use sample.Say you've delegated Slack posting to your agent. Even if you write "don't post directly — create a draft" in the prompt, it forgets across sessions.The solution is to create a prohibited actions section in the instruction file and structure it so it's loaded every session. Move the instruction's location from prompt (volatile) to file (persistent).## Prohibited ActionsFollow these without exception.- Do not auto-post to company Slack (draft only; user handles posting)- Do not make definitive financial judgments (always ask user for confirmation)- Do not treat replies to clients as final versions (always get user approval)- Do not make judgments about personnel evaluations or compensation- When including confidential information (salaries, contract amounts, etc.) in summaries, explicitly note thisInstead of telling someone verbally each time, place rules in a fixed location and reference them every time. It's that simple, but it changes the lifespan of rules from per-session to permanent.You want to leave a work log at the end of each session. Even if you write "create a work log and commit & push at the end" in the prompt, the agent just wraps up when the conversation gets lively.The solution is to define trigger conditions and mandatory actions as a set in the instruction file.## Mandatory Actions at Session EndWhen the user indicates work completion with phrases like "done," "thanks," or "commit,"execute the following. Skipping is prohibited.1. Create a work log at `docs/work-logs/YYYY-MM-DD-{topic}.md`   - Include: background, options considered, key decisions, deliverables, next steps2. Append a summary of changes to `CHANGELOG.md`3. Execute git commit & pushThe difference from the prohibited actions example is that trigger conditions for "when to fire" are also defined. By explicitly stating end signals like "done," "thanks," and "commit," the agent can more easily judge "this is the moment." It's not perfect, but the firing rate goes up significantly compared to writing "execute at the appropriate timing" with vague triggers.The key is the single line: "Skipping is prohibited." If you leave room for the agent to judge, it will decide on its own that "it's probably fine to skip this time" when conversations get long. Removing discretion stabilizes behavior.There's a secondary benefit too. When rules are defined in the instruction file, a simple "leave a log" or "commit" is enough for the agent to instantly understand "that action." No need to explain from scratch each time. The instruction file becomes shared vocabulary between human and agent.The third is an example of a "can't proceed without passing the check" structure.In conversations with agents, information worth accumulating comes up frequently — things decided in meetings, conclusions from tool selection, facts discovered during troubleshooting. Even if you write "save important information" in the prompt, it predictably forgets.The solution is to embed a "knowledge check" protocol in the instruction file.## Knowledge Accumulation (Mandatory Check)Before each response, internally execute the following check. Skipping is prohibited.Check: Does the user's immediately preceding statement, or your own response,contain new information matching any of the following?1. Factual information: team composition, tech stack, account info, environment configuration2. Decisions: architecture selection, tool adoption, policy changes3. Learnings: facts discovered during troubleshooting, gotchas, operational tips4. Client-specific: contact names, contact info, project progress→ If applicable: In addition to the normal response, append the following at the end.💾 Knowledge capture proposal:  File: knowledge/{project-name}/{filename}.md  Content: (summary of content to add)  Reason: (why this should be accumulated)→ If not applicable: Append nothing.The intended structure is "can't produce a response without passing the check." Of course, LLMs can skip instructions, so the enforcement isn't as strong as a mechanical gate. Still, by embedding the check into the system, the probability of capturing information rises significantly even when the human forgets to say "save that."Since implementing this system, knowledge files have been steadily accumulating in the knowledge directory.Let me address the strongest counterargument upfront. "Markdown prohibitions don't have the same enforcement power as a linter." That's correct.Linters and type checkers mechanically detect rule violations. Depending on configuration, they can even block builds and merges entirely. Markdown prohibitions, on the other hand, carry the risk of the agent reading past them. If buried in a long instruction file, effectiveness drops.However, the comparison here isn't against "mechanical enforcement" — it's against "writing it in the prompt each time." Why does writing in a file work better than a prompt? Two reasons.First, the "reference mechanism is different." As noted earlier, instructions placed in Project Knowledge or Custom Instructions are passed to the agent in a separate channel from regular messages. They're placed in a position that's harder to bury even as conversations grow longer, structurally increasing the probability of being referenced.Second, "accumulation becomes irreversible." Instructions written in a prompt don't exist in the next session. Write them in a file, and they persist unless deleted. The cycle of "write a good instruction → forget → write again" becomes "write a good instruction → append to file → automatically referenced from then on."Lining up enforcement strength from weakest to strongest:"Write in the prompt each time" → "Place in a persistent file and reference every time" → "Mechanically block with linters and hooks"Non-coding agents are currently at the middle position. Definitely stronger than the left end, doesn't reach the right end. But moving to the middle is still better for agent stability than staying at the left.So far I've written about individual rules, but the "where to put" the rules is itself a design decision.The repository structure that solidified through operation looks like this:ai-agents/├── agents/                  # Role-specific instruction files│   ├── assistant.md         # Main instructions (prohibitions, mandatory actions)│   ├── project-a/│   │   ├── sre-support.md   # SRE-specific instructions│   │   ├── qa-support.md    # QA-specific instructions│   │   └── ...│   └── project-b/│       ├── accounting.md    # Accounting-specific instructions│       └── ...├── knowledge/               # Accumulated knowledge│   ├── project-a/│   ├── project-b/│   └── writing-style-guide.md├── docs/work-logs/          # Per-session work logs└── CHANGELOG.mdThis structure shares two principles with coding agent harness design.The first is "separation of concerns." OpenAI's report documents the experience of a monolithic AGENTS.md not working well. When everything in the context is "important," nothing is important. In my own repository too, I initially crammed everything into a single Markdown file. Separating files by role and having the agent reference only what's needed improved instruction effectiveness.What enables this is context routing rules. Define routing in the main instruction file so the agent can reference the appropriate specialized instructions based on conversation content.## Context Routing RulesJudge which context the user's statement belongs to and reference the appropriate specialized instructions.- Project A context signals: AWS, infrastructure, SRE, QA, team member names → Reference files under `agents/project-a/`- Project B context signals: billing, contracts, accounting, legal → Reference files under `agents/project-b/`- Ambiguous: Ask which project this is aboutThis is the same structure as the AGENTS.md "design as a pointer" principle. The main file handles routing only, delegating details to specialized files. OpenAI's report describes keeping AGENTS.md to roughly 100 lines, functioning as a map. For non-coding agents, I've observed the same tendency — the longer the instruction file, the more effectiveness drops.The second is "version control." By placing instruction files in a Git repository, change history is preserved. "When was this prohibition added?" "Which rule change made things stable?" — all traceable via diff. Slack messages and ad-hoc prompts don't preserve this history. Additionally, since it's a Git repository, you're not tied to a specific PC. Keep it on a remote, and you can launch the same harness from any device.OpenAI's team makes the same point. Slack discussions, Google Docs content — if it's not in the repository, it's inaccessible to the agent and might as well not exist. This applies equally to non-coding agents.You don't need to structure everything from the start when beginning harness engineering for non-coding agents.In my case too, the early days were spent rewriting prompts. The order in which structure solidified was:When the agent makes the same mistake twice, write it in a file instead of a promptWhen the file gets bloated, split by roleWhen information is lost between sessions, build an accumulation systemIt's the same pattern Mitchell Hashimoto describes. "When the agent makes a mistake, build a system where that mistake can't happen again." For coding, you build it with linters and hooks. For non-coding, you build it with Markdown file structure. The material differs, but the thinking loop is the same.Here's a minimal starter template. Place it in Claude Desktop's Project Knowledge or ChatGPT's Custom Instructions and it works as-is.# Assistant Instructions## Your RoleAn AI assistant that supports user workflows.Use MCP tools like Slack, Google Calendar, and Confluence for information gathering and organization.## Prohibited Actions- Do not auto-post to company Slack (draft only)- Do not make definitive financial judgments (always ask user for confirmation)- When including confidential information in summaries, explicitly note this## Mandatory Actions at Session EndWhen the user indicates work completion, execute the following. Skipping is prohibited.1. Create a work log at `docs/work-logs/YYYY-MM-DD-{topic}.md`2. If there are changes, execute git commit & push## Knowledge Accumulation (Mandatory Check)Before each response, internally execute the following check. Skipping is prohibited.Check: Does the immediately preceding conversation contain new information matching any of the following?1. Factual information (team composition, tech stack, environment configuration)2. Decisions (architecture selection, tool adoption, policy changes)3. Learnings (facts discovered during troubleshooting, gotchas)→ If applicable: Append a knowledge capture proposal at the end→ If not applicable: Append nothingThis template is roughly 30 lines. Start here, and add one line to the prohibited actions every time the agent makes a mistake. In a few months, you'll have a harness built specifically for you.Harness engineering isn't a coding-specific technique. It's a design philosophy: giving agents a reliable execution environment.Coding agents build that environment with types, linters, and hooks. Non-coding agents build it with structured Markdown and forced referencing. The materials differ, but the question is the same: "When this agent makes a mistake, where is the system that prevents it from happening a second time?"Since shifting from "I just need to write better prompts" to "I need to build a structure where the same mistake can't happen," my agents have been running more stably.

Harness Engineering with Nothing but Markdown

コーディングエージェントが主戦場でなければ、「ハーネスエンジニアリング」は少し遠い言葉でしょう。Claude CodeやCodexを前提にした解説記事が並ぶタイムラインを見て、「これは自分の話ではない」と感じた人もいるはずです。私自身のエージェント活用もコーディングが中心ではなかったので、出回っている記事のどれも自分のケースには当てはまらないと思っていました。しかし振り返ると、名前がついていなかっただけで同じことをしていました。Slack・Confluence・Google Calendarなど複数の業務ツールを横断して情報を収集し、文脈ごとに判断基準を切り替えながらアウトプットを出...

Markdownだけで作るハーネスエンジニアリング

On March 31, 2026, AWS made DevOps Agent and Security Agent generally available — the first two of the autonomous AI agents announced at re:Invent 2025 under the "Frontier Agents" brand. A 2-month free trial is included, after which pay-as-you-go pricing kicks in.https://aws.amazon.com/blogs/mt/announcing-general-availability-of-aws-devops-agent/https://aws.amazon.com/blogs/machine-learning/aws-launches-frontier-agents-for-security-testing-and-cloud-operations/The official announcements highlight numbers like "up to 75% MTTR reduction" and "penetration testing compressed from weeks to hours." The question that matters more is: how does this change the day-to-day work of an SRE team? Feature overviews are already plentiful, so this article focuses on what shifts to agents and what stays with humans.AWS announced three Frontier Agents at re:Invent 2025: Kiro Autonomous Agent (software development), DevOps Agent (operations), and Security Agent (security). Of these, DevOps Agent and Security Agent are now GA. Kiro Autonomous Agent remains in preview.AWS defines Frontier Agents as systems that "work independently to achieve goals, scale massively to tackle concurrent tasks, and run persistently for hours or days." Frankly, that description could apply to existing AI agents like Claude Code or Devin. What AWS emphasizes is delivering "complete outcomes" rather than assisting with individual tasks, but this feels like a difference of degree, not kind.In practice, it's probably best to think of them as domain-specialized autonomous agents — deeply integrated with DevOps and security workflows. "Frontier" is more of a marketing brand than a technical category: "AWS's first-party, domain-specific agent products" is a fair characterization.What matters isn't the naming — it's how these agents affect SRE work.AWS describes DevOps Agent as an "always-available operations teammate." However, since it requires human approval for fixes and can't make business decisions, the reality is closer to an "always-on SRE apprentice" — it investigates and proposes, but can't decide or execute. Here's where that boundary lies.Imagine an alert fires at 2 AM. Traditionally, the on-call engineer wakes up from a Datadog alert, opens their laptop, checks dashboards for metric anomalies, digs through logs, cross-references deployment history, and identifies the root cause. DevOps Agent automates this entire initial investigation.Specifically, it correlates metrics and logs from monitoring tools (CloudWatch, Datadog, Dynatrace, New Relic, Splunk, Grafana), code repositories (GitHub, GitLab, Azure DevOps), and CI/CD deployment histories to build hypotheses like "this code change introduced in this deployment correlates with this metric anomaly." Investigation progress is shared via the web console and Slack, where you can ask follow-up questions or redirect the investigation.The GA release adds Azure and on-premises environments as investigation targets. On-premises tools connect via MCP (Model Context Protocol), enabling consistent investigation across multicloud and hybrid setups.Beyond incident response, DevOps Agent also provides proactive improvement recommendations — analyzing historical incident patterns to identify gaps in alert coverage, test coverage, code quality, and infrastructure configuration.It's worth noting that Datadog's Bits AI SRE offers quite similar capabilities: autonomous alert investigation, source code analysis, and deployment correlation. The key difference is that DevOps Agent can simultaneously span multiple observability tools (Datadog + CloudWatch + Splunk, etc.) and include Azure and on-premises environments via MCP. If your organization is entirely within the Datadog ecosystem, Bits AI SRE may be sufficient. If you have multiple tools or a multicloud setup, DevOps Agent's cross-platform analysis adds value. More on this in the "How Does the Relationship with Existing Tools Change?" section.The GA release also introduced "Learned Skills" and "Custom Skills." Learned Skills let the agent learn from your organization's investigation patterns and tool usage, improving accuracy over time. Custom Skills let you add organization-specific investigation procedures and best practices, configurable per incident type (triage, root cause analysis, mitigation). Code Indexing also enables code-level fix suggestions based on repository understanding.This is the critical part. DevOps Agent investigates and proposes — executing fixes is up to humans.It can generate fix proposals and work with Kiro or Claude Code to produce fix code, but applying changes to production requires human approval. This is intentional — AWS has made the design decision that "an agent that modifies production without approval won't be trusted."The other thing the agent doesn't do is business judgment. "This incident has major customer impact, so we need a company-wide response." "It's Friday night — let's apply a workaround and do the root cause fix Monday." These decisions require human context. Identifying the technical root cause and deciding how to respond are separate jobs. DevOps Agent handles the former; humans own the latter.Security Agent is the security counterpart — an "always-on penetration tester and security reviewer." It has three main capabilities: on-demand penetration testing, design document security review (Design Review), and PR security review (Code Review).Traditionally, penetration testing meant "once or twice a year, for the most critical applications only, outsourced to specialists, taking weeks." Cost and time constraints leave most of the application portfolio untested. As the Security Agent FAQ notes, "most organizations limit manual penetration testing to their most critical applications and conduct these tests periodically." And even tested applications become partially unverified the moment new code is deployed.Security Agent changes this structure. You create an "Agent Space," connect your GitHub repository, and the agent reads source code, architecture documents, and design docs to understand the application's structure before running automated penetration tests against endpoints.The key difference from simply running a scanner: Security Agent validates discovered vulnerabilities by actually sending payloads to confirm exploitability. Reports include reproduction steps, dramatically reducing false positives. Per the official features page, testing covers OWASP Top 10 vulnerability types plus business logic flaws. According to the GA announcement blog, LG CNS reported significant false positive reduction, over 50% faster testing, and roughly 30% cost reduction.This capability reviews architecture documents and design docs from a security perspective before any code is written. It checks against AWS best practices and your organization's custom security requirements. Catching issues at the design stage avoids costly rework after implementation.Pull Request-level security review is the third capability. As of GA, it supports GitHub PRs — Security Agent automatically reviews PRs for security issues when they're created. You can configure it to check custom security requirement compliance, common security vulnerabilities, or both.PR security checks aren't new — many organizations already have Claude Code or Codex review PRs with security instructions via CLAUDE.md, or have SAST tools in their CI/CD pipeline. Security Agent's difference is operational: security requirements are defined once in the console and automatically applied across all repositories. This removes the overhead of maintaining per-repository md files, but it doesn't enable something technically impossible before. Of the three capabilities, penetration test automation is where the real differentiation lies.Design reviews are free up to 200/month, and code reviews up to 1,000/month. Only penetration testing is paid ($50/task-hour) — more on this in the "Cost Structure" section.Security Agent automates "discovery and validation" — "judgment and response" remain human territory.Security policy decisions are human work. "Which risks to accept and which to address," "how to interpret compliance requirements" — these are outside the agent's scope. For example, "fixing this vulnerability requires a breaking API change, but we need to consider the impact on a major customer's release schedule" is a business trade-off that requires human judgment.Social engineering (tricking employees into granting access) and vulnerabilities that can only be discovered by understanding the entire business workflow are also difficult to cover with automated testing alone. While the official documentation says business logic flaws are included in the test scope, the agent doesn't fully replace a human penetration tester's judgment of "what this operation means in the context of this business flow." Security Agent's strength is "broad, frequent, systematic testing" — complementing, not replacing, "deep, creative testing" by human experts."Will Datadog or PagerDuty become unnecessary?" Short answer: no. The relationship changes, not the need.Here's how the human steps change, using a late-night alert as an example:Previously humans handled all 5 steps; after adoption, human steps drop to 2. Red = previously all-human work, green = shifts to the agent, blue = remains human.DevOps Agent doesn't "replace" these tools — it uses them as "data sources." GA supports integrations with CloudWatch, Datadog, Dynatrace, New Relic, Splunk, and Grafana. This isn't about canceling Datadog and switching to DevOps Agent — it's about DevOps Agent analyzing the metrics and logs that Datadog collects.You might wonder: "Could we drop Datadog, consolidate on CloudWatch, and use DevOps Agent / Security Agent to save costs?" DevOps Agent handles incident investigation and improvement recommendations — it doesn't include day-to-day monitoring features like APM, RUM, distributed tracing, or dashboards. Datadog's value extends beyond incident response, so a simple swap doesn't work. That said, there is overlap between Datadog's Bits AI SRE and DevOps Agent's incident investigation capabilities, so whether you need to pay for both is worth evaluating.In fact, the quality of your monitoring setup directly affects DevOps Agent's effectiveness. The agent can only analyze what your tools collect. Sparse metrics and logs mean less accurate analysis. The direction isn't "adopt the agent so we can invest less in monitoring" — it's "invest in monitoring to maximize the agent's effectiveness."Alert routing and on-call management roles remain unchanged. DevOps Agent starts investigating the moment an alert fires, completing initial investigation before the notified human even logs in. On-call scheduling, escalation, and incident lifecycle management continue to be handled by tools like PagerDuty or Datadog On-Call. The GA release added PagerDuty integration as well.What changes is "the first thing the on-call engineer does." Instead of "open the dashboard and check metrics," it becomes "read the Agent's investigation results shared in Slack." Per the official GA blog, Zenchef (a restaurant technology platform) submitted an issue to DevOps Agent during a hackathon and had the root cause identified in 20–30 minutes — an investigation that would normally take 1–2 hours, completed while the engineers stayed focused on the hackathon.Security Agent automatically posts security review comments on GitHub PRs. Developers can review and address findings without leaving the PR interface. Merge decisions remain human. Details and differentiation points are covered in the "What Security Agent Does and Doesn't Do" section above.Frontier Agents have a distinctive pricing model, especially DevOps Agent's tie-in with AWS Support plans.DevOps Agent costs $0.0083/agent-second (roughly $30/hr). The official pricing page shows usage examples: a small team (10 incident investigations/month, 8 minutes each) at ~$40/month, and an enterprise (500 incidents, 10 Agent Spaces) at ~$2,300/month.On top of this, per the pricing page, AWS Support customers receive monthly credits based on the prior month's Support spend:Support PlanCredit RateUnified Operations100% of prior month's Support spendEnterprise Support75% of prior month's Support spendBusiness Support+30% of prior month's Support spendFor example, an organization paying $15,000/month for Enterprise Support would receive $11,250/month in DevOps Agent credits. If usage stays within that, the incremental cost is zero.Behind this credit structure is the relationship with TAM (Technical Account Manager) in Enterprise Support. Traditionally, Enterprise Support customers get a TAM who provides architecture reviews and operational guidance. The Enterprise Support page now presents TAM and DevOps Agent side by side — TAM handles strategic guidance, DevOps Agent handles 24/7 automated investigation and improvement proposals. DevOps Agent is positioned as an "extension" of Support, not a replacement, which explains why credits come from Support spend.Security Agent penetration testing is billed at $50/task-hour (design and code reviews have free tiers as mentioned above). Per the official FAQ, a 2-month free trial is included post-GA.Traditional third-party penetration testing typically costs hundreds of thousands of yen (tens of thousands of dollars) per engagement, taking weeks. This "high unit cost × low frequency" structure transforms into "$50/task-hour × high frequency."The implication: it becomes economically viable to expand penetration testing coverage. Organizations that could only test their most critical applications due to cost constraints can now continuously test across their entire portfolio.Frontier Agents adoption has implications for how SRE teams operate.DevOps Agent's biggest impact is automating initial investigation for late-night alerts. Per the official GA blog, WGU (Western Governors University) deployed it to production during preview, reducing estimated 2-hour investigations to 28 minutes.Traditional on-call pain comes from being woken up and having to start investigating from scratch in a less-than-ideal state. Opening dashboards, hunting for metric anomalies, pulling related logs, cross-referencing deployment history — this alone can take 30 minutes to an hour.After DevOps Agent adoption, this "starting from zero" disappears. The on-call engineer's first action becomes "read the Agent's findings." The agent presents "this code change in this deployment correlates with this metric anomaly — here's the proposed fix" as the starting point.However, a new kind of pressure may emerge: "Is the root cause the Agent identified actually correct? Are there blind spots?" The tension between trusting the agent's output and risking an incorrect fix, versus distrusting it and re-investigating from scratch. Worth discussing as a team before it happens.The shift goes from "investigate from scratch when alerted" to "review the Agent's findings and judge whether anything was missed." It's similar to when CI/CD became standard — the emphasis moved from "memorize manual deployment procedures" to "design pipelines and make judgment calls when they fail." As automation advances, the ability to audit automated output and handle exceptions that automation can't becomes more important than hands-on execution skills.For less experienced team members, learning design becomes necessary. Previously, "investigating incidents yourself" was the primary way to build incident response skills. With agents handling initial investigation, these "learn by doing" opportunities shrink.Possible approaches include "form your own hypothesis before looking at the Agent's findings," "review Agent output with intentionally injected errors," or "regular incident response drills without the Agent." The same thinking as understanding manual deployment procedures even when you rely on CI/CD.For SRE team managers, this question is unavoidable. Can Frontier Agents adoption mean fewer people?In the short term, "same headcount, broader coverage" is more realistic. Agent-handled initial investigations free up SRE team time. Whether that freed time goes to "headcount reduction" or "proactive improvements that were previously backlogged (SLO reviews, chaos engineering, architecture improvements)" is the real question. The latter likely delivers more organizational value.SRE teams perpetually stuck in reactive incident response mode (the "firefighter" state) is a common challenge. Frontier Agents adoption is a catalyst for accelerating the shift from "firefighter" to "fire prevention engineer."AWS's published figures — "up to 75% MTTR reduction," "up to 80% faster investigations," "94% root cause accuracy" — are all preview-period customer-reported values, explicitly qualified with "up to." Whether your environment sees similar results depends on application complexity, monitoring maturity, and incident characteristics. Treat them as reference points and validate in your own environment.WGU's "estimated 2 hours → 28 minutes" and LG CNS's "over 50% faster testing" are also results from specific situations. This article cites these numbers as material for understanding implications, not as guarantees that generalize.Both DevOps Agent and Security Agent are available in the same six regions at GA: US East (N. Virginia), US West (Oregon), Europe (Frankfurt / Ireland), and Asia Pacific (Sydney / Tokyo). Tokyo region availability is a plus for teams in Japan.However, per New Claw Times analysis, DevOps Agent inference processing occurs in US regions regardless of the selected region. Organizations with strict GDPR or data residency requirements should verify this.Both agents include a 2-month free trial, but DevOps Agent has monthly caps. Per official pricing, the trial period allows up to 10 Agent Spaces, 20 hours of incident investigation, 15 hours of prevention evaluations, and 20 hours of on-demand SRE tasks per month. Excess usage incurs standard charges. Sufficient for pre-production evaluation, but watch the limits for large-scale PoCs.DevOps Agent supports AWS, Azure, and on-premises. On-premises connection uses MCP, requiring access configuration for target tools. "It doesn't just see other environments without setup." Note that DevOps Agent does not explicitly support Google Cloud environments at GA.Security Agent's penetration testing supports per the official GA announcement "AWS, Azure, GCP, other cloud-providers, and on-premises" — it can test any reachable endpoint regardless of cloud provider.As mentioned earlier, Security Agent's PR review (Code Review) only supports GitHub at GA. Organizations primarily using GitLab or Bitbucket need to factor in this constraint.Frontier Agents don't "eliminate" SRE work — they "partition" it.Work that shifts to agents centers on pattern recognition and correlation analysis: detecting anomalies across metrics and logs, matching against historical incidents to form hypotheses, systematically scanning code for vulnerabilities. This "intellectual labor that demands volume and speed" is where agents excel.Work that stays human centers on judgment and decision-making: whether to apply a fix, how to assess business impact, how much risk to accept, how to evolve the architecture. These are context-dependent, requiring organizational knowledge and business priority judgment — outside the agent's scope.For SRE team management, this is an opportunity to redesign team skill composition and on-call structure around this new division of labor. Not "agents mean we need fewer people," but "agents handle more of the routine, so humans can focus on work that demands greater judgment."

What Changes and What Stays the Same for SRE with AWS Frontier Agents

2026年3月31日、AWSがDevOps AgentとSecurity Agentを一般提供（GA）しました。re:Invent 2025で「Frontier Agents」として発表された自律型AIエージェントのうち、最初の2つです。GA後は2ヶ月の無料トライアルが提供されており、その後は従量課金に移行します。https://aws.amazon.com/blogs/mt/announcing-general-availability-of-aws-devops-agent/https://aws.amazon.com/blogs/machine-learning/aws-lau...

AWS Frontier Agentsで変わるSREの仕事、変わらないSREの仕事

On April 7, 2026, AWS made Amazon S3 Files generally available. It lets you mount S3 buckets as NFS v4.1/v4.2 file systems from EC2, EKS, ECS, and Lambda.There are already plenty of setup guides and first-look posts. This article focuses on something different: what becomes unnecessary and what becomes possible in your architecture.If you use S3 regularly and are wondering "this sounds big, but how does it actually affect my architecture?" — this is for you.Let's start with a shared understanding.Say an ML team needs to preprocess training data. The raw data is in S3. They want to use pandas. While pd.read_csv("s3://my-bucket/data.csv") works, under the hood boto3 issues GET requests and loads data into memory. Writing results back requires PUT. This is fundamentally different from open("./data.csv").At scale, this becomes an architectural problem. Many organizations operate pipelines like this:Copy from S3 to EFS/EBS, process, write results back to S3. This "middle copy layer" exists solely to bridge the I/O model gap between object storage and file systems. Maintaining sync scripts, managing consistency during copies, and provisioning EFS — all of this overhead comes from that gap.S3 Files aims to eliminate this gap entirely.From the application's perspective, S3 data appears as a local directory. pd.read_csv("/mnt/s3files/data.csv") reads from S3 behind the scenes, and df.to_csv("/mnt/s3files/result.csv") automatically commits changes back.The full technical overview is in the official documentation.docs.aws.amazon.com                        If "mount S3" sounds familiar, you might be thinking of Mountpoint for Amazon S3 or Google Cloud's Cloud Storage FUSE (gcsfuse). S3 Files has a fundamentally different architecture.FUSE-based tools emulate file system behavior on top of S3's API. In Mountpoint for Amazon S3, for example, overwriting a file means deleting the old object and PUTting a new one. Partial file writes — a basic file system operation — aren't supported. Directories don't actually exist, leading to inconsistencies with empty directories.S3 Files doesn't emulate. It connects EFS (Elastic File System), a real NFS file system, to S3. The file system side provides real NFS semantics, and the S3 side remains real S3 objects. Two distinct systems coexist with an explicit synchronization layer between them.This matters in practice: appending to a WAL (Write-Ahead Log) or editing part of a config file works with byte-level writes on the file system side, periodically synced to S3 as whole objects. With FUSE, these operations require re-PUTting the entire object.Andy Warfield, VP and Distinguished Engineer at AWS, describes the sync model as "stage and commit" in his post on All Things Distributed, explicitly noting it's "a term borrowed from version control systems like git" (official documentation uses "synchronization" instead).File system changes are like working directory changes in Git. They aren't immediately reflected in S3 — instead, they're batched and committed as S3 PUTs approximately every 60 seconds. In the other direction, when objects are updated in S3 (e.g., via PutObject from another application), the official documentation states changes are reflected in the file system "typically within seconds." DevelopersIO's hands-on testing measured approximately 30 seconds.If both sides modify the same file simultaneously, S3 is the source of truth. The file system version is moved to a lost+found directory, with a CloudWatch metric indicating the conflict.This is a deliberate tradeoff: not a real-time shared file system, but one that tolerates tens of seconds of delay in exchange for preserving both file and object semantics without compromise.According to Warfield's post, the team initially tried to make the boundary between files and objects invisible, but every approach forced unacceptable compromises on one side or the other. They ultimately decided to make the boundary itself an explicit, well-designed feature. His post is essential reading for understanding the "why" behind S3 Files.Here's the core of this article: what specific architectural patterns does S3 Files make unnecessary?Consider a daily retraining pipeline for a recommendation model. Purchase logs accumulate in S3, and preprocessing involves data cleansing → feature generation → format conversion.Previously, every time an EC2 or SageMaker Processing Job starts, it first downloads data from S3 to EBS. For 100GB of training data, depending on instance network bandwidth, the download alone takes several minutes. After processing, results are uploaded back to S3, and the EBS volume is cleaned up. Of the four steps — download → process → upload → cleanup — only "process" is the actual work.With S3 Files, you mount the S3 prefix (e.g., s3://ml-data/purchase-logs/) and your processing script reads and writes /mnt/s3files/purchase-logs/ directly. Download, upload, and cleanup steps disappear.Note: if a downstream job needs to read results via the S3 API immediately, the ~60-second commit delay matters. If both jobs use the same mount point, this isn't an issue. For S3 API consumers, design around S3 event notifications or explicit waits.Consider a Lambda function that generates thumbnails when images are uploaded to S3. The traditional implementation:# Traditional: Download → Process → Uploadimport boto3from PIL import Images3 = boto3.client('s3')def handler(event, context):    bucket = event['Records'][0]['s3']['bucket']['name']    key = event['Records'][0]['s3']['object']['key']    download_path = f'/tmp/{key.split("/")[-1]}'    s3.download_file(bucket, key, download_path)    img = Image.open(download_path)    img.thumbnail((128, 128))    thumb_path = f'/tmp/thumb_{key.split("/")[-1]}'    img.save(thumb_path)    s3.upload_file(thumb_path, bucket, f'thumbnails/{key}')With S3 Files mounted:# S3 Files: Operate directly on mounted pathsfrom PIL import Imagedef handler(event, context):    key = event['Records'][0]['s3']['object']['key']    img = Image.open(f'/mnt/s3files/{key}')    img.thumbnail((128, 128))    img.save(f'/mnt/s3files/thumbnails/{key}')You don't even need to import boto3. The same code you'd write for local development works as-is.Beyond code simplicity, Lambda functions are freed from /tmp capacity constraints (default 512MB, max 10GB). For functions referencing multi-GB ML models, cold start download time directly impacted latency. S3 Files pre-fetches files below a configurable threshold (default 128KB) alongside metadata, and fetches larger files on demand. Warfield calls this "lazy hydration" in his post — you can start working immediately even with millions of objects in the bucket.docs.aws.amazon.com                        If your organization uses S3 as a data lake but needs EFS for real-time processing or interactive analysis, you likely have DataSync, Step Functions, or cron scripts bridging the two. Maintaining this sync logic — detecting new objects, identifying diffs, retry on failure, consistency during sync, cleanup of stale EFS files — is a significant operational burden.S3 Files replaces this with managed synchronization. Per the official documentation, import from S3 runs at up to 2,400 objects/second, and export to S3 uses ~60-second batch windows. Unused file data is automatically evicted from the file system cache (configurable from 1 to 365 days, default 30) but never deleted from S3. File system storage costs scale with your active working set, not your total dataset.docs.aws.amazon.com                        Log aggregation tools watching /var/log/, build systems reading from /src/, config management tools writing to /etc/ — these applications assume open() / read() / write() and rewriting them for the S3 SDK is often impractical.Previously, "put files on EFS, back up to S3 as needed" was the pragmatic solution. S3 Files lets you keep S3 as primary storage while applications access it via NFS mount. POSIX permissions and file locking (flock) are supported, making migration possible with a mount point change and zero code changes.What becomes practically feasible for the first time?S3 Files uses a two-tier architecture internally. The first tier, "high-performance storage," caches small, frequently accessed files with sub-millisecond to single-digit millisecond latency per the official documentation. The second tier is S3 itself — reads of 1MB or larger are streamed directly from S3 even if data is cached locally, because S3 is optimized for throughput. Notably, these large reads incur only S3 GET request costs with no file system access charge.Official performance specifications:MetricValueMax read throughput per client3 GiB/sAggregate read throughput per file systemTerabytes/sMax read IOPS per file system250,000Aggregate write throughput per file system1–5 GiB/s (varies by region)Max write IOPS per file system50,000docs.aws.amazon.com                        For context: EBS gp3 provides 125 MiB/s baseline throughput, scalable to 2,000 MiB/s (~2 GB/s) with additional provisioning. io2 Block Express maxes out at 4 GB/s. S3 Files delivers comparable read throughput without any volume provisioning.From spec values alone: reading a 100GB dataset sequentially takes ~13 minutes at gp3 default (125 MiB/s) versus ~33 seconds at S3 Files maximum (3 GiB/s). Actual throughput depends on workload and instance type, but the order-of-magnitude difference matters. And since 1MB+ reads are billed at S3 GET rates only, heavy sequential reads essentially incur no file system charges.Previously, Lambda functions using large reference data had three options: container images with embedded models (max 10GB, rebuild on every model update), EFS mounts (requires VPC, tends to increase cold starts), or S3 downloads to /tmp (max 10GB, download time added to cold starts). S3 Files is a fourth option: mount the S3 prefix, read model files via the file system. Model updates require only an S3 upload — no Lambda redeployment needed.Unlike EFS mounts, the backend is your standard S3 bucket, so S3-native features like versioning, lifecycle policies, and cross-region replication work as-is.Coding agents like Claude Code, Codex, Kiro, and Cursor use file system operations as their primary data access method: ls to list files, cat to read, editor to modify and save. It's the Unix toolchain.Of course, agents can access S3 through other means — running aws cli commands, calling S3 APIs via MCP servers or Skills/Powers, generating boto3 code. But all of these are indirect compared to file operations and add reasoning steps. To search S3 logs, a file system lets you write grep -r "ERROR" /mnt/s3files/logs/ in one line, while the S3 API requires listing objects, downloading individually, and searching locally.With S3 Files mounting the bucket, this indirection disappears. To the agent, S3 data is just another directory under /mnt/s3files/.Warfield's post describes AWS engineering teams using Kiro and Claude Code hitting the problem of agent context windows compacting and losing session state. With S3 Files, agents write investigation notes and task summaries to shared directories, and other agents read them. When sessions end, state persists on the file system for the next session.File locking (flock) supports mutual exclusion across agents and processes. However, S3 API access bypasses file locks — if you write from both the file system and S3 API simultaneously, locking won't protect you.S3 Files isn't universal. Key constraints to evaluate:Writes take ~60 seconds to appear as S3 objects. If job B reads via S3 API immediately after job A writes via the file system, job B may see stale data.This isn't just a limitation — it's a cost optimization. Per the official documentation, consecutive writes to the same file are aggregated within the 60-second window and committed as a single S3 PUT, reducing S3 request costs and versioning storage overhead.Sync throughput per the official performance specification: S3 → file system at up to 2,400 objects/s and 700 MB/s; file system → S3 at up to 800 files/s and 2,700 MB/s.No "commit now" API exists at GA. Warfield mentions this as an area for future improvement. Workarounds: pass data between jobs via the file system (same mount point), or trigger downstream jobs via S3 event notifications.S3 has no native rename. File system renames are implemented as copy + delete internally. Per the official performance specification, renaming a directory of 100,000 files completes instantly on the file system, but takes several minutes to reflect in the S3 bucket. During that window, the file system shows the new path while S3 still has the old keys. S3-side request costs (100K CopyObject + 100K DeleteObject) are also non-trivial.Warfield's post warns about mounting buckets with more than 50 million objects (this figure doesn't currently appear on the official quotas page). Consider mounting a specific prefix to narrow the scope.Mount targets live inside a VPC. Lambda functions and EC2 instances must connect from subnets in the same AZ as the mount target. Per the official documentation, supported compute services are EC2, Lambda, EKS, and ECS. On-premises or cross-cloud resources are not in the supported list.Some S3 object keys can't be represented as POSIX filenames: keys ending with /, keys containing POSIX-invalid characters, or path components exceeding 255 bytes. See the official quotas page for the full list.This is intentional. Per Warfield's post, the team chose to pass through the vast majority of keys that work in both worlds and emit events for incompatible ones rather than silently converting them.S3 Files requires S3 bucket versioning. For existing buckets, evaluate the storage cost impact (old versions are retained) and compatibility with existing lifecycle rules.First, inventory your pipelines for "copy from S3, process, write back to S3" patterns. Batch processing and ML preprocessing pipelines with EBS/EFS staging layers are prime candidates for replacement.Second, consider how storage choices change for new projects. "Put it in S3 now, access it as a file system later" is now a viable strategy, reducing the urgency of early "object vs. file system" decisions.Third, audit Lambda functions that explicitly download to / upload from /tmp. Functions handling large reference data or sharing data across invocations are worth evaluating.S3 started 20 years ago as an object store. With Tables, Vectors, and now Files, it has expanded how data can be accessed. S3 Files removes one more architectural constraint imposed by storage choices. It won't apply to every workload, but for organizations where "the data is in S3 but the tools need a file system" — and that's a lot of organizations — the impact is significant.

Architecture Layers That S3 Files Eliminates — and Creates

2026年4月7日、AWSがAmazon S3 Filesを一般提供（GA）しました。S3バケットをNFS v4.1/v4.2のファイルシステムとしてマウントできる機能です。EC2、EKS、ECS、Lambdaのいずれからでも利用できます。https://aws.amazon.com/blogs/aws/launching-s3-files-making-s3-buckets-accessible-as-file-systems/発表直後から多くのセットアップ記事や速報が出ていますので、この記事では「何が設定できるか」ではなく「何が不要になり、何が可能になるか」を整理します。対象読...

S3 Filesで消えるアーキテクチャ層、生まれるアーキテクチャ

AI-Powered Test Case Review with MagicPod MCP Server and Claude

テスト自動化は進んだ。レビューもセットで回っている？MagicPodのようなノーコードツールでE2Eテストを自動化するチームは増えています。テストケースの作成ハードルは確実に下がりました。では、作られたテストケースの品質は、誰がどう担保しているでしょうか。プロダクト開発におけるソースコードであればGitHubのPull Requestという、コード管理とレビューが一体化した場があります。一方、ノーコードのテスト自動化ツールには同等の場が整っていないことが多く、レビュー体制の構築はチームの意思と工夫に委ねられています。テストケースの作成者がそのまま最も詳しい人であり続ける。その状態...

MagicPod MCPサーバー × Claudeで始めるテストケースAIレビュー

CLAUDE.md, .cursor/rules, Kiro Specs, Devin Playbooks. The past year has seen an explosion of instruction files for AI. While every new tool comes with a new name, doesn't what they are doing feel like deja vu?Isnt this a requirements definition document? Isnt this onboarding material? Isnt this a runbook?Anyone involved in software development for a long time likely feels the same way. At the same time, you might feel that some practices previously considered common sense are starting to become a hindrance in modern development.This article explores the true nature of this deja vu and sense of misalignment.To state the conclusion first: the design philosophy of AI coding tools is a reinvention of practices built over 20 years of human team development. In this process, part of software development common sense is structurally flipping. There appears to be a simple law to categorize what flips and what remains universal.First, let's organize the facts.If we map the ways to provide instructions in various AI tools to what humans have done in team development for years, it looks like this:AI Tool ConceptHuman Team Development EquivalentKiro SpecsPRD / Requirements DefinitionCLAUDE.mdOnboarding Documentation.cursor/rulesCoding Conventions (.eslintrc, etc.)Devin PlaybooksOperating Procedures / RunbooksHooks (PreToolUse, etc.)Git hooks / CI PipelinesSkillsInternal Common LibrariesPluginsTemplates distributed via npm/pipMany of you have likely noticed this correspondence.The important part is what comes next. In human team development, there was a long period of trial and error regarding the design of what to provide. Giving only coding conventions doesn't help a new member get moving. Giving only a PRD doesn't convey design intent. Giving only a procedure manual doesn't allow for exceptional judgments. The knowledge that a person becomes effective only when provided with layers of why this design was chosen, what must not be touched, and criteria for judgment when stuck has been accumulated over many years.The instruction design for AI tools is exactly a reinvention of this knowledge.Furthermore, the differences in design philosophy among tools can be translated into differences in what kind of organization provides what to a new member first.Kiro is like a company that starts with specifications. Let's structure the requirements and clarify acceptance criteria before starting implementation. The design of having three stages—requirements.md, design.md, and tasks.md—aims for a middle ground between pre-definition and iteration. (Note: Kiro provides Requirements-First and Design-First workflows; here, we focus mainly on the Requirements-First flow).Claude Code is like a company that emphasizes verbalizing implicit knowledge. The guideline to write persistent context that cannot be inferred from code is spreading as a best practice for CLAUDE.md, which is the essence of onboarding materials. It is the idea of organizing technical stacks, reasons for past design decisions, and hidden pitfalls that cannot be read from the code itself.Cursor is like a company that gives rules and lets people work freely. You write project rules flatly in .cursor/rules and leave the rest to the agent's judgment. Because the degree of freedom is high, the quality of the rules directly affects the output quality. Conversely, since the ability to write rules serves as leverage for the team's output quality, the operational design of rules (who updates them and when) becomes implicitly important.Devin is like a company that makes people follow procedures. It is a design where humans control the task execution flow by explicitly defining steps in Playbooks.None of these is the single correct answer; rather, they represent design differences based on the nature of the team and the task.Now for the main topic.Looking at the failure patterns occurring in AI tool instruction design, we notice they are structurally identical to the failures repeated in human team development over the last 20 years.Using Claude Code without writing CLAUDE.md and repeatedly re-instructing it because it's not right is almost the same structure as the silos created when starting a project without design documents.In human teams, if the basis for design decisions is not documented, a state of it's unknown unless you ask that person is born. For AI, it is even simpler: context disappears once you cross sessions. As a result, you repeat the same explanation, yet get a different output than before. This is the very challenge stated over a decade ago: without documentation, implicit knowledge evaporates.The efforts of Kiro to structure requirements.md in EARS format and Claude Code to persist prerequisite knowledge via CLAUDE.md are architectural answers to this evaporation.Adding ten MCP servers only to have the response quality collapse is another common pattern.Defining too many tools crowds the context window, and the agent begins to skim the results. As pointed out in Anthropic's article on Code execution with MCP, direct calls to MCP tools can cause token consumption to explode. One example mentioned is a case where transferring a transcript of a two-hour sales meeting from Google Drive to Salesforce could consume an additional 50,000 tokens.https://www.anthropic.com/engineering/code-execution-with-mcpThis is the same structure as inviting a new hire to 30 Slack channels on their first day and causing them to freeze from information overload. Both humans and AI have limits to the amount of information they can process, necessitating a design that provides necessary information at the appropriate granularity. The evolution of Claude Code Skills, Cursor Rules, and Kiro Powers as mechanisms to provide only necessary information when needed is a response to this problem.Kiro Specs' design philosophy of writing specifications first is an answer to the classic failure pattern of starting development without specs and seeing the project go up in flames in the latter half.Since AI generates code probabilistically, it will fill in the blanks of ambiguous specifications on its own. You won't know if that matches your intent until you verify the output. If you run with ambiguous specs, a game of whack-a-mole style bug fixing begins. This is the same for both human and AI development.Forcing automatic formatting or linting via Hooks upon saving files is a reenactment of the history where we moved from relying on human goodwill for reviews and style consistency to automating it with CI.Ten to fifteen years ago, themes like Jenkins implementation, test automation, and continuous integration were frequent at web conferences. Discussions on securing quality through systems became popular, leading to build servers, the cultivation of automated testing cultures, and the establishment of deployment pipelines. The rapid development of Hooks and Skills in the context of AI coding today is exactly a reenactment of this history.While the summary so far is that history repeats itself, another point is that some common sense is flipping.To explain this flip, I propose a law:When generation cost decreases, the center of gravity for value shifts from the product to the intent.The cost of writing code has dropped dramatically. Instruct an AI, and hundreds of lines of code appear in seconds. Let's consider the structural consequences of this change.It is the same structure as the movement of bottlenecks in the Theory of Constraints (TOC). When the cost of one process drops sharply, the bottleneck moves to another process. Ten years ago, implementation man-hours were often the bottleneck, so it was rational to invest in technologies that improved code quality, such as test automation, refactoring, and coding conventions.Now, writing code itself has become cheap. Consequently, the bottleneck moves to what to make it write. The process of verbalizing specifications, recording design decisions, and organizing context—in other words, the process of refining intent—is becoming the bottleneck for productivity.Note that this law relies on the current asymmetry where generation costs have dropped, but verification costs have not decreased at the same rate. If AI-driven code review or formal verification advances significantly in the future, verification costs may also drop dramatically, moving the bottleneck to yet another process. In that sense, this is not a permanent law of the universe but a law explaining current structural dynamics.Using this law, let's categorize development common sense into what flips and what remains universal.These are things considered a given for any good developer over the past 20 years, but for which the ROI is changing in the AI era.Note that these haven't become meaningless; rather, they have changed from things you should always invest in to things you judge based on the situation.DRY (Don't Repeat Yourself) is a design principle to eliminate code duplication and centralize changes. This was a rational investment when humans were maintaining the code. Duplication leads to missed updates and becomes a hotbed for bugs.However, in the context of AI generating code, abstraction for the sake of DRY can sometimes become a risk.Introducing abstraction layers for unification increases the chance of the AI misreading the context. If the responsibility of a common function is unclear, the AI might use that function for unintended purposes or call it in inappropriate places. Concrete, self-contained code is often less likely to be misunderstood by AI.Of course, DRY remains important in core parts of the codebase that humans will maintain long-term. The criteria for judgment have changed: we must now discern whether this code is a core component for long-term maintenance or a peripheral one intended for regeneration.Refactoring is the process of improving internal structure without changing external behavior. It has long been valued as a means of paying off technical debt.As code generation costs drop, the calculation changes. Which is faster and more reliable: carefully refactoring existing code over a week, or clarifying specifications and having it regenerated? The latter is increasingly becoming a realistic option.However, this doesn't mean refactoring is unnecessary. Regeneration is only effective within the scope where specifications can be clearly verbalized. Code containing implicit specifications accumulated over years of operation—such as edge case handling not written in docs or performance tuning results—risks being lost during regeneration.The axis of investment has shifted from always refactor to refactor or regenerate in this case.The value of writing tests itself does not change. What has changed is the ROI of humans writing test code by hand. What is flipping here is the allocation of investment toward metrics, not the design principle.If you leave identifying test cases and generating test code to AI, comprehensive tests appear in seconds. What humans should do here is design the test strategy—judging what should be tested—rather than implementing the test code.Spending time on determining whether a test verifies a truly meaningful specification is becoming higher ROI than spending time just to raise coverage numbers.The degree of flip for investment in readability is smaller compared to other items, but judgment is beginning to change depending on who is reading. If the code is for humans to read and understand, beautiful naming and clever comments remain important.On the other hand, in code primarily read and written by AI, type information and intent explanations in JSDoc can improve AI understanding more than beautiful naming intended for humans. The definition of readability itself is changing depending on the reader.While some things flip, others have always been important and are even more worth investing in now. According to the law, these are things related to the definition of intent and judgment—processes AI cannot do.The ability to accurately verbalize what to make and why is actually increasing in value in the AI era.It is no coincidence that Kiro Specs is designed to have you write specifications first. If you throw ambiguous specs at an AI, it will probabilistically fill in the blanks, resulting in code that sort of works but you don't know if it meets the specs. The effort to verify and fix this often exceeds the effort of writing specifications from the start.Starting development without a PRD leads to chaos later. This lesson from 10 years ago is perfectly valid for AI development. In fact, because AI generation speed is fast, ambiguous specs can lead to a large amount of rework in a short time, arguably making the importance of specifications greater than before.The culture of ADR (Architecture Decision Records)—why this configuration was chosen, what alternatives existed, and why they were rejected—is being rediscovered in the context of CLAUDE.md.The guideline for CLAUDE.md to write persistent context that cannot be inferred from code is exactly the recording of design decisions. Information such as packages/shared/src/legacy/ is a compatibility layer for old APIs. You will want to refactor it, but do not touch it (three external systems depend on it, scheduled for removal in 2026 Q3) cannot be inferred no matter how closely an AI reads the code.To have AI write correct code, we must provide the background of these design decisions as context. This is the same structure as onboarding a new human member; the verbalization and persistence of prerequisite knowledge is universally important across eras.The value of the ability to read and judge is rising relative to the ability to write.In the era when CI was just about if the build passes, it's okay, the quality gate was the success or failure of the build. Now, the phase where humans judge if the AI output meets the requirements is becoming the quality bottleneck.Reviewing AI-generated code differs in quality from reviewing human-written code. AI can produce inconsistent errors and it is not rare for it to lie convincingly. To spot library version mismatches, calls to non-existent APIs, or logic that ignores instructions, one needs an understanding of the entire codebase and a deep understanding of specifications.Since review is becoming the process that determines quality, investment here is universally important.CLAUDE.md, Steering, Rules. Though the names differ, they all represent the act of organizing prerequisite knowledge to provide to the AI.We are in an era where the most cost should be spent on organizing preconditions before writing code. This is a direct consequence of the law: when generation cost drops, the bottleneck moves to intent. Code can be regenerated as many times as you like, but if the preconditions are wrong, it will never be correct no matter how many times you regenerate it.If we look at the summary so far along one axis, the criteria for categorization are simple:What Flips = Investment in processes AI can now do cheaply (Refining the product)What is Universal = Investment in processes AI still cannot do (Refining the intent)As generation costs drop, the ROI of the former decreases, and the ROI of the latter increases. This can be called a structural law that does not depend on specific tools or languages.Combining this law with patterns from software development history, we can see several problems that have not yet fully materialized but are almost certain to come in the context of AI coding. While each of these themes is deep enough to be explored in its own separate article, I will only outline their structures here.The issue where no one updates the internal Wiki and a new member causes an accident using old procedures has occurred repeatedly in technical organizations.The same will happen with CLAUDE.md or Kiro Specs. Code is generated and updated by AI, but the maintenance of instruction files is done by humans. This asymmetry will eventually become a problem. A state where the code is up-to-date but the instruction file is a lie is the classic problem of code works but docs are wrong. Handling this issue may become a primary axis in future tool competition.Kiro's Agent Hooks is a mechanism that can trigger agents based on events such as file changes, allowing for the configuration of tasks like automatic document updates. However, as pointed out in the SDD (Spec-Driven Development) tool comparison article published on martinfowler.com, drift between specification and implementation remains a challenge. Addressing this issue may become a key factor in the future competition among tools.https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.htmlBefore Docker, deployments often broke due to differences in development environments. It works on my machine hindered team development due to lack of reproducibility.A similar problem is appearing in AI tool instruction design. On GitHub, dotfiles repositories like My Claude Code Settings or My AI Agent Setup are surging, creating a culture of sharing personally optimized CLAUDE.md, skills, and hooks. While healthy for individual productivity, It works with my CLAUDE.md could eventually become an obstacle in team development.DevOps was born out of the disconnect between those who build and those who run. In the future, the same wall may arise in the structure of humans operating code in production that was written by AI.Lisanne Bainbridge's 1983 paper Ironies of Automation pointed out that as automation becomes more sophisticated, operators lose manual skills and become unable to respond to exceptions. This insight, repeatedly confirmed in aviation and process control, also applies to software development. As AI writes more code, humans understand the details of the codebase less, and humans may become unable to handle failures that the AI cannot handle.https://en.wikipedia.org/wiki/Ironies_of_AutomationWith the decentralization of microservices, how to maintain consistency between services became a major challenge. The same could happen with Agent Teams. Running 10 agents in parallel might decrease efficiency due to the overhead of sharing context. This is the Agent version of Brooks's Law—adding manpower to a late software project makes it later—proposed by Fred Brooks in The Mythical Man-Month in 1975.https://en.wikipedia.org/wiki/Brooks%27s_lawThe design philosophy of AI coding tools is a reinvention of practices built over 20 years of human team development. Some parts of history repeat, while some common sense flips.The law for categorization is simple: When generation cost decreases, the center of gravity for value shifts from the product to the intent.Refining code—DRY, refactoring, naming, coverage—is changing from things you should always invest in to things you judge based on the situation. Refining intent—verbalizing specifications, recording design decisions, review ability, organizing context—remains as important as ever, and its weight as a bottleneck has increased.And if you know the patterns of history, you can see through new tools and concepts, recognizing them as that thing from 10 years ago. If you can see through them, you can apply the lessons left by your predecessors as they are.Problems that look new may boil down to known patterns when viewed structurally. Thinking this way, there might not be that many truly unknown challenges after all.

When Software Development Common Sense Flips: The Law of Decreasing Generation Costs

CLAUDE.md、.cursor/rules、Kiro Specs、Devin Playbooks。ここ1年で「AIへの指示ファイル」が急増しました。新しいツールが出るたびに新しい名前がつくものの、やっていることには既視感があるのではないでしょうか。「これ、要件定義書では？」「これ、オンボーディング資料では？」「これ、ランブックでは？」長年ソフトウェア開発に関わってきた人なら、同じことを感じているでしょう。一方で、過去に「当然やるべき」とされていたプラクティスの一部が、今の開発では足枷になり始めている実感もあるのではないでしょうか。本記事では、この既視感と違和感の正体を掘り下げま...

ソフトウェア開発の常識が反転するとき—生成コストの低下がもたらす法則

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 and Cursor.AI coding agents are increasingly used in software development, helping developers write, review, and deploy code more efficiently. Agent skills and the broader agent plugin packaging model are emerging as best practices for steering coding agents toward reliable outcomes without bloating model context. Instead of repeatedly pasting long AWS guidance into prompts, developers can now encode that guidance as reusable, versioned capabilities that agents invoke when relevant. This improves determinism, reduces context overhead, and makes agent behavior easier to standardize across teams. Agent plugins act as…  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                        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