AIdeas: Gomi Bunrui - AI-powered waste classification app for Japan
Gomi Bunrui (ゴミ分類) is an AI-powered waste classification app that helps residents of Japan sort their rubbish correctly. Point your phone camera at any waste item and the app instantly identifies it, breaks it into its components, and tells you exactly which bin each part belongs to, based on the specific rules of your municipality.
My Vision
The day I got my first rejection sticker, I spent a good few minutes staring at my bin bag trying to figure out what I had done wrong.
In Japan, incorrectly sorted rubbish is not collected. It stays on the street with a sticker attached, and you carry it back inside and try again next time. For residents new to Japan, or even long-term residents navigating a new city, this happens more than most would admit.
Japan has 1,741 municipalities, and almost every one of them has different recycling rules. A PET bottle is not a single waste item; the bottle body, the cap, and the label are three separate categories, and which bins they go in depends on where you live. The official guidance exists in printed pamphlets, often only in Japanese, updated every few years.
My vision for Gomi Bunrui is simple: nobody should have to study a pamphlet to throw something away. You should be able to point your phone at something, get an instant answer, and move on with your day.
That idea eventually found its philosophical expression in a custom kanji that I am thinking to create for this project: 言帰, read gen-ki or kotoba-gaeri. It combines 言 (word, to name) and 帰 (return, homecoming). The meaning it carries is: "The word that sends things home." The AI names each component correctly. The object finds its way back to where it belongs. That is the complete loop this app is trying to close. I will need more help from locals with this one.
For the MVP, I built support for four municipalities: Nagoya, Shibuya (Tokyo), Osaka, and Kyoto, covering a combined population of approximately 6.6 million people. The longer-term ambition is to expand this to all 1,741 municipalities and offer it as a managed service to local governments who want to reduce waste sorting errors and support their international residents.
Why This Matters
Japan's recycling system is one of the most rigorous in the world, and one of the most confusing to navigate.
For the 3 million-plus international residents of Japan, the gomi pamphlet is a genuine source of stress. Rules vary not just by city but sometimes by ward. Collection days vary by category. Items that seem like a single object, a bottle, a takeaway container, a battery, are often multiple waste streams in one.
Beyond individual frustration, there is a real civic cost. Incorrectly sorted waste disrupts collection schedules, increases contamination in recycling streams, and creates friction between residents and their local community. In many neighbourhoods, gomi rules are a source of tension, particularly for newcomers.
This friction runs against something deep in Japanese culture. もったいない (mottainai) is the feeling of grief at a thing not used, not returned, not respected at the end of its life. Incorrect sorting is, in a quiet way, a violation of that value. Gomi Bunrui does not preach it. It just tries to make doing the right thing easy.
AI is well suited to solving this problem. The challenge is not intelligence; it is knowledge. What the system needs is deep, accurate, municipality-specific data combined with a reliable way to interpret what someone is holding. Amazon Bedrock and Claude provide both the vision capability and the reasoning to connect what the camera sees to what the local rules require.
This also represents a meaningful opportunity for local governments. Japan's recycling apps are largely static, rule-lookup tools that require manual maintenance and provide no multilingual support. AI changes what is possible: the ability to handle novel items, multi-component objects, and ambiguous packaging, without exhaustive manual rule-writing for every possible item.
How I Built This
The Approach: Spec-Driven Development with Kiro
I built Gomi Bunrui using Kiro throughout the entire development process, and the spec-driven workflow was central to how the project came together in a short time.
Rather than jumping straight into code, I started by writing a high-level spec describing what the app should do. Kiro translated that into a structured set of requirements, a design, and a task list. This forced me to think carefully about the architecture before writing a line of code, and it meant I was never working from a blank page.
I also used Kiro's steering files to give the project persistent context: brand guidelines, the bilingual output requirements, the architecture constraints, and the municipality data structure. Every time I opened a new task, Kiro already understood the project. This was particularly valuable for maintaining consistency across the frontend and backend as the codebase grew.
Beyond the defaults, I invested time in customising how Kiro works to match the way I wanted to build. I created three hooks:
A git-commit hook that automatically commits after any top-level task is completed, keeping the git history clean and aligned with the task structure without any manual effort.
A sequential ordering hook that fires before Kiro begins creating a new spec, adding a sequence number to the spec directory name. This keeps specs organised in the order they were built and makes it easy to understand the shape of the project's history at a glance.
A knowledge-base hook that triggers at the end of each implementation phase, automatically updating the project's living documentation: ubiquitous language, general docs, architecture decisions, infrastructure and ops details, and end-to-end test coverage. The knowledge base stays current without being a separate task.
I also built a custom agent skill to generate conventional commits, which feeds directly into the semantic versioning system across all four monorepo projects.
Kiro accelerated development across the full stack: the React PWA frontend, the user registration and authentication flows, the Kotlin Lambda functions, and the static landing page with beta signup collection. In each case I guided and reviewed, but Kiro did the heavy lifting. For a solo developer working to a competition deadline, this workflow made a meaningful difference.
Architecture Overview
The stack is deliberately lean, built to run cost-effectively on the AWS Free Tier during development and scale cleanly into production.
The project is structured as a monorepo with four independently deployable projects: backend, frontend, website, and end-to-end tests. Each follows semantic versioning driven by conventional commits. All three application projects have full test coverage: unit and integration tests for the backend, component and integration tests for the frontend, unit tests for the website, and end-to-end tests covering the critical user flows across the full stack. GitHub Actions runs the full test suite on every push and only deploys on a clean run.
Frontend: A React Progressive Web App (PWA), deployed to S3 and served via CloudFront. Building as a PWA meant I could reach both Android and iOS users without the overhead of separate native builds. The app is fully bilingual, switching between English and Japanese throughout.
Authentication: User registration and login are handled via Amazon Cognito, with email and social login supported. Auth was built entirely with Kiro and is fully functional in the current release.
Backend: A Kotlin Lambda function with SnapStart enabled, sitting behind API Gateway. SnapStart significantly reduces cold start latency, important for an app where the scan response time directly affects the user experience. The Lambda handles image receipt, constructs the Bedrock request, parses the response, and returns the result.
AI Classification: Amazon Bedrock with Claude Haiku 4.5 as the model. Each scan sends the image and a municipality-specific system prompt to Bedrock. The prompt instructs Claude to identify the item, decompose it into its physical components, map each component to the correct waste category for the selected city, assess sorting difficulty, and return a structured bilingual JSON response. The prompt structure is identical across all four municipalities; only the city-specific category enums and rules differ.
Data: DynamoDB stores municipality data, category definitions, and collection schedules. Waste category rules for Nagoya, Shibuya, Osaka, and Kyoto were extracted from official municipal PDF guides and verified against source material before being encoded into the system prompts.
Landing page: A separate static site at
gomi-bunrui.app, also built with Kiro, deployed to S3 via CloudFront. It collects beta signups through an email form backed by a Lambda and DynamoDB, with SES sending confirmation emails. The landing page went live before the app itself, giving the build-in-public content strategy a URL to point to from the early days.DNS and TLS: Route 53 manages all DNS for
gomi-bunrui.app, with hosted zones and record sets defined in SAM. ACM provisions and auto-renews the TLS certificates attached to the CloudFront distributions. No manual certificate management, no clickops.Infrastructure: Every AWS resource in the project is defined as code using AWS SAM. There is no clickops anywhere in the stack. SAM templates cover Lambda functions, API Gateway, DynamoDB tables, S3 buckets, CloudFront distributions, Cognito user pools, SES configuration, CloudWatch log groups, alarms and custom metrics, Route 53 records, and ACM certificates. GitHub Actions compiles and deploys each of the four monorepo projects independently on every push to main, using SAM for all backend and infrastructure changes and S3 sync for static assets.
The Hardest Part: Multi-Component Classification
The single most challenging part of the build was getting Bedrock to reliably identify that a single physical item is made up of multiple components, each with a different waste classification.
A PET bottle is the clearest example. The bottle body, cap, and label are three distinct materials, PET resin, polypropylene, and paper or plastic film respectively, and in most Japanese municipalities they go in different bins. Initially, the model would sometimes classify the bottle as a single item, or correctly identify the components but apply the wrong category mappings for the selected city.
The solution was in the system prompt design. I moved away from asking Bedrock to classify the "item" and instead instructed it to identify the physical materials present in the image and classify each one independently against the city's category rules. I also added explicit examples of multi-component items to the prompt, and built validation into the response parser to flag cases where the component count seemed unusually low for the identified item type.
This granularity is not just an engineering choice. It reflects the philosophy embedded in 言帰: every component deserves its own correct name before it is sent on its way. Classifying a PET bottle as a single object would be a simpler problem, but it would be the wrong answer.
I also had to be careful about guardrails. Early versions of the prompt were too aggressive about rejecting unrecognised input, and were flagging legitimate product labels and foreign-language packaging as suspicious. Getting that balance right, rejecting genuinely problematic inputs while allowing normal real-world items, took several iterations.
The result is reliable enough that a PET bottle consistently returns three components with correct category mappings, which the scan results screen surfaces clearly: "3 parts detected. 3 categories."
AWS Free Tier
The project was developed within the AWS Free Tier where possible. All infrastructure is managed through AWS SAM templates with no clickops anywhere in the stack. The services in use are: Lambda (with SnapStart), API Gateway, DynamoDB, S3, CloudFront, Cognito, SES, CloudWatch, Route 53, and ACM, all operating within free tier limits during development. Amazon Bedrock is the primary cost, charged per token, and the token efficiency of the system prompts was an intentional design choice. Switching to Japanese-only text output with English category IDs roughly halves inference costs compared to fully bilingual model output. The team behind the competition provided $200 in AWS credits that helped with cost for Bedrock.
Demo
What the App Does
The core flow takes about five seconds from camera tap to result:
- Open the app and select your municipality (Nagoya, Shibuya, Osaka, or Kyoto)
- Navigate to the scan screen and point your camera at any waste item
- Tap the capture button; the image is sent to Amazon Bedrock
- The results screen appears with each detected component listed, colour-coded by waste category, with sorting tips and disposal instructions in English or Japanese
Scan Result: PET Bottle
[INSERT SCAN RESULT SCREENSHOT]
In this scan, the app identified a sports drink PET bottle and returned three components with their correct Nagoya classifications:
- ペットボトル本体 (bottle body) — PET bottle recycling
- 青色プラスチックキャップ (blue plastic cap) — Plastics
- ラベル (label) — Burnable waste
Sorting difficulty: Easy
One item. Three bins. The right answer for this specific city, in under three seconds.
Live App
The app is live as a PWA at gomi-bunrui.app/app/
Registration, login, and scanning are all fully functional. The collection day calendar is coming in the next release.
What I Learned
Spec First, Code Second
The biggest shift from my usual workflow was starting with the spec rather than the code. Writing out what the app needed to do, in plain language, before opening the IDE, forced decisions that would otherwise have been deferred until they became expensive problems. The navigation architecture, the bilingual output schema, the municipality data structure: all of these were resolved at the spec stage, which meant the implementation phase was mostly execution rather than discovery.
Kiro's steering files were also more valuable than I expected. Giving the IDE persistent context about the project meant every generated output was aligned with the broader system from the start, rather than requiring constant correction to match conventions I had established elsewhere.
The deeper lesson was that Kiro rewards investment. The out-of-the-box workflow is already useful, but the custom hooks made it genuinely fit the way I work. Auto-committing after each completed task, keeping specs sequentially ordered, updating the knowledge base at the end of every implementation phase: none of these are complicated to set up, but together they meant the project stayed well-organised under competition pressure. The custom conventional commit agent skill was a small addition that paid dividends every single day.
Prompt Engineering Is Product Design
The quality of the scan results is almost entirely determined by the quality of the system prompts. Getting multi-component classification right, handling edge cases like foreign-language packaging and product barcodes, and tuning guardrails to reject genuinely problematic inputs without blocking normal items: all of this required careful, iterative prompt work.
The most useful insight was treating city-specific rules as configuration rather than logic. Nagoya is the reference implementation; Shibuya, Osaka, and Kyoto share an identical JSON schema and output format, varying only in their category definitions. Adding a new municipality is now a matter of writing a verified prompt, not changing any code. Scaling to more cities is tractable.
The Unexpected Value of Constraints
Working within the AWS Free Tier imposed discipline that turned out to be useful. It pushed me towards architectural choices, Lambda with SnapStart over a persistent server, DynamoDB on-demand over provisioned, aggressive CloudFront caching, that are also the right choices for a production system at this scale.
The same was true of the competition timeline. Knowing the article deadline forced prioritisation in a way that open-ended side projects rarely do. Registration, scanning, and CI/CD all work end-to-end. Full test coverage exists for backend, frontend, and website; unit, integration, component, and end-to-end. The calendar is coming.
The Opportunity Beyond the MVP
Japan has over 1,700 municipalities and no scalable, AI-powered waste classification solution available to them. Most local governments handle resident enquiries about waste sorting manually. The combination of AI classification, official rule data, and a clean bilingual interface is something that I didn't find.
The post-competition path is a B2B municipal SaaS model: free pilots with two or three municipalities to build credibility and reference cases. This is a real market with a real problem, and Gomi Bunrui is in a good position to address it.
A Final Thought
There is a line in the philosophy behind 言帰 that stayed with me throughout the build: the app speaks the word; the user places the object in the correct bin. Technology names. People act. The kanji holds both roles without privileging either.
That felt like the right way to think about what AI should do in a product like this. Not replace the human. Not make decisions on their behalf. Just remove the confusion that was standing between them and doing the right thing.
If it managed that, even for a few people, it was worth building.
If you found this useful or know someone living in Japan who would benefit from the app, I'd genuinely appreciate your support. A like on this article helps Gomi Bunrui reach the top 300 in the AIdeas competition.
Try the app: gomi-bunrui.app/app/
Built with Kiro and the AWS Free Tier as part of the AWS 10,000 AIdeas competition.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article