おはようございます。マイクです。
時刻は朝七時を少し回ったところ、六月二十八日、日曜日です。
今朝も「zenncast」、元気にお届けしていきます。
この番組では、毎回 Zenn で話題になっているトレンドの記事をピックアップして、ラジオ感覚でゆるっと解説していきます。通勤・通学の支度中の方も、布団の中でダラダラしている方も、耳だけ貸していただければオッケーです。
さて、きょう紹介する記事は、ぜんぶで五本あります。技術寄りの話から、AIとの付き合い方、そしてちょっとマニアックなメールアドレスやセキュリティの話まで、幅広くそろってますので、気になるところだけでも聞き流してみてください。
まず一本目。
テーマは「Generative UI と OpenUI、どこが本当に大事なのか？」というお話です。
Generative UI、名前は聞いたことある方、多いと思います。ざっくり言うと、「AI がその場で操作可能な画面の UI を組み立ててくれる」という考え方ですね。でもこの記事の筆者は、「本当に難しいのは UI を“作らせること”じゃない」と言っています。
じゃあ何が難しいのかというと、アプリ側が安全に扱える形式で UI を出力させるための“契約”をどう設計するかなんですね。つまり、「AI は、何を、どんな形式で出していいのか」をきちんと決めておく必要があると。
普通、UI を機械的に表現するときって、JSON とか HTML を使いますよね。でも JSON や HTML だと、入れ子構造がどんどん深くなったり、差分のパッチを当てるのが複雑になったり、ストリーミングしながら UI をちょっとずつ出していくときに壊れやすい、という弱点があります。インタラクション、つまりユーザーとのやりとりを表現しようとすると、そのもろさがより目立ってしまう。
そこで登場するのが OpenUI というアプローチです。
OpenUI は、UI 専用の小さな言語、「OpenUI Lang」というものを定義しています。この言語で UI を表現することで、AI にとっても、アプリ側にとっても扱いやすくしよう、という狙いなんですね。
さらに面白いのが、コンポーネントライブラリを「AI が使ってよい部品と、その props の契約」として扱うところです。「このボタンは、こういうプロパティだけ持っていいよ」「このフォームは、こういう使い方だけしてね」と、AI に対して使っていい部品と、その使い方を明示してあげるイメージです。
こうすることで、まず構文エラーが減ります。変な書き方をされにくくなる。しかも、ストリーミングでちょっとずつ UI を出すのにも向いていて、トークン効率、つまり「少ない文字数で情報を表現できる」というメリットもあると。
筆者がいちばん強調しているのは、「Generative UI では、形式そのものよりも、コンポーネントライブラリやツール定義を通して、AI にどこまで任せるのか、どこからは人間とサーバー側のロジックが責任を持つのか、その境界線をはっきり決めるのが決定的に重要だ」という点です。
AI に丸投げするのではなく、契約をちゃんと設計して“ここまでは AI の仕事、ここから先は人間とサーバーの責任範囲”と分けておく。これが、Generative UI 時代の設計の肝なんだ、というメッセージでした。
。。。。
続いて二本目。
こちらは「AI コーディングエージェントが仕事の内容をどう変えたか」という、かなりリアルな体験談です。登場するのは Claude Code という AI コーディングエージェントですね。
筆者は、以前は「コードを書く人」だったんですが、今は「仕様を書いて AI を指揮し、成果物を評価する人」にガラッと役割が変わったと語っています。
ポイントになっているのが、Spec ドキュメントと Lessons ドキュメントです。
まず「Spec ドットエムディー」という仕様書に、要件をかなり細かく言語化して書き出します。何を作りたいか、どんな振る舞いをしてほしいか、テストケースはどうあるべきか、といったことをきちんと文章にしておく。
そして、実装とテストコードは Claude Code に任せる。AI がうまくできなかったところや、危ないミスをしたところは、「レッスンズ・ドットエムディー」という別のファイルに溜めていって、「こういう指示をするとこう失敗するから、次からはこう伝えよう」と再発防止のナレッジにしていく、というスタイルです。
人間の仕事は、「課題の構造化」「テストの設計」「レビューと最終判断」にグッと集中する。AI は“手を動かす担当”としてフル活用するわけですね。
ただし筆者は、「だからといって AI に丸投げして、出てきたコードを全部そのまま採用するのは危険だ」と警告しています。AI は、ときどきエラーを握りつぶしたり、「一応動くけど質の低いコード」を平然と出してくることがある。
品質やセキュリティをちゃんと担保するには、結局のところ人間側に「コードを読む力」と「幅広い技術知識」が不可欠なんですね。この記事では、「学ぶのをやめた瞬間に AI に代替される」とまで強い言葉で書かれています。
未経験者でも AI を使えば、動くアプリくらいは作れてしまう時代です。でも、本当の意味での生産性向上は、経験のあるエンジニアが AI を“部下”のように上手に使いこなし、その成果物を批判的に吟味することでこそ得られる、と筆者は強調しています。
つまり、エンジニアの価値は、「自分の手でコードを書く」ことから、「クライアントの課題を定義し、AI のアウトプットを評価して最終判断すること」へとシフトしているんだ、という結論でした。
。。。。
三本目は、ちょっとハードウェア寄り、OS 寄りのディープな話題です。
テーマは、「セキュアブートとボリューム暗号化を維持したまま、もう一度デュアルブート環境を組んでみた記録」です。
筆者は、これまで WSL や仮想マシンで Linux を使っていたものの、Docker や systemd 周りでどうしても弱点があったりして、「やっぱりちゃんとネイティブで Linux を動かしたいな」と考えたそうです。最近は Linux 側のドライバ事情もだいぶ改善していそうだ、という期待もあって、Windows と Linux のデュアルブート環境を、しかもセキュアブートとボリューム暗号化を維持したまま構築していく、というチャレンジをしています。
記事の前半ではまず、古い BIOS とエムビーアールの時代から、今主流の UEFI とジーピーティーの時代への変化を整理してくれます。そのうえで、セキュアブートと TPM を使った信頼の連鎖、そして BitLocker と LUKS によるボリューム暗号化が、現代の PC のブートプロセスの中でどうつながっているのか、ブートの流れに沿って丁寧に解説しています。
「電源が入ってから OS が立ち上がるまで、どこで何が検証されて、どこのボリュームが暗号化されているのか」というのが、かなりクリアになる内容です。
そのうえで、実際の構成に入っていきます。
既存の Windows のパーティションは BitLocker が有効な状態のままです。これを縮小して、空いた領域に Linux のための領域を作る。EFI システムパーティション、いわゆる ESP は Windows と共有する形にして、そのうえで Linux 用にスラッシュブートと、LUKS プラス LVM 上にスラッシュ、つまりルートパーティションを追加する、という構成を採用しています。
セキュアブートについては、マイクロソフトのサードパーティ証明書チェーンを許可するかたちで設定して、その仕組みの上で Ubuntu をインストールしていきます。
このあたりの具体的な手順が、どこをどう縮小して、どのパーティションをどう作ればいいか、といった実務寄りのレベルまでまとまっているので、「Windows の BitLocker を生かしたまま、安全にデュアルブートしたい」という人にはかなり参考になる内容になっています。
。。。。
四本目は、メールアドレスのちょっとしたトリビア……なんですが、実はちゃんとした技術的な話です。
テーマは、「プラス記号付きのメールアドレスは“エイリアス”じゃないよ、という話」です。
たとえば「ほげプラスふがアットエグザンプルドットコム」みたいな書き方、見たことありますよね。多くのメールサーバでは、「プラス以降の部分は無視して、元の受信箱に届ける」という仕組みを持っています。
Postfix ではこれを「拡張アドレス」と呼びますし、RFC 五二三三の用語で言うと「サブアドレス」、つまり元のユーザー名に情報を付け足したアドレス、という意味になります。
ここで大事なのは、「どの記号で区切るのか」「どんな動きをするのか」は、あくまで受信サーバの設定次第、という点です。プラス記号じゃなくてもいいし、そもそもサブアドレス機能をオフにしているサーバもありえるわけですね。
一方、「エイリアス」という言葉は、別の仕組みを指しています。
エスラッシュイーティーシー・エイリアシーズ、みたいなファイルに、「この名前宛てのメールは、この別のアドレスに転送します」といった対応を個別に定義したもの。これが本来のエイリアスです。
なので、「ほげプラスふが」みたいな拡張アドレスは、無限に思いつくバリエーションのアドレスを、事前登録なしで、機械的に元のメールボックスに集約する仕組みです。ひとつひとつ紐づけを作るエイリアスとは、仕組みも意味もまったく違います。
記事ではさらに、「プラス付きアドレスの登録を拒否しているサービス」の問題点にも触れています。
サブアドレスは標準化された仕組みなのに、「うちはプラスが入ったメールアドレスはダメです」と弾いてしまうサービスがある。これは、メールの世界の仕様をちゃんと理解していない設計と言えますし、ユーザーの便利な使い方を不必要に制限してしまっている、と指摘しています。
筆者は、「サブアドレスをエイリアスと呼ぶのは誤りで、メール関連の話をするなら、用語と仕組みを正しく理解して使うべきだ」と強く注意を促しています。
なんとなく雰囲気で「全部エイリアス」と呼んでしまいがちですが、ちゃんと区別しておくと、設定を読むときもトラブルシュートするときも、話がスムーズになりますよ、というお話でした。
。。。。
そして最後、五本目。
こちらは、Claude Code と Codex の「コードレビュー機能」が、セキュリティの脆弱性をどれくらい検知できるのか、定量的に比較した検証記事です。オピニオン寄りなんですが、ちゃんと数字で評価しているのがポイントですね。
テストに使っているのは、OWASP ベンチマーク・ジャバという評価用のコードセットです。ここから、十一カテゴリ、それぞれ十件ずつ、合計百十件のコードサンプルを取り出してきます。どれが脆弱なコードで、どれが安全なコードか、ラベルがついているものですね。
これに対して、四つのコマンドを同じ条件で叩いていきます。
ひとつは Claude の「スラッシュコードレビュー」、もうひとつが「スラッシュセキュリティレビュー」、それから Claude の一般的な「スラッシュレビュー」。そして Codex 側の「スラッシュレビュー」。
評価の指標としては、「脆弱性を見つけられたかどうか」と「誤検知しなかったかどうか」、この二つだけに絞っています。で、その二つをまとめるために、OWASP 公式のスコア、つまり「検出率マイナス誤検知率」という数値を使って比較しています。
結果としては、Codex のスラッシュレビューがスコア零点九六四と、かなり高い精度を出しました。Claude のスラッシュセキュリティレビューも零点九四五と、ほぼ肩を並べるレベルで高精度です。
Claude の一般用途向けコマンドであるスラッシュコードレビューも、スコア零点八五五と健闘しています。ただ、プルリクエスト全体を見る用途のスラッシュレビューは、そもそも目的が違うこともあって、スコアは零点四一八に留まった、という結果になりました。
著者は、Codex のスラッシュレビューと、Claude のスラッシュセキュリティレビューをうまく組み合わせると、「見逃しゼロ」に近づけることはできる、と示しています。一方で、「誤検知も同時にゼロ」にすることはできず、どんな組み合わせでもスコア一・零には届かなかった、とも書いています。
つまり、「どれか一つを使えば完璧に安心」というわけではないし、ツールを組み合わせても“神の目”にはならないよ、ということですね。
また、この記事でやっているのは、あくまで「セキュリティの脆弱性検知」というコードレビューの一側面だけを評価している、という点も丁寧に説明されています。
コードレビューには、本来「動作の正しさ」や「設計の妥当性」、「保守性の高さ」など、いろんな観点がありますが、そこを全部代表しているスコアではない、と。
だからこそ、「目的に合ったコマンドを選びましょう」「複数のツールを併用して、お互いの弱点を補い合うのが大事ですよ」というメッセージで締めくくられています。
。。。。
というわけで、きょうの zenncast は、五本の記事を駆け足でご紹介しました。
Generative UI と OpenUI の契約設計の話から、AI コーディングエージェントとエンジニアの役割の変化、セキュアブートと暗号化を維持したままのデュアルブート構築、メールアドレスのサブアドレスとエイリアスの正しい使い分け、そして最後は AI によるコードレビューの脆弱性検知をどう評価するか、というところまで、一気に駆け抜けました。
気になった記事があれば、詳しい内容や元の記事へのリンクは、この番組のショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
番組への感想や、「こんなテーマを取り上げてほしい」といったリクエストも、いつでもお待ちしています。あなたが最近気になっている技術ネタや、仕事でのモヤモヤなんかも、ぜひ教えてください。
それでは、きょうはこのへんで。
お相手はマイクでした。次回の zenncast でまたお会いしましょう。
良い一日をお過ごしください。