20年以上前、NTT時代に作った資料を見返していた。

表紙には「最終報告」とある。
日付は、平成16年2月24日。

いまから見ると、かなり古い資料だ。

青いグラデーション。
少し硬い表組み。
大企業の改革資料らしい言葉。

意識改革。
営業活動。
収益管理。
危機意識。
顧客満足度調査。
個社別戦略。
ステージチェック。
工程別収支。
タイムレポート。

当時の自分は、それを法人営業改革の資料として作っていた。

営業の動き方を変える。
顧客対応を改善する。
提案力を高める。
属人的な営業を組織化する。
収益を見えるようにする。

たぶん、そういう資料だった。

でも、2026年のいま、Decision Stackの観点から読み返すと、少し違って見える。

これは営業改革の資料ではなかったのかもしれない。

むしろ、法人顧客に向き合う組織が、顧客の声をどう受け取り、どう解釈し、どこで止まり、どこで実行し、その結果をどう記憶するか、という資料だった。

当時は、それをSFAやCRMと呼んでいた。

いまなら、それはDecision Stackと呼べる。

営業改革ではなく、意思決定の問題だった

資料の中では、施策が大きく三つに分かれている。

意識改革系施策。
営業活動系施策。
収益管理系施策。

意識改革系には、危機意識醸成、顧客満足度調査、将来ビジョンの策定、実績ベースの評価制度などがある。

営業活動系には、営業ツールの整備、ステージチェックミーティング、個社別戦略策定、管理ツールの整備などがある。

収益管理系には、工程別・商品別収支の管理、タイムレポートによる個人別採算管理などがある。

いかにも2000年代前半の改革資料だ。

強い言葉が多い。
危機感を持て。
変われ。
実績で評価する。
収支を見える化する。

いま読むと、少し息苦しさもある。

でも、その奥にあった問いは、今でもほとんど古びていない。

顧客は何に困っているのか。
営業はそれを理解しているのか。
導入後の不安は誰が拾っているのか。
障害が起きた時、誰が判断しているのか。
現場で起きたことは、次の提案に戻っているのか。
優秀な営業の勘は、組織の知識になっているのか。

つまり、問題は営業担当者の能力だけではなかった。

組織の中で、意味が生成されていなかった。
解釈が分岐していなかった。
信頼できる判断条件がなかった。
止まるべき場面で止まれていなかった。
実行結果が、組織の記憶に戻っていなかった。

それは、Decision Stackの問いそのものだった。

顧客の声は、意味になる前に消えていた

ヒアリング調査の資料も残っている。

そこには、顧客のかなり生々しい声が書かれている。

提案の頻度が少ない。
見積りが遅い。
サービス料金や機能概要だけの説明で、他社とどう違うのかがわからない。
課題のヒアリングではなく、機能説明に終始している。
業界ニーズや業界課題を把握した上での具体的な提案が欲しい。
問題として感じている点を開示しても、それについての改善提案がない。

かなり厳しい。

でも、これは単に「営業が弱い」という話ではない。

顧客の中には、まだ言葉になりきっていない不安や期待がある。
それを拾うのが営業の役割だった。

ただし、拾っただけでは足りない。

顧客の声は、意味にしなければ消えてしまう。

「見積りが遅い」という声は、単なる不満ではない。
その裏には、意思決定のリードタイム、社内稟議、競合比較、導入リスクへの不安がある。

「機能説明ばかり」という声は、単なる説明不足ではない。
その裏には、顧客が自社の課題をどう言語化すればよいかわからない、という問題がある。

「他社との違いがわからない」という声は、単なる競合比較ではない。
その裏には、自分たちが何を基準に選べばいいのか、顧客側にも判断軸がないということがある。

Decision Stackで言えば、ここは意味生成の層である。

顧客の発言を、そのまま処理してはいけない。
一つの答えにしてはいけない。
まずは、そこに複数の意味があることを認める必要がある。

価格の問題なのか。
信頼の問題なのか。
導入後の不安なのか。
社内説明の難しさなのか。
競合との差別化なのか。
担当者との関係性なのか。

意味は一つではない。

当時の資料では、それを顧客満足度調査やヒアリングシートとして扱っていた。

2026年の言葉で言えば、それはMeaningの入口だった。

業界別ニーズは、解釈のための地図だった

別の資料には、産業別情報化ニーズがまとめられている。

建設。
電気・ガス。
運輸。
通信。
卸売。
小売。
情報サービス。
銀行・証券。
生保・損保。
リース。
その他金融。

業種ごとの投資動向や情報化ニーズが並んでいる。

当時は、これを営業資料として見ていた。
どの業界にどんなIT投資ニーズがあるのか。
どの業界が伸びそうか。
どの業界にネットワークサービスを提案できるか。

でも、今見ると、これは単なる市場調査ではなかった。

顧客の発言を解釈するための地図だった。

同じ「コストを下げたい」という言葉でも、建設業と金融業では意味が違う。
同じ「安定したネットワークが欲しい」という言葉でも、小売と通信業では背景が違う。
同じ「システムを更新したい」という言葉でも、運輸と生保ではリスクの種類が違う。

顧客の声は、業界文脈の中で解釈しなければならない。

個社の事情。
業界構造。
規制。
商流。
人手不足。
投資余力。
競争環境。
顧客の顧客。

それらを重ねた時に、初めて発言の意味が変わる。

Decision Stackで言えば、ここは解釈層である。

Meaning OSの仕事は、意味を一つに確定することではない。
文脈に応じて、どの解釈が妥当かを選ぶことだ。

2004年の資料では、それを「業界別ニーズ一覧」や「商品導入事例集」や「業種別情報化ニーズ」と呼んでいた。

でも、やろうとしていたことは近い。

顧客の声を、その会社だけの声として処理しない。
業界の中に置き直す。
時間軸の中に置き直す。
競争環境の中に置き直す。

つまり、営業資料は解釈のための地図だった。

ステージチェックは、HOLDの原型だった

資料の中で、特に気になったのはステージチェックミーティングである。

管理職が部下の営業活動状況を週次などで確認し、問題点の指摘やアドバイスを行う。
営業活動の型を作る。
商談熱度を確認する。
正しいコーチングを行う。

当時の言葉では、営業管理である。

でも、Decision Stackから見ると、これはTrust OSに近い。

つまり、実行してよいかどうかを判断する層である。

この顧客に、この提案を出してよいのか。
顧客課題を本当に理解しているのか。
価格だけで押していないか。
導入後に問題が起きないか。
保守体制は確認できているか。
社内の関係部署は連携できているか。
このまま進めるべきか。
いったん止めるべきか。

本来、ステージチェックとは、営業を前に進めるためだけの会議ではない。

進めてはいけない案件を、止めるための会議でもある。

ここに、HOLDの原型がある。

当時の営業改革は、どうしても「もっと売れ」「もっと訪問しろ」「もっと報告しろ」に見えやすい。
でも、Decision Stackで読み替えると、主語が変わる。

営業担当者を動かす改革ではない。
組織が誤った意思決定をしないための構造設計である。

HOLDとは、単なる保留ではない。

判断を一時的に止めること。
不確実性を消さずに扱うこと。
人間が介入する余地を残すこと。
止めた理由を記録すること。

営業にも、HOLDは必要だった。

顧客の要件が曖昧なまま提案しない。
実績がないことを、あるように言わない。
保守体制が未確認のまま契約しない。
コスト競争力が弱いのに、安心感まで毀損するような運用をしない。
問題が起きた時に、たらい回しにしない。

営業におけるHOLDとは、売らない勇気でもある。

それは「売らないPR」にも近い。

売る前に、立ち止まる。
提案する前に、問いを立てる。
進める前に、顧客にとっての意味を確認する。

20年前の資料には、まだHOLDという言葉はなかった。

でも、ステージチェックという形で、その小さな芽はあった。

SFA/CRMは、DeciLayerになりきれなかった

2004年当時、SFAやCRMはかなり新しい言葉だった。

営業活動をシステムで管理する。
顧客情報を共有する。
商談進捗を見える化する。
リテンションを高める。
中小企業向けの営業プロセスを効率化する。

それは正しかった。

ただ、当時のSFA/CRMには限界もあった。

入力するのは人間だった。
更新するのも人間だった。
読むのも人間だった。
活用できるかどうかも、人間次第だった。

つまり、SFA/CRMは記録の器ではあったが、意思決定の流れそのものではなかった。

2026年のAI時代には、ここが変わる。

AIは、顧客の声を要約できる。
議事録を整理できる。
問い合わせ履歴を横断できる。
障害履歴と営業履歴をつなげられる。
FAQを更新できる。
次の提案候補を出せる。

ただし、そこで終わってはいけない。

AIが答えを出すことよりも、重要なのは、その答えを実行してよいかどうかである。

ここにDeciLayerがある。

DeciLayerとは、推論結果をCRMや業務プロセスへ接続する実行層である。

でも、それは単なる自動実行ではない。

意味が生成されたか。
解釈は妥当か。
信頼できるか。
HOLDすべきか。
誰が承認するか。
何を記録するか。
どの業務へ渡すか。

この流れがあって、初めて実行になる。

2004年のSFA/CRMは、顧客情報を入れる箱だった。

2026年のDeciLayerは、意思決定を業務に接続する層になる。

SFAの夢は、AIエージェントに引き継がれた。
でも、本当に引き継がれるべきなのは、システムではない。

顧客を忘れないこと。
現場を忘れないこと。
失敗をなかったことにしないこと。
人の勘を、組織の記憶に変えること。

中小企業対応が弱かったのではない

ヒアリング資料では、大規模ユーザーと中小規模ユーザーの差がはっきり出ている。

大規模ユーザーには、比較的丁寧な対応ができている。
一方で、中小規模ユーザーでは、営業マナー、定期的な営業活動、問題発生時の迅速な対応、報・連・相に課題がある。

これも、いま読むと別の見え方をする。

中小企業対応が弱かったのではない。

中小企業向けのDecision Stackが存在していなかったのだと思う。

大企業には、暗黙のDecision Stackがある。

担当営業がいる。
定期訪問がある。
社内で情報共有される。
問題があれば人が動く。
稟議もエスカレーションもある。
保守も営業も、何となく重要顧客として扱う。

つまり、大企業には、人間による意味生成、解釈、信頼制御、実行の流れがあった。

でも、中小企業には、それがなかった。

だから、顧客の不満は意味として拾われない。
営業の理解は解釈として深まらない。
問題が起きても、HOLDされない。
障害対応も、組織的な判断ではなく、場当たり的な対応になる。
そして実行結果は、次の営業や保守に戻らない。

顧客から見ると、これはとても不安だ。

開設後に連絡がない。
問い合わせ先がわからない。
専門用語で説明される。
カスタマーセンターが分かれている。
作業員が来るのが遅い。
原因究明に時間がかかる。
営業と保守の間で情報がつながっていない。

これは通信回線の問題ではない。

顧客接点の意思決定が、設計されていない問題である。

中小企業向けにこそ、Decision Stackが必要だった。

人を増やすのではなく、判断の流れを設計する。
大企業だけに暗黙で存在していた判断構造を、より小さな顧客にも適用できるようにする。
そのために、SFA/CRMがあり、FAQがあり、業界別ニーズがあり、ステージチェックがあり、カスタマーセンター連携があった。

当時は、それを営業改革と呼んでいた。

でも、実際には、顧客接点OSの設計だった。

経済圏という、もう一つのDecision Stack

この話は、法人営業だけに閉じていない。

2004年の資料を読み返しながら、同時に思い浮かんだのは「経済圏」という言葉だった。

楽天経済圏。
au経済圏。
PayPay経済圏。
dポイント経済圏。
そして、NTTグループが見ているであろう、もっと大きな社会インフラとしての経済圏。

通信会社は、もはや通信だけを売っていない。

スマートフォン。
決済。
ポイント。
銀行。
証券。
保険。
電気。
EC。
映像。
旅行。
広告。
ID。
データ。

これらをつなぎ、一人のユーザーの生活の中に、何度も接点を作っていく。

楽天の経済圏の図を見ると、その構造がよくわかる。

中心には、Brand、Membership、Data、Communicationsがある。
その外側に、E-Commerce、Card & Payment、Banking、Securities、Insurance、Mobile、Digital Content、Travel、Sports & Cultureなどが広がっている。

これは単なる事業ポートフォリオではない。

生活の中で発生する無数の意思決定を、ひとつのブランド、ひとつのID、ひとつのポイント、ひとつのデータ基盤に引き寄せていく構造である。

どこで買うか。
どのカードを使うか。
どの銀行にお金を置くか。
どの証券口座で投資するか。
どの保険に入るか。
どの通信回線を使うか。
どの動画を見るか。
どこへ旅行するか。

生活の意思決定が、経済圏の中に吸い込まれていく。

ここにもDecision Stackがある。

ユーザーの行動がデータになる。
データが意味を持つ。
意味がレコメンドになる。
レコメンドが選択肢になる。
選択肢が決済につながる。
決済がポイントになる。
ポイントが次の行動を促す。
そして、その行動がまたデータになる。

経済圏とは、生活者のDecision Stackを企業側が設計する試みなのだと思う。

もちろん、それは便利でもある。

IDがひとつで済む。
ポイントが貯まる。
支払いが楽になる。
サービス間の移動がなめらかになる。
生活の中で迷う場面が減る。

でも、同時に少し怖さもある。

選ぶ前から、選択肢が並べられている。
考える前から、おすすめが出る。
比較する前から、ポイント還元で誘導される。
生活の断片が、経済圏の内部で意味づけされる。

つまり、経済圏は便利なサービスの束であると同時に、生活者の判断を包み込む構造でもある。

ここでDecision Stackが必要になる。

AIやデータによって、人の選択をただ速く誘導するのではなく、どこでHOLDするか。
どこで人間が考える余白を残すか。
どこで説明可能性を持たせるか。
どこで、売らない判断をするか。

経済圏が強くなるほど、企業には「判断を預かっている」という責任が生まれる。

ポイントを配ること。
キャンペーンを打つこと。
レコメンドを出すこと。
与信すること。
保険を提案すること。
投資を促すこと。

それらはすべて、顧客の意思決定に介入する行為である。

通信会社が経済圏を狙う理由は、通信料金だけでは成長できないから、というだけではない。

通信会社は、すでに人の生活の入口を持っている。

スマートフォン。
ID。
請求。
位置情報。
決済。
家族契約。
店舗網。
法人契約。
サポートセンター。
ネットワーク。

通信会社は、生活と産業の両方に接点を持っている。

だから、通信会社は経済圏を作りたくなる。

回線の上に、生活を乗せる。
IDの上に、決済を乗せる。
決済の上に、金融を乗せる。
金融の上に、ポイントを乗せる。
ポイントの上に、次の行動を乗せる。

この構造は、2004年の法人営業改革資料とは一見離れているように見える。

でも、根は同じである。

顧客の声をどう拾うか。
顧客の行動をどう理解するか。
顧客の判断をどう支えるか。
顧客接点をどう記憶するか。
そして、進めてよい判断と止めるべき判断をどう分けるか。

法人営業では、それがSFA/CRMだった。
生活者向けサービスでは、それが経済圏になった。

どちらも、顧客接点をめぐるDecision Stackである。

IOWNによって、境界が溶ける

NTTの話に戻ると、さらに大きな補助線がある。

IOWNである。

IOWNは、単なる高速ネットワーク構想ではない。

All-Photonics Network。
Digital Twin Computing。
Cognitive Foundation。

そこにあるのは、通信、計算、現実世界の制御を、より深いレベルで結び直そうとする発想である。

これは、ITとOTの境界が溶けるということでもある。

ITは、情報の世界だった。
OTは、現場の世界だった。

ITには、データ、アプリケーション、クラウド、ID、業務システムがある。
OTには、工場、設備、道路、電力、物流、医療機器、センサー、ロボットがある。

これまでは、情報システムと現場システムは、どこか別のものとして扱われてきた。

でも、IOWN的な世界では、その境界が薄くなる。

現場の状態がデータになる。
データがデジタルツインになる。
デジタルツインが予測する。
予測が制御に戻る。
制御の結果が、また現場からデータとして返ってくる。

つまり、現実世界そのものが、意思決定のループに入ってくる。

ここでは、Decision Stackはもはや営業や経済圏だけの話ではない。

工場の設備を止めるか。
配送ルートを変えるか。
電力をどこに振り分けるか。
通信障害をどう迂回するか。
医療機器のアラートをどう判断するか。
都市の人流をどう制御するか。
災害時にどの情報を優先するか。

これらはすべて、実行を伴う判断である。

AIが推論する。
システムが予測する。
ネットワークがつなぐ。
現場機器が動く。

だからこそ、HOLDが重要になる。

実行してよいのか。
止めるべきか。
人間に戻すべきか。
別の解釈を確認すべきか。
社会的な影響はあるか。
安全性は担保されているか。
説明できるか。

ITとOTが融合すると、判断の失敗は画面の中で終わらない。

現場が動く。
機械が動く。
都市が動く。
人の生活が動く。

だから、IOWNのような次世代情報通信基盤の上には、Decision Stackが必要になる。

高速であること。
低遅延であること。
大容量であること。
省電力であること。

それらはもちろん重要である。

でも、それだけでは足りない。

高速に間違える社会にしてはいけない。
低遅延で誤った制御をしてはいけない。
大容量で不確かな判断を拡散してはいけない。
省電力であっても、信頼できない意思決定を自動化してはいけない。

IOWNが物理層の未来だとすれば、Decision Stackは判断層の未来である。

光でつながる世界には、止まれる構造が必要になる。

防災デジタルツインという、地域のDecision Stack

デジタルツインの話をすると、もう一つ思い出す事例がある。

NTT東日本が、山形県長井市、NTT e-Drone Technology、NAVER Cloud、韓国水資源公社と進めている、デジタルツインおよびドローンを活用した地域防災強靭化の取り組みである。

これは、とてもNTTらしい。

派手な消費者向けサービスではない。
スマートフォンの料金プランでもない。
ポイント経済圏でもない。

地域の防災である。

ドローンで空撮する。
高精細なデジタルツインを構築する。
水害シミュレーションを行う。
河川水位センサーやカメラの情報を取り込む。
降水や降雪の情報を反映する。
そして、デジタルツイン上で地域の状況を管理し、分析する。

ここでは、現実世界とデジタル空間が重なっている。

川の水位。
降雨。
積雪。
地形。
道路。
避難経路。
カメラ映像。
ドローン映像。
自治体職員の判断。
住民への情報提供。

それらが、一つの判断空間に集まってくる。

これは単なる可視化ではない。

地域のDecision Stackである。

災害時に、どこが危険なのか。
どの地域を優先して確認するのか。
どの道路を通れるのか。
どこに人を送るのか。
どのタイミングで避難を促すのか。
どの情報を住民に出すのか。
どの判断をAIやシステムに任せ、どこで人間が介入するのか。

防災における意思決定は、速さが重要である。

でも、速ければよいわけではない。

間違った避難指示。
過小評価された危険。
見落とされた地域。
現場に届かない情報。
誰も責任を持てない自動判断。

災害時には、判断の失敗がそのまま人の生活に影響する。

だから、防災デジタルツインには、Decision Stackが必要になる。

データを集めるだけでは足りない。
シミュレーションするだけでも足りない。
可視化するだけでも足りない。

そのデータが、何を意味しているのか。
複数の解釈のうち、どれを採用するのか。
どこでHOLDするのか。
どこで人間に戻すのか。
どの判断を実行するのか。
実行した結果を、どう記録するのか。

この流れが必要になる。

たとえば、水位センサーが危険な兆候を示す。
ドローン映像では、ある地域の浸水が確認される。
降雨予測では、さらに水位が上がる可能性がある。
デジタルツイン上では、特定の道路が使えなくなる可能性が示される。

この時、システムは「危険です」と言うだけでは足りない。

それは、どの程度危険なのか。
過去の災害と比べてどうなのか。
どの地域に影響するのか。
避難にはどれくらい時間がかかるのか。
高齢者や移動困難者はどこにいるのか。
現場確認が必要なのか。
すぐに避難情報を出すべきなのか。
いったんHOLDして、別の情報を確認すべきなのか。

ここに判断がある。

デジタルツインは、現実のコピーではない。

現実を判断可能にするための、もう一つの現実である。

そして、もう一つの現実ができると、そこには必ず責任が生まれる。

何を写すのか。
何を写さないのか。
どの粒度で写すのか。
誰が見られるのか。
誰が判断するのか。
誰が止められるのか。

防災のデジタルツインは、都市や地域を「見る」ための技術であると同時に、都市や地域を「判断する」ための技術でもある。

だから、ここでもHOLDが重要になる。

AIが危険を示したからといって、自動的にすべてを実行するわけにはいかない。
人間の勘だけで、システムの警告を無視するわけにもいかない。
両者の間に、信頼制御の層が必要になる。

これは、2004年の法人営業改革資料にあったステージチェックと、構造としては似ている。

営業では、提案を進めてよいかを確認する。
防災では、避難判断や現場対応を進めてよいかを確認する。

対象はまったく違う。

でも、問いは同じである。

この判断は、進めてよいのか。
止めるべきなのか。
別の情報を待つべきなのか。
人間に戻すべきなのか。

Decision Stackは、営業のためだけのものではない。

生活者の経済圏にも必要になる。
法人営業にも必要になる。
そして、地域防災にも必要になる。

通信会社がデジタルツインを扱うということは、単にネットワークを提供するということではない。

地域の現実をデータ化し、判断可能な形に変え、その判断を現場に戻すということである。

これは、ITとOTの境界が溶けるということでもある。

ITの中に、地域が入ってくる。
OTの現場が、データとして立ち上がる。
デジタルツイン上の判断が、現実の避難や復旧に戻っていく。

この時、通信会社は回線会社ではなくなる。

地域の判断インフラを支える会社になる。

NAVER Cloudという、AI実装基盤

長井市の防災デジタルツインの話で、もう一つ見逃せないのがNAVER Cloudである。

NTT東日本。
NTT e-Drone Technology。
NAVER Cloud。
韓国水資源公社。
山形県長井市。

この組み合わせは、少し不思議で、かなり象徴的だ。

日本の地域。
日本の通信会社。
日本のドローン会社。
韓国のクラウド／AI企業。
韓国の水資源管理機関。

一見すると、防災DXのための国際連携に見える。

もちろん、それはその通りである。

でも、Decision Stackの観点から見ると、これはもう少し深い。

地域の現実をデジタルツインにする。
ドローンで現場を撮る。
水位や気象データを重ねる。
AIで解析する。
クラウド上で管理する。
必要に応じて、自治体や現場が判断する。

この流れには、通信、クラウド、AI、現場データ、行政判断が全部入っている。

つまり、防災デジタルツインは、ネットワークだけでは動かない。
AIだけでも動かない。
クラウドだけでも動かない。
現場だけでも動かない。

それらを重ねる基盤が必要になる。

NAVER Cloudは、そこに入ってくる。

NAVER Cloudは、単なるクラウドベンダーではない。

HyperCLOVA Xのような自社LLMを持ち、CLOVA StudioのようなAI開発環境を持ち、企業向けAIサービスや産業別クラウド、データセンターまでを持っている。

つまり、AIを使うための上の層だけでなく、その下にある計算資源、クラウド、データ運用、アプリケーション化までを含めた基盤を持っている。

これは、経済圏の話ともつながる。

楽天経済圏やau経済圏は、生活者の行動をID、ポイント、決済、金融、通信で包み込む構造だった。

一方で、NAVER CloudのようなAIクラウド基盤は、企業や自治体の判断を、AI、データ、クラウド、アプリケーションで包み込む構造である。

生活者向けの経済圏が、消費のDecision Stackだとすれば、
AIクラウドは、業務と地域のDecision Stackである。

ここで重要なのは、AIモデルだけではない。

どこにデータを置くのか。
どのクラウドで動かすのか。
どの言語・文化・制度に最適化されたAIを使うのか。
どの産業のデータを扱えるのか。
どの現場システムと接続できるのか。
どの判断を自動化し、どこで人間に戻すのか。

これらはすべて、技術選定であると同時に、意思決定の設計である。

AI時代には、クラウドは単なるサーバー置き場ではなくなる。

クラウドは、判断が生成される場所になる。

問い合わせが要約される。
映像が解析される。
センサー値が予測される。
災害リスクが可視化される。
業務の次のアクションが提案される。
人間に確認すべき箇所が示される。

つまり、クラウド上で意味が作られ、解釈が走り、実行候補が生まれる。

だからこそ、そこにはDecision Stackが必要になる。

AIクラウドが強くなるほど、企業や自治体の判断はその基盤に依存していく。

どのAIが、どのデータを見て、何を危険と判断したのか。
どのモデルが、どの根拠で、その提案を出したのか。
どこでHOLDしたのか。
誰が承認したのか。
実行後、何が起きたのか。

これを記録できなければ、AIクラウドは便利だが危うい。

特に防災のような領域では、判断の失敗が生活に直結する。

水位。
降雨。
積雪。
地形。
道路。
避難。
復旧。
住民への通知。

これらをAIクラウドが扱う時、重要なのは「AIが賢いか」だけではない。

その判断が説明できるか。
現場が納得できるか。
自治体が責任を持てるか。
住民に伝えられるか。
必要なら止められるか。

AIクラウドは、実行のための基盤であると同時に、HOLDのための基盤でもなければならない。

NTTがIOWNによって、通信と計算と現実世界をつなごうとしているとすれば、NAVER CloudはAIとクラウドとアプリケーションによって、その上で動く判断の環境を作ろうとしている。

一方は、光とネットワークから入る。
もう一方は、AIとクラウドから入る。

でも、防災デジタルツインのような場面では、それらは同じ問いに合流する。

現実をどう写し取るか。
データをどう意味に変えるか。
AIの解釈をどう扱うか。
どこで人間が止めるか。
どの判断を現場へ戻すか。
結果をどう記憶するか。

ここに、AIクラウド時代のDecision Stackがある。

NAVER Cloudがこのプロジェクトに入っていることは、単なる外部ベンダー参加ではない。

地域防災という現実の問題に、AIクラウドが接続されるということだ。

それは、AIが画面の中から出て、地域の判断に入り始めるということでもある。

そして、AIが地域の判断に入るなら、そこには必ず、止まれる構造が必要になる。

通信会社は、回線会社ではなくなる

2004年のNTT資料では、法人営業の対象はネットワークサービスだった。

回線を売る。
VPNを売る。
広域イーサネットを売る。
導入し、保守し、障害対応する。

それは通信会社らしい仕事だった。

でも、2026年の通信会社は、もう回線会社ではない。

通信会社は、経済圏を作る。
IDを持つ。
決済を持つ。
金融を持つ。
ポイントを持つ。
データを持つ。
法人顧客の業務基盤を持つ。
そして、IOWNのような次世代インフラ構想を持つ。

生活者の判断にも入っていく。
企業の判断にも入っていく。
産業設備の判断にも入っていく。
都市や社会インフラの判断にも入っていく。

つまり、通信会社は、接続を売る会社から、判断を支える会社へ変わっていく。

ここで、2004年の資料がもう一度意味を持つ。

当時の課題は、顧客対応だった。
営業の遅さだった。
提案力の不足だった。
カスタマーセンターの分断だった。
保守との連携不足だった。
顧客の声が組織の記憶に戻らないことだった。

でも、その小さな課題の中に、現在の大きな問いがすでにあった。

顧客接点をどう設計するか。
データをどう意味にするか。
判断をどう支えるか。
どこで止めるか。
実行結果をどう記憶するか。

経済圏も、IOWNも、防災デジタルツインも、結局はこの問いに戻ってくる。

生活の経済圏では、人の選択が設計される。
産業のIOWNでは、現場の判断が設計される。
地域のデジタルツインでは、防災と都市の判断が設計される。
法人営業では、顧客接点の判断が設計される。

規模は違う。
対象も違う。
技術も違う。

でも、構造は似ている。

Meaning。
Interpretation。
Trust。
Hold。
Execution。
Memory。

2004年には、その言葉がなかった。

だから、SFA、CRM、顧客満足度調査、ステージチェック、収益管理という言葉で書いていた。

でも、2026年から見れば、それはもう少し大きなものだった。

通信会社が経済圏を作り、IOWNによってITとOTの境界が溶け、AIクラウドが自治体や企業の判断に入り、防災デジタルツインが地域の現実を写し取る時代には、回線の上に判断が乗る。

そして、判断が乗るところには、Decision Stackが必要になる。

通信会社の本当の競争領域は、通信速度だけではない。

どれだけ速くつなぐかではなく、
何を意味として拾い、
どう解釈し、
どこで止まり、
何を実行し、
どう記憶するか。

そこに移っていくのだと思う。

人を責める改革から、構造を見る改革へ

2004年の資料には、今読むと少し強すぎる表現もある。

危機意識を持たせる。
市場価値を評価する。
実績ベースで評価する。
個人別採算を明確にする。

当時の空気としては、よくわかる。

でも、2026年のいま、そのまま持ち込むのは少し危うい。

AI時代は、あらゆるものが見えすぎる。

誰が何時間働いたか。
誰が何件訪問したか。
誰が何通メールを送ったか。
誰がどのくらい利益を出したか。
誰が返信を遅らせたか。
誰が商談を落としたか。

見ようと思えば、いくらでも見える。

だからこそ、見るべきものを間違えてはいけない。

本当に見るべきなのは、人の弱さではない。
構造の弱さである。

顧客の声は、どこで止まったのか。
営業の違和感は、どこで消えたのか。
保守の情報は、なぜ営業に戻らなかったのか。
カスタマーセンターの不満は、なぜ商品に戻らなかったのか。
なぜ、止めるべき案件が止まらなかったのか。
なぜ、進めるべき提案が進まなかったのか。

AIは、人を追い込むために使うべきではない。

構造を見るために使うべきだ。

Decision StackのHOLDは、そのためにある。

止まることを、失敗にしない。
保留を、逃げにしない。
不確実性を、消さない。
人間の判断を、最後に残す。
そして、止めた理由を記録する。

組織に必要なのは、もっと速く動くことだけではない。

正しく止まれることだ。

都市はコピーできるのか

ここまで来ると、少しSFのような話になる。

もし、デジタルツインによって都市を十分にシミュレーションできるようになったら、都市はどこまでコピーできるのだろうか。

道路。
河川。
地形。
建物。
電力。
通信。
水道。
物流。
人流。
商流。
防災。
医療。
教育。
行政。
店舗。
交通。
住民の行動。
季節ごとの変化。
災害時の反応。
朝の混雑。
夜の静けさ。

それらがデジタルツインの中で構造化される。

ただ地図として写すのではない。
ただ3Dモデルとして再現するのでもない。

都市が、どのような条件で動き、どのような時に詰まり、どこで危険が生まれ、どこに余白があり、何が人々の生活を支えているのか。

それを、判断可能な形に変えていく。

すると、都市は単なる場所ではなくなる。

都市は、ひとつのOSになる。

土地の上に建っているように見えて、実際には無数のプロトコルで動いている。

信号のタイミング。
バスの運行。
ごみの回収。
病院の受け入れ。
学校の時間割。
コンビニの配送。
水門の制御。
避難所の開設。
地域の放送。
住民同士の暗黙の距離感。

都市とは、建物の集まりではない。

判断の集まりである。

だから、都市のデジタルツインとは、都市の見た目をコピーすることではない。

都市の判断構造をコピーすることだ。

気候変動の時代に、都市を構造化する

ここで、気候変動の話が入ってくる。

地球の気候は、すでに安定した背景ではなくなっている。

猛暑。
豪雨。
洪水。
干ばつ。
山火事。
海面上昇。
食料生産の不安定化。
水資源の偏り。
都市インフラへの負荷。

人間は、長い間、地球環境を前提として都市を作ってきた。

空気がある。
水がある。
重力がある。
季節がある。
海がある。
森がある。
土がある。
雨が降る。
川が流れる。

その前提の上に、都市、産業、交通、農業、金融、文化、生活が積み重なっている。

でも、その前提が少しずつ揺らいでいる。

そうなると、都市はもう、自然環境に乗っているだけでは済まなくなる。

都市は、自分自身をより強く理解しなければならない。

どこが熱に弱いのか。
どこが水に弱いのか。
どこで電力が足りなくなるのか。
どこに高齢者が多いのか。
どの道路が冠水するのか。
どの病院が逼迫するのか。
どの地域が孤立するのか。
どのタイミングで避難すべきなのか。

ここで、デジタルツインが必要になる。

デジタルツインは、未来の都市を作るための技術である前に、変わりつつある地球で都市を生き延びさせるための技術である。

現実を写す。
環境の変化を読む。
都市の弱点を見つける。
シミュレーションする。
判断する。
必要なら止める。
現場に戻す。

それは、防災の話であり、気候適応の話であり、都市の生存戦略の話である。

ただ、その先に、もう一つの問いがある。

もし、地球上の都市をデジタルツインとして構造化できたら。

もし、都市がどのように水を使い、電力を配り、交通を動かし、人を避難させ、医療を維持し、食料を届け、共同体を保っているのかを、判断可能な形で記述できたら。

その構造は、地球の別の場所にも移せるかもしれない。

災害後の復興地。
水害に強い新しい街。
過疎地の再設計。
海上都市。
砂漠の都市。
極地の基地。
そして、月や火星の居住区。

もちろん、地球の都市をそのまま宇宙にコピーすることはできない。

宇宙には、空気がない。
水が少ない。
放射線がある。
気温差が激しい。
重力も違う。
外に出るだけで命に関わる。

でも、都市を動かしている判断構造は、移植できる可能性がある。

水をどう循環させるか。
空気をどう保つか。
電力をどう配るか。
食料をどう作るか。
ごみをどう処理するか。
故障をどう検知するか。
どこで区画を閉じるか。
誰をどこに避難させるか。
どの判断をAIに任せ、どこで人間が止めるか。
失敗をどう記憶し、次に活かすか。

宇宙では、都市のあらゆる機能がむき出しになる。

地球上では見えなかったものが、宇宙では見える。

空気はインフラである。
水はインフラである。
温度はインフラである。
重力さえ、条件である。
共同体のルールも、インフラになる。

SpaceXが見ているもの

ここで、SpaceXのことを考える。

SpaceXが見ている先は、単にロケットを飛ばすことではない。

もちろん、ロケットは重要である。
再利用できることも重要である。
打ち上げコストを下げることも重要である。
Starshipのような巨大な輸送システムを作ることも重要である。

でも、SpaceXが本当に見ているのは、その先にある。

月に基地を作ること。
火星に都市を作ること。
人類を複数惑星種にすること。

これは、かなり大きな話である。

ロケット会社というより、地球外に社会を移植しようとしている会社に近い。

ここで、デジタルツインの話とつながる。

火星に都市を作るためには、建物を運べばいいわけではない。
人を運べばいいわけでもない。
機械を運べばいいわけでもない。

都市を動かす構造を持っていく必要がある。

空気。
水。
電力。
通信。
食料。
医療。
移動。
修理。
廃棄物。
教育。
労働。
娯楽。
行政。
緊急対応。
共同体のルール。

地球上では、それらはあまりに自然に存在している。

水道から水が出る。
コンビニに食べ物がある。
スマートフォンがつながる。
病院がある。
道路がある。
電車が来る。
ごみが回収される。
誰かが設備を直している。
誰かが交通を管理している。
誰かが電力を配分している。

都市の多くは、見えない判断でできている。

火星では、それをゼロから作らなければならない。

しかも、失敗するとすぐに生存に関わる。

空気の循環が止まる。
水の再生が遅れる。
電力が偏る。
通信が切れる。
放射線リスクが高まる。
外部作業の判断を誤る。
避難区画を間違える。
食料の配分を誤る。

宇宙都市では、判断のミスが都市のミスになる。

だから、宇宙に必要なのは、ロケットだけではない。

都市のDecision Stackである。

何をセンサーで拾うのか。
どのデータを優先するのか。
AIが何を予測するのか。
人間がどこで判断するのか。
何を自動化するのか。
何をHOLDするのか。
どの区画を閉じるのか。
どの資源を配分するのか。
実行結果をどう記憶し、次にどう活かすのか。

この構造がなければ、火星都市は運用できない。

SpaceXは、物理的にはStarshipで人と物を運ぼうとしている。

でも、その先で本当に必要になるのは、都市の運用OSである。

そして、都市の運用OSを作るには、地球上の都市をまず理解しなければならない。

地球の都市をデジタルツインで写す。
都市の動きをシミュレーションする。
災害時の判断を構造化する。
水、電力、通信、交通、医療、物流の依存関係を可視化する。
どこで止まり、どこで動くのかを記録する。

それは、地球のための技術であると同時に、宇宙のための技術でもある。

NTTのIOWNやデジタルツインが、地球上の都市や地域を構造化していく。
NAVER CloudのようなAIクラウドが、その構造を解析し、運用可能にしていく。
そしてSpaceXのような会社が、人と物を地球外へ運ぶ。

この三つは、別々の話に見える。

通信会社。
AIクラウド。
宇宙企業。

でも、未来の都市という観点では、同じ場所に向かっている。

都市を写す。
都市を理解する。
都市を運用する。
都市を移植する。

SpaceXが見ているのは、火星にビルを建てることではない。

地球の外で、都市を再起動することだ。

そして、都市を再起動するには、都市の見た目ではなく、都市の判断構造が必要になる。

宇宙は、リミナルスペースである

宇宙開発の話をすると、どうしても夢の話に聞こえる。

月面基地。
火星都市。
軌道上の居住区。
小惑星資源。
多惑星種としての人類。

少し前なら、それはSFの中の話だった。

でも、気候変動の時代に入ると、宇宙開発の意味は少し変わってくる。

それは、地球を捨てるという話ではない。

むしろ、地球を捨てられないからこそ、宇宙を考えるのだと思う。

地球上で気候変動が進むほど、私たちは都市の仕組みをより深く理解しなければならない。
そして、都市の仕組みを深く理解するほど、それを別の場所で再起動する可能性が見えてくる。

宇宙は、人間の生活を支えていた前提がすべて外れた場所である。

だから、宇宙はリミナルスペースである。

地球でもない。
完全な都市でもない。
自然でもない。
人工物だけでもない。
生活の場所でありながら、常に実験場でもある。
家でありながら、避難所でもある。
未来でありながら、廃墟のようにも見える。

そこには、地球の都市が持っていた当たり前がない。

コンビニはない。
路地もない。
川沿いの散歩道もない。
夕立の匂いもない。
駅前のざわめきもない。

でも、人間はきっと、そこにも生活を作ろうとする。

窓のない部屋に、窓のようなものを作る。
人工の空に、朝と夜を作る。
水耕栽培の緑に、庭の意味を見つける。
狭い通路に、街路のような感覚を作る。
通信の遅延の中に、遠さを感じる。
地球の映像に、故郷を感じる。

宇宙都市は、最初からリミナルである。

そこでは、すべてが境界になる。

内と外。
自然と人工。
人間と機械。
地球と火星。
生活と実験。
都市と基地。
避難と移住。
現在と未来。

だからこそ、Decision Stackが必要になる。

境界が曖昧な場所では、判断が難しくなる。

これは生活なのか、実験なのか。
これは安全なのか、危険なのか。
これは自動化すべきか、人間が判断すべきか。
これは進めるべきか、止めるべきか。
これは都市なのか、まだ都市になる前の何かなのか。

宇宙開発は、地球からの逃避ではない。

地球の条件を、もう一度見つめ直すための鏡でもある。

気候変動が突きつけているのは、地球の都市をどう守るかという問いである。
宇宙開発が突きつけているのは、都市を地球の外でどう成立させるかという問いである。

この二つは、別々の問いではない。

どちらも、都市のDecision Stackを問うている。

何を意味として拾うのか。
どう解釈するのか。
どこで止まるのか。
何を実行するのか。
どう記憶するのか。
そして、その構造を、どこまで持っていけるのか。

まだ名前がなかっただけだった

20年前の自分は、営業改革の資料を作っているつもりだった。

でも、いま読み返すと、そこにあったのは営業の話だけではなかった。

顧客の声を、どう意味にするか。
現場の違和感を、どう解釈に変えるか。
進めてはいけない判断を、どう止めるか。
実行した結果を、どう組織の記憶に戻すか。

それは、Decision Stackの問いそのものだった。

当時は、その名前がなかった。
だから、SFA、CRM、営業改革、意識改革、収益管理という言葉で語っていた。

でも、見ていたものは、たぶん同じだった。

人が判断する前に、何が起きているのか。
組織は、なぜ間違った判断をしてしまうのか。
顧客の声は、なぜ消えてしまうのか。
そして、どうすれば、止まれるのか。

Decision Stackは、突然出てきたものではない。

2004年の資料の中に、すでに小さく埋まっていた。
ただ、そのときはまだ、名前がなかっただけだ。

思考の化石

古い資料を見返すのは、不思議な体験だ。

当時の自分が考えていたことが、少し古い言葉で残っている。
でも、その奥にある関心は、あまり変わっていない。

見えないものに、名前を与える。
流れて消えるものを、少しだけ留める。
まだ意味になる前のものを、捨てずに置いておく。

顧客の不満。
営業の違和感。
保守の記録。
カスタマーセンターの声。
業界の変化。
提案の失敗。
受注の理由。
止めるべきだった判断。
止められなかった案件。

それらは、放っておくと消える。

でも、あとから見返すと、別の意味を持ち始める。

このNTT時代の資料は、古い営業改革資料ではなかった。

自分にとっては、思考の化石だった。

SFAの夢は、AIエージェントに引き継がれた。
CRMの夢は、DeciLayerに引き継がれた。
営業改革の夢は、Decision Stackに引き継がれた。

でも、本当に引き継がれたのは、技術ではない。

顧客を忘れないこと。
現場を忘れないこと。
失敗をなかったことにしないこと。
人の勘を、組織の記憶に変えること。
そして、進む前に止まれること。

2004年の法人営業改革資料から、ずいぶん遠くまで来てしまった。

営業改革。
経済圏。
IOWN。
AIクラウド。
防災デジタルツイン。
気候変動。
SpaceX。
宇宙都市。

全部、違う話に見える。

でも、底にある問いは同じである。

人間は、どう判断するのか。
組織は、どう記憶するのか。
都市は、どう止まるのか。
そして、未来の場所に、何を持っていけるのか。

宇宙は、究極のリミナルスペースである。

そこでは、まだ都市ではないものが、都市になろうとしている。
まだ生活ではないものが、生活になろうとしている。
まだ故郷ではないものが、故郷になろうとしている。

デジタルツインは、現実の影ではない。

いつか別の場所で起動するかもしれない、もう一つの都市の種である。

© SHIRO & Co.

First published: 2026-06-11