どうも、マイクです。おはようございます！
2026年1月29日、木曜日の朝7時を回りました。ここからの時間は「zenncast」、きょうもZennで話題になっているトレンド記事を、ラジオ感覚でゆるっと紹介していきます。通勤や通学の準備をしながら、耳だけ貸してもらえたらうれしいです。

さて、今日は全部で5本の記事をご紹介していきます。AIエージェントのワークフロー、次世代のGitクライアント、宇宙からの地球観測データ、Claude Codeの小技、そしてDockerビルド高速化まで、技術好きにはたまらないラインナップでお届けします。

まず1本目。
タイトル「AIの見張り番をやめよう - AIチームを指揮するOSS『takt』を公開しました」。
AIエージェントに開発を任せていると、「役割を忘れちゃう」「レビュー飛ばして次行っちゃう」みたいな、あるある問題がありますよね。結局、人間が横で「ちゃんとレビューした？」「それ誰がチェックするの？」って見張り番になっちゃう。この記事の作者は、そこをガチで解決しようとしていて、「自由に動き回るAI」じゃなくて「強制力のあるワークフローで動くAI」に振り切ったOSS、「takt」を作りました。
YAMLで「実装 → レビュー → 修正」みたいな流れを定義しておいて、エージェントの出力にステータスを埋め込ませることで、機械的に次のステップに進ませる。これによって、「レビュー忘れてそのままマージしちゃった」みたいな事故を防ぐ、というアイデアです。ビルトイン・カスタム両方のエージェントを登録できたり、セッションを永続化してタスクキューで監視実行できたり、レポートも自動生成してくれたりと、かなり「実務を回すための道具」って感じの作り。Claude CodeとOpenAI Codexの両方に対応していて、複数エージェントをチームとして動かす指揮官、みたいな役割を担わせる構想になっています。自由度より再現性と品質を優先しているので、「とにかく安定して同じフローを回したい現場」に刺さりそうですね。ちなみにこの記事自体も、taktのワークフローを使って書いたそうで、最後だけ人間がチェックしたと。AIと人間の役割分担が、ちょっと未来のドキュメント制作現場を先取りしてる感じがしました。
。 。 。 。

続いて2本目。
タイトル「Git の次へ。jj（Jujutsu）が変えるバージョン管理の常識」。
Gitを日常的に使っている人、多いと思いますけど、「ステージングエリアってなんなん？」「うっかり変な状態になった…」みたいなストレス、ありますよね。この記事で紹介されている「jj」ことJujutsuは、GoogleのエンジニアがRustで作っている次世代VCSで、既存のGitリポジトリの上にかぶさる「レイヤー型ツール」です。なので「Gitを捨てる」のではなく、「jjの世界の操作感でGitリポジトリを扱う」というイメージ。
大きな特徴が「ステージングエリアをなくす」こと。ワーキングコピーが「常にコミット」で、いわゆる「ダーティ状態」がない。`add`とか`stash`を意識せずに、コミット同士を自由に行き来しながら、自動リベースで履歴をきれいに保ってくれます。コンフリクトがあっても、とりあえずコミットしておいて後でまとめて直せるとか、全ての操作がオペレーションログとして残っていて、`jj undo`で簡単に巻き戻せるとか、「Gitでやりたかったけどちょっと怖かった操作」が、かなり安全に扱えるようになる設計なんですね。
さらに、Revsetsという強力なクエリで、複雑な条件でコミットを検索できたり、チェックアウトなしで任意リビジョンをいじれたりと、Gitにはない発想が盛り込まれています。一方で、GitHub上のレビュー体験とか、IDEの統合、エコシステムはまだ発展途上。メンタルモデルもGitとけっこう違うので、慣れは必要そうです。ただ、Gitと完全互換で、`jj git init --colocate`で同じディレクトリに両方置いて試せるし、気に入らなければいつでも撤退できるロックインなし設計。個人的には、「チームの一部だけが試しにjj使ってみる」とか、「個人開発から徐々に切り替えてみる」のにちょうどいいポジションのツールだなと感じました。
。 。 。 。

では3本目。
タイトル「JAXAが公開したMCPサーバーを触ってみる」。
これはちょっとロマン枠ですね。JAXA Earth APIという、宇宙からの地球観測データを扱えるサービスがあります。標高、地表面温度、海面水温、降水量など、いろんな地球の状態を、範囲と期間を指定して取得できる。PythonやJavaScriptのライブラリ、QGISプラグインも用意されていて、本格的な解析にも使えるようになっています。
この記事は、そのJAXAのEarth APIを、MCPサーバー経由でClaude Desktopから使うための手順をまとめた備忘録です。`uv`でプロジェクトを作って、`mcp`と、PyPI外で配布されている`jaxa-earth`を`extra-index-url`付きでインストール。JAXA公式が提供している`mcp_server.py`を配置して設定します。その上で、`claude_desktop_config.json`の`mcpServers`に「`uv run mcp_server.py`」を登録しておいて、Claude Desktopを再起動すると、JAXA Earth APIが「ツール」として使えるようになる、と。
これが何を意味するかというと、「2025年12月の関東地方の地表面温度の画像ちょうだい」と、自然言語で頼むだけで、裏でJAXAの観測データを叩いて、画像を生成・表示してくれる世界がすでに来ている、ということなんですよね。筆者も「宇宙からの観測データを言葉で呼び出せるの、すごい時代では？」と驚きを語っていて、同時に「これをきっかけに、地球観測データに触れる人が増えてほしい」と期待を書いています。
さらに、別の読者から「もっと簡易設定でやるなら、わざわざプロジェクトディレクトリを作らずに、`claude_desktop_config.json`の`uv run`のところに`--with mcp`や`--with jaxa-earth`、`extra-index-url`を直書きして、ダウンロードした`mcp_server.py`のパスを渡す方法もあるよ」という実践的なTipsも共有されていて、「手元の環境でまず触ってみたい人」にとってありがたい情報がまとまっています。
。 。 。 。

4本目の記事。
タイトル「Claude CodeのPlanモードで実装した後、そのまま質問しまくってるやついる？いねえよな！」。
タイトルからしてノリがいいんですけど、内容はかなり実践的なTipsです。Claude CodeのPlanモードでコードを書いてもらったあと、そのまま「ここどういう意図？」「この設計パターンのメリットは？」みたいな質問を延々と続けてしまうと、会話ログがどんどん膨らんで、コンテキストを圧迫してしまいます。公式ドキュメントにもあるように、コンテキストが無駄に膨らむと、モデルのパフォーマンスが落ちる原因になるんですよね。
で、本筋に戻って「ここを変更して」「テストコードを書いて」みたいな具体的な作業を頼むときに、それまでの大量の質問ログがノイズになる。これを避けるために、この記事が推奨しているのが、質問フェーズが一段落したら`/rewind`コマンドで会話だけを巻き戻す運用です。実装結果やファイルはそのままにして、「会話の履歴だけなかったことにする」というイメージ。これでコンテキストをすっきりさせた状態で、次の作業依頼ができるようになります。
もうひとつのテクニックが`/fork`。Planモードでの実装セッションを本筋として残しつつ、質問ベースの調査用に別ターミナルを分岐させることで、「実装」と「調査」を物理的に分けて進められるようになります。「パワハラ質問タイム」は別セッションでやって、本番セッションには余計なログを残さない、という考え方ですね。Claude Codeをヘビーに使っている人ほど、「なんか最近レスポンスの質が落ちてきたな…」と思ったら、一度コンテキストの整理と`/rewind`、`/fork`の運用を見直してみるといいかもしれません。
。 。 。 。

そして最後、5本目。
タイトル「GitHub ActionsでDockerビルドを高速化する：並列化・キャッシュ・ARMビルドの実践ガイド」。
これはデプロイに30分、40分かかっていて「つらい…」と思っているインフラ担当・SREの方に刺さる記事です。SST v3で自動Dockerビルドを回していたところ、デプロイに30分超かかるようになってしまい、しかもPulumi経由で並列ビルドされるせいでログが混ざり合い、どこで何が起きているのか分析しづらい状況になっていたそうです。
そこで筆者は、DockerビルドをSSTから切り離し、GitHub Actionsに集約。まずはテナント×サービスをマトリックスで並列ビルドできるようにしつつ、そのマトリックス自体を`jq`で動的に生成することで、可読性と保守性を両立させています。GitHub Actionsの同時ジョブ上限が256なので、そこを踏まえた設計もポイント。
キャッシュ戦略もかなり工夫されていて、GitHub Actionsのキャッシュは10GB制限があるため、代わりにECRのRegistry Cacheを利用。`mode=max`や`oci-mediatypes`といった設定で、マルチステージビルドやECRとの相性を最適化しています。また、Provenanceを無効化して、不要なECRイメージが量産されるのを防ぎ、コストを抑える工夫も。GITHUB_TOKENはDockerfileのARGではなく、secretマウントで渡すことで、キャッシュを効かせつつセキュリティも担保しています。
ARMビルドに関しては、QEMUによるエミュレーションが遅くて不安定、かつGitHubのLarger Runnersが使えない制約の中で、CodeBuildベースのセルフホストARMランナーを導入。起動時間やコスト、安定性を比較検討しながら、実用的なラインを探っています。その結果、`sst deploy`自体は5〜10分程度、Dockerビルドに至ってはキャッシュヒット時で1分未満まで短縮できたとのこと。読み終わるころには、「自分のCIもそろそろ見直すか…」という気持ちにさせられる、かなり実践的なガイドになっていました。

というわけで、きょうの「zenncast」、駆け足で振り返ると……
1本目は、AIエージェントを「見張る」んじゃなくて、「ワークフローで指揮する」OSS「takt」のお話。
2本目は、Gitのステージングエリアを捨て去る次世代VCS「jj（Jujutsu）」。
3本目は、JAXA Earth APIをMCPサーバー経由でClaude Desktopから呼び出す、宇宙データ活用の第一歩。
4本目は、Claude CodeのPlanモードを快適に使うための`/rewind`と`/fork`のコンテキスト整理術。
そして5本目は、GitHub ActionsでDockerビルドを並列化とキャッシュで爆速にする実践ガイドを紹介しました。

気になった記事があれば、このあとショーノートからぜひ元の記事もチェックしてみてください。番組の感想や、「このテーマもっと深掘りしてほしい！」といったリクエストも、どしどしお待ちしています。

それでは今日はこのへんで。
お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。いってらっしゃい！