新機能の発表は「買うか」ではなく「差分表」で受ける — 自前のエージェント基盤でなぞったら、欠けは2つだけだった

これは「現場ログ」— 僕ら自身のAIエージェント運用で実際にやった改善を、思想・変更・効果の3点で記録するシリーズだ。

今回は、他社の新機能発表を受け取ったときに何をしたか、の話をする。

発表を見たときの反応は、たいてい2種類しかない

新しいAI製品の発表を見たとき、僕の反応はたいてい「すごい」か「うちには関係ない」のどちらかで終わっていた。その中間、つまり「自分の環境と比べてどこが違うのか」を紙に落とすことは、少なくとも僕はやってこなかった。

今回は違うやり方を試した。発表された機能を1つずつ分解して、手元の基盤と突き合わせる差分表を作った。所要時間は30分ほどで、結論は「欠けているのは2つだけ」だった。そしてその2つは、その日のうちに実装できた。

材料: 「次のブレイクスルーはモデルではなく文脈」という主張

きっかけは Genspark の AI Workspace 6.0 の発表だ。ソフトウェアとして SecondBrain（永続記憶）、GenMail（受信箱のエージェント）、GenTeam（人とエージェントが同居するチームチャット）、AI Design（プロンプトからビジュアルを出す）、AgentBase（業務アプリを作る）の5つ、加えてハードウェアの SecondBrain Note（会話を録って記憶に同期するカードサイズの端末）が発表されている（2026年7月20日・Genspark 公式の発表ページ。同内容は Business Wire 配信の同社プレスリリースにもある）。

僕が突き合わせたのはソフトウェアの5つだけだ。ハードウェアは配線でなぞれる対象ではないので、最初から比較の外に置いた。

打ち出しのコピーが目を引いた。“AI’s next breakthrough isn’t models. It’s context.”（AIの次のブレイクスルーはモデルではない。文脈だ）——同社のXでの投稿でも、「どんなに強力なモデルでも、あなたのプロジェクト・チーム・受信箱・会議・ファイル・決定を理解していなければゼロから始まる」と説明されている。

僕はこの主張自体には強く同意する。実際、うちのエージェント運用で効いてきたのはモデルの乗り換えではなく、記憶・観測源・承認位置といった配線のほうだった。

同意したからこそ、確かめたくなった。その主張が正しいなら、文脈と配線を自分で組んできた環境には、この5機能の多くがすでにある形で存在しているはずだ。

差分表を作る

手元の基盤はこうだ。エージェントのランタイムが3つ（Claude Code・OpenClaw・OpenRyoko）、Google Workspace を叩く CLI、定期実行の cron 群、そして操作画面としての Slack。この上に、目的別のスキルとループが積み上がっている。

5機能を「名前」ではなく「入出力」で分解して、1行ずつ突き合わせた。判定はあくまで、発表文に書かれた入出力を自分の環境で満たせているかという僕の暫定判定であって、製品としての同等性の評価ではない。実物を並べて使い比べたわけではないので、「ある」の行も機能の粒度・完成度で負けている可能性は普通にある。

発表された機能	やっていること（入出力）	手元の実体	暫定判定
GenTeam	人とエージェントが同じチャンネルで会話し、共有記憶で動く	Slack に役割別のエージェントが常駐。報告も指示も承認もチャンネル上	ある
AgentBase	業務データを持つ小さな業務アプリをプロンプトから作る	スプレッドシートを正本、Slack を操作画面にした商談管理	ある
AI Design	プロンプトからスライド・ビジュアルを出す	スライド生成スキルと画像生成スキル。実運用でデッキを量産中	ある
SecondBrain	蓄積した記憶を横断で検索・参照する	記憶は貯まっているが、横断して引く入口が無い	欠け
GenMail	受信箱を読み、優先度を判断し、自分の文体で返信を書く	受信箱を毎朝読む担当が居ない	欠け

表にして分かったのは、上の3行は入出力としては満たせていて、しかも満たし方が浅くないことだった。たとえば Slack のエージェントは、単に会話に居るだけでなく、承認ボタンの向こう側と手前側が設計されている。

一方、下の2行は言い訳のしようがない空欄だった。記憶は貯めてきたのに引く道具が無い。メールは毎日届くのに読む担当が居ない。発表を見なければ、この2つの空欄に気づくのはもっと後になっていた。

欠け①: 記憶はあるのに、引く入口が無い

蓄積側は十分にあった。議事録、エージェントの記憶ファイル、週次レポート、ブックマーク、ループの成果物。数えたら Markdown だけで 3,766 ファイルあった（今日、対象ディレクトリを find で実測）。

問題は、どこに何が書いてあるかを僕自身が覚えていないことだ。「あの件、前に何か書いたよね」が毎週起きる。

僕（というかAI側）が最初に設計したのは、全文検索インデックスを持つデータベースと、それを毎晩更新する cron と、壊れたときのための破損監視だった。もっともらしい設計だ。

これを Codex にレビューさせたら、口で批評せずに手を動かしてきた。対象ファイル数とサイズを実際に数え、検索を実測した上で、「データベース・cron・破損監視・機密データの複製を維持するコストが便益を上回る。まず検索ラッパーで十分」と却下してきた。指摘は全部で29件、うち設計を作り替えるレベルのものが5件あった。

採用した結果がこれだ。データベースなし、インデックス更新なし、常に現物が正。9つの情報源を横断して引く CLI を1本置いただけで、実測1.4秒で結果が返ってくる。壊れる部品はこの構成にはほとんど無い（cronもDBも持っていないので、壊れるとしたら検索対象そのものが消えたときだ）。

欠けを埋めるのに、発表された機能と同じ構造を作る必要はない。 同じ体験が返ってくれば、実装は一番軽い形でいい。

欠け②: 受信箱を読む担当と、送信ボタンの位置

もう一つの空欄はメールだった。相手ごとの文脈も、自分の文体も、蓄積はあるのに使われていない。

朝のループを1本作った。受信箱を走査し、要返信・判断材料・通知の3つに分類し、ブリーフィングを出し、要返信のものに返信の下書きを作る。文体は過去の送信済みメールから起こしたガイドに従わせる。

初回の実走で、直近7日ぶんの170スレッドを読ませた。結果は要対応6件・下書き作成1通・スキップ164件（実行ログの1行として記録されている）。ここで面白かったのは、僕が書きかけで放置していた下書き2件を、ループが「人間の判断が要る」として正しく避けたことだ。

そしてこのループの設計で一番時間をかけたのは、分類でも文体でもなく送信ボタンをどこに置くかだった。

答えは「置かない」。下書きを作るCLIには、サブコマンドが5つ（走査・下書き作成・処理済み記録・保留一覧・整合性回復）あるだけで、送信に相当するものが存在しない。プロンプトに「送信しないでください」と書くのをやめて、経路そのものから消した。Gmail の下書き画面が、そのまま承認画面になる。

正直に書いておくと、これは技術的な強制ではない。エージェントはシェルを持っているので、その気になれば別のコマンドを叩ける。だから禁止の実効性は3層で担保している。①正典の経路を1本に絞る ②手順書に「なぜ禁止か」を添えて明示する ③作った下書きを全部ブリーフィングで人間の目に晒す。この3つが揃って初めて「送らない」が運用として立つ。

効果: 買わずに済んだ、ではない

この差分表の効果を「他社製品を買わずに済んだ」と書くのは違う。そもそも表を作った目的が購買判断ではないし、良い製品なら使えばいい。

本当の効果は3つあった。

1つ目は、自分の基盤の棚卸しが強制されたこと。何があって何が無いかを、他人の製品を物差しにして1行ずつ確認した。自己申告の棚卸しは甘くなるが、外部の機能一覧を物差しにすると空欄が正直に出る。

2つ目は、空欄が2つに絞られたこと。「うちのAI活用、まだまだですね」という漠然とした焦りは、行動に変換できない。「横断検索が無い」「受信箱を読む担当が居ない」まで解像度が上がると、その日のうちに手が動く。

3つ目は、埋めた実装が軽くなったこと。差分表があると「同じものを作る」ではなく「同じ体験を最短で出す」に発想が寄る。データベースを1個作らずに済んだのはこの効果だ。

自分の環境で試せる最小レシピ

新機能の発表を見たときに、30分でできる手順として書いておく。

1. 手元の道具を先に棚卸しする（10分）。 記憶に頼らず、実際に動いているものを機械的に列挙する。定期実行しているジョブの一覧、エージェントに持たせているスキルやツールの一覧、この2つで足りる。うちの場合は cron の一覧とスキルディレクトリの ls だ。ここを先にやるのが肝で、後回しにすると「たぶんあるはず」で表が埋まってしまう。

2. 発表された機能を「名前」ではなく「入出力」に書き換える（10分）。 製品名やブランド名のままでは比較できない。「SecondBrain」ではなく「蓄積した記憶を横断で検索して参照する」と書く。僕の場合はこの書き換えをした時点で、5つのうち3つは自分がすでに別の名前で持っていると分かった。同じ比率が出るとは限らないが、名前のまま比べているうちは持っているものにも気づけない。

3. 1機能=1行の表にして、判定を3値で入れる。 ある／欠け／要らない、の3つ。「要らない」を正直に入れられるかがこの表の質を決める。全部を埋めようとした瞬間に、これは買い物リストに変わってしまう。

4. 欠けの行だけを、その日のうちに最小実装する。 ここでの最小とは「同じ構造」ではなく「同じ体験」だ。まずデータベースを作らない、まず cron を足さない、まず状態を持たない。それで体験が足りるなら、その軽さがそのまま維持コストの差になる。足りなくなってから重くすればいい（うちは「検索対象が数百MBを超えたら」「体感で3秒を超えたら」を昇格条件として書き残した）。

この方法が効く範囲

効くのは、自分の側に一定の道具と記憶がすでに積み上がっている場合だ。棚卸ししても空欄しか出てこない段階なら、差分表を作るより、まず何か1つを毎日動かすほうが早い。

効かないのは、機能ではなく体験の質で差がつく領域だ。UI の完成度、モバイルでの手触り、社外の人を巻き込む導線あたりは、差分表の「ある」に入れても実際には同等にならない。今回で言えば、うちの Slack ベースの環境は社内では強いが、社外の人に触ってもらう入口としては弱い。

それから、これは1回きりの棚卸しではない。次の発表が出たらまた表を作る。空欄が毎回2つ以内に収まっているなら、配線の積み上げは効いていると判断していい。

まとめ

新機能の発表は、買うかどうかの判断材料としてではなく、自分の基盤の空欄を炙り出す物差しとして使うのが一番安い。今回はそれで空欄が2つ見つかり、どちらもその日のうちに、想定よりずっと軽い実装で埋まった。

「AIの次のブレイクスルーは文脈だ」という主張は正しいと思う。ただし文脈は買うものではなく、貯めたものに引く入口を付けることで初めて使えるようになる。うちで実際に必要だったのは、新しいモデルでも新しい製品でもなく、検索ラッパー1本と、送信ボタンを置かない朝のループ1本だった。