QGISラスタ計算機の使い方：検証済みの計算式と気づきにくい4つの落とし穴

QGIS のラスタ計算機は Raster > Raster Calculator（日本語版では ラスタ > ラスタ計算機）から開きます（Processing Toolbox からも開けます）。Sentinel-2 のNDVIには ("B08@1" - "B04@1") / ("B08@1" + "B04@1") を使います。メニューの計算機は自動的に Float32 で計算します。注意したいのは、GDAL の計算機で符号なし整数が折り返されること、* によるマスクが nodata ではなく 0 を書き込むこと、そして度単位のグリッドで傾斜ツールが破綻することです。

2026年11月7日、QGIS 3.44.15 を使って、これらをすべて検証しました。対象はブラジル、ミナスジェライス州マシャードの南にある丘陵の農地で、5 km × 5 km の範囲です（2,500 ha、10 m 解像度で250,000ピクセル、UTM 23S、EPSG:32723）。2026年11月3日の Sentinel-2 L2A シーンと 30 m の Copernicus GLO-30 DEM を使い、すべての出力を QGIS の外で 64ビット浮動小数点の numpy による参照値と比較しました。

QGISのラスタ計算機とは？ どの計算機を開いているのか

ラスタ計算機は、1つまたは複数のラスタバンドに対して、数式や論理式をピクセルごとに評価し、新しいグリッドを書き出すツールです。QGIS では、バンドを "layername@band" の形で指定します（たとえば "B08@1" はレイヤ B08 のバンド1）。バンドは +、-、*、/、<、>、AND、OR、if(condition, true, false) で組み合わせ、出力は GeoTIFF かメモリ上の仮想レイヤに書き出します。

つまずきやすいのは、QGIS に「Raster calculator」という名前のツールが5つあり、すべてが同じエンジンで動くわけではないという点です。4つは QGIS ネイティブの式パーサを使い、浮動小数点で計算します。GDAL のもの（内部では gdal_calc.py）は A/B/C の文字変数を使い、入力バンド自身のデータ型で numpy の式を評価します。

型変換を気にせず使える式がほしいなら、上部メニューの Raster > Raster Calculator か、Processing の QGIS ネイティブグループにある最初の Raster calculator を使ってください。

手順：QGISのラスタ計算機でNDVIを計算する

まず Sentinel-2 のバンドが必要なら、QGIS で Sentinel-2 画像をダウンロードする方法のガイドで STAC カタログを使う手順を説明しています。バンド B04（赤、10 m）と B08（近赤外、10 m）がレイヤパネルに入っていれば、NDVI が何を測るのかの計算は4つのステップで終わります。

("B08@1" - "B04@1") / ("B08@1" + "B04@1")

次の画像は OK をクリックする直前のダイアログで、範囲は B08 から取られています。

RdYlGn でスタイルを設定すると、マシャード周辺の密な植生は濃い緑、裸地や道路は赤で表示され、赤が近赤外を上回る703ピクセル（水域や暗い部分）は負の値になります。範囲全体のNDVIの平均は 0.727 です。樹冠が密でNDVIが飽和する場合や、列の間に裸地が見える場合は、NDVI vs EVI、SAVI、NDRE の比較で式がどう変わるかを確認してください。

QGISラスタ計算機の計算式集

以下の式はすべて QGIS 3.44.15（QgsRasterCalculator）でマシャードのデータに対して実行し、numpy とピクセルごとに比較しました。"layer@band" をダブルクォートで囲む書き方のままコピーしてください。

誤った数値を出す4つの気づきにくい落とし穴（と見分け方）

以下の4つの失敗は、どれも QGIS で警告が出ません。処理は最後まで終わり、プロジェクトにレイヤが追加され、確認するまではもっともらしく見える数値が出てきます。

1. GDAL Raster Calculator は負のNDVIで符号なし整数を折り返す

QGIS ネイティブのラスタ計算機は Sentinel-2 のバンドで整数除算のバグに当たることはありません。しかし Processing の GDAL Raster calculator（gdal:rastercalculator）は (A-B)/(A+B) を入力ファイル自身の numpy データ型で評価するため、赤が近赤外より大きいピクセルをすべて壊してしまいます。

Sentinel-2 Level-2A のバンドは符号なし16ビット整数（uint16）で配布されています。250,000ピクセルの検証範囲では、703ピクセル（0.28%、水域や暗い部分）で B04 が B08 より大きくなっています。gdal:rastercalculator が uint16 のまま B08 から B04 を引くと、負の結果が65,536で折り返され、この703ピクセルには負のNDVIではなく 0 から 126.7 の値が Float32 のファイルに書き込まれます。

GDAL の計算機を使うなら、式の中で (A.astype(numpy.float32)-B)/(A+B) のように型を変換するか（検証では誤ったピクセルが 0 になりました）、QGIS ネイティブのラスタ計算機を使ってください。また、指数の出力型を GDAL で Int16 や Byte にしてはいけません。Int16 を指定すると、250,000ピクセル中249,973ピクセル（99.99%）が -1、0、1 のどれかに丸められました。

2. 条件を掛ける（*）と nodata ではなく 0 が書き込まれ、平均値が下がる

("ndvi@1" > 0.3) * "ndvi@1" のようにラスタに論理条件を掛けると、除外したピクセルはすべて nodata ではなく 0 になります。その結果、残した範囲のNDVIの平均は 0.753 から 0.719 に下がりました。

QGIS の公式マニュアルは、ラスタをマスクする標準的な方法として ("elevation@1" >= 0) * "elevation@1" を紹介しています。マシャードのNDVIレイヤでは、11,343 ピクセルが 0.3 以下です。("ndvi@1" > 0.3) を掛けると、この 11,343 ピクセルすべてに有効な数値 0.0 が書き込まれます。そのためレイヤの統計は250,000ピクセルすべてを数え続け、このあと実行する平均、ヒストグラム、ゾーン統計のすべてに 11,343 個のゼロが含まれます。

1ステップで本当の nodata を書き込むには、掛けるのではなく条件で割ります。"ndvi@1" / ("ndvi@1" > 0.3) です。条件が真（1）の箇所では値はそのまま、偽（0）の箇所ではゼロ除算により nodata になります。

3. 度単位のDEMで傾斜を計算してから計算機を使うと、地図の100%が急斜面になる

地理座標系のDEM（EPSG:4326 の Copernicus GLO-30 など）に QGIS の Slope ツールを既定の設定で実行してから "slope@1" > 15 でしきい値処理すると、丘陵の農地の100%が15度より急だと判定され、平均傾斜は 89.99 度になりました。UTM に変換したあとの正しい値は 32.61% です。

Copernicus GLO-30 などの無料の全球DEM（QGIS で無料のDEMをダウンロードするガイドを参照）は、標高はメートル、位置は地理座標の度（EPSG:4326）で提供されます。既定の Z 係数のままでは、Slope ツールはメートル単位の高低差を 0.000278（度で表したピクセル幅）という水平距離で割るため、どの斜面も垂直な崖に見えてしまいます。

1度あたり 111120 メートルという scale の近道を使っても、ちょうど1ポイント低くなります（31.61% 対 32.61%）。南緯22度では経度1度の長さが緯度1度より約7%短いためです（cos 22° = 0.93）。Slope とラスタ計算機を実行する前に、必ずDEMをその地域の UTM ゾーンに変換してください（Raster > Projections > Warp (Reproject)、リサンプリングは bilinear、端に偽の87°の傾斜が出ないように nodata 値を -9999 に設定）。

4. シーンを確認せずに Sentinel-2 の +1000 オフセットを引くと、90.6%のピクセルが壊れる

NDVIを計算する前に Sentinel-2 L2A のバンドから 1000 を引いたところ、250,000 ピクセル中 226,413 ピクセル（90.6%）が有効範囲 [-1, 1] の外に出ました。値は -1273 から 1217、平均は 0.727 ではなく 1.39 でした。

ESA の Sentinel-2 処理ベースライン 04.00 以降では、暗いピクセルがゼロで切り捨てられないように、デジタル値に +1000 のオフセットが加えられています。STAC のメタデータにも scale: 0.0001 と offset: -0.1 が記載されています。しかし Earth Search STAC API から Cloud-Optimized GeoTIFF を取得した場合（今回のシーン S2A_23KLR_20261103_0_L2A、ベースライン 05.13 がそうです）、提供元がすでに値をずらしてあり、アイテムのメタデータに earthsearch:boa_offset_applied: true が設定されています。

今回の B04 ファイルでは、250,000 ピクセル中 226,773 ピクセル（90.7%）の生のデジタル値が 1000 未満でした（最小 59、中央値 491）。式を変える前に、Layer Properties > Information で B04 の最小値を確認してください。暗いピクセルが 50 から 300 前後なら、オフセットはすでに除かれていて、生の (B08 - B04) / (B08 + B04) で正確な値になります（10,000 のスケール係数は比の中で打ち消し合います）。1000 を引くのは、晴天の最も暗いピクセルが 1000 を超えている場合だけです。

おまけ：「Expression valid」と汎用の赤いエラーバーが本当に意味すること

Raster > Raster Calculator には、デバッグの時間を大きく奪う挙動がほかに2つあります。

• 解像度の異なるバンドを粗いグリッドで組み合わせても平均されません。 10 m のバンド（B08）と 20 m のバンド（B11）を組み合わせると、ネイティブの計算機は最近傍法でその場でリサンプリングします（GDAL の計算機は Error! Dimensions of file ... (250, 250) are different from other files (500, 500). Cannot proceed ですぐに止まります）。10 m の出力グリッドでは、20 m の各ピクセルを 2 × 2 で繰り返すだけなので問題ありません。20 m の出力グリッドでは、計算機は 10 m の4ピクセルを平均しません。62,500 セル中 62,250 セルで、各 2 × 2 ブロックの右上の 10 m ピクセルをそのまま選んでおり、(B08 - B11) / (B08 + B11) では4ピクセル平均との差が最大 0.71 になりました。
• 「Expression valid」は構文を確認するだけで、バンド名は確認しません。 "B08@1" / のように演算子で終わる式なら、ダイアログが検出します（Expression invalid となり、OK がグレーアウトします）。

ところが、プロジェクトにないレイヤやバンド（"B04@2" や、B02 を読み込んでいないときの "B02@1" など）を入力しても、ラベルは Expression valid のままです。OK をクリックすると、QGIS は100% nodata で埋まった 500 × 500 の GeoTIFF を書き出し、地図には何も追加せず、赤いバナーを1つだけ表示します。Raster calculator: An error occurred while performing the calculation. このバナーが出たら、すべての "layer@band" の名前を Raster Bands の一覧と照らし合わせてください。

ダイアログを使わない方法：QGISのAIエージェントに頼んでラスタ演算を実行する

私たちは AI Agent を開発しているので、このセクションは自社のプラグインについての話です。AI Agent は QGIS の中にチャットパネルを追加し、STAC カタログの検索、DEMの変換、Python や Processing によるラスタ演算、地図上での出力のスタイル設定を行えます。

上記の落とし穴をまったく同じマシャードのデータで避けられるかを確かめるため、空の OpenStreetMap プロジェクトの上に 120.07 ha の農地ポリゴン（UTM 23S で E 405300-406300, N 7594400-7595600）を描き、1回のメッセージで完結するプロンプトを3つ送りました。設定は Medium effort、Balanced permissions で、タスクごとに新しいチャットを使いました。

テスト1：NDVIを5クラスに分け、クラスごとの面積（ha）を出す

入力したのは次のプロンプトです。

Compute NDVI for this field from the latest cloud-free Sentinel-2 and class it in 5 classes with hectares per class

エージェントは STAC カタログを確認し、2026年11月6日のシーンもあるものの雲が多いことに触れたうえで、手作業の検証で使ったのと同じ2026年11月3日のシーン（タイルの雲量 1.65%）を選びました。10 m の B08 と B04 を取得してNDVIを計算し、5つの区間に分類してレイヤのスタイルを設定し、10 m のメートル単位のグリッドでクラスごとの面積を報告しました。

エージェントが書き出したNDVIラスタをピクセルごとに比べると、参照値との平均絶対差は 5e-5 で、クラスラスタが私のものと異なったのは12,000ピクセル中4ピクセルでした。

テスト2：15度を超える傾斜（プロジェクトにDEMがない状態で）

農地ポリゴンだけを読み込んだ新しいチャットで、次のように入力しました。

Show where slope is above 15 degrees on the farm layer

エージェントは Copernicus の 30 m DEM を取得し、度のまま傾斜を計算するのではなくメートル単位のグリッドに再投影して、2クラスのレイヤ（15 degrees or less を淡い黄色、above 15 degrees を赤）でスタイルを設定しました。報告は農地の 1,320 ピクセル中 331 ピクセルが15度超（25.08%、最大 29.15°）でした。同じ長方形で私が UTM に変換してネイティブの Slope で計算した参照値は、1,360 ピクセル中 341 ピクセル（25.07%、最大 29.29°）で、差は 0.01 ポイントでした。

テスト3：それでもエージェントを確認すべき点

3つ目のチャットでは、次のように頼みました。

Mask out everything with NDVI below 0.3 on the farm layer and tell me the mean NDVI of what is left

このプロンプトには「cloud-free」も「latest」も書いていない点に注意してください。エージェントは 0 マスクの落とし穴を避け、マスクしたピクセルすべてに nodata の -9999 を書き込み、残った 2,277 ピクセルでNDVIの平均 0.552 を返しました。出力ファイルの平均は 0.5515、同じシーンと同じ条件で私が計算した値は 0.5513 でした。

しかし、エージェントが取得したのは2026年10月27日の Sentinel-2 シーンで、この日は農地の 80.5%（Scene Classification バンドで 12,000 ピクセル中 9,656 ピクセル）が雲、雲の影、巻雲に覆われていました。回答の中で日付は示していましたが、0.552 が農地のうち晴れていた5分の1だけの値だとは一言も触れませんでした。晴れていた11月3日のシーンで同じ条件を使うと、8,785ピクセルで平均は 0.766 になります。

私の目安はこうです。ラスタ計算機を手で使う場合も、QGIS の AI エコシステムのエージェントに頼む場合も、集計値を信じる前に必ずシーンの日付を確認し、トゥルーカラーか SCL の雲バンドを読み込んでください。

測定方法 すべてのテストは2026年11月7日、macOS 上の QGIS 3.44.15-Solothurn（GDAL 3.13.3、numpy 2.5.2）で、ブラジル、ミナスジェライス州マシャードの南にある 5 km × 5 km の範囲（EPSG:32723、E 402000-407000、N 7591000-7596000）を対象に実施しました。使ったのは Earth Search の Sentinel-2 L2A シーン S2A_23KLR_20261103_0_L2A（テスト3では2026年10月27日のシーン）と、Copernicus GLO-30 のタイル S22_00_W046_00 です。手作業の検証と、エージェントのテスト1とテスト2の成功基準は、ラスタ計算を実行する前に書きました。テスト3の基準は、テスト1とテスト2の結果を見たあとに書きました。参照グリッドは QGIS の外で 64ビット浮動小数点の numpy により計算しました。AI Agent 1.9.4 は Medium effort と Balanced permissions で、チャットごとに1メッセージで使いました。1シーン1地点の検証は単一事例のベンチマークであり、複数のベースラインにわたる統計的な調査ではありません。

よくある質問

次に読むNDVIとは？意味・値の見方・計算式をQGISで解説

AI Agentを無料で試す