写真整理に時間を溶かしていた不動産管理会社が、CodexとGASで「自動圧縮・自動リネーム」を作った話 | 神奈川区 不動産管理日記

不動産管理の現場では、写真がとにかく増えます。

退去立会い、修繕依頼、設備不具合、原状回復、鍵の設置場所、メーター、共用部、掲示物、室内確認。

写真を撮ること自体は、もう当たり前です。
スマホで撮って、Google Driveに入れて、必要なときに共有する。

ところが、問題はそのあとです。

写真が増えすぎる。
ファイル名が IMG_3847.jpg のまま残る。
どの物件の写真かわからなくなる。
容量が大きくてDriveを圧迫する。
メールやLINEで送るときに重い。
担当者ごとに保存方法が違う。

写真は便利なはずなのに、後から探すときには、むしろ仕事を邪魔してくることがあります。

今回はその地味なストレスを減らすために、Codexを使ってGoogle Apps Scriptを書き、写真の「自動圧縮」と「自動リネーム」の仕組みを作りました。

大げさなAI活用ではありません。
でも、現場ではこういう小さな自動化がかなり効きます。

写真管理は、地味だけどかなり時間を食う

不動産管理の仕事では、写真が証拠にも記録にもなります。

たとえば、給湯器の不具合写真。
水漏れ箇所の写真。
退去後の室内写真。
鍵のキーボックス設置場所。
水道メーターの位置。
原状回復前後の比較写真。

こうした写真は、後から見返せることに意味があります。

ただ、保存時点で整理されていないと、あとで困ります。

IMG_1024.jpg
IMG_1025.jpg
IMG_1026.jpg

こんな名前のままだと、ファイルを開かないと中身がわかりません。

さらに、スマホで撮った写真は1枚あたりの容量も大きくなりがちです。
数枚なら問題ありません。
でも、現場ではそれが何十枚、何百枚、何千枚と積み上がっていきます。

Google Driveの容量も圧迫しますし、共有するときにも扱いづらくなります。

つまり、写真管理には大きく2つの課題がありました。

1つ目は、容量が大きいこと。
2つ目は、ファイル名から中身がわからないこと。

この2つをどうにかしたかったわけです。

作ったものは2つ

今回作ったのは、次の2つです。

1つ目は、写真の自動圧縮GAS。
2つ目は、写真の自動リネームGAS。

どちらもGoogle Drive上のフォルダを対象にして動く仕組みです。

専用システムを導入したわけではありません。
Google DriveとGoogle Apps Scriptを使って、今ある業務環境の中に小さな自動化を足しました。

写真の自動圧縮GAS

写真の自動圧縮GASは、指定したフォルダ内にある画像ファイルを検出し、サイズを小さくするためのものです。

対象は主にJPEGやPNGです。

現場写真は、記録として内容がわかれば十分なケースも多いです。
もちろん、原本レベルの画質が必要な場面もあります。
しかし、日常的な共有や社内確認では、必要以上に高画質なまま保存しておく必要がない写真も多いです。

そこで、指定フォルダに入った画像を圧縮し、Drive容量を節約できるようにしました。

目的は、きれいな写真を作ることではありません。
業務で扱いやすい写真にすることです。

写真の自動リネームGAS

もう1つが、写真の自動リネームGASです。

こちらは、ファイル名を後から見て意味がわかる形に整えるためのものです。

たとえば、元のファイル名がこうだったとします。

IMG_3847.jpg

これを、次のような名前に変えます。

2026-05-31.星川アイランド.101.給湯器.jpg

日付、物件名、号室、内容。
このあたりがファイル名に入っていれば、写真を開かなくても概要がわかります。

検索もしやすくなります。
共有もしやすくなります。
後から別の担当者が見ても、何の写真なのか判断しやすくなります。

写真の中身は同じでも、ファイル名が整うだけで、業務上の価値はかなり変わります。

なぜCodexを使ったのか

今回、コードを書くときにCodexを使いました。

理由は、単に「AIがコードを書いてくれるから」ではありません。

むしろ便利だったのは、こちらのやりたいことを業務の流れに合わせて整理しながら、実装に落とし込めたことです。

たとえば、写真圧縮ひとつ取っても、考えることは意外とあります。

対象フォルダをどこにするのか。
サブフォルダも対象にするのか。
元画像を残すのか、残さないのか。
処理済みの画像をどう判定するのか。
エラーが出たときにどう記録するのか。
何度実行しても二重処理にならないようにするにはどうするのか。

リネームも同じです。

ファイル名に何を入れるのか。
日付形式はどうするのか。
区切り文字は何にするのか。
物件名や号室の表記ゆれをどう扱うのか。
すでに同じ名前のファイルがあった場合はどうするのか。

こういう細かい設計を飛ばして、「とりあえず動くコード」だけ作ると、現場ではすぐ詰まります。

業務用の自動化は、動けばいいわけではありません。
失敗したときに気づけること。
やり直せること。
担当者が迷わないこと。
後から確認できること。

このあたりが大事です。

Codexは、その実装の壁打ち相手として使いやすいと感じました。

こちらがやりたいことを自然文で伝え、出てきたコードを見ながら、

「この場合は元画像を残さない仕様にしたい」
「ログを残したい」
「処理済みファイルは再処理しないようにしたい」
「命名ルールは日付.物件名.号室.内容にしたい」

という形で、少しずつ業務に合わせて調整していきました。

プログラミングの知識がゼロでよい、とは言いません。

ただ、以前なら自分で調べながら時間をかけて書いていた処理を、かなり短いサイクルで試せるようになったのは大きいです。

自動化で一番大事なのは、コードより運用ルール

今回あらためて感じたのは、自動化で大事なのはコードそのものより運用ルールだということです。

たとえば、写真を圧縮するだけなら、やり方はいろいろあります。
リネームも、単純にファイル名を変えるだけなら難しくありません。

でも、現場で使うなら話は別です。

誰がそのフォルダに写真を入れるのか。
どのタイミングで処理するのか。
圧縮前の写真は残すのか。
処理後のファイル名はどう統一するのか。
失敗した場合はどこを見るのか。
間違えて入れた写真はどうするのか。

このあたりを決めないと、せっかく作った自動化も使われません。

特に、ファイル名のルールは重要です。

自社では、ファイル名の区切りをドットに寄せる運用を考えています。
日付は YYYY-MM-DD。
その後に、物件名、号室、内容を並べる。

たとえば、こんな形です。

2026-05-31.ハピネスハイム上星川.102.水道メーター.jpg

この形にしておくと、ファイル一覧で見たときに内容がわかります。
日付順にも並べやすい。
検索もしやすい。

地味ですが、こういうルールが効きます。

逆に、ここを曖昧にしたまま自動化すると、ただの自動混乱装置になります。
便利なようで、あとから余計に困ります。

元画像を残すか、残さないか問題

写真圧縮で悩むのが、元画像を残すかどうかです。

元画像を残せば安心です。
ただし、容量削減の効果は弱くなります。

元画像を残さなければ、容量削減の効果は出やすいです。
ただし、間違って圧縮してしまった場合のリスクがあります。

ここは、目的によって分けるべきだと思います。

証拠性が高い写真、原本を残す必要がある写真、トラブル対応で重要な写真は、元画像を残す運用の方が安全です。

一方で、社内確認用、共有用、日常記録用の写真であれば、圧縮後の画像だけで十分な場面もあります。

今回の仕組みでは、対象フォルダを限定し、処理ログを残し、テスト運用をしながら調整する前提にしました。

いきなり全社の写真フォルダに対して自動処理をかけるのは危険です。

まずはテストフォルダで動かす。
次に対象業務を限定する。
問題がなければ範囲を広げる。

この順番が現実的です。

自動化は、強い薬みたいなものです。
効くけれど、雑に使うと副作用もあります。

Before / After

今回の自動化で変わったことを整理すると、こんな感じです。

Before

写真を撮ったあと、ファイル名はスマホやカメラの初期名のまま。

必要になったら、画像を開いて中身を確認する。

写真が重いので、共有時に時間がかかる。

Google Driveの容量もじわじわ圧迫する。

物件名や号室がファイル名に入っていないので、後から探すのに時間がかかる。

担当者が変わると、どこに何があるのかわかりづらい。

After

指定フォルダに写真を入れる。

必要に応じて画像が圧縮される。

ファイル名が一定のルールで整理される。

写真を開かなくても、日付・物件名・号室・内容がわかる。

Drive容量の圧迫を減らせる。

共有しやすくなる。

後から探しやすくなる。

属人化も少し減る。

もちろん、これだけで写真管理のすべてが完璧になるわけではありません。

でも、「毎回ちょっと面倒だった作業」が減るだけで、現場の体感はかなり変わります。

これは派手なAI活用ではない

今回の取り組みは、正直かなり地味です。

AIで契約書を自動作成したわけでもありません。
高度な画像認識をしたわけでもありません。
営業戦略をAIに全部考えさせたわけでもありません。

やったことは、写真を圧縮すること。
ファイル名を整えること。
ログを残すこと。

ただ、それでいいと思っています。

現場のDXは、派手なものから始める必要はありません。

むしろ、毎日少しずつ発生している面倒な作業を減らす方が、効果を実感しやすいです。

写真を探す時間。
ファイル名を直す時間。
容量を気にする時間。
どの写真かわからずに開いて確認する時間。

こうした細かい時間は、ひとつひとつは小さいです。
でも、積み上がると結構大きい。

AIやCodexの使いどころは、こういうところにもあります。

「大きなシステムを作る」ではなく、
「現場の小さな不便を、ひとつずつコードに置き換える」。

この感覚です。

不動産管理会社こそ、小さなGAS自動化が効く

不動産管理の仕事は、意外と情報整理の仕事です。

物件情報。
入居者情報。
オーナー情報。
修繕履歴。
退去立会い。
写真。
PDF。
メール。
LINE。
スプレッドシート。

情報はあちこちにあります。
そして、現場ではそれを毎日さばいています。

大きな基幹システムを入れればすべて解決、というほど単純ではありません。

現場には、現場ごとの細かい運用があります。
店舗ごとのやり方もあります。
担当者ごとの癖もあります。

だからこそ、Google Driveやスプレッドシートの周辺を小さく自動化することには意味があります。

今回の写真圧縮・リネームGASも、その一例です。

大きな改革ではありません。
でも、日々の業務の引っかかりをひとつ減らせます。

こういう小さな改善を積み重ねる方が、現場には合っている気がします。

Codexは、現場担当者の「こうしたい」をコードに近づけてくれる

今回よかったのは、現場側の言葉で相談しながら作れたことです。

「このフォルダに入れた写真を圧縮したい」
「処理済みのものは再処理したくない」
「元画像は残さない仕様にしたい」
「失敗したらログに残したい」
「ファイル名は日付.物件名.号室.内容にしたい」

こういう業務上の要望を、少しずつコードに変えていける。

これはかなり大きいです。

もちろん、出てきたコードをそのまま信用しすぎるのは危険です。
動作確認は必要です。
テストフォルダで試すべきです。
エラーも出ます。
修正も必要です。

でも、ゼロから自分で調べて作るより、圧倒的に前に進みやすい。

特に、GASのような業務改善向けの小さなコードは、Codexとの相性がいいと感じました。

まとめ

今回は、Codexを使って写真の自動圧縮GASと、自動リネームGASを作りました。

目的は、すごいAIツールを作ることではありません。

不動産管理の現場で地味に面倒だった写真整理を、少し楽にすることです。

写真の容量を減らす。
ファイル名を整える。
後から探しやすくする。
共有しやすくする。
担当者ごとのバラつきを減らす。

やっていることは小さいです。

でも、現場の仕事はこういう小さな面倒の積み重ねです。

AI活用やDXというと、つい大きな話になりがちです。

でも実際には、

「毎回手でやっていた作業を1つ減らす」

これだけでも十分価値があります。

Codexは、そのためのかなり実用的な相棒になります。

不動産管理のDXは、大きなシステム導入だけではありません。

まずは、写真の整理みたいな地味な作業からでもいい。

毎日ちょっと面倒な作業を、ひとつずつ減らしていく。

その積み重ねが、現場に合ったDXになると思います。