はじめに

本記事はリンクアンドモチベーション Advent Calendar 2025の15日目になります。

自分は外部の技術顧問の方に月に一回のペースで1on1する機会をもらっています。
今回はその中で話したことを共有します。

※公開するにあたって分かりやすさを重視して脚色しています。

問い

ぼく「自分は手を動かしてコードを書くことで事象を理解を深めていたことに気づきました。AIエージェントにコードを書いてもらうと自分の理解が深まらず長期的にスキルが上がらないという懸念があります。」

ぼく「一方でコードを書かなくても事象を理解できているように見える人もいて、これは自分の理解の仕方をアップデートする必要があるんですかね？」

定式化、機械言語化することで気づけることはある

技術顧問「えっとさ、数学の文章題ってあるじゃん。鉛筆何本と何本で合計いくら～みたいな。」

ぼく「ありますね。」

技術顧問「あれって定式化するプロセスと、定式化したもの解くプロセスがあるわけよ。定式化が何をXと置いて合計は何みたいな式をつくることね。それはプログラムに近いの。」

技術顧問「問題の構造がこうなんだなって定式化する時に分かるっていうのはあるよね。」

技術顧問「機械言語に変えたから自然言語の時は気づかなかったことが気づけることはあると思うのね。」

ぼく「自分はそういう気づきに助けられてきました。コードを書くのが好きなのは事象の理解が深まることが理由の一つです。」

『友達』って属性？関係？

技術顧問「例えばさ、日常会話で『友達』ってめっちゃ曖昧なのよ。」

ぼく「ほう。」

技術顧問「『俺と君は友達だよね』って言う時は、AとBの関係をラベル化してる。でも『あいつ友達だから』って言う時は、その人の中の属性のように扱っている。」

ぼく「あー確かに。」

技術顧問「でも『友達』を属性として扱うと、不都合が生まれる。僕にとっては『友達』だけど君にとっては違うかもしれないから。主観が入ってしまうんだよね。」

技術顧問「論理的には僕の友達を君に紹介する時は、『こいつは俺の友達』ではなくて『こいつと僕は友達関係』という方が適切になる。」

技術顧問「こう考えると、『友達』って人間Aと人間Bの間のラベルなんだよね。」

ぼく「なるほど。」

『友達』の議論はまだ終わらない

技術顧問「『友達』をAとBの関係性と仮定して、次に思考することは本当にそうなのかっていうことよね。」

技術顧問「例えばAはBのことを『友達』だと思っていてもBはAのことを『友達』だと思っていないケースもあるよね。これを『友達』と見なす場合、関係性というよりもAがBをどう見ているかという情報になるわけ。」

ぼく「逆のパターンもあるかもしれないですね。」

技術顧問「側から見た時にこの2人は『友達』ですというのはどういう条件を指すのか？みたいなことが日常だとクリアにならないけど、論理的な言語で書かれていると考慮せざるを得ない。」

ぼく「（この辺が決まってないとDB設計とかできないもんなぁ。）」

大事なのはモデリング

技術顧問「今の会話のなかでコードを書かなくても自然言語で事象の理解が深まったでしょ？」

ぼく「！！！」

技術顧問「モデリング思考で問題を解くと自然言語でも今と同じようなことは表現できるわけです。」

モデリングとは定式化であり、問題の解き方の提示

技術顧問「僕は小規模なプロジェクトの時はTypeScriptの型定義をつくることから始める。そしたら型定義を元にこうしたいとAIに依頼して実装してもらう。」

技術顧問「型定義（=モデリング）が適切ならコンパイルは通るし、どこかで無理があるならエラーになる。エラーになったら型定義を修正する。」

ぼく「『友達』のモデリングをミスってたらどこから無理が生じてAIが実装できないみたいなイメージですね。」

技術顧問「問題の解き方自体をAIに教え込んで解かせるようにして、解き方をアレンジすることに人間の役割を変えていった方が効率的じゃん？」

ぼく「たしかに。」

技術顧問「そうすると自分自身の理解も深まるんじゃない？だって言語化して解き方教えなきゃいけないし。」

ぼく「なるほど〜。話を通して分かったのですが、自分はAIに何を任せて自分は何をすればいいのかに悩んでいました。自分はモデリングをすればいいのか！」

具体例

技術顧問「映画館の料金表ってあるじゃん？」

技術顧問「お客さんのタイプが9で時間帯によるタイプが5と考えると45パターンあるように見えるよね。」

技術顧問「だけど二次元テーブルをつくるのではなくて、問題の構造を理解したい。」

技術顧問「これは以前話題になったチケット料金モデリングで、色々な人が色々なモデリングをしているので君もやってみるとよいよ。」

ぼく「はい！」

ちなみに以下が分かりやすく、綺麗なモデリングだと思いました。
スケールする要求を支える仕様の「意図」と「直交性」

技術顧問「適切な構造が分かるとテスト数は少なくなるし、バグも起こりにくくなるよね。これが問題の構造を理解することであり、モデリングであり、設計なのよ。」

技術顧問「画面から考えると表をそのまま作りたくならない？でもそれじゃ思考として深まらない。まずはUMLやmarmaidとかで構造を明らかにすることが僕は好き。」

ぼく「自分はWebデザインからこの業界に入ったので見た目から入りがちでした。」

技術顧問「結局、問題解決の本質は“構造をどう捉えるか”なんだよね。」

技術顧問「モデリングがんばってね！」

まとめ

AI時代に頑張るべきはモデリング。
モデリングが正しいかどうかはAIが高速にコードを書く中で検証してくれる。