動画記事 · AI Engineer
理解こそが新たなボトルネックに — Geoffrey Litt氏(Notion)
動画の文字起こしと公開情報をもとにAIで要約・構成しています。 正確な発言は元動画と時間位置で確認してください。
まず要点
AI エージェントがコードを書く時代において、人間は正しさの検証だけでなく「理解」を維持し、創造的参加者であり続けるための教育学的アプローチと具体的な実践手法を提唱する。
AI がコードを書く時代、なぜ「理解」こそが新たなボトルネックなのか — Notion の Geoffrey Litt 氏が語る創造的参加の条件
生成AIがコード作成を自動化する現在、「人間はコードを理解し続ける必要があるのか?」という問いが業界で議論されています。Notion のデザインエンジニアであるジェフリー・リット氏は、その答えは「正誤チェックのため」ではなく「次のアイデアを生み出すための創造的参加」のために理解が必要だと断言します。
AI に依存しすぎて内部構造を知らないと生じるのは技術的な負債ではなく、プロジェクトへの参加能力を奪う「認知負債」です。リット氏は、教育学的な知見を応用した3 つの実践的手法(説明ドキュメントの改善、クイズによる速度調整、マイクロワールドでの直感的学習)を通じて、この課題を解決する道筋を示しています。
正誤チェックから「創造的参加」へ:理解の真の目的
多くの開発者が抱くメンタルモデルは、「AI が書いたコードが正しいか、人間が検証する」というものです。仕様書に合致しているか、本番環境をダウンさせないか、アーキテクチャは適切か——これらはすべて「OK」か「NG」かの判断です。
エージェントが賢くなるにつれ、正誤チェックにおける人間の役割は減少していきます。むしろ、人間がその役割を減らすことは悪いことではありません。
リット氏は、AI が提案し、人間がそれを承認するループにおいて、AI の能力向上に伴い人間の検証コストは下がるべきだと考えます。しかし、ここで人々が陥りがちな誤解があります。「AI が賢くなれば、人間はコードの中身を理解する必要もなくなるのではないか」という発想です。
これは大きな勘違いです。なぜなら、ソフトウェア開発は単一のループで完結するものではないからです。
理解の真の目的は「正しさの確認」ではなく、次のアイデアを生み出すための創造的参加にあります。
何が起きているかを深く理解している人と、表面的な知識しか持っていない人では、生み出せるアイデアの種類に決定的な違いがあります。頭の中に豊かな概念的構造があり、誰かに尋ねるまでもなく概念を高速で再結合できる能力こそが、創造的な飛躍を可能にします。
AI が生成するコードの背景にある仕組みを理解していないと、私たちは単なるオペレーター(実行役)に堕し、プロジェクトの設計者や創造的参加者としての役割を失ってしまいます。これが、なぜ今なお「理解」が重要なのかという根本的な理由です。
見えないリスク:認知負債の蓄積
AI にコードを書かせていると、最初は非常に効率的で気持ちが良いものです。しかし、ある時ふと気づきます。「待てよ、何が起きているのか全くわからない」という瞬間です。
バイブコーディング(直感に任せて進む開発)がうまくいっているつもりでも、実は認知負債を積み上げすぎている可能性があります。
この用語は技術負債の比喩として使われます。少しの間は乗り切れるかもしれませんが、理解度が低下した時点でプロジェクトは破綻します。参加できなくなってしまうのです。AI のスピードに追いつこうと必死になるあまり、内部構造への理解が後回しになり、結果として最終的にはプロジェクトから排除されてしまうリスクがあります。
教育学的アプローチ:3 つの実践的解決策
では、どうすれば AI の高速化の中で「理解」を維持できるのでしょうか。リット氏は、この問いに答えるために「教育」という分野の知見を応用することを提案します。単なる読書や講義ではなく、学習者が能動的に理解する仕組みを作るための3 つの手法です。
1. 「解説付き差分(Explain Diff)」:背景と直感から始める
AI が生成したコード変更に対する説明ドキュメントは、単なる「差分リスト」では不十分です。リット氏が推奨するのは、「この変更をチームに教えるための個別カリキュラム」を作成させるアプローチです。
優れた説明には以下の要素が必要です:
- 背景の提示: 変更から始めるのではなく、「このシステムはそもそも何をしているか」という既存知識を確認し、そこから変化を説明します。
- 詳細より直感: コードを見せる前に、そのコミットの目的や本質的な感覚(例:「2D の描画テクニックで立体感を持たせる」)を伝えます。これは良い数学教師が行うような手法です。
- インタラクティブな図形: 可能であれば、静止画では得にくい理解を提供するシミュレーションを組み込みます。Notion の新機能である HTML ブロックを活用し、岩の描画方法がどう変わるかをドラッグ操作で確認できるなど、触って試せる要素を加えます。
AI が生成したコードを、かつて IDE に張り付いていたようにカフェで PR の教科書を読むような形で理解する。これは皮肉ですが、AI によるプロセス変革の結果です。
2. クイズによる「速度調整装置」:理解度の担保
読んでいるつもりでも、実は理解できていないという現象はよくあります。リット氏はこれを防ぐために、クイズを導入します。
AI はすべてを加速しますが、理解の速度も同じように加速させる必要があります。そのための「速度調整装置」としてクイズが機能します。
コードレビューを他者に依頼する前に、まず自分自身が作成したエージェントによる説明に対して、中程度の難易度のクイズに合格することを条件とします。これは少し馬鹿げているように思えるかもしれませんが、多くの場合で「理解していなかった」ことに気づかせてくれます。本を読んでも理解していないことに気づかないという研究(アンディ・マタシャク氏)に基づき、記憶定着のための間隔反復をコードレビューのプロセスに組み込むのです。
3. マイクロワールド:直感的な学習環境の構築
教育者セーモア・パパートが提唱した「マイクロワールド」という概念を応用します。これは、「フランスに住めば子供がフランス語を学ぶように、数学を学ぶには『数学ランド』のような場所が必要だ」という発想です。
コード理解においても、単にドキュメントを読むのではなく、その仕組みが生きている環境(マイクロワールド)の中で学習することが有効です。
- デバッガーの活用: プログラミング言語のプロローグを学ぶ際、インタプリタの実装を可視化する UI を構築し、タイムラインをスライドさせて内部状態の変化を目で追います。これにより、「機械への感覚」が養われます。
- 移行プロセスのシミュレーション: サイトのフレームワーク移行時、AI に「ポートするゲーム」を作成させます。左側に古いサイト、右側に新しいサイトを表示し、ボタンを押すたびにファイルツリー上でファイルが移動する様子を確認できるインタラクティブなツールです。
エージェントはコードを書くだけでなく、私たちがこれらの小さなマイクロワールドを構築することで、単なる実行ではなく「仕組みの理解」を得ることができます。
共有空間で協働:チーム全体の認知負荷管理
最後に、リット氏は個人での理解からチーム全体での共有理解へと視点を広げます。Notion では、複数の人間とエージェントが同時にマルチプレイヤーのチャットスレッドを作成できる機能を実装しています。
あなたと他者の間に存在する「共有された理解」こそが、効果的なコミュニケーションを可能にします。
プロダクトマネージャーが質問に対し、別のエージェントが即座に参加して回答するなど、1 対 1 の会話から Slack やチャネルのような共有空間へ移行させることで、チーム全体でアイデアを出し合い、議論を深めることができます。ローカルのコンピュータではなく、共同作業スペースにあるドキュメントやチャットで議論することで、集合的な理解が強化されます。
まとめ
生成AI がコード作成を加速させる時代において、人間が果たすべき役割は「正誤チェック」から「創造的参加」へとシフトする必要があります。そのためには、教育学的な知見に基づいた「解説付き差分」「クイズによる速度調整」「マイクロワールド」という3 つの手法を用いて、認知負債の蓄積を防ぎ、チーム全体で深い理解を共有する文化を築くことが不可欠です。
AI に任せるだけでなく、人間が仕組みを理解し続けることこそが、これからのソフトウェア開発における最大の競争優位性となるでしょう。
Original Source
元動画で発言を確認
プレイヤーは必要になるまで読み込みません。YouTubeのCookieと通信も再生を選ぶまで開始しません。
時間位置から根拠を確認
章や引用を選ぶと、元動画をその位置から再生します。