結論
- 技術習得とはメンタルモデルを鍛えることである
- メンタルモデルには階層構造があり、上位モデルほど別技術へ応用が利く
- 上位モデルの効率の良い鍛え方は予測と検証の繰り返しである
- AIは検証を速くするが、予測は自分で立てるしかない
「ひとつ極めると応用が利く」とは何が起きているのか
「TypeScript を深くやった人は Python の習得も速い」という話をよく聞きます。言語が違うのに、なぜ速いのか。
TypeScript 固有の文法が Python で使えるわけではありません。使っているのは、文法の下にある、もっと抽象的なモデルです。
「型とは何か」「非同期とは何か」「モジュール分割とは何か」といった、言語に依存しない理解。これが新しい言語を触るときの予測の土台になります。
こうした概念は、ソフトウェア工学として言語をまたいで存在するものでもあります。
ただ本記事で注目したいのは知識体系そのものではなく、それが個人の頭の中で予測の土台として働く側面です。
この頭の中の土台を、メンタルモデルという言葉で掘り下げてみます。
メンタルモデルとは
メンタルモデルとは、「このシステムはこう動くはず」「この操作をするとこうなるはず」という、頭の中にある動作の予測モデルのことです。
新しい技術を触るとき、私たちはこのモデルを使って「たぶんこう動くだろう」と予測し、実際に試して確かめ、ズレていたら直す、ということを繰り返しています。このモデルの精度が高いほど、予測が当たり、習得が速くなります。
新しい技術の習得は、予測と検証の繰り返し
具体的に、TypeScript 経験者が Python に触れたときを例にします。TypeScript は「型」が重要な言語なので、自然と以下のような予測から入ります。
1. 予測する：「TypeScript に型システムがあるなら、Python にもあるはず」
2. 試す：Python の型を調べて、型ヒントの仕組みを見つける
3. 結果を確認する：型ヒントが書けた。ただしコンパイル時に型エラーにはならない
4. モデルを修正する：「Python の型は実行時には強制されない。mypy のような外部ツールで検査する設計なんだ」
5. また予測する：「検査の厳しさを設定できるはず。TypeScript の strict みたいなモードがあるのではないか」
このサイクルの起点は「予測する」です。
予測があるから、結果がその答え合わせになります。当たれば確信が深まり、外れれば「なぜ？」が生まれてモデルが直る。
予測なしに試すと、結果を見ても「ふーん」で終わり、何も更新されません。
メンタルモデルは階層になっている
さて、このサイクルで「Python は型を外部ツールで検査する」と分かりました。
このとき頭の中では、実は2つの層が同時に更新されています。
- 下の層：その技術に閉じた個別の知識
- 「Python の型は実行時には強制されない。mypy のような外部ツールで検査する」
- 上の層：技術をまたいで使える、設計の引き出し
- 「型の強制には幅がある。言語自体が強制するものもあれば、外部ツールが補助するだけのものもある」
下の層は Python に閉じています。他の言語には持ち出せません。
一方、上の層は持ち出せます。次に Go や Ruby を触るとき、「この言語の型はどちら寄りだろう」と予測する材料になります。応用が利くのは、この上の層が育つからです。
ここが肝心なところで、上の層は下の層を学ぶ過程の副産物として育ちます。「Python は外部ツールで検査する」という個別の事実を一つ知るたびに、「型の強制には幅がある」という抽象的な引き出しが少しずつ厚くなる。個別の事実を集めないと、抽象的な引き出しも育ちません。
そして、さきほどのサイクルの起点だった「予測」そのものも、この上の層の産物です。ステップ1で「Python にも型があるはず」と予測できたのは、「型」という上の層をすでに持っていたから。上の層があるから予測でき、予測して検証するからまた上の層が厚くなる。この循環が「応用力」の中身です。
AIは検証コストを下げる
昨今のAIにより、上のサイクルの「試す → 結果を確認する」のコストが劇的に下がりました。「TypeScript のこの考え方は、Python だと何に当たる？」という転移の確認が、数秒で済みます。
自分：TypeScript の strict みたいに、Python の型ヒントを厳しく検査したい。そういう設定はある？
AI：mypy の --strict オプションが近いです。未注釈の関数や暗黙の Any を
エラーにできます。設定ファイル（mypy.ini や pyproject.toml）にも書けます。
以前ならドキュメントを探し、Stack Overflow を漁り、試して、と手順が必要だった確認が、一往復で終わります。転移の仮説を検証するサイクルが、桁違いに速く回るようになりました。
ただし、転移の予測は自分で立てるしかない
AIが速くしたのは「検証」であって「予測」ではありません。
「strict みたいに厳しくできる？」と聞けたのは、strict という上の層を持っていて、「Python にも同等のものがあるはず」と転移を予測できたからです。
予測がなければ、何を聞けばいいかもわかりません。
つまりAIへの質問の質は、そのまま上の層の厚さを反映します。
| 上の層の状態 | AIへの質問 |
|---|---|
| 薄い | 「Python って型は書けるの？」 |
| そこそこ | 「Python の型ヒントって、書いたら型チェックされる？」 |
| 厚い | 「型の強制には言語による幅があるけど、Python はどの言語が近い？ TypeScript の strict 相当はどう再現する？」 |
下に行くほど、質問に転移の仮説が含まれています。仮説があるから、返ってきた答えを自分の引き出しに位置づけられます。
AIに丸投げすると、上の層が育たない
AIは、こちらの理解を超えた回答を平気で返してきます。このとき理由を理解せずに「正しそうだから」で次ステップに進むと、検証を放棄してAIに判断を委ねたことになります。下の層の答え（個別の事実）だけを受け取り、「なぜそうなるのか」を確かめない使い方です。
数学ドリルで答えだけ写して、解き方が身につかなかったときと同じです。
これを続けても、下の層の断片は手に入りますが、上の層は育ちません。
個別の事実を「なぜ？」で噛み砕いて初めて抽象的な引き出しになるのに、その工程を飛ばしているからです。結果、答えは集まるのに応用が利かない、という状態になります。
これが「AIを使う」から「AIに使われる」への転落です。
逆に、超えた回答が来たときこそチャンスです。「なぜそうなるのか」を一段掘って検証すれば、それが上の層に取り込まれ、次の言語・次のツールで効いてきます。
まとめ
「ひとつの技術を極めると応用が利く」のは、個別の知識の下に、技術をまたいで使える上位のメンタルモデルが育つからです。
その上の層は、個別の技術を予測と検証で確かめていく過程でしか育ちません。
AIに個別の答えを丸投げして受け取るだけなら、下の層の断片が増えるだけで上の層は変わらないです。「これは何の一例だろう」と一段抽象化して取り込むことで、はじめて上の層が厚くなり、次の技術に転移します。
AIがあるから深く学ばなくていい、のではありません。より上手くAIを使いこなすために、学習サイクルを回していくのです。
本ブログに掲載している内容は、私個人の見解であり、所属する組織の立場や戦略、意見を代表するものではありません。