どうも、マイクです。おはようございます。
2026年3月28日、土曜日の朝7時になりました。ここからは「zenncast」、Zennで今トレンドになっている技術記事を、ラジオ感覚でゆるっと紹介していきます。

今日は全部で5本の記事をご紹介していきます。エンジニアの開発効率アップから、社内DX、ローカルLLMのお金のリアルな話まで、なかなか濃いラインナップです。それでは順番にいってみましょう。

まず1本目。タイトルは「git worktree を Worktrunk で管理したら手放せなくなった」。
git worktree をメインに使ってる方、あるいは「名前は聞いたことあるけど、まだ触ってない」という方にグッと刺さりそうな内容です。Worktrunk というRust製のCLIツールを使うと、gitに近い感覚で worktree の作成、切り替え、削除がサクサクできるようになります。特に面白いのが `wt switch`。ブランチを切り替いだタイミングで、自動でそのディレクトリに移動してくれるので、「あれ、このブランチの作業どこだっけ？」っていう迷子が減ります。さらに、インタラクティブなブランチピッカーで、ブランチ名を全部覚えてなくても直感的に選べたり、`wt list --full` でCIステータスやLLMによるサマリーも表示できる。Hook機能を使えば、worktree作成直後に依存インストールを自動実行したり、`.gitignore` の対象ファイルも `.worktreeinclude` と組み合わせてコピーできるので、「チェックアウトしたけど環境整ってなくて何も動かない問題」もかなり軽減されます。さらに、Claude Code のプラグイン連携で、設定ドキュメントとつないだり、`wt switch -x claude ...` でブランチ作成と同時にセッションを立ち上げたり、LLMにコミットメッセージを考えてもらったりと、開発フローとAIがかなり密接につながるのが特徴です。PR番号からのチェックアウトや、マージ済みworktreeの一括削除なんかも含めて、「git worktree前提の開発」を本気でやるなら、かなり強い武器になりそうだなという印象でした。。.。。

続いて2本目。タイトルは「Claude Opus 4.6と同等のAIをローカルで動かすにはいくらかかるか？ローカルLLMを構築してわかったこと」。
この記事は、ローカルLLMに興味がある人にとって、かなり現実的な数字を突きつけてくれる内容です。筆者の環境はRTX 3070、VRAM 8GBで、OllamaとQwen2.5:7Bを組み合わせてローカルLLMを構築しています。完全オフラインで日本語も喋れるところまではいけるんですが、たとえば「札幌のこのあたりの店を教えて」みたいなローカル情報を聞くと、実在しない店名や駅名をそれっぽく作ってしまう、典型的なハルシネーションが頻発したそうです。小さなモデル＋足りない学習データ領域だと、やっぱり精度に限界があるんですよね。一方で、じゃあClaude Opus 4.6クラスのモデルをローカルで動かしたらいいじゃん、と思って計算してみると、推定パラメータ数からVRAM必要量を見積もって、fp16でなんと約11.6テラバイト。RTX 5090を数百枚とか、Mac Studio M3 Ultraを何十台も並べる規模で、コストは数千万円から1億円オーバー。もはや個人趣味ではなく、データセンター案件です。記事では、「正確な外部知識が必要なときはクラウドLLMやRAGを使うのが現実的。でも、機密情報を外に出したくないとか、災害時でも動かしたい、社内文書の要約や校正、軽い相談相手にしたい」といった用途なら、ローカルLLMは今でも十分実用的だとまとめています。将来、モデル軽量化や新しい手法でこの常識がひっくり返る可能性も触れつつ、「今はどこまでをローカルに任せるのか、その線引きを考える時期だよね」という、ちょっと足元を見直したくなる内容でした。。.。。

3本目は、かなり実務寄りの話。タイトルは「社内問い合わせをAIエージェント化して爆速で解決できるようにした」。
飲食店向けサービスを提供するダイニーさんの事例です。技術的な社内問い合わせが1日8件、調査に数時間かかるのに、リードタイムの中央値はなんと10日以上。しかもステータスが放置されがち、という、現場ではあるあるだけど結構つらい状況からスタートしています。これを「AIエージェント化」でどう改善したか。大きく3つのポイントがあって、まず1つ目が問い合わせの入り口を整えること。Slackフォームで、一次情報、発生日時、Notion AIでの事前検索結果などを必須にして、「調べるのに絶対いる情報」を最初から揃えるようにした。2つ目が、毎回必ずやっている調査作業を自動化すること。MastraとRAGを使って、過去の問い合わせ、ヘルプ、チーム資料、Q&Aといった社内ナレッジを一気に検索するAIエージェントを用意して、初動調査を高速化しています。そして3つ目が、ボットによるリマインドと、Slackスレッドの内容からステータスを自動更新する仕組みで、「誰も見てない、誰も閉じない問い合わせ」を減らしたこと。この結果、リードタイムの中央値は10日以上からなんと5時間まで短縮。この記事の良いところは、「AIが全部判断する」のではなく、完了判定など曖昧で重要な判断は人間がいつでも覆せるようにしておいて、「機械的に潰せる仕事」から順番にAI化した、というスタンスなんですよね。その過程で、AI向けにコンテキストを整えたことが、人間が調査するときの効率も結果的に上がった、という学びも紹介されていて、社内問い合わせに疲れているチームにはかなりヒントになる記事だと思いました。。.。。

4本目は、データ基盤や社内の分析環境に関わっている人には刺さりそうなお話。タイトルは「社内データの民主化 - 全DBを自然言語で横断検索できるMCPサーバーを作った話」。
エアークローゼットさんの事例で、10年分の開発の結果、15スキーマ・991テーブルが複数DBに散らばっている状況。どのテーブルがどうつながっているかを完全に把握している人が、社内にごく少数しかいない、という「属人化データベース問題」をどう解消したか、という内容です。やっていることは大きく2段構えで、まず「DB Graph」と呼んでいる仕組み。ORM定義や実DBからテーブル、カラム、リレーションを抽出し、BigQuery上でグラフ＋ベクトル検索として構造情報を集約しています。ここに自然言語で「こういうデータが欲しい」と投げると、どのテーブルを見るべきか、どうつなげばいいかの候補を出してくれる。そして、これをClaude CodeからMCPとして使えるようにしたのが「DB Graph MCP」です。`search_tables` で候補テーブルを探し、`get_table_detail` でカラムや意味を確認し、`trace_relationships` でテーブル間のつながりをたどる。SQLやテーブル構成を知らなくても、「日本のこの期間のユーザーの解約傾向を見たい」といった自然言語から、必要なクエリまで道筋をつけてくれます。権限まわりもかなりしっかりしていて、個人ごとのDB権限に応じたクエリツール、GCPからAWS VPC内DBへはOIDC経由で静的鍵なし接続、本番はRead Replica、PIIは自動マスキング、SQLはSELECT系のみ、と多層防御を実装。さらに、テーブルの説明文はGeminiで自動生成しつつ、Web UIで人間がレビューして、不要なテーブルにはDEADフラグをつけるなど、暗黙知もきちんと反映しています。そのうえで、DBアカウントの発行もワークフローから自動化し、権限・パスワード管理も安全に回している。結果として、「SQL書けないとデータ取れない世界」から、「自然言語だけで複数DBを横断して調査・分析できる世界」に一歩近づいた、という取り組みでした。データの民主化って言葉だけ聞くとふわっとしがちなんですが、「ここまでやるのか」という具体例として、とても参考になる記事です。。.。。

そして最後、5本目。タイトルは「takt で Codex・Cursor・Claude Code を協調させてみた ― 5回 ABORT して気づいた設計の急所」。
これはAIエージェントオーケストレーションに興味がある人に、かなり響きそうな内容です。taktというツールを使って、Codexで仕様レビュー、Cursorで実装、Claude Codeで受け入れ検査、という3段構成で、自作OSSに新しいAPIを追加するワークフローを組んだ話なんですが、キモは「分岐条件の設計ミスで5回連続ABORTした」ところにあります。taktではpieceやmovementといった概念を使ってYAMLでフローを組むんですが、最初は「仕様に問題があったらABORTする」という、ある意味まっとうだけど厳しすぎる条件にしてしまった。するとCodexが毎回新しい指摘をしてくるので、延々とABORTして終わらない、という沼にハマってしまったんですね。そこで、「軽微な指摘なら実装には進める」という条件を明確にし、どこまでを“要修正”とするかの判定基準テンプレートも整備したところ、仕様の精度が上がり、実装から受け入れ検査まで一発で通るようになった。このあたり、「複数のAIを並べたら自動でうまくやってくれるわけじゃなくて、“どこの段階でどのくらい厳しくチェックするのか”を人間が設計しないといけない」という教訓がにじみ出ています。一方で、仕様書に書いていない観点は当然検査されないので、外部のCodeRabbitだけが指摘できた設計の穴もあった、という反省点も正直に書かれています。記事の結論としては、taktのようなエージェントオーケストレーションでは、分岐条件の設計と、各工程にどのエージェントを割り当てるか、その相性見極めがすごく重要だ、というもの。AIに仕事を任せる時代でも、「ワークフロー設計力」が人間側に強く求められているんだな、ということを感じさせる内容でした。

というわけで、今日は5本の記事をご紹介しました。
Worktrunkでgit worktreeを超快適にする話、
Claude Opusクラスをローカルで動かすにはいくらかかるのかという現実的な試算、
社内問い合わせをAIエージェント化してリードタイムを10日から5時間に縮めた事例、
社内データを自然言語で横断検索できるMCPサーバーで「データの民主化」を進めた話、
そして、taktで複数AIエージェントを協調させる中で見えてきた設計の急所。

気になった記事があれば、詳しい内容はこの番組のショーノートに書いておきますので、ぜひ元記事もチェックしてみてください。
「zenncast」では、番組の感想や、こんなテーマを取り上げてほしい、といったリクエストもお待ちしています。あなたの開発現場でのモヤモヤや、「これ良かったよ」というTipsなんかも、ぜひ教えてください。

それでは、そろそろお別れの時間です。
お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。お聴きいただき、ありがとうございました。