FLIGHT / KNOWLEDGE & DESIGN
機体登録と機体台帳|同じ機体を正しく扱う
登録番号、所有者、機体構成、整備履歴。ひとつの入力欄に詰め込まず、運航につながる台帳をつくるんじゃ。
このページを読む順
01
制度の入口を確認する
国土交通省の案内では、屋外を飛行する100g以上の無人航空機は登録が必要じゃ。登録記号の表示とリモートIDの対応も確認する。リモートIDには例外条件があるけぇ、「全機体で同じ対応」とは決めつけず、公式の案内へつなごう。
出典:国土交通省|無人航空機登録ポータル02
識別子は役割で分けるんよ
| 項目 | 何を表すか | 注意点 |
|---|---|---|
| 内部機体ID | アプリ内で機体を追跡する鍵 | 変更される外部番号と分ける |
| 製造番号 | 製造者が付けた機体の番号 | メーカー・モデルとセットで照合 |
| 登録記号 | 管轄当局の登録に関する識別 | 国・期限・証拠資料も保存 |
| Remote ID識別情報 | 放送機能や機器を識別する情報 | 外付け機器交換を履歴にする |
| 表示名 | 操縦者が覚えやすい呼び名 | 一意性や公的な証明を担わせん |
外部の番号をデータベースの主キーにすると、変更時に整備や飛行の履歴が迷子になるんよ。内部IDで履歴を結び、公的番号は有効期間付きの関連情報として持つ案じゃ。
03
登録フローは、途中から戻れるようにする
まずメーカー・モデル・製造番号を入れ、重複候補を見せる。その後に登録情報と証拠資料を加える。登録手続き自体を終えていない人も下書き保存できるとええ。ただし「アプリへ保存」と「行政への登録完了」は表示を分けよう。
- 同じ番号が既にある場合は、新規作成前に既存機体を選べるようにする。
- 所有者と使用者を分け、チームの閲覧・編集権限を確認する。
- センサーや積載の変更は、機体本体を複製せず構成履歴へ残す。
- 登録期限が不明なときは、不明のまま保存して確認事項にする。
04
データ例と変更時の扱い
下はアプリ独自の設計例じゃ。DIPSの送信仕様ではないけぇ、そのまま外部に送るんじゃないよ。
{
"aircraft_id": "aircraft_demo_01",
"display_name": "調査機1",
"registration": {
"jurisdiction": "JP",
"mark": null,
"expires_at": null,
"verification_state": "unverified"
},
"configuration_version": 1,
"readiness": "not_assessed"
}飛行が終わった後に機体情報を更新しても、過去の飛行で使った構成は書き換えん。機体台帳の現在値と、飛行時点の写しを両方持つ。将来の不具合調査で効いてくる地味な工夫じゃ。
DEFINITION OF DONE
つくる時は、ここを確かめよう。
- 重複登録の候補を利用者が確認できる。
- 証拠未確認の機体が、確認済み扱いにならん。
- 機体情報を変えても過去の運航構成が復元できる。
仕様レビューと動作確認に使う、設計上のチェック項目じゃ。
根拠を確かめる
制度・定義の説明は下の資料を参照しとる。画面・データ・完成基準は独自の設計提案じゃ。
- 国土交通省|無人航空機登録ポータル機体登録・登録記号・リモートID
参照確認日:2026年9月30日。個別の適用は、公式の最新情報で確認してつかぁさい。