どうも、マイクです。おはようございます。
六月二十四日、水曜日の朝七時をまわりました。「zenncast」今日も元気にお届けしていきます。
この時間は、技術コミュニティ「Zenn」で今トレンドになっている記事を、ラジオ感覚でさらっとキャッチアップしていくコーナーです。通勤・通学のおともに、コーヒー片手に、ゆるっとお付き合いください。
今日はお便りはお休みということで、そのぶん記事紹介をみっちりやっていきます。
さて、きょう紹介する記事は全部で、五本です。
テスト設計をAIに任せる工夫、自宅のラズパイを安全にインターネット公開する方法、AIとのコンテキスト管理テク、OLAPとOLTPを統合する次世代アーキテクチャ、そして最後はCSSまわりの最新事情とTailwindとの付き合い方まで、幅広くご紹介していきます。
まず一本目。
一つ目の記事は、「テスト設計をAIにどう任せるか」という、かなり実務寄りの内容です。
筆者は、Claude Codeにテスト設計を手伝ってもらう中で、「毎回クオリティにばらつきが出る」「観点漏れが怖い」という問題にぶつかったそうです。そこに対して編み出したのが、七人の意地悪なQAペルソナを組み込む、というアイデア。
この七人がなかなかおもしろくて、
新人ユーザー、ベテランユーザー、悪意ある操作者、データベースの整合性を監査する人、データ移行担当、回帰テスト担当、そして仕様を疑いまくる仕様懐疑者、という七つの役割を用意します。
AIにテスト観点を出させるときに、「この七人それぞれが、必ず少なくとも一個はチェック観点を出すこと」と指示しておくことで、「あ、ここ見るの忘れてた」という穴をふさぐわけですね。
さらに、テストケースの出力フォーマットもきっちり決めています。
二十五列のテストケースCSVに固定して、品質特性はISO二五〇一〇を意識してラベル付け。プラスで、「どの課題チケットから来た仕様なのか」「どのヘルプ記事・一次情報にひもづくのか」といった、根拠のリンクを必須にします。
これによって、なんとなく雰囲気で書かれたテストではなく、「このテストは、この仕様の、この情報源を守るために存在する」という筋の通ったケースだけが残るようにしているんですね。
テストケースの管理方法も工夫されています。
正本はリポジトリ内で二層管理しておいて、スプレッドシートはそこから派生させる形。こうすることで、スプレッドシートだけが更新されてリポジトリは放置、みたいな「ドキュメントの陳腐化」を防ぎます。
そして立ち位置もはっきりさせています。AIは「テスト設計者」、人間は「実行者であり合否のジャッジをする人」。
AIに丸投げではなく、「観点を洗い出してもらう」「仕様からブレない設計をしてもらう」、そこまでをAIに担当してもらい、実際に動かしてバグを見つけるところは人間がやる。
一人QAでも安定した品質を出すための、AIとの役割分担の仕組みとして、かなりよく出来た事例だなと感じました。テスト設計がつらい…という方には刺さりそうな記事です。
。。。。
続いて二本目。
二つ目は、Raspberry Pi上で動いているWebアプリを、できるだけお金をかけず、でもある程度安全にインターネットへ公開する方法をまとめたTips記事です。
やっていることをざっくり言うと、「Cloudflare Tunnelを使って、自宅のラズパイを外からHTTPSで見られるようにする」という内容です。
まず事前準備として、無料プランでCloudflareアカウントを作って、自分のドメインをCloudflare管理にしておきます。
次に、Raspberry Pi側。ラズパイにDockerをインストールして、Cloudflare Tunnel用のコンテナを、ネットワークモードをホストにして起動します。
この `--network=host` の指定によって、トンネル用コンテナがラズパイ本体のネットワークをそのまま使えるようになるんですね。
公開したいWebアプリ、この記事ではASP.NET Coreのサンプルアプリを例にしていて、これもDockerコンテナとして立ち上げます。ラズパイのポート、たとえば八千番ポートで待ち受けておくイメージです。
ここまで準備したら、Cloudflareのダッシュボード側で「ルート追加」から「公開アプリケーション」を選びます。
そこで、使いたいサブドメインと、ラズパイ上のサービスのURL、たとえば「ローカルホストの八千番ポート」をひもづけます。
すると、インターネットからは、そのサブドメインにアクセスするだけで、Cloudflare Tunnel経由で自宅のラズパイに届き、しかも証明書付きのHTTPSで安全にアクセスできるようになる、というわけです。
さらに一歩進めて、Cloudflare Accessを使うと、認証もCloudflare側でかけられます。
自分のCloudflareアカウントでログインしたユーザーだけがアクセスできるようにするとか、そうした制限を、ラズパイ側に複雑な仕組みを用意しなくても、比較的簡単に設定できるのがポイントです。
自宅サーバーを公開したいけど、ポート開けるのは怖い…とか、SSL証明書どうするの…と悩んでいる方には、かなり実用的な手順がまとまっている記事になっていました。
。。。。
三本目。
三つ目の記事は、Claude Codeとの付き合い方、特に「コンテキスト管理」をどう工夫するか、というTips系のお話です。
一つのセッションの中に、実装も調査もメモも全部詰め込んでしまうと、履歴が長くなりすぎて精度が落ちる、どこで何を話していたか分からなくなる、という経験、ある方多いと思います。
そこで筆者がやっているのが、tmuxのタブを「一タブ＝一つの関心事」として分けてしまう、という方法です。
たとえば、アプリ開発用のタブ、レポート生成用のタブ、検証用のタブ、みたいに目的ごとに分離して、それぞれ別のClaude Codeインスタンスを動かします。
こうすることで、アプリ開発の会話にレポートの履歴がまざる、といったコンテキスト汚染を防げる、という発想ですね。
さらに面白いのが、「まとめ役のタブ」を一つ用意しておくこと。
このオーケストレータ的なタブは、他のタブから「done」「summary」「next」みたいな、すごく短い要約レポートだけを受け取ります。
あえて詳細なログは持たず、「今どこまで進んだか」「次に何をさせるか」だけを握って、各タブに指示を出していく。
つまり、一つの巨大なチャットログに全部溜め込むのではなく、タブごとに詳細を保持して、まとめ役はダイジェストだけを見る、という構成です。
タブ同士のやりとりもルール化されています。
`tab:ask` は質問、`tab:share` は情報共有、`tab:request` は依頼、みたいに、決まった形式の短いメッセージだけを送るようにして、全文ログをそのまま投げ合わないようにする。
これにより、どのタブが何をしているかは把握しつつ、コンテキストをムダに圧迫しないようにしているわけですね。
また、長い作業だと、AI側で「履歴を圧縮しますね」といったコンパクト機能が走ることがありますが、それで会話の文脈が消えても迷子にならないように、進行中のタスクは `todo.md` というファイルに、手順と進捗を人間側で残しておきます。
コンテキスト外、つまりファイルとして「今、ここまで進んだ」という状態を保存しておくことで、いつでも再同期が取れるようにしている、というわけです。
最後に、監視スクリプトも用意していて、各タブの状態やコンテキスト使用率を定期的にチェック。
「どのタブが詰まっているのか」「どのタブが履歴の限界に近いのか」を一覧で把握できるようにしているそうです。
AIを本格的にワークフローに組み込みたい人には、かなりヒントが多い記事でした。
。。。。
四本目。
四つ目は、データ基盤の世界の新しいアーキテクチャ、「LTAP」を紹介するサービス紹介系の記事です。
キーワードは、OLAPとOLTPの統合、そして「一つの物理データを共有する」という考え方です。
LTAPでは、Databricksの分析基盤であるLakehouse、これはOLAP側ですね。それと、トランザクションデータベースのLakebase、こちらがOLTP側。
この二つが、DeltaとかIcebergといったオープンなテーブル形式の、一つの物理データを共有する仕組みを提供します。
従来はどうしていたかというと、アプリケーションのトランザクションDBから、分析用のDWHにデータを持っていくために、CDC、いわゆる変更履歴を読んで同期する仕組みや、ETLパイプラインを組んでいました。
そこにはデータコピーが発生して、同期が遅れたり、バッチが落ちたり、といったコストとリスクがどうしてもついて回ります。
LTAPでは、この「データをコピーして同期する」という前提を壊しにいっています。
内部的には、PostgresベースのLakebaseの書き込みログを、Mooncake Labs由来の技術などを使って、高速に列指向フォーマット、つまりParquetプラスDeltaやIceberg形式に変換して保存します。
これによって、トランザクション処理側の性能は保ちつつ、そのまま分析側からも参照できるようにしているんですね。
ポイントは、コンピュート、つまり処理エンジン自体はOLTPとOLAPで分けたままにしておいて、ストレージだけを共通化しているところです。
これまでのHTAP製品って、「一つのエンジンでOLTPとOLAP両方をこなします」というアプローチが多く、そのぶん性能面で妥協が必要になったり、ベンダーごとの専用フォーマットにロックインされたり、という課題がありました。
LTAPは、「処理は用途に合わせて別々、でもデータはオープンな形式で一つに」という構え方をとることで、そういった性能面の妥協やベンダーロックインを避けた、新しい選択肢になっている、というわけです。
リアルタイムに近い形でトランザクションと分析をつなぎたい、でもアーキテクチャをシンプルに保ちたい、というニーズに応える構想として、とても興味深い内容でした。
。。。。
そしてラスト、五本目。
五つ目は、CSS周りの話題で、筆者の考えと経験を語っている記事です。
テーマとしては、「標準CSSがここ数年でかなり進化したので、SassやTailwindに頼っていた理由の多くは、もう標準だけで解決できるんじゃないか？」という話ですね。
最近のCSSでは、ネスト構文が使えるようになってきたり、疑似クラスの `:has()`、`:is()`、`:where()`、それからカスタムプロパティ、いわゆるCSS変数ですね、こういった機能が充実してきました。
その結果、以前は「これがないからSassが要る」「Tailwindを使わないとつらい」と言っていた部分のかなりの割合が、標準CSSだけでカバーできるようになってきた、と筆者は指摘しています。
一方で、TailwindやDaisyUIそのものも、ちゃんと評価しています。
ユーティリティファーストという考え方で、細かいクラスを組み合わせてデザインしていくスタイル。
それから、分かりやすいクラス名や充実したドキュメントのおかげで、結果的にCSSの理解が深まった、というポジティブな側面もあると書かれています。
ただし、デメリットとしては、ユーティリティクラスが増えすぎてHTMLが読みにくくなったり、「見た目を変えるためにHTMLそのものをいじる」という状態になりがちな点を挙げています。
これは、単一責任の原則から考えると、HTMLは構造を表すものであって、見た目のロジックを過度に持たせるのは違うんじゃないか、という違和感ですね。
そこで筆者が推しているのが、「今の標準CSSを前提にして、ネスト構文とカスタムプロパティを活用しよう」というスタイルです。
特に、Open PropsのようなCSS変数集と組み合わせれば、デザイントークンを変数として扱いつつ、HTMLはすっきりきれいなまま保てる。
それでいて、テーマ変更や調整にも柔軟に対応できるので、「Tailwindを絶対に使わなきゃ」という状況は、もはやかなり薄くなってきているんじゃないか、という立場が示されています。
CSSをこれからちゃんと学び直したい人や、「結局Tailwindでいいの？」「いや、純CSSでいくべき？」と悩んでいる方には、バランスのいい視点をくれる記事だと思いました。
。。。。
というわけで、きょうの「zenncast」でご紹介した記事を、駆け足でおさらいしておきます。
まず一つ目は、七人の意地悪なQAペルソナをAIに組み込んで、テスト設計の観点漏れを防ぎつつ、ISO二五〇一〇や一次情報へのひもづけで、根拠あるテストケースを作る工夫のお話。
二つ目は、Cloudflare TunnelとDockerを使って、Raspberry PiのWebアプリを、安価で比較的安全にHTTPS公開する手順の記事。
三つ目は、tmuxのタブを一タブ一関心事として分けて、オーケストレータタブや `todo.md` を駆使しながら、Claude Codeとのコンテキスト管理を最適化するTips。
四つ目は、DatabricksのLakehouseとLakebaseが、DeltaやIcebergといったオープンなテーブル形式の一つの物理データを共有する、LTAPというOLAP／OLTP統合アーキテクチャの紹介。
そして五つ目は、ネスト構文や `:has()` などの登場で大きく進化した標準CSSと、Tailwindとの付き合い方を見直そう、というCSS談義でした。
気になった記事があれば、詳しい内容はこの番組のショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。
番組の感想や、「こんな記事を取り上げてほしい」といったリクエストも、いつでもお待ちしています。あなたのフィードバックが、この「zenncast」をもっとおもしろくしてくれます。
それでは、そろそろお時間です。
ここまでのお相手はマイクでした。
次回の「zenncast」で、またお会いしましょう。いってらっしゃい。