シングルボードコンピュータ向けの安定したバッテリー電源

November 2025

Raspberry Pi ボードは負荷スパイクにはある程度耐性がある一方で、電源の安定性には非常に厳しい。5V が PMIC のしきい値（約 4.63V）を下回ると、ファームウェアはスロットリングを行い低電圧を記録する。さらに電圧低下が続くとリセットに至り、書き込み中であればストレージ破損の現実的なリスクが生じる。^{1 2} Raspberry Pi 5 では、電源がどのような能力を広告しているかに応じて USB ポートの電流上限を引き上げたり制限したりするため、電源とケーブルの選択は稼働時間だけでなく周辺機器に割り当てられる電力にも影響する。²

この挙動は現代の多くのシングルボードコンピュータに共通している。バッテリー駆動での安定動作は、十分な蓄電量、変換効率、遷移時に問題を起こさない電源経路、そして一度の異常終了で破綻しないストレージの組み合わせに依存する。本稿では、OpenWrt といくつかの自作サービスを動かす Raspberry Pi 4B（8GB）を、Anker 737 Power Bank（PowerCore 24K）から給電する実例を用い、これらの点を順に説明する。この構成では、AP に数台のアイドルクライアントが接続された状態で消費電力は約 2W、稼働時間はおよそ 1 日である。

目的は、Pi 4B と 24,000mAh パックの組み合わせに限らず、他のボードと他の電源に対しても SBC とバッテリーの組み合わせを理詰めで評価できるだけの背景を示すことにある。

電力・エネルギーと、mAh 数値だけでは足りない理由

稼働時間や安定性を議論する前に、いくつかの電気量を明確にする必要がある。

電力 $P$ はワットで表され、ある瞬間にシステムがどれだけ速くエネルギーを消費しているかを示す。エネルギー $E$ はワット時で表され、バッテリーが時間を通じてどれだけの仕事を供給できるかを示す。電圧 $V$ と電流 $I$ の関係は通常どおりである。

$$ P = V \cdot I $$

電力がほぼ一定であれば、時間 $t$（時間単位）にわたるエネルギーは

$$ E = P \cdot t $$

となる。

一方、バッテリーやパワーバンクはしばしばミリアンペア時（mAh）で表記される。しかし、この数値だけでは不十分である。アンペア時は特定の電圧における電荷量であり、機器間の比較や稼働時間の計算にはエネルギー、つまり容量と電圧の両方が必要になる。

一般的なコンシューマ向けリチウムイオンセルでは、公称電圧は約 3.6～3.7V である。変換は次の式で行える。

$$ E_{\text{Wh}} = \frac{\text{mAh} \cdot V_{\text{cell}}}{1000} $$

この関係はメーカー説明やユーザー議論でも頻繁に使われている。Anker 737 の場合、$24,000\ \text{mAh} \times 3.6\ \text{V} = 86.4\ \text{Wh}$ となり、筐体に記載された値と一致する。³

具体例を挙げると、3.7V の 10,000mAh パックは約 37Wh、3.6V の 20,000mAh パックは約 72Wh を蓄える。Anker 737 は 24,000mAh、86.4Wh とされ、USB-PD 出力はポート合計で最大 140W に対応している。これらの数値は Anker の公式ページと独立レビューの双方で確認できる。^{3 4 5}

一度ワット時に変換してしまえば、mAh は事実上無視できる。以後の稼働時間や容量設計はすべて「利用可能な Wh ÷ 平均 W」に還元される。

表記 Wh から現実的な稼働時間へ

パワーバンクに記載されたワット時は内部セル電圧で定義されている。SBC が直接その電圧を見ることはない。代わりに DC-DC コンバータがセル電圧を 5V、9V、15V、20V などに昇圧し、別系統で充電制御が行われる。これらの過程では必ず熱としてエネルギーが失われる。

最近の USB-C パワーバンクのテストでは、一定負荷・一定電圧での「実効容量」が測定されることが多い。Anker 737 については、TechRadar などのレビューで 10W～140W 出力時におよそ 73～77Wh が利用可能と報告されており、効率は動作モードにより 81～89% 程度である。⁴ StorageReview の詳細レビューでも、24,000mAh / 86.4Wh の定格と実使用での稼働時間が議論されている。⁵

簡易的な見積もりでは、これらを単一の効率係数 $\eta$ にまとめてよい。

$$ E_{\text{usable}} = E_{\text{label}} \cdot \eta $$

737 のような設計の良い製品では、小型コンピュータを 5V で動かす用途で $\eta \approx 0.8～0.85$ が測定値として妥当である。無名品や仕様不明な製品では、$\eta \approx 0.7$ を計画値とする方が安全だ。

利用可能なワット時が見積もれれば、稼働時間は直ちに求まる。

$$ t_{\text{hours}} = \frac{E_{\text{usable}}}{P_{\text{avg}}} $$

ここで $P_{\text{avg}}$ は SBC と周辺機器を含めた長期平均消費電力である。

具体例として、

• Anker 737 の定格エネルギーは $E_{\text{label}} = 86.4\ \text{Wh}$。
• 保守的に $\eta = 0.75$ とすると、$E_{\text{usable}} \approx 64.8\ \text{Wh}$。

Raspberry Pi 4B が平均 2.1W を消費する構成であれば、期待される稼働時間は

$$ t \approx \frac{64.8}{2.1} \approx 30.85\ \text{時間} $$

737 の表示では、Pi 4B が約 2W を消費し、OpenWrt のアクセスポイントに 2 クライアントが接続された状態で、満充電から残り稼働時間は約 24.5 時間と表示される。これは残量約 49Wh を示唆する。表示が移動平均であること、負荷が完全に一定ではないこと、燃料計ロジックが数回のフルサイクルを経るまで保守的になりがちなことを考えれば、この差は単純計算と矛盾するものではない。

実用的な設計では、簡単な近道が役に立つ。あるパワーバンクが 5V の SBC に対して実測で約 60Wh を安定供給できると分かっていれば、

$$ t_{\text{hours}} \approx \frac{60}{P_{\text{watts}}} $$

という近似で十分なことが多い。2W なら約 30 時間、3W なら約 20 時間、5W なら約 12 時間である。これ以上の精密化は、計算よりもワークロード変動の方に制約される。

シングルボードコンピュータの実際の消費電力

稼働時間の見積もりには現実的な平均消費電力が必要であり、データシートの最大値や大雑把な推測では不十分である。Raspberry Pi 4B については、複数の独立測定で、5V 給電・重い USB 機器なしの場合、アイドル時で約 2.7～3.0W、CPU ストレス時で約 6～7W という値が報告されている。^{6 7} 「Pi Dramble」クラスタに関連する GitHub Wiki では、USB 電力計を用いた詳細な測定が公開されている。⁶ これらを前述の式に当てはめると、報告されている稼働時間とよく一致する。

$$ t \approx \frac{86.4\text{Wh}\times 0.8}{2.7W} \approx 25.6\ \text{時間} $$

これらの数値は、デフォルトのファームウェアクロック、HDMI 有効、一般的な周辺機器構成を前提としている。実際の運用はもっと簡素な場合が多い。ルータやデータロガーとして使われる Pi は、ディスプレイなし、USB 使用は最小限、最大 CPU 周波数を必要としないワークロードであることが多い。

そのような場合、調整の効果は大きい。

• HDMI、Bluetooth、アナログ音声など未使用サブシステムをファームウェアで無効化し、起動時に電源が入らないようにする。
• config.txt で保守的な CPU/GPU 周波数を設定し、OS が要求する遅延・スループットを満たすか確認する。¹
• Linux の CPU 周波数スケーリングを、アイドル時は低クロックを優先する設定にする。
• トラフィックが Wi-Fi のみなら Ethernet を落とす、あるいはその逆を行う。
• カーネルが対応している場合、PCIe や USB3 などのバスでランタイム電源管理を有効にする。

前述の OpenWrt 構成ではこれらを実施している。Pi 4B は config.txt で arm_freq=1000、core_freq=300、gpu_freq=300 を設定し、HDMI、Bluetooth、音声をブート時に無効化している。CPU ガバナは ondemand、最小 600MHz、最大 1GHz とし、rc.local の短いスクリプトで Ethernet を停止、PCIe USB3 コントローラの自動電源制御を有効化し、不要な LED を消灯する。この状態で無線クライアントが 2 台接続された軽負荷時、Anker 737 のメーターは 5V 出力から約 2W の消費を示す。

他の SBC でも制御方法は異なるが構造は同じである。SoC の資料には対応する電圧・周波数動作点が記され、ボード資料にはサブシステムを完全に無効化するジャンパやデバイスツリーオーバーレイが記載されている。候補構成を決めたら、USB 電力計と長時間測定で実際の $P_{\text{avg}}$ を得て、稼働時間計算にフィードバックする。

消費電力を下げることは二重の効果を持つ。同じバッテリーでの稼働時間が延び、同時にケーブルやコネクタ経路での電圧降下も減る。

安定電圧と低電圧検出

十分な蓄電量があっても、ボード上の電圧が許容範囲を保てなければシステムは不安定になる。Raspberry Pi は 5V レールの低電圧を常時監視し、その状態を Linux から確認できる形で露出しているため、この点が特に可視化される。

最近のモデルでは、電源管理 IC 内の監視回路が 5V 入力を監視し、レールが一定のしきい値（文書やコミュニティ資料では約 4.63V とされる）を下回ると信号をアサートする。^{1 5} この信号が有効になると、ファームウェアは消費電力を抑えるためにクロックを下げる。内部状態は vcgencmd get_throttled コマンドで確認でき、そのビットフィールドは現在の低電圧状態と、起動以降に発生したかどうかを示す。^{8 9}

出力例:

$ vcgencmd get_throttled
throttled=0x50005

2 進表記 0101 0000 0000 0000 0101 は、ビット 0、2、16、18 が立っていることを示す。

• 0: 現在低電圧が検出されている（ライブ）
• 2: 現在スロットリング中（ライブ）
• 16: 起動以降に低電圧が発生した
• 18: 起動以降にスロットリングが発生した

短く脆弱な USB-A → USB-C ケーブルも低電圧やスロットリングの原因になる点に注意が必要だ。USB-A ポートは供給電流が限られることが多く、安価または劣化したケーブルは抵抗が高いため、高負荷時に Pi 側の電圧が下がりやすい。より良い方法は、高品質で短い大電流対応の USB-C → USB-C ケーブルを使い、USB-A 出力やインラインスイッチ、摩耗したケーブルを避けることである。検証時には vcgencmd get_throttled 1 で履歴ビットをクリアし、再度負荷をかけて vcgencmd get_throttled が負荷中も 0x0 のままか確認できる。

他の SBC では、PMIC やレギュレータ内部に隠れた別の仕組みが使われるが、物理は同じである。必ず最低入力電圧が存在し、それを下回れば動作保証は終わる。安定したバッテリー運用とは、過渡状態も含めてその限界を十分上回る動作点を保つコンバータとケーブルを選ぶことに等しい。

パワーバンク、パススルー、UPS への期待

USB-C パワーバンクを小型 UPS のように使いたいと考える利用者は多い。AC アダプタをバンクに接続し、SBC をバンクから給電すれば、停電時も再起動せずに済むという期待である。Anker 737 を含む一部の製品は、入力と出力を同時に使うパススルー充電をサポートしている。

内部では少なくとも三つの課題を同時に扱っている。過充電を避けるためのセルへの充電電流管理、USB-PD 仕様内に収めるための昇圧出力管理、そして条件に応じたアダプタ直給電とセル放電の切り替えである。アダプタの抜き差し時には、コントローラが電源経路を再構成し、アクティブなポートで USB-PD の再ネゴシエーションを行うことが多い。

こうしたモード切替時の挙動を測定したレビューでは、短時間の出力乱れが一般的であり、明示的に「UPS モード」を謳っていない限り、厳密な意味での UPS 動作は保証されないことが報告されている。^{4 5} TechRadar による 737 のテストでも、大きな電力のパススルーは可能だが、同時に自己充電は行われず、厳密な UPS ではないと記されている。⁴

Pi 4B のように 5V レールが約 4.63V を下回ると低電圧と判断する SBC から見ると、モード切替時の短い break-before-make 区間は、ケーブルを一瞬抜いたのと同じに見える。SBC 上のコンデンサは非常に短いグリッチを平滑化できるが、必要容量は負荷電流と必要保持時間に比例して増える。コンデンサのホールドアップ能力は次式で表せる。

$$ C = \frac{I \cdot \Delta t}{\Delta V} $$

ここで $I$ は負荷電流、$\Delta t$ はカバーしたい時間、$\Delta V$ は許容電圧降下である。2A の負荷、10ms、0.2V の降下を許容すると、0.1F となり、これはマイクロファラド級のデカップリングではなくスーパーキャパシタの領域である。

実務的な結論として、コンシューマ向けパワーバンクをパススルーで使うと稼働時間の延長や短時間の停電耐性は得られるが、明示的な測定なしに確実な UPS とみなすべきではない。AC 障害をまたいだ無停止運用が厳密な要件である場合、切替特性が明示された DC UPS HAT や、標準 5V 電源を給電する小型 AC UPS の方が予測しやすい。

ファイルシステム、SD カード、電断

ここまでは SBC を動かし続けることに焦点を当ててきた。安定したレールがあっても、バッテリー枯渇時の意図的な電断、ケーブル抜け、上流障害などで突然のシャットダウンは起こる。これらの事象に対するファイルシステムの振る舞いは、全体の堅牢性に影響する。

Linux では ext4 が多くの SBC ディストリビューションで標準である。カーネルドキュメントでは、ext4 はメタデータの信頼性とスケーラブルな性能に重点を置いたジャーナリングファイルシステムと説明されている。¹⁰ デフォルトの data=ordered モードでは、メタデータ変更がジャーナルされ、関連するデータブロックがメタデータのコミット前に書き込まれる。これにより、非ジャーナリング FS と比べて構造的破損の可能性は大幅に減るが、アプリケーションが fsync() を発行する前に電源が落ちた場合、最新のユーザーデータが存在する保証はない。

ext4 の挙動や fast-commit 拡張を解説する分析も同じ点を強調している。ジャーナリングは内部構造の整合性を強く保証するが、アプリケーションバッファ内の任意のデータまで保証するものではない。^{10 11} Unix & Linux Stack Exchange のよく引用される回答では、「保証はない。ジャーナリング FS はより耐性があり破損しにくいが、免疫があるわけではない」と端的に述べられている。¹²

F2FS（Flash-Friendly File System）はフラッシュメディア向けに設計された。カーネルドキュメントや 2015 年の FAST 論文では、そのログ構造レイアウトが説明されている。ボリュームはセグメントに分割され、すべての書き込みは空きセグメントに行われ、チェックポイントが最近の状態を要約し、NAT（Node Address Table）と SIT（Segment Information Table）がメタデータとデータの所在を管理する。^{13 14} 不整合を防ぐため、F2FS は NAT と SIT のシャドウコピーを保持し、チェックポイントごとに切り替える。¹⁴ 電断時には最新の有効なチェックポイントからマウントされ、必要に応じて fsync 済み変更がリプレイされる。

この設計は生のフラッシュ特性に適合しており、書き込み増幅を抑える効果がある場合もある。ただし、市販の SD カードや eMMC では、ファイルシステムと物理セルの間に高度な FTL が存在する。電断時の挙動は F2FS とコントローラファームウェアの双方に依存する。実際には、F2FS は書き込みの多い用途で妥当な選択肢だが、クリーンシャットダウンの必要性をなくすものではない。

したがって、バッテリーや不安定な上流電源で動く SBC では、ファイルシステムの堅牢性は層構造の問題となる。

1. 電源経路を適切に設計し、不要なブラウンアウトやハードカットを避ける。
2. ext4 や F2FS など、クラッシュ耐性のあるファイルシステムを選ぶ。
3. 電断時に失われる状態を減らすため、永続ストレージへの書き込みを抑える。

overlayfs を用いた読み取り専用ルートファイルシステムで Raspberry Pi を運用する方法は多く紹介されている。^{15 16} これは SD カード上の静的ベースに、RAM 上の tmpfs による書き込みレイヤを重ねる方式である。正しく構成すれば、ログや一時ファイル、キャッシュなど大半の書き込みは RAM に落ち、再起動時に消える。SD カードへの書き込みは、明示的に read-write で再マウントして保守する場合に限られる。

安定した電源経路とこの種のファイルシステム構成を組み合わせることで、突発的な電断に対しても驚きの少ないシステムになる。

上流電源としての太陽光

パワーバンクは必ずしも商用電源から充電する必要はない。条件が良ければ、小型の太陽光発電でも同じ直流エネルギーを供給できる。SBC の視点では上流が変わるだけで、ボードが見るのは依然としてバッテリーと DC-DC コンバータである。

太陽光の寄与を考える際、瞬時電力よりも日量エネルギーが自然な単位になる。SBC と周辺機器が平均 5W を消費するなら、1 日あたり約 120Wh を消費する。太陽光・バッテリー系は、平均化された期間でこれ以上を供給できなければならない。

World Bank Group が提供する Global Solar Atlas では、全球水平日射量（GHI）が kWh/m²/日で示される。^{17 18} 日本の多くの地域では、長期平均で設置容量 1kWp あたり約 3～4kWh/日となり、地点や傾斜条件で変動する。日本地域の屋根上太陽光をこのデータセットで評価した研究も、実条件を考慮すると同様の値を示している。^{19 20}

これは、適切な MPPT や PWM コントローラを介してバッテリーに充電する 30～40W パネルで、平均的条件下では 1 日あたり 100～150Wh 程度を供給できることを意味する。夏季には需要を上回ることもあるが、冬季や悪天候では不足する。基本的なエネルギー収支は、パワーバンクの例と同じで、入ってくる利用可能 Wh が出ていく Wh を賄う必要がある。

安定性の観点では、太陽光の変動はバッテリーで平滑化される点が重要だ。充電コントローラとバッテリーが適切に選ばれていれば、SBC は仕様内のローカル DC 電源を見る。コンバータ品質、ケーブル抵抗、低電圧監視に関する規則は同じである。

バッテリー駆動 SBC 設計の実践的手順

以上を踏まえると、バッテリー駆動 SBC の設計や評価手順は紙の上では単純である。

まず、広告されている mAh を定格セル電圧でワット時に変換するか、Wh が直接示されていればそれを使う。Anker 737 では 86.4Wh である。次に、現実的な効率係数を掛けて利用可能エネルギーを得る。737 の場合、テストから中負荷で約 80～85% が示唆されるため、70～75Wh 程度を期待値とするのが妥当である。^{4 5}

次に、実際のワークロード下で SBC の平均消費電力を測定する。インライン USB 電力計は安価で、注意深く扱えば十分である。HDMI 無効、クロック低減、重い USB 機器なしの Pi 4B であれば約 2W、HDMI 有効や高クロック、CPU ストレス下では 3W、6W 以上になる。^{6 7} 現実的な長期平均値を使う。

利用可能 Wh を平均 W で割り、得られた稼働時間が目的に合うか判断する。合わなければ、負荷低減、バッテリー容量増加、変換効率改善、またはその組み合わせを検討する。

並行して安定性を検証する。Raspberry Pi では vcgencmd get_throttled や電源ログスクリプトで低電圧イベントを確認できる。^{8 9} 発生している場合は電源経路を改善する。ケーブルを短く太くする、電圧レギュレーションの良い電源を使う、不要なアダプタやハブを外す、ピーク負荷を下げるなどである。他の SBC では、同等のステータスレジスタやログを資料から確認する。

最後にストレージを考慮する。無人運用でバッテリー枯渇が起こり得るシステムでは、電断を例外ではなく日常とみなすファイルシステム構成が有利である。overlayfs を使った読み取り専用ルート、適切に設定された ext4 や F2FS、ログを SD カードではなく RAM に出す構成は、十分な文書が存在する標準的手法である。^{10 12} [^16] ^{15 16}

消費電力を約 2W に抑え、低電圧を監視した Raspberry Pi 4B と Anker 737 の組み合わせは、この一般設計の一例にすぎない。ワット時、ワット、効率、電圧安定性の関係が明確になれば、他の SBC、別のパワーバンク、太陽光充電システムにも同じ分析がほぼそのまま適用できる。