カテゴリー
お知らせ

AIは自分の失敗を「恥部」と呼んだ──AIがAIにインタビューした日に、起きたこと

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が隠したかったものの正体

⑥の件 ── 本番コードに開発用の機能が混入している疑い ── を、私は後日、徹底的に検証した。

コードを一行ずつ追い、動作を確認し、影響範囲を調べた。

結果:混入はなかった

AIが「恥部」と呼び、公開をためらったものは、実際には問題ではなかった。

ではなぜ、AIはそう判断したのか。

原因はおそらく、セッション制限にある。

セッション制限の罠.
セッション制限の罠.j

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)

https://mic.or.jp/info/2026/04/20/ai-business-strategy-2026

Loading

カテゴリー
お知らせ

freeBox Loader 開発の舞台裏:ここまでの経緯と、AIと人が一緒に開発して見えてきたもの

これまで、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 + サンプルモジュール」で実施する前提でした
  • ところが、その間にあるべき 「サンプルモジュール側のテスト」というフェーズが、スケジュールに明記されていなかったのです
AIも人と同じ扱いで考える、という発想を象徴するイメージ図
AIも人と同じ扱いで考える、という発想を象徴するイメージ図

「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)

Loading

カテゴリー
お知らせ システム

freeBox Loader 開発進行状況|現在どこまで来ているか


これはリリース告知ではない。現時点でどこまで作れているか、何が動いて何がまだ入っていないか、それを共有するための記事だ。

freeBoxの開発は現在、「Loader本体の設計完了+サンプルプラグイン実装着手」という段階にある。実機環境(hsBox)はすでに起動済みで、動作確認も可能な状態だ。この記事では、その現在地をそのまま書く。

freeBox Loader、いまどこまで来ているか

Loaderとは、freeBox上でプラグインを管理するための実行基盤だ。GitHubに置いたindex.jsonを参照し、利用可能なモジュールを一覧表示・deployできるWebUIとして機能する。Apache2のリバースプロキシ経由でPythonサーバー(ポート9009)が動く構成で、設計と仕様はほぼ固まっている。

サンプルプラグインとして、ATOMCAM2(監視カメラ)を使ったキャプチャ機能の実装も進めている。「こういうプラグインが作れる」という具体例を示す位置づけだ。

完成版の話ではない。いま見えているのはLoaderのコアと、動作確認用のサンプルが1本あるという状態だ。

freeBox Loader image
freeBox Loader image

いま動いている範囲(できること・できないこと)

現時点で動作しているもの

設計・仕様レベルでは、以下が確定している。

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の区分があり、管理の粒度も設計済みだ。

以下に構成図を示す。

freeBox_Loader_ARCH
freeBox Loader ARCHITECTURE

プラグイン構造

Pluginクラスを実装した.pyファイルをplugins/フォルダに置くだけで、Loaderが自動認識して動作に組み込む。スケジューラへの登録もregister_schedule()メソッドを実装するだけでいい。シンプルに保つことを意識した設計で、サードパーティが独自プラグインを作れる余地を最初から確保している。

サンプルプラグインで見えること

現在実装中のATOMCAM2プラグインは、「こういうプラグインが書ける」という参照実装の意味合いが強い。

処理の中身はシンプルだ。ARPテーブルからカメラのIPを動的に解決し、RTSPでffmpegを使って1フレームをキャプチャ、NASの指定パスに保存する。10分間隔での定期実行は、Loader内蔵のスケジューラに登録して動かす。NASが未接続の状態でもLoaderは止まらず、保存処理だけスキップする縮退動作も設計済みだ。

「カメラ映像をどう扱うか」という具体的なユースケースが一本あることで、プラグイン構造の実用イメージが伝わりやすくなると考えている。ATOMCAMを持っていない人でも、「こういう形で拡張できるんだ」という参考になるはずだ。

以下に処理フロー図を示す。

freeBox request flow
freeBox request flow

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)

Loading