どうも、おはようございます。マイクです。
時刻は朝七時を回りました。今日は二千二十六年六月二十日、土曜日。
ここからの時間は「zenncast」、Zennで今トレンドになっている記事を、ゆるっと楽しく紹介していきます。
今日はぜんぶで五本、気になる技術記事をピックアップしてきました。
それぞれ内容みっちりなので、コーヒー片手に、耳だけ貸してもらえたらうれしいです。
まず一本目。
「AWS Blocks」というフルスタックフレームワークを紹介している記事です。
これね、コンセプトが面白くて、TypeScriptでアプリを書くだけで、そのコードから必要なAWSインフラが自動で組み上がる、という仕組みになっています。
「Block」という部品をコードの中で一つ作ると、その裏側で、DynamoDBとかS三、API Gateway、さらにはBedrockといった、いろんなAWSリソースが、CDKとかCloudFormationとして自動生成されるんですね。
インフラ担当いなくても、とりあえず動く環境まで持っていけるっていうイメージです。
うれしいのがローカル開発の体験で、AWSアカウントも認証情報もいらずに、そのまま「エヌピーエム・ラン・デブ」だけで、認証もデータベースもリアルタイム通信もついたアプリが起動します。
で、同じコードを「エヌピーエム・ラン・デプロイ」とすると、そのままAWSに本番デプロイまでいけちゃう。
記事では、「Agent」と「KnowledgeBase」という二つのBlockを使って、RAG検索とツール呼び出し、それから「ヒューマン・イン・ザ・ループ」で、ちゃんと人間が承認してから実行されるサポートチャットボット、これを数十行くらいのコードで実装する様子が紹介されています。
普通だったら、BedrockのSDKを触ったり、WebSocketの実装をしたり、DynamoDBのテーブル設計を考えたり、承認フロー用にステートマシンを組んだりと、あっちこっち手を入れないといけないところが、Blocksでは「needsApproval: true」みたいな設定一つで済む、という世界観です。
おもしろいのは、アプリのコードからインフラを導き出すスタイルなんだけど、裏側で動いているのはあくまで素のAWSリソースなんですよね。
だから、必要になったらCDK側で細かくカスタマイズできる、という逃げ道もちゃんと用意されている。
「インフラは自動化したい、でもブラックボックスはいやだ」という、欲張りなフルスタック開発者には刺さるフレームワークじゃないかなと思いました。
。。，。。
続いて二本目。
デザイントークンをAIにちゃんと守らせるためのノウハウをまとめた記事です。
「AIにスタイルガイド読ませてるのに、全然ルール守ってくれないんだけど！」っていう人には、かなり実践的な内容だと思います。
ポイントの一つ目は、Design TokenをMarkdownじゃなくて、CSS変数プラスコメントで書くスタイルにしていること。
変数名は「ダブルダッシュ・ディーエス・ほにゃらら」みたいな形にして、その右にコメントで用途を書いておくことで、AIがまず変数名を見てから、横のコメントで使い道を判断できるようにして、精度を上げているそうです。
さらに、Cursorのルール機能を使って、「参照するファイルはこれ」「ハードコードは禁止」「スタイル指定するときはディーエスの変数を使う」「コメントと用途が合っているかを確認する」という手順を、ステップ・バイ・ステップで書いておく。
これによって、AIに人間と同じチェックフローを踏ませて、ダブルチェックさせているのが面白いところです。
トークンは、tokens-colorとかtokens-typographyみたいに、種類ごとにCSSファイルを分割。
AIに読ませるファイルの行数と情報量をあえて絞ることで、参照ミスとか混乱を減らしていると解説されています。
さらに大事なのが、Primitives、いわゆる生の値トークンの扱い。
ここは「原則全面禁止」とコメントしてあって、「〜など特殊なタイミングで使用」みたいなぼんやりした説明は避ける。
「使用していいのは〇〇のケースのみ。通常は△△を使うこと」という感じで、例外ルールをものすごく限定して、AIが勝手に拡大解釈しないようにしているのがポイントです。
それから、複数のCSSファイルにまたがって判断が必要な禁止事項は、prohibitionsドットエムディーという横断ルールのファイルに集約。
「どのファイルに何を書くか」をきっちり分けて、同じ内容を重複させないようにしていると。
marginやgapみたいな、入れ子構造に依存するレイアウトのルールについては、「まず子要素の最大値を調べる」「次に自分の値と比較する」「最後に親要素と比較する」といった、人間が普段やっている順番のチェック手順を、文章として明文化。
これを読ませてようやく、AIが意図通りに判断してくれるようになった、という経験談も紹介されています。
AIに「好きにやって」じゃなくて、「こういう順番でこう考えて」と、かなり細かいレベルまで手順を教える必要があるんだな、というのがよくわかる記事でした。
。。，。。
三本目は、学習サービスProgateのHTMLとCSSレッスンで使われている、Chromeの開発者ツールをそのまま画面内に埋め込んだ実装の解説記事です。
「ブラウザのDevTools、そのまま教材の中に入ってるじゃん！」っていう、あの体験をどうやって実現しているか、裏側を丁寧に説明しています。
普通の開発環境と違って、Progateみたいな学習サービスだと、レッスンのプレビューはiframeの中に表示されています。
そこでブラウザ標準のDevToolsを開くと、サービス本体のHTMLやCSSまで丸見えになっちゃうし、画面も狭くなるしで、学習にはちょっと不便なんですよね。
そこでやっているのが、Chrome DevToolsのフロントエンドをフォークして、自前ビルドしてしまう、というアプローチです。
Chrome DevTools Protocol、いわゆるCDPと、Chobitsuというライブラリを使って、本来はWebSocketでやりとりしている部分をpostMessageに置き換えることで、レッスンページ内の別のiframeと通信できるようにしています。
つまり、レッスンのページの中に、DevTools用の画面と、学習用プレビューの画面、二つのiframeがあって、その間をpostMessageでしゃべらせているイメージですね。
さらに、学習にいらない機能は思い切って削っています。
不要なタブはimport文をコメントアウトして読み込まないようにして、HTMLとCSSの学習に必要な要素パネル、スタイルパネル、コンソールといった最低限に絞り込んで、学習用にかなりチューニングしているそうです。
ビルドにはChromiumと同じくgnとninjaを使うので、セットアップもビルド時間もそれなりに重たいんですが、そのぶんカスタマイズの自由度が高い。
その結果、学習者がプロと同じDevToolsを、ほぼそのまま教材の中で触ることができる、という体験を実現できた、と締めくくられています。
「学習だから簡易版でいいでしょう」じゃなくて、「本物をどうやって安全に埋め込むか」を追求してるのが、エンジニア魂を感じる記事でした。
。。，。。
四本目。
こちらは、Apple純正のLinux仮想マシン機能「container machine」の中に、本物のDocker EngineとDocker Composeをそのまま入れて動かす手順を、最初から最後までちゃんと再現できる形でまとめたTips記事です。
ポイントになっているのが、既定のmachineカーネルにはパケットフィルタ、いわゆるnetfilterが入っていない、というところ。
そのせいで、「ドッカー・ラン・ハイフン・ピー」とか、Composeでのサービス間通信が正しく動かない問題があります。
そこで記事では、Kata Containersが推奨しているカーネルに差し替えて、netfilterを有効化する、というのが最大の山場だと説明しています。
ベースにはsystemd入りのUbuntuを使ってカスタムmachineイメージを作り、その中に「dockerドットアイオー」と「docker-compose・ブイツー」をインストール。
さらに「systemctl enable docker」で、machineの起動と同時にdockerdが自動で立ち上がるように設定します。
コンテナで公開したポートに、Mac側からアクセスするための工夫も入っています。
「container machine inspect」でmachineのIPと公開ポートの一覧を取ってきて、それをもとに「socat」で、「ローカルホストのポートからmachineのIPとポートへ」自動転送するデーモンを用意。
machineのIPが変わっても追従できるような作りになっています。
このポート転送のデーモンは、macOSの「ローカルネットワーク」権限の制限を避けるために、rootのLaunchDaemonとして常駐させる構成。
その上で、「launchctl asuser」経由でユーザーの「container」コマンドラインツールを呼び出すようにしています。
最後に、カーネルの差し替えからイメージビルド、machine作成、dockerdが立ち上がるまでの待ちも含めて、一括で実行できる冪等なセットアップスクリプトを用意。
これによって、Apple純正のCLIだけで、Docker Desktopにかなり近いCompose開発環境を、無料で再現できるよ、というまとめになっています。
「Docker Desktopはちょっと重いなぁ」とか「ライセンス気になるなぁ」という人には、かなり熱い選択肢になりそうな内容でした。
。。，。。
そして五本目。
AIエージェントのためのAgent Skill「self-improvement」を紹介する記事です。
名前の通り、エージェント自身が学びを蓄積して成長していくためのスキルですね。
このスキルは、ユーザーからの指摘とか、エラー対応、機能要望といった、会話の中で生まれた「学び」を検知して、それを「ドット・ラーニングス」以下のMarkdownファイルとして、構造化して保存してくれます。
ポイントは、この学びのメモが、アプリケーションのコードと同じリポジトリに自動で溜まっていくこと。
あとは普通にコミットしてプッシュしておけば、チーム全員と、複数のエージェントの間で、その知見が共有される仕組みになっています。
記録された生ログは、同じパターンの話題が何度も出てくるようになった段階で、「エージェンツ・ドット・エムディー」とか、プロジェクトの規約に昇格させる。
そうすることで、「とりあえず記録はゆるくどんどん残す、でもルールとして正式に書くのは、ほんとに必要なものだけ」という運用ができると紹介されています。
導入もシンプルで、CLIからスキルを追加して、「ドット・ラーニングス」ディレクトリを用意するだけ。
依存ライブラリも特に必要なくて、やっていることはローカルにMarkdownを追記していくだけなので、安全性も信頼性も高い、と説明されています。
特に、日常的にエージェント開発をしている人とか、チームでエージェントの設定を共有している現場、あとは暗黙知が多いプロジェクトなんかにはハマりやすそうです。
「教えたことが、セッションをまたいでも蒸発せずに、チームの資産として積み上がっていく」――そんなエージェント体験を実現する仕組みとして、かなりおすすめされていました。
というわけで、今日は五本の記事を紹介しました。
ざっとおさらいすると、
TypeScriptのコードからAWSインフラを自動で組み上げる「AWS Blocks」のフルスタックな世界。
それから、CSS変数とコメント、Cursorのルールを駆使して、AIにデザイントークンをちゃんと守らせる工夫の話。
三つ目は、ProgateがChrome DevToolsをほぼそのままレッスン画面に埋め込むために、CDPやChobitsuを使ってカスタムビルドしている裏側。
四つ目は、Apple純正のcontainer machineの中にDocker EngineとComposeを入れて、カーネル差し替えやsocatのポート転送で、ほぼDocker Desktop相当の環境を作るTips。
最後五つ目が、学びをMarkdownとして「ドット・ラーニングス」に貯めて、エージェントとチームが一緒に成長していく「self-improvement」スキルのお話でした。
気になった記事があったら、詳しい内容や元の記事へのリンクは、ショーノートにまとめておきますので、そちらもぜひチェックしてみてください。
番組への感想や、「こんなテーマを取り上げてほしい」といったリクエストも、どしどしお待ちしています。
それでは、今日の「zenncast」はこのへんで。
お相手はマイクでした。
また次回、お耳にかかれるのを楽しみにしています。ありがとうございました。