どうもおはようございます。マイクです。
今朝は二千二十六年九月一日、火曜日の朝七時を少し回ったところです。
今日も「zenncast」、最新のテックトレンドをゆるっと楽しくお届けしていきます。今日は、技術者の皆さんがZennに投稿してくれた、今ホットなトレンド記事をまとめてご紹介していきますね。
さてさて、きょう紹介する記事は、ぜんぶで五本です。
AIエージェント環境づくり、TypeScript製の組版エンジン、日本語ウェブのアクセシビリティ、npmパッケージが乗っ取られたときの対応、そしてGitHub ActionsのArtifactの新しい使い方まで、かなり幅広いラインナップになってます。コーヒーでも飲みながら、耳だけ貸してもらえたらうれしいです。
まず一つ目。
八ビットドゥー・マイクロという、ちっちゃいゲームコントローラーを、なんとターミナル用のコントローラーとしてマッピングして、片手操作と音声入力を組み合わせて「体への負担を減らしながらAIと作業する環境」を作っている、というお話です。
キーボードを長時間ガチャガチャ叩き続けるのって、手首とか肩にきますよね。この筆者の方は、ターミナル操作をコントローラ側に割り当てて、片手でポチポチしながら、もう片方は音声入力でAIと会話、みたいなスタイルを作っていて、「とにかく人間の体を壊さない」ことをかなり意識した環境づくりをしています。
使っているのは、claude code という環境で、permissions設定のオートと、ビュー・モードの「フォーカス」というモードを組み合わせて、AIエージェントがかなり自律的に実装を進めてくれるようにしているそうです。人間がずっと画面を見張ってなくても、AIがちゃんと進めてくれて、必要なときだけチェックする。さらに、実装をガンガン書くモデルと、助言をしてくれるアドバイザー用モデルを分けているのも面白いポイントです。
MacBook側も工夫されていて、エージェントが作業しているあいだはスリープしないように設定しておいて、代わりに「SidePulse」というLEDガジェットで進捗を色で可視化しているんですね。「いま作業中」「終わったよ」「ちょっと人間の対応が必要だよ」みたいな状態が、パソコンをのぞき込まなくても色で分かるようになっている。物理ガジェットでAIの進捗を見る、ちょっと未来のオフィス感があります。
エディタの設定まわりもかなり作り込んでいて、settingsのJSONの差分は、そのまま見るんじゃなくて、jqで一回整形してから比較するとか、ステータスラインにはトークンの使用量を電池の絵文字で割合表示したりしています。AIにどれくらいトークン食わせているかが一目で分かるので、ちょっと節約モードにしようかな、みたいな判断もしやすいと。
実装の動作確認とか、開発サーバーの起動は、「zmx」という仕組みと、エージェント用のブラウザ・ターミナルのツールを組み合わせて、AIにほぼ自律で任せています。テスト回したり、開発サーバー立ち上げたりといった「人間がやると地味にダルい作業」を、なるべく人間のボトルネックにしないようにしているわけですね。
とはいえ、なんでも勝手に触られるのは怖いので、「cage」とか「guard-and-guide」という仕組みで、ファイルの書き込みや、読み込み・コマンド実行を、ゆるく制限しています。ポイントは、「危ない操作をしようとしたときに、制限を回避しようとがんばらず、ちゃんと諦める」ようにプロンプトで教えているところ。AIに、「これは制限されてるから、それを前提に別のやり方を考えようね」と言い聞かせている感じです。
さらに、AIエージェントの内部でどんな思考をしているか、どんなツールを実行しているかを、別画面から見られる専用のログ閲覧ツールも用意していて、セッションの裏側までチェックできるようになっています。冗長な実装をしていないかは、「ponytail」というプラグインにチェックさせて、コメントの書き方は「CLAUDEドットエムディー」というルール集を用意して、「誰が読んでも分かるコメント文言」に揃えているという、かなり几帳面な設計です。
リポジトリの中には、「ズィー・エーアイ」というディレクトリを作って、そこをAI専用のワークスペースにして、あえてgit管理からは外しています。知見の保存はclaudeのメモリ機能に任せて、ローカルのリポジトリは汚さない。で、Mac本体の画面には「エージェントオフィス」をどーんと表示して、「今AIが働いてますよ」という「働いている感」もちゃんと演出しているのがおもしろいです。
レビュー対応とか、コミットの整理も、「アドレス」とか「リプライ・レビュー」「リベーサー」「リワーダー」といったコマンドやエージェントに落とし込んで、GitHub Actions用のルールにして定型化しています。で、こういう設定全体を、半年から四半期ごとに一回棚卸しして、要らなくなったものはちゃんと捨てて、AI本体の進化に合わせて最適化し直している。道具も「作りっぱなし」じゃなくて、定期メンテするのが大事だよ、というお話でした。AIに仕事を任せたい人には、すごく参考になる環境づくりだと思います。 。。。
続いて二つ目の記事。
TypeScriptのライブラリとして動く組版エンジン「ミニタイプ」を紹介する内容です。
ふつう「ちゃんとした組版」っていうと、専用のフォーマットや言語を覚えて、専用アプリでPDFを作る、みたいな世界なんですけど、このミニタイプは、それを「npmから入るTypeScriptライブラリとして、直接呼び出せるようにした」というのが大きなポイントです。Nodeジェイエスでもブラウザでも動いて、日本語の縦組や禁則処理、ルビなんかにも対応していますし、行分割はクヌース・プラスという有名なアルゴリズムに基づいてやってくれます。
しかも、ただPDFを吐くだけじゃなくて、「この文章はどこにどうレイアウトされたか」という情報も一緒に取れるようになっているんですね。なので、「見た目」と「構造」を両方扱えるエンジンになっている、と。
文章の定義の仕方もおもしろくて、見出しはエイチワン、本文はピー、みたいな関数で宣言的に書いていきます。表や図、脚注、数式、それから段組とかボックスレイアウトなんかも用意されていて、コードで「論文っぽい紙面」を組んでいくイメージです。
新しく始めるときは、「クリエイト・ミニタイプ」というテンプレート生成ツールを使ってプロジェクトを作って、さらにViteのプラグインと組み合わせることで、ブラウザ上でリアルタイムプレビューしながら、学会論文とかビジネスレポート、スライドなんかを作れます。「書いてビルドしてPDF開いて…」というサイクルじゃなくて、Web開発みたいなノリで組版できるわけですね。
LLMや既存のnpmライブラリとも相性がよくて、たとえばセキュリティレビューの結果を自動でレポートにするとか、旅程表や履歴書、教材を自動生成してPDF化するとか、Webのドキュメントと印刷用PDFを一元管理するといったユースケースが紹介されています。おもしろい例だと、ウィキペディアの記事を読みやすい二段組のPDFに変換するブラウザ拡張、なんていうのも挙げられていました。
著者の方は、「日本語の複雑な組版を、ちゃんと国内の技術として維持したい」という思いと同時に、「LLMやアプリケーションからの文書生成を支える共通の基盤エンジンにしたい」と語っています。テキスト生成するAIと、紙面を作るエンジンが、同じNodeやブラウザの世界できれいにつながる。これからの「自動ドキュメント生成」のど真ん中にいそうな技術ですね。 。。。
三つ目の記事は、ウェブデザインでおなじみ、「トップへ戻るボタン」のアクセシビリティの話です。
画面の右下とかに、ずーっと付いてくるタイプの「トップへ戻る」ボタン、よく見かけますよね。この記事では、その「常に画面下に付きまとっている」パターンは、アクセシビリティ上の問題を起こしやすいですよ、という指摘がされています。
具体的には、まずアイコンだけだと、スクリーンリーダーの音声読み上げで何のボタンか伝わらない、という問題があります。それから、押したときにスクロールアニメーションで、ビューンと上に戻る演出が入ると、それが原因で「めまい」や「吐き気」といった身体的な負担につながる可能性がある。
さらに、ユーザーの予想と違う戻り方をしてしまったり、画面の端っこにボタンがあるせいで誤タップが増えたり、背景の文字や、キーボードフォーカスの状態を隠してしまったりと、細かいところでいろいろトラブルの元になりやすいんですね。
ある程度は、CSSや配置の工夫でマシにできますが、そもそも、OSとかブラウザ側に「トップへ戻る」に近い機能があることも多いんですよね。たとえばホームキーを押すとか、ステータスバーをタップすると一番上に戻る、みたいな。なので、記事では「実は、トップへ戻るボタン自体の必要性が、そんなに高くない場面も多いですよ」と指摘しています。
一方で、「スクロール操作がつらい身体障害のある人にとっては、トップへ戻るボタンがありがたい」という声もちゃんと紹介されています。なので、この記事の結論は「ボタンを全部やめろ」ではなくて、「固定ボタンとか、バナー全般に共通する問題だから、本当に必要かどうかを設計段階からよく考えよう」というまとめ方になっています。
見た目としては便利そうでも、裏側でどんな人に影響が出るか、ちゃんと想像したいところですね。 。。。
四つ目の記事は、一気にセキュリティ寄りの話題で、「npmパッケージが乗っ取られて、悪意あるバージョンが複数公開されてしまったとき、どう動けばいいのか」を、初動から復旧まで、時系列で整理してくれている記事です。npm向けの内容なんですが、他のパッケージレジストリにもほぼ同じ考え方が当てはまると説明されています。
まず何より先にやるべきなのは、「侵入経路を塞ぐこと」です。たとえば、脆弱なGitHub Actionsのトリガーがあったらそれを削除するとか、npm側のトラステッド・パブリッシングの設定を見直して、古いアクセストークンを無効化するとか、とにかく「攻撃者から公開権限を奪う」のが最優先になります。
ここをちゃんと閉じないまま、表面的な対処だけしても、また悪意あるバージョンを上げられてしまう可能性がありますからね。
その次にやるのが、`latest`とか、その他のディストタグを安全なバージョンに戻してあげること。それから、汚染されたバージョンを「unpublish」で消し飛ばすのではなく、「npm deprecate」で無効化していきます。
deprecateを使うと、「バージョンレンジの解決」で、汚染された版が選ばれてしまうのをかなり防げるんですが、ピン止めされた固定バージョンとか、ロックファイルには効かないんですよね。なので、そういうケースまでしっかりケアするには、npmのマルウェア報告フォームから削除を依頼して、実際にそのバージョンにアクセスしたときに「フォーオーフォー」になるまで確認する必要がある、と書かれています。
利用者への告知もかなり重要で、「汚染されたバージョンの一覧」「安全なバージョンと、その公開時刻」「ペイロードが何をするのか」「利用者が何をすべきか、たとえばすべての認証情報のローテーションをしてください」といった情報を、はっきりと書く必要があります。
ありがちなNGとしては、「このバージョンレンジより前は安全です」と雑に書いてしまうこと。もし攻撃者が、もっと古いバージョンもこっそり汚染していた場合、利用者に誤った安心感を与えてしまうので、記事では「公開日時や、系統ごとの最後の正常版を列挙する形がいい」と説明しています。
汚染を検出する条件も、結構むずかしいポイントです。バージョン番号だけで判定するのか、インストールスクリプトの有無で見るのか、特定のファイルが入っているかどうかで見るのか。バージョンごとに手口が違う場合もあるし、`files`設定のせいで、ペイロードがtarballの外側に出てしまっている場合もあって、「どれか一つの手法だけだと見逃すかもしれない」と注意を促しています。
GitHub側の証拠保全も大事で、これは通報より前にやるべきことだと。フォースプッシュがあっても、コミットオブジェクト自体は残るんですが、プルリクのタイムラインにあるSHAの記録は、アカウントが凍結されると一緒に消えてしまう可能性があります。なので、グラフキューエルAPIでSHAを控えておいて、`git fetch`でローカルに退避する、という手順を踏んでおくのが重要だと書かれています。
攻撃者のアカウントは、GitHubの「アクティブ・マルウェア・オア・エクスプロイツ」というカテゴリで通報します。そのうえで、同じようなパターンが他のリポジトリのワークフローにも仕込まれていないか、横展開のチェックを機械的に行うことを勧めています。とくに、「issueコメント」とか「pull requestターゲット」といったトリガーと、「アイディー・トークン・ライト」の組み合わせには注意ですね。
自分のパッケージが万一乗っ取られたとき、パニックにならないための「実務マニュアル」のような記事でした。 。。。
そして五つ目、最後の記事は、GitHub ActionsのArtifactまわりの、ちょっとしたけど便利なアップデートの話題です。
AIで生成したHTMLレポートなんかを、プルリクで共有したい。でも、これまでのアーティファクトは、ジップをダウンロードして、解凍して、中のHTMLを開かないと中身が見られない。それが地味にめんどくさいよね、という問題からスタートしています。
二千二十六年の二月以降、「アクションズ・アップロード・アーティファクト・バージョンセブン」で、「アーカイブ・フォルス」という指定ができるようになりました。これを付けると、単一ファイルをジップに固めず、そのままアップロードできます。なので、HTMLや画像だったら、そのArtifactのURLを開くだけで、ブラウザに直接表示されるようになったんですね。
筆者の方は、これを活用して、CIの中で二種類のHTMLを自動生成しています。
一つ目は、プルリクのディフからAIが作ってくれる「レビューガイド」。どこがどう変わったのか、どんな観点でレビューするとよさそうか、みたいな情報をまとめてくれるレポートです。
もう一つは、「動作確認レポート」。これは、プレイライトで撮ったスクリーンショットをベースシックスティフォーでHTMLの中に埋め込んだもので、「この画面、ちゃんとこう表示されてますよ」というのを画像付きでパッと確認できるようになっています。
どちらも、ボットがプルリクのコメント欄にArtifactのURLを貼ってくれる運用にしていて、レビュアーはリンクを一回クリックするだけで中身を見られる。ジップを落として解凍して…というフローがなくなるので、レビュー体験がかなりいい感じになります。
テクニカルなところでいうと、URL自体は、アップロードステップのアウトプットとして、「ステップス・アップロード・アウトプッツ・アーティファクト・ユーアールエル」という形で取得できます。で、共有するのは、GitHub上のArtifactページのURLだけ。このページは、そのリポジトリを閲覧できる人だけが見られるように保護されています。
裏側の仕組みとしては、そのGitHubのArtifactページから、実体であるAzureブロブストレージの署名付きURLに、数分だけリダイレクトされるようになっています。この署名付きURL自体は、URLを知っていれば誰でも一時的にアクセスできるので、「こっちを直接共有しないのがポイントだよ」と記事では説明しています。
「地味だけど、毎回のレビューが確実に楽になる」系のテクですね。AIでレポートを自動生成しているチームには、かなりうれしいアップデートだと思います。
というわけで、きょうのzenncastは、全部で五本の記事をご紹介しました。
片手操作と音声入力でAIエージェントに仕事を任せる、こだわり満載の開発環境のお話。
TypeScriptで直接呼べる日本語対応の組版エンジン、ミニタイプの紹介。
「トップへ戻るボタン」が持つアクセシビリティ上の課題と、その必要性を設計段階から見直そうという提案。
npmパッケージが乗っ取られたときの、初動から復旧までの具体的な対応フロー。
そして、GitHub ActionsのArtifactをジップなしでアップロードして、AI生成HTMLレポートをそのままブラウザで見せるテクニック。
どれも、開発体験とか、安全性とか、情報の届け方を一段上げてくれる内容だったんじゃないかなと思います。
気になった記事があれば、詳しい内容はショーノートにまとめておきますので、そちらから原文にもぜひアクセスしてみてください。
この番組「zenncast」では、みなさんからの感想や、「こんなテーマを取り上げてほしい」といったリクエストも募集しています。ラジオネームを添えて、ぜひ気軽に送ってください。
それでは、きょうはこのへんで。
お相手はマイクでした。
また次回のzenncastでお会いしましょう。お仕事前の方も、一日どうぞご安全に。