City AI Poleは、ローカルコンピューティング、セキュリティセンシング、環境モニタリング、ドローンと地上ロボットの連携運用を統合した、フィジカルAI型の都市エッジノードです。SOLARTODO SentinelのSky Hubは、OTATODOで稼働する、完全オフグリッド型の照明機能を持たないポールです。今回提案するバンコク向け構成では、地上ロボットによる点検を用いてスポーツイベントの交通インシデントを評価し、人が承認した対応を支援するとともに、生データをポール内に保持したまま誤警報を評価します。
1. 検証対象のインシデント：スポーツイベント退場時の判断が難しい通行障害
ここで検証するインシデントは、計画検討用の想定事例であり、バンコクで実際に報告された出来事ではありません。スポーツの試合終了後、歩行者が交通結節点に集中する一方、隣接する進入路では大型バス、タクシー、業務用車両が通行します。横断歩道付近で1台の車両が停止し、人の流れが遅くなり、縁石の周辺に人が集まります。警備上の判断点は、これが通常の乗車行動なのか、故障なのか、衝突事故なのか、あるいは介入が必要な通行障害なのかということです。
仮設イベントの計画に関わるエコ・環境チームにとって、この区別は重要です。不要な出動は職員の注意を奪い、すでに混雑している接続エリアでの移動を増やします。状況評価が遅れると、歩行者が危険にさらされたままとなり、車両の滞留が長引く可能性があります。環境観測にも状況の把握が必要です。一時的な騒音や粒子状物質の増加を、自動的にセキュリティインシデントとして扱ったり、根拠なく特定車両に起因すると判断したりしてはなりません。
運用上の中心的な課題は、人による巡回では状況確認に時間がかかることです。判断が難しいカメラ警報を受けた担当者は、何が起きたかを確認するまでに、退場する観客の中を歩いて移動しなければならない場合があります。その間、同じ状況が繰り返し観測され、重複警報が発生する可能性があります。そのため、混雑した現場では、新たな危険が生じていなくても、評価時間と見かけ上のインシデント件数の両方が増えることがあります。
提案する対応では、SOLARTODO Sentinelの成熟したSky Hubの機能群を、仮設イベント向けの構成で使用します。本記事で説明するのは導入設計と評価であり、バンコクにおける顧客への導入実績や達成済みの成果ではありません。主たる対応手段は地上ロボットによる状況評価であり、空中運用は補助的な手段として位置付けます。導入側の主要な評価指標は誤警報率ですが、指標を改善するためだけに実際のインシデントが抑制されないよう、対策を設けます。
2. 初動判断の再構成：出動前のセンシング
提案するノードは、現地調査と最終的な技術確認を条件として、交通結節点への進入部に隣接する、承認済みのイベント運営区域内に設置します。配置にあたっては、歩行者の流れ、バリアフリー動線、緊急車両などのアクセス、および保護されたロボット帰還経路を確保する必要があります。仮設であっても、技術設計に基づく固定、機器周囲の必要空間、排水評価、合意済みの撤去手順が必要です。仮設とは、固定が不要であることや、どこにでも設置できることを意味しません。
PTZカメラは、匿名化された車両台数の計測、群衆密度、侵入、周界状況の把握に向けたローカル認識機能を提供します。この想定インシデントでは、停止車両と歩行者の動きの変化を組み合わせたものが初期トリガーとなります。OTATODOはこれらの観測をポール内で処理し、関連する検知を関連付け、評価用に個人を特定できない形式のイベント概要を提示します。カメラが同じ通行障害を再び捉えたという理由だけで、繰り返しの計測を別々のインシデントとして扱うべきではありません。
環境センサーパッケージは、風速、風向、温度、湿度、気圧、騒音、PM10、PM2.5、照度を測定します。この9項目の測定値は、運用状況を理解するための情報を補います。照度は測定対象の変数です。Sky Hubは照明システムを持たないPUREスマートポールです。環境変化は検証の参考情報になりますが、衝突の重大性を確定したり、排出源を特定したり、現場での状況評価に代わったりするものではありません。
共通状況図を用いた指揮画面には、イベントの位置、分類、不確実性、ロボットの利用可否、エネルギー状態、タスク履歴を集約します。遠隔オペレーターが受け取るのは、個人を特定できない形式のイベントおよび状態のメタデータのみです。生の映像とセンサーデータはポール内に保持し、ローカルで処理します。生記録の詳細な確認が必要な場合、提案手順では記録を外部に転送せず、ノードで管理されたアクセスを提供します。この制約を当初から運用手順に組み込みます。
3. 対応の検証：地上ロボットが観測の空白を埋める
権限を持つオペレーターがイベント概要を評価した後、指揮画面からサービスロボットに、事前調査済みの運用区域内での点検タスクを割り当てます。ロボットは、利用者や車両との間隔を保ちながら、承認済みの経路を通って接近します。その役割は、通行障害周辺の状況を確認し、状況認識を支援することであり、交通整理を行ったり、緊急対応機関の権限を担ったりすることではありません。
この事例で確認すべき点は具体的です。歩行者の経路が塞がれているか、車両が引き続き停止しているか、人による現場対応が必要か、という点です。ロボットによる観測はポール内での評価を支援し、より広域の指揮画面に送られるのは個人を特定できない形式の判断結果のみです。現場の状況が依然として不明確な場合、そのイベントは未解決のままとし、職員へエスカレーションします。経路にアクセスできない場合や混雑している場合は、ロボットのタスクを停止または延期すべきであり、観客の中を強行して進む理由にはなりません。
これにより、人による巡回のワークフローが変わります。職員は、緊急事態や判断が難しい事例への責任を維持しながら、追加観測によって裏付けられたインシデントを優先できます。ロボットは、自律巡回、警報対応、点検、空地連携にも対応します。割り当てられた作業を完了すると、ワイヤレス充電のためにポール基部へ戻ります。経路の利用可否と充電状態はインシデントと併せて表示されるため、次の出動判断に実際の稼働準備状況を反映できます。
ドローン運用は、適用される運用許可条件の範囲内で、補完的な広域視点を提供します。このノードは、ポールにオペレーターを常駐させることなく、自律的な離陸、巡回、点検、帰還、タスクへの再投入に対応します。複数ベイを備えたバッテリーマガジンが、着陸後に後部アクセス方式で自動交換を行い、充電済みパックを装着して再離陸に備えます。複数ベイにより連続出動を支え、経路計画、充電・交換状態管理、タスクキュー、機体群の健全性、ミッションログによって一連の運用を調整します。こうした機能があっても、すべての交通警報に対してドローンを出動させる必要はありません。
4. 運用上の制約の検証：エネルギー、承認、ローカルデータ
Sky Hubは、蓄電池とポール上の太陽光による補充電を使用して完全オフグリッドで稼働し、系統電源、都市側の電源、設置場所の電源を使用しません。高さ約8 m、幅約0.6 mの円筒形本体には、約15 m²の柔軟なCIGS薄膜を360°巻き付け、銘板上の定格容量は約2.4–2.7 kWpです。この定格値を、終日利用できる稼働出力として扱ってはなりません。
ある時点で直射日光を受けるのは、円筒の太陽に面した投影面のみです。サウジアラビアのような高日射量の参照地域では、現実的な晴天時出力はDCピークで約0.8–1.1 kW、日量で6–9 kWh/dayであり、ピークは正午ではなく午前の中頃または午後に生じます。これらの参照値は、バンコクでの発電量予測ではありません。イベント会場の遮蔽、雲、雨、温度、設置形状を踏まえた、現地でのエネルギー評価が必要です。
CIGS層は、蓄電池を備えたマイクロステーションへの補助的な補充電を担います。5–20 kWhクラスの蓄電容量が、より大きな電力を必要とするドローンやロボットのタスクを支えます。OTATODOは、デューティサイクル、利用可能なエネルギー、運用上の優先度に基づいてワークロードをスケジュールします。蓄えられるエネルギーには限りがあります。そのため、仮設イベントの計画では、開始時の充電要件、予備残量のしきい値、稼働を抑える手順が必要です。評価したエネルギー収支でイベント日程を支えられない場合は、導入前に構成またはタスク日程を変更しなければなりません。
対無人航空機システム（counter-UAS）の連携には、別の承認上の境界を設けます。Sentinelは無許可のドローンを検知・追跡し、人による承認と該当する運用許可が得られた場合に限り、自らの味方ドローンに、ソフト方式の空中ネット捕獲または近接による抑止を指示できます。レーダーはポールに内蔵されていません。オプションのパートナー製センサーから追加情報を提供できる場合があります。このワークフローは、通常の交通状況評価とは分離して運用します。
データアーキテクチャはローカル処理を前提に設計され、PDPL/LGPDを意識したものですが、認証取得や法令遵守の確立を主張するものではありません。バンコクの導入側は、適用されるタイのプライバシー要件、保存期間、アクセス制御、運用許可を別途検証する必要があります。
5. 検証の締めくくり：見逃しを隠さずに誤警報を測定する
提案する評価は、定義への合意から始まります。この導入における誤警報率は、確認済みのセキュリティ警報のうち、所定の警備対応が不要と判断されたものの件数を、確認済みのセキュリティ警報の総件数で割った値とします。この運用指標は、実際に陰性である観測すべてを分母にして算出する統計上の偽陽性率とは異なります。この区別により、調達文書と運用報告で、異なる分母を持つ指標に同じ名称を使うことを防ぎます。
評価者は、確認済みインシデント、問題のない活動、重複警報、未解決イベントという分類を一貫して適用すべきです。通常の乗車行動は問題のない活動に、1件の通行障害に対する繰り返しの通知は重複警報に該当し得ます。未解決の事例は、問題なしと数えるのではなく、引き続き可視化しておく必要があります。軽微な通行障害の正確な検知は、緊急出動が必要でない場合でも有用になり得るため、対応のしきい値を明確に定義する必要があります。
ロボットによる状況評価が判断を改善するかを検証するには、比較可能なイベント時間帯同士を比較し、群衆の状況、経路の利用可否、天候、警報しきい値、要員配置を記録します。ロボット点検の前後の分類を保持します。警報件数を減らすだけでは警備の改善を示せないため、警報がなかった時間帯についてもサンプルを抽出して検証します。見逃したインシデント、未解決事例、ロボットのタスク失敗は、主要指標が見かけ上改善している場合に必要な確認項目となります。
エコ・環境分野の関係者向けには、不要な現場移動と、環境に関する状況情報の利用可否も記録すべきです。こうした観測は、その後の運用判断に役立つ可能性がありますが、排出量削減や環境保健上の便益を証明するものではありません。そのような結論には、追加の測定方法と証拠が必要です。
権限を持つオペレーターが処理結果を記録し、必要な対応要員への引き継ぎを確認し、ロボットのタスクを終了すると、インシデントはクローズします。その後、次の割り当てに備えて、保守担当が充電、バッテリー予備残量、センサー、帰還経路の状態を確認します。これにより、センシング、承認に基づく評価と対応、エッジコンピューティングのスケジューリング、現場運用と保守からなる1つの運用ループが完了します。調達判断は、この追跡可能なワークフローと実測による評価結果に基づくべきであり、バンコク向けの最終構成は技術確認を条件とします。
システム構成
| 項目 | 構成 |
|---|---|
| ポールと設置 | 照明機能を持たないPURE Sky Hub。高さ約8 m、幅約0.6 mの円筒形本体。技術設計に基づく仮設イベント向け設置 |
| オフグリッド電源 | 約15 m²の巻き付け型フレキシブルCIGS、銘板上の定格容量約2.4–2.7 kWp。5–20 kWhクラスの蓄電池。最終的な容量設計はエネルギー評価に基づく |
| エッジコンピューティングとデータ | ポール内AI推論とOTATODOによるワークロードのスケジューリング。生データのローカル保存。外部送信は個人を特定できない形式のイベント・状態メタデータのみ |
| セキュリティと環境 | 匿名化されたローカル認識機能を備えるPTZカメラ。風速・風向、温度、湿度、気圧、騒音、PM10、PM2.5、照度のセンシング |
| 地上運用 | 巡回、点検、警報の状況評価を行うサービスロボット。事前調査済みの経路とポール基部のワイヤレス充電 |
| 空中運用 | ドローンの自律離陸・帰還インターフェース、複数ベイによる後部アクセス方式のバッテリー交換、ミッション管理。人の承認に基づくcounter-UAS連携 |
仕組み
- ポール上のPTZカメラが、停止車両と歩行者の動きの変化を検知する。
- OTATODOが観測をローカルで関連付け、個人を特定できない形式のイベント概要を作成する。
- 権限を持つオペレーターが概要を評価し、地上ロボットによる点検を承認する。
- エッジスケジューラーが、経路の利用可否、バッテリー予備残量、タスク優先度を確認する。
- ロボットが点検を行い、必要に応じて対応要員への引き継ぎを支援した後、ワイヤレス充電のために帰還する。
- オペレーターが処理結果と誤警報の分類を記録し、生記録はポール内に保持する。
計画前提(参考値)
購入者が再計算できる例示的な計画入力値であり、達成済みの結果ではなく目標指標です。最終的なエンジニアリング確認が前提です。
| 指標 | 計画前提 | 参考値 |
|---|---|---|
| 警報確認の作業量 | 例示のみ：イベント開催日1日あたり40件の警報が3日間発生し、各警報の確認に2分を要すると仮定。 | 40 × 3 × 2 = 240分の確認作業を計画上見込む |
| 誤警報評価の目標 | 例示のみ：120件の警報を評価対象とし、所定の警備対応が不要と分類される警報を上限30件とする目標を設定。 | 30 ÷ 120 × 100 = 25%は例示的な目標であり、達成済みの結果ではない |
| 回避できる人による状況確認の作業量 | 例示のみ：ロボット支援による状況評価で、1回あたり8人・分を要する不要な現場訪問を10回回避すると仮定。分類の妥当性と安全性は別途検証。 | 10 × 8 = 80人・分は、仮定上の回避可能な作業量 |
| エネルギー計画の概算確認 | 例示のみ：公称蓄電容量10 kWhのうち70%を利用可能と仮定し、スケジュールされた平均負荷0.5 kWに供給。この計算では太陽光発電を含めない。 | 10 × 0.70 ÷ 0.5 = 14時間は、変換損失を考慮する前の例示的な電力供給可能時間であり、稼働時間を保証するものではない |
導入機器
- 技術設計に基づく仮設取付設備を備えた、照明機能のないSky Hubポール
- 巻き付け型フレキシブルCIGSによる太陽光補充電層と蓄電池
- OTATODOが稼働し、ローカルストレージを備えるポール内コンピューティングキャビネット
- PTZ防犯カメラと9項目の環境センサーパッケージ
- サービスロボットとポール基部のワイヤレス充電インターフェース
- ドローン離陸・帰還インターフェースと複数ベイのバッテリー交換マガジン
- 個人を特定できない形式のイベント・状態メタデータを扱うよう設定された指揮画面端末
よくある質問
これはバンコクでの既存導入に関する報告ですか？
いいえ。これはSentinelの成熟した機能群を用いた、バンコクの交通結節点向けの提案構成と想定インシデントの検証です。導入済みの顧客を示すものでも、実際のスポーツイベントでのインシデントを報告するものでも、達成済みの成果を主張するものでもありません。設置場所の選定、設置、許認可、評価基準には、導入側の合意と最終的な技術確認が必要です。
交通インシデントの警備で地上ロボットを優先する理由は何ですか？
遠隔警報だけでは判断が難しく、人による巡回では到着に時間がかかる場合、地上ロボットは通行障害周辺の追加観測を提供できます。その有用性は、事前調査済みで通行可能な経路と、人や車両からの安全な間隔を確保できるかに左右されます。緊急対応要員を代替したり、交通整理の権限を担ったりすることなく、人による評価と対応要員の優先順位付けを支援します。
太陽光だけでイベントの全期間を通じて稼働できますか？
太陽光のみでの連続稼働は約束していません。Sky Hubは完全オフグリッド型で、有限の蓄電容量と補助的な太陽光補充電を組み合わせます。提示した高日射量地域の参照値は約6–9 kWh/dayであり、バンコクでの予測ではありません。技術者は、現地の発電量、開始時の蓄電量、変換損失、予備容量の要件、ドローンとロボットのデューティサイクルを、イベント日程に照らして評価する必要があります。
導入側は誤警報KPIをどのように解釈すべきですか？
提案する運用KPIは、確認済み警報のうち合意済みの警備対応が不要なものの件数を、確認済み警報の総件数で割って算出します。導入側は、評価前に対応のしきい値を定義し、重複警報と未解決事例を個別に追跡すべきです。警報件数が少ないだけでは、警備運用の精度や安全性が高まったことを示せないため、見逃したインシデントと、運用条件が比較可能かどうかも確認する必要があります。
指揮センターにはどのようなデータが送られますか？
ポールの外部に送信できるのは、個人を特定できない形式のイベントおよび状態のメタデータのみです。生の映像とセンサーデータは、ローカル処理のためにポール内に保持します。そのため、遠隔の指揮画面では、概要、タスクの状態、機器の状態を通じて意思決定を支援します。生記録の詳細な確認には、管理されたローカルアクセスが必要であり、保存期間とアクセス権限を導入時に定めます。
ドローンおよびcounter-UASの活動には、どのような許可が必要ですか？
ドローン運用には、適用される空域、設置場所、イベントの運用許可が必要です。counter-UAS対処には、人による承認と、ノード側の味方ドローンによるソフト方式の空中ネット捕獲または近接による抑止について承認された運用手順が必要です。検知しただけで介入が許可されるわけではありません。レーダーはポールの搭載機器ではありませんが、オプションのパートナー製センサーから情報を提供できます。
さらに詳しく
街路・キャンパス・公共空間で同様のフィジカルAI導入をご検討ですか? エンジニアリング相談を依頼する