今日、鳴る？ (Will It Ring Today?)

An AI-powered decision-support tool that turns Osaka weather, time, vehicle, and rider preferences into practical work-area and break plans for delivery riders.

Comment

Food-delivery riders constantly make practical decisions: When should I work? Which area should I start in? Should I continue in the rain, or take a break?

I built 今日、鳴る？ (Will It Ring Today?) after experiencing this uncertainty as a delivery rider in Osaka. The original site presented demand indicators based on weather, weekdays, holidays, and time bands. For OpenAI Build Week, I wanted to turn those indicators into a clear, personalized action plan.

What it does

The new Today's AI Work Plan asks the rider for:

  • vehicle type
  • available start and end times
  • rain preference

It combines those choices with the day's weather, weekday or holiday information, existing time-band indicators, and the general characteristics of five Osaka areas.

The result is a chronological plan showing:

  • suggested areas and work periods
  • a possible break period
  • a concise explanation
  • safety notes and the information used to make the recommendation

For example, it can suggest working in Umeda at lunchtime, taking a break in the afternoon, and moving to Namba–Shinsaibashi for the evening.

How I built it

The frontend uses React, TypeScript, and Vite. The backend uses FastAPI and Python. The production app is deployed with Vercel and Render.

The backend first creates and scores valid area-and-time candidates deterministically. It then sends only the strongest valid candidates to GPT-5.6 Terra through the OpenAI Responses API with Structured Outputs.

GPT-5.6 does not invent areas, change scores, or decide from unrestricted possibilities. It selects from backend-approved candidates and turns the result into a useful Japanese explanation. The response is validated again before it reaches the user.

How I used Codex

The original forecasting website was also built with Codex before Build Week. During the event, I continued working with Codex CLI to review the existing repository and develop the new AI work-planning feature.

In one continuous CLI session during Build Week, Codex helped me:

  • review the existing repository
  • design the AI feature and API contract
  • implement the FastAPI and React changes
  • add validation, caching, request limits, and deterministic fallback behavior
  • write and run automated tests
  • review edge cases and accessibility
  • connect and test the real OpenAI API
  • prepare the repository and documentation for submission

I used Codex not only to generate code, but also to inspect its work, find weaknesses, test assumptions, and iterate on confusing user-facing language.

Challenges I ran into

The hardest part was keeping the AI helpful without allowing it to overstate what the available data could prove.

The app does not have access to live delivery-order volumes or live compensation data. Area recommendations are based on weather, time, rider conditions, and general characteristics such as commercial districts, office districts, residential areas, and transport hubs.

To keep the output grounded, candidate calculation remains deterministic. GPT-5.6 can only select from validated candidates, and generated times and areas are checked before display. If the API is unavailable or returns an invalid result, the app returns a deterministic rule-based plan in the same format.

Cost and reliability

To keep the public demo affordable and available, the app includes:

  • a six-hour cache for matching requests
  • global and per-IP daily generation limits
  • duplicate-request locking
  • compact candidate input
  • a low reasoning setting
  • deterministic fallback behavior

A production test confirmed that the first request generated a GPT-5.6 Terra response and an identical second request was served from cache without another model call.

What I learned

I learned that adding AI is not simply adding a chat box. The most valuable design was a controlled pipeline: deterministic calculation first, constrained model reasoning second, and validation last.

That structure made the result more useful, testable, affordable, and honest about its limitations.

Build Week scope

The original forecasting site, which I had previously built with Codex, existed before Build Week. During Build Week, I used Codex CLI to design and build the personalized AI work-plan feature, including its backend controls, frontend interface, automated tests, real API integration, and submission documentation.

The current backend test suite passes all 40 tests, and the frontend production build succeeds.

What's next for 今日、鳴る？ (Will It Ring Today?)

Next, I would like to improve the service with shared persistent caching, support for overnight work periods, broader browser testing, and—where reliable data becomes available—carefully sourced live signals.

The current version is a decision-support tool, not a guarantee of orders, demand, or earnings.

Built With

Share this project:

Updates