前回は、パネル間のレーンだけでは表しにくい雑草候補を、面状の作業候補エリアとして整理する考え方について書きました。

レーンは、方向が明確で連続した作業空間を表すのに向いています。一方で、面状の task zone は、敷地端や広い空地、不規則な植生の広がりを、その形に近いまま扱うのに向いています。

ただ、レーン候補とエリア候補を画面上に表示できるようになっても、それだけではまだ現場で使いやすい情報とは言えません。

現場の人が知りたいのは、「どこに候補があるか」だけではなく、「どれを先に見るべきか」「なぜその候補になったのか」「作業候補なのか、監視候補なのか」という判断の流れです。

そこで今回は、複数のレーン候補と面状エリアを一つの task list として整理し、現場確認や後段の作業計画に渡しやすくする部分について書きたいと思います。

可視化だけでは、現場判断に渡しきれない

画像上にレーンや task zone を重ねると、候補の位置は直感的に分かりやすくなります。

しかし、可視化はあくまで「見るための表現」です。実際の運用では、候補を確認し、比較し、優先順位をつけ、必要に応じて現場側で判断できる形にする必要があります。

たとえば、同じ画面の中に赤いレーンとオレンジのエリアが表示されていたとしても、それだけでは次のことがすぐには分かりません。

どの候補がより重要なのか。どの候補は監視だけでよいのか。どの候補は no-go 領域との距離に注意が必要なのか。どの候補は形が不規則なため、現場確認を優先した方がよいのか。

このように考えると、画像上の overlay と同じくらい重要なのが、候補を list として整理することでした。

list にすることで、候補を一つずつ確認でき、現場側やロボット側の処理にも渡しやすくなります。

task list に持たせる情報を設計する

今回意識したのは、task list を単なる座標の一覧にしないことです。

作業候補として扱うためには、「場所」だけでなく、その候補がどういう性質を持っているのかを一緒に持たせる必要があります。

たとえば、一つの候補には次のような情報が必要になります。

候補の種類。レーンなのか、面状エリアなのか。

候補の状態。cut-now に近いのか、monitor なのか、review が必要なのか。

候補の理由。植生の広がりが大きいのか、no-go 領域に近いのか、形状が不規則なのか。

候補の範囲。どの geometry を持ち、どの場所を表しているのか。

このような情報をまとめることで、task list は単なる検出結果ではなく、「なぜこの場所が候補として残っているのか」を説明できるデータになります。

開発していて感じたのは、AI の結果を現場へ渡すときには、結果そのものと同じくらい、その理由や状態を一緒に伝えることが重要だということです。

レーン候補とエリア候補を同じ枠組みで扱う

レーンと面状エリアは見た目が違います。

レーンは線に近く、進行方向を持つ候補です。面状エリアは範囲を持ち、内部の走行方法までは決めない候補です。

しかし、現場へ渡す task list として考えると、どちらも「作業や確認につながる候補」という点では同じです。

そこで、レーンとエリアを別々の特別なものとして扱うのではなく、共通の task candidate として整理することを意識しました。

違いは type と geometry として持たせます。

レーン候補であれば、中心線や幅、方向を持つ。エリア候補であれば、polygon として範囲を持つ。

一方で、status、priority、reason、review flag のような情報は、どちらにも共通して持たせることができます。

この設計にすると、後段の処理では「レーンだから特別」「エリアだから特別」と分けすぎず、同じ task list の中で比較・確認できます。

この小さな整理によって、画像解析の結果が少しずつシステムの部品として扱いやすくなっていく感覚がありました。

優先度は「命令」ではなく、確認順序を作るための情報

task list を作るときに注意したのは、priority を強すぎる指示として扱わないことです。

たとえば、ある候補を high priority としたとしても、それは「必ず今すぐ刈るべき」という意味ではありません。

現場では、天候、作業者の状況、設備状態、ロボットの移動可能性、他の作業との兼ね合いなど、画像だけでは判断できない要素があります。

そのため、priority は最終判断ではなく、「どの候補から確認するとよさそうか」を示すための情報として考える方が自然です。

これは、AI の出力を現場に押しつけないためにも重要だと思いました。

システムができることは、候補を整理し、見落としを減らし、確認の順番を考えやすくすることです。

最終的な判断は、現場の情報や運用ルールと組み合わせて行う必要があります。

この境界を意識しておくことで、AI の出力を安全側に使いやすくなります。

判断理由を残すことで、後から見直しやすくする

もう一つ大事だと感じたのは、候補を作った理由を残すことです。

task list に「cut-now」「monitor」といった status だけが並んでいても、なぜそう判断されたのか分からなければ、現場の人は確認しにくくなります。

理由があると、判断の見直しがしやすくなります。

たとえば、「植生の広がりが大きい」「パネル端に近い」「面積は小さいが通路付近にある」「形が不規則なので review が必要」といった情報があれば、候補の意味を理解しやすくなります。

また、後から結果を振り返るときにも、なぜその候補が出たのかを追いやすくなります。

この部分は派手ではありませんが、実運用に近づくほど重要になると感じています。

AI の判断を完全なブラックボックスとして扱うのではなく、人が確認し、修正し、次の改善につなげられる形にする。

そのために、task list には geometry だけでなく、status と reason を一緒に持たせることが必要だと考えました。

task list は、画像解析と現場運用をつなぐインターフェース

今回の開発を通して、task list は単なる出力ファイルではなく、画像解析側と現場運用側をつなぐインターフェースに近いものだと感じました。

画像解析側は、画像から植生候補を抽出し、no-go 領域や作業可能領域と組み合わせ、レーンや面状エリアとして整理します。

一方で、現場側やロボット側では、その候補を見て、確認順序、作業可否、実際の移動方法、安全条件を考えます。

この二つの間に task list を置くことで、AI の出力をそのまま最終判断にするのではなく、後段で扱いやすい情報として渡すことができます。

特に、候補の type、geometry、status、priority、reason をそろえておくと、画面で見る場合にも、ロボット側の処理に渡す場合にも、同じ意味を保ちやすくなります。

このような中間表現を設計することは、見た目には地味ですが、現場で使えるシステムに近づくためには大切な部分だと思います。

まとめ

今回は、レーン候補と面状エリアを一つの task list として整理し、現場確認や後段の作業計画に渡しやすくする考え方について書きました。

可視化だけでは、候補の位置は分かっても、優先度や判断理由までは十分に伝わりません。

そこで、レーンかエリアかという type、場所を表す geometry、判断状態を表す status、確認順序を考えるための priority、そして判断理由となる reason を一緒に持たせることを意識しました。

この整理によって、画像解析の結果は、単なる mask や overlay ではなく、現場が確認できる作業候補データに近づきます。

今回あらためて感じたのは、AI の出力を現場につなげるには、「何を検出したか」だけでなく、「どの意味で、どの形で渡すか」を設計する必要があるということです。

次回は、この task list を実際の確認フローやフィードバックに接続し、現場で見直しながら改善していく考え方について書きたいと思います。

なお、読みやすさと内容の連続性を重視するため、本記事では一部の技術内容を簡略化・抽象化して記載しており、実際の実装詳細とは異なる表現を含む場合があります。