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

つくる時は、ここを確かめよう。

  • 重複登録の候補を利用者が確認できる。
  • 証拠未確認の機体が、確認済み扱いにならん。
  • 機体情報を変えても過去の運航構成が復元できる。

仕様レビューと動作確認に使う、設計上のチェック項目じゃ。

根拠を確かめる

制度・定義の説明は下の資料を参照しとる。画面・データ・完成基準は独自の設計提案じゃ。

参照確認日:2026年9月30日。個別の適用は、公式の最新情報で確認してつかぁさい。