飛行計画登録API フィールド対応表

概要

本ドキュメントは、飛行計画登録API（registerFlightPlan: POST /api/v1/fp/flight-plans/{flightPlanId}/registration。全入力項目が対象となる本登録時点のデータをFLIGHT_PLAN_REVISIONへ確定登録するAPI）を対象に、以下3層のフィールド対応関係を整理したものである。項目自体の入力は「飛行計画仮登録」（createFlightPlan）／「飛行計画更新」（updateFlightPlan）で行う。本ドキュメントが示す必須項目・型はいずれも本登録時点（FLIGHT_PLAN_REVISION）の制約である。

テーブル名・カラム名の命名規約、および本ドキュメントとER図で結論が食い違った場合にどちらを正とするかはデータモデル設計ドキュメントの規約に定める。

[!NOTE] 飛行計画の登録は仮登録（status=DRAFT）と本登録（status=ACCEPTED）の2段階に分かれ、仮登録の内容は FLIGHT_PLAN_DRAFTに保持したうえで本登録時にFLIGHT_PLAN_REVISIONへ確定登録する。10月デモではフロントエンドが一時保存機能を提供せずこれらのAPIを立て続けに実行するため、仮登録の時点で本登録と同じDIPS必須項目がすべて要求され、本ドキュメントが示す必須項目は実質的に仮登録から適用される（詳細はflight-plan-er.mdの「一時保存は専用テーブルで表す」参照）。

FlightPlanningService API: flight-planning.yaml の FlightPlanFields
データベースカラム: flight-plan-er.md の図1（FLIGHT_PLAN / FLIGHT_PLAN_REVISION / FLIGHT_PLAN_AREA / FLIGHT_PLAN_PILOT_ASSIGNMENT）・図2（FLIGHT_PLAN_DIPS_ATTRS / FLIGHT_PLAN_DIPS_PURPOSE / DIPS_REPORT）・図3（PILOT / ASSET / ASSET_UAS_ATTRS / ASSET_UAS_DIPS_ATTRS）。上位の概念モデルはutm-design-docs/docs/data-model/data-model.md
DIPS API: 「DIPS2.0 API（FPR）Guideline USP v1.0」 2.3.6 飛行計画情報登録・更新API のリクエストボディ

[!IMPORTANT] 10月デモで実際に通報するのは模擬DIPSであり、上記のDIPS2.0とは送信構造が一部異なる（実行モードが無い、 ussId・uriForCoordinationが必須、綴りの違いなど）。差分と模擬DIPS側の解決元は 11. 模擬DIPS（10月デモ）への通報にまとめており、食い違う項目は11節を正とする。

DIPS通報固有の詳細項目は、飛行計画本体（FLIGHT_PLAN_REVISION）ではなくFLIGHT_PLAN_DIPS_ATTRSとその配下で管理する。内訳は以下のとおり。

flightPurposes: 業務ロジック（noteの条件付き必須判定等）で参照するため、コード単位の行を持つFLIGHT_PLAN_DIPS_PURPOSEとして個別テーブル化
departurePoint/destinationPoint/email/flightAirspace/flightType: 一覧取得・通知・通報要否判定のいずれかが参照するため、FLIGHT_PLAN_DIPS_ATTRSの個別カラムとして保持
それ以外の項目は、DIPSへのパススルー用途のみのためFLIGHT_PLAN_DIPS_ATTRS.dips_report_detail（jsonb）へ集約

表左端の「項目」は、DIPS APIガイドラインに記載の項目名（日本語）を優先して採用し、DIPSに存在しないUTM固有項目（status/reportRequired/reportStatus等）はFlightPlanningService APIのdescriptionに記載の日本語名を採用した。

1. 管理・状態系フィールド

項目	FlightPlanningService API	API型	データベースカラム	DB型	DIPS API	DIPS型	備考
飛行計画ID（UTM）	`flightPlanId`（レスポンス）	`string`(uuid)	`FLIGHT_PLAN.id`	`uuid`	`flightPlanInfo.flightPlanId`	文字列	UTM内で作成時に発行するUUID。DIPSへは送信しない。`flightPlanInfo.flightPlanId`は`mode=0`（登録）では空文字、`mode=1`（更新）・`mode=2`（削除）ではDIPS側の受付番号（`DIPS_REPORT.dips_receipt_no`）を送る
飛行計画ID（DIPS）	`dipsFlightPlanId`（レスポンス。nullable）	`string`（nullable）	`DIPS_REPORT.dips_receipt_no`（`DIPS_REPORT`は`FLIGHT_PLAN`の通報履歴テーブル。表示するのは最新レコードの値）	`string`	DIPS API(飛行計画登録)のレスポンスに含まれる飛行計画ID(flightPlanId)	文字列	UTMのIDとは別にDIPS側が発行する識別子。`reportStatus`が一度も`REPORTED`になっていない間は`null`
飛行計画ステータス	`status`	`string`(enum `FlightPlanStatus`)	`FLIGHT_PLAN.status`（`FLIGHT_PLAN_STATE_EVENT`由来の導出キャッシュ）	`enum`	—	—	運航状態軸。UTM内部のライフサイクル管理用
DIPS通報義務	`reportRequired`	`boolean`	`FLIGHT_PLAN_DIPS_ATTRS.report_required`	`bool`	—	—	通報要否はUTM側で判定・保持する属性。
DIPS通報状態	`reportStatus`	`string`(enum `ReportStatus`)	`FLIGHT_PLAN_STATE_EVENT.report_status_after`（最新イベントの値）	`enum`	—	—	`DIPS_REPORT.status`（`enum`: REPORTED/WITHDRAWN）とは別軸。`REPORTING`（通報中）・`WITHDRAWING`（取り下げ中）はいずれもDIPS API呼び出し中のUTM内部一時状態でありDIPS側に対応する値はない
空域制限との競合	`conflict.airspaceRestrictions[]`	`array`	`CONFLICT_DETECTION.airspace_restriction_id` / `.airspace_restriction_type`（`current_revision_id`に紐づく行）	`uuid`/`enum`	—	—	種別コードの変換は「空域制限の種別コードの対応」参照。`status=DRAFT`のときは行が存在せず空配列を返す
飛行計画同士の競合	`conflict.flightPlanIds`	`array`	`coordination.confliction.opponent_flight_plan_id`（`conflict_flag=TRUE` の行（★`is_deleted`は`db/schema/coordination.sql`のDDLにのみ存在し内部APIのスキーマには現れないため、応答生成で参照してよいか運航調整へ確認する）。自組織側は`DIPS_REPORT.dips_receipt_no`で突き合わせる）	`varchar`	—	—	運航調整ドメインが保持する。`reportStatus`が現在の内容に対して`REPORTED`の間のみ値が入り、内容更新時は空配列に戻る
最終更新日時	`updatedAt`（レスポンス。必須）	`string`(date-time)	`FLIGHT_PLAN.updated_at`（`FLIGHT_PLAN_REVISION.changed_at`・`FLIGHT_PLAN_STATE_EVENT.occurred_at`・`FLIGHT_PLAN_DRAFT.updated_at`の最大値の導出キャッシュ）	`timestamp`	—	—	内容変更・状態遷移のいずれでも更新される（一覧の例でも`ACTIVATED`行の`updatedAt`が飛行開始時刻と一致）。`status`と同じく導出値だが、全レスポンスの必須項目であり一覧の全行で必要になるため実体化する
作成日時	`createdAt`（レスポンス。必須）	`string`(date-time)	`FLIGHT_PLAN.created_at`	`timestamp`	—	—	仮登録時に設定し以後変わらない
飛行計画名称	`name`	`string`	`FLIGHT_PLAN_REVISION.name`	`string`	`flightPlanInfo.name`	文字列
飛行開始日時	`flightPeriod.startTime`	`string`(date-time)	`FLIGHT_PLAN_REVISION.planned_start_at`	`timestamp`	`flightPlanInfo.startTime`	日時
所要時間	`flightPeriod.plannedFlightTime`	`integer`	`FLIGHT_PLAN_REVISION.planned_end_at`（`startTime`+`plannedFlightTime`から算出して保持）	`timestamp`	`flightPlanInfo.plannedFlightTime`	数値	所要時間そのものの個別カラムは持たない（DIPS側も「飛行終了日時は所要時間から計算」と明記）。DIPS通報時は`planned_end_at`-`planned_start_at`から所要時間を再計算して送信する

2. DIPS通報固有フィールド

flightPurposesのみ業務ロジックが参照するため個別テーブル（FLIGHT_PLAN_DIPS_PURPOSE）とし、他はDIPSへのパススルー用途のみのためFLIGHT_PLAN_DIPS_ATTRS.dips_report_detail（jsonb）に集約する（departurePoint・destinationPoint・email・flightAirspace・flightTypeは参照経路があるため個別カラム）。flightPurposesは「目的コード＋そのコードに対する補足（note）」の組の配列であるため、1コード1行として保持する。

項目	FlightPlanningService API	API型	データベースカラム	DIPS API	DIPS型
飛行目的	`flightPurposes[].code`	`string`（enum `FlightPurposeCode`）	`FLIGHT_PLAN_DIPS_PURPOSE.code`（1コード1行）	`flightPlanInfo.flightPurpose`	配列（数値） ★FlightPlanningServiceにて型変換する
その他１理由入力	`flightPurposes[].note`（`code=OTHER_BUSINESS`の行）	`string`	`FLIGHT_PLAN_DIPS_PURPOSE.note`	`flightPlanInfo.othergyomutext`	文字列 ★通報時に該当行のnoteから導出する
その他２理由入力	`flightPurposes[].note`（`code=OTHER_NON_BUSINESS`の行）	`string`	`FLIGHT_PLAN_DIPS_PURPOSE.note`	`flightPlanInfo.othergyomugaitext`	文字列 ★通報時に該当行のnoteから導出する
飛行空域	`flightAirspace`	`array<string>`（enum `FlightAirspaceCode`）	`FLIGHT_PLAN_DIPS_ATTRS.flight_airspace`（配列型カラム）	`flightPlanInfo.flightAirspace`	配列（数値） ★FlightPlanningServiceにて型変換する
飛行方法	`flightType`	`array<string>`（enum `FlightTypeCode`）	`FLIGHT_PLAN_DIPS_ATTRS.flight_type`（配列型カラム）	`flightPlanInfo.flightType`	配列（数値） ★FlightPlanningServiceにて型変換する
補助者	`riskMitigation.assistantsNumber`	`integer`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.assistantsNumber`（`jsonb`）	`flightPlanInfo.assistantsNumber`	数値
出発地	`departurePoint`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.departure_point`	`flightPlanInfo.departurePoint`	文字列
航続可能時間	`flightPeriod.plannedMaxTime`	`integer`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.plannedMaxTime`（`jsonb`）	`flightPlanInfo.plannedMaxTime`	数値
飛行速度 ※1	`flightSpec.speed`	`number`(double)	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightSpeed`（`jsonb`）	`flightPlanInfo.flightSpeed`	数値
目的地	`destinationPoint`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.destination_point`	`flightPlanInfo.destinationPoint`	文字列
立入管理措置	`riskMitigation.types`（`ONSITE_CONTROL`を含むか）	`array<string>`（enum `RiskMitigationType`）	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.riskMitigationOnsiteControl`（`jsonb`）	`flightPlanInfo.riskMitigationOnsiteControl`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
立入管理措置(レベル3飛行)	`riskMitigation.types`（`ONSITE_CONTROL_LEVEL3`を含むか）	`array<string>`（enum `RiskMitigationType`）	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.riskMitigationOnsiteControlL3`（`jsonb`）	`flightPlanInfo.riskMitigationOnsiteControlL3`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
立入管理措置(レベル3.5飛行関連)	`riskMitigation.types`（`ONSITE_CONTROL_LEVEL35`を含むか）	`array<string>`（enum `RiskMitigationType`）	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.riskMitigationOnsiteControlL35`（`jsonb`）	`flightPlanInfo.riskMitigationOnsiteControlL35` ★模擬DIPSには項目が無く送信しない（11-3）	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
立入禁止措置	`riskMitigation.types`（`NO_ENTRY_CONTROL`を含むか）	`array<string>`（enum `RiskMitigationType`）	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.riskMitigationOnsiteControl2`（`jsonb`）	`flightPlanInfo.riskMitigationOnsiteControl2`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
係留飛行	`riskMitigation.exceptionalConditionsMooring`	`boolean`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.exceptionalConditionsMooring`（`jsonb`）	`flightPlanInfo.exceptionalConditionsMooring`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
その他特記事項	`otherInformation`	`string`（nullable）	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.otherInformation`（`jsonb`）	`flightPlanInfo.otherInformation`	文字列
メールアドレス（調整連絡先）	`email`	`EmailAddress`	`FLIGHT_PLAN_DIPS_ATTRS.contact_email`	`contactInfo.email` ★模擬DIPSに`contactInfo`が無く、送信先は未確定（11-3）	文字列

(注1) 飛行速度はdips_report_detail（jsonb）に置く一方、DIPSから収集した他社計画では DIPS_FLIGHT_PLAN.flight_speed_kmhとして型付きカラムで保持しており、扱いが非対称である。収集側は GeoSpatialの他Operator計画検索が返す項目のため型付きが必要なのに対し、自組織側は現時点でDIPSへのパススルー以外の参照経路がないためjsonbに留める。ただしOASはFlightSpecを「他USPとの重複調整等でも参照される実質データ」と位置づけているため、運航調整ドメインが自組織側の飛行速度を参照するかは確認が必要であり、参照するならFLIGHT_PLAN_DIPS_ATTRS.flight_speed_kmhとして個別カラム化して収集側と対称にする。

(注) API側は4種の立入管理・禁止措置をriskMitigation.typesという1つの配列項目（RiskMitigationTypeのenum: ONSITE_CONTROL/ONSITE_CONTROL_LEVEL3/ONSITE_CONTROL_LEVEL35/NO_ENTRY_CONTROL）に統合している。DIPS側は個別の"0"/"1"文字列フラグ4つのままのため、riskMitigation.typesに各値が含まれるかどうかを、対応するDIPS個別フラグへ変換する処理が必要（riskMitigation.exceptionalConditionsMooringも同様にAPI側boolean・DIPS側"0"/"1"の型変換が必要）。またflightPurposes[].code/flightAirspace/flightTypeはAPI側・DB側とも文字列enum（FlightPurposeCode/FlightAirspaceCode/FlightTypeCode）で保持する（flightPurposesはコード単位の行、flightAirspaceとflightTypeはenum配列カラム）。DIPS側のみ数値配列であるため、通報時に数値へ変換する処理が必要。

(注) DIPS通報固有の項目は飛行計画本体（FLIGHT_PLAN_REVISION）ではなくFLIGHT_PLAN_DIPS_ATTRS（FLIGHT_PLAN_REVISIONと1:1）に持たせる。日本固有の制度概念を飛行計画本体に混在させないため（flight-plan-er.mdの「DIPS通報固有の属性は飛行計画本体から分離する」参照）。dips_report_detailはその中でインラインのjsonbとし、中身をさらに別テーブルへ正規化はしない。常に同時アクセスされるデータであり、DIPS_FLIGHT_PLAN.raw_payloadと同じインライン格納の前例に倣う。

3. 飛行経路（flyRoute）

flyRouteは判別子type（circle/polygon/route）によるoneOf（FlyRouteCircleInput/FlyRoutePolygonInput/FlyRouteRouteInput）で表現する。 typeごとに標準GeoJSON Geometryのgeometry（circle: Point、polygon: Polygon、route: LineString）と、面積を確定させる付随パラメータ（circle: radiusM必須、route: bufferM必須・最大100m、polygonにはパラメータなし）を持つ（DIPS側のGeoJSON Feature形式・properties.radiusとは構造が異なるため、通報時に変換が必要）。

項目	FlightPlanningService API	API型	データベースカラム	DB型	DIPS API	DIPS型	備考
エリア種別	`flyRoute.type`（`circle`/`polygon`/`route`）	`string`(enum)	`FLIGHT_PLAN_AREA.area_type`（ROUTE/CIRCLE/POLYGON）	`enum`	`flightPlanInfo.flyRoute.type`	文字列	UTM内部（API・DB）の呼び名は`ROUTE`/`CIRCLE`/`POLYGON`に統一する方針。OASの`flyRoute.type`もPR #126で`route`へ改名したため、API境界での読み替えは不要。DIPS通報時はGeoJSONのCircle/Polygonへ変換する（`ROUTE`→Polygon近似等）
ジオメトリ（中心点／構成点）	`flyRoute.geometry`（`type`に応じてPoint/LineString/Polygonのいずれか。`coordinates`に中心点または構成点を持つ）	`object`(GeoJSON Geometry)	`FLIGHT_PLAN_AREA.geometry`（WGS84）	`geometry`(PostGIS)	`flightPlanInfo.flyRoute.center`/`radius`/`coordinates`	radius=数値、coordinates=配列（他は構造体）	DIPSはGeoJSON文字列として送信（`"`のエスケープが必要）
半径／バッファ（円形エリアの半径／経路のバッファ幅）	`flyRoute.radiusM`（`type=circle`時）／`flyRoute.bufferM`（`type=route`時）	`number`(double)	`FLIGHT_PLAN_AREA_CIRCLE.radius_m`（`area_type=CIRCLE`時）／`FLIGHT_PLAN_AREA_ROUTE.buffer_m`（`area_type=ROUTE`時）	`float`	`flightPlanInfo.flyRoute.radius`	数値	`radiusM`は`circle`時必須（上限なし）、`bufferM`は`route`時必須・最大100m（DIPS飛行計画登録の指定可能範囲による上限。未指定は不可で「幅0」は表現できない）、`polygon`では項目自体が存在しない
飛行する最低高度	(対応するAPI項目なし。`FlightSpec`は`altitude`（最高高度）のみを持ち、最低高度の入力フィールドは現行APIに存在しない)	—	`FLIGHT_PLAN_AREA.min_altitude_m_agl`	`float`	(対応なし)	—	DIPSでは高度の競合チェックを行わないことから最高高度のみ管理する。現時点では最低高度は常に０となる。
飛行する最高高度	`flightSpec.altitude`	`number`(double)	`FLIGHT_PLAN_AREA.max_altitude_m_agl`	`float`	`flightPlanInfo.flightAltitude`	数値	DIPS通報時は`flightSpec.altitude`の値を`flightAltitude`として送信する

4. 操縦者・機体情報（pilotInfo）

pilotInfoはPilot/Assetマスタへの参照のみを保持するN:M関係のため、リビジョンに紐づく中間テーブル FLIGHT_PLAN_PILOT_ASSIGNMENT（1行=1操縦者×1機体のペア）で管理する。テーブル定義は flight-plan-er.mdの図1を参照（pilot_idは/api/v1/asset/pilots、aircraft_idは /api/v1/asset/aircraftsのマスタを指す）。

(flight_plan_revision_id, pilot_id, aircraft_id)にUNIQUE制約を付与し、同一組の重複登録を防ぐ。 DIPSのリクエストではaircraftInfoはpilotInfoの入れ子ではなく、flightPlanInfo直下の兄弟の配列である （ガイドラインのリクエストサンプルで両者が同じ階層に現れる）。したがって機体は操縦者に紐づかず、飛行計画単位のフラットな配列として送る。通報リクエストの組み立ては次のとおり。

pilotInfo[] … 当該リビジョンのFLIGHT_PLAN_PILOT_ASSIGNMENTからpilot_idを重複排除して列挙する
flightPlanInfo.aircraftInfo[] … 同じくaircraft_idを重複排除して列挙する（どの操縦者が使うかは送らない）

UTM側は「1操縦者×1機体のペア」で保持するが、DIPSへはこれを2つの独立した集合に射影する。どちらの配列も順序に意味がないため、行の順序（sequence等）を管理する必要はない。

4-1. 参照（FlightPlanningService API ⇔ 中間テーブル）

項目	FlightPlanningService API	API型	データベースカラム	DB型
操縦者ID	`pilotInfo[].pilotId`	`string`(uuid)	`FLIGHT_PLAN_PILOT_ASSIGNMENT.pilot_id`	`uuid`
使用機体ID	`pilotInfo[].aircraftIds`	`array<string(uuid)>`	`FLIGHT_PLAN_PILOT_ASSIGNMENT.aircraft_id`（1行1機体。配列は行の集合で表現）	`uuid`
操縦者氏名	`pilotInfo[].pilotName`	`string`	`PILOT.name`（応答生成時にマスタを解決した現在値。リビジョンには複製しない）	`string`
機体名	`pilotInfo[].aircraftNames`	`array<string>`	`ASSET.model`（型式／名称。`aircraftIds`と同じ順序・同じ件数で返すため両配列とも`aircraft_id`の昇順で組み立てる）	`string`

UTM APIはリクエストではpilotId/aircraftIdsという**マスタ参照（UUID）**のみを受け取る。レスポンス（PilotAssignment）は表示用にpilotName/aircraftNamesを必須で返すため、応答生成時に Pilot/Assetマスタを解決する。マスタが論理削除（PILOT.deleted_at／ASSET.deleted_at）されていても、過去の飛行計画の表示に必要なため解決対象から除外しない。住所・機体諸元などDIPS通報にのみ必要な詳細は通報時に解決する（4-2節）。

4-2. DIPS通報時に解決する詳細項目（Pilot/Assetマスタ）

DIPS APIの項目単位で行を分けた。「FlightPlanningService API」列は該当APIフィールドが存在しないため、解決元のマスタ参照経由であることを示す。PILOT/ASSET/ASSET_UAS_ATTRS/ASSET_UAS_DIPS_ATTRSのER図はflight-plan-er.mdの「Assetドメイン」セクションを参照。

操縦者（contactPilot・技能証明）

項目	FlightPlanningService API	データベースカラム	DB型	DIPS API	DIPS型
氏名	(`pilotId`経由でPilotマスタから解決)	`PILOT.name`	`string`	`pilotInfo[].contactPilot.name`	文字列
国	(同上)	`PILOT.country`（コード。別紙1_1_国コード）	`string`	`pilotInfo[].contactPilot.country`	文字列
都道府県	(同上)	`PILOT.prefectures`（コード。別紙1_2_都道府県コード）	`string`	`pilotInfo[].contactPilot.prefectures`	文字列
住所	(同上)	`PILOT.address`（番地まで含む住所全体）	`string`	`pilotInfo[].contactPilot.municipality`	文字列
電話番号(国コード)	(同上)	`PILOT.telephone_country`	`string`	`pilotInfo[].contactPilot.telephoneCountry`	文字列
電話番号	(同上)	`PILOT.telephone`	`string`	`pilotInfo[].contactPilot.telephone`	文字列
メールアドレス	(同上)	`PILOT.email`	`string`	`pilotInfo[].contactPilot.email`	文字列
技能証明書番号	(同上)	`PILOT.skill_certification_number`	`string`	`pilotInfo[].skillCertificationNumber`	文字列
技能証明（一等）	(同上)	`PILOT.first_class`	`bool`	`pilotInfo[].firstClass`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
技能証明（二等）	(同上)	`PILOT.second_class`	`bool`	`pilotInfo[].secondClass`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する

機体（aircraftInfo）

aircraftInfo[]はflightPlanInfo直下の計画単位のフラットな配列であり、操縦者には紐づかない。通報リクエストの組み立て方は「4. 操縦者・機体情報（pilotInfo）」に記載したとおりで、ここでは各エントリに詰める項目のマスタ解決のみを示す。

ASSET/ASSET_UAS_ATTRSは既存のAssetドメインのエンティティ、ASSET_UAS_DIPS_ATTRSは本設計で追加するテーブル（DIPS通報に必要な項目はflight-plan-er.mdの「Assetドメイン」セクションで追加提案中）。

項目	FlightPlanningService API	データベースカラム	DB型	DIPS API	DIPS型
機体の種類	(`aircraftIds`経由でAssetマスタから解決)	`ASSET_UAS_DIPS_ATTRS.dips_aircraft_type`（コード1-6。既存の`airframe_type`とは別軸）	`string`	`flightPlanInfo.aircraftInfo[].type`	文字列
機体認証書番号	(同上)	`ASSET_UAS_DIPS_ATTRS.certification_number`	`string`	`flightPlanInfo.aircraftInfo[].certificationNum`	文字列
登録記号	(同上)	`ASSET_UAS_DIPS_ATTRS.registration_symbol`	`string`	`flightPlanInfo.aircraftInfo[].symbol`	文字列
型式／名称	(同上)	`ASSET.model`（既存カラムを流用。新規カラムなし）	`string`	`flightPlanInfo.aircraftInfo[].model`	文字列
製造者名	(同上)	`ASSET.manufacturer`（既存カラムを流用。新規カラムなし）	`string`	`flightPlanInfo.aircraftInfo[].maker`	文字列
機体認証(第一種)	(同上)	`ASSET_UAS_DIPS_ATTRS.certification1`	`bool`	`flightPlanInfo.aircraftInfo[].certification1`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
機体認証(第二種)	(同上)	`ASSET_UAS_DIPS_ATTRS.certification2`	`bool`	`flightPlanInfo.aircraftInfo[].certification2`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する
総重量(kg)	(同上)	`ASSET_UAS_ATTRS.max_takeoff_weight_kg`（機体登録時の値をそのまま送信。取得契機は異なるがいずれも飛行時の機体重量を表すため同一の値として扱う）	`float`	`flightPlanInfo.aircraftInfo[].maxWeight`	数値

5. 飛行許可・承認情報（flightPermitApplicationInfo）

dips_report_detail（jsonb）内にflightPermitApplicationInfoとしてネストして格納する（他エンティティを参照しない自己完結データのため）。

項目	FlightPlanningService API	API型	データベースカラム	DIPS API	DIPS型
許可・承認番号	`flightPermitApplicationInfo.flightPermitApplicationNumber`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.flightPermitApplicationNumber`（`jsonb`）	`flightPermitApplicationInfo.flightPermitApplicationNumber`	文字列
許可書発行日	`flightPermitApplicationInfo.permitDate`	`string`(date)	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.permitDate`（`jsonb`）	`flightPermitApplicationInfo.permitDate`	文字列
許可期間（自）	`flightPermitApplicationInfo.startDate`	`string`(date)	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.startDate`（`jsonb`）	`flightPermitApplicationInfo.startDate`	文字列
許可期間（至）	`flightPermitApplicationInfo.finishDate`	`string`(date)	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.finishDate`（`jsonb`）	`flightPermitApplicationInfo.finishDate`	文字列
連絡先（氏名）	`flightPermitApplicationInfo.contactPermit.name`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.name`	文字列
連絡先（国）	`flightPermitApplicationInfo.contactPermit.country`	`CountryCode`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.country`	文字列（3桁）
連絡先（都道府県）	`flightPermitApplicationInfo.contactPermit.prefectures`	`PrefectureCode`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.prefectures`	文字列（2桁）
連絡先（住所）	`flightPermitApplicationInfo.contactPermit.address`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.municipality` ★API側は`address`だがDIPSは`municipality`。読み替えが必要	文字列
連絡先（電話番号(国コード)）	`flightPermitApplicationInfo.contactPermit.telephoneCountry`	`CountryCode`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.telephoneCountry`	文字列（3桁）
連絡先（電話番号）	`flightPermitApplicationInfo.contactPermit.telephone`	`PhoneNumber`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.telephone`	文字列
連絡先（メールアドレス）	`flightPermitApplicationInfo.contactPermit.email`	`EmailAddress`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.flightPermitApplicationInfo.contactPermit.*`（`jsonb`）	`contactPermit.email`	文字列

フィールド名はAPI・DIPS間でおおむね1:1（DIPSの命名がそのままAPIに踏襲されている）。ただし連絡先の住所だけはAPI側でmunicipalityからaddressへ改名済み（x-ix-changesに記載）のため、DIPS通報時にcontactPermit.municipalityへ読み替える必要がある。日付項目（permitDate/startDate/finishDate）はAPI側はCalendarDate（format: dateのYYYY-MM-DD）で、DIPS通報時に区切り文字を除いたYYYYMMDDへ変換する。あわせてpermitDate <= startDate <= finishDate、およびflightPeriod.startTimeをJST暦日に変換した値が許可・承認期間内にあることをビジネスルールとして検証する。

DIPS側の実際の許可・承認申請情報の取得は10月デモのスコープ外とする（DIPSに参照APIがなく、Operatorの入力値をそのまま通報にパススルーする）。したがって、許可・承認申請に含まれる機体と飛行計画に紐づく機体（pilotInfo）の整合チェックは実施しない。上記の日付・期間の検証は、いずれも入力値内およびflightPeriodとの突き合わせのみで完結するため本方針の影響を受けない。

6. 保険情報（insuranceInformation）

dips_report_detail（jsonb）内にinsuranceInformationとしてネストして格納する。

項目	FlightPlanningService API	API型	データベースカラム	DIPS API	DIPS型
保険会社名	`insuranceInformation.insuranceCompany`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.insuranceInformation.insuranceCompany`（`jsonb`）	`flightPlanInfo.insuranceInformation.insuranceCompany`	文字列
商品名	`insuranceInformation.insuranceProduct`	`string`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.insuranceInformation.insuranceProduct`（`jsonb`）	`flightPlanInfo.insuranceInformation.insuranceProduct`	文字列
補償金額（対人）	`insuranceInformation.interPerson`（`CompensationAmount`: `unlimited`/`amount`）	`object`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.insuranceInformation.interPerson`（`jsonb`）	`flightPlanInfo.insuranceInformation.interPerson`	数値（無制限は`-1`） ★FlightPlanningServiceにて型変換する
補償金額（対物）	`insuranceInformation.interObject`（`CompensationAmount`: `unlimited`/`amount`）	`object`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.insuranceInformation.interObject`（`jsonb`）	`flightPlanInfo.insuranceInformation.interObject`	数値（無制限は`-1`） ★FlightPlanningServiceにて型変換する
賠償能力	`insuranceInformation.insuranceAbility`	`boolean`	`FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.insuranceInformation.insuranceAbility`（`jsonb`）	`flightPlanInfo.insuranceInformation.insuranceAbility`	文字列（“0”/“1”） ★FlightPlanningServiceにて型変換する

(注) API側はinterPerson/interObjectを「無制限かどうか」（unlimited: boolean）と「金額」（amount: integer）を持つCompensationAmountオブジェクトとして表現する（未入力・無制限・実額の3状態を1つの整数と-1のようなマジックナンバーに詰め込むことを避けるため）。DIPS側は無制限を-1とする単一の数値のままのため、送信時はunlimited=trueなら-1、それ以外ならamountの値に変換する処理が必要（insuranceAbilityも同様にAPI側boolean・DIPS側"0"/"1"の型変換が必要）。

7. DIPS固有の制御フィールド（UTM APIには存在しない）

項目	DIPS API	DIPS型	値	対応するUTM側の操作
実行モード	`mode`	文字列	`"0"`: 登録	`reportFlightPlan`（初回通報）
実行モード	`mode`	文字列	`"1"`: 更新	`reportFlightPlan`（`REPORTED`状態からの再通報）
実行モード	`mode`	文字列	`"2"`: 削除	`cancelFlightPlan`で`CANCELLED`にした際のDIPS側削除、および`deleteFlightPlan`で通報済みの飛行計画を削除する際のDIPS側削除（いずれも`reportStatus`→`WITHDRAWN`遷移）

modeはDIPS API呼び出し時にFlightPlanningServiceが状況に応じて設定する制御値であり、UTM側のAPI・DBには対応するフィールドを持たない。

[!IMPORTANT] 本節は模擬DIPSには適用しない。 模擬DIPSにmodeは無く、登録・更新はflightPlanIdの有無で切り替わり、削除は存在しない（11-1）。以下のmodeごとの要求項目のうち、「更新は全項目の再送が必要」という結論は模擬DIPSでも変わらない。

modeごとに要求される項目は次のとおり（出典は「別紙2_入力チェック一覧」の4_飛行計画情報登録・更新API_更新・ 5_飛行計画情報登録・更新API_削除）。

mode=1（更新）は全項目の再送が必要: 更新シートの入力チェックは新規登録シートと同一の内容に、「飛行計画IDは必須」「飛行計画IDがDIPSに登録済かつ自身の管理する飛行計画であること」の2件を加えたものであり、mode=0で必須の項目はすべてmode=1でも必須である。差分更新ではなく全置換であるため、再通報時は FLIGHT_PLAN_DIPS_ATTRS・FLIGHT_PLAN_DIPS_PURPOSE・FLIGHT_PLAN_REVISION・FLIGHT_PLAN_AREA・ Pilot/Assetマスタから通報リクエストを毎回すべて組み立て直す。dips_report_detail（jsonb）が常に全項目を保持している必要があるのはこのためである。
mode=2（削除）は飛行計画IDのみでよい: 削除シートの入力チェックは4件（実行モードの値域、飛行計画情報の必須、飛行計画IDがDIPSに登録済かつ自身の管理する飛行計画、実行モードが1または2なら飛行計画IDは必須）だけで、飛行内容の項目は要求されない。
mode=1・mode=2で指定する飛行計画IDはDIPS側の受付番号: DIPS_REPORT.dips_receipt_noの最新行の値を用いる。UTMが発行するFLIGHT_PLAN.id（UUID）ではない。

8. DIPS側の入力チェックとAPI制約の対応

DIPSの飛行計画情報登録・更新APIには項目ごとの必須・桁数・値域のチェックがあり（出典は「別紙2_入力チェック一覧」の3_飛行計画情報登録・更新API_新規登録）、UTM側の制約がこれより緩いと通報時にDIPSで弾かれる。桁数・値域の現在値は本節を単一の正とする（他の節・他ドキュメントは本節を参照し、値を再掲しない）。UTM側で先に検証し、通報前に422を返す。

「UTM側の制約」はPR #126で是正した後の値である。

項目	DIPS側の制約（別紙2 ID）	UTM側の制約	状態
`name`（飛行計画名称）	30文字以内（ID23）	`maxLength: 30`	一致
`flightPurposes[].note`（その他１・その他２の理由入力）	120文字以内（ID29・ID31）	`maxLength: 120`	一致
`otherInformation`（その他特記事項）	300文字以内（ID7）	`maxLength: 300`	一致
`departurePoint`（出発地）	120文字以内（ID34）	`maxLength: 120`	一致
`destinationPoint`（目的地）	120文字以内（ID72）	`maxLength: 120`	一致
`flightSpec.speed`（飛行速度）	整数（ID48）。範囲は出典間で不一致（下記）	`integer`、1〜100	整数は一致。範囲は出典間の不一致が未解消（下記）
`flightSpec.altitude`（飛行する高度）	1〜999の整数（ID51・ID52）。範囲は出典間で不一致（下記）	`integer`、1〜999	整数は一致。範囲は出典間の不一致が未解消（下記）
`insuranceInformation.insuranceCompany`（保険会社名）	60文字以内（ID84）	`maxLength: 60`	一致
`insuranceInformation.insuranceProduct`（商品名）	60文字以内（ID86）	`maxLength: 60`	一致
`CompensationAmount.amount`（補償金額対人・対物）	11桁以下（ID89・ID92）	`integer`(int64)、`0`〜`99999999999`	一致（11桁は`int`に収まらないため`format: int64`）
`FlightPermitContact.name`（許可・承認連絡先の氏名）	120文字以内（ID10）	`maxLength: 120`	一致
`PilotAssignment.pilotName`（操縦者氏名の表示用解決値。`pilotInfo[].contactPilot.name`に対応）	120文字以内（ID100。相関チェック：実行モードが登録・更新の場合）	`maxLength: 120`	一致
`PilotAssignment.aircraftNames`（機体名の表示用解決値。`flightPlanInfo.aircraftInfo[].model`に対応）	100文字以内（ID126。相関チェック：実行モードが登録・更新の場合）	`maxLength: 100`	一致
`flyRoute`のPolygon構成点（`GeoJsonPolygon`のLinearRing）	3点以上36点以下（ID68）	`minItems: 3` / `maxItems: 36`	一致
`flyRoute`の経路構成点（`GeoJsonLineString`の`coordinates`）	Polygon変換後に36点以内に収まる必要がある	`minItems: 2` / `maxItems: 16`	一致（`2N+4`点となるため`N≦16`。詳細は下記）
`flightPeriod.startTime`（飛行開始日時）	API実行日の1日前まで（ID39）、かつAPI実行日から1年以内（ID37・ID38）。暦日単位（下記★参照）	descriptionに明記（JSON Schemaでは表現できないためビジネスルールとして検証）	一致

speed・altitudeの整数制約: DIPSは整数値を要求する一方、APIはnumber(double)だった。通報時に丸めが必要になり、丸め方向の規約がないと通報値がOperatorの入力値と食い違うため、UTM側をintegerに制約した。
★飛行速度の範囲は出典間で食い違っている: ガイドライン項番15は「単位: km/h 1〜100」、別紙2 ID49は「1〜999の範囲の値」で一致しない。UTM側はガイドライン本文と一致しているため、上限は緩めず100のままとした（緩めた結果DIPSに弾かれる方が損害が大きい）。是正したのは整数化のみで、どちらが正かはDIPSへの照会事項として未解消である。
★飛行する高度の範囲も出典間で食い違っている: DIPS APIガイドラインの項番16・別紙2 ID51・ID52は「1〜999」だが、「ReAMo 模擬DIPSインタフェース仕様」05 飛行計画通報APIの項番17（写しは flightplan-spec.mdの項番17）は「1〜400」である。通報先は模擬DIPSであるため、実装は狭い方（400）を採る（DipsFlightAltitudeMeters。緩めた結果 DIPSに弾かれる方が損害が大きいというspeedと同じ判断）。API側は1〜999のままであり、401以上の飛行計画は登録できるが通報時に弾かれる。 どちらが正かはDIPSへの照会事項として未解消で、 followups.mdに登録済み。
★飛行開始日時の「1日前」は暦日単位である: 別紙2 ID39は対象項目「飛行開始日時」、チェック内容「飛行開始日時がAPI実行日の1日前まで」、違反時メッセージ「飛行計画の登録・更新でエラーが発生しました。：予定開始時間が2日以前です。」である。メッセージが「2日以前」を境界としているため、時刻単位（実行時刻の 24時間前）ではなく暦日単位と判断できる。判定はJST（UTC+9）の暦日で行う（DIPS通報時にJST暦日へ変換するため。別紙2に基準タイムゾーンの記載はなく、これは設計判断である）。なお旧版は「1日前まで」と「1年以内」の両方をID37・ID38に帰していたが、「1日前まで」の出典はID39である。同メッセージは「登録・更新」の両方に言及している。ただしこれはAPI名（飛行計画情報登録・更新API）の定型接頭辞であり、これだけでは更新時のチェックの根拠にならない。根拠は§7の「mode=1（更新）は全項目の再送が必要」で、更新シートの入力チェックが新規登録シートと同一の内容である旨を直接示している。したがってUTM側も登録・更新のいずれでも検証する。更新時のガードを緩めてUTM側に保存できるようにしても、その計画は通報時にDIPSへ弾かれるため緩める意味がない。画面は日時を変更していなくてもflightPeriodを送るため、開始日時が範囲から外れた飛行計画は他の項目だけを直す更新も422になる。この場合は開始日時もあわせて範囲内へ直す必要がある。
Polygonの36点上限が最も影響が大きかった: 是正前のGeoJsonPolygonの上限は1000点で、descriptionにも「妥当性検証・競合判定の計算コストを抑えるための技術的な暫定値であり、業務要件に基づく値ではない」と記載されていた。DIPSの36点が業務要件側の上限にあたるため、これに合わせた。GeoJSONのLinearRingは終点に始点と同じ座標を含む一方、DIPSは終点を自動付与する仕様（ガイドライン項番11）であるため、 OASはFlyRoutePolygonInput.geometryのdescriptionで「終点は始点と同座標を自動付与するため、頂点として重複指定する必要はない」と定め、minItems: 3もこれと整合するため、 GeoJsonPolygonの配列長はDIPSの36点とそのまま同値になる。あわせてROUTE（バッファ付き経路）をDIPSへ通報する際はPolygonへ変換する必要があるが、バッファ適用後のポリゴンは容易に36点を超える。経路の形状を保ったまま36点以内に収める変換が必要であり、単純な ST_Bufferの結果をそのまま送ることはできない。変換方式はflight-plan-er.mdの「飛行領域の呼び名はUTM内部でROUTEに統一する」に記載する。
PilotAssignment.pilotName/aircraftNamesは他の行と異なり、Operatorが直接入力する項目ではない（PILOT.name/ASSET.modelをマスタ解決した現在値）。そのため、DIPSの制約（ID100・ID126）を満たすにはPILOT.name/ASSET.model自体の値もこの桁数に収まっている必要があるが、両カラムはVARCHAR(255)（db/schema/asset.sql）でこれより緩い。forDemoでは機体・操縦者のCRUD APIを提供せず値は固定シードのみのため実害はないが、CRUD実装時はカラムの桁数制約もこれに合わせて狭める必要がある（followups.mdに登録済み）。
一致を確認した項目: flightPeriod.plannedFlightTime・plannedMaxTime（5の倍数・5以上1440以下、 ID41〜46）、flyRoute.radiusM（0より大きい、ID62）、riskMitigationの4種の措置と係留飛行（"0"/"1"、 ID73〜82）はOAS側と一致している。email（ID161〜163）も、domain.yamlの EmailAddressがmaxLength: 254とHTML5/WHATWG相当のpatternを持ち、飛行計画APIの各emailがこれを$refしているため充足している。
コード値域の一致を確認した項目: FlightPurposeCode（16値）・FlightAirspaceCode（3値）・ FlightTypeCode（6値）は「別紙1_コード一覧」の3_飛行目的コード・4_飛行空域コード・5_飛行方法コードと順序・内容ともに一致している。別紙1の「指定なし」（飛行空域・飛行方法の最終行）はコード値ではなく「当該空域・方法での飛行を行わない」ことを表すため、API側では空配列で表現する。

項目間の条件付き必須

DIPSは項目単体の制約に加えて、項目間の相関による必須指定を持つ。UTM側で先に検証しないと通報時に弾かれる。

条件	必須になる項目	出典	OAS側の現状
許可・承認情報の指定がある	保険に関する情報	ID142・ID155	`insuranceInformation`は`flightPermitApplicationInfo`と無関係な任意項目
技能証明（一等）または（二等）が「あり」	技能証明書番号	ID120	`PILOT`側に相関の記載なし
機体認証（第一種）または（第二種）が「あり」	機体認証書番号	ID56（ガイドライン項番56）	`ASSET_UAS_DIPS_ATTRS`側に相関の記載なし
カテゴリ判定の結果が「ⅡA」「Ⅲ」かつ許可承認情報がnullでない	連絡先（氏名・国・都道府県・住所・電話番号・メールアドレス）、許可・承認番号、許可書発行日、許可期間（自）（至）	ID143〜154	カテゴリ判定の設計が本設計・OASのいずれにも存在しない。10月デモでは判定を実施しないと決定済み（下記★参照）

上3件はビジネスルール検証（違反時422）として実装する。
カテゴリ判定は10月デモのスコープ外とする（決定済み）: カテゴリ（Ⅰ／Ⅱ／ⅡA／Ⅲ）の判定ロジックが UTM側に存在せず、10月デモでは判定を実施しない。許可・承認の要否判断も同様である。判定を実装するか、許可・承認情報が入力された場合は常に連絡先一式を必須として扱うかは、以降のリリースで決める。

是正の経緯

是正はOAS側の制約を厳しくする修正であり、Operatorの入力可能範囲が狭まるだけで機能の増減はない。 14項目をPR #126でまとめて反映した。
未解消はspeedの範囲のみ（出典間の不一致。上記参照）。DIPSへの照会結果によっては上限を見直す。
Polygonの36点上限は変換方式の設計を伴うため、データモデル側で先に方針を定めた（flight-plan-er.mdの「飛行領域の呼び名はUTM内部でROUTEに統一する」）。

9. 空域制限の種別

空域制限の種別は、GeoSpatial（AirspaceRestrictionProperties.category）と飛行計画API （AirspaceRestrictionConflict.airspaceRestrictionType）が同じ列挙値 AirspaceRestrictionTypeを返す。定義はdocs/openapi/domain.yamlにあり、両OASが$refする。 CONFLICT_DETECTION.airspace_restriction_typeが格納するのも同じ値であるため、ドメイン間での変換は不要である。

値の一覧と意味はdocs/openapi/domain.yamlのAirspaceRestrictionTypeを参照する。

10. 機体IDの対応

機体を指すIDがAPI間で複数の名前で現れる。すべてがASSET.idに対応するわけではない点に注意する。

API上の名前	定義箇所	対応
`pilotInfo[].aircraftIds`	flight-planning.yaml（`AircraftId`）	`ASSET.id`（`kind=UAS`）。`FLIGHT_PLAN_PILOT_ASSIGNMENT.aircraft_id`が参照する
`FlightPlanAreaProperties.uasId`	geospatial.yaml（uuid。「使用UASのアセットID」）	同上
`uasEntityIds` / `TelemetryPositionProperties.uasEntityId`	geospatial.yaml（uuid。「UTM側で発行するUASエンティティのID」）	自組織機は`ASSET.id`と一致（telemetry-er.mdの`TELEMETRY.aircraft_id`で決定済み）。他Operator機は未決定（Issue #135）
`TelemetryTrackProperties.uasId` / `TelemetryPositionProperties.uasId`	geospatial.yaml（string。例`JU00012345`）	別種のID。Remote ID由来（`uasRegistrationId`/`uasSerialNumber`/`uasUtmId`/`uasSpecificSessionId`の優先順で採用）。受信した生値をそのまま返し、いずれの識別子が入っているかは値からは判別しない（telemetry-er.mdの`TELEMETRY.reported_uas_id`）。かつて本表は`ASSET_UAS_DIPS_ATTRS.registration_symbol`（登録記号）へ解決する設計としていたが、取り込み実装（`telemetry-service-proto`）が解決を行っていないことが判明したため訂正した

★uasEntityId の出所: searchFlyingDronePositionsは「飛行中の全ドローン（自組織・他Operatorを問わず）」を返す仕様で、TelemetryPositionPropertiesはuasEntityIdを必須としている。他Operatorの機体は自UTMのASSETとして存在しないため、uasEntityIdをASSET.idとすると他Operator機で値を作れない。自組織機についてはASSET.idと一致することを決定済み（telemetry-er.md）。他Operator機に対して何を返すのか（テレメトリ受信時にUTM側で採番する追跡エンティティのIDなのか等）はIssue #135で扱う。
同名のuasIdが2種類ある: FlightPlanAreaProperties.uasId（uuid）とテレメトリのuasId（string）は別物である。名前を揃える是正を行う場合、この衝突を踏まえる必要がある。

11. 模擬DIPS（10月デモ）への通報

1〜10節の「DIPS API」列は「DIPS2.0 API（FPR）Guideline USP v1.0」を出典としている（概要参照）。 10月デモで実際に通報するのは模擬DIPSの「飛行計画通報API（項番5）」であり、送信構造が一部異なる。 10月デモの実装は本節を正とする（1〜10節と食い違う項目は本節が優先する）。

出典は「ReAMo 模擬DIPSインタフェース仕様」（NTTデータ提供）の インタフェース定義/05_飛行計画通報API_20250130.xlsxと模擬DIPS実機の実行結果である。リポジトリ内の写しは項番つきの書き起こしflightplan-spec.mdと、 Prismモック定義flightplan.yamlで、送信するJSONの実体はsrc/main/java/com/intent_exchange/utm/infrastructure/client/dips/dto/のDTO群にある。

11-1. 登録と更新の切り替え

模擬DIPSに実行モード（mode）は無い。登録・更新は同一エンドポイントで、flightPlanInfo.flightPlanIdを null（新規登録）とするか受付番号を設定する（更新）かで切り替わる。削除は存在しない。 したがって7節のmodeの表は模擬DIPSには適用しない。更新時に全項目の再送が必要である点（同節）は模擬DIPSでも変わらない。

UTM側の操作	`flightPlanId`	模擬DIPS側の扱い
`reportFlightPlan`（初回通報）	`null`	新規登録
`reportFlightPlan`（`UNREPORTED`へ戻った計画の再通報）	`DIPS_REPORT.dips_receipt_no`（最新行）	更新
DIPS側の削除	—	手段なし（10月デモでは取り下げに対応しない）

11-2. 模擬DIPSにのみ存在する項目

DIPS2.0側に対応がなく、1〜10節の表に行を持たない項目。

項目	模擬DIPS	必須	UTM側の解決元
USS ID	`flightPlanInfo.ussId`	必須	設定値`dips.api.uss-id`（`DipsApiProperties.ussId`）。パスの`{USSID}`と同じ値を設定する
調整先URI	`flightPlanInfo.uriForCoordination`	必須	`coordination.uss_default_info.utm_endpoint_url`（自USSの行）。重複相手が本UTMへ調整を開始する宛先
ウェイポイント	`flightPlanInfo.waypoint[]`（経度・緯度・高度・時刻・速度）	任意	対応するデータを持たない。10月デモでは値を送らない（キー自体を省略する）。`ReportFlightPlanInfo.waypoint`は`@JsonInclude(NON_EMPTY)`で空リストならキーごと出力しない（`open-questions.md` D-17）。模擬DIPSは`waypoint`キーが存在すると「2件以上」のバリデーションを課すため、空配列`[]`のまま送ると`400`で弾かれることが実機で確認されている。模擬DIPSは`waypoint`があればそれを、無ければ`flyRoute`を重複判定に使う
技能認証保有状況	`pilotInfo[].privateLicense`	必須	固定値`"0"`を送る（`PILOT`に対応カラムがなく、`first_class`/`second_class`とは別軸のため。10月デモでの決定）
操縦者の代表機体（製造者名）	`pilotInfo[].maker`	必須	当該操縦者に割り当てた機体のうち代表1機の`ASSET.manufacturer`
操縦者の代表機体（型式／名称）	`pilotInfo[].model`	必須	同上の`ASSET.model`

11-3. DIPS2.0側にあって模擬DIPSに無い項目

項目	1〜10節の記載	模擬DIPSでの扱い
実行モード	`flightPlanInfo.mode`（7節）	項目自体が無い（11-1のとおり）
立入管理措置（レベル3.5飛行関連）	`flightPlanInfo.riskMitigationOnsiteControlL35`（2節）	送信先が無い。 `FLIGHT_PLAN_DIPS_ATTRS.dips_report_detail.riskMitigationOnsiteControlL35`には保持したまま、通報リクエストには含めない
メールアドレス（調整連絡先）	`contactInfo.email`（2節）	`contactInfo`という項目が模擬DIPSに無い。個人の連絡先は`reporter.contactReporter`・`pilotInfo[].contactPilot`・`flightPermitApplicationInfo.contactPermit`の3つだけで、いずれか1つの連絡先フラグを`"1"`にする仕様（下記「未確定事項」）

11-4. 綴り・型・書式の差異

実装で取り違えやすい箇所。値はすべて模擬DIPS側を正とする。

項目	1〜10節・DIPS2.0	模擬DIPS	出典
機体認証書番号	`aircraftInfo[].certificationNum`	`aircraftInfo[].certificationlNum`（`certification`＋小文字のL＋`Num`）	仕様書・サンプルとも一致（flightplan-spec.md項番63）
保険会社名	`InsuranceCompany`	`insuranceCompany`（先頭小文字）	サンプルJSON
住所	`ｍunicipality`（全角m）	`municipality`（半角m）	実測・サンプル
通報者の連絡先フラグ	文字列`"0"`/`"1"`	実測は数値`1`（`contactPilotFlag`は文字列のまま。型が揃っていない）	実測・サンプル
日時	—	`yyyyMMdd HHmm`（例`"20260827 1300"`）。ただし許可・承認の日付3項目だけは`yyyy/MM/dd`	実測・サンプル

11-5. 通報者（`reporter`）は設定値で送る

模擬DIPSはreporter.contactReporter（氏名・国・都道府県・住所・電話番号・メールアドレス）を必須とするが、 UTM側にこれを保持するマスタが無い（asset.pilotは操縦者であって通報者ではなく、 FLIGHT_PLAN_DIPS_ATTRS.contact_emailはメールアドレスしか持たない）。

10月デモはIX-UTM共通のクライアント証明書で通報するため、DIPS上の通報者は全Operatorで同一になる（UC-DIPS-03の補足）。そこで通報者はIX-UTM共通の固定値とし、設定値（dips.api.reporter.*）として持たせる。飛行計画ごとに変わる値ではないため、DBのカラムは追加しない。

値は個人情報を含むため設定ファイルに直書きせず、環境変数で注入する
既定値は組み込まない（接続先と同じく明示的な設定を必須とする）
contactReporterFlagは"1"（通報者を連絡先とする）。模擬DIPSは通報者・操縦者・許可承認情報のいずれか 1つの連絡先フラグが"1"であることを要求するため、通報者側を立てて他は"0"にする
α版以降にOperator個別の認証（UC-DIPS-02）へ戻す際は、通報者をOperatorごとに解決する仕組みが要る

11-6. 未確定事項

いずれもfollowups.mdの台帳に登録する。

タイムゾーン: 日時項目にタイムゾーンの記載が無く、JSTと推測されるが未確認（flightplan-spec.md「未確定事項」）。
重複時の登録可否: 仕様書は「重複と判定された場合は登録失敗」とするが、実測ではHTTP 200・ flightPlanRegistrationResult:"1"で登録が成功している（同上）。