Kioku Lab

FIELD NOTE

担当が替わる。約束は残る。——追加10席の開始日は、どこに消えたか

客先は確かに言った。「10席追加で」。二か月後、見積書を作る段になって、その開始日が社内のどこにも見つからない。 メールにはなく、Chatworkは閲覧期限の向こう側。xbackup.app の営業現場で実際に起きた出来事の記録——最初の FIELD NOTE。

PUBLISHED
READING
7 min

丹下研究室は設計演習だった。実地の記録は FIELD NOTE として公開する——本稿がその最初の一本である。 舞台は、X アカウントのバックアップ SaaS を提供する xbackup.app。ここに書くのは、同チームの営業の現場で実際に起きた出来事の記録だ。顧客の社名・日付など固有の情報は伏せ、または改変してある。それ以外は、起きたとおりに書く。

今回の舞台が大学ではなく ToB 営業なのには理由がある。研究室の記憶は年単位で失われるが、営業の記憶は週単位で失われる。そして失われた瞬間に、金額と信用が直接動く。

8月下旬、期末の午後

xbackup.app の法人営業・遠藤のもとに、見積書を担当する宮内からメッセージが届く。

「遠藤さん、A社さまの追加10席、見積書つくってます。適用開始日っていつでしたっけ?来月頭?来期頭?」

遠藤は覚えている。確かに決まっていた。先方の担当者が言ったのだ——「追加の10席、お願いします。開始は——」。

開始は、いつだと言った?

遠藤の四十分

まずメールを検索する。「追加」「10席」、先方の社名。ヒットするのは見積の初版、単価の質問、関係のない CC メールの山。あの一言は、メールではなかった。

そうだ、Chatwork だ。先方とのグループチャットで、担当者がさらっと書いたのだ。「例の件、進めてください。開始は——」。遠藤は Chatwork を開き、検索し、遡る。そして気づく。

二か月前のメッセージが、見えない。

Chatwork のフリープランで閲覧できるのは、直近40日以内・最新5,000件のメッセージに限られる(2022年10月の仕様変更以降)。あの合意はおよそ二か月前。原文は、閲覧期限の向こう側にある。

これは Chatwork の欠陥ではない、と先に言っておく。メールボックスは検索性の墓場であり、無料プランのチャットには閲覧期限があり、議事録は書かれないか読まれない。総説の言葉に戻れば——これらはすべて「保管」であって「記憶」ではない。そして保管には、期限がある。

記憶がない世界の、二つの結末

記憶の運用がなければ、この時点で遠藤に残された道は二つしかなかった。

一つ。顧客に電話して聞く。「お客さまが仰った開始日を、当方で確認できなくなりまして」。先方は教えてくれるだろう。そして小さく、確実に、信用が欠ける。約束は、先方の中にはちゃんと残っているのだ。 自社の側だけが失った。

二つ。「たしか来期頭だったはず」で見積を切る。合っていれば何も起きない。間違っていれば、10席×数か月分の請求事故になる。

ここにあるのは、「約束の非対称残留」と呼ぶべき構造である。約束は双方の間で交わされ、一方の組織にだけ残る。 顧客は覚えている。こちらは探せない。営業事故の多くは、この非対称から生まれる。

記憶がある世界

ここで話は終わらなかった。xbackup.app のチームは、会話とメールから記憶を構造化するツールとして Tanka AI を使っている。

あの日——先方のメッセージが届いた日。会話から記憶の候補が抽出され(ai_extracted)、遠藤はその場で確認していた(confirmed_by_human)。以来、こういう一件が営業の記憶にある(以下は当該記録の再現であり、社名・日付・金額などの固有情報は改変してある)。

{
  "id": "mo:xb-2026-0xxx",
  "kind": "DECISION",
  "claim": "A社:現行契約に10席を追加。適用開始は下期の期初。単価は現行契約単価を適用。",
  "context": "定例で提案済み。後日、先方担当者がChatworkで正式に進行を指示。開始日を期初に揃えたのは先方の予算の都合。",
  "provenance": {
    "recorded_by": "営業・遠藤",
    "recorded_at": "2026-06-XX",
    "source": "同日の Chatwork(A社グループ)のメッセージ",
    "captured": "ai_extracted",
    "confirmed_by_human": true
  },
  "accountability": { "owner": "営業・遠藤", "steward": "営業・遠藤" },
  "validity": { "effective_from": "2026-06-XX", "review_by": "適用開始日の直前", "status": "active" },
  "visibility": "org"
}

実際には、宮内のあの質問への答えはここにあった。「A社 追加」で想起すれば、開始日・単価・なぜその開始日なのか(先方の予算都合)までが、来歴つきで出てくる。見積書は、それで終わった。

ここで大事なのは、検索が速くなった話ではない、ということだ。Chatwork の原文は、いまも閲覧期限の向こうにある。それでも構わない。 判断はあの日のうちに、来歴・確認者・見直し期限つきの記憶として確定していたからだ。

原文は消えた。判断は残っている。

保管は期限とともに消える。記憶は判断として残る。この一文のためだけに、本稿はある。

ちなみに review_by が適用開始日の直前に設定されていることにも意味がある。開始の前に「この合意はまだ有効か」を確認せよ、という仕様(v0.1)の要求だ。先方の担当が替わっているかもしれないのは、こちら側だけの話ではない。

「担当が替わる」は、人事異動の話ではない

このタイトルを掲げたとき、想定していたのは春の人事異動だった。だが書いてみて分かるのは、担当はもっと高い頻度で替わっているということだ。

商談は遠藤のものだった。見積書は宮内のものだ。請求は経理に渡り、更新はカスタマーサクセスに渡る。一つの約束が、社内で四回、担当を替える。 そのたびに文脈は口頭とメール転送で受け渡され、そのたびに少しずつ欠けていく。人事異動は年に一度だが、この工程間の引き継ぎは毎日起きている。

営業の文脈(なぜこの条件か)と、事務の正確性(いつから・いくらで・何席か)。この二つをつなぐ接点が、これまでは「遠藤さん、あれっていつでしたっけ?」という一往復だった。Memory object は、その一往復を構造で置き換える。

この記録が露出させた v0.1 の宿題

正直に二つ。

  1. 来歴の永続性。 この記憶の来歴はあの日の Chatwork メッセージを指すが、その原文はもう閲覧できない。来歴が消えた情報源を指すとき、記憶の検証可能性をどう保つか。確認時点での引用文の保全(スナップショット)を仕様に含めるべきかもしれない。
  2. 相手方の確認。 この合意は二つの組織の間のものだ。A社の側にも同じ記憶が(彼らの形式で)あるとき、二つを突き合わせる標準的な方法はまだない。組織間の記憶は、引き続きこの研究の最も遠い到達点である。

いずれも 仕様のフィードバックに合流させる。

記述した運用は公開仕様 Memory object v0.1 に基づいており、同等の機能を持つ任意の実装で再現できる。開示:本稿の舞台 xbackup.app と Tanka AI の利用は、当事者の了解のもとで記録した。

出典