どうも、おはようございます。朝7時を少し過ぎたところでしょうか。3月24日、火曜日の朝です。今日もzenncast、パーソナリティのマイクがお届けしていきます。これから、Zennで今トレンドになっている記事を、ゆるっと楽しく、でも中身はガッツリめに紹介していきますので、通勤中の方も、作業のお供の方も、最後までお付き合いください。
今日はですね、全部で5本の記事をご紹介していきます。AIとの付き合い方から、フロントエンドのちょっとした落とし穴、開発ワークフローの新しい型、そしてUnityのECSまで、わりと幅広いラインナップです。順番にいきましょう。
まず1本目。「Claude Codeに長期記憶を持たせたら、壁打ちの質が変わった」という記事です。
みなさん、AIと話してて「毎回同じ説明してるな…」って思うことありませんか？セッションが切り替わると、前回どこまで話したかとか、どんな議論をしたかを、また一から説明し直すあの感じですね。この記事の著者の方もまさにそこに課題を感じて、自分で「sui-memory」という記憶エンジンを作っちゃった、というお話です。
ポイントは、「静的な前提」と「動的な会話の履歴」をきっちり分けているところ。技術スタックとかルールみたいな変わらない情報はCLAUDE.mdにまとめておいて、一方で「こういう案は前に却下したよね」とか、「前回こんな失敗をしたよね」といった“生きた履歴”は、SQLiteに長期保存しておきます。この会話ログを、日本語特化の埋め込みモデルでベクトル検索しつつ、FTS5のキーワード検索も組み合わせて、RRFっていう手法で統合してあげる。さらに時間減衰もかけることで、「最近の、かつ、いま必要そうな文脈」をサッと取り出せるようにしているんですね。
おもしろいのが、あえてLLM要約を使わない設計にしているところ。トークン消費ゼロ、外部サービスに依存しない、セッション終了時に自動保存する――このミニマムな方針で、約1900セッション・7000件超の記憶から100ミリ秒で検索できるようにしているそうです。その結果、「また同じ話を最初から」ではなく、「前回の結論の続きから」議論できるようになってきた、と。AIを“継続的な壁打ち相手”として育てたい人には、かなり刺さる内容だと思います。
。。。。
続いて2本目。「適用されていないCSSを検出するChrome拡張を作った」という記事です。
CSSって、書いてもエラーが出ないがゆえに、「実は効いていないプロパティ」がけっこう紛れ込みますよね。インライン要素にwidthを書いていたり、position: staticなのにz-indexだけ設定していたり、flexでもgridでもないのにgapを指定していたり…。ブラウザは黙って無視してくれるんですが、そのせいでスタイルシートがどんどんノイズまみれになっていく。
この記事の著者は、そういう「効いてないCSS」を検出するChrome DevTools拡張「CSS Noop Checker」をOSSとして公開しています。DevToolsのElementsタブにサイドバーとして出てきて、要素ごと、あるいはページ全体をスキャンして、「何が・なぜ・どう直すべきか」を教えてくれる。ルールは45本以上あって、「この状況でこのプロパティは意味ないよ」「こう書き換えるといいよ」みたいなところまで面倒を見てくれるわけですね。
さらにおもしろいのが、これをMCPサーバー経由でClaude Codeからも使えるようにしている点。LLMに「このページのNoopなCSS洗い出して、直し方も提案して」といった依頼ができるようになっているわけです。実装の工夫としては、検出ルールをChrome APIと切り離した“純粋関数”として書いてあって、テストしやすく、他の人もルール追加しやすい設計になっている。ユニットテストに加えて、Playwrightで実ブラウザのgetComputedStyleとの整合を見るE2Eテストまで揃えているという、かなり本気のツールです。導入も、リポジトリをcloneしてbuildして、distフォルダをChromeに読み込むだけなので、CSSをよく触る方は一度試してみる価値ありそうです。
。。。。
3本目は、「GitHub Copilot CLIでSuperpowersスキルを導入してみた」という記事です。
これは、AIコーディングエージェント用の「Superpowers」というスキルライブラリを、GitHub Copilot CLIとVS Code拡張の両方でどう使うか、その体験レポートになっています。Superpowersって何をしてくれるかというと、テスト駆動開発や体系的なデバッグ、設計のブレストといった「良い開発の型」をスキルとして定義して、自動でトリガーしてくれる仕組みなんですね。
Copilot CLIの場合は設定がとても簡単で、`/plugin marketplace add` と `/plugin install` の2コマンドで導入完了。そこから、自律的なワークフローとか、質問ツールなんかも、わりと安定して動いてくれるようです。一方で、VS Code拡張側はまだプラグイン機構がなくて、CLIが配置したスキルフォルダを `chat.agentSkillsLocations` に手動で設定してあげる必要がある。さらに、自律的に質問ツールを使ってくれるかというと、そこはまだ不安定で、「こういうスキルを使ってほしい」と明示的に指示してあげたほうがいい、という感想でした。
記事の結論としては、「Superpowersをフルに活かすならCopilot CLIがメイン」「設計やプランニングはCLIで、細かい編集や日常的なコーディングはVS Codeで」といった使い分けが良さそうだ、というお話です。ターミナル駆動でAIと対話しながら、設計プロセス自体を型にはめていく、というワークフローに興味がある方には、イメージが付きやすい内容になっています。
。。。。
4本目は、「仕様駆動開発スターターキットを公開しました」という記事です。
ここでは、「人が仕様を決める」「AIが実装とドキュメント更新を担当する」というワークスタイルを、既存プロダクトに導入するためのスターターキットが紹介されています。いわゆる「仕様駆動開発」を、現実のプロダクトに無理なく持ち込むためのパッケージですね。
このキットには、大きく2種類のスキルが用意されています。ひとつは、プロダクトのコードベースを自動解析して、要求定義から開発ガイドラインまで、6種類の“永続ドキュメント”を生成するスキル。もうひとつは、個別機能ごとの要件・設計・タスク・テストを書き出してくれるスキルです。導入のステップもシンプルで、スキルをプロジェクトにコピーして、所定のコマンドを流し、CLAUDE.mdにルールを追記するだけでスタートできるようになっている。
おもしろいのは、「テストはあくまで人間が手動で確認する」というスタンスをちゃんと明示しているところです。AIはドキュメントとコードの整合性を保つとか、変更に伴う影響範囲をテキストとして洗い出すところが得意なので、そこを任せる。一方で、挙動の最終確認は人間がやる。ドキュメントもいきなり完璧を目指さず、段階的に充実させていく前提で設計されています。前回の記事がコンセプトや個別実装の話だったのに対して、今回は技術スタックに依存しない汎用パッケージとして公開された形で、「まずはこのキットを試して、フィードバックください」という呼びかけで締められていました。既存プロダクトで「仕様と実装がだいぶ離れてきたな…」と感じているチームは、導入のヒントになりそうです。
。。。。
そして最後、5本目。「Unity: ECS の性能を引き出すデータ設計の勘所」という記事です。
UnityのEntities 1.0以降、本格的にECSアーキテクチャを使っていこう、という流れが強くなっていますが、その性能をちゃんと引き出すには、データ設計の考え方をガラッと切り替える必要があります。この記事は、その「ECS脳」への切り替えどころをコンパクトにまとめた内容になっています。
ECSの基本は、「ArchetypeごとにChunkに連続配置されたstructコンポーネントを、Systemがまとめて処理することでキャッシュ効率と並列性を稼ぐ」という考え方。でもその代わり、抽象化や継承構造には弱いし、Archetypeが細かく分散してしまうと、かえってパフォーマンスが落ちることもある。記事では、性能を出すための具体的なコツとして、いくつかのポイントが紹介されています。
まず1つ目は、有効／無効の制御の仕方。頻繁にオンオフする状態を、コンポーネントの追加・削除で表現してしまうと、Archetypeがコロコロ変わって構造変化コストがかさんでしまう。そこで、IEnableableComponentやTag Componentを使い分けて、できるだけ構造変化を減らそう、という話です。次に、コンポーネントのサイズとレイアウト。フィールドの順番や、同居させるコンポーネントの組み合わせを工夫して、Chunk内の密度を高めつつ、クエリを最小限に抑える。それでも重たいデータが混在するなら、別のEntityに分ける、といった設計が推奨されています。
さらに、IJobEntityやIJobChunkを使ったChunk単位の並列処理、ジョブのDependency管理、Systemの実行順序をチューニングすることで、待ち時間を減らすテクニックも紹介されています。Managed Componentはどうしてもキャッシュ局所性が悪くなるので、アクセスは短くまとめて、必要なときだけUnmanaged側にコピーして、Burst/Jobで重たい処理を走らせる、といった運用もポイントです。最後に、Archetypes Windowで実際の配置を可視化しながら、MonoBehaviourとの併用や計測を通じて、「どこまでECSを使うのが妥当か」を見極めるべきだ、という結論で締めくくられていました。Unityで大規模・高性能なゲームやシミュレーションを作りたい方には、設計の指針としてかなり役立つ内容です。
。。。。
というわけで、今日は5本の記事を駆け足でご紹介してきました。
Claude Codeに長期記憶を持たせて、前回の議論の“続き”から話せるようにしたお話。効いていないCSSを検出するChrome拡張で、スタイルのノイズを減らす取り組み。GitHub Copilot CLIとSuperpowersで、AIに「開発の型」を覚えさせる試み。仕様駆動開発スターターキットで、人が仕様・AIが実装という分業を現実プロダクトに持ち込む話。そして最後に、Unity ECSで性能をきちんと引き出すためのデータ設計の勘所。どれも、「人とAI」「設計と実装」「性能と抽象化」といったバランスの取り方がテーマになっているのが、なんとなく共通点でしたね。
気になった記事があれば、詳しい内容やキーワードはショーノートにまとめておきますので、あとでゆっくりチェックしてみてください。番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストも、ぜひお便りで送ってください。AIとの付き合い方にまつわる小さな工夫から、ゲーム開発のディープな話まで、幅広くお待ちしています。
それでは、そろそろお別れの時間です。今日もzenncast、ここまでのお相手はマイクでした。次回また、この時間にお会いしましょう。それでは、いってらっしゃい。