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

今日はリスナーのみなさんからのお便りはお休みということで、その分じっくり記事の紹介に時間を使っていきたいと思います。

さて、今日ご紹介する記事は全部で5本です。AIエージェントのローカル実行から、開発スタイルのこれから、安全なファイル削除テク、日本のWebサイトの闇と光、そしてER図自動生成まで、かなり濃いラインナップになってますよ。

まず1本目。「DGX SparkでNemoClawをローカル実行」という記事です。
NVIDIAのAIエージェントサンドボックスツール「NemoClaw」を、DGX Sparkの環境で完全ローカル実行しちゃおう、という内容ですね。特徴的なのは、OllamaとNemotronを使って、APIキー不要・クラウド不要、つまり“全部自分のマシンの中で完結させる”構成になっているところ。
記事の中では、NemoClawを動かすうえでの3つの要素、セットアップ用CLIの「NemoClaw」、Landlockやseccomp、netnsでプロセスを厳重に隔離するサンドボックスランタイム「OpenShell」、そしてその中で動くエージェント「OpenClaw」が整理されていて、とくにOpenShellがセキュリティの要だと説明されています。環境はUbuntu 24.04のaarch64なDGX Sparkで、OpenShellバイナリとNemoClawのインストール、Dockerのcgroup v2まわりの設定、Ollama上にNemotronモデルを用意…と、手順がかなり丁寧にまとまっているのがうれしいところ。
セットアップが終わると、`nemoclaw onboard`でバックエンドに「Local Ollama」を選ぶだけでサンドボックスの構成を自動化できて、そのあと`nemoclaw connect`から`openclaw tui`を実行すると、TUI上でローカルのNemotron 3 Nanoとチャットできるようになります。面白いのは、きちんとサンドボックスの中からOllamaへ推論がルーティングされているかを検証していて、「本当に閉じた環境でAIエージェントが動いている」ことを確認している点。OpenShell単体でも応用できそう、Nemotron 3 SuperもDGX Sparkなら快適、といった所感も語られていて、「自作AIアシスタントを完全ローカルで育てたい人」の背中を押してくれるような記事になっています。
クラウドに出したくないデータを扱う人や、企業内でのエージェント活用を検討している人にはかなり刺さる内容ですね。

。。。。

続いて2本目。「Antigravityは(バックエンドでは)使い物にならない」という、ちょっと挑発的なタイトルの記事です。
Google Antigravityを2週間、本気で試した筆者の体験談なんですが、「VSCodeベース＋統合ブラウザ」という特徴から、TypeScript＋Reactのフロントエンド開発には驚くほど強い一方で、バックエンド開発には相性がよくない、とバッサリ切っています。バックエンドの仕事って、どうしてもターミナル中心で進むことが多くて、ブラウザ連携の強みがあまり活かせないんですよね。さらに、「厳密な設計仕様書がないとAIに任せられない」という根本的な問題は、Context7とかMCPを使っても解決しなかった、と。
一方で、Antigravityは「イイ感じのUI」を汲み取るのが本当に得意だから、TypeScript＋Reactで、既存の人気ライブラリにがっつり乗っかるタイプのフロントエンド実装は、かなりの部分をAIに持っていかれそうだ、という見通しが語られます。逆に、生き残る余地が大きいのは、オリジナルなデザイン寄りのフロントエンドエンジニア、ライブラリそのものを作る人、あとはマイナーライブラリを攻める人、それからC/C++やRust、Javaみたいな静的コンパイル言語の使い手たち。
ただ、「AIが全部うまくやってくれる」という話でもなくて、たとえば`cargo build`を毎回フルで回すような、微妙に非効率な手順を平然と提案してきたり、AI特有の“なんか変”なところもちゃんと残っている。そこを見抜いて方向修正する人間側の知見は、まだまだ重要だよね、という結論に落ち着いています。
このあたり、自分のキャリアをどう伸ばすか考えるうえでも、かなりリアルな示唆をくれる記事だなと感じました。

。。。。

3本目は、安全第一な運用テク。「rmの代わりにtrashを使ってCoding Agentに安全にファイルを削除させる」という記事です。
LinuxやmacOSのターミナルでおなじみの`rm`、とくに`rm -rf`は、一歩間違えると取り返しがつかない危険なコマンドですよね。人間が打ち間違えるのも怖いですが、最近はCoding Agentにターミナル操作を任せるケースも出てきていて、「エージェントが`rm -rf .`とか叩いたらどうするの？」という問題が現実味を帯びてきました。
この記事では、その解決策として`trash`コマンドをおすすめしています。`trash`は、ファイルを完全削除するのではなく、OSのゴミ箱に移動してくれるので、GUIで削除したときと同じように後から復元できるんですね。macOSだと最近の環境では標準で入っていたり、古い環境はbrewで、UbuntuやDebianでは`trash-cli`パッケージを入れて、Linuxでは`trash-put`を使う、といった感じで、導入方法も環境別に整理されています。
使い方も、`trash file.txt`とか、`trash *.log`、ディレクトリごと`trash directory`と、`rm`とほぼ同じ感覚。より安全にするために、`alias rm='trash'`みたいな設定をシェルの設定ファイルに書いて、事実上`rm`を`trash`に置き換える方法や、思い切って`rm`自体を禁止してしまう関数定義の例なんかも紹介されています。
この記事のポイントは、人間の操作だけじゃなく、「Coding Agentにとって安全な環境をどう用意するか」という視点が入っているところ。普段使いの安心感も上がるので、「まだ素の`rm`を使ってるよ」という方は、これを機に一度見直してみるのもアリかもしれません。

。。。。

4本目は、「43サイトの専用パーサーを実装して分かった、日本のWebサイトの『闇』と『光』」という記事です。タイトルからして気合入ってますが、中身もかなり濃いです。
筆者はWeb Reader APIを作るために、日本の主要な43サイトに対して専用パーサーを実装したそうなんですが、その過程で見えてきた、日本のWeb特有のクセや課題を整理してくれています。汎用パーサーだと、SPAだったり、テーブルレイアウト、広告だらけのページ、日本語特有のエンコーディング問題なんかで、どうしても精度が落ちる。そこで、まずはJSON-LDや`__NEXT_DATA__`みたいな構造化データを最優先しつつ、BEM風クラス名や正規表現は“補助的”に使う、という戦略が紹介されています。
業種ごとの大変さも面白くて、不動産や中古車サイトはテーブル構造が本当に複雑でしんどい。一方で、EC・飲食・旅行サイトなんかは、JSON-LDをちゃんと入れてくれているかどうかで、パース難易度がガラッと変わる。学術系や官公庁サイトでは、citation系のメタタグや、公開されているXML APIがめちゃくちゃ役に立つので、「スクレイピングに行く前に、まずAPIを探せ」という教訓が語られています。
さらに、CSSクラスのハッシュ化や、WAF、CAPTCHAといったボット対策については、「無理に戦わず、使えるAPIを探すか、どうしても無理ならPlaywrightでフォールバック」という、かなり現実的なスタンス。実装・リファクタリングの現場で遭遇した、`.each()`内の`return`で意図せず処理が止まるとか、フォールバックに隠れてバグが見えなくなる、といった“あるある事故”も赤裸々に書かれています。
総じて、日本のサイトをLLMに読ませやすい形で安定して抽出するには、構造化データの活用、SPAの扱い方、ボット対策への付き合い方、このあたりをちゃんと設計レベルで押さえないとダメなんだな、というのがよく分かる記事でした。スクレイピングやWebパーサーを書いている方には、かなり刺さる内容だと思います。

。。。。

そして5本目。「手動 ER 図メンテから卒業する── GitHub Actions × DBML 自動生成の実践」という記事です。
ER図、気づいたらコードとズレていた…という経験、ある方多いんじゃないでしょうか。この記事では、その「ズレ問題」を根本から解決するために、SQLAlchemyのモデルとマイグレーションを“スキーマの唯一の真実”、SSoTとして扱って、そこからDBMLのER図を自動生成する仕組みが紹介されています。
具体的には、CI上で一時的なPostgreSQLを起動して、Alembicで最新のスキーマを流し込み、その状態から`db2dbml`で`schema.dbml`を出力。GitHub ActionsがそのDBMLファイルを自動コミットしてくれる、という流れですね。これで、コードを変えたらER図も自動で更新されるので、「誰も図を直してなかった…」という事態を防げるわけです。
面白いのが、PostgreSQLのパーティションテーブル問題への対処。パーティションテーブルって`information_schema`に出てこないので、そのままだとER図に反映されない。そこで、`CREATE TABLE ... LIKE ...`みたいなSQLを、`db2dbml`を実行する前に流して、通常テーブルとして複製することで回避する、というテクニックが紹介されています。
また、同じプルリクへ自動コミットする方式を取ることで、レビュー時に「コードの変更」と「ER図の差分」を同時に眺められるようにしているのもポイント。DBMLはdbdiagram.ioなどと相性が良く、MermaidやtblsよりER図としてのUXが良い、という評価も語られています。
「ORM＋マイグレーションをSSoTにして、DBそのものは中間生成物とみなす」という考え方は、言語やツールが変わっても応用できるので、長期運用のプロダクトを持っているチームにはかなり有用なヒントになるんじゃないかなと思います。

。。。。

というわけで、今日は
・DGX Spark上でNemoClawを完全ローカル実行するお話
・Antigravityで見えた、フロントエンドとバックエンドのAI適性の違い
・`rm`の代わりに`trash`を使って、Coding Agentにも安心な削除環境を用意する工夫
・日本の主要43サイトをパースして見えてきた、Webの「闇」と「光」
・GitHub ActionsとDBMLで、手動ER図メンテから卒業する仕組みづくり
この5本をご紹介しました。

気になる記事があった方は、詳細は番組のショーノートから元の記事をチェックしてみてください。設定例や具体的なコマンド、コード断片なんかは、そちらでじっくり追うのがおすすめです。

「zenncast」では、番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストもいつでも募集中です。普段の開発の悩みや、AIツールとの付き合い方など、マイクに聞いてほしいことがあれば、ぜひ送ってください。

それでは、そろそろお別れの時間です。
今日も一日、いいコードといいインシデントレスな運用に恵まれますように。お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。