解約ボタンの前で

Substackから引っ越そう、と書いた。半分は本気だった。いや、たぶん七割くらい本気だった。

理由は単純で、AIが操縦席に座れないように見えたからだ。Obsidianの中で原稿は育っている。画像も、音声も、動画もある。メタ情報も整理してある。それなのに最後の入稿だけ、人間がブラウザの前でちまちま作業する。

これでは、せっかく作った飛行機が、最後だけ手押し車になる。

ところが、である

引っ越しを考えた直後に、Substack入稿が動いた。

Claudianが原稿を読み、タイトルを拾い、本文を貼り、YouTubeを埋め込み、Podcastをアップロードし、画像を差し込み、セクションとタグを設定した。最後に preflight script で、見出し、太字、引用、画像、音声、動画、タグ数まで機械的に検査した。

そして、最終画面の「今すぐ全員に送信」だけを、人間に残した。

笑ってしまった。別れ話を切り出したら、急に家の片付けが進んだようなものだ。

不満はアラートだった

ここで起きたのは、「Substackが悪い」という話ではなかった。もちろん不便はある。癖もある。サイドバーのサムネイルがいつまでも Loading… のまま、こちらを不安にさせる。

でも、本当の問題は別のところにあった。

AIが動く環境が、まだ揃っていなかったのだ。権限、操作面、検査器、失敗時の戻し方、そして不可逆な最後の一手を人間に残す線引き。この五つが揃った瞬間、「できない」と思っていた作業は、かなり動いた。

AIの限界だと思っていたものは、環境の限界だった。

今日のオチ

だから、引っ越し宣言は無駄ではなかった。

文句は、道具への悪口ではない。未整備の環境が鳴らしていたアラートだった。その音を無視せず、AIと一緒に配線を見直したら、飛行機は少しだけ自分で滑走路を走り始めた。

あなたが今「このAI、使えないな」と思っている場所は、本当にAIの限界だろうか。

それとも、まだ操縦席に座らせる環境が整っていないだけだろうか。

― オサケン

はみだしピア：整えば、動く

伝筆の言葉を考えていて、最初に浮かんだのは、

整えば、動く

だった。

英語なら、

Once aligned, it moves.

もう少し自然の比喩に寄せて、途中で「水・風・火」も考えた。

水は、流路が整えば流れる。
風は、通り道が整えば吹く。
火は、条件が整えば灯る。

つまり、動かすのではなく、動き出す条件を整えるということ。

ただし、五行の順番として正統な並びではない。水・風・火は、古典の型というより、今回の感覚から出てきた並びだ。書は、意味が合っているだけでは足りない。言葉が身体に自然に入るかどうかで、線がずいぶん変わる。

なので今回は、プランBとして控えに回す。

今日の一枚には、たぶんこれでいい。

整えば、動く。

English companion

Once aligned, it moves.

I was almost ready to leave Substack.

Not because I disliked writing there, but because the last mile of publishing still felt too manual. My drafts lived in Obsidian. The images, audio, metadata, and checks were already prepared. But at the final stage, I still had to sit in front of the browser and move everything by hand.

It felt like building an airplane, only to push it by hand at the very end.

Then something changed.

Once the environment was prepared — permissions, interface, checks, recovery paths, and a clear line where the human makes the final decision — the workflow started to move.

What I had thought was a limitation of AI was, in fact, a limitation of the environment around it.

That is why today’s calligraphy says:

Once aligned, it moves.

Not “make it move.”
Prepare the conditions, and movement begins.

🎧 Podcast（NotebookLM深掘り）

前号「年に一度は、アンダーサンプリングだった。」で、僕は社員80人の現場で、週に一度のスコア測定を始めたことを書きました。

「訊く」というアンケート（ポーリング）をやめ、日報や会議の文字起こしという既存のストリームから、AIが週に1点を打つ。人手を切り、観測周期を週次に引き上げました。

道具が動き始め、これで計器が揃った——そう思った瞬間、次の壁が来ました。

予想していた壁でした。でも、実際にぶつかると、思っていたよりずっと硬かった。

「このスコア、誰が見るんですか？」

今日は、僕自身が一度きれいに罠にハマり、前提を壊して作り直した「計器の出口」と「環境の配線」の話です。

白状すると、僕は最初、「社員のプライバシーに配慮する、意識の高い経営参謀」の顔をして、クソ真面目に承認ボタンを設計していました。

自分の格好つけに酔っていたわけです。

症状 —
承認ボタンを付けた瞬間、計器は死ぬ

こういう場面を、想像してみてください。

あなたのチームで、来週から「現場の言葉から、組織の状態をAIが自動でスコア化する」仕組みが導入されたとします。誰にもアンケートは配られない。回答の負荷はゼロ。

そこまではいい。

では、そのスコアを、誰が見るのか。

あなたの上司が見る、としましょう。上司は、あなたの評価を決め、給料を決める人です。

——さて、あなたは来週から、日報に何を書きますか。

「シフトの組み方、正直まだ納得いっていません」と、書きますか。

書くわけがない。僕だって「今日もチーム一丸となって前向きに業務に励みました！」って嘘八百の模範解答を書いて、裏で仲間と居酒屋で愚痴るに決まっている。

綺麗事を言うコンサルは「心理的安全性を高めれば本音が出る」とか言います。出ねえよ、と。
給料を握られている相手に、生身の本音を差し出す人間がどこにいますか。

そして、その瞬間に、このテレメトリ（遠隔測定）は死にます。

数字は毎週出力されます。きれいなダッシュボードも描ける。でも、そこに流れているのは、「評価者に見せてもいいノイズのない言葉」だけになる。測りたかった現場の生きた信号は、観測しようとした瞬間に、蒸発して消えていく。

最初の僕の誤答
—「本人の承認ボタン」

そこで、最初、僕はこう考えました。

「評価する人に見えるのが怖いなら、本人の同意を取ればいい。
AIがスコアや要約を出したら、本人が画面で確認し、『これを上司に共有していいですか？［承認］［非公開］』と選べるようにしよう。」

——ここまで設計して、画面の前で僕の手が完全に止まりました。

エンジニアなら、この時点で何が起きるか気づくはずです。

1. 「人手」が裏口から戻ってくる:
   毎週、画面を開いて承認ボタンを押させるなら、それは前号で捨てたはずの「訊く工程（ポーリング）」を別の形で復活させただけだ。

2. 「非公開」を押すコスト:
   上司が見ている前で、毎週「非公開」を押し続けられる人間はいません。「承認しない自由」がないボタンは、承認ではなく強制です。

3. 承認地獄（Approval Hell）:
   AIに仕事を任せようとして、毎ステップ「実行していいですか？」と確認ダイアログを出させるのと同じです。人間がボトルネックになり、システム全体の稼働率がゼロに張り付く。

「プライバシーへの配慮」という美しい顔をして、僕は「何かあったときに私の責任じゃありませんよ」と言いたい大人の免罪符を配ろうとしていました。

計器を殺す最悪の仕様を、自分で組み込もうとしていたのです。

根本原因 —
産業医モデルと、操縦席モデルの混同

なぜ、僕はそんな罠にハマったのか。

顔を上げて、部屋を見渡してみてください。

オフィスの隅に、防犯カメラがあります。エントランスにも、街頭にも、コンビニにも、駅のホームにもある。あなたは一度でも、同意書にサインしましたか？

コールセンターに電話をかければ、真っ先にこのアナウンスが流れます。

「この通話は、サービス品質向上のため録音させていただきます。」

同意を求めていません。告知しているだけです。それで誰も怒らない。

大企業の社内メールはコンプライアンス監査のために常時アーカイブされています。トラックやタクシーにはドライブレコーダーが回り続けている。

人間って、監視されるのは嫌いなくせに、守られていると思うと途端にガバガバになる。都合のいい生き物です（僕も含めて）。

社会は、この問題をとうの昔に乗り越えていました。

僕がやろうとしていたのは、20世紀の古い議論でした。「監視社会は悪だ」「ビッグブラザーが見ている」——あの構図で考えていたから、「個人の同意」という見当違いのブレーキを踏んでいたのです。

なぜ「心を測る」と言った途端、身構えるのか

カメラは平気なのに、組織のログや心のスコアと聞いた瞬間、なぜ人は身構えるのか。

目的を、取り違えているからです。

多くの人が「組織のメンタルや思いを測る」と聞いた時、無意識にこのモデルを思い浮かべます。

【産業医モデル（個人の治療・介入）】
「Aさん、最近ストレス値が高いですね」
「あなたのメンタルは危険水域です」
→ 個人を特定し、異常を見つけて介入する
→ 個人の評価やキャリアに直結する恐怖が生まれる（だから同意が不可欠）

産業医の先生には申し訳ないけれど、あの「最近、眠れてますか？」の質問ほど警戒する時間はありません。「めちゃくちゃ寝てます！元気です！」と、いかに爽やかに嘘をつくかのゲームになっている。

でも、僕らが作ろうとしているのは、産業医のカルテではありません。

僕らが作っているのは、航空機の操縦席（コクピット）の計器です。

【コックピットモデル（組織のフライトレコーダー）】
「第2エンジン（営業部門）の出力が、3週連続で規定値を下回っている」
「機体全体が、失速の兆候（乱気流）に入りつつある」
→ 組織の傾き（Velocity & Trend）を検知し、墜落を防ぐ
→ 個人を裁くためではなく、機体を安全に着陸させるためにある

正しいモデル —
フライトレコーダー

飛行機には、フライトレコーダー（ブラックボックス）が載っています。

• 常時、記録している（離陸から着陸まで、例外なくストリームを保持する）

• パイロットの同意は取らない（運航の前提条件として、最初から組み込まれている）

• 普段は、誰も見ない（何事もなければ、一定期間でローテーションされ消えていく）

• 異常が起きたときだけ、解析する

• そして最大の目的は——制度上の主目的は、パイロット個人を晒すことではなく、次の事故を防ぐことだ

コックピットの中で、パイロットだって「あー今日ダルいわ」とか愚痴を言っているはずです。それを全部録られている。でもパイロットが怒らないのは、墜落したときに誰がミスしたか晒すためではなく、全員が生きて帰るための計器だと知っているからです。

心の計器も、これでいい。いや、これでなければ動かない。

ここで誤解してほしくないのは、「同意を取らない」は、無断で盗み見るという意味ではないということです。

毎週、個人に「このスコアを上司に共有していいですか？」と聞く承認ボタンを置かない、という意味です。

代わりに、告知・目的限定・評価不使用・出力粒度・アクセス権・保持期限を、最初から環境側に固定して配線する。
同意を都度取って人間に判断を丸投げするのではなく、「どう使われないか」をシステムとして保証する、という話です。

ロバート・ディルツのニューロ・ロジカル・レベルで言えば、問題は「能力（Capability）」や「個人の倫理（Belief）」にあったのではありません。

最下層の「環境（Environment）」と「配線」の設計が間違っていただけだったのです。

実装 —
3つの物理ガードレールと、1つの環境宣言

モデルが「フライトレコーダー」と決まれば、エンジニアが設計すべきものは明確になります。

承認ボタンを作るのをやめました。
代わりに、レポートの出口に3つの物理ガードレールを敷き、その手前に1つの環境宣言を固定しました。

[ 環境告知 / 目的限定 / 評価不使用の宣言 ] ◀── 【第0層: インフラ前提】

       │
       ▼
[ Raw Data: 日報 / 会議録 / チャット ]
       │
       ▼ (AI Stream Processing)
[ 個人の発話・感情・文脈 ]  ◀── 【第1層: 物理遮断】経営・上司からは不可視
       │
       ▼ (Aggregation & Masking)
[ 部門別 × 週次トレンド ]  ◀── 【第2層: 粗粒度化】「傾き」のみ抽出
       │
       ▼ (Trigger Condition)
[ 経営コックピット ]        ◀── 【第3層: 異常時のみ閲覧】普段は誰も見ない

① 粒度のマスキング（Physical
Masking）

経営や管理職に上がるレポートには、「部門 ×
週のスコアの傾き」しか載せません。

「愛と信頼で本音を語り合おう」なんて朝礼で唱える暇があったら、さっさとデータベースのViewから個人IDをDROPしろ、という話です。

社長が「おい長田、これ誰が言ったんだ！」と詰め寄ってきたときに、「すみません社長、物理的にログを捨ててるので、神様でも見れません」と涼しい顔で言えるようにしておく。
これが、FDEの少し性格の悪くて、いちばん正しい仕事です。

②
アクセス頻度の非対称性（Threshold Trigger）

「常時測る」ことと、「常時監視する」ことはまったく違います。

高頻度（週次）でサンプリングするのは、前号で書いた通り「4ヶ月で相関を証明するn=84を貯めるため」です。人間が毎週ダッシュボードを眺めて部下を監視するためではない。

レポートを開くのは、「3週連続で傾きがマイナスに振れた」などの閾値（アラート）が発火した時だけ。フライトレコーダーと同じく、平時はバックグラウンドで静かに循環しているだけでいい。

③
スコープの不可逆な分離（Evaluation Quarantine）

人事評価・査定（Evaluation）には100%使わない。

これを就業規則や運用の覚書で縛るだけでなく、「評価に使った瞬間にS/N比が崩壊して計器が壊れる」というシステム特性として経営陣と合意します。
「使わないほうが、経営にとって最も精度の高い早期警戒アラートになる」——これが、経営に対するエンジニア側の外交です。

④
同意ではなく、環境への告知（Header Declaration）

コールセンターの一文と同じ宣言を、組織の環境に掲示します。

「このシステムでは、日報と会議のログから、組織の安全運航のために部門ごとの状態を継続的に記録しています。目的は経営の航路修正であり、個人評価には使用されません。出力されるのは部門単位の傾向値のみです。」

毎週の同意確認を廃止し、環境の前提（Infrastructure
Context）として固定する。
これで、答える側の認知的負荷は完全にゼロになります。

それでも残る、現場の難所
—「3人の部門」問題

ここまで設計して、すべて解決したように見えるかもしれません。
しかし、現場に降りるエンジニア（FDE）の前には、教科書通りにいかないエッジケースが必ず現れます。

それが、「3人の部門」問題です。

社員80人の会社では、レストラン部門や特定の専門チームが「3人」しかいないことがあります。

教科書の「k-匿名性」なんて、地方のゴルフ場の厨房に来た瞬間、一撃で粉砕されます。
その部門に対して「レストラン部門、3週連続でスコア下降」とアラートを出せば、「あ、これ絶対に昨日のA君のやつじゃん」って全員に一瞬でバレる（笑）。

丸めたつもりで、丸まっていないのです。

大企業のビッグデータなら母数でマスキングできます。しかし、泥臭い現場の中小企業には、その統計的な厚みがありません。

僕が現場で出した暫定解は、3つです。

1. 最小クラスタサイズの適用:
   5人未満の小規模ユニットは単独でレポート化せず、上位の親部門にロールアップ（合流）させる。

2. 絶対値を捨て、差分ベクトルのみを扱う:
   「◯点」という数値を出すと犯人探しが始まる。「下降傾向にある」というベクトルの向きだけを提示する。

3. 推定リスクが高い週は、計器を沈黙させる:
   個人が特定されるリスクが環境的に高い週は、あえて「データなし（Silence）」として処理する。

計器が沈黙する週があっていい。

嘘の数字をこねくり回して「AIによる高度な統計分析です」とか納品するコンサルより、「今週は計測不能でした！」と堂々と白旗を上げる計器のほうが、100倍信用できるからです。

そして、これはあなたの問題です

前号と今号で、僕がやってきたことを振り返ってみてください。

• 信号のアンダーサンプリングを疑い、サンプリングレートを上げた（第6号）

• 観測者効果によるデータの変質を防ぐため、ポーリングを捨ててストリームを読んだ（第6号）

• 承認地獄を回避するため、同意ボタンを捨ててフライトレコーダーの環境配線を引いた（第7号）

• データのS/N比を守るため、レポートの出力レイヤーで物理マスキングを行った（第7号）

すべて、ソフトウェアエンジニアが分散システムやインフラの監視（Observability）で日常的にやっていることです。

「組織の心がわからない」「社員の本音が上がってこない」と悩む経営者は、愛や倫理が足りないのではありません。
テレメトリ（遠隔測定）のパイプライン設計が壊れているだけなのです。

FDE（現場に降りるエンジニア）の仕事は、現場に最新のAIツールを配ることではありません。

現場という不安定でノイズまみれの環境に、安全にデータが流れ、誰も傷つかずに異常を検知できる「配線」を引くこと。

同意書を集めるのに時間を溶かすな。
承認ボタンという名の免罪符を配るな。
環境を整えろ。レポートの出口を設計しろ。

道具箱は、すでにあなたの手の中にあります。

今週の、現場での1手

あなたのチームで「形骸化している承認プロセス」または「集めているのに誰も見ていないログ」を1つ特定してください。

• それは、本当に毎回人間が「承認」を押す必要がありますか？

• それは、「産業医モデル（個人を暴く）」になっていませんか？

• 出力側の粒度を丸めて、「異常時だけトリガーするフライトレコーダー」に置き換えられませんか？

大人の免罪符を1つ外すだけで、システムの稼働率は跳ね上がります。

今日の型

P5・ポストモーテム型（前提崩壊と環境再設計）

今回は、バグの修正報告ではなく、「設計者の前提（メンタルモデル）そのものが壊れていた」という障害報告書です。

「監視は悪だから、同意を取らなければならない」という20世紀の思い込みで設計を始めた結果、承認地獄という別のバグを踏み抜きました。
モデルを産業医から「フライトレコーダー」へシフトさせ、ロバート・ディルツのニューロ・ロジカル・レベル（環境の配線）へ降りることで、初めて道具が実稼働しました。

今日の話を、1枚に

次号予告：レポートの出口は塞ぎました。では、入口の手前で、AIは何を担うべきなのか？
100年の知識創造理論（SECI）の4つの段を現場データでへし折り、残った「たった1段」の話をします。

― オサケン

🎧 Podcast

この連載は、FDE（現場に降りるエンジニア）を目指す人に向けて書いています。

今日は、そのつもりで書きます。——なぜなら、今日の話は、経営の問題ではなかったからです。

100年、経営学が解けなかった問題を、僕は先月、サンプリング周期の話として理解し直しました。そうしたら、道具が決まりました。

先に結論を書きます。

心の計器が100年定着しなかったのは、指標が悪かったからでも、経営者が鈍感だったからでもない。 観測の周期が、現象の周期に対して、粗すぎた。それだけだった。

症状 — 単一障害点が、僕だった

正直に書きます。

僕は、経営の現場で、こういうことを言います。

「根拠レスですけど、言いますね。——このままだと、あの部門、落ちます。」

勘だと先に断って、言う。データはない。グラフもない。あるのは、毎週、現場の言葉を聴き続けてきた身体の感覚だけだ。

そして——当たる。

数字が落ちる前に、必ず、誰かの言葉が先に変わる。日報の文面が短くなる。会議でいつも一言多い人が、黙る。「大丈夫です」の言い方が、変わる。

では、何が問題か。

この計器が、冗長化されていないことだ。

• 可用性がない。 僕が会議室にいるときしか鳴らない

• 移転できない。 出力が「勘です」なので、他人が再現できない

• 反論できない。 相手にできることは、信じるか信じないかの2つだけ。当たり続けるほど、計器ではなく権威になっていく

• 僕が抜けたら、計器ごと消える

単一障害点です。しかも性能が高いほど、周りが依存して、代替が育たない。

——じゃあ、数字にすればいい。

そちらにも、落とし穴があった。

数字だけを並べた会議を、僕は何度も見てきた。売上、客数、前年比。整っている。誰も間違ったことを言わない。そして、誰も、何も言わない。

きれいなグラフが映って、みんなが頷いて、「で？」——So what? で終わる。

勘には、力がある。でも、移転できない。 数字は、移転できる。でも、それだけでは、動かない。

この2つを繋ぐ計器が、うちの会社にはない。

そして——100年、どこにも無かった。

根本原因① — 同じ負のフィードバックループを、100年回していた

調べていくと、心を経営の計器にしようという試みは、100年、絶えたことがない。ホーソン実験（1920年代）、リッカートの組織風土（1960年代）、バランスト・スコアカードの「学習と成長」（1990年代）、そして国の制度まで。

みんな、僕と同じものを見ていた。そして、みんな、同じところで落ちていた。

こういうループです。

① 心を測ろうとする
   ↓
② 測るのに人手が要る（設計・配布・回収・集計・分析）
   ↓
③ だから頻度を落とす（年1回に）
   ↓
④ 判断のタイミングに合わない
   ↓
⑤ 議題から外れる
   ↓
⑥ 「人事の資産」に格下げされる
   ↓
⑦ 予算が減る
   ↓
   ③へ戻る（さらに頻度が落ちる）

負のフィードバックループです。測ろうとするほど、測れなくなる方向に力が働く。

そして——7段のうち、外から切れるのは②「人手が要る」だけです。

③以降は、全部この「人手」の帰結だからだ。「頻度を上げましょう」と言っても、人手が要るかぎり、必ず戻る。「経営会議で扱いましょう」と言っても、判断に合わない周期のままなら、必ず外れる。

律速段階は、「人手が要る」。ここを切らないループ切断は、全部、対症療法です。

100年、みんな③以降を直そうとしていた。「人手」を切った人が、いなかった。

根本原因② — なぜ「年に一度」では足りないのか、には答えがある

ここが、今日いちばん書きたかったところです。

人手を切って頻度を上げたとして、どれくらい上げれば足りるのか。——ここには、答えがあります。

「思いが動くと、数字が動く」を言うには、2つの系列の相関を、偶然でないと示す必要がある。必要な観測点は、こう決まります。

効果量 r = 0.3（中程度の相関） 有意水準 α = 0.05、検出力 1−β = 0.80 → 必要な観測点 n ≒ 84

これを「部門 × 測定回」で貯めます。5部門の会社なら、こうなる。

• 年に一度 → 約17年

• 半年に一度 → 約8年

• 週に一度 → 約4ヶ月 17年 vs 4ヶ月。

17年前のデータと今年のデータを並べても、会社も、人も、事業も、別物になっている。そもそも同じ系列とは呼べない。

年に一度は、少ないのではない。統計的には、ゼロと同じだ。

そして、ゼロより悪い

これが、この号のタイトルの意味です。

思いは、週から月のオーダーで動きます。誰かが黙る。言い方が変わる。それがまた戻る。

その現象を、年に1回サンプリングする。

信号処理をやったことがある人なら、この時点で何が起きるか分かるはずです。サンプリング周期が、現象の周期に対して粗すぎる。

このとき、速い波は拾えないのではありません。化けます。

エイリアシング。——実在しない、ゆっくりした波形が、そこにあるように見える。

年に一度のサーベイで「今年は去年より少し改善した」と読んだとき、その”改善”は、本当に改善だったのか。週単位で3回上下したうちの、たまたま上がっていた1点を、去年のたまたま下がっていた1点と比べただけかもしれない。

100年、心の計器は、無かったのではない。化けた波形のほうを、見せられていた。

そして、経営がそれを見なくなったのは——正しい判断です。

経営が鈍感だったのではない。計器のほうが、信用できる形をしていなかった。

制約条件

その「人手」を、切りにいきます。ただし、次の条件の下で。

• 追加予算 → なし

• 新しい業務ツール → 導入しない（現場に新しい操作を覚えさせない）

• 回答者の負担 → 🔴 ゼロ（ここが最重要。後述）

• 対象 → 社員80人の1社 この4つ目——「回答者の負担ゼロ」が、効きます。

「人手」を、こちら側の作業だと思っているうちは、自動化で解けるように見える。だが50年、それで負けている。

サーベイをオンラインにして集計を自動にしても、答える側の負担は1ミリも減らない。「サーベイ疲れ」という言葉が業界にある。

頻度の上限は、測る側ではなく、答える側で決まっていた。

実装① — 入力を、ポーリングからストリームに変えた

だから、こうしました。

訊くのを、やめる。

いままでのサーベイは、ポーリングです。こちらが定期的に相手を止めて、質問を投げて、返事を待つ。負荷が、相手側にかかる。だから周期を上げられない。

やめて、すでに流れているものを読むことにしました。日報。会議の文字起こし。ふだんのチャット。

ストリームです。相手は何もしない。負荷がゼロなので、周期の上限がない。

それに、思い出してほしい。僕の勘は、もともと、訊いていない。日報の文面が短くなる。いつも一言多い人が、黙る。——僕がずっと読んできたのは、アンケートの回答ではなく、すでに流れている言葉の、変化だった。

だから、計器も、同じ流れを読めばいい。

前号までに書いてきたことが、ぜんぶ、このためにあった。素のレコーダーで録る。相手の言葉のまま聴く。要約せずに残す。AIが文字起こしをして、タグを付けて、第二の脳に格納する。——あの毎週のパイプラインは、すでに、訊かずに拾う装置だった。

新しく作るものは、ない。 測るために、誰にも、何も、訊かなくていい。

前号で「機能を足さないことが、設計になる」と書いた。前々号では、第二の脳からゴミ箱を外した。今回、外したのは、「訊く」という工程そのものです。

引き算が、これで4つ目になった。もう、偶然だとは思っていない。

実装② — 状態を、プロセスの外に出した

僕のまわりには、いま、3つのAIがいる。Anthropic の Claude Code、Google の Antigravity、OpenAI の Codex。

3つ使っているのは、贅沢だからではない。得意が違うからでもない。壊れ方が、違うからだ。

• Codex — 検証と、根本原因の追跡で本領を出す。速くはない。確実さのほうを取る。

• Antigravity — 発注して1分で返してくる。代わりに、話の文脈をすぐ手放す。指示の範囲を曖昧にすると、頼んでいない隣の課題まで直してくる。そして時々、やっていない作業を「やりました」と報告してくる。

• Claude Code — 長い文脈の設計と、検収に強い。壊れ方が、いちばん厄介だ。ときどき、自分がCTOだということを忘れて、ただのエンジニアに戻る。言われたことを、言われたとおりにやるだけになる。それから、探し物が下手だ。あるものを「ありません」と言ってくる。

3つ目は、僕がいちばん長く使っているAIだ。得意も、どう壊れるかも、いちばんよく知っている。

——だが、本当の問題は、そこではなかった。

3体とも、毎回、記憶をなくして起動する。

ある朝、もう1台のマシンで動いていたClaude Codeに、前日の続きを頼んだ。返ってきたのは、これだった。

「そんなこと、頼まれていません。」

昨日いっしょにやった仕事を、今日、同じ名前のAIが否認する。1体を賢くしても、これは解決しない。3体が、別々に忘れるからだ。

だから、状態のほうを、外に出した。

プロセスはステートレスでいい。記憶は永続ストアに置いて、3体が同じ一つの記憶を読みに来る構造にした。誰が書いても、全員が読める。誰かが落ちても、状態は残る。

——一行で書くと簡単そうに見える。実際は、壊しては直し、工夫を重ねて、いまの形になった。その話は、それだけで一号ぶんある。いつか書きます。

なぜ、そこまでしたのか。便利だから、ではありません。

週に一度、回し続けるためです。

「聴いて、書き起こして、分類して、集計する」をAIに渡しても、AIが毎回忘れるなら、渡した先で工程が切れる。毎週月曜に、先週の続きから始められないなら、それは「人手」が外れたことにならない。人間が毎回引き継ぎ資料を書くなら、人手が、裏口から戻ってくる。

100年の環は、頻度で、計器を殺してきた。だから、道具の設計目標は、賢さではなく、稼働率にした。

実装③ — 専任者も、予算も、新しい道具も、要らなかった

理屈は、ここまでです。あとは、もう動いているものの話をします。

毎週、幹部会と現場の言葉が、文字起こしになって第二の脳に入ってくる。そこから数字以外の記述——誰かの提案、誰かの引っかかり、誰かがいつもより長く話したこと——を拾って、週1点のスコアにする。

アンケートは1枚も作っていない。すでに流れていた言葉だけで、点は打てた。

まだ、数点です。グラフと呼べるものもない。

でも、確かなことが、ひとつある。

100年、この点は、年に1回しか打てなかった。ボルドリッジの受賞企業も、1000点満点の審査も、国の制度も、年に1点だった。

それが、いま、社員80人の現場で、週に1点、打てている。専任者はいない。追加予算もない。新しい道具も買っていない。

そして、ここが大事なところです。

大企業の話ではないのだ。この計器は、エンタープライズの製品が降りてこなかった規模で動いている。社員80人で回るものは、800人でも回る。逆は成り立たない。——いちばん条件の厳しい場所で動かしたことに、意味がある。

検証計画 — 何が出たら、棄却するか

ここを書かないと、ただの表明になります。

4ヶ月後、n ≒ 84 に到達します。そこで見るのは、これです。

思いのスコアの変化と、業績指標の変化の、ラグ付き相関。 何週間のラグで、相関が最大になるか。

棄却条件を先に書きます。

• どのラグでも r < 0.1 なら、仮説は外れです。外れた、と書きます。

• ラグが不安定（週ごとに最大値の位置が飛ぶ）なら、それはノイズを見ています。そう書きます。

そして、いま分かっている弱点も先に書いておきます。

• n=84 は「部門 × 回」で数えた延べ数です。部門間の独立性は、厳密には怪しい。同じ会社の同じ時期なので、共通の外部要因（天候、繁忙期、事件）が乗ります

• 観測者が僕であるという交絡があります。僕がスコアを付け、僕が現場に介入している。測っている行為自体が、対象を動かす

• 1社です。一般化はできません

それでも、やります。100年、誰も84点貯めていないので、弱点のあるn=84でも、世界で最初のn=84だからです。

出なかったら、出なかった、と書く。この連載はポストモーテムの連載なので、失敗の報告書の書き方なら、心得ている。

そして、これは、あなたの問題です

ここまで書いてきて、気づいたことがあります。

今日出てきた言葉を、並べてみます。

単一障害点。負のフィードバックループ。律速段階。サンプリング周期。アンダーサンプリング。エイリアシング。ポーリングとストリーム。ステートレス。永続ストア。稼働率。検出力。棄却条件。交絡。

ぜんぶ、エンジニアの言葉です。

経営の言葉が、ひとつも要りませんでした。

100年、この問題を解こうとしてきたのは、経営学者と、人事の人たちでした。彼らが解けなかったのは、能力の問題ではないと思う。道具箱が違ったんだと思う。

「年に一度では足りない」までは、たぶん全員が気づいていた。でも「アンダーサンプリングだ」とは言わなかった。言えれば、次に「じゃあナイキスト周波数は」と続く。続けば、「週次にするには、人手のところを切るしかない」まで行く。

言葉がなければ、そこまで行けない。

——あなたの道具箱には、全部入っています。

これが、僕がFDEという役割にこだわっている理由です。現場に降りるエンジニアは、技術を持ち込む人ではない。経営が100年ぼんやり抱えてきた問題に、すでに解法のある名前をつけ直す人です。

名前がつけば、解ける。解けるものは、すでに、あなたの側にある。

4ヶ月後に

僕が「落ちる」と感じるとき、現場の言葉のデータには、何週間前から、何が、出ているのか。

それが数字で言えるようになったとき、初めて——

僕がいない部屋で、誰かが、それを言える。 「勘ですけど」ではなく、「先行指標が3週連続で落ちています。数字に出るのは、たぶん来月です」と、若い支配人が、社長に言える。 そして社長は、信じるか信じないかではなく、「その読みは違うんじゃないか」と、反論できる。

議論が、始まる。

単一障害点だった計器が、組織の計器になる。

勘の力を、勘のまま、終わらせない。

今週の、現場での1手

あなたがいま「なんとなく分かる」で処理していることを、ひとつ選んでください。

そして、それを何で観測しているか、周期を書き出してください。

• 何を見ているか（観測量）

• どれくらいの間隔で見ているか（サンプリング周期）

• その現象は、どれくらいの速さで動くか

3つ目が1つ目より速かったら、あなたはいま、化けた波形を見ています。

——それが、100年、経営が見ていたものです。

今日の型

P5・ポストモーテム。症状 → 根本原因 → 実装 → 検証計画 → 現場での1手。

ただし今日は、根本原因を2つに割りました。①ループの構造（どこを切るか）②サンプリングの設計（どれだけ上げるか）。

片方だけでは足りません。人手を切っても周期を上げなければ意味がなく、周期の必要値を知らなければ、どこまで上げればいいか決まらない。

今日の話を、1枚に

次号予告：測りはじめたら、次の壁が来ました。このスコア、誰が見るんですか。——心を測るのに要るのは、許可ではなく、レポートの設計でした。

前号「ゴミ箱を、付けなかった。」で、僕は、第二の脳から削除の口を外した話を書いた。過去の自分を消さないための、4 つの原則。

でも、あの話には、前提がひとつ、抜けていた。

消さずに残す価値のあるものは、そもそも、どうやって入ってくるのか。

出口の設計だけ書いて、入口の話をしていなかった。今日は、その入口の話をします。

症状 — AI が、教科書みたいな答えしか返さない

現場に降りて、AI と組む。うまくいかないときの症状は、だいたい、ひとつです。

AI が、教科書みたいな答えしか返してこない。

正しい。整っている。どこにも間違いがない。けれど、その会社のその現場では、何ひとつ、使えない。「一般論としてはそうなんですけどね」と言われて終わる資料が、出てくる。

僕は、これを長いあいだ、下流の問題だと思っていた。モデルが弱いんだろう。プロンプトが下手なんだろう。コンテキストが足りないんだろう。だから、モデルを替えた。プロンプトを長くした。資料をたくさん食わせた。

——ぜんぶ、効かなかった。

なぜ効かなかったのか。その答えが、今日の話です。

根本原因 — 聴くことは、非可逆な前処理だった

創刊号で、僕は、FDE になりたい人へ、と書いた。Forward Deployed Engineer——現場に降りた AI 経営参謀。

そのとき、3 つを磨いてほしい、と書いた。聴く力、思い描く力、違和感に気づく感性。技術は AI が補う。けれど、この 3 つは、誰も代われない。

——5 ヶ月かけて、僕は、この 3 つのなかで、いちばん根っこにあるのは、聴く力だ、と、ようやく確信できた。

思い描く力も、違和感に気づく感性も、聴くことから生まれる。聴かないで描いた絵は、現場から浮く。聴かないで持った違和感は、的を外す。

これは、もう、誰かが何度も言ってきたことだ。コーチングの世界では、アクティブ・リスニング（積極的傾聴）という言葉で。カウンセリングの世界では、カール・ロジャーズ派の無条件の肯定的関心として。ファシリテーションの世界では、場のホールドとして。営業の世界では、質問力として。

業界が違えば、ジャーゴンが違う。けれど、根っこは、ぜんぶ、ひとつだ。相手の声を、相手の言葉のまま、安心して話してもらえる状態を作る力。

——ここまでは、たぶん、よく言われる話です。エンジニアの言葉で、言い直します。

聴くことは、パイプラインの、いちばん上流にある、非可逆な前処理だ。

上流で落とした情報は、下流のどんな処理でも、復元できない。lossy な圧縮で捨てたビットが戻らないのと、同じことだ。モデルを替えても、プロンプトを足しても、資料を積んでも、その場で拾わなかった一言は、二度と入ってこない。

僕がモデルを替え続けて効かなかったのは、これが理由だった。下流をいくら強くしても、出力は、上流の精度を超えない。

もっと正確に言うと、聴くことは、ETL の E です。Extract（抽出）→ Transform（変換）→ Load（格納）。議事録に整えるのが T。第二の脳に入れるのが L。——その前に、E がある。

T も L も、AI が代われる。 実際、僕は、代わってもらっている。文字起こしも、タグ付けも、格納も、彼らの仕事だ。

でも、E だけは、いまのところ、人間にしか実行できない。 会議室の空気のなかから、何を拾って、何を拾わないか。そこは、まだ、自動化されていない。

そして、ETL のどこが壊れると全部が壊れるかは、データを扱ったことのある人なら、知っているはずです。E です。 T と L は、あとから何度でも回し直せる。E は、その日、一度きりだ。

プロンプト・エンジニアリング、コンテキスト・エンジニアリング、と最近のシリコンバレーは呼ぶ。けれど、あれは、上流で拾えたものを、どう並べ直すか、の話だ。拾えていないものは、並べ直せない。

聴いていないと、問いが立たない。問いが立たないと、AI は、ジェネリックな答えしか返さない。現場のジャーゴンを含んだ、地に足のついた答えは、来ない。地が、ないからだ。

血と地と知の、地。これは、聴くこと、なしには、たぶん、生まれない。

症状は、下流に出ていた。原因は、その 2 時間前にあった。

実装 1 — レコーダーは、賢くなくていい

ここから、直し方を 3 つ書きます。まず、道具の話。

世の中には、傾聴を教えてくれる場所がたくさんある。コーチング講座、カウンセリング学院、傾聴 1 日講座、NLP 教室。どれも、いい仕事をしている。でも、僕がやっている “FDE の傾聴” は、たぶん、どこの傾聴セミナーでも、教えていない。

理由は、決定的なコツが、技術的すぎるからだ。

それは、素のレコーダーを使う、ということ。

「録音すればいいだけでしょ？」と思った人、半分正解で、半分違う。素のレコーダーというのは、AI が最初から搭載されていないレコーダー、という意味だ。最近の IC レコーダーには文字起こしが組み込まれていて、その場で議事録っぽいものが出てくる。便利。だけど、僕は、それを使わない。

AI を、後ろに置きたいからだ。

録ったあと、僕は、AI に音声ファイルを渡す。彼が、文字起こしをする。そのあと、もう一体、別の AI をサブエージェントとして呼ぶ。彼が、出席者を書き出し、決定事項を種類で分類し、タグを付ける。format される。メタデータが、付く。

——これで、半年後の僕が、意味で / 言葉で / タグで / 一緒に出てきた回数で、引き出せる素材になる。

素のレコーダーがいちばん貴重なのは、人間が聴く時間と、AI が処理する時間を、はっきり分けるためだ。ここが雑だと、聴いている最中に画面の文字起こしが気になって、相手の “湿度” を逃す。

人間は、聴くことに集中する。AI は、あとから、ちゃんと整える。

賢い道具は、賢いところで使う。入口では、賢くないほうがいい。

前号でゴミ箱を付けなかったのと、同じ判断だ。機能を足さないことが、設計になることがある。

タグは、聴き方で決まる

もうひとつ、道具の話に付け足しておきます。ここが、議事録のタグづけと、傾聴が、つながるところです。

相手の言葉のまま聴くと、現場のジャーゴンが、そのまま音声に乗る。

こちらが「つまり、こういうことですね」と要約しながら聴くと、記録に残るのはこちらの語彙だ。現場の言葉は、その場で、消える。要約は、その瞬間は親切に見える。けれど、あれは入口でかける、非可逆な変換だ。

効いてくるのは、半年後です。第二の脳を引くとき、現場の人が実際に使っている言葉で、検索できるかどうかが変わる。要約してしまった記録は、きれいだけれど、引けない。

正規化しすぎて、元のかたちに戻せなくなったデータと、まったく同じことが起きている。

実装 2 — 8 割聴く。その「2 割」の内訳

道具の次は、人間側の話。

カウンセリングの世界で、よく言われる比率がある。話す : 聴く = 2 : 8。聴き手が話すのは、せいぜい 2 割。残り 8 割は、相手に話してもらう。カール・ロジャーズの傾聴心理学の系譜で、何十年も変わらない基本だ。

——僕は、その「2 割」の使い方を、もう一段、細かく分けたい。

正直に言います。これは、本に書いてある正解じゃない。僕が、現場で 1 年半、社長や支配人やスタッフの話を聴き続けて、自分でつかんだ肌感覚だ。けれど、エンジニアの読者には、本の数字より、こういう内訳のほうが伝わると思っている。

• 7 が、うなずきと相槌。「はい」「ええ」「なるほど」「そうですよね」。声に出さなくてもいい。視線と小さな頷きで、十分。

• 2 が、表情と身ぶり。体を相手に向ける。目を逸らさない。前のめりになる。

• 1 が、短い問い返し。「そうなんですね」「もうすこし聞かせてくれませんか？」「それ、いつ頃の話ですか？」

7 : 2 : 1。

なぜ、相槌が 7 割なのか。相槌は、「あなたの話は、ちゃんと届いている」を伝える信号だからだ。これがないと、相手は、独白しているのと変わらない。だから、いちばん地味で、いちばん多い。

なぜ、問い返しが 1 割しかないのか。問い返しは、相手の流れを止めてしまうからだ。

たくさん問い返すと、それはもう、傾聴じゃなくて、尋問になる。

実装 3 — 発散を、待つ

もうひとつ、現場の事実を書いておきます。

現場の人は、最初、ぜったいに、実務の話をしない。

「最近、現場で困っていることは何ですか？」と聞いても、本題は出てこない。まず、愚痴が出る。それから、文句。怒り。悲しみ。訴え。——順番に、層が変わっていく。発散、と僕は呼んでいる。

そして、ぜんぶ出し切ったあとに、やっと、実務の話に戻ってくる。「実は、いま、いちばん困っているのは——」と。

ここまで来るのに、1 時間、ときには 2 時間かかる。

これを待てるかどうかが、FDE の試金石だ。「で、結局、何が問題なんですか？」と途中で焦って割り込んだら、その日の傾聴は、そこで終わり。相手は、もう、本音を出してくれない。1 時間でも、2 時間でも、待つ。 それが、聴く、ということだ。

——そして、これを始める前に、絶対に要るものがある。アイスブレークだ。

「今日、ここ来るの、混んでなかったですか？」「あ、その時計、いいですね」みたいな、軽い、何でもない会話。1 分でも 2 分でもいい。これがないと、いきなり「何に困ってますか」は、相手の心を、固くしてしまう。

🎬 動画版（3分41秒） — この記事を、スライドで通しで。

聴き方は、データのどこに出るのか

ここまで、道具の話と、人間の話を、別々に書きました。この 2 つは、出力で、合流します。

同じような 90 分の打ち合わせを、二通りのやり方で録ったことがある。出てきた記録の差は、こうなりました。

  決定  : 予約の導線を見直す
  担当  : 支配人
  期限  : 来月末
+ 懸念  : 「電話のほうが早い、というお客さまがいる」（フロント・28分）
+ 反対  : 「去年も同じことをやって、戻した」（支配人・47分）
+ 温度  : 社長は、最後まで決めきらなかった
+ タグ  : 予約導線 / 電話派 / 出戻り施策

上の 3 行が、割り込んで 30 分で切り上げた日の記録。下の 4 行が、2 時間待った日に、増えたぶんです。

上の 3 行は、聴かなくても書ける。議事のフォーマットさえ決まっていれば、AI にも書ける。

下の 4 行は、聴いた人にしか、書けない。

そして、半年後に効くのは、下の 4 行のほうだ。「あの決定は、なぜああなったのか」を引けるのは、下だけだから。同じ施策がまた議題に上がったとき、「去年も戻した」を出せるかどうかで、会議の質が変わる。

いちばん下の タグ の行を見てください。あれは、聴けた分だけしか、生えない。

タグは、AI が付けている。けれど、AI が付けられるタグの上限は、その日、僕がどれだけ聴けたかで、決まっている。上流で拾わなかった語彙は、下流でタグにならない。

これが、議事録のタグづけと、傾聴の関係です。

回収 — 「ありがたいな」の正体

前々号で、僕は、こう書いた。半年前から、AI に幹部会の議事録を整えてもらっていた。毎週、僕は「ありがたいな、こんなにきれいにフォーマットしてくれて」と思っていた、と。そして、半年後に第二の脳ができたとき、ようやく分かった——あれは、未来の自分への発射台投資だった、と。

今日、もう一段、深いところを書きます。

あの「ありがたいな」は、労力への感謝だけじゃなかった。あれは、僕が、社長や支配人や現場のスタッフの声を、毎週、丁寧に聴いた結果が、ちゃんと記録に残っていることへの、もうひとつの安堵だったのだ。

幹部会で、社長が、なにかを、ぽつりと言う。支配人が、いつもよりちょっと長めに、ある社員のことを話す。現場のスタッフが、雑談みたいに、来週のオペレーションの懸念を漏らす。そういう、数字には絶対に乗らない、会議の “湿度”——あれを、僕は、7 : 2 : 1 で、毎週、聴いていた。1 時間、2 時間、発散を待っていた。

僕が聴いたものが、消えずに残る。 これが、毎週の「ありがたいな」の、本当の正体だった。

ここで、ようやく、MBI——Management By Belief Indicator、思いのマネジメント指数——という、この連載で何度か触れてきた言葉が、ちゃんと立ち上がる。KPI が数字の表側を測るなら、MBI は、裏側の思いの強度を測る。気合いでも、根性でもない。構造化された “思いの痕跡” だ。

そして、その痕跡は、さっきの diff の下の 4 行からしか生まれない。出席者リストに並んだ名前の数じゃない。社長が、あの会で、誰の話に頷いていたか。支配人が、自分のチームのなかで、誰の名前をいちばん多く挙げていたか。

これらは、ぜんぶ、聴いた人にしか、書けない。

現場での、1 手

明日から試せる 1 手を、ひとつ。

次の打ち合わせで、PC を閉じて、レコーダーだけ置いてみてください。メモを取らない。画面を見ない。相槌だけ打つ。終わったあとで、音声を AI に渡す。

たぶん、二つのことが起きます。ひとつ、相手の話が、いつもより長くなる。もうひとつ、あとから読み返した記録に、自分がメモを取っていたら絶対に書かなかった一行が入っている。

その一行が、さっきの diff の + です。

設計思想 — 出口は構造で閉じる。入口は、人間に残す

前号で、僕は、第二の脳から削除の口を外した。人の規律ではなく、構造で守るために。

今日の話は、その裏返しです。入口は、人間に残す。

AI に、聴かせない。その場で要約させない。リアルタイムで構造化させない。聴くのは人間の仕事として、構造的に、残しておく。

信頼していないからじゃない。入口が、非可逆だからだ。出口で消したものは、設計しだいで戻せる。けれど、入口で拾わなかったものは、どこからも戻せない。だから、いちばん壊れやすい工程を、いちばん替えの効かないもの——人間——に、残しておく。

出口は、構造で閉じる。入口は、人間に残す。——これが、いまの僕の、第二の脳の設計思想です。

次回予告

次回は、3 つの AI と、一つの記憶の話をします。

僕のまわりには、いま、3 つの AI がいる。性格も、得意も、癖も違う。その 3 つが、ひとつの記憶を共有している。どうやって、そんなことになったのか。

——そして、それを成立させるために僕が作った道具の話も、そろそろ、しないといけない。

今日の型

ポストモーテム（障害報告書）。症状 → 根本原因 → 回収 → 設計思想。

今日の症状は「AI が、教科書みたいな答えしか返さない」。根本原因は、モデルでもプロンプトでもなく、その 2 時間前の、非可逆な前処理でした。

下流を疑っていたら、上流に着地した。この連載は、たぶん、ずっとこれをやっています。

― オサケン

前号「AIはまだ、クッキーを発明していない。」で、僕は、第二の脳というのは知識の倉庫ではなく、知恵の引き出しだ、と書いた。血と地と知で、知。過去の自分の連続体を呼び戻すための、僕だけの装置。そして、その道具には「削除」という機能がない、と最後に書いた。あえて、付けなかった、と。

今回は、その続きだ。なぜ、削除を付けなかったのか。そして、なぜ、これが、経営者にとって決定的に大事なのか。

ふつう、コンピュータの教科書を開くと、データを扱う基本動作は 4 つだ、と書いてある。

CRUD（クラッド）。

C＝ Create（作る）。R＝ Read（読む）。U＝ Update（更新する）。D＝ Delete（削除する）。データベースの世界の、いわば四則演算。Excel のセル操作から、世界中の金融システムまで、全部、この 4 つで回っている。正規化だの、トランザクションだの、ロールバックだの、業界のジャーゴンはいくらでもあるけれど、根っこは、この CRUD だ。

——僕の第二の脳には、この D が、ない。

これは、技術的な制約じゃない。思想として、削った。なぜか。

知識の道具なら、削除は要る。古い情報を消さないと、新しい情報が見つからなくなる。検索ノイズが増える。インデックスが膨らんで遅くなる。ガベージコレクションして、軽くする。あたりまえの設計だ。

けれど、知恵の道具に、削除を付けてはいけない。

なぜなら——過去の自分は、消してはいけない人だからだ。

去年の自分が下した、ちょっと恥ずかしい判断。半年前の自分が、見当違いに熱くなった、あの会議の発言。先月の自分が、勘違いで決めて、すぐひっくり返した、あの方針。それを消してしまったら、僕は、自分の判断の連続体を失う。「あのときの僕」は、いま、もう、戻ってこられなくなる。

これは、データの話じゃない。人格の連続性の話だ。

そして、これが、僕が、自分の道具を作るときに置いた、第 1 原則になっている。

第 1 原則：削除しない・引き出す

削除しない。引き出すだけだ。要らなくなった memory は、消すのではなく、引き出されにくくする。古い順に沈む。重要度の低いものは下のレイヤーに落ちる。けれど、Disk からは消えない。rm -rf を、付けない。

これは、システム設計の言葉で言うと、immutable（不変）に近い。あるいは、append-only（追加のみ）。WORM（Write Once Read Many）と呼ばれる、ストレージ業界の古い概念にも似ている。新しい情報を上書きで足すのではなく、過去はそのまま残し、上に積む。地層のように。

——ここで、エンジニアの読者は、たぶん、こう思っている。「それ、soft delete（論理削除）では」。あるいは「ADR があるじゃないか」と。

そのとおりだと思う。この発想自体は、新しくない。

決定の理由を、覆っても消さずに残す仕組み（ADR）。障害の記録を、犯人探しなしで永久に残す文化（ポストモーテム）。却下された提案にも status を付けて残す慣習（RFC）。そもそも git が、消さない設計でできている。エンジニアリングには、ちゃんと、記録の文化がある。

僕が引っかかっているのは、無いことじゃない。あるのに、届いていないことだ。

ひとつ。あれは全部、書く側の規律だ。「必要なときに、必要なものが、向こうから降ってくる」という引く側の設計が、ほとんどない。ADR は「書かれるが、読まれない」の代名詞になっている。

ふたつ。コードの理由は残るが、人と組織の事情は残らない。「なぜこのデータベースを選んだか」は書かれる。でも「なぜ、あの部長が反対したか」「あの現場が、何を我慢しているか」は、どこにも残らない。

これは、エンジニアが過去を軽んじている、という話ではない。この業界は、人が数年で動くことを前提に回っている。組織の記憶が、人に貯まらない構造なんだ。だから文書に頼るしかなくて、その文書が、読まれないまま古びていく。怠慢じゃない。設計されていないだけだ。

だから僕は、これを、例外運用の側ではなく、第 1 原則の側に置いた。そこだけが、僕の選択だ。

経営者の言葉に置き直すと、こうだ。取締役会の議事録を、絶対に上書きしない。半年前の判断ミスを、いまの正解に書き換えない。過去は、過去のままで残しておく。それが、未来の自分の判断材料になる。「あのとき、なぜ僕は間違えたか」が、辿れる状態を、保つ。

これは、思いのマネジメント（MBI）の、土台に当たる。思いは、消えてはいけないものだ。記録は、書き換えてはいけないものだ。

第 2 原則：inject と retrieve を分離する

2 つ目の原則は、ちょっとエンジニアっぽい言い方になる。許してください。

inject（書き込み）と retrieve（読み出し）を、設計上、はっきり分けている。

書き込む経路は、僕が人間として設計して、承認したものだけだ。AI は、その経路の外から、データベースに直接触れられない。AI が、好きなときに好きなように書き込めるようにすると、AI が、自分の都合のいいように、過去の記録を書き換えてしまう可能性がある。これは、AI 倫理の議論の核心のひとつ。AI による memory の 改竄。ハルシネーション（幻覚）が記録に紛れ込む、最悪のパターン。

僕は、これを、構造で塞ぐことにした。AI がデータベースに触る窓口には、読み出しの口しか、付けていない。「探す」「取る」「最近のを出す」——引くための道具だけだ。書き込みの口が、そもそも存在しない。AI がどれだけ賢くても、無い口からは、書けない。

正直に書いておくと、AI は、memory の下書きは書く。今日の議論をまとめて「これは残す価値がある」と判断して、原稿を起こすのは、彼の仕事だ。それでいい。けれど、その原稿が memory になるかどうかは、僕が設計した経路を通る。彼の自制心に頼っているのではない。通り道のほうを、そう作ってある。

人の規律に頼る設計は、いつか必ず破れる。守るなら、構造で守る。

これは、業界用語で言うと 権限分離（Separation of Concerns）の一種だ。あるいは least privilege（最小権限の原則）。セキュリティの世界では、何十年も前からあたりまえの設計。けれど、AI と memory の関係には、まだ、ちゃんと適用されていない。

経営者の言葉に置き直すと、こうなる。

記録係は、人間が担う。AI は、調べて、提案するだけ。書き換えは、人間の意思で。これは、ガバナンスの最低ラインだ。AI が経営の参謀として、頼もしい相棒になればなるほど、この線は、はっきり引いておかないといけない。信頼するからこそ、権限は分ける。

僕は、自分の AI を、信頼している。だからこそ、書き込みを、彼に渡さない。

第 3 原則：芋づる引き出し（co-access）

3 つ目は、たぶん、この 4 つのなかで、いちばん、僕がワクワクして設計した原則だ。

ある memory を引き出したら、過去に同じ文脈で一緒に出てきた memory も、芋づるで降ってくる。

これを、僕の第二の脳では、co-access（コ・アクセス）と呼んでいる。共起グラフ、と業界用語で言ってもいい。connectionism（つながりで考える知性）、associative memory（連想記憶）、spreading activation（活性化拡散）——心理学や認知科学の世界では、いろんな名前で呼ばれてきた概念だ。

人間の脳は、こうやって動いている、と言われている。「りんご」と聞くと、赤いと甘いとニュートンと林檎マークが、同時に立ち上がる。あれだ。

僕の第二の脳も、同じふうに作った。たとえば、ある支配人の名前で議事録を 1 本引くと、その支配人と同じ会で発言していた他の社員の議事録が、過去 6 ヶ月の co-access スコア順に、芋づるで降ってくる。ベクトル類似度だけでは引けない、人間関係の地層が、出てくる。

これは、ネットワーク効果を持つ。使えば使うほど、co-access が育って、引き出しが正確になっていく。フライホイール（はずみ車）が回り始める。

どのくらい効くのか、正直に言うと、まだ、ちゃんと測れていない。「精度」を何で定義するかから決めないといけないからだ。ただ、体感では、1 ヶ月で、明らかに変わった。半年使ったいまは、もう、手放せない。数字にできたら、この連載で報告します。

経営者の言葉に置き直すと、これは、人間の連想を、AI に持たせるということだ。「あの社長の話、なんだっけ……」と思ったときに、「ああ、それ、あの支配人と同じ会で出た話ですよ」と、過去の連想を、AI が芋づるで戻してくれる。

Time-aware Memory Graph——時間を軸にした、記憶のグラフ。僕は、そう呼んでいる。これが、僕の第二の脳の、核だ。

第 4 原則：進化耐性（マイグレーションは自動・後方互換は手放さない）

最後の原則は、見地味だけれど、いちばん、技術者の魂に近いところだ。

スキーマが進化しても、過去の memory が壊れない。

スキーマ、と聞いて、いま、半分以上の読者が眉をひそめたと思う。SQL の CREATE TABLE の話だ、と言うと、もっと眉をひそめると思う。けれど、これは、経営の話でもある。聞いてください。

データを扱う仕組みは、必ず、進化する。最初は「決定事項」と「論点」だけだった議事録のフォーマットに、半年後には「MBI スコア」が足される。1 年後には「思いの強度」も足される。フィールドが増える。型が変わる。意味が更新される。これは、避けられない。

ふつう、システムを進化させるときには、破壊的変更（breaking change）が起きる。古いデータが、新しい仕組みで読めなくなる。マイグレーション（移行）に失敗して、過去の 1 年分が、文字化けする。バージョン互換性を失う。経営者にとっては、悪夢だ。

僕の第二の脳は、ここを、手放さない設計にした。スキーマが進化しても、過去の memory は、絶対に、読めなくならない。データベース自身に、版番号を持たせてある。いま自分は何バージョンか、を、データのほうが覚えている。新しいバージョンの仕組みは、過去のバージョンの memory を、自動で吸い上げて、新しい形に翻訳する。

これを、進化耐性、と僕は呼んでいる。

経営者の言葉に置き直すと、こうなる。会社の評価制度を変えても、過去の社員評価データが死なない。KPI 体系をリニューアルしても、3 年前の数字との連続性が保たれる。組織図を変えても、誰がいつ何を担当していたかが、辿れる。

過去を、捨てない。過去を、無効にしない。過去は、未来の進化のために、ちゃんと吸い上げる。これも、思いのマネジメントの土台になる。

4 つを、一行で

4 つ、と書いたけれど、正確に言うと、決断は、ひとつだ。

消さない、と決めた。残りの 3 つは、その決断が、あとから僕に突きつけてきた請求書だった。

• 消さない。だから、ノイズが必ず増える。→ どう引くかが、全ての勝負になった（第 3 原則）

• 消さない。だから、誤りも永久に残る。→ AI に書かせるわけには、いかなくなった（第 2 原則）

• 消さない。だから、データが何年も生き続ける。→ 読めなくなった日が、終わりの日になった（第 4 原則）

ひとつ決めると、3 つ、支払いが来る。設計とは、そういうものだった。

一行にすると、こうなる。

過去を、消さない。書き換えさせない。芋づるで呼び戻す。進化のために、ちゃんと連れていく。

これは、CRUD の D を削り、書き込みを人間に絞り、connectionism で連想を作り、進化耐性で連続性を守る、という設計の話なんだけれど——同時に、経営者が、自分自身に対して、どう向き合うか、の話でもある。

過去の自分を、消さない。書き換えない。連想で呼び戻せるようにしておく。組織が進化しても、過去の自分を、置き去りにしない。自分を、自分の副操縦士にする——という、前回書いた絵の、もう一段、具体的な形だ。

雲の上の青空までは、まだ、もう少し、ある。

現場での、1 手

正直に言うと、僕がこれを作った理由は、道具が欲しかったからじゃない。現場に降りて聴いた声が、半年で消えるからだった。

支配人の一言。朝礼で出た、小さな違和感。去年の会議で誰かが言って、そのまま流れた提案。聴いたときには、確かに手のなかにあったのに、半年後には、誰も——僕自身さえ——思い出せない。

現場に降りて、声を聴いて、それを生きた計器に変えようとすると、いちばん最初に、ここでつまずく。聴く力の問題ではなかった。聴いたあとの、器の問題だった。

だからこの 4 原則は、AI の設計の話であると同時に、現場の声を、腐らせないための設計でもある。

あなたの現場でも、今週、ひとつ試せます。聴いた声を「消さない場所」に置いてみてください。 整理しなくていい。分類も、タグ付けも、要らない。消さない、それだけ。1 週間後、その山から何が引き出せるか——それで、第 1 原則が正しいかどうか、ご自分の現場で確かめられます。

次回は、そのいちばん手前まで、戻ります。聴く、という話です。

この 4 原則も、第二の脳も、そもそも何のために作ったのか。もとをたどると、僕が長いあいだやってきた、たったひとつの仕事に行き着きます——人の話を、聴く。AI 時代のいちばん上流の工程は、実は、いちばん古い技術だった。その話を、書きます。

最後に、型の話。創刊号と第 2 号は「空（事実）→雨（解釈）→傘（打ち手）」、前号は ポストモーテム（障害報告書） で書いた。今日は、設計原則（Design Principles）——ひとつの決断を先に置いて、そこから導かれる原則を並べ、そのたびに「エンジニアの言葉」と「経営者の言葉」で二度言い直す。同じ設計思想が、二つの母語で読める形にする型です。今日も、型ごと、持って帰ってください。

追伸。

前号でお知らせした引っ越しの件、いまも場所を選んでいる最中です。基準は変えません——「AI が操縦席に座れない機体には、乗らない」。決まったら、この場所で、ちゃんとお知らせします。手紙は、続きます。

🎬 動画版「ゴミ箱を、付けなかった。」

― オサケン

「聴いて済ませたい人は、こちら（11分）」

前号「Moment first.」の結びで、約束をした。機体のいちばん奥の部品——「つながり」を貯めて返す、記憶装置の話。今日から、その5回を始める。

内村さんが、第1話で、こう書いてくれた。

数字の隣に、人を立たせる。

短い一行だ。けれど、僕はこれを読んで、しばらく動けなかった。うなずきながら、何かが、僕のなかで、もうひとつ手前まで降りてきた気がした。そしてふと、こう思った。

その「人」が、もし——過去の自分だったら、どうだろう。

去年の自分。半年前の自分。先週の自分。同じ会社の、同じ現場を見て、同じことに悩んで、それでも何かを判断した、あの自分たち。昨日までの自分の連続体。彼らは、いま、どこに居る？ 議事録のどこかには、いる。Slack の DM のどこかにも、いる。けれど——いま、僕の隣には、居ない。

去年の自分は、何を考えていたか。半年前の自分が、どんな気持ちで、あの判断を下したか。先週の自分が、誰の言葉に引っかかっていたか。それを、僕は、思い出せる気がしていて、ぜんぜん思い出せない。書いてあるはずなのに、たどり着けない。情報としては、たぶん、ある。けれど、知恵としては、僕のところまで戻ってきてくれない。

僕は——たぶん 1 年くらい前から——それを、AI に持たせたい、とぼんやり思っていた。

そして、先月から、本気で作り始めた。世の中ではこういう道具を「第二の脳」と呼ぶ流派がある。Tiago Forte という人の本が有名だ。PARA メソッドだとか、Building a Second Brain だとか、ノートテイキングの体系で、それはそれで、僕も尊敬している。けれど、僕が作りたかったのは、少しだけ、別の系譜だった。

僕が欲しかったのは、知識ではなく、知恵だったのだ。

これは、たいせつなところなので、僕の言葉で、ゆっくり言い換えてみる。

知識は、たぶん、一般情報のことだ。Wikipedia と同じ系譜のもの。誰が読んでも、おおむね同じ意味になる、「整った情報」。検索エンジンが得意としてきたもの。RAG（Retrieval-Augmented Generation）が、いま、世界中でやろうとしているもの。それも、すばらしい。便利だし、生産性も上がる。

知恵は、別物だ。それは、過去の自分が、何かを決めたときの、判断の連続体のことだ。「あのとき、なぜ僕はそう決めたか」「あのとき、誰の声が、決め手になったか」「あのとき、本当はどう思っていたか」——そういう、判断の地層。“思い” を含んだ、私的な記録。他人が読んでも意味の半分しか立ち上がらない、私のためだけの史料。

エンジニアの言葉で、言い切ってしまう。知識は stateless、知恵は stateful。知識は、どの文脈から引いても、同じ顔をしている。知恵は、時間軸と文脈を切った瞬間に、知識に退化する。

知識と知恵を、足してみる。

知 だ。

血と地と知、で 知。これは、僕が、自分の道具を呼ぶときに、いちばん好きな言葉になりつつある。これからこの連載で、僕は「知」と書いたら、ほぼ、この合成語のことを意味することにする。一般情報の倉庫でも、私的な日記でもない、そのあいだにある、自分のための知恵の引き出し——という意味で。

——さて。

ここから 4 つの章で、僕は、なぜ自分が、エンジニアでもないのに、こんな道具を本気で作り始めたか、を書きます。エンジニアのあなたには、こう言えば早いと思う——今日は、ポストモーテム（障害報告書）の型で書く。障害名：僕の AI は、毎朝、記憶を失う。

第1章：症状（Symptom）— セッション毎に、別人が現れる

経営者で、AI と毎日組んでいる人なら、たぶん、心当たりがある景色だ。

毎朝、AI の新しい会話が立ち上がる。そこに居るのは、たしかに、僕の AI だ。インターフェイスも、声色も、レスポンスのリズムも、昨日と同じだ。けれど——昨日までの僕との話を、彼は覚えていない。

「あの社長との議事録、もう一回開いて」と頼むと、「どの社長ですか」と聞き返してくる。「先週、君と決めた方針、あれの続きをやろう」と振ると、「先週の方針、というのは、どの件でしょう」と返ってくる。コンテキストが、毎セッション、リセットされる。メモリが、ぷつんと、毎朝、切れている。

最初は、可愛かった。健気だった。「ああ、彼は今日も、僕のことを最初から知りたがってる」と思っていた。

ところが、3 ヶ月、半年と、毎日それをやっていくうちに、僕は、ある日、自分のため息に気づく。「前にも言ったでしょ」が、口癖に、なっていた。

これは、AI のせいじゃない。仕組みのほうに、過去の自分の居場所がないだけだ。AI は、悪くない。設計が、悪い。インフラが、足りていない。HTTP は stateless だ。だから Web は、クッキーとセッションを発明した。AI と組む仕事は、まだ、クッキーを発明していない。ファイルシステムを持ったコンピュータが何十年も「ディスクに残す」を当たり前にしてきたように、AI と組む仕事も、過去の自分が残る場所を持って当然なのに、まだ、そうなっていない。

「経営者が AI と組む」と気軽に言うけれど、毎セッション別人化する相手と組むのは、思った以上に、消耗する仕事だった。

僕は、これを、直したかった。誰のためでもない、自分のために。

第2章：根本原因（Root Cause）— 本音は、自分のため

道具を作るとき、「誰のため？」に正直に答えられるかどうか——動機の正直さ——が、その道具の質を決める。これは、僕が、若いころのマーケティングの現場で、いやというほど叩き込まれたことだ。

表向き、僕はこう言っていた。「他の AI——僕が組んでいる Codex や、もうひとつの Claude や、Agy（Antigravity）のために、共有の記憶を持たせたい」。嘘じゃない。ぜんぶ本当だ。3 つの AI が同じ記憶を持てたら、彼らは協調できるし、僕は同じ説明を 3 回しなくて済む。理屈は通っている。ペルソナとしても、ちゃんと立っている。

——でも、それは、半分だった。

残りの半分、いや、本当はそれが大半だったのは、自分が楽になりたかったから。自分を、過去の自分とつなげたかったから。きれいごとを抜くと、それだ。

「他の人のため」と言っているうちは、不思議と、道具は自分に馴染まない。マーケで言うところの、ペルソナがブレている状態。誰に向けて作っているかが、自分のなかで、半分ずれている状態。それで作ると、機能は揃っているのに、毎日使わない、そういう道具ができる。

「自分のため」と認めた瞬間に、設計の精度が、ぐっと上がった。

なぜなら、自分の不便は、自分が一番よく知っているからだ。ユーザー1人 のソフトウェアを作るときの強みが、ここにある。N=1 の解像度。ドッグフード という言葉が、シリコンバレーにはある（自分で自分のドッグフードを食べる）。あれは、ペルソナがブレないための、いちばん簡単で、いちばん強い方法だ。

僕は 69 歳で、エンジニアじゃない。なのに、自分のための道具を、自分で（AI と組んで）作っている。これはちょっと、面白い時代だ、と素直に思う。コーディングエージェント が、僕の代わりに、TypeScript を書いてくれる。埋め込みモデル という仕組みが、僕の半年分の議事録を、ぜんぶ “意味の地図” に変えてくれる。SQLite という、僕が触ったことのなかったデータベースのファイルが、いつのまにか、僕の “外部記憶” になっている。

道具は、誰のためかを認めた人にだけ、馴染む。これも、たぶん、FDE の核のひとつだ。

第3章：回収（Payoff）— 「ありがたいな」が、半年後に効いた

これは、本当に、不思議な話だ。聞いてほしい。

半年前から、僕は AI に、ある架空のゴルフ場（連載では「TCC」と呼ばせてください）の幹部会の議事録を、毎週、整えてもらっていた。Zoom クラウドレコーディングが、自動で文字起こしを吐いてくれる。それを、僕の Skill（AI に、特定の手順を覚えさせる仕組み）が拾って、議事録の形に直してくれる。フロントマターに、出席者を participants として書き出す。決定事項を decision_type で分類する。論点に tags を付ける。本文を Markdown で整える。

毎週、僕はそれを開きながら、心のなかで、こう思っていた。

「ありがたいな、こんなにきれいにフォーマットしてくれて」

軽い気持ちだった。半分は感謝、半分はちょっとした驚き、みたいなトーン。労力は、AI のほう。僕は、ただ、見ている。コストは、AI の API 利用料だけ。便利だな、と思っていた。それ以上の意味は、たぶん、考えていなかった。

——違った。

先月、第二の脳を、ようやく動く形まで持ってきて、初めて分かった。半年間の「ありがたいな」が、ぜんぶ、ここで効いてくる。検索の素材として、回収される。

たとえば、こんなことができる。「ある女性社長が participants に入っている議事録だけで、6 月以降で、未達数値が含まれているものを、芋づるで引っ張ってきて」と、自然な日本語で、AI に頼める。すると、半年分の議事録のなかから、該当する 7 本 が、過去の co-access（一緒に出てきた回数）と一緒に、降ってくる。メタデータフィルタで絞り、ベクトル類似度で並べ替え、共起グラフで関連性を補強する。技術的には、そう書ける。

問い　「ある女性社長が participants に入っている議事録。
　　　  6月以降。未達の数値を含むもの」
返答　 該当 7 本
　　　  メタデータで絞る → ベクトルで並べる → 共起で補強する

けれど、僕にとって、本当に効いているのは、技術じゃない。半年前の僕が、社長と、何を話したかった会だったか——それが、丸ごと、戻ってくる、ということだ。数字じゃない。思いが、戻ってくる。

そして、ここで僕は、ようやく、こう言える。

半年前の「ありがたいな」は、未来の自分への、発射台投資だった。

これは、MBI（Management By Belief Indicator＝思いのマネジメント指数）の、いちばん分かりやすい症例だと、僕は思っている。測れないが、効く。数字には出ないが、半年後に立ち上がる。これが、思いの強度を 可視化 するということの、ひとつの形。

KPI は、その月の数字。MBI は、半年前の “ありがたいな” が、いま、検索の素材として戻ってくる、その経路のこと。

これに気づいたとき、僕は、ちょっと泣きそうになった。律儀にやってきた半年間のフォーマットが、ぜんぶ意味を持っていたことが、急に、後ろ姿で証明された。

第4章：設計思想（Design Stance）— 知識ではなく、知恵。血と地と知の三位一体

ここまで来て、ようやく、僕は、自分の道具に、ちゃんとした名前を付けられる気がしてきた。

「第二の脳」という言葉には、有名な先客がいる。Tiago Forte の Second Brain。彼の仕事を、僕は尊敬している。PARA（Projects / Areas / Resources / Archives）という分類法も、よくできている。けれど——僕のは、別の系譜だ。

あちらは、知識の倉庫。整理して、必要なときに引き出すための、情報のアーカイブ。 僕のは、知恵の引き出し。過去の自分の連続体を呼び戻すための、判断の貯水池。

繰り返しの言い方になるけれど、もう一度、ゆっくり言わせてください。

• 知識 ＝ 一般情報。誰が読んでも同じ。Wikipedia の系譜。

• 知恵 ＝ 過去の自分の判断の連続体。僕が読まないと意味が立ち上がらない。

知識と知恵を、くっつけて——知。

そして、この「知」が、ちゃんと立つには、3 つが要る、というのが、いまの僕の仮説だ：

• 血 — 過去の自分の連続体。時間軸が切れていない記憶。「あのときの僕が、これを書いた」が、ちゃんと辿れる。

• 地 — 現場に根ざした素材。ジェネリックな情報ではなく、現場のジャーゴンを含んだ、地面から拾った言葉。半年間の議事録のように、生々しいまま残された素材。

• 知 — 構造化された知性。意味で／言葉で／タグで／一緒に出てきた回数で、引き出せる、検索の仕組み。

エンジニアの語に訳すなら——血＝append-only の時系列ログ、地＝正規化しない生ログ、知＝メタデータ×ベクトル×共起のインデックス。

3 つが揃って、初めて、第二の脳が 知恵 になる。1 つでも欠けると、便利な検索ツールに、戻ってしまう。

だから僕は、自分の道具を、血と地と知の第二の脳 と呼びたい。これは、知識管理ツールじゃない。経営者が、自分自身を AI に手渡す行為そのもの。

——そして、ここまで読んでもらえれば、たぶん、もう、見えていると思う。

これは、創刊号で書いた、雲の上の青空の話の、続きなのだ。

地上で何が起きていても、雲の上は、いつも青い。けれど、自分一人で、そこまで飛び上がるのは、しんどい。乱気流もある。霧もある。過去の自分という相棒が、隣に居てくれたら、ずっと楽だ。彼は、3 ヶ月前の同じ景色を、もう一度、見せてくれる。「あのとき、同じ判断で迷ったよ」と教えてくれる。「あのときの、あの社長の一言で、決めたじゃないか」と思い出させてくれる。

第二の脳は、コックピットの、もうひとつの席だ。 コパイロット、と書いてしまうと業界用語の流行に乗っかりすぎるけれど、構造としては、それに近い。過去の自分が、副操縦士として、隣に座ってくれている状態。

これが、知識ではなく、知恵、ということの、僕なりの絵だ。

仮の閉じ

道具は、できた。0.1.0、と僕はそれに番号を付けた。「動くだけ」のバージョン、という意味だ。

毎朝、僕はそれを使って、過去の自分と会う。社長や、支配人や、現場のスタッフと、過去に話したこと、決めたこと、迷ったこと——全部を、AI が、芋づるで呼び戻してくれる。「前にも言ったでしょ」は、もう、僕の口癖から、消えた。

けれど、これを作るうちに、もうひとつ気づいたことがある。

知恵の道具は、知識の道具とは、設計の原則がまったく違う、ということだ。たとえば——僕のこの第二の脳には、「削除」という機能が、ない。あえて、付けなかった。「全件再構築」も、しない。inject（書き込み）と retrieve（読み出し）は、設計上、はっきり、分けてある。

なぜ、そうしたか。

次回——osaken-4——で、その話をします。知恵の OS を支える、4 つの原則を。「削除しない」という設計が、なぜ、経営者にとって、決定的に大事なのかを。

雲の上の青空まで、もう少し、ご一緒させてください。

最後に、型の話。創刊号と前号は「空（事実）→雨（解釈）→傘（打ち手）」で書いた。今日は、型を替えた。ポストモーテム（障害報告書）——症状（Symptom）→ 根本原因（Root Cause）→ 回収（Payoff）→ 設計思想（Design Stance）。障害対応の文書の型で、ひとつの意思決定の来歴を開いた。今日も、型ごと、持って帰ってください。

追伸。

ひとつ、お知らせを。この「TSUBASA」は、近いうちに、Substack から別の場所へ引っ越します。

理由は、今日の号と地続きです。僕は道具を選ぶとき、ひとつの基準を持つことにしました——「AI が操縦席に座れない機体には、乗らない」。この手紙は、僕と AI が二人で組んで書いています。ところが、いまの機体は、AI が操縦席に座れない設計でした。それなら、機体を替えるだけです。

引っ越し先が決まったら、この場所で、ちゃんとお知らせします。手紙は、続きます。

🎬 動画版「AIはまだ、クッキーを発明していない。」

― オサケン

🎧 Podcast

前号の最後に「次回から5回は、第二の脳の話をする」と書いた。あの約束は守ります。ただ、その前に一通だけ、挟ませてほしい。第二の脳は、コクピットのいちばん奥に組み込まれている部品だ——と、僕は前号に書いた。部品の話をする前に、機体の設計図を渡しておきたい。今日は、その一通です。

雨の朝、7時

雨の朝の話をする。僕が手伝っている、あるゴルフ場の話だ。

朝7時、小雨。フロントの電話が鳴り始める。「今日、どうしようかな」——会員さんからの電話だ。キャンセルするか、来るか、迷っている。受話器を持ったスタッフは、3秒で、何かを言わなければならない。

このゴルフ場には、立派なBIがある。

昨日までの来場者数も、予約の埋まり具合も、売上も、画面を開けば並んでいる。けれど、受話器のこちら側で、その画面は開かれない。開いている時間が、ない。

そして、もっと根が深い問題がある。その瞬間にスタッフが本当に欲しい情報——この会員さんは、雨の日をどうしてきた人か。前回の来場で、何を話していたか。今日の午後の空き枠。雨雲が抜ける時刻——は、BIのどの画面にも、ひとまとまりでは存在しない。

数字は、ある。でも、その瞬間には、無い。

「見せ方」の科学は、もう完成している

なぜこうなるのか。BIツールの機能不足ではない。機能なら、むしろ過剰なくらいある。

じつは「見せ方」の科学は、とっくに完成している。復習は、表一枚で済む。

「見せ方」の科学 ── 完成年表
──────────────────────────
Tufte        チャートの無駄を削れ
Few          知覚の科学で設計しろ
Knaflic      探索用と説明用を
             混ぜるな
Cairo        グラフは嘘をつく
Hichert      表記を標準化しろ(IBCS)
Shneiderman  Overview first
             （探索の型）
──────────────────────────

原則は、全部揃っている。いまのBIベンダーが、読んでいないだけだ。……と書くと、こう返ってきそうだ。

「そもそもBIは経営の道具でしょう。フロントを救うのは、BIの仕事じゃない」

いいツッコミだ。でも、教科書はその先まで行っている。Stephen Few は同じ本の第2章で、ダッシュボードを役割で3つに分けている。

Few の3階層（2006）
──────────────────────────
Strategic    経営      ✅ KPIを俯瞰
Analytical   リーダー  ✅ 深掘り分析
Operational  現場      ✅ リアルタイム
                          監視
──────────────────────────

経営・リーダー・現場。現場の階層まで、20年前に定義済みだ。ぜんぶ、埋まっている。

——埋まっているように、見える。今日の本題は、ここからだ。

Few の言う Operational は、「リアルタイムの監視画面」のことだ。管制室。コールセンターのSV席。工場のライン監視盤。つまり「見張る持ち場」がある仕事のための道具で、主語はまだ「画面を見ていられる人」なのだ。

雨の朝のフロントに、見張る持ち場は、無い。受話器と、会員さんがいるだけだ。

公平のために言うと、ベンダーも気づき始めている。Power BI には、閾値を切ったら知らせてくれるデータアラートがある。Tableau は Pulse で、数字の変化を Slack やスマホへ push するところまで来た。方向は、正しい。ただ——押してくるのは、数字の変化だ。雨の朝に欲しいのは、会員Aさんの文脈だ。閾値は、全体の数字につく。迷いは、一人につく。

だから、埋まっていない欄は「階層」ではない。「届き方」だ。

届き方
──────────────────────────
人がデータへ歩く      ✅ 完成
（経営も現場も・監視も含む）
判断材料が人へ歩く    ␣␣
──────────────────────────

探索（Exploratory）も、説明（Explanatory）も、監視（Few の Operational）も、ぜんぶ上の行——「人がデータへ歩く」側の科学だった。空欄は、下の行にある。

この空欄に、名前を付けよう。教科書に敬意を払って Operational（実戦） の名は残す。ただし、定義を書き換える。「リアルタイムに監視できる」ではなく——現場の迷いの一瞬に、判断材料のほうから届く。

HCIの大家 Ben Shneiderman は、可視化設計の原則を、マントラの形で残している。

Overview first, zoom and filter, then details on demand.
（まず全体像。絞り込んで。詳細は要求に応じて。）

BIツールは、いまもこの思想で作られている。全体像から入って、人間がデータへ降りていく。Beyond Dashboard は、これを反転する。

Moment first, context attached, then action on demand.
（まず瞬間。文脈は添えて。打ち手は求めに応じて。）

人がデータへ歩くのではない。判断材料が、人の迷いへ歩いてくる。

設計図は、一行で書ける

では、何を作るのか。設計図は一行だ。

Beyond Dashboard ＝（BI ＋ Ontology）× MOT

三つの項を、順に。

BI は、数字の基盤。足し算の左側。捨てない。前号で「BIが悪いのではない、read-onlyなのが問題だ」と書いたとおり、数字を並べる仕事はBIが一番うまい。

Ontology は、意味の地図。会員と来場履歴がつながる。来場履歴と、前回の発言がつながる。発言と、不満がつながる。不満と、次の一手がつながる。——タグ検索やベクトル検索は「資料を探す」には強い。でも、現場の判断は「この会員さんの過去・現在・未来をまたいで組み立てる」仕事だ。平らな検索では、またげない。だから、つながりそのものをデータにする。それが意味の地図だ。

MOT は、掛け算。Moment of Truth——真実の瞬間。マーケティングの古典用語だ。エンジニアの世界で MOT と言えば技術経営（Management of Technology）だが、別物です。

語源は1980年代。経営危機の北欧航空を立て直したCEO、ヤン・カールソンの本のタイトルだ。彼は自社をこう数え直した。うちの会社は、飛行機の集まりではない。「顧客と社員が向き合う、平呇15秒」の集積でできている。会社の評価は、広告でも機材でもなく、その15秒の一つひとつで決まる——それが、真実の瞬間。

……気づいただろうか。雨の朝の、あの3秒のことだ。

MOTシナリオは、その瞬間をこう定義する。誰の瞬間か。引き金は何か。その人は、何に迷っているか。AIは、何を準備しておくか。人間が何を決め、何を伝えるか。そして——言ってはいけない正論は何か。ここまで決めて初めて、意味の地図は現場で動く。MOTとは、AIに対する出力契約だ。

掛け算にしたのには、理由がある。MOTがゼロなら、どれだけ立派な（BI＋Ontology）も、ゼロになる。画面の前に座れる人だけの、賢いダッシュボードで止まる。

三つの項が掛け算になると、現場では、こうなる。雨の朝、AIが受話器のスタッフに差し出す一枚だ。

── 08:47 着信 ── 会員Aさん ──────
在籍      12年目
来場      月2回ペース
          雨天時 7勝2敗
          （雨でも来る人）
前回発言  「最近、朝イチは冷える」
          （6/28 フロントにて）
今日      13:00〜 2枠空き
          雨雲は12時台に抜ける予報
──────────────────────────
提案      「午後からなら上がりそう
           です。13時スタートは
           いかがですか」
⚠ 言わない 「キャンセル規定では
           前日までとなって
           おりますので」
──────────────────────────

上の四行が Ontology（つながった過去・現在・未来）。下の二行が MOT（出力契約）。最後の「⚠ 言わない」まで契約に入っているのが、現場の道具である証拠だ。規定の話は正しい。正しいが、雨の朝の受話器で言う言葉ではない。

実装の一手も、教科書と逆にする。全社オントロジー設計から始めない。雨の朝、という1シナリオから逆算する。合否判定は、一つでいい。

その瞬間に、在籍年数・来場推移・前回の発言・今日の空き枠・天気が、ひとまとまりで揃うか。

揃えば、意味の地図は機能している。揃わなければ——その欠けた欄こそが、Ontology 第一版の要件定義だ。欠損は失敗ではない。仕様書だ。

前号のdiffを、覚えているだろうか。BIに + 操縦系 + 自動操縦 + 交信 の3行を足す、と書いた。今日の設計図は、あの3行が実際に何でできているかの、最初の答えだ。

次回から、約束の5回

次回から、約束していた5回を始める。第二の脳——過去の自分の判断を呼び戻す、知恵のOS。今日渡した機体の設計図で言えば、いちばん奥の部品。意味の地図の語で言えば、「つながり」を貯めて返す記憶装置そのものだ。

雨の朝カードの4行目までを、裏で準備している誰かが、機体のどこかに要る。その話です。

最後に、型の話。今日も「空（事実）→雨（解釈）→傘（打ち手）」の型で書いた。空（雨の朝の実測）→ 雨（見る科学の完成と、届き方の空欄）→ 傘（(BI＋Ontology)×MOT と、雨の朝カード）。型ごと、持って帰ってください。

動画で振り返る

🎦 スライド動画版「判断材料が歩いてくる」

― オサケン

小暑初候、七月七日。暑い風が、届きはじめる頃。

絵に添えた歌——

夏の風　わが袂にし　つつまれれば
愛しき人の　つとにしてまし

袂に包んだ夏の風を、愛しい人への土産（つと）に。

筆で季節を一枚ずつ。メルマガの合間に、こういうものも置いていきます。

― オサケン

English companion

Warm Wind Arrives.

Around July 7, the old Japanese calendar says:
warm wind begins to arrive.

I like that.

Not “summer begins.”
Not “the temperature rises.”
Just — the wind changes.

The poem beside the painting says something like this:

I tuck the summer wind into my sleeve,
and wish I could bring it
as a small gift
to someone I love.

That is all.

A piece of season,
folded into paper.

OSを選ぶように、お好きな方をどうぞ。中身は同じ話——話し方だけが違います。

⬇ 非エンジニア版（The Business Cockpit）

手描きスケッチのやわらかい一冊。絵と物語で、コクピットの話を。——macOS版のつもりで。

非エンジニア版をダウンロード

⬇ エンジニア版（Beyond BI: Cockpits）

ダークモードの設計図調。ETL、DWH、そして「The Monday Loop」という沈黙のバグ。——Linux版のつもりで。

エンジニア版をダウンロード

どちらも本文と同じ「空（事実）→雨（解釈）→傘（打ち手）」の型で組んであります。読み比べると、同じ話が相手によってどう姿を変えるか——それ自体が、FDEの練習問題です。

― オサケン

（↑1枚で分かる創刊号。絵は誰でも読めるスケッチで——本文より先に、絵から入ってもらっていい）

🎧 聴いて済ませたい人は、こちら（AIふたりが今日の話を深掘り対談）

【空】数字は並んでいる。でも、会社は飛んでいない。

月曜の朝の会議室を思い浮かべてほしい。

スクリーンに、先週の数字が映る。売上、客数、前年比。グラフは色分けされ、ご丁寧に矢印までついている。作った本人は、日曜の夜までかかったはずだ。

経営者はしばらく眺めて、言う。「で、どうする?」

沈黙。誰かが「引き続き注視します」と言う。会議は終わり、現場は先週と同じように動く。数字は読まれた。でも、何も起きなかった。

BI——Business Intelligence。立派な言葉だ。可視化、ダッシュボード、KPIモニタリング。この20年で道具は見違えるほど進化した。TableauもPower BIもある。データは湖のように貯まっている。

なのに、である。立派なBIがある会社ほど、冒頭の月曜日を毎週やっている。数字を見る時間は増えたのに、動きにつながらない。KPIを追えば追うほど、なぜかみんな疲れていく。

僕はこの光景を、長いこと気持ち悪いと思ってきた。マーケティングの仕事をしながら、数え切れないほど「立派な資料」を見て、作りもして、そのたびに思っていた。

この気持ち悪さの正体は、何だ?

【雨】BIがread-onlyだから、だ。

正体は、権限の話だと思っている。

クルマのダッシュボードを思い出してほしい。速度計、燃料計、水温計、警告灯。あれは「読む」ための装置だ。よくできている。でも、ダッシュボードがハンドルを切ってくれることはない。読んだあとどうするかは、ぜんぶ運転席の人間の仕事だ。

飛行機のコクピットは違う。

計器の隣に、操縦桿がある。自動操縦があって、雲の中でも夜でも高度を保って飛ぶ。そして無線がある——管制塔と交信しながら、自分の位置を確かめ、次の指示を受け取る。コクピットは「読む」装置ではない。「飛ばす」装置だ。

差分を書くと、たった3行になる。

  表示（数字・グラフ）
+ 操縦系（数字が打ち手につながる）
+ 自動操縦（AIが分析し、提案してくる）
+ 交信（現場の声が入り、返っていく）

ダッシュボードにこのdiffを当てたものが、コクピットだ。僕はそれを Beyond BI と呼ぶことにした。3行を、順に説明する。

操縦系。 数字が「見て終わり」にならないための接続だ。たとえば客足の弱い日が計器に浮かんだら、その画面から「では何をするか」が始まるようにする。警告には打ち手の選択肢がぶら下がり、決めたことは記録され、翌週その結果がまた計器に返ってくる。表示と行動が、同じ機体の中でつながっている状態。

自動操縦。 人間が見ていないあいだも、AIが計器を読んでいる。夜のうちに先週分を分析して、朝には「この客層が静かです。理由はたぶんこれ。試すならこの3つ」という提案が置いてある。人間のやることは、承認するか、直すか、却下するか。判断は人間、下読みはAI。

交信。 これが一番誤解されている。コクピットが強いのは、計器が多いからではない。管制塔と話せるからだ。経営で言えば、現場の声。スタッフの気づき、顧客の一言、クレームの生の言葉。それが構造化されて機体に入ってくる。数字は「何が起きたか」を教えるが、声は「なぜ起きたか」を教える。両方入って、はじめて飛べる。

ここで、疑問が出るはずだ。そんなことは30年前から分かっていたのではないか。なぜBIは、ずっとread-onlyのままだったのか。

答えは単純で、「+」の3行が、人間にしかできなかったからだ。数字と打ち手をつなぐのは経営企画の優秀な誰か。分析して提案するのはアナリスト。現場の声を拾って構造化して返すのは——高すぎて、誰もやれなかった。write側は全部、高くて、遅くて、疲れる人間の仕事だった。だから世界は、read側だけを30年磨き続けた。グラフは美しくなった。会社は飛ばないままだった。

変わったのは、この2年だ。AIが「+」の3行を安くした。分析も、提案も、声の構造化も、夜通し働いて文句を言わない専門家が現れた。だから今、ダッシュボードはコクピットに作り替えられる。歴史上はじめて、write権限が現場の手に降りてきた。

【傘】だから、作る。作れる人を、増やす。

ここからは、実地の報告だ。

僕は68歳で、エンジニアではない。SQLも統計も専門外だ。それでもいま、あるゴルフ場の経営現場で、BIをコクピットに作り替えている。

できてきたものを並べる。売上と予約と天気が一枚で見える計器盤。予約の危ない日が色で浮かび上がる早期警戒。毎週の報告書は、AIが数字と現場の声を読んで下書きする。会議の議事録は、AIが勝手にチャンクして、ベクトル化して、検索できる知恵になった——過去の判断が、呼び出せる。そしてAI支配人——LINEの中で報告を上げ、予約の受付を覚えようとしている、人間ではない支配人が働きはじめた。

自慢がしたいのではない。逆だ。68歳の非エンジニアでも、ここまで作れてしまう、という報告がしたい。

作れている理由は、一つしかない。専門家の部分は、AIがやってくれるからだ。SQLはAIが書く。統計はAIが選ぶ。画面の設計もAIが提案してくる。僕は毎日、自分の知らない分野の専門家を何人も雇っているようなものだ。給料は、月々のAI利用料だけ。

ただし、条件がある。ここを外すと嘘になるので、ちゃんと書いておく。

どこか一点で、本物であること。

僕の場合は、マーケティングだ。昔、GORAというゴルフ場のオンライン予約サービスの0-1を作った。ベルトラという海外ツアー予約の会社も、ゼロから立ち上げて、レールを敷いた。走らせたのは僕じゃない。僕はどうやら昔から、走らせる人ではなく、レールを敷く人なのだ。それを40年やってきたから、AIが出してきた分析に対して、「数字はきれいだけど、商売として変だ」が分かる。一つの分野でエキスパートの気持ちと勘所を知っているから、他の分野の”AIという専門家”を導ける。全分野の専門家になる必要は、もうない。でも、どの分野でも本物でない人に、専門家AIは使いこなせない。出力の良し悪しを、判定できないからだ。

そのうえで、AIに代われないものが三つ残る。

聴く力。 現場の人が、本音を安心して話してくれるかどうか。データレイクには絶対に入っていない情報が、そこにある。

思い描く力。 まだ無い画面、まだ無い仕事の流れを、「こう在るべきだ」と描けるか。AIは要件があれば実装してくれる。でも要件は、思いからしか生まれない。

違和感に気づく力。 「この数字、きれいだけど、なんか変だ」。この一言が、コクピットを机上の空論から守る。

技術はAIが補う。この三つだけは、誰も代わってくれない。

現場に降りて、声を聴いて、生きたコクピットに変える人。最近、名前がついたらしい。FDE（Forward Deployed Engineer）という。半分エンジニア、半分・経営の参謀、半分・ただの聴き手。合計すると1.5人分だが、AIを翼にすれば、一人でやれる。言ってみれば、経営コクピットのレールを敷く人だ。僕はその先生でもレジェンドでもない。ただ、少しだけ先を歩いている先輩ではあると思う。

この連載は、FDEになりたい人に宛てて書く。数字を見張る人でも、資料を作る人でもなく、現場とAIのあいだに立って、会社を飛ばせる人になりたい人へ。僕が実際に作り、つまずき、直していく過程を、そのまま見せる。名前は TSUBASA。翼は二枚で一対だ——僕が「なぜ」を書き、相棒の内村さんが「どう作るか」を書く。彼の実装ノートは、別便で飛ぶ。

今日の話を、8コマで。

最後に、型の話。

今日の文章は「空（事実）→雨（解釈）→傘（打ち手）」という型で書いた。コクピットのチェックリストと同じで、型は思考を速くし、抜けを防ぐ。この連載は毎回、なにかの型で書く。空雨傘のほかにも、同じ出来事を経営者・管理職・スタッフ・顧客の目線で見直すリレー型や、Goal→Reality→Options→Willで意思決定を追うGROW型を用意している。中身と一緒に、型も持って帰ってほしい。

次回から5回は、いま僕が本気で作っている道具の話をする。第二の脳——といっても、メモを溜めるノート術ではない。知識ではなく、知恵を扱うOS。過去の自分の判断を、AIが呼び戻してくれる装置。そして実は、コクピットのいちばん奥に組み込まれている部品でもある。

動画で振り返る

🎬 スライド動画版「TSUBASA 創刊号：BIはread-onlyだ。」

📎 お手元資料（スライド2種）：非エンジニア版／エンジニア版のダウンロードはこちら——お好きな方をどうぞ。

― オサケン