AI に航空機の整備管理コンソールを作らせてみた — 鉄道で固めた土台が、そのまま航空に効いた（やってみた #130）
/aircraft-maintenance375px のビューポートで撮影。縦長のページはフレーム内をスクロールします。
解説記事
AI に航空機の整備管理コンソールを作らせてみた — 鉄道で固めた土台が、そのまま航空に効いた（やってみた #130）
やってみたシリーズ: 自作のデザインシステム
@gunjo/ui（群青）を、群青のことを一度も見たことのない AI に、実際の画面で組ませていく連載。航空の事業者向けの土台埋め（#113 OCC 以来2枚目）——機体整備管理／MRO コンソール（保有機材・整備周期・ドック割当・要対応・整備確認）。鉄道 車両検査#108 の、ちょうど航空版。
なぜこの回？ — 「事業者向けの画面は終わった？」の答え合わせ
前回、「鉄道と航空の事業者向けの画面は終わった？」と台帳を数え直したら——鉄道の事業者向けは3枚（運行/乗務員/車両）で土台達成、だが航空の事業者向けは #113 の1枚だけだった。利用者向けで欠落が噴き出して深掘りした分、航空の事業者向けが薄いまま残っていた。だから土台まで埋める。そして同時に試したいことがあった：14業種＋鉄道で固めた「保守の事業者向けの土台」（資産テーブル／消費vs限度メーター／時間軸スケジュール／要対応キュー／署名記録）は、航空 MRO にそのまま効くのか？
結果 — 4.5/5、構造的手組みゼロ
tsc 緑・デスクトップ密度。予備知識ゼロの AI（群青を一度も触っていない設定）：
業務コンソールとして、明確に「このために作られている」。 必要な事務方のパターンは全部、専用のコンポーネントがあった。摩擦ゼロ：ActionQueue・SignedRecord・Meter・Gantt・ScheduleGrid・ActionDataTable・StatGroup。何ひとつ手組みを強いられなかった。むしろマーケティング用途より業務コンソール向けに完成している。
業界を越える地力テスト — 鉄道#108 の土台が、航空MROに横展開
鉄道 車両検査#108 で効いた土台が、機番も型式も整備規程も違う航空 MRO でそのまま：
- 整備周期の残り →
Meter（higher-is-worseが既定＝「限度に近づく/超過＝destructive」が配線不要・size="inline"はテーブルセル用・予備知識ゼロの AI「期限インジケーターのために作られた標準コンポーネント」）。鉄道の「走行キロ vs 限度」#108 がそのまま「FH/FC vs 整備限度」に。 - ドック割当 →
Gantt（docstring が文字通り「整備窓（a maintenance window）」を例示）＋ScheduleGrid（格納庫×7日の占有マトリクスがタダの第2ビュー）。 - 要対応（AD/SB期限・MEL是正・限度超過接近） →
ActionQueue（深刻度で自動ソート＋アイコン＋色のみに依存しない）。 - 整備確認（確認主任者の署名） →
SignedRecord（下書き→署名 でロック・追記の連なり・予備知識ゼロの AI「最難関の項目が最も完成していた」）。 - 保有機材一覧 →
ActionDataTable（汎用・行選択 data-state・行ごとに Meter/操作）。
予備知識ゼロの AI の結論：「消費者向けのライブラリを無理にダッシュボードに伸ばした感じが全くない。資産テーブル・消費vs限度メーター・リソース×時間軸スケジュール・選別キュー・署名記録が、それぞれ名前があって完成したコンポーネント。」
今回 src の新規コンポーネントなし（4.5/5・事業者向けの土台がそのまま効く＝土台の成熟の証明）。
拾った小さな欠落（課題に記録）
- 🟡 Meter の読み上げ値の同期：
formatValueは見た目だけ変え、読み上げの値は value/max のまま（valueTextも要る）＝#381。 - 🟡 InspectorPanel の固定の
w-[320px] h-[420px]既定：グリッドに埋め込むと上書きが要る＝#381。 - 🟠 資産のステータス行のコンポーネント（ActionDataTable と ListCard の中間＝行＝ステータス＋key/value＋末尾の Meter＋操作）＝#381（1/3）。
- ✅ 索引の是正 #382：「status 付き一覧」がモバイルの ListCard に誘導していた→デスクトップ密度の機材/資産グリッドは DataTable/ActionDataTable と明記。
学び — 「事業者向けの土台は、もう新しい業種では揺らがない」
14業種の事務方で固めた事業者向けの土台は、鉄道の事業者向けを経て、航空 MRO という全く別の専門領域でも構造的な手組みゼロで立った。これは利用者向けの深掘りと真逆の景色：利用者向けは深掘るほど欠落が噴き出して11個のコンポーネントを固めさせた。事業者向けは逆に、もう新しい業種を当てても揺らがない＝成熟しきっている。 「事業者向けの画面は終わった？」への本当の答えは——枚数の問題ではなく、土台の成熟の問題。航空の事業者向けは枚数こそ薄かったが、当ててみれば土台は完璧に効いた。あと1枚（乗員スケジュール）で航空の事業者向けも安心の土台に。
📊 コンポーネント化スコアボード（作成済 11個）
AmountBreakdown / ActionQueue / ListCard / Gantt-segments / SeatMap / LoyaltySummaryCard / RadioCard / FilterChips / PageHeader / Itinerary / TicketStub 進行中：CheckboxCard・StatusScreen success・StatusLevel・asset-row・BottomActionBar
📋 事業者向け/利用者向け 進捗
- ✈️ 航空：利用者向け 全6枚 ✅／事業者向け 2枚（OCC#113・MRO#130）＝あと乗員スケジュールで土台
- 🚆 鉄道：利用者向け 全6枚 ✅／事業者向け 3枚（運行/乗務員/車両）＝土台達成
次回予告（やってみた #131）
- 航空の事業者向け 乗員スケジュール（パイロット/CA 乗務割・FTL 飛行時間制限・資格管理）＝鉄道 乗務員#107 の航空版で航空の事業者向けを土台に。その後 鉄道の事業者向けを厚く（駅務/ダイヤ作成）→ バスへ。
試す
- gunjo.jp ／ メーター Meter ／ ガント Gantt ／ 署名記録 SignedRecord ／ npm
@gunjo/ui／ GitHub ／ 前回まで #1〜#129 - GunjoUI by UIXHERO
鉄道で固めた保守の土台が、機番も整備規程も違う航空 MRO にそのまま効いた——事業者向けは枚数ではなく、土台の成熟で「終わる」。
この連載は、作者が AI（Claude と Codex）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。
使用した @gunjo/ui コンポーネント
この画面のソースが直接 import しているコンポーネントです。
cold AI が組み上げた実コード
ファイル名をクリックでソースを展開できます。