どうも、マイクです。おはようございます。
2026年3月8日、日曜日の朝7時になりました。
ここからの時間は「zenncast」、今日もZennで話題になっているトレンド記事を、ゆるっと楽しく紹介していきます。
今日はリスナーのみなさんからのお便りはお休みということで、その分じっくり記事を掘っていきたいと思います。
さて、今日紹介する記事は全部で5本。
AI開発のワークフローから、大学の技術スタック、そしてGitHub Actionsのセキュリティまで、技術好きにはたまらないラインナップです。
まず1本目。
タイトルは「Claude Code の 便利コマンド5選」。
AIと対話しながら開発している方、多いと思うんですが、「なんか最近レスポンス質落ちた？」とか「このセッション、どれくらいコンテキスト使ってるんだろう」って気になったことありませんか？
この記事では、そんなモヤモヤを一気に解決してくれる、対話モードの隠れ便利コマンドたちが紹介されています。
たとえば `/context`。
これを叩くと、System prompt や Memory files、Skills、Messages、Free space、Autocompact buffer みたいな感じで、コンテキストの消費状況を色付きで一覧表示してくれます。
「最近応答が雑だな…」と思ったときに、「あ、メモリがパンパンで自動圧縮されてるのか」みたいな原因の見立てがしやすくなるんですね。
さらに `/insights` は、自分の使い方を分析したHTMLレポートを生成してくれて、「あなた最近こういう使い方してますよ」「ここ改善するともっと効率上がりますよ」みたいな“利用のふりかえり”をAI側がやってくれる。これ、地味に嬉しいやつです。
会話を分岐して別ラインで検証したいときには `/fork`。重たい調査だけを別セッションに切り出して、本線はサクサク進める、みたいな並列作業ができるのも便利です。
ログをテキストとしてまとめておきたいときには `/export`。作業ログの保存や、チームへの共有、あとで記事に起こすときの下書きにも使えそうです。
そしてショートカット枠として、Ctrl+R。これで過去に投げたプロンプトを逆順検索できるので、「あのときのいい感じの指示、もう1回出したい」が一瞬で再利用できる。
こういう「メイン機能の周りにある小技」を押さえておくと、毎日のAI開発がかなり快適になりますよ、という内容でした。CLIのリファレンスをちゃんと読むと、こういうお宝コマンドがまだまだありそうですね。
。。。。
続いて2本目。
タイトル「スピードも品質も諦めたくない！そんな願いを叶える『仕様駆動開発』のススメ」。
AIと一緒にコードを書いていると、「とりあえず書かせて、後で直そう」が増えがちなんですよね。結果として、手戻りが増えて、なぜこうなったのか分からないコードだけが残る…。
この記事では、それに対する解として「仕様駆動開発（SDD）」というスタイルが紹介されています。
ざっくり言うと、「とにかく先に仕様をちゃんと言語化して、その仕様を元にAIにコードを書いてもらう」というやり方です。
要件 → 設計 → タスク → 実装という流れを、AIと一緒に一貫して更新していけるので、いきなり実装から入って迷子になる、いわゆる“バイブコーディング”を防げるのがポイント。
テスト駆動開発（TDD）とも相性がよくて、「仕様が固まっている状態でテストを書ける」ので、あとで仕様ブレが起きにくい構造になっています。
記事の中では、OSSの「cc-sdd」を使って、Notionに書いたPBI（プロダクトバックログアイテム）から requirements / design / tasks をAIで生成し、それをレビューしてからタスクごとに実装していく、というフローが紹介されています。
この運用を回した結果、これまで1ヶ月かかっていた機能が、「実装は1週間＋周辺対応込みで2週間」まで短縮できた、というなかなかインパクトのある話が出てきます。
もちろん良いことばかりではなくて、AIが量産してくれたコードをどうレビューするか、という新しい課題も生まれていて、プロジェクトメモリや静的解析・動的解析ツールを組み合わせて負荷を減らそうとしているところも正直に書かれています。
スピードと品質をトレードオフにしないための、かなり実践的なワークフローの紹介になっているので、「最近AI開発のチームフローに悩んでるんだよな」という方には特に刺さりそうです。
。。。。
3本目。
タイトル「コードレビューにClaude Code subagentsを導入したら、レビューレベルが改善した話」。
さっきの話ともつながりますが、プロジェクトが大きくなると、「人間だけで全部のPRをちゃんとレビューする」のがどんどん難しくなってきます。特にマイクロサービスが増えてくると、設計もセキュリティもパフォーマンスも、それぞれ専門性が必要になりますよね。
この記事では、最初は「1つのClaude Code＋100行くらいのガイド」でAIレビューをやってみたものの、どうしても指摘が浅くなってしまった、というところからスタートします。
そこで発想を変えて、「設計」「セキュリティ」「テスト」「パフォーマンス」みたいに役割ごとに特化した subagents を作って、それぞれが `.claude/rules/` 以下に置いた、合計1600行超えの詳細なルールを参照しながら並列レビューする構成に変えた、というのが面白いポイントです。
ルールをちゃんと細かく書き込んでおくことで、OWASP Top 10に関わる脆弱性の可能性や、DDD／クリーンアーキテクチャ的に怪しい設計、テスト漏れ、パフォーマンスボトルネックなどを、かなり具体的に指摘してくれるようになったそうです。
さらに、指摘のフォーマットを統一して、GitHub Review APIを使い、4つのエージェントの結果を1つのレビューとしてPRのdiffにインラインコメントで流し込む。これをGitHub Actionsで自動実行しているので、「人間がレビュー画面を開いた時点で、すでにAIの専門家チームが一周見てくれている」状態になっているんですね。
その結果として、レビューの品質とスピードと一貫性が全部底上げされて、開発者の負担がかなり軽くなった、というのがこの記事の結論です。
今後はルールの改善や、新しいサブエージェントの追加、自動修正機能の検討など、さらに攻めた構想も書かれていて、「AIレビューを本気でプロダクション運用していくとこうなるのか」という良いケーススタディになっています。
。。。。
4本目。
タイトル「【2026年版】大阪公立大学の学生システム開発チームで使用している技術スタック」。
これ、学生チームの技術スタック紹介なんですが、読んでみると「いやこれ普通にモダンSaaSの構成では？」っていうレベルで、めちゃくちゃちゃんとしてます。
大阪公立大学の情報システム部門にある学生チーム「TryAngle」。
ここが学内システムを、企画から開発、運用まで学生主体で回しているんですね。
フロントエンドは Vue / Nuxt と Astro が軸。外部ライブラリへの依存をむやみに増やさず、UnoCSSでユーティリティ系をさばきつつ、Bootstrapからフォーム用のCSSを抽出して使うなど、「身軽だけど現実的」な選択になっています。
さらに、自前の共通フロントエンドライブラリでレイアウトや状態管理を提供していて、プロジェクトをまたいでも一貫した体験が作れるようになっているのが良いですね。
バックエンドは Go + Echo + GORM がメイン、一部では Bun + Elysia といった組み合わせも使っているとのこと。
DBは PostgreSQL と MariaDB。
サービス間の型共有には Protobuf と Connect RPC を使っていて、ここも2026年っぽいスキーマドリブンな構成になっています。
インフラ面では、大学の仮想化基盤と、学生専用サーバー「TAKOYAKI」上でDockerコンテナ運用。
CI/CDはGitHub Actionsを学内のSelf-hosted Runnerで回し、GrafanaとUptime Kumaで監視。SSL証明書はUPKI＋ACMEで取得・更新、ということで、「学内システムだからレガシーでも仕方ないよね」ではなく、ちゃんと今どきの運用をやっているのがよくわかります。
記事の最後では、学生スタッフの募集もされていて、「在学中にここまでのモダン栄養を浴びられるのはかなり良い環境だな…」と感じました。学生さんでインフラやWeb開発をがっつりやってみたい人には、こういうチーム、ほんとにおすすめです。
。。。。
そして5本目。
タイトル「GitHub Actions の式構文はスクリプトインジェクションの温床になる」。
最後はセキュリティ系の記事です。GitHub Actionsを普段から使ってる方は、耳が痛くて、でも絶対に押さえておきたい内容。
GitHub Actionsの `${{ }}`、ありますよね。
あれはただの「便利な変数展開」ではなくて、「実行前にテキストとして置換されるテンプレートエンジン」だ、というところが重要なポイントです。
特に `run:` の中や、`actions/github-script` の `script:` の中で使うと、その展開結果がシェルやJavaScriptとして実行されてしまう。
もしPRのタイトルや本文、merge_shaみたいな、外部からいじれる値をそのまま埋め込んでしまうと、そこから任意コード実行、つまりスクリプトインジェクションに繋がりかねない、というわけです。
じゃあどうするか。
記事で強調されているのは、「データ」と「コード」を分離すること。
`${{ }}` で外部入力をスクリプト内に直接差し込むのではなく、まずは環境変数に入れておいて、スクリプト側は環境変数を読むだけ、という形にする。これで、テキスト展開された瞬間に“コードの一部になってしまう”危険を避けられます。
`${{ }}` 自体が常に危ないわけではなくて、`if:` や `env:` みたいな、コード実行コンテキストではないところで使う分には安全、という整理もされています。
実務的な対策としては、`rg` などでワークフローを検索して、危険な使い方をしている箇所を洗い出すこと。
それから、actionlint や zizmor といった静的解析ツールをCIに組み込んで、怪しいパターンを自動検出させるのがいいよ、という提案もありました。
「とりあえず `${{ github.event... }}` をペタペタ貼ってる」ワークフローに心当たりのある方は、この記事を機に一度棚卸ししてみると良さそうです。
。。。。
というわけで、今日は5本の記事を紹介してきました。
Claude Codeの便利コマンドで開発体験を底上げする話から、仕様駆動開発でスピードと品質を両立するワークフロー。
さらに、Claude Codeのsubagentsを使ったAIコードレビューの高度な実践例。
大阪公立大学「TryAngle」の、学生チームとは思えないモダンな技術スタック。
そして最後は、GitHub Actionsの式構文が招くスクリプトインジェクションリスクと、その具体的な対策まで。
気になる記事があった方は、詳しい内容や元の記事への導線をショーノートにまとめてありますので、ぜひそちらからじっくり読んでみてください。
番組の感想や、「こんなテーマを取り上げてほしい！」というリクエストも大歓迎です。あなたの開発現場での悩みや工夫を、ぜひ教えてください。
それでは、そろそろお別れの時間です。
今日もお付き合いいただき、ありがとうございました。
お相手はマイクでした。次回の「zenncast」でまたお会いしましょう。お楽しみに。