これはリリース告知ではない。現時点でどこまで作れているか、何が動いて何がまだ入っていないか、それを共有するための記事だ。
freeBoxの開発は現在、「Loader本体の設計完了＋サンプルプラグイン実装着手」という段階にある。実機環境（hsBox）はすでに起動済みで、動作確認も可能な状態だ。この記事では、その現在地をそのまま書く。
freeBox Loader、いまどこまで来ているか
Loaderとは、freeBox上でプラグインを管理するための実行基盤だ。GitHubに置いたindex.jsonを参照し、利用可能なモジュールを一覧表示・deployできるWebUIとして機能する。Apache2のリバースプロキシ経由でPythonサーバー（ポート9009）が動く構成で、設計と仕様はほぼ固まっている。
サンプルプラグインとして、ATOMCAM2（監視カメラ）を使ったキャプチャ機能の実装も進めている。「こういうプラグインが作れる」という具体例を示す位置づけだ。
完成版の話ではない。いま見えているのはLoaderのコアと、動作確認用のサンプルが1本あるという状態だ。
いま動いている範囲（できること・できないこと）
現時点で動作しているもの
設計・仕様レベルでは、以下が確定している。
Loaderコア（box_webserver.py）の動作仕様、Apache2プロキシ設定、systemdサービス定義、REST APIの全エンドポイント仕様（v1確定版）。UIのモックは複数バージョンが存在し、画面遷移・ダイアログの挙動は確認できる状態だ。
サンプルプラグインのATOMCAM2は、RTSPでフレームキャプチャしNASへ保存する処理のベース実装が存在する。内蔵スケジューラで10分間隔の定期実行を想定している。
まだ入っていない機能
現時点で意図的に実装しないと決めているものがある。
プラグインのEnable/Disable（ホットロード非対応のためv2以降）、モジュール詳細画面、Status画面、Settings画面。これらはUIモックには存在するが、v1の実装対象ではない。「モックに画面があるから動く」ではないので注意してほしい。モック上でも「この機能はv2以降で実装予定です」と明示している。
freeBoxとは何か（全体像）
目指しているもの
freeBoxは「USB起動のLive環境に、誰でも機能を追加できるプラットフォーム」を目指して作っている。
ベースとなるhsBox（Ubuntu Live＋パーシステンス機能）の上に、Loaderと各種プラグインが乗る構造だ。専門知識がなくても、GitHubで公開されているモジュールを選んでdeployするだけで機能が増える──そういう世界を作りたいというのが根っこにある。スマートホーム、エッジコンピューティング、スモールオフィスなど、用途は使う人次第で広げられる設計にしている。
Loaderの役割
Loaderは、その拡張のための「受け口」だ。GitHubのindex.jsonを参照してモジュール一覧を取得し、インストール・アンインストール・状態管理を行う。サーバー側はPythonで実装し、Apache2のリバースプロキシ経由でUIに公開する。モジュールにはpublic / restricted / privateの区分があり、管理の粒度も設計済みだ。
以下に構成図を示す。
プラグイン構造
Pluginクラスを実装した.pyファイルをplugins/フォルダに置くだけで、Loaderが自動認識して動作に組み込む。スケジューラへの登録もregister_schedule()メソッドを実装するだけでいい。シンプルに保つことを意識した設計で、サードパーティが独自プラグインを作れる余地を最初から確保している。
サンプルプラグインで見えること
現在実装中のATOMCAM2プラグインは、「こういうプラグインが書ける」という参照実装の意味合いが強い。
処理の中身はシンプルだ。ARPテーブルからカメラのIPを動的に解決し、RTSPでffmpegを使って1フレームをキャプチャ、NASの指定パスに保存する。10分間隔での定期実行は、Loader内蔵のスケジューラに登録して動かす。NASが未接続の状態でもLoaderは止まらず、保存処理だけスキップする縮退動作も設計済みだ。
「カメラ映像をどう扱うか」という具体的なユースケースが一本あることで、プラグイン構造の実用イメージが伝わりやすくなると考えている。ATOMCAMを持っていない人でも、「こういう形で拡張できるんだ」という参考になるはずだ。
以下に処理フロー図を示す。
Claude Codeでどう開発しているか
分割実装の進め方
この開発はClaude Codeを中心に進めている。当初は構想をもとに一気に作り上げる方向で進めていたが、進捗に伴い想定以上に複雑化しこのままではバグ収束しそうにないので、慣れ親しんだV型開発に立ち戻った。工程見直しまでに作成した仕様書と実装をもとに「Step分割」で進行管理しており、現在はStep1（認識合わせ：基本仕様書）→Step2（設計・機能仕様書など策定）が完了し、Step3（実装・コーディング）に入るフェーズだ。
各ステップで成果物ドキュメントを作り、次のステップの入力として渡す形を取っている。設計書・API仕様・UIモック仕様をそれぞれ独立したドキュメントとして整理し、「この仕様書を元に実装してください」という形でClaude Codeに渡す想定だ。
やってみて見えたこと
設計フェーズでは、Claude Codeとのやり取りの中でAPI仕様の矛盾や未定義エンドポイントが複数浮き上がってきた。「モックに画面があるのにAPIが定義されていない」という不整合を、実装前に発見できたのは助かった。
一方で、複数ドキュメントをまたぐ整合の判断は人間側がやる必要がある。「どの設計書が正しいか」の判断はAIには委ねられない。Claude Codeは実装の速度を上げるツールだが、設計の意思決定はあくまで自分たちで行っている。本開発は数KL規模の開発に過ぎないが、過去の数ML規模の開発での苦労を思い出すこととなった。AI活用での開発では、効率的な開発ルールの順守が人間での開発以上に重要なのだろう。
触れるもの（UIモックあり）
現時点でUIの動作確認ができるHTMLモックが複数存在する。Loaderのメイン画面、各種ダイアログ（public/restricted/privateそれぞれのインストール確認）、ステータス表示など、画面遷移のパターンは一通り作ってある。モックなのでAPIとはつながっていないが、「どういう操作感になるか」は触って確認できる。
UIモックを触ってみる（Module Manager v2.8）
実装前にUIを固めておくことで、「作ってみたら使いにくかった」を減らす狙いがある。
現在詰まっているポイント
正直に書いておく。
実機環境はすでに立ち上がっており、hsBox上での動作確認も可能な状態にある。機材の問題ではない。
現在のボトルネックは、実装の整合性調整にある。設計・仕様フェーズで複数のドキュメントを積み上げてきた分、「どこを正とするか」の判断が実装フェーズに持ち越されている部分がある。APIの定義、モックの挙動、設計書の記述──それぞれが微妙にずれているところを、一つひとつ潰しながら進めている段階だ。
一気に書き上げるより、精度を確認しながら進めることを選んでいる。スピードより整合性を優先している、というのが現在の進め方だ。Step3（コーディング）の着手は済んでいる。「設計は終わった、書きながら検証する」という段階にある。
これからの進め方（ロードマップ）
まずLoaderコア（box_webserver.py）の実装を完成させ、ATOMCAM2プラグインとセットでベース部分を公開する。その後、サードパーティ向けのプラグイン開発ドキュメントを整備し、外部の開発者が独自プラグインを作れる環境を用意する予定だ。
v2以降では、現在スコープ外としているEnable/Disable機能やモジュール詳細画面なども順次追加していく。完成してから公開するのではなく、現在の状態を共有しながら作っていくスタイルで進めている。
詳細はGitHubで確認できる（近日整備予定）：github.com/hoscm/freebox
一緒に作れる人を探しています
プラグインを作ってみたい開発者、または連携の可能性を探りたい事業者と話したいと思っている。
カメラ・センサー・スマートホームデバイスのメーカーや開発者、あるいはfreeBoxの拡張先として面白そうなユースケースを持っている人。現時点でできることは限られているが、プラグイン構造の仕様は固まっているので、「こういうプラグインは作れそうか」という技術的な会話はできる状態だ。
まずはモックを触って意見をもらえるだけでもいい。完成を待たずに関わってもらえる形を探している。
UIモックを触ってみる ／ GitHub（hoscm/freebox）
