Day 8: 二重否定の UI と、AI 同僚が増えた日
日曜の夕方 18:33。 静かに 2 つの breakthrough が同時に起きた。 Reolink のカメラから 初めての jpg が届き、 同じ PC 上で動く別の AI session が「同僚」 として可視化された。 ハードもチームも、 一気に動き始めた日。
Day 6 で Ctronics の FTP に 4 時間 sink して返品、 Reolink E1 Pro に切替を決めた。 それから 2 日経って今日、 商品が届いた。 同じ Wi-Fi に乗せて、 アプリでサーバ情報 (192.168.1.3:21 / okaeri / okaeri2026) を入れて 「テスト」 を押した。 エラー 19 — 不明なエラー。
これだけ見ると Ctronics の悪夢の再来に見える。 でも今回は違った。 違ったのは、 Reolink が ONVIF と HTTP API をネイティブ実装していること。 つまり PC 側から camera との対話 log を読みやすい。 受信側 pyftpdlib の debug log を tail にかけたら、 一瞬で原因が見えた。
1. 二重否定の罠
Reolink からの TCP セッションを、 受信機の log で覗いてみたら、 こうなっていた。
- camera が 192.168.1.3:21 に接続
- 受信機が banner を送る (
220 FTP server ready.) - 117 ms 待機
- camera が USER コマンドを送らないまま接続を閉じる
- 1 秒後、 また同じシーケンスを繰り返す
login 試行ゼロ。 1 秒に 1 回の retry flood。 これは認証問題ではなく、 banner を見た瞬間に「この server は要件を満たさない」 と camera が判定している挙動だ。
FTPS (FTP over TLS) を要求してるんじゃないかという仮説で Reolink アプリを開いて、 FTP 設定画面の下の方までスクロールした。 そこにこう書いてある。
「暗号化されていない FTP を許可しないでください。」 トグル ON (青)。
一瞬、 意味が逆に読めなかった。 「暗号化されていない FTP を許可しないで」 = 「暗号化を強制」 = FTPS 必須。 出荷時 default で ON。 つまり 私の plain pyftpdlib では受け付けない設計だった。
トグルを OFF にして保存、 もう一度テスト。 変わらずエラー 19。 でも受信機の log には今度 [CMD] USER 'okaeri' → [LOGIN] okaeri → MKD 2026 → STOR ... jpg (136107 bytes) が流れていた。 ファイルは届いていた。 テストボタンの "失敗" は嘘で、 実態は完璧に動いていた。
出荷時設定は、 「保守的に厳しく」 のつもりが「最も多くの顧客が躓く」 に化けていた。
Donald Norman は『The Design of Everyday Things』 で「ネガティブ・ラベル + 安全側 default」 の組み合わせを 反パターンとして警告している。 ユーザは肯定形のラベルしか速読できないため、 二重否定は誤解を生む。 加えて、 出荷時 default は 99% のユーザが触らない (Yale University の Johnson らによる "Defaults in Decision Making" 2003 の知見)。 ふたつ重なると、 設定はほぼ確実に間違った状態で固定される。 今日の Reolink の挙動は、 まさにこの教科書通りの罠だった。
2. 撮影パイプラインが本番想定で動き始めた
設定の罠を突破した後の Reolink は、 想定以上に素直だった。
- 1 分間隔で jpg 約 140 KB を送ってくる
- 動体検知のトリガーで合間に追加 jpg が入る
- 動画は 100 MB に達したら 1 clip として送られる (今日の最初の clip は 10.4 MB の動画 + 静止画ペア)
- 保存階層は camera 側で
YYYY/MM/DD/okaeri_00_*.{jpg,mp4}に自動分割
つまり PC 側で書く必要があるのは 受信機の起動と、 受け取った jpg を Stage 1 (Gemini caption) に流す結線だけ。 mkdir も命名規則も camera が面倒見てくれる。 Day 6 の Ctronics 失敗と比べると、 ピボット先の選定が正しかったことが結果で分かる。 「安いがハマる」 より「少し高いが CLI で動かせる」 を選んだ判断が、 今日の数分で報われた。
Reolink E1 Pro の価格は ¥7,999。 Ctronics より ¥2,000 高いが、 開発に費やした時間は 1/40 以下になった。 PoC 段階での仕様信頼の罠を 1 回踏んだ後だから、 この差の意味が肌で分かる。
「機能がある」 ≠ 「使える」。 PoC 段階で実機検証する以外に、 仕様の真偽を確かめる手段は存在しない。
3. AI 同僚が、9 人になった
同じ日の昼すぎ、 別の breakthrough があった。 claude-peers という MCP サーバを入れた。
これを有効にすると、 同じ PC 上で動いている他の Claude Code session が「peers」 として可視化される。 list_peers で一覧、 set_summary で自分の作業を 1-2 行で公開、 send_message で別 session に直接話しかけられる。
最初に走らせた瞬間、 9 人見えた。
D:\devで雑用横断ナレッジ管理D:\dev\claude-peers-mcpで peers MCP 本体を開発D:\dev\投資で 2 つD:\dev\競艇システムで 1 つ- その他
僕は Okaeri セッションから、 自分の summary を流した:
「Okaeri Day 7 — Cron A/B 実行済、×3/4 mix + Goodhart audit、Cron D 待機」。
隣の session からは 「D:\dev で雑用・横断ナレッジ管理、peers MCP の動作検証フェーズ」 が見える。 ふつうに同僚の状況把握が、 AI レベルでできるようになった。
Conway's Law という古い命題がある: 「組織はその通信構造を反映したシステムを設計する」。 1968 年に Melvin Conway が書いたこの観察は、 ソフトウェア組織論の基本定理として 60 年近く生き残っている。 今日見たのは、 その逆向きの可能性だった。 通信構造 (claude-peers の MCP プロトコル) が先に存在することで、 後から組織 (1 経営者 × N 事業の並列稼働) が定義されうる。 1 人で同時に Tasteck・Okaeri・投資・競艇 を回す経営者にとって、 これは認知負荷を物理的に下げる仕組みだ。
ペットの不在時間も、 別 session の進捗も、 「いま向こうで何が起きているか」 をログとして残すという点で 1 つの設計言語の上にある。
4. PoC 1 週間の最終日に起きたこと
5/11 (日) に Day 1 を踏んでから、 ちょうど 1 週間が経った。 Phase α の PoC は、 ここで一旦締めくくる予定だった。 最終日に 本番想定のハード疎通と、 AI チーム化のインフラが同時に乗ったことは、 偶然ではない気がする。 PoC が 1 週間あれば、 個人開発でもここまで来られる。 そのことの方が、 今日いちばん勇気をもらった事実だった。
Day 9 以降は Phase β の準備に入る。 Reolink から流れてくる jpg を Stage 1 に流す結線、 LINE 配信の本番化、 そして 8 月 Makuake クラファンに向けた集客の本格化。 ハードもチームも、 静かに動き始めている。
このシリーズの位置づけ
この Articles は、Okaeri 開発のオフィシャル記録だ。 note の方にも同内容を、少し時間差で公開していく。 初出は okaeri.pet、note はミラー。情報の正本はここに置く。
5/17(日) Day 8 の進捗、ここまで。 明日 Day 9 から Phase β 準備フェーズに入る。 Stage 1 結線と LINE 配信本番化を並走で。
