kbits

747とコーディングエージェント

原題: 747s and Coding Agents
著者: Carl Kolon
公開日: 2026-02-27
ソースURL: https://carlkolon.com/2026/02/27/engineering-747-coding-agents/
アーカイブ日: 2026-04-17


要約

著者は数年前、ドイツ出張からの帰路で、長年747を操縦してきたベルギー人パイロットと隣り合わせになる。機械工学を学び、可変ジオメトリーのジェットタービンについて熱心に語るその人物は、誰が見ても飛行機好きであり、自分の仕事に深く適合した人に見えた。著者はその姿に羨望を覚えるが、当のパイロットは、747を知り尽くした今となっては、昨日より今日の自分が上達している感覚はない、と物寂しげに語る。飛ばすことはできても、設計する側ではない。新しく学ぶことを仕事の中心に置ける職業のほうが、むしろ羨ましいのだという。

この会話は、のちに著者自身の仕事観を反転させる伏線になる。海軍を離れてプログラマーになったばかりの頃、著者にとって実装とは、機能追加やバグ修正を通じてシステム理解を深める営みだった。たとえばウェブサイトにページネーションを追加するなら、まず公式ドキュメントを読み、必要なプラグインを探し、設定例を読み、試して、失敗したらさらに調べて再試行する。その一連の過程は面倒ではあっても、なぜその仕組みが必要なのか、どこが壊れやすいのか、システム全体がどう動いているのかを身体化する学習でもあった。同じ問題に再び出会えば、次はより速く、より深く対処できる。生産と学習が同じ回路の中にあった。

初期のLLMは、この過程の入口で検索エンジンの代役を務める程度だった。エラーメッセージを貼り付けて当たりをつけたり、最初の探索コストを下げたりはしたが、それでも最終的には自分で理解し、自分で設計し、自分で実装する必要があった。ところが、ここ数か月のコーディングエージェントは、その位置づけを変えた。いま著者は、新しい変更が必要になったとき、まず理解から始めるのではなく、エージェントに一発で解かせられないかを試す。失敗しそうなときだけ人間が介入する。この介入頻度は下がり続け、任せられる仕事の粒度はどんどん大きくなっている。

著者は、コーディングを目的ではなく手段として捉えている。だから、エージェントによって以前より多くのことを達成できるようになった事実そのものは歓迎している。しかし同時に、自分が技能や知識を以前ほど速く獲得できていないことに違和感を抱く。AIに任せて作った機能をあとでもう一度作ることになっても、前回より自分が速くなるとは限らない。二十年にわたってAIと一緒にコードを書いても、最後に残る自分の技能がそれほど増えていない未来すら想像できる。747の操縦士が語った「改善がない」という感覚が、自分の職業にも入り込んできたのである。

さらに問題を厄介にするのは、AIが大きな仕事を引き受けるほど、人間が途中から介入するときの認知負荷が増すことだ。著者が読むのは、自分が段階的に組み立ててきたコードではなく、ほぼ完成形として突然差し出された他人の解答である。ただし、それは少しだけ間違っている。人間は、問題と解法に徐々に馴染んでいく代わりに、完成品に近いが微妙に壊れた成果物の査読者として呼び出される。コードレビューはもちろん必要だが、コードを書くこととは学習の質が違う、と著者は言う。レビューだけでは、作ることで得られる理解は代替できない。

著者は、こうした状況に対する安直な反論も退ける。これから重要になる技能はプロンプト能力なのではないか、という見方には同意しない。プロンプトはすでに簡単であり、今後ますます簡単になるだろう。コーディングエージェントの成否を本当に左右するのは、プログラミングと問題領域についての堅い知識であり、設計判断を支える理解である。にもかかわらず、その知識を育てる工程が、エージェントの普及によって「必須の副産物」ではなくなりつつある。

最終的に著者は、コーディングエージェントの不可逆性を認める。使わないのは愚かだ、とまで言い切る。しかしそのうえで、もっとも上手く使いこなせるのは、依然として対象領域を深く理解している人だと強調する。だからこそ、実務効率のためではなく教育目的として、一定量のコードを手で書くことには意味があるかもしれない。あるいはまず自力で解法を考え、自分の答えに確信が持ててからAIの出力と照合するほうがよいかもしれない。著者の提案は、AIを拒むことではなく、学習を生む実践を意識的に再設計することである。


論評

この文章の強みは、コーディングエージェントを生産性や雇用の話だけで語らず、技能形成という見落とされやすい軸に引き戻した点にある。747パイロットの逸話は単なる導入ではなく、成熟した職能が抱える停滞感と、AIによって変質しつつあるソフトウェア開発の感覚を一つの像に重ねる装置として機能している。比喩が効いているだけでなく、その比喩が本文全体の論旨を最後まで支えている。

また、著者はAI礼賛にもAI拒絶にも寄らず、実務上の有用性を認めたうえで、その副作用として学習の回路が断たれることを指摘している。このバランスの良さが、ありがちな懐古論や煽動的な未来予測から文章を救っている。特に、レビューは執筆の代替ではない、プロンプト能力よりも領域理解が設計判断を左右する、という指摘は、今後も繰り返し参照されうる実務的な観察である。

長期的価値という点でも、この文章は一時的なツール比較ではなく、人間が何によって熟達するのかという普遍的な問いに触れている。コーディングエージェントの性能が上がるほど、この問いはむしろ重くなる。将来、AI支援開発がさらに当たり前になったとき、私たちはどの局面で意図的に学習の機会を確保するべきか。その判断を考えるための短く鋭い基準点として残る文章だと思う。