目次
•
•
•
•
•
•
•
•
•
•
•
PVSyst マニュアルで最初に押さえるべき全体像
PVSyst マニュアルを探している人の多くは、「画面操作の手順を知りたい」というだけでなく、「どの入力値をどこまで確認すれば、太陽光発電シミュレーションとして信頼できるのか」を知りたいはずです。PVsystは太陽光発電システムの検討、サイズ設計、データ分析を行うPCソフトで、系統連系、独立型、ポンプ、DCグリッドなど複数のPVシステムを扱えます。公式ドキュメントでは、気象データ、コンポーネントデータベース、各種太陽エネルギーツールを備え、建築家、エンジニア、研究者、教育用途にも向くソフトとして説明されています。
ただし、PVSyst マニュアルを上から順番に読むだけでは、実務でつまずきやすいポイントを見落とします。太陽光発電の発電量シミュレーションは、単にモジュール容量とPCS容量を入力すれば終わるものではありません。地点、気象データ、方位、傾斜、影、配線、温度、汚れ、劣化、停止、出力抑制などの条件が積み重なり、最終的な発電量、PR、損失図、レポートに反映されます。
公式のグリッド連系チュートリアルでも、PVsystは太陽光発電プロジェクトを設計・最適化し、システム性能、エネルギー収量、財務的な実現性を評価できるソフトとして説明されています。また、同チュートリアルはユーザーマニュアルとして使える一方、完全な参照マニュアルはプログラム内のHelpやオンラインヘルプで確認する位置づけです。
つまり、実務で重要なのは「マニュアルを読むこと」ではなく、「マニュアルを使って設計条件の妥当性を検証すること」です。この記事では、PVSyst マニュアルを使いこなすために、初心者から実務担当者まで確認すべき7つのチェック項目を、入力順ではなく判 断順で解説します。
実務チェック1:プロジェクトの目的を最初に固定する
PVSystで最初に確認すべきことは、どの画面を開くかではなく、「このシミュレーションで何を判断するのか」です。事業計画用の概算、EPC提案用の設計比較、金融機関向けの発電量根拠、PPA単価検討、蓄電池併設、既設設備の性能検証では、必要な精度も入力条件も変わります。
たとえば、同じ「年間発電量」を求める場合でも、初期検討では方位・傾斜・容量の比較が中心になります。一方、融資や技術DDに使う場合は、気象データの出典、影の再現性、損失率の根拠、機器データの整合性、バージョン管理まで求められます。目的を決めずに入力を進めると、あとから「なぜこの損失率なのか」「このPCS構成で本当に良いのか」と説明できなくなります。
PVSystではプロジェクトとバリアントを分けて管理します。公式ドキュメントでは、プロジ ェクトファイル、シミュレーションバリアント、比較バリアント、気象データファイルなどがディレクトリ構造の中で管理されることが示されています。具体的には、プロジェクトに.PRJ、シミュレーションバリアントに.VCi、気象データに.METなどの拡張子が使われます。
この仕組みを理解すると、PVSyst マニュアルの読み方が変わります。1つの正解を作るのではなく、「標準案」「影考慮案」「PCS過積載案」「架台角度変更案」「損失率保守案」など、複数のバリアントを比較しながら設計を詰めるのが実務的です。
チェックする項目
プロジェクト開始時には、少なくとも次の4点を明確にします。
• 用途:概算、詳細設計、提案、融資、性能検証のどれか
• 評価指標:年間発電量、PR、売電量、自家消費量、損失要因のどれを重視するか
• 比較軸:方位、傾斜、容量、PCS比、影、蓄電池、出力制限など
• 提出先:社内検討、顧客、金融機関、EPC、O&M、行政資料など
目的が明確であれば、入力値の精度をどこまで高めるべきか判断しやすくなります。逆に、目的が曖昧なまま詳細な影モデルや細かな損失率を設定しても、レポートの説得力は上がりません。
実務チェック2:気象データと地点条件を確認する
PVSyst マニュアルで必ず確認すべき2つ目のポイントは、気象データです。太陽光発電シミュレーションの出発点は、モジュール容量ではなく日射量です。どれほど正確に機器を選んでも、気象データの出典や地点条件が不適切であれば、発電量推定の信頼性は大きく下がります。
PVsystでは、Meteonorm、PVGIS、NSRDB、Solcast、ユーザー独自の気象ファイルなど、さまざまな気象データを扱えます。公式ドキュメントでは、カスタム気象ファイルをインポートする場合、.MEFというフォーマットファイルが必要で、これが独自データの項目対応を定義すると説明されています。
実務で特に注意したいのは、気象データにすでに地平線や周辺地形の影響が含まれているかどうかです。公式ドキュメントでは、PVsystのサイトデータベースにおけるMeteonorm由来の基本照射値は通常、遮られていない地平線を前提に定義される一方、測定データや山岳地などでは地平線効果がすでに反映されている場合があると説明されています。
この点を見落とすと、地平線影響を二重に考慮してしまうことがあります。たとえば、実測データに山影の影響が含まれているにもかかわらず、さらにHorizon設定で同じ山影を追加すると、発電量を過小評価する可能性があります。逆に、開放地平線の気象データを使っているのに地形影を入れなければ、発電量を過大評価する可能性があります。
気象データで見るべき3つの数字
気象データ確認では、次の3つを必ず見ます。
PVSyst マニュアルを読む際は、単に「気象データをインポートする手順」を覚えるのではなく、「この気象データは、どの地点の、どの期間を代表し、どのような前提を持つのか」を確認することが重要です。
実務チェック3:方位・傾斜・架台条件を整理する
3つ目のチェックは、方位・傾斜・架台条件です。太陽光発電の発電量は、同じ容量でもパネル面がどの方向を向いているかで変わります。PVSyst マニュアルを使うときは、Orientationの項目を単なる角度入力欄として扱わず、発電特性を決める中核条件として確認します。
PVsyst 8ではOrientationの考え方が大きく変わり、電気システムのサブアレイと3Dシーン上のテーブルをつなぐ中心的な要素として扱われます。公式ドキュメントでは、複数の独立した方位を定義でき、固定式と追尾式、異なる軸条件のトラッカー、複数のピッチ条件などを1つのプロジェクト内で組み合わせられると説明されています。
この仕様は、屋根上太陽光や複雑な野立て案件で特に重要です。たとえば、工場屋根に東西南北の面が混在する場合、1つの平均方位で入力すると、実際の発電カーブやPCS負荷の再現性が落ちます。PVsyst 8のOrientation管理を活用すれば、複数面を分けて扱い、サブアレイや3D配置と整合させやすくなります。
方位・傾斜でよくあるミス
よくあるミスは、「南向き・傾斜10度」といった代表値だけで設計を進めることです。実際には、屋根勾配、架台の設置角、基礎勾配、東西設置、トラッカー、ドーム型架台、地盤傾斜などが複雑に絡みます。
PVsystの公式ドキュメントでは、固定傾斜面を選ぶと簡易的な方位最適化ツールが表示され、傾斜・方位が最適値と比べて発電量にどう影響するかを概算できます。ただし、この評価は簡易アルゴリズムに基づくため、最終的なシミュレーション結果とは異なる可能性があるとも説明されています。
そのため、実務では次の順番で確認します。
• 図面上の方位とPVSyst上の方位が一致しているか
• 傾斜角が屋根勾配、架台角度、地盤勾配のどれを表しているか
• 複数面を1つにまとめてよい案件か、分けるべき案件か
• 3Dシーンを作る場合、方位とテーブル面積が整合しているか
• 発電量だけでなく、時間帯別の出力カーブも妥当か
特に自家消費型では、年間発電量だけでなく、午前・午後・昼ピークの出力バランスが重要です。南向きが最大発電量になるとは限らず、東西配置の方が需要カーブに合う場合もあります。PVSyst マニュアルを活用するなら、方位最適化を「最大発電量を探す機能」ではなく、「事業目的に合う出力特性を比較する機能」として使うべきです。
実務チェック4:モジュール・PCS・ストリング構成を確認する
4つ目のチェックは、モジュール、PCS、ストリング構成です。PVSystでは、機器データベースからモジュールやインバータを選び、サブアレイ、ストリング数、直列枚数、MPPT構成などを設定します。ここは発電量だけでなく、過積載、クリッピング、電圧範囲、低温時最大電圧、高温時MPPT電圧に関わるため、実務上の重要度が高い項目です。
公式ドキュメントでは、PVsystのモジュールデータベースにおいて、PANファイルがデータベースの主キーとして使われ、ファイル名には通常.PAN拡張子が使われると説明されています。 つまり、同じメーカー・同じ型番に見えても、PANファイルの更新年、定格、温度係数、低照度特性、セル構成が異なれば、結果に差が出る可能性があります。
PCS側も同様です。インバータ効率は単純な一定値ではなく、運転時の瞬時電力に対する電力変換関数として扱われます。公式ドキュメントでは、インバータ効率は入力または出力電力に対する非線形カーブで表され、しきい値入力電力はインバータ自身の消費として理解できると説明されています。
ストリング構成で確認すべきこと
PVSyst マニュアルを見ながらストリングを組むときは、次の項目を確認します。
実務では、PVSyst上でエラーが出ないからといって、必ずしも良い設計とは限りません。たとえば、PCSの定格に対してモジュール容量を大きくする過積載設計は一般的ですが、過積載が大きすぎるとピーク時間帯のクリッピング損失が増えます。逆に過積載を避けすぎるとPCSの利用率が下がり、経済性が悪くなることもあります。
また、屋根上案件では1つのMPPTに異なる方位のストリングを接続するケースがあります。PVsystでは混合方位を扱えますが、MPPTごとの入力特性を理解せずに設定すると、実機の電気的挙動とシミュレーションがズレます。PVSyst マニュアルを読むときは、「この構成を入力できるか」だけでなく、「実機配線と同じ意味になっているか」を確認してください。
実務チェック5:遠方影・近傍影を分けて確認する
5つ目のチェックは影です。PVSyst マニュアルで多くの人がつまずくのが、Horizon、Near Shadings、3D Scene、Electrical Shadings、Module Layoutの関係です。影の設定は発電量に大きく影響しますが、過剰に細かく入れれば良いわけではありません。重要なのは、影の種類を分けて考えることです。
PVsystの公式ドキュメントでは、Far shadingsは地平線によって表され、PVフィールド全体に一括して影響する遠方物体を扱うと説明されています。一方、Near shadingsは近くの物体がPVフィールドに可視的な影を落とすもので、詳細な3D記述が必要になるため、遠方影より複雑です。公式ドキュメントは、Near shadingsをPVsystの中でも最も難しい部分と説明しています。
実務では、まず影を次の2種類に分けます。
• 遠方影:山、丘、遠方建物、地平線など、太陽が見えるか見えないかに近い影
• 近傍影:隣棟、塔屋、フェンス、電柱、樹木、架台列間、パラペットなど、パネル面の一部を遮る影
遠方影はHorizonで扱い、近傍影は3DシーンやNear Shadingsで扱います。この 区別を誤ると、損失の意味が分からなくなります。たとえば、山影を近傍影として3Dで作ろうとすると不自然ですし、隣棟の影をHorizonだけで処理すると、パネル面の部分影や電気的ミスマッチを表現しきれません。
影設定で必ず確認する3ステップ
1つ目は、現地条件の整理です。配置図、周辺写真、測量データ、ドローンデータ、3Dモデル、地形データなどから、どの影が発電量に影響するかを確認します。
2つ目は、PVSyst上の影モデルの選択です。列間影のように規則的な影は簡易モデルで足りる場合がありますが、複雑な建物影や屋根上の障害物は3Dで再現した方が良い場合があります。
3つ目は、影損失の読み取りです。影を入れたら終わりではなく、損失図や月別結果で、冬場・朝夕・低太陽高度時に過大な損失が出ていないか確認します。影損失が大きい場合は、配置変更、架台角度変更、列間隔調整、ストリング分割、PCS入力分割などの設計判断に戻す必要があります。
PVSystでは近傍影の電気的損失について、パーティションモデルやModule Layoutなど複数の扱いがあります。公式ドキュメントでは、パーティションモデルは詳細なModule Layoutより高速に電気的影損失を計算する近似で、規則的な列配置のシステムに適していると説明されています。
大規模案件で詳細なModule Layoutを使う場合は、計算時間にも注意が必要です。公式ドキュメントでは、詳細度の高いシミュレーションは時間がかかるため、システムサイズが1MWpを超えると警告、5MWpを超えるとエラーが表示されると説明されています。
実務チェック6:損失条件を根拠つきで設定する
6つ目のチェックは損失条件です。PVSyst マニュアルを実務で使ううえで最も説明責任が問われるのが、各種損失率の設定です。損失条件は発電量を調整する便利な数字ではなく、現地条件、設計条件、機器仕様、運用方針を反映する技術的な前提です。
PVsystでは、熱損失、配線損失、モジュール品質損失、ミスマッチ損失、IAM、汚れ、劣化、停止、変圧器損失、補機消費、出力制限などを設定・評価できます。公式ドキュメントでは、システム定義のバリアントで、PVアレイ特有の損失パラメータ、たとえば熱、配線抵抗、モジュール品質、ミスマッチ、IAM、停止などを修正でき、初期値は典型的なデフォルト値として設定されると説明されています。
ここで重要なのは、デフォルト値をそのまま使ってよいかどうかを判断することです。初期検討ならデフォルト値を起点にしても構いません。しかし、投資判断や発電量保証の根拠に使う場合は、なぜその値を使ったのか説明できる必要があります。
代表的な損失と確認ポイント
損失条件は、保守的に入れすぎると発電量を過小評価し、事業性を不当に悪く見せます。一方、楽観的に入れすぎると、運転開始後の実績とシミュレーションが乖離します。PVSyst マニュアルを読むときは、画面ごとの意味だけでなく、「この損失は誰が責任を持って説明するのか」を意識してください。
PVsystでは、損失の影響はシミュレーション結果で確認でき、Loss diagramに可視化されます。公式ドキュメントでも、各損失の影響は時間、日、月の値として得られ、Loss diagramで確認できると説明されています。
実務チェック7:結果レポートを読み、設計判断に戻す
7つ目のチェックは、結果レポートの読み方です。PVSystでシミュレーションを実行すると、年間発電量、PR、月別発電量、損失図、気象条件、システム条件などが出力されます。しかし、レポートは「提出用PDF」ではなく、設計の良し悪しを判断するための資料です。
公式ドキュメントでは、シミュレーションは数十の変数を扱い、その一部が月別または詳細な時間ステップ値として結果ファイルに保存され、レポートや詳細結果画面の表・グラフに使われると説明されています。また、シミュレーション結果はプロジェクトファイル名に対応した.VCiファイルとして保存されます。
結果確認で最初に見るべきは、年間発電量だけではありません。少なくとも、次の5点を確認します。
• 年間発電量が地域・容量に対して大きく外れていないか
• PRが過度に高すぎないか、低すぎないか
• 月別発電量の季節変動が自然か
• Loss diagramで大きな損失がどこに出ているか
• クリッピング、影、温度、配線、停止などの損失が設計条件と整合するか
PVsystのLoss diagramは、PVシステム設計の品質を素早く把握し、主な損失源を特定するための機能です。公式ドキュメントでは、年間のSimulation reportに常に含まれ、月別の詳細結果でも確認できると説明されています。
PRを過信しない
PVSystの結果でよく見られる指標にPRがあります。PRは便利ですが、単独で設計の良し悪しを判断するのは危険です。公式ドキュメントでは、PRには影、IAM、汚れなどの光学損失、PV変換、経年、モジュール品質、ミスマッチ、配線などのアレイ損失、さらに系統連系ではインバータ効率、独立型では蓄電池や未使用エネルギーなどのシステム損失が含まれると説明されています。
つまり、PRが高いから優れた設計とは限りません。低日射地域、影条件、温度条件、出力制限、過積載率などによってPRの意味は変わります。自家消費型では、PRよりも需要時間帯との一致や余剰電力量の方が重要になることもあります 。
レポートを読むときは、PR、E_Grid、GlobInc、Specific yield、Loss diagramをセットで確認します。特に、損失図の中で一部の損失だけが極端に大きい場合は、入力ミス、設定過多、設計上の問題のいずれかを疑うべきです。
PVSyst マニュアルを読むときの実務フロー
PVSyst マニュアルは、機能説明として読むより、業務フローに沿って読む方が効率的です。おすすめの流れは次の通りです。
1. 目的と比較条件を決める
最初に、発電量を求めるだけなのか、複数案を比較するのか、金融機関や顧客へ提出するのかを決めます。この段階でバリアント名のルールも決めておくと、あとから比較しやすくなります。
例として、次のような命名が実務では分かりやすいです。
• Base:標準案
• Shading:影考慮案
• DCAC:過積載率変更案
• Tilt:傾斜変更案
• Conservative:保守的損失案
• Final:提出候補案
2. 気象データを先に確定する
次に、地点と気象データを確定します。日射量が変わると、最終発電量だけでなく、最適傾斜、PCSクリッピング、温度損失、季節別発電量も変わります。機器構成を先に細かく作り込むより、気象データを早く固める方が効率的です。
3. 方位・傾斜・容量を大枠で入れる
初期段階では、3D影や細かな損失を入れすぎず、まず大枠の設計を作ります。ここで複数の方位・傾斜・容量を比較し、採用候補を絞ります。
4. 機器構成と電気条件を詰める
候補が見えたら、モジュール、PCS、ストリング、MPPT、電圧範囲を確認します。ここで実機仕様とPVSyst上のデータベースが一致しているかを確認します。
5. 影と損失を追加する
次に、遠方影、近傍影、列間影、 建物影、電気的影損失を追加します。同時に、熱、配線、汚れ、停止、劣化などの損失も根拠つきで設定します。
6. 結果を見て設計に戻す
最後に、レポートを見て終わりではなく、設計へ戻します。影損失が大きければ配置変更、クリッピング損失が大きければPCS容量や過積載率の見直し、配線損失が大きければケーブル設計の見直しを行います。
このように、PVSyst マニュアルは「入力の順番」ではなく「判断の順番」で読むと、実務に直結します。
よくある失敗と対策
失敗1:デフォルト値のまま提出してしまう
初心者に多いのが、PVSystの初期値をそのまま使い、根拠を説明できない状態でレポートを提出することです。デフォルト値は便利ですが、すべての案件に最適な値ではありません。
対策は、提出用のシミュレーションでは、主要な損失条件にコメントや根拠資料を残すことです。最低でも、気象データ、汚れ、停止、劣化、配線、影、出力制限については説明できるようにします。
失敗2:影を入れすぎて結果が読めなくなる
3Dモデルを細かく作りすぎると、計算時間が長くなり、どの影がどの損失に効いているのか分からなくなることがあります。特に初期検討では、詳細モデルよりも比較しやすさが重要です。
対策は、最初に簡易モデルで影響度を把握し、影響が大きい部分だけ詳細化することです。すべてを詳細に再現するより、発電量に効く要素を優先します。
失敗3:方位混在を平均値で処理する
屋根上太陽光で複数面があるにもかかわらず、平均方位・平均傾斜でまとめると、実際の発電カーブとズレることがあります。年間発電量だけを見ると大差がないように見えても、PCS入力、MPPT、時間帯別発電量では差が出ます。
対策は、方位や傾斜が明確に異なる面は、できるだけ分けてモデル化することです。特に自家消費型では、午前・午後の発電バランスを確認します。
失敗4:PRだけで良し悪しを判断する
PRは便利な指標ですが、案件条件を無視して比較すると誤解を招きます。影が少ない案件と影が多い案件、低温地域と高温地域、出力制限あり・なしの案件をPRだけで比較しても、設計判断としては不十分です。
対策は、PRをLoss diagramとセットで読むことです。どの損失がどれだけ効いているかを見れば、改善すべきポイントが分かります。
失敗5:バージョン差を記録しない
PVsystはバージョン更新により、データベース、計算機能、バグ修正、UI、レポート表示などが変わります。公式リリースノートでは、バージョン8系でも3Dシーン、気象データ、レポート、蓄電池、最適化機能などに関する改善や修正が継続的に行われています。
対策は、提出資料にPVsystのバージョン、使用した気象データ、主要な機器データ、バリアント名を残すことです。後日再現できることが、実務では非常に重要です。
PVSyst マニュアルを使う担当者向けチェックリスト
最後に、PVSyst マニュアルを使って案件を確認するための実務チェックリストをまとめます。
このチェックリストを使えば、PVSyst マニュアルを単なる操作説明ではなく、設計品質を高めるための確認資料として活用できます。
まとめ:PVSyst マニュアルは入力順ではなく確認順で読む
PVSyst マニュアルで使いこなすために重要なのは、画面操作を丸暗記することではありません。実務では、プロジェクトの目的、気象データ、方位・傾斜、機器構成、影、損失、結果レポートという7つの観点で、入力値が設計判断に耐えられるかを確認する必要があります。
特に重要なのは、次の7点です。
• プロジ ェクトの目的を最初に固定する
• 気象データと地点条件を確認する
• 方位・傾斜・架台条件を整理する
• モジュール・PCS・ストリング構成を確認する
• 遠方影・近傍影を分けて確認する
• 損失条件を根拠つきで設定する
• 結果レポートを読み、設計判断に戻す
PVSystは高機能なシミュレーションソフトですが、結果の信頼性は入力条件の妥当性に左右されます。だからこそ、PVSyst マニュアルを読むときは「どのボタンを押すか」ではなく、「この入力値は現地条件・設計条件・提出目的に合っているか」を確認する視点が欠かせません。
PVSyst マニュアルを実務で活かす最大のコツは、1回で完璧なシミュレーションを作ろうとしないことです。標準案を作り、影を追加し、損失を調整し、機器構成を見直し、結果を比較する。この反復によって、発電量の数字だけでなく、設計判断の根拠が強くなります。PVSystを使いこなすとは、ソフトを操作できることではなく、結果を読み解き、より良い太陽光発電設計へ戻せることです。
LRTKで現場の測量精度・作業効率を飛躍的に向上
LRTKシリーズは、建設・土木・測量分野における高精度なGNSS測位を実現し、作業時間短縮や生産性の大幅な向上を可能にします。国土交通省が推進するi-Constructionにも対応しており、建設業界のデジタル化促進に最適なソリューションです。
LRTKの詳細については、下記のリンクよりご覧ください。
製品に関するご質問やお見積り、導入検討に関するご相談は、
こちらのお問い合わせフォームよりお気軽にご連絡ください。ぜひLRTKで、貴社の現場を次のステージへと進化させましょう。

