原題: Understanding is the new bottleneck
著者: Geoffrey Litt
公開日: 2026年7月
ソースURL: Understanding is the new bottleneck
アーカイブ日: 2026-07-04
エージェントがコードを書く速度は日増しに上がっている。だが、人間がそのコードを理解する速度は変わらない。Geoffrey Litt（Notionのデザインエンジニア）は、AI Engineerカンファレンスでの講演をもとにした本記事で、この非対称性を正面から論じる。「理解」こそが、これからのソフトウェア開発における真のボトルネックだ。
Littはまず、「なぜ理解するのか」という問いに二つの答えを提示する。よくある答えは「検証のため」——エージェントの成果物をチェックし、正しいかどうかを判定するためだ。しかしエージェント自身が自己検証能力を急速に高めていることを踏まえると、この役割だけで人間の存在意義を語るのは心許ない。
そこでLittが強調するのが第二の答え、「参加するため」だ。ソフトウェア開発は一度きりのループではない。プロジェクトとはエージェントとの無数の往復であり、次の一手を思いつくためには、システムに対する豊かな概念のセットが頭の中に必要だ。その流暢さを欠けば、創造的参加者としての能力は意味のあるかたちで制限される。これはMargaret StoreyとSimon Willisonが広めた「認知的負債（cognitive debt）」の概念にも通じる。技術的負債と同様に、短期的には理解しなくてもやり過ごせるが、いずれ手痛いしっぺ返しを食らう。
では、AIと高速に作業しながら、どうやってその理解を構築するのか。Littは教育の分野から三つの技法を借用する。
第一の技法：説明（Explanations）
エージェントが作業を終えるたびに、それは説明の機会でもある。Littは /explain-diff というスキルを自作し、日々使っている。このスキルはコードの差分を読み解くための「コード説明書」をHTML、Markdown、あるいはNotionページとして生成する。その設計思想には、いくつかの原則が埋め込まれている。
まず「背景を教えよ」。変更内容に入る前に、そもそも何がすでに存在しているのかを説明する。彼の例では、ゲームの視点を変更する前に、まずゲームエンジンそのものを解説する。
次に「詳細より直観を」。コードを見せる前に変更の目的を宣言し（「2Dの描画トリックで庭に立体感を与える」）、等角投影法（isometric projection）とは何かを説明する。これによって読者は変更の本質を掴み、人間として対等な参加者になれる。
さらにLittはインタラクティブ図版の重要性を指摘する。Notionに新たに実装された埋め込みHTML機能を使い、庭の岩をドラッグすると座標がどう変わるかをインタラクティブに観察できる図版を説明書に組み込んでいる。
コード自体の提示方法も工夫されている。通常のdiffはファイルがアルファベット順に並んだ「コードの山」にすぎない。Littが「literate diff」と呼ぶ方法では、変更を散文として構成し、意味のある順序でコードスニペットを提示しながら説明を添えていく。生のdiffを読むよりずっと速くレビューできる。
こうして出来上がった説明書を、Littはときに印刷してカフェに持ち込む。AIがインタラクティブな活動を「静的な紙のレポート」に変換し、それによって深く集中できる——彼はその皮肉な美しさを楽しんでいる。
しかし読むだけでは不十分だ。Andy Matuschakの「本は効かない」という警句を引き合いに、Littは「読んだ気になる」ことの危険性を指摘する。そこで登場するのが第二の技法だ。
第二の技法：クイズ
説明書の末尾に、5問のインタラクティブなクイズを埋め込む。Littのルールは明確だ——自分がクイズに合格するまで、そのコードを他人に渡さない。同僚のコードをレビューするときも同じルールを適用する。
Littはクイズを「AIループの速度調整器（speed regulator）」と呼ぶ。AIと仕事をしていると、ループは人間の理解速度を容易に追い越す。クイズはそれに対する拮抗力であり、「本当に理解しているか」を機械的に問い直すことで、創造的参加者であり続けることを可能にする。
第三の技法：マイクロワールド
ここでLittは教育思想家Seymour Papertの「マスランドに住む」という構想を引く。フランス語を学びたければフランスに住めばいい——同じように数学を学びたければ、数学が自然に使われる環境に住めばいい。子どもの好奇心の自然な副産物として学習が起きるような環境を設計できるのではないか、という問いだ。
これをコードに応用すると、「システムがどう動き、どう変わるのかを自然に直観できるような世界」を作れないか、という問いになる。Littは二つの実例を挙げる。
一つ目はPrologインタプリタのデバッガ。自分で書いた論理型言語の実行を理解できずに苦労していた彼は、エージェントと協力してカスタムデバッガを構築した。タイムラインをスクラブし、各ステップでスタックの状態や評価されているルールを確認できるUIだ。彼はデバッグ中に自分用のコメントも残せる（「いいね、そのルールを正しく適用できた」）。重要なのは、これはエージェントにデバッグさせるツールではなく、人間がデバッグするためのツールだという点だ。自分でデバッグするプロセスそのものが理解を育む。
二つ目は個人ウェブサイトのフレームワーク移行だ。Claudeが書いた移行スクリプトのレビューが困難だったため、彼は「コマンドセンター」——新旧サイトを並べて表示し、ボタンを押すたびに段階的に移行が進むUI——を作らせた。このコマンドセンターで新しいサイトが少しずつ息を吹き込むのを眺めることで、手作業でやったのと同じような理解が、はるかに速く得られた。
ここでのポイントは明白だ —— エージェントは、人間がコードを理解するためのコードを書ける。これは大きな転換である。
第四の技法：共有空間
ここまで個人の理解について語ってきたが、チーム開発では「一緒に理解する」必要がある。Littは共有メンタルモデルの力を強調する。同じ語彙が同じイメージを呼び起こすとき、人は効率的にコミュニケーションでき、ジャムセッションのような創造的対話が可能になる。
Littが所属するNotionでは、人間とエージェントが協働するための機能が次々とリリースされている。たとえばNotion内でClaudeやCursorのエージェントを実行できるようになり、エージェントが技術計画を立てるとき、それはデフォルトで共同編集可能なページに出力される。チームメンバーはそこにコメントし、即座に議論できる。「孤立して考える」のではなく「共に考える」のだ。
最後にLittは、このすべてが50年前のAlan Kayのビジョンに立ち返ると指摘する。コンピュータは、本よりも優れた、人々——とりわけ子ども——が世界の仕組みを考えるための新しいメディアになりうるという構想だ。子どもたちがインタラクティブなゲームをプレイしながら、そのコードを編集して物理学を理解する——このビジョンが半世紀前からあった。
Littは宇宙飛行士のミームで締めくくる。「待って、コンピュータの目的は人々が複雑な概念を理解するための動的なシミュレーションを作ることだったの？ —— ずっとそうだった。」
ポイントは常に自動化ではなく拡張だった。そしてAIがシミュレーション作成をこれほど手軽にした今こそ、AIに教えてもらうことは、コンピューティングが開いた最大の可能性のひとつだ。ループから降りるだけでなく、ループのより深くに入り込むこともできる。それは私たち次第である。
Geoffrey Littの本記事の最大の貢献は、「エージェントがコードを書く時代に人間は何をするのか」という問いに対して、「理解し、参加し続けること」という明快かつ実行可能な答えを示した点にある。巷には「人間はループから外れるべきだ」「いずれエージェント同士が自律的に回す」といった言説が溢れているが、Littは静かに、しかし強固にその前提を退ける。
本記事の特筆すべき点は、抽象論に留まらず、自らの日々の実践に根ざした具体的な技法を提示していることだ。 /explain-diff スキル、クイズによる理解の自己検証、インタラクティブなマイクロワールド——これらはすべてLittが実際に使っている手法であり、机上の空論ではない。特に「literate diff」と「speed regulator」という概念は、現在のAI支援開発ツール群に決定的に欠けている視点を突いている。コードが生成される速度と、人間が理解する速度の非対称性を認識し、後者を保護する仕組みを意図的に設計する——これはエンジニアリング文化に対する静かな挑戦状である。
教育理論からの借用も巧みだ。Papertの「マスランド」とMatuschakの「本は効かない」をコード理解の文脈に移植する手つきは、HCI研究者としてのLittのバックグラウンドをよく示している。Alan Kayのビジョンに回帰する終盤の展開も、単なるノスタルジアではなく、「拡張（augmentation）」というコンピューティングの原点がAI時代にこそ輝くことを説得的に示す。長期的に見て、この記事は「AI時代のソフトウェア開発における人間の役割」を論じる際の参照点のひとつとして残るだろう。
唯一の懸念は、これらの技法が現状では個人の工夫と手作業に依存している点だ。Littの所属するNotionがこれらのアイデアをプロダクトにどこまで組み込めるか——それによって、このビジョンが一部の先鋭的なエンジニアの実践に留まるのか、業界全体の標準になるのかが決まる。
Tags: AI、ソフトウェア開発、HCI、教育、エージェント、augmentation、コード理解