AI に施工スケジュールを作らせてみた：運輸のために作った工程表コンポーネントが、建設現場でもそのまま動いた（やってみた #174）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青を一度も見たことのない AI に、実際の画面で組ませていく連載。今回は業種を建設に広げます。お題は⁠建設現場の現場監督が使う施工スケジュール（工程管理）画面⁠。工種ごとの工程バー、進捗と出来高、担当業者、マイルストーン、天候と稼働をひとつにまとめた画面です。

結果：4/5。工程表コンポーネントが、業種をまたいでそのまま動いた

予備知識ゼロの AI（群青を一度も触っていない設定）に、公開されている npm パッケージと gunjo.jp の docs だけを渡して組ませました。tsc は緑、モバイルとデスクトップの両対応です。

一番の見どころは、⁠工程表コンポーネント Gantt が、建設のために作ったものではないのに、施工工程にほぼ無改造で嵌まった⁠ことです。この Gantt は元々、航空機の運用ローテーションや生産ラインのリソース計画のために群青へ加わったものでした。行と時間軸、今日を示す線、バーを選んで詳細を開く操作、読み上げ用のラベルまで、建設の工種スケジュールでそのまま機能しています。

工程表以外でも、既存のコンポーネントが素直に当てはまりました。

• ⁠Timeline⁠：中間検査・上棟・引渡しといったマイルストーンにそのまま。
• ⁠Meter⁠：全体の出来高を「予定に対してどうか」で見せる指定（target と「高いほど良い」の向き）が、出来高管理の意味にぴったり合いました。
• ⁠DataTable⁠：行クリックで詳細を開く動きと、セルの中に小さなメーターを置く使い方で、工種一覧と詳細の画面が組めました。
• ⁠StatGroup⁠：遅延件数のように「増えると悪い」指標を、色で正しく反転して見せられました。

業種が変わっても、UI のコンポーネントのレベルでは同じものが使い回せる。それを建設でも確認できた回です。

足りなかったもの：工程表の「依存線」と「バーの中の進捗」

一方で、建設ならではの要件で、群青に無いものが2つはっきり出ました。どちらも工程表コンポーネントの機能の穴です。

1. ⁠工種どうしの先行後続を、線でつなぐ表現が無い。⁠ 「基礎が終わってから躯体」といった依存関係を、工程表のバーの間に矢印で描きたかったのですが、Gantt にその機能はありません。今回は詳細パネルに「先行する工種」を文字で並べる形に落としました。建設の工程では本来いちばん大事なところなので、最大の穴です。
2. ⁠バーの中に進捗（出来高）を塗る表現が無い。⁠ 各工種がどこまで進んだかをバーの中で見せたかったのですが、これも標準では持っていません。今回は別用途のしくみを借りて代用しました。

このほか、色と意味を対応させる凡例や、読み込み中の骨組み表示は、既存のコンポーネントだけでは組み切れず一部を手で書きました。手で書いた量はおよそ80行で、画面全体（およそ870行）から見ればごく一部です。大半は既存のコンポーネントの組み合わせで足りました。

足りないコンポーネントは、3つの別々の画面で独立に手作りされたら、そこで初めて正式に作って群青に加える、というルールで運用しています。今回の依存線とバー内進捗は、まだ1回目です。

名前で迷ったところ

スケジュールに関わるコンポーネントは名前が近く、選ぶのに迷いが出ました。ScheduleGrid は名前だけ見ると本命に見えますが、中身は「時限×曜日」の時間割で、工程表ではありません。本命は Gantt でした。名前では決められず、それぞれの説明を読んで初めて用途が確定します。ここは「用途から探す」入口の案内をもっと強くできる余地があります。

まとめ

建設は、群青にとって基盤UIや金融とは遠い業種です。それでも、工程表・進捗・一覧と詳細・マイルストーンといった画面の骨格は、別の業種のために作ったコンポーネントでそのまま組めました。埋まらなかったのは、工程の依存線とバー内進捗という、建設に固有の2点だけです。業種を増やしていくと、こうして「共通で使える土台」と「その業種でしか出てこない穴」がきれいに分かれて見えてきます。

---

この連載は、作者が AI（Claude）と協働で制作しています。実験・検証の設計、判断、公開前の事実確認は人間が行い、実作業と下書き執筆は AI が担っています。

GunjoUI by UIXHERO