現在、私は32か国のニュース・情報収集サービスと、主要国（米国、日本、英国、韓国）およびコイン／先物市場の日次スナップショットをMCP(Model Context Protocol)で提供する機能を開発しました。現在はこれを基盤に、OpenClawと似たように自由な動作が可能な投資プログラムを開発中です。
私が悩んでいる点は2つあります。
-
AIの「自由度」とフロントエンドUIの共存
既存ソフトウェアのように、あらかじめ決まったUIと機能を基本として提供しつつ、各機能をAPI化してIDEやAIがそれらを完全に理解し制御できるように実装しています。結局、未来のソフトウェア開発はAIがどれだけ自由に機能を拡張し実行できるか、つまり 「AIの自由度」 に焦点が当たるのではないかと考えていますが、みなさんの意見が気になります。 -
ユーザー体験の変化：「これやって」の時代
今後ユーザーは、「これやって」というシンプルな命令だけで望む結果を得たいと考えるはずです。さらに、開発者が事前に定義していない機能であっても、AIが自らインターネットを検索したりコードを書いたりして、ユーザーのニーズを満たすべきだと思います。（例：法律プログラムであっても、ユーザーが望めば航空券の予約まで手伝ってくれるレベル）
技術がユーザーに究極の利便性を提供すべきだとするなら、私たち開発者は「閉じた機能」ではなく「開かれた拡張性」をどこまで考えるべきでしょうか。OpenClawのようなエージェントの登場によって、最近この悩みがいっそう深まっています。
5件のコメント
1番のケースを私がテストしています
その結果、経験した失敗が積み重なると、自ら制約をかけ始めるようでした
ちなみに私は、ハルシネーションをパスチャネル探索エンジンとして活用する段階です
(a) 既存アプリの機能をさらに拡張すること
(b) すでに試みられてきた、人が行っていたさまざまなサービスの API を組み合わせて機能を拡張すること
(a) については、まだ AI に任せて自由に機能を拡張させるには信頼しきれませんね。
(b) はコントロールされたものなので、その分まだましだと思います。
しかし、「法律プログラムが飛行機の予約」をすることは絶対にないと思います。そうなれば、それはもはや法律プログラムではありません。汎用の Her OS になってしまいます。人の組織や責任を分けているのには理由があるように、プログラミングやアーキテクチャもそのように分けているのには理由があるのだと思います。自分が望むことを本当に理解させて、そうしたことをすべて自分好みに処理させようというのは、デジタルクローンの話に近い気がします。
「これやって」は、長年自分を知っている個人秘書のように、具体的に細かく説明しなくてもよくなることですが（今よく言われる spec-driven のように）、自分のすべてをスキャンして知識を蓄積し記憶する過程を経ても、結局は何らかのミスが生じます（『Her』でも初期設定のときにユーザーのメールやあらゆるデータを検査する場面があります） -- そのミスをどれだけうまく見つけて排除できるか、あるいはそのミスを修正できるかが必要ですが、まだ先は長いようです。人に仕事を任せてみれば分かりますが、10年20年一緒に働いた人でも私の意図を正確には理解していませんし、あるいは勘の鈍い人はずっと分からないままミスをし続けたりします……。人間でもそうなのですから、momento のような、そして責任を持たない AI をこうした人間のレベルまで引き上げることが先だと思います。
おっしゃるようなオープンな拡張性に向かえばよいとは思いますが、そのためにはそうした汎用の個人秘書 AI である必要があり（上で別の方が書いていたように、トースターが別の仕事をしないように）、ユーザーとの相互作用を通じて継続的にユーザーを学習していく必要があるでしょう。車に税務申告書を書いてほしいとは思いません。これは人間でも同じですね。従業員に特定の仕事を与えたのに別の仕事までしてしまったら、雇用者は喜ぶかもしれませんが、たいていはむしろ心配すると思います。
明確なドキュメント化と、適切に設計されたアクセシビリティが最終的には勝ちます。あえてAIの自由度に焦点を当てなくても、よく設計されたアクセシビリティは人間にもAIにも理解しやすいです。
いいえ、最小権限の原則は必ず守られるべきです。私は自分のトースターにはパンだけを焼いてほしいのであって、インターネットに接続してニュースを要約したり、Doomを実行したりしてほしいわけではありません。
哲学的には、アンディ・クラークの拡張された心という理論をおすすめします。もっともらしさがすべてであるLLMが、ツールを通じて認知を拡張していく部分について深い理解を与えてくれるはずです。
実践的には、OpenCodeはエージェント構成のあらゆる部分が公開されているので、役に立つでしょう。
2番はすでに現実です。最初に与えられたツールの一つがコードインタープリタでした。なので、特定ドメインのエージェントについての私の意見は、結局は消えゆく短期決戦です。
今取り組まれているドメインであれば、従来型のMLをMCPとして提供するのがよいのではないかと思います。言語モデルは、パターン分析や線形予測にはまったく有利ではありません。
あえて人間のUIに基づいてツールのシンメトリーを設計する必要はないように思います。どうせUI自体をエージェントが直接解釈して制御するwebMCPやGDIベースの自動化されたMCPは、あっという間にやって来るでしょう。人間向けの数多くのレガシーシステムを活用しなければならないはずですから。ネイティブなマルチモーダルを備えたLLMベースのエージェントであれば、開発者がGUIをMCPに翻訳する手間をわざわざかける必要もないでしょう。ファウンデーションのGUI支配力が強いiOSは、次のバージョンですぐに始まるかもしれませんね。
そうなれば、ただ適当な株式アプリをインストールするだけで、エージェントに投資を委任できるようになるでしょう.