これまで仕事は、完成物として残されてきた。
文書、設計書、ソースコード、マニュアル、データ、システム。
何かを作り、それを保存し、必要になれば修正しながら使い続ける。
多くの仕事は、この前提の上で組み立てられている。
しかし生成AIが実務へ入り始めたことで、この前提そのものが少しずつ変わり始めている。
重要になるのは、完成物をどれだけ長く保存できるかだけではない。
その仕事を、あとからもう一度つくれるか。
仕事の保存単位が、完成物から「再生成できる記述」へ移り始めている。
完成物は、時間とともに環境からずれていく
完成物には、それが作られた時点の条件が埋め込まれている。
コードであれば、言語やフレームワーク、OS、データベース、ライブラリ、サーバ構成がある。
文書であれば、制度、組織、担当者、業務フロー、その時点で共有されていた前提がある。
完成した瞬間には問題なくても、時間が経てば周囲の条件が変わる。
すると、
成果物 ↓ 環境差分 ↓ 読解コスト ↓ 修正コスト ↓ 維持コスト
という流れが発生する。
ここで厄介なのは、単に技術が古くなることではない。
「なぜこう作られているのか」が分からなくなることだ。
コードは残っている。
設計書も残っている。
しかし、なぜその分岐が必要だったのか、なぜその仕様を採用したのか、どこまで変更してよいのかが分からない。
成果物は存在しているのに、成立条件が失われている。
レガシー化とは、古い技術が残ることだけではなく、過去の判断を再構成できなくなることでもある。
AIは、完成物より「条件」から再び作る
生成AIの特徴の一つは、既存の成果物をそのまま保存することではない。
与えられた条件から、新しい成果物を生成できることにある。
たとえば、
- 何を実現したいのか
- 何を守る必要があるのか
- どこまで変更してよいのか
- どのような例外があるのか
- どの環境で動かすのか
といった条件が分かれば、その時点の技術環境に合わせて別の実装を作ることができる。
従来の仕事は、概ね次のような形だった。
目的 ↓ 仕様 ↓ 実装 ↓ 完成物 ↓ 完成物を維持する
これがAIを介すると、別の形が見え始める。
目的 ↓ 条件 ↓ 記述 ↓ AIによる解釈 ↓ 現在環境への実装
この違いは小さくない。
過去に作られた実装を未来まで運び続けるのではなく、必要になった時点で、その時点の環境へもう一度射影する。
つまり保存する対象が、完成物だけではなくなる。
「再生成できる記述」とは何か
ここでいう記述は、詳細な仕様書だけを意味しない。
むしろ重要なのは、成果物の背後にあった条件が残っていることだ。
たとえば、
何をしたかったか 何を守る必要があったか どこまで変更可能だったか 何を判断しなかったか どこに例外があったか 何が観測されたか
といった情報である。
これらが残っていれば、将来の担当者やAIは、過去の成果物を単に読むだけではなく、その意味を再構成できる。
この視点に立つと、仕事の記録も少し違って見える。
コード、設計書、議事録、Issue、テスト、コメント、会話履歴、観測ログ。
これらは別々の成果物ではなく、ある仕事を再生成するための条件を部分的に保持している記述群として見ることができる。
記述から実装へ、実装から記述へ
ただし、AI時代の変化は「記述から実装を生成する」ことだけではない。
逆方向も強くなる。
実装 ↓ AIによる解析 ↓ 暗黙条件の推定 ↓ 記述への回収
古いコード、ログ、画面、DB、テスト、運用履歴が残っていれば、そこから「このシステムは何を成立させようとしていたのか」を推定できる余地が増える。
つまり、
記述 → 実装
という一方向ではなく、
記述 ⇄ 実装
という往復が成立し始める。
過去の仕事をそのまま保存することと、過去の仕事から意味を読み戻すことが、別々の操作ではなくなっていく。
実装資産から意味資産へ、さらに差分履歴へ
これまで資産として重視されてきたのは、実装そのものだった。
コードを残す。
文書を残す。
環境を保存する。
バックアップを取る。
これらは今後も必要だ。
ただしAIが再実装能力を持つほど、それだけでは足りなくなる。
何を意味していたのか。
何を成立させる必要があったのか。
どこまで変えてよいのか。
こうした情報の方が、長期的には重要になる可能性がある。
実装資産 ↓ 意味資産
と重心が移る。
ただし、意味そのものも固定ではない。
仕事は途中で変わる。
要件が変わり、例外が追加され、前提が崩れ、保留された判断が後から効いてくる。
そのため、さらに重要になるのは、
なぜ変更したか 何が変わったか 何を捨てたか 何を保留したか
という差分履歴である。
実装資産 ↓ 意味資産 ↓ 意味変化の履歴
まで保存されていれば、未来のAIは「現在の意味」だけでなく、「なぜそこへ至ったのか」まで再構成しやすくなる。
Issue、Git履歴、会話ログ、観測ログが重要になるのは、そのためでもある。
レガシーシステムの見え方も変わる
この変化は、レガシーシステムの意味も変える。
従来は、古い言語、古いフレームワーク、古いOS、古いデータベースが問題として扱われやすかった。
しかしAIによる再実装が一般化すると、本当に重要なのは別のところへ移る。
そのシステムが、何を成立させていたのかを再構成できるか。
古いコードしか残っていなくても、業務条件や例外条件、利用者の期待、他システムとの接続条件が分かれば、新しい環境へ移し替えられる可能性がある。
さらに、条件が十分に文書化されていなくても、コードやログそのものから意味を回収できる可能性も高まる。
逆に最新のコードであっても、なぜそう作られているかが分からず、差分履歴も失われていれば、変更は難しい。
レガシー性は、単純に技術の古さだけでは測れなくなる。
「意味が回収できるか」
「差分が追えるか」
「再生成できるか」
という別の軸が加わる。
仕事の記録がAIにとっての柔らかいDSLになる
ここで、もう一つの可能性が見えてくる。
人間が残す仕事の記録そのものが、AIにとってDSLのように働き始める可能性がある。
ただし、ここでいうDSLは厳密な構文を持つ言語ではない。
むしろ、
目的 制約 前提 判断 観測 例外 未確定
のような半構造化された記述群を、AIが一種の「柔らかい仕様言語」として読む状態に近い。
人間がすべての実装詳細を書くのではなく、成立条件を残す。
AIはそれを読み取り、現在の技術環境へ射影する。
人間 ↓ 成立条件を記述する ↓ AI ↓ 実装へ射影する
同時に、
既存実装 ↓ AI ↓ 成立条件を推定する
という逆向きも成立する。
そのとき仕事の記録は、単なる過去のログではなくなる。
未来の実装を生成し、過去の意味を回収するための中間層になる。
ただし、記録を増やせばよいわけではない
ここには別の問題もある。
再生成可能性を高めるために、あらゆる判断、会話、例外、変更を保存しようとすれば、今度は記録そのものが肥大化する。
実装保守コスト ↓ 意味保存コスト
へ負荷が移るだけなら、仕事は軽くならない。
重要になるのは、すべてを残すことではない。
何を残せば、あとから十分に再生成できるのか。
つまりAI時代には、「記録量」よりも「最小記述境界」が新しい設計対象になる。
どこまで記述すれば意味が戻るのか。
どの差分だけ残せば判断経路を復元できるのか。
どこから先は実装そのものから推定できるのか。
この境界は、まだ固定されていない。
「戻ってくる仕事」の意味が変わる
RT｜Recurring Time が見るのは、仕事が何度も戻ってくる構造である。
システム更新、制度変更、改修、移行、再テスト、再説明。
一度終わったように見える仕事も、環境が変われば再び戻ってくる。
これまでは、そのたびに人間が過去の成果物を読み直し、修正してきた。
更新 ↓ 修正 ↓ 移行 ↓ 再テスト ↓ 再説明
しかし再生成可能な記述が十分に残り、既存実装から意味を回収する能力も高まれば、この反復の一部は「再作業」ではなくなる。
再作業 ↓ 再射影
へ変わる。
ここでRTとして重要なのは、仕事が消えることではない。
反復される対象が変わることである。
従来は、
実装 修正 移行
が反復していた。
AI介在後は、
確認 選択 例外判断 責任引受
の方が人間側へ残りやすくなる。
AIによる高速化は、一回の作業時間を短くするだけではない。
戻ってくる仕事が、以前と同じ形では戻ってこなくなる。
RT-02が見る変化は、そこにある。
それでも、すべてを記述できるわけではない
もちろん、仕事のすべてが記述へ変換できるわけではない。
現場には、
- 暗黙知
- 身体知
- 状況判断
- 責任
- 信頼関係
- 空気
- 言語化されていない例外
が残る。
そのため、
記述 = 現実
ではない。
AIが再生成できる範囲は、何が記述され、何が観測可能になっているかに依存する。
現時点では、
完成物 + 再生成条件 + 差分履歴
という三層で考える方が自然だろう。
完成物を捨てるのではない。
完成物だけに依存しない。
意味を固定するのでもない。
意味が変わった履歴まで残す。
この差は重要である。
仕事の寿命は「何年使えるか」だけではなくなる
これまでシステムや文書の寿命は、「何年使えるか」で語られてきた。
しかしAIによる再生成が前提になると、別の問いが生まれる。
この仕事は、別の環境でももう一度成立させられるか。
言語が変わっても、OSが変わっても、担当者が変わっても、制度が変わっても、意味を読み戻して再構成できるか。
仕事の耐久性が、
成果物の寿命
だけではなく、
意味の再射影可能性
でも測られるようになる。
すると、長く使えるコードを書くことと同じくらい、長く読み戻せる条件と差分を残すことが重要になる。
完成物を残す仕事から、再び作れる状態を残す仕事へ
AIは、完成物を不要にするわけではない。
完成物を、唯一の保存形式ではなくし始める。
コードも、文書も、システムも、その時点の条件から生成された一つの射影になる。
同時に、その射影から意味を読み戻すことも可能になっていく。
そして、より長く残る資産は、
何を作ったかだけではなく、
なぜそれが必要で、何を満たせばもう一度作れるのか。さらに、そこへ至るまでに何が変わったのか。
という記述へ移っていく。
これからの仕事では、「完成させること」と同時に、「再生成できる状態を残すこと」が重要になるかもしれない。
作ったものを保存する。
そこからさらに一歩進んで、
もう一度つくれる状態を保存する。
そして必要になれば、過去の完成物から、その状態そのものを読み戻す。
AI時代の仕事は、その方向へ少しずつ動き始めている。
■ 接触面（GOA）
この構造は、企業の中期システム設計、既存資産の保守判断、制度変更への適応設計、AI導入時の責任境界で接触する。完成物を延命するのか、成立条件を保存して再生成へ移るのかで、時間軸の取り方が変わる。
■ 再帰地点
成立前提は、AIが意味・差分・例外を十分に回収できること。位相を変える制約膜は、記録密度、責任配置、実装互換性。再評価すべき変数は、保守コスト、意味回収可能性、再生成精度、差分履歴の残存度である。
