【RYOKI ENERGY株式会社】太陽光発電所の故障予知システム「AiPCSi」のUI/UXデザイン・開発
1200x630.png)
Tweet
Share
【RYOKI ENERGY株式会社】太陽光発電所の故障予知システム「AiPCSi」のUI/UXデザイン・開発
アンカーデザインは、RYOKI ENERGY株式会社様の太陽光発電所のパワーコンディショナーの故障予知システム「AiPCSi（アイピクシー）」のUI/UXデザインおよび開発を一気通貫で担当させていただきました。本レポートでは、ハードウェア監視と現場作業をシームレスに繋ぐ本プロジェクトの設計・開発プロセスについてご紹介します。
プロジェクト概要
- Client: RYOKI ENERGY株式会社
- Service: 太陽光発電所のパワーコンディショナーの故障予知システム「AiPCSi (アイピクシー)」
- Role: UI・UXデザイン / システム開発
- Launch: 2024.01
背景と目的
ハードウェアの数値と、現場の目視点検。2つの視点で発電所を守る。
RYOKI ENERGY株式会社様は、カーボンニュートラルに向けたエネルギーソリューション事業を展開しています。今回、太陽光発電所の状態を管理・監視するシステム「AiPCSi」の新規立ち上げにあたり、アンカーデザインがUI/UXデザインおよび開発を担当させていただきました。
本プロジェクトの目的は、RYOKI ENERGY様の発電所での実証実験（PoC）を起点に、将来的な外部事業者への展開を見据えた、拡張性の高い監視・管理システムを構築することでした。
「AiPCSi」には、太陽光発電所のパワーコンディショナー内に設置されたセンサーから得られる「温度・湿度・電流」といった定量的データによる監視機能に加え、保守作業員による「目視点検報告」という定性的な情報を統合し、異常を早期に発見・特定することが求められました。
システム設計
複数の立場の人が関わる業務システムのUIデザインでは、画面構成や機能を検討するために、業務と意思決定の構造を正しく理解することが欠かせません。
UIは単に情報を表示し、システムを操作するためのものではなくユーザーの適切な判断をサポートするためのインターフェースです。この前提を曖昧にしたまま設計を進めると、使いにくさだけでなく、判断の遅れや不適切な判断、あるいは責任の所在の不明確さといった運用上の問題につながります。
そのため業務システムのUIデザインにおいて下記のような点を明確に定義する必要があります。
ステークホルダー：誰がシステムに関わり、どの情報に責任を持つのか
通常、システムを利用する人には様々な立場の人が存在します。例えば本システムの場合、太陽光発電所にてメンテナンスなどの作業をしてくださる方や、システムを通して発電所の様子を把握する方、あるいはシステムの管理や承認をする方、さらにはデータの閲覧のみを行う立場の方などが挙げられます。これら関与する人物とその役割を明確にします。
ユースケース：各立場の人が、いつ・どこで・何を行うのか
現場、事務所、移動中など利用シーンの違いも含め、どのタイミングでどのような情報を確認する必要があり、どのような操作が発生するのかを整理します。
意思決定フロー：どのアクションに対して、誰が最終的な意思決定を行うのか。
承認が必要な判断と、現場で完結してよい判断を区別し、UI上で混同が起きないように設計することが重要です。
これらを整理した上で、必要な機能要件や画面構成を導き出します。単に機能を並べるのではなく、業務と判断の流れを支える構造としてUIを設計することで、運用開始後も迷いが生じにくい、堅牢なユーザー体験が実現できます。
今回のAiPCSi開発においても、こうした観点から業務構造を整理した上で設計を行い、PoCフェーズにとどまらず、将来的な拡張や運用を見据えたUI設計を行いました。
デザインアプローチ
「AiPCSi」の主要なユーザーは大きく2つに分けられます。オフィスなどからリモートで発電所の状況を把握し適切な指示を出す方々と、太陽光発電所の現場（時に過酷な環境下となります）で各種設備の保守点検作業をする方々です。
私たちは、この双方にとってストレスのないUXを目指しました。保守作業は、外部委託や一時的な人員によって実施される可能性もあり、利用者が固定されないことが想定されていました。こうした前提のもとでは専用のネイティブアプリを配布・管理するよりも、URLにアクセスすればすぐに使えるWebベースのアプリの方が運用上の負荷を抑えられます。一方、管理者向けの画面では、PCから多くの情報を俯瞰できる情報設計としています。
1. 柔軟な異常検知ステータス
本システムは実証実験（PoC）の側面も持っているため、運用開始時点ですべての仕様を固定しきることはリスクとなります。そのため監視対象となる「電流値」「PCSの室内温度」「冷却ファンの稼働状況」のそれぞれに対し、管理画面側で柔軟にしきい値を設定することを可能としました。 単なるOK/NGの判定ではなく、しきい値に応じて「正常」「注意」「異常」の3段階でステータスを分類することで危険な状態になる手前の「注意」段階で早期発見を促せるよう、RYOKI ENERGY様と議論を重ねながら、運用を通じてシステム自体の精度をチューニングしていける拡張性を持たせた設計としています。
2. 確実な位置情報共有
太陽光発電所には無数のソーラーパネルが並んでいますが、パネルの1枚1枚にIDが振られ地図上で管理されていることは稀でありストリング（直列につないだ数十枚）や架台ブロック／列単位で管理されることが一般的です。これでは、現場の作業員がどのパネルで破損を見つけたのかチームで正確に共有することが困難です。Googleマップ等の地図サービスを活用することも検討しましたが、これら一般的な地図サービスでは広大な発電所内にある無数のソーラーパネルの正確な配置までは表示されません。
そこで「AiPCSi」では、独自の位置情報共有の仕組みを設計・実装しました。これにより、位置情報の伝達ロスを極限まで減らすことを目指しました。
3. 確実に状態を把握してもらう仕組み
ダッシュボードによる能動的な監視に加え、受動的な情報共有の仕組みも導入しました。 システムが自動でデータを集計し、週に1回、および月に1回の頻度で「状態レポート」を管理者にメール配信します。これにより、管理者がダッシュボードにログインしていない期間があっても、発電所の稼働状況や異常の有無を定期的に把握できるセーフティネットを構築しました。
インフラ構成
AiPCSiは、24時間365日、全国の発電所から継続的にデータを受け取り続けるシステムです。さらに本プロジェクトはPoCの側面も持っており、将来的に拠点数やデータ量がどの程度まで拡大するかを、事前に正確に見積もることはできません。そのためインフラには特定の構成に固定せず、負荷や規模の変化に応じて柔軟にスケールできる設計が求められました。
そこで本プロジェクトでは、運用負荷を最小限に抑えつつ、拡張に耐えうる基盤として、AWS（Amazon Web Services）においてフルマネージドなサーバーレス・アーキテクチャを構築しました。
アプリケーションの実行基盤にはAWS App RunnerやAmplify、AWS Lambda を用い、アクセス数やデータ量の増加に応じてインフラ側が自律的にリソースを拡張する構成としています。これにより、拠点数の増加や利用状況の変化に対しても、システムを止めることなく段階的にスケールさせることが可能です。
こうした構成により、「止めないこと」を最優先としながら、将来的な拡張や運用コストの増大にも対応できる基盤を整えています。
おわりに
本プロジェクトを通して改めて感じたのは、複雑な業務システムにおいてこそ、設計がチーム全体の判断と実装を支える基盤になるということです。
誰が、どの情報を見て、どの判断を行うのか。利用環境や運用の前提はどうなっているのか。そうした構造を開発前に丁寧に整理し、「迷いのない設計図」を共有できたことが、開発フェーズにおけるスムーズな役割分担と効率的な実装につながりました。
一見するとオーソドックスなアプローチですが、プロジェクトごとの前提を見極め、「何を決め切るべきか」を設計段階で定めることが、不確実性の高い開発を前に進める確かな方法だと、私たちは考えています。
.png){kind=small}
