生成AIの議論を見ていると、日本ではいまだに
「どのモデルが賢いか」「日本語性能はどうか」といった話題が中心になりがちだ。
しかし、LLMを実際に使ってプロダクトを作ったことがある人なら、
すでに気づいているはずだ。
問題はそこではない。
アプリを作り始めた瞬間に、モデルの「正体」が見える
LLMを使ったアプリを本気で作り始めると、必ず次のような体験をする。
-
このモデル、ここまでは賢いが、ここから急に壊れる
-
Tool呼び出しは得意だが、失敗時のリカバリが弱い
-
コンテキストが長くなると、判断基準がブレる
-
「次に何をすべきか」を考えさせると、妙に保守的になる
これらは、ベンチマークやAPI仕様書を読んでいても分からない。
実装して、壊して、ログを眺めて、初めて見える。
そして重要なのはここからだ。
その制約を見た瞬間に、
「じゃあ、こういう機能が必要だな」
「この制約前提なら、UXをこう変えたほうがいい」
という新しいアイデアが必ず生まれる。
つまり、アプリ開発はLLMの能力を“消費”する行為ではなく、能力を“発見”する行為なのだ。
LLMの進化は「机上」では起きない
ここで致命的な誤解が生まれやすい。
-
モデルチームはモデルを作る
-
アプリチームはそれを使う
-
フィードバックは仕様書かSlackで渡す
こういう分業を想定している組織が多いが、
LLMではこれはほぼ機能しない。
なぜなら、
-
「この制約は致命的か？」
-
「それともUX側で吸収できるか？」
-
「ここを直すと別の能力が壊れないか？」
といった判断は、アプリの文脈を知らないとできないからだ。
逆に言えば、
-
アプリを作っている最中に
-
モデルの癖や限界を肌感覚で理解し
-
その場で設計を変え、機能を足し、要求を変える
このループが回らない限り、
LLMを使ったプロダクトは一段上に行けない。
ClaudeやChatGPTが自然に強くなる理由
ClaudeやChatGPTを使っていて感じる「噛み合いの良さ」は、偶然ではない。
-
アプリ側で「ここはつらい」と思った点が
-
次のモデルで自然に改善されている
-
あるいは「こういう使い方を想定しているな」と感じる挙動が増える
これは、モデルを作っている人間と、アプリを壊している人間が、ほぼ同じ場所にいるからだ。
アプリ開発中に見つかった制約や違和感が、遠回りせずにモデル改善の材料になる。
この密度の高いフィードバックループこそが、本当の競争力だ。
MetaとManus AIの話を、もう一段深く見る
MetaがManus AIを買った理由も、ここまで来ると分かりやすい。
Manus AIが価値を持っていたのは、
-
優れたUIでも
-
目新しい機能でもなく**「LLMでアプリを作り続けた結果、どこで壊れ、どこを諦め、どこを工夫したか」という生々しい知見**だった。
これはコードレビューでは引き継げない。
組織として“一緒に作った経験”がないと、手に入らない。
だから買うしかなかった。
日本企業が陥りやすい罠
日本のAI開発で一番危ういのは、ここだ。
-
モデル開発は研究部門
-
アプリ開発は事業部門
-
両者は「連携」しているつもり
しかし実態は、
-
制約が抽象化され
-
痛みが翻訳され
-
意思決定が遅れる
結果として、
-
アプリ側は「LLMは使いにくい」と感じ
-
モデル側は「ちゃんと使ってくれない」と思う
という、最悪のすれ違いが起きる。
LLM時代に必要なのは「密なチーム」
結論はシンプルだ。
-
モデルとアプリは分けられない
-
仕様書越しの連携では足りない
-同じ課題を、同じ速度で、同じ温度感で見るチームが必要
これは組織論の話ではなく、技術要件だ。
LLM時代のプロダクト開発は、
「アプリを作りながら、モデルの限界を知り、
その限界を前提に次の機能を発明する」
という営みだからだ。
おわりに
LLMは魔法のAPIではない。
そしてアプリは単なるUIでもない。両者は、作りながら互いを定義し合う存在になった。
この前提に立てるかどうかで、
5年後に残るチームと、消えるチームははっきり分かれる。
日本のAI開発が、
「分業の安心感」より「密さの不快さ」を選べるかどうか。
そこが、ひとつの分かれ道だと思う。