モデルがアプリを飲み込む時代に、残るのはハーネスである

AIの話をするとき、まだ多くの議論は
「どれだけ速くなったか」に寄っている。

コードが速く書ける。
資料が速く作れる。
画像が速く出せる。
調査が速く終わる。

もちろん、それは事実だ。
ただ、その見方だけでは足りない。

今起きている変化の本体は、
既存作業の高速化ではなく、ソフトウェアの単位そのものの組み替えである。

LLMは、アプリを速く作る道具ではない。
アプリの中にあった機能を、モデル側へ飲み込み始めている。

LLMは、スクリプトを書く補助ではない。
手順書そのものを、実行可能な契約に変え始めている。

LLMは、検索を便利にするだけではない。
未整理の知識を読み、編み直し、次に使える中間表現へ変換し始めている。

つまり、Software 3.0 の本質は
「自然言語でコードを書くこと」ではない。

自然言語で書かれた意図・手順・制約・評価基準が、実行環境の一部になることである。

ここを見誤ると、AI活用はいつまでも「便利な生成ツール」の話で止まる。
ここを正しく見ると、次の問いに進む。

モデルがアプリを飲み込むなら、
人間と組織は何を設計すべきなのか。

答えはかなりはっきりしている。
残るのは、ハーネスである。

アプリが消えるのではない。アプリの境界が溶ける

たとえば、メニュー画像を入力すると、料理の写真付きメニューに変換してくれるアプリがあるとする。
従来なら、そこには多くの部品が必要だった。

画像を読み取る。
文字を抽出する。
料理名を構造化する。
料理の意味を推定する。
画像を探す、または生成する。
レイアウトを整える。
最終画像として出す。

これは普通のアプリ開発だ。
しかし、マルチモーダルモデルが十分に強くなると、
この中間処理の多くは、モデルの内側に吸収される。

入力画像を渡す。
意味を読み取る。
必要な視覚表現へ変換する。
出力画像を返す。

このとき、アプリは何をしているのか。

もはや、処理の中心ではない。
モデルへ入力を渡し、結果を受け取り、人間が使える形に整える外枠になる。

ここで重要なのは、「開発が楽になった」ではない。
専用アプリとして作っていた機能の一部が、モデル能力に吸収されたということだ。
この吸収は、これから何度も起きる。

OCRアプリ。
要約アプリ。
翻訳アプリ。
簡易画像加工アプリ。
定型資料作成アプリ。
単純な社内検索ツール。
軽いデータ整形ツール。
フォーム入力補助ツール。

これらはすべて、単体機能としての価値が薄くなっていく。

なぜなら、ユーザーはそれを
「アプリを開いて使う機能」としてではなく、
「モデルに頼めば済む変換」として扱い始めるからだ。

つまり、アプリの境界が溶ける。
では、アプリは不要になるのか。
そうではない。

不要になるのは、単発の変換だけを価値としていたアプリである。
残るのは、変換の前後にあるものだ。

誰が使うのか。
どのデータを正本とするのか。
どこまで自動化してよいのか。
どこで人間承認が必要なのか。
失敗したらどう戻すのか。
どのログを残すのか。
どの品質基準を満たせば完了なのか。

この部分は、モデルが強くなっても消えない。
むしろ、モデルが強くなるほど重要になる。

なぜなら、モデルができることが増えるほど、
どこまで任せるかが設計問題になるからだ。

install.sh から install.md へ

Karpathyの話で特に象徴的なのが、
「install .md skills instead of install .sh scripts」という視点だ。

これは、かなり危険なほど大きな変化を含んでいる。
これまで、コンピュータに何かをインストールさせるには、
手順をコード化する必要があった。

OSを判定する。
依存関係を確認する。
パスを通す。
バージョンを固定する。
エラー時の分岐を書く。
成功確認のコマンドを書く。

だから install.sh があった。
機械は自然言語を実行できなかった。
だから、人間があらかじめ機械語に近い形へ落とし込む必要があった。

しかし、LLMエージェントが環境を読めるなら、話は変わる。
Markdownにこう書けばよい。

このツールを入れる目的。
対応するOS。
前提となる環境。
避けるべき操作。
よくある失敗。
確認すべきコマンド。
成功条件。
ロールバック方法。
人間承認が必要な箇所。

すると、LLMはその手順を読み、
現在の環境に合わせて行動を組み立てる。

これはREADMEの進化ではない。
Markdownが、エージェントにとっての実行物になるということだ。

ただし、ここで勘違いしてはいけない。
.sh がすべて .md に置き換わるわけではない。
むしろ、責任範囲が分かれる。

.sh は、決定的な低レイヤー実行に向く。
.md は、状況適応・判断・修復を含む高レイヤー手順に向く。
LLMは、その .md を読み、現場に合わせて具体行動へ変換する。

このとき、手順書はただの説明ではなくなる。

それは、小さな実行契約になる。

だから、これからの手順書には、文章力よりも設計力が必要になる。

曖昧なことを書くと、曖昧に実行される。
危険なことを止めていないと、危険なまま実行される。
成功条件を書いていないと、モデルは「やったつもり」で止まる。
ロールバックを書いていないと、失敗後に戻れない。
証跡を書いていないと、何が起きたか追えない。

つまり、install.md 時代に必要なのは、「わかりやすい説明書」ではない。
Agentが読んで安全に動ける実行仕様書である。

そして、Skillはドキュメントではなくなる

この流れで見ると、Skillの見方も変わる。

Skillは、便利なプロンプト集ではない。
専門知識を書いたフォルダでもない。
手順を書いたMarkdownでもない。

Skillとは、モデルに渡す、再利用可能な実行契約である。
ここでいう実行契約には、最低でも次が含まれる。

何を達成するのか。
何を入力として受け取るのか。
どの条件では実行してはいけないのか。
どこで確認を求めるのか。
どのファイルを読んでよいのか。
どの操作は人間承認に回すのか。
成功をどう検証するのか。
失敗したらどう戻すのか。
どの証跡を残すのか。

ここまで書かれて初めて、Skillは業務に耐える。

逆に言えば、
「手順を自然言語で書けばAIが何とかしてくれる」
という理解は危ない。

自然言語で書けるようになったからこそ、
より厳密な境界設計が必要になる。

コードの時代は、曖昧な文は実行されなかった。
しかし、LLMの時代は、曖昧な文でも実行されてしまう。

ここが怖い。

Software 1.0では、曖昧さはコンパイルエラーになった。
Software 3.0では、曖昧さはもっともらしい実行結果になる。

だからこそ、Skillは資産管理の対象になる。

版管理する。
配布する。
更新する。
依存関係を見る。
危険操作を検査する。
利用ログを見る。
失敗例を反映する。

つまり、Skillは
「プロンプトの延長」ではなく、
エージェント時代のパッケージに近づいていく。