最近、ダリアのハウス制御シミュレータを作っていた。
と言っても、現代らしくAIと一緒に、である。
ダリアの短日処理を題材に、閾値制御と予測制御を比較する。そんな小さな検証から始まったはずだった。
気が付くと、
が並んでいた。
数年前なら、それぞれ本を買って、記事を読んで、ハンズオンを試してから触る対象だったと思う。
だが今は違う。
AIは平然とそれらを組み合わせ、30分後には何かが動いている。
問題はそこからだ。
昔の開発は、「理解してから作る」だった。
まず技術を学ぶ。
そのあと設計し、実装する。
理解が先で、成果物が後だった。
ところがAIと開発していると順番が逆になる。
まず成果物が現れる。
そのあと人間が理解する。
READMEを書こうとして初めて、
「ところでなんでRidge回帰使ってんの？」
と調べ始める。
一昔前なら、少し恥ずかしい状態だったかもしれない。
しかし最近は、この流れがむしろ自然に思える。
理由は単純だ。
技術の数が多すぎる。
新しいプロジェクトを始めるたびに、
のどれかが顔を出す。
それら全てを事前に学習してから前に進むのは現実的ではない。
かといって、何も理解せずにAIへ丸投げするのも危険だ。
では、何を理解すればいいのだろうか。
最近、自分なりの基準ができてきた。
それは、実装を説明できなくても、採用理由を説明できること。
例えば今回のRidge回帰。
私は最初から正則化項を書けたわけではない。
しかし、
「なぜ使われているのか」
は説明できる。
重みを極端にしすぎず、短時間先の状態予測を安定させるためだ。
MPCについても同じだ。
制御理論の専門家ではない。
しかし、
「未来を予測しながら操作を選ぶため」
という目的は理解している。
その理解があれば、少なくとも設計や意思決定の議論には参加できる。
考えてみれば、経営とITの間にいる人間は昔からそういう役割だった。
会計システムの内部実装までは知らなくても、
なぜ導入するのかは説明できる。
ネットワーク機器のファームウェアは読めなくても、
なぜ必要なのかは説明できる。
AI時代になって、その対象がソフトウェア開発そのものに広がっただけなのかもしれない。
技術を極めることと、意味を翻訳することは違う。
いまは、後者の価値がむしろ高まっているように感じる。
最近は、理解のゴールも変わってきた気がする。
以前は、
「全部知る」
ことが理想だった。
今は、
「なぜその結果になったのかを説明できる」
ことの価値が高い。
ダリアのシミュレータでも重要なのは、
Ridge回帰の数式ではなく、
なぜ予測制御だと26日目に到花するのか。
なぜ閾値制御は湿った外気で失敗するのか。
その因果関係を語れることだ。
AIは、これからも人間が思いつかない組み合わせを提示し続けるだろう。
人間が数日かけるような試行錯誤を、数十分で形にしてしまう場面も増える。
だからといって、人間の役割が消えるわけではない。
むしろその逆ではないだろうか。
AIが作った道を歩き、その道に意味を与える。
なぜその道が存在するのかを説明する。
技術と経営の狭間で仕事をしている人にとって重要になるのは、その能力かもしれない。
最近は「キャッチアップ不足」を不安に感じることが減った。
その代わり、
「これは何を解決する技術なのか」
を意識するようになった。
全てを学ぶ時間はない。
しかし、意味を理解する時間ならまだ取れる。
AI時代の学習とは、新しい技術を覚えることよりも、新しい技術の意味を理解することなのかもしれない。