はじめに
知人が Atom Cam 2 という Wi-Fi ネットワークカメラで遊んでいるのを見て楽しそうだったので、自分も挑戦してみることにしました。
どうも中身は Linux 機器のようなので、大好きな Elixir と Nerves で操作できるようになったらいいな〜と思ってました。
調査を始めた当初は、本当に Nerves が起動できるかもよく分からない状態でしたが、
試行錯誤を重ねた結果、Atom Cam 2 向けの独自 Nerves System を作り、次のような標準的な Nerves の開発手順を利用できるところまで進めることができました ![]()
mix firmware # Nerves ファームウェアを作成する
mix firmware.burn # ファームウェアを MicroSD カードへ書き込む
mix upload nerves.local # 起動中の機器へネットワーク経由でファームウェアを転送・更新する
せっかくなので成果は次のリポジトリで公開し、世界のみんなに共有しようとおもいます。
この記事では、Atom Cam 2 の標準機能、先行研究である atomcam_tools、独自 Nerves System の構成、録画ファイルの NAS 転送について紹介します。
Atom Cam 2 とは
- 小型のネットワークカメラ
- 比較的安価(2026-06-25 現在、約5,000円)
- 一辺が約5センチのサイコロのような形
- Wi-Fi に接続し、スマートフォンアプリから映像を確認できる
- 映像の録画、人の動きの検知、夜間撮影、通知などにも対応
- 内部には Wi-Fi、カメラセンサー、保存領域、音声入出力、映像処理機能を備えている
大まかな動きは次の通りです。
Atom Cam 2
-> Wi-Fi に接続する
-> 映像と音声を取得する
-> microSD またはクラウドに録画する
-> 動きを検知する
-> スマートフォンに通知する
-> アプリから映像を確認できる
単なるカメラというより、小さな Linux 搭載の映像機器と考えることもできます。
公式の使い方
付属の取扱説明書を読み、まずは公式の使い方を確認しました。
初期設定は次のような流れでした。
- スマートフォンに公式アプリを導入する
- Atom Cam 2 に電源をつなぐ
- 公式アプリを開く
- アカウントを登録する
- Atom Cam 2 を登録する
- Wi-Fi を設定する
設定が終わると、登録した Atom Cam 2 のリアルタイム映像を公式アプリから確認できます。
利用者から見た大まかな構成は次のとおりです。
公式アプリ
|
v
ATOM クラウド
|
v
インターネット
|
v
Wi-Fi ルーター
|
v
Atom Cam 2
公式アプリは、映像の確認やカメラの設定、通知の受信などを行うための操作画面です。
Atom Cam 2 が Wi-Fi を通じてインターネットへ接続し、ATOM クラウドと連携することで、自宅の外からも映像を確認できます。
公式サイトにある動画によると、最終的には「使い方はあなた次第」とのことです。
自分次第とのことなので、自分らしく Nerves で操作できる環境を作ってみます。
公式の動画保存方法
公式サイトによると、主な動画保存方法には「クラウドストレージ」と「microSD カード保存」があります。
クラウドストレージ
- 有料サービスとして提供される
- カメラが動きを検知すると録画を開始する
- 録画した動画をクラウド上へ保存する
- 保存期間は利用するサービス内容によって決まる
microSD カード保存
- 録画した動画をカメラ本体の microSD カードへ保存する
- 初期設定後は、インターネット接続が切れてもカメラ側の録画を継続できる
- 空き容量が不足すると、古い録画から順に上書きされる
ハック
知人から、自力で Atom Cam 2 を調査して拡張している方がいると教えてもらいました。
atomcam_tools は、Atom Cam 2 の重要な先行研究です。
この公開成果がなければ、私は Atom Cam 2 の内部構造を理解するところから始めることも難しかったと思います。貴重な知見を公開してくださったことに感謝し、atomcam_tools の実績ある方法を参考にしながら作業を進めました。
元のカメラ機能をすべて作り直すのではなく、カメラ内部に保存されている提供元の実行環境を利用しながら、周囲へ機能を追加しています。
主な実装方法は次のようなものです。
- シェルスクリプトによる起動処理
- Linux プロセスの起動と監視
- C の共有ライブラリによる関数の差し替え
-
mvやrmなどのコマンド差し替え - ファイルや名前付きパイプによる処理間連携
- Web 画面
- NAS、RTSP、通知などの追加機能
例えば、提供元のカメラアプリケーションが録画ファイルを移動するときに呼び出す mv を差し替えることで、NAS 転送などの追加処理を実現しています。
提供元のカメラアプリケーション
|
v
録画ファイルが完成
|
v
差し替えた mv コマンド
|
+-- 通常のファイル移動
|
+-- NAS 転送
|
+-- 通知
この仕組みから、次のことを学びました。
- Atom Cam 2 の起動方法
- 内部フラッシュの構成
- カメラ実行環境の起動方法
- Wi-Fi 部品の初期化方法
- 既存のカメラ機能を壊さずに拡張する方法
今回の Nerves System でも、すべてを Elixir で作り直すことは目指していません。
ハードウェア固有の部品や提供元のカメラ実行環境は必要に応じて再利用し、アプリケーションの状態管理、監視、更新、復旧を Elixir と Nerves 側へ移す方針としました。
Atom Cam 2 の解剖
Atom Cam 2 は、単なるカメラではなく、小さな Linux 搭載の映像機器として見ることができます。
Linux からは、内部フラッシュの構成、読み込まれているカーネルモジュール、起動中のプロセスなどを確認できます。
atomcam_tools の公開資料と実機調査を組み合わせることで、それぞれの部品がどのように利用されているかを少しずつ確認しました。
重要だったのは、最初から全部を置き換えようとしないことです。
既知の状態で起動する
|
v
一つの層だけ置き換える
|
v
どこまで動いたか確認する
|
v
結果を記録する
この繰り返しで調査を進めました。
カスタム Nerves System
当初は「将来的に作れたら面白そう」と考えていた Atom Cam 2 向けの Nerves System ですが、実際に起動できるところまで実装できました。
2026-07-30 現在、次の土台を実装しています。
- Atom Cam 2 上で Nerves を起動
- Atom Cam 2 向けの独自クロスコンパイル環境
mix firmwaremix firmware.burnmix upload- Wi-Fi 接続
-
nerves.localによる名前解決 - SSH 接続
- 永続保存領域
/data - A/B アプリケーション領域
- 新しいファームウェアの確認と復旧
- 提供元カメラ実行環境の読み取り専用事前確認
- 録画ファイルを外部へ転送する NAS exporter
全体構成
構成は次のようになっています。
Atom Cam 2 hardware
|
v
提供元の起動部品
|
v
Nerves boot manager
|
v
Application slot A または B
|
v
Erlang VM
|
v
Elixir application
|
+-- Wi-Fi
+-- SSH
+-- /data
+-- 更新
+-- 復旧
+-- NAS exporter
ハードウェア固有の低い層は、動作が確認できている提供元の部品を残しています。
その上で、一般的な Linux ユーザー空間、Erlang VM、Elixir アプリケーション、ネットワーク、更新、復旧などを Nerves 側で管理します。
起動の流れ
Atom Cam 2 の起動環境は、microSD 上にある特定の名前のファイルを読み込みます。
電源を入れる
|
v
U-Boot
|
v
保護された制御カーネル
|
v
内蔵された提供元 initramfs
|
v
rootfs_hack.squashfs
|
v
Nerves boot manager
|
v
Application slot A または B
|
v
Nerves アプリケーション
rootfs_hack.squashfs は、直接アプリケーションを格納する場所ではなく、小さな起動管理役として利用しています。
起動管理役が、A または B のどちらのアプリケーションを起動するか判断します。
A/B ファームウェア更新
通常の一領域だけを使う更新では、動作中のファームウェアを直接上書きすることになります。
書き込み途中で電源が切れると、起動できなくなる危険があります。
このため、アプリケーションを A と B の二つの領域へ分けました。
現在起動中
Slot A
新しいファームウェア
Slot B へ書き込む
新しいファームウェアは、使っていない領域へ書き込みます。
Slot A で動作中
|
v
Slot B へ新しいファームウェアを書き込む
|
v
書き込み結果を確認する
|
v
Slot B を試験起動する
|
+-- 正常
| |
| v
| Slot B を確定
|
+-- 異常
|
v
Slot A へ戻る
新しいアプリケーションが正常に動かなかった場合でも、以前に確認済みの領域へ戻せることを目指しています。
永続保存領域 /data
A/B のアプリケーション領域は読み取り専用です。
設定、録画待ちファイル、SSH の状態など、書き換えが必要な情報は /data へ保存します。
Application slot A / B
-> 読み取り専用のファームウェア
/data
-> 書き換え可能なアプリケーションデータ
/data は、次の操作を行っても維持されます。
- 再起動
- ファームウェア更新
- A/B 領域の切り替え
- 以前のファームウェアへの復旧
Wi-Fi と SSH
Atom Cam 2 の Wi-Fi 部品は、ATBM603x 系の SDIO 機器でした。
atomcam_tools に含まれていた互換カーネルモジュールと起動手順を調査し、Nerves 側で wlan0 を生成できるようにしました。
Wi-Fi 部品の初期化
|
v
カーネルモジュールを読み込む
|
v
wlan0 が現れる
|
v
VintageNet が Wi-Fi へ接続する
|
v
nerves.local
|
v
SSH 接続
これにより、次のような通常の Nerves 開発手順を利用できます。
ping nerves.local
ssh nerves@nerves.local
mix upload nerves.local
提供元カメラ実行環境
公式モバイルアプリのライブ映像などを維持するには、提供元のカメラ実行環境を動かす必要があります。
ただし、これを Nerves の起動処理へ直接組み込むと、カメラ側の障害が SSH、更新、復旧にも影響する可能性があります。
そのため、カメラ実行環境は任意の互換サービスとして分離する方針としました。
Nerves の基本機能
|
+-- 起動
+-- Wi-Fi
+-- SSH
+-- /data
+-- 更新
+-- 復旧
|
+-- 任意のカメラ互換サービス
|
+-- 提供元ファイルシステムを読み取り専用で利用
+-- 必要なカメラ用モジュールを読み込む
+-- 提供元カメラプロセスを起動する
現在は、提供元ファイルシステム、カメラ用バイナリ、共有ライブラリ、カーネルモジュールなどを安全に確認するための事前調査機能を実装しています。
Nerves 上での提供元カメラ実行環境と、公式モバイルアプリの完全な共存は引き続き検証中です。
NAS への録画保存
今回の目標の一つは、録画ファイルを自分で管理する NAS へ保存することです。
録画処理と NAS への転送処理は分けて考えました。
完成した録画ファイル
|
v
/data に一時保存
|
v
NAS exporter
|
v
SFTP
|
v
ローカル NAS
録画ファイルをいったん /data に保存し、別の処理が NAS へ転送します。
この構成にしておくと、NAS やネットワークに問題が発生しても、録画ファイルを端末側へ残し、あとから転送を再試行できます。
NFS や SMB は現在のカーネルで利用できないため、Erlang/OTP から扱える SFTP を採用しました。
手元に専用の NAS がなかったため、最初の検証では Linux 開発機を保存先として利用しました。
この検証では、公開鍵による認証と、録画ファイルを遠隔のディレクトリへ転送する基本的な流れを確認しました。
atomcam_tools と Nerves の違い
先行研究である atomcam_tools と、本プロジェクトの nerves_system_atomcam2 は、どちらも提供元のカメラ機能を活用しますが、処理のまとめ方が異なります。
| 項目 | atomcam_tools |
nerves_system_atomcam2 |
|---|---|---|
| 中心 | シェルスクリプト | Elixir プロセス |
| 処理管理 | Linux プロセスと起動スクリプト | OTP supervisor |
| 処理間連携 | ファイル、名前付きパイプ、コマンド | メッセージ送信 |
| 低水準の拡張 | C hook、コマンド差し替え | 必要な処理だけ外部処理として利用 |
| 障害対応 | プロセスや機器の再起動 | プロセス単位の監視と再起動 |
| 更新 | 独自の更新処理 | A/B ファームウェア更新 |
| NAS | SMB などを直接利用 |
/data と独立した NAS exporter |
atomcam_tools は、既存のカメラ機能を残しながら、多くの機能を追加する仕組みです。
一方、nerves_system_atomcam2 は atomcam_tools を参考にしつつ、必要な低水準の仕組みを利用し、その周囲の状態管理、障害対応、更新、復旧を Elixir と Nerves で管理することを目指しています。
AI を使った開発
今回の調査と開発では、ChatGPT と Codex を活用しました。
AI を使うと自分の理解より速く実装が進むことがあるため、完成したコードだけでなく、設計判断や実験結果もリポジトリへ残しました。
docs/adr -> 設計判断
docs/worklog -> 調査と実験の記録
scripts -> 再現可能な操作
tests -> 機械的に確認できる条件
README.md -> 現在の使い方
CHANGELOG.md -> 変更内容
すべてをその場で理解できなくても、後から読み返して学べる状態を目指しています。
現在の状況
2026-07-30 現在、次の基本機能を確認できています。
- Nerves の起動
- Wi-Fi と SSH
-
mix firmware、mix firmware.burn、mix upload - A/B 領域による更新と復旧
-
/dataへの永続保存 - SFTP による外部保存
今後も、実機での検証を重ねながら、少しずつ改善していきます。
おわりに
Atom Cam 2 は、見守りカメラとしてだけでなく、Linux、Elixir、Nerves、ネットワーク、ファームウェア更新、障害復旧などを學べる組み込み機器でもあります。
今回、Nerves の起動、Wi-Fi、SSH、永続保存領域、A/B 更新、NAS 転送の土台を作ることができました。提供元のカメラ実行環境との共存や長時間録画については、引き続き実機で確認していきます。
カメラをハックしたというより、Atom Cam 2 を自分が学び続けるための組み込み教材へ変えている感覚です。
今後も実験結果と設計判断をリポジトリへ残しながら、そこで使われている技術への理解を少しずつ深めていこうと思います。







