※本記事は、ChatGPT/Gemini/perplexityによる意訳+翻訳、情報ソースを活用し、レイアウト調整したものです。
※元記事を見て、内容がズレていないか査読するようにしています。
※感想は、オリジナルです。
原文
「AIは過剰に宣伝されているが、ツールとしては大いに信じている」、リーナス・トーバルズ氏が東京開催のOpen Source Summit Japan基調講演で語ったこと（前編） － Publickey
「あなたが修正するのは自分だけのバグではない」、リーナス・トーバルズ氏が東京開催のOpen Source Summit Japan基調講演で語ったこと（後編） － Publickey
意訳+要約
長尺だが、簡潔に要点だけ。
現場に言ったわけではないので、あんまり雰囲気感は出せてない。全部伝聞。
前編：AIに対する見解
AIへの見解： AI全般の話題は過剰に宣伝されているため嫌いだが、ツールとしては大いに信じている。
- コードを書くAIよりも、メンテナーとして重要なコードレビューを支援するAIに興味がある。
- AIツールが人間のレビューを超える問題を発見したこともあった。
コンパイラが過去にプログラミングを1000倍効率化したように、AIもツールとして開発効率を上げるが、コンパイラほどではない
後編：Linuxの後方互換性と開発方針
"リグレッションを起こさない"は技術的に極めて難しく、長期維持には多大な努力が必要。
開発者は新しい改善を好む傾向があるが、「自分の修正が他者のシステムを壊すこと」を強く意識する必要があると警告。
Linux開発では「古いインターフェースは維持し、新しい機能は新しいインターフェースで提供する」方針を徹底している。
検証
AI全般の話題は過剰に宣伝されている可能性
過剰宣伝の具体例
企業が「AI搭載」を謳う「AI washing」（過剰表現）が横行し、実際の機能が限定的なケースが多い。
2025年現在、AI市場は2440億ドル規模に膨張する予測ですが、生成AIの派手なデモが実務ニーズ（複雑統合やデータガバナンス）を上回るハイプ状態。
AIの「現実」と「見方」
AIには誇大広告の部分がある一方で、ツールとしての本質的な価値は非常に高いと多くの専門家が認識しています。
- ツールとしての価値: Linuxカーネルの開発者であるリーナス・トーバルズ氏のように、「AIは過剰に宣伝されているが、ツールとしては大いに信じている」と述べる意見もあります。コンパイラや他のITツールと同様に、生産性を大きく向上させる力は間違いなく存在します。
- 現実的な導入: 成功の鍵は、完璧なAIを待つのではなく、自社の具体的な課題を特定し、AIをその解決のための一つのツールとしてどう活用できるか、冷静に検証し、小さな一歩を踏み出す姿勢にあります。
AIブームは、投資の急増と企業の心理的な動機（競争に乗り遅れたくないという焦り）によって過熱している側面があるため、情報の受け手側も熱狂に踊らされることなく、冷静な視点を保つことが重要です。
参考リンク
MIT Tech Review: AI企業の誇大広告に「待った」、米FTCが政権交代前の大仕事
生成 AI はハイプサイクルの幻滅期に入るのか？｜Hi-Noguchi | 株式会社きみより代表
「生成AIブームは終了？」ハイプサイクルで読み解く今後の展開
AI開発競争の過熱が生んだ誇大宣伝はいつ終わるのか…そのときはスタートアップにも影響がおよぶ | Business Insider Japan
AI in 2025: From Hype to Reality – What’s Next? - hyperight.com
製造業におけるAI：誇大広告を超えて実ビジネス価値を創出する | Forbes JAPAN 公式サイト（フォーブス ジャパン）
過剰なAI報道が招く大きな誤解 AIと機械学習と混同していないか | テクノロジー｜DIAMOND ハーバード・ビジネス・レビュー
AI Hype vs. Reality: The Value of the AI Technology for Businesses in 2025 | SPD Technology
リグレッションを起こさないための手法
- 回帰（リグレッション）テストの自動化
- 変更後の無影響確認
- リスクベースで重要テストを選別し、変更に合わせて範囲を変える
- 自動化必須
- バグ修正時は必ずテストケースを追加
- カバレッジの向上（重要なロジックは高く保ち、バグが潜んでる箇所のリスクを下げる）
- CI/CDパイプラインの活用
- 頻度を高く保ち、迅速に問題を検出
- ペアプログラミング / モブプログラミング
- 見落としやミスの抑制
- フィーチャートグル / カナリアリリース
- リスクを限定的な範囲に抑えながら新機能を展開
- 問題発生時もすぐ切り戻し、ロールバック可能な構成にする
- 監視・モニタリングの強化
- 即座に異常を検知
参考リンク
10 Best Practices for Regression Testing: Improve Software Quality with Opkey
リグレッションテストとは？デグレーションの確認は必要不可欠！ - システム開発のプロが発注成功を手助けする【発注ラウンジ】
リグレッションテスト自動化とは。CI/CD時代の回帰テスト戦略 - FSI Embedded
感想＋雑記
AIブームが加熱要因としては、誇大広告が主要因だが、それに加えて、乗り遅れたくないという人たちの心境が拍車を賭けてそう。
今は、AIがどんなものか見えてきて、どこにどうやって適用するのかが重要という認識でいる。
万能説には懐疑的だったが、リーナスさんも似た考えを持っていたことは驚いた。過激な印象だったので、もっと過激に批判するかと思ったが、レビューツールとして使っている点にも驚いた。自分もAIの適用を考えていたが、同じくレビューで利用しようと考えていた。自分は、開発に最初は適用させようと考えていたが、不確定要素が多すぎて、精度が低く、開発者を惑わせると感じたので断念して、レビューやテストケースの抽出での利用を考えていた。レビューは、比較的精度が高く、見て欲しい観点を伝えたら、予想通りの指摘をしてくれたので、有用だという判断でいた。リーナスさんも似たような判断だと知って、ちょっと誇らしかった。
リグレッションを起こさないのは、開発している身として、難易度が高いことは重々承知している
言うは易く行うは難し事案だとは思っている。
調べた限りだと、手法として目覚ましいの、そんなに出てない認識でいる。カナリアリリースが比較的新しいだろうか？今は、リリースで問題発覚した場合に切り戻すことを考えてからリリースに望むので、それに近しいことをしているが、やっぱり工数はかかるんだよね。。。
たまに、リグレッション防止で２回レビューをやってるって、他の現場での報告で聞いたことを、調べてる途中で思い出した。個人的には、その考えには懐疑的。
なぜなら、俺なら手を抜くから。もう一人の方がちゃんと見るだろうって感覚がどうしても出てきてしまう。
責任感が薄まるのが問題なんだよね、複数回やるのは。
チェック増やして問題増えたって事例は、何回か聞いたことがあるので、ダメだろうと思ってる。
結局は、古典的な手法が一番安全な認識。
カオスエンジニアリングって手法も聞いたことがあるが、あれは、組織全体が理解してないと実現は厳しそう。
