ソフトウェアの歴史は、現実そのものを扱ってきた歴史ではない。むしろ、現実をいったん「状態」に変換してから扱う歴史だった。
顧客はCRMのレコードになり、問い合わせはチケットになり、業務はワークフローになった。文書は抽出されたフィールドになり、デザインはレイヤーやコンポーネントの集合になった。ユーザーが本当に欲しかったのは、答えであり、判断であり、成果物だった。しかしソフトウェアは、まず現実を自分が操作できる形に変換する必要があった。
この「状態ファースト」の発想は、欠陥ではない。むしろ近代的なソフトウェアを可能にした土台である。状態が明示されることで、情報は検索でき、編集でき、共有でき、検証でき、再利用できるようになった。現実にソフトウェア的な取っ手をつけるには、現実をいったん操作可能な表現へ変換しなければならなかった。
機械学習は、その射程を大きく広げた。画像はラベルになり、音声はテキストになり、文書は構造化データになり、行動履歴は推薦やスコアになった。これまで人間が手で整えていた現実の多くを、機械が読める状態へ変換できるようになったのである。
ただし、機械学習は中間表現を消したわけではない。むしろ、より多くの現実を中間表現へ変換できるようにした。MLは状態ファーストの時代を終わらせたのではなく、その入口を広げた。
生成AIの変化は、そこから一歩先にある。生成AIは、乱雑な入力を分類したり、抽出したり、要約したりするだけではない。文書、会話、スクリーンショット、表計算、ログ、チケット、商品データ、設計意図を読み取り、そこからレポート、回答、UI、分析、計画、返信、判断、シミュレーションを直接生成できる。
つまり、現実をいったん状態に変換し、それを操作してから出力するのではなく、現実から結果へ直接進む道が開かれつつある。
これを「現実起点のソフトウェア」と呼びたい。
現実起点のソフトウェアとは、ユーザーに中間状態の構築を求めるのではなく、与えられた現実の文脈から、ユーザーが本当に欲しかった成果物を生成するソフトウェアである。状態ファーストのソフトウェアが「現実 → 中間表現 → 出力」だったとすれば、現実起点のソフトウェアは「現実 → 結果」に近づいていく。
文書処理を考えるとわかりやすい。従来のシステムでは、まずOCRをかけ、項目を抽出し、分類し、正規化し、例外を検証し、ワークフローに回し、最後にレポートを作る。だが、ユーザーが欲しかったのは抽出フィールドではない。判断、要約、提案、報告書である。抽出フィールドは、ソフトウェアが必要とした中間物にすぎなかった。
サポート業務も同じだ。顧客との会話はチケットになり、タグが付けられ、担当者に回される。担当者はアカウント情報やポリシーを読み、返信を書く。だがチケットは仕事そのものではない。仕事を入れておく容器である。システムが会話、契約、製品状態、ポリシーを直接読めるなら、中心になるべきものはチケット管理ではなく、回答、処理、エスカレーションの生成である。
データ分析では、この変化はいっそう深い。ダッシュボードは、誰かがあらかじめ想定した問いに答える。売上、解約率、サポート件数、コンバージョン率。問いが安定しているなら、それで十分強い。
しかし実際のビジネス上の問いは、しばしばもっと探索的である。なぜこのセグメントの売上が落ちたのか。サポート件数の急増は何が原因か。価格変更は拡張売上に影響したのか。ローンチ後に何が起きたのか。
ダッシュボードは静的な状態である。エージェント型の分析は、動的な調査である。問いに応じてデータウェアハウスを叩き、スプレッドシートを開き、サポートチケットを読み、外れ値を調べ、仮説を立て、反証し、証拠付きのレポートを書く。ソフトウェアは、もはや既存のビューを表示するだけではない。その場で調べる。
デザインツールにも同じ構造がある。Figmaのようなツールでは、ユーザーはフレーム、レイヤー、コンポーネント、バリアント、制約、オートレイアウト、スタイルといった内部状態を操作する。その結果として、画面上にUIがレンダリングされる。これは非常に強力な編集モデルである。
しかし、現実起点のデザインでは出発点が変わる。ユーザーはまずオブジェクトグラフを組み立てるのではない。プロダクトの意図、ブランド、制約、参考例を与え、インターフェイスそのものを生成する。編集可能な構造は後からあってよい。だが、創造の起点は状態ではなく意図になる。インターフェイスが、オブジェクトグラフに先行する。
ゲームは、この変化の最も遠い例かもしれない。従来のゲームは、マップ、メッシュ、テクスチャ、物理、アニメーション、クエストフラグ、会話ツリー、NPCの行動、アイテム、戦闘ルール、セーブデータといった、あらかじめ設計された世界状態をレンダリングしている。プレイヤーは自由な世界を体験しているように感じるが、その世界は基本的には事前にモデル化され、プログラムされた範囲に閉じている。
生成型の世界モデルでは、プロンプト、文脈、プレイヤーの行動から、世界そのものがその場で生成される。世界は、プレイヤーが入る前に完全に指定されている必要がなくなる。従来のゲームが事前に作られた世界を描画するものだとすれば、生成型のゲームは、プレイヤーの移動とともに世界を生み出していくものになる。
もちろん、状態が不要になるわけではない。銀行残高、医療記録、権限、契約、監査ログ、インフラ、マルチプレイヤーの整合性、組織の記憶には、永続的で検証可能な共有状態が必要である。現実起点のソフトウェアは、それを否定しない。
変わるのは、あらゆる有用な作業の前に、必ず中間状態を作らなければならないという前提である。
この変化は、組織にも及ぶ。企業の仕事は、多くの専門機能に分散している。プロダクト、デザイン、エンジニアリング、データ、法務、財務、マーケティング、サポート、運用、QA、セキュリティ、営業。ある部門が望む成果物を直接作れないのは、必要な能力や判断やシステムが、他部門に分散しているからだ。
エージェントは、その分散を一部内側に取り込む。プロダクトは仕様を書く前にプロトタイプを作れる。サポートはチケットを投げるだけでなく、製品改善の仮説を出せる。マーケティングは、デザインや開発を待たずに実験用ページやコピーを作れる。データチームは、調査の多くをエージェントに任せ、より高度な判断に集中できる。
組織における現実起点化とは、部門が意図から成果物へ進む距離を短くすることでもある。
ソフトウェアの第一段階では、現実は明示的なアプリケーション状態にならなければならなかった。第二段階では、機械学習によって、より多くの現実がその状態へ変換可能になった。そして今、生成AIによって、現実の文脈から直接、成果物を生み出すことが可能になりつつある。
状態ファーストのソフトウェアは、現実を表現することでプログラム可能にした。MLは、表現できる現実の範囲を広げた。生成AIは、現実から結果へ進む道を開いた。
次のパラダイムは、状態をよりうまく操作することではない。現実から結果までの距離を、根本的に短くすることである。