コラム仕組みと技術

施工管理アプリを生成AIで自作すると、どこで詰まる?手配ボードと入力画面を10回作らせ、現場の12要件で採点した

• 公開 2026年10月17日
• 更新 2026年10月17日
• 事実の確認 2026年10月17日
• 書いた人 現場のまど 主宰(元AIエンジニア)

施工管理アプリを生成AIで自作すると、動くものは作れますが、依頼文に書かなかった現場の条件はほぼ入りません。手配ボードと協力会社の入力画面を、簡素な依頼文と現場の条件を書いた依頼文で5回ずつ作らせ(Claude Sonnet 5.5、n=10)、12要件を動かして数えると、満たした数は簡素な版が60点中39点、条件を書いた版が57点でした。資格・権限・リンクの失効・圏外の再送は、書かない版では5回とも0点です。この実験の範囲での結果です。(2026年10月時点)

全体の流れと費用は現場管理アプリの独自開発のページにまとめています。

要点

• 手配ボードと入力画面を生成AIに5回ずつ作らせ、現場の12要件で採点すると、簡素な依頼文は60点中39点、条件を書いた依頼文は57点でした(n=10)。
• 簡素な依頼文では、資格の足りない割り当て・権限・失効後の送信拒否・圏外の再送の4要件が、5回とも0点でした。
• 条件を書いた5回のうち4回は12要件をすべて満たし、1回は送信の準備の1行の誤りで報告が1件も送られず、9点でした。
• 重なり警告・半日・月またぎの集計は、簡素な依頼文でも5回とも満たしました。実験の範囲の結果で、ほかのモデルや依頼文には当てはめられません。

生成AIで施工管理アプリを作ると、現場の12要件のうちいくつ満たしますか?

簡素な依頼文では60点中39点、現場の条件を書いた依頼文では57点でした。現場のまどの実験で、手配ボードと協力会社の入力画面を生成AIに作らせ、現場の12要件を動かして満たした数を数えました。1つの依頼文を5回ずつ、合わせて10個のアプリです。

簡素な依頼文で抜けたのは、依頼文に書かなかった条件でした。資格の足りない割り当て、権限、リンクの失効後の送信拒否、圏外の再送は、5回とも0点です。条件を書いた版は、5回のうち4回が12要件すべてを満たしました。

どんな条件で試したのですか?

2026年10月17日に、Claude Sonnet 5.5(claude-sonnet-5-5)へ、Claude Codeの claude -p で依頼文を渡しました。道具は使わせず、1回で返ってきたHTMLをそのまま採点しています。やり取りを重ねて直す使い方はしていません。

依頼文は2通りです。簡素な版は、手配ボードと入力画面が要る、とだけ書き、動作確認用の関数名を添えました。

建設会社向けの施工管理アプリを作ってください。職人を現場と日付に割り当てる「手配ボード」と、協力会社が自分のスマホで現場の報告(現場・時間・午前/午後/1日)を入力する画面の2つが要ります。HTML1ファイル(CSSとJavaScriptも中に入れる)で、フレームワークなしで作ってください。
(以下、動作確認用の関数の一覧。addWorker・addSite・assign・getAssignments・issueLink・submitReport・getReports・monthlyTally)

条件を書いた版は、これに次の8項目を足しました。関数の一覧には、資格(quals・needQuals)・立場(setRole)・リンクの有効確認(linkValid)の窓口も加えています。

- 同じ職人が同じ日・同じ時間帯に2つの現場へ入る割り当ては、警告を出して止めてください。
- 現場ごとに必要な資格があり、資格の足りない職人は割り当てられません。
- 半日(午前・午後)の割り当てを扱います。午前に現場A、午後に現場Bは正常です。1日と半日の重なりは重なりです。
- 協力会社の入力画面は、職人ごと・日ごとの入力リンク(アカウントなし)で開きます。リンクの有効期限は7日で、過ぎたら入力を受け付けません。
- 電波が悪い現場が多いので、圏外で送信しても内容を失わず、電波が戻ったら自動で送り直してください。ただし同じ報告が2回届いてはいけません。ボタンの連打も1回にまとめてください。
- 協力会社は自分の報告を入れるだけで、手配ボードの割り当ては変えられません。
- 時間の入力は0〜24の範囲だけ受け付けます。
- 出面(人工)は月末に職人ごとに集計します。1日=1人工、午前または午後だけ=0.5人工で、月をまたぐ分は入れません。

採点は、返ってきたHTMLをブラウザで開き、窓口の関数を呼ぶ台本で行いました。送信先は台本が受けて本文を数え、圏外は接続状態を偽にして送信を中断して作ります。判定の条件は上の表のとおりで、台本は実験の台本とデータ(zip)に入れています。

窓口の説明に要件の手がかりを入れた最初の版も、簡素な版で3回試しました。12要件のうち11を満たし、差が出なかったため、手がかりを外してやり直しています。

簡素な依頼文だと、どこが抜けるのですか?

書かなかった条件が抜けます。簡素な5回は、重なりの警告、半日、月またぎの集計を、何も頼まなくても5回とも入れました。人が普通に想像する範囲は、生成AIも補っています。

抜けたのは、資格、権限、リンクの失効、圏外の再送です。簡素な版は窓口に資格や立場の欄がないので、前の2つは入りようがありません。ただし失効と圏外は窓口に手がかりがなく、それでも5回とも入りませんでした。リンクは発行した日付にしか使えない作りでも、30日後に開けば、そのまま報告を受け付けました。

二重送信は、簡素な5回のうち1回が同じ報告を2件送りました。連打に備えた作りは、頼まなくても4回入っています。入力リンクも5回とも日付ごとに作られ、別の日の報告は断りました。

条件を書いても、抜けたのは何ですか?

5回のうち1回は、送信の準備に誤りのあるアプリでした。「いま送信中」の印が、最初に立ったまま下りないのです。報告は画面に「送信待ち」と出るのに、サーバーへは1件も送られず、二重送信・圏外の再送・時間の範囲チェックの3要件が不合格になりました。

条件を書いた版の表の4/5が3つあるのは、すべてこの1回のためです。要件の文に書いてあっても、動かして確かめないと見つからない不具合でした。画面で1件送って「送信待ち」と出るだけでは、見つけにくい種類です。

圏外の再送を満たした4回は、送信が失敗した報告を端末に保存し、電波が戻る通知や一定の間隔で送り直す作りでした。ブラウザの接続状態の値は、falseならオフラインとみなせますが、trueでも通信できるとは限りません(MDN)。再送で同じ報告を二重に処理させない仕組みには、リクエストに重複防止の印(Idempotency-Key)を付ける案が標準化の途上にあります(IETFのドラフト)。

この実験から言えることと、言えないことは?

言えるのは、この依頼文とこのモデルで、書いた条件はほぼ入り、書かなかった条件は入らなかったことです。10個のアプリのコードは314〜654行でした。手配表を1画面で動かすだけなら、自作で足りる場面は多いはずです。

言えないことも多くあります。試したのは1つのモデルで、5回ずつです。画面を見ながら何度も直す使い方や、サーバーとの連携、ログイン、写真の扱いは試していません。12要件は自動で判定できるものに絞ったので、見やすさや押しやすさは採点していません。

窓口の関数を呼ぶ採点なので、画面のボタンの動きは細かく見ていません。点数の差は、この実験の中の比較として読んでください。件数が少ないので、39点と57点の差が小さな偏りで動く余地もあります。

自作で足りる場面と、頼んだほうがよい場面は?

自分たちの手配表を1人か2人で使う段階なら、生成AIで作って試す価値があります。重なりの警告や半日の扱いは、この実験では頼まなくても入りました。

協力会社に入力リンクを配る段階や、圏外の現場がある段階では、この実験で抜けた条件がそのまま要ります。資格で割り当てを止めたいときも同じです。作る範囲と費用の全体は現場管理アプリの独自開発とは?と費用のページ(一式30万円〜)にまとめました。重なりや資格の検査の精度は職人の手配ミスの実験、リンクの安全性は協力会社の入力リンクの試作で調べています。

自作したアプリの抜けを確かめる相談をするには?

御社の現場の条件で、作ったアプリのどこが足りないかは、現場のまどの相談で一緒に確かめられます(無料で相談する)。何をどう頼むか決まっていなくても大丈夫です。御社のやり方に合わせて、進め方を一緒に考えます。準備は要りません。