結論：清掃業・ビルメンテナンスの点検報告は、Claude Codeに「作業完了報告書」「品質点検表」「オーナー向け月次報告」の3帳票を読ませる小さな仕組みから始めるのが現実的です。
- 要点1：現場写真やチェック表をそのまま丸投げするのではなく、物件名・作業区分・指摘事項・是正状況を固定項目にそろえます。
- 要点2：Claude Codeは、報告書を書くチャット欄ではなく、CSV・写真台帳・HTML/PDF雛形・検証スクリプトをまとめて扱う作業環境として使います。
- 要点3：最初の完成形は「人間が確認する下書き」です。品質判定、契約範囲、クレーム対応、個人情報の扱いは必ず管理者が最終確認します。
対象読者：日常清掃・定期清掃・巡回点検の報告書、シフト連絡、月次報告の事務負担を減らしたい清掃会社・ビルメンテナンス会社の管理者。
読了後にできること：自社の既存帳票を使って、Claude Codeに点検報告の下書きと差戻しチェックを作らせる最初のプロンプトを試せます。
「現場は終わっているのに、報告書だけが終わらない」
清掃・ビルメンテナンスの管理者と話すと、ここで詰まる会社がかなり多いです。日常清掃は作業箇所が細かく、定期清掃は写真と実施内容の対応づけが必要で、巡回点検は指摘事項の温度感まで残さないと、オーナーや管理会社への説明で困ります。
しかも、現場スタッフの報告は「3階トイレ OK」「エントランス汚れあり」「ガラス清掃完了」のように短い。管理者はそれを読み替えて、物件別の作業完了報告書、品質点検表、月次報告に整えるわけです。正直、ここはAIに文章を書かせるだけでは足りません。帳票の構造をそろえ、未確認項目を検出し、写真と文章を突き合わせる仕組みにする必要があります。
この記事では、清掃業 ビルメンテナンス Claude Code の実装パターンとして、点検報告を自動化する5ステップを紹介します。既存の小売店舗巡回や建設日報とは似ている部分もありますが、今回は清掃・ビルメン固有の「作業完了」「品質点検」「オーナー向け報告」を中心に組み立てます。
事例区分：実装パターン解説
この記事は、特定企業の実測事例ではありません。清掃・ビルメンテナンス会社で一般に発生しやすい帳票業務をもとにした実装パターン解説です。効果時間や削減率は断定せず、自社で測定できる設計に寄せています。
まず押さえる：清掃・ビルメンの報告は「3帳票」に分ける
最初にやるべきことは、AIツール選びではありません。報告書を3つに分けることです。清掃業務の報告は、現場メモをきれいな文章にする作業だと思われがちですが、実際には読み手が違います。
| 帳票 | 主な読み手 | Claude Codeに任せること | 人間が確認すること |
|---|---|---|---|
| 作業完了報告書 | 管理会社・施設担当者 | 作業内容、実施箇所、写真番号、未実施理由の整理 | 契約範囲、作業漏れ、写真の取り違え |
| 品質点検表 | 自社管理者・現場責任者 | 指摘事項、再清掃要否、前回からの再発箇所の抽出 | 合否判断、スタッフへの指導、是正期限 |
| オーナー向け月次報告 | ビルオーナー・PM会社 | 月内の作業履歴、重要指摘、改善状況の要約 | 表現のトーン、追加費用、クレーム対応方針 |
この分解をしないまま「いい感じの報告書にして」と頼むと、Claude Code以前に、どの読者に向けた文書なのかが曖昧になります。AnthropicのClaude向けプロンプトガイドでも、望む出力形式や制約を具体的に示すこと、順序が大事な場合は手順として渡すことが推奨されています。帳票ごとに読み手と用途を分けるのは、その実務版です。
巡回報告の考え方は、既存記事の小売店舗の巡回報告をClaude Codeで整理する事例も参考になります。ただし清掃・ビルメンでは、売場状態よりも「契約作業が完了したか」「衛生・美観の品質が保てているか」「月次でオーナーに説明できるか」が中心になります。
Claude Codeを「報告書作成チャット」として使わない
Claude Codeは、ターミナルや開発環境でファイルを読み、コマンドを実行し、複数ファイルにまたがる変更を扱えるエージェント型の作業環境です。Anthropic公式ドキュメントでは、テスト作成、依存関係更新、リリースノート作成のような面倒な反復作業を扱える例が示されています。清掃・ビルメンで置き換えるなら、毎回同じように発生する帳票整形、チェック漏れ検出、月次要約が近いです。
ここで大事なのは、Claude Codeにいきなり本番報告書を作らせないこと。まずは次のようなフォルダ構成を作り、既存帳票を機械が読める状態にします。
cleaning-report/
README.md
CLAUDE.md
input/
daily-checks.csv
photo-index.csv
shift-notes.md
templates/
work-completion-report.html
quality-inspection-sheet.html
owner-monthly-report.html
output/
scripts/
validate_report.py実際に触ってみると分かるのですが、AIに強い指示を出すより、ファイル名と置き場所をそろえるほうが安定します。たとえば「写真1、写真2」ではなく、photo_id、location、taken_at、related_taskのように列を決める。これだけで、写真と作業内容の突き合わせがかなりやりやすくなります。
チーム導入の前提設計は、Claude Codeのビジネス導入ガイドで整理している観点とも重なります。清掃会社の場合も、最初から全現場に展開するより、帳票が安定している物件を1つ選んで、検証可能な形で始めるのが現実的です。
5ステップ：点検報告をClaude Codeで自動化する
ステップ1：帳票ルールをCLAUDE.mdに固定する
最初のステップは、会社ごとの報告ルールをCLAUDE.mdに書くことです。これはClaude Codeに渡す常駐メモのようなものです。物件名の表記、日常清掃と定期清掃の区分、オーナー向けに使わない表現、未確認項目の扱いを明記します。
ここを飛ばすと、同じ「汚れあり」でも、ある日は「軽微な汚れ」、別の日は「清掃不備」と表現が揺れます。清掃報告はトーンが強すぎるとクレームに見え、弱すぎると是正が進みません。表現ルールは、文章力ではなく運用ルールなんです。
あなたは清掃・ビルメンテナンス会社の報告書作成補助エージェントです。
目的:
- 作業完了報告書、品質点検表、オーナー向け月次報告の下書きを作成する
- 現場メモの不足、写真番号の不整合、未実施理由の欠落を検出する
- 事実と推測を分け、未確認事項は「要確認」と明記する
表記ルール:
- 物件名、フロア名、作業区分は input/site-master.csv の表記に合わせる
- クレーム、事故、費用、契約範囲外作業は断定せず、管理者確認欄に回す
- オーナー向け文書では、担当者個人名を出さない
不足している情報があれば、最初に質問してから作業を開始してください。
仮定した点は必ず「仮定」と明記してください。この段階で、厚生労働省が公表している建築物衛生の考え方も確認しておきます。厚労省のページでは、特定建築物の所有者・占有者等が建築物環境衛生管理基準に従って維持管理すること、基準が空気環境、給水・排水、清掃、ねずみ・昆虫等の防除などを含むことが説明されています。清掃の報告書は単なる「作業しました」の証跡ではなく、維持管理の説明資料にもなるわけです。
ステップ2：現場メモを標準CSVに寄せる
次は、現場から集まる情報を標準CSVに寄せます。スマホ入力フォーム、表計算、紙の転記など入口は会社ごとに違っていて構いません。ただしClaude Codeに渡す前の中間形式は、できるだけ固定します。
| 列名 | 例 | 用途 |
|---|---|---|
| site_name | 青山第3ビル | 物件別の集計 |
| work_type | 日常清掃 / 定期清掃 / 巡回点検 | 帳票テンプレートの切替 |
| area | 1Fエントランス | 作業箇所の特定 |
| status | 完了 / 要再清掃 / 要確認 | 品質点検表の判定 |
| note | 床面に雨天由来の泥汚れあり | 報告文の素材 |
| photo_id | P-20260706-014 | 写真台帳との突合 |
清掃現場では、短いメモが多いのは自然です。「汚れ」「臭い」「水はね」「備品不足」のような言葉を、管理者が文書に変換しているからです。Claude Codeには、その変換ルールを先に作らせます。
input/daily-checks.csv を読み、清掃・ビルメン報告用の標準CSVとして不足している列を洗い出してください。
確認してほしいこと:
1. site_name, work_type, area, status, note, photo_id が存在するか
2. status が「完了」「要再清掃」「要確認」のいずれかに正規化できるか
3. note が空欄の行、photo_id があるのに写真台帳に存在しない行を抽出する
4. 修正案は output/standardization_issues.md に書く
数字と固有名詞は、根拠となる入力ファイル名と行番号を添えてください。
不足している情報があれば、最初に質問してから作業を開始してください。ここでの成果物は、完成報告書ではなく「入力データの問題リスト」です。地味ですが、ここを通すと後段の報告書が安定します。私が帳票自動化の設計で一番よく見る失敗も、AIの文章が悪いことではなく、入力項目が毎回違うことです。
ステップ3：作業完了報告書の下書きを作る
作業完了報告書は、最も自動化しやすい帳票です。理由は、読み手が知りたいことが比較的はっきりしているからです。いつ、どこで、何を、契約範囲どおりに実施したのか。未実施があればなぜか。写真はどれか。この順番で整理します。
input/daily-checks.csv と input/photo-index.csv をもとに、
templates/work-completion-report.html の形式で作業完了報告書の下書きを作成してください。
出力条件:
- output/work-completion-report-draft.html に保存する
- 物件名、作業日、作業区分、作業箇所、実施内容、写真IDを表で整理する
- status が「要再清掃」「要確認」の行は、完了扱いにせず「管理者確認事項」に分ける
- note が空欄の行は「現場コメント未入力」と表示する
- オーナー向けに断定できない内容は「要確認」と明記する
禁止:
- 入力にない作業を追加しない
- 写真IDを推測で補完しない
- 契約範囲外作業を「完了」と書かない
仮定した点は必ず「仮定」と明記してください。ポイントは「完了」と「要確認」を混ぜないことです。報告書をきれいに見せようとして、要確認の指摘まで完了欄に入ると、後で説明が難しくなります。Claude Codeには、文章を整える前に分類をさせます。
ステップ4：品質点検表で差戻しを先に出す
清掃品質の点検表は、単なるチェックリストではありません。再清掃の要否、前回からの再発、備品補充、設備不具合との切り分けが必要です。ここはClaude Codeに「合否を決めさせる」のではなく、「管理者が見るべき差戻し候補を出させる」と考えます。
output/work-completion-report-draft.html と input/daily-checks.csv を読み、
品質点検表の下書きと差戻し候補を作成してください。
出力:
- output/quality-inspection-sheet.html
- output/review-backlog.md
判定ルール:
- status が「要再清掃」の行は review-backlog.md に必ず出す
- 同じ area に「要再清掃」または「要確認」が複数回出ている場合は「再発候補」としてまとめる
- note に「臭い」「水漏れ」「破損」「害虫」「異音」が含まれる場合は、清掃範囲だけで判断せず「設備・衛生確認」に回す
- 合否欄は空欄にし、管理者入力欄を残す
不足している情報があれば、最初に質問してから作業を開始してください。厚労省の建築物衛生ページでは、特定建築物の定義として、事務所や店舗などの用途、延べ面積3,000平方メートル以上などの条件が説明されています。すべての清掃案件がこの枠に入るわけではありませんが、大規模物件では清掃報告が維持管理の説明資料になりやすい。だからこそ、品質点検表では「清掃で対応できる指摘」と「設備・衛生管理側で確認すべき指摘」を分けるのが大事です。
ステップ5：オーナー向け月次報告とシフト連絡に展開する
最後に、月次報告とシフト連絡へ展開します。ここで初めて、文章要約の価値が出ます。毎日の作業完了報告と品質点検表がそろっていれば、Claude Codeは月内の傾向、再発箇所、未解決の確認事項をまとめやすくなります。
output/quality-inspection-sheet.html と input/shift-notes.md をもとに、
オーナー向け月次報告の下書きと、現場責任者向けのシフト連絡メモを作成してください。
出力:
- output/owner-monthly-report.html
- output/shift-briefing.md
月次報告の条件:
- 作業実施状況、品質指摘、是正状況、次月の注意箇所に分ける
- 個人名、勤務評価、内部事情は書かない
- 追加費用や契約変更が必要そうな内容は「管理者確認事項」に分ける
シフト連絡の条件:
- 次回担当者が見るべき注意箇所だけを箇条書きにする
- 断定できない原因分析を書かない
- 現場で確認する項目と、管理者が判断する項目を分ける
仮定した点は必ず「仮定」と明記してください。ここで注意したいのは、シフト連絡は「外部送信」まで自動化しないことです。まずは下書きをファイルに出し、管理者が確認してから社内の既存ルールで共有します。報告書の文面は便利に作れても、送信先、個人情報、クレーム対応、契約判断は会社ごとの統制が必要です。
実装スタック：最初は表計算とHTMLで十分
最初から大きな業務システムを作る必要はありません。清掃・ビルメンの点検報告で最初に必要なのは、帳票を再現できる最小の入出力です。Claude Codeに向いているのは、次のような構成です。
| 層 | 推奨 | 理由 |
|---|---|---|
| 入力 | CSV、Markdown、写真台帳CSV | 差分確認しやすく、Claude Codeが読みやすい |
| 帳票 | HTMLテンプレート | 表や見出しを固定しやすく、PDF化にもつなげやすい |
| 検証 | Pythonの軽いチェックスクリプト | 必須列、空欄、写真ID不一致を機械的に確認できる |
| 運用メモ | CLAUDE.md、README.md | 担当者が変わってもルールを残せる |
経済産業省の中堅・中小企業向けDX手引きでは、DXを何から進めればよいか分からない企業向けに、事例や進め方を整理しています。清掃・ビルメンの報告自動化も同じで、いきなり全社システムにするより、帳票の流れを小さくデジタル化し、確認できる形にするほうが失敗しにくいです。
私はこの手の設計で、最初に「PDFを最終成果物にしない」ようにしています。PDFは提出には便利ですが、途中の検証には向きません。まずHTMLやCSVで状態を見えるようにして、最後に必要であればPDFにします。これはかなり地味ですが、後から修正できる余地が残ります。
帳票別プロンプト集：コピペして試せる5本
ここからは、実務でそのまま改造しやすいプロンプトをまとめます。すべてのプロンプトに、不足情報の質問、仮定の明記、根拠の提示を入れています。清掃報告は事実関係が大事なので、AIに自信満々の推測をさせない設計にします。
1. 作業完了報告の抜け漏れ確認
input/daily-checks.csv を確認し、作業完了報告書を作る前の抜け漏れを一覧化してください。
必ず確認する項目:
- 作業日
- 物件名
- 作業区分
- 作業箇所
- 完了/要確認の状態
- 写真ID
- 未実施理由
出力は output/precheck-work-completion.md に保存してください。
入力にない情報は補完せず「未入力」と書いてください。
不足している情報があれば、最初に質問してから作業を開始してください。2. 写真台帳との突合
input/photo-index.csv と input/daily-checks.csv を突き合わせ、
写真IDの不一致、未使用写真、写真が必要なのに存在しない作業行を抽出してください。
出力:
- output/photo-reconciliation.md
形式:
- 問題の種類
- 該当する入力ファイル名
- 行番号
- 管理者が確認すべき内容
写真の内容は推測せず、台帳に書かれた説明だけを根拠にしてください。3. オーナー向けの表現調整
output/owner-monthly-report.html を読み、
オーナー向け文書として強すぎる表現、曖昧すぎる表現、内部事情が見える表現を指摘してください。
出力:
- output/owner-wording-review.md
観点:
- クレームと断定していないか
- 担当者個人の評価を書いていないか
- 原因不明の事象を原因確定のように書いていないか
- 契約範囲外作業を実施済みのように書いていないか
修正案は、事実を増やさず、入力済みの情報だけで書いてください。4. 再清掃バックログの作成
input/daily-checks.csv から、再清掃・要確認・設備確認に回すべき項目を抽出し、
output/recleaning-backlog.md にまとめてください。
分類:
- 再清掃候補
- 備品補充候補
- 設備確認候補
- 管理者判断候補
各項目には、物件名、エリア、現場メモ、写真ID、次回確認事項を含めてください。
合否判定は行わず、管理者確認欄を残してください。5. シフト引き継ぎメモの生成
input/shift-notes.md と output/recleaning-backlog.md をもとに、
次回担当者向けのシフト引き継ぎメモを作成してください。
条件:
- 現場で確認することを最初に書く
- 管理者に確認することを別枠にする
- 個人情報、勤務評価、社内事情は書かない
- 1項目は短く、現場で読める長さにする
出力は output/shift-briefing.md に保存してください。
不足している情報があれば、最初に質問してから作業を開始してください。プロンプトを改善するときは、Anthropicのベストプラクティスにある「Claudeに検証方法を与える」という考え方が役に立ちます。報告書の場合、検証方法は「必須列があるか」「写真IDが存在するか」「要確認が完了扱いになっていないか」です。AIの文章力を信じるのではなく、検証できる条件を先に渡します。
【要注意】よくある失敗パターンと回避策
失敗1：現場メモをそのまま整文させる
❌「このメモをいい感じの報告書にして」
⭕「物件名、作業区分、作業箇所、状態、写真ID、未実施理由に分け、不足項目を先に抽出してから報告書下書きを作成してください」
なぜ重要か：清掃報告は、文章の見た目よりも事実の対応関係が大事です。短い現場メモをいきなり文章にすると、写真の取り違えや未確認事項の混入に気づきにくくなります。
失敗2：品質判定までAIに任せる
❌「この現場は合格か不合格か判定して」
⭕「品質判定に必要な確認事項を抽出し、合否欄は空欄のまま管理者確認欄を残してください」
なぜ重要か：清掃品質は契約範囲、施設特性、オーナーとの合意、過去経緯で判断が変わります。Claude Codeは候補抽出には使えますが、最終判定者にはしません。
失敗3：月次報告を毎日の文章から直接作る
❌「今月の日報を全部読んで月次報告にして」
⭕「作業完了報告、品質点検表、再清掃バックログを作ってから、月次報告に集約してください」
なぜ重要か：日々の報告文を直接まとめると、重要な指摘と細かな作業メモが混ざります。月次報告は、日報の要約ではなく、管理者が説明すべき論点の整理です。
失敗4：送信まで自動化する
❌「完成したら関係者に自動送信して」
⭕「下書きファイルを作成し、管理者レビュー項目を添えて保存してください」
なぜ重要か：報告書には個人情報、クレーム、追加費用、契約範囲外の作業が混ざることがあります。外部共有は、会社の承認ルールと個人情報保護の運用に従ってください。
セキュリティと運用ルール：AIに渡す前に決めること
清掃・ビルメンの報告書には、建物名、入退館情報、担当者名、写真、クレーム内容が含まれることがあります。便利だからといって、全部をそのままAIに渡す設計は危険です。Claude Codeを使う前に、少なくとも次のルールを決めます。
- 個人名、電話番号、入館証番号などを入力ファイルから除外する。
- 建物名を外部提出用と内部作業用で分ける必要があるか確認する。
- 写真に人物、車両番号、テナント情報が写っている場合の扱いを決める。
- 契約範囲外作業、事故、クレーム、費用に関する文章は管理者確認に回す。
- Claude Codeの出力は下書きとし、提出前に人間が確認する。
AnthropicのClaude Codeベストプラクティスでは、環境設定、権限、CLIツール、検証の設計が重要な観点として整理されています。清掃報告でも同じです。自動化は「早く出す」ためだけでなく、「何を根拠に書いたかを後から追える」ために設計します。
不動産管理寄りの問い合わせや入居者対応が絡む場合は、不動産管理の入居者対応をClaude Codeで整理する記事も近い論点があります。清掃会社がPM会社や管理会社とやり取りする場合、現場報告と顧客対応を分けておくと、余計な情報を出さずに済みます。
小さく始めるための導入順序
導入順序は、次のように軽く始めるのがおすすめです。日数ベースの計画にすると、現場都合や物件数で崩れやすいので、ここでは成果物ベースで考えます。
| 順序 | 作るもの | 完了条件 |
|---|---|---|
| 1 | 標準CSV | 既存の現場メモを固定列に変換できる |
| 2 | 作業完了報告書 | 完了と要確認が分離されている |
| 3 | 品質点検表 | 再清掃候補と管理者判断候補が出る |
| 4 | 月次報告 | 重要指摘、是正状況、次回注意箇所がまとまる |
| 5 | 運用ルール | 提出前レビュー、個人情報、写真利用のルールが明文化される |
建設現場の日報に近い業務を扱う会社なら、建設日報をClaude Codeで整理する記事も参考になります。ただし、清掃・ビルメンでは「作業した証跡」と「品質の説明」を分ける点が違います。ここを分けるだけで、月次報告の読みやすさが変わります。
参考・出典
- Claude Code Overview — Anthropic / Claude Code Docs（参照日: 2026-07-06）
- Best practices for Claude Code — Anthropic / Claude Code Docs（参照日: 2026-07-06）
- Prompting best practices — Anthropic / Claude Platform Docs（参照日: 2026-07-06）
- 建築物環境衛生管理基準について — 厚生労働省（参照日: 2026-07-06）
- 建築物衛生のページ — 厚生労働省（参照日: 2026-07-06）
- 中堅・中小企業等向け「デジタルガバナンス・コード」実践の手引き — 経済産業省（参照日: 2026-07-06）
まとめ：今日から始める3つのアクション
- 最初にやること：既存の作業完了報告書を1枚選び、項目をCSV列に分解します。物件名、作業区分、作業箇所、状態、写真ID、未実施理由だけで十分です。
- 次にやること：Claude Code用の
CLAUDE.mdを作り、禁止表現、未確認事項の扱い、管理者確認に回す条件を書きます。 - 運用に入る前にやること：作業完了報告書、品質点検表、月次報告を別ファイルで出し、提出前レビューの責任者を決めます。
清掃業・ビルメンテナンスのClaude Code活用は、派手なAIエージェントを作る話ではありません。現場メモ、写真台帳、点検表、月次報告の間にある「転記と確認」を、検証可能なファイルの流れに変える話です。
正直に言うと、最初から完全自動化を狙うと失敗しやすいです。まずは下書き、次に差戻しチェック、最後に月次要約。この順番で作ると、現場にも管理者にも負担が少なくなります。
あわせて読みたい：巡回チェックの構造化は小売店舗の巡回報告事例、管理会社とのやり取りは不動産管理の入居者対応事例、チーム導入の考え方はClaude Codeビジネス導入ガイドで補足しています。
次回予告：次の記事では、写真台帳と作業完了報告書を突き合わせる実装パターンを、CSV設計とチェックスクリプト中心に掘り下げます。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
