FLIGHT / KNOWLEDGE & DESIGN
Flying Drones in Japan | Separate the Decisions
Aircraft, pilot, location, method, and conditions on the day. Keep these five apart and the procedures and screens you need come into focus.
Read this page in order
Start by gathering the flight conditions
To guide someone through Japan's flight rules, first line up the planned site, the date and time, the aircraft, the pilot, and the flight method. Answer "do I need permission?" with any of these missing and you end up answering for a different flight. Start from the official guidance published by MLIT (Japan's Ministry of Land, Infrastructure, Transport and Tourism) and check it against the specific conditions.
Source: MLIT | Rules for flying unmanned aircraft| Axis to check | Question for the user | Where the design stores it |
|---|---|---|
| Aircraft | Which aircraft, in which configuration? | Aircraft + a snapshot of this flight's configuration |
| Pilot | Who is flying, and in what role? | Pilot + evidence such as certificates |
| Location | Where are the takeoff point and flight area? | Mission route and area |
| Method | Within visual line of sight? At night? How close to people? | OperationProfile |
| Point in time | When was the decision made, and based on which information? | Assessment + referenced version |
Keep registration, permission, and notification separate
Aircraft registration, flight permission/approval, and flight plan notification are separate procedures with different purposes. DIPS2.0 provides several functions to match. Roll them into a single "Approved" inside the app and nobody can tell what has actually been completed.
Source: MLIT | DIPS2.0 and API guidanceA valid registration, for example, does not guarantee that this particular route falls within the permission conditions you hold. A record that the plan was notified does not mean the aircraft's condition or the day's weather have been checked. Keep that separation visible on screen too.
Show the reason and the next step on screen
A good first screen puts the map next to the list of open items. Spell out the reason, such as "airspace check still pending" or "registration expiry date could not be read," and point to one place to check for each. The key is never to paint an unverified item green.
| Example label | Meaning | Next action |
|---|---|---|
| Awaiting check | Required information not yet entered or retrieved | Fill in the missing items |
| Procedure may be required | These conditions may call for an additional procedure | Check with the relevant authority |
| Matched against documents | Comparison with the stated conditions is complete | Proceed to day-of checks |
| Recheck | Date, route, aircraft, or similar has changed | Re-evaluate the changed conditions |
Move on to the next layer
A sensible build order is the fleet register, then flight conditions, then day-of records. Make each an independent record tied to the same mission, and adding countries or workflows later becomes much easier.
DEFINITION OF DONE
When you build it, check these.
- An aircraft that has only completed registration is never shown as ready to fly.
- When a plan changes, every affected check item returns to "Recheck."
- The source URL and the time of verification can be opened from the results screen.
Design checkpoints for spec reviews and functional testing.
Check the sources
Explanations of the rules and definitions draw on the material below. The screens, data, and definition of done are our own design proposals.
- MLIT | Rules for flying unmanned aircraftJapan's flight rules and the relevant official contact points
- MLIT | DIPS2.0 and API guidanceEach procedure and the conditions for applying to use the API
Sources checked on: September 30, 2026. Please confirm how the rules apply to your case against the latest official information.