ラズパイ監視カメラの作り方｜録画・通知・クラウド保存

ラズベリーパイで監視カメラを自作する際、どのカメラを選ぶか（Camera Module V3 / HQ Camera など）、まずは motionEyeOS で素早く立ち上げるか、Raspberry Pi OS と Python で通知まで作り込むかで迷いがちです。
この記事は、自宅の見守りや小規模オフィスの状況確認を目的に、必要な機材と最初の構成を最短で決めたい人向けに、ライブ視聴、録画、動体検知通知、クラウド保存までの道筋を整理します。
遠隔確認は VPN 経由に限定すると安全性が高まるため、原則としてポート開放は避ける前提で進めます。

関連記事ラズベリーパイ入門｜できること・始め方・選び方[Raspberry Pi](https://datasheets.raspberrypi.com/pico/getting-started-with-pico-JP.pdf)はArduino Uno Rev3や[Raspberry Pi Pico](https://datasheets.raspberrypi.com/pico/getting-started-with-pico-JP.pdf)のようなマイコンではなく、Linuxを動かして学習から電子工作、軽いサーバー運用までこなせる小型のシングルボードコンピュータです。

ラズパイ監視カメラでできることと、最初に決めるべき3つ

できること一覧と用途の対応表

ラズパイ監視カメラの魅力は、できること自体は市販のネットワークカメラに近いのに、録画・通知・保存の組み合わせを自分の目的に合わせて組める点です。Raspberry PiはLinux系OSを動かせる小型コンピュータなので、単に映像を映すだけでなく、録画の条件分岐や通知連携まで一台でまとめられます。
ブラウザ中心で組むなら『motionEyeOS』系、自由度を優先するならRaspberry Pi OSとPythonや『Telegram』連携という分け方になります。

まず全体像をつかむなら、機能と用途を対応で見るのが早いです。

できること	何に使うか	家庭用途での実感
ライブ視聴	今の状況確認	置き配が届いたか、子どもやペットがどこにいるかをその場で見られます
常時録画	連続した記録の確保	出入りが多い場所や、あとから流れを追いたい場所に向きます
動体検知録画	動きがあった場面だけ保存	家庭ではこの方式がもっとも扱いやすく、保存容量も抑えられます
通知	イベント発生の即時把握	人の動きがあった瞬間にメールや『Telegram』へ知らせられます
クラウド/ネットワーク保存	ローカル故障への備え、長期保存	SDカードだけに依存せず、NASやクラウドへ逃がせます
遠隔確認	外出先からの確認	VPN経由で玄関や室内の様子を見返せます

図にすると、流れはシンプルです。

カメラで撮る → ライブ表示する → 録画条件を決める → 必要なら通知する → SD/USB/NAS/クラウドに保存する → 外出先から確認する

筆者の感覚では、家庭用途は「高画質で全部残すこと」よりも、「必要なときに見られること」が先です。
実際、常時録画より動体検知中心のほうが日常運用に馴染みますし、フレームレートも15fps前後あれば玄関の出入りや置き配確認では十分に場面を追えます。
監視映像は映画のような滑らかさより、誰が来たか、何を置いたか、どの方向へ動いたかが読めるかどうかで実用性が決まります。

監視カメラと防犯カメラの違い

ここで一度、監視カメラと防犯カメラの違いを整理しておくと、設置方針がぶれません。
一般的な使い分けでは、監視カメラは記録と状況把握が主目的、防犯カメラは抑止が主目的です。

監視カメラとして組むなら、重視するのは「見たい場所がきちんと映ること」です。
たとえば玄関前の荷物、室内のペットスペース、倉庫のシャッター付近など、出来事が起きる範囲を確実に画角へ入れることが先になります。
この場合、カメラは必ずしも目立つ位置でなくても構いません。
むしろ逆光を避けられる位置や、出入りの動線を斜めに捉えられる位置のほうが映像としては価値があります。

一方で防犯カメラとしての役割を持たせるなら、「見えていること」自体が意味を持ちます。
目立つ場所に設置して、録画中であることが伝わる見せ方のほうが抑止力につながります。
監視カメラが“証拠を残す”寄りなのに対して、防犯カメラは“やろうと思わせない”寄りです。
同じCamera Module V3でも、この違いを意識するだけで置き場所は変わります。

カメラ選びにもこの考え方は反映できます。
玄関で広めに周囲を見たいなら、標準で約75度、Wideで約120度の視野角を持つCamera Module V3の性格がわかりやすいです。
画角を広く取れば死角は減りますが、人物や荷物は相対的に小さく写ります。
逆に、倉庫の出入口のように「通る一点」をはっきり捉えたいなら、交換レンズ前提のHQ Cameraの考え方が合います。
記録重視か抑止重視かを先に言葉にしておくと、標準画角で足りるのか、ワイドに寄せるのか、あるいはレンズ選定まで踏み込むのかが決めやすくなります。

最初に決める3つ：録画方式・通知方式・保存先

ラズパイ監視カメラで迷いやすいのは、カメラ本体よりも「運用のルール」を後回しにしてしまうことです。
先に決めるべきなのは、録画方式、通知方式、保存先の3つです。
この順番で固めると、必要なソフトとストレージ容量が自然に決まります。

1つ目は録画方式です。
選択肢は大きく常時録画か動体検知録画です。
常時録画は流れを途切れなく残せる反面、保存容量を多く使います。
動体検知録画は、動きがあった場面だけを残せるので、家庭ではこちらが主役になります。
Canonの動体検知の解説でも、動きのある場面だけ保存する方式は容量削減に向くと整理されています。
筆者も自宅では動体検知中心で回していますが、あとから見返す場面の多くは「何か起きた瞬間」なので、常時録画が必要になる場面は思ったより限られます。

2つ目は通知方式です。
メール通知は導入のわかりやすさがあり、『motionEyeOS』系でも扱いやすい構成です。
対して『Telegram Bot API』を使う構成は、画像付き通知や自作フローとの相性が良く、複数のイベントを整理しやすいのが利点です。
筆者は『Telegram』をよく使います。
通知先がチャットにまとまるので、玄関カメラと室内カメラを分けても追跡しやすく、必要なら静止画だけ送る、短い動画だけ送るといった調整もしやすいからです。

3つ目は保存先です。ここはストレージの性格差を押さえると整理できます。

保存先	向く場面	特徴
SDカード	最小構成で始めるとき	配線が少なく手軽ですが、連続書き込みの負荷は重めです
USB/SATA外付け	録画時間を伸ばしたいとき	SDカードより録画運用に向き、容量も増やしやすい構成です
NAS/ネットワーク保存	複数カメラをまとめたいとき	保存を集約でき、ラズパイ側の負担を減らせます
クラウド保存	オフサイト保全を持たせたいとき	遠隔から扱いやすい一方で、保持管理は自前設計が前提になります

録画時間の感覚も持っておくと判断しやすくなります。
1080pの常時録画を4Mbps前後で見積もると、1時間で約1.8GBです。
64GBの高耐久microSDなら連続でおよそ35時間ほど入る計算なので、常時録画を長く続けたいならSDカード単体では窮屈です。
逆に、動体検知録画なら必要な場面だけ残るため、同じ容量でも運用期間は大きく伸びます。
一般的な保持日数の目安としては30日がよく使われますが、家庭では「毎日見返すのか」「トラブル時だけ見返せればよいのか」で適切な長さが変わります。
筆者は、保存先を決めるときに“何日残したいか”より“どの出来事を落としたくないか”を先に考えるようにしています。

{{product:3}}

用途別完成イメージ：玄関/屋内/倉庫

完成形を先に思い描くと、必要な画角や保存方針が決めやすくなります。ここでは家庭でよくある3パターンに分けて、ラズパイ監視カメラの完成イメージを具体化します。

玄関の置き配確認なら、欲しいのは“荷物が置かれた瞬間と、持ち去られた動きが見えること”です。
カメラはドア正面より少し高めの斜め位置に置くと、人物の顔と足元の荷物を同時に収めやすくなります。
広めの範囲を一台で見たいならCamera Module V3 Wideの約120度が合います。
解像度はフルHD級で十分で、フレームレートは15fps前後でも出入りの確認には不足しません。
録画方式は動体検知中心、保持日数は短めでも実用になります。
玄関映像は“何か起きた日だけ見返す”ことが多いからです。

屋内の見守りでは、置き配確認ほど広角は要りません。
ペットの居場所、子どもの帰宅、部屋の明かりが消えているかといった確認なら、Camera Module V3標準の約75度が収まりやすい画角です。
室内は人の動きがゆるやかなので、ここでも15fps前後で困る場面は多くありません。
筆者も家庭用途では、このくらいの設定が最も扱いやすいと感じています。
録画は動体検知で十分なことが多く、保存先はSDカードでも始められますが、日常運用まで考えるとUSB保存かNAS保存に寄せたほうが後から詰まりません。
保持日数は中くらいを想定すると、家族の行動確認と容量のバランスが取りやすくなります。

倉庫や夜間の監視では、室内見守りよりも「出入口を逃さないこと」が優先です。
ここでは広角で全体を入れるより、侵入経路を外さない構図のほうが価値があります。
出入口一点を狙うなら標準画角でも十分で、より画質やレンズ選択を詰めたいならHQ Cameraも候補になります。
倉庫は夜間の変化を追いたいので、常時録画か、感度を詰めた動体検知録画が向きます。
保持日数も玄関や屋内より長めに取りたい場面です。
録画量が増えるため、保存先はNASや外付けストレージ前提で考えたほうが自然です。

用途ごとの目安を表にすると、設計の差が見えます。

用途	画角の目安	解像度の考え方	fpsの目安	録画方式	保持日数の考え方
玄関・置き配確認	広め。Camera Module V3 Wideの約120度が候補	荷物と人物の動きが読めるフルHD級	15fps前後	動体検知中心	短めでも回しやすい
屋内見守り	標準。Camera Module V3の約75度が収まりやすい	表情より行動確認を優先するフルHD級	15fps前後	動体検知中心	中くらいでバランスを取りやすい
倉庫・夜間監視	出入口重視。標準画角またはHQ Cameraで調整	侵入経路を確実に読める解像度を優先	15fps前後を基準に、記録重視なら上げる	常時録画または調整済み動体検知	長めを前提に設計したい

この段階で「どこを見るのか」「何を残したいのか」が言語化できていれば、カメラ選びで迷いにくくなります。
ラズパイ監視カメラは部品選びから入りがちですが、実際には完成イメージの解像度が高いほど、必要な構成はすっきり決まります。

関連記事ラズパイ カメラの使い方｜撮影・録画・配信Raspberry Piでカメラを始めるなら、まず押さえるべきなのはモデル選びよりも、最短で「映る・保存できる・Pythonで触れる・配信できる」まで到達する手順です。

必要なもの｜おすすめ構成を用途別に整理

raspberry-pi本体の選び方と目安価格">Raspberry Pi本体の選び方と目安価格

監視カメラ用途のRaspberry Pi本体は、まずRaspberry Pi 5とRaspberry Pi 4 Model Bの2択で考えると迷いません。
どちらもLinux系OSを動かせて、GPIOやカメラインターフェースを備えています。
基本の仕組みはRaspberry Pi hardware overviewでも整理されています。

Raspberry Pi 5は、これから新しく組むなら第一候補です。
現行世代なので情報が集まりやすく、今後の周辺ソフトとの相性も取りやすいからです。
公式発表では1GBモデルの追加がアナウンスされていますが、国内の実売価格や在庫は流動的です。
購入時は販売店の当日価格や在庫状況を必ず確認してください。
監視カメラは録画・配信・通知・Web UIが重なるとバックグラウンド処理が増えるため、余裕を見たいならPi 5系が安心です。

一方で、Raspberry Pi 4 Model Bもまだ十分に現役です。
過去には4GBモデルが15,999円前後で流通した例がありますが、実売価格は流通や販路で変動するため、購入時は販売店の当日価格を確認してください。
既に持っているなら流用候補として優秀です。

本体選びで見落としやすいのが、カメラ用ケーブルです。
Camera Module V2V3HQ Cameraは従来の15ピンCSIケーブル前提の情報が多い一方、Raspberry Pi 5側は22ピンコネクタなので、接続には15ピン→22ピンのケーブルが必要になります。
ここを見落とすと、部材がそろったのにその日に組めない、という初歩的な詰まり方をします。

用途別にざっくり振ると、新規購入ならRaspberry Pi 5、手持ち活用や情報量重視ならRaspberry Pi 4 Model Bです。
在庫と価格は変動が大きいので、ここはスペック表だけでなく入手性も含めて判断するのが現実的です。

カメラモジュールの違い

カメラはCamera Module V2Camera Module V3Camera Module V3 WideHQ Cameraの4つを押さえると整理できます。
監視用途では「何メガピクセルか」だけでなく、画角、フォーカス方式、取り付け後の調整量で選ぶほうが失敗が減ります。

Camera Module V2は8MPのSony IMX219を使う旧世代の定番です。
固定焦点なので構成が素直で、低コストで始めたいときに候補になります。
ピントを自動で追い込まないぶん、設置距離がある程度決まっている室内の定点観測とは相性が悪くありません。
ケースや作例も多いので、部材を探す段階では助かることがあります。

Camera Module V3は現行の主力で、オートフォーカス搭載が大きな違いです。
標準版は約75°、V3 Wideは約120°の視野角があります。
玄関や室内見守りのように、「置く位置は決まるが、被写体までの距離が毎回少し変わる」用途だと、V3系の扱いやすさが光ります。
固定焦点のカメラだと、置き配の荷物は合っているのに人物が甘い、逆に人には合うが足元が眠い、ということが起きますが、AFが入るとこのズレを吸収しやすくなります。

V3 Wideは、玄関まわりや部屋全体を1台で収めたい場面で強いです。
筆者も玄関用なら120°のV3 Wideを選ぶことが多いです。
ただ、広く写るぶん1人あたりの写り込みは小さくなります。
人物識別まで考えるなら、標準画角のV3のほうが実像が大きく入りやすく、表情や持ち物の確認では有利に働きます。
広角は万能ではなく、範囲を取る代わりに1対象あたりの情報量を削るという見方をしておくと選びやすくなります。

HQ Cameraは12.3MPのSony IMX477Rを搭載し、レンズ交換に対応するのが最大の特徴です。
画質重視、撮影条件に合わせて画角や明るさを詰めたい、という用途では魅力があります。
反面、監視カメラの1台目としては少し方向性が違います。
レンズ選定、ピント調整、取り付け方法まで自分で決める要素が増えるため、完成までの自由度が高い代わりに、迷うポイントも増えるからです。
画質にこだわりたい人には刺さりますが、「まず玄関の様子を安定して見たい」ならV3系から入るほうが構成全体がまとまりやすくなります。

ストレージ・電源・ケース・ネットワーク

ストレージはRaspberry Pi OSを入れる前提なら32GBのmicroSDがひとつの基準で、Raspberry Pi OS Liteに寄せるなら16GBからでも構成できます。
Raspberry Pi 公式 Getting startedでも、通常構成は32GB以上、Lite系は16GB以上が目安です。
監視カメラではOSだけでなくログや一時ファイルも増えるので、GUIありのOSを入れるなら32GBを基準に見たほうが詰まりません。

カードの種類は容量だけでなく耐久性も効きます。
監視用途は書き込み回数が多くなりやすいので、SanDisk High Endurance microSDのような高耐久品が向いています。
動体検知中心なら通常カードでも短期検証はできますが、録画が日常運用に入ると高耐久カードとの差がじわじわ出ます。
特に通知用の静止画保存や短い動画クリップが積み重なる構成では、見た目以上に書き込みが増えます。

電源は公式定格に沿わせるのが基本です。
監視カメラは1回起動して終わりではなく、24時間近く連続で動かす前提なので、ギリギリのUSB電源だと不安定さが残ります。
USB給電なら本体に合った公式推奨クラスの電源を使うほうが、カメラ認識の失敗や録画中の不意な再起動を避けやすくなります。
固定設置で配線をすっきりさせたいならPoE+ HATも候補で、Switch Scienceでは4,455円（税込）で流通しています。
PoE+ HATは5V 4A出力の情報があり、Pi本体にカメラや軽い周辺機器を足した構成でも余裕を取りやすいです。

ケースは「見た目」より、放熱と取り付け方で選ぶと失敗が減ります。
Pi 5は発熱を逃がせるケースのほうが相性がよく、壁面や棚下に固定するならネジ止め穴やマウントパーツの有無も効きます。
監視カメラは一度設置すると、向きの微調整以外はあまり触らないので、フタの開けやすさよりも、ケーブルを引いたまま安定して固定できるかのほうが大事です。
V3系はレンズ周りの出っ張りがV2と異なるため、旧ケース流用ではカメラ部だけ干渉することがあります。

ネットワークは、固定設置なら有線LANを第一候補に置くのが無難です。
理由は3つあって、安定性、スループット、給電の拡張性です。
ライブ映像は帯域そのものより、瞬間的な揺れに弱いんですよね。
筆者もWi-Fiで運用していたときは、ライブ遅延やフレーム落ちが気になっていましたが、有線LANに変えた途端にドロップが収まりました。
それ以来、固定設置の監視カメラは迷わず有線寄りです。

有線LANならNAS保存や複数台集約のときも帯域設計が立てやすく、PoE系アクセサリを使えば電源と通信を1本にまとめる発想も取れます。
逆にWi-Fiは設置の自由度が高い一方、電子レンジや壁の位置、アクセスポイントの混雑で映像品質が揺れやすく、原因切り分けが面倒になりがちです。
仮設や短期検証はWi-Fi、本設は有線という分け方だと構成がぶれません。

比較表：Camera Module V2/V3/V3 Wide/HQ

監視カメラ向けに必要な観点だけを並べると、選び分けは次の表に収まります。

製品	画素	視野角	フォーカス	導入難易度	向く用途
Camera Module V2	8MP	標準	固定焦点	低い	低コスト導入、距離がある程度決まった定点監視
Camera Module V3	約11.9MP	約75°	オートフォーカス	低い	屋内見守り、人物をある程度大きく写したい監視
Camera Module V3 Wide	約11.9MP	約120°	オートフォーカス	低い	玄関、部屋全体、1台で広くカバーしたい設置
HQ Camera	12.3MP	レンズ次第	レンズ依存・調整前提	高い	画質重視、レンズ交換、撮影条件を詰めたい構成

この表の読み方はシンプルで、1台目の監視カメラならV3かV3 Wide、予算を抑えるならV2、撮影そのものを作り込みたいならHQ Cameraです。
監視用途は「写ること」より「必要な範囲を、必要な解像感で、安定して残せること」が効きます。
そこから逆算すると、多くの家庭用途ではV3系に落ち着きます。

構成の選び方｜motionEyeOS系か、Raspberry Pi OS + Pythonか

motionEyeOSの手軽さと互換性の注意

『motionEyeOS』系の魅力は、まず立ち上がりの速さにあります。
専用イメージを書き込んで起動し、ブラウザから設定画面に入れば、ライブ表示、録画、動体検知、保存先、メール系の通知までをひとつのWeb UIでまとめて触れます。
Linuxのパッケージ管理やPython環境の準備を飛ばして、監視カメラとしての形を先に作れるので、「まず映像を見たい」「管理画面がある構成のほうが安心」という人には今でもわかりやすい選択肢です。
導入の入り口だけ見れば、Raspberry Pi OS上で一から組むより短時間で監視画面まで届きます。

一方で、この系統は手軽さと引き換えに、土台の新しさでは不利です。
『motionEyeOS』の最終安定リリースは2020-06-06のv20200606で、執筆時点では活発な更新が止まっています。
公式配布元の『motionEyeOS』や関連コミュニティでも、この保守状況は前提として扱われています。
新しいラズパイや新しいカメラ周りを使うなら、導入前の期待値は少し調整しておいたほうがよく、特にRaspberry Pi 5では公式イメージが対応していません。
Pi 3やPi 4世代で既存資産を活かすならまだ候補に入りますが、現行機を中心に長く運用する設計とは相性が分かれます。

また、『motionEyeOS』はGoogle DriveやDropboxへのアップロード情報が広く紹介されていますが、保持期間の制御まで含めてきれいに完結するわけではありません。
アップロード先のクラウドに「何日たったら自動削除するか」という運用まで含めると、結局は外部スクリプトや別の仕組みが欲しくなります。
ブラウザから設定できる範囲でまとまっているぶん、細かな分岐や例外処理を入れたい場面では、設計の自由度が先に天井へ当たります。

Download MotionEyeOS - Free Raspberry Pi Surveillance System

Download MotionEyeOS free for Raspberry Pi. Turn your Pi into a surveillance system with motion detection, multi-camera

motioneyeos.org

Raspberry Pi OS + Pythonの拡張性と通知連携

Raspberry Pi OSに『libcamera』系のツールとPythonを載せる構成は、最初の一歩こそ少し増えますが、その先の伸び代が大きいです。Raspberry Pi公式のカメラソフトウェア解説でも、Bullseye以降は『libcamera』系が標準になっており、Bookwormではrpicam-*系へ整理されています。
ここにPicamera2や自作スクリプトを組み合わせると、撮影、録画、動体検知、前後バッファ、通知、再送、保存先切り替えまでをひと続きのロジックとして組めます。

なお、『Telegram Bot API』は429応答で retry_after を返すため再送制御が必要です。
ファイルサイズの上限やレート制御はクライアントやAPI側の扱いで変動するため、実装では「50MB前後」をあくまで運用上の目安とし、動画送信の実装前に必ず公式ドキュメント動画送信の実装前に必ず公式ドキュメントで最新の仕様を確認してください。
筆者は、通知や誤検知抑制の細かい制御が必要な案件ではRaspberry Pi OS + Pythonを選ぶことが多いです。
理由は単純で、ログの粒度を自分で決められて、通知失敗時の再送制御や抑止ルールもコードとして残せるからです。
動体検知そのものより、「いつ、なぜ、何を送ったか」を追える構成のほうが後で効きます。
誤検知が出たときも、しきい値だけでなく時間帯、連続イベント数、対象エリア、通知先ごとの出し分けまで掘れます。
この自由度は、Web UI中心の構成では届きにくいところです。

OSの素の運用ができる点も見逃せません。
保存先をUSB SSDにしたり、NASへSMBやSFTPで逃がしたり、Google Drive APIやDropbox APIでアップロード処理を書いたりと、周辺の設計をLinuxサーバーとして普通に積み上げられます。
監視カメラというより、小さな専用サーバーを1台立てる感覚に近く、あとから要件が増えても構成を折り直しやすいのがこの路線です。

{{product:3}}

GitHub - raspberrypi/libcamera

Contribute to raspberrypi/libcamera development by creating an account on GitHub.

github.com

複数カメラ/ハブ構成の設計指針

カメラが2台、3台と増えると、設計の軸は「どこで撮って、どこで保存して、どこで通知を判断するか」に移ります。
考え方としては、複数のRaspberry Piに処理を分散する方法と、1台にUSBカメラを集約してハブ機のように扱う方法の2つが基本です。

分散構成は、1台ごとに役割が明確です。
玄関用のPi、室内用のPi、ガレージ用のPiというように分ければ、1台が落ちても全体は止まりませんし、カメラ位置と配線長の制約も減ります。
特にCSIカメラはケーブル長に限界があるので、カメラの近くにPiを置いて、映像だけをネットワーク越しに集約するほうが素直です。
固定設置なら有線LANと組み合わせやすく、PoE系の発想とも噛み合います。

1台集約は、USBカメラ前提なら選べる場面があります。
管理対象が1台にまとまるので、更新、ログ、通知処理の置き場を一本化できます。
ただし、USBバス帯域、電源、熱、障害時の影響範囲が1台に集中します。
複数カメラを同時に録画しながら通知も回すなら、単に「つながるか」ではなく「落ちずに回り続けるか」で見たほうが判断しやすくなります。
家庭用途でも、台数が増えるほど分散のほうが保守は楽になることが多いです。

保存先はローカル完結にせず、外付けストレージやNASへ寄せると設計が整理されます。
前のセクションでも触れた通り、OSはmicroSD、録画は外付けやネットワーク保存という分担にすると、障害の切り分けが明快です。
たとえば各Piはイベント発生時の短期キャッシュだけ持ち、長期保存はNASへ集約する形なら、録画保持日数の調整やバックアップ方針もまとめて扱えます。
監視録画の保持は30日がひとつの目安として語られることが多く、容量見積もりも集約側で考えたほうが破綻しにくいです。
Canonの監視向け解説では、200万画素・30ips・1台・音声ありで1TBあたり約14日という目安が示されており、台数が増えるほど「どこに貯めるか」の比重が上がります。

通知のハブだけを中央へ寄せる設計も相性がよいです。
各Piは撮影と一次判定だけ担当し、中央の1台が『Telegram』送信、クラウド転送、日次削除、ログ集約を受け持つ形です。
この分け方にすると、現場側のPiはシンプルに保てますし、通知ロジックを後から変えるときも中央だけ直せば済みます。
インフラ目線では、映像処理ノードと管理ノードを分ける感覚に近く、監視台数が増えても整然と運用できます。

比較表：motionEyeOS vs Raspberry Pi OS + Python

どちらを選ぶかは、まず動かしたいのか、あとから作り込みたいのかでほぼ決まります。
導入直後の見通しは『motionEyeOS』が強く、通知や外部連携まで含めた運用設計はRaspberry Pi OS + Pythonが優勢です。

項目	『motionEyeOS』系	Raspberry Pi OS + Python
導入速度	速い。専用イメージとWeb UI中心で監視画面まで届きやすい	中程度。OS準備、カメラ設定、スクリプト構成が必要
UI	ブラウザ管理が中心。複数設定を画面から触れる	CLIと自作UI中心。必要ならWeb化も可能
通知	メール系を含め基本機能をまとめて設定しやすい	『Telegram』などの通知先を自由に組める
クラウド連携	Google Drive、Dropbox連携の情報が多い	APIやスクリプトで任意の連携を作れる
拡張性	中程度。監視機能としてはまとまっている	高い。条件分岐、再送、ログ、独自判定まで広げられる
向く場面	まず1台で監視画面を立てたい、ブラウザで管理したい	通知制御、誤検知抑制、外部連携を細かく作りたい
注意点	開発停止状態で、執筆時点の互換性確認が前提。Pi 5の公式対応なし	実装量が増える。Linux運用とコード管理の前提がいる

この比較で迷うなら、1台目は『motionEyeOS』系で全体像をつかみ、通知や保存の要件が増えた段階でRaspberry Pi OS + Pythonへ寄せるという考え方もあります。
ただ、最初から『Telegram』通知、誤検知抑制、複数台集約まで見えているなら、後者で始めたほうが構成を作り直す回数は減ります。
筆者自身も、単体カメラの試作ではWeb UIの速さに助けられる一方、運用ルールまで詰める段階では結局Raspberry Pi OS + Pythonへ戻ることが多いです。

関連記事スマートホーム自作｜ラズパイとESP32の始め方ラズパイ=司令塔、ESP32=末端ノードの役割で最小構成を組む入門。必要部品、MQTT（Mosquitto）、Node-RED、必要に応じてHome Assistantまで一気通貫で解説。センサー送信とLED制御の初実装、容量要件とセキュリティの基本もカバー。

Step 1: カメラとOSをセットアップする

OSイメージの選択と書き込み

ここは、あとで何をやりたいかを先に決めておくと迷いません。ブラウザから手早く管理したいなら『motionEyeOS』系、通知や保存ルールを自分で組みたいならRaspberry Pi OSという切り分けがいちばん素直です。
前のセクションでも触れた通り、『motionEyeOS』系はWeb UI中心で監視画面まで持っていく速度が速く、1台目の試作では全体像をつかみやすい構成です。
その一方で、公式の最終安定版は2020年のv20200606で止まっており、開発停止状態として扱うのが妥当です。
特にRaspberry Pi 5では公式イメージが使えないため、Pi 5を前提にするならRaspberry Pi OS側で考えたほうが話が早いです。

Raspberry Pi OSを選ぶ場合は、デスクトップを使うかどうかでFullとLiteを分けます。
モニターをつないで設定画面を触りながら進めるならFull、SSH前提で最小構成に寄せるならLiteで十分です。
OS用ストレージはFullで32GB以上、Liteで16GB以上を目安にしてください。
ヘッドレスで始める場合は、イメージ書き込み時にSSHの有効化ファイルを置き、Wi‑Fi SSID/パスワードとホスト名を事前に埋め込むと、初回起動後すぐにLAN経由で接続できます。

カメラ接続とCSIケーブルの装着注意

OSの準備ができたら、次はカメラを物理的に載せます。
ここでつまずく原因の多くは、故障ではなくCSIケーブルの向きと固定不足です。
Camera Module V2Camera Module V3HQ Cameraの多くは15ピンのCSIケーブルを使いますが、Raspberry Pi 5だけは基板側が22ピンなので、V3をつなぐときは15ピンから22ピンへの対応ケーブルが前提になります。
HQ CameraやV3はレンズ周りの出っ張りや基板形状も異なるので、旧ケースにそのまま入るつもりで進めると、物理的に干渉して止まります。

装着前は、電源を抜いた状態で作業します。
冬場や乾燥した部屋では静電気を逃がしてから触るだけで、余計なトラブルを避けられます。
特にカメラ基板は小さく、指が端子に触れやすいので、机の上を片付けてから作業したほうが確実です。

CSIコネクタは、見た目よりも「奥まで入ったか」が勝負です。
筆者はロック爪をしっかり起こしてからケーブルを奥まで差し込み、ロックを戻したあとに軽く引いて抜けないことを確認しています。
この一手間を省くと、起動後にカメラが見えず、OS設定の問題に見えて遠回りします。
実際には、ケーブルが半差しのままということがよくあります。

向きはボードごとに変わるので、金属端子面がどちらを向くかをコネクタ側の接点に合わせて見ます。
向きを暗記するより、端子が接点どうしで向かい合っているかを毎回確認したほうが事故が減ります。V3ではオートフォーカス対応という利点がありますが、物理接続が甘いと当然その前段で止まりますし、HQ Cameraではレンズ装着とピント調整も入るので、まずはケーブル接続の安定を優先したほうが切り分けが早くなります。

複数カメラを考えている場合も、CSIケーブルを長く引き回す発想は早めに捨てたほうがまとまります。
MIPI CSI-2は短距離前提の信号なので、玄関までケーブルを伸ばすより、カメラの近くに各Raspberry Piを置いて、映像やイベントだけをネットワークへ流す構成のほうが素直です。
前のセクションで触れた分散配置やハブ集約の考え方は、この物理制約とも噛み合っています。

初回起動とIPアドレスの確認

初回起動は、ヘッドレスで進めるか、HDMIをつないでローカルで進めるかの二択です。
どちらでも到達点は同じですが、監視カメラ用途では設置場所が天井裏や玄関脇に寄ることも多いので、以後の運用を考えるとヘッドレス構成に慣れておく価値があります。
先にRaspberry Pi ImagerでWi‑Fi、SSH、ホスト名を埋め込んでおけば、起動後はLAN内からそのまま入れます。
ホスト名を cam-genkan や cam-living のように役割ベースで付けておくと、複数台へ増えたときにIPアドレス帳を見比べずに済みます。

ローカル起動で進める場合は、HDMIとUSBキーボードをつないで、最初のウィザードでネットワークを上げます。
この方法は、Wi‑Fiパスワードの打ち間違いや画面表示の有無をその場で確認できるぶん、1台目の学習コストを抑えやすい流れです。
『motionEyeOS』系を使う場合も、結局はブラウザで管理画面へ入るので、まずIPアドレスをつかむところまでは同じです。

IPアドレスの見つけ方は、ルーターのDHCPリース一覧を見るのがいちばん早いです。
家庭用ルーターの管理画面には、接続端末名と払い出しIPが並んでいることが多く、ホスト名を設定してあればすぐ特定できます。
ディスプレイをつないでいるなら、ターミナルから hostname -I で確認しても構いません。
ここでIPが不明確なままだと、あとでSSH、Web UI、ファイル共有のすべてが曖昧になります。

『motionEyeOS』系なら、IPさえ分かればブラウザで管理画面へ入って録画や検知設定を始められます。
この「とりあえず画面が見える」速さは、専用OSならではです。
一方、Raspberry Pi OSで進める場合は、SSHで入り、カメラ認識、時刻、更新、通知用パッケージの導入へと流します。
導入速度では前者、後からの作り込みでは後者という差が、初回起動の時点からもう見えています。

複数台構成では、IP管理の方法も1台運用とは別物になります。
各カメラ用Piを分散配置するなら、DHCP予約でIPを固定しておくと、保存先のNAS、通知ハブ、監視ダッシュボードから参照先がぶれません。
1台のハブ機にUSBカメラを集約する場合は、逆にカメラ側ではなくハブ機だけを固定しておけば済みます。
どちらの方式でも、名前とアドレスの対応が崩れないことが運用の土台になります。

初期設定：ユーザー/パスワード/更新

起動できたら、監視用途の前に普通のLinux初期設定を片づけます。
タイムゾーンとロケールがずれていると、録画ファイル名、ログ時刻、通知タイムスタンプが全部ずれます。
あとで動体検知の履歴を見返すとき、「映像は合っているのに時刻だけ信用できない」という状態がいちばん面倒です。
日本で使うなら、最初に日時まわりを合わせておくほうが切り分けが楽になります。

ユーザー管理では、初期ユーザーのまま放置しないことが基本です。
新しいRaspberry Pi OSは初回作成の流れに乗れますが、既存イメージや配布済みテンプレートを使う場面では、管理用ユーザーを作って初期パスワードをその場で変更しておくのが筋です。
監視カメラは「家の中にある小さなLinux機」なので、映像以前に認証設定の甘さがそのまま弱点になります。
筆者は、SSHで入れることを確認したら先にユーザーまわりを固めてから、カメラ設定へ進みます。
順番を逆にすると、動いた安心感で後回しになりがちです。

OSアップデートもこの段階で済ませます。
Raspberry Pi OSではパッケージ更新を先に入れておくと、『libcamera』系やネットワーク周りの素直な挙動を得やすくなります。
古い記事では raspistill 系コマンドが出てきますが、現行の流れは『libcamera』、新しい系統では rpicam-* へ移っています。
監視カメラの自作では検索で古い手順が混ざりやすいので、OS更新を先に入れて現在の標準スタックに寄せたほうが、手順の読み替えで消耗しません。

ここで、どのソフト構成に乗せるかをもう一段だけ具体化できます。
ブラウザ管理の手軽さを優先するなら、『motionEyeOS』系か、Raspberry Pi OS上に『motionEye』アプリを載せる方向が候補です。
開発停止と互換性の不安を避けながらWeb UIも欲しいなら、後者のほうが現実的です。
『Telegram』通知や画像加工、一定時間ごとの再送、検知後だけクラウドへアップロードといった独自処理を入れたいなら、Pythonでイベント処理を書ける構成が向いています。
通知ハブを中央の1台へ寄せる設計にしておけば、各カメラPiは撮影と一次判定だけ、中央機は『Telegram』送信や保存整理だけ、という分担も取りやすくなります。

この段階まで整うと、1台構成でも複数台構成でも、土台が同じ形にそろいます。
1台だけならそのままカメラテストへ進めますし、複数台ならOS、ホスト名、ユーザー方針、更新手順をテンプレート化できます。
監視カメラの出来はレンズや通知機能だけで決まるわけではなく、こうした初期セットアップがきれいにそろっているかで、その後の保守負荷が大きく変わります。

Step 2: 録画設定を作る｜常時録画と動体検知録画

常時録画 vs 動体検知録画の選び方

録画設定は、まず「全部残すか」「動いた場面だけ残すか」を決めるところから始まります。
常時録画は、前後の流れを切らさず追えるのが強みです。
たとえば玄関前で荷物が置かれ、そのあと誰が近づき、どの方向へ去ったかまで連続で見返せます。
証跡の網羅性を優先するならこちらです。
一方で、保存容量はそのぶん着実に減っていきます。

動体検知録画は、映像の中で変化があった場面だけを保存する方式です。
容量効率がよく、あとから見返すときもイベント単位で追えるので、家庭用途ではこちらが主役になりやすいです。
玄関、室内見守り、駐輪場の一角のように「何かあった瞬間だけ押さえたい」場所なら、まず動体検知から入るほうが運用に乗せやすいです。
Canonの動体検知解説でも、常時録画に比べて記録容量を抑えられる考え方が整理されています。

筆者は、出入りの記録を取りこぼしたくない場所では常時録画、普段の無駄映像を増やしたくない場所では動体検知録画、という分け方にしています。
玄関は「いつ誰が通ったか」が分かれば十分なことが多く、15 fpsのフルHDで動体検知中心でも実用上の不満は出ませんでした。
逆に、夜間の敷地境界や長時間の出入り監視では、検知漏れよりも連続性を優先したくなります。

ここで構成との相性も見ておくと迷いません。
『motionEyeOS』系や『motionEye』をRaspberry Pi OSに載せる構成なら、Web UIから常時録画と動体検知録画を切り替えながら詰めていけます。
最小構成を早く動かす目的には向いています。
Raspberry Pi 5では公式の『motionEyeOS』イメージが対応していないので、専用イメージ前提で考えるより、Raspberry Pi OSを入れてWeb UIやアプリ側で録画設定を組む流れのほうが素直です。
Pi 3やPi 4では既存イメージの選択肢がまだ残りますが、モデルごとに使えるイメージが違う点は最初に押さえておきたいところです。

セットアップ直後に録画設定へ進む前提なら、前段で触れた初回起動とIP確認が済んでいることが前提になります。
ブラウザでWeb UIに入る構成でも、Raspberry Pi OS側で初期設定を済ませてから録画を作る構成でも、最初に「映像が見える」「保存先へ書ける」を切り分けておくと、その後の検知調整で迷走しません。
カメラ認識でつまずく場合は、CSIケーブルの差し込み向きとロック不足が原因のことが多く、特にRaspberry Pi 5では22ピン側への変換ケーブルを含めて装着を見直す価値があります。

{{product:1}}

フレームレート・解像度・画角の目安

監視用途では、フレームレートを高くしすぎなくても実用になります。
15 fpsは、人物の出入りや置き配の確認なら十分追える水準です。
30 fpsに上げると滑らかさは出ますが、保存容量と処理負荷も増えます。
常時録画ならなおさら差が効いてきます。
筆者も玄関向けでは15 fps、1080pで不足を感じていません。
顔認識のような用途ではなく、「誰か来た」「荷物を置いた」「手に持っていた物が分かる」程度を狙うなら、この設定がちょうどよく収まります。

解像度は高ければ安心というものでもありません。
Camera Module V2は8メガピクセル、HQ Cameraは12.3メガピクセルですが、監視録画の実運用では録画解像度と画角の組み合わせのほうが効きます。
被写体が遠いのに広角で部屋全体を入れると、画面の中の人物は小さくなります。
逆に、出入口だけを狙って標準画角で絞ると、同じ1080pでも人物の占有面積が増えて判別しやすくなります。

Camera Module V3標準は約75度、Camera Module V3 Wideは約120度なので、ここが設計の分かれ目です。
玄関前の幅を広く取りたいならV3 Wide、廊下や室内の一方向を見るなら標準のほうが扱いやすいです。
広角は死角を減らせますが、そのぶん1人あたりの写る大きさが小さくなります。
画素数だけ見て決めるより、「人が何ピクセルで写るか」を意識したほうが監視用途では失敗が減ります。

対応イメージ選びにも少し注意が必要です。
『motionEyeOS』系の専用イメージで始める場合は、使うRaspberry Piモデルに合ったビルドがあるかを先に見ます。
Pi 5ならRaspberry Pi OSベースで進めるほうが現実的ですし、Pi 4以前なら専用イメージで早く立ち上げる選択肢も残ります。
OSを焼く段階では、Raspberry Pi Documentationが案内する通り通常のRaspberry Pi OSは32GB以上、Lite系は16GB以上が基準になります。
録画そのものは外部保存へ逃がすにしても、最初のセットアップで詰まらない容量は確保しておきたいところです。

動体検知の調整ポイント

動体検知は、オンにしただけでは実用品になりません。
調整するのは主に、フレーム差分のしきい値、検知エリアのマスク、夜間の誤反応対策、そしてイベントを何秒以上で1件とみなすかの4点です。
ここが決まると、通知のうるささも保存量も一気に落ち着きます。

しきい値は、画面の変化をどこから「動き」と扱うかの線引きです。
低すぎると葉の揺れや照明のちらつきで反応し、高すぎると人が画面端を横切っても拾えません。
最初は少し厳しめにして、実際の通行を見ながら下げていくほうが追い込みやすいです。
筆者の玄関カメラでは、道路側をマスクして、しきい値と最小イベント秒数を詰めるだけで誤検知が目に見えて減りました。
車のヘッドライトや通行人の影まで拾っていた状態から、玄関前に人が入ったときだけ残る挙動に寄せられました。

マスクは、検知してほしくない場所を最初から無視する設定です。
道路、隣家の植栽、風で動くのれん、窓越しの反射が出る位置は、監視対象から外したほうが運用が安定します。
動体検知で悩むとき、感度調整だけで解決しようとしがちですが、まず画面のどこを見ないかを決めるほうが効きます。

夜間はもう少し癖があります。
自動露出や街灯の変化で画面全体の明るさが揺れると、画面全域を動きと判定しがちです。Camera Module V3はオートフォーカスや露出制御が扱いやすい一方で、監視では「見栄え」より「判定が暴れないこと」が勝ちます。
夜間だけ感度を少し下げる、マスクを広めに取る、最小イベント長を長めにして一瞬の変化を捨てる、といった方向が収まりやすいです。

最小イベント長は地味ですが効く設定です。
1フレームや2フレームの変化をそのまま録画イベントにすると、通知もファイルも細切れになります。
何秒以上変化が続いたら1件にするかを決めておくと、あとから探すときに記録が読みやすくなります。
通知連携を入れる構成では、この設定が雑だと『Telegram』やメールが短時間に連発し、見る側が疲れます。
録画設定は保存の話で終わらず、通知の質にも直結します。

保存先と保持日数の設計

録画設定を作る段階で、保存先と保持日数は同時に決めます。
ここを後回しにすると、撮れてはいるのに数日で消える、逆に消えずに満杯になる、という状態になりがちです。
Canonの保存目安では、200万画素、30ips、1台、音声ありで1TBあたり約14日です。
30日保持を考えるなら、単純に画質を上げるより、録画方式を見直して容量効率を作るほうが筋が通ります。
家庭用途では、常時録画を全台にかけるより、常時録画は重要地点だけ、他は動体検知録画に寄せる構成が現実的です。

30日をひとつの目安にすると設計がまとまります。
保険や防犯の文脈でも、1か月前後の保持が扱いやすい線として語られることが多いです。
ここで効くのが、リングバッファと自動削除です。
新しい録画で古い録画を押し出す前提にしておけば、容量の上限が明確になります。
ファイル数ベースではなく、日数または使用量ベースで削除ルールを作るほうが、あとから見返すときに挙動を読み取りやすいです。

保存先は、最小構成ならmicroSDでも始められますが、録画運用では早めに外へ逃がしたくなります。
SanDisk High Endurance microSDのような高耐久品は監視向けに作られていますが、それでも連続書き込みを続けると消耗は避けられません。
常時録画を載せると高耐久microSDでも劣化が早く見えました。
OS用と録画用を分けるか、録画先を外付けSSDかNASに寄せるほうへ判断が傾きます。

Raspberry Pi OSの最小構成では、OSはmicroSD、録画はUSB接続のSSDという分け方が扱いやすいです。
もっと台数が増えるなら、NASへ集約すると各Piのローカル書き込み負荷を減らせます。
クラウド保存も選べますが、Google DriveやDropboxはアップロード先としては便利でも、保持日数の自動削除はクラウド側で勝手に整理されるわけではありません。
アプリ側で削除ルールを組む前提で考えるほうが、運用像を描きやすくなります。

比較表：SD/USB/NAS/クラウドの向き不向き

保存先ごとの性格を、導入の軽さ、録画運用との相性、遠隔保全まで含めて整理すると次の通りです。

保存先	向く場面	強み	弱点	監視カメラ運用での位置づけ
SDカード	1台目の試作、最小構成の立ち上げ	配線が少なく、OSと一緒に始められる	連続書き込みが集中しやすく、録画用途では消耗が先に来る	初期検証用。常時録画の主保存先には置きにくい
USB/SATA外付け	1台運用で録画時間を伸ばしたいとき	SDより書き込み負荷に強く、容量を増やしやすい	電源まわりと接続の安定性を見ておきたい	家庭用の本命。OSはSD、録画はSSDの分離が素直
NAS/ネットワーク保存	複数台の映像をまとめたいとき	保存を集約でき、Pi側のローカル負荷を下げられる	ネットワーク設計と共有設定が要る	2台目以降で効く。保持日数の管理もしやすい
クラウド保存	オフサイト保全、遠隔からの参照	物理故障や盗難と切り離して残せる	容量課金とアップロード設計、自動削除の実装が要る	補助的な退避先。常時録画の主保存庫より、イベント保全向き

この表の通り、最小構成を動かすだけならSDカードで足ります。
ただ、録画設定まで作る段階に入ると、保存先はもうシステムの一部です。
『motionEye』系のWeb UIでも、Raspberry Pi OS上の自作構成でも、録画先をどこに置くかで設定の意味が変わります。
初回起動とIP確認、Web UIまたはOS初期設定まで進んだら、次は「どこへ、何日残すか」を固定し、その前提で常時録画か動体検知録画かを選ぶほうが、あとで設定がぶれません。

Step 3: 通知設定を作る｜メール/Telegramで知らせる

メール通知

最小構成をまず動かすなら、通知は『motionEye』系のメール送信から始めるのが素直です。
Web UIにSMTPサーバー、送信元アドレス、宛先アドレスを入れれば形になります。
本文だけ送るより、検知時の静止画や短い動画断片を添付する設定にしておくと、わざわざ録画一覧を開かなくても状況が読めます。
動体検知録画を有効にしているなら、イベントごとの画像添付と動画クリップ添付を分けて考えると整理しやすく、まずは静止画、その後に必要なら動画断片まで足す流れが安定します。

ここでつまずきやすいのは、通知設定そのものより前段の構成差です。
『motionEyeOS』を使う場合は、対応イメージの選択を最初に間違えないことが前提になります。
『motionEyeOS』の公式イメージは最終安定版が2020年で止まっていて、Raspberry Pi 5向けの公式イメージはありません。
Pi 3Pi 4なら専用イメージで進めやすい一方、Pi 5ではRaspberry Pi OS上に『motionEye』を入れる流れになります。
ここを取り違えると、通知設定以前に起動で止まります。
カメラ側でもPi 4までの15ピンCSIとPi 5の22ピンCSIの違いがあるので、ケーブルの向きとロックを丁寧に合わせたうえで、初回起動後にIPアドレスを確認し、Web UIまたはOS初期設定まで終えてから通知に入ると切り分けが早くなります。

メール通知が飛ばないときは、いきなり「動体検知が壊れている」と考えず、SMTPの疎通とイベント発生を分けて確認すると詰まりません。
まずテスト送信でSMTP認証の成否を見る。
次に、手動で静止画送信やテストイベントを発生させて添付の有無を見る。
そのあとで、実際の動体検知時に通知が出るかを確かめます。
この順番にすると、メールの資格情報ミスなのか、イベント条件が厳しすぎるのか、添付サイズが重いのかが見えます。
通知だけ来て画像が付かないなら添付設定、イベント自体が起きていないならしきい値側、何も届かないならSMTP側という具合に、見る場所がはっきりします。

{{product:3}}

Telegram Botのセットアップと送信

『Telegram』は通知の確認速度が速く、最小構成でも実運用に持ち込みやすい選択肢です。
Raspberry Pi OSで組む場合は、まずBotFatherでBotを作ってトークンを取得し、次に自分や通知先グループのチャットIDを控えます。
そのうえで、検知イベントが起きたら画像はsendPhoto、短い動画クリップはsendVideoで送る、という流れに分けると実装が素直です。
画像だけでも役に立ちますが、玄関や駐車場のように前後の動きが読みたい場所では、静止画1枚より数秒のクリップのほうが判断が速くなります。

筆者は動体検知のたびにその場の1枚だけを送っていた時期より、動体検知の直後に直近5秒の動画を『Telegram』へ送り、本編はNASへ保存する形に変えてから、通知の処理が一気に軽くなりました。
スマホ上で要点だけ確認し、本当に必要なイベントだけ本編を開けばよいので、見逃しと空振りの両方が減ります。
イベント確認の導線を分ける発想は、録画設定と同じくらい効きます。

実装は難しく見えますが、部品は少なめです。
Pythonなら、動体検知イベントを受けて画像ファイルやmp4ファイルをHTTPで『Telegram Bot API』に送るだけです。
1枚の画像ならファイルI/Oも軽く、まずはそこから始めると動作確認が早く進みます。
動画クリップは、検知時点から録り始めるより、常時の低負荷バッファまたは短いプリレコードを持って「少し前からの映像」を切り出す発想のほうが監視用途に向いています。
前セクションで触れたイベント長や間隔の設定ともつながっていて、通知用のクリップを短く保つほどスマホで扱いやすく、保存本編は別系統に逃がすほうが全体の負荷配分も安定します。

ハード側の初期セットアップも、ここで一度だけ頭をそろえておくと後の混乱を防げます。
カメラモジュールはCamera Module V3ならオートフォーカスが使え、Standardは約75度、Wideは約120度なので、通知で確認したい対象が玄関前なのか部屋全体なのかで見え方が変わります。
Camera Module V2は8メガピクセル、HQ Cameraは1230万画素でレンズ選定も絡むため、通知に使う切り出し映像の雰囲気も別物になります。
OSイメージも同様で、Pi 5ならRaspberry Pi OS前提、Pi 4までなら『motionEyeOS』系も候補に残る、という整理のほうが実際の作業に直結します。
CSIケーブルは端子面の向きを合わせて奥まで差し込み、ロックを戻す基本動作だけで認識トラブルの多くを避けられます。
起動後にIPを確認し、Web UIまたはOS初期設定を終えてからBot送信を試すと、ネットワークとカメラのどちらで止まっているかを切り分けやすくなります。

Telegram Bot API

The Bot API is an HTTP-based interface created for developers keen on building bots for Telegram. To learn how to create

core.telegram.org

誤検知低減の実践テクニック

通知が動き始めたら、次は誤検知を削って「見る価値のある通知」だけ残します。
監視カメラは撮れることより、通知を見たくなる状態を保てるかが運用の分かれ目です。
屋外では夜間に虫やヘッドライトで反応が増えるので、筆者はエリアマスクとスケジュールを必ず組み合わせます。
道路側や街灯の反射が入る場所をマスクし、通知は夜間だけ有効にすると、無意味な着信が目に見えて減ります。
昼間は人の往来が多く、夜は光源の変化が激しいので、片方だけでは取り切れません。

スケジュールは単なるON/OFFではなく、監視の目的を通知に反映するための設定です。
玄関なら在宅中の昼間は通知を切り、夜間だけ反応させる。
倉庫なら営業時間外だけ有効にする。
この形にすると、同じ検知精度でも通知の密度が落ち着きます。
『motionEye』系のWeb UIでも時間帯制御を持たせやすく、自作構成でもcronやサービス側の設定で十分組めます。

エリアマスクは、画角の決め方ともつながります。
Camera Module V3 Wideの約120度は玄関前を広く拾えますが、画面端に道路や植栽が入りやすく、そのままだと誤検知の種を抱えます。
広角で撮ってマスクするのか、標準の約75度で必要範囲だけ切り取るのかで、後の調整量が変わります。
HQ Cameraのようにレンズ側で詰める構成は狙った場所だけを見せやすい一方、取り付け時の調整が増えます。
通知品質まで含めると、画角選定は録画映えではなく、不要物をどれだけ画面から外せるかで決めるほうが筋が通ります。

動体検知のしきい値では、最小移動ピクセルの設定が効きます。
小さなノイズや枝葉の揺れを拾いすぎる状態なら、感度全体を落とすより、どの程度の面積変化を「動き」と見なすかを上げたほうが、人物は残して細かい揺れを落とせます。
そこにイベント間隔を足して、1件の通知が終わってから次の通知を送るまで少し間を空けると、同じ人物の通過で着信が連発する事態を防げます。
短すぎる間隔は通知疲れを招き、長すぎる間隔は別イベントを飲み込みます。
ここは録画一覧の粒度と通知の見え方を一緒に眺めながら詰めると、設定の意味が見えます。

実運用では、15fps前後でも監視用途の確認には十分な場面が多く、通知用クリップはフレームレートを欲張らないほうが全体のバランスが良くなります。
映像を滑らかにするより、誤検知を減らして「通知が来たら見る価値がある」状態を作るほうが、体感では効果が大きいです。
通知はカメラ性能の競争ではなく、検知条件と送信内容の設計で質が決まります。

Step 4: クラウド保存と遠隔確認を設定する

クラウド保存（Google Drive/Dropbox）の注意点

クラウド保存は、まず最小構成を動かす段階では「オフサイトにもう1本逃がす」ための仕組みとして考えると整理しやすくなります。
『motionEyeOS』系でもGoogle DriveやDropboxへのアップロード機能は用意されていますし、Raspberry Pi OS＋自作構成でも同期スクリプトやAPIで同じ発想を組めます。
ただし、ここで先に押さえたい制約があります。
Google Driveへはアップロードできますが、Drive上のファイルを一定期間後に自動削除する機能は、監視カメラ側の設定だけでは完結しません。
保存先をクラウドにした瞬間に安心、ではなく、保持期間の設計まで含めてやっと運用になります。

この制約は、保存方針を決めるときに効いてきます。
たとえば動体検知ごとに画像や短い動画を全部Google Driveへ投げると、最初は便利でも、数週間後には「どこまで残すのか」「古いものをどう減らすのか」で詰まりがちです。
Google Drive APIにはファイル操作の仕組みがありますが、クラウドストレージ製品のライフサイクル機能のように、Drive側だけで単純に自動削除を回す設計ではありません。Dropboxも同様で、削除APIはあっても、一般的な個人運用ではアプリ側で保持期限を決めて消す前提になります。

ここでは保存の粒度を最初から絞るほうがうまくいきます。
筆者は常時録画の本編をNASへ置き、クラウドにはサムネイルと検知イベントだけを送る形にして、容量と通信量の両方を抑えています。
通知で見返すのに必要なのは「何が起きたかを素早く把握できる軽いデータ」であって、24時間分の本編をそのまま外へ出すことではありません。
特に家庭回線ではアップロード帯域が細い時間帯もあるので、クラウドへ送る対象は、静止画1枚か短いイベントクリップまでに留めると全体が落ち着きます。

OSの初期セットアップ全体はRaspberry Pi公式のGetting startedにも流れがまとまっています（ヘッドレスのSSH有効化、Wi‑Fi設定、ホスト名の指定など）。

Raspberry Pi 公式 Getting started

{{product:9}}

ネットワークドライブ（SFTP/SMB/NAS）という選択肢

クラウドだけで保存を完結させようとすると、容量管理とアップロード待ちで運用が重くなります。
そこで現実的なのが、宅内のNASや別サーバーへまず逃がす構成です。
保存先としてはSFTPとSMBが代表的で、Linux寄りの管理に慣れているなら鍵認証を使えるSFTP、家庭内のPCやNASと一緒に扱うならSMBが馴染みやすい構成になります。

監視カメラ用途では、このネットワークドライブが実は主役になりやすいです。
常時録画や長めのイベント動画はローカルネットワーク内で保持し、必要分だけをクラウドへ二次保全する形にすると、保存量と見返しやすさのバランスが取りやすくなります。
筆者もこの形に落ち着いていて、普段の録画はNASに集約し、外へ出すのはサムネイルと検知イベントだけにしています。
こうすると、スマホ通知で状況をつかみ、必要なときだけ宅内の本編を掘る流れが作れます。

SFTPを使う場合はSSHの枠組みで運べるので、転送先をLinuxサーバーやRaspberry Piに寄せたいときに相性がいいです。
ポートはTCP 22で、鍵認証を前提にすると自動転送にも載せやすくなります。
SMBはNASとの親和性が高く、既存の共有フォルダへそのまま保存できるのが利点です。
ただし、監視用途で使うならSMBv1は切り、SMBv2かSMBv3で閉じた宅内だけに置く設計が筋です。
古いファイル共有の感覚で外へ見せると、便利さより危険が先に立ちます。

ここでも最初のセットアップが響きます。
『motionEyeOS』を前提にする場合は、使うPiの世代に合ったイメージ選びが必要です。
既出の通り、Pi 5では『motionEyeOS』の公式イメージが前提にしづらいため、Raspberry Pi OS上に監視ソフトを載せる流れが素直です。
反対にPi 4までなら、Web UIで保存先を設定する構成も取りやすいです。
どちらの方式でも、初回起動でIPが取れていること、カメラが認識されていること、Web UIまたはOS初期設定が終わっていることが保存先設定の前提になります。

安全な遠隔確認：ポート開放NG・VPN推奨

遠隔確認をしたくなると、いちばん簡単に見えるのはルーターでポートを開けてWeb UIやストリームを外から見られるようにする方法です。
ただ、監視カメラでそれをやると、便利さと引き換えに攻撃面を広げます。
『motionEye』のWeb画面でも、自作のストリーム配信でも、公開ポートを持った瞬間に「家庭内の機器」から「インターネット上の公開サービス」に性格が変わります。
監視カメラは映像そのものが機微情報なので、ここは割り切って公開ポートは作らないほうが安全です。

筆者はスマホからの遠隔確認を自宅VPN経由のみに限定し、公開ポートはゼロのまま運用しています。
外出先から見るときは、先にVPNへ入り、そのあと宅内IPでNASや監視画面へ接続する形です。
この構成だと、監視用のWeb UIやSMB共有をインターネットにさらさずに済みます。
宅内側では普段通りのアドレス設計と認証で運用できるので、構成が無理に二重化しません。

VPNを前提にしても、認証は甘くしないほうがいいです。
MFAが使えるなら有効にし、パスワードだけで入る構成なら、推測されにくい長いものへ寄せます。
SFTPを使う場合は鍵認証、SMBは宅内限定、Web UIはVPNの内側だけ、という切り分けにすると役割が明確になります。
遠隔確認の設計は、映像を見る方法だけでなく、「何を外へ出さないか」を決める作業でもあります。

{{product:5}}

容量管理と自動削除の設計

保存先を決めたら、次に詰めるのは容量管理です。
監視カメラは撮れるようになった瞬間からファイルが増え続けるので、保持期間と削除条件を決めていない構成は長続きしません。
家庭用途でも、保存日数の目安は30日程度を起点に考えることが多いですが、これは「何日残せるか」より「何日残すと見返しに意味があるか」で決めたほうが破綻しません。
玄関の置き配確認なら短め、倉庫や出入口ならやや長め、という考え方です。

削除ポリシーは保存先ごとに分けると扱いやすくなります。
NASには本編を世代管理付きで残し、クラウドにはイベントだけを短めに置く、という二段構えだと役割がはっきりします。
Google DriveやDropboxはアップロード先としては便利ですが、前述の通り自動削除をクラウド側に丸投げできないので、フォルダ単位で日付を切るか、ファイル名に日時とカメラ名を入れて、削除対象を機械的に判断できる形にしておくと後が楽です。
たとえば「camera01_2026-03-18_214500_motion.jpg」のように規則を決めておくと、古いイベントだけをスクリプトで消せます。

帯域の見積もりも一緒に見ておきたいところです。
1080pのH.264をそのまま長時間クラウドへ送り続けるより、イベントごとの短いクリップへ寄せたほうが、回線にも保存先にも無理が出ません。
監視用途では15fps前後でも確認には十分な場面が多いので、保存本編と通知用クリップで役割を分けると設計が締まります。
Google Drive APIでは1ユーザーあたり24時間で750GBのアップロード制限があるため、複数台運用や高頻度イベントでは「送れるか」より先に「何を送らないか」を決めるほうが先です。

ローカル側の記録媒体にも目を向けると、OS用ストレージはRaspberry Pi公式ドキュメントの案内で32GB以上、Liteなら16GB以上が目安です。
録画を同じmicroSDへ重ねると書き込みが集中するので、最小構成では動かせても、保存本編まで背負わせると寿命と容量の両面で窮屈になります。
常時録画を入れるなら、OSはmicroSD、録画はNASや外付け、クラウドは二次保全、という分離が運用しやすい形です。
セットアップ段階で選んだOSイメージとPiの世代、カメラの種類、CSIケーブルの装着、初回起動後のIP確認、Web UIまたはOS初期設定までが揃っていれば、この保存設計へ素直につなげられます。

トラブルシューティングとセキュリティ注意点

カメラが認識されない/映らない場合

Raspberry Pi でカメラが出ないときは、いきなり設定ファイルを追うより、まず物理接続から見たほうが早いです。
筆者の経験では、未認識トラブルの大半は CSI ケーブルのロック不足か、使っている OS イメージとカメラまわりの世代が噛み合っていない状態でした。
切り分けの順番を「物理、その次にソフト」にすると、遠回りを避けやすくなります。

最初に見る場所は、カメラ側と Raspberry Pi 側の両方のコネクタです。
フラットケーブルは奥までまっすぐ入っていても、黒いロックが半端にしか閉まっていないだけで認識されないことがあります。
端子面の向きが逆でも同じ症状になります。
Raspberry Pi 5では 22 ピン側のコネクタになるため、Camera Module V3やCamera Module V2を従来の 15 ピン前提の感覚でつなぐと、変換ケーブルまわりでつまずきやすくなります。Raspberry Piのカメラアクセサリ資料でも、Pi 5 では 15 ピンから 22 ピンへの取り回しが必要なことが整理されています。

物理が正しそうなら、次はソフトの世代を見ます。
ここで初心者が混乱しやすいのが、『libcamera-*』系とrpicam-*系の名前の違いです。Raspberry Piのカメラソフトウェア資料では、Bullseye 以降は『libcamera』系が標準で、Bookworm ではコマンド名がrpicam-stillrpicam-vidなどへ変わっています。
つまり、古い記事どおりに libcamera-still を打ってうまくいかないのに、実際は rpicam-still の世代だった、という食い違いが起こります。
逆に、古い legacy 系の raspistill 前提で調べると、今の OS では話が噛み合いません。

OS イメージが古いままだと、ここがさらにややこしくなります。
『motionEyeOS』は公式の最終安定版が 2020 年で止まっており、Raspberry Pi 5には対応していません。
古いイメージを流用した結果、起動はしてもカメラまわりだけ不安定という状態に入りやすいです。
Raspberry Pi OSを使っている場合も、書き込み済みイメージを長く寝かせていたものだと、カメラスタックやパッケージの整合が崩れたままになりがちです。

ソフト側の確認は、OS を最新状態に寄せてから行うと筋が通ります。
たとえばRaspberry Pi OSなら、まずパッケージ情報と本体を更新して、そのあとで rpicam-still あるいは libcamera-hello 系で最小テストを通す流れです。Raspberry Pi公式のカメラソフトウェアページに沿った世代で揃えると、古い解説記事の断片をつぎはぎするより迷いません。
コマンド名の違いで悩んだら、OS が Bullseye なのか Bookworm なのかを先に見たほうが早く収束します。

Wi‑Fiが不安定な場合の対策

監視カメラは「映るかどうか」より、「常用したときに落ちないか」のほうが厄介です。
とくに Wi‑Fi でライブ配信や録画転送を回す構成は、設置場所の壁、電子レンジや周辺 AP の干渉、2.4GHz 帯の混雑の影響を受けやすく、短時間の確認では問題が見えないまま運用に入ってしまいがちです。
筆者も Wi‑Fi でライブ映像を流す構成は何度か組みましたが、見た目は同じ 2 本アンテナ環境でも安定度の差が大きく、常用前に長時間流しっぱなしで試す工程を抜くと後で崩れます。

不安定さが出るときは、まず通信量の重い処理を分けて考えると整理しやすくなります。
ライブ視聴、録画ファイルのネットワーク保存、通知用クリップの送信は、それぞれ帯域の食い方が違います。
監視用途では 15fps 前後でも実用になる場面が多いので、ライブ表示だけフレームレートや解像度を一段落として、保存本編は別経路にするだけでも切断が減ることがあります。
反対に、ライブも録画保存も通知も全部 Wi‑Fi に載せると、瞬間的な再送で遅延が連鎖しやすくなります。

固定設置なら、有線 LAN を第一候補にしたほうが構成が締まります。
理由は単純で、監視カメラは「その場に固定して長く動かす」機器だからです。
スマホのように持ち歩く前提ではないので、無線の自由度よりも、経路が変わらないことの恩恵が勝ちます。
録画欠落やライブ停止の原因が電波なのかアプリなのかを切り分けるうえでも、有線化すると変数がひとつ減ります。
PoE 対応のネットワークを組めるなら、電源と通信をまとめられるぶん、配線の意味も明快です。

SDカード破損・古いOSイメージの罠

microSD はセットアップの入口としては便利ですが、監視カメラのように書き込みが続く用途では消耗品として見たほうが現実的です。
OS、ログ、サムネイル、録画の断片が同じカードに集まると、故障したときに「録画だけ消えた」では済まず、OS ごと起動不能になりやすいからです。
Raspberry Pi OSの案内でも OS 用ストレージは 32GB 以上、Lite なら 16GB 以上が目安ですが、これはあくまで起動と運用の土台の話で、録画本編まで背負うと別問題になります。

カード自体は、高耐久モデルを前提にしたほうが安心です。
SanDisk High Endurance microSDのように監視カメラやドライブレコーダー向けをうたうシリーズは、連続書き込み用途に寄せて設計されています。
通常品でも動きますが、監視用途では書き込み回数の差がそのまま寿命の差として出やすいです。
録画保存を SD に残す期間が長いほど、カード選びの影響は無視できません。

運用面では、書き込みを減らす工夫が効きます。
ログを RAM ディスクや外部ストレージ側へ逃がす、一時ファイルを録画保存先と分ける、録画本編は USB/SATA 外付けやNASへ置く、といった分離です。
OS 領域と録画領域を同じ microSD に詰め込まないだけで、破損時の被害範囲が狭くなります。
加えて、突然の電源断はファイルシステム破損の引き金になるので、電源アダプタの余裕を削らない構成や、PoE なら給電経路を安定させる設計が効いてきます。

古い OS イメージを焼き直して使うのも、見落とされやすい罠です。
以前うまくいったカードイメージを再利用すると、カメラスタック、カーネル、パッケージ世代のズレをまとめて持ち込んでしまいます。
『motionEyeOS』系では保守停止の影響がここに直結しやすく、Raspberry Pi OSでも、古い Bookworm 前の手順と今の rpicam-* 世代を混ぜると、動く部分と動かない部分が出ます。
新規構築時に毎回イメージを作り直し、更新後の状態でバックアップを取り直す運用のほうが、復旧時間を短く抑えられます。

定期バックアップも、監視カメラ用途では「設定を守る」意味が大きいです。
録画データは保存先で世代管理するとして、OS 側は通知設定、クラウド連携、カメラ調整値が戻れば復旧が早いです。
カード丸ごとのイメージでも、設定ファイル単位でもよいのですが、少なくともゼロから作り直す前提にしないほうが運用負荷は軽くなります。

{{product:6}}

セキュリティ基本：初期パス/外部公開NG/VLAN

監視カメラは、映像が撮れること自体が機密性の高い機能です。
セットアップ直後に見直したいのは、まず初期パスワードのまま残っていないかです。
Raspberry Pi OSのログイン、Web UI の管理画面、『Telegram』の bot 用トークン保管場所、ファイル共有アカウントが初期値や短い文字列のままだと、構成全体の強度が一段落ちます。
OS 側のユーザーだけ変えて満足しがちですが、監視用途では「映像に触れる入口」を一つずつ閉じる感覚が必要です。

更新の適用も、ここでは機能追加より保守の意味が大きくなります。Raspberry Pi公式のカメラソフトや OS の更新で、ドライバまわりとセキュリティ修正を同時に取り込めるためです。
古いイメージをそのまま使い続けると、前段のトラブルシューティングでも触れた認識不良だけでなく、管理画面や周辺パッケージの古さも抱え込みます。

外部公開を避けるのは基本線です。
前のセクションで触れた通り、Web UI やストリーム URL、SMB 共有、SFTP をインターネットへ直接さらす構成は、家庭用途でも守りにくくなります。
遠隔確認は VPN の内側に閉じ、監視用ホストそのものはローカルネットワーク専用にしたほうが、公開面が整理されます。
SMBを使うならMicrosoft Learnでも古い SMBv1 を避ける方針が示されており、共有は宅内限定、バージョンは新しい系へ寄せるのが自然です。

ネットワーク分割も効きます。
監視カメラ用の Raspberry Pi を、普段使いの PC やスマート家電と同じセグメントにベタ置きするより、監視専用 VLAN や専用 SSID 側へ寄せたほうが、万一のときに横移動を抑えられます。
筆者は自宅でも、カメラや IoT 機器をメイン端末のネットワークから分けています。
こうしておくと、たとえば監視用 Web UI にだけアクセスできる端末、保存先のNASにだけ話せる端末、といった通信制御を切りやすくなります。
セキュリティの話に見えて、運用中の「どの通信が正常か」を見分ける助けにもなります。

おすすめ構成まとめ｜玄関・屋内見守り・倉庫監視の3パターン

玄関

玄関は、人物と荷物の動きが一画面に収まることを優先すると組みやすいです。
そこで基準にしたいのが、広角重視のRaspberry Pi 4 Model BとCamera Module V3 Wideの組み合わせです。
Camera Module V3 Wideは対角約120度なので、玄関ドア前の立ち位置と足元の置き配を同時に見たい場面に向きます。
玄関は距離が取りにくく、標準画角だと「人は見えるが荷物が切れる」ということが起きやすいので、画角の余裕がそのまま使い勝手につながります。

録画は動体検知中心、フレームレートは15fps前後にしておくと、通知の反応と保存容量のバランスが取りやすくなります。
人が出入りする瞬間を把握する用途なら、この設定で不足を感じにくいです。
通知先は『Telegram』が扱いやすく、有線LANで安定させておくと、玄関まわりの Wi-Fi 混雑に引っ張られません。
保存先はNASをおすすめします。
玄関カメラは「見返したいのは本体ではなく録画そのもの」という場面が多く、本体側の microSD に録画を抱え込まないほうが復旧も運用も軽くなります。

{{product:10}}

屋内見守り

室内の見守りでは、広く映すことよりも、日常運用で負荷を増やしすぎないことが効いてきます。
基準にしやすいのはRaspberry Pi 4 Model Bと、標準画角のCamera Module V3です。
標準版は約75度なので、リビングの一角や子ども部屋、ペットの定位置など「見たい範囲が決まっている場所」に置くとまとまりが出ます。
オートフォーカス付きなので、手前に人が来る室内でも扱いやすい構成です。

設定は10〜15fps、録画方式は動体検知中心で十分です。
屋内は玄関より変化が少ない一方、常時録画にすると生活音や日常の細かな動きまで保存量が積み上がります。
筆者も室内カメラは、まず「動きがあったときだけ残る」状態にしてから必要に応じて詰めていくことが多いです。
通知はメールでも『Telegram』でも構いませんが、家族用途なら到達確認のしやすさから『Telegram』のほうがまとまりやすい印象があります。
保存先は USB SSD が扱いやすく、OS と録画先を分けるだけでメンテナンス時の気持ちがだいぶ軽くなります。

{{product:11}}

倉庫監視

倉庫や物置は、玄関や室内よりも画質重視で考えたほうが後悔しにくいです。
暗い場所、距離のある通路、狙いたい出入口がはっきりしている環境では、Raspberry Pi 5とHQ Cameraの組み合わせが合います。
HQ Cameraは Sony IMX477R の1230万画素センサーを使い、交換レンズ前提で画角を詰められるので、「広く何となく見る」より「どこをどう残すか」を決めて設置する構成です。
レンズ選びとピント調整の手間は増えますが、監視対象が決まっている場所ではその手間が記録の差になります。

フレームレートは15〜30fpsの範囲で組み、ネットワークは有線LAN、保存先は外付けSSDかNASで1TB以上を目安にすると運用像が見えやすくなります。
監視カメラの録画保持は30日をひとつの目安に置かれることが多く、倉庫のように「その場で見ないが、あとで確認する」用途ではこの考え方が噛み合います。
1TBで1台あたり約14日という一般的な録画目安もあるので、画質重視の構成ほど保存先から逆算して決めるほうが失敗が少ないです。
ここは低消費電力より記録優先の設計ですが、逆に長時間の待機だけを優先するなら Pi 4 と動体検知中心へ戻したほうが全体の負荷は抑えられます。

次の一歩