ソラコム公式ブログ

I wanna IoT罠 version2！狩猟罠の遠隔操作デバイス第2弾を Discovery 2026 プロトタイピングコーナーで展示しました！

2026年09月09日 17時30分更新

　本記事はソラコムが提供する「SORACOM公式ブログ」に掲載された「I wanna IoT罠 version2！狩猟罠の遠隔操作デバイス第2弾を Discovery 2026 プロトタイピングコーナーで展示しました！」を再編集したものです。

こんにちは、ソリューションアーキテクトの守谷 (ニックネーム: moris) です。

2026年7月7日に開催された「SORACOM Discovery 2026」で、昨年に引き続き「I wanna IoT罠 version2」と銘打ったデバイスを展示しました。この記事ではその紹介をしていきます。

なお、昨年展示したバージョン1 についてはこちらの記事を読んでいただければと思います。

私は趣味で狩猟（銃猟・罠猟）を行っており、また2026年からは有害鳥獣駆除にも従事しています（狩猟免許・銃所持許可を持っています）。ソラコムでソリューションアーキテクトをやっていることもあり、なんとかIoT技術を用いて狩猟を効率化出来ないか、と日々考えています。IoT罠もその一つです。

IoT罠とは？

遠隔から罠を任意のタイミングで作動させるデバイスです。何はともあれ次の動画を見ていただきましょう。

これは大型の箱罠です。奥行き2m x 幅1m x 高さ1m で、鹿や猪を取るためのものです。動画でご覧の通り、通常は入口の上に吊り上げられている扉が、IoT罠の作動により下に落ち、動物を閉じ込めます。

別角度から

ちなみに、底面のコンパネ合板は、誘引のための餌を配置しやすい、鹿が格子を踏むのを嫌がるのを防ぐ、捕獲された動物が暴れるさいに滑って突進力が弱まる、といった効果を期待して設置しています。

また、内部にぶら下がっているオレンジ色の物体は鉱塩です。こちらは鹿が塩分を好むということで誘引餌の一種として設置しています。雨で溶けないようにポリカーボネートの波板を上に載せています。

こうした箱罠は通常、内部にピアノ線など細い糸を張り、それを動物が引っ張ることで（罠自体の）トリガーが作動し、扉を吊り上げているワイヤーが外れ、扉が重力で落ちる、という構造になっています。

この「ピアノ線を引く」という動作について、通常は罠に入った動物が足を引っ掛けるなどして作動するものを、遠隔操作可能なモーターで動かしてしまおう、というのが、今回の IoT罠のコンセプトになっています。

通常の箱罠は獲物がピアノ線を引くことで自動的に捕獲する仕組みになっていますが、以下のような課題があります。

錯誤捕獲
- 狩猟対象でない獲物がかかってしまう。小型の箱罠の場合はアライグマを狙っているのに猫やタヌキがかかってしまう、大型の箱罠の場合はシカやイノシシを狙っているのに熊が入ってしまう、といったことがあります。特に熊は、シカやイノシシ用の罠を破壊してしまうこともあると言われており非常に危険です。また、狩猟鳥獣以外の動物がかかってしまう、有害鳥獣駆除で申請していない動物がかかってしまう、といった場合には放獣する必要がありこちらも苦労と危険を伴います。
複数の獲物の同時捕獲が難しい
- 大型の箱罠には複数の獲物が入ることがありますが、良いタイミングで罠が作動してくれるとは限りません。最初の一匹だけかかってしまい、残りの動物たちはその姿を見て箱罠が危険なものであると学習してしまいます。可能な限り、群全体を一網打尽にしたいという要請があります。
- 箱罠以外にも、檻を作ってある程度の空間全体を罠として用いる囲い罠という猟法もあります。こちらだと、より複数の動物を同時に捉える能力が高く、また扉を閉めるタイミングが重要になってきます。

出典: 撃退百貨店 (2026年8月21日閲覧) https://gekitai.kwn.ne.jp/55940/

捕獲のタイミングを制御できない
- 自動作動する罠の場合、いつ獲物がかかるかはコントロールできません。狩猟者の状況にもよりますが、都市部で生活し、時々農村や山間部に罠を見回りに行く、といった週末ハンターの場合、獲物がかかるタイミングを自分でコントロールしたい時があります。

こうした課題を解決するため、狩猟者自身が「遠隔で罠を監視し」「狙った獲物が入ったのを確認し」「自分のタイミングで罠を作動する（閉じる）」仕組みを実現するのが IoT罠です！

記事冒頭の動画で、箱罠のトリガーの隣に取り付けられているのが今回制作したデバイスです。
なお、本記事ではこれ以降、このデバイスを「IoT罠トリガー」と呼びます。IoT罠だけだと意味が広く取られる可能性があるためです。

ここからは、今回作成したバージョン2がどのように変わったのかを書いていきたいと思います。

IoT罠バージョン 2 の進化

前回のバージョン 1 はあくまでコンセプト、実際に利用するためではなく「モーターで罠を作動させたら面白いのでは？」という発想からスタートし、とりあえず形にしてみたというものでした。実際に作ってみると、AIの助けを借りたとはいえ様々な困難に直面し、多くの学びがありました。

今回は、バージョン 1 の学びを活かして実際に利用可能な水準のプロトタイプを目標にして開発を行いました。

バージョン 2 のデバイス

中央にサーボモーターとリチウムイオン電池 (18650型) 用ケースが固定されています。ケース右側には穴が開けられており、モーターの羽根（サーボホーン）に固定されたワイヤーが穴を通って外部に露出しています。モーターが作動するとホーンが反対側に回転、ワイヤーが数cm ケース内部に引き込まれる、という寸法です。

モーターが固定されているのはケースの内板で、裏側に通信モジュール( Wio BG770A )が固定されています。

内板を裏返したところ

ちなみに、モジュールにUSB延長ケーブルが刺さっているのは、内板を外さずにファームのアップデートやシリアル出力へのアクセスを行うためです。

Webクライアント

Webクライアントもバージョン 1 で作成したものを改めて作り直しました。全てのコードはClaude Codeが書いていますが、納得がいくものになるまでにはAIとのやり取りがそれなりに必要でした。

通常時は「デバイス切断中」となっており、省電力モードで動作しています。「Connect」ボタンを押すとデバイスに指示が飛び、「デバイス接続中」になります。この状態で「トリガー起動」を長押しするとモーターが駆動、ワイヤーが引かれます。その後、サーボResetボタンを長押しするとモーター位置が元に戻ります。

↓ Connect を押す(数十秒待つ）

↓ トリガー起動を長押し（モーターが作動、ワイヤーが引かれる）

ワイヤーのイラストが縮んでいるところが工夫したポイントです(笑)

↓ サーボ Resetを長押し（ワイヤー位置が元に戻る)

↓ 切断するを押すと「デバイス切断中」に戻る

デバイス切断中の状態ではデバイスは省電力モードのため、指示に即座に反応できません。
Connect ボタンを押すとデバイス接続中モードに遷移します（遅延は数十秒、eDRXサイクルにより変化)。
デバイス接続中の状態になると、Webクライアントからの指示をすぐに受け取り、モーターを駆動します（遅延は1-2秒程度）。

電池持ちをある程度良くしつつ、獲物が近づいた時はすぐにトリガーを動かせるような設計になっています。

バージョン2の変更点

変更点をまとめると以下のようになります。

	バージョン1 (前回)	バージョン2 (今回)
通信	WiFiのみ、LTEルータおよびNAT設定が必要	単体でLTE-Mに接続
省電力	スリープなし、乾電池駆動	eDRX対応し、1週間程度の無給電動作が可能
レスポンス性	死活監視タイミングでHTTPサーバ起動、最大10分待ち	eDRXのサイクル待ち、最大1分(設定変更可能)
モーター	マイクロサーボ(FS90), プラスチックギア、トルク1.3kg・cm	デジタルサーボ(DS3218MG), 金属ギア, トルク20kg・cm
組立方式	ブレッドボード, 針金, 両面テープ	ユニバーサル基板に半田付け, ねじ止めで取り外し可能
動作検証	室内で小型箱罠での動作試験	実際の猟場にて大型箱罠での動作試験

それぞれ細かくみていきます。

通信方式の変更: セルラーに対応することでシンプルで繋がりやすく

バージョン1 では、WiFi対応（セルラー非対応）のマイコン WioTerminal を用いたため、WiFiアクセスポイントを外部に用意する必要がありました。SORACOMプラットフォームに接続する必要があるため、ラズパイにOnyxドングルを挿し、アクセスポイント化して利用しました。さらに、SORACOMプラットフォームからの Remote Command を受信するため、ラズパイにポートフォワーディングを設定し、ラズパイ向けの特定のポートに送信されたHTTPパケットをWiFiで繋がったWio Terminalにルーティングしてあげる必要がありました。

IoT罠トリガーには獲物がかかったのを確認するためのカメラが必要になります。WiFi アクセスポイントを1つ用意し、そこにIoT罠トリガーとカメラを接続することで通信料・基本料を抑えたい、という思いからWiFiを使う設計にしたのですが、デバイスが増えることで電源やデバイス間の接続設定など、取り回しが不便になってしまいました。

バージョン2ではこの反省もあり、直接セルラー通信可能な通信ボード(Wio BG770A)を用いています。また、カメラ側もセルラー通信に対応したトレイルカメラを用いることにしました。これによりデバイスが電源を入れるだけで動作可能になり、アクセスポイント用の電源などの問題も解消しました。

ちなみに、トレイルカメラの映像は以下のような感じです。

夏なのでだいぶ下草が伸びていますが、罠の状況は鮮明にわかります。

省電力性の向上: eDRX対応で無給電でも長時間動作

バージョン1では WioTerminalにスリープ機能がなかったため、常時ウェイクアップした状態でした。ファームウェアの仕様としては定期的に metadata サービスを確認 -> 状態遷移の指示があれば HTTPサーバを立ち上げ、トリガー作動指示を待ち受け、としていましたが、電池の持続時間への貢献は今ひとつといったところでした。

Wio BG770A は LTE-M の省電力機能である eDRX や PSM に対応しており、今回は eDRX を利用しました。
eDRXは基地局からの着信を監視する受信動作を一定間隔(数秒〜数十分) の間欠動作にすることで消費電力を抑える機能で、設定した間隔に応じた遅延はありますが、クラウドからの通信を受け取ることができます。PSMは通信モデムを長時間（規格上最大約413日）深くスリープさせるためさらに低消費電力ですが、今回は使用していません（理由は後述)。

電池には 18650型 3500mAh のリチウムイオン電池を使用しています。デバイスの写真には電池ケースが2つ写っていますが、これはサーボモーター用と通信ボード用に分けているためです。モーターが駆動した瞬間に電圧が降下し、ボードの電源が落ちてしまう可能性を懸念してこのような構成にしています。

実際に動かしてみると、eDRXサイクル: 61.44秒, Heartbeat間隔: 30分の場合 6日間程度の動作が確認できました。長期の稼働にはソーラー充電への対応が必要ですが、さしあたりは eDRXサイクルやHeartBeat間隔を長くすることで１週間程度の動作は可能と思われます。

レスポンス性の向上: 省電力動作の方針変更で実用性向上

バージョン1では「デバイスが定期的に立ち上がる -> metadata サービスを確認 -> 状態遷移指示があればウェイクアップして作動指示をリッスン」という動作パターン ( Pullアクセスパターン )でした。

今回も同じ動作であれば、PSMを使った方が長期間のバッテリー駆動が可能となりますが、PSMのスリープ期間中はクラウドからのパケットを受信できないため、あまり長いスリープ期間を設定してしまうと、罠に動物が入っているのを見てもタイミングよく作動させることができません。
IoT罠トリガーの性質として、あまり長い遅延は許容できません。このため、eDRXを使って間欠受信するだけにとどめ、デバイスのウェイクアップ指示には Remote Command (UDP) を使う、という方針を採用しました。

PSMに比べて消費電力は大きくなるのですが、将来的にはソーラーパネルからの給電も見据え、バッテリー駆動期間は１週間程度あれば十分と判断しました。

Pullアクセスパターンでは、デバイスに要求されるレスポンスタイムが短いほどスリープ間隔も短くする必要があり、必然的に通信頻度も高くなってしまいます。また、死活監視データの保存に用いるHarvest Data や Remote Command はオーバーヘッドの少ないUDPでの通信が可能ですが、metadata サービスは HTTPでの通信が必須となります。Pull アクセスパターンで 10分おきにmetadata サービスを読みに行くと、今回の場合 1ヶ月の通信量は約 20MBになりました（実測値から算出)。通信回線に SORACOMの planX3 を使う場合、5MBまでなら基本料にバンドルされているので、できればそれ以下に抑えたいです。

月の通信量を抑えるためには metadata 取得間隔（= スリープ間隔）を伸ばす必要がありますが、そうするとカメラから通知が来ても素早くIoT罠トリガーをウェイクアップすることができません。例えばスリープ間隔を60分にした場合、通信量は5MBを下回りそうですが、獲物が最大60分も罠の周りをうろうろしてくれるとは思えません。

eDRXを利用して Push アクセスパターン（クラウド -> デバイス) に変更することで、レスポンスタイムと通信頻度を分けて考えることができ、レスポンスタイムを維持したまま通信量を抑えることができるようになりました。例えば eDRX の間欠受信間隔を約60秒, Heartbeat / metadata 取得間隔を60分とした場合、通信量を 1/6 に抑えつつ、ウェイクアップのレスポンスタイムは最大60秒程度に維持することができます。

モーターの変更により耐久性向上

バージョン1では電子工作によく使われるプラスチック製ギアのマイクロサーボモーターを利用していました。元々、狩猟罠のトリガーというのはそこまで大きなトルクを必要としない作りになっているため、マイクロサーボでも大型箱罠に使えるかもしれません。ただし、実際の猟場で使う時に十分な耐久性があるのかは疑問でした。そこで、今回はラジコン用に使われる防水性・金属ギアのデジタルサーボモーターを採用しました。価格としてはそこまで高額でなく、トルクも20kgとなり余裕があります。

ハードの組み込み方式: ブレッドボードからユニバーサル基板

バージョン1は本当に簡易的な作りで、ブレッドボードにジャンパピンを指して電池やモーター、マイコンをつなぐ回路を構成していました。ちょっとした操作でピンは抜けてしまいますし、電池の節約のためにピンの抜き差しが必要、など実用に耐える作りではありません。

今回はユニバーサル基板に配線を半田付けするなどして、実用を考えた作りにしています。前回の反省を活かし、電源スイッチも実装しています。
（回路を単純化するため、電池をマイコン用とサーボモーター用で2つ用意しており、その影響で電源スイッチも2つあります）

大型の箱罠での動作試験もクリアしました。冒頭の動画がその試験内容になります。もう一回貼っておきましょう。何度でも見てください。
https://youtu.be/bTwRtI-90dY

IoT罠トリガーが動いて、罠の扉が落ちているのがわかるでしょうか。とてもいい感じです（自画自賛）。

作ってみた感想

デバイスやWebクライアントの仕様としてはそれほど複雑ではないはずですが、実際に作ってみると多くの学びがありました。

省電力性の要求を緩和し、Push アクセスパターンに変更することでレイテンシが改善され、システム全体の構成もシンプルになり、メリットが多かった。当初の設計に拘らず、システムの要件に合わせて見直すことが重要。
AIが高速にコードを書いてくれるようになり、ソフトウェアの仕様変更は大きな問題ではない。思いついたことを素早く実装・検証することで学びが得られる。机上での設計も大事ではあるが、手を動かす重要性が高まっている。
ソフト側よりハードウェアの設計・実装が大変だった。回路設計や部品の選定もAIがやってくれる時代だが、半田付けは人間がやるしかない。また、意外とネジ穴のサイズが部品の穴径と合わないなど、細かい問題で苦労した。AIに調べてもらうのも良いが、ホームセンターや秋葉原の電子パーツショップで実物を見るのもインスピレーションを得られて良い。