FLIGHT / KNOWLEDGE & DESIGN
飛行計画・当日確認・飛行日誌｜運航を閉じる
予定を出して終わりにせず、何を確認し、何が起き、どう終わったかまで一つの運航に結ぶんじゃ。
このページを読む順
01
計画と実績を二つ持つ
特定飛行では、事前の飛行計画通報や飛行日誌に関する義務を確認する必要がある。国土交通省の最新要領が基準じゃ。アプリ独自の記録が、そのまま法定の様式を満たすとは限らんけぇ、出力項目を照合しよう。
出典：国土交通省｜飛行計画の通報・飛行日誌計画は「こう飛ぶ予定」、実績は「実際にはこうじゃった」。実績を入れて計画を上書きすると、なぜ遅れたのか、どこを変更したのかが消える。二つを残して差分を見るんよ。
02
三つの時間帯で責任を受け渡す
| 時間帯 | 確認と記録の例 | 完了の合図 |
|---|---|---|
| 飛行前 | 機体状態、気象、周囲、体制、緊急時の対応 | 責任者が今回の条件を確認 |
| 飛行中 | 開始・終了、位置、逸脱、異常、担当者の操作 | 飛行の終了と機体回収を確認 |
| 飛行後 | 不具合、整備、画像回収、必要な報告 | 未解決事項の担当と期限を付与 |
チェックボックスを並べるだけじゃ弱い。「異常あり」を選んだときに、説明と対応先へ進める設計がいる。天候や機体の中止基準は、機種・運用マニュアルと現場のリスク評価で定めるものじゃ。万能な数値をここで決めんこと。
03
状態遷移の例
draft → planned → preflight_review → ready
ready → in_progress → landed → closed
preflight_review → on_hold
in_progress → contingency → landed
landed → follow_up_required → closedこれは記録アプリの状態例じゃ。実機への指令をこの列から自動で出す設計ではない。通信が途絶えたら、最後に受信した状態を「今の状態」として確定せず、時刻付きで不明を伝えよう。
04
オフラインからの復帰
現場で通信が弱いことを想定し、未送信の入力は端末内に一時保存できる設計を検討する。共有済みかどうかを表示し、再送時は同じイベントIDで重複登録を避ける。別の人が更新しとったら、黙って上書きせず差分を確認するんよ。
DEFINITION OF DONE
つくる時は、ここを確かめよう。
- 計画変更前の版と、実際の飛行記録が両方残る。
- 未送信・送信済み・送信失敗を区別できる。
- 異常ありで閉じた案件に担当とフォローが残る。
仕様レビューと動作確認に使う、設計上のチェック項目じゃ。
根拠を確かめる
制度・定義の説明は下の資料を参照しとる。画面・データ・完成基準は独自の設計提案じゃ。
- 国土交通省｜飛行計画の通報・飛行日誌特定飛行の計画通報と記録
参照確認日：2026年9月30日。個別の適用は、公式の最新情報で確認してつかぁさい。