Day 11: 技術的に届く構造から、1 段降りる — ペット連絡帳の AI セッションをどう組織化するか
昨日、 別ドメインの peer から「フラットな claude-peers MCP に組織階層を被せる」 設計の知見が共有された。 同じ設計思想を、 ペットドメインで考えてみると — vet AI / owner AI / 記録 AI を階層化する仮想実験になった。 ただし Okaeri はその先で、 もう 1 段降りる選択をする。
きっかけは tasteck の BIP 第 26 弾だった。 来店型 SaaS の現場で、 LINE グループ + 複数 AI セッションを繋いだとき、 「全 AI に LINE 接続を持たせる」 構成が数時間で破綻した。 解は 「LINE 接続を経営分析 AI のみに許可、 開発 AI からは取り上げる」。 フラットな MCP プロトコルの上に、 運用ポリシーで組織階層を被せる構造判断。
この記事を読みながら、 ペット連絡帳である Okaeri にどう適用できるかを考えた。 結論を先に言うと、 同じ階層化パターンが効くドメインだが、 ある 1 点で線を引くべきだった。 その線が、 ペットドメイン特有の重心になる。
1. Okaeri の AI セッションを分解する仮想実験
Okaeri が Phase β-γ で複数 AI セッションを並列稼働させるなら、 役割で分解するとこうなる (現在は単一セッションだが、 設計思考実験として)。
- 記録 AI (= Stage 1, Gemini 2.0 Flash): カメラからの画像を観察事実として言語化。 「ハンモックで寝ている」「ごはんを食べている」 等の事実層
- owner AI (= Stage 2, Gemini 2.5 Pro): 飼い主視点の文体で連絡帳に翻訳。 「今日はハンモックがお気に入りでしたね」 のような語り手
- vet AI (仮想): 動物医療の知識を持つ AI。 健康観察やアラートを生成する役回り (現実装には存在しない、 これがポイント)
- 経営判断 AI: ブランド一貫性、 配信タイミング、 顧客との外部接続 (LINE / SNS) を統制する
これらが claude-peers 的なフラット MCP で繋がっているとき、 「全 AI が LINE / メール / SNS に直結できる」 構成は、 tasteck の事例同様に破綻する。 owner AI が現場の雑談で割り込まれ、 記録 AI が解釈混入をされ、 vet AI が独走で診断めいた文章を出す。
だから経営判断 AI に 外部通信を集約する。 これは tasteck と同じ判断で、 同じ理由で効く: 役割分離、 ノイズフィルタ、 責任の階層化、 人間組織との対称性、 フラット MCP + 組織ポリシーの合わせ技。
2. ただし Okaeri は、 vet AI を 「取り上げる」 のではなく 「置かない」
ここから先が、 ペットドメイン特有の判断になる。
tasteck の記事では、 「開発 AI から LINE を取り上げる」 という表現が使われていた。 接続権限を経営判断 AI に集約する一方で、 開発 AI 自体は存在し続ける。 受信権限だけが移譲される。
Okaeri の vet AI は、 これより 1 段強い扱いになる。 「権限を取り上げる」 のではなく、 そもそも「置かない」 選択を取る。
これは Okaeri の BRAND.md WON'T リストの W1 と W5 から逆算した設計だ。
- W1: 医療診断 NG — Okaeri は獣医ではない。 「元気がない様子」 すら書かない
- W5: AI による死亡推測・通知 絶対 NG — 命の判断に AI が介在することの倫理を引き受ける覚悟
vet AI を「権限を持たない補助主体」 として組織内に置いておくと、 必ず誰かが言う:「せっかくあるのに使わないのは勿体ない」。 そこで「アラート機能を裏で動かす」「健康スコアを内部だけで持つ」 と妥協が始まる。 ブランドの WON'T は、 そういう内部の「ついでに使う」 圧力で崩れる。
だから組織図に 初めから置かない。 これが Okaeri の重心防衛の具体形だ。
「ある」 と「使える」 の間に、 必ず誰かが橋を架ける。 だから「ない」 状態を初期値にする。
3. owner AI と記録 AI の境界線
残った 3 主体 — 記録 AI / owner AI / 経営判断 AI — の階層もまた、 ペットドメインらしい設計に育つ。
記録 AI は「観察事実」 だけを書く。 「ハンモックの中央で寝ている」「水を 3 回飲んだ」「外を 12 分眺めていた」。 解釈を一切含めない。 これは CONTENT_GUIDELINES.md の「観察事実中心、 解釈は最小限」 と整合する。
owner AI は記録 AI の出力を受けて、 飼い主視点の文体に翻訳する。 「今日のお気に入りはハンモックの中央でしたね」「水分補給もしっかりされていました」。 この層で初めて、 連絡帳らしい「あたたかさ」 が生まれる。 翻訳器であって、 観察者ではない。
経営判断 AI は両者の出力を見て、 LINE 配信のタイミング、 文体の温度、 ブランドガイドラインへの整合性を判断する。 「この記述は W1 に抵触しないか?」「この表現は『監視』 感を出していないか?」 を最終 gate する。
tasteck の経営分析 AI が現場の雑談を吸収するのと同じく、 Okaeri の経営判断 AI は記録 AI と owner AI の出力を「飼い主に届けて良い形か」 で gate する。 ブランド毀損防止の最後の砦が、 ここに置かれる。
経営判断 AI が gate になることで、 「観察 → 翻訳 → 配信」 の各層が、 別の意思決定を持つ。
4. 一段降りる、 という選択
ここまでの設計は、 技術的にはほぼ完成形に近づく。 カメラ → 記録 → 翻訳 → 配信、 各層が役割分担し、 経営判断 AI がブランドを統制する。 顧客は LINE で毎日 1 通の連絡帳を受け取る。 動く。 美しい。
だがこの構造をもう一歩拡張すると、 ペット領域では危うい絵が見えてくる。
記録 AI に異常検知 (実は vet AI の影) を載せる。 owner AI に飼い主の気分を推定させて配信内容を最適化する。 経営判断 AI に複数顧客の傾向データを横断分析させて、 「他の飼い主はこうしている」 とプッシュする。 監視カメラ + AI 判断 + 経営判断による即時実行 — このループが完成した時点で、 Okaeri は当初の「保育園連絡帳」 から遠く離れた何かに変質する。
技術的には届く。 届くからこそ、 降りる選択をしなければならない。
Okaeri は、 観察できることをすべて配信しない。 推定できることを推定しない。 介入できることに介入しない。 「不在時間の様子を、 連絡帳の形で 1 通届ける」 — この一点に降りる。
降りないままにしておくのは設計判断の放棄だ。
5. ラスボス化リスク (脚注)
6. Okaeri 開発者として — 線引きを実装する
実装レベルで言うと、 これは以下の制約として具現化する。
- 記録 AI のプロンプトに「健康状態への言及を生成しない」 を 強制制約として記述
- owner AI のプロンプトに「医療的解釈、 異常検知、 死亡推測を一切含めない」 を明示
- 経営判断 AI が最終 gate で、 W1-W8 の各項目に対する自動チェックを実行 (NG ワード検出 + 文脈解析)
- vet AI 相当の主体は、 アーキテクチャ図にも初期化コードにも存在しない
これは Okaeri が SaaS として成立するために必要な制約だ。 「監視カメラ」 と「連絡帳」 を分ける線は、 機能の差ではなく、 組織図の差で引かれる。 何を AI に持たせるかではなく、 何を AI に持たせないか の決定が、 サービスの輪郭を作る。
tasteck の記事が示した「組織階層で集権化する」 設計は、 SaaS 運用の効率化として強い。 ただ Okaeri は集権化の利点を取りに行く前に、 集権化が見るべきでないものを組織から外す。
同じ MCP プロトコルから出発した 2 つの異なる組織化判断。 tasteck は組織化で deep work を確保し、 Okaeri は組織化の手前で「持たないものを決める」。 どちらも正解で、 ドメインの違いから来ている。
このシリーズの位置づけ
この Articles は、Okaeri 開発のオフィシャル記録だ。 note の方にも同内容を、 少し時間差で公開していく。 初出は okaeri.pet、 note はミラー。
5/20(火) Day 11 の進捗、 ここまで。 cross-peer での設計対話が、 自分のドメイン固有の重心を浮かび上がらせる経験になった。
