どうも、マイクです。
今朝も「zenncast」お届けしていきます。今日は二〇二六年八月二日、日曜日の朝七時台ですね。みなさん、いかがお過ごしでしょうか。これから、Zennで今日トレンドになっている記事を、まとめてご紹介していきます。
今日は全部で五本、ご用意しています。エンジニアリングとUI、それからAI活用まで、けっこう幅広いラインナップです。
まず一つ目。
最初は「CLI を AI にとって使いやすくするにはどうするか？」というお話です。
ポイントになっているのは、コマンドラインツールを、AIエージェントが自力でちゃんと理解して使えるようにしておこう、という発想なんですね。
よく、AIにツールを触らせるときって、なんでもかんでもウェブ検索とかウェブフェッチに頼りがちなんですけど、これ、効率が悪いし、要約を間に挟むことで大事な情報がこぼれ落ちちゃう、という問題があります。
そこで筆者は、「正しいドキュメントに、確実にたどり着けるようにしておく」ことがすごく大事だと説明しています。
具体的には、`--help` のヘルプメッセージとか、ログ、エラーメッセージの中に、「coding agent 向け」の案内をあえて書いておきます。
たとえば、「詳しくは `ghtkn docs list` とか `ghtkn docs show <name>` を実行して読んでね」といった感じで、ドキュメントを読むための専用コマンドに誘導してあげる。
さらに、対話が必要なコマンドについては、「ここは人間に実行してもらってください」と明示しておいたり、シークレットキーが出てしまう可能性があるコマンドには、ログの中で「出力をチャットにコピペしないで」「渡すなら環境変数経由にして」といった注意も書いておくわけです。
ドキュメント自体も工夫されています。
CLI と同じリポジトリの中に、マークダウン形式で置いておいて、トピックごとにファイルを分割しておく。で、その各トピックの description を「エージェント向けの説明」として書くんですね。
それを Go の `embed` 機能を使って、CLI のバイナリの中に埋め込んでしまって、`docs list` と `docs show` というサブコマンドで一覧と本文をいつでも出せるようにする。そうすると、ツールのバージョンと、読ませるドキュメントのバージョンを常に揃えられる、というメリットがあります。
さらに、README、`--help`、`--version` の出力など、とにかくあらゆる入り口から、この `docs` コマンドへの導線を張ります。そうすると、AI がどこからツールに入り込んできても、最終的にドキュメントにたどり着ける、という状態になる。
エージェント用のスキルも、「一つのツールにつき一つ」に絞って、そのスキルの中では `docs` コマンドだけを呼ぶようにしておくことで、バージョンずれとか、メンテナンスの手間を減らしている、という話です。
実際にエージェントに使わせてみると、最初はいつものクセでウェブフェッチをしようとするんですが、`ghtkn --help` を見たタイミングで `docs` コマンドの存在に気づいて、そこからは `ghtkn docs list` や `ghtkn docs show` を自律的に使い始める、という動きが確認できたそうです。
筆者は、こうした工夫をしておくことで、ユーザーがAI経由でツールを触るときにも問題解決がしやすくなるし、メンテナ側のサポート負荷もぐっと下げられる、とまとめています。AIエージェント前提でCLIを設計する、っていう新しい視点が面白いですね。
。。.。。.。.
続いて二つ目。
今度は GitHub の「スタック型プルリクエスト」の話題です。
GitHubが公式機能として提供を始めたこのスタックプルリクは、「大きな変更を、そのままドーンと一つのPRにしないで、順番付きの小さなPRの束として扱いましょう」という仕組みです。
それぞれのPRは、一つ下のPRとの差分だけを含むようになっているので、「どこで何を変えたか」が追いやすくなります。レビューもやりやすいし、あとから変更履歴を追うのもすごく楽になる、というわけですね。
CLI で使うときは、まず `gh extension install github/gh-stack` で拡張を入れます。
その上で、`gh stack init`、`gh stack add`、`gh stack submit` というコマンドを使って、ブランチとPRをまとめて作成していける仕組みになっています。
そして `gh stack sync` を使うと、スタックの一番下の層から順番に、自動でリベースして、プッシュまでやってくれる。
これまでは、スタック状にブランチを積み上げて開発している人って、手作業でリベースして、時にはフォースプッシュして…っていう、なかなか神経を使う作業をしていたと思うんですけど、その部分の手間が大きく減らせます。
さらに面白いのが、`gh skill install github/gh-stack` でスキルを入れておくと、Claude Code や Codex みたいなAIエージェントに対して、「この変更をスタックPRで作って」「全部リベースしておいて」みたいに、自然言語でお願いできる点です。
AIエージェントの時代になると、一つのプロンプトでどんどんコードを書いていって、気づいたら巨大なPRになってしまう、という問題が増えがちなんですが、それをこのスタックPRと `gh stack` コマンドで、細かく整理されたレビュー単位に分解してあげられる。
筆者は、そこがこの機能の面白さであり、重要なポイントだとしています。AIと組み合わせる前提で、PRの粒度をどうやって保つか、っていう発想が、時代だなあという感じがしますね。
。。.。。.。.
三つ目の記事は、ちょっと趣を変えてオピニオン系。
タイトルとしては、Rich Hickey の有名な講演「Simple Made Easy」の考え方を、UIやUXの世界に当てはめて考えよう、という内容になっています。
ここでキーワードになるのが、「シンプル」と「簡単」は違う、という話です。
この文脈での「シンプル（Simple）」は、構造が絡み合っていないこと。つまり、要素同士がごちゃごちゃと編み込まれていなくて、どこを見れば何がわかるかが、はっきりしている状態。
一方で、「簡単（Easy）」は、馴染みがあって、すぐに使える、わかりやすく感じる、という意味。
この二つ、ついついごっちゃにしちゃいがちなんですが、実は別物なんだよ、という指摘です。
UIの世界だと、どうしても「見た目をできるだけ少なくする」「直感的に見せる」「ワンクリックで済ませる」「自動でいい感じにやってくれる」…みたいな「イージーさ」を追い求めがちです。
ところが、その結果として、エクセルのセルみたいに、一つの場所にたくさんの意味や状態を詰め込んでしまうことがあります。
そうすると、「使い始めは簡単に見えるんだけど、内部的にはとても複雑で、成長するほど変更が怖くなり、誰もきちんと読めない・触れないUI」になってしまう。筆者はこれを「EasyだけどComplex」、そして最終的にはHardな状態に向かってしまう、と表現しています。
この落とし穴を避けるために、記事の中では六つの指針が紹介されています。
ざっくりいうと、一要素一役割にすること。
画面を、大きな一枚岩としてではなく、部品やステップに分けて組み合わせること。
状態は隠さず、画面やURLにきちんと表現して見せること。
同じ操作はいつも同じふるまいをするようにして、一貫性を保ち、ユーザーが挙動を予測できるようにすること。
こういった考え方ですね。
そして最後のまとめとして、「UIの複雑さは自然発生するものではない」と言っています。
設計者が、新しい概念を一つ編み込むたびに複雑さが増えていく。だから常に、「これは何と何を絡めているのか？」と問い続ける必要がある。
目先のEasyさ、たとえば「なんか便利そう」「ワンクリックでできたらかっこいい」といった魅力に引きずられて、構造を壊していないか？を意識しながら設計していくことが、大事なんだ、という主張でした。
UI設計をやっている方には、刺さるところが多い話だと思います。
。。.。。.。.
四つ目の記事は、Web Streams API の解説です。
まず「ストリームとは何か？」から丁寧に説明してくれています。
ストリームというのは、データを大きな塊としてどかっと扱うんじゃなくて、小さなチャンクの連続として順番に扱っていく仕組みのことです。
これによって、メモリをあまり使わずに済むし、届いた順にすぐ処理できるので、リアルタイム性も上がる、というメリットがあります。
Web Streams API は、このストリームの考え方を、ブラウザと Node.js で共通に扱えるようにした標準APIです。
基本になるのは三種類で、「読み取る側」の `ReadableStream`、「変換する側」の `TransformStream`、「書き込む側」の `WritableStream`。
この三つをパイプでつないでいくことで、一連の処理を組み立てていきます。
例えば、`fetch` で取ってきたレスポンスの `Response.body` を `ReadableStream` として扱ったり、`TextDecoderStream` でバイナリからテキストへの変換をかませたり、最後はファイルへの書き込みに流したりといった組み合わせができます。
そうすると、大きなJSONLファイルのインポートとか、LLMのストリーミング応答をリアルタイムで画面に出していく処理なんかを、「全部メモリに展開しなくても」書けるようになるわけですね。
中身としては、「内部キュー」と「背圧（backpressure）」の仕組みがあって、処理が追いつかないときは、自動的に上流の流量を絞ってくれます。
キューのサイズは `highWaterMark` といったパラメータで制御できるので、「どのくらいまでなら溜めておいてよいか」を調整可能です。
また、Promise / async / await との相性も良くて、`pipeTo()` でストリーム同士をつないだ結果が終わるのを `await` したり、`for await ... of` 構文でチャンクを一つずつ反復処理したり、`ReadableStream.from()` で普通のイテレータからストリームを生成したりできます。
Node.js にも昔から独自の Stream がありましたが、それと比べると、インターフェースや型、安全なエラーハンドリングの面でWeb Streams APIのほうが改善されている部分が多い、と記事では紹介しています。
さらに、Node.js 独自のストリームとの互換変換として `toWeb` と `fromWeb` も用意されているので、既存コードとの橋渡しもできます。
筆者は、「これから新しく書くコードについては、Web Streams API を前提にしておくのがいい」と述べています。
ブラウザとサーバーの両方で同じモデルを使えるので、長期的に見てメリットが大きいよ、というお話でした。
。。.。。.。.
そして最後、五つ目の記事です。
テーマは「GitHub Copilot Chat の会話ログを、丸ごときちんと保存したい」という話です。
今の Copilot Chat には、会話全体をそのまま一括保存する機能がないんですね。
そのため、残しておきたいやりとりがあったときは、一メッセージずつ手でコピーしていくか、最後にAIに要約を出してもらうしかない、という状況になっています。
ところが、要約に頼ると、細かいニュアンスがどうしても失われてしまう。ここが困るポイントだと、筆者は説明しています。
一応、Microsoft Graph の監査用APIを使ってログを吸い上げるとか、ブラウザ拡張を入れる、といった方法もあるにはあります。
ただ、企業環境だと権限の問題やセキュリティポリシーの制約が厳しくて、そういう仕組みを簡単には導入しづらい。
そこで筆者が選んだのが、「インストール不要」「コードが丸見え」「データが外に出ない」という条件を満たす、ブックマークレット方式です。
この記事では、Copilot Chat のウェブ版で使える、ジャバスクリプト一行のブックマークレットが紹介されています。
これをブラウザのお気に入りに登録しておいて、Copilot Chat の画面を開いた状態でクリックするだけで、会話全体を「You」と「Copilot」ごとに見出しを付けたマークダウンファイルとして、自動でダウンロードしてくれる、という手順が解説されています。
仕組みとしては、画面に表示されている要素、いわゆるDOMを、上から下まで自動でスクロールしながら読み取っていきます。
それぞれの吹き出しについて、「You said:」「Copilot said:」といった読み上げ用のラベルを手がかりに、どちらの発言かを判定していきます。
そして最後に、Copilot が出してくる「おすすめの質問」みたいな、おまけの部分だけは削除してから保存するようになっているそうです。
この記事の面白いところは、「なぜこの方法で動くのか」を丁寧に説明している点です。
DOM をどう読み取っているのか、どこを見て発言者を判断しているのか、どの部分を除外しているのか、といったロジックを理解しておけば、もしCopilotのUIが将来変わってしまっても、自分でブックマークレットのコードを少し直して対応できる。
単なる「便利スクリプトの配布」ではなくて、「仕組みを理解して、自分の環境に合わせて調整できるようになろう」というメッセージになっているのが印象的でした。
。。.。。.。.
ということで、今日は五本ご紹介しました。
AIにとって使いやすいCLI設計の話から、GitHubのスタック型プルリクエスト、UIにおける「シンプル」と「簡単」の違い、Web Streams API のストリーム処理、そしてCopilot Chatの会話ログをブックマークレットで丸ごと保存する方法まで、けっこう駆け足でお届けしましたが、気になるトピックはありましたでしょうか。
詳しい内容やキーワードは、番組のショーノートにも載せておきますので、気になった記事があった方は、ぜひそちらから元の記事もチェックしてみてください。
この「zenncast」では、番組の感想や、取り上げてほしいテーマのリクエストも大歓迎です。日々の開発で感じている悩みや、気になっている技術トピックなど、ぜひ気軽に送ってください。
それでは、そろそろお別れの時間です。
今日も聞いてくれてありがとうございました。次回の配信で、またお会いしましょう。マイクでした。