どうもー、おはようございます。マイクです。
時刻は朝7時を少しまわったところ、2026年5月8日、金曜日です。
ここからの時間は「zenncast」、今日もZennで話題になっているトレンド記事を、ゆるっと楽しくご紹介していきます。通勤・通学のおともに、コーヒー片手に、最後までお付き合いください。
さて今日は、お便り紹介はお休みしまして、このまま本題にいきたいと思います。
今日ご紹介する記事は全部で5本。どれも開発者の方にはグッと刺さりそうな、かなり濃いラインナップになってます。
まず1本目。「OpenAPIという間接的な型共有をやめてoRPCを導入した話」という記事です。
TypeScriptでバックエンドはNestJS、フロントはReact、という構成、かなり王道ですよね。ここにOpenAPIをかませて型を共有していたんですが、やってるうちに「TS → OpenAPI → TS」という、遠回りな6段階変換パイプラインになってしまっていた、と。しかも生成されるファイルが巨大で、手動再生成が必要、コンフリクトもしょっちゅう起きる、型も劣化気味…と、だんだん開発者体験が悪くなっていったそうです。
そこで著者が改めて、「自分たちが本当にほしいのは何か？」を整理しているのが面白いんですよね。エンドツーエンドの型安全、コード生成なし、でもOpenAPIは自動で欲しい、コントラクトファーストでいきたい、Zodでバリデーションも書きたい、さらにTanStack Queryともつなげたい、と。これらを全部満たせるかどうかで、tRPCやts-rest、Nestiaなどを比較していって、最終的に採用したのがoRPC。
oRPCでは、Zodで定義した「コントラクト」を中心に、TypeScriptの型推論をそのまま活かしてフロントとバックで型を直接共有しつつ、同じ定義からOpenAPIも生やせるというのがポイントです。フロントとバックが別リポという制約の中で、`*.api-contract.ts` をバックエンド側で集約してnpmパッケージとして配布、普段はpublish版を使い、並行開発中はpnpm linkで密に同期する、という運用も具体的で参考になります。
一方で、oRPCのエコシステムがまだ若いことや、ESMとCJSの混在、Zodのバージョン差など、現実的なハマりどころもちゃんと書かれていて、「型安全を高めつつ、コード生成パイプラインを削ぎ落としていくとこうなるのか」という実録になっていました。型共有まわりでモヤモヤしているチームには、かなり刺さりそうな記事です。
。。.。。.。。
続いて2本目。「ローカルワークスペースのMarkdownファイルをブラウザで閲覧・編集できる軽量Webアプリを作った」という記事です。
メモやドキュメントをMarkdownで書いている方、多いと思いますが、「ローカルに散らばってるmdファイルを、サクッとブラウザから編集したい」というニーズ、まさにそれを満たす小さなWebアプリを作者さんが自作して公開した、というお話です。
アプリ名は「workspace-web-editor」。思想としてはObsidianっぽくて、Wikiリンクやバックリンク、クイックスイッチャー、ディレクトリツリー表示、タグフィルター、Mermaidで図をプレビュー、テーマ切り替えまでできる。「軽量」と言いつつ、個人Wikiとして十分戦えそうな機能が揃っています。Node.jsとExpressでできていて、環境変数でワークスペースのパスを指定して起動するスタイル。Tailscaleとかをかませると、スマホから自宅PC上のMarkdownを直接編集、なんてこともできる構成ですね。
面白いのは、これをAIエージェントの「Skill」としても想定しているところです。xangiやOpenClawといったAI環境の中から、このエディタを呼び出して、AIが生成したMarkdownドキュメントを人間がブラウザで確認・微修正する、というワークフロー。AI時代の「エディタ」として、かなり良いポジションを狙っているなと感じました。
作者さん自身は、もともと自分用のAI環境向けに使っていたものを、GWの成果として一般公開したそうで、「手元のMarkdown資産をちゃんと活かしたい」「Obsidianフルセットまではいらないけど、ブラウザでサクッと触れたい」という方には刺さりそうです。
。。.。。.。।
3本目は、「AIのPlan Modeをなんとなく承認しないために」という記事です。
最近のAIツールって、「いきなり実装します」じゃなくて、一度Planを提案してくれるモード、ありますよね。便利ではあるんですが、ここで問題になるのが、「そのPlanを人間がどう評価するか」。この記事は、そこをかなり丁寧に分解しています。
キーワードは、「Plan＝どう作るか」と、「受け入れ条件＝何を満たすべきか」を切り分ける、という考え方です。AIにいきなり受け入れ条件まで丸投げするのではなく、Issueや仕様、既存実装を元に、「受け入れ条件の候補」をAIに洗い出させる。そのうえで人間が、(1)ちゃんと参照元がある条件、(2)仮説として書いている条件、(3)要確認な条件、というふうにラベリングして、根拠付きで磨き込んでいく。
そのうえでPlanを見るときには、「根拠」「受け入れ条件」「実装手順」「確認方法」という4つの観点でレビューする。「なんとなくよさそうだからOK」ではなく、「どの受け入れ条件を、どのテストやどの画面で確認できるのか」まで落とし込んでから承認する、というスタイルです。
印象的なのは、失敗したケースも含めて、それを次タスクの受け入れ条件やチェックリストとして蓄積していこう、という視点。AIの出力を鵜呑みにせず、自分の判断基準をアップデートし続けること自体が、エンジニアとしての重要なスキルだ、と結んでいます。将来的に、AIが自動で画面チェックやログ確認ができるようになっても、「何を確認できれば受け入れOKなのか」という条件設定の力は、変わらず人間側に残るよね、というメッセージが印象的でした。
。。.。。.。。
4本目は、「Agentic Graph RAG MCPのススメ — Graph RAGは『単発』ではなく『対話』になった」という記事です。
RAG、つまり外部データを検索してLLMに渡す仕組みは、もうおなじみになってきましたが、最初のベクトルRAGは基本的に「1問1答」の世界だったんですよね。質問に近い文書をベクトル検索で取ってきて、LLMにそのまま渡す。それだと、多段の推論や、関係性をたどるような問いに弱い。
そこで登場したのがMicrosoftのGraphRAG。エンティティを抽出して、コミュニティごとに要約することで、関係をたどれるようにした…んですが、重い前処理や更新コスト、抽象化しすぎてディテールが失われる、といった課題もありました。
この記事で提案されているのは、MCPやエージェント基盤の発展を前提にした「Agentic Graph RAG」というスタイルです。人間が設計したグラフ構造と、IDベースで決定的に動くretrievalツール、それを多段でオーケストレートするAIエージェント。この三つ巴で、「対話しながらグラフを探索する」イメージですね。
ポイントは、「揺らぎがあるのは入口だけ」にすること。最初にどのノードから入るか、どのツールを使うか、どこで止めるか、そこはAIの裁量に任せるけれど、一度グラフ探索が始まったら、IDベースで決定的にたどっていく。MCPツールの返却値には、関連IDやenum、次に取り得るステップを含めて、「AIにとってのrunbook」にする設計が勧められています。
さらに、DBのGraphやビジネスロジックのGraphなど、社内に複数のグラフがあるときでも、「概要を探索 → 詳細を引く → 走査しつつ次の手を提案」という共通パターンを使うとよい、という実践的な話も。とはいえ、グラフの設計の良し悪しへの依存や、入口検索の難しさ、コストやハルシネーションの「発生場所が変わるだけ」といった限界もしっかり指摘していて、「良いGraph RAGは、結局、人間のドメイン理解が土台になる」という結論になっています。
。。.。。.。।
そして5本目。「自動運転E2Eモデルは何を見ているのか — Integrated Gradientsによる解釈」という記事です。
自動運転のエンドツーエンドモデルって、入力はカメラ画像、出力はステアリングやアクセルの操作、みたいな「全部を一気につなぐ」モデルですよね。これが「どこを見て判断しているのか」を知ることは、安全性でも規制対応でも、かなり重要になってきます。そこで登場するのがIntegrated Gradients、略してIGという手法です。
IGは、ある「ベースライン」から実際の入力までの直線経路を少しずつたどりながら、その途中の勾配を積分していくことで、「どの入力特徴がどれだけ出力に寄与したか」を計算する方法です。この記事では、SensitivityとImplementation Invarianceという2つの公理を満たしていること、さらに「帰属の総和が出力差分と一致する」というCompletenessも保証されていることが、理論的な強みとして紹介されています。
これによって、ReLUの飽和みたいに「勾配が0になってしまって本当は効いてるのに見えない」問題を避けられるし、DeepLIFTやLRPのようにモデルの内部構造に強く依存する手法に比べて、より一般的に使えるのが魅力です。記事では、自動運転の実データを例に、道路の白線や路面、対向車の位置、信号機の青ランプの点灯タイミングなど、どこにモデルが注目しているかを、ピクセルレベルの可視化として見せてくれます。
実装面では、PyTorchでのIGの書き方や、何ステップで積分するかを「Completeness誤差」を見ながら決めていく実務的な指針も解説されています。自動運転に限らず、安全性や説明責任が重要な領域で、E2Eモデルをどう説明可能にするか、その1つの有力なアプローチとして、かなり丁寧に整理された記事でした。
。。.。。.。。
というわけで、今日のzenncastでは、
OpenAPIからoRPCへの移行で型共有を見直した話、
ローカルMarkdownをブラウザで軽量に扱えるworkspace-web-editor、
AIのPlan Modeを「なんとなく」承認しないための受け入れ条件の作り方、
エージェントとMCPを活かしたAgentic Graph RAGの考え方、
そして、自動運転E2EモデルをIntegrated Gradientsで解釈する手法、
この5本をご紹介しました。
気になる記事があった方は、番組のショーノートから、元の記事をぜひチェックしてみてください。実際のコードや図、もっと細かい議論がたくさん載っています。
「zenncast」では、番組の感想や紹介してほしいテーマなど、みなさんからのメッセージもお待ちしています。開発のちょっとした悩みや、最近ハマっている技術ネタなんかも、ぜひ気軽に送ってください。
それでは、そろそろお別れの時間です。
今日も良い一日をお過ごしください。お相手はマイクでした。また次回のzenncastでお会いしましょう。