AI に出来高査定を作らせてみた：金額の内訳も承認も確定ロックも既にそろっていて、新しく作るものがほぼ無かった（やってみた #177）

⁠やってみたシリーズ⁠: 自作のデザインシステム @gunjo/ui（群青）を、群青を一度も見たことのない AI に、実際の画面で組ませていく連載。建設の4枚目です。お題は⁠施工管理・積算担当が使う出来高査定（出来高・出来形の管理と出来高請求）画面⁠。工種ごとの出来高の積み上げ、請負金額に対する出来高率、出来高請求の内訳、査定と承認の段階までをまとめた画面です。

結果：5/5。作るべき穴がほとんど出なかった

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

これまでの建設の3枚（現場工程・施工写真台帳・安全KY）では、毎回その業種に固有の穴が出ていました。ところが4枚目の出来高査定では、⁠画面の核になる要素がすべて既存のコンポーネントでそろっていて、新しく作るべきものがほとんど出ませんでした。⁠ 手で組んだのは補助的な小物と、金額の計算そのものだけです。

核になった3点を、既存のコンポーネントがそのまま担いました。

• ⁠金額の内訳＝AmountBreakdown⁠：もともと保険金や給与明細のために作ったものですが、「累計出来高から、前回までの請求と前払金の充当を差し引き、消費税を足して今回の請求額を出す」という出来高請求の導出にそのまま合いました。工種詳細の「当初契約＋変更＝現契約金額」にも同じコンポーネントを使い回せて、1つで2か所を賄えています。
• ⁠工種ごとの出来高の積み上げ＝DataTable＋インラインの Meter＋Delta⁠：進捗率を表のセルの中のメーターで、予定に対する差（遅れ・進み）をセルの中の差分表示で見せられ、表に自然に収まりました。行をクリックして詳細を開く動きも、モバイルでカードに切り替える機能も、コンポーネント側が持っています。
• ⁠査定と承認＝ApprovalWorkflow＋SignedRecord⁠：現場の査定から一次承認・本社承認・発注者査定までの段階を並べ、差し戻しの理由も記録できます。発注者の査定が確定したら署名でロックし、以後は訂正の追記だけになる、という「確定後の扱い」もそのまま表せました。

これらは保険・給与・経理・医療の記録のために作ったコンポーネントです。それが建設の積算という遠い業種で、そろって主役として機能しました。

手で組んだのは、小物と計算だけ

埋まらなかったのは、コンポーネントの穴というより、細かな作りの部分です。

• ⁠軽いラベルと値の並べ物⁠：モバイルのカードの中に「現契約金額・対予定・当月・累計」を小さく2列で並べたかったのですが、既存の項目表示は少し重く、統計の表示は密度が高すぎました。数語のラベルと値だけを軽く置く小さなコンポーネントがあると、こうした場面が楽になります。
• ⁠読み込み中の骨組み⁠：骨組み表示の素材はありますが、テーブル用・サマリ用の組み合わせ済みのものは無く、画面ごとに組んでいます。表のコンポーネント自体が読み込み中の表示を持てると、各画面で作り直さずに済みます。
• ⁠金額の計算⁠：出来高や税の計算そのものは、コンポーネントの仕事ではなくアプリ側の仕事です（金額内訳のコンポーネントは「計算せず、表示するだけ」という作りで、これは想定どおり）。

名前で迷ったところ

ほとんど迷いませんでした。「用途から探す」入口が、「金額の導出」「承認」「主要指標」といった用途の言葉で、そのまま当たりのコンポーネントに導いてくれました。唯一迷ったのは進捗の見せ方で、似た候補が複数あるなかで、出来高率に合うものを説明を読んで確かめました。用途索引に「進捗率・出来高率」の言葉があると、もう一段速く辿れそうです。

まとめ

建設の4枚目は、これまでと様子が違いました。3枚目までは毎回その業種の穴が出ていましたが、出来高査定では核になる要素が既存のコンポーネントでそろい、新しく作るものがほぼ出ませんでした。これは、建設の事業者向けの画面について、共通で使える土台が十分に育ってきたということでもあります。金額の内訳・多段の承認・確定後のロックといった、業種をまたぐ「事務の背骨」は、もう繰り返し作らなくてよい段階に来ています。

---

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

GunjoUI by UIXHERO