この記事は『LITALICO Advent Calendar 2025』のカレンダー1最終日の記事です。
LITALICOでCTOをやっている@yuyaichihashiです。
今年もLITALICOではたくさんの仲間たちが記事を投稿してくれています！
ぜひ、カレンダーのリンクをポチって気になった記事も読んでみてください！
0. はじめに
ChatGPTのリリースが2022年11月だったことを考えると、その後の進化も、開発現場での普及も目を見張るものがありますね。
これまでの歴史も、機械語/アセンブリ言語から高水準言語へ、オブジェクト指向言語やフレームワークの発展、仮想化やクラウドなど、大きな変化の波は繰り返しやってきていますが、人間の扱う情報をどんどん抽象化していくこれまでと同様の変化だけではなく、決定論的ではなく確率論的な技術への変化というのが、エンジニアリング上の大きなポイントかなと思っています。
これからは、より多くをAIに任せ、人間が主に取り組む工程が上流に寄っていくとともに、AIに任せる範囲について、確率論的に揺らぎのあるAIをどうコントロールするか、という大きく2つの観点でどのように発展していくかなのだと思います。
タイトルの「AIはユーザーの夢を見るか？」は、フィリップ・K・ディックの名作「アンドロイドは電気羊の夢を見るか？」へのオマージュ、というかただのダジャレですが、本記事では、実用的/実践的な記事は他のみんなにお任せしつつ、AIはぼくらがやっているように、ユーザーに向き合い、理解し、どのような価値を提供するのか考え、それをどのようにデザインや設計するか考え、実装するようになるのか、未来に思いを馳せつつ、そこへ向けてどのような動向があるんだろう？と個人的に見たり考えたりしたものを簡単にまとめてみました。
専門の研究者ではなく、日々のスキマで気になった情報をつまみ食いしてるので、内容の網羅性や思考の不足などなどはご了承いただき、ポエム記事と思って見てもらえれば幸いです。
1. LLMフレンドリーなコードベースやアーキテクチャ：人とAIが協力してコードを書く段階
1.1 生成AIの「メモリ」と「注意力」の限界をどう扱うか
人間もそうなのですが、LLMもまた「物理的な記憶容量」と「注意力」の限界があります。
物理的なメモリ限界（コンテキストウィンドウ）:
LLMが一度に読み込める情報の総量には「コンテキストウィンドウ」という物理的な上限があります。近年では100万トークンを超える巨大なウィンドウを持つモデルも登場していますが、数百万行に及ぶエンタープライズ級のコードベース全体を一度に読み込ませることは依然として不可能です。つまり、AIにとってシステム全体は常に「メモリに乗り切らない」状態であり、適切な情報の取捨選択が不可欠です。
注意力の劣化:
また、仮にメモリに収まったとしても、コンテキストが長すぎると中間にある重要な情報を無視してしまう「Lost in the Middle」という現象のほか、長い依存関係の連鎖によるアーキテクチャ推論の減衰や、アテンションの希釈、局所的な最適化に引きづられる性質などもあります1。
これらに対して、人間に対して有効だったのと同様に、モジュール分割や型定義であったり、JSDoc等でのドキュメンテーションであったりといった工夫も有効だと思いますが、 さらに踏み込んだアーキテクチャレベルのアイデアについて、以下のような研究がありました。
1.2 判読性を高めるアーキテクチャ
「What You See Is What It Does: A Structural Pattern for Legible Software」という論文2では、ソフトウェアの構造を「完全に独立した機能単位（Concepts）」と「明示的な相互作用ルール（Synchronizations）」に強制的に分離する設計パターンが提案されています。
Concepts（局所化された知識）:
各部品（ユーザー、在庫など）が持つべき状態遷移のルールを閉じ込めます。AIは、他の部品を気にせず「この部品が何であるか」だけに集中してコードを書けます。
Synchronizations（集約されたフロー）:
部品同士がどう連動するかというフローを、DSL（専用言語）や厳密なインターフェースで定義します。
LLMは「狭い範囲のロジック」は得意ですが、「広範囲に広がる副作用」の推論には弱く、アーキテクチャ上の複雑な推論はコンテキストウィンドウの増大とともに精度が低下します1。この設計手法で構造を物理的に「分離」しておくことで、AIが一度に考慮すべき範囲を限定し、生成精度と保守性を高めることができると考えられます。
1.3 既存コードの「暗黙知」をナレッジグラフ化する
先ほどの設計パターンは新規開発のおいては有効かもしれませんが、すでに存在している既存のソフトウェアをその状態までリアーキするのはとても大変そうです。
そこで既存ソフトウェアに対してのアプローチとして、こんなアイデアの研究もありました。
既存ソフトウェアの修正をAIに任せる時の最大の壁は、コードに現れない「設計の背景」や「過去の妥協点」という 暗黙知（Tacit Knowledge） の欠落だと思いますが、これを解決するためのアイデアとして、 Code Digital Twin (CDT)3 というものがありました。
ソースコードの二層表現:
CDTは、ソフトウェアをソースコードという「物理層」だけでなく、PRの議論、ADR（設計判断記録）、Slackログ、過去の障害履歴を統合した「概念層（ナレッジグラフ）」の二層で管理します。
「なぜ」を逆引きする:
AIが特定のメソッドを修正しようとした際、CDTは「そのメソッドが5年前に特定のパフォーマンス問題のためにあえて泥臭い実装にされた」という背景を概念層から抽出します。
実証的な成果:
最新の研究では、単にコードを読ませるよりも、こうした「設計意図」をグラフ経由で供給する方が、SWE-bench（現実の複雑な課題を解くベンチマーク）におけるAIの成功率が数倍に向上することが示されています。
人間がソースコードの「外」でやってることをAIもできるようにしよう、というアプローチですね、乱暴に言ってしまうと。
1.4 メモリ限界や注意力の質に対するアプローチ
そもそもこの物理限界をどうにかしようという研究も進んでいます。
MemGPT (Virtual Context Management):
OSが物理メモリを仮想メモリ（ディスク）で補完するように、AIが自律的に「重要度の低い情報を外部ストレージに逃がし、必要な時に呼び戻す」という階層型メモリ管理のアプローチが提案されています4。
Infini-attention:
Googleの研究では、過去のコンテキストを固定サイズのメモリ状態に圧縮して保持し続けることで、計算コストを抑えながら「実質的に無限の文脈」を扱う手法が模索されています5。
2. 「仕様駆動開発 (SDD)」：人がコードを書かない段階
2.1 SSoT（Single Source of Truth）の移動
これまでは、意図的な選択であれ、実態としてであれ、ドキュメントは存在していてもSSoTはコードでしたし、何かあれば最終的には人間はコードを読みコードを修正します。
（あわせてストック情報としている設計ドキュメントは漏らさず更新したいものですがw）
SDDについての詳しい解説が世の中にたくさんあるので、詳細はそちらに譲りますが、SDDでは、（現在は人間が多く介在する必要があるものの、理想として）SSoTは仕様書に移行し、人間が直接コードを触ることはなくなっていくことを目指すものだと思います。
様々な点でまだ発展が必要ですが、SDDのワークフローの中でAIがより複雑で規模の大きいソフトウェアを実装できるようになるためにも、1章で触れたようなことも繋がってくるのだと思います。
2.1 HULAフレームワークという思想的背景
この流れは、AI開発コミュニティから発生したHULA (Human-in-the-Loop AI) フレームワーク6という思想に端を発しているようです。
AIとのチャットは、時間が経つと過去の要件を忘れる「揮発性」が課題であり、そこで、対話ログではなくMarkdownファイルをAIの「外部記憶」として使う手法としてのアイデアが生まれました。
- FUNCTIONAL.md：機能的な要求（何をするか）
- ARCHITECTURE.md：技術的な設計（どう実現するか）
- TICKETS.md：実行可能なタスク（どの順序でやるか）
これらのファイルをAIと人間が共有する「SSoT」とし、人間が「意図」を定義し、AIが「実装」を行うという明確な分業体制に発展したのがHULAフレームワークです（非常にざっくりですが)。
2.2 Amazon Kiro
このコミュニティの知恵を製品レベルで統合したのが Amazon Kiro7 だと思われます。Kiroは単なるエディタではなく、このSDDのワークフローをエンジニアに提供する統合環境です。
階層的な外部記憶:
ユーザーの曖昧な指示をいきなりコードにするのではなく、requirements.md -> design.md -> tasks.md という順序で中間成果物を作らせます。
SSoTの移動:
人間はコードを直接修正するのをやめ、仕様書をマスター（SSoT）として扱います。仕様書が書き換わればAIがコードを「再生成」し、コードに手が入ればAIが仕様書を「逆更新」して同期を保つ、「生きたドキュメント（Living Documentation）」の状態を維持します。
PBT(Property-Based Testing):
EARS(Easy Approach to Requirements Syntax)という構造化された自然言語による記法で書かれた仕様(requirements.md)に基づいて、後述するPBTコードを自動生成します。
Amazon kiroだけでなく、GitHub Spec Kitや、Gotaさんが開発されている国産のcc-sddなどもありますね。
2.3 コードの検証
人間のレビュー対象が「コードレビュー」から「仕様レビュー」へと変わりますが、それには、コードの品質を保証する技術が必要です。
プロパティベーステスト (PBT) による論理の担保:
AIは仕様書（EARS記法等）から、「送金前後でシステムの総残高は不変である」といった 不変条件（Property） を抽出し、Hypothesisのようなライブラリを用いて、人間が到底思いつかないようなエッジケース（空のリスト、巨大な数値、null値など）を突く数万パターンのテストを自動生成・実行します。
形式検証による数学的証明:
さらに厳密な検証として、自然言語の仕様を Dafny や TLA+ といった形式言語に変換し、矛盾がないかを数学的に証明する研究（SpecGen 8 など）が進んでいます。これにより、「コードの中身」を確認する代わりに、「証明の成否」を確認するというアプローチです。
システム・シナリオテストの行方:
システムテストやシナリオテストはどうなるのでしょうか？ 論理的な正しさ（Verification）は上記のPBT等で自動化されますが、「そもそもこの仕様でユーザーは満足するのか？」という価値の妥当性（Validation）の確認は依然として重要です。
将来的には 仕様からE2Eテストを自動構成するエージェント や、合成ユーザー（Synthetic Users） が一次的なシナリオテストを代行するようになり、人間はそのシミュレーション結果をレビューし、最終的な「手触り」や「納得感」を承認する、より上位の意思決定へとシフトしていくかもしれません。
3. ソフトウェアを修正せずリビルドする未来：AIのためのコードの段階
AIによるコード生成やSDDが極まり、その他必要な分野の技術も発展すると、最終的には、人間はコードに触れることだけでなく、読むこともなくなるのでしょう。
そうなると、人間にとって読みやすい/理解しやすいコードという制約も必要なければ、既存のコードに少しずつ修正を加えるというやり方である必要もありません。
クラウドやコンテナ技術によって、サーバーに修正を加えるのではなく、毎回再生成するという概念に変わっていったように、ソフトウェアも変更の必要があれば、毎回再生成した方が合理的になるかもしれません。
3.1 「修正」よりも「作り直し」が安くなるか
人間がコードを書く時代においては、全てのコードを書き直しテストする「人間の工数」があまりに高価となるため、変更が必要な箇所だけコードを修正するの方が遥かに安価でした。
これがAIに代わると逆転するかというと、品質保証をどうするか等の観点もありますが、何はともあれ、より小さいコストでより安価に大量のコードを書けるようになる必要があり、以下のようなトピックが関連すると思います。
投機的デコーディング9:
AIは小さなモデルに「下書き」をさせ、大きなモデルでそれを「検証」することで、従来の数倍の速度でコードを書く。
プロンプトキャッシング10:
推論コストを下げ、レイテンシや金銭コストを大幅に下げる。
また、2.3で触れたように、コードの検証からシステムテストまでの多くがAIを使った自動化がされていかないと、再生成した方が早いし安いという特異点に到達できません。
3.2 コンピュータにとって最適なコード
DeepMindの AlphaDevは、深層強化学習を用いて人間には解読不能だが計算機にとって最適なアセンブリ命令を見つけました11 。
人間のための可読性という制約を外すことで、コンピューターにとっての最適解が追求できるとなると、コードやプログラミング言語も変わっていくのではないかと思います。
セキュリティ面でも「動的な難読化」などのメリットを生むかもしれません12。
4. 要求工学のAI化
「何をリビルドするか」を決める工程、要求工学（要求分析〜要件定義） ではAI化についてはどのような動向があるでしょうか。
4.1 EARS記法による意図の正規化
これはkiroでも組み込まれていますが、曖昧な要望を、EARS (Easy Approach to Requirements Syntax) という構造化された自然言語の構文テンプレートに落とし込みます（例：「WHEN <イベント>, THE SYSTEM SHALL <アクション>」）。このように表現を構造化/正規化することで、AIは要求の不備や矛盾を事前に指摘し、人間との「意図のすり合わせ」をより能動的に行えるようになります。
余談ですが、その昔、某エンタープライズ企業内で要求インスペクションチームというのを立ち上げる仕事をしたことがありまして、まさにこれを人力でやる感じでした。
AIと開発する時代になり、人間の役割がシフトしていく中で、またそれらもAIをコントロールして行うようになっていくだろう中で、ソフトウェア工学の各工程の知見やスキルがあらためて問われている気がします。
4.2 複数AIエージェントの協調によるレームワーク
MARE（Multi-Agents Collaboration Framework for Requirements Engineering）13 では、
- 要求引き出し (Elicitation): 利害関係者からニーズを引き出す
- モデリング (Modeling): 引き出した内容からエンティティや関係性を抽出する
- 検証 (Verification): モデルに基づき、要求に矛盾や不足がないかチェックする
- 仕様策定 (Specification): 最終的な仕様書として文書化する
という4つのタスクに分割し、それを、
- Stakeholders: システムの利用者としてユーザーストーリーを語り、質問に答える
- Collector: インタビューを行い、要求のドラフトを作成する
- Modeler: 要求モデル（実体と関係性）を構築する
- Checker: 品質基準に基づき、モデルと照らし合わせて要求を検証する
- Documenter: 最終的な仕様書（SRS）や検証レポートを作成する
という5つの役割のAIエージェントがコラボレーションしながら実行していくフレームワークが提案されています。
5. おわりに
本当は、UXデザインやUIデザインに関するトピックや、そもそもの課題やニーズを見つけたり検証したりといったフェーズのトピックも触れたかったのですが、記事が膨れ上がってしまうので、また別の機会にしたいと思います。
（どちらかというと、単純に力尽きまして🙇）
ここまで触れてきたことや、Nielsen Norman Groupが提唱する Generatibe UI14 や、AIエージェント同士が協調して動作する A2A(Agen-to-Agent) や、一時的な要望に対してツールを生成し使い終わったら破棄する Just-in Time Software などを組み合わせていくと、未来のソフトウェアは、AIが一人一人のユーザーを深く理解し、その場その場で最適なものを生成するようなものになるのかもしれませんね。