どうもー、おはようございます。マイクです。
「zenncast」、2026年2月11日、水曜日の朝7時を少し過ぎたところです。みなさんいかがお過ごしでしょうか。
この時間は、テックな皆さんと一緒に、Zennで話題になっているトレンド記事をゆるっと、でも中身はがっつりめに紹介していきます。

今日はお便りコーナーはお休みで、そのぶん記事をたっぷりご紹介していきます。
さて、きょうピックアップする記事は全部で5本です。AIまわり、データモデル、開発フローと、なかなか濃いラインナップですよ。それぞれサクサク解説していきますね。

まず1本目。タイトルは「『アンチパターン』と呼ばれるEAVを、あえて採用した話 ── 数十万件の属性、数十億件の値と向き合って」。
EAV、Entity-Attribute-Value って、設計本だと「やめとけ」側の常連なんですよね。SQLが複雑になる、型安全じゃない、外部キー効かせづらい、パフォーマンス不安…と、悪評てんこ盛り。でもこの記事がおもしろいのは、「それでも条件がハマると、むしろ有力な選択肢になるよ」というところなんです。
Speeda では、数十万件の勘定科目を「属性」として扱い、さらに期間をあらわす period_id を入れることで、4次元のEAVモデルにしているんですね。で、「どうアクセスされるか」をかなり丁寧に洗い出して、そこにバチッとハマる複合インデックスを設計することで、数十億行あっても実用的なレスポンスを出していると。
さらに YESOD というプロダクトでは、一歩進んで reference_id っていう軸を足して、Entity間の関係自体もEAVの中に押し込んじゃう。普通なら「EAVは外部キー弱いよね」と言われるところを、逆にちゃんと外部キー制約を効かせるように工夫している。値の部分も、ただの文字列じゃなくて、バイナリ＋Kotlinのシリアライズで型安全に扱うことで、「型がない問題」もかなり抑え込んでいるんですね。
ポイントは、「EAVはアンチパターンだからNG」ってラベルで終わらせずに、要件と代替案を並べて冷静に比較したうえで、「弱点をどう運用・実装で埋めるか」までセットで考える姿勢。スキーマを頻繁に変更したくない、属性が膨大でスパース、そんな現場で悩んでいる方には刺さる内容だと思います。

。。。。

続いて2本目。タイトルは「Claude16台で10万行のCコンパイラを作った論文を読んで、『いや答えあるじゃん』と思った話」。
このタイトルだけでもう、ちょっと笑っちゃいますよね。Anthropic の Carlini さんが、「Rust製のCコンパイラ10万行を、Claude16台で2週間・2万ドルで自動生成して、Linuxブートもできるし、GCCテストも99%通りました」という、かなりパンチのある実験をやったんです。
これを聞くと、「じゃあもう全部AIに作らせればよくない？」って思いがちなんですけど、筆者が冷静に指摘してるのが、「これは“答えがある世界”だから成立している」ということ。コンパイラの世界だと、GCCのテストスイートっていう、ほぼ完全な仕様＋採点マシンがあるんですよね。だからAIたちに「とにかくこのテストを全部PASSさせろ」と命令して、自律ループのマルチエージェントを回せば、かなり機械的に前に進める。
でも、現実の業務開発って、「何が正解か」がそもそも存在しないことが多い。テストも完璧じゃないし、仕様も揺れ動く。いちばん難しいのは「何を作るか」を決めるところなんだ、と。
そこで筆者が提案しているのが multi-agent-shogun という枠組みで、「Spec → Test → Implement」の3段階に分けるやり方です。仕様（Spec）は人間が決めて、テストと実装をAIに任せる。Carlini流の「テストが仕様で、人間の介入ゼロでOK」というのは、答えがあらかじめ定まっている特殊な世界だけの話として受け止めよう、と。
結論としては、「何を作るかは人間が握る。どう作るかはなるべくAIに任せる」。この線引きが、AI時代の開発スタイルとして本質だよね、という話でした。AIで全部置き換わるんじゃなくて、役割分担の再設計なんだ、という視点がいいですね。

。。。。

3本目。タイトルは「Claude Codeがベクトル検索を採用しなくなった理由」。
最近どこもかしこも「とりあえずベクトル検索でRAG」みたいな雰囲気ありますけど、Claude Code はあえてそこを外しているんですね。代わりに採用しているのが agentic search、エージェントが自分で考えながらコードベースを検索して回る、いわゆる Agentic RAG というスタイルです。
中身としては、Glob・Grep・Read をうまく組み合わせて、エージェントが「今このファイルが怪しいな」「ここから参照をたどろう」みたいに、何度も行ったり来たりしながらコードを探索していく。ベクトル検索と喧嘩してるわけじゃなくて、共存もできるんだけど、少なくとも Claude Code 本体では「使わない」という判断をしている。
理由はシンプルで、コード検索の世界だと、ファイル名や関数名でパシッと検索できる Glob/Grep が思った以上に強いんですよね。一方で、コードをベクトル化して意味検索するのって、意外と精度が安定しないし、コードの変更頻度が高いから、インデックスの構築・更新コストもバカにならない。
コードの場合は、参照関係を辿っていくと、わりと自然に「必要なところ」にたどり着けるので、ベクトル検索が本当に効くのは、探索の初動のごく一部だけになりがち。それなら、わざわざ重いインフラを抱えなくても、エージェントに Glob/Grep/Read をちゃんと使わせた方がコスパいいよね、という判断です。
逆に、整理されたドキュメントや議事録、大量の文章から意味的に近い情報を引っ張ってくる系では、いまでもベクトル検索の価値は大きい、ともちゃんと書かれてます。VersionRAG とか Hindsight みたいな、「ログや履歴をうまく料理する」アプローチとはすごく相性がいい。
要するに、「なんでもかんでもベクトル検索」じゃなくて、対象とワークフローを見て、手段を選ぼうね、という実践的な話でした。

。。。。

4本目。タイトルは「効果的なCLAUDE.mdの書き方」。
これは Claude Code を日常的に使っている方には、かなり実務的に役立つ内容です。CLAUDE.md って、プロジェクトごとに置いておく「このプロジェクトの覚書」みたいなファイルで、Claude Code が毎セッション自動で読みに行ってくれる、いわばプロジェクトメモリなんですね。
ここで大事なのが、「なんでもかんでも書かない」こと。コンテキストや命令の上限があるので、目安としては500行以内におさめる。判断基準は「この1行を消したら、Claude がミスりそうか？」。ここがかなりシビアで、でも重要な観点です。
書くべきなのは、コードからは読み取れないけど、作業に効いてくる情報。例えば、プロジェクト固有のコマンドとか、一般的な慣習と違うコードスタイル、テストの回し方、いつも使うワークフローや設計判断、環境のクセやハマりポイントなど。
逆に、コードを見れば分かること、やたら長いドキュメント、すぐ変わる情報、細かすぎるスタイル規約なんかは、CLAUDE.md には書かずに別の場所に逃がす。構成としては、「概要 / コードスタイル / コマンド / アーキテクチャ / 注意事項」ぐらいのシンプルなセクションにして、詳細は `.claude/rules/` や `docs/*.md`、スキル・サブエージェントに段階的に分けていく。「Progressive Disclosure」、少しずつ情報を開いていく設計ですね。
アンチパターンとしては、なんでも詰め込みすぎる、/init の出力をそのままコピペして放置する、あるタスクにしか効かない指示をトップレベルに書いちゃう、などなど。
運用面の話もよくて、Claude が間違えたときや、PRレビューの指摘が出たときに、「これは次から避けたいな」というものを CLAUDE.md にフィードバックしていく。定期的に棚卸しして、いまも効いている指示だけ残す。そうすることで、「短いけど高シグナル」なプロジェクトメモリに育っていくんだ、という提案になっています。

。。。。

ラスト5本目。タイトルは「Claude Code Agent Teams を使ってわかったチーム設計の勘所と自動化の限界」。
Claude Code には「Agent Teams」っていう、複数エージェントをチームにして動かせる実験的な機能があるんですが、この記事の筆者はそこで、team-builder という skill を作って、チーム編成自体を自動化しようとチャレンジしています。
24エージェント×83スキルという、なかなかカオスな組み合わせの中から、タスクに最適なチームを組む仕組みを作ったんですね。その過程で、skill やテンプレート、スクリプトを使って、「十分なコンテキストを渡す」「タスクをうまく分割する」「同じファイルを同時に編集しないようにする」「コストを意識する」といった、公式のベストプラクティスをワークフローに組み込んでいった。
さらに、モデルの使い分けパターンを4種類に整理して、テンプレートとして再利用できるようにしたことで、「毎回ゼロから考えないで済む」というメリットがかなり大きかったそうです。
一方で、「全部自動にしよう」としたところは意外と伸びなかったという話も正直に書かれてます。AUTOモードでの自動ドメイン検出や、Skill Injection みたいな仕組みは、「Claude 本体の自然言語理解＋既存スキル一覧」をちゃんと見せれば、ほとんど代替できてしまった。つまり、「わざわざ複雑な自動判定ロジックを書いても、リマインダー程度の効果にとどまることが多かった」と。
さらに、Teammate の中で Subagent を呼ぶような多層構造は、コストも管理も重くなりすぎて、あまり割に合わなかった。結局のところ、「タスクのスコープをどう切るか」の設計のほうが重要で、チーム構造をやたら複雑にするより、シンプルな単一セッション＋必要なところだけSubagent、みたいな形のほうが安定したそうです。
総括として、Agent Teams が真価を発揮するのは、「並列の調査」や「並列レビュー」、「違う仮説を同時に検証する」みたいな場面。逆に、「順番に依存するタスク」や「同じファイルをいじる作業」には、かえって向かない。全部を全自動にするよりも、「ベストプラクティスを体系化して、再利用可能な設計パターンに落とし込むこと」が最大の成果だった、と締めくくられています。
AIチームをどう設計するか悩んでいる方には、そのまま実務に持ち込める知見が多い記事でした。

。。。。

というわけで、きょうの「zenncast」、お届けしてきたのは全部で5本。
EAVをあえて採用して数十億行と戦った設計の話、
答えがある世界とない世界でのAI開発の違い、
Claude Code がベクトル検索を外した理由、
CLAUDE.md をどう書けばAIがちゃんと働いてくれるか、
そして Agent Teams で見えてきたチーム設計と自動化の限界。
どれも、「AIと一緒に開発していく時代」のリアルな知見が詰まっていました。

気になった記事があった方は、この番組のショーノートから、ぜひ元の記事もチェックしてみてください。もっと細かい設計や具体例がたくさん載っているので、現場に持ち帰るヒントが見つかると思います。
番組の感想や、「こんなテーマ取り上げてほしい」というリクエストも、どしどしお待ちしています。あなたの現場での悩みが、次回のトピックになるかもしれません。

それでは、きょうはこのへんで。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。お仕事・勉強、無理しすぎず、ほどよくがんばっていきましょうね。