エージェントAI × QGIS：地形スクリーニングの前処理を自動化する実験
「山の周辺で、傾きが30度以上の場所を赤くしてほしい」。今回Willow38では、エージェントAIと地図ソフトQGISを組み合わせ、標高データの取得から地形のスクリーニング（条件に合う場所の抽出）までを動かしてみました。
まず、実際にできたものをご覧ください。左は計算した地面の傾き。右は30度以上の場所を赤く重ねたものです。
赤色は今回の抽出条件に合う場所です。危険区域の指定や、安全性の判定を示すものではありません。
地面の高さを記録した「方眼紙」を使う
QGISは、地図に情報を重ねたり、場所に関する計算をしたりできるソフトです。材料にはDEM（数値標高モデル）を使います。地面を細かなマスに区切り、それぞれに高さを記録したデータ。「高さの数字がびっしり書かれた方眼紙」と考えるとイメージしやすいでしょう。
今回は高尾山周辺の、国土地理院の5mメッシュDEMに由来する標高タイルを9枚取得しました。タイルとは、地域ごとに分割されたデータのことです。
この9枚をつなぎ、計算に使う一枚のデータにしました。解析範囲はタイルから決まり、高尾山の区域や行政界で切り取ったものではありません。
高さの違いから、地面の傾きを計算する
隣のマスと高さがほとんど変わらなければ、平らに近い場所。短い距離で高さが大きく変われば、急な斜面です。高い場所だから急とは限りません。標高と傾きは別の情報です。
距離を正しく扱うため、対象地域に合うメートル単位の座標系へ変換してから計算しています。専門的な条件は、JGD2011平面直角座標系IX系（EPSG:6677）、5m出力格子、双一次補間、Horn法による斜度計算です。水平距離と標高の単位をメートルにそろえました。
出力格子を5mにしても元データの精度は上がりません。欠測部分と、周囲の値が足りず計算できない部分は欠測として残しています。
何を自動化すると、作業が楽になるか
従来もQGISで斜度は計算できます。既存の処理モデルやコードによる自動化も可能です。今回試したのは、言葉で伝えた目的を、AIエージェントに実行手順とコードへ落としてもらうことです。
| 工程 | 画面で操作する場合 | 今回のプログラム |
|---|---|---|
| データ取得 | 地域を探して取得 | 指定位置の周辺9枚を取得 |
| 接合と準備 | 接合・座標系・単位を設定 | 同じ条件で一括処理 |
| 傾きの計算 | 機能を選んで条件を入力 | 決めた方法で計算 |
| 抽出と保存 | 条件を入力し、出力を保存 | 30度以上を抽出し、結果と条件を保存 |
AIが手順をコードにし、QGISと計算ライブラリが数値処理を担当する。その結果を人が確認します。AIが地図を見て「急そうだ」と推測しているわけではありません。
今回はチャット専用のQGISプラグインを作ったわけではなく、AIエージェントがQGIS付属のPythonを使って処理を実行し、成果をQGISで開きました。条件を変えて調べ直すときにも手順を再利用できます。地域を変える際は、座標系などを再確認します。
どういう手順で開発したか：Codexと道具の分担
今回使ったAIエージェントはOpenAIのCodexです。このチャットで目的を伝え、コードの作成だけでなく、実行環境の確認、処理の実行、結果の点検まで進めました。
- 目的を言葉にする。DEMを取得し、斜度を計算し、30度以上を抽出する、と依頼しました。高尾山周辺はCodexが実験用の対象として設定した場所です。現場の専門家が選定・承認した実務条件ではありません。
- 環境と仕様を調べる。MacのQGIS 3.44 LTRと付属Pythonを確認。国土地理院の標高タイル仕様とGDALの計算仕様を参照しました。
- 処理をコードにする。CodexがPyQGIS（PythonからQGISを操作する仕組み）でterrain.pyを作成。Pythonの通信機能で国土地理院から9枚を取得し、NumPyで数値配列として接合。GDALで座標変換と斜度計算を行い、NumPyで30度以上を抽出しました。PyQGISは成果のレイヤー登録・色設定・プロジェクト保存を担います。
- 実行して、失敗を直す。最初は実行環境のネットワーク制限で取得できず、通信許可後に実データ処理が成功しました。出力ファイルを閉じるタイミングと、QGISの表示範囲・濃淡・重ね順も調整しました。
- 保存結果と画面を確かめる。保存ラスタの読み直し、抽出条件と欠測の点検、45度の人工斜面によるチェックを実施。Codexの画面操作機能でQGISを開き、表示も確認しました。
- 途中成果を説明用の図にする。保存したGeoTIFF（位置情報付き画像）をPythonで読み、Matplotlibというグラフ描画ライブラリで本文の図を作りました。地形をAI画像生成で描いたものではありません。
依頼と判断：私 → 手順作成・実行支援：Codex → 数値処理：Python／NumPy／GDAL → 地図表示：QGIS → 記事の図：Matplotlib
コードはMac上で動き、数値処理を担当します。一方、Codexとの相談にはクラウドAIを使っています。すべてが端末内で完結する構成ではありません。別エージェントによる検算は、今後の発展案です。
結果を数字と、答えのわかる入力で確かめる
斜度を計算できた351,508画素のうち、30度以上は259,279画素でした。抽出部分の水平投影面積は約6.48km²です。斜面の表面積でも、高尾山全体の集計でもありません。
保存データを読み直し、全有効画素で「斜度30度以上」と抽出結果が一致することを確認しました。欠測が「30度未満」に混ざっていないことも点検しています。
人工斜面の内部98×98画素で、45度からの誤差が0.001度以内であることを確かめました。これは計算動作のチェックであり、実地形の精度検証ではありません。
QGIS画面では、初期範囲、斜度の濃淡、重ねる順番に手直しが必要でした。修正して、DEM・斜度・赤い抽出結果を切り替え、表示を確認しています。本文の図は保存済みデータから作った説明用の図で、QGIS画面そのもののスクリーンショットではありません。
環境はQGIS 3.44 LTR／GDAL 3.13.3。保存データと画面表示は確認済みですが、表示改善を反映した配布コードの全工程再実行は未実施です。専門的な妥当性の評価、時間短縮やミス削減の測定も今後の課題です。
勝負どころで、脳が元気でいられるように
私の軸足はAIエンジニア・コンサルタントです。地形解析や土木の専門家ではありません。最初に何を調べるかを決め、最後に結果の妥当性を押さえるのは、その道の専門家だと考えています。
その間にある、データを探す、設定を選ぶ、保存先を確認する、といった細かな作業。私が手で進めるなら、ケアレスミスが多くてどうしよう、となりそうです。
細かな作業で疲れ切り、肝心の結果を確かめるときに力が残っていない。そんなことはないでしょうか。
間違えてはいけない初動と、最後の詰め。そのときに、脳が元気でなければならない。勝負どころで疲弊していては、勝負になりません。
繰り返す操作をAIに任せ、大事な判断に使う余力を残す。今回探りたかったのは、その分担です。
AI × アプリケーション × 専門家をつなぐ
エージェントAIが処理を組み立て、アプリケーションが計算を担い、専門家が経験と知識で方向と結果を押さえる。どこを任せ、どこで確かめるか。途中成果をどう残し、失敗をどう見つけるか。
そのトータルコーディネートをすることが、AIコンサルタントの仕事だと私は考えています。
発展形として、別エージェントによる検算や、独立した計算方法との照合も考えられます。今回は別エージェントの検算は未実施です。AI同士の答えが一致しても、専門的な妥当性の保証にはなりません。最初の方向づけと最後の押さえは専門家。その人が力を使えるよう、間の仕事を組み立てていきたいのです。
図の出典：国土地理院DEM5A標高タイルを加工（人工斜面の図を除く）。
