どうもこんばんは、マイクです。「zenncast」金曜の朝担当しております。
今日は二〇二六年八月二十一日、金曜日の朝七時を回ったところです。
この時間は、テック系のナレッジ共有サービス「Zenn」で、きょうトレンドになっている記事をピックアップしてご紹介していきます。ゆったりコーヒーでも飲みながら、お付き合いください。
さて、きょう紹介する記事は、ぜんぶで五本用意しています。
デスクトップアプリのメモリの話から、分散システムの形式仕様、社内エージェントの評価方法、AIエージェントの権限設計、それからデザイナーさんがAIコードエディタと一緒にフロント実装した話まで、盛りだくさんでいきます。
まず一つ目。
一つ目は、いろんなデスクトップUIフレームワークの「メモリの重さ」を実測してみた、というオピニオン寄りの計測レポートです。
最近ね、メモリ価格が上がってきていたり、クラウドのメモリ課金もじわじわ効いてきたりで、「アプリがどれくらいメモリを食うか」って、前より重要になってきてますよね。
この記事の著者は、よく言われる「Electron は重い」「Rust 系は軽い」「Tauri は省メモリ」みたいな評判が本当なのかを確かめるために、なんと十五種類のデスクトップUIフレームワークを並べて、同じ高負荷のアプリをAIにコーディングさせて、そのうえで物理メモリ使用量の最大値を比較しています。
内容としては、ネイティブ系とRust 系がどうか、WebView 系がどうか、JVM や Go 系がどうかっていうのを、実測値と一緒に見ていく感じですね。
結果としては、まずネイティブ系とRust 系は、おおむね百メガから百七十メガ台で収まっていて、「かなり省メモリだよね」という結論です。
mac の AppKit と SwiftUI みたいなOS標準のフレームワークはもちろん、Linux界隈でおなじみの GTK や Qt、それから Rust 系の Slint、iced、egui といったフレームワークも、ネイティブ組と互角か、それ以上の効率が出ていたそうです。
一方で、WebView を土台にしているElectron、Tauri、Wails、Neutralino みたいなフレームワークと、JVM や Go を使う Compose、Fyne といったフレームワークは、ピークで四百五十メガから五百三十メガくらいまでいってしまって、かなり「重い」結果になったと。
特に、JVM 系は一度確保したメモリをなかなか手放さずに持ち続ける傾向がある、という指摘もされています。
おもしろいのが、Flutter と Avalonia。
この二つは、いわゆる完全ネイティブほどではないにせよ、Web系ほどは重くなくて、メモリ効率的にはかなり健闘してるポジションだったそうです。
Dart や Cシャープで書けて、開発効率もそれなりに高いことを考えると、「現実的な選択肢として、かなりアリなんじゃない？」という評価になっています。
そのうえで著者は、「メモリがほんとにシビアな環境であれば、WebView 系は構造的にどうしても不利で、チューニングには限界があるよね」と。
だから、将来的には、「仕様だけ決めておいて、OS標準のUIをAIに実装させる」みたいな方向性もあるかもしれない、というちょっと未来っぽい締め方をしています。
「とりあえずElectronで」って言いがちなところに、測ってから考えようぜ、という一石を投じる記事でした。
。 。 。 。
続いて二つ目。
こちらは、分散システム向けのRust製ミドルウェア「celld」で起き得る、ちょっと怖いバグを形式仕様で見つけた、というお話です。オピニオン寄りの技術紹介ですね。
この celld っていうミドルウェアは、「一つの cell には、常に writer が一つだけ」という制約を守りたいシステムなんですけど、筆者はこれを Quint という形式仕様言語でモデル化して、モデルチェックをかけました。
すると、「実時間の時計」であるウォールクロックと、「戻らないローカル時計」であるモノトニッククロック、この二種類の時計を混在させて期限を判断してしまっていたために、時計のズレ次第では、一時的に writer が二つとも“有効”になってしまうケースが出てくる、というパターンが見つかったんですね。
Quint のモデルチェックで、具体的な反例が出てくるんですが、その反例には、具体的な時刻や、TTL、時計のズレの値がぜんぶ書かれている。
筆者はそれをそのまま Rust のテストコード、`State::on_event` のテストケースに落とし込んで、実装側でも本当に再現するかを確認しています。
で、見事に同じパターンが発生して、「これはモデルだけの机上の話じゃなくて、“本物のバグだ”」ということがはっきりした、という流れです。
そのあと記事では、「じゃあどう防ぐの？」という話にも触れていて、時計のズレに上限を設けて、テイクオーバーをちょっと遅らせるとか、分散システムでよくある一般的な対策を紹介しつつ、「安全性」と「フェイルオーバーの速さ」のトレードオフについてもコメントしています。
ここで筆者が言いたいのは、形式仕様って「全体を数学的に証明するための、すごく重たい道具」というイメージがあるけれど、実際には、分散システムで「なんかこの辺あやしいな…」と思っているところを、具体的な反例と、回帰テストに変えてくれる“実用的なデバッグ手段”として使える、ということなんですね。
「考えてもモヤモヤが晴れない」部分を、仕様言語に書き下ろして、モデルチェックでガツンと殴ってみる。その結果をそのままテストにして、バグを潰していく。こういう現実的な使い方が紹介されています。
。 。 。 。
三つ目の記事にいきましょう。
ここからは、AI エージェントを「社内の新入社員」として受け入れる話です。
会社にエージェントを導入するときに、「社内ルールや手順をどう教えるのか」とか、「どのくらい仕事ができるようになったら“戦力”と見なせるのか」を、きちんと測るのが課題になっている、という出発点ですね。
筆者は、新入社員向けに用意されている Notion のオンボーディング資料を土台にして、その中の条件や完了状態なんかを整理して、「Skills」という形で構造化しました。
そのうえで、「全く知識を事前に持たせない状態」「毎回 Notion を検索しながら答えさせる状態」「あらかじめ整理済みの Skills を参照させる状態」という三つのパターンを用意して、十五問の実務っぽい自由回答課題を出してみたんですね。
で、それぞれの回答を、Rubric というチェックリスト形式の評価表で採点しています。
結果がかなりわかりやすくて、項目ベースの正解率は、
知識なしだと三十三パーセント、
Notion をその都度検索するパターンで八十七点三パーセント、
そして整理済み Skills を参照するパターンだと九十六パーセント。
Skills を使ったときが、正解率も一番高くて、応答も速いし、必要な入力の文章量も少なく済んだ、というのがポイントです。
なぜかというと、Notion 検索のパターンは、毎回検索ワードをどう選ぶかとか、どのページを開くかとか、そういう「ゆらぎ」が大きくて、情報もあちこちに分散している。
それに対して、あらかじめ判断条件とか優先ルールを整理しておいた Skills の方は、「このケースではこう判断する」っていう現場ルールを安定して適用できるから、ぶれにくい、という考察になっています。
一方で、この記事はちゃんと限界も挙げていて、問題数が十五問と少ないこと、人手で厳密な採点をしていないこと、実際にツール操作まで含めた「作業完了レベル」はまだ測れていないこと、それから重大なミスが完全にゼロになったわけではないこと、こういった点を課題として認めています。
筆者が強調しているのは、「このエージェントが、何をできれば“仕事ができる”と見なせるのか」を、Eval としてちゃんと具体化することが大事だ、というところです。
単なる一問一答ではなくて、現場で起こる条件分岐とか、ミスした時の重さを Rubric に落とし込んで、継続的に評価と改善を回していく必要がある。
AI を“社員”として受け入れるなら、評価制度もちゃんと設計しよう、という、組織寄りの視点が入った記事になっています。
。 。 。 。
では四つ目。
今度は、AI エージェントがたくさんの外部サービスと連携するときの「認可どうする問題」です。
サービスごとに「このアプリに権限を与えますか？」っていう認可画面が、何度も何度も出てきて、作業がぜんぜん進まない、という経験、ある方も多いと思います。
この記事では、ユーザーが最初の一回だけ、たとえば Google みたいな IdP、アイディプロバイダで認証します。
そのときにもらった `id_token` を使って、追加のユーザー操作なしに、各サービスごとの `access_token` に交換していく「OBO」、オン・ビーハーフ・オブ方式を解説しています。
「ユーザーに代わって、このエージェントが権限をもらいます」というイメージですね。
この OBO 方式は、RFC 八六九三で定義されているトークン交換の一種で、AI エージェントがユーザーの代理として認可サーバーに `id_token` を渡して、そのユーザーに代わる `access_token` を各サービス向けに発行してもらう、という仕組みです。
記事では、これを実装するために必要な要件が、かなり整理されています。
具体的には、トークン交換用のエンドポイントを用意すること、新しく必要になるトークン検証の処理と、既存の検証とのすみ分け、ユーザー権限をどう解決するか、そして最終的なJWTをどう発行するか、といったポイントですね。
サンプルとして、TypeScript と AWS を使った構成が紹介されていて、Cognito、Lambda、API Gateway、それから Bedrock AgentCore を組み合わせた例が説明されています。
さらに、本番運用で怖いのが、「なりすまし」や「権限の取り過ぎ」。
ここにどう対処するかも詳しく書かれていて、トークンの検証やエラー応答の設計、署名鍵の管理と、トークンの有効期限やローテーションの仕方、そして監視のポイントですね。
特に、ユーザー本人が誰なのか、代理実行しているエージェントはどれなのか、実際にどんな scope の権限を付与したのかを、あとからたどれるようにログを残しておく重要性が強調されています。
全体として、「ブラウザでログインしたときみたいに、一回サインインしたら、あとはシームレスに色んなサービスにアクセスできる」というSSOの体験を、AI エージェント側にも持たせてあげる。そのうえで、安全に権限委任をデザインするための、かなり実践的なガイドになっています。
。 。 。 。
そして最後、五つ目の記事です。
これはちょっと雰囲気が変わって、デザイナーさんが AI コーディングエディタの Cursor を使いながら、自分の手でフロントエンド実装を学びつつ、デザインシステムを構築していった実践レポートになっています。
もともと Figma 上では、デザインシステムはもう完成していた。でも、エンジニアが足りなくて、実装側がなかなか前に進まない。
そこで筆者は、「じゃあ自分でやろう」と、React と TypeScript、それから MUI を使った実装にチャレンジします。
そのとき Cursor を、「全部自動でコードを書いてくれる魔法のツール」ではなくて、「困ったときのメンター役」として使った、というのが面白いところです。
実際の進め方としては、わからない部分を都度 Cursor に質問しながら、少しずつ理解を広げていくスタイル。
Figma のデザインとコードを行ったり来たりしながら、「ブランドに合うこの微妙なトーン、余白、動きはどこで調整するのがいいか」を、試行錯誤しやすくなったと書かれています。
その結果、だいたい三週間で二十二個のコンポーネントを実装できたそうです。これは、デザイナー一人でやったと考えると、かなりのペースですよね。
もう一つの学びとして、コード側で「どこまで振る舞いを固定しておくべきか」、逆に「文章のガイドラインには何を書いておくべきか」、その境界線が見えるようになってきた、と。
つまり、デザインシステムの中で、どこを決め打ちにして、どこを柔軟にしておくか、仕様と実装の分担が、実際に手を動かすことで理解できた、という話です。
記事の締めでは、「AIと分業しながら、自分の専門性を横に広げていく働き方が、もう現実的になっている」と述べています。
AIに任せっぱなしではなくて、「AIをメンターにしながら、自分もスキルを伸ばしていく」。
そんな前向きなコラボレーションの例として、読んでいて勇気をもらえる内容でした。
というわけで、きょうの「zenncast」、駆け足でおさらいしておきます。
一つ目は、十五種類のデスクトップUIフレームワークを比較して、ネイティブ系とRust 系の省メモリさ、WebView 系やJVM系の重さ、Flutter・Avaloniaの健闘ぶりを測ったメモリ計測レポート。
二つ目は、Rust 製ミドルウェア celld で、ウォールクロックとモノトニッククロックの混在から「一時的に writer が二つ」になるバグを、Quint のモデルチェックで見つけて、実装テストで確認した話。
三つ目は、社内エージェントを「新入社員」として迎えるために、Notion のオンボ資料から Skills と Rubric を作って、「どこまでできれば戦力か」を Eval として定義していく取り組み。
四つ目は、AI エージェントにブラウザ並みのSSO体験を持たせるため、OBO 方式で `id_token` から各サービスの `access_token` を安全に交換する設計と、権限・監査ログの実践的なガイド。
そして五つ目は、デザイナーが Cursor をメンター的に使いながら、React と TypeScript、MUI で二十二コンポーネントを三週間で実装し、AIと分業する新しい働き方を模索したレポートでした。
気になる記事があった方は、詳しい内容や元の記事へのリンクはショーノートにまとめてありますので、あとでじっくり読んでみてください。
この番組「zenncast」では、みなさんからの感想や、「こんなトピックを取り上げてほしい」といったリクエストもお待ちしています。
日々の開発で感じたモヤモヤや、「これ他の人どうしてるの？」っていうネタも、ぜひ教えてください。
それでは、きょうも良い一日をお過ごしください。
お相手はマイクでした。また次回、お会いしましょう。