AI・機械学習
絶滅したという意味ではないか?
Don't You Mean Extinct? (fabiensanglard.net)
要約
この記事は、1993年の映画『ジュラシック・パーク』におけるCG(コンピュータ・ジェネレーテッド・イマージュリー)の革命的な使用と、それが業界に与えた影響について論じています。特に、ストップモーションの巨匠フィル・ティペットがCGの台頭により自身の技術が「絶滅」したと感じたエピソードを紹介し、現代のプログラマーがLLM(大規模言語モデル)の台頭に抱く同様の不安に重ね合わせています。記事は、変化に適応し進化することの重要性を説き、LLMを効果的に活用する方法や、コード品質の維持、メンタルヘルスへの影響など、現代のソフトウェア開発におけるLLMとの共存について考察しています。
全文翻訳
Fabien Sanglard - WEBSITE
2026年7月10日
絶滅したという意味ではないか?
1993年、映画『ジュラシック・パーク』が公開され、映画におけるCG(コンピュータ・ジェネレーテッド・イマージュリー)の使用に革命をもたらしました[1]。一般の人々にとっては魔法のような体験でした。しかし、映画業界の一部の人々にとっては、それは厳しい現実でした。監督のスティーブン・スピルバーグは、ストップモーションの巨匠[2]フィル・ティペットに、彼のゴーモーション技術を用いて映画の全身恐竜を命を吹き込むよう依頼していました。スピルバーグは、CGが恐竜をリアルに描写できるかどうかについて懐疑的でした[4]。しかし、インダストリアル・ライト&マジック(ILM)のデニス・ミューレンとデジタルアーティストたちは、CGを用いた概念実証に取り組みました。彼らは、完全にテクスチャ加工され、フォトリアルなT-レックスが、日差しの下でガリミムスの群れを追いかける様子をレンダリングしました。
「デニス・ミューレンと一緒に、彼がスティーブンにT-レックスのテストを見せたとき、スティーブンは『すごい、これだ』と言い、私にどう思うか尋ねてきた。私は『絶滅した気分だ』と答えた[5]。私がそれまで築き上げてきたものがすべて、『もうこれはやらない』ということになったように感じた[6]。」
フィル・ティペット
すでに30人のクルーを選定し、大規模なゴーモーションの仕事の準備を進めていたティペットは、当然のことながら、この展開に打ちのめされました。
『ジュラシック・パーク』の制作
最近、この逸話についてよく考えています。プログラマーの周りには多くの悲観論[7]が見られます。時代遅れになるという不安は、特にオンラインで顕著です[8][9]。
進化する
絶滅を避ける最善の方法は進化することです。Hacker Newsのzkmonの意見が気に入りました。「ウェブサイト/ウェブアプリが波だった頃、あなたはそれに乗った。私はインターネット以前にソフトウェア業界に入り、常に馬を変えてきた。新しいことを学ぶのに遅すぎるということはない。新しい波は新しい種類の仕事と労働者を生み出す。その一員になろう。その波に乗って、ツールを使いこなそう。それは同じゲームだ。」 — zkmon (Hacker News)
現在のエピソードはzkmonに90年代半ばのウェブを思い出させますが、私には2000年代初頭のコンピュータグラフィックス分野や、2010年代初頭の「モバイルファースト」の台頭を思い起こさせます。プログラマーの各世代は、おそらく何らかの形の革命を目にしてきたでしょう。これはまさに同じゲームなのです。人生は流転する[10]。
LLMはまた一つのツールです。進化するとは、それがどのように機能するか、そしてそれを最大限に活用する方法を学ぶために時間を投資することです。
LLMの仕組みを学ぶ
LLMの仕組みを学ぶために見つけた最高の資料は、アンドレイ・カルパシーのチャンネルです。彼は明らかにLLMに深い関心を持っており、あなたがそれを理解することを本当に望んでいます。彼のこれまでのビデオシリーズは、25時間にわたる純粋な金塊です。それに続く良い資料は、セバスチャン・ラスカによる『Build a Large Language Model (From Scratch)』という書籍です。フルカラーの描画が多く、「Now Draw the Owl」の瞬間も含まれています。これは非常に良い本です。
LLMでコードを書く方法を学ぶ
一行一行手書きすることは、もはや標準ではありません。LLMの使用を拒否する人々は、それほど多くのものを生産できなくなるため、遅れをとるでしょう。そして、エージェントの使用を拒否する開発者を何人か知っています。
ジョン・カーマックは最近、コーディングについて興味深い見解を持っていました。「コーディング」は決して価値の源ではなく、人々はそれに執着すべきではありません。問題解決こそが中核的なスキルです。従来のプログラミングに要求される規律と精度は、価値のある転移可能な属性であり続けるでしょうが、参入障壁にはならないでしょう。長年にわたり、アセンブリ言語を愛しすぎてC言語に移行したくないと思っていた素晴らしいプログラマーのことを何度も考えてきました。私も、既存の巨大なコードベースや非効率な言語の使用に関して、同様の感情と戦っていますが、乗り越えています。 — ジョン・カーマック
たとえ私がコードを書いていなくても、間接的にコードを生成しています。そして、生成できるものにはかなりの裁量があります。「フルバイブコード」に行ってLLMを実行させると、以前の1000倍を生成でき、解読不能な混乱状態に陥る可能性があります。それは悪いことでしょうか?プロトタイプや小さな個人的なプロジェクトに取り組む場合、それは問題ではありません。しかし、それ以外のすべての場合、コードの品質は依然として非常に重要です。LLMはプロジェクトを理解し、解決策を提案できると主張するかもしれませんが、私はそれらが劇的に失敗し、幻覚を見るのを見てきました。コードを読み、アーキテクチャを理解できる能力は依然として重要です。これは当然のことのように聞こえるかもしれませんが、多くの開発者がそれに失敗するのを見てきました。その結果、私は手作業で生成していたであろう品質レベルに達するまでPRを繰り返し、速度を低下させています。気に入らない点に気づくたびに、それを ~/.gemini/GEMINI.md/~/.claude/CLAUDE.md に追加して、エージェントが私のスタイルを模倣できるようにしています。過去数ヶ月で、以下のような行をいくつか追加しました。
- マジックナンバーや文字列を使用しない。適切な場合は定数、さらに良い場合は列挙型を使用する。
- コードのインデントを減らす。アローアンチパターンを避ける。早期リターンとcontinueを活用する。
- 関数パラメータにブール値の代わりに列挙型を使用する。
- レイヤリングを尊重する。レイヤーを貫通しない。
- コードの読者が呼吸できるようにする。論理的なコードブロックの間に空行を追加する。ブロックが*何*をするのか、そして*なぜ*そうするのかを説明する短い、的確なコメントを追加する。
私が遭遇した最大の困難は「コンテキストスイッチ」です。複数のプロジェクト/独立した機能に取り組むことで、複数のエージェントを同時に駆動できます。それに追いつくのはかなりの精神的な体操です。私は「メンタルバーンアウト」の報告を見てきましたし、個人的にも精神的な疲労が増加した経験があります。これは間違いなく監視すべきことです。
LLM時代のコードレビュー
ツールがこれほど優れているので、コードレビューではるかに高い期待を寄せています。今となっては、悪いコミットメッセージにはほとんど言い訳ができません。良いコミットメッセージの書き方に関するガイドはたくさんあります。私がこれまでに出会った中で最高のガイドはこれです。LLMに要約させて、追加できる指示に変換するのに1分しかかかりません。コミットメッセージを書くときは、次の7つのルールに従ってください。
ルール1:件名行と本文を1つの空行で区切る。
ルール2:件名行は50文字に制限する(絶対的なハードリミットは72文字)。
ルール3:件名行の最初の文字を大文字にする。
ルール4:件名行の末尾にピリオドを付けない。
ルール5:件名行では命令形を使用する(例:「バグを修正」「機能を追加」ではなく、「修正した」や「追加した」)。テスト式:これは、「適用された場合、このコミットは[あなたの件名行]を行います」という文を完成させる必要があります。
ルール6:Gitのフォーマット問題を避けるため、本文テキストを72文字で手動で折り返す。
ルール7:「どうやって」ではなく、「何と」「なぜ」を説明するために本文を使用する。コードが「どうやって」を説明していると仮定し、メッセージはコンテキストと理由を説明する必要があります。
コードの作成ははるかに労力が少なくなったため、SWE(ソフトウェアエンジニア)には、より多くの注意を払ってエレガントなソリューションを設計することを期待しています。PRが混乱している場合、コードの明瞭さ/コードの単純さの改善を求めることにためらいはありません。PRのコードサイズについても同様です。PRをより小さく、レビューしやすい部分に分割するのはかつては面倒でしたが、今はそうではありません。正当な理由がない限り、著者にPRを分割するように依頼することに問題はありません。
多くのコードレビューツールには、現在LLMが統合されています。最初のパスを自動的に実行するために、独自の好みのプロンプトを作成できます。私が所有するコードベースについては、GEMINI.md/CLAUDE.md の内容を追加しており、ワンクリックでトリガーできます。PRをレビューに送信する前に、まずLLMに批判/間違いを探すように依頼します。これにより、レビュー担当者の時間を無駄にすることがなくなります。
テストを書くことはかつては苦痛でした。今はそうではありません。各PRに対して単体テスト/CIテストを要求することは問題ありません。大規模なリファクタリングがますます一般的になっているため、これらはかつてないほど重要になっています。
依存関係を拒否することは、今ではより許容されるようになりました。かつては、中程度に複雑なものを書くことを避けるための常套手段でした。今朝も、プロジェクトに依存関係を追加する代わりに、Levenshtein距離関数を書くようにLLMに依頼しました。