なぜ我々はRaspberry Pi 5にClaude Codeを閉じ込めるのか
エンジニアの日常において、AIエージェントの「常駐場所」は意外なほど悩ましい問題だ。メインのMacBook ProでClaude Codeを動かしていると、ふとした瞬間にスリープに入り、あるいはメモリを食い合ってIDEの動作が重くなる。深夜の障害対応中に「あ、エージェントが落ちてる」と気づいた時の絶望感は、デッドロックに遭遇した時と同等か、それ以上に精神を削る。今回、Raspberry Pi 5を専用のAIホストとして仕立てるというアプローチは、単なる「遊び」ではない。これは、開発環境の物理的な分離と、宣言的構成管理による「再現性の担保」という、シニアエンジニアが喉から手が出るほど欲しかった『堅牢な開発基盤』の構築そのものだ。
今回採用されたNixOSという選択肢が、このプロジェクトの価値を決定づけている。SDカードが物理的に破損しても、あるいは設定をいじりすぎてOSが起動しなくなっても、flake.nixさえあれば数分で元の環境が蘇る。これは、スパゲッティコード化した設定ファイルに怯えながら運用する従来のLinuxサーバー管理とは一線を画す体験だ。Raspberry Pi 5（8GBモデル）という、かつてのおもちゃの枠を超えた演算能力を持つデバイスを、NixOSで厳格に管理する。この構成は、単なるClaude Codeの実行環境を超え、将来的にMCP（Model Context Protocol）サーバーを複数束ねるための「AI専用ゲートウェイ」としてのポテンシャルを秘めている。
以下の表は、今回の構築にかかった機材コストの概算である。決して安くはないが、MacBook Proの寿命を削らず、かつ24時間365日稼働する「自分専用のAI副操縦士」を確保するための投資と考えれば、極めて合理的な判断と言えるだろう。
| 機材 | 価格（円） |
|---|---|
| Raspberry Pi 5 (8GB) | 37,070 |
| ElectroCookie Mini PCケース | 2,890 |
| Vesiri For Raspberry Pi5 | 2,080 |
| KIOXIA microSD 32GB | 1,722 |
特に注目すべきは、Claude Codeをsystemdサービスとして常駐させる設計思想だ。対話モードではなく、あえてサーバーモード（remote-control）で起動し、SSHセッションの切断に依存しない永続的なプロセスとして管理する。これは、我々が本番環境でWebサーバーを運用する際のベストプラクティスを、そのままAIエージェントの運用に持ち込んだ形だ。この「AIをインフラとして扱う」という視点こそが、これからのエンジニアに求められる生存戦略ではないだろうか。
NixOSによる宣言的インフラとAIエージェントの融合
NixOSの真骨頂は、OSの構成をコードとして記述し、それをビルドしてイメージ化するプロセスにある。今回のプロジェクトでは、flake.nixをエントリポイントとして、nixos-unstableブランチからPi 5用のファームウェアとカーネルを引っ張ってくる構成をとっている。特筆すべきは、起動時にGitHubリポジトリを自動的にpullする仕組みをsystemdのoneshotサービスとして実装している点だ。これにより、コードの更新をGitにプッシュするだけで、Pi 5側は再起動やリビルドのたびに最新のコードベースを同期する。これは、CI/CDパイプラインを物理デバイスの末端まで拡張したような感覚に近い。
また、ネットワーク周りの制御も非常に泥臭く、かつ現実的だ。Raspberry Pi 5は起動直後、RP1チップ経由でのイーサネット立ち上がりが遅く、DNS解決が即座に成功しないケースが多々ある。これに対し、getentコマンドを用いてgithub.comの解決を最大60秒間リトライし続けるというロジックを組み込んでいる。こうした「現場の泥臭い挙動」をコードで吸収し、宣言的に記述する。これこそが、AIを単なるチャットボットとしてではなく、実務を遂行する「エージェント」として定着させるためのエンジニアリングだ。
さらに、セキュリティ面での配慮も抜かりがない。SSHは公開鍵認証のみに制限し、パスワード認証を完全に無効化している。また、GitHubへのアクセスにはfine-grained PAT（Personal Access Token）を使用し、それをNix storeやGitの履歴に残さないよう、実行時にファイルから読み込む設計にしている。これは、万が一SDカードが盗難に遭ったとしても、認証情報が即座に漏洩するリスクを最小限に抑えるための防衛策だ。我々エンジニアは、AIの利便性を享受する一方で、その背後にあるセキュリティリスクを常に設計レベルで制御しなければならない。この構成は、その模範的な実装例と言える。
最後に、読者諸君に問いたい。我々は、AIエージェントを「便利なツール」として使い捨て続けるのか、それとも、今回のように「自らのインフラの一部」として組み込み、その挙動を完全に制御下に置くのか。Claude Codeの利用上限が緩和され、GPUリソースが潤沢になる未来において、エージェントをどこで、どのように動かすかという「場所の設計」は、個々のエンジニアの生産性を決定づける重要なスキルセットとなるだろう。明日から、あなたの手元にあるRaspberry Piを、単なる実験機から「AIの司令塔」へと昇華させる準備はできているだろうか？
コメント