全部を一枚の地図に押し込まんでええ。つながる台帳が先じゃ。
共通IDを先に決める
本章の設計案では、組織、農場、圃場、作期、作物、機体、担当者、観測、処方、作業、実績を独立させる。圃場境界が変わっても過去の実績を壊さないよう、境界の版と有効期間を持たせる。
画像の発見と作業の承認を分ける
OGCのSTACは時空間データを記述するJSONの仕組みで、画像等を検索・参照しやすくする。だがカタログに画像があることは、処方や飛行が承認済みという意味ではない。作業の承認状態は別の業務データにする。
接続が切れても二重実行させない
依頼に一意のIDを付け、再送されても同じ作業を重複作成しない。現場端末の記録は同期時に競合を検出する。処方を更新したのに古い機体計画が残る場合は、実行前に版番号の一致を確認する。
このサイトの実装境界
このサイトは知識ガイドと計算ツールで、実機の操縦・農家データの管理サーバーは持たない。本文と調査データはJSON、生成物は静的HTMLじゃ。将来の業務APIに移行しても、特定AIの会話履歴を唯一の仕様書にしない。
データ契約に、値の意味まで含める
NaLamKIは公開インターフェースと分散学習を扱う研究例じゃ。以下はその性能を保証する話ではなく、本ガイドの設計提案。二つの会社が「散布量」を送れても、一方が原液、もう一方が希釈後の液なら接続は成立しない。各項目に意味、単位、座標系、時刻帯、欠測の表現、品質、作成者、版を持たせる。圃場境界はいつ有効だったかも必要じゃ。受信側は不明な単位を推測で補わず保留し、修正担当へ戻す。CSVで持ち出せるだけを互換性と呼ばず、別のソフトで同じ位置、量、対象日を再現できることを受入試験にする。
| 項目 | 必須の意味 | 曖昧なら |
|---|---|---|
| 散布量 | 原液／希釈液、L/ha等 | 処方を保留 |
| 境界 | 座標系、有効期間、版 | 旧版と照合 |
| 観測時刻 | 取得時刻、時刻帯 | 鮮度を未確認表示 |
| 欠測 | ゼロと区別した理由 | 未観測を正常にしない |
依頼・指示・観測・承認を別イベントにする
「完了」という一語では、飛行終了、散布終了、品質確認、顧客への引渡しが混ざる。仕事を依頼受付、計画確定、開始、中断、部分実施、照合、品質確認、引渡しへ分け、各イベントに実行者と時刻を記録しよう。計画を書き換えても過去の実績を消さず、訂正は元の記録を指す追加イベントにする。例えば補給後に別機へ引き継ぐなら、未処理区画と実際の吐出量を確認してから再開指示を作る。通信が戻った際の同じ報告は同じイベントIDで重複排除するが、内容が違うなら自動上書きせず競合として扱う。これでAIが要約しても、責任ある人が元の根拠を追える。
空の予約と農地の処置を、同時に確定しない
圃場の処方が承認されても、その時刻の空路が空いているとは限らん。逆に飛行枠が取れても、資材の条件や現地の準備は未確認かもしれない。提案する仕組みでは、農学的な実施条件と空域・人員・補給設備の予約を別管理し、開始直前に両方の有効性を照合する。天候で一機が帰還した際、全機を同じ補給点へ向かわせないよう、混雑と予備着陸場所を扱う。古い位置情報の機体を地図から消して空いたと判定せず、不明状態の予約を残して担当者へ渡す。ただし、このモデルは運航許可を与えるものでも、実機の安全機能を置き換えるものでもない。
AIを替えても、仕事の台帳は残す
Claude、Grok、その他のツールを替えるたびに圃場や履歴を作り直す構造にはせん。標準的なファイルと明示したAPIを正本へつなぎ、AIは検索・説明・下書きを担当するクライアントとして扱う。AIが提案した処方や予定は、人の承認状態と分け、会話だけを実行指示にしない。モデル更新後に同じ入力で結果が変わるため、使用モデル、入力資料の版、出力、承認者を結ぶ。停止時は最終承認済みの記録を閲覧でき、別の担当者へ引き継げる状態を保つ。将来APIを実装するなら、読み取りと変更の権限、監査、失効、データ持ち出しを最初の契約に含める。