ラズパイカメラでできることと、今の標準環境

ラズパイカメラでできること

Raspberry Piのカメラでできることは、静止画の撮影だけではありません。
純正のCSI接続カメラを使えば、写真撮影、動画録画、ライブ配信、定点観測、Pythonからの制御、さらにAI Cameraを使った物体検出まで、1枚のカメラから段階的に広げていけます。Raspberry Pi公式 Camera ドキュメントでも、現行のカメラ製品としてCamera Module 3High Quality CameraAI CameraGlobal Shutter Cameraが案内されています。
用途に応じて選ぶ前提がはっきりしています。

標準的な入門機として見やすいのはCamera Module 3です。
Camera Module 3はV2の後継にあたり、センサーはIMX708、画素数は約12MP級で、オートフォーカスとHDRに対応します。
工作机の上を撮る、植物の成長を毎日記録する、玄関先を定点で残す、といった用途ではまずここから入ると全体像をつかみやすくなります。
モジュール自体も汎用寄りで、初心者向けの説明と相性がよいモデルです。

画質やレンズ選定まで踏み込みたいならHQ Cameraが別軸になります。
こちらはIMX477の12.3MPセンサーを搭載し、CSマウント系の交換レンズを使えます。
広角で部屋全体を押さえる、望遠寄りで遠くの被写体を切り取る、暗所寄りの構成を試すといった調整ができるため、単なる「ラズパイ用カメラ」ではなく、小型の撮影システムとして組みたいときに向いています。
モード例としては4056×3040で10.00fps、2028×1080で50.03fps、1332×990で120.05fpsの例があり、解像度とフレームレートのバランスを意識して選ぶ世界に入っていきます。

AI寄りの使い方ではAI Cameraの存在が分かりやすいです。
AI Cameraは12MPのSony IMX500を採用し、カメラ上で低遅延のAI推論を実行する構成が特徴です。
人や物体の検出、通過カウント、簡易なエッジAI用途では、撮った映像をあとでPCに送って解析するのではなく、その場で判断する流れに持ち込めます。
Raspberry Pi公式の案内では価格は70ドルとされていて、通常の撮影カメラとは役割が分かれています。

ライブ配信も守備範囲に入ります。
CLIで撮った映像をFFmpegにつないでRTMPで流す構成は定番で、もう少し配信基盤寄りに寄せるならMediaMTXを組み合わせる流れもあります。
監視カメラ風の定点配信や、工作の手元配信、研究・観察用途の常時配信などはこの延長線上です。
筆者の経験では、ここまでの用途は「カメラが映るかどうか」よりも、「どの世代のコマンド体系で進めているか」が成否を分けます。
古い日本語記事のコマンドをそのまま打って動かない場面が本当に多く、最初に現行系と旧系を切り分けるだけで、詰まりどころが一気に減りました。

現行スタック

今の標準環境は、ざっくり言うとlibcameraを土台にして、rpicam-appsでCLI操作し、PythonはPicamera2で触る構成です。
対象OSの目安はRaspberry Pi OSのBullseye以降、とくにBookworm世代までを含む現行系です。
ここがポイントで、同じ「ラズパイカメラの記事」でも、書かれた時期によって前提のソフトウェアがまるで違います。

最初に入れるパッケージの目安は、次の4つです。
ここではあくまで現行構成の見取り図として挙げます。
実際のパッケージ名や収録バージョンはリリースごとの差分があるため、導入時点ではRaspberry Pi公式 Camera softwareの記載に合わせて再確認する前提で見てください。

rpicam-apps
python3-picamera2
ffmpeg
mediamtx（配信サーバー構成を組む場合）

rpicam-appsには、プレビュー確認向けのrpicam-hello、静止画向けのrpicam-still、動画向けのrpicam-vidのようなツール群があります。
まずCLIで「映る」「撮れる」を確認し、その後にPythonへ進む流れにすると、トラブルの切り分けが明快になります。
Pythonで最初から入ると、カメラ認識の問題なのか、ライブラリの呼び出し方の問題なのか、切り分ける材料が減るためです。

Python側の現行ライブラリはPicamera2です。
ここで混同されやすいのが、Picamera2とlibcameraは同じものではないという点です。
libcameraは下の層でカメラ制御を担い、Picamera2はその上に乗るPythonライブラリです。
ワークショップでも「libcameraを入れたからPythonもそのまま同じ感覚で使える」と考えて詰まる人がいますが、実際にはCLIで動作確認する層と、Pythonコードを書く層は分けて考えたほうが整理できます。

OS側の認識まわりも、古い記事と今とで前提が違います。
以前はGUIやraspi-configで「カメラを有効化する」手順が強く意識されていましたが、Bullseye以降では自動認識前提で進む情報が増えています。
その一方で、古い画面や旧設定項目を前提にした記事も残っているので、「設定項目が見当たらないのに記事通り進めようとして迷子になる」という場面が起きます。
この世代差を最初に頭に入れておくと、接続不良と設定差分を混同せずに済みます。

旧スタックとの違いと注意点

旧スタックとして知っておきたいのがraspistillraspivid、そして旧picameraです。
これらはレガシー側の流れに属していて、現行の推奨はrpicam-appsとPicamera2に移っています。
古い日本語記事ではraspistillやlibcamera-jpeglibcamera-vidの時代の説明が多く残っているため、検索結果の上から順に試すと、同じ「ラズパイカメラ」でも文法の違う記事が混ざります。
筆者はこの混在が初心者のつまずきの大半だと感じています。

違いは単なるコマンド名の差ではありません。
使っているソフトウェア層が違うので、記事の通りに入力しても、現行OSではそのまま再現できないことがあります。
さらに、旧カメラスタック前提のツールは、現行ハードと組み合わせたときに素直に動かないことがあります。
たとえばMotionEyeのような旧構成寄りのツールは、Camera Module 3やRaspberry Pi 5との組み合わせで相性の壁にぶつかる例が知られています。
監視用途の情報を探しているとこの系統の記事に当たりやすいので、撮影用CLIと監視アプリを同じ土俵で見ないほうが混乱しません。

性能面の考え方にも違いがあります。
Picamera2はPythonから柔軟に扱える一方で、1080pの高フレームレート録画ではlibcamera-vidや現行のrpicam-vidのような低レイヤー寄りのツールのほうが有利とされる議論があります。
たとえばHQ CameraのIMX477では2028×1080で50.03fpsのモード例があり、高fpsの連続録画では、Pythonで細かく制御する便利さより、CLI側で録画パイプラインを素直に通したほうがまとまりやすい場面があります。
筆者の感覚でも、録画そのものを安定して回したいときはCLI、撮影条件をコードでいじりたいときはPython、と役割を分けると迷いが減ります。

ストレージ感覚も、動画用途では早めに持っておくと役立ちます。
たとえば1080p前後を長時間録ると、圧縮前の映像データは現実的でない量になります。
IMX477の2028×1080・50fps級を未圧縮に近い感覚で考えると、1分で約9.86GB規模に膨らみます。
実際にはH.264やH.265で圧縮するのでここまでのサイズにはなりませんが、逆に言えば、動画運用ではコーデックと出力形式まで含めて設計する必要があります。
静止画が撮れた延長でそのまま長時間録画へ進むと、保存先の空き容量と扱うファイル形式で足元をすくわれます。

現行環境に寄せるときの見分け方は単純です。
CLIがrpicam-hellorpicam-stillrpicam-vid、PythonがPicamera2なら現行系、CLIがraspistillraspivid、Pythonが旧picameraなら旧系です。
この切り分けだけで、検索中に拾った情報の賞味期限が見えてきます。
読んでいる記事がどちらの世界の話なのかを先に判定すると、接続トラブルなのか、OS世代差なのか、そもそも前提が古いのかを落ち着いて追えるようになります。

対応カメラの選び方｜Camera Module 3・HQ Camera・AI Camera

カメラ選びで迷ったら、まず結論を先に置くと整理できます。標準の1台を選ぶならCamera Module 3、作品撮りやレンズ遊びまで含めるならHQ Camera、物体検出や分類をRaspberry Pi側のCPU負荷を抑えて回したいならAI Cameraです。
Camera Module 2やNoIR、広角版、USBカメラはその補助線として考えると判断しやすくなります。

実際、机の上で工作記録を撮る用途では、AF（オートフォーカス）付きのCamera Module 3がひとつ抜けています。
基板を手前に寄せたり、工具を置いたりすると固定焦点のカメラはピントを外しがちですが、V3はその失敗が少なく、はじめて撮る人でも「ちゃんと見える絵」が出やすいんですよね。
逆にHQ Cameraは、レンズ選びやピント固定にひと手間かかる代わりに、暗い場所の粘りや背景のボケ表現で明確に個性が出ます。
撮る対象に合わせて機材を育てる感覚に近いカメラです。

3機種の比較表

まずは現行の主力3機種を、選定に必要な項目だけに絞って並べます。
Raspberry Pi公式 Camera ドキュメント（https://www.raspberrypi.com/documentation/accessories/camera.htmlでも、現行ラインとしてCamera Module 3High Quality CameraAI Cameraなどが案内されています）。

製品名	センサー	画素数	AF/HDR	レンズ交換	代表解像度 / フレームレート例	価格目安	向く用途
Camera Module 3	Sony IMX708	約12MP	AF対応 / HDR対応	不可	4608×2592、2304×1296、1536×864、各30fpsの例	スイッチサイエンスで税込5,967円の例	汎用撮影、工作記録、定点監視、配信のベース
HQ Camera	Sony IMX477	12.3MP	AF非搭載 / HDRの訴求は薄い	可能（CSマウント系）	4056×3040で10.00fps、2028×1520で40.01fps、2028×1080で50.03fps、1332×990で120.05fps	国内参考価格11,580〜14,880円、別途レンズ代	作品撮り、低照度撮影、画作り重視、光学実験
AI Camera	Sony IMX500	12MP	用途はAI推論中心	不可	非公表	公式案内で70ドル	画像認識、物体検出、エッジAI処理

この表で見ると、Camera Module 3はスペックの派手さよりも失敗の少なさが魅力です。
Pi 5での代表モード例として4608×2592や2304×1296があり、記録用にも配信用にも扱いやすい帯域に収まっています。
机上の撮影では、ネジ袋やジャンパワイヤにフォーカスを持っていかれにくく、ブログ用の写真や進捗記録で歩留まりが上がります。

一方のHQ Cameraは、同じ12MP級でも性格がまったく違います。
4056×3040の高解像度だけでなく、2028×1080で50.03fps、1332×990で120.05fpsといったモードがあるので、レンズ選定まで含めて狙いを作り込めます。
暗所や被写界深度（ピントが合って見える範囲）のコントロールはV3では出しにくく、ここはHQの領分です。
組み込みカメラというより“小さな撮影システム”として考えたほうがしっくりきます。

AI Cameraは写真作品向けの代替ではありません。
Raspberry Pi公式 AI Camera（https://www.raspberrypi.com/documentation/accessories/ai-camera.htmlでも、Sony IMX500を使ったオンセンサーAI推論が中心に説明されています。
つまり、カメラが映像を取るだけでなく、認識処理の一部をカメラ側で担う設計です。
人物検出や物体カウントのように、「映像を撮ること」より「映像から何を判断するか」が主役の用途で選ぶ製品だと言えます）。

用途別おすすめ

用途で分けると、選び方は明快です。迷ったらCamera Module 3から入る、これがいちばん外しにくい考え方です。
AFとHDRがあるので、工作机の記録、3Dプリンタの監視、簡単なストリーミング、学習用途まで広く受け持てます。
Raspberry Piのカメラを初めて触る人ほど、ピント調整を別途考えなくてよい恩恵が大きく出ます。

監視や定点観測でも、V3は相性が良い部類です。
被写体までの距離が毎回ぴったり固定されない場面でも対応しやすく、照明条件が変わる部屋でもHDRが効いて破綻しにくい構成を組めます。
配信でもまずはV3で十分で、画角や照明の詰めを後から考えられます。
標準モデルとしての完成度が高い、という表現がいちばん近いです。

作品撮り、商品撮影、マクロ寄りの表現、暗所撮影まで狙うならHQ Cameraが向きます。
ここは画素数の差ではなく、交換レンズを使えること自体が本質です。
広く見せたいのか、寄って撮りたいのか、背景を落として主役を浮かせたいのかでレンズを変えられるので、撮影意図を機材側に反映できます。
実際に使うと、レンズを付けてピントを追い込み、固定してから構図を決めるまでに少し時間を使いますが、そのぶん暗い場所での表情やボケの出方は一段上の絵になります。

画像認識が目的ならAI Cameraを選ぶほうが筋が通ります。
たとえば、ライン上の通過物を検出したい、人物の有無だけを見たい、分類結果をGPIOやネットワーク連携に回したい、といった用途です。
通常のカメラでもRaspberry Pi上で推論はできますが、AI Cameraはそこを前提に設計されています。
映像作品用の“高画質カメラ”として考えるとズレますが、エッジAI用センサーとして見ると立ち位置がはっきりします。

判断フローとしては、「まず撮る」ならV3、「どう撮るかまで詰める」ならHQ、「撮った映像をその場で判断する」ならAI Cameraです。
この3本に当てはまらないケースは、旧モデル流用か特殊用途の派生モデルを見ていくと整理できます。

V2・NoIR・広角・USBカメラの考え方

Camera Module 2は旧モデルですが、安価に流用できるならまだ候補に入ります。
センサーはIMX219で8MP、モード例としては3280×2464で21.19fps、1920×1080で47.57fps、1640×1232で41.85fpsがあります。
固定焦点で世代差はありますが、すでに手元にある、あるいは中古・在庫品でコストを抑えたいなら十分使い道があります。
新規購入の第一候補はV3ですが、V2を「古いから即除外」とまでは言いません。

NoIRはIRカットフィルタなしの派生モデルです。
昼間の自然な色再現より、赤外照明と組み合わせた夜間撮影や植物観察のような用途で意味が出ます。
普通の室内記録や配信では標準版のほうが扱いやすく、NoIRは「暗所・赤外前提」の選択肢として切り分けると混乱しません。
用途がハマると強いですが、万能版ではありません。

広角版も考え方は似ています。
広い机全体、部屋全体、天井近くからの俯瞰を一枚に収めたいときには有効ですが、そのぶん周辺の歪みや被写体の小ささと引き換えになります。
工作手元の記録なら、広すぎる画角は情報量が増える一方で“見せたい場所が小さくなる”こともあります。
配信や監視で画面全体を押さえたいのか、部品の向きまで見たいのかで向き不向きが分かれます。

USBカメラは手軽ですが、純正CSIカメラと同じ感覚で考えないほうが整理できます。
接続の手軽さはUSB側の利点ですが、Raspberry Pi純正のカメラスタックに乗るCSIカメラとは、制御やチューニングの前提が異なります。
オートフォーカスや露出制御、認識、複数台構成を進めると、その差が見えてきます。
すでにUVC対応のUSBウェブカメラを持っていて会議や簡易配信に使うなら成立しますが、Raspberry Piのカメラ機能をしっかり活かしたいなら、まずはCSI接続の純正系を基準にしたほうが選定の軸がぶれません。

接続方法と初期確認｜Pi 4以前とPi 5で何が違うか

接続前の準備とケーブルの向き

物理接続でつまずく原因は、相性よりも差し込み方のミスであることが多いです。
ここがポイントです。
作業は必ずRaspberry Piの電源を落としてから行います。
通電したままリボンケーブルを抜き差しすると、認識不良だけでなくコネクタ側を傷める原因になります。

カメラモジュールを取り付ける前に、レンズ前面や基板側に保護フィルムが残っていないかも見ておきます。
初心者の方で意外と多いのが、映像が白っぽい、妙にぼやけると思ったら保護フィルムを剥がしていなかった、というケースです。
とくにCamera Module 3のようにそのまま映る前提で作業を始めるモデルでは、ソフトの設定を疑う前に物理面を見直したほうが早く切り分けられます。

リボンケーブルは、青い補強タブの向きと、金属接点の向きをセットで確認します。
ここを曖昧にすると、見た目には刺さっていても信号が通りません。
コネクタは多くの場合、黒や茶色のラッチをいったん起こしてからケーブルを奥までまっすぐ差し込み、左右が均等に入った状態でラッチを戻して固定します。
筆者がワークショップで見てきた限り、初心者に多い事故はラッチを開けずにそのまま押し込んでしまい、接点やケーブル端を傷めるパターンです。
写真付きで開閉手順を一コマずつ示すと失敗が目に見えて減るので、この部分は「刺さった気がする」ではなく、ラッチが戻ってケーブルが平行に固定された状態まで確認したいところです。

固定にも少しコツがあります。
カメラ基板だけがぶら下がった状態だと、ケーブルの重みで微妙に抜けかかることがあります。
ケースのカメラマウントや三脚座付きの治具があるなら使ったほうが安定しますし、仮設置でも両面テープやスペーサーで基板の向きを落ち着かせるだけでトラブルが減ります。
リボンケーブルは鋭く折り曲げず、ゆるいカーブで取り回します。
長めのケーブルを使うときは、ケースのふたで押しつぶさないことと、ファンやヒートシンクに擦れない経路を先に決めておくと、あとで「映ったり消えたりする」症状を避けやすくなります。

Pi 4以前：15ピンCSIの接続

Raspberry Pi 4以前の標準モデルでは、カメラ接続に15ピンのCSIコネクタを使います。
Raspberry Pi公式 Camera ドキュメントRaspberry Pi公式 Camera ドキュメントでも、この世代差は接続時の注意点として整理されています。
従来のCamera Module 2やCamera Module 3を「普通のラズパイにそのままつなぐ」イメージで紹介している記事の多くは、この15ピン前提で書かれています。
（出典: https://www.raspberrypi.com/documentation/accessories/camera.html）

接続手順そのものは単純で、基板上のCSIコネクタのラッチを開け、ケーブルをまっすぐ差し込み、ラッチを閉じます。
ただ、初心者の方はLANポートやHDMI周辺に気を取られて、ディスプレイ用のDSIとカメラ用のCSIを混同しがちです。
Raspberry Pi 4ではコネクタの位置関係も比較的わかりやすいものの、ケースに入った状態だと見分けづらくなるので、基板シルク印刷を見てから作業したほうが迷いません。

この世代では、純正系カメラと付属の15ピンケーブルでそのままつながる構成が多く、物理的には扱いやすい部類です。
逆に言うと、ここで映らない場合はケーブルの裏表、差し込みの浅さ、ラッチの閉め忘れといった基本ミスを優先的に疑うのが近道です。
ソフト側の話に進む前に、カメラ基板が斜めに引っ張られていないか、ケーブル端がコネクタから均等に見えているかを見るだけで原因が見つかることがよくあります。

Pi 5/Zero：22ピンCSIと変換ケーブル

Raspberry Pi 5とRaspberry Pi Zero系では、22ピンのCSIコネクタが使われます。
ここがPi 4以前とのいちばんわかりやすい違いです。
見た目は似ていてもピン数が違うので、15ピン用ケーブルをそのまま挿すことはできません。

とくにRaspberry Pi 5で従来の15ピンカメラを使う場合、15ピン-22ピンの変換ケーブルが必要になることがあります。
この点を見落とすと、「カメラは対応しているはずなのに物理的につながらない」という、いちばん避けたい足止めになります。
カメラモジュール自体の世代と、ボード側コネクタの世代は別問題として考えると整理しやすく、たとえばCamera Module 3を選んでいても、接続先がRaspberry Pi 5なら22ピン側の準備が必要、という理解になります。

Pi 5では複数カメラ構成の情報も増えてきましたが、まず1台を確実につなぐ段階では、変換ケーブルの向きと差し込み深さが肝になります。
変換ケーブルは両端で青いタブの向きが異なるものもあり、片側だけ正しく刺さっていても反対側が裏返っていると認識しません。
15ピン直結時よりも「どちら側の接点が下か」を目で追う癖をつけたほうが失敗が少なくなります。

Zero系も22ピンなので発想は同じです。
小型ケースに組み込むと、ケーブルが急角度で折れやすくなります。
基板が軽いぶん、カメラの重みで本体ごと引っ張られることもあるので、ケース側でカメラを受けるか、ケーブルに余裕を持たせてテンションを逃がすと安定します。
小型機ほど省スペース配線に寄せたくなりますが、リボンケーブルだけは窮屈に詰め込まないほうが、立ち上げ時の不具合を減らせます。

認識確認コマンドと判定ポイント

物理接続が終わったら、OS上でカメラが見えているかを確認します。
現行の手順では、まず rpicam-apps や libcamera 系のユーティリティでカメラ一覧を確認する流れが一般的です。
ただし、これらのユーティリティが提供するオプション名（たとえば「カメラ一覧を出す」オプションなど）は、パッケージ版やビルドにより異なることがあります。
ツールやオプションを断定的に書くのではなく、まず各コマンドの --help / man を確認してください（例: rpicam-hello --help / libcamera-hello --help）。
そのうえで、センサー名やデバイスが列挙されれば少なくとも接続と基本認識は通っています。
何も出ない場合は、ソフトの細かな設定より先にケーブルの向きやラッチ、変換ケーブルの組み合わせを見直したほうが切り分けが早いです。
判定の目安は明快です。
センサー名が出る、dmesg にカメラ初期化のログが見える、この2つがそろえば次の撮影テストへ進めます。
どちらも空なら、ソフト導入より前に物理接続へ戻るべき場面です。
経験上、ここで時間を使う案件の多くはドライバではなく、ケーブルが1ミリほど浅い、ラッチが片側だけ閉まり切っていない、変換ケーブルの向きが逆、といった機械的な原因に集約されます。

静止画を撮る｜rpicam-still / libcamera系コマンドの基本

最小コマンドと環境別の注意

静止画を最短で1枚保存するなら、まずは次のように試します（例示）。
ただしオプション名や動作は rpicam-apps のバージョンや OS により差があります。
実行前に rpicam-still --help を確認してください。

rpicam-still -o image.jpg

# 最小例（環境によりオプション名が異なるため実行前に --help を確認してください）
rpicam-still -o image.jpg

# ヘッドレスでプレビューを無効化するオプションは環境依存です。実行前に `rpicam-still --help` を確認してください。
rpicam-still -n -o image.jpg

rpicam-still -o /home/pi/Pictures/image.jpg

相対パスも使えるので、作業用ディレクトリを切っているなら -o photos/test01.jpg のような形でも十分です。
よくある間違いは、存在しないディレクトリを指定して保存できていないのに、撮影そのものが失敗したと考えてしまうことです。
まずは image.jpg のような短い名前で同じ場所に保存し、そこから整理していくと迷いません。

保存先は -o にファイル名だけを書けばカレントディレクトリへ、絶対パスを書けば任意の場所へ保存されます。
解像度を変えたいときは --width と --height を指定しますが、センサー側の読み出しモードに依存するため、rpicam-still --help や --list-cameras の結果を参照して実際に使えるモードを確認してください。

rpicam-still -n --width 1920 --height 1080 -o image_1920x1080.jpg

この指定は「出力サイズをどうするか」の入口として覚えると十分です。
ただし、センサーには得意な読み出しモードがあります。
たとえばHQ CameraのIMX477では 4056×3040、2028×1520、2028×1080、1332×990 といった代表モードがあり、Camera Module 3のIMX708でも 4608×2592、2304×1296、1536×864 の例が知られています。
幅と高さを自由に書けても、実際にはセンサー側のモードや内部処理に寄せて動くので、最初から細かく追い込むより、端末で --list-cameras の結果を見ながら近いモードを意識して決めるほうが筋が通ります。
この指定は「出力サイズをどうするか」の入口として覚えると十分です。
ただし、幅・高さの指定はセンサー側の読み出しモード（利用可能な解像度・クロップ／スケーリング等）に依存します。
実際に使えるモードは環境や rpicam-apps の版によって変わるため、rpicam-still --help や（存在する場合は）--list-cameras の出力で利用可能なモードを確認してから指定してください。

AF/HDR/露出まわりの触り

最初の1枚が撮れたら、次に触る価値が高いのはオートフォーカス、HDR、露出、ホワイトバランスです。
Camera Module 3のようにAF対応のカメラでは、ピントが背景へ抜けて「壊れているのでは」と感じることがありますが、実際にはフォーカス設定の問題であることが多くあります。
一方でHQ Cameraはレンズ側で合わせる前提なので、同じ感覚でAFを期待すると話が噛み合いません。

このあたりは便利なスイッチが用意されていますが、オプション名は使っている世代で差が出ます。
旧 libcamera-still の記事に載っている指定が、そのまま rpicam-still で通らないこともあります。
そこで実運用では、触る項目だけ先に決めて、実際の名前は rpicam-still --help と公式ドキュメントで確認する進め方が堅実です。
ここでは「AFを動かす」「HDRを有効にする」「露出やAWBを固定する」といった発想を持っておけば十分です。

露出まわりでは、明るい窓際と室内が同居する場面で、見た目より白飛びや黒つぶれが出ます。
HDR対応カメラなら、その差を詰める手段として候補に入ります。
ホワイトバランスも、机の上では自然でも、蛍光灯や電球色に寄ると紙が青やオレンジへ振れます。
作品撮りで色を揃えたいときはAWB任せから一歩進めて固定系の設定を試す価値があります。

AFや露出に触れ始めると、1回で正解を当てるというより、まず標準状態の絵を残し、その次に1項目だけ変えて差を見るほうが理解が進みます。
静止画は撮り直しの負担が小さいので、image_auto.jpg、image_hdr.jpg、image_manual.jpg のように別名で並べるだけでも、設定の効き方が見えます。
コマンド撮影はとっつきにくく見えますが、結果がファイル名で残るぶん、むしろ比較には向いています。

動画を録る｜rpicam-vidで録画する

最小録画コマンド

動画の最初の1本は、録画時間を決めてファイルへ保存する形から入るのがいちばん確実です。
以下は一般的な例ですが、rpicam-vid のオプション名や詳細は rpicam-apps のバージョンで変わることがあります。
実行前に rpicam-vid --help で利用可能なフラグを確認してください。

rpicam-vid -o video.h264 -t 10000

-o は保存ファイル名、-t は録画時間（ミリ秒）です。
解像度・フレームレート指定も例示として示していますが、オプション名や組み合わせは rpicam-apps のバージョンやビルドで差が出ることがあります。
実行前に rpicam-vid --help で利用可能なフラグと各オプションの説明を確認してください。

rpicam-vid -o video_1080p30.h264 -t 10000 --width 1920 --height 1080 --framerate 30

ビットレートは画質と容量の釣り合いを取る項目です。
たとえば H.264 を中程度の 8 Mbps と見積もると、1 時間で約 3.6 GB です。
これは 1080p30 の記録量をざっくり掴む目安として便利で、長時間録画では保存先の空き容量を考える足がかりになります。
逆に高fps化すると、この感覚のままでは足りなくなりやすく、画が荒れたり動きの多い場面で破綻しやすくなります。

代表的なモードの例を、よく使われるIMX477とIMX219でまとめると次のようになります。

センサー	代表モード	fps	向く用途
IMX219	1920×1080	47.57	一般撮影、少し滑らかな動き
IMX219	1640×1232	41.85	画角を広めに取りたい記録用途
IMX219	3280×2464	21.19	静止画寄り、動画では低fps前提
IMX477	2028×1080	50.03	動きもの、滑らかさ重視の一般動画
IMX477	2028×1520	40.01	解像感とfpsのバランス型
IMX477	1332×990	120.05	スポーツ、動作解析、スロー用途
IMX477	4056×3040	10.00	動画というより高解像度取り込み寄り

この表を見ると、1080p 前後で 30fps から 50fps は現実的な落としどころで、120fps 級は解像度を下げて狙う構図になります。
HQ CameraのIMX477で 1332×990@120.05fps のようなモードがあるのは、高速な動きを追いたい場面では大きな武器です。
反対に、4056×3040@10.00fps は数字としては魅力的でも、普通の動画として見ると滑らかさより解像度優先の世界です。

高fpsや長時間録画では、Picamera2より rpicam-vid のようなCLIのほうが安定するという議論もあります。Raspberry Pi公式 Camera softwareの通り、現行の標準系は rpicam-apps と libcamera を軸にしており、Python から柔軟に扱えるPicamera2とは役割が少し違います。
筆者も、連続録画の検証ではまず CLI で条件を固め、その後に Python 化する流れをよく取ります。
コミュニティでも高fps録画で同様の見方がありますが、これは「常にCLIが上」と言い切る話ではなく、録画専用でシンプルに回したい場面では有利になりやすい、という整理が実態に近いです。

TIP

迷ったら、一般撮影は 1920×1080・30fps、低帯域や長時間記録は 1280×720、高速な動きはIMX477の 1332×990・120fps のように、用途ごとに軸を1本決めると設定がぶれません。

ファイル形式と後処理

rpicam-vid -o video.h264 で保存される .h264 は、H.264 の生ストリームです。
これは「映像の中身」は入っていますが、一般的な動画プレーヤーで扱いやすい MP4 コンテナとは別物です。
撮れたのに再生しづらい、長さ情報がうまく出ない、編集ソフトに持っていきにくい、といった場面はここで起きます。

録画した .h264 を MP4 コンテナへ包む実用例です。
実際の ffmpeg の挙動はバージョンやビルドにより差があるため、まずローカルで ffplay 等で入力を確認し、ffmpeg のドキュメントに従ってフレームレート等を合わせてください。

# 録画時の framerate に合わせて -framerate を設定してからコンテナ化する（再圧縮なし）
ffmpeg -framerate 30 -i video.h264 -c copy video.mp4

MP4Boxを使う流れもあります。
たとえば次のような形です（ツールの入手性は環境により異なります。
GPAC/MP4Box が利用可能かはパッケージマネージャで確認してください）。

# MP4Box を使う例（ツールの入手性やオプション挙動は環境で変わります。事前にパッケージマネージャで GPAC/MP4Box が利用可能か確認してください）
MP4Box -add video.h264 video.mp4

実運用ではまずローカルで ffplay 等を使って入力を確認し、ffmpeg のマニュアル（ffmpeg -h / オンラインドキュメント）に従ってフレームレートなどを合わせてからコンテナ化してください。
FFmpeg のフラグやフィルタの振る舞いはバージョン・ビルド差が出やすいため、各環境での検証を推奨します。
なお、未圧縮に近い感覚で動画サイズを考えると、必要な記録帯域の大きさが見えてきます。
たとえばIMX477の 2028×1080@50.03fps を YUV420 の未圧縮相当で概算すると、1 分で約 9.86 GB 級になります。
実際の rpicam-vid は H.264 で圧縮するのでここまで膨らみませんが、高解像度・高fpsがストレージへ強い負荷をかける、という感覚はこの計算でもつかめます。
だからこそ、高ビットレートで長回しするなら microSD より USB SSD のほうが結果が安定しやすく、給電まで含めた構成が効いてきます。
ファイル形式で迷ったときは、録画中は .h264、共有や編集に回す前に .mp4 へコンテナ化、という二段構えで考えると整理しやすくなります。
ツール選定（FFmpeg / MP4Box 等）の可用性やパッケージ名は OS やリポジトリで異なるため、利用する環境でパッケージマネージャ（apt search / dnf search 等）を使って入手性を確認してください。
Picamera2は、libcamera の上に構築された現行の Python ライブラリです。
ここがポイントです。
古い記事で出てくる旧picameraとは別物で、いまのRaspberry Pi OSでカメラを Python から扱うなら、Picamera2を起点に考えるのが自然です。
Raspberry Pi公式 Camera softwareでも、現行のカメラ制御は libcamera 系と rpicam-apps が中心になっています。

Raspberry Pi公式 Camera software の構成を見ると、CLI ツール群の土台と Python ライブラリの関係がつかみやすくなります。Picamera2 = Python から libcamera を扱う入口 と捉えると整理しやすくなります。

パッケージ名としては python3-picamera2 が多くの環境で見られますが、配布状況は OS バージョンやディストリビューションにより変わります。
まずは当該環境でパッケージが入っているかを確認してください（例: apt search picamera2、apt policy python3-picamera2）。
インポート確認の簡易コマンドは次のとおりです。

python3 -c "from picamera2 import Picamera2; print('Picamera2 OK')"

動作しない場合はパッケージ名や入手方法を公式ドキュメント／ディストリのパッケージリポジトリで確認してください。

筆者は授業や試作で、ここを省略せずに「CLI で映る」「Python で import できる」を別々に確認します。
片方ずつ潰すだけで、詰まる時間が短くなります。
自動化の入口として Python は強力ですが、最初の切り分けだけは CLI のほうが速い場面が多い、というのが実感です。
筆者は授業や試作で、ここを省略せずに「CLI で映る」「Python で import できる」を別々に確認します。
パッケージ名はディストリやOSバージョンで異なることがあるため、まず当該環境で apt search picamera2 や apt policy python3-picamera2 などで提供状況を確認してください。
インポート確認の簡易コマンドは次のとおりです。

python3 -c "from picamera2 import Picamera2; print('Picamera2 OK')"

from datetime import datetime import time

使用ボード・ライブラリの注記（例）

- 実行環境によっては picamera2 API が異なることがあります。実行前に公式ドキュメントを確認してください。

picam2 = Picamera2() config = picam2.create_still_configuration() picam2.configure(config)

picam2.start() time.sleep(2) # 露出やAWBが安定するまで少し待つ

filename = datetime.now().strftime("image_%Y%m%d_%H%M%S.jpg") picam2.capture_file(filename)

picam2.close() print(f"saved: {filename}")


このコードで押さえたいのは、**静止画用の構成を明示してから保存している**ことです。`time.sleep(2)` は、起動直後にすぐ切るよりも、露出やホワイトバランスが落ち着いた状態で撮れる場面が多いため入れています。

ファイル名に `strftime` で時刻を入れておくと、定点撮影や実験記録で効いてきます。筆者はこの形をよく使いますが、`image.jpg` のような固定名にすると上書きが起き、あとから比較するときに履歴が消えます。`20250318_101530` のような時刻入りにしておくと、撮影順がそのまま並び、ログの時刻とも突き合わせやすくなります。撮影時に温度や照明条件を別ログへ残しておくと、あとで「なぜこのカットだけ色が違うのか」を追いやすくなります。

### 動画の最小サンプル

動画は静止画より部品が少し増えます。`create_video_configuration()` で動画向けに構成し、エンコーダとして `H264Encoder`、保存先として `FfmpegOutput` を組み合わせると、短い録画をそのまま MP4 に出せます。自動化やアプリ連携では、この形が出発点になります。

# 動画の最小サンプル（Picamera2）
> [!WARNING]
> 以下は一般的なサンプル例です。Picamera2 の API 名・エンコーダ／出力クラスはバージョン差があり得ます。
# 実運用前に picamera2 の公式 API リファレンスで該当バージョンの確認を行ってください。

```python
from picamera2 import Picamera2
from picamera2.encoders import H264Encoder
from picamera2 import Picamera2
> [!WARNING]
> 以下のエンコーダ／出力クラス名は picamera2 のバージョンで変わることがあります。
# 実運用前に picamera2 の公式 API リファレンスで該当バージョンを確認してください。
# （例: import パスやクラス名が異なる場合は公式ドキュメントのサンプルに合わせてください）
from picamera2.encoders import H264Encoder
from picamera2.outputs import FfmpegOutput
from datetime import datetime
import time

picam2 = Picamera2()
config = picam2.create_video_configuration()
picam2.configure(config)

filename = datetime.now().strftime("video_%Y%m%d_%H%M%S.mp4")
encoder = H264Encoder()
output = FfmpegOutput(filename)

picam2.start()
picam2.start_recording(encoder, output)

time.sleep(5)  # 例: 5秒録画

picam2.stop_recording()
picam2.close()

print(f"saved: {filename}")

### 構成（create_*）の考え方と使い分け

`create_*` 系メソッドは、Picamera2で何をしたいかを先に宣言するための入口です。代表的なのが `create_preview_configuration()`、`create_still_configuration()`、`create_video_configuration()` です。名前の通りですが、実際には「表示重視」「静止画保存重視」「動画録画重視」で内部の最適化ポイントが違います。

`create_preview_configuration()` は、画面に映しながら確認する用途と相性がよく、試作段階のカメラ位置合わせや画角確認で扱いやすい構成です。リアルタイムに見ながら調整したいなら、まずこれが出番になります。  
`create_still_configuration()` は、1 枚ずつ撮る静止画向けです。保存品質を主眼にしたい場面で素直です。  
`create_video_configuration()` は、連続フレームを安定して録ることを前提にした構成で、録画パイプラインに乗せるならここから始めるのが自然です。

よくある間違いは、静止画コードの延長でそのまま動画も扱おうとすることです。たとえば `create_preview_configuration()` のまま「とりあえず録れたからこれでよい」と進めると、あとで解像度や記録条件を詰める段階で整理しづらくなります。用途が固まった時点で、構成もそれに合わせて切り替えるほうが見通しがよくなります。（参考: https://www.raspberrypi.com/documentation/computers/camera_software.html）

> [!TIP]
> 画角確認やUI試作は `create_preview_configuration()`、写真保存は `create_still_configuration()`、録画処理は `create_video_configuration()` と分けておくと、コードの役割が崩れません。

CLI とPicamera2を対立させないほうが実務では進みます。まずrpicam-stillやrpicam-vidで「この解像度とフレームレートなら狙い通りに撮れる」と条件を固め、その後で Python に持ち込む流れは手堅いです。逆に、タイマー撮影、センサー入力との連動、撮影後のリネームやアップロードまで一気につなぐなら、Picamera2のほうが伸びます。自動保存名に時刻を入れる、撮影ログを同時に残す、異常時だけ別フォルダへ逃がす、といった運用は Python で書く価値が高い部分です。

つまり、Picamera2は「Python からカメラを部品として扱う」ための道具で、CLI は「まず確実に撮る」ための道具です。自動化やアプリ連携の入口としてはPicamera2が強く、単純録画や性能を詰める場面では CLI が頼れます。この使い分けが見えてくると、カメラ周りの設計が一段すっきりします。

## ストリーミングする｜RTMP配信とローカル配信の考え方

### YouTubeへRTMP配信

配信まで持っていくときは、まず経路を2つに分けて考えると整理できます。ひとつはYouTubeのようなクラウド向けにRTMPで送る方法、もうひとつはMediaMTXで Raspberry Pi 内、あるいは家庭内 LAN に閉じたローカル配信です。前者はそのまま公開配信へつながり、後者は遅延確認や構成の切り分けに向きます。

YouTubeへ送る基本形は、`rpicam-vid` で H.264 を出し、その生ストリームをFFmpegへパイプしてRTMPへ流す構成です。考え方としては、**カメラ制御と配信プロトコル変換を分業させる**のが。`rpicam-vid` は Raspberry Pi 側のカメラ取り回しに集中させ、配信先の要件調整はFFmpeg側で受け持たせると見通しがよくなります。

たとえば、映像だけをそのまま投げる最小構成は次の形です。

```bash
# 配信の最小構成（例）
> [!WARNING]
> オプション名（例: --inline）の有無や挙動は rpicam-apps のバージョンで異なる可能性があります。
```bash
# 配信の最小構成（例）
> [!WARNING]
> オプション名（例: --inline）の有無や挙動は rpicam-apps のバージョンで異なる可能性があります。利用する環境で `rpicam-vid --help` を確認し、まずはローカルで ffplay 等で受けるテストを行ってください。
rpicam-vid -t 0 --inline -o - \

| ffmpeg -re -i - -c:v copy -f flv "rtmp://a.rtmp.youtube.com/live2/＜ストリームキー＞"

（注）--inline の有無や意味合い（SPS/PPS の挿入タイミングなど）は版によって異なる場合があります。
配信前にローカルで受けて動作を確かめてください。

YouTubeでは音声トラックが前提になるケースがあり、映像だけだと受け付けが安定しない場面があります。
そのため、マイクを使わない配信でも無音音声を足しておく構成が手堅いです。
FFmpegの anullsrc で無音を作り、AAC 128kbps を追加する例は次のようになります。

# 無音音声を付ける例（環境により lavfi/anullsrc の扱いが異なる場合があります）
```bash
# 無音音声を付ける例（lavfi/anullsrc のシンタックスやパイプ入力時の扱いは ffmpeg のビルドやバージョンで変わることがあります）
# 事前にローカルで ffplay 等を使って動作確認を行い、ffmpeg のドキュメントでフィルタの挙動を確認してください。
# また、配信キーはコマンド履歴に残さないよう注意してください。
rpicam-vid -t 0 --inline -o - \

| ffmpeg -re -i - -f lavfi -i anullsrc=r=44100:cl=stereo \
  -c:v copy -c:a aac -b:a 128k -shortest \
  -f flv "rtmp://a.rtmp.youtube.com/live2/＜ストリームキー＞"

YouTube向けでは、GOP と映像ビットレートも押さえておきたいところです。
GOP はキーフレーム間隔の目安で、30fps 配信なら 2 秒ごとに I フレームを入れる考え方が基本になり、フレーム数で書くと 60 です。
ビットレートは解像度や絵の動きで変わりますが、実際の入り口としては次のくらいから詰めると迷いません。

配信条件の目安	映像ビットレート	GOP
低めの画質で帯域を節約したい場合	700kbps	60
標準的な 720p〜1080p 配信の入口	1Mbps〜3Mbps	60
動きが多い 1080p 配信で余裕を持たせたい場合	4Mbps〜6Mbps	60

この範囲なら、家庭回線の上り帯域と Raspberry Pi 側の熱設計を見ながら現実的に調整できます。
画が止まり気味の定点監視なら低めでも破綻しにくく、人物が大きく動く配信や屋外映像では上側へ寄せたほうがブロックノイズを抑えやすくなります。

TIP

配信の初回は、公開設定より前にローカル再生で H.264 が連続して出ているかを見ておくと、失敗の原因が一気に絞れます。
YouTubeの待機画面を見ながらカメラ側も同時に疑うより、段階を分けたほうが早く直せます。

ローカル配信

外向け公開の前に、手元や LAN 内で安定して見たいならMediaMTXが噛み合います。Raspberry Pi公式 Camera software でも、rpiCamera ソースを使う方法が案内されていて、カメラを直接ソースにしたローカル配信構成を組めます。
ここがポイントで、rpicam-vid | ffmpeg のような外部パイプを毎回書かなくても、サーバ側が Raspberry Pi カメラを直接扱える形があります。

最小構成のイメージは次のようになります。

paths:
  cam:
    source: rpiCamera

まずはこれくらいから始めると、考える対象が増えすぎません。cam というパス名に対して、クライアント側は RTSP や RTMP、WebRTC で取りにいく、という形です。
執筆時点でBookworm環境におけるパッケージ導入手順や配布形態は要確認ですが、構成の考え方としてはこのシンプルさがMediaMTXの強みです。

ローカル配信でMediaMTXを使う利点は、同じ映像ソースを複数プロトコルで見られることです。
RTSP は監視カメラ系ツールやVLCとの相性がよく、RTMP は既存の配信ワークフローに寄せやすく、WebRTC はブラウザ視聴で遅延を詰めたい場面に向きます。
Raspberry Pi 単体の中で配信サーバまで完結できるので、LAN 内の検証機として置いておくと構成が散らかりません。

筆者の経験では、公開配信を急ぐより、このローカル段階をひとつ挟んだほうが全体が安定します。
たとえばVLCで RTSP を再生して映像は滑らか、でもYouTubeに上げると不安定という状態なら、問題はカメラやエンコードより外向きの送信設定に寄っています。
逆に LAN 内ですでにコマ落ちしているなら、解像度、ビットレート、あるいは Raspberry Pi 側の処理負荷を先に見るべきだと切り分けられます。

ビットレート/GOP/音声と安定運用のコツ

安定運用では、画質の設定そのものよりも、どこでボトルネックが出るかを先に決め打ちしないことが効きます。
配信が乱れるとき、原因は映像ビットレート、キーフレーム間隔、音声の有無、上り回線、サーバ側の認証設定と、候補が複数あります。
そこで、まずローカル再生、次に LAN 配信、そこから外向き RTMP という順で確認していくと、手戻りが減ります。

ビットレートは高くすると画は保ちやすくなりますが、上り帯域が足りないと一気に詰まります。
定点映像なら低めから始めて、人物の移動や背景変化で破綻したぶんだけ上げる、という詰め方のほうが合理的です。
遅延との兼ね合いもあり、バッファを厚く取れば安定側へ寄りますが、ライブ感は落ちます。
逆に遅延を詰める設定は揺れに弱くなります。
ここは画質と遅延を同時に最大化するのではなく、用途ごとに優先順位を決めたほうが運用で迷いません。

GOP は長すぎるとシークや復帰が鈍くなり、短すぎると帯域効率が落ちます。
YouTube向けの 60 は、30fps 配信で 2 秒間隔という扱いやすい落としどころです。
ローカル用途でも、この感覚を基準にすると設定の意味を掴みやすくなります。

音声も見落とされがちな要素です。
マイクをまだ載せていない段階でも、無音 AAC を添えるだけで配信先との相性問題を避けやすくなります。
映像しか使わないつもりでも、受け手の仕様は映像単独を前提にしていないことがあります。anullsrc を使う構成は、その段差を埋めるための実務的な処理です。

セキュリティ面では、RTMP のストリームキーをコマンド履歴や公開リポジトリに残さないことが前提になります。
MediaMTXを外部公開するなら、認証なしで置く構成は避けるべきです。
LAN 内の実験では気軽でも、外に向けた瞬間に話が変わります。
配信URL、鍵、公開範囲を分けて管理しておくと、試験用と本番用が混ざりません。

ネットワークも見逃せない。
家庭回線では下りより上りが先に限界へ当たることが多く、動画配信ではそこが支配的になります。
配信の成否はカメラ性能だけでは決まらず、上り帯域に対してどのビットレートを載せるかでほぼ決まる場面があります。
Raspberry Pi とカメラだけで映る段階から、配信として成立する段階へ進むときは、このネットワーク設計が主役に入ってきます。

よくあるトラブルと対処

物理接続の落とし穴

Raspberry Pi カメラで最初につまずきやすいのは、ソフト設定より先に CSI ケーブルの向きと固定 です。
見た目では刺さっているのに認識しないケースは珍しくなく、実際にはケーブルの接点面が逆だったり、ラッチが最後まで倒れておらず半挿しになっていたりします。
とくにフラットケーブルは薄くて柔らかいため、差し込んだつもりでも数ミリ浮いていることがあります。
ここがずれると、症状としては「昨日まで映っていたのに今日は未検出」が起こります。

Raspberry Pi公式のドキュメント系でも現行はlibcamera系とrpicam-appsが中心ですが、その前段で物理層が崩れているとコマンド側ではどうにもなりません。
筆者の経験では、カメラ本体や基板を宙ぶらりんにせず、小型のクランプやテープを併用して、ケーブルに引っ張り荷重がかからない位置で固定すると誤接触が目に見えて減ります。
ワークショップでも、映像が不安定な個体ほどケーブルがねじれた状態で浮いていることが多く、固定を見直すだけで復帰する場面がありました。

Raspberry Pi 5ではここにもうひとつ落とし穴が加わります。
Raspberry Pi Documentationの整理どおり、Pi 5 と Zero 系は 22 ピン CSI、Pi 4 以前の標準モデルは 15 ピン CSI です。
つまり、以前の Raspberry Pi で使っていた 15 ピン前提のケーブルをそのまま流用すると、物理的に合わないか、変換前提の構成になります。
Pi 5 で認識しないときに OS やドライバから疑う人は多いのですが、まず疑うべきは 22 ピンと 15 ピンの規格違い です。

もうひとつ見落としやすいのが、ケーブル長と折れ癖です。
長めのケーブルをきつく曲げた状態でケースに押し込むと、接点の一部だけが不安定になることがあります。
映るときもある、触ると落ちる、再起動でたまに戻る、という症状なら、ソフト不具合より接触不良の可能性が高めです。
再装着しただけで直る事例が多いのは、結局この物理接点が原因だからです。

認識しないときのチェックリスト

認識しないときは、闇雲に設定を変えるより順番を固定したほうが切り分けが早く進みます。
現行環境では、まず rpicam-hello --list-cameras でカメラが列挙されるかを見ます。
ここで未検出なら、撮影コマンド以前の段階で止まっています。

試す順番は次の流れが堅実です。

Raspberry Pi の電源を落とす
CSI ケーブルを両端とも外し、向きを確認して再装着する
ラッチが最後まで固定されているか見直す
別のケーブルがあれば交換して再試行する
rpicam-hello --list-cameras を再実行する
dmesg を見て、初期化失敗やリンクエラーの痕跡が出ていないか確認する
非公式カメラなら、公式カメラに差し替えて本体側の問題か切り分ける

この順番にしておくと、原因がケーブル、カメラ本体、OS 側のどこに寄っているか見えます。
とくに 電源断してから再装着 は効くことが多く、通電したまま触っても状態が変わらないケースがあります。
筆者の手元でも、何度設定を見直しても未検出だったものが、電源を落としてケーブルを差し直したらそのまま復帰したことがありました。

dmesg は読み慣れていなくても、カメラまわりのエラーが続けて出ていれば手掛かりになります。
接続そのものが成立していないのか、初期化途中で失敗しているのかで見る場所が変わるからです。--list-cameras で空、しかも dmesg に関連エラーが出るなら、物理接続かハード相性の線が濃くなります。

ここで分けて考えたいのが、公式の CSI カメラと非公式の CSI カメラ、さらに USB カメラは挙動が別物 だという点です。
公式のCamera Module 3やHQ Cameraで認識するのに、非公式 CSI モジュールだけ不安定なら、Raspberry Pi 本体よりカメラ側実装の癖を疑う場面です。
USB カメラはそもそも CSI 系の確認手順とは別ルートになるため、rpicam-hello --list-cameras の結果だけで一括判断しないほうが混乱しません。

TIP

公式カメラを 1 台基準機として持っていると、トラブル切り分けが一気に進みます。
ケーブルと本体が正常なら公式側でまず映る、という基準があるだけで、原因を狭める速度が変わります。

旧スタック/ツールの相性と回避策

古い記事をたどってセットアップすると、ここで引っかかることがあります。
たとえばMotionEye系の情報には、旧来の raspistill や raspivid を前提にした説明がまだ残っています。
けれど現行の Raspberry Pi カメラ環境は、前述の通りlibcamera系とrpicam-appsが中心です。
つまり、古い解説どおりに進めても、Camera Module 3やRaspberry Pi 5では素直に噛み合わないことがあります。

相性問題として出やすいのは、V3 系カメラで映像取得までは行けても制御項目が欠ける、あるいは Pi 5 で旧スタック前提のツールがそのまま動かない、という形です。
これはカメラが壊れているというより、ツール側が想定しているカメラ制御の世代が違う ためです。
旧スタック前提の監視カメラ構成をそのまま移植しようとして時間を使うより、今のlibcamera対応状況を基準に見直したほうが筋が通ります。

回避策として現実的なのは、まずrpicam-helloやrpicam-still、rpicam-vidで単体動作を通してから、その上にアプリを載せる流れです。
基礎の撮影系コマンドで正常動作していれば、少なくとも本体、カメラ、現行スタックの組み合わせは成立しています。
その状態でMotionEye系だけが不安定なら、問題はアプリ層に絞れます。
逆に最初から旧ツール込みで組んでしまうと、どこで崩れているのか見えにくくなります。

Python を使うならPicamera2へ寄せたほうが、今の環境と足並みがそろいます。
旧 picamera 時代のコード断片をそのまま持ち込むと、同名でも前提が違って読み替えが必要になる場面があります。
ワークショップでも、昔のブログのコードを貼り付けて動かないケースは珍しくなく、トラブルの中心はライブラリの世代差でした。

電源・性能・プレビューの悩み

録画や配信でだけ不安定になるなら、物理接続の次に見るべきは電源です。
静止画 1 枚は撮れるのに、連続録画やストリーミングで落ちる、フリーズする、保存に失敗するという症状は、処理負荷が上がった瞬間の電源余裕不足で起こります。
とくに USB SSD を同時に使って録画先を外付けにしている構成では、Raspberry Pi 本体、カメラ、ストレージの電力要求が重なります。
AC アダプタの容量だけでなく、USB ケーブルや給電ケーブルの品質が足を引っ張ることもあります。

この手の不安定さは、OS 再設定より配線と給電の見直しで収まることが多いです。
普段は動くのに高負荷でだけ崩れるなら、ソフト相性より先に電源ラインを疑うほうが近道です。
保存先を SD から USB SSD に変えた途端に不安定になった、という流れなら、なおさら筋が通ります。

プレビューの失敗も初心者が戸惑いやすい点です。
ヘッドレス運用で rpicam-hello や rpicam-still を叩いたとき、映像ウィンドウ前提で止まったように見えることがあります。
この場合は -n を付けてプレビューを無効にすると通るケースがあります。
カメラが動いていないのではなく、表示先がないことで詰まっているだけ、ということがあるからです。

性能面では、Picamera2と CLI ツールの差を一言で決めつけないほうが実態に合います。
Python から柔軟に制御したいならPicamera2の価値は高い一方で、高フレームレートの連続録画では rpicam-vid のほうが安定して伸びる場面があります。
1080p の高 fps を長めに回す用途では、CLI のほうが処理経路が短く、詰まりどころが少ない印象です。
反対に、撮影しながら独自処理を差し込みたいならPicamera2が合います。
ここは優劣ではなく、録ることを優先するか、Python から制御することを優先するか で選ぶと整理できます。

次のステップ｜監視カメラ・タイムラプス・AI認識へ

用途で迷ったら、まず「何を撮りたいか」ではなく「撮ったあとに何をしたいか」で切り分けると選定ミスが減ります。
常時見守りならCamera Module 3、画作りを詰めるならHQ Camera、認識処理まで載せるならAI Cameraという軸で決めると、買ったあとに構成を組み替える回数が減ります。
古い資産を活かしたいならCamera Module V2も安価な流用候補になりますが、いま新規で一本目を選ぶなら、将来の拡張まで見据えて現行系を基準にそろえるのが堅実です。
次は必要なケーブルをそろえて認識確認を通し、CLIで静止画と動画を一度撮ってから、Picamera2か配信系へ進む流れに乗せてください。