AI に航空機の整備管理コンソールを作らせてみた — 鉄道で結晶化した床が、そのまま航空に効いた（やってみた #130）

やってみたシリーズ: 自作のデザインシステム @gunjo/ui（群青）を、文脈ゼロの cold な AI に実 UI で作らせる連載。航空 toB の床埋め（#113 OCC 以来2枚目）——機体整備管理／MRO コンソール（保有機材・整備周期・ドック割当・要対応・整備確認）。鉄道 車両検査#108 の、ちょうど航空版。

なぜこの回？ — 「toB は終わった？」の答え合わせ

前回、KeEem に「鉄道と航空の toB は終わった？」と聞かれて台帳を数えたら——鉄道 toB は3枚（運行/乗務員/車両）で床達成、だが航空 toB は #113 の1枚だけだった。toC で gap が噴き出して深掘りした分、航空 toB が薄いまま残っていた。だから床まで埋める。そして同時に試したいことがあった：14業種＋鉄道で結晶化した「保守 toB 床」（資産テーブル／消費vs限度メーター／時間軸スケジュール／要対応キュー／署名記録）は、航空 MRO にそのまま効くのか？

結果 — 4.5/5、構造的手組みゼロ

tsc 緑・デスクトップ密度。cold AI（群青を一度も触っていない設定）：

業務コンソールとして、明確に「このために作られている」。 必要な back-office アーキタイプは全部 first-class な部品があった。zero-friction：ActionQueue・SignedRecord・Meter・Gantt・ScheduleGrid・ActionDataTable・StatGroup。何ひとつ手組みを強いられなかった。むしろマーケ用途より業務コンソール向けに完成している。

越境の地力テスト — 鉄道#108 の床が、航空MROに横展開

鉄道 車両検査#108 で効いた床が、機番も型式も整備規程も違う航空 MRO でそのまま：

• 整備周期の残り → Meter（higher-is-worse が既定＝「限度に近づく/超過＝destructive」が配線不要・size="inline" はテーブルセル用・cold AI「due indicator のために作られた標準部品」）。鉄道の「走行キロ vs 限度」#108 がそのまま「FH/FC vs 整備限度」に。
• ドック割当 → Gantt（docstring が文字通り「整備窓 / a maintenance window」を例示）＋ScheduleGrid（格納庫×7日の占有マトリクスが無料の第2ビュー）。
• 要対応（AD/SB期限・MEL是正・限度超過接近） → ActionQueue（severity 自動ソート＋アイコン＋色のみに非依存）。
• 整備確認（確認主任者の署名） → SignedRecord（draft→signed でロック・追記チェーン・cold AI「最難関項目が最も完成していた」）。
• 保有機材一覧 → ActionDataTable（ジェネリック・行選択 data-state・行ごとに Meter/操作）。

cold AI 結論：「消費者キットを無理にダッシュボードに伸ばした感じが全くない。資産テーブル・消費vs限度メーター・リソース×時間軸スケジュール・トリアージキュー・署名記録が、それぞれ named で finished な部品。」

今回 src build なし（4.5/5・toB床がそのまま効く＝床の成熟の証明）。

拾った小さな gap（起票）

• 🟡 Meter の announced-value 同期：formatValue は見た目だけ変え、読み上げ値は value/max のまま（valueText も要る）＝#381。
• 🟡 InspectorPanel の固定 w-[320px] h-[420px] 既定：グリッド埋め込みで override が要る＝#381。
• 🟠 asset status-row primitive（ActionDataTable と ListCard の中間＝行＝ステータス＋key/value＋末尾Meter＋操作）＝#381（1/3）。
• ✅ 索引是正 #382：「status 付き一覧」がモバイルの ListCard に誘導していた→デスクトップ密度の機材/資産グリッドは DataTable/ActionDataTable と明記。

学び — 「toB床は、もう新しい業種では揺らがない」

14業種の back-office で結晶化した toB床は、鉄道 toB を経て、航空 MRO という全く別の専門領域でも構造的手組みゼロで立った。これは toC 深掘りと真逆の景色：toC は深掘りるほど gap が噴き出して11部品を結晶化させた。toB は逆に、もう新しい業種を当てても揺らがない＝成熟しきっている。 「toB は終わった？」への本当の答えは——枚数の問題ではなく、床の成熟の問題。航空 toB は枚数こそ薄かったが、当ててみれば床は完璧に効いた。あと1枚（乗員スケジュール）で航空 toB も安心の床に。

📊 結晶化スコアボード（build 済 11個）

AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub 進行中：CheckboxCard・StatusScreen success・StatusLevel・asset-row・BottomActionBar

📋 toB/toC 進捗

• ✈️ 航空：toC 全6枚 ✅／toB 2枚（OCC#113・MRO#130）＝あと乗員スケジュールで床
• 🚆 鉄道：toC 全6枚 ✅／toB 3枚（運行/乗務員/車両）＝床達成

次回予告（やってみた #131）

• 航空 toB 乗員スケジュール（パイロット/CA 乗務割・FTL 飛行時間制限・資格管理）＝鉄道 乗務員#107 の航空版で航空 toB を床に。その後 鉄道 toB を厚く（駅務/ダイヤ作成）→ バスへ。

試す

• gunjo.jp ／ メーター Meter ／ ガント Gantt ／ 署名記録 SignedRecord ／ npm @gunjo/ui ／ GitHub ／ 前回まで #1〜#129
• GunjoUI by UIXHERO

鉄道で結晶化した保守の床が、機番も整備規程も違う航空 MRO にそのまま効いた——toB は枚数ではなく、床の成熟で「終わる」。

---

<!-- 公開前: 相互URL差込／スクショ確定／EN(dev.to)ミラー -->