飞行 / 知识与设计
在日本飞行无人机 | 把判断分开来看
机体、驾驶员、地点、飞行方式、当天的条件。把这五项分开处理，所需的手续和界面就会清晰起来。
按顺序阅读本页
01
先把飞行条件收集齐全
要为用户讲清日本的飞行规则，首先要把计划地点、日期时间、机体、驾驶员和飞行方式排列出来。缺少其中任何一项就回答“需要许可吗？”，最终回答的就是另一次飞行。请从 MLIT（日本国土交通省）发布的官方指南出发，对照具体条件逐一核对。
出处：MLIT | 无人机飞行规则| 核对维度 | 向用户提出的问题 | 设计中的存放位置 |
|---|---|---|
| 机体 | 哪一架机体，采用哪种构型？ | 机体 + 本次飞行构型的快照 |
| 驾驶员 | 由谁操纵，担任什么角色？ | 驾驶员 + 证书等凭证 |
| 地点 | 起飞点和飞行区域在哪里？ | 任务航线与区域 |
| 飞行方式 | 是否在视距内？是否夜间？离人员多近？ | OperationProfile |
| 时间点 | 判断是何时做出的，依据的是哪些信息？ | 评估 + 所引用的版本 |
02
把登记、许可和通报分开
机体登记、飞行许可/批准、飞行计划通报是目的不同的独立手续。DIPS2.0 也相应地提供了多个功能。如果在应用中把它们合并成一个“已批准”，就没人说得清究竟完成了什么。
出处：MLIT | DIPS2.0 与 API 指南例如，登记有效并不能保证这条具体航线落在你所持许可的条件范围内。计划已通报的记录也不代表机体状态或当天天气已经检查过。这种区分在界面上也要保持可见。
03
在界面上显示原因和下一步
好的首屏会把地图和待办事项列表并排放置。写明原因，例如“空域检查尚未完成”或“无法读取登记有效期”，并为每一项指出一个核对的地方。关键是绝不把未核实的项目标成绿色。
| 标签示例 | 含义 | 下一步操作 |
|---|---|---|
| 待核对 | 所需信息尚未输入或获取 | 补齐缺失项目 |
| 可能需要办理手续 | 这些条件可能需要额外的手续 | 向主管部门确认 |
| 已与文件比对 | 与所载条件的比对已完成 | 进入当天检查 |
| 重新核对 | 日期、航线、机体等发生了变化 | 重新评估变化了的条件 |
04
进入下一层
合理的构建顺序是：先机队台账，再飞行条件，然后是当天记录。把每一项做成关联到同一任务的独立记录，之后增加国家或业务流程就会容易得多。
完成的定义
动手实现时，请核对以下各项。
- 仅完成登记的机体绝不会被显示为可以飞行。
- 计划变更时，所有受影响的检查项都回到“重新核对”。
- 可以从结果界面打开出处 URL 和核实时间。
用于规格评审和功能测试的设计检查点。
查看出处
关于规则和定义的说明参考了以下资料。界面、数据和完成的定义是我们自己的设计方案。
- MLIT | 无人机飞行规则日本的飞行规则及相关官方联系窗口
- MLIT | DIPS2.0 与 API 指南各项手续以及申请使用 API 的条件
出处核对日期：2026 年 9 月 30 日。规则如何适用于您的具体情况，请以最新的官方信息为准。