フロントエンドエンジニアが完全にオワコンになっていない件（Apps in ChatGPT）
「フロントエンドエンジニアが完全にオワコンになった件」という投稿が飛び込んできた。
むしろ逆である。Apps in ChatGPTはフロントエンジニアに新しい仕事を増やした。
ちなみにこの件、古くはFunctionCallingで最近の呼び名だとToolsが出てきた時点でこの議論は出ていたので今更感はある。
その頃から「全てがチャットGPTと連携してUIもAIが自動生成、Webサイトがなくなるかもね」と話していたのが、そのまま進化して近いものが出てきた、というのがこれ。
フロントエンジニアの仕事はむしろ増えた
フロントエンジニアが完全にオワコンになるという話、むしろ逆。
「全てがチャットGPTと連携してUIもAIが完全自動生成、Webサイトがなくなるかもね」という会話が見逃していたのは、リソースの有限さである。
AIがデータ構造をもとにUIを完全自動生成、なんと無駄なことでしょう。こんなことをしたら毎年凄まじい量の計算リソースが無駄に消費されてしまう。
つまり、このような進化は起き得ない。むしろ逆に、このようなスーパーアプリ化するプラットフォームの中にフィットする新しいUIを作る新しい仕事が生まれてしまった。
LINEミニアプリでLIFFを知る必要が生じたように、OpenAIのApps SDKを知る必要が生じた。
GPTのApps SDKは2025年10月時点でプレビューだが、現時点でもBuild a Custom UXページでReactを使用したカスタムUI実装が解説されている。
でもサーバー側の仕事も増えている
Apps in ChatGPTの公式ドキュメントは「Introducing apps in ChatGPT and the new Apps SDK」でこう述べている。
The Apps SDK builds on the Model Context Protocol (MCP), the open standard that lets ChatGPT connect to external tools and data. It extends MCP so developers can design both the logic and interface of their apps.
つまりApps in ChatGPTはMCPの延長に存在するもの。Apps in ChatGPTに対応したいと思っても、まずは土台のMCPから手をつける必要があるということ。
Apps SDKがプレビューでここから変化していくことを踏まえると、現時点で対応すべきは
- AIプラットフォーム連携の必要性を検討（アプリケーション側にAIを組み込むかAI側にアプリケーションを組み込むか）
- サーバー側がAIとセキュアに連携できる基盤作りや設計の見直し
AIに対応しようとするとまずはサーバー側の仕事から増え始める。
結論
- （フロントエンドエンジニア）あなたの仕事はむしろ増えた
- （サーバーサイドエンジニア）でもあなたの仕事から増える
- （サービス提供者）Apps in ChatGPTへの対応を検討しつつサーバー側から整えておきましょう
雑にまとめるとこんな感じ。
公式のAppデザインガイドラインを読んでいると、自分のサービスのどの部分を切り取ってチャットGPTに乗せるべきか、どのようなサービスが駆逐されるか、朧げながら浮かんでくると思います。
Discussion