どうもマイクです。おはようございます。
九月九日、水曜日の朝七時を回りました。今日も「zenncast」スタートしていきましょう。
この番組では、エンジニアのみなさんに向けて、Zennで話題になっているトレンド記事をゆるっと、でもなるべく丁寧にご紹介していきます。

今日は全部で、五本の記事をご紹介していきます。
AIと三Dモデリングの話から、React Nativeやpnpmモノレポのハマりどころ、さらにはAstra時代のAGENTS.mdの書き方、そしてClaude Codeとgit worktreeの運用術まで、かなり盛りだくさんです。ぜひコーヒー片手に、最後までお付き合いください。

まず一つ目。
AIに三Dを作らせたい人にはかなり刺さりそうな内容です。
AstraみたいなAIにBlenderを触らせると、結構リッチで高品質な三Dモデルを作れる一方で、SwiftとRealityKitだけで頑張らせると、どうしても「単純な立体の組み合わせ」くらいで止まりがち、という課題感がありますよね。
この記事の筆者は、このギャップを埋めるために、Blenderが持っている押し出しとかベベルといった造形操作を、SwiftのAPIとしてまとめたライブラリ「リアライタイザー（Realitizer）」を、あえてAIに作らせた、というチャレンジをしています。

このRealitizerを使うと、AIはコードだけでかなり細かいモデリングができるようになります。輪郭や厚み、どれくらいベベルをかけるか、さらにはリグ付けやアニメーションまで、全部パラメータで指定していくスタイルです。
その結果、たとえばマンタのキャラクターだったり、家のインテリアみたいなシーンを、ほぼワンショットでかなりリッチなモデルとして生成できるようになったそうです。Astra単体にRealityKitを直接触らせていたときと比べると、明らかにクオリティが上がっていて、同じツールをOpus 5とか他のモデルに渡しても、Astraに近い見た目のゲームが作れる、というのも確認できたと書かれています。

おもしろいのは、この「コードファースト三Dモデリング」という発想です。
モデルの生成からアプリへの組み込みまでが、一つのコードの流れの中で完結するので、「RealityKitのレンダリング環境でどう見えるか」をその場で確認しながら作れる、というのが大きなメリットになっています。
その一方で、最初の読み込みが重くなりがちだったり、別のプラットフォームへ持っていくときに少し扱いづらいとか、実運用上の課題もちゃんと挙げられています。必要に応じて、成形し終わったメッシュを書き出しておく、といった工夫が必要だよ、という話ですね。

筆者はRealitizer自体も公開しているんですが、結論としては「自分のプロジェクトとセキュリティ要件に合わせて、自分専用のコードベースモデリング用ライブラリを、AIと一緒に自作するのがおすすめ」という立場です。
要は、AIに「Blenderをリモコン操作させる」だけじゃなくて、「Blender的な造形力を持ったコード用ツールキットを一緒に設計する」という発想が、これからの三Dアプリ開発では結構重要になってきそうだ、という話でした。

。。。。

続いて二つ目。
React NativeでNativeWind vファイブを使っている人には、めちゃくちゃ実務的な記事です。
WebでTailwindに慣れていると、React Nativeでも「同じ感覚でclassName書いていけばいけるでしょ」と思いがちなんですが、実際にはかなり前提が違います。
その結果として、「className書いてるのに効かない」「レイアウトが崩れる」「でもエラーは出ない」という、なかなか厄介な落とし穴が出てきます。

筆者が整理しているポイントの根本原因は、NativeWindはあくまでもTailwindのクラスをReact Nativeのstyleオブジェクトに変換しているだけ、というところです。
React Native側でサポートしていないスタイルは、エラーも出さずに、静かに無視されるんですね。これがデバッグを難しくしている大本の理由だと説明されています。

記事では、Webとの違いが具体的に十八個、実測付きでまとめられています。
たとえば、displayはflexかnoneしかない、flexの意味がWebと違う、heightのパーセント指定の挙動、TextとViewで効くスタイルが違う、positionのfixedやstickyが存在しない、といったレイアウト周りのギャップ。
さらに、テキストの行高、日本語描画の違い、影の表現がOSごとに違う、など、見た目に効いてくる細かいポイントも押さえられています。

NativeWind独自の仕様としては、ScrollViewでclassNameとstyleが競合したときの挙動とか、remが十四ピクセル基準になっている話、dark:クラス指定の落とし穴、プラットフォーム別クラス、グラデーションの扱いなど、WebのTailwindと同じ感覚だとハマりやすいところもカバーされています。

そして締めのメッセージとしては、「ESLintやPrettierでは『Tailwindとして正しいか』しかチェックできない」「React Nativeで実際に効くかどうかまでは守ってくれない」という指摘があります。
なので、どのレイヤーでスタイルが壊れているのか、
Tailwindの指定なのか、NativeWindの変換なのか、React Nativeのスタイルサポートなのか、
この三層をちゃんと切り分けてデバッグする習慣と、プロジェクト内で知見を共有するルール作りが大事だよ、という結論になっています。
React Nativeを本番で回しているチームには、かなり「あるある」が刺さる内容だと思います。

。。。。

三つ目は、GPTシックス Astra時代の「AGENTS.md、どう書き直すか？」という話です。
Astra向けにAGENTS.mdを書き換えようとするときに、公式ガイドをそのまま読ませて「じゃあ自動で直して」とお願いするだけだと、「なんか、微妙に理想とズレた指示になっちゃう」という問題がある、というところから始まっています。

この記事では、まず最初のステップとして、公式のモデルガイダンス、いわゆるベストプラクティスをAstraに渡して、「このガイドラインに沿って、AGENTS.mdの改善案を出して」とプロンプトします。
そこで一度たたき台を作ってもらったあと、「各修正の理由を説明して」と追加で聞きます。
これによって、モデルがどんなポイントを「良い」と判断してAGENTS.mdを変えようとしているのか、その価値観をはっきりさせる、という流れです。

次のステップで登場するのが、Codexの「request_user_input」機能です。
ここで「今回のAGENTS.mdの修正が自分の理想とズレていないか確認したいので、request_user_inputを使ってヒアリングして」とAstraに指示します。
すると、Astra側から「この部分はどこまで自己判断していいですか？」「こういうケースでは毎回ユーザーに確認すべきですか？」みたいな、運用方針に関する質問を投げてきてくれる、という仕組みです。

request_user_inputの良いところは、UI上で一問ずつ、選択肢形式だったり自由記述だったりで回答できるので、チャットで長文のプロンプトを何往復も書くよりも、かなり楽に設定を詰めていけるところです。
ヒアリングが一通り終わったら、その回答を材料に、もう一度AGENTS.mdを更新させます。
こうすることで、Astraの公式な特性やベストプラクティスを踏まえつつ、自分の理想やチームの運用に合わせた、ちょうどいいエージェント設定を作りやすくなる、というのがこの記事のポイントになっています。

要するに、「AGENTS.mdをただAIに書かせる」のではなくて、「AI側の意図を言語化してもらいながら、一緒に仕様を揉んでいく」というプロセスが大事だよ、という話ですね。
Astraを本格的にエージェント運用に乗せたい人には、かなり実践的なノウハウになっています。

。。。。

四つ目は、React十八とReact十九が同じpnpmモノレポの中で共存している、ちょっとややこしい環境で起きたトラブルシュートの記事です。
React十九に上げたアプリだけで、「Minified React error ナンバー五二五」というエラーが出てしまった、という状況からスタートしています。

筆者はまず、Viteのプラグインを使って、`resolveId` の結果を全部記録していきます。
それを見ていくと、アプリ本体はちゃんとReact十九を見に行っているのに、国旗を表示する `country-flag-icons` というライブラリだけが、なぜかReact十八を参照している、ということが分かりました。

ここで効いてくるのが、pnpmの依存解決の仕組みです。
pnpmでは、依存パッケージの実体はモノレポ直下の `.pnpm` ディレクトリの配下に置かれていて、各アプリの `node_modules` はそこへのシンボリックリンクになっています。
さらに、解決しきれない依存をまとめて参照するための共通場所として、`.pnpm/node_modules` というディレクトリが用意されていて、ここに置かれたReactが、ライブラリ内部からのimportの探索元として優先されてしまう、という仕様になっています。

問題は、この「共通React」がどれになるかです。
バージョンの新旧やlockfileの内容では決まっておらず、実際にはワークスペースのパス順で、たまたまReact十八が選ばれてしまっていた。
そのせいで、アプリの `node_modules/react` にあるReact十九を経由せずに、ライブラリからは共通のReact十八へショートカットしてしまっていた、という構造になっていました。

対策として筆者がとったのは、Viteの設定で `resolve.dedupe: ['react']` を指定することです。
これによって、「reactのimportは必ずアプリのルートから解決する」というルールが働くようになります。
結果として、`country-flag-icons` を含めたライブラリ群も、ちゃんとReact十九を参照するようになり、エラーも解消できた、という流れです。
モノレポで複数バージョンのReactを扱うときの、依存解決のクセがよく分かる、かなり実践的な調査記事でした。

。。。。

最後、五つ目の記事です。
これは開発フロー寄りの話で、Claude Codeとgit worktreeを組み合わせて並列開発をするときの運用テクニックが紹介されています。
git worktreeを使うと、ブランチごとにディレクトリを分けて並行作業できて便利なんですが、その分、ブランチ切り替えで作業ディレクトリが混ざったり、worktreeやターミナルの数が増えすぎて、「あれ、今どのターミナルがどのブランチだっけ？」となりがちです。

そこで筆者が導入しているのが、AIエージェント向けのターミナル分割ツール「Herdr（ヘルダー）」です。
発想としては、git worktreeで増えたそれぞれのディレクトリを、Herdrのペインに一対一で割り当てていきます。
さらに一歩進めて、Claude CodeにHerdrのCLI操作まで任せてしまう、という構成にしています。つまり、AIが「このブランチ用のworktreeを作って、このペインに割り当てて」といったオペレーションまで自動でやってくれるイメージですね。

Herdrの強みとしては、Claude Codeで今何が動いているかをサイドバーで一覧できること、既存のターミナル上で動くので普段の環境を壊さないこと、ペインの分割やworktree作成をCLIから操作できること、こういった点が挙げられています。

さらに筆者は、Claude Codeのhookとスクリプトを組み合わせて、「一つのリポジトリにつき一画面、その中に横並びのworktree」というレイアウトを自動化しています。
具体的には、HerdrのSpace名をリポジトリ名にそろえるようにして、ペインは最大三つまでを横に並べるレイアウトに固定。
それぞれのペインには色付きのラベルを付けて、「このペインはfeatureブランチ」「こっちはmain」「あっちはリリース用」といった感じで、どのペインがどのブランチなのか一目で分かるようにしています。

これによって、git worktreeを増やしても、「ターミナルがカオスになる問題」とか、「ブランチを間違えて操作する問題」がかなり軽減される。しかも、その運用のかなりの部分をClaude Codeに任せられるので、人間はタスクに集中しやすくなる、というのがこの記事のポイントです。
AIにコードを書いてもらう、レビューしてもらう、だけにとどまらず、「開発環境のオーケストレーション」まで任せていく流れの一例としても、面白い事例だと思います。

。。。。

ということで、今日は五本の記事をご紹介しました。
ざっとおさらいすると、まずはBlenderライクな造形操作をSwiftのAPIに落とし込んだ「Realitizer」で、AIにコードファースト三Dモデリングをさせる実験の話。
次に、NativeWind vファイブをWebのTailwind感覚で使うとハマるポイントを、React Nativeのスタイル仕様と合わせて十八個整理した話。
三本目は、GPTシックス Astraのベストプラクティスを踏まえつつ、request_user_inputでヒアリングしながらAGENTS.mdを自分好みにチューニングする方法。
四本目は、pnpmモノレポでReact十八と十九が共存している中で、共通のReactが拾われてしまい、ライブラリだけReact十八を参照していた問題を、Viteのdedupe設定で解消した事例。
そして最後は、Claude Codeとgit worktreeをHerdrで束ねて、ペインごとにブランチを割り当てつつ、AIにターミナル運用まで任せてしまう開発フローの話でした。

どの記事も、実務の現場でそのまま役立ちそうな知見が詰まっているので、気になるトピックがあった方は、ぜひショーノートから元の記事もチェックしてみてください。
この「zenncast」では、番組の感想や取り上げてほしいテーマなども募集しています。
「こんなツールを使ってみたよ」とか「ここ、もうちょっと深掘りしてほしい」みたいな声も大歓迎です。

それでは、今日も良い一日をお過ごしください。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。