社内の業務プロセスに生成AIを組み込みたいが、どのツールをどの工程に当てるべきか迷っているエンジニアやPMに向けた内容です。欧州の不動産管理会社Heimstadenが公開した事例をもとに、LLM（大規模言語モデル）を複数の業務タスクに分散適用する設計思想を整理します。
Heimstadenは欧州で住宅賃貸管理を手がける企業です。2025年6月にOpenAIの採用を決め、ChatGPT EnterpriseとCodex（OpenAIのコーディング支援AI）を併用する体制を構築しました。オランダでは物件画像の加工コストが1枚あたり約50ユーロから0.1ユーロ未満に下がり、削減率は99%超と公表されています。
何が起きたのか、なぜ注目に値するか
この事例で技術的に興味深いのは、1つのLLMをあらゆる業務に当てはめたわけではない点です。
ChatGPT Enterpriseは価格提案・物件画像のスタイリング・物件説明文の生成・広告審査・市場フィードバック生成という、賃貸運用プロセスの複数ステージに組み込まれています。一方Codexは、2万112件という物件アセットの分析に使われたと報告されています。
つまり「対話型のタスク実行」と「コード生成によるデータパイプライン構築」を役割分担させる構成です。LLM基盤を検討する際に参考になるのは、この切り分けの発想そのものです。
技術的な仕組みを段階的に見る
まず、ChatGPT Enterpriseが担う部分から確認します。これは主にプロンプト（AIへの指示文）ベースで、非エンジニアの従業員が直接操作する業務アプリケーションとしての使い方です。
物件画像のバーチャルステージング（家具のない部屋に家具を合成する加工）は、従来は専門のデザイナーやカメラマンへの外注が必要でした。画像生成系のAI機能をChatGPT上のワークフローに組み込むことで、内製かつ低コストで同等の成果物を作れるようになっています。
次にCodexが担う部分です。2万件超の物件データを分析する作業は、自然言語での対話だけでは非効率です。Codexはコードを書いて実行する能力を持つため、データの集計・分類・異常値検出といった処理をスクリプト化できます。
これはRAG（検索拡張生成、外部データを検索してLLMの回答に反映させる仕組み）とは異なるアプローチです。RAGは「LLMに正しい情報を渡して回答させる」ことが目的ですが、Codexの使い方は「LLMにコードを書かせてデータ処理そのものを自動化する」点に主眼があります。
HeimstadenのCDO（最高デジタル責任者）であるNikolaj Brammer氏は、AI戦略を3本柱で説明しています。従業員への教育とツール提供、中央の変革推進チームとAI推進担当者のネットワーク、そして物件管理システムとデータモデルをAI対応にする基盤整備です。
この3本目の「データ基盤整備」は見落とされがちですが、技術的には最も重要です。LLMやCodexがどれほど優秀でも、物件データが構造化されずバラバラのフォーマットで保存されていれば、分析精度は上がりません。
背景・関連技術との比較
企業がLLMを業務に組み込む方法は、大きく3パターンに分かれます。1つ目はプロンプトのみで完結する汎用利用、2つ目はRAGによる社内データ参照、3つ目はファインチューニング（モデル自体を自社データで追加学習させる手法）です。
Heimstadenの事例は、公開情報を見る限りファインチューニングには言及がなく、ChatGPT EnterpriseとCodexという既存製品の組み合わせによる構成です。これは、自前でモデルを学習させるコストやMLOps（機械学習の運用基盤）の整備負荷を避け、既存SaaS（サービス型ソフトウェア）を業務プロセスに合わせて配線する設計と言えます。
日本の不動産管理会社やSaaS企業でも、似た構成は十分に実現可能です。たとえば社内の物件管理システムにAPI連携（システム間でデータをやり取りする仕組み）を用意し、ChatGPTのようなLLMサービスから呼び出せるようにすれば、価格提案や広告文生成の自動化は比較的早く着手できます。
一方でCodexのような「コードを書いて実行するAIエージェント」をデータ分析基盤に組み込む場合は、実行結果の検証プロセスが別途必要になります。Heimstadenも「従業員が決定をレビュー・承認する責任を持つ」と明言しており、AIの出力をそのまま業務に流し込んでいるわけではありません。
読者への影響と今日確認できること
自社でLLMを業務プロセスに組み込むか検討しているなら、まず着手できる確認項目があります。
- 対象業務を「対話で完結するタスク」と「大量データの処理が必要なタスク」に仕分けできるか確認する
- 社内データが構造化されているか、物件データのような業務データがAPIやCSVで取り出せる状態か棚卸しする
- ChatGPT EnterpriseのようなSaaS型LLMを使う場合、利用規約でデータの学習利用有無を確認する（OpenAIのエンタープライズプランはデフォルトで学習に使われない設定になっているか、契約条項を確認する）
- Codexのようなコード生成AIを使う場合、生成コードの実行環境を本番から隔離したサンドボックスで試す
- AIの出力を人がレビューする承認フローを、最初から業務フローに組み込んでおく
また、導入効果を測定する指標の設計も重要です。Heimstadenは画像加工コストの削減率、分析対象アセット数、従業員の利用率という3種類の指標を公表しています。コスト・処理規模・利用定着率という3軸は、他業種でも流用しやすいフレームワークです。
従業員の利用定着率についても触れておきます。Heimstadenでは導入から2〜3カ月で従業員の50%がツールを使い始めたと報告されています。これは技術導入のスピードだけでなく、教育体制やAI推進担当者のネットワークづくりが並行していたことの結果と考えられます。
まとめ
Heimstadenの事例から汲み取れる技術的な論点は3つに整理できます。
1つ目は、LLMを単一用途に絞らず、対話型タスクとコード実行型タスクで製品を使い分ける設計です。2つ目は、ファインチューニングではなく既存SaaSの組み合わせで始める現実的なアプローチです。3つ目は、AI導入の前提として物件データのような業務データの構造化が欠かせない点です。
自社で検討する際は、まず業務プロセスを棚卸しし、対話で完結する部分とデータ処理が必要な部分を分けてみることから始められます。そのうえで、利用するLLMサービスのデータ取り扱いポリシーを確認し、人によるレビュー工程を設計に組み込むところから着手できます。