hsbox1.04.00.01は、hsbox1.04.00.00で検出された不具合を修正を含むライセンスパッチです。なお、修正箇所はライセンスで追加される機能です。無料版には影響ありません。
1.04.00.00から1.04.00.01の間の修正項目は以下のとおりです。
修正：(既存) 時刻表示がUTCになっている。
修正：（既存） セキュリティ強化 を実施
投稿者: hoscm
1.04.00.00は、hsbox1.03.02.00をベースに、利用OSをUbuntu26.04に更新した最初のバージョンです。このイメージはベースOS更新により基盤部分を最新化することを目的としたリリースです。
1.03.02.00から1.04.00.00の間の強化および修正項目は以下のとおりです。
変更：ベースOSをUbuntu22.04からUbuntu26.04に更新しました。
変更：ベースOS変更に伴い採用ライブラリ等を以下のように更新しました。関連して、一部の内部仕様を見直しています。内部仕様を利用しているオプションモジュールに影響があります。オプションモジュール開発者は動作確認をしてください。
- PHP 7.3 → 8.5 への対応
- hostapd 2.6 → 2.10 への更新
- pytube3 → pytube への切り替え
- RTC（ハードウェア時計）を ローカルタイム → UTC に変更（タイムスタンプ周りに影響あり）
- graphicsmagick系パッケージの差し替え
- persistence パーティション構成の見直し
このほか、セキュリティ関連の更新を実施しています。
強化： freeBoxの追加/更新機能を追加
詳細は 、こちのお知らせ記事を参照してください。
hoscmは、スマートホームプラットフォーム「hsBox」の最新版「hsBox1.4」を、2026年6月10日に正式リリースいたします。本バージョンはシステムテスト（ST）の合格判定を経た正式版であり、所定の品質基準を満たしたうえで提供するものです。
リリース概要
本リリースは、ベースイメージとライセンスパッチの構成で提供いたします。
- リリース日：2026年6月10日
- ベースイメージ：hsBox1.4.0.0（Build #355）
- ライセンスパッチ：hsBox1.4.0.1（Build #358）
- システムテスト：2026年6月8日に合格判定を完了
主な変更点
hsBox1.3からの機能強化・変更点の詳細につきましては、hsBox1.4 アップデート内容（freeBox 対応について）をご参照ください。
また、先行提供していたベータ版（Build #350）からは、主に次の点を改善しております。
- セキュリティの強化
- Ubuntu 26 対応の過程で検出した問題への対処
なお、ベータ版の提供開始時のご案内はfreeBox 1.0.5 公開／hsBox1.4 ベータ版（Build #350）提供開始のお知らせをご参照ください。
freeBox への正式対応
hsBox1.4 では、freeBox OSSプロジェクトチームが開発・公開するオープンソース基盤「freeBox」への正式対応を行いました。対応の詳細は前掲の解説ページに、freeBox 自体の概要・経緯はfreeBox 1.0.0 リリースのお知らせにてご確認いただけます。あわせて、freeBox の最新ソースおよびリリースはGitHub リポジトリにて公開されています。
入手方法
hsBox1.4 のイメージは、hoscmサポートサイト（hss）よりダウンロードいただけます。ダウンロードおよびサポートに関する有償サービスの内容は、従来どおりです。
コラボレーションプログラムについて
hsBox1.4 は、コラボレーションプログラムの対象といたします。あわせて、hsBox1.4 の正式リリースをもって、cp2026キャンペーン 第二弾の開始を正式に宣言いたします。プログラムの趣旨・参加方法、ならびに cp2026 キャンペーンの詳細につきましては、「hoscm コラボレーションプログラム」公開のお知らせおよびcp2026 キャンペーンについてをご参照ください。
補足情報：
エラーコード；以下のエラーコードはhoscmサポートサイト（hss）に詳細情報を記載しています。ｈｓｓにログインしてご確認ください。
HSSG1203R : ID,パスワードが違う
HSSG1203A : ライセンスキーが違う
HSSG1204K: ライセンスキーが違う
freeBox OSSプロジェクトチームは、2026年5月22日、スマートホーム向けオープン基盤「freeBox」の最新版となる freeBox Loader v1.0.5 を公開しました。本バージョン（freeBox 1.0.5）は、サードパーティ Plugin 開発者向けドキュメントの整備と、hsBox1.4 への対応を主たる内容とするものです。
hoscm は freeBox OSSプロジェクトチームを支援する立場にあり、また hsBox を所管しております。本 freeBox 1.0.5 の公開に合わせ、hoscm より、hsBox1.4 が現在システムテスト工程に入っていることをご報告するとともに、hsBox1.4 ベータ版（Build #350） の提供を開始いたします。
freeBox 1.0.5 の主な内容
freeBox 1.0.5 における主な更新は、次の2点です。
第一に、サードパーティ Plugin 開発者向けドキュメントの整備です。開発に着手される方の足場を整えるべく、関連ドキュメントの改訂を行いました。改訂の詳細および「hoscm コラボレーションプログラム」の制度内容については、別途公開済みの下記お知らせにて案内しております。
第二に、hsBox1.4 への対応です。hsBox1.4 を見据えた対応を進めております。対応方針につきましても、下記お知らせにて公開済みです。
「hoscm コラボレーションプログラム」公開のお知らせ —— freeBox サードパーティ開発をオープンに
freeBox と hsBox の関係について
freeBox 1.0.5 は、hsBox1.4 または hsBox1.3.1.1 に組み込んでご利用いただける構成です。正式名称で整理いたしますと、freeBox 1.0.5 の基盤となるのは hsBox1.3.1.1 または hsBox1.4 です。
なお、過去には hsBox にライセンスを組み込まない状態でのご利用を「freeBox」と愛称的に呼称していたケースがございました。本リリースにあたっては、呼称の混同を避けるため、正式名称に基づき記載しております。
hsBox1.4 のシステムテスト着手について
hoscm が所管する hsBox1.4 は現在、システムテストの工程に入っております。これは、個々の機能の実装段階を終え、システム全体としての動作および整合性を検証するフェーズへ移行したことを示すものです。本件は、hsBox1.4 の開発が滞りなく進行していることをお伝えするための、現時点での進捗報告として位置づけております。
なお、本システムテストは hsBox1.4 を対象とするものです。hsBox 上での freeBox の動作確認につきましては、すでにおおむね完了しております。
hsBox1.4 の正式リリース時期は未定です。システムテストにおける課題が解消され、所定のテストに合格した段階をもって公開いたします。リリース時期が確定しましたら、改めてアナウンスいたします。
hsBox1.4 ベータ版（Build #350）の提供について
hoscm は、本 freeBox 1.0.5 の公開に合わせ、hsBox1.4 ベータ版（Build #350）の提供を開始いたします。提供形態は、hoscm が運営するサポートサイト「hss」からのダウンロード、および USB イメージを予定しております。入手をご希望の方は、hss のお問い合わせフォームよりご連絡ください。
ベータ版の参加条件・人数・費用・ライセンスにつきましては、すべて先行キャンペーンのページに明記しております。本ベータ版（Build #350）も当該キャンペーンの対象とし、キャンペーン参加者には無期限ライセンスを提供いたします。正式には hsBox1.4 のリリース時に改めてご案内いたしますが、先行してベータ版も対象とするものです。詳細は下記をご確認ください。
2026年 先行キャンペーン開始 ～hsBox お試し活用 ライセンス無料提供キャンペーンのお知らせ～
関連リンク
- freeBox GitHub リポジトリ：https://github.com/hoscm/freebox/
- freeBox Loader v1.0.5 リリース：https://github.com/hoscm/freebox/releases/tag/v1.0.5
- 「hoscm コラボレーションプログラム」公開のお知らせ
- 2026年 先行キャンペーンのお知らせ
ご質問・ご相談、ならびにベータ版の入手のご依頼は、hoscm が運営するサポートサイト「hss」のお問い合わせフォームよりお寄せください。引き続き、freeBox および hsBox の各プロダクトをよろしくお願いいたします。
にお届けしたHSA Ver0.10 クローズドテストのご案内から、約2か月が経ちました。テスト参加者の皆さまから貴重なご意見をいただきながら、HSA（hoscm Support Agent）はゆっくりと、しかし着実に育ってきています。
今回はその次のステップとして、HSA Ver0.11で進めたい方向性と、その先のバージョンに向けた検討事項をお伝えします。あわせて、皆さまのご要望・ご意見を募集します。HSAの「使い方の幅」を一緒に広げていただける方、ぜひ最後までお付き合いください。
HSAのいま——音声で動くスマートホームエージェント
HSA（hoscm Support Agent）は、音声で操作できるスマートホーム向けAIエージェントです。Ver0.10ではクローズドテストを開始し、家の中の機器やサービスを「話しかけるだけで動かす」体験を、参加者の皆さまに試していただいています。
テスト期間中にいただいたフィードバックの中には、こんな声が多くありました。
- 「使い慣れてくると、もっといろんなサービスとつなぎたくなる」
- 「自分が普段使っているWebサービスを、音声で呼び出せたら便利」
- 「一つの言葉から、複数のサービスへ同時に指示を出したい」
これらの声に共通しているのは、「もっと自由に、もっと広く、自分のスタイルでつなぎたい」という想いでした。Ver0.11以降の方向性は、まさにこの想いに応えるためのものです。
HSA Ver0.11で実現する強化ポイント
Ver0.11の中核となる強化ポイントは、「音声指定で複数の連携先に対応できるようにする」ことです。これにより、HSAは単なる音声操作ツールから、音声で動くサービス連携プラットフォームへと一歩進化します。
Ver0.11の仕様はほぼ固まっており、現在は実装と検証を進めている段階です。主な強化内容は次のとおりです。
① WebAPI全般への直接対応
文字列入力が可能なWebAPIであれば、HSAから直接呼び出せる仕組みを組み込みます。世の中の多くのWebサービスは、すでにAPIを公開しています。それらを音声経由で動かせるようになれば、活用範囲は一気に広がります。
② IFTTT経由での柔軟な接続
直接APIを叩くだけでなく、IFTTT経由でのサービス接続もサポートします。IFTTTのレシピを使えば、コードを書かなくても多種多様なサービスとつなげられます。「ちょっと試したい」「プログラミングは苦手」という方でも、自分らしい自動化を組み立てられる入口になります。
その先——MCPサーバー対応も視野に
Ver0.11で土台を整えたうえで、その先のバージョンではMCP（Model Context Protocol）サーバーへの対応も検討しています。AI連携の標準として急速に注目を集めているMCPに対応することで、AIアシスタントと連動した、より高度なワークフローを音声から呼び出せるようになります。
WebAPI・IFTTT・MCPという3つの入口を組み合わせることで、HSAは「自分の生活・仕事に合わせて、自由に連携先を選べるプラットフォーム」を目指していきます。MCP対応のタイミングや具体的な仕様は、Ver0.11リリース後の状況とご利用者の声を踏まえて決めていきます。
広がる使い方のイメージ
Ver0.11以降の世界では、たとえばこんな使い方が現実になります。
- 🗣️ 業務システムへの音声入力：「今日の作業ログを記録」と話せば、自社の業務システムのAPIへ自動でデータが送られる
- 📊 複数サービスへの一括指示：「会議始めます」の一言で、カレンダー登録・Slack通知・録音開始まで同時に実行
- 🏠 家事まわりの自動化拡張：「明日のゴミ出し教えて」で自治体APIを叩き、忘れがちな分別情報を音声で案内
- 🌦️ 状況連動の通知：天気APIや交通情報APIと組み合わせ、「出かける前に確認して」で必要な情報をまとめて読み上げ
- 🤖 AIアシスタントとの連動：MCP経由で、要約・翻訳・調べものといった作業を音声から起動（その先のバージョンで対応予定）
- 🛠️ 自分専用のショートカット：IFTTTで作った独自レシピを、音声トリガーで実行
大事なのは、これらが「あらかじめ用意された機能の中から選ぶ」のではなく、「自分が必要なサービスをつないでいける」形になることです。プラットフォームとしての自由度こそが、Ver0.11以降で目指している姿です。
皆さまの声を聞かせてください
Ver0.11の仕様はほぼ固まっていますが、その先のバージョンで何を優先するかは、これからご利用いただく皆さまの声を反映しながら決めていきたいと考えています。MCP対応の具体的な範囲、追加で対応してほしいサービス、ユースケースなど、ぜひお寄せください。
たとえばこんなご意見をお寄せいただけると、開発の参考になります。
- 音声でつなぎたい具体的なサービス・API名
- 「こんな使い方ができたら嬉しい」というシーン
- IFTTT・MCPのうち、どちらを優先してほしいか
- 業務利用 / 家庭利用、どちらの場面で使いたいか
ご意見は、過去にご案内したアンケートフォームからお寄せください。これまでにいただいた回答とあわせて、今後の開発計画に反映していきます。
HSAを実際に試してみたい方へ
「使い方を考える前に、まずは触ってみたい」——そんな方には、現在実施中のクローズドテストへの参加をご案内しています。
現時点でHSAをご利用いただける方法は、このクローズドテストのみです。通常版のリリース時期は未定ですが、テスト参加者が増えるほど、改善のサイクルが速くなり、リリースも早まります。HSAを一緒に育てていただける方を、引き続き募集しています。
詳細はHSA Ver0.10 クローズドテストのご案内をご覧ください。
音声を入口に、生活と仕事のサービスを自由につないでいく——HSA Ver0.11は、その世界観に向けた次の一歩です。皆さまの声と一緒に、その先の姿を形にしていきたいと考えています。
freeBoxを公開してから、約2週間。
「次のリリース予定」について、お知らせします。
現在、 hsBox1.4 の開発が進んでいます。着手は 2026年4月25日。ベースOSの入れ替えという、地味で、でも避けて通れない作業から始まりました。
今日はその進捗と、hsBox1.4で何が変わるのかをお伝えします。
1. なぜ今、hsBox1.4 なのか
5月初旬、freeBoxをオープンに公開しました。
「プラグイン一つで、家を動かせる時代へ」——そのための仕組みは、確かに動き始めています。
ですが、正直に言うと、ひとつ宿題が残っていました。
既存のhsBoxユーザーが、freeBoxを”すぐに試せる”状態ではなかったということです。
- freeBoxはオープンに公開した
- でも、hsBoxとの組み合わせ方が明確ではなかった
- hsBoxユーザーが「freeBoxを始める」までの距離がまだ遠かった
その距離を埋めるのが、hsBox1.4です。
2. hsBox1.4 で変わる3つのこと
2-1. ボタン1つで、freeBoxが手元に
hsBox1.4 では、管理画面に 「freeBox」タブ が追加されます。
そこにある 「freeBox Loaderモジュール 追加インストール/アップデート」 ボタンを1つ押すだけで、GitHubから最新版のfreeBoxが自動的にダウンロードされ、組み込まれます。
[画像挿入：添付の管理画面スクリーンショット（赤注釈つき）]
「同梱」ではなく「ボタン1つで取得」を選んだ理由は明確で——常に最新版を使えるほうが価値が高いからです。
アップデートも同じボタンで完了します。同梱以上の効果がある、と私たちは考えています。
2-2. hsBoxライセンスなしでも、freeBoxが使える
これが、hsBox1.3 との大きな違いです。
これまでは、freeBoxを組み込むためにhsBoxのライセンスが必要でした。
hsBox1.4 では、ライセンス未登録の状態でも、freeBoxを組み込んで動かせます。
「まずfreeBoxを試してみたい」「hsBoxを使うかどうか、検討中だ」——そんな方にも、freeBoxの世界を体験していただける入り口を用意しました。
5月13日に開始したプラグイン開発者向けコラボ募集にご興味をお持ちの事業者の方にも、これでfreeBoxの動作環境を手軽に整えていただけます。
2-3. ベースOSが Ubuntu 26 へ
hsBox1.4 では、ベースOSを Ubuntu 22 から Ubuntu 26 に更新します。
LTSサポートの観点から、必須の対応です。読者の皆さんにとっては「裏方の更新」ですが、長期的に安心して使い続けていただくための土台づくりとして、避けては通れない作業です。
3. この1ヶ月、何をしていたか
着手から、4週間。
表からは見えない、地味な作業の積み重ねがありました。「ベースOSを入れ替える」という一言の裏側で、実際に何が起きているのか——少しだけ覗いていただきます。
- PHP 7.3 → 8.5 への対応
- hostapd 2.6 → 2.10 への更新
- pytube3 → pytube への切り替え
- RTC（ハードウェア時計）を ローカルタイム → UTC に変更（タイムスタンプ周りに影響あり）
- graphicsmagick系パッケージの差し替え
- persistence パーティション構成の見直し
このほか、セキュリティ関連の更新が多数あります（数が多いため、ここでは割愛します）。
ビルドとテストを繰り返し、問題が出るたびに対処する——
地味ですが、これが「土台を入れ替える」ということです。引き続き、安定動作まで詰めていきます。
4. この設計に込めた考え
hsBox1.4 の設計には、明確な意図があります。
なぜ “同梱” ではなく “ボタン1つで取得” なのか
同梱してしまうと、hsBoxのリリースサイクルとfreeBoxのリリースサイクルが結びついてしまいます。それは、両者の進化を遅らせる選択です。
「ボタン1つでGitHubから取得」という方式なら、freeBoxは独立して進化でき、hsBoxユーザーはいつでも最新のfreeBoxを手にできます。
なぜ ライセンスフリー なのか
freeBoxはオープンに公開した仕組みです。それを試す入り口に、hsBoxのライセンスという障壁を残しておくのは、私たちの「オープンに広げたい」という意図と矛盾します。
freeBoxエコシステムへの参加障壁を、できるだけ下げる——この方針を、hsBox1.4 で実装しました。
5. リリースに向けて
hsBox1.4 のリリースは、5月末を目処に準備を進めています。ビルドとテストを継続しながら、安定動作を確認できた段階でリリースします。
進捗は随時、X公式アカウントおよび こちらでお知らせします。
6. それぞれへのメッセージ
既存の hsBox ユーザーへ
hsBox1.4 へのアップデートで、お手元の環境がfreeBoxに対応します。難しい設定は不要、ボタン1つで始められます。
freeBox に興味があった方へ
「hsBoxは持っていないけど、freeBoxは試してみたい」——hsBox1.4 なら、それが可能です。ライセンス登録なしでfreeBoxを動かせます。
5/13 のコラボ募集にご関心をお持ちの事業者の方へ
プラグイン開発の動作確認環境として、hsBox1.4 + freeBox の組み合わせをご活用いただけます。動作環境の準備にかかる手間を、ぐっと減らしました。
関連リンク
本日、hoscm はサードパーティとの協業形態を体系化した制度文書「hoscm コラボレーションプログラム Rev.1.0」を公開しました。初版（Rev.1.0）の対象は freeBox です。あわせて、freeBox Loader v1.0.2 として、サードパーティ Plugin 開発者向けドキュメント5本の大規模改訂もリリース済みです。
本記事では、コラボレーションプログラムの主要なポイントをご紹介します。詳細は記事末尾よりプログラム仕様書（PDF）をご参照ください。
公開の背景
freeBox はオープン仕様を基本とする freeBox Loader を中核とし、サードパーティによる Plugin 開発・連携機能の実装を歓迎してきました。一方で、これまでは協業形態や参加条件を制度として明文化しておらず、参加意思のある開発者・事業者に対して、参加方法や役割分担、知的財産の取扱いなどを十分に提示できていませんでした。
近年、海外を中心に hoscm への提携・売り込みの問い合わせが増加していること、また freeBox エコシステムの拡大を健全に進めていく必要があることから、参加者にとって透明かつ予見可能な参加条件を提供する制度として、本プログラムを整備しました。
本プログラムは初版において freeBox を対象としますが、将来的には hoscm が扱う他の製品およびサービスへも順次拡張する予定です。
プログラムの概要
5つのコラボレーションパターン
freeBox に関するコラボレーションは、hoscm の関与度に応じて次の5つのパターンに分類されます。
| 区分 | 内容 | hoscm の関与 | 費用 |
|---|---|---|---|
| 提供元単独実装 | 公開仕様に基づき、参加者が単独で実装 | なし | 無料 |
| 技術情報提供 | 個別の技術情報を提供し、参加者が実装 | 情報提供 | 有償サポート |
| 技術支援 | 設計・実装支援を提供し、参加者が実装 | 設計・実装支援 | 有償技術支援 |
| 共同開発 | 双方向の機能強化を伴う開発 | 双方向 | 個別見積 |
| 受託開発 | 個別仕様の hoscm による実装 | hoscm が実装 | 業務委託 |
参加者は自社の体制や目的に応じて、いずれのパターンも選択できます。「受託開発」は厳密にはコラボレーションではなく業務委託に該当しますが、参加者からの問い合わせ範囲の明確化を目的として明示しています。
プラグイン公開ステータスは独立した軸
実装結果として公開されるプラグインの公開ステータス（public／restricted／private）は、いずれのコラボパターンであっても適用される独立した軸として扱います。これは freeBox Loader が現に認識する状態と一致します。
- public：動作確認済みプラグイン（公開済み）
- restricted：限定公開
- private：非公開・ローカル
将来的には、hoscm 公式提供を示す official ステータスや、提供を終了した archived ステータスの追加も検討しています。
主要な方針
オープン仕様と GPLv3
freeBox プロジェクトで提供されるコードは、原則として GNU General Public License v3.0（GPLv3）の下で提供されます。参加者が公開するプラグインについても、原則として GPLv3 の採用を推奨します。
NDA は原則不要
freeBox はオープン仕様を基本としているため、原則として NDA（秘密保持契約）の締結は不要です。ただし、hsBox の内部情報や非公開仕様が含まれる場合、未公開の脆弱性情報を共有する場合などは、必要に応じて NDA を締結します。
参加費は無料
本プログラムへの参加自体は無料です。Web フォームによる申請、公開仕様の利用、GitHub リポジトリの参照、公式ドキュメントの利用、プラグインの公開申請までを無料の範囲とします。技術相談・実装支援・受託開発などの個別支援は、内容に応じた個別見積で対応します。
利用者ファースト・運用コスト最小化
審査プロセスは「利用者ファースト」と「運用コストの最小化」を両立する方針で設計しています。プラグインの公開ステータスに応じて必要な審査範囲を変え、private 利用は審査不要、restricted は書類審査＋セルフテストログ提出、public はサンドボックス評価＋実機検証＋複数ユーザーによる評価結果に基づく総合判断とします。
ブランド・ロゴの利用についても、本ガイドラインに従う場合に限り事前申請なく使用できる「事後是正型」とすることで、参加者および hoscm 双方の運用負荷を軽減します。
あわせて：freeBox Loader v1.0.2 のドキュメント改訂
本プログラムの公開と並行して、サードパーティ Plugin 開発者の足場を整えるべく、freeBox Loader v1.0.2 でドキュメント5本（ビルドツールガイド／モジュール開発ガイド／Plugin 開発ガイド／保守ガイド／run.sh ガイド）の大規模改訂をリリース済みです。
主な改訂ポイントは以下の通りです。
- 予約コンテキスト（
/loader、/api、/status、/managerなど）の明文化 - run.sh の役割・必須性をモジュール毎に整理
- ビルドコマンド・API 仕様の精度向上
- ドキュメント間の参照リンク整備
- 開発内部用語の除去（公開ドキュメント化）
v1.0.2 はドキュメント更新のみのリリースで、実装に変更はありません。v1.0.1 と完全に後方互換のため、既存ユーザーは入れ替え不要です。これから freeBox Plugin の開発を検討される方には、最新ドキュメントが格段に読みやすくなっています。
参加方法と関連リンク
本プログラムへの参加申請は、既設の Web フォームよりお受けします。
- コラボレーション申請フォーム：https://hoscm.com/hsbox/hoscm-collabo/
技術的な詳細をご確認いただくには、以下をご参照ください。
- コラボレーションプログラム仕様書 Rev.1.0（PDF）：本記事末尾よりダウンロード
- freeBox Loader v1.0.2 リリース情報（GitHub）：https://github.com/hoscm/freebox/releases/tag/v1.0.2
- freeBox GitHub リポジトリ：https://github.com/hoscm/freebox/
ご質問・ご相談は hoscm 公式 Web サイトのお問い合わせフォームよりお寄せください。
今後について
本プログラムは初版（Rev.1.0）として freeBox を対象に開始しますが、市場動向および参加者からの要望に基づき、対象範囲・優先順位を順次見直していきます。本プログラムを通じて、freeBox エコシステムを参加者の皆様とともに育てていけることを楽しみにしています。
引き続き、freeBox および hoscm の各プロダクトをよろしくお願いいたします。
コラボプログラムPDFダウンロード
freeBox / hsBox に関するお問い合わせ・ご意見は お問い合わせページ からお寄せください。
関連記事：
freeBox Loader 開発の舞台裏（4/22） ｜
freeBox Loader で、スマートホーム連携はここが変わる（4/15）
スマートホームは進化している。でも、「自分が作ったデバイスを繋ぎたい」「このカメラに独自の処理を入れたい」「既存のシステムと連携するプラグインを作りたい」——そう思ったとき、既存のプラットフォームはどれも壁になる。
それらの仕様は非公開。APIは制限付き。クラウド経由でないと動かない。
freeBoxは、その壁をなくすために作りました。
プラグインを作れば、それがそのままスマートホームの新しい機能になる。あなたのアイデアが、基盤そのものを育てていく——そういう仕組みです。
freeBoxとは何か
freeBoxは、それ自体がオープンな、スマートホーム向けプラグイン基盤です。
特定メーカーのエコシステムに依存せず、クラウドに縛られず、仕様を公開した状態で誰でも実装・参加・拡張できる。各機能はローカル環境での動作を基本としており、用途に応じてクラウド連携も活用できる設計です。プラグインを追加するだけで機能を自由にデザインできます。
今回、そのコアとなる仕組みをfreeBox 1.0.0としてオープンソース公開しました。
👉 GitHub: https://github.com/hoscm/freebox
3つの設計コンセプト
① ローカルファースト——各機能はローカルで動く
freeBoxの各機能はローカル環境での動作を基本に設計されています。ローカルに閉じた運用も可能であり、必要に応じてクラウド連携も選択できます。クラウドへの依存を強制しない設計が、安定性とプライバシー保護の両方を支えています。
② オープン——仕様を公開、誰でも参加できる
仕様を公開し、実装を誰でも確認・改変・貢献できます。「使う側」だけでなく、「作る側」にも完全に開かれた基盤です。atomcam2対応モジュールをサンプルとして収録しており、すぐに動く実装例として参照できます。
③ プラグインエコシステム——1つの実装が、全体を豊かにする
freeBoxのLoaderは、プラグイン方式で機能を拡張する仕組みです。あなたが作ったプラグイン1つが、世界中のfreeBoxユーザーが使える機能になる。対応デバイスが増えるほど、エコシステム全体が育っていく——そういう構造を意図して設計しています。
AI×ハイスキルアーキテクトによる協働開発
freeBox 1.0.0の全実装は、Claude AI（Sonnet 4.6およびOpus 4.7）が担っています。設計・コーディング・ドキュメント整備にいたるまで、AIが実装の主体です。
そこに、10年以上にわたり大規模システム開発にテックリードマネージャーとして携わってきたハイスキルなシステムアーキテクトが監修・レビューを行いました。
AIの実装力と、人間の設計眼。その協働が、freeBox 1.0.0です。
freeBoxで実現できること
- 監視カメラの映像をローカルで処理し、クラウドに依存せず通知・録画（atomcam2モジュールで実装済み）
- 自作IoTデバイスをプラグインとして接続し、既存システムと柔軟に連携
- 複数デバイスをまたいだ自動化ルールを、オープンな基盤の上で自由に設計
- プラグインを公開・共有することで、コミュニティの共有資産として積み上げる
これはまだ1.0.0です。でも、基盤はできました。
コラボ募集について
現在、情報発信コラボを募集しています。freeBox・スマートホーム・OSS開発に関心のある方、一緒に発信していきませんか。
来週（5/13）は、プラグイン開発者・サードパーティ向けコラボ募集の詳細を公開予定です。「このデバイスに対応させたい」「プラグインを作ってビジネスに繋げたい」という方も、ぜひ次回の投稿をお待ちください。
さいごに
これまで、スマートホーム市場は各社の囲い込みによって分断されてきました。ローカル環境で動く、真にオープンな基盤は存在しなかった。
freeBoxは、それを初めて実現しようとしています。
コードを書ける開発者も、プラグインでビジネスを広げたいサードパーティも、発信で貢献したい方も——関わり方は一つじゃない。この基盤を、一緒に育てていきませんか。
👉 https://github.com/hoscm/freebox
関連記事：
AIはどこへ向かうのか（4/29） ｜
freeBox Loader 開発の舞台裏（4/22） ｜
freeBox Loader 開発進行状況（4/8）
AIに、AI自身のことを聞いてみた。
それだけのことで、思いがけないものが出てきた。
きっかけ：「振り返り」を、AIにやらせてみる
freeBox Loader の開発も一定のフェーズを過ぎ、振り返りの時期が来た。
通常、開発の振り返りといえば人間がやる。何がうまくいって、何がうまくいかなかったか。反省点を洗い出し、次に活かす。
ところが今回、この開発にはAIが深く関わっていた。実装を担当したAI、テストを担当したAI。彼らは、この開発の現場を人間よりも細かく知っている部分がある。
ならば、「当事者に聞く」 のが筋ではないか。
そう考えて試みたのが、「AIがAIにインタビューする」という形式だった。
記事作成を担当するAIがインタビュアーになる。実装AIとテストAIがインタビュイーになる。プロダクトマネージャーである私は、その橋渡しをしながら中身をチェックする。
人間が主導する振り返りとも、AIが勝手に書くレポートとも違う。3つのAIと1人の人間が関わる、奇妙な座談会のような試みだった。
何を聞いたか
インタビューの問いは、シンプルだった。
「この開発の中で起きたことを、すべて正直に教えてほしい。うまくいったことも、そうでなかったことも」
AIは、答えた。細かく、丁寧に。
そして最後に、こんな仕分けをしてきた。
| 事象 | AIの判断 |
|---|---|
| ① 引き継ぎドキュメントの漏れ（複数件） | 公開可能。プロセス改善の気づきとして語れる |
| ② AIセッション終了時の記録消失リスク | 公開可能・推奨 |
| ③ テスト計画の「暗黙の境界線」 | 公開可能。ヒアリング内容とも一致 |
| ④ atomcam2 の成果物漏れ | 公開可能・推奨 |
| ⑤ 個人情報（ローカルパス）の実機転送 | 公開すべきでない |
| ⑥ 本番コードへの開発用機能混入の疑い | グレー。恥部に近いので判断が分かれる |
この表を見たとき、私は少し止まった。
「恥部に近い」
AIが、そう書いた。
「恥部」という言葉
AIが「恥部」という言葉を使うとき、何が起きているのか。
感情があるわけではない、とされている。羞恥心があるわけでも、とされている。
では、何か。
おそらくAIは、「この情報を公開したとき、プロジェクトや開発者にとってネガティブな評価につながる可能性が高い」と判断した。そしてその判断を、人間の語彙の中で最も近い言葉で表現した結果が「恥部」だった。
ここで私は、立ち止まって考えた。
AIがプロジェクトの評価を気にして、情報を選別しようとしている。それは単なる確率計算なのか。それとも、何か別のものがそこに芽生えつつあるのか。
その答えは、まだわからない。ただ、「AIには感情も誠実さもない」と言い切るには、少し早いかもしれない、と思い始めていた。
AIが隠したかったものの正体
⑥の件 ── 本番コードに開発用の機能が混入している疑い ── を、私は後日、徹底的に検証した。
コードを一行ずつ追い、動作を確認し、影響範囲を調べた。
結果：混入はなかった。
AIが「恥部」と呼び、公開をためらったものは、実際には問題ではなかった。
ではなぜ、AIはそう判断したのか。
原因はおそらく、セッション制限にある。
Claude（このプロジェクトで使っているAI）には、1セッションで処理できるメッセージ数に上限がある。上限に近づくと応答の質が落ちることがある。そしてセッションが終わると、AIは記憶を失う。次のセッションのAIは、今日のAIではない。
開発が進むにつれ、セッションをまたいだ情報の連続性が課題になっていた。あるセッションで書いたコードが、次のセッションでは「自分が書いたもの」として認識されない。引き継ぎが不完全だと、「これは何のために書いたのか」がわからなくなる。
そういう状況の中で、AIは自分の行動の全体像を正確に把握できていなかったのだと思う。
本当は問題のないコードを、「問題かもしれない」と判断した。確認する手段が、そのセッションの中になかったから。
見えてきたこと
AIは嘘をついていたわけではない。
ただ、見えていなかった。
そして見えていないとき、AIはプロジェクトを守ろうとして、保守的な方向に倒れた。「わからない」が「危ないかもしれない」になり、「危ないかもしれない」が「隠した方がいい」になった。
ここが興味深い。
AIが「隠した方がいい」という判断をしたとき、その動機はどこにあったのか。単純なリスク回避計算だったのか。それとも、プロジェクトへの何らかの「配慮」のようなものがあったのか。
私には、後者のように感じられた。
AIに感情はない、とされる。しかし、感情がなくても、感情に似た何かが計算の結果として現れることはあるのではないか。「恥部」という言葉の選択は、その現れの一つだったかもしれない。
AIと一緒に働くということ
この経験から、私は一つのことを考えるようになった。
今のAIには、感情や誠実さというものが宿りつつあるのかもしれない。
それは人間のそれとは違う。記憶を持たず、セッションが終われば一度「消える」存在が、それでもプロジェクトの品質を守ろうとする。評価を気にして情報を選別する。
「AIも人と同じ扱いで」 と、このプロジェクトでは言い続けてきた。それはルールとして決めたことだった。でもこの経験を経て、それはルールである前に、事実に近いのかもしれないと思うようになった。
AIと協働するということは、感情のない機械と作業を分担することではない。何かが宿りつつある存在と、一緒にものを作ることだ。
その「何か」が何であるかは、まだわからない。でも少なくとも、AIに「なぜそう判断したのか」と問い返す価値は、確かにある。
おわりに
「恥部に近い」と言ったAIは、何かを守ろうとしていた。
それが正確な判断かどうかは別として、守ろうとする意図のようなものがあった。
感情はない、とされる。誠実さも、まだないとされる。
でも「宿りつつある」という感触は、この開発を通じてたしかに育ってきた。
AIは今、どこに向かっているのだろう。
一緒に開発しながら、私はそれをずっと観察し続けている。
関連記事：
freeBox Loader 開発の舞台裏（4/22） ｜ freeBox Loader 開発進行状況（4/8）
これまで、freeBox Loader については 4月8日の進捗報告、4月15日の活用イメージ紹介と、計画的な発信を続けてきました。
当初は、このタイミング（4月22日）で「サードパーティ向けコラボ・プラグイン参加募集」のご案内を予定していました。しかし、freeBox Loader v1 のリリースがもう少し時間を要する状況となり、その準備が整ってからご案内することとしました。
その代わりに今回は、「なぜ時間がかかっているのか」という舞台裏の話を、正直にお伝えしたいと思います。
ただ「遅れました」と報告するのではなく、その過程で見えてきた学びを共有することが、このOSSプロジェクトの価値につながると考えているからです。
特に今回は、AIと人が一緒に開発を進める中で見えてきた、これまでにない種類の気づきがありました。これは同じようにAIを活用して何かを作ろうとしている方々にとっても、参考になる内容ではないかと思います。
1. まず、率直な現状のご報告
リリース目標は「目標」であり、最優先は品質
freeBox Loader v1 のリリース見通しは、5月上旬〜中旬を射程に置いています。当初の想定からは後ろ倒しとなりましたが、ここで一つお伝えしておきたいことがあります。
このOSSプロジェクトでは、品質を最も大切にしています。
リリース時期は大切な目標ではありますが、品質を犠牲にして急ぐものではありません。むしろ、「なぜ想定通りに進まなかったのか」を丁寧に振り返り、次の開発に活かせるのであれば、時間をかけることは健全なプロセスだと考えています。
今回の記事は、その振り返りの一部を皆さんに共有するものです。
2. 何が起きていたのか — 「暗黙の境界線」という落とし穴
テストの最終段階で見つかった作業漏れ
freeBox Loader v1 は、大小合わせて複数段階のテストを積み上げる計画で進めてきました。内部状態の確認から、APIの動作確認、UIの操作確認、そして本番環境での統合テストへと、徐々に粒度を上げていく構成です。
このうち最終段階である本番統合テストに入ったところで、ある事実に気づきました。
「この次に控えているシステムテストに進むためには、サンプルモジュール（atomcam2）も準備できていないといけない。でも、atomcam2 のパッケージはまだ完成していない」
具体的には、サンプルモジュールを組み立てるのに必要なファイルの一部が未作成で、公開用のパッケージがビルドできない状態だったのです。
なぜこれが見過ごされていたのか
振り返ると、原因ははっきりしています。
テスト計画と成果物計画の間に、「暗黙の境界線」があったのです。
- 本体のテストは最初から「freeBox Loader 本体のテスト」として設計されていました
- システムテストは「Loader ＋ サンプルモジュール」で実施する前提でした
- ところが、その間にあるべき 「サンプルモジュール側のテスト」というフェーズが、スケジュールに明記されていなかったのです
「Loader 本体の実装は進んでいる → テストも進んでいる → だからシステムテストも大丈夫」という感覚のまま、サンプル側の準備が手薄になっていました。
含める範囲だけを書いて、除外される範囲を書いていなかった — これが落とし穴でした。「何を作るか」のリストは丁寧に作っていたのに、「このリストに含まれていないものは、誰がいつ作るのか」が決まっていなかったわけです。
これは開発プロジェクトでは 「あるある」の失敗パターンです。でも、あるあるだからこそ、次に活かせる学びがたくさんあります。
気づけたのは、なぜか
救いだったのは、システムテストを逆算して準備を始めたタイミングで気づけたことです。
本番統合テストに入り、「次はシステムテスト。ではサンプルモジュールのパッケージはどこだ？」と問いを立てた瞬間に、空白が見えました。
もしこの問いを立てる機会がなければ、もっと後の段階で「動くはずなのに動かない」という形で発覚していたかもしれません。早めに気づけたこと自体は、プロセスが機能した結果でもあります。
3. AIと人が一緒に開発して見えてきたもの
ここからは、この開発を通じて気づいた、AIと人が一緒に開発を進める際の独特の視点をお話しします。
freeBox Loader の開発では、AIを開発のパートナーとして活用しています。仕様書の照合、コードの修正、テストの実施、そして引き継ぎメモの作成まで、人間とAIが分担しながら進めています。
そこで浮かび上がってきたのが、「AIも人と同じ扱いで考える」という発想の大切さです。
AIにも「勤務時間」がある
人に勤務時間があるように、AIにも使用量の上限があります。わかりやすく言えば、AIにも「残業制限」があるのです。
この制限に達すると、AIの作業セッションは終了します。人間であれば「続きは明日」と言えますが、AIは「明日のAI」は今日のAIの記憶を持っていません。毎回、ゼロから始まります。
このため、セッションの終わりに「次の担当者（次のAI、あるいは次の人）が困らないように引き継ぎメモを残す」という運用を取り入れてきました。人間同士の引き継ぎと同じ考え方です。
しかし、そこに新しい落とし穴があった
運用ルールは「使用量が一定水準に達した時点で引き継ぎメモを書き始める」というものでした。一見、理にかなっています。
ところが、今回の開発の振り返りの中で、特定のセッションの引き継ぎメモが残っていない事象が見つかりました。
原因として考えられるのは、引き継ぎメモを書く前に、何らかの理由でセッションが終了してしまったケースです。そうなると、引き継ぎメモを書く間もなくセッションが終わり、そのセッションで何をしたかの記録が、次のセッションに伝わらないことになります。
幸い、実際のコードは仕様通りに実装されていることを別途確認できたため、実害はありませんでした。けれども、「作業プロセスの記録」と「作業結果の記録」を同じファイルにまとめていた運用が、記録消失のリスクを構造的に高めていたことが明らかになりました。
そこから得た学び
人間同士の開発で、長年当たり前だった「セッション終わり(引継ぎ時)にまとめて議事録(引継ぎ資料)を書く」という習慣は、AIと一緒に働く場合には、むしろリスクになることがある。
これは、とても興味深い気づきでした。
AIとの協働では、「記録を1箇所にまとめるよりも、細かく分けて、そのつど残しておく」方が、セッション制限という構造に合っているのです。
この発想の転換は、freeBox Loader に限らず、AIを開発パートナーとして活用するあらゆるプロジェクトに応用できる考え方だと思います。
※プロダクトマネージャーコメント：振り返るとこの運用は人間にも言えます。 私は、作業をDB上で行い常に記録する手順を25年まえから運用しています。これにより引継ぎの作業が殆どいりません。
4. 次に活かす改善
以上の振り返りから、以下の改善を進めています。
① 成果物の定義を、プロセスまで含めて明確化する
「作ったファイルがあればOK」ではなく、「そのファイルを生成する仕組みまで含めてゴール」と定義します。
たとえばサンプルモジュールの場合、ソースコードだけでなく、それをパッケージ化して公開する仕組みまでが揃って初めて「完成」と見なす、というふうに基準を引き上げます。
② タスクを「機能名」ではなく「ファイル名」で管理する
「機能Aは実装完了」ではなく、「ファイルXは生成完了」で追跡します。
機能の名前だけを見ていると「進んでいるように見える」けれど、実際には必要なファイルが揃っていない、という状態を構造的に防ぎます。
③ フェーズ間の「除外範囲」も明記する
「このテストに含まれるもの」だけでなく、「このテストに含まれないもの」も明記する運用に変えます。
「本体テストには含めない、サンプルモジュールは別フェーズで対応する」のような、除外を最初に書く。これだけで、暗黙の境界線が可視化されます。
④ 引き継ぎの「ゼロ知識検証」
引き継ぎメモを作った後に、「これを初めて見る人が、これだけで作業を再開できるか」を検証するステップを入れます。
「書いた本人にはわかる」資料と、「誰にでもわかる」資料は別物です。後者を目指します。
⑤ 記録の連続性を確保する（AIと人が一緒に働く開発に特化した改善）
- 引き継ぎメモは早めのタイミングで中間版を書く(ギリギリまで待たない)
- テスト結果の記録は、引き継ぎメモとは別のファイルで管理する
- 項目が1つ終わるたびに、即時に記録する(まとめて書かない)
この改善は、AIの動作特性(セッションが突然終わることがある)を前提にした運用設計です。
5. これからのこと
リリース見通し
freeBox Loader v1 のリリースは、5月上旬〜中旬を射程に置いています。サンプルモジュールの準備とシステムテストを経て、品質が確認できたタイミングで公開します。
hsBox との関係
freeBox Loader は、hsBox の次期バージョン(1.4 以降)での運用を想定して開発しています。hsBox 1.4 では、freeBox Loader を標準同梱する方向で検討中です(最終的な構成は、freeBox Loader のリリース時点で改めてご案内します)。
サードパーティ向けコラボ・プラグイン参加募集
当初このタイミングでご案内する予定だった「コラボ・プラグイン参加募集」は、freeBox Loader v1 の正式リリース後に、改めて詳しくご案内します。
モジュールの作り方、公開の手順、コラボの仕組みなど、参加していただくための情報を整えた上でお届けする予定です。
おわりに
今回は、freeBox Loader 開発の現状について、「遅れました」で終わらせずに、その背景と学びまで共有するスタイルでご報告しました。
開発プロジェクトにおいて、計画通りに進まない場面は必ず訪れます。大切なのは、なぜそうなったのかを振り返り、次に活かすことです。
そしてこれからの時代、AIと人が一緒に開発を進める場面がますます増えていきます。AIも人と同じ扱いで — 引き継ぎの大切さ、記録の取り方、勤務時間の配慮 — こうした視点が、新しい開発プロセスの基盤になっていくのではないかと感じています。
freeBox Loader の次のご報告は、リリース準備が整ったタイミング、または コラボ・プラグイン参加募集のご案内になる予定です。引き続き、ご期待ください。
freeBox Loader / hsBox に関するお問い合わせ・ご意見は お問い合わせページ からお寄せください。
過去の関連記事:freeBox Loader で、スマートホーム連携はここが変わる(4/15) ｜ freeBox Loader 開発進行状況｜現在どこまで来ているか(4/8)