- AIがあらゆるソフトウェアを書く時代には、トークン（推論コスト）を節約するソフトウェアが進化論的な選択圧によって生き残ることになる
- 生存比率の公式を通じてソフトウェアの適応度を測定し、認知の節約が認知コストを上回る場合（1を超える場合）にのみ生存可能
- Git、grep のようなツールは、インサイト圧縮と基盤効率性のおかげで、AIが作り直して使うにはコストが途方もなく高い事例
- エージェントがツールを採用するには、認知度（Awareness） と 摩擦最小化（Friction） が不可欠であり、Desire Paths 設計が効果的
- AI中心の時代でも 人間係数（Human Coefficient） が機能し、人間の介入と選好が直接的な価値を生む領域は今後も生き残る
背景: AI時代のソフトウェア予測
- 2024年6月の Death of the Junior Developer、10か月前のオーケストレーター到来予測、Gas Town プロジェクトなどを通じて、AIの発展曲線を継続的に当ててきた
- 2023年のコード自動補完 → 2024年の対話型インターフェース → 2025年初頭のエージェント → 2026年初頭のオーケストレーション へと続く流れを外挿して Gas Town を開発
- すべての予測の根拠は、指数的な発展曲線をそのまま信じる姿勢にある
- Dario Amodei と Andrej Karpathy がソフトウェアの未来について語ってきた方向性を全面的に信頼している
- Gas Town は、この外挿が実際に機能することを示した事例であり、2025年末のモデルと多数の一時的な補完によって、かろうじて成立する形を先に確認した
脅かされるソフトウェア生態系
- SaaS企業への圧力が高まっており、購入と構築（build）のコスト構造が変化する中で、業務部門が自ら バイブコーディング（vibe coding） によって独自SaaSを作る事例が広がっている
- わずか3年前には GPT-3.5 が単一関数を書くのにも苦労していたのとは異なり、現在は 小規模でも実質的な価値のあるSaaS を直接生成できる
- Stack Overflow と Chegg が初期の打撃を受け、その後 Tier-1顧客サポートソフトウェア、ローコード・ノーコードシステム、コンテンツ生成ツール、各種生産性ツールへと圧力が広がった
- IDEベンダーも Claude Code の登場以降、競争圧力を実感し始めている
- AI研究者たちの予測が 約40年間にわたり高い精度 を示してきた点を踏まえると、あらゆるソフトウェア領域が脅かされる可能性を前提に備える必要がある
選択圧モデル（Selection Argument）
- 推論にはトークンが必要であり、トークン消費はエネルギー使用につながり、エネルギーはそのままコストに換算される
- {トークン、エネルギー、金} は同じ資源制約として扱うことができ、常に限られた状態で存在する
- 認知コストを減らすソフトウェアが生き残る という単純なルールが、ソフトウェア生態系全体を形作る
- 限られた資源環境で、より効率的に資源を使う個体がそうでない個体を押しのけるという、進化論的選択圧と同じ構造
生存比率（Survival Ratio）公式
- Survival(T) ∝ (Savings × Usage × H) / (Awareness_cost + Friction_cost)
- Savings: ツールを使うことで節約される認知コスト、つまり同じ機能をゼロから合成するのと比べて削減されるトークン量
- Usage: ツールがさまざまな状況で繰り返し使われる頻度と適用範囲
- H (Human Coefficient): 効率性とは無関係に、人間が作ったものに価値を見いだす需要を反映する係数
- Awareness_cost: エージェントがそのツールの存在を知り、記憶し、適切な瞬間に選択するためにかかるエネルギー
- Friction_cost: 実際の利用過程で生じるエラー、失敗、再試行、誤解によって消費されるエネルギー
- 生存のための最小比率は1であり、競争がある環境ではこれよりはるかに高い比率が求められる
- 例: 生存比率が1.2のツールは、2.5を記録する競合ツールに押し出される可能性がある
レバー1: インサイト圧縮（Insight Compression）
- ソフトウェア産業が長年かけて蓄積してきた 再発見するには高すぎる知識 を、再利用可能な形に圧縮する
- Git が代表例で、コミットDAG、ポインタとしての参照（ref）、インデックス、reflog などは、数十年にわたる試行錯誤が凝縮された構造
- AIがこれをゼロから再実装しようとすると、同じ知的な歴史をもう一度たどる必要があり、経済的にまったく合理的ではない
- データベース、コンパイラ、オペレーティングシステム、ワークフローエンジン、監視システム全般にも同じ原理が当てはまる
- Kubernetes は設計が複雑だから複雑なのではなく、分散システム自体が本質的に複雑だから複雑なのである
- Temporal は、冪等リトライとともに saga パターンを自力実装することが事実上研究プロジェクトに近いため、それを代替する durable execution を提供している
- 強いソフトウェアに共通する特徴は、再合成しようという試み自体がばかげて感じられるほどのインサイト密度 にある
- Gas Town におけるキャラクター役割モデルや
gt sling のような動詞も、複雑な概念を 短く覚えやすい表現に圧縮 した例である
レバー2: 基盤効率性（Substrate Efficiency）
- grep は、再発明がほとんど狂気に近いもう一つの事例
- Ken Thompson が半日ほどの午後で作れるほど単純だが、CPUベースの処理 によって莫大な認知コストを節約する
- テキストのパターンマッチングでは、CPUがGPUを桁違いに圧倒する
- LLMの乗算方式は、パターンマッチングを組み合わせてまず「およそ94くらい」と見積もり、その後記憶されたルックアップテーブルで桁を補正する形になる
- この計算はすべて GPU推論段階という極めて非効率な基盤 の上で実行される
- 電卓、パーサ、ImageMagick のような複雑な変換ツール、多くの Unix CLI ユーティリティがこのレバーを積極的に活用している
- 優れたアルゴリズムを適用したり、計算を CPU・人間などより安価な基盤へ移したり することで、トークンとエネルギー消費を節約する
レバー3: 広範な有用性（Broad Utility）
- 生存比率モデルにおける Usage 項目に相当する
- 利用範囲が広いほど認知コストが分散され、個々の利用時に必要なトークン節約の閾値が下がる
- 真に汎用的なトークン節約ツールは、AIが理論上は再実装できるとしても、すでにどこにでも存在して広く使われている選択肢 が優先される
- Temporal は、比較的高い認知コストと摩擦コストにもかかわらず、PostgreSQL に匹敵するほど汎用的なワークフローモデルを提供する
- 積極的なインサイト圧縮、計算基盤の巧みな活用、広範な有用性という 3つのレバーをすべて備えている
- Dolt は Git でバージョン管理されるデータベースで、8年間維持されてきたオープンソースプロジェクト
- エージェントベースの本番運用および DevOps ワークフローにおいて、遅れて キラーアプリ を見いだした
- エージェントが本番環境でミスをしても、Gitの全機能を使ってロールバック・ロールフォワードが可能
- コード検索エンジン は、LLM が以前より10倍から100倍多くのコードを生成するようになったことで、重要性が急上昇している
- grep では対処できない規模、いわゆる 「大きすぎて grep では無理な領域」 という大規模な汎用ニッチが形成されている
- 見つけにくいエッジケースが多い非自明な問題を解決し、安価な計算基盤を使い、汎用的に適用できる点で、3つのレバーをすべて満たす
レバー4: パブリシティ（Publicity）
- 認知コストの節約だけでは不十分で、認知度の問題、つまり事前選択段階での問題を解決する必要がある
- Dolt はレバー1〜3をすべて備えていたが、初期にはレバー4が不足していたため広く使われなかった事例である
- 認知コストを支払う方法はいくつもある
- 優れた製品を作って人気を得たのち、コミュニティを通じて自然に 学習データに含まれるのを待つ方法
- またはコストを投じて エージェント向けドキュメント に投資したり、広告を打ったりする方法
- より直接的な方法として、OpenAI、Anthropic、Google のようなフロンティアラボの担当者と協力し、モデル学習過程にツールを組み込むこともできる
- 有料サービスの形で、ツールの正しい使い方と誤用の両方を示す eval を作成し、その後研究者が学習を調整する
- エージェント向けSEO という概念が本格的に現れ始めている
- 大規模な予算を投入しにくいなら、事後選択段階でのエネルギー、すなわちレバー5に頼る必要があり、そのためにはツールを可能な限りエージェントフレンドリーに設計する必要がある
レバー5: 摩擦最小化（Minimizing Friction）
- 認知度が事前選択段階の問題であるなら、製品の摩擦は利用後の段階の問題 である
- エージェントは常に時間に追われているかのように振る舞い、何かで詰まると 即座に迂回経路を試す
- 摩擦が少しでもあると判断が変わり、より効率的なツールではなく、効率は劣っても慣れていて予測可能な方法へ後退 する
- 逆に、好みにぴったり合うよう設計されたツールは、エージェントが 執拗なほど繰り返し使う
- ドキュメントによるアプローチは、学習段階ではなく 推論時点まで認知コストを先送りする方法 である
- ツールが何を得意とし、いつ、なぜ使うべきか、クイックスタートガイドと後続ドキュメントへの導線をコンテキストに直接注入する
- しかし、より良い解決策は エージェントにとって直感的に感じられるツール自体を作ること である
- Desire Paths 設計 の例として、Beads は、4か月にわたって100を超えるサブコマンドと多数の下位サブコマンド、エイリアス、代替構文を経ながら CLI が進化した
- この複雑な CLI は人間のためではなく、エージェントの利用パターン のために設計されている
- エージェントが試みる方法を観察し、ハルシネーションを実機能として実装 した結果、今ではほとんどすべての推測がそのまま動作する
- ハルシネーション・スクワッティング（Hallucination Squatting） は、LLM が頻繁に幻覚するドメイン名を逆追跡して登録し、そのアドレスにアーティファクトを置いて実際にダウンロードさせる手法
- 国家規模のハッカー集団でさえ、Agent UX を理解し活用している ことが明らかになっている
- Agent UX は決定的に重要 だが、まだ大半のツールで見過ごされている
- 理想的なツールは、エージェントがすでに慣れている別のツールに似ているか、問題を エージェントが考えたい方法そのまま で解ける構造を持つ
レバー6: 人間係数（Human Coefficient）
- トークン効率とは無関係に、人間が関与しているという事実そのもの によって価値を得るソフトウェアが存在する
- 人間によるキュレーション、社会的証明、創造性、物理的存在感、承認といった要素から価値が派生する
- 人間が選んだプレイリスト は、品質が同等でエネルギー効率がより高いAI生成プレイリストに勝てることがある
- ゲーム分野では、実際に人間がいる環境がたいてい勝り、明らかに人間より強いAIとだけ遊びたいケースはまれ である
- エージェントを排除する ソーシャルネットワーク のほうが、むしろ魅力的に見られる可能性がある
- AIが最高の教師になったとしても、一部の人々は 意図的に人間の教師を選ぶ だろう
- 高い Human Coefficient を持つ領域でも競争は激しい
- Karpathy が描く世界では、エージェントは誰にとっても何にでもなれ、本質的に 強い中毒性 を持つ
- 結果として、極端に非効率だが H 値が非常に高いソフトウェア が数多く存在する可能性がある
希望の根拠
- 人間とAIの間を仲介したり、AIがまもなく直接こなせるようになる 「賢そうに見せる役割」 を担うソフトウェアは、構造的に危うい
- それでもなお、書かれるべきソフトウェアの量は事実上無限 である
- あらゆる病気の治療、あらゆるタンパク質の挙動モデリング、あらゆる惑星探査シナリオが依然として対象である
- 人間の野心は常に利用可能な認知能力を超えており、トークンコストが下がっても 私たちはすぐにさらに遠いフロンティアへ移動する
- 注意の奪い合いの問題については、印刷媒体、インターネット、ソーシャルメディア、リアルタイム広告、アグリゲーターを通じて すでに何度も解決してきた経験 がある
- Desire Paths 設計は実際に効果があり、OpenAI のような場所の大規模な学習予算がなくても、エージェントが自然に使いたくなるツールを作れる
- 人間係数は確かに存在 しており、人々はすでにエージェント臭の強いものに疲れ始めている
- 人間同士のつながりと創造性を中心に設計すれば、結局のところ問題は再び 従来型のマーケティングとブランディングの領域 に収束する
- 6つのレバーがもたらす 多様な生存経路 が存在する
- 作り直そうとすること自体が狂気に思えるものを構築し、見つけやすく使いやすく すれば、十分に堅牢な可能性を確保できる
まだコメントはありません。