CCUSやグリーンサイトへの二重入力は、自社システムと連携して消せますか？
結論から述べます。外部サービスへの入力の一部は連携で消せますが、全項目を一本化しようとすると、かえって壊れやすい仕組みになります。
理由は単純です。CCUS（建設キャリアアップシステム）やグリーンサイトのような外部サービスは、自社で仕様を決められません。連携手段はAPI連携・CSV（ファイル）連携・画面操作の自動化の3つに限られ、どれを選んでも「相手側の仕様が変わったら止まる」というリスクを抱えます。
だから設計の出発点は「どうやって繋ぐか」ではありません。「その連携が止まったとき、誰の業務が、どれだけ止まるか」です。ここを先に見積もらずに全項目の自動連携を組むと、仕様変更のたびに現場が動けなくなります。
以下、エクサテックが実際に使っている判断の順序を書きます。
そもそも二重入力はどこで発生していますか？
「二重入力が大変」という相談を受けたとき、最初にやるのは自動化の検討ではありません。項目ごとの発生源の特定です。
作業員名簿1枚を例にとると、載っている項目の発生源はバラバラです。
| 項目の例 | 最初に確定する場所 | 自社システムから流せるか |
|---|---|---|
| 現場名・工期・工事内容 | 元請の受注管理・基幹システム | 流せる |
| 元請の担当者・安全衛生責任者 | 元請の社内台帳 | 流せる |
| 協力会社の商号・許可番号 | 協力会社（契約時に取得） | 契約書類から取れれば流せる |
| 技能者の氏名・生年月日 | 協力会社の従業員台帳 | 元請側には無い |
| CCUS技能者ID | CCUS（技能者本人の登録済み情報） | 元請側には無い |
| 資格・特別教育の修了状況 | 協力会社（有効期限あり） | 元請側には無い／期限管理が必要 |
| 保険加入状況 | 協力会社 | 元請側には無い |
この表を作ると分かることがあります。元請の自社システムから外部サービスへ流し込めるのは、上の数行だけです。技能者個人の情報は、そもそも自社システムに正しい状態で存在しません。存在しないデータを連携で流すことはできません。
したがって設計の順序はこうなります。
- 帳票・画面ごとに、入力項目を全部列挙する
- 項目ごとに「最初に確定する場所」を書き込む
- 発生源が社内にある項目 → 自動連携の候補
- 発生源が協力会社・本人にある項目 → 収集の設計（連携ではなく）
- 発生源が外部サービス側にある項目（技能者IDなど） → 参照の設計
この切り分けをせずに「作業員名簿の自動作成」を作ると、結局現場が手で埋める項目が残り、「半分自動化されたけど結局全部見直すから意味がない」という状態になります。これが「導入したのに使われない」の典型パターンです。
API連携・CSV連携・画面操作の自動化、どれを選ぶべきですか？
判断基準は1つです。その連携が止まったとき、誰がどれだけ止まるか。
止まる影響が小さい業務には、多少壊れやすい手段を使ってもよい。止まると現場が動けない業務には、壊れにくい手段しか使わない。この順序で選びます。
3つの手段の性質
| 手段 | 壊れる原因 | 壊れたときの検知 | 復旧の主体 |
|---|---|---|---|
| API連携 | 仕様バージョンの変更、認証方式の変更 | エラーが返るので検知しやすい | 開発側（改修が必要） |
| CSV／ファイル連携 | 項目の追加・並び順の変更、コード値の変更 | 取込エラーで検知できる。ただし「通ったが値がずれた」は検知しにくい | 開発側＋現場の目視確認 |
| 画面操作の自動化（RPA等） | 画面レイアウト変更、要素の名前変更、ログイン導線の変更 | 何も起きない／途中で止まる。気づくのが遅れやすい | 開発側（画面追従の改修） |
画面操作の自動化がもっとも壊れやすく、かつもっとも気づきにくいという点が重要です。APIが落ちればエラーが返りますが、画面自動化はボタンの位置が1つ変わっただけで無言で失敗します。
採否の判断ライン
エクサテックでは、次の順で検討します。
第1候補：正式なAPI／連携機能があるか
外部サービス側が公式に提供する連携機能があれば、原則これを使います。仕様が公開されており、変更もアナウンスされるためです。
第2候補：CSVの一括登録機能があるか
多くの業務システムは一括登録（インポート）用のフォーマットを持っています。これを自社システム側から出力する形にすれば、外部サービスの画面を触りません。「取込用CSVを作るところまでを自動化し、アップロードは人が押す」という設計は、壊れにくく、かつ人の確認ポイントが残るため実務では優れています。
第3候補：画面操作の自動化
上の2つが使えない画面で、かつ入力件数が多い場合にのみ検討します。ここに次の条件を付けます。
- 止まったとき、手入力に戻せる手順が現場側に用意されている
- 止まったことに担当者が気づく通知がある（成功／失敗をどちらも通知する）
- 画面変更に追従するための保守を、誰がどの頻度で見るか決まっている
この3条件が揃わないなら、画面操作の自動化は作らないほうがよいと考えています。月に数件の作業を自動化するために画面追従の保守を抱えるのは、多くの場合割に合いません。
「止まったら誰が止まるか」の見積もり方
具体的には、次の質問を発注者に投げます。
- この入力が今日できなかったら、明日の作業に影響しますか？（入場前日までに必要な手続きかどうか）
- 手入力に戻すとして、それができる人は社内に何人いますか？
- その人は普段どこにいますか？（本社にいるのか、現場に出ているのか）
- 締切は月末に集中しますか？（集中する業務は、止まったときの被害が大きい）
入場管理に直結する手続きで、手入力できる人が実質1人しかいない業務に、画面操作の自動化を入れるのは危険です。逆に、月次でまとめて処理する集計系の入力なら、多少止まっても翌日リカバリできます。
協力会社側の入力負荷まで減らせますか？
減らせます。ただし方向が決まっています。元請から協力会社へ情報を配る方向は減らせますが、協力会社の入力を元請が代行する方向は慎重に線を引くべきです。
配る方向で減らす
作業員名簿や再下請通知の項目のうち、現場名・工期・工事内容・元請情報・注文者情報は、元請が確定情報を持っています。ここを協力会社に手入力させると、表記のゆらぎ（現場名の略称、工期の書式）が発生し、元請側の確認作業が増えます。
そこで、次の設計にします。
- 元請の基幹システムから、現場ごとの共通項目を出力する
- 協力会社には「共通項目が埋まった状態」を渡す
- 協力会社が入力するのは、自社の技能者情報と差分のみ
これで協力会社の入力量が減り、同時に元請側の突合作業も減ります。二重入力の削減は、社内だけを見ていると半分しか解けません。
代行入力に踏み込むときの注意
「協力会社の分もこちらで入力してあげたい」という要望は頻繁に出ます。しかしここには、外部サービスのアカウント権限、代行入力の可否、個人情報の取得範囲といった論点が絡みます。
このあたりは各サービスの利用規約や、個人情報の取扱いに関わる部分です。技術的にできるかどうかとは別の判断が必要になるため、実装前に発注者側で運用ルールを確認していただくことを前提にしています。個別の可否判断は各サービスの規約および専門家にご確認ください。
設計の順序はどうなりますか？
エクサテックが実際に踏む順序です。株式会社イーリアルティ様の転記エージェント構築でも、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。この順序は外部サービス連携でも変わりません。
Step 1：現場に同行して、実際の入力操作を見る
ヒアリングだけでは分かりません。どの画面を何回開いているか、どこからコピーしているか、Excelを何枚並べているかを実際に見ます。「1件30分」と言われた作業が、待ち時間込みなのか操作時間なのかもここで分かります。
Step 2：入力項目を全部列挙し、発生源を書き込む
前述の表を作ります。この段階で「自動化できない項目」が確定します。
Step 3：外部サービス側の連携手段を調べる
公式のAPI・一括登録機能・CSVフォーマットの有無を確認します。ここで手段が無いことが判明する項目もあります。
Step 4：止まったときの被害を項目ごとに見積もる
前述の4つの質問で、影響度を分けます。
Step 5：Step 3と4を掛け合わせて、手段を割り当てる
影響大かつ手段が画面操作しかない項目は、あえて自動化しないという判断もします。
Step 6：1帳票・1画面に絞って作る
最初から全部やりません。1つ動かして現場が使うことを確認してから広げます。
Step 7：止まったときの手順書と通知をセットで納める
連携システムは必ずいつか止まります。止まる前提の運用手順まで含めて納品しないと、止まった日に業務が停止します。
この方法でできないことは何ですか？
正直に書きます。
外部サービスの仕様変更を予測することはできません。
API連携でも、認証方式の変更やバージョンの廃止は起こります。連携システムは「作って終わり」ではなく、外部サービスの更新に追従し続ける前提の資産です。保守を見込まない前提での見積りは、後で必ず破綻します。
入力項目そのものを減らすことはできません。
外部サービスが求める項目は、そのサービスの仕様です。連携で減らせるのは「同じ内容を人が2回打つ回数」であって、必要な情報の総量ではありません。
元請側に無いデータは作れません。
技能者の資格の有効期限、保険の加入状況、本人のCCUS技能者IDなど、協力会社や本人しか持っていない情報は、連携では埋まりません。ここは収集の仕組み（依頼と回収の設計）の話であり、システム連携とは別のテーマです。
「全部の入力が1画面で終わる」状態は作れません。
複数の外部サービスに同じ情報を出す構造自体は、外部サービス側の仕様が変わらない限り消えません。減らせるのは人の操作回数です。
画面操作の自動化に完全な安定性は約束できません。
これは技術の問題ではなく、相手の画面を自社で管理できないという構造の問題です。だからこそ「止まったら手入力に戻す」手順を必ずセットにします。ここを省くと、自動化が現場のリスクになります。
まとめ
- CCUSやグリーンサイトへの二重入力は連携で減らせるが、全項目の一本化は目標にしない。壊れやすくなる
- 設計の第一歩は自動化ではなく、項目ごとの発生源の特定。元請の社内に発生源がある項目だけが自動連携の対象になる
- 連携手段はAPI連携 → CSV／一括登録 → 画面操作の自動化の順に検討する。画面操作の自動化はもっとも壊れやすく、もっとも気づきにくい
- 手段の採否は「その連携が止まったとき、誰がどれだけ止まるか」で決める。入場管理に直結し、手入力できる人が1人しかいない業務には壊れやすい手段を使わない
- 協力会社側の負荷も、元請から共通項目を配る方向なら減らせる。ただし代行入力は権限と規約の確認が先
- 連携システムは必ず止まる。止まったときの手順書と通知をセットで納めるのが前提
ご相談について
エクサテックは、不動産・建設業の現場に入り込んで、仕組み設計からWebアプリ構築まで同一チームで担当しています。費用は1業務に絞ったかなり小さなプロジェクトなら数十万円から、対象範囲が広がると数百万円前半のレンジが目安です。
「どの入力から手をつけるべきか」の整理だけでもお役に立てることがあります。まずは現状の入力作業を見せていただくところから、お気軽にご相談ください。
