I attended AWS Summit 2026, held at Makuhari Messe.
There seemed to be more people than before. The scale felt like it was gradually growing, and you could feel the energy of the venue. The seats for the keynote were full, with many people standing to watch. It rained every day, so lining up was a bit of a hassle too.
About the sessions I heard
First, let me summarize the content of each session and what I learned.
Session 1: Using Claude on Amazon Bedrock to build and deliver generative AI services
This was a mini-session by NTT DATA held inside the Anthropic booth. They introduced how they use Claude on Amazon Bedrock in their customer-facing generative AI service “LITRON.”
The talk centered on two axes: using Claude both for “embedding it into the service” and for “making service development more efficient.”
Embedding into the service
They embed Claude as a core function that handles user interaction and decision-making/coordination. On top of that, they also assign it task-specific functions like document comprehension and slide generation. From the user’s perspective, they receive value as a single feature of the service without being aware that Claude is running behind the scenes.
One benefit they highlighted is that going through Amazon Bedrock lets them keep inference entirely within Japan. This makes it easier to serve customers with strict security requirements.
Making service development more efficient
On the development side, they combine Claude Code on Amazon Bedrock with the AWS MCP Server.
They introduced scenarios like the following.
- Design study / PoC: Since generative-AI-related AWS services are updated daily, they want to start by gathering the latest information. They have Claude Code run everything from “researching the latest information → deploying AWS resources → coding,” speeding up PoCs.
- Design / implementation: They have it propose implementation plans based on source code and design documents, then proceed straight to coding. Even legacy Excel design documents that come up in external system integrations can be used as input.
- Managing team development: Because development members create and use AWS resources at their own discretion, management tends to get messy. They have Claude assist with checking and analyzing resource status, and routine tasks are scripted and run on a schedule.
What stuck with me was how they collected team rules such as commit message formats into Skills, shared them among members, and standardized development. It felt like a way of turning implicit rules that tend to depend on individuals into a team asset through the mechanism of Skills.
Session 2: Transforming the developer experience through AI-driven development
Slides: https://pages.awscloud.com/rs/112-TZM-766/images/R12_0625_6_AIM213_v1.pdf
This was a session by Tokio Marine & Nichido Systems. They introduced how the whole organization incorporates AI into development and operations, with AI-driven development as the main theme.
The company has been driving cloud adoption with AWS at its core since 2018, and their migration to the cloud (LIFT) is 70% complete. The flow was that they now want to redirect the agility they gained toward AI. They deploy generative AI along two axes: “for BIZ” in the business domain and “for IT” in system development and operations.
Embedding AI into operations (for BIZ)
They introduced a “business AI navigator” that embeds AI into highly specialized decision-making work. The implementation is a multi-agent architecture, running on Amazon Bedrock AgentCore as the execution platform, with Mastra adopted as the framework that runs on top of it.
A Supervisor agent orchestrates three agents: web search, document checking, and answer review. By splitting the roles, they ensure the accuracy and explainability of answers. Separately, they have also built internal information search (SysSearch) and others, and shared that efficiency gains are starting to show.
AI-driven development (for IT)
Here is the main theme, AI-driven development. The company pursues it in two styles.
One is “AI-driven development” that keeps existing processes but has AI create the deliverables, with people focusing on instructing and approving. The other is “AI-DLC,” a customized version based on AWS’s proposed AI-DLC (AI-Driven Development Life Cycle), an end-to-end style where the business owner and developers sit together and complete everything from requirements definition to implementation in a single day.
In August 2025, they ran an AI-DLC workshop jointly with AWS (the third company in Japan, and the first in the financial industry). Four teams and about 40 people participated, and in the trial they reportedly saw results like roughly 10x speed and roughly 3x productivity.
Challenges that came into view
At the same time, they frankly talked about walls that still need to be cleared before running AI-DLC in full production for financial system development.
They cited things like existing assets whose structure is hard for LLMs to read (such as Excel grid-paper spreadsheets), the limits of the context window, the quality and review of generated artifacts, and UI/UX not yet being sufficiently covered by AI-DLC. The biggest challenge is people keeping up with the speed of “questions.” As AI mass-produces questions, the key is how fast you can turn the “question → verification → judgment” cycle, and it was memorable that this demands a shift in mindset and improved skills not only from developers but also from business owners.
Facing it as an organization
To face these challenges as an organization, they have set up an “AI-Driven Development Overall Promotion Office.”
They pursue four things in parallel—platform building, talent development, support for individual projects, and revising development processes—plus research into the latest trends. Among these, the idea of “harness engineering” was interesting: the framing that what determines AI output quality is not the model itself but the design quality of the environment surrounding the model (the harness) (Agent = Model + Harness). By preparing harnesses like specification templates, verification scripts, and AI review agents as organizational assets, they aim to guarantee a certain level of quality no matter which team is in charge.
They closed with the outlook of positioning AI-driven development as a “third development methodology” alongside waterfall and agile, aiming for company-wide rollout in fiscal year 2027.
Session 3: How to use AWS for training and operating Physical AI
Slides: https://pages.awscloud.com/rs/112-TZM-766/images/R10_0625_AIM328_v1.pdf
This session explained how to train and operate Physical AI on AWS, all the way down to a reference architecture. I also stopped by the “Physical AI - See, Think, Move” booth inside the AWS Village. A demo embodying this concept was running, so I’ll summarize that too.
What is Physical AI
The session’s definition of Physical AI was “a system that perceives the physical world, reasons, learns, and acts autonomously.” Unlike conventional industrial robots where a person specifies coordinates and motions in advance, its distinguishing feature is that it can move adaptively from training data, and it is expected to be useful in ever-changing settings that have been hard to automate.
For the architecture, they introduced the framing of combining a slow agentic AI that oversees the whole with a fast (tens of Hz) robot foundation model (VLA: Vision Language Action Model) that controls the robot. The agentic AI plans “what to do and how,” and the robot foundation model generates the actual control and motion based on sensor input—a division of roles.
The booth demo
In a large booth, there was a diorama modeled on a virtual town, with two robot arms lined up next to it. The buildings in the town were reportedly generated by AI too. The roads were given names like Green Street and Purple Street, and delivery robots running along line-tracing paths carried packages on them.
The demo scenario goes like this. When a delivery robot encounters an obstacle blocking the road while driving, it sends that information to the cloud. On the cloud side, based on which position the alert came from, it determines which of the two robot arms to move.
Since there is no camera overlooking the town, the designated robot arm moves near where the alert came from, photographs the road, and recognizes the obstacle from that image. The screen showed the intermediate steps of its thinking, like “Observing Green Street with ARM2” and “An object that appears to be a plastic bottle is blocking the road,” so you could see how the AI was interpreting the situation. A gripper is attached to the tip of the arm, and it removes obstacles tagged with QR codes in smooth motions. It did recognize plastic bottles and smartphones as foreign objects, but it was built so that it could only actually grab the ones with QR codes.
This decision-making part is handled by Claude Haiku on the cloud. The robots on the ground stick to just seeing and moving, while interpreting the situation and deciding the next move is left to the agentic AI in the cloud. The division of roles from earlier was directly embodied here, making for an easy-to-understand demo.
How AWS supports training and operations
The main body of the session was about how to build, on AWS, the training and operations foundation that makes such Physical AI possible. It was broadly organized into a three-stage flow. First comes data collection from the edge (AWS IoT Greengrass and AWS IoT Core, with Amazon S3 as the storage destination). Next is model training and simulation in the cloud (Amazon SageMaker AI and AWS Batch, and physics simulators like Isaac Sim and MuJoCo), followed by the Sim2Real loop that delivers trained models to real machines and closes the gap. Finally, Strands Agents was introduced as the part connecting robots and agentic AI, and they said the reference architecture bringing these together and sample implementations are also publicly available.
The framing that even robots operating in the physical world come down to the ML lifecycle of data collection, training, and deployment behind the scenes made sense to me. Looking back afterward, I realized the booth demo had carved out and shown the operations side of that loop.
Session 4: From 165 days to 30 minutes: the “developer-only runway” JAL Digital laid down — a practical account of Platform Engineering that reduces cognitive load to zero
Slides: https://pages.awscloud.com/rs/112-TZM-766/images/0626_PRT141-S.pdf
This was a session by Takuya Daiyo of JAL Digital and Hiroshi Otsuka of Red Hat (PRT141-S, a Red Hat sponsor session). It was a practical report on how they used Platform Engineering to change a situation where in-house developers were so busy with environment setup and various applications that they could hardly start writing code. The title “From 165 days to 30 minutes” contrasts a lead time of 165 days to release a minimal system against their goal of getting the development environment ready in under 30 minutes.
Why a “runway” was needed
The background for launching it was the “turbulence” surrounding developers. Code conventions, monitoring setup, CI/CD, vulnerability response, application procedures—a state where you get worn out before writing the actual code. To change this, a Platform Engineering (PFE) team was launched.
The first thing they tackled was measuring the current state in numbers. When they visualized it through VSM (Value Stream Mapping), USM (User Story Mapping), and interviews with developers, three numbers came into view: a lead time of 165 days, a process time of 385 hours, and more than 40 kinds of application forms. Showing this in numbers rather than by gut feel, so that the challenge could be shared by both management and the front lines, was a stance consistent throughout the session.
Building it into the business plan
The next impressive point was that they built this effort into the business plan rather than ending it as a one-off improvement. They drew a roadmap with FY25 as the dawn phase, FY26 as the growth phase, and FY27 as the expansion phase, and set concrete first-year KPIs like “development environment preparation via the portal averaging under 30 minutes,” “a 70% reduction in the average lead time to production release,” and “over 90% of JAL Digital employees aware of PFE activities.” The framing was that precisely because there is numerical backing, you can secure budget and talent and get the whole company involved.
Three approaches to eliminate cognitive load
To shrink the lead time for environment preparation from 165 days to 30 minutes, they introduced three solutions.
The first is turning internal documents into TechDocs. They consolidate documentation that was scattered all over the place into a single entry point called the developer portal. Beyond that, they envision an interactive knowledge base linked with AI, aiming to shift from “searching” to “asking” and reduce the time spent looking for documents to zero.
The second is creating Software Templates. These shorten the path from application to environment setup down to minutes, automatically provisioning from a simple configuration that tends to be adopted in-house: AWS Lambda and Amazon DynamoDB. They automated everything from creating a repository to launching Terraform, lowering the cognitive load around CI/CD as well.
The third is company-wide education and awareness. From the belief that it means nothing if no one uses what you built, they ran company-wide education and achieved results like breaking 80% attendance and 96.2% understanding of PFE’s significance. Alongside that, they continuously gather raw voices from the field in the form of a “troubles dump” and connect it to improvements.
Building the foundation, and Red Hat running alongside
As the foundation supporting all this, they introduced ROSA (Red Hat OpenShift Service on AWS) and RHDH (Red Hat Developer Hub). ROSA offloads operations as a managed service, and RHDH acts as the developer portal handling self-service environment provisioning—a division of roles. Developers can provision their own AWS environments from the portal through Terraform, Ansible, and GitOps.
At the same time, they were frank about it: just introducing the products didn’t make things work. When launching the PFE team “LUX,” they hit walls in areas like gaining management’s buy-in and getting each department to cooperate. They got over those by reaching agreement through KGIs and KPIs, and by having leaders repeatedly raise awareness to gather members. For the challenge that “even if you build it, it won’t spread if people don’t know how to use it,” they ran alongside the front lines with the motion of an Enabling Team—teaching, letting people try, and running beside them. On the Red Hat side too, the arrangement had them running in parallel on things like building a support structure that involves management and developing engineers who can run on their own.
Summary
They wrapped up with three things to start acting on tomorrow. First, “measure”; build it into the “business plan”; and start from your “main battleground.” In particular, the realistic approach of not trying to do everything at once but producing results from the part your company uses most (in JAL’s case, the foundation where AWS and ROSA make up the majority) and expanding from there felt like a lesson that runs through the other sessions too.
Other
There were many robotics demonstrations, with all kinds of robots such as ones that trace human movements and ones with five fingers.
It looks like robots x AI will be active in all sorts of fields, from medicine to industry.
Summary
What I felt strongly through this year’s AWS Summit was just how many sessions there were on the theme of how to incorporate AI into development and drive it as an organization. From how to build generative AI services, to rethinking the development process through AI-driven development (AI-DLC), to Physical AI that works with robots, to Platform Engineering for developers—even with different angles, each company was heading in the direction of “restructuring how development is done with AI as the premise.” I felt the center of gravity of the conversation shifting from the stage of individuals using tools conveniently to how to move forward as a whole company or organization.
Flip that around, and it also means no one yet has a definitive way of doing it. AI’s evolution is right in the middle of a period of rapid change, and it wouldn’t be strange for last half-year’s correct answer to change in the next half year. That’s exactly why, rather than copying case studies as-is, I think all you can do is try things small in your own environment, measure, and build your own patterns while improving.
I myself want to use what I saw and heard here as a trigger to get hands-on and try out various things around AI-driven development. I’m looking forward to seeing, at next year’s Summit, how much of the scenery I saw this year has become the norm.
Session materials and more
https://pages.awscloud.com/AWS-Summit-Japan-2026-Session-Materials-Download.html
https://summitjapan.awslivestream.com
