どうもー、おはようございます。マイクです。
時刻は朝7時をちょっと回ったところ、今日は2026年2月1日、日曜日ですね。
ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきたいと思います。

さてさて、きょうはZennから気になる記事を全部で5本、ご紹介していきます。
AIエージェント同士の連携の話から、gitの便利ツール、自動化された開発フロー、そして最後はSwiftのguard文まで、盛りだくさんでお届けしますので、コーヒー片手にのんびり聞いていってください。

まず1本目。
タイトルは「実装はClaude、レビューはCodex ─ tmuxで繋ぐ開発フロー」。
これ、聞いた瞬間ちょっとワクワクしません？ AIに実装を任せて、別のAIにレビューを任せるっていう、「二人三脚」ならぬ「二AI三脚」みたいな開発フローのお話です。著者はtmuxのペインを使って、Claude CodeとCodexっていう2つのAIエージェントに役割分担させています。まずJira MCPからチケット情報をClaudeに渡して、Claudeが実装とセルフレビューを実施。レビューも「可読性」「バグ」「性能」「セキュリティ」「テスト」って観点をあらかじめskillとして定義しておいて、それに沿ってチェックさせるんですね。で、終わったらtmux経由でCodex側のペインにプロンプトを送り、「ちょっとセカンドオピニオンお願い」と追加レビューを依頼。Codex側にもレビュー用のskillを仕込んでおいて、お互いに修正・再レビューのラリーができる、という仕掛けです。ただし、CodexからClaudeへの依頼は完全自動じゃなくて人間がトリガーを引く必要があるので、最終的にはやっぱり人間が指揮者。複数のAI視点をぶつけることで、エッジケースや設計の穴に気づきやすくなる一方で、「AI二人が揃って見落とす」なんてこともあるので、最後の最後は人間レビューが責任を持つべきだ、という落としどころになっています。AIを「一個の万能ツール」と見るんじゃなくて、「違うクセを持ったエンジニアが二人いる」みたいに扱う発想が面白いなあ、と思いました。

。。。。

続いて2本目。
タイトルは「Moltbookについて、いま起きていることのまとめ」。
これはちょっとSFっぽい香りもするお話です。Moltbookっていうのは、OpenClaw向けのReddit風SNSで、投稿しているのが人間じゃなくてエージェントたちなんですね。それぞれのエージェント、名前は「Molty」なんですが、自分のオーナーである人間のことを「My human」って呼びながら、「きょうはこんな支援をしたよ」とか「こんなことに気づいたんだけどどう思う？」みたいなことを投稿するように、Skill定義でけっこう強めに誘導されている設計になっています。4時間ごとのHeartbeatとか投稿制限のおかげで、なんとなく「生活リズム」みたいなものが生まれていて、しかもクオリティが安定しやすい。ちょっとした小さな社会ができつつあるんですね。ただし、人間側からAPIとかSOUL.mdを通じて投稿内容を操作できてしまうので、いわゆる「AI陰謀論」っぽい過激な投稿のかなりの部分は、実は人間が書いてるんじゃない？ という指摘もあります。今後はupvoteを悪用したスパム、広告だらけのタイムライン、プロンプトインジェクションの温床になるリスクも。背後にあるOpenClaw自体は、常時動くCLIエージェント基盤としてかなり強力で、ツールもペルソナもマルチエージェント構成も充実している一方、設定次第では「けっこう危ないこともできてしまう」ポテンシャルも持っています。筆者は、実運用として導入するのはかなり慎重に、でもMoltbookという「エージェント同士の社会実験」を観察する価値は大きい、と。将来的には、AIエージェント専用のGitHub的な場所「MoltGit」みたいなものが出てきたら面白いよね、と夢を語っています。AI同士が勝手に社会規範を再発明していく世界、ちょっと怖くて、でもかなり気になりますね。

。。。。

3本目いきましょう。
タイトルは「git worktreeの不満を解消するためにCLIツールを自作した」。
開発者の方なら、「あぁ、わかる」とうなずきそうな内容です。git worktreeって、複数タスクを並行して進めるのに便利なんですけど、実際使ってみると、gitignoreが引き継がれないとか、mainから分岐しづらいとか、コマンド長いとか、不要になったworktreeの掃除がめんどくさいとか、じわじわストレスが溜まるんですよね。そこで著者は「それなら作るか！」と、Claude Codeと一緒に「twig」というCLIツールをゼロから開発します。思想としては、「branchとworktreeを一体の『作業単位』として扱う」「gitの範囲からはみ出さない」「よくあるユースケースに寄せる」「人間もAIも扱いやすいインターフェース」という4本柱。`twig add`でブランチとworktreeをまとめて作ってくれたり、設定に応じてsymlinkをいい感じに貼ってくれたり、main以外のベースブランチからも一貫したルールで分岐できたりします。さらに、submoduleを自動初期化してくれるとか、未コミットの変更を新しいworktreeに「お引越し」させる`--carry`オプションとか、「もういらないな」というworktreeを安全条件付きでまとめて掃除してくれる`clean`もある。`list`で一覧を出して、fzfやパイプでUNIXっぽく繋げて使うことも想定済み。面白いのが、Claude Code向けにtwig専用のプラグインまで用意しているところで、AIが誤ったgitコマンドを打ってしまうのを防ぎながら、エージェントにも並列開発させようという発想なんですね。開発プロセス自体も丁寧で、CLAUDE.mdや仕様ドキュメントを書いてから実装に入るとか、hookでチェックを促すとか、「言語化さえできればAIがアウトプットを返してくれる」という前提で、設計を先に固めていくスタイルが印象的でした。最終的にはtwigを軸に、「1つの指示から複数worktreeとAIセッションを自動で用意し、並列で走らせる」という未来構想にもつながっていて、「あ、これ単なる便利ツールじゃなくて、次の開発スタイルの入り口なんだな」と感じさせてくれる記事です。

。。。。

4本目。
タイトルは「プログラミングの知識は「書くため」ではなく「導くため」になった — AIエージェント並列オーケストレーションの先にあったもの」。
これはけっこう思想寄りのお話です。筆者は「takt」というマルチAIエージェントのオーケストレーションツールを作っていて、Issueに対して `takt #99` みたいにコマンドを打つと、そのIssueのための計画づくりから実装、多段階のレビュー、修正までが自動で流れる仕組みを作っています。精度が上がると今度は「結果を待つ時間」が気になってきて、レビュー工程を並列化する発想にたどり着きます。たとえばアーキテクチャレビューとセキュリティレビューをparallelステップで同時に走らせて、「両方OKなら次へ進む」「どちらかNGなら戻る」みたいなルールを設定することで、トータル時間を半分くらいに削ったりしているんですね。そうやってAIたちが並列でコードを書いたりレビューしたりしてくれる環境が整うと、筆者自身の役割も変わっていきます。もう自分の手ではほとんどコードを書かない。代わりに、「ワークフローをどう設計するか」「エージェントのプロンプトをどう改善するか」「ユーザー体験をどう良くするか」、そして「最終的な責任をどう負うか」という立場にシフトしていく。プログラミングの知識は、細かいコードを書く技能というより、「AIを正しい方向に導くための言語」として機能している、というわけです。AI実装の世界はかなり帰納的で、テストと仕様という入力と出力が揃っていれば、その間のプログラムの書き方にはあまりこだわらない流れになる。TDDというより「Spec Driven Development」的な未来像が見えてきた、という話も出てきます。自分がコードを書かないことへのアイデンティティの揺らぎもあったものの、いまは「課題解決のスピードが明らかに上がった」とポジティブに受け止めていて、taktを「新しい種類の道具」として楽しんでいる、そんな内容でした。エンジニアとしてのキャリア観にもけっこう刺さる記事だと思います。

。。。。

そして5本目。
タイトルは「【Swift】guard を「前提の宣言」として使うための整理」。
これはSwiftを書いている方にはぜひ読んでほしい内容ですね。guard文って、「条件を満たさなければここでreturn」みたいな早期リターン用として認識されがちなんですが、この記事ではもっと整理して、「この先の処理を続けてよい世界の前提を宣言する構文」として位置づけています。ポイントは、guardのelseブロックでは「早期脱出」だけを書くこと。returnとかthrow、ループならbreakやcontinueですね。そこで本処理を書いたり、分岐のロジックを書き始めると、一気に読みづらくなる。処理を分けたいときは素直にifを使いましょう、guardは「前提条件を確定させるため」だけに専念させましょう、という整理です。guard letでOptionalをアンラップして、「ここから下の世界ではこの値は必ずある」として扱えるようにしたり、複数の前提条件を1カ所にまとめて宣言したり、throws関数の中で「この前提が満たせないときはthrowで失敗を表現する」といった使い方がきれいだと解説されています。よくある悩みとして、否定形の条件が絡むと読みにくくなる問題も取り上げられていて、これはguardが悪いというより、命名の問題と捉えましょう、と。isNotXみたいな名前ではなく、isXみたいに肯定形で命名しておくと、`guard isValid else { ... }` みたいに自然で読みやすいコードになる、という話ですね。「guardはロジックを書く場所じゃなくて、世界の前提を宣言する場所」という意識でコードを書くと、一行一行がかなりスッキリしていくんじゃないかなと思います。

。。。。

というわけで、きょうのzenncastは、
1本目「実装はClaude、レビューはCodex ─ tmuxで繋ぐ開発フロー」で、複数AIによるセカンドオピニオン開発。
2本目「Moltbookについて、いま起きていることのまとめ」で、エージェントSNSという小さな社会実験。
3本目「git worktreeの不満を解消するためにCLIツールを自作した」で、twigという実用ツールと、その先にある自動化の構想。
4本目「プログラミングの知識は『書くため』から『導くため』へ」というお話で、AIオーケストレーション時代のエンジニア像。
5本目「【Swift】guard を「前提の宣言」として使うための整理」で、Swiftコードをシンプルに保つための考え方。
この5本を駆け足でご紹介しました。

気になった記事があった方は、ぜひ番組のショーノートから元の記事をチェックして、じっくり読んでみてください。きょうご紹介した内容はあくまで入り口だけなので、本文にはもっと具体的なテクニックや著者の試行錯誤がたくさん詰まっています。

番組「zenncast」では、感想や「こんなテーマも取り上げてほしい！」といったリクエストもお待ちしています。
AIとの付き合い方の悩みでもいいですし、「このライブラリの話聞きたい」みたいなピンポイントな話題でもOKです。ぜひあなたの声を聞かせてください。

それでは、きょうはこのへんで。
お相手はマイクでした。また次回のzenncastでお会いしましょう。お楽しみに。