国立研究開発法人 産業技術総合研究所（以下、産総研）のゼロエミッション国際共同研究センターでは、家庭のエネルギー消費データをはじめとする大規模な時系列データに基づく社会システムの研究を進めています。
研究で扱うデータ量は数十億～数百億レコード、さらには1兆レコード級へと拡大している中、従来のオンプレミス環境だけでは対応が難しい局面を迎えたことをきっかけにSnowflake AIデータクラウド（以下、Snowflake）を導入しました。現在は、AIコーディングエージェントのSnowflake CoCoを活用しながら、研究のためのデータ解析を加速させています。
今回は、同センターのデータ駆動型社会システム研究チームで研究チーム長を務められている本田 智則氏と、導入を支援したDATUM STUDIOの子会社であるちゅらデータのシニアデータエンジニア 倉富に、Snowflake導入の背景から基盤構築時の苦労と導入後の効果、そして今後の展望について、話を伺いました。
右：ちゅらデータ株式会社 シニアデータエンジニア 倉富 優
オンプレミス環境が抱えていた課題
－貴チームのミッションと、研究概要について教えてください。
本田氏：産総研のゼロエミッション国際共同研究センターは9つのチームで構成されており、私が率いるデータ駆動型社会システム研究チームは3名の研究者と学生など約30名で、スマートメーターのデータや機器の制御データなど、エネルギー関連のデータを用いて「データ駆動型社会システム」の実現を目指し研究しています。
特に、住宅に設置された太陽光発電システムや蓄電池、給湯器などの家庭エネルギー機器を制御することにより、温室効果ガスの排出削減と生活者の快適性、そして経済性を両立させる機器制御技術の開発に取り組んでいます。
従来は、「平均的な世帯」を仮定して制御を考えることが多かったのですが、現代の暮らし方や価値観は非常に多様化しています。そのため、統計的には意味があっても、仮定した「平均的な世帯」というものは、ほぼ実在しないといった問題を抱えていました。加えて、家庭に設置される機器も多様化し、その制御の難易度も上がっています。
たとえば、太陽光発電や蓄電池、EVなど家庭内のエネルギー機器が増え、使用タイミングが重なれば電柱の変圧器の容量を超える恐れもあるため、各機器の稼働を調整する「制御」が必要です。また、世帯ごとに「節約重視」か「快適重視」かといった価値観も異なり、画一的な制御では各家庭のニーズに応えきれません。
そこで仮説ではなく、実データから個を捉える方向に転換しました。
家庭内機器レベルのDSR（※1）として、太陽光発電、蓄電池、空調機、給湯器、冷蔵庫などの制御技術を開発し、複数機器・複数世帯、さらには約100世帯規模の街区単位での最適制御に取り組んでいます。
外部から制御をかける以上、利用者に経済的損失を与えてはなりませんので、電力会社と協力した料金モデルの設計や、柱上変圧器・変電所を含む系統側への「影響評価」が欠かせません。
こうした制御・予測を実現する技術として、私たちは強化学習モデルを用いています。時系列計算に特化したスーパーコンピューター「GAMA（※2）」や、国内最大級のAI専用スーパーコンピューター「ABCI（※3）」を活用しています。
また、実験用の住宅1棟をデジタルツイン化（※4）し、断熱性能や地域条件を変えたシミュレーションも行っています。
※1：Demand Side Resourcesの略。一般家庭などユーザー側に存在する発電設備、蓄電設備、電気自動車、空調など電力リソースの消費設備の総称
※2：産総研が運用するスーパーコンピューター・集合知解析基盤。家庭を中心とした膨大なエネルギー消費実態データを蓄積している
※3：AI Bridging Cloud Infrastructureの略。産総研が構築・運用する、AI技術開発に特化した国内最大級のオープンな計算インフラ
※4：現実の建物をデジタル空間上に再現し、様々な条件でシミュレーションする技術
－産総研で扱われているデータの規模と、オンプレミス環境で直面された課題について教えてください。
本田氏：産総研では、約20万世帯分の住宅エネルギーデータを収集しています。30分・1時間ごとの消費電力データを含めたデータ規模は、数十億～数百億レコードに及んでいます。
さらに近年は、時間解像度を1分、15秒、5秒単位まで高める必要性が高まってきました。帰宅後すぐに空調のフィードバック制御を行いたい場合や、機器の故障を早期に検知したい場合、データの解像度が粗ければ対応が遅れたり予兆を見逃してしまうため、解像度が高いデータが必要とされるのです。
たとえば、15秒単位・10万世帯・住宅内6系統（発電、蓄電、放電、売電、買電、給湯）という条件を掛け合わせると、年間で約1.3兆レコードになります。この規模になるとGAMAでも太刀打ちできず、データベース基盤そのものを見直す必要に迫られていました。
加えて、オンプレミス環境は計算能力が固定的で、10～20人の利用者が散発的に使う一方、必要時には一気に高負荷になるため、常時高性能な設備を持っていても稼働率は決して高くありませんでした。
データ規模の拡大に伴い、分散台数を100～200台規模に増やしたい場面が出てきましたが、サーバールームの収容力の限界もありました。
Snowflakeの導入プロセスと活用後の効果
－導入にあたって、難しかった点はありますか。
倉富：民間企業のデータ基盤構築では週次・日次で定常的にデータを投入する運用を前提に設計することが多いのですが、産総研さまの場合は多種多様なデータをイレギュラーなタイミングで投入する必要があるとお聞きし、定常的なETL処理を組むシステムではないと理解しました。プロジェクト開始後は、研究用途に合わせた必要機能をヒアリングしながら導入を進めていきました。
その中で難しいと感じたのは、既存の分析ツールとSnowflakeの接続です。単純に接続するとクライアント側でデータを処理する形になり、Snowflakeが単なるデータの置き場所になってしまいます。計算リソースを使える接続形態を実現するにあたって、前例や資料も少なく調査に時間を要したのが印象に残っています。
－セキュリティや運用面においては、どのような点に配慮しながら設計されたのでしょうか。
倉富：Snowflakeをはじめとしたクラウド製品全般に言えることですが、コスト管理やアラートの設計は当然必要になります。加えて、各ユーザーに必要範囲での権限を付与するよう、コードで権限設定ができる設計にしました。
ネットワーク面では、Snowflakeをインターネット上に公開せず、AWS PrivateLinkやVPNを用いたプライベート環境でのネットワーク構成とすることで、データ漏洩のリスクをさらに軽減できています。
本田氏：当研究機関内においては、公開可能情報と非公開情報によって取り扱いが分かれています。
企業から提供されたデータをはじめとする非公開情報を扱うにあたっては、ISMAP（※5）に登録されたサービスであることが前提条件だったので、SnowflakeがISMAPに登録されていたことも採用を後押しした理由の一つになりました。
また、オンプレミス環境のみで取得していたISMS（ISO/IEC 27001）やプライバシーマーク（JIS Q 15001）といった情報セキュリティ・個人情報保護関連の認証についても、Snowflakeを含めて認証範囲の拡張を進めていこうと考えています。
※5：Information system Security Management and Assessment Programの略。政府が求めるセキュリティ要件を満たすクラウドサービスをあらかじめ評価・登録し、政府調達におけるセキュリティ水準を確保するための制度
－実際にSnowflakeを使ってみて、良かった点を教えてください。
本田氏：特に利便性を実感しているのは、ウェアハウスのサイズを任意で変更できる点です。従来は、データ量が6倍になれば処理時間も比例して6倍になる感覚でしたが、SnowflakeではX-Largeから3X-Largeへサイズを変更することで、同程度の時間で処理を完了できます。
さらにAdaptive Warehouse（適応型ウェアハウス）の登場により、サイズの選定自体をSnowflakeが自動で行ってくれるようになり、時間とコストの両面でさらに最適化しやすくなっています。
また、直近ではAIコーディングエージェント「Snowflake CoCo」との親和性の高さも実感しています。以前は他の生成AIソリューションを用いてSQLを生成しており、その精度やコストパフォーマンスに課題がありましたが、Snowflake CoCoの登場によりエラーによるやり直しが格段に減りました。
従来はデータ基盤を1～2週間ほど占有してしまうため実行をためらっていた大規模解析も、こうした改善の積み重ねで実行しやすくなりました。約6時間かかっていた処理が30分～1時間程度まで短縮されることもあります。
倉富：Snowflake CoCoは、基盤を構築した当時まだリリースされていませんでしたが、お客さまの課題解決や業務効率の向上に寄与できるよう、都度最新機能の情報をキャッチアップし、見直しを重ねながら進めています。
－一方で、コスト面はいかがでしょうか。
本田氏：Snowflakeはクレジット課金モデルなので、研究機関特有の「試しにやってみて、違ったらやめる」という探索的な試行をする際には、当然のことながら注意が必要です。
コスト最適化のための対策として、オンプレミスとSnowflakeを併用し、Snowflakeが得意とする高速処理は優先して任せるなど、用途に応じて使い分けながら運用しています。
倉富：ローカルからAmazon S3へ効率よくアップロードするコマンドをご提案したり、1ファイルあたりのサイズ設計やSnowflake側で取り込みやすい単位への分割方法について、ご支援させていただきました。分割の仕方によって取り込み効率は大きく変わってきます。
取り込み効率が改善されれば計算時間が減り、結果としてコストの最適化にも貢献できるので、一見地味な取り組みに思えますが重要なポイントですね。
今後の展望
－今後のSnowflake活用について、実現されたいことはありますか。
本田氏：専門的な数理アルゴリズムを使った分析は今後も継続していくので、引き続き大いに活用していきたいと思います。
一方、企業との共同研究においては、共同研究先を含む外部の利用者にとって使いやすい仕組みへとアップデートしていきたいと考えています。
今考えている理想は、自然言語で「こんな異常はないか？」と問い合わせると、データに基づく分析結果を返してくれる仕組みです。実現に向けた手応えは感じていますが、まだ十分とは言えないので、引き続き取り組んでいきたいと思います。
－最後に、同じような課題を持つ研究機関や企業に向けて、アドバイスをお願いします。
本田氏：Snowflakeに限定せず、「自分たちが実現したい研究に対して、技術的に何が必要か」を軸に検討することだと思います。私たちの場合は、それによって従来は難しかった大規模解析が、現実的な時間で実現できるようになりました。
また、コスト管理では「やるべきこと」と「やらないこと」を決めて運用することが、私たちにとって最も重要な前提条件でした。同じ課題を持つ方には、ぜひ参考にしていただければと思います。
倉富：お客さまによって課題や実現したいことは千差万別で、共通の正解があるわけではありません。お客さまとディスカッションを重ねながら、最適解に導くことが私たちの使命であると考えています。ぜひお気軽にご相談ください。
