AI時代のソフトウェア開発において、人間のプログラマーが持つ「怠惰」という美徳が失われる危険性を、ソフトウェアエンジニアのブライアン・カントリル氏が自身のブログで論じています。
プログラミング言語のPerlの生みの親として知られるラリー・ウォール氏は『Programming Perl』で、プログラマーの3つの美徳として「怠惰」「短気」「傲慢」を挙げています。ここでいう「怠惰」とは単なる手抜きではなく、「将来の自分や他者の作業を減らすために、よりよい抽象化や単純な設計を考え抜く姿勢」を意味しています。
そのため、カントリル氏は、LLMを放置することはシステムをより良くするのではなく、既存の混乱の上にさらに大量のコードを積み重ねる可能性があると警告しています。コード行数のような見かけの指標には訴えやすい一方で、設計の単純さ、認知負荷の低さ、将来の保守性といった本当に重要なものを損なう恐れがあるというわけです。
カントリル氏は、「人間には時間や認知負荷という制約があるからこそ、複雑なシステムを前にして、より明快な抽象化や単純な構造を求める動機が生まれる」と述べ、「優れたエンジニアリングは制約から生まれるものであり、時間や負荷の制約を持たないLLMが自発的に同じ判断を下すことは期待できない」としています。
ただしカントリル氏は、LLMそのものを否定しているわけではありません。LLMはソフトウェアエンジニアリングにおける強力な道具であり、技術的負債への対処や開発上の厳密さを高めるために役立てることはできると述べています。
カントリル氏は、LLMを人間の「怠惰」に代わる存在として扱ってはならないと強調し、「LLMは人間のよい怠惰に従わせるべき道具であり、単にコードを増やすためではなく、より単純で強力なシステムを作り、将来の開発者にも役立つ形で使うべき」だと論じました。
⇧ まぁ、「AI」を利用する以上、「幻覚（ハルシネーション）」の問題も相まって、「保守・運用」の負担が上がるのは致し方ないということですかね...
とりあえず、「AI」によって「変更容易性」など考慮されない「コード」が量産されるのは避けられない気がするので、「影響範囲」の特定が困難になっていて、
- 機能追加
- 障害対応
といったタスクの難易度が上がっているのは間違いない気がしますな...
そもそもとして、「ソフトウェア開発」の「情報」が整備されていないので、「AI」が善い「設計」を考慮できなくても不思議ではないという気もしますな...
Grafana Image RendererのCVE-2025-11539の対象はDockerイメージに限らないのでは
結論は、Dockerイメージに限らず影響を受けるようです。
本記事の最後で上げたissueをご覧くださいませ。
とりあえず、
⇧ 上記の「GitHub」の公式の情報だと、「Dockerイメージ」に対してしか述べられていない...
で、
⇧ 上記の「アメリカ」の「国立標準技術研究所（NIST：National Institute of Standards and Technology）」が公開している「情報」を見ても、対象はハッキリしない...
ちなみに、「Grafana Image Renderer」の導入方法について、
⇧ 公式の「ドキュメント」によると、
- Install with Docker
- Install with binarise
の2択となっているのだが、
⇧ 上記によると、「Install with plugins」という方法も用意されている。
まぁ、
⇧ 上記によると、2025年9月の時点で非推奨（deprecated）になったようなのだが...
とは言え、古い「バージョン」の「Grafana」を利用している場合、「plugin」を利用している可能性もあると思うのだが、
⇧ 改めて、上記には、「Dockerイメージ」についてしか触れられていないのよ...
少なくとも、
- Install with Docker
- Install with binarise
- install with plugins
⇧ 上記の3パターンが対象になりそうなものなのだが...
と言うわけで、
⇧ 上記の疑問を投げてみたところ、レスポンスがむっちゃ早かった、感謝。
まぁ、何が言いたいかと言うと、一次情報は極力「ファジー」な部分を無くして、正確な「情報」を提供して欲しいのよね...
語弊を招く「情報」だと、一次情報として意味が無いように思えてしまいますしな...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
