飞行 / 知识与设计
飞行许可与批准 | 让条件和出处一目了然
要把用户引导到正确的申请,就必须处理地点与飞行方式的组合。同时还要为例外情况和未核实项目做好设计。
按顺序阅读本页
01
把判断拆成五个格子
是否需要飞行许可/批准,取决于空域、飞行方式等因素。除了《航空法》的手续之外,还要留意《小型无人机等飞行禁止法》以及地方政府或设施的限制。请在 MLIT(日本国土交通省)的手续指南中确认最新条件。
出处:MLIT | 飞行许可与批准手续| 格子 | 输入示例 | 结果的保存方式 |
|---|---|---|
| 空域 | 机场周边、高度、人口密集地区等 | 适用 / 不适用 / 未核实 |
| 飞行方式 | 夜间飞行、超视距、与人员和财产的距离等 | 对每项运行条件逐一检查 |
| 机体与驾驶员 | 认证、资质、适用条件 | 凭证的有效性单独管理 |
| 地面与设施 | 土地使用、进入权限、当地限制 | 与管理者确认的记录 |
| 临时限制 | 临时指定、紧急变更 | 适用期间以及获取信息的时间 |
这份清单整理的是判断所需的输入,并不是一张详尽的法律判定表。在实现带条件的例外时,请追溯到法规原文和审查要领,并请专业人士复核结果。
02
不要只用文字段落保存规则
为每条规则赋予管辖区域、生效日期、适用条件、例外、出处 URL 和审核状态。如果只把阈值埋在代码里,规则一变,没人找得到该改哪里。
rule = {
jurisdiction, effective_from, effective_until,
conditions, exceptions, required_actions,
source_url, source_checked_at, review_status
}
assessment = {
mission_revision, rule_version,
result: "requires_review",
missing_inputs, reasons
}03
即使有许可,也要与本次计划比对
核对文件中写明的条件:涵盖的机体、驾驶员、期间、地点、飞行方式等。绝不要让 AI 去猜测读不出来的部分。可以让 AI 提取候选项,但与原件比对以及责任人签字确认必须作为流程中的明确步骤保留。
| 变更 | 应用的建议响应 |
|---|---|
| 更换为另一架机体 | 重新比对所涵盖机体的条件 |
| 更改开始时间 | 重新核对有效期和临时限制 |
| 延长航线 | 重新核对许可区域和地面管理 |
| 文件文字无法辨认 | 显示“无法读取”并要求重新提交 |
04
做一个出错时不会沉默的界面
地图数据不可用、规则已过期、许可文件无法读取。这三种情况都不等于“没有问题”。显示该项目为何未核实,并提供官方核查或转交人工处理的途径。给用户一条前进的路。
完成的定义
动手实现时,请核对以下各项。
- 输入缺失与不合规显示为不同的状态。
- 可以识别出依据过时规则评估的任务。
- 可以从结果追溯出处、例外和适用范围。
用于规格评审和功能测试的设计检查点。
查看出处
关于规则和定义的说明参考了以下资料。界面、数据和完成的定义是我们自己的设计方案。
- MLIT | 飞行许可与批准手续许可与批准、空域以及飞行方式
出处核对日期:2026 年 9 月 30 日。规则如何适用于您的具体情况,请以最新的官方信息为准。