ハクソク

世界を動かす技術を、日本語で。

AIには知恵がなく、あなたにもそれはない

2026年9月22日原文(alexn.org)

概要

  • AIの普及 により、コードを読む・書く習慣が減少傾向
  • 保守性や設計の悪化 はすぐには現れず、長期的な問題となる
  • AIや初心者向けルール では本質的なコード品質は測れない
  • エキスパートの直感 や経験が不可欠
  • AI依存のリスク と今後の「NO-AI」戦略の可能性

コードを読まなくなった業界のリスク

  • 最近よく耳にする「コードレビューは終わった」「もう誰もコードを読まない」という風潮
  • コードを読まずに進めるプロジェクトは、 長期的に保守不能な混乱 に陥る危険性
  • コードの保守性や良い設計は、 短期間では評価できない 特性
    • 問題が明らかになるのは 数ヶ月～数年後
  • 悪いコードの特徴
    • 読みにくい、理解しにくい、将来の変更に弱い
    • 一箇所の変更が予測不能なバグを引き起こす「バタフライ効果」現象
    • 機能追加のたびに複数箇所を修正し、 一貫性が崩壊
    • 設計の不変条件（インバリアント）が不明確、 作者不在で品質維持困難
    • テストが困難で、 モックや実装詳細の露出が多く、リファクタリング困難

コード品質の評価とエキスパートの直感

  • 悪いコードの発見には 時間がかかる 事実
  • 経験豊富なエンジニアは 「コードの臭い」 を直感で察知し、早期に対処可能
  • この直感は 文脈依存 であり、 厳密なルール化は不可能
  • エキスパートは ルールを作る側 であり、 初心者向けルールには従わない
  • 初心者とエキスパートは 同じルールでは成長できない

AIとコード保守性の課題

  • AIは コードの保守性 を学習できていない
    • 強化学習では 即時の報酬信号 が必要だが、保守性は 長期的な評価が不可欠
  • AIは主に 初心者向けのルールブック から学習
  • 野生のコードベースは 品質が低いものが多く、AIもそれを模倣
  • 保守性を測る 明確なフィットネス関数 が存在しない
    • もしあれば リンターに実装済み のはず
  • AIによる「コードの単純化」は現状 非効率的
    • 小さい関数への分割が 再利用性や可読性を損なう場合 が多い
    • 良い関数設計は 熟練の技術 であり、AIや多くの開発者には難しい

AI依存とエンジニアの成長喪失

  • AIに コードの記述・読解を依存 する人が増加傾向
  • その結果、 自らの判断・責任・学びの機会が失われる
  • AIがミスをしても、 人間もAIもその失敗から学ばない
  • 成長機会の喪失 と 品質低下のリスク

AIはあくまで道具

  • LLM（大規模言語モデル）は 優れたツール であり、筆者も日常的に活用
    • 退屈な作業の自動化や 効率化には有用
  • しかし 過度な依存は危険
  • 革命的なツールも いずれは日常化し、特別ではなくなる
  • 技術の未来は 予測困難 だが、 NO-AI戦略 を掲げる企業が増える可能性

NO-AI戦略とソフトウェア開発の本質

  • 今後、 「NO-AI」方針 を競争優位とする企業の増加予測
  • ソフトウェア業界は 自動化が本質 であり、LLMだけが自動化手段ではない
  • 文脈によっては AI導入が逆効果 となる場合も
  • 「コーディングは解決済み」ではなく、 本質的な課題は残る
  • 無意味なCRUDアプリの再発明より、 新たな価値創造が重要
  • AI利用の責任 を持たない企業や個人には、 将来的な悪影響 が及ぶ可能性

まとめ AIは便利なツールだが、 本質的なソフトウェア開発力や保守性 は人間の経験・直感・責任に依存。 AI依存のリスク を認識し、 主体的な学びと判断 を忘れない姿勢が今後ますます重要。

Hackerたちの意見

「技術的な知識や興味がない人によって作られた雰囲気」と「手書きのドメイン駆動設計開発」の間には連続性があるよね。コーディングエージェントを使って、かつメンテナブルなコードを持つことは全然可能。でも、そう言わないとコーディングエージェントが魔法のようにすべてをメンテナブルにしてくれるわけじゃない。「コードのメンテナビリティと良いアーキテクチャには、適用できる良い測定基準がない」って誰が言ってるの？コードのメンテナビリティを測る方法はたくさんあるよ。サイクロマティック複雑度はその一つに過ぎない。SonarQubeのメトリクスをエージェントのコーディングワークフローに組み込むことを妨げるものは何もないよ。

└

著者はメンテナビリティという測定基準を認めているね。これを測る方法には定量的なものと定性的なものがあって、一番のシグナルは完全な放棄だよ。

└

そう、コーディングエージェントが魔法のようにすべてをメンテナブルにしてくれるわけじゃない。これが問題なんだ。メンテナビリティについて知っていて、気にかける必要がある。で、「2025年以降一行もコードを書いていない」人たちの多くは、気にしてないんだよね。

└

コーディングエージェントを使って、かつメンテナブルなコードを持つことは全然可能。でも、そう言わないとコーディングエージェントが魔法のようにすべてをメンテナブルにしてくれるわけじゃない。トリリオンドルの質問は、もし従業員が気にしなかったらどうやってこれを実現するかってことだよ（彼らはコードの質じゃなくて給料や時間を最適化してるから）。AIのスロップと良いメンテナブルなコードを見分ける方法もないしね。（もしできたら、ただAIを訓練するだけだろう。）AI以前は、良いプログラマーと悪いプログラマーを見分ける方法が少しはあったけど、今はAIとスロップ生成があるから、ほとんど無理になった。

└

できるけど、誰もやらないよね。もちろん、AIじゃないスロップもたくさんあるし。（こんにちは、systemd）

└

でも、そうだね、コーディングエージェントは、指示しない限り、すべてをメンテナブルにしてくれるわけじゃないよ。まだね。数年後には、新しい基準がベンチマークに入って、AIがデフォルトで今まで見た中で最も明確で賢いコードを作るようになると思うよ。

└

たくさんの測定方法はあるけど、記事にもあったように、良い測定方法を見つけるのがポイントだよね。サイクロマティック複雑性は、メンテナビリティ研究コミュニティでは数十年にわたり、かなりしっかりと否定されてきた。Sonarの認知的複雑性メトリックは少しマシだけど、ある研究では、プログラマーが実際にコードを読むのにどれだけ苦労したかとの相関が約0.5しかないことがわかった。最も正確なコードの複雑性を測る方法は、目の動きやEEGのようなものを使わずに、結局は「雰囲気」 - プログラマーに理解するのが難しいと思うかどうかを聞くことだった。https://www.frontiersin.org/journals/neuroscience/articles/1... Halstead Effortは2位で、そこそこ良いスコアだったけど、こちらの研究ではあまり良くない結果も出てる。SonarQubeのメトリックはさらに悪くて、相関は0.35しかない。https://www.sciencedirect.com/science/article/abs/pii/S01641...

└

//「技術的知識や興味がない人が作った雰囲気コード」と「手書きのドメイン駆動設計開発」の間には連続性がある。その連続性の中間には、「ドメインからの高水準の英語の概念（明確に定義されたもの）を使ったドメイン駆動の仕様」と「いくつかの標準アーキテクチャの選択」が位置している。

└

でも、そうだね、コーディングエージェントは、指示しない限り、魔法のようにすべてをメンテナブルにしてくれるわけじゃない。でも、それは実際には変化じゃないよ。人間も、指示しない限り、魔法のようにすべてをメンテナブルにしてくれるわけじゃないし（指示してもそうならないかもしれない）。彼らを監視して、トレーニングし続ける必要があるんだ、基本的には永遠にね。

もう、ただコードを書けばいいじゃん。人に作らせて、デザインさせて、調整させればいい。誰が気にするの？この投稿を書いてる人たちは誰なの？彼らの言うことに何の価値があるの？この投稿、すぐに飽きるよ。

└

同意するけど、問題は理解を外注しちゃうことだよね。

└

これは時代の産物だよ。ソフトウェアの技術に情熱を注いでいる人もいれば、ただの仕事だと思っている人もいるし、感情的なつながり（怒りや情熱、どんな感情でも）を通じて関与を促進する文化全体がある。大多数の人は、ただ黙っていて、議論に興味がなくて、好きなことをするのに忙しいってことが見えないんだよね。

Hacker Newsで議論の続きを見る