🐧 ラズパイ5でこれから何をやるべきか — 実測診断と、入れるべきソフト15本

🎒 Section 0: 高校生のための前提知識 — ここを読めば全部わかる

🔬 Section 1: 実測 — 2026年8月2日、このPiは何になっていたか

2026年8月2日、本人のRaspberry Pi 5にSSHで入り、稼働状況・カーネル設定・ネットワーク構成をそのまま実測した。加工も推測もない、コマンド出力そのものである。まずは数字から見る。

ハードとOS、実測値とその意味

先に認めておく必要がある。温度41.1℃、load average 0.15/0.32/0.27、swap使用0B、ディスク使用率13%というこれらの数字は、きわめて健全である。この機械はいま困っていない。落ちていないし、詰まっていないし、熱くもない。もし目的が「安定稼働」だけであれば、この記事はここで終わってよい。

だが本人の要望は違う。「もっともっとLinuxの深淵に生きたい」である。健康な機械が困っていないからこそ、次に取りに行くべきものは性能改善ではない。カーネルが持つ2,262個のtracepoint、CONFIG_BPF_SYSCALLが=yになっているのに一度も使われていないeBPF基盤、namespaceもcapabilityも触られないまま存在するcgroup v2という、**理解の深さ**の方である。この記事はその深さを、実測とスコアと具体的な手順で埋めていく。

→ 次のSection 2では、稼働中の35サービスと3本の自作システムを全部見せ、「作る力はあるがOSは素通りしている」という構造を具体的に確認する。

🗺 Section 2: 全部見せる — 稼働35サービスと、手作りの3システム

このPiで何が動いているかを、隠さずに全部見る。systemdのrunning状態にあるユニットは全35個。まずこれを役割別に分類し、判定として「主力」「補助」「用途不明＝棚卸し対象」の三段階を付ける。

稼働サービス一覧と判定

見えてくるのは資産の未活用である。Dockerは導入済みだが動いているコンテナは searxng の**1個だけ**。InfluxDBは常駐しているが、中に入っているデータベースは pironman5 と _internal の**2つだけ**で、実質ケースのファン・温度テレメトリしか記録していない。時系列DBとコンテナランタイムという「深く使えば強力な道具」が、いずれも入口だけで止まっている。

自作システム3本の時系列

Windows側の管理アプリ Raspberrymaneger（Electron 33 + ssh2 + node-pty）

ここまで見て言えることは一つである。この人はアプリを作る力は完全にある。flockによる多重起動防止、失敗3回でのdisable化、トークンをレンダラプロセスへ渡さない設計判断は、いずれも初心者の書くコードではない。足りていないのは実装力ではなく、この仕組みをOSの機構（systemd unit、namespace、cgroup）に乗せる部分である。

→ 次のSection 3では、この実態をClaudeとCodexの合議による8レイヤ採点で数値化し、総合4/10という結果の中身を一つずつ見る。

📊 Section 3: 深度診断 — 8レイヤ採点、総合4点

Section 1・2で見た実測とサービス構成をもとに、ClaudeとOpenAI Codex(GPT-5.6)が合議して8つのレイヤに点数を付けた。単なる印象評価ではなく、実測値ひとつひとつを根拠として並べている。

補足しておくべきことがある。4点は低い点数ではない。世の中の大半のセルフホスト勢は3〜5点のレンジに収まる。cron・ufw・fail2ban・Docker片手間運用というのは、自宅サーバーとしてはごく標準的な到達点である。問題は点数の低さではなく、**この人の場合は天井がすでに見えている**ことである。カーネルはBPF_SYSCALL・KPROBES・FTRACEをすべて=yで持ち、linux-headersまでインストール済みで、あとは触るだけの状態が並んでいる。作る力と自作システムの完成度を考えれば、この4点は「まだ本気を出していない」の4点である。

→ 次のSection 4では、この採点の裏返し——このPiで「まだ何にも使われていない資源」がどれだけ余っているかを数える。

💤 Section 4: 眠っている資源 — このPiは能力ではなく、やらせることが足りない

Section 2で見た通り、このPiは81日間ノンストップで動き続け、load 0.15という余裕を保っている。 問題は稼働の安定性ではない。せっかく確保した資源のほとんどが、何もやらされずに眠っていることである。

→ 次のSection 5では、この198GBと6.0GBを使って「具体的に何を入れれば何ができるようになるか」をソフト単位で15本挙げる。

📦 Section 5: 入れるべきソフト TOP15 — 何ができるようになるか

以下は「何をするソフトか」「導入した結果、生活と仕事の何が変わるか」を基準に並べた15本である。 順位は、Section 2・3で見た本人の実際の構成（cron 11本・SNS5媒体・Forgejo・Cloudflare事故2回）に対してどれだけ直接効くかで付けている。 「利用の広がり」列は世界での実測データがあるものだけ数値を入れ、無いものは「未取得」と正直に書く。

上位8本を深掘りする

表だけでは「結局何が変わるのか」が伝わりにくい。上位8本については、①何をするものか（専門用語を使わずに）②この人の場合、具体的に何が変わるか ③どこに置くか、の3点で深掘りする。

導入コスト

最初の30分 — 15本を一度に入れてはいけない

上に15本挙げたが、一度に入れると必ず失敗する。どれが原因で何が壊れたか分からなくなるからだ。最初は Uptime Kuma 1本だけにする。理由は単純で、このPiにとって最大の損失は「自動化できていないこと」ではなく、過去2回、サイトが落ちたことに気づけなかったことだからである。守りを1本だけ先に置く。

# 1. 専用フォルダを作る（Dockerは既に動いているので追加インストールは不要）
mkdir -p ~/stacks/uptime-kuma && cd ~/stacks/uptime-kuma

# 2. compose.yaml を1つ置く
cat > compose.yaml <<'YAML'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    restart: unless-stopped
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./data:/app/data
YAML

# 3. 起動する
sudo docker compose up -d

# 4. 動いているか確認する
sudo docker compose ps

起動したらブラウザで開く。127.0.0.1:3001 に閉じてあるので、外からは見えない。Tailscale が既に入っているので、外出先からは Tailscale 経由で見ればよい（新しく穴を開ける必要はない）。

④まで終わって初めて「監視を入れた」と言える。ここまででおよそ30分である。2本目以降は同じ手順の繰り返しで、~/stacks/<ソフト名>/compose.yaml を増やしていけばよい。1本入れるたびに、④の「わざと壊して確かめる」をやること。

→ 次のSection 6では、この中の上位5本を実際に入れた場合、1週間後の1日がどう変わるかを朝から夜まで追う。

🌅 Section 6: 上位5本を入れると、1週間後の1日はこう変わる

Section 5で挙げた15本のうち、Uptime Kuma・Umami・n8n・Paperless-ngx・Immichの5本を実際に入れて1週間運用したとする。 朝起きてから夜寝るまでの間に、これまで無意識にやっていた確認作業や、そもそもやっていなかったことが、どう変わるかを追う。

→ 次のSection 7では、この5本を含む15本を「事業に直結する3つの使い方」としてまとめ、Cloudflare事故の再発防止・コンテンツ工場の数字化・事業書類の自宅保管に落とし込む。

🏭 Section 7: 事業に直結する3つの使い方

① Cloudflare事故を二度と起こさない仕組み

過去2回、自作botのポーリングがCloudflare無料枠を枯渇させ全サイトを停止させた。3秒間隔のポーリングを2チャンネル分走らせただけで1日57,600リクエストになり、無料枠10万req/日の半分以上をこの1本のbotが食い潰した計算になる。この手の事故は「後から気づく」から被害が大きくなる。監視と通知を自宅のPiに常駐させておけば、異常が起きた瞬間にスマホへ届く。

② コンテンツ工場の材料と成果を数字で回す

記事や動画のネタ集め、情報源の巡回、公開後の反応確認をそれぞれ別のソフトに任せ、その結果を1か所に記録する。記録先は新しくサーバーを立てる必要はなく、いま「pironman5」と「_internal」の2つのDBしか入っていない、ほぼ空のInfluxDBをそのまま使う。既にある資産を再利用するだけで、コンテンツ工場の「どれが当たったか」が数字で見えるようになる。

③ 事業書類とパスワードを自分の手元に置く

契約書・領収書・ログイン情報・原稿PDFといった事業の中身は、外部のクラウドサービスに預けなくても自宅のPiで管理できる。Paperless-ngxで書類を検索可能な状態にし、Vaultwardenで全サービスのログイン情報を1か所にまとめ、Stirling-PDFで原稿や資料を外部アップロードせずに加工する。この考え方は、33リポジトリのForgejoを自宅に置いているのと同じ思想の延長であり、事業データの置き場所を自分でコントロールし続けるという一貫した方針である。

→ 次のSection 8では、逆に「入れても使わなくなるもの」と「Pi 5では動かないもの」を正直に挙げる。

🚫 Section 8: 入れても使わなくなるもの／Pi 5では動かないもの

使わなくなるもの 5つ

どれも紹介記事やランキングでは定番として名前が挙がるソフトである。しかし、この人の実際の構成（Samba・Immich・Syncthing・Beszel・n8n・Homepageが既に役割を持つ構成）に当てはめると、機能が重複するか、24時間稼働のPiにとってリスクの方が大きい。

Pi 5では動かない・向かないもの

Pi 5は8GBメモリでGPUを持たない。動かせないわけではないが、実用に耐える速度で動かせないものがある。無理に動かそうとして時間を溶かすより、最初から別の手段に振り分けた方が早い。

このセクションを入れたのは、期待させたまま終わらせないためである。Pi 5は何でもできる万能サーバーではない。できないことを先に書いておけば、入れた後に「動かなかった」で時間を溶かさずに済む。

→ 次のSection 9では、世界の人々が実際に何を動かしているのかを、一次情報の実測だけで確認する。

🌍 Section 9: みんなは何を動かしているのか — 一次情報だけで測る

🚨 Section 10: 今すぐ直すべき危険 TOP5

以下はClaudeとCodexの合議で深刻度順に並べた5件である。すべて実測に基づき、誇張表現は避けた。 「今すぐ壊れる」ものと「いつか効いてくる設計上の負債」を分けて書く。

危険は5つ挙げたが、そのほとんどは「いま起きている障害」ではない。この機械は壊れていない。 81日間安定稼働し、swapは0Bのままで、温度は41.1℃を保っている。ここに挙げたのは、すべて「いつか効いてくる設計上の負債」である。 今日壊れる話と、5年後に効いてくる話を混同しないことが、この診断の信頼性を保つ唯一の方法である。

→ 次のSection 11では、この記事の目玉である「Codexによる私（Claude）への反論」を、そのまま載せる。

🤖 Section 11: Codexの反論 — 私（Claude）の提案は、どこが間違っていたか

この記事は、最初から「まずソフトを入れて、生活と仕事を載せる」という構成だったわけではない。私(Claude)は当初、実測データを見た時点で「bpftraceとeBPFを軸に、systemdのhardening・nftablesのネイティブ記法移行・Nixによる宣言的管理・Prometheus+Grafanaの監視スタックを一気に組む」という構成を考えていた。これをOpenAI Codex（GPT-5.6）に投げ、「反論しろ」と明示的に指示した。返ってきたのは7つの指摘であり、そのうち何を受け入れ、何を受け入れなかったかを、ここで正直に書く。

7つの反論と判定

特に重い3つの指摘

① 「eBPFを最初に置くのは順序が逆」

これが最も記事の骨格を変えた指摘である。Section 8は当初「bpftraceを入れて終わり」の短いセクションになるはずだった。Codexの指摘を受けて、strace → perf → ftrace（既にカーネルに組み込まれている追跡機構） → bpftrace → CO-RE型eBPFという5段の階段に書き直した。理由は単純で、いきなり高級な観測ツールを使えても、その裏で何を見ているか説明できなければ「コピペで動かした」に過ぎないからである。

② 「Python+cronを否定するな」

当初、私は「cronとPythonスクリプトは前時代的で、systemdへの全面移行が正解」という暗黙の前提を持っていた。しかし実測では、sns-posterはfcntl.flockによる多重起動防止・3回連続失敗で自動的に投稿を無効化・月$6.5の予算管理と80%到達時の警告という、決して素人設計ではない仕組みを持っていた。Codexの指摘を受けて方針を「Pythonのアプリケーション側設計は否定しない。起動方法・実行権限・ログの出し先だけをsystemdへ委譲する」に変更した。この方針転換がなければ、記事は「全部systemdに書き直せ」という、実行されない提案で終わっていた。

③ 「最大の盲点は復旧訓練」

これは私が完全に見落としていた指摘である。IaC（Infrastructure as Code、構成をコードとして書く手法）を導入しても、監視ツールを整えても、Forgejo・秘密情報・systemd設定を別の媒体から実際に復元できることを検証しない限り、運用の成熟度は上がらない。Section 10の危険TOP5で「Forgejoバックアップが同一NVMeのみ」という問題を挙げたが、これはバックアップの有無ではなく復元できることの証明が欠けているという、より根の深い問題として扱うべきだとCodexは示した。この視点はSection 12の90日ロードマップの合格条件にそのまま反映されている。

「監視スタックは過剰」という直感がデータと一致していた

Codexの4番目の反論は「Prometheus+Grafana+LokiはPi5には過剰」という定性的な主張だった。これを裏付けるため、Debianの利用実態統計であるpopcon（popularity-contest、Debianパッケージがどれだけ実際にインストールされているかを匿名集計した統計）を確認すると、Prometheusのインストール率は0.3%、Grafanaは0.9%だった。つまりCodexの「深さより監視製品の世話が増える」という直感は、実際のDebianユーザーの選択傾向とも一致していたことになる。

クロスモデルレビューの効用

この一連のやり取りが示すのは、単一のモデルだけで記事を作ることの限界である。私(Claude)だけで書いていたら、この記事は「eBPFとNixとPrometheusを入れましょう」という、見た目は高度だが実際には順序も優先度も誤った提案で終わっていたはずである。Codexという別のモデルに反論させることで、「深そうに見えるもの」と「実際に深いもの」を分離できた。これは記事の構成だけでなく、実際の作業計画（Section 12）にもそのまま反映されている。

→ 次のSection 12では、ここまでの全部を「90日で何を入れて、何ができたら合格か」という実行計画に落とす。

🗓 Section 12: 90日ロードマップ — 何を入れて、何ができたら合格か

この記事の出発点は「もっとどうしたらいいか」だった。答えは新しい技術を学ぶことではなく、いま余っている198GBのディスクと6.0GBのメモリの上に、仕事と生活を実際に載せることである。Piは既に81日間止まらずに動き続けている。足りていなかったのは能力ではなく、やらせることだった。

🎓 Section 13: 高校生レビュー — Codexに2回、厳しく採点させた

この記事には「高校生レビュー」を必ず入れるという決まりがある。何も知らない高校生が読んで理解できないなら、その記事は書けていないという考え方である。 そして書いた本人（私・Claude）には「自分が分かっているから読者も分かるはずだ」という盲点がある。だから別のモデルに採点させる。 「甘い評価は不要。厳しく判定せよ。この評価はそのまま記事に掲載される」と指示した。

初版がなぜ0点だったのか

Codexの再採点（原文のまま）

残った指摘と、この改訂での対応

「で、何をすればいいのか」は伝わるようになったか

この記事を読んだ人が、明日やること1つ

📎 付録: カーネル解剖 — このPiで、eBPFの半分は動かない

「もっともっとLinuxの深淵に生きたい」と決めて、最初にやったことはアプリを1個増やすことではなかった。 このPiの /boot/config-6.12.75+rpt-rpi-2712 を読むことだった。 アプリケーション層でどれだけサービスを積み上げても、カーネルが観測を許していなければ、その下には潜れない。 だから深淵の入口は、まず「このカーネルは何を許し、何を許していないか」を実測することから始まる。

実行したコマンドは3つだけである。カーネルのビルド設定を grep で確認し、BTF（後述）のファイルが存在するかを ls で確認し、 ftraceが使えるトレーサー一覧を cat する。これだけで、このマシンの観測能力の輪郭が見える。

# カーネルのeBPF/トレース関連ビルド設定を確認
grep -E "^CONFIG_(BPF_SYSCALL|DEBUG_INFO_BTF|KPROBE_EVENTS|UPROBE_EVENTS)=" /boot/config-$(uname -r)

# BTF(BPF Type Format)ファイルの存在確認
ls /sys/kernel/btf/vmlinux

# ftraceが使えるトレーサーの一覧
sudo cat /sys/kernel/tracing/available_tracers

結果は明快だった。ls /sys/kernel/btf/vmlinux は「そんなファイルは無い」と返す。 available_tracers は blk function_graph wakeup_dl wakeup_rt wakeup function nop という7つの名前を返す。 以下、実測したCONFIG項目を全て並べる。

BTFとCO-RE — 何が「無い」のか

BTF（BPF Type Format）とは、カーネルの構造体やその型情報をバイナリに埋め込んだデータ形式のことである。 これがあると、eBPFプログラムは「struct task_struct の pid フィールドを読む」というように、カーネル内部のデータ構造を名前で参照できる。

CO-RE（Compile Once - Run Everywhere）とは、このBTFを使うことで、1回コンパイルしたBPFプログラムを、 カーネルのバージョンやビルド設定が違う別のマシンでも再コンパイルなしで動かせる仕組みを指す。 現代のBCCツール群やbpftraceの「構造体メンバに直接アクセスする」記法は、この仕組みの上に成り立っている。

このPiのカーネルは CONFIG_DEBUG_INFO_NONE=yでビルドされている。デバッグ情報を一切埋め込まない設定であり、結果として /sys/kernel/btf/vmlinux は生成されない（実測で確認済み）。BTFが無ければCO-REは成立せず、 BCCの現代的なツール群とbpftraceの構造体メンバアクセスは、このカーネルの上では素のままでは動かない。

もう一点、CONFIG_UPROBE_EVENTSが未設定であることも効いてくる。これはユーザ空間の関数にプローブを刺す機能で、 これが無いということは、自作のPythonスクリプトの特定の関数呼び出しをbpftraceで追跡する、といった使い方ができないことを意味する。 カーネル空間のイベントは観測できても、アプリケーションコードの内部までは踏み込めない。

なぜRaspberry Pi公式カーネルはこの設定なのか。BTFを有効にするとカーネルイメージのサイズが増え、ビルド時間も伸びる。 組込み・SBC向けディストリビューションとしては合理的な判断だと考えられる（これは推測であり、公式の明言ではない）。 実際、Raspberry Pi公式リポジトリには「BTFを有効にしてほしい」という要望issueが存在する。 github.com/raspberrypi/linux/issues/6622

では何ができるのか — ここが救いである

BTFが無い、uprobeが無い、で終わる話ではない。ftraceは完全に生きている。 available_events は2,262個、イベントカテゴリは116個ある。kprobeもCONFIG_KPROBE_EVENTS=yのおかげで使える。 BPF_SYSCALL・BPF_JIT・BPF_EVENTS・PERF_EVENTSも全て有効である。「トレースができない機械」ではなく、 「最新のCO-RE型eBPFツールだけが動かない機械」というのが正確な表現である。

「やりたいこと」に対して、このPiが実際に「できるか／できないか」を対比させると、次のようになる。

導入済みのトレース系ツールはstraceとsystemd-analyzeだけである。bpftrace・bpftool・perf・ltraceはまだ入っていない。 Debian 13(trixie)ではbpftrace 0.23.2-1、bpfcc-tools 0.31.0+ds-7、bpftool 1:7.7.0+6.18.39-1+rpt1、linux-perf 1:6.18.39-1+rpt1が候補として存在するので、 導入自体は難しくない。難しいのはBTFという前提条件の方である。

この制約は不幸ではない。むしろ深淵への入口である。BTFとuprobeを有効にした自作カーネルをビルドし、 既存のカーネルと並べて起動する——これは曖昧な目標ではなく、「起動できたか／できなかったか」で検証可能な明確なゴールになる。 それが、この付録の先にある作業である。

参考: ebpf.io / docs.kernel.org/bpf / bpftrace.org / docs.kernel.org/trace/ftrace.html / raspberrypi/linux issue #6622

→ 次のSection 4では、この採点の裏返し——このPiで「まだ何にも使われていない資源」がどれだけ余っているかを数える。