ソフトウェア生成が安くなった今、何を作らないかを誰が決めるのか

When Anyone Can Build Software, Who Decides What Not to Build?

ソフトウェア生成が安くなった今、何を作らないかを誰が決めるのか

生成AIによってコードや設計資料の作成コストは劇的に下がったが、データ、統合、契約、運用プロセスといった「状態」は依然として蓄積し続ける。筆者は、局所的に合理的な意思決定が企業全体の非整合を生むと指摘し、生成が安くなるほど非整合のコストは高まると論じる。ボトルネックは構築能力から、何を永続化すべきかを見極める判断力へと移った。

ソフトウェアの作成コストが下がれば下がるほど、非整合のコストは高くなる。
  1. deminature

    LLMを使って高品質なソフトウェアを構築するのは、依然として非常に時間がかかる。参入障壁がどれほど低かろうと、大多数の人はわざわざやろうとはしない。時間はタダではないからだ。それに、ほとんどの人にとってソフトウェアを作ることは面白くない。電子機器を組み立てることがほとんどの人にとって面白くないのと同じ理由だ。限られた層にしか受けないニッチな趣味なのだ。この2つの理由から、ソフトウェア職はAIが登場しても生き残るだろう。

  2. OakNinja

    この問題は新しいものではない。新しいのは、開発チームを巻き込まなくても、素早いアイデア出しとラピッドプロトタイピングによって、解決しようとしている核心的な問題を誰もが理解できるようになったことだ。

    いつも通り、その後は何に注力するかを会社が優先順位付けするだけのこと——昔からずっとそうだったように。

    * 時間をかけたからといって、アイデアやプロンプトの出力に固執してはいけない。

    * コードを書くのは簡単だ。維持するのが難しい。

    * 時間を節約したり収益を生まないなら、それは単なる経費だ。

    * 出力は価値とイコールではない。

  3. anonzzzies

    我々(私の会社)には、40年余りかけて収集した、想像しうるあらゆるプロセスを含む企業向けLoBの「ベース」があり、それを使って大企業のプロセスを調べ、部門レベルで自動化を提案している。そうすれば、取締役会の承認もIT部門の承認も得ずに費用を支払えるからだ。SOTA AIは我々のベースがあれば、ほぼ独力でこれを1日か2日でやってのける。そして我々は部門予算の少し下の価格で請求する。もちろん、こうした中間管理職は自分が役に立っていると思われたいので、多くの会議には嫌味な皮肉屋の「プロジェクトマネージャー/営業担当」を送り込まなければならない。これらの会議は客観的に見て我々には無意味だが、それでも必要な苦行だ。こうした(肉空間の)会議は、フレームワークを何らかのライセンス料とSLAコストで評価するとしても、今や(純粋な)技術部分よりもはるかに高くつく。

    これらの企業、そのほとんどは多国籍企業で、大半が米国、インド、中国のオーナーによって所有されており、彼らのIT部門は文字通りすべてがひどい。20年前のJavaやC#に固執し、改善や学習のインセンティブはゼロ。AIのことは聞いたことがあるが、何にも使っていない。

    これは濡れ手に粟で、適切なレベルで入り込めればどの地域でも数十億ドルの価値がある。ただ、私の経験では、こうした部門の人々のほとんどは今日iPhoneで動くLLMに置き換え可能であり、LoBアプリは数十年の知識を持つ堅実なコンサルタントが1人いればかなり退屈なものだから、これが長く続くかはわからない。彼らはまさにそのためにLLMを訓練しているのだろうか?

  4. CurleighBraces

    少なくとも今のところ、これはもっと微妙な話だと思う。

    誰でもソフトウェアを作れるというのは本当だが、だからといってそのソフトウェアが良いわけではないし、それが特にセンスに依存するというのも本当ではない。

    例として、今コーディング経験ゼロの起業家と仕事をしているが、その人は製品をうまく作り、すでに中規模企業に売り込むことにも成功している。

    しかし、私が関与してAIを巧みに操る適切なレバーを知らなければ、最新のフロンティアモデルが彼の述べたことを達成しようと全力を尽くしても、ソフトウェアは必要な性能を発揮できなかった。

    少なくとも今のところ、経験豊富な開発者の必要性は依然としてある。

  5. ma2kx

    少し混乱している。興味深い投稿だが、彼が「ポリシー・アズ・コード」でどこへ向かおうとしているのか正確には理解できなかった。彼は「ポリシー・アズ・コードは中央アーキテクチャ機能なしで企業の一貫性を生み出す」と結論づけているが、それには同意しつつも、今日インフラ/企業・アズ・コードが欠けている点を見落としていると主張したい。少なくとも、エージェントが彼が最初に挙げた問題を解決できる、あるいは少なくとも認識できるようにしたいなら。ポリシーは我々の作業環境の境界を定義するが、作業自体を定義するわけではない。この「ノウハウ」は人々にとってはほとんど暗黙的だが、LLMには見えず、エージェントが動作するコンテキストフレームを与えられたプロンプト(そしておそらくコンテキスト内にあればポリシーによって制約される)に限定してしまう。

    彼の例を挙げるなら:

    「フロントラインのスタッフは、そのプロセスが顧客とのやり取りごとに15分の摩擦を加えるため、必須フィールドをスキップしているのかもしれない。」

    まず、それらのフィールドが必須でありながらスキップもできる場合、ポリシーがどうなっているのか不明確だ。次に、スキップしても摩擦が減るだけで他の結果がないように見えるなら、なぜそれらは必須なのか?モデルは、それらのフィールドのポリシーを強制すべきか、自動化をコーディングすべきか、それとも単に任意にすべきか、どうやって判断するのだろうか?

この日のほかの記事

2026-09-13