街区は人・モノ・環境が複雑に相互影響を与えながら成り立っています。そのため、1つのデジタルツイン（DT）で街区を表現することは困難であると私たちは考えています。街区を1つのDTで表現する代わりに、私たちはまず街区を構成する産業ドメインごとにDTをモデル化し、次に複数のDT間を媒介する人のDTをモデル化し、最後にデジタルツインコンピューティング（DTC）によりDTを連鎖＊1させ相互影響をモデル化する、というアプローチを取ります（図1）。
DTはそれぞれ異なる目的を持つため、DTを独立に動作させるとDTどうしで競合する可能性があります。例えば、飲食店のDT（飲食フードロスDT）は、来店者数やメニューごとの販売数の予測値と実績値の差分に応じてフードロスが発生するととらえており、フードロスが最小となることを目的としますが、フードロス抑制のために個人の嗜好と異なる飲食店へ来店させることは、個人の満足度の最大化を目的とする人のDT（個人サービスDT）と競合します。このように、フードロスの抑制と個人の満足度はトレードオフの関係にあり、フードロスの最小化と満足度の最大化を同時に実現することはできません。したがって、フードロスと満足度がバランスした最適解を求める必要があります。
フードロスの最小化と満足度の最大化のように、目的関数が複数あるときにそれらがバランスした最適解を求めるような問題を多目的最適化問題＊2と呼びます。多目的最適化問題では最適解は一意に定まらず、複数の最適解が曲線（目的関数が2つの場合）または曲面（目的関数が3つ以上の場合）を形成します。この曲線・曲面をパレートフロントと呼びます（図2）。DTCによりDTを連鎖させ相互影響をモデル化するとは、連鎖する複数のDTに関する多目的最適化問題の定式化を行い、パレートフロントを求められるようにすることを意味します。
DTCの目的は、DT独立での最適化を超えた街区の全体最適化を実現することで新たな価値提供を行うこと、にあります。複数のDTのトレードオフのバランスが取られたSocial Well-beingな状態を多目的最適化問題を解くことによって求め、環境を自動制御したり、人に働きかけたりすることによって、その状態が実現するように現実世界へフィードバックします。そのためには、DTを接続して全体最適化計算を行い、計算結果を外部システムへAPI（Application Programming Interface）経由で提供する「基盤的機能」が必要となります。また、人に対して最適なタイミングに、最適なコンテンツを、最適なコミュニケーション方法で提供し、行動変容を促す「アプリケーション」が必要となります。

＊1 単体で価値提供を行う機能群が相互に連動すること。
＊2 多目的最適化問題：目的関数が4つ以上になる場合は、最適化がより困難になることから、多数目的最適化問題と呼び区別されます。

デジタルツイン統合基盤（DT統合基盤）は前述の「基盤的機能」を実現したものです。街づくりDTCのアーキテクチャ^（1）におけるDTCレイヤに該当し、DT接続機能、全体最適化機能、APIなどを具備しています（図3）。DT接続機能はDTとの入出力インタフェースであり、各DTの予測値を全体最適化機能の入力として受け取ったり、環境制御（空調制御など）のために全体最適化計算結果を特定のDTへ出力したりします。全体最適化機能はDTCを行うDT統合基盤のコア機能です。APIは外部システムとの入出力インタフェースであり、顧客接点アプリで取得したログを受け取ったり、人に働きかけるために全体最適化計算結果を顧客接点アプリへ出力したりします。
全体最適化機能の課題は大きく2つあります。1つは連鎖する複数のDTに関する多目的最適化問題の定式化を行うこと、もう1つは現実的な時間内でパレートフロントを求めること、です。
まず定式化は、接続されるDTの種類や数、複数DTのバランスを取った結果をどのように具体的なサービスとして価値提供していくか、などに依存して変わるものです。DT統合基盤にDTを接続すれば直ちに全体最適化が行われるのが理想的ですが、人・モノ・環境の複雑な相互影響を自動的に読み解くことになり、実現は困難です。そのため私たちは、具体的なサービスとして「ランチ推薦」や「フリーアドレスの座席推薦」などを想定し、定式化を行いました。これらの詳細は事例として後に記述します。
次に現実的な時間内でのパレートフロントの求解は、全体調停・部分変更の2つに全体最適化を分けることにより実現しました。全体調停は夜間や早朝など、各DTに対応する現実世界のオブジェクト（飲食店や人など）が動作していない状態で実行され、各DTの予測値を基に終日の動作計画を立てる計算処理です。また、部分変更は、各DTに対応する現実世界のオブジェクトが動作している状態で事前に設定されたトリガー条件（フードロスがしきい値以上など）に応じて実行され、全体調停で作成した動作計画からの差分を補正する計算処理です。全体調停・部分変更により、全体の動作計画を立てながらも状況に応じて一部の動作計画変更を行うことが可能になります。これにより、トリガー条件に合致するたびに全体調停が繰り返され、前回の計算処理が完了しないまま次の計算処理が走ってしまい、現実的な時間内で計算処理が完了しない状況を抑制します。

統合アプリは前述の行動変容を促す「アプリケーション」を実現したものです。街づくりDTCのアーキテクチャ^（1）や図3における顧客接点アプリに該当します。街区ユーザに向けて、ランチ推薦、フリーアドレスの座席推薦、パーソナル空調制御、モバイルオーダによるロボット配送、セルフケアサポートなどのサービスが提供されます（図4）。
DT統合基盤で想定したSocial Well-beingな状態を実現するためには、人に想定どおりの行動をとってもらう必要があります。過去のサービス利用ログを基にユーザの嗜好をとらえ、嗜好に基づく推薦により行動を促すことはこれまで広く行われてきました。しかし、複数のサービスが提供される街区において、街区での価値体験を向上させることを考えた場合、サービス単位でこれを行うのでは不十分です。複数のサービスをまたぐユーザの価値体験（バリュー）を一連の行動軌跡（ジャーニー）として連結してとらえ、サービスを横断したユーザ嗜好の把握や、サービス利用の推移を基にしたユーザ行動の予測により、街区の価値体験を向上させることができると考えています。これを私たちはバリュージャーニー型行動予測と呼びます。
バリュージャーニー型行動予測を実現するためには、複数のサービスを利用するユーザ行動を1つのIDで連続的にとらえる必要があります。統合アプリはこれを実現するものであり、DT統合基盤に接続された会員基盤で認証を行うことで、DTやDTCが提供するサービスを同一IDでワンストップ利用することができます。複数サービスの利用ログは統合アプリを通じて学習データとしてDT統合基盤に蓄積され、行動前後の文脈を踏まえた先読み行動予測が可能となります。
次に、DT統合基盤と統合アプリを利用した具体的な事例として、「ランチ推薦」と「フリーアドレスの座席推薦」を紹介します。

ユーザが出社したタイミングやランチに向かうタイミングで、統合アプリがおすすめのランチを通知します。個人サービスDT、飲食フードロスDT、モビリティDT＊3という3つのDTの全体最適化により、ユーザごとの推薦ランチ（時間・メニュー・手段）を決定します。また、推薦により来店者数が変化することを踏まえ、街区管理DTが空調を制御します。全員が推薦どおりにランチをとれば、満足度、フードロス（メニュー販売数の予測値と実績値の差分）、ロボット配送の利用率がバランスした全体最適な状態が実現します。また、人流の増減予測に合わせて空調をプロアクティブに制御することにより、熱的快適性とエネルギーコストがバランスした全体最適な状態が実現します。
ランチ推薦では、ユーザの満足度に対して、フードロスやロボット配送の利用率がペナルティとして働くとみなし、3つのDTに関する多目的最適化問題を線形加重和法＊4により単目的最適化問題に変換することで定式化を行いました。単目的最適化では最適解が唯一に定まるためパレートフロントは形成されませんが、解空間が凸集合であれば、重みを変化させた際に得られる最適解の集合がパレートフロントとなります。街区オーナは「ユーザの満足度が高い街区にしたい」「フードロスが少ない街にしたい」などの街区コンセプトを持っていると考えられるため、重みの強弱を変化させることにより街区コンセプトの実現に近づけられるような設計としました。
図5は、ユーザ3人に3メニューのいずれかを推薦する際のイメージです。全員ラーメンが好みであり、寿司とパンはそれぞれで好みが異なります。鮮魚を扱う寿司でフードロスが発生しそうであり、ロボット配送利用率は余力がある状況とします。全体最適化結果は図5右側の推薦ランチのとおりです。満足度重視型の街区に比べ、バランス型の街区では満足度を大きく損なうことなくフードロス抑制とロボット配送利用率向上を実現しています。満足度をさらに減らしてでも、フードロスを抑制したい・ロボット配送利用率を高めたいことも考えられ、街区オーナは重みの強弱によりこれを調節できます。ロボット配送利用により飲食店に向かう人流が減少するため、飲食店フロアの空調を弱めるなど空調制御に反映できます。
なお、ランチ推薦は、2023年2月から3月までアーバンネット名古屋ネクスタビルにて実証実験が行われ^（2）、4つのDTによる連鎖が期待どおりに動作することを確認しました。

＊3 モビリティDT：移動体に設置されたセンサ情報などを用いて構築される移動体のDT。ランチ推薦におけるモビリティDTは配送ロボットをDT化しています。
＊4 線形加重和法：多目的最適化問題において、各目的関数に重みを乗算して総和をとったものを新しい目的関数とし、単目的に変換する方法。

ユーザが出社したタイミングなどで、統合アプリが効率良く業務ができるフリーアドレスの座席を推薦します。個人サービスDT、街区管理DTという2つのDTの全体最適化により、推薦座席を決定します。全員が推薦どおりに着席すれば、熱的快適性（快適に業務できる温度）と一緒に働きたい人との距離がバランスした全体最適な状態が実現します。
フリーアドレスの座席推薦では、一緒に働きたい人との距離に対して、熱的快適性が制約条件として働くとみなし、2つのDTに関する多目的最適化問題を制約法＊5により単目的最適化問題に変換することで定式化を行いました。制約法は、制約条件を複数回変更してみないとパレートフロントが分からない、制約条件が厳し過ぎると解が求まらないなどの問題がありますが、熱的快適性をユーザの希望温度と推薦座席における温度の差で表現すると、許容できる温度差の範囲は事前にある程度の想定ができるため、このユースケースにおいては問題にはならないと判断しました。また、必ずしも推薦どおりに着席や座席移動が行われないことを考慮し、推薦座席への移動率はユーザによって異なるという仮定のもとで最適化計算を行い、移動率の高いユーザに移動率の低いユーザの近傍を推薦するように定式化をしました。
図6は、1グループ当り10人からなる10グループを配席する際のイメージです。人は暑がり、寒がりといった温度嗜好があり、同一グループ内や、矢印で示されるグループ間では、一緒に働きたい関係性があるものとします。また、空調はあえて均一に冷暖房を行わずに温度にむらが発生する状況を許容し、エネルギーコストを下げている状態とします。全体最適化結果は図6右側の推薦座席のとおりです。暑がり、寒がりのグループは座席の温度に合わせて配席されているほか、一緒に働きたい関係性があるグループどうしは近隣に配席されていることが確認できます。
なお、フリーアドレスの座席推薦は、2023年11月よりNTTグループ会社の所有オフィスビルにて実証実験が行われています。

＊5 制約法：多目的最適化問題において、複数の目的関数のうち1つを目的関数とし、その他を制約条件として、単目的に変換する方法。

産業ドメインごとのDTの増加に伴い、トレードオフの解決が必要なユースケースも増加していくと考えています。具体的な街づくりDTCのモデル化を今後も積み重ねるとともに、共通機能の洗い出しと集約により、基盤としての汎用化も進めていきます。また、DT統合基盤が想定したSocial Well-beingな状態を実現するためには、人に想定どおりの行動をとってもらう必要があります。情報推薦のみのアプローチでは限界があるため、ナッジやインセンティブなど行動変容がより発生するような適切なアプローチを統合アプリに搭載していきます。
複数のDTが調和することで街区全体がサイバー空間上にかたちづくられ、個人に寄り添うおもてなし街区体験がフィジカル空間で得られるようなスマートシティの実現をめざして、今後も研究開発を推進します。

■参考文献
（1）　山本・社家・深田・上野：“「街づくりDTC」によるデータ駆動・連鎖型のスマートシティ,”NTT技術ジャーナル, Vol. 32, No. 11, pp. 77-83, 2020.
（2）　神谷・秦・朝日・星野：“アーバンネット名古屋ネクスタビルにおける「街づくりDTC^®」の実証,”ビジネスコミュニケーション, Vol. 60, No. 2, pp. 18-20, 2023.