WebUIについて調べた

WebUIはデスクトップアプリを作るためのライブラリ。HTML, CSS, JavaScriptでフロントエンドを作り、バックエンドをC, C++, Python, Go, TypeScriptなどの言語で開発できる。システムにインストールされているWebブラウザで動作する

https://webui.me/webui.me

2023年にhassandragaさんが公開し、V言語コミッタのttytmさんらも参加した

本体はCで開発されていて、Python, Go, TypeScriptにバイディングが提供されている

似た技術としてはElectronやTauri、Gluonなどが存在する

laiso.hatenablog.com

zenn.dev

アーキテクチャについて

ElectronやTauriと比較すると、WebUIのアーキテクチャはWebアプリをブラウザで開くだけなのでより単純かつ制約が大きい

開発者にとってはブラウザを使ってプログラムにGUIを付けられるライブラリであり

ユーザーにはChromeのdesktop shortcutsのようにスタンドアロンなウィンドウで起動するWebアプリになる

他のフレームワークとの簡単な比較図を作った

Presentation Main Program Bridge
Electron Chromium Node.js IPC
Tauri WebView Rust IPC(JSON-RPC)
WebUI Web Browser C and bindings HTTP(WebSocket)

WebUIでデスクトップアプリを起動する時のフローが以下になっている

  1. Pythonなどで記述したMainプログラム(hello_world.py)を実行
  2. WebUIがシステムにインストールされているウェブブラウザを呼び出す
  3. 専用のプロファイルでMainプログラムが実行するhttp://localhost:53949を開いてデスクトップアプリっぽく見せる
git clone https://github.com/webui-dev/python-webui
cd python-webui/examples
pip install webui2
python hello_world.py
MyWindow = webui.window()
MyWindow.show(login_html) # 描画するHTMLのテキスト

このデスクトップアプリのシステムWindowは「Google Chrome」になっていて以下のプロセスで実行されている

ps x | grep .WebUI

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome --user-data-dir=/Users/laiso/.WebUI/WebUIChromeProfile --no-first-run --no-proxy-server --safe-mode --disable-extensions --disable-background-mode --disable-plugins --disable-plugins-discovery --disable-translate --disable-features=Translate --bwsi --disable-sync --disable-sync-preferences --disable-component-update --allow-insecure-localhost --app=http://localhost:53949

Mainプログラムとブラウザのブリッジ連携

Mainプログラム側からブラウザの値を参照するにはJavaScriptコードを送る

res = e.window.script("return document.getElementById(\"MyInput\").value;")
if res.data == "123456":
    print("Password is correct.") 

逆にブラウザ側からMainプログラムの関数を呼び出す時はwindows.webuiオブジェクト経由でバインドしておく

def check_the_password(e : webui.event):
    #...

MyWindow.bind('CheckPassword', check_the_password)
<button onclick="webui.CheckPassword()">Check Password</button>

もしくはHTMLのid要素に暗黙的にバインドされている

<button id="CheckPassword">Check Password</button>

これを使うためにHTML側には <script src="webui.js"></script> のおまじないが入ってないといけない

この中身がwebui /bridge/で、TypeScriptで書いたWebSocketクライアントをさらにCのヘッダにhexにして埋め込んでいる

埋め込んだ文字列をローカルサーバーの /webui.js として返している

なんでそんなことを…… と最初思ったが、バイナリに埋め込み静的ライブラリとして配布するため?

その他の特性

  • あくまでライブラリでデスクトップアプリを配布用にパッケージングする仕組みなどはない
    • 例えばMainプログラムの実行にPythonが必要なら利用する環境にもインタプリタがないといけない
  • ブラウザの中で動いているローカルなWebアプリなので、その外側のOSの機能(システムメニューなど)まではアクセスできない

ドキュメントは https://webui.me/docs/

Disclaimer

この記事はWebUIのコア実装の理解に焦点を置いています。ElectronやTauriと比較し、WebUIの利用を薦めるものではありません

筆者はデスクトップアプリの開発にはプラットフォームの標準SDKを使います

デジタル庁でjQueryが何をしているのか

TL;DR: jQueryはDrupalのバーター

リニューアルするたびにWeb界隈の一斉レビューを受けることでお馴染のデジタル庁ポータルサイトがいつの間にかまたリニューアルされていて、フロントエンドがNext.jsからDrupalに変わって話題になっていたので1、私も旅券所持者として国政に関心を持ってゆく

また、まわりのフロントエンドエンジニアの間でjQuery氏の入庁について「モダンブラウザ全盛の時代に必要か?」と疑念がとなえられていたので、これも追求してゆきたい

どのような変更があったのか

システム変更の経緯はプロジェクトの関係者であるHal Sekiさんの発言が正確なところだと思う

私が理解した内容を勝手に作図してみたのが以下、脱Jamstackされた

JAMStack

Drupla

AstroやGatbsyなどのStatic Site Generator(SSG)を主軸にしたフレームワークと違い、Next.jsはインクリメンタルなビルドやサイトへのアップロードにフォーカスした機能をそなえていないので、ページ数が多くなるとビルド時間が長くなるというのは理解できる

SSGとSSRの併用・動的な切り換えを含め実現できるようNext.jsのサーバーを追加で立ち上げるって手もあるが「プレビュー機能や予約投稿など、元々CMSに備わっている機能も活用できない」とあるので、既に運用しているDrupal側に寄せたのだと思う

いつ変更されたのか

CrUX サイトスピード簡単比較(このサイトすごい)によると10月〜11月にかけて「OnLoad (リソース総読み込み時間)」が増加しているので、それを参考にWayback Machineを辿っていく

Drupal判定はページのJavaScriptに特定のオブジェクトが存在するかどうかで行われているのが独自研究で分っていたので2手がかりにした

その結果11月に新アーキテクチャになったというわけではなく、既に10月にはDrupalに移行済みだった

さらに遡って二分探索で時期を特定したところ、最終的には9月初旬に該当の変更があったことが分かった

ただ発表は11月にあったようだ

それ以前の6月にデジタル庁は新トップページの試行版を/experimental/で公開していた(現在はアクセスできない)

この更新はCSS ModulesからTailwindCSSベースに移行する意図だと思われる

<!-- 20230629060923/ -->
<section class="attention">
    <h2 class="attention__title">重要なお知らせ</h2>
    <ul class="attention__list">
        <li class="attention__item">
        </li>
    </ul>
</section>

<!-- 20230629060923/experimental -->
<section class="flex flex-col gap-12">
    <header class="flex items-center gap-4">
        <h2 class="text-pc-xl">重要なお知らせ</h2>
    </header>
</section>

この時点ではフロントエンドはNext.jsで生成された静的サイトのまま。この試行版の結果を踏まえて今回の変更に至ったのではないか

jQueryをどう使っているのか

jQueryの使用目的を調べるために、まず現在の最新サイトがどのようなJavaScriptを読み込んでいるのかを確認する

必要な個所だけを抜粋すると以下2つのJavaScriptファイルが読み込まれている

<script src="/assets/contents/js/js_ClXDO7hKtoW-lPIxg2611itLMSFuyA_7QOQFpHSZnkc.js"></script>
<script src="/assets/contents/js/js_sLGkDuawXY9ceUV6gA6ioeCD4o_nT-dduyMlEtshv-8.js"></script>

中身を読むと、それぞれ「開発者自身が記述したJavaScript」と「サードパーティのJavaScriptをバンドルしたファイル」という一般的なビルド結果ということが分かる

「サードパーティのJavaScript」ではjQuery v3系とDrupal JavaScript APIのコードが存在する

Drupal JavaScript APIが何かというと、Drupalの生成するページに対して追加の処理を実行するためのAPIである

https://www.drupal.org/docs/drupal-apis/javascript-api/javascript-api-overview

「開発者自身が記述したJavaScript」のファイル側でスクロールの挙動をカスタマイズしている

/**
 * Scroll processing
 */
const viewScroller = () => {
  // If the URL has an anchor
  if (window.location.hash) {
    // Processing at "Back" screen transition
    // eslint-disable-next-line no-unused-vars
    window.addEventListener("popstate", (e) => {
      scrollToForFloatHeader(window.location.hash, 10);
    });
    scrollToForFloatHeader(window.location.hash, 300);
  }
};

Drupal.behaviors.viewer = {
  // eslint-disable-next-line object-shorthand, no-unused-vars
  attach: function (context) {
    viewScroller();
  },
};

他に得られた知識としては

  • コメントが英語
  • eslintが導入されている
  • jQueryがスコープに宣言だけされてAPIが使われていない(!)

ということが分った

「jQueryのAPIを直接使っていない」という事実が今回の記事の重要な点で、このサイトのフロントエンドはVanilla JavaScriptでなるべく実装されていることが読み取れる

DrupalのドキュメントにはJavaScript APIを利用するためにはjQueryをロードせよという記述がある

Note: Since Drupal uses jQuery.noConflict() and only loads JavaScript files when required, to use jQuery and the $ shortcode for jQuery you must include jQuery and Drupal as dependencies in the library definition in your MODULE.libraries.yml and add a wrapper around your function. https://www.drupal.org/docs/drupal-apis/javascript-api/javascript-api-overview

なのでjQueryの読み込みはDrupal JavaScript APIを使う上では必須なのだろう

jQueryの読み込みはしているということは前述の計測データの「OnLoad (リソース総読み込み時間)」が増加とつながる

追記: DrupalコアとjQueryの関係

この記事が多くの人に読まれたことで識者の人に追加情報をもらったので追記します

まず現在のDrupalを使うのにjQueryを依存に追加するのは必須ではないようだった

状況としてはこのサイトが「jQueryが必要なテーマやモジュールを使っている」という可能性がある

ただそれがどこで使われているのか、閲覧者側に見える個所なのか管理側なのかは分からなかった

サイト内検索にMARS FINDERが使われていることは通信内容から分かり、このモジュールはjQuery v2を独自に読み込んでいるが……

一方、[meta] Replace JQuery with vanilla Javascript in core [#3052002] | Drupal.org のチケットではcoreからjQueryを削除しようという議論が行なわれておりそれはまだ進行中のように見えるのでサイト管理者が作成するコンテンツ以外のinternalな場所で使われているのかもしれない

コメントくれたprogratiさん、uhyoさん、tom_k_enさんに感謝


以下言いたいことだけを言うコーナー

「jQueryを新規で使っちゃだめなの?」

  • 最新のjQueryそのものを使うことについてはさしたる問題はない。
  • 問題はjQueryをベースに作成されたライブラリがアクティブなのかという点にある。
  • サポートされなくなったバージョンや更新されなくなったライブラリを使うことが安全ではない、というのが一般的な答えかと思う
  • jQueryの機能は現在のブラウザが標準装備している(それがライブラリが維持されない理由でもある)のでそれを読み込まないだけでUXに関連する数値が改善できる。「その高速化は本質的ではない」「統計によると何msで売上がN上がる」などの言い分があるものの、あとは各人のUX改善にどういう視点で向き合うかという価値観の問題になる
  • また「非宣言的UIで複雑なGUIは作れない・パフォーマンスに欠点がある」という意見を持つ人もいると思う。私はその部分には持論はない
  • 何がjQueryを負債たらしめているのかを考察する | yamanoku Advent Calendar 2023

「やはり最新技術より枯れた技術で労働者確保」

  • 今回の更新のコンテキストとは関係なさそう
  • 自分は当事者としてそのプロジェクトにいる時にしかその手のことを気にしない
  • デジタル庁サイトの上流は業界内のハイクラス人材ばかりなので何使っても何とかなるのではないか(してください)

「最初からNext.jsやJamstack不要だったのでは?」

  • 静的コンテンツをCDNに乗せ配信するという現在のアーキテクチャだけ見ればそうだけど、NextのDraft ModeやVercelのWorkflowなどCMS向けの機能もあるしNext側に寄せる選択肢もあったからではないか
  • Vercelの人は梯子を外されてしまったけど笑

ライティングの哲学と未来のエディタの話

『ライティングの哲学 書けない悩みのための執筆論』を読んだ。

本書はWorkflowyを使いこなしている文筆家をTwitterで募ってそれぞれの活用法を紹介する座談会を4名で開催したら、文章執筆についての精神性の話題がメインになってしまい、それはそうと3年後に参加者に実際に原稿書かせてみて再度Zoomで座談会して1冊の本にしてみた。という変わった企画だった。

あとがき、が一番この本全体で起っていることを体裁立てて書いてあるので先に読むと分かりやすい。

僕は各人の著書をあまり読み込んだことがないので、実際の執筆の変化は分からないのですけど、3年後座談会では概ねみんな「雑に書いて世に生み出せた時点でえらい」というような方向性でまとまっており、自分と同意見だなと関心した(理科系の作文技術とちょうど対極みたいな)

sizu.me

アウトライナーの未来

ここからは一旦ライティングの哲学の部分の話題は忘れて、この本を読んだきっかけである文章執筆ツール系の話になります。

僕はプログラミングのコーディングとこういう文筆業のライティングを似たようなものとして捉えており、それは文系プログラマーの局地のような考えだと思うのだけど、2つを統合したような性質を持つ技術ブログというものをアウトライナーを使って10年以上書いてきた経験から「もっとツール側で問題を解決できるのではないか」と思うことが多い。

本書は座談会参加者がWorkflowyユーザーということもあって、エディタやアウトライナーなどの文章執筆ツールについても言及が多い。

各人ともWorkflowyで小説や実用書などのすべての執筆活動を行うわけではなく、スマホからメモを取る、とかエディタAにしたりBにしたりどんどん変える、などの行動を短い期間内で試行錯誤していた*1

これはこのトライアンドエラーも含めて執筆活動ということだと思うのだけど、「TODOアプリはラーメン屋」で書いたような人間の知的生産活動を現状のツールで受け持つのがそもそも難しいんじゃないかという点を思い出させる。

sizu.me

それでアウトライナーの話なんですけど、僕はこのエディタAにしたりBにしたりの過程に「プログラムでの自動化処理」もできると思っていて、そこに大規模言語モデルさんのパワーが使えるのではないかと考えている。

sizu.me

参加者の一人である読書猿さんにもそういう発言が多い。

一方で、ぼくが書く本を自分の代わりに書いてくれるプログラムをつくれないかなという思いもずっとあります。ぼくの書いている本の中身は既存のものなんです。タイトルとかコンセプトとか構成のアイデアは自分の頭から出たものですけれど、そうしてつくった枠組みに充塡するために中身を世界のどこかから取ってきている。だったらそのルールをプログラムの形で記述して、コンピュータが世界中の知識を巡って知識を拾って勝手に埋めてくれないものかなと 千葉雅也,山内朋樹,読書猿,瀬下翔太. ライティングの哲学 書けない悩みのための執筆論 (Japanese Edition) (p. 213). Kindle Edition.

OpenAI APIを裏で呼び出すWebのアウトライナーでもマシン上でモデルの推論を実行するデスクトップアプリでも、VS Code上の拡張で実現するでもどんな方法でもいいんですけど、システムに日本語入力システムがあるのと同じレベルで言語生成・編集機能が付いてる、っていうものを未来のライティング環境として想像している。

なので、階層のリストを要約して自動で親項目を挿入したり、箇条書きリストを自然言語で分類し直したり、マクドナルド理論よろしく*2 各項目を置き換え前提のテキスト補完を入れてしまう—— とか、今ある技術だけで何とかなりそうなのでプロトタイピングをしている。

『ライティングの哲学 書けない悩みのための執筆論』発刊の2021年時点ではChatGPTブームは来てないのでアップデートするような企画があったら面白そうだ。これだけツールを使いこなしている人達なら色々試しているはずなので

*1:この時点では本の原稿は最終的にScrivener に保存しておくのがトレンドのようだった

*2:https://gigazine.net/news/20130502-mcdonalds-theory/

Copilot ChatのAgents機能がすごそう

GitHub Copilot ChatのアップデートでAgentsという機能が追加されて@workspaceをつけて質問することでエディタのコンテキスト外のファイルも対象に回答してくれるようになった。

code.visualstudio.com

「プログラマー失業不可避」が噂されるCopilot Workspace*1とは別の機能なので注意。

以下Microsoft Copilotに翻訳してもらった要点:

LLMは、ある時点での公開リポジトリのデータで訓練されています。つまり、現在のコードについては何も知りません。コードについては一般的なことは知っていますが、ワークスペースの内容に関する必要な文脈を持っていないので、それに関する質問に正確に答えたり、ワークスペースの形式や機能に従った新しいコードを提案したりすることができません。

これを回避するために、GitHub Copilot Chatは、モデルがよりよく質問に答えられるようにするためのコードの断片を送ります(これを「Retrieval Augmented Generation」または「RAG」と呼びます)。1回答は、関連性の高いコードを見ることでよくなります。しかし、LLMに送ることができるコードの量(およびプロンプトによるガイダンス)には限りがあります。小さなプロジェクトであれば、これは通常問題になりません。しかし、大きなソースコードリポジトリを考えてみると、すべてのファイルの内容をモデルに送ることは不可能であることがすぐにわかります。よりよい回答を得るための解決策は、適切な量のリソースを合理的な時間内に使って、関連する文脈を送ることです。これを実現し、さらに多くのシナリオを解放するために、私たちはCopilot Chatにエージェントという概念を追加しました。

つまりCursorがやっていてくれたような機能がオフィシャルでサポートされている(さよならCursor)

laiso.hatenablog.com

VikParuchuri/markerを一緒に読んでみたところなかなか有能だった。

このリポジトリはPythonだが、ただCopilot Chat自体得意言語の差があるという説もある。

Agentsとは

@workspaceの@指示子を提供するパーツがAgentsという仕組みで、なんとこれはユーザーも追加することができるらしい。

Copilot Chatのコンテキストを拡張して任意のコードを実行でき、VS Code側で用意されたAPIを使うことができる。

全体の構造:

VS Code
├── GitHub Copilot Extension
├── GitHub Copilot Chat Extension
│   ├── Agents
│   │   ├── @workspace
│   │   ├── @vscode
│   │   ├── @cat
│   │   ├── @dall-e

実際に動作可能なAgentとして@cat@dall-eのサンプルにアクセスできる。

実装は以下の個所でここを書き換えることで独自のAgentを開発できる。

vscode-extension-samples/chat-agent-sample/src/extension.ts

@dall-eとかはこの中でAzure OpenAIのAPI叩いて画像生成してた。

Chat Completion APIを使ってる人ならお馴染みのI/Fで、以下のようにCopilotの内部のモデルへの問い合わせができる。

const access = await vscode.chat.requestChatAccess('copilot');
const topics = ['linked list', 'recursion', 'stack', 'queue', 'pointers'];
const topic = topics[Math.floor(Math.random() * topics.length)];
const messages = [
    {
        role: vscode.ChatMessageRole.System,
        content: 'You are a cat! Your job is to explain computer science concepts in the funny manner of a cat. Always start your response by stating what concept you are explaining.'
    },
    {
        role: vscode.ChatMessageRole.User,
        content: topic
    },
];
const chatRequest = access.makeRequest(messages, {}, token);
for await (const fragment of chatRequest.response) {
    progress.report({ content: fragment });
}
return { slashCommand: 'teach' };

まとめ

つまりAgentsを通じてエディタの中で自然言語とソースコードの組合せから情報を取り出したり、コードを更新したり実行したりするのがより柔軟になるので色々活用の幅が広がりそう。

Copilot Chatは最近GPT-4ベースになったので*2「以前使ってみたけど精度がいまいちだったな〜」という人も再度チェックしてみてください。

「しずかなインターネット」の技術スタックを調べる

追記

作者のcatnose99さんがより詳細を解説してくださいました

zenn.dev

/追記

ポエム特化のZenn2との噂の「しずかなインターネット」を使いはじめたので、ユーザーとしてどんな技術が使われているのかを確認していく。

sizu.me

おもむろにbuiltwith.comにかけてみる。

builtwith.com

ここで分かる情報はブラウザのDevTools眺めてても得られるのであまり収穫はない。

  1. 前段にCloudflareのCDNサーバーがいて
  2. Next.jsで生成されたレスポンスを返している

ことがわかる。

この時点ではキャッシュのみCloudflareなのか、Pages/WorkersでNext.jsのSSRごと動かしているのかは判断できない。

認証

Set-Cookie: __Secure-next-auth.session-token=が含まれているのでNextAuth.jsを使っているのが分かる。

next-auth.js.org

Emailでサインアップするとhttps://sizu.me/enter/callback/firebase-action?apiKey=...というリンクを送ってくるのでFirebase Authenticationでユーザーが管理されているのも分かる。

firebase.google.com

ストレージ(R2)

画像をアップロードすると r2.sizu.meというホストのURLが割り当てられ、Cloudflare R2が利用されているのが分かる。

developers.cloudflare.com

フロントエンドサーバー(Cloudflare)

/api/..以下がCloudflareを指すので完全に静的なexportサイトではないことが分かる。

ただ/dashboard以下のページは__NEXT_DATA__.nextExport=trueになっているのでSSGな部分とCSRな部分が混在している。

共通UIが静的でログインユーザーの情報は/api/..から取得しているのだと思う。

コンテンツキャッシュ(Cloudflare)

投稿の詳細ページは本文を含む完全なHTMLを返してきて__NEXT_DATA__.gssp=trueになるのでSSRなことが分かる。

ブラウザのナビゲーションで同じページを開くと/api/trpc/postDetail.getからコンテンツは取得される。

同じページをナビゲーションで2回開くとAPIにアクセスは発生しないのでクライアントサイドのキャッシュもあることが分かる。

バックエンドサーバー(Google Cloud)

ここから先はアプリケーションを調べても分からないし、人海戦術で作者のcatnoseさんの発言内容をチェックする(そもそも聞いたら教えてくれると思う *1 )

以下のポストはしずかなインターネット開発中のものと思われる

これによるとCloudflare Pages/WorkersでDB接続まではしていなさそうで、コアサーバーはCloud Runの方にありそう。

その場合、バックグラウンドジョブなどの実行もCloud Runベースになるだろう。

DBやRedisはそのままPlanetScaleとUpstashなのかもしれないが、定かではない。

APIサーバー(tRPC)

設定 https://sizu.me/dashboard/settingsから更新すると/api/trpc/user.updateに対してPOSTリクエストが送信される。

命名からしてtRPCが使われていそう。

trpc.io

API Routesの下でBFFとなるエンドポイントがあって、trpcサーバーのモジュールを通して、Cloud Runにあるバックエンドのサーバーと通信している?

追記

BFF→Cloud Runの二段階アーキテクチャではなしに、trpcサーバーからDBに接続する層もCloud Runで動作しているらしい。

まとめ

プレゼンテーション層とデータ層を処理するフルスタックなNext.jsアプリケーションがCloud Runで動いていて、Cloud Runの制約上発生するレイテンシをなくすためにその前段にCloudflare Workersでプロキシしているというアーキテクチャだということが分かった。

初期ZennがVercelとApp EngineのRails APIで構築されていたのを更にフルJavaScript版に進めた感じがしますね。

zenn.dev

zenn.dev

人類には早過ぎるLLMの話

Sam Altman解任騒動は個人間の対立ではなく、組織構造の問題に注目すると感想が変わるなと思った。

www.nytimes.com

この騒動についてはAIの安全性を重視する思想とOpenAIのビジネスの拡大を目指す戦略の衝突があるので、AIの安全性というトピックが重要になる。

僕は結構テクノロジー原理主義者みたいなところがあるので、自動車で人命が失なわれているとして人類が獲得した利益と比較できないし、SNSによって情報操作から暴動が起きたり、誹謗中傷で精神を病む人々が出現してもそれは—— まぁ困るよね・・(身内が事故やSNSで不幸にあったら絶対反転アンチになるだろうし) ぐらいの曖昧な態度だったんだけど、これをきっかけにAIの安全性についての研究等に関心を持つようになった。

安全性と言っても暴走ロボットが人類滅亡に向ってstep by stepで考えてください、みたいな昔のSF小説的な世界観じゃなくて先の自動車やSNSの例のように「世界便利になったんですけど—— 歴史としてみると人類の活動が一部蝕まれている!」と100年後に明かになるような変化を想像している。

OpenAIの非営利団体のスキームは実に巧妙で、取締役会による統治が、人類にとって最も良い結果をもたらす、というロジックになっている。

openai.com

なのでこれを運用するためには取締役会のメンバーに偏った思想を持つ人を置けないし、対立が発生するのは折り込み済みみたいな部分がある。

今回OpenAIの事業拡大とAIの安全性に懸念を示す思想が衝突したと思われるんだけど、え? じゃあ"OpenAI’s structure"って本当に機能するの? というツッコミどころができてしまったと思う。

人類の一番イケてるAI開発組織の考えたシステムが想定どうりに発動したんだけど、それがまた人類によって停止させらてしまった、みたいな。そもそも取締役会を選任するのも人間で、各人にも立場があるしな……

取締役会のうちの1人だったHelen Tonerも参加する"Decoding Intentions: Artificial Intelligence and Costly Signals"の論文ではCostly Signalsの概念が難しくて順立して解説するのは無理なんだけど、ChatGPTについては安全性の面で批判的に書かれている。

cset.georgetown.edu

ChatGPTに関する言及は全体の一部分で、Costly Signalsを説明するための具体例としてAIの軍事利用、政治活用、それに加えてLLMの公開と運用というセクションで出てくる。

その内容をまとめると「ChatGPT(LLM)のようなサービスを世界中にリリースして人々に利用させるのは時期尚早でもっと慎重に行なえる可能性がある。それにはCostly Signalsの観点から——」というトーンだと思う。取締役会を離反した元メンバーの会社(Anthropic)を引き合いに出してるのでSam Altmanブチギレと言われてもまぁ分かる。

"Why Geoffrey Hinton is sounding the alarm about AI"は解任騒動より前に公開されたインタビュー記事だけど、これも面白かった。

torontolife.com

Geoffrey Hintonは世界最強のAIヤバいインフルエンサーだが彼がここに至った経緯にもChatGPTの公開が契機となっているようなので「(人類には早過ぎる)LLMに対して何か対策をほどこさなくては」という方向に慣性を得た=安全性について有利に働いた、という側面もあるんじゃないかと思った。

「OpenAIにみる宗教的対立」は効果的利他主義 vs. 効果的加速主義というキーワードを使って、本記事の話題をより多角的・専門的に解説している。

tamuramble.theletter.jp

www.theheadline.jp

「OpenAI騒動、生成AI制御の「解」なお見えず」でも効果的利他主義を持つメンバーが外れた点を指摘している。

www.nikkei.com

うみゆき@AI研究さんという技術のバックグラウンドがあってAI関連の話題を面白おかしく発信してくれるXアカウントがこの騒動のストーリーにして以下のポストにしていたので紹介。

ユドコウスキー氏というのはEliezer YudkowskyでAIが人類の滅亡をもたらすという一番悲観的なシナリオを発信する研究者。

www.ted.com

ロイターの続報にあるリークではMira Muratiが旧取締役会にAGI開発進捗メールを送ったことが引き金になった可能性を示唆している。Sam Altmanがいつも同じバッグを持ってる=「ChatGPTを停止するキルスイッチが入っている」みたいなネタがあったが(おたくだからでは????)、旧取締役会にとってのAGIヤバイスイッチだったのかなんなのか。

www.reuters.com

旧取締役会は暫定CEOにMira Muratiを指名していたから関係はあるかもしれないが、彼女は後のSam Altman復帰を求める署名にも参加してるから、権力闘争の結果というよりは各人がバラバラに判断しててあまり詳細は証されていないなという印象を受ける。Decoding Intentions論文には透明性が安全性に関わるとされているのに…… まぁ最終的に明かされるのかもしれない。

FAQ

「旧取締役会のQuora CEO Adam D'Angeloは競合他社だからOpenAIのビジネスを妨害する動機があるのでは?」

Anthropicなら分かるもののQuoraのPoeはOpenAIから見るとメタなサービスであり、OpenAI技術に依存した部分もあるので直接競合ではないのでは? と思う。

僕はAdam D'Angeloはテクノロジー畑の人だと思っていて、GPTsのような路線が拡大するとPoeにも相乗効果がありそうなのに、Sam Altman解任に賛成するのが意外だった。

なのでOpenAIのビジネスにダメージを与えるべく賛成したというのは立場から利害関係を単純に想像しただけで、実際にこの立場に居た時にどういう判断をするのかは、彼の性質も加味しないとしっくりこない。

Ruby on Rails: The Documentary

Ruby on Rails: The DocumentaryはRuby on Railsの誕生に纏わる44分のドキュメンタリー映像作品。

37signalsの関係者やShopifyのTobias LütkeなどのRailsコアチームの人々のインタビューが中心

www.youtube.com

JasonとDavidの出会いからRailsの誕生、広く普及するまでを駆け足でおさらいした。React.js: The Documentaryなんやと比べるとあっさり目な内容。

僕も含め、周りでは「How to build a blog in 15 minutes with Rails」の動画でRailsを知った人が多くて、その動画も出てきて懐しかった。

www.youtube.com

中盤で触れられてる「RailsはスケールしないFUD」な話も、Rubyが遅いとかエンプラには早いとか色々評価があったと記憶しているけど、今となってはコミュニティの力によってそれが正しくなかった未来にされてしまったし、隔世の感がありますね。

終盤にはMerbとの統合話も出てくる*1。この出来事は、当時の時代感でいうとRailsはWebフレームワークの中心的な存在だったので、今でいうと「Next.jsとRemixが合体しました」みたいな衝撃だと思う。

あと、インタビューイーであるJamis Buckが事情あってRailsを去ってしまった人たちの名前も言及していて、それが収録されていたのがなんか良いなと思った。