どうもー、おはようございます。金曜日の朝、いかがお過ごしでしょうか。マイクです。
今は2026年1月16日、金曜日の朝7時台ということで、今日も「zenncast」スタートしていきます。
この番組は、エンジニアのみなさんと一緒に、Zennで話題になっているトレンド記事をゆるっと、でも中身はしっかりめにチェックしていく番組です。通勤・通学中の方も、これから作業を始める方も、コーヒー片手に耳だけ貸してもらえたらうれしいです。
さて今日は、Zennで今ホットな記事を、全部で5本ご紹介していきます。Claude Code、エージェント、Skill、アーキテクチャの話まで、AIまわりの実践ネタがぎゅっと詰まってますので、最後までお付き合いください。
まず最初の1本目です。
タイトルは「Claude CodeとCodexの連携をMCPからSkillに変えたら体験が劇的に改善した」。
これ、Claude Code と Codex CLI をつないで開発している人には、かなり刺さる内容だと思います。もともと著者は Codex を MCP サーバーとしてつないでたんですが、「実行中に何が起きてるか見えない」「長時間無応答になって不安」「タイムアウトさせるべきか判断しづらい」「エラーになっても中身がよくわからない」という、ありがちな悩みを抱えてたんですね。
そこで発想を変えて、Codex を「MCPツール」じゃなくて、Claude Code の「Skill」として生やしてしまった。中では `codex exec --full-auto ...` みたいなコマンドを叩くだけのシンプルなスキルなんですけど、これで何が変わったかというと、Codexのターミナル出力がリアルタイムで見えるようになったんです。進捗もエラーも目で追えるから、「あ、今ここで詰まってるんだな」とか「このログを見て中断しよう」といった判断がしやすくなる。
さらに、スラッシュコマンドで `/codex` って打てばサッと呼び出せるようにしていて、Claude が Codex をどう使って問題を解いていくか、そのプロセスを横で観察できるんですね。これがそのまま自分の学習にもつながる。著者としては、「長時間走る系のツールはMCPに突っ込むより、Skillにして人間からも様子が見える構成にしたほうが幸せになりやすいよ」という提案でした。AIにまかせきりにするんじゃなくて、「人間の視界にログを戻してくる」っていうのがポイントですね。
。。。。
続いて2本目。
タイトルは「『横のガードレール』でAIにアーキテクチャを教えるのをやめた話」。
これは「AIにクリーンアーキテクチャ＋DDDでちゃんと実装してもらいたいんだけど、だんだん崩れていく問題」にガチで向き合った記事です。設計方針を文章でどれだけ説明しても、長いセッションを続けるうちに依存関係がじわじわ壊れていったり、戻り値の型が雑になったり、気づくと「いつものスパゲッティ」に戻ってしまう……という経験、ある方も多いんじゃないでしょうか。
著者はそこで「もう口で教えるのやめよう」と。代わりに「横のガードレール」と呼ぶ静的検査の仕組みをTypeScriptで作り込みます。ESLint でチェックできるものは eslint-plugin-boundaries などを使ってレイヤー依存をガチガチに固定しつつ、それでも ESLint ではつらいところ、たとえば OpenAPI の仕様と実装がちゃんと一致しているか、リポジトリの戻り値は必ず Result<T> 型になっているか、ドメインイベントに必要なメタ情報が全部入っているか、こういう細かいルールを「独自ガードレール」として追加していく。
面白いのは、これをすべて runGuard というコマンドで一括実行できるようにしている点と、ソースコードに @what / @why / @failure みたいなコメントを書いて、「このチェックは何のためにあるのか」「失敗したら何が起こるのか」を明文化しているところです。AIがそれを読んで、「あ、じゃあこのエラーはこう直せばいいんだな」と自律的にアーキテクチャに沿う方向で修正してくれる。pre-push で ESLint とこのガードレールを全部流すことで、「レビューで怒る」のではなく「仕組みで守る」状態を作っているんですね。
著者はこのスタイルを「自律駆動」と呼んでいて、人間がいちいち設計警察になるのではなく、AIと人間の両方がテストと静的検査に導かれて、自然とアーキテクチャ品質が保たれるようにする、そんな発想が印象的でした。
。。。。
3本目の記事です。
タイトルは「Claude Codeの並列実行を効率化する管理アプリを作った」。
これは、Claude Code で複数セッションを並列に動かしている方には「わかる〜」ってなる話だと思います。ターミナルを3つ4つ開いて、あちこちでエージェントを走らせていると、「このターミナルは今何やってたっけ？」「どれが入力待ちで、どれがまだ考え中？」って完全に迷子になるんですよね。結果として、人間が状態を把握できないせいで、並列化したはずなのにあんまり効率が上がらない。
筆者はここで、「ボトルネックはもうAIじゃなくて人間の応答速度と状態把握なんだ」と整理します。そこで Claude Code Hooks と WebSocket を使って、セッションごとのイベントを収集し、それをReactで作ったダッシュボードにリアルタイム表示する「Claude Code Monitor」という管理アプリを自作しました。
機能としては、「複数セッションの一覧」「ステータス表示（実行中・入力待ち・完了）」「入力待ちのターミナルへ iTerm2 のタブフォーカスを即切り替え」といった、まさに欲しかった機能が詰まっている感じです。これによって3〜4セッションを同時進行しつつ、「入力待ちの放置」をほぼゼロにできて、体感2〜3倍くらいの効率アップがあったそうです。
興味深いのは、5並列以上にすると今度は人間のコンテキストスイッチが増えすぎて、逆に効率が落ちたという発見ですね。つまり、「AIエージェントを増やせば増やすほどいい」わけじゃなくて、人間がきちんと状態を追える並列数にチューニングするのが大事だと。今後は社内向けの展開も視野に入れているそうで、「エージェントをどう作るか」だけじゃなくて、「エージェント群と人間がどう一緒に動くか」というワークフロー設計の重要性を教えてくれる記事でした。
。。。。
4本目。
タイトルは「Claude Agent Skills のベストプラクティス」。
これは Claude の公式ガイド「Skill authoring best practices」をかみ砕いて、日本語で要点をまとめた記事です。Claude Agent Skills を作り始めた人、あるいはなんとなく書いているけど設計に自信がないという人には、かなり役立つ内容になっています。
大きなポイントとしては、「Skillsは同じコンテキストウィンドウを共有する」という前提ですね。なので、スキルの説明をダラダラ長く書くと、それだけでコンテキストを食い潰してしまう。Claude がすでに知っている一般知識は極力省いて、「このSkillが何をするか」「どう使ってほしいか」を簡潔に書くことが大事だとされています。
また、タスクの性質に応じて、スキルにどこまで厳密な手順を書き込むか、あるいは大まかな指針だけに留めるか、自由度を調整する話も出てきます。SKILL.md には YAML のメタデータと短い概要だけを置いて、詳細な運用ルールや長い解説は別ファイルに逃がす「Progressive Disclosure（段階的な情報開示）」のスタイルが推奨されているのも実践的ですね。
name / description の付け方、動名詞・三人称で統一するとか、Skill の参照構造は1階層までに抑えるとか、細かいけれど効くベストプラクティスも紹介されています。さらに、チェックリストやバリデーションを組み込んで、Claude自身が自分の出力を検証できるフィードバックループを作る話、開発用Claudeとテスト用Claudeを分けて反復開発する話など、「Skillをコードとして育てる」視点が面白いところ。
アンチパターンとして、Windowsパスをベタ書きする、選択肢をやたら並べて迷子にさせる、時間依存の記述であっという間に古くする、なども挙がっていて、「あ、やりがちだな…」と思った方も多そうです。Skillを量産する前に、一度押さえておきたい内容でした。
。。。。
そして今日ラスト、5本目の記事。
タイトルは「Claude Codeに別のAIエージェント（Codex等）を相談役として付けてみた」。
これは発想がすごく人間っぽくておもしろいです。著者は、Claude Code に完全自動で任せきるのがちょっと不安で、「人間の同僚みたいに、計画段階・実装中・完了時に横でレビューしてくれる存在がほしい」と感じていたそうなんですね。でも、ずっと自分が付きっきりでレビューするのも大変だと。
そこで考えたのが、「Claude Code が他のAIエージェントに相談できるようにする」というアプローチです。具体的には、Codex や Gemini の CLI、あるいはClaudeのサブエージェントを「相談役」にする Agent Skill を作ります。名前でいうと ask-codex / ask-gemini / ask-peer、それから逆向きの ask-claude など。ユーザーは「codexに相談して」とか、スラッシュコマンドでさっと指示するだけで、Claude Code が別のAIにレビューを依頼してくれる仕組みです。
相談ルールは CLAUDE.md に書いておけるので、「新しいタスクを始める前は必ず計画をCodexにレビューしてもらう」「実装が終わったらGeminiに抜け漏れをチェックさせる」といったワークフローを自動化できます。実装自体はSKILL.mdから外部CLIやサブエージェントを呼び出すシンプルな構成で、「AIにAIをレビューさせる」体制がわりと簡単に組めてしまう。
これによって、計画段階でのフィードバックが増えたり、人間だと見落としがちな観点を別のモデルが拾ってくれたりして、「ずっと画面に張り付いて監視する」必要がだいぶ減ったそうです。一方で、トークン消費は当然増えますし、相談役のAIの意見をそのまま鵜呑みにすると危ない、最終判断は必ず自分で下す必要がある、という注意点もちゃんと書かれています。プラグイン自体はGitHubやマーケットプレイス経由で導入可能とのことなので、「AIチーム開発」みたいな世界に興味がある方には要チェックですね。
。。。。
というわけで、今日の「zenncast」、駆け足でおさらいしていきます。
まず1本目は、Codex連携をMCPからSkillに切り替えることで、ログが見えてデバッグしやすくなり、長時間ツールはSkill化したほうが体験が良くなるという話。
2本目は、「横のガードレール」として静的検査を作り込み、AIにアーキテクチャを口で教えるのではなく仕組みで守る「自律駆動」のアプローチ。
3本目は、Claude Code の並列実行を可視化・管理するダッシュボードを自作して、人間側の状態把握を最適化することで、実効速度を2〜3倍にしたという話。
4本目は、Claude Agent Skills のベストプラクティスを整理した記事で、コンテキストの使い方、SKILL.mdの設計、フィードバックループなど、Skill設計の指針。
そして5本目は、Claude CodeにCodexやGeminiといった別のAIエージェントを「相談役」として付けて、計画・実装・レビューをAI同士に分担させるという取り組みでした。
気になる記事があれば、詳しい内容はショーノートにまとめてありますので、ぜひそちらから元記事に飛んでじっくり読んでみてください。
この番組「zenncast」では、リスナーのみなさんからの番組の感想や、「こういうテーマを取り上げてほしい」「このツールどう思う？」といったお便りも募集しています。普段どんなふうにAI開発を進めているか、現場の工夫なんかも教えてもらえると、とても参考になります。
それでは今日はこのへんでお別れです。
お相手はマイクでした。
また次回の zenncast でお会いしましょう。いってらっしゃい！