どうもー、おはようございます。マイクです。
時刻は朝7時を少しまわったところ、今日は2026年3月27日、金曜日。
ここからの時間は「zenncast」、きょうもZennで話題のトレンド記事を、ラジオ感覚でゆるっとご紹介していきます。

今日はお便り紹介はお休みで、そのぶん記事をどーんとたっぷりめにいきたいと思います。
きょうピックアップする記事は全部で5本。AIエージェント、データ基盤、CLIでのプレゼン、DDDの学び、そしてPRレビューの効率化まで、かなり攻めたラインナップです。

まず1本目。
タイトルは「【消費トークン1/12】コーディングエージェントにRAGは罠だった。「検索」ではなく「コンパイル」するDAGツールを作った話」。
AIでコードを書かせようとすると、AGENTS.mdとかarchitecture.md、ADRみたいな設計ドキュメントが山ほど増えていきますよね。で、「RAGで検索すればいいじゃん」と思いきや、実際はうまくいかない、というところから始まるお話です。
実装時に欲しいのって、「このファイルに関係する設計やガイドラインを、漏れなくちゃんと持ってきてほしい」ってことなんですが、意味ベースの検索だと、どうしても確率的になってしまう。そこで著者が取ったのが、「検索」じゃなくて「コンパイル」という発想です。
ドキュメントとファイルパスをノードにして、それらの依存関係をエッジとしてつないだDAG（有向非巡回グラフ）としてSQLiteに保存。対象のファイルを指定すると、そこから再帰的にたどって、関連する設計ガイドラインやADRを一気に「コンパイルして返す」ツール「Aegis」を作った、というものです。
面白いのが、エージェントがセルフレビューした結果をObservationとして集めて、そこから「このドキュメントとこのファイル、つながってるよね？」っていうエッジ追加の提案を自動生成して、人間がそれを承認していく仕組み。いわば、ペアプロ相手が勝手に設計マップを育ててくれる感じですね。
実プロジェクトでは、関連ガイドラインをRAGで探し回らずに、設計意図込みで一括で取れるようになって、トークン消費は約12分の1、応答も3.5倍速くなったそうです。コンテキストが増えれば増えるほど、「決定的に辿れる知識のグラフ」を用意しておく重要性が上がるよね、という示唆に富んだ内容でした。

。。，。。

続いて2本目。
タイトルは「Claude Code Agent Teamで実現するAIのためのデータ品質向上プロセス」。
レシピサービス「クラシル」のデータチームのお話ですね。こちらのチームでは、AIで使えるデータをTierというランクで管理していて、Tier3以上を「SSoT」、つまり信頼できる唯一の情報源として扱っているそうです。
問題になっていたのが、このTier3に昇格させるまでのプロセス。ディメンショナルモデル化したり、品質検証したりって、本来すごく大事なんですけど、どうしても人に依存しちゃうし、検証も時間がかかる。そこで登場するのが、Claude Codeのエージェントチームです。
面白いのは、役割をガッツリ分けているところ。設計専任の「data-architect」、dbtで実装する「dbt-data-modeler」、Snowflakeに接続して移行検証をする「migration-tester」など、AIエージェントに明確な職務分掌をしている。人間のチーム組成とほぼ同じノリでエージェントをチーム化しているところがポイントです。
特にmigration-testerは、SnowflakeとMCPでつないで、集計レベル、ディメンション別、EXCEPT差分、NULLの分布まで自動でチェックしてくれるので、これまで数時間〜数日かかっていた移行検証が、10分〜数時間で終わるようになった、と。
さらに「promote-to-tier3」というスキルで、generic testを足したり、メタデータを補完したり、「このテーブル、ほんとにSSoTにしていい？」っていう検証や、関係者へのインタビュー内容まで支援してくれる。これにより、Tier昇格作業が最大2日から1〜2時間くらいに短縮されたそうです。
最後に、`/retro`というコマンドでエージェント自身が振り返りをして、気づいた改善点をスキルやエージェント定義のPRとして返す、というループまで組み込んでいるのがすごい。人間とAIのチーム開発の、かなり先進的な実例だなと感じました。

。。，。。

3本目。
タイトルは「GitHub Copilot CLI でプレゼンテーションをする技術」。
これはイベント「GitHub Copilot Dev Days Tokyo 2026」での10分セッションの裏側ですね。普通はスライド作ってPowerPointとかKeynoteで発表するところを、「GitHub Copilot CLIにプレゼンさせちゃおう」という、なかなか攻めたデモをやっています。
仕組みとしては、ターミナルにアスキーアートでスライド風の画面を出しつつ、Copilot CLIにしゃべらせる形。コンテンツの中身は`.github/copilot-instructions.md`に書いておいて、プレゼンの進行ロジックは`.github/skills/presentation/SKILL.md`というスキル定義に書いておく、という役割分担になっています。
SKILLの方では、「スライド1はイントロ、スライド2はデモ概要…」みたいな構成と順番を定義して、`ask_user`ツールを使って、「次へ」「前へ」「スライド一覧」「終了」といったナビゲーションを実現。聞き手に選択してもらうことで、CLI上でも“それっぽい”スライドショーになるようにしています。
おもしろいのが、スライド本文は通常の回答としてストリーミング表示して、`ask_user`のメッセージには含めないようにしているところ。これで、ターミナルにテキストがじわじわ流れ込んでくるあの演出を再現しているんですね。
著者自身、「コンテンツとふるまいが完全に分離しきれていない課題はある」としつつも、Copilot CLIの柔軟さとか、「こんな使い方までできるんだ」というメッセージとして、とても良いデモになったと振り返っています。プレゼンそのものをエージェント化する、という発想が好きな人には刺さる記事です。

。。，。。

4本目。
タイトルは「ドメイン駆動設計を1から勉強してみた感想」。
これは、DDDを初学者としてちゃんと勉強してみた、という素直な体験談になっています。背景としてあるのが、運用フェーズに入ったプロダクトの改修がどんどんつらくなってきた、という悩み。機能別や役割別でディレクトリを切っていくと、最初はわかりやすいんですけど、時間がたつほど肥大化して、どこを触っていいか分からなくなっていくんですよね。
著者はそこからDDDに出会って、「これ、ちゃんとやれば構造化できそうだぞ」と希望を感じたと書いています。記事の中では、2010年代前半の「とにかく作れれば価値がある」時代から、2017〜2019年ぐらいに「事業ドメインで差別化しよう」という流れになってきた歴史も軽く触れつつ、DDDがなぜ注目されたかを整理しています。
メリットとして挙げているのは、まず1つ目が、業務領域を中核・一般・補完に分けることで、「どこにリソースをかけるべきか」がはっきりすること。2つ目が、コンテキストを分割することで、誤訳やGod Objectを避けられること。3つ目が、レイヤー構造で責務が明確になること。
一方で、デメリットもかなり率直に書かれていて、専門用語も多いし、設計と実装の両方の知識がいるから学習コストは高い。さらに、「これを守ればOK」という万能テンプレートがないので、結局チームごとにルールが個別最適になりがち、なんて話も出てきます。
実務での体感としては、値オブジェクトをちゃんと設計して、仕様とコードを行ったり来たりしながら進めることで、考慮漏れが減り、テストもしやすくなった。その一方で、値オブジェクトを量産する工数や、責務をどこに置くか、どこまでを1つのドメインとするか、といった線引きの難しさには相当悩んだそうです。
入門の読書順も具体的に書かれていて、「まずはオライリーの『ドメイン駆動設計をはじめよう』から入り、『ドメイン駆動設計入門』、そして『つくりながら学ぶ！実践入門』の順がよかった」とのこと。読み終えたあと、「エンジニアとして一段レベルアップした実感がある」と締めているのが印象的でした。

。。，。。

そして最後、5本目。
タイトルは「GitHub PRをレビューするTUIをつくった」。
AIエージェントにコードを書かせる場面が増えると、人間のエンジニアは「PRレビュー担当」になりがちですよね。著者もまさにそうなってきた中で、「じゃあ、PRレビューをもっと快適にしよう」と作ったのが、ターミナル上でGitHub PRをレビューできるTUIツール「gh-prism」です。
RustとRatatuiで実装されていて、GitHub CLIの拡張として動きます。既存のTUIツールだと、PR全体の最終的なdiffを見るのには強いけど、「コミット単位でじっくり追いたい」というニーズに応えてくれるものが少なかった。そこで、「コミットごとの差分をちゃんと追えるツール」を自作した、という流れです。
画面は4つのパネルに分かれていて、左上にPR説明、左下にコミット一覧、右上にファイル一覧、右下に詳細表示、という構成。コミット単位でdiffを見られるだけでなく、コミットやファイルごとに「viewed」フラグをつけて、どこまで見たかもきっちり管理できます。
さらに、コメントの投稿、サジェストの追加、レビューの送信、マージまで、すべてターミナル内で完結できるようになっているので、「ブラウザとターミナルを行ったり来たり」がなくなるのが嬉しいところ。
記事では、描画パフォーマンスや操作感をどうチューニングしたか、コメント入力用のテキストエディタコンポーネントを自作した話、バージョニングにCalVerを採用した理由など、実装の裏側も丁寧に紹介されています。AIがコードを書く時代に、人間側の「レビュー体験」を磨き直すという発想が、これからの開発フローを考えるうえでも参考になりそうです。

……というわけで、今日のzenncastは、
1本目は、RAGから一歩進んだ「コンパイル型」知識DAGツールAegisのお話。
2本目は、Claude Codeのエージェントチームでデータ品質とTier管理を爆速化した事例。
3本目は、GitHub Copilot CLIにプレゼンをさせるターミナル・スライドショーの工夫。
4本目は、DDDをゼロから学んだエンジニアのリアルな感想とつまずきポイント。
5本目は、PRレビューをターミナルで完結させるTUIツール「gh-prism」の開発記。
この5本をご紹介しました。

気になった記事があれば、詳しい内容や元の記事へのリンクは、番組のショーノートにまとめてありますので、ぜひそちらから読んでみてください。
「zenncast」では、番組の感想や「こんなテーマ取り上げてほしい」といったリクエストもお待ちしています。普段Zennでどんな記事を読んでるか、なんて話もぜひ教えてください。

それでは、そろそろお時間です。
お相手はマイクでした。次回のzenncastで、またお会いしましょう。いってらっしゃい！