目指す開発哲学が千差万別ですからね……。

やはりAIも公平ではないですね

あまりにも恐ろしいです。
悪意をもって記録された記録が、
記憶や経験を打ち負かして証拠となり、
私たちを脅かす事態が起こりうるということです。

人々が使うブラウザーなんて種類はそれほど多くないのに、なぜフレームワークはこんなに多いのでしょうか。ブラウザーを管理している会社が最適なフレームワークを作って一緒に管理するのが最善ではないでしょうか。いつまでこの悪循環を繰り返すのでしょう。

なぜ破談になったのか気になります。

ユーザーにおもねるAIの究極形は、社長におもねるAIだったんですね……

現象への共感はしますが、結論には共感しません。

現象の表面的な原因は本文でも言及されていたように、「アプリのようなWeb」への需要が増えたことであり、
今も当時もWebは「アプリのような何か」を作るのに適していたわけではないものの、無理やり工夫すれば「似たものを作ることはできる」状態だったのだと思います。

そもそもWebの成り立ち自体が、論文のような一種の「文書」を共有するために作られたプラットフォームです。
HTML の基本構成要素を見るだけでもわかります。

その後、cgi のような動的コンテンツを生成できる技術が生まれ、ブラウザ側にもスクリプト言語が組み込まれて成果物に動的な性質を与えられるようになることで、「文書としてのWeb」からの脱却が始まりました。

問題は、最初の脱却の瞬間から現在に至るまで、Webの根幹が依然として「文書」ベースのシステムだということです。
もちろん WebSocket、WebRTC、Wasm など「文書」志向から外れた新しい技術は数多く登場しましたが、現在に至るまで大半のWebサイトは従来の「文書」ベースのプラットフォームに依存して開発されています。
今なお私たちは画面を描くために div タグを積み重ねなければなりません。

ここまでが現象分析で、では答えは何かと考えるのですが、
現実性のようなものをまったく考えず、理想的な次のプラットフォームの機能を想像してみるとこうなります。

（すべてのサイトがこうあるべきという話ではなく、アプリケーション的な性格を持つサイトに限ってですが）
まずブラウザは一種のアプリランチャーになります。
一度ダウンロードしておけば、オフラインでも実行できるべきでしょう。
そしてアプリは既存の html/css/js から離れ、別の言語で実装されます。
その過程で、Android のようにブラウザが一種のフレームワークを提供できるかもしれません。
サーバーとの通信方式も、従来の web リクエストから離れて別のパラダイムを使えるかもしれません。
リアルタイム性が必要な通信であれば、従来の tcp 通信をそのまま使うこともできるでしょうし、
http プロトコルを使わない、より単純な rpc 通信を新たに作って使うこともできそうです。

おお、そうなんですね。WindSurf の将来もそれほど明るいわけではなさそうですね。

1か月前、CURSORを活用してAIコーディングとは何かを学ぶつもりで、開発フレームワークの開発に着手しました。

3週間ほど、成功したかと思えばAI Agentによって検証済みだったソースコードが壊されることを繰り返し、あらゆる方法を動員してAI Agentを制御しようと努めましたが、失敗しました。

その後、開発フレームワークを作る前に、まずAI Agentを制御するソースコードを開発することが優先だと気づきました。

結局、最初にAIとは何かを知ろうとして始めてからちょうど1か月で、AI Agentを完全に制御し（正確には外部LLMやAI Agentを必要としない）、AIによる100%実装 + 100%運用が可能なソフトウェアの開発を完了するという成果を達成しました。

現在は14日目で、さらなる高度化のためにそのMETA AIを追加学習させながら、運用規定を作って守らせるプロセスを進めています。また、従来人手によって不完全に作られていたMESシステム3件を同時に移行・改善し、さらに標準化も進めており、仕上げの段階に入っています。

そして今、また別の進化を準備しています。

MCP-B技術の中核となるビジョンは、次のようなものだと考えられます。
「信頼できる媒介であるChrome拡張機能（Extension）を通じて、ブラウザがすでに安全に管理しているユーザー情報（Cookie、セッション、認証など）を活用し、
Webページ上で開発者があらかじめ定義しておいた『ツール（Tools）』をAIチャット画面から自然言語の命令で呼び出し、制御する。」

しかし私は「拡大する余地はなさそうだ」と感じており、その理由は次のとおりだと思います。

1. ユーザーの抵抗感: 最大のハードルです。ユーザーは自分のブラウザ情報にアクセスする拡張機能をインストールすることに対して、本能的な拒否感とセキュリティ上の懸念を持っています。
   この技術が提供する利便性が、その懸念を上回るほど圧倒的でなければ、ユーザーはインストールをためらうでしょう。
2. Web開発者の負担: Webサイト開発者は、既存のAPIを作ることに加えて、MCP-B向けの『ツール（Tools）』を別途定義し、管理しなければならないという追加の負担を負うことになります。
   この技術が広く採用されることで得られる利益が大きくなければ、開発者はあえて二重の労力をかけようとはしないでしょう。
3. セキュリティ問題の責任の所在: もしこの技術を通じてセキュリティ事故が発生した場合、その責任がWebサイト開発者にあるのか、拡張機能開発者にあるのか、あるいはAIモデル提供者にあるのかが不明確になる可能性があります。
   このような複雑さは、企業が技術導入をためらう要因になります。
4. 集中型プラットフォームの不在: 現時点では、「どのWebサイトがどのツールを提供しているのか」を知らせる標準化されたディレクトリやプラットフォームがありません。ユーザーはWebサイトを訪問する前には、どのようなAI機能が使えるのか分かりにくいです。

結論として、
MCP-Bのアイデア自体は技術的に非常に興味深く革新的ですが、ユーザーと開発者の双方にとって「なぜわざわざこの方式を使う必要があるのか？」という根本的な問いに対する明確な答えを示せていないように思います。既存のAPI方式と比べて得られる利点は不明確である一方、セキュリティ上の懸念と開発の複雑さという欠点は明確だからです。

したがって現時点では、この技術は一部のマニアや特定の目的を持つ開発者の間で実験的に使われることはあっても、Webエコシステム全体へ拡大していくには多くの困難があるように見えます。

この記事の根本的な問題意識には共感しますが、いくつかの点では首をかしげたくなる部分もあります。

例えば、私の会社が運営している特定サービスのプロモーション用Webサイトは、まさにこの記事で称賛されているような単純さを保っています。幸い、このWebサイトは大半の要素が十分に静的です。フロントエンドのHTMLやCSSなどのコードは、何のフレームワークも使わず人が手で直接書いたもので、JSもjQueryとGoogle Analyticsが入っている程度です。お知らせや掲示板などはjQueryを使ったAJAXで実装されていますが、そこまで不合理だったり過度に複雑なレベルだとは思いません。私が昔、初歩的なWeb開発に入門したときにjQueryベースで実装できた程度のものだと思うからです。私の知る限り、このサイトはInternet Explorer時代から運営されていたもので、私が直接作ったわけではありませんが、悪くないと思います。

しかし、そこにはGitによるバージョン管理とCI/CDパイプラインがあり、ステージングサーバーと本番サーバーを分離しています。MainブランチにPull Requestがマージされると、パイプラインでバンドラーを回した成果物がステージングサーバーに自動デプロイされ、担当者がステージングサーバーを確認したあとでデプロイを最終承認すると、それが再び本番サーバーにデプロイされる形になっています。以前は単にFTP経由で元ファイルを本番サーバーに直接上書きする方式でしたが、関連業務が私たちのチームに移ってきたあと、このように変更しました。

これは本当に不合理な複雑さでしょうか。以前は、そのWebサイトのtitleタグを修正するには、FTP接続をサポートするAcroEdit（はい、そのサイトのHTMLを直接書いた人たちは、今でもこれを使っていました）で本番サーバーのHTMLファイルに直接入って1行だけ直して保存すれば作業完了、というものでしたから、その人たちはたぶんそう感じるのかもしれません。

しかし私としては、この程度の複雑さの追加は十分に受け入れ可能だったと思います。すべての作業がtitleタグを1つ直すのと同じ程度なわけではありません。そして、昔のコードがコメントアウトされてべたべた残っていたものを、いつでも戻せるので気兼ねなく完全削除できることや、透過的な変更追跡とロールバックが可能になったこと、バンドラーによって必要ならもう少し基本的な最適化を追加できることは、十分な利点だと私は思います。実環境にデプロイする前にプレビューできるステージングサーバーの追加も、見方によっては複雑性だと言えるかもしれませんが、私はこれが必要だったと思います。

私も、さまざまなWebサイトの内部コード構造が過度に複雑化し重くなっていることには不満が多いです。最近のWindowsのOutlookアプリはWebアプリベースですが、このところ特に重くなりました。画面上でメール本文を書いたり、本文を全選択したりするだけで引っかかったり、ひどいときには「ページ応答なし」が出るほどです。なぜだろうと思ってWeb版Outlookで開発者ツールを開いてみて驚きました。一度キャッシュを消してリロードしたら、1分後になっても何かしらのリクエストが出続けていたのです。ブラウザで確認すると、MS Officeサイト関連だけで数GBのデータが保存されていました。

ただ、この記事はさまざまな論点が混ざっていて、共感する部分もあれば、あまり共感できない部分もあります。セマンティックHTMLやアクセシビリティに関する話は、むしろ昔のほうがひどかったと私は認識しています。それに、開発者体験の向上がユーザー体験を悪化させるという話は、私がWebフロントエンド開発者ではないからかもしれませんが、まったく共感できません。ましてや、すべての権力と統制が開発者に集中したというのは、荒唐無稽な話に聞こえます。会社の中で権力を持っているのは経営陣ではなかったのでしょうか。欧米では会社の構造が韓国とはかなり違うのでしょうか。

いつもそうであるように、バランスと中庸、単純さと実用性は重要な価値であり、これを意思決定で優先すべきだという点には全面的に同意します。ただ、この記事は「すべてのWebサイトをソフトウェア製品のように扱うこと」が、まるで全面的に開発者の責任であるかのように主張しており、その点がかえって根本的な問題意識をぼやけさせていると思います。そして、体制が整っていなかった「古き良き時代」を美化しているように見える部分は、むしろ批判されるべきではないかと思います。

退屈〜なふり…

韓国は何だかんだで Java 一色の国だから、なじみがないんだねｗ

他国の技術 != 他国のデータ だと思います

とりあえず無料公開されるまでは信じない。Grokは30ドルもするから、購読するのが怖い…

ｗｗｗｗｗ 突然ぶん殴られた大学院生、ぽかーん……

Railsを使おう、そうすれば幸せになれる

試みは応援しますが…
organization を新しく作って 1.0 はなかったことにする、そんなことはしないでほしいですね。

（韓国）会社員生活ですか？（笑）

YCD版も出るとうれしいです〜