Scribble at 2026-08-05 10:53:27 Last modified: unmodified

まず最初に注意として、このサイトというかページは GenAI のスクレイピングに対応しないので、ブラウザのサイド・バーで使う Copilot などに内容を要約させると、AI が適当に一般論を列挙して解説し始めるという典型的なハルシネーションが起きる。必ずしもページからコンテンツ（文章）を読み取れなかったとは「自白」せずに勝手な妄想で記事を要約したりするから、やはり僕らのように原文をそもそも読める人間でなければ危なくて使えない。思うのだが、生成 AI のサービスって１年前と比べてすごくパフォーマンスや品質が逆に落ちたような気がするのだけれど、これは攻撃に使えるからというチューニングをやりすぎてる結果なのだろうか。それとも、生成 AI の improvement にはスケール則が通用しない何らかの原理的な限界があるという兆候なのだろうか。ここでの話題とはあまり関係ないが、実はそういう「限界」があると嬉しいなと思っていたりする。なぜなら、既にその「限界」の範囲内でも個人で制作する画像や音楽は十分なクォリティに達しているからだ。そこを超えて、国家間で情報戦を繰り広げるような性能なんて、僕らには必要ない。もちろん、そういう品質を達成するからこそ、他にも用途はあるのだろうけど、いまのところ生成 AI で癌の特効薬を見つけた話なんて全く聞いたこともないし、AGI なんていうスローガンにしたって、自分たちで作った基準（しかもコンピュータ・サイエンスのプロパーですら同意しない基準）で言ってるだけの話だ。

さて、上に紹介する論説は、ソフトウェア開発における生成 AI の導入だとか成果の測定について蔓延している誤解（神話）を、実証研究や調査データに基づいて分析・反論したものだ。

神話1：開発者は時間の大部分をコード記述に費やしている

ソフトウェア開発はデザイン、ミーティング、レビューなどの協調作業が多くを占める。2025年に Microsoft が実施した調査では、開発者が実際にコードを記述している時間はプロジェクト全体の達成に費やされた時間の約 14 % に過ぎないことが示されている。これは僕らのような中小零細企業でサーバ構築やプログラミングをやっている立場でも似たようなことが言える。なので、コーディングの時間が生成 AI で大幅に短くなれば、プロジェクトの所要工数や日数が大幅に節約できるというのは錯覚である。ただし、クライアントや経営者というのは、これが錯覚であることを分かっていて、わざと工数を短くするために生成 AI の話をこじつけていたりするので、これを「錯覚である」と会議などで指摘する場合は、相手をよく見てから言うことだ。そして対照的に、これが錯覚であることが理解できない極め付きのバカも、上場企業の企画部とか情シスとか中小企業の経営者には意外と多いので、これまた注意が必要だ。バカに正論や事実を語っても、クレヨンしんちゃんに量子力学を説明するようなものであり、おおむね無意味である。寧ろ、受託案件の進捗や契約関係、あるいは経営判断でのリスクがない限りは、クライアントや経営者なんて馬鹿を馬鹿のまま懐柔する方がマシだ。

神話2：コーディングが開発のボトルネックである

コーディングが全体の約 15 % にとどまるため、AI で記述速度を2倍にしても全体生産性の向上は 15 % 未満にとどまる。開発プロセスの最遅フェーズ（アウター・ループ）に対処せずにコーディング（インナー・ループ）だけを加速させると、レビューやテスト待ちのコードが増加し、後流に負荷を転嫁するだけに終わる。これは、実際に多くのプロジェクトで起きていて、しかも出てくる「成果」の大半が AI スラップというガラクタのようなコードであるため、レビューする工数そのものが浪費されてしまう。これによってレビューするエンジニアのメンタルにも悪影響がある。

神話3：AI が生成したコードの行数が指標になる

コード行数（LOC）は、実は生産性や成果との統計的関連性を持たない指標であることが知られている。日本とか呼ばれている猿の生息地では、「死ぬほどプログラミングしていたい」などとブログに書いて、コーディングした行数を高らかに宣伝する上場企業の小僧や下っ端のプログラマが大量にいたり、数日で何万行のプログラムを書いたベンチャーの社長が自ら英雄譚としてビジネス書を書いたりする、僕らのようにコンピュータ・サイエンスの素養がある者からすれば非常に恥ずかしい話が横行している（そういう人たちは熱意でプログラミングを独学した人々であって敬服には値するが、しかしソフトウェア・エンジニアリングの学識はないので、こういうプロパーなら熟知している常識というものがない）。なんにせよ、コーディングの行数を成果の指標にすると、開発者が質の高い設計や協調作業よりもコードをただ単に吐き出すことだけを優先するようになり、技術的負債やセキュリティ上の欠陥を増やす原因となる。もっとも、セキュリティなんて後から考えたらいいとか、経産省に怒られたり X で炎上してから対処すればいいと思っている上場企業やベンチャーは多いので、こういう指摘が本当に有効かどうかは疑問がある。慶応閥や東大閥、あるいは金融機関とのコネだけでヒルズや中央区に事務所を構えるような、脱法行為の IT ゴロツキどもに、法や道徳やプライバシーやリスクを説いても無駄であろう。

神話4：AI は全てのタスクあるいは全てのエンジニアに役立つ

生成 AI の効用は条件によって異なる。定型的・反復的なタスクや慣れたタスクでは高い効果を発揮するかもしれないが、複雑な作業や創造的なタスクや熟練開発者でこそ達成できるような暗黙知が有効な環境では、生成 AI の導入は逆効果になることがある。また、プロンプトの記述精度や個人のモチベーション、開発者の経験年数なども影響する。

神話5：AI は個々の開発者の生産性を10倍に引き上げる

実務における開発はチーム単位の協調や知識の共有、システムの複雑性に依存する。孤立した限定的タスクで測定されただけの生産性の向上といった報告は、たいていの企業が置かれている複雑な環境のチーム開発にそのまま適用できるものではない。ただし、僕は安易な否定論にも疑問があって、実際に生産性は向上すると思う。それが10倍などという意味不明な数値でないのは明らかだが、少なくとも何倍かにはなると思うので、導入を安易に拒絶することもまた愚かだと思う。やはり、生成 AI でいくらか達成できる生産性の向上が明白なら、凡人はともかくとして、余剰となる無能は会社から追い出すべきだ。

神話6：AI を活用できるかどうかは個々の開発者の努力次第である

過去の多くの実例から言えるのは、生産性の抜本的な向上は個人のレベルで解決したり達成できることではなく、組織的なシステムの変更によってもたらされてきた。それゆえ、アメリカの企業でも日本の QC 活動などに着目してきたわけである。個々のエンジニアに ChatGPT の法人アカウントを与えて、各自で最適化させる手法には限界がある。AI の価値を引き出すには、組織レベルでワークフローやプロセスを再設計する必要がある。

神話7：優れた AI ツールであれば自然と導入が進む

そうではない。人間的・組織的・認知的障壁が存在するので、そう簡単ではない。AI 利用に対する評価の偏見（能力の低い人物とみなされるペナルティ）や、生成された結果に対する不信感（回答精度を信頼している開発者は 29 % にとどまる）、デバッグにかかる認知負荷の増大、スキル低下への懸念などが導入の妨げとなっている。そう。寧ろ一部の人々は妥当な理由もなく積極的に AI を遠ざけているのであって、これもまた安易な導入と同じ程度に考慮しなくてはいけない課題だ。

神話8：生成 AI を使えば大企業もスタート・アップ並みの速度で革新できる

スタート・アップ企業と大企業では置かれている前提条件が異なるので、それは無理である。スタート・アップ企業が一般的なオープン・ソースをベースに新規開発を行うのに対し、大企業は AI が学習していない独自のレガシー・システムや厳格なコンプライアンス、セキュリティ、上位互換性の維持といった構造的制約を抱えている。また、こういうことを言うのは自分でも気が引けるわけだが、上場企業の多くは社内の経理・財務系のシステムでは組織に特有の業務フローに対応した処理を実装しているだけではなく、その中には会計監査を誤魔化すための、いわば帳尻合わせのためのサブ・システムが実装されていたりする。要するに建前だけで動く帳簿システムだ。実際には、ノートに記載されてシステムに登録されていない情報とか数値が本体だったりする（もちろん、政治家への献金やヤクザへの上納金、あるいは役員がキャバ嬢に与えた渋谷のマンションの家賃を、交際費以外のどういう仕訳にするとかだ。漫画のようだが、これは高級クラブの内情を少し知っている僕の見聞きした経験では、現実に多くの上場企業にある）。