2 ポイント 投稿者 GN⁺ 2025-09-04 | 1件のコメント | WhatsAppで共有
  • このブログは 再利用された Google Pixel 5 で運用されている
  • Termux のようなツールを使い、モバイル端末上にサーバー環境を構築してブログ運営を実現
  • 100W のソーラーパネル と Jackery 160W パワーステーションの組み合わせにより、ブログを完全なオフグリッド環境で稼働
  • ブログは Hugo ベースで、パッケージのインストールや運用自動化、ファイルのバックアップ・管理を ssh、rsync、cron などで容易に実施
  • Android スマートフォンでも一般的な Linux サーバーのように安定して高速に動作し、効率的な電力消費を実現

紹介と動機

  • このブログは Google Pixel 5再生可能エネルギー(太陽光)だけで運用されている
  • 複数の Mastodon ユーザーが ESP32、Android 端末、ルーターなど独創的なハードウェアでウェブサイトを自前ホスティングしている事例に触発された
  • 低消費電力を意識しながら、中古ハードウェア を新たな用途で生かす実験に自ら着手した

ハードウェアとネットワーク環境

  • 保管していた複数のデバイスの中から、Ethernet に密接に接続でき(USB-OTG とドック対応)、最新のセキュリティアップデートを適用できる Google Pixel 5 を選択
  • Verizon ロックのためカスタム ROM の導入はできなかったが、Android 環境をそのまま活用した
  • 無線接続(Wi-Fi)ではなく、物理的な有線 Ethernet ネットワーク を必ず使うことを重視

太陽光電力ベースのオフグリッドブログ

  • Harbor Freight Tools の 100W 単結晶ソーラーパネルと Jackery 160W パワーステーション で電力を供給
  • このセットアップを通じて、パーマコンピューティング(恒久的に持続可能なコンピューティング)と再生可能エネルギーの実験経験を蓄積
  • 中古部品だけで独立したオフグリッド Web サイトを運用できる可能性を確認

サイト構築: Termux と Hugo

  • 一般的な Linux 環境の構築も検討したが、Android 用ターミナルエミュレーターである Termux と独自のパッケージシステムを活用
  • ssh, git, hugo などの必須パッケージは、以前から Termux リポジトリに存在していた
  • Hugo を Termux に直接インストールし、既存の Hugo ベースのブログを移行

運用経験

  • サイトは期待以上に高速で信頼性の高い動作を見せた
  • 当初は Hugo のバージョン差異やソーラーバッテリー管理など、細かな問題をいくつか経験した
  • Android スマートフォン上で動作していることを、アクセスした人が見分けにくいほど完成度の高い環境を実現

シンプルな構築と管理

  • git, screen, テキストエディタ, hugo のインストールだけで素早くサーバーを構築可能
  • ファイルアップロードや新規投稿は dufs パッケージ(ブラウザベースの静的ファイルサーバー)または scp を活用
  • dufs も Termux リポジトリから簡単にインストール可能

基本ユーティリティパッケージ一覧

  • rsync, openssh, git, wget, curl, fish shell, cronie, termux-services, iperf3, speedtest-go, screen, helix, hugo

サービス自動化と SSH 接続

  • Termux 内ではサービス単位(sv-enable)で sshd/cronie を起動
  • 公式ドキュメントを参照しつつ、ssh 公開鍵の登録、固定ポート(8022)、自動生成されるユーザー名などに注意が必要

Hugo ベースのブログ運用自動化

  • hugo serve の実行コマンドを fish shell のエイリアスとして登録して管理
  • 以前の screen セッション終了、キャッシュ削除、新規セッション作成などの作業を自動化スクリプト(~/scripts/blog_reload.sh)で実装
  • cronie による cron ジョブ登録(*/5 * * * * ...)で、定期的なブログ再起動とリロードを処理

バックアップとデータ管理

  • Termux 上で ssh によりリモート接続し、rsync でディレクトリ全体をバックアップ可能
  • デスクトップおよび NAS に対する cron 連携の自動化も含む
  • 独自の git インスタンスへの追加バックアップも可能で、GitHub など他の forge の利用も自由

まとめと共有

  • モバイル端末と再生可能エネルギーを組み合わせた 安価で効率的かつ環境にやさしいブログ運用 の可能性を実証
  • 関連する質問やフィードバックは Mastodon またはメールで歓迎

1件のコメント

 
GN⁺ 2025-09-04
Hacker Newsのコメント
  • 古いスマートフォンをインフラ軽用途に活用するアイデアが気に入った。低消費電力で内蔵UPSもあるからだ(もちろん欠点もあるが、ある程度は補える)。自分も古いAndroid端末を何台か持っているので、こういう素敵な実験をしてみたい。すでに稼働中のホームラボのインフラなら、VMやコンテナで簡単に機能追加できるので電力消費はほとんど増えない気もするが、それでもこういう試み自体が良いし、自分でもやってみたい。ひとつ気になるのは、なぜWiFiを使わなかったのかという点。ドック→有線LANの機器は、電力消費を増やすだけの余計な追加機器にも感じられる。旧型のスマホでそこまで帯域が必要とも思えないので、著者があえて有線LANを選んだ理由が気になる。ちなみにPixel 5もホームラボの在庫に追加すべきかもしれない。サイトのレイアウトや情報もとても良い
    • 自分もPixel 3をキーボードの左側に磁石で取り付けて使っている。ボタングリッドを表示したWebページを開いておき、ボタンを押すとカーソル位置にタイムスタンプを入力したり、モニターのオンオフを切り替えたり、特定のアプリを起動したりと、いろいろな操作をしている。もともとはElgato Stream Deckを買いたかったが、余っているスマホがあったのでこうして活用している
    • 古いモバイル機器向けの「サーバー化」キットを見てみたい。昔のGame Boy Advance向けコンソール化キット[https://fingercramp.com/portfolio/…
    • ブログの作者です。ありがとう。すでに動いているホームラボにVMやコンテナを追加しても電力消費が増えない、という点には同意する。自分は面白半分と、太陽光で給電してみたかったのでこのプロジェクトを始めた。もともとは夜間にホームラボを止めて、スマホだけをバッテリーで動かし続けるつもりだったが、ホームラボが今では必須インフラになってしまい、常時稼働させる必要がある。有線LANが必要なのは、安定した帯域のためだ。うちのWiFiネットワークは性能があまり良くない
    • WiFiはレイテンシが高く、しかも一定しない。サーバーから出るリクエストの遅い1%は、1秒近く余計にかかることもある。ブログをスマホで動かすなら、かなり素早く応答すべきだと思う。古いAndroidスマホは最新のWiFi規格に対応していないかもしれないし、HNのトップに載ったときのトラフィックをさばくのも難しいかもしれない
    • スマートフォンのWiFiは省電力機能のせいで、外部から予期せず入ってくる接続への応答性能が非常に不安定で遅延も大きい。カーネルパラメータで無効にできるかは分からないが、できたとしてもroot化が必要だろう
  • スマートフォンの電力効率は本当に興味深い。最近のスマホは、バッテリー駆動向けに最適化されたARMサーバーのようなものだ。Pixel 5はフルロードでも5W未満だが、一般的なx86サーバーは50〜100W消費する。個人ブログだけでも年間400〜800kWhの節約になる。電子機器はリサイクルよりも再利用のほうが、環境への影響が思っている以上に大きい
    • 静的サイトならS3やGithub Pagesにデプロイするほうが、はるかに効率的だ。リクエストがないときのリソース消費は0だからだ。自宅で静的サイト運用にx86サーバーを使うのは非常に非効率だ
    • x86でも低消費電力構成は可能だ。n100システムならアイドル時10W未満、最大負荷でも20〜30W程度だ
    • 2020年のスマホでできる作業にx86 CPUが50〜100W使っていた、というのは10年くらい前の話だ。静的ファイルをいくつかホストするために75Wを燃やすのは、今では珍しい。結局のところ、家に余っている古いスマホを超低電力のPi代わりに使うのも良いアイデアだ
    • 年間400〜800kWhの節約だと、米国の平均的な電気料金(1kWhあたり13.2セント)では最大105.60ドル、月あたり約8.8ドルだ。単身世帯の貧困線(2025年基準で15650ドル)の1%にも満たない。エネルギー効率は良いが、マクロで見れば大きな違いではない
  • 正確には リサイクルされた Google Pixel 5ではなく、再利用された Google Pixel 5だ。完全に分解して再生産されたわけではない。Reduce, Reuse, Recycleの順に環境への影響が大きく、再利用は一段上だ
    • とはいえ、全体として再利用であるなら「リサイクル」でも間違いではない。[https://en.wiktionary.org/wiki/recycle/…]
    • recycleも文法的には正しい表現だ。reuseとの意味の差はほとんどない
  • RPiや他のボードを再利用する試みと比べても、Pixel 5の活用は合理的だ。むしろ性能が高い可能性もあり、電力を食うのは画面くらいだろう。高負荷作業での発熱が気になり、どんな電力最適化をしたのか知りたい。ブログで使っているHugoはGoで作られた静的サイトジェネレーターで、コンテンツ配信にも向いていそうだ。ちなみに最近はSSGが好きになっていて、MarkdownベースのブログエディタをTauri/Rust + React/MUIで作り、git連携とCloudflareへのデプロイを組み合わせる構想があるが、まだ実行には移していない。昔MicrosoftがGUIブログエディタを作っていたが、今はなくなってしまったのが惜しい
  • いちばん気になるのは、いわゆる spicy pillow(バッテリー膨張や発火)の問題をどう避けるかという点だ。バッテリーなしでUSB給電だけで動くなら、とても良さそうだ
    • 最近は80%までの充電制限オプションを備えたスマホもある。なければ、スマートプラグとタイマー、あるいはIFTTTでバッテリー残量に合わせて電源を自動制御する方法もある。たとえば40%以下でオン、60%以上でオフにする設定が可能だ
    • いちばん厄介なのは、バッテリーセルを取り外してBMSに直接給電しても、Androidが一定時間後に「バッテリー切れ」と判断してシャットダウンすることがある点だ。これを防ぐにはroot化が必要で、かなり面倒だ。コンセントから直接給電できれば、この問題もなくなる
    • 自分は古いAndroid端末を何台もUSBマルチ充電器につないでおき、それ自体をスマートスイッチにつないで夜に数時間だけ充電している。ROMを書き換えてroot化したあと、ACCAアプリで80%までの充電制限を設定している。2015年発売のSamsung Note 5は半年ほど前に膨張したが、Samsung S9とNokia 6.1はLineageOSを入れて6年間問題なく動いている
    • [https://www.instructables.com/Power-an-Android-Phone-Without-Battery/] こういう方法も参考になるし、機種別のダミーバッテリーもオンラインで購入できる
    • ただ耐火ボックスに入れておいて、壊れたら新しいものに替えるという手もある
  • どこかのGoogle幹部が「なぜこんなふうにGoogle機器を再利用できてしまうのか、ここに広告を差し込む方法はないのか」と気にしていそうだ
  • このコメントは、今でも状態の良いPixel 5から投稿している。自分が使った中で最高のスマホだ。ちょうどいいサイズ、背面の指紋認証など、どれも良い。その後に出たスマホはどれも満足できなかった
    • 自分も整備済みのPixel 5を約250ドルで買って使っている。やはり自分にとって最高のスマホだ。2020年のデザインは、シンプルで実用本位(たとえば画面内指紋認証のような見せかけ機能を排した)なので、長く満足して使える。これから先も2〜3日ごとの充電と、写真品質が「十分良い」水準であってくれることを期待している
    • うちのPixel 5はバッテリー交換が必要そうだ。今では1日に2〜3回充電しなければならないほどバッテリーがへたっている
    • 自分も似たようなものだ。iPhone SE2を寿命まで使うつもりだ(同年代、同サイズ、同重量、Touch IDなど)
  • こういうセットアップでDNSをどう処理しているのか気になる。ISPは普通、家庭用回線でのサーバー運用を歓迎しない気がする
    • 本当の問題はNATだ。tailscale関連のissue [https://github.com/tailscale/tailscale/issues/11563] を追っている。あるいはISPに直接連絡して(もしくは競合他社に切り替えて)、少額の追加料金(たとえば月+5ユーロ)で固定IPをもらう方法もある。たとえば友人とのFactorioマルチプレイにも使える
    • ほとんどのISPは実質的には「動的」IPだが、実際にはほとんど変わらない。自分の場合は年に1回ランダムに変わる程度で、その都度手動でDNSを更新している。自動化もできるが、頻度が低いので手動のままだ。ISPが気にするのは、アップロード側の帯域を継続的に飽和させるような場合くらいだと思う。Comcast/XFinityのようなところは上下非対称がかなり大きいので、その点は考慮が必要だ
    • 動的DNSのソリューションはいろいろある。TP-linkなどはアプリから簡単に設定できる
    • 自分は2.5ギガビット回線を使っているが、それでも固定IPはない。その代わり、ルーターでIPが変わるたびにDNS設定を更新するスクリプトを走らせている。DNSプロバイダがttl変更を許可していれば自動化できる
  • 関連リンク: [https://fairphone.com/en/2024/…]
  • ええと、ここが自分のブログです。自分はただ雑多な文章を書く普通の人間にすぎないのに、急に井戸の外へ放り出された気分だ。HNアカウントも今日初めて作った。質問に答えると、1) 今でもPixelでブログを運営している。変える理由がない 2) 自宅回線に載せたのは、もともとトラフィックはほとんど来ないと思っていたから 3) 平日の夜に家でいろいろ実験しているだけの人で、業界の人間でもない。実際には建設請負会社の社長だ
    • あなたの考え方はエンジニアそのものだから、ここでもうまくやっていけると思う。ブログの他の記事も見てみたが、面白いものが多いし、レイアウトも読みやすいのでまた見に来るつもりだ。「ひとりでいたい」という投稿もHNで人気があった
    • 興味深く読んだ。ひとつ気になったのは、hugo serve だけで動かすのではなく、hugo でファイルをビルドしたうえでnginxのようなWebサーバーを使わなかったのには何か理由があるのか、という点だ