OpenAI Apps SDK
(developers.openai.com)- OpenAIは、ChatGPT 内で動作するアプリを開発できるようにするフレームワーク Apps SDK を公開
- 開発者はこのSDKを活用して、ChatGPT内で動作する新しいアプリを作成し、実験的な機能を自由にテストできる環境を利用可能
- Apps SDKは現在 プレビュー版 として提供されており、アプリの提出および正式公開は今年後半に予定
- このフレームワークにより、ChatGPTプラットフォームの拡張性とカスタムアプリ開発の機会 が開かれ、さまざまなソフトウェアやサービスとの連携および自動化が可能になる見込み
- 開発エコシステムの拡大を通じて、生産性向上 と革新的なサービス創出の促進が期待される
1件のコメント
Hacker Newsの意見
ChatGPTがますますウェブ閲覧の出発点になっているのは興味深い。今や検索すらわざわざせず、基本的な地図、Stripe決済、航空券予約などのワークフローが提供され、人々が日常的に行うたいていの作業がカバーされるようになる。
過去2年間、この進展における最大のボトルネックはモデルではなく、エンジニアリング、インフラ、そして企業がOpenAIと直接協業しようとする意思だった。
今ではOpenAIが成長し、ユーザー基盤も大きくなったことで、企業ははるかに積極的に投資したり参加したりしようとしている。
こうした変化は、ユーザー中心のインターネット利用だけでなく、SDKベースのツールがさらに増えれば、人間のワークフローがチャットボット経由のトラフィックと、SEO最適化およびチャット/エージェント向けの新しいウェブへと分岐する結果ももたらすだろう。
私のようにAIを使いたくない人も多いと思う。
特に航空券の購入では、AIがミスをするという不信感からではなく、自分で主導して処理したいからだ。
たとえるなら、運転が飛行機より危険だと分かっていても、運転のほうが安全に感じられるのと同じだ。
結局は自分のコントロール権が重要だということだ。
なぜわざわざチャットボックスの中で無理やりアプリを立ち上げて妙な形式で見せたうえで、結局本物のアプリにリンクするのか分からない。
むしろアプリの中にチャットボックスを入れるほうが標準的なやり方だ。
1社がインターネット利用全体を統制、フィルタ、管理する状況が来たら、インターネットの意味はなくなると思う。
もちろんGoogleも似たようなものだという主張は理解できるが、少なくともGoogle検索から実際のサイトには行ける。
ChatGPTを通じて、いわば「伝言ゲーム」のようにやり取りする構造はあまりにもひどい。
音声アシスタントに買い物を任せる気がまったくないのと同じで、重要な意思決定をLLMに任せるのは絶対に無理だ。
自分のクレジットカード決済権はもちろん、飛行機の予約まで任せるなんて想像もできない。
OpenAIはユーザーが爆発的に増えた時点からこうした機会を持っていたが、実際にはプラグインやGPTsでうまく生かせなかったと思う。
皮肉なことに、AnthropicのMCPがこの分野のゲームチェンジャーになるかもしれない。
ChatGPTが未来の汎用ユーザーインターフェースになるという信念に立てば、こうした構想はもっともらしく見える。
しかし実際には、最近のエージェントのトレンドは、むしろチャットインターフェースをもっと厳格なUIパラダイムの背後に隠したほうがよいことを示している。
チャットが優れたインターフェースになり得る領域は非常に多いと思う。
ChatGPTがそうした領域の配布者になれば、Googleを置き換えることもできる。
それでも特定のドメインではカスタムインターフェースが正しいアプローチであり、その分野に十分な価値があれば、専用インターフェースを作る人は必ず現れるだろう。
最近のエージェントの主な活用例はコード生成で、ターゲットユーザーはIDEやコードエディタに慣れている。
トークン使用量の大きな割合を占めてはいるが、これが一般ユーザーのニーズや願望を代表しているわけではない。
チャットインターフェースがここまで普及したのは、それ自体に利点があるからだと確信している。
一般的なエージェント活用においても、チャットはタイピングや音声入力の利便性をもたらす。
音声対音声や動画活用とも簡単に組み合わせられる。
今後、動画生成がリアルタイムで可能になったとしても、たいていの結果はテキストで消費するほうが快適だろう。
人々はchatGPTにZillowやCanvaへ代わりに問い合わせてほしいとは思わないだろう。
Zillowで住宅価格を調べたり、Canvaでグラフィック作成を頼んだりはするかもしれないが、特定のアプリ自体を呼び出す必要までは感じない。
結局、アプリがChatGPTに依存してユーザーを流し込むようになると、ChatGPTが直接機能を提供してアプリを置き換えるほかなくなる。
つまり、チャットが万能インターフェースだという考えで自分のサービスをChatGPTに露出すると、自らの生存を難しくすることになる。
音声インターフェースとチャットは本当に相性がいいと思う。たとえば歩きながら音声で外国語レッスンやウェブ検索をするとき、とても便利だ。
NotebookLMのようなノートアプリ形式も週に1、2回は使っている。
小さなオープンモデルをより大きなシステムにつないで構造化データ抽出に活用するなど、多くの実験が可能だ。
現在のagenticシステム（MCPなど）の実質的な有用性には懐疑的だ。
それでも今日はAGIの話が出なかっただけでもよかった。
ASI、AGI幻想にFOMOでしがみつくと、破産しか残らないかもしれない。
未来のインターフェースは、データセットで学習された機能がハードウェアに組み込まれたローカルAIだ。
EEでありエネルギーモデル分野で働いている立場からすると、オシロスコープの幾何学的特性を思い浮かべれば、方程式がその構造を復元できる。
ユーザーはパラメータUIで簡単に望む結果を得られる。
現代のOSは文字列処理用の仮想マシンだが、未来は座標を操作するベクトル仮想マシンになるだろう。
メモリ行列とディスプレイ行列の同期へと単純化され、今後は開発者が旧式の文字列処理から抜け出せるようになる。
実物を見ると、思ったほど革新的ではない。
「アプリ」は実質的にはMCPサーバーにすぎず、HTMLを返せるというオプションが違うだけだ。
MCPの根本的な問題、つまりシングルプレイヤー的で、ユーザーが常に「取得しにいく（pull）」必要があり、アプリを開くより接続構造が直感的でないという点はそのままだ。
理想的にはアプリごとに固有の入口があり、ユーザーにプッシュ通知も送れ、UI上で持続性もあるべきだ。
主要インターフェースもチャットではなくHTMLであるべきだ。
今の状況はGPTsと似た結末になると予想している。
サービスが能動的にユーザーとLLMを継続的に結びつければ、MCPサーバーは本当に強い粘着性を持つようになる。
インストール/認証プロセスも、非専門家向けの要件に合わせてますます簡単になるだろう。
Phind 2を作ったとき、回答に動的ウィジェットを直接埋め込んでいたのを思い出して興味深い。
この方式の弱点は、アプリ/ウィジェットの入出力スキーマがハードコードされていることだ。
ウィジェットの範囲内なら非常によく動作するが、Zillowで特殊な高度フィルタリングを使ったり、StreetEasyと連携したりしたくなると、すぐ限界を感じる。
今やユーザーの立場では、高度な機能が欠けていれば単に使えないということになる。
本当に革新的だと思うのは、「その場で生成されるUI」だ。
まもなくPhindでこの部分に関するアップデートがある予定だ（私はPhindの創業者だ）。
Phindは本当に良い。
以前は、的外れな検索結果ばかり返すGoogleのような従来の検索エンジンにうんざりしたとき、Phindですぐに欲しい情報を見つけていた。
しかし最近はLLM自体が検索もうまくやってくれるので、このところはLLMだけを使っている。
既存のMCP-UIプロジェクトがすでにあるのを見ると、可能なのは驚くことではない。
ただ、それでも実用にはまだ遅すぎるので、改善が必要だと感じる。
私も似たようなものを自社製品に作るべきか悩んでいて、スキーマ制約への解決策として、ウィジェットをできるだけ汎用ブロックとして設計し、活用性を高める方法を考えている。
まだアイデア段階だが、モデルが複数のモジュール型ウィジェットの中から課題に合わせて組み合わせて選んで使うようにしたらどうかと思っている。
たとえば検索結果を単一項目、マトリクス比較、フィルタリングセクションなどに分け、文脈を変えながらセッション内で複数のやり方で扱えるよう研究中だ。
Phindで実際にこうした体験について書いた記事があれば参考にしたい。
こうした限界は、チャットと事前制作またはオンデマンドのウィジェットが組み合わさることで解決されると思う。
キーノートのデモでは、チャットインターフェースでZillowの住宅のうち犬の公園の近くのものだけをフィルタリングする、といった高度なフィルタリングが複数ソースの情報を統合して可能だった。
MCPでこの問題は解決できる。
アプリを触らなくてもMCPサーバーのスキーマを動的に更新できる。
アプリは自動で新しいスキーマを認識するようになる。
今回のOpenAI発表は本当に新しいものを作るチャンスだったのに、ただチャットに既存アプリの画面を固定的に埋め込むだけに終わったようで残念だ。
本当の強みは、ユーザーが課題を説明するとAIがどんなツールが必要かを把握して自ら組み合わせ、ユーザーが編集可能なワークフローやキャンバスの形で結果を見せることだ。
LlamaIndex WorkflowやLangGraphのようなフレームワークは、すでに手作業でこうしたグラフ（workflow-DAG）をPythonで実装できるよう支援しているが、LLMがこうしたDAGをリアルタイムで作れれば本当に強力だろう。
LLMはすでにUIコードをうまく生成でき、デザインシステムにもよく従うのだから、わざわざ画面をハードコードする理由はない。
Googleには今回の道を追わないでほしい。
最近、OpenAIの組織内部にチャットインターフェースが実際どれほど深く刻み込まれているかについての文章があったが、今回の発表でその執着をさらに感じた。
本当の問いは「本当に大半のユーザーが視覚要素より会話だけでやり取りするのを好むのか」だ。
特に複数のアプリ名（Zillowなど）を覚えてチャットに打ち込まなければならない点、そして広告や『優先表示（app discovery）』のような課金戦略の可能性が非常に不快に感じられる。
個人的にはこんな未来は来てほしくない。
GUIとターミナル（あるいはCLI）のどちらがより強力かについて、また議論しているようなものだ。
トークンストリームにうまく合う多くの作業では、コマンドラインやチャットのほうが優れているかもしれない。
ボットやMCPを素早く呼び出せるタブ補完機能なども生まれるかもしれないが……
一方で、新しい内容を探索したり、グラフィックな相互作用が必要だったりする場合には、視覚的で専用のインターフェースのほうがはるかに直感的だ。
結局は課題に応じた複数UIの適切な混合と抽象化が定着すると思う。
チャットインターフェース中心であることが、LLMの活用度を実質的に妨げていると思う。
会話の連続性という幻想がどう作られているのか（コンテキスト管理、以前のプロンプトが記憶から抜け落ちる構造など）は、非専門家には説明することすら難しい。
私が非技術系の友人に普段する助言は、「プロンプトごとに新しい会話を始めること」だ。
そうすれば何が効いているのかを明確に把握できる。
UX革新はAppleが主導すると期待していたが、まだそうはなっていないようだ。
反論を挙げるなら、私の知る多くの人はZillowにアクセスするためにGoogleでただ「zillow」と打つだけなので、チャットにアプリ名を入力するのも必ずしもおかしなことではないのかもしれない。
否定的な反応が多いが、個人的にはOpenAIの方向性はあまりにも当然に見える。
最終的には、ユーザーが望むことを言えば、OAIが勝手にアプリ（メール、カレンダー、決済など）とつないで処理してくれるプラットフォームになるだろう。
この方式なら、OAIは広告なしで収益シェアだけで済む。
メール、カレンダーアプリで大きな売上が出ると信じているなら、投資家にとっては衝撃だろう。
広告がないという話は間違っている。
広告は非常に巧妙に、役立つヒントのような形で大量に隠されるはずだ。
間違いなくOpenAIは両方（収益シェア、広告）を狙うだろう。
すでに広告チームも組成しており、資本も十分あるのだから、スケール可能なあらゆるビジネスモデルを試そうとするはずだ。
App Store、アルゴリズムフィードなど、歴史上成功したモデルはすべて試すだろう。
プラットフォームになるには、ユーザーロックインか不公正な優位性が不可欠だ。
単にモデル品質が優れているだけでは不十分だ。
まだ今のところ、この方式が実際に何かを改善しているとは感じられない。
誰かがSpotify連携に言及していたが、旧世代のアシスタントでもすでにできたことだ。
単に従来と同じことを、はるかに高コストで処理しているように見える。
結局みんな、OpenAIのツールエコシステムに無料アプリを注ぎ込む運命になる。
こうした流れはOpenAIの防御力を強化し、他の機会は犠牲にする。
iPhone初期には6つのアプリしかなく、App Storeすらなかった。
2024年時点でiOS App Storeは1.3兆ドルの売上を生み、そのうち85%が開発者の取り分だ。
OpenAIの「moat」（参入障壁）が何なのか気になる。
実際にはこうした流れはおかしくない。
リアルタイムデータとMCPアクションがユーザーに実質的な助けを与える理由がなくなることはない。
アプリ連携時に認証は必要かもしれないが、決済がなければ非常に大きな配布チャネルだ。
今回の発表はブランディングの面では興味深い実験だ。
MCPを「アプリ」と呼べば親しみやすく使いやすい印象を与えるが、ツール/サーバー/道具と呼ぶとあまりにも技術的に聞こえる。
Expedia、Spotifyとのデモ追加により、ユーザーがすぐ使えるMCPが完成したような印象を与える。