前回は、レーン候補と面状エリアを一つの task list にまとめ、type、geometry、status、priority、reason といった情報を持たせる考え方について書きました。

ただし、task list を作ること自体が最終目的ではありません。画像解析から生成された候補を実際の運用へつなげるには、現場で確認し、必要に応じて修正し、その結果を次の判断へ戻せる流れが必要です。

そこで今回は、task list を現場確認の起点として使い、確認結果を structured feedback として残していく考え方について書きたいと思います。

task list は結論ではなく、確認の起点

画像解析は、広い敷地の中から確認すべき場所を絞り込み、候補を一定の基準で整理することに向いています。

一方で、現場には画像だけでは分からない情報があります。直近の作業状況、設備の状態、通路の使われ方、当日の天候、作業者やロボットが実際に入れるかどうかなどです。

そのため、task list は「AIが決めた結論」ではなく、「現場が効率よく確認するための起点」として位置づける方が自然だと考えました。

AI側は候補を見落としにくい形で整理し、現場側は状況に応じて意味を確認する。どちらか一方に判断を寄せるのではなく、それぞれが得意な情報を組み合わせることが重要です。

この役割分担を明確にすると、AIの出力を強すぎる指示にせず、それでも実務に役立つ情報として使いやすくなります。

task list をAIの最終指示ではなく、現場確認の出発点として扱う

候補ごとに、位置と理由を同時に確認する

現場確認を考えると、候補を一覧表だけで見るよりも、画像や地図上の位置、周辺のパネルや no-go 領域、候補になった理由を同時に確認できる方が分かりやすくなります。

例えば、同じ monitor 候補でも、「植生の広がりが小さいため monitor」なのか、「パネル端に近いため慎重な確認が必要」なのかでは意味が異なります。

位置と reason を一緒に見られると、現場の人は候補の背景を理解したうえで判断できます。また、営業や顧客への説明でも、単に色分けされた画像を見せるより、「なぜこの場所が候補になったのか」を伝えやすくなります。

開発していて感じたのは、説明可能性は難しい数式を見せることではなく、判断に必要な情報を適切な単位でそろえることから始まる、ということです。

候補の位置、周辺制約、選定理由を同じ画面で確認する

確認結果を yes / no だけで終わらせない

現場確認の結果は、単純な承認・否認だけでは表しきれません。

候補をそのまま作業対象として確認する場合もあれば、今回は monitor に残す場合もあります。優先度だけを変更したい場合、範囲を少し修正したい場合、別の候補とまとめたい場合、作業対象から外したい場合もあります。

そこで、確認結果を一つの yes / no にせず、status、priority、geometry、reason のどこが更新されたのかを残せる形にすることが重要になります。

この設計にすると、現場の判断が単なるコメントではなく、task data の更新として扱えます。

人が確認した結果を構造化して残すことで、次の作業計画にも使いやすくなり、後から見直すときにも判断の意味が分かりやすくなります。

yes / no だけでなく、status、priority、geometry を構造化して更新する

ラベルだけでなく、境界の修正もフィードバックになる

画像解析の結果を現場へ渡すとき、status の修正だけでなく、候補の形そのものを見直せることも大切です。

面状エリアであれば、実際の作業範囲に合わせて polygon の境界を少し狭めたり、二つのエリアに分けたりすることがあります。レーン候補であれば、開始点や終了点、幅、方向を調整した方が現場の感覚に合う場合があります。

このような geometry の修正には、現場の知識が直接反映されます。

画像だけでは一続きに見える領域でも、実際には設備や地形によって分けた方がよいことがあります。逆に、別々に見える候補でも、同じ作業単位として扱った方が効率的な場合があります。

つまり、現場フィードバックは「正しい / 間違い」の判定だけではなく、AIが作った空間表現を、実際の作業単位へ近づけるための情報でもあります。

現場状況に合わせて候補の境界や範囲を修正する

確認履歴を残すことで、判断を説明しやすくする

task list を更新するときには、最終状態だけでなく、どの候補がどのように見直されたのかを残しておくことも重要です。

例えば、最初は cut-now 候補だったものが、現場確認後に monitor へ変更された場合、その変更理由が分かれば、後から結果を振り返りやすくなります。範囲が修正された場合も、どこが変わったのかを確認できると、次の改善につながります。

確認履歴があることで、「AIが何を提案し、現場がどこを調整したのか」という役割分担が明確になります。

これは、単に記録を残すためだけではありません。判断の透明性を高め、同じような候補を次回確認するときの参考にするための情報になります。

実運用に近づくほど、最終結果だけでなく、そこに至るまでの判断過程を追えることが大切になると感じています。

AIの提案と現場の調整を履歴として残し、判断過程を追えるようにする

フィードバックを次回の候補生成につなげる

現場確認で得られた情報は、その場の task list を修正するだけで終わらせる必要はありません。

どのような候補がよく承認されたのか、どのような候補が monitor に変更されたのか、どの場所で geometry の修正が多かったのかを整理すると、候補生成のルールや判断基準を見直す材料になります。

ここで重要なのは、すべてをすぐに自動学習へつなげることではありません。まずはフィードバックを一定の形式で蓄積し、何が現場の判断と一致し、どこに調整が必要だったのかを分析できる状態にすることです。

そのうえで、threshold、priority rule、zone definition、review condition などを少しずつ改善できます。

今回特に面白いと感じたのは、現場の知識がAIの外側にある補足情報ではなく、システムを育てるためのデータになる点です。

AIが一方的に答えを出すのではなく、候補を提示し、現場が確認し、その結果が次の候補生成に戻る。この循環を作ることで、画像解析と現場運用の距離を少しずつ縮められると考えています。

現場フィードバックを次回の候補生成とルール改善へ戻す

まとめ

今回は、task list を現場確認の起点として使い、確認結果を structured feedback として残す考え方について書きました。

task list はAIの最終結論ではなく、現場が確認しやすいように候補を整理したインターフェースです。候補の位置と理由を同時に見せ、status や priority だけでなく geometry の修正も受け取れるようにすることで、現場の判断をデータとして反映しやすくなります。

さらに、確認履歴を残すことで、なぜ候補が変更されたのかを説明でき、蓄積したフィードバックを次回のルールや候補生成の改善に使うことができます。

今回あらためて感じたのは、現場で使えるAIを作るうえで重要なのは、最初から完全な答えを出すことではなく、人が確認し、修正し、改善につなげられる流れを設計することだということです。

次回は、一回の画像だけで判断するのではなく、同じ場所を継続的に観測し、雑草の再成長や作業履歴を時系列でどのように扱うかについて書きたいと思います。

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