Near Shadings警告が意味することを整理する
PVsystの画面では、近傍遮蔽に関する機能名として主にNear Shadingsが使われています。これは、建物、壁、樹木、設備、地形、隣接するPVテーブルなど、PVアレイの近くにある物体がつくる影を3Dシーンで評価する機能です。遠方の山並みや地平線は、原則としてHorizonによる遠方遮蔽として別に扱います。
最初に押さえたいのは、PVsystに単一の「Near Shadings警告」があるわけではないことです。表示される警告やエラーには、3DシーンとOrientationまたはSystemの不整合、PV面積やモジュール数の不一致、オブジェクトの交差、計算モードの組み合わせ、Module Layoutの定義不足など、異なる原因があります。一方、現実に列間影が発生していても、それだけで必ず警告が出るとは限りません。
したがって、警告を見たら最初に行うべきことは、警告を消す操作を探すことではなく、表示された文面をそのまま記録することです。画面名、対象のOrientation、表示色、シミュレーションを続行できるか、使用中の計算モードも併せて残します。文面を一般化して「影が多すぎる警告」と解釈すると、原因を取り違えるおそれがあります。
Near Shadingsの評価では、二つの確認を分ける必要があります。一つは、PVsystが検出する定義間の不整合を解消することです。もう一つは、ソフトウェアが自動では判定できない現地寸法や設計条件の正しさを検証することです。警告が消えても、遮蔽物の高さや座標が誤っていれば、計算結果は誤った入力に基づいたままです。
本記事では、Near Shadings画面周辺で警告や不自然な損失が見つかったときに、原因を切り分ける7つのチェックポイントを整理します。メニュー名や表示文言はバージョンによって変わることがあるため、実際の警告文と使用中バージョンの公式ヘルプを優先してください。
チェック1 3Dシーンと実際の配置条件を照合する
最初に、3Dシーン、Orientation、Systemの三者が整合しているかを確認します。PVsystは3Dシーンを閉じる際などに、PV面の方位・傾斜、Orientationの割り当て、Systemで定義したモジュール数やPV面積との対応を確認します。不一致の程度によっては警告のまま計算を続けられる場合もあれば、修正しないとシミュレーションへ進めない場合もあります。
確認項目は、方位角、傾斜角、Orientationのグループ分け、PVテーブル数、モジュール数、PV面積、設置範囲です。複数方位、東西配置、屋根ごとに傾斜が異なる案件では、見た目が似ていても異なるOrientationとして扱うべきケースがあります。反対に、CADデータの取り込み時に細かな角度差が多数のOrientationとして認識され、Systemとの対応が崩れることもあります。
ここで注意したいのは、PVsystによる面積チェックが現地寸法の正しさを保証するものではない点です。PV面の面積がSystem側のモジュールを配置できる大きさでも、実際のモジュール外形、離隔、通路、架台寸法まで自動で妥当と判定されるわけではありません。面積の整合と、実施設計としての成立性は別に確認します。
次に、最新の配置図、架台図、屋根伏図、断面図、測量成果と3Dシーンを照合します。設計変更前のシーンを複製している場合は、削除漏れのPVテーブル、旧配置の遮蔽物、重複オブジェクトが残っていないかを確認してください。原点、座標軸、単位、北方向の扱いが異なるデータを組み合わせると、全体が正しい形のまま位置だけずれることがあります。
3Dシーンの見た目だけで判断せず、少なくとも一つの既知寸法と一つの既知方位を使って、縮尺と回転を検証します。警告が消えていることではなく、現地と設計の基準に対して3Dシーンが説明できることを完了条件にします。
チェック2 モジュール面と遮蔽物の位置関係を確認する
次に、PV面と遮蔽物の位置関係を確認します。屋上のパラペット、設備基礎、壁、手すり、配管、隣接建物、樹木などは、位置、高さ、幅によって影の時刻と範囲が変わります。入力値が不明な物体を推定で置いた場合は、確定値と同じ扱いにせず、仮定であることを記録してください。
特に確認したいのが、PV面と他のオブジェクトの交差です。PV面が屋根や遮蔽物にめり込んでいる、同一面に重なっている、複製したPVテーブル同士が重なっていると、シーンの妥当性エラーや不自然な遮蔽計算につながります。公式ヘルプでも、オブジェクトの交差は正しい影計算を妨げる可能性があるため、避けるよう案内されています。
近接して見えるだけで実際には離れている場合もあるため、上面、正面、側面など複数の視点で確認します。必要に応じて座標値を直接確認し、画面上の見た目だけで離隔を判断しないことが重要です。交差チェックを無効化できる設定がある場合でも、単にエラーを回避する目的で使わず、形状と離隔を検証したうえで判断します。
また、オブジェクトが影を落とす設定になっているかも確認します。3Dシーンに表示されていても、影を落とす属性が無効なら遮蔽物として計算されないことがあります。反対に、位置合わせ用の補助物体や不要な詳細部品が影を落とす設定になっていると、計算時間や損失に影響します。
原因の確認には、日付を変えた影アニメーションと、太陽方向からの表示が有効です。冬季、夏季、朝、正午、夕方を確認し、どの物体がどのPV面に影を落としているかを特定します。樹木のように形状や高さが変化する対象は、単一の精密値として扱うより、現況と将来想定を分けたケース比較が安全です。
チェック3 アレイ間隔と列間影の発生条件を見直す
地上設置、陸屋根、折板屋根、傾斜架台では、前後列のPVテーブルによる相互遮蔽が損失の主要因になることがあります。ただし、列間影が存在すること自体は必ずしも入力ミスではなく、敷地利用率と遮蔽損失のバランスを取った設計結果の場合もあります。
まず、図面の「列間隔」が何を示す寸法かを確認します。モジュール端部間、架台端部間、基礎芯間、PVテーブルの基準点間では値の意味が異なります。PVsystのオブジェクトで使われるPitchなどの定義と、図面寸法の基準が一致しているかを確認し、名称だけで同じ寸法と判断しないでください。
列間影は、列ピッチだけで決まりません。モジュール面の幅、傾斜角、下端高さ、前後列の相対高さ、地盤勾配、方位によって変わります。同じピッチでも、南北方向の高低差や架台高さが異なれば、影の発生時間と範囲は変化します。
影アニメーションやiso-shading図を使い、低太陽高度時にどの列から影が始まるかを確認します。年間損失だけでなく、月別結果や代表日の時刻別挙動も確認すると、冬季に集中する影と通年で発生する影を分けやすくなります。ただし、年間値が小さいという理由だけで、特定の設備やストリングへの集中影を無視しないことが重要です。
トラッカーを使用する案件では、列ピッチやGCRに加えて、バックトラッキングの基準設定と3Dシーンの整合も確認します。バックトラッキングを設定していても、地形差や不均一なピッチにより相互遮蔽が残る場合があります。警告の有無ではなく、代表日の日射条件で実際の影を可視化して判断します。
列間影を減らすためにピッチを広げると、同じ敷地に置ける容量が減る可能性があります。したがって、損失ゼロを一律の目標にせず、設備容量、年間発電量、施工性、保守動線、造成条件を含む複数案で比較します。
チェック4 地形差と設置高さの入力ずれを確認する
傾斜地、造成地、段差のある屋根、複数棟の屋上では、高さ方向の入力がNear Shadings結果を大きく左右します。平面位置が正しくても、Z座標や基準高が異なれば、PVテーブルと遮蔽物の相対関係は変わります。
最初に、高さの基準を統一します。現況地盤、造成計画高、建物床、屋根面、架台基礎、モジュール下端など、図面ごとに異なる基準が混在していないかを確認してください。絶対標高と相対高さを組み合わせる場合は、変換方法と基準点を記録します。
屋上案件では、屋根面の高さだけでなく、パラペット上端、設備基礎上端、室外機やダクトの最高部、架台脚、モジュール面の下端と上端を区別します。地上設置では、造成前の測量データと造成後の設計高を混同しないことが重要です。設計段階に応じて、現況ケースと造成後ケースを分ける方法もあります。
地形データや3Dデータを取り込んだ場合は、単位、原点、回転、鉛直方向、簡略化の程度を確認します。高密度なデータは精細に見えますが、不要なポリゴンが多いと計算負荷が増えます。反対に、簡略化しすぎると局所的な段差や法面を失う可能性があります。必要な遮蔽要因を残しつつ、計算目的に合う密度へ整理します。
PVsystは地上画像、地形データ、対応する3D形式を利用できますが、取り込みに成功したことと位置・縮尺が正しいことは同義ではありません。既知点や既知距離で検証し、PVテーブルが地形上の意図した高さに置かれているかを断面表示でも確認します。
一部のエリアだけ損失が大きい場合は、その区域のZ座標、地形への追従、架台高さ、Orientationの割り当てを重点的に確認します。局所的な異常は、全体の平均値では見つけにくいため、区域別にシーンと結果を比較することが有効です。
チェック5 遮蔽計算の設定と適用範囲を確認する
3Dシーンが正しくても、Use in simulationで選んだ計算方法が目的と合っていなければ、結果の解釈を誤ります。Near Shadingsでは、少なくとも幾何学的な日射欠損と、部分影による電気的不整合を分けて考える必要があります。
Linearは、PV面で失われる日射量を評価し、電気的不整合による追加損失は含めません。遮蔽の幾何学的影響を確認する基準ケースとして有効ですが、部分影がストリングやサブモジュールへ与える影響を詳細に表すものではありません。
According to Module stringsまたはPartitionsを使う方法は、PVテーブルを区画に分けて電気的影響を近似する方式です。規則的な列間影には適用しやすい一方、不規則な建物影や樹木影では近似誤差が大きくなり得ます。一般に保守的な上限側の評価となるため、Fraction for electrical effectを根拠なく下げて期待値へ合わせる運用は避けます。
Detailed, according to Module Layoutは、各モジュールの位置、ストリング、サブアレイ、MPPTとの対応を定義して、より詳細に電気的損失を計算する方法です。ただし、定義後に3DシーンやSystemを変更すると対応関係が崩れることがあるため、再確認が必要です。また、システム規模、細長い影、対応モジュール技術などに制約があるため、詳細計算を選べば常に正解というわけではありません。
計算には、事前計算したshading factor tableを補間する方式と、シミュレーション中により詳細に計算する方式があります。名称や利用可否はバージョンとモードで異なるため、計算時間だけで選ばず、精度要件と案件規模に合わせます。3Dシーンを変更した後は、必要なテーブルが再計算されているかも確認してください。
大規模案件で一部のPVテーブルだけを代表として計算する機能を使う場合は、その結果が全体へ外挿されることを理解し、選定区域の代表性を検証します。現在の公式ヘルプでは、部分選択による遮蔽計算とModule Layoutを同時に使えない組み合わせも示されているため、設定間の互換性も確認が必要です。
最後に、3Dオブジェクトの影を落とす属性、計算対象のPV面、Orientationごとの適用状況を確認します。「シーンにあるから計算される」「警告がないから全域へ適用されている」とは限りません。
チェック6 電気的影響とストリング分割を見直す
部分影の発電損失は、影面積に単純比例するとは限りません。同じ影面積でも、影がかかるセル列、サブモジュール、モジュール、ストリング、並列回路、MPPTの構成によって電気的損失は変わります。そのため、3D上の影の形だけで電力量への影響を断定しないことが重要です。
まず、実設備の配線図とPVsystのSystem定義を照合します。モジュール枚数、直列数、並列数、インバータ、MPPTへの割り当て、方位別のサブアレイが一致しているかを確認します。複数方位のモジュールや、影条件が大きく異なる区域を同じ電気回路として扱う場合は、その設計意図を説明できるようにします。
Partitionsを使う場合、区画は電気的影響を近似するためのモデルであり、画面上の区画を作っただけで実際の配線を完全に再現したことにはなりません。モジュールの縦置き・横置き、バイパスダイオードで保護されるサブモジュールの向き、影の進行方向を踏まえて区画を設定します。規則的な列間影と、不規則な局所影を同じ精度で扱えるとは限りません。
Module Layoutを使う場合は、各モジュールの機械配置と電気接続を実際の計画に合わせます。PVテーブルの寸法やSystemのモジュール数を変更した後は、以前のModule Layoutをそのまま信頼せず、未割り当てや誤割り当てがないかを確認します。
設計改善を検討する際は、影の多い区域と少ない区域の回路分離、機器位置の変更、アレイ配置の変更などを候補にできます。ただし、シミュレーション上の損失だけで決めず、電圧範囲、MPPT入力条件、配線長、施工性、保守性、安全性も合わせて設計します。
実務では、Linearの基準ケース、Partitionsを使うケース、必要に応じたModule Layoutケースを比較すると、幾何学的損失と電気的追加損失を切り分けやすくなります。差が大きい場合は、どの仮定が差を生んでいるかを確認し、説明できない係数調整で合わせ込まないことが大切です。
チェック7 レポート数値と警告文を説明可能な形に整理する
最後に、警告文、入力条件、計算モード、結果を一つの説明にまとめます。PVsystの警告を消しただけでは、発電量予測の妥当性を説明したことにはなりません。反対に、修正不要と判断した警告が残る場合でも、理由と影響を記録できればレビューしやすくなります。
まず、警告またはエラーの原文、発生画面、対象Orientation、発生条件、対応内容を記録します。3DシーンとSystemの不一致を修正したのか、実在する遮蔽物による損失を受け入れたのか、計算モードの非互換を解消したのかを区別します。
結果確認では、少なくとも次の数値を混同しないようにします。
- 近傍遮蔽による日射量の損失
- 電気的不整合による追加損失
- 年間発電量への影響
- 月別または時刻別に偏った影響
- 設計変更前後の差
loss diagram、iso-shading図、影アニメーション、月別結果、必要に応じた詳細時系列を組み合わせると、どの季節・時間帯・遮蔽物が主要因かを説明しやすくなります。年間値だけでは、冬季朝夕に集中する影や、特定区域だけに生じる影を見落とす可能性があります。
一律の「許容損失率」を根拠なく設定するのは避けます。許容範囲は、契約条件、発電量保証、事業計画、設計方針、代替案の有無によって異なります。数値が小さいから無視するのではなく、入力根拠、影響範囲、改善コストを踏まえて判断します。
レポートには、使用した図面や測量データの版、3Dシーンの版、計算モード、主要仮定、未確定事項を残します。樹木の将来成長、未確定設備、造成高の変更など、結果を変え得る条件が残っている場合は、確定値として扱わずリスクとして明示します。
Near Shadings警告を放置しないための実務フロー
Near Shadings対応を属人化させないため、案件ごとに同じ順序で確認します。
- 警告文を原文のまま保存し、画面名、表示色、使用バージョン、計算モードを記録する
Orientation、System、3Dシーンの方位、面積、モジュール数、割り当てを照合する- 最新図面と既知寸法を使い、原点、縮尺、回転、設置高さを検証する
- 交差、重複、影を落とす属性を確認し、代表日で影アニメーションを実行する
- Linear、Partitions、Module Layoutのうち、検討目的に合う計算方法を選ぶ
- 修正前後を別Variantで比較し、損失差と発電量差の原因を確認する
- 警告への対応、残る仮定、結果への影響をレビュー記録とレポートへ残す
設計変更時には、3Dシーンだけでなく、System、Orientation、Module Layout、shading factor tableも更新対象になり得ます。一つの画面だけ修正して完了とせず、関連定義の再チェックを行います。
また、警告を消すために実在する遮蔽物を削除したり、電気的影響の係数を根拠なく変更したりしてはいけません。修正の目的は、期待する発電量へ近づけることではなく、現地と設計を適切に表すモデルへ近づけることです。
社内レビューでは、警告一覧だけでなく、入力根拠一覧を用意すると効果的です。遮蔽物の高さはどの図面から取得したか、地形は現況か造成後か、樹木は現況値か将来想定か、配線はどの版の結線図に基づくかを明確にすると、後工程の手戻りを減らせます。
まとめ ドローン活用で現地条件の確認精度を高める
PVsystのNear Shadings画面で警告や不自然な損失が見つかった場合は、まず警告の原文を確認し、定義間の不整合と、現地条件の入力精度を分けて検証します。警告は、必ずしも「影が大きい」ことを示すものではありません。また、警告がないことも、3Dシーンが現地を正しく再現している証明にはなりません。
原因特定では、3DシーンとSystem・Orientationの整合、PV面と遮蔽物の交差、列ピッチ、地形と設置高さ、計算モード、実際の電気接続、レポート上の損失内訳を順に確認します。Linear、Partitions、Module Layoutは目的と前提が異なるため、案件規模と必要精度に合う方法を選び、係数や区画の根拠を残すことが重要です。
現地情報の不足を補う手段として、ドローン撮影、オルソ画像、写真測量による3Dデータは有用です。屋根設備、周辺構造物、法面、造成状況などを面的に確認でき、図面との差分を見つける助けになります。ただし、撮影しただけで測量精度が保証されるわけではありません。重要寸法には、適切な基準点、座標・縮尺管理、必要精度を満たす測量または実測を用い、成果の精度を確認します。
ドローン由来の画像や3DデータをPVsystで使う場合も、対応形式への変換、原点、単位、回転、ポリゴン数、影を落とす属性の確認が必要です。データを直接取り込めるとは限らないため、PVsystへ渡す前に、遮蔽評価に必要な情報へ整理します。
Near Shadings対策の本質は、警告を非表示にすることではなく、入力と結果を説明できる状態にすることです。図面、現地確認、測量、ドローンなどを目的に応じて組み合わせ、再現性のある確認フローを整えることで、発電量予測と設計レビューの信頼性を高められます。