建設会社の写真台帳をAzure Blob Storageで管理する: Claude Codeで命名規則を作る

建設会社の現場写真は、スマホから送られたままの IMG_4821.jpg が増えた瞬間に探せなくなり、引き渡し前の手戻りになります。黒板には工事番号が写っている。LINEには撮影者のメモが残っている。けれど、Azure Blob Storageへ上げた後の名前が日付順でも現場順でもないため、「防水シートの施工写真どこですか」と聞かれて止まります。今日まず直すのは、写真台帳のファイル名とタグです。

この記事では、建設会社の写真台帳をAzure Blob Storageに置く前に、Claude Codeで命名規則、Blob index tags、metadata、共有URL、保持期間を点検する流れを書きます。施工事例ページの整え方は建設会社の施工事例ページで扱いました。ここでは、公開用ページではなく、社内で探す写真台帳に絞ります。

この記事の要点

• 建設写真は、写真名だけで探すのではなく、工事番号、工程、撮影日、部位、撮影者を分けて持つ。
• Azure Blob Storageのblob名は自由度が高いが、container名にはDNS名としての制約がある。先に命名表を作る。
• Blob index tagsは検索用、metadataは補助情報として分けると、後から写真を探しやすい。
• Claude Codeには、今の写真名、フォルダ、黒板ルール、提出先、共有URLの作り方を読ませる。
• 人が見る範囲は、施主名、住所、顔、車番、近隣情報、契約書、事故写真、公開可否、削除依頼です。

現場で起きる失敗シーン

建設会社の写真台帳では、現場監督、職人、事務担当、協力会社が別々の経路で写真を集めます。スマホのカメラロール、LINE、メール添付、共有フォルダ、工事管理アプリから写真が来ます。引き渡し前、役所提出、施主説明、保険対応、クレーム対応で写真を探すときに、名前が IMG_4821.jpg のままだと手が止まります。

よくある痛みは、写真がないのではなく、見つからない点です。工事番号、建物名、階数、部位、防水、配筋、是正前、是正後、撮影日がどこかに残っていても、Blob名やタグに入っていない。すると、担当者がLINEをさかのぼり、同じ現場写真を何度も再送します。対応時間が1件あたり15分増えるだけでも、月末の台帳作成が重くなります。

参考にした一次情報は、Azure Blob Storage introduction、Naming and referencing containers, blobs, and metadata、Blob index tags、lifecycle management、soft delete、SAS overviewです。公式情報では、保存、名前、検索、保持、共有が分かれているため、写真台帳でも分けて見ます。

業務フロー: 写真を集めて探せる形にする

写真台帳の最初の画面は、Azure Portalではなく現場の写真一覧です。工事番号、撮影日、工程、部位、撮影者、提出先、公開可否を1枚の表にします。黒板写真から読める情報、職人メモにしかない情報、ファイル名に入れる情報、Blob index tagsへ入れる情報を分けます。

おすすめの分け方は、blob名、index tags、metadata、台帳CSVの4つです。blob名は人が見ても並びが分かる名前。index tagsは後で検索するキー。metadataは補助情報。台帳CSVは人がレビューする一覧です。全部をファイル名に詰め込むと長くなり、全部をmetadataに寄せると一覧で読みにくくなります。

持つ場所	例	使い道	人が見る点
blob名	2026/07/site-042/waterproof/20260719_roof_before_001.jpg	並び、重複防止、目視確認	現場名を出しすぎない
index tags	projectId=site-042, phase=waterproof	検索、抽出、台帳更新	タグの表記ゆれ
metadata	shotBy=tanaka, source=line	補助情報、取り込み経路	個人名や連絡先
台帳CSV	写真URL、工程、提出先、公開可否	提出前レビュー	施主名、顔、車番

この表をClaude Codeへ渡すと、現場写真の命名規則案を作れます。たとえば projectId/yyyy/mm/phase/location/date_status_seq.ext のように分けます。Blob Storageのblob名は長さ制限があるため、説明文を詰め込むより、タグと台帳CSVへ逃がす方が後から直しやすいです。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、今ある写真名の棚卸し、命名規則案、タグ表、台帳CSVの列、共有URLの運用メモ、保持期間の下書きです。現場写真のサンプル一覧、工事番号ルール、工程名、提出先、現在のフォルダ構成を読ませると、写真台帳のレビュー表を作れます。

人が見る範囲は、写真の中身です。施主名、住所、顔、車番、近隣住宅、事故写真、契約書、黒板の個人情報、公開可否、削除依頼は、人が止めます。Claude Codeが「この写真は公開OK」と判断したように見える記事は危ないです。AIにはファイル名と台帳の抜けを見させ、公開承認は人が残します。

Azure Blob Storageの共有ではSASが便利ですが、URLをメールやチャットに貼る時は期限、権限、対象範囲を絞ります。施工写真の一時共有なら、読み取りだけ、短い期限、container全体ではなく対象blobや限定prefixにする運用が向きます。長期保管はsoft delete、versioning、lifecycleの候補も合わせて見ます。

3つのUse case

Use case 1: 現場写真の命名規則を作る

• 入力: 既存フォルダ、写真名、工事番号、工程名、部位、撮影日、提出先。
• 出力: blob名テンプレート、禁止文字、連番ルール、表記ゆれ一覧、台帳CSV列。
• 人の確認: 施主名、住所、現場名をURLに入れすぎていないかを見る。

最初に触るのは、写真そのものではなく一覧表です。100枚だけ抜き出し、今の名前、撮影日、黒板の工程、現場メモ、提出先を並べます。Claude Codeには、この表から命名規則を作らせます。人は、URLに出したくない情報を削ります。

Use case 2: Blob index tagsで探せる台帳にする

• 入力: projectId、phase、location、status、shotDate、submittedTo、publicOk。
• 出力: tag設計、検索例、必須タグ、空欄検出ルール、タグ表記の辞書。
• 人の確認: タグに個人情報や施主名を入れていないかを見る。

Blob index tagsは、後から写真を探すためのキーです。たとえば projectId=site-042、phase=waterproof、status=before のように置くと、是正前写真や提出済み写真を探しやすくなります。一方で、タグに個人名や住所を入れると扱いが重くなります。検索に必要な短い値だけに絞ります。

Use case 3: 施主や協力会社へ共有するURLを点検する

• 入力: 共有対象の写真、共有先、期限、権限、メール文面、提出期限。
• 出力: SAS運用メモ、期限切れチェック、共有対象一覧、送信前チェックリスト。
• 人の確認: 共有先、期限、読み取り権限、写真内の個人情報、契約情報を見る。

共有URLは、現場の手戻りを減らす一方で、範囲を間違えると写真を見せすぎます。Claude Codeには、URL一覧と共有先を表にさせます。人は、container全体を見せていないか、期限が長すぎないか、是正前や事故写真が混ざっていないかを確認します。

コピペで使えるプロンプト

あなたは建設会社の写真台帳レビュー担当です。
目的は、Azure Blob Storageに保存する現場写真を、後から探せる名前とタグに直すことです。

入力:
- 既存フォルダと写真名の一覧
- 工事番号、工程名、部位、撮影日、提出先
- Azure Blob Storageのcontainer案
- 共有URLの作り方
- 写真の保持期間

確認してほしいこと:
1. blob名に工事番号、撮影日、工程、部位、連番が入っているか
2. 施主名、住所、個人名、車番をURLやタグに入れすぎていないか
3. Blob index tagsで探す項目と、metadataに置く項目が分かれているか
4. 共有URLの期限、権限、対象範囲が狭いか
5. soft delete、versioning、lifecycleで削除や長期保管の案があるか
6. 台帳CSVで人が公開可否を見られるか

出力:
- 命名規則案
- 必須タグ表
- 台帳CSVの列
- 危ない写真名の例
- 今日まず直す100枚チェック手順

動く確認コード

次のコードは、建設写真台帳のblob名、タグ、共有URLをざっくり点検する小さなレビュー用コードです。わざと危ない写真を入れているため、実行すると直すべき項目が表で出ます。

// verify-construction-photo-ledger.mjs
// No dependencies. Run with: node verify-construction-photo-ledger.mjs
const photos = [
  {
    blobName: "IMG_4821.jpg",
    tags: { projectId: "site-042", phase: "waterproof" },
    metadata: { source: "line" },
    share: { permission: "read", expiresInHours: 240 }
  },
  {
    blobName: "2026/07/site-042/waterproof/20260719_roof_before_001.jpg",
    tags: {
      projectId: "site-042",
      phase: "waterproof",
      location: "roof",
      status: "before",
      publicOk: "review"
    },
    metadata: { source: "camera", shotBy: "staff-01" },
    share: { permission: "read", expiresInHours: 24 }
  },
  {
    blobName: "sato-home-address-kyoto-crack-after.jpg",
    tags: { projectId: "sato-home", phase: "repair", publicOk: "yes" },
    metadata: { customerName: "Sato" },
    share: { permission: "write", expiresInHours: 72 }
  }
];

const requiredTags = ["projectId", "phase", "location", "status", "publicOk"];
const blobNamePattern = /^\d{4}\/\d{2}\/[a-z0-9-]+\/[a-z0-9-]+\/\d{8}_[a-z0-9-]+_(before|after|progress)_\d{3}\.(jpg|jpeg|png)$/i;
const sensitiveWords = /(address|customer|home|name|phone|car|license|住所|氏名|電話|車番)/i;
const problems = [];

for (const photo of photos) {
  if (!blobNamePattern.test(photo.blobName)) {
    problems.push({ blobName: photo.blobName, item: "blob name", fix: "use yyyy/mm/project/phase/date_location_status_seq.ext" });
  }
  for (const tag of requiredTags) {
    if (!photo.tags[tag]) {
      problems.push({ blobName: photo.blobName, item: `missing tag: ${tag}`, fix: "fill required Blob index tags before upload" });
    }
  }
  if (sensitiveWords.test(photo.blobName) || sensitiveWords.test(JSON.stringify(photo.tags)) || sensitiveWords.test(JSON.stringify(photo.metadata))) {
    problems.push({ blobName: photo.blobName, item: "sensitive label", fix: "remove customer names, addresses, phone numbers, and car identifiers" });
  }
  if (photo.share.permission !== "read") {
    problems.push({ blobName: photo.blobName, item: "share permission", fix: "use read-only sharing for external photo review" });
  }
  if (photo.share.expiresInHours > 48) {
    problems.push({ blobName: photo.blobName, item: "share expiry", fix: "shorten SAS expiry for temporary construction photo review" });
  }
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Construction photo ledger checklist passed.");
}

このコードで見ているのは、blob名、必須タグ、個人情報に近い文字、共有権限、共有期限です。実際の現場では、写真の中身、黒板、顔、車番、近隣住宅、契約情報を人が見ます。まずは100枚だけこの形式に当てはめ、問題の多い工程を1つ選んで直します。

Pitfall: よくある落とし穴

写真台帳で一番起きる落とし穴は、ファイル名だけで全部を表そうとする流れです。原因は、Blob index tagsや台帳CSVへ分ける前に、現場名、部位、工程、説明文を全部つなげてしまう点です。直し方は、blob名は短く並びやすくし、検索したい項目をタグへ逃がすことです。

二つ目は、タグに個人情報を入れることです。原因は、後で探せるように施主名や住所を入れたくなる点です。直し方は、projectIdやinternalIdへ置き換え、施主名は社内台帳の権限付き列で扱います。

三つ目は、共有URLの期限が長すぎることです。原因は、期限切れの再送が面倒だからです。直し方は、施主確認や協力会社確認の期限を先に決め、読み取りだけの短いURLにします。

四つ目は、削除と長期保管を同時に考えないことです。役所提出、保証、事故対応、クレーム対応で残す写真と、早く消す写真は違います。soft delete、versioning、lifecycleの候補を表にして、人が保存年数を決めます。

よくある質問

Q. 写真は全部同じcontainerでよいですか。

A. 最初は1つのcontainerでも運用できます。ただし、公開用、社内用、事故・是正用、長期保管用で権限や保持期間が違うなら、containerやprefixを分ける候補を出します。

Q. Blob index tagsとmetadataは何が違いますか。

A. この記事では、検索に使うものをBlob index tags、補助情報をmetadataとして扱います。工事番号、工程、状態はtags、取り込み経路や撮影者IDはmetadataの候補です。

Q. SAS URLは安全ですか。

A. 期限、権限、対象範囲を狭くすれば一時共有に使えます。container全体、書き込み権限、長すぎる期限、転送先が不明なメール送信は避けます。

Q. 今日まず何を直せばよいですか。

A. 直近1現場の写真100枚だけを選び、blob名、projectId、phase、location、status、publicOkの6列を埋めます。空欄が多い工程から直すと、台帳作成の対応時間を下げやすいです。

研修・相談につなげるなら何を見るか

建設会社の写真台帳記事から相談へ進めるなら、PVだけでは判断しません。写真検索の対応時間、再送依頼の件数、台帳CSVの空欄率、提出前レビューで止めた写真数、共有URLの期限切れ件数、問い合わせ率を見ます。ここが見えると、写真台帳、クラウド保管、権限、公開フローをまとめて相談する理由が出ます。

Azure Blob Storageの命名、タグ、共有URL、保持期間、施工事例ページへの転用までまとめて整えたい場合は、ClaudeCodeLabの研修・相談で相談できます。まずは直近1現場の写真100枚を出し、この記事の確認コードで空欄と危ない名前を洗い出してください。

実際に試した結果

この記事では、Microsoft LearnのBlob Storage introduction、naming rules、Blob index tags、lifecycle management、soft delete、SAS overviewを確認しました。さらに、slug、frontmatter、内部リンク、外部リンク、CTA、コードブロック、10言語ファイル、記事キューの削除対象を確認しています。今日まずやる1手は、直近1現場の写真100枚で、blob名、projectId、phase、location、status、publicOkをチェックする作業です。