今、何を作るか？—Theo Browne氏

AI エージェントの進化がもたらすパラダイムシフト：「スケアモルフィズム」からの脱却と「Too Big」の崩壊

AI モデルがコード生成から自律的なタスク実行、さらには他モデルをオーケストレーションする段階へと急速に進化している今、ソフトウェア開発の常識は根本から書き換えられつつあります。Sonnet 3.5 から Mythos へ至る進化は、単なる効率化ではなく、「スケアモルフィズム（旧来の習慣への執着）」からの脱却を迫り、以前はスタートアップや大企業しか手がけられない領域が、個人開発者のサイドプロジェクトレベルで実現可能になるという劇的なパラダイムシフトをもたらしています。

AI エージェントの進化：指示から「拡張」へ

AI モデルの進化は、単なる性能向上ではなく、開発者の役割そのものを変容させています。Theo Browne 氏は、この進化を3つの段階に分類して説明します。

まずSonnet 3.5 の時代は、「ツール呼び出し」が可能になった時期です。コードベースの文脈を理解し、日常的なコーディング作業を一貫性高く実行できるようになりましたが、まだ開発者の指示に従ってステップバイステップで動く段階でした。

次にOpus 4.5 の登場は、長時間タスクを実行できる能力の獲得を意味します。数時間かかる作業を、開発者が細かく指示しなくても「欲しいもの」を伝えるだけで、自身で計画を立てて完了させることができます。これは、開発者の役割が「指示を出す人」から「拡張されたパートナー」としての変化を示しています。

そして現在、Mythos（および Fable） と呼ばれる最新モデルは、「オーケストレーション」の時代です。コードベースを理解するだけでなく、自分自身の能力を再評価し、必要に応じて他のモデルを起動してタスクを分割・実行します。さらに、カスタムツールや複雑なソフトウェアファクトリーを構築する必要すらなく、AI 自身がシステムを構成して作業を完了させます。

「Mythos は、コードベースを理解するだけでなく、自分自身も理解し、追加モデルを起動して作業を分割する方法を知り、より確実に完了できるようにする最初のモデルのように感じます。」

この進化により、以前は開発者が壁にぶつかって諦めたような複雑なタスクも、AI の能力範囲内であれば解決可能になります。重要なのは、モデルの進化速度が人間の改善速度を上回っているため、私たちは「より良く」なることよりも「より大きく（スケール）」することを目指す必要があるという点です。

スケアモルフィズムからの脱却：iOS 7 の教訓

開発者が AI の真価を引き出すためには、「スケアモルフィズム」と呼ばれる心理的障壁を乗り越える必要があります。これは、iOS 7 のデザイン転換に例えられます。

iPhone 6 の時代、アプリは現実の物理的な物体（革製の財布や木製のコンパスなど）を模倣したデザインが主流でした。しかし iOS 7 で Apple は、見た目のリアリティよりも実用性を重視するフラットなデザインへと移行しました。当時のユーザーからは「 downgrade（後退）」だと批判されましたが、新しいインターフェースは情報伝達において圧倒的に優れており、すぐに慣れ親しむことができました。

現在のソフトウェア開発者も同様に、「スケアモルフィズム」の段階にいます。ターミナルや Git、特定の言語への執着です。私たちは「慣れているから」「昔からそうしてきたから」という理由で、非効率なワークフローを正当化しています。

「なぜ環境ファイルをコミットできないのか？他のファイルはすべて問題なく取得できるのに。これは愚かです。単に Git がそのように作られたからです。」

Git の設計思想が業界の思考を支配し、私たちは「なぜそうするのか」という本質的な問いを失っています。Vim や特定の言語への誇りも同様で、かつてはエンジニア不足のために許容されていた「アイデンティティ」に固執することが、AI 時代には不要になっています。

エンジニアとしてのプライドと「スケアモルフィズム」の崩壊

AI エージェントが普及した今、開発者が抱える心理的負担も劇的に減っています。従来の開発現場では、「誰かが長時間かけて作ったコードを削除する」という行為に罪悪感が伴いました。しかし AI 時代には、作業を停止してリセットしても、AI が即座に新しい解決策を生み出せるため、過去の成果への未練や「スケアモルフィズム」から解放されます。

「エージェントの素晴らしい点の一つは、作業を停止しても罪悪感を抱く必要がないことです。」

言語やフレームワークに対する固執も不要です。かつて「JavaScript を書くのは本物の開発者じゃない」といった偏見がありましたが、AI がコードを書き換えられる時代において、特定の言語へのアイデンティティはもはや意味を成しません。エンジニアとしてのプライドを捨て、AI が最も得意とする新しいアーキテクチャやワークフローを受け入れることが、真の生産性向上につながります。

製品構築の階層再定義：「Too Big」の境界線が消失する

AI の進化は、プロジェクトの規模定義そのものを書き換えています。Browne 氏は、以前は以下のように分類されていたと指摘します。

• サイドプロジェクト: 個人や小規模チームで構築できるもの
• スタートアップ: 一定の機能範囲を持つビジネス
• Too Big（大きすぎる）: AWS や Salesforce のような大規模インフラ、独自 OS の開発など、個人には不可能な領域

しかし現在、この境界線は崩壊しています。AI を活用すれば、以前は「スタートアップ」レベルだったものが「サイドプロジェクト」で実現可能になります。逆に、「Too Big」とされていた領域の定義も不透明になっています。

例えば、Markdown ファイル一つで動作するサービスが、今や「スタートアップ」レベルの価値を持ち得ます。Browne 氏は自身の事例として、GitHub の PR を AI が自動レビューし、優先順位を付けて HTML に変換して S3 にアップロードするシステムを紹介しました。これは単なる Markdown ファイルとスクリプトで構築されたものでありながら、複雑な業務フローを自動化しています。

「Markdown ファイル一つで動作するサービスが『スタートアップ』レベルになり、以前は不可能だった『広範な機能範囲（AWS や Salesforce への挑戦）』を AI を使って短期間で実現可能になる。」

かつて AWS や Salesforce と競うことは「Too Big」とされていました。しかし現在は、適切なプロンプトと努力次第で、データベースプラットフォームやクラウドインフラを数日で製品に組み込むことが可能です。重要なのは、AWS のすべての機能を模倣することではなく、特定の領域で深く機能を提供し、ユーザーが不足している部分を自分で拡張できるようなアーキテクチャ（Slack の成功例のように）を設計することです。

結論：今こそ「大きすぎる」の定義を書き換える時

AI エージェントの進化は、開発者の思考様式と製品構築の規模感を根本から変えています。スケアモルフィズムからの脱却、言語やフレームワークへの固執からの解放、そして「Too Big」という概念の崩壊。これらはすべて、私たちに「以前は理にかなっていたものを却下し、今では理にかなったアイデアを生み出す」よう求めています。

開発者はもはや、既存の技術的制約や業界の常識に縛られる必要はありません。AI の能力範囲内で、より広範かつ深い製品を短期間で構築する戦略へ移行することが、これからの時代に必要なマインドセットです。「大きすぎる」と思っていた領域が、実は次なる挑戦の入り口である可能性を信じて、今こそ大きな夢を描く時なのです。