技術だけでどこまで作れるのか - OSSライブラリから考察するソフトウェア開発の境界

1. 最近注目しているC#のOSS

C#/.NETのライブラリを探していると、長年使われている定番とは別に、最近になって非常に興味深いプロジェクトに出会うことがある。

その中でも、個人的に注目しているのが OwnAudioSharp と ProGPU だ。

2. OwnAudioSharpが面白い理由

https://github.com/ModernMube/OwnAudioSharp

OwnAudioSharpは、C#から利用できるオーディオエンジンを、Rustを中心としたネイティブ実装と組み合わせて構築している。低レイヤーのオーディオI/OからDSP、ミキシング、各種オーディオ機能までを一つのエンジンとしてまとめ、C#側から利用できる形にしている点が興味深い。

オーディオライブラリというと、C#/.NETでは長年使われてきたNAudioや、商用のFMOD、BASSなどが候補になる。それらと比較したとき、OwnAudioSharpの面白さは、単なるAPIの豊富さではない。

C#だけで完結させるのではなく、Rust側に低レイヤーのオーディオ処理を置き、C#との間をFFIで接続する。

CPALはここでAudio Deviceへの入出力を抽象化する役割を担う。OwnAudioSharpはその上にMixerやDSP、EffectsなどのEngine側の機能を構築している。つまり、CPALそのものを.NETから呼び出すのではなく、低レイヤーのAudio I/O基盤を利用して、その上に独自のAudio Engineを構築している。

この構造を成立させるには、C#だけ、Rustだけ、あるいはAudio APIだけを知っていればよいわけではない。Realtime Audio、DSP、並行処理、メモリ管理、FFI、各プラットフォームのオーディオ事情など、複数の専門領域をまたぐ必要がある。

さらに重要なのは、C#からNativeコードを呼べることと、実用的なAudio Engineとして成立させることは全く別の問題だということだ。

こうしたプロジェクトを見ていると、コード量よりも「一人の開発者が扱っている問題の種類」に驚かされる。

3. ProGPUが面白い理由

UI方面で興味深いプロジェクトがProGPUだ。

https://github.com/wieslawsoltes/ProGPU

ProGPUは、GPUを中心とした.NET向けの描画基盤を目指している。WebGPUなどの既存基盤を利用しながら、Vector Graphics、Text、Composition、Sceneなど、より上位の描画機能まで構築しており、こうした描画基盤を単独のGraphics Libraryとして完結させず、AvaloniaやWPFのようなUI Frameworkから利用できるRendererとして統合しようとしているかなり巨大なプロジェクトだ。

例えばWPFやAvaloniaのようなUI Frameworkでは、アプリケーションがButtonやTextBox、PanelといったUI要素を配置すると、そのUIを実際に画面へ描画するためのRendererが必要になる。

ProGPUが目指しているのは、この「Renderer」より下の部分をGPU中心の新しい基盤で置き換えられるようにすることだ。つまり、アプリケーション開発者がGPU APIを直接操作するのではなく、

Button / Text / Image
        ↓
UI Framework
        ↓
ProGPU
        ↓
WebGPU
        ↓
GPU

という形で、既存の.NET UI開発の延長線上からGPUを利用できるようにする。
そのためProGPUは、単なる「C#からGPUを使うためのAPI」というより、GPU描画を.NETのUIエコシステムへ接続するための基盤として見ると分かりやすい。

ProGPUは、ゼロからGPUドライバやGPU APIを作ろうとしているわけではない。むしろ、すでに存在する複数の低レイヤー基盤を組み合わせ、その上に.NET向けの高レベルな描画・コンポジション基盤を構築するという方向性を取っている。

大まかに見ると、次のような階層になる。

┌──────────────────────────────────────┐
│ .NET Application / XAML Application │
├──────────────────────────────────────┤
│ Avalonia / Uno / WinUI              │
├──────────────────────────────────────┤
│ ProGPU                               │
│  ├─ Composition                      │
│  ├─ Vector Graphics                  │
│  ├─ Text                             │
│  ├─ Scene                            │
│  └─ GPU Compute                      │
├──────────────────────────────────────┤
│ Silk.NET                             │
├──────────────────────────────────────┤
│ WebGPU / wgpu-native                 │
├──────────────────────────────────────┤
│ DirectX / Vulkan / Metal / OpenGL等 │
├──────────────────────────────────────┤
│ GPU / Driver                         │
└──────────────────────────────────────┘

ここで重要なのは、ProGPUそのものがすべての層を置き換えようとしているわけではないことだ。

WebGPU / wgpuという「共通のGPU基盤」

まず下側にあるのがWebGPUと、そのネイティブ実装の一つであるwgpuだ。
これは、DirectX、Vulkan、Metalなど各プラットフォーム固有のGPU APIを直接アプリケーションから扱うのではなく、より共通化されたGPU APIとして利用するための基盤になる。

この層を自前で作る必要がないというのは非常に大きい。
例えば、

ProGPU
   ↓
WebGPU
   ↓
DirectX / Vulkan / Metal

という構造にすることで、ProGPU自身は各GPUベンダー・各OSのAPI差をすべて直接抱え込まずに済む。これは「手を抜いている」のではなく、抽象化の境界を適切な場所に置いていると見るべきだろう。

Silk.NETが.NETとNative Graphicsの橋になる

その上で、C#/.NET側との接続にSilk.NETを利用する。
ここも重要なポイントだ。

C#からDirectXやVulkan、OpenGL、WebGPUなどのNative APIを直接扱うためには、単純な関数呼び出し以上に、

• Native handle
• pointer
• struct layout
• callback
• resource lifetime
• ABI
• platform-specific type

などを考える必要がある。

Silk.NETはこうしたNative Graphics APIとの.NET側の接続を担う。
つまりProGPUの作者は、

「C#からGPU APIを叩くためのFFI層」

まで全部自分で発明するのではなく、既存の.NETバインディングを利用して、そのさらに上の問題に集中している。

この判断が非常に合理的だ。

ProGPUを実際のUI Frameworkへつなぐ

ProGPUの面白さは、GPU描画基盤そのものだけではない。
普通なら、

「新しいRendererを作ったので、既存のアプリは全部ProGPU向けに書き直してください」

となる。
しかし、それでは普及させるのが非常に難しい。

新技術を作ることと、既存資産を捨てさせることは別問題だからだ。

例えばProGPU.SkiaSharpでは、SkiaSharp互換APIをProGPU側のVector、Text、Imaging、Path、Compositingなどへ接続する互換層を用意している。
概念的には、

既存アプリ
    │
    │ SkiaSharp API
    ↓
ProGPU.SkiaSharp
    ↓
ProGPU
    ↓
WebGPU
    ↓
GPU

となる。この構造が非常に重要だ。
また、ProGPU上に実際の.NET UI Frameworkを接続するプロジェクトも存在する。

https://github.com/wieslawsoltes/wpf
https://github.com/wieslawsoltes/winforms

LibreWPFはWPF互換のUI Frameworkを目指し、LibreWinFormsはWinForms互換のUI Frameworkを目指している。ここにProGPUを組み合わせることで、従来のWindows向け.NET UI APIに近い開発モデルを維持しながら、より新しい描画基盤へ接続するというアプローチが可能になる。

ここが興味深いところで、既存のWPFやWinFormsに慣れた開発者にとって重要なのは、

• Window
• Button
• TextBox
• Layout
• Event
• Control

といったUIのプログラミングモデルであって、GPUのCommand BufferやPipelineを直接操作することではない。
そのため、

GPU技術
   ↓
ProGPU
   ↓
UI Framework
   ↓
既存の.NET開発モデル

という複数の層を組み合わせることで、GPUの進化をアプリケーション開発者から隠蔽しながら、既存のUIエコシステムへ新しい描画基盤を導入することができる。

これはProGPUの思想を理解する上で重要なポイントだ。
ProGPUの技術的な面白さは「GPUを直接触っている」という点ではなく、

既に存在する優れた基盤を見つけ、それらを組み合わせ、その間を埋める実装を作り、最終的に既存のアプリケーションまで接続する

というところにある。この「縦方向のパイプライン」を個人プロジェクトとして構築していくこと自体が、かなり大きな仕事だ。

そしてこれは、先ほど挙げたOwnAudioSharpにも通じる。
OwnAudioSharpも、CPALという既存の低レイヤー基盤を利用しながら、その上に独自のEngineを構築している。

だから両者を並べると、

既存基盤を使うことと、既存基盤に依存するだけであることは全く違う

ということがよく分かる。
既存技術を適切に利用しながら、その上にどのような抽象化を構築するか。
そこには、単純な実装量とは別の設計能力が必要になる。

4. 「全部自作」より難しいこと

先に挙げた二つのライブラリに共通しているのは、単なるAPIラッパーではないことだ。低レイヤーの既存技術を利用しながら、その上に独自の抽象化とエコシステムを積み上げている。

そして、この二つを眺めていると、単に「凄いライブラリがある」という話を超えて、個人開発でどこまでソフトウェアを構築できるのか、という興味深い問題が見えてくる。

ソフトウェア開発では、独自実装そのものが技術力の証明のように語られることがある。
しかし、実際には既存技術との統合の方が難しい場合も多い。
例えば、

既存技術A
    ↓
既存技術B
    ↓
新しい基盤
    ↓
既存API
    ↓
既存Framework

という構成を成立させるには、それぞれの技術の境界を理解しなければならない。

OwnAudioSharpならC#とRust、Audio EngineとOS Audio APIの境界、
ProGPUなら.NET、GPU API、Renderer、UI Framework、既存Graphics APIなどの境界がある。

さらに難易度を上げるのが、クロスプラットフォーム対応だ。

クロスプラットフォームは「同じコードを動かす」だけではない

一見すると、クロスプラットフォーム対応は、

Windows
macOS
Linux

それぞれで動けばよいように思える。

しかし、低レイヤーまで降りていくと、それぞれのプラットフォームには異なるAPI、ライフサイクル、制約、挙動が存在する。

例えばオーディオなら、

                 Audio Engine
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
     Windows        macOS         Linux
        │             │             │
     WASAPI        Core Audio    ALSA / PipeWire

という差異を吸収する必要がある。

GPUでも同様に、

                  Renderer
                     │
        ┌────────────┼────────────┐
        ↓            ↓            ↓
     DirectX       Vulkan        Metal
        │            │            │
     Windows        Linux        macOS

のような違いが存在する。

さらに、単純にAPIの呼び出し方が違うだけではない。
メモリ管理、スレッド、デバイスのライフサイクル、エラー処理、同期、入力、ウィンドウ管理など、プラットフォームごとに微妙な差異が積み重なっていく。

そのため、

「Windowsで動いたので、あとはmacOSとLinuxにも対応させればいい」

というほど単純ではない。

抽象化の難しさ

クロスプラットフォームライブラリを作る場合、最終的にはこれらの違いを上位層から隠蔽する必要がある。

                共通API
                   │
        ┌──────────┼──────────┐
        ↓          ↓          ↓
     Windows     macOS      Linux
        │          │          │
     Native      Native      Native
      API          API        API

しかし、抽象化しすぎれば各プラットフォーム固有の機能を使えなくなる。
逆に、プラットフォーム固有の機能をそのまま公開すれば、今度は共通APIとしての意味が薄くなる。つまり、

「どこまでを共通化し、どこからをプラットフォーム固有として残すか」

という設計判断が必要になる。
これは単純な実装量の問題ではない。抽象化の設計そのものがライブラリの価値を左右する。

個人開発では「対応する」ことより「維持する」ことが難しい

さらに個人開発で厳しいのは、最初に複数プラットフォームで動かすことよりも、その状態を長期間維持することだ。

Windows
   ├─ OS Update
   ├─ Driver Update
   └─ API Changes

macOS
   ├─ OS Update
   ├─ Hardware Changes
   └─ API Changes

Linux
   ├─ Distribution
   ├─ Desktop Environment
   ├─ Audio / Graphics Stack
   └─ Configuration Differences

一つのプラットフォームで問題が発生した場合でも、開発者がその環境を日常的に使っていなければ、再現するだけでコストがかかる。

まして個人開発では、Windows、macOS、Linuxの実機を常に用意し、それぞれの環境でテストし、ユーザーから報告された問題を再現して修正するという作業そのものが大きな負担になる。

つまりクロスプラットフォーム対応とは、

一度すべてのOSで動かすことではなく、異なる世界の変化を継続的に吸収し続けること

でもある。

プロジェクトは「完成」してからが長い

そして、もう一つ個人開発で見落とされやすいのが、プロジェクトそのものの継続性だ。ライブラリは、一度完成して公開すれば終わりというものではない。

OSやコンパイラ、依存ライブラリ、GPUドライバ、SDKなど、周囲の環境は継続的に変化していく。

          自分のプロジェクト
                 │
    ┌────────────┼────────────┐
    ↓            ↓            ↓
   OS          Compiler     Dependencies
    │            │            │
    └────────────┼────────────┘
                 ↓
          継続的なメンテナンス

さらにライブラリを利用するユーザーが増えれば、

• Issueへの対応
• Pull Requestのレビュー
• バグ修正
• ドキュメント更新
• Breaking Changeへの対応
• セキュリティや互換性への配慮
• 新しいプラットフォームへの対応

なども必要になってくる。
ここには、単純な「実装能力」とは別の能力が必要になる。
そして個人開発の場合、最も大きな問題は開発者自身がプロジェクトを続けられるとは限らないことだ。

仕事、生活、興味の変化、別のプロジェクトへの移行など、技術とは無関係な理由でも開発が止まる可能性がある。これはOSSの弱点というより、むしろOSSが「人間によって維持されるソフトウェア」である以上、避けられない性質でもある。

「作れる」と「存在し続ける」は別の問題

ここで、個人開発の評価について一つ重要な視点が出てくる。
ある開発者が非常に高度なライブラリを一人で作れることと、そのライブラリが10年後も利用できることは、全く別の問題だ。

技術力
  ↓
プロトタイプ
  ↓
実用化
  ↓
継続的メンテナンス
  ↓
エコシステム
  ↓
長期的な信頼

後ろへ行くほど、必要になる能力の種類が増えていく。

特にUI FrameworkやGraphics、Audioのようにプラットフォームとの結びつきが強い領域では、周辺環境の変化を追い続ける必要がある。
そのため、個人開発のプロジェクトを見るときには、

「これを一人で作ったのか」

だけでなく、

「これを一人で維持し続けられるのか」

という視点も重要になる。

「全部自作」ではなく「適切に任せる」

だからこそ、OwnAudioSharpがCPALのような既存基盤を利用し、ProGPUがWebGPU / wgpuやSilk.NETなどを利用していることには大きな意味がある。

自分ですべてのプラットフォーム差異を直接扱うのではなく、

Platform
    ↓
既存の低レイヤー基盤
    ↓
自分の抽象化
    ↓
.NET API
    ↓
Application

という形で責任範囲を整理できるからだ。
これは「自分で作っていないから凄くない」という話とは正反対だ。
むしろ、

どこまでを自分の責任として引き受け、どこから下を既存基盤に任せるのか

を判断すること自体が、高度な設計能力になる。
このようなプロジェクトを見ると、優れたソフトウェア設計とは「全部を自分で作ること」ではなく、何を自分で制御し、何を既存基盤に任せるのかを判断することでもあると分かる。

そして個人開発の場合、その判断はさらに重要になる。自分で抱え込める技術的範囲には限界があるからだ。優れた既存基盤を利用することで、その限界を越えて、より上位の問題に集中できる。

5. AIだけでは解決できないもの

ここまで見てきたOwnAudioSharpやProGPUのようなプロジェクトを見ると、現在の個人開発者が到達できる技術的な範囲の広さに驚かされる。特に生成AIの普及によって、コードを書くことそのもののコストは大きく下がった。

しかし、それによってソフトウェア開発の難しさがすべて消えるわけではない。むしろ、コードを書く以外の問題が以前よりもはっきり見えるようになった。例えば、

• 何を作るべきか
• どこまでを自分で実装するか
• 既存技術のどれを採用するか
• 抽象化の境界をどこに置くか
• クロスプラットフォームの差異をどう吸収するか
• どこまで互換性を維持するか
• 何を捨てて何を優先するか

といった問題は、コード生成だけでは解決できない。
AIに指示すれば、ある程度のコードを生成することはできる。
しかし、

CPALを使うべきなのか、それとも別のAudio Backendを採用するのか。
C#とRustの責務をどこで分けるのか。
Realtime Audioの制約をどこまでAPI設計に反映させるのか。
Windows、macOS、Linuxの差異をどの層で吸収するのか。

といった判断は、最終的にはプロジェクトそのものを理解していなければできない。

これはProGPUでも同じだ。WebGPU、wgpu、Silk.NET、SkiaSharp、Avaloniaなど、既存の技術を組み合わせること自体はAIにも支援できる。しかし、

何を使うか
    ↓
どこで接続するか
    ↓
何を抽象化するか
    ↓
何を捨てるか
    ↓
誰に使ってもらうか

という設計判断は、単純なコード生成とは別の問題になる。
AIによって「実装」の価値が下がるほど「判断」の価値が上がる

これは、個人開発にとって必ずしも悪いことではない。これまでは実装コストが高すぎて手を出せなかった領域でも、AIによって調査、試作、定型コードの生成、デバッグなどを高速化できるようになった。
その結果、

アイデア
  ↓
設計
  ↓
プロトタイプ
  ↓
実装
  ↓
検証
  ↓
改善

というサイクルを個人でも高速に回せるようになった。
しかし、サイクルが高速になったからといって、良い方向へ進むとは限らない。間違った設計を高速に実装することもできるからだ。

コードを書く速度が上がれば上がるほど、「何を作るのか」「どこが間違っているのか」を判断する能力の重要性はむしろ増していく。AIは実装を高速化できても、生成されたものが本当に正しいかを判断するには専門知識が必要だ。そのためAIは、専門知識を持つ開発者にとって、単なる代替手段というより実装能力の増幅器になりやすい。

そして、ここでOwnAudioSharpやProGPUのようなプロジェクトが面白く見えてくる。重要なのはコードの行数ではない。既存技術を理解し、適切な境界を設計し、複数の技術を組み合わせ、実際に動くシステムとして成立させる。その「設計して成立させる能力」こそが、AI時代になっても簡単には自動化されない部分なのだと思う。

6. 技術だけでは解決できないもの

ここからは、筆者が考える「技術だけでは解決しにくい問題」である。

GPU RendererやAudio Engineのようなシステムは、非常に高度ではあるものの、基本的には技術的な問題として閉じることができる。

ところがUI Frameworkになると事情が変わる。

Renderer
   ↓
Input
   ↓
Keyboard / Touch / Pen
   ↓
IME
   ↓
Focus
   ↓
Accessibility
   ↓
Platform Convention
   ↓
User Experience

ここには、単純な「正しい実装」だけでは解決できない問題が大量に存在する。

WindowsとmacOSでは入力の挙動が違う。
AndroidとiOSではUIの文化そのものが違う。
日本語IMEのような入力システムは、単純なKeyDown/KeyUpイベントだけでは扱えない。
Accessibilityもまた別の巨大な領域になる。

そして最も難しいのは、仕様上正しくてもユーザーが「使いにくい」と感じる可能性があることだ。UIには、技術仕様だけでは定義しきれない「手触り」がある。

Linuxデスクトップが示す難しさ

この問題を考える上で、Linuxデスクトップは興味深い例だと思う。

Linuxには、技術的に見れば非常に多くの優れた基盤が存在する。
Wayland、X11、Mesa、Vulkan、GTK、Qt、各種Window Manager、Desktop Environmentなど、GUIを構成するための技術は決して不足していない。それどころか、個々の技術だけを見れば非常に高度なものも多い。

それでも、LinuxデスクトップはWindowsやmacOSのような「一つの統一されたデスクトップ環境」としては主流になっていない。

ここで重要なのは、これを単純に「Linuxの技術力が低いから」と説明することはできないということだ。
むしろ逆で、Linuxには非常に多くの選択肢がある。

この自由度はLinuxの大きな魅力である一方、デスクトップ全体を一つの製品として見ると難しさにもなる。例えばアプリケーション開発者からすると、

「Linux向けに対応しました」

だけでは、Windowsほど単純な意味にならない。

どのDesktop Environmentを想定するのか。
どのWindow Systemを使うのか。
テーマやフォントはどうするのか。
IMEはどう動作するのか。
通知、クリップボード、ドラッグ＆ドロップ、ファイルダイアログ、スクリーンキャプチャ、アクセシビリティなどはどう扱うのか。

さらに、Distributionによって標準構成まで変わってくる。
つまり、単純に「LinuxというOSに対応する」というだけでは、ユーザーが期待するデスクトップ体験まで保証できない。

「技術がない」のではなく「統一する主体」が違う

ここが重要なポイントだと思う。
WindowsやmacOSでは、OSベンダー自身が、

Windowing
Input
IME
Accessibility
Font
UI Guidelines
Desktop Integration
Hardware Support

などについて、ある程度一貫した方向性を示すことができる。
もちろんWindowsやmacOSにも互換性問題やプラットフォーム固有の癖は大量にある。
しかし、少なくともアプリケーション開発者から見れば、

「このOSでは、このようなUIと入力体験が標準である」

という共通認識を作りやすい。

一方でLinuxデスクトップでは、複数のプロジェクトや組織が異なる思想で開発している。
これはOSSとしては非常に健全な構造でもある。しかし、
「誰もが同じ環境を使い、同じ期待を持つデスクトップ」
を作るという目的に対しては、別の難しさが生まれる。

つまり問題は、「優れた技術が存在するか」だけではなく、
「それらを一つのユーザー体験として統合し、長期間維持する主体が存在するか」
という問題になる。

UI Frameworkにも同じ問題がある。
これは、先ほどのProGPUの話ともつながってくる。
GPU Rendererを作ること自体は、技術的な問題としてかなり閉じている。
しかし、それをUI Frameworkへ組み込むと、

GPU Renderer
   ↓
UI Framework
   ↓
Input / IME
   ↓
Accessibility
   ↓
Platform Integration
   ↓
Application
   ↓
User

と問題の範囲が急激に広がる。
さらに複数のOSをサポートするなら、各プラットフォーム固有の問題を吸収し続けなければならない。

ここまで来ると、Rendererの技術力だけでは完成度を決められない。
実際のユーザーから大量のフィードバックを受け、それぞれの環境で問題を再現し、修正し、またユーザーに試してもらう。このループそのものが製品の品質になる。

だからUI Frameworkは、単なる「コードを書く問題」から、徐々に「現実世界との接続を維持する問題」へ変わっていく。

7. 個人開発と企業開発の違い

この問題に対して企業が強いのは、単純に開発者の人数が多いからだけではない。
大量のユーザーやコミュニティから継続的にフィードバックを受け取る仕組みを持っているからだ。

Users
  ↓
Feedback / Telemetry
  ↓
QA / UX Research
  ↓
Engineering
  ↓
New Version
  ↓
Users

このループを大規模に回せる。

UI Frameworkの場合、実際に何万人、何百万人が使った結果として初めて分かる問題がある。IME、Accessibility、入力デバイス、ウィンドウ操作、DPI、タッチ、キーボード操作など、実際の利用環境から得られる知見は非常に多い。

個人開発者が高度なRendererを作ることは可能でも、世界中のユーザーから継続的にフィードバックを得ながらUIの完成度を高めることは難しい。

ここには、技術力とは別の強さがある。

8. Steamが示す「プラットフォーム」の強さ

この話をさらに広げると、Steamのようなプラットフォームがなぜ強いのかも見えてくる。
Steamは単なるゲームストアではない。

ゲーム、ランタイム、Input、Cloud、Community、Proton、SteamOS、Steam Deckなど、ゲームを取り巻く複数の要素を一つのエコシステムへまとめている。

特にProtonは象徴的だ。

Windows向けゲームをLinuxへ移植するよう開発者に要求するのではなく、既存のWindows向けゲームをLinux側で動かすための互換レイヤーを構築する。

これは、既存のエコシステムを壊すのではなく、既存資産を自分のプラットフォームへ取り込むという戦略だ。

ProGPUのような個人OSSとSteamを同列に扱うことはできない。
しかし、

新しい基盤を作りながら、既存の資産やユーザーをどう取り込むか

という問題には共通する部分がある。

9. コンピュータの世界に存在する異なる種類の「難しさ」

ここまでを見ると、ソフトウェアを単純に「難しい」「簡単」と分類することはできない。
例えば、

物理・ハードウェア
        ↓
CPU / GPU
        ↓
OS / Driver
        ↓
Runtime
        ↓
Engine / Framework
        ↓
Application
        ↓
UX
        ↓
Ecosystem / Platform

下の層では、数学、物理、アルゴリズム、アーキテクチャなどが重要になる。
この領域では、突出した個人が非常に大きな成果を上げる余地がある。

一方、上の層へ行くほど、人間、組織、ユーザー、文化、市場といった要素が強くなる。
つまり、

技術一本で突破できる世界と、技術だけでは閉じない世界が、同じコンピュータの中に存在している。

AIによってコードを書くコストが下がるほど、ソフトウェア開発における本当のボトルネックが見えやすくなる。専門知識を持つ個人は、AIによってさらに高速に実装できる。

一方で、AIだけでは大量のユーザーを獲得することも、ユーザーの「なんとなく使いにくい」を継続的に観測することもできない。

その意味では、AIによって個人開発者の技術的な到達点が上がる一方で、企業が持つ「ユーザーとの接続」や「エコシステムを維持する能力」の価値もより明確になるのかもしれない。

10. 個人開発の可能性

OwnAudioSharpやProGPUを見ていると、個人が技術的に到達できる範囲は以前考えていたよりずっと広い。

既存の低レイヤー基盤を利用し、複数の技術領域を組み合わせ、適切な抽象化を作る。
そしてAIによって、その実装速度まで引き上げられる。

一方で、UIやプラットフォームのように、ユーザーとの継続的な接触が必要になる領域では、企業やコミュニティの持つ強さが依然として大きい。

だからこそ、単純に「個人開発が企業開発を置き換える」と考える必要もない。
個人にしかできないことと、組織だからこそできることが、それぞれ別の場所に存在している。

おわりに

AIにより、一人の開発者が驚くほど深い技術領域を掘り下げることができるようになった一方で、ユーザーの体験を磨き、大規模なエコシステムを維持し、異なるプラットフォームを一つの体験へまとめるには、また別の能力が必要になる。

「どこまで技術だけで世界を作れるのか」

そして、

「どこから先は、人間や組織そのものを扱わなければならないのか」

その境界が見えてくるほど、コンピュータの世界はむしろ面白くなる。
AIによって実装能力がさらに拡張されていく今だからこそ、この境界を観察することには意味があるのかもしれない。