協力会社ポータルの招待・請求・OTPを分離する：建設業の受信箱を転送エイリアスで守る
3月6日公開 · 読了時間12分
建設業の現場では、協力会社（サブコン）とのやり取りが膨大です。入退場手続き、ポータル招待、資格証明、図面共有、出来高・請求、変更指示、そして管理画面のログイン通知やワンタイムパスワード（OTP）。これらが同じ受信箱に混ざると、重要メールが埋もれるだけでなく、なりすまし（取引先偽装）に気づきにくくなります。
TempForwardは、捨てメール／転送メール／エイリアスの仕組みで「入口（アドレス）」を分け、必要なものだけを本来の受信箱へ転送できます。本記事では、協力会社ポータルを日常的に使う人ほどTempForwardが効く理由、誰が一番使うか、具体手順、落とし穴、ベストプラクティスをまとめます。
この分野で利用者が多い理由（協力会社対応は「外部からの入口」が増え続ける）
協力会社の管理は、社外との接点が多い仕事です。プロジェクトが増えるほど、招待メールや書類提出依頼、請求関連の連絡が増え、担当者の受信箱はすぐ飽和します。さらに、現場のスピード感から「至急」「今日中」「承認お願いします」といった文言が多く、判断が雑になりやすいのも現実です。
この状況は、攻撃者にとって都合が良い条件になります。取引先や現場関係者を装ったメールは、支払先口座の変更や偽のポータルログインへ誘導しやすく、発見が遅れると金銭被害や工期遅延につながります。建設分野では契約・請求・図面など機微情報がメール経由で流れやすく、基本的なセキュリティ衛生（強固なパスワード、MFA、バックアップなど）が重要だと繰り返し指摘されています。
だからこそ「入口の設計」が効きます。TempForwardで協力会社ごとの入口を分ければ、受信箱での判断回数が減り、誤クリックや見落としを減らせます。怪しい入口は止めるだけで被害面を小さくできます。
誰が一番使う？（現場で起きる“困りごと”別）
ゼネコン／元請の現場監督・施工管理
- 招待メールが迷子：協力会社追加のたびに届く案内が、日常の連絡に埋もれる。
- 短期で外部連絡が激増：工程変更や写真共有が増え、重要な承認依頼を見落とす。
- 夜間のOTP対応：現場外でポータルに入る必要があるのに、OTPが見つからず作業が止まる。
購買・調達／協力会社窓口
- 協力会社が多い：見積依頼（ITB）や契約書類のやり取りが並行し、メール整理が破綻しやすい。
- 取引先偽装の判別が難しい：似た差出人名・似たドメインで、請求や変更指示が紛れ込む。
- プロジェクト終了後も届く：現場が終わっても営業メールや案内が残り続ける。
経理（請求・支払）
請求書と支払関連のメールは、扱う情報が重く、判断ミスが致命的です。入口が混在していると、正規の請求と偽装請求を同じ目線で処理してしまいます。請求専用の入口を作り、そこだけをルール化して転送・確認するのが安全です。
具体手順：協力会社ポータル向け「三つの受信箱分離」
おすすめは、用途で入口を分ける方法です。協力会社別に増やす前に、まずは用途の分離で事故率を下げます。
ステップ1：用途で入口を分ける（最小構成）
- ポータル招待・アカウント作成：portal-invite@（招待、登録、権限付与）
- 請求・支払関連：portal-billing@（請求、支払条件、口座連絡、領収書）
- OTP・復旧専用：portal-otp@（OTP、ログイン通知、復旧リンク）
TempForwardでそれぞれエイリアスを作り、普段使う受信箱へ転送します。重要なのはOTP専用入口を「日常の雑多な連絡」から切り離すことです。
ステップ2：協力会社ごとに入口を作る（必要な範囲だけ）
規模が大きい現場や協力会社が多い場合は、会社単位でも入口を分けるとさらに強いです。例：
- sub-aaa-invite@（AAA社の招待・担当変更）
- sub-aaa-billing@（AAA社の請求・出来高）
- sub-aaa-otp@（AAA社のOTP・復旧）
入口を分けるほど、受信箱で「誰から来たか」を推測する必要が減り、偽装メールに強くなります。プロジェクトが終われば、その入口を止めるだけで後処理が完了します。
ステップ3：転送先を役割で分ける（共有受信箱に寄せすぎない）
「全部を共有受信箱に転送」は便利ですが、権限が広がりすぎます。おすすめは次の分離です。
- 招待・権限変更 → 現場責任者＋バックアップ担当
- 請求 → 経理の専用受信箱（現場メンバーに転送しない）
- OTP・復旧 → セキュリティ担当（または最小限の管理者）
OTPの転送先が多いほど、内部の漏えい面が広がります。最小限にして、必要な時だけ共有するのが安全です。
落とし穴（現場で起きがちな事故）
落とし穴1：OTPが請求メールに埋もれる
OTPは「今すぐ必要」な情報です。請求や日程連絡と同居すると、見つからない・期限が切れる・再送が増える、の悪循環になります。OTPは専用入口に隔離しましょう。
落とし穴2：差出人名だけで判断する
なりすましは「表示名」を似せます。入口を分けると、少なくとも「この入口に来るはずのない話」が目立ちます。違和感が出たら、入口を止める（または転送を無効化）して一旦被害拡大を止められます。
落とし穴3：プロジェクト終了後の入口を放置する
工事が終わっても、古い入口が生きていると攻撃面が残ります。TempForwardなら、入口単位で停止できるので、完工時のチェックリストに「入口停止」を入れるのがおすすめです。
ベストプラクティス（現場でも回る運用ルール）
- 命名規則：用途→会社→案件の順に揃える（例：sub-aaa-billing）。迷いが減ります。
- 入口を最小化：最初は「招待」「請求」「OTP」の三つだけで始め、必要な所だけ細分化します。
- MFAは前提：強固なパスワードとMFAを有効化し、端末紛失や共有PCでも被害を抑えます。
- 請求は別ルートで再確認：支払先変更や高額請求は、メール以外の連絡手段でも確認する運用にします。
- 完工チェック：案件終了時に入口を停止し、必要なら新案件で新しい入口を作ります。
まとめ：協力会社対応は「入口設計」で事故率が下がる
協力会社ポータルは便利ですが、メールが起点になりやすく、入口が増えるほど判断ミスが起きます。TempForwardで招待・請求・OTPを分離し、必要に応じて協力会社単位でも入口を分けると、現場のスピードを落とさずに安全性を上げられます。まずは三つの入口から始めて、現場に合う形へ育てていきましょう。