※この記事は2026年5月時点の実運用メモです。
※古いシステムやAIによるコード移行の専門的な技術解説ではなく、古いコードの話を自分のAI活用や情報整理とつなげて考えた個人メモです。
最近、古い業務システムやCOBOLの話を見ていて、少し考え込んだ。
最初は、かなり単純に
「AIが強くなれば、古いコードの問題もかなり解決しやすくなるのでは」
と思っていた。
古いコードを読む。
処理内容を説明する。
別の言語へ変換する。
仕様書っぽくまとめる。
こういうことは、たしかにAIが得意そうに見える。
実際、AIにコードを読ませると、自分では追うのが大変な処理でも、かなり分かりやすく整理してくれることがある。
ただ、その話を見ていて強く感じたのは、問題はコードそのものだけではないということだった。
AIはコードを読めても、そこに残っていない文脈までは復元できない。
ここがかなり大きい気がしている。
最初は、AIが読めばかなり解決すると思っていた
AIにコードを読ませると、かなり助かる。
この関数は何をしているのか。
どこで条件分岐しているのか。
この処理は何に使われていそうか。
どこが危なそうか。
こういうことを説明してもらえるだけで、かなり見通しがよくなる。
だから、古いコードや古いシステムの問題も、AIがあればかなり楽になるのではと思っていた。
もちろん、それは今でもある程度そうだと思っている。
人間が全部を手で読むより、AIに一度整理してもらう方が速い場面は多い。
昔の書き方や、長く積み上がった処理を読む時にも、AIはかなり助けになる。
でも、そこで終わらない。
コードを読めることと、そのコードが生まれた理由まで分かることは別だった。
問題は、コードより「なぜそうなっているか」だった
古いシステムで本当に怖いのは、コードが古いことそのものではないのかもしれない。
それより怖いのは、
なぜこの例外処理があるのか。
なぜこの条件だけ特別扱いされているのか。
なぜここだけ変な順番で処理しているのか。
誰の判断でこうなったのか。
どの業務ルールを前提にしているのか。
このあたりが残っていないことだと思う。
コードには処理は残る。
でも、判断理由までは残っていないことがある。
当時の担当者なら分かっていた。
現場では常識だった。
一部の取引先だけの例外だった。
昔の運用上、そうせざるを得なかった。
そういう背景が、コードの外側にあった可能性がある。
そして、その文脈がどこにも残っていなければ、AIも推測するしかない。
AIは「見えている情報」には強い。でも、残っていない情報には弱い
ここで、自分の中でかなり腑に落ちたことがある。
AIは、見えている情報を整理するのはかなり強い。
コードがある。
ログがある。
仕様書がある。
メモがある。
会話ログがある。
そういうものを渡せば、かなりのところまで読んでくれる。
でも、残っていない情報は読めない。
当たり前のことなのに、意外と忘れやすい。
AIが強くなると、何でも復元できるような気がしてしまう。
でも実際には、AIが読めるのは、どこかに残っているものだ。
残っていない判断理由。
書かれなかった迷い。
削られた補足。
当時の口頭説明。
なぜそうしたかの背景。
こういうものは、後からかなり拾いにくい。
AIがそれっぽく説明してくれることはあるかもしれない。
でも、それはあくまで推測に近い。
ここを混ぜると危ない気がしている。
これは自分のObsidian運用にもそのまま刺さった
この話を見ていて、自分のObsidian運用ともかなりつながった。
最近、自分はAIに読ませるために、rawやhandoff、dailyを残すようにしている。
最初は、単に作業を引き継ぎやすくするためだった。
今日何をしたか。
どこまで進んだか。
次に何をしてほしいか。
どのメモが元になっているか。
こういうことを残しておくと、別のAIに渡す時も楽になる。
でも、古いコードの話を見ていて、もう少し意味が広がった。
これは単に今の自分が楽をするためだけではない。
未来の自分や、未来のAIに文脈を渡すためでもある。
なぜこの下書きにしたのか。
なぜこの関連記事を選んだのか。
なぜこのネタを後回しにしたのか。
なぜこのメモを残したのか。
こういう判断理由が残っていないと、あとから見た時に分からなくなる。
本文だけ残っている。
でも、なぜそうしたかは分からない。
これは、古いコードだけの問題ではない。
結果だけ残しても、あとから使いにくい
メモも同じだと思う。
きれいに整理された結論だけを見ると、一見かなり使いやすい。
でも、そこに至るまでの迷いや判断が消えていると、あとから扱いにくいことがある。
なぜこの結論になったのか。
他にどんな案があったのか。
何を捨てたのか。
どこを不安に思っていたのか。
このあたりが残っていないと、あとからAIに渡しても少し弱い。
AIは結論を読める。
でも、結論に至るまでの流れがなければ、その判断の重みまでは分かりにくい。
だから最近は、きれいな要約だけでは少し足りないと思うようになってきた。
もちろん、要約は必要だ。
handoffも必要だ。
整理されたメモも必要だ。
でも、それだけではなく、元のrawや、その時の判断理由も残しておいた方がいい。
未来のAIに推測させすぎないために残す
今のAIでも、かなり多くのことができる。
数年後には、もっと長い資料も自然に読めるようになるかもしれない。
今よりずっと古いコードや資料も扱いやすくなるかもしれない。
でも、その時に材料が残っていなければ、どうしようもない。
未来のAIがどれだけ強くなっても、残っていない文脈までは読めない。
だから、今のうちに残しておく意味がある。
完璧に整理しなくてもいい。
すべてをきれいに書き直さなくてもいい。
でも、判断理由や元の文脈を消しすぎない。
rawを残す。
handoffを残す。
dailyに進捗を書く。
なぜそう考えたかを短く添える。
こういう地味なことが、あとからかなり効いてくる気がしている。
AI時代ほど、文脈を残す力が大事になるのかもしれない
AIが強くなるほど、文章を書く力やコードを書く力だけではなく、文脈を残す力も大事になるのかもしれない。
何を決めたか。
なぜ決めたか。
何を見送ったか。
どこに不安があったか。
次に誰が何を見ればいいか。
このあたりを残しておくと、AIはかなり使いやすくなる。
逆に、結果だけが残っていると、AIはそれっぽく補完してしまうかもしれない。
でも、その補完が正しいとは限らない。
だから、AIに任せる前提なら、なおさら人間側が文脈を残す必要がある。
AIが読む未来を考えるなら、メモはただの記録ではなく、あとから判断をつなぐための材料になる。
まとめ
古いコードやCOBOLの話を見ていて、最初はAIでかなり解決できるのではと思っていた。
実際、AIはコードを読んだり、処理を説明したり、変換の手助けをしたりするのはかなり強いと思う。
でも、それだけでは足りない。
AIは見えている情報には強い。
でも、残っていない文脈までは復元できない。
なぜその処理があるのか。
なぜその判断になったのか。
何を避けるための例外なのか。
そういうものが残っていなければ、AIは推測するしかない。
これは古い業務システムだけの話ではなく、自分のメモやObsidian運用にもそのまま当てはまる。
だから、rawを残す。
handoffを残す。
dailyに進捗を書く。
判断理由を少しだけ添える。
未来のAIに推測させすぎないために、今の自分が文脈を残しておく。
最近は、その意味が前よりかなり大きく見えてきた。
関連記事
AIに知識を渡すなら、メモは渡せる形にしておく必要があった
AIをまたぐなら、最初にrawを残すだけでかなり楽になる
AIに刺さった理由は、知識を外部化したかったからだった
一度うまくいったAI活用を、あとから再現するのが意外と難しい
コメント