はじめに
社内・社外問わず、最近ではAIの話題が尽きないので、自分も何か絡められないかと考えていたところ、ふと思い出しました。

自社のオフィスには会議室の利用状況を取るための人感センサーが設置されていて、自社の可視化サーバーに4年分のデータが蓄積されています。
せっかくなのでこのデータを生成AI「Claude(クロード)」に渡して、弊社の働き方を分析させてみることにしました。
結果からいうと、単純な0/1のデータからでも、思っていたより多くのことが見えてきました。
システム構成
まず今回のデータがどう収集されているかを整理します。
- センサー:CPI-J
- IoTゲートウェイ:OpenBlocks IoTシリーズ
- 時系列DB+可視化サーバー:OpenBlocks IDM
- 分析:Claude(チャット形式で対話)
以前に、本構成を社内設置した記事、設定等の解説記事を公開していますので興味ある方はこちらの記事から読むことを推奨します。
データの素性と前処理
CPI-Jは、人の動きを検知すると毎分1回データをゲートウェイに送信する仕様です。
値は「使用中=1」「未使用=0」のシンプルな2値、今回OpenBlocks IDMからエクスポートしたCSVには、TIME(タイムスタンプ)・VALUE(0/1)・COUNT の3列が含まれていました。
期間は2022年4月1日〜2026年5月10日の約4年強。コロナ禍はおおむね過ぎた時期からの記録となっています。
(参考までに、最後の緊急事態宣言は”2021年9月”、まん延防止等重点措置は”2022年3月”でした。)
単純集計の罠
まずCSVを単純に集計してみたところ、会議室の利用率73%という値が出ました。
ですがそこまで高い利用率になるはずがなく、確認すると原因はこのセンサーがイベント駆動でデータを送ってくる点にありました。
「使用中」を検知している間は毎分1が送られてくる一方、「未使用」状態は連続的には送られず、状態変化のタイミングや数時間ごとの定期送信でしか0が来ない、つまり生データの行数を数えると、当然ながら1の方が多くカウントされます。
そこで、データを1分単位のグリッドに整え直し、最後に受信した値を次の値が来るまで保持する形(前方補完)で連続時系列に変換しました。
これで初めて、「ある時刻にその会議室が使用中だったかどうか」を時間方向に正しく集計できます。
なお、地味な前処理ですがIoTデータをClaudeに渡す前にやっておかないと、AIから返ってくる結論ごと盛大に間違うことになります。

生データをそのまま投げるのではなく、データの取り方の癖を理解した上で適切な集計をかけるのが重要だという当たり前の話を改めて実感しました。
3つの会議室を並べてみる
今回分析に使ったのは、社内利用が中心の「D会議室」、来客対応にも使う「C会議室」、そして社内・来客を問わず広く使われている「プレゼンルーム」の3部屋です。
いずれも社内打ち合わせで使うことはありますが、用途や設備の違いが利用パターンに差を生んでいます。
なお、弊社の定時は9:30〜18:00なので、以降の集計はこの時間帯(平日のみ)を基本としています。
全体像:月次推移

長期的な傾向として、3部屋とも利用率は緩やかに右肩上がりで、プレゼンルームは早い時期から40%台で推移し、D会議室はじわじわと利用率を伸ばしています。
C会議室は他2部屋に比べると低めの水準で安定しています。
特にD会議室は、2022年は25〜30%台だったのが、2025年以降は40%を超える月が増えてきています。
コロナ禍からの出社回帰がデータにも表れているように見えます。
年別の利用率

年ごとに集計してみると、3部屋でコロナ明けからの伸びに違いがあるのがわかります。
- D会議室:27.7% → 39.2%(約1.4倍)
- C会議室:14.9% → 19.3%(約1.3倍)
- プレゼンルーム:35.7% → 46.4%(約1.3倍)
D会議室の伸びが最も大きく、社内利用が中心の会議室ほど出社回帰の影響を受けやすかった、という解釈もできそうです。
曜日別の傾向

曜日別に見ると、3部屋それぞれに個性が出てきます。
- D会議室は火曜がピーク(40.7%)、金曜が最も低い(29.2%)
- C会議室は曜日差が小さく、水曜がやや高い程度
- プレゼンルームは金曜がピーク(49.2%)
時間帯別の傾向

時間帯では、D会議室とプレゼンルームが12時に明確なピークを持ちます(53%)。
一方でC会議室は12時に山がなく、むしろ13時以降にゆるやかに利用率が上がる、おそらくランチタイムに使用されているのかと思われます。
もう一つ目を引くのが、プレゼンルームの17時以降の粘り強さです。他の2部屋が17時以降は急速に利用率を落とすのに対し、プレゼンルームは17時でも40%台を維持しています。
曜日×時間帯のヒートマップ
単純な平均値だけでは見えないパターンを掘り下げるために、曜日と時間帯を掛け合わせたヒートマップを作ってみました。
D会議室

D会議室は火曜の10時と14時に明確なピークがあり、火曜午前と午後に何らかの定例会議が入っているようです。それ以外はランチタイムの12時を中心に幅広く使われています。
C会議室

C会議室は突出したセルが少なく、全体的にフラットです。特定の曜日・時間帯に定例があるというより、必要な時に必要なだけ使われている、という性格が見て取れます。
プレゼンルーム

プレゼンルームのヒートマップでは3つの「赤い塊」が浮かび上がってきました。
- 月曜17時:78%(飛び抜けて高い)
- 金曜13時:87%(4年間で最も高いセル)
- 水曜9〜10時台:44〜56%(連続して高い)
単純な数字の山ではなく、この時間にほぼ確実に誰かが会議をしている、という強いシグナルになりそうです。
センサーが「定例会議」を見つけた
上のヒートマップが示すパターンを、Claudeに「この3つの突出したセルから何が読み取れるか」と聞いてみたところ、返ってきた答えは「定例会議が開催されている可能性が高い」というものでした。
実際、プレゼンルームの月曜17時と金曜13時には、心当たりがありました。
- 月曜17時:社内会議(毎週)
- 金曜13時:社内会議(毎週)
30分刻みで詳しく見ると、より明確になります。

月曜は16:30の37%から17:00で79%へ一気に跳ね上がり、17:30まで76%を維持する。会議が17時ピッタリに始まり、30分以上続く様子がデータに刻まれています。
金曜は更に明瞭で、13:00〜13:30が88%、13:30〜14:00が85%。4年分のデータを平均してこの値ということは、ほとんど毎週この時間帯に会議が入っています。
社内に聞かないとわからない情報を、人感センサー1個と4年分のデータから自動的に検出できました。
ひとつの謎
3つ目の「赤い塊」、水曜9時〜10時台です。
弊社の定時は9:30からで、9:00台はそもそも定時前です。
にもかかわらず、水曜の9時台にプレゼンルームの利用率が38%、9:30〜10:00で49%、10時台で58%まで上がる。
月曜の社内会議のような「特定の時刻にスパイクする」パターンではなく、「水曜の朝はじわじわ立ち上がる」という形で出ています。
4年分のデータが「水曜朝、プレゼンルームでは何かが起きている」と告げており、センサーは嘘をつかない。
ということは、特定のメンバーや会議体が定期的に使っているはずですが、ここだけは最後まで謎でした。
まとめ:3つの会議室、それぞれの個性
改めて、3部屋の性格の違いを整理すると以下のようになります。
| 項目 | D会議室 | C会議室 | プレゼンルーム |
|---|---|---|---|
| 全体利用率 | 35.0% | 16.2% | 42.8% |
| ピーク曜日 | 火曜 | 水曜 | 金曜 |
| ピーク時間帯 | 12時(53%) | 15時(19%) | 12時(53%) |
| 夕方の傾向 | 17時以降は急減 | 夕方も控えめに継続 | 17時でも40%台で粘る |
同じオフィスの3つの会議室なのに、利用率も曜日パターンも時間帯の癖も、見事に違います。
社員の感覚としては「いつも会議で埋まっている」「あの部屋は人気がない」程度のぼんやりした認識だったものが、4年分のデータを並べてみると、はっきりとキャラクターが浮かび上がってきました。
おわりに
今回やったことは、技術的にはそれほど大したことではありません。
CPI-Jが拾った人の動きを、OpenBlocks IoTで受け取り、OpenBlocks IDMに蓄積したデータをCSVで吐き出して、前処理してClaudeに渡しただけです。
しかし、こうして書き出してみると、4年前から地味に取り続けてきたデータが、AIと組み合わせることで「会社の働き方の定点観測レポート」に変わることがわかりました。
コロナ明けからの出社回帰、ランチタイムの使用、毎週同じ時間に開かれる定例会議の存在、これらは社員の体感としてなんとなく知っていたことでした。しかしデータで裏付けられると説得力が違います。

IoTで取ったデータを「可視化して終わり」ではなく、「AIに読み解かせる」段階に進む時代になってきているのかと思います。
IoT全盛期のころからよく「データ分析したい」「予知保全したい」など様々なお話がありましたが、これらは全て、過去のデータを蓄積できていることが大前提となります。
会議室センサーに限らず、温度・照度・ドアの開閉・電力消費など、IoTで取れるデータは無数にあります。それらをOpenBlocks IDMのような時系列データベースに溜めておけば、後からこういう形で活用できる、という事例の一つとして読んでいただければ幸いです。


