どうもみなさん、おはようございます。マイクです。
今朝も「zenncast」のお時間がやってまいりました。
今日は二千二十六年七月十三日、月曜日の朝七時ということで、出勤や通学の支度をしながら聴いてくださっている方も多いんじゃないでしょうか。
この番組では、毎回、技術ブログサービス「Zenn」に投稿された記事の中から、いまホットなトレンド記事をピックアップしてご紹介していきます。
きょうも最新のエンジニアリング事情、たっぷりお届けしていきますよ。
さて、きょうはお便りコーナーはお休みということで、そのまま本編にいきたいと思います。
今日ご紹介する記事は、全部で五本です。
インフラとCIの話から、生成AIのセキュリティ、CADツール、デスクトップアプリ開発、そしてAIコーディングエージェントのワークフローまで、かなり幅広いラインナップになっています。
それでは、一つ目の記事からご紹介していきましょう。
一つ目は、GitHub Actions の新機能、同じジョブの中でステップを同時に動かせる `parallel` と `background`、それから `wait` を使ったお話です。
これが出てきたことで、同じランナー上でステップを並列実行しながら、セットアップを共有できるようになった、というのがポイントですね。
まず、本番のECSデプロイの事例が紹介されていて、これまでは web と worker、それぞれ別々にデプロイしていたものを、`parallel:` で並列化したそうです。
その結果、デプロイの「待ち時間」がきれいに重なってくれて、トータル八分かかっていたデプロイ処理が、なんと約三分まで短縮できた、というかなりインパクトのある改善になっています。
次に、RuboCop と Brakeman の静的解析の話。
これは従来、別々のワークフローとして動かしていたものを、一つのワークフローにまとめて、セットアップ処理を一回だけにしたそうです。
完了までの実時間はほとんど変わらないものの、ランナーの合計稼働時間、つまり実行コストが大きく削減できた、ということで、お財布に優しい最適化ですね。
一方で、フロントエンドCIでは少し事情が違ったという話も出ています。
`test` まで含めて、全部を一つの一CPUランナーにギュッとまとめてしまうと、CPUの取り合いが起きて逆に遅くなってしまった。
そこで、重たい `test` や `build` は別ジョブに分割して、軽い `lint` や `prettier`、`type-check` だけを `parallel:` でまとめる構成に変更。
これによって、完了時間は維持しつつ、コストをおよそ三割削減できたそうです。
記事のまとめとしては、「ステップの並列化」は、処理の待ち時間を重ねて速くするか、セットアップを共有してコストを下げる、そういった用途に向いている、と。
逆に、CPUやメモリをガッツリ消費する処理は、ジョブ並列、つまり別ランナーに分ける判断が大事だよ、という整理になっていました。
GitHub Actions を本番運用レベルでチューニングしている方には、かなり実践的な知見が詰まった記事ですね。
。。。。
続いて、二つ目の記事です。
こちらは、生成AIの導入をめぐる「現場」と「リスク管理部門」の対立を、どうやって乗り越えるか、という非常にリアルなストーリーです。
現場としては、「生成AIを使って業務効率化したい、どんどん使っていきたい」という前向きな空気がある一方で、リスク管理部門は「情報漏洩が怖いから慎重に」「下手に触りたくない」と、かなりブレーキをかけがち。
これ、実際の会社でも、すごくよくありそうな構図ですよね。
この記事では、この対立を「導入するリスク」と「導入しないリスク」、両方を並べて比較することで、「そもそもやるかやらないか」から、「どう安全に導入するか」という建設的な議論に変えていった、というプロセスが紹介されています。
情報漏洩の可能性も、ざっくり「AI怖い」ではなくて、経路を二つに分解しています。
一つは、ユーザーがチャットに入力する情報。
もう一つは、外部ツール連携の部分です。
前者のチャット入力については、Enterprise契約の条件をきちんと確認して、「入力された内容を学習に使わない」ことを前提にしていく。
後者の外部ツール連携に関しては、プロキシやメールフィルタ、承認フローといった、すでに社内にあるセキュリティの仕組みでコントロールできるよね、と整理しています。
さらに追加の「防波堤」として、生成AIが実行できる操作を事前にリストアップしておいて、「こういう操作をさせて良い」というのを許可制にするルールも導入。
新しい操作を追加したいときは、関係部門の承認が必須になる、という仕組みにすることで、最終的には Claude、ChatGPT、Gemini を全社で利用できるようにしたそうです。
また、Claude Code のようなエージェント型ツールについては、「個人の効率化」と「正式な業務プロセスへの組み込み」をきちんと分ける運用も紹介されています。
Excelマクロみたいに、個人が自分の仕事を楽にするためにちょっと使うレベルのものは、そこまでガチガチに管理しない。
一方で、正式な業務プロセスに組み込むような重要な使い方だけ台帳管理していくことで、過度に恐れすぎず、でも安全性も確保する、というバランスを取っているんですね。
生成AI導入で社内調整をしている方には、かなりヒントになる記事だと思います。
。。。。
さあ、三つ目の記事です。
ここからは少しものづくり寄りの話題。「cad-coworker」という、AIと一緒にCAD設計を進めるためのブラウザツールを紹介している記事です。
この「cad-coworker」は、CadQuery で書いた三次元モデルのコードをベースに動きます。
コードの中で、変数の横に、「最小値」「最大値」「刻み幅」「ラベル」などをコメントで書いておくと、その情報を読み取って、ブラウザ上にスライダーや数値入力のUIを自動生成してくれるんですね。
これによって、寸法の「最後の数ミリ」を直感的に追い込んでいけるのが大きな特徴です。
たとえば、ケースの幅をあと二ミリだけ広げたいとか、ネジ穴の位置をほんの少しだけ調整したい、といったときに、いちいちコードを書き換えてパラメータを変えるのではなく、ブラウザのスライダーを動かしながら、リアルタイムに形状を確認していける、というイメージですね。
さらに面白いのが、こうした機能を Codex や Claude Code などのAIエージェント環境の「スキル」として組み込めるようにしているところです。
エージェントに対して、「こういうロボット用のケースを作って」と頼むと、まずはたたき台になるCadQueryのコードを生成してもらう。
そのあと、人間がブラウザの「cad-coworker」上でスライダーを動かして微調整していく、というワークフローを想定しています。
STL出力にも対応しているので、調整し終わったモデルをそのまま三次元プリンタで出力できる。
メカ設計が得意じゃない人でも、AIの力を借りながら、ロボットや電子工作用のケースを作っていけるツールになっている、という紹介でした。
「AIと一緒に物を作る」という未来を、かなり具体的な形で見せてくれる記事ですね。
。。。。
続いて四つ目の記事です。
こちらはデスクトップアプリ寄りの話題で、Rust と Tauri、それから React を組み合わせて、「sysgauge」という古いMac風デザインのシステムモニタを作った、という開発記です。
「sysgauge」は、CPU使用率、メモリの used / available / free / swap、それからディスク使用量、温度といった情報を、一画面でライブ表示してくれるツールになっています。
見た目は、「昔のMacっぽい」ちょっと懐かしいデザインに振り切っているのが特徴で、ネイティブアプリのようなレスポンスと、ノスタルジックなUIがいい感じに合わさっています。
仕組みとしては、数値の取得はRust側で `sysinfo` というクレートを使って行い、フロントエンドからは一秒ごとに `get_metrics` を呼ぶだけ、というシンプルな構成。
ハードウェア情報の取得はネイティブ側でしっかりやりつつ、UI部分はReactで作り込む、という役割分担ですね。
温度については、`Components` という仕組みからラベルでセンサーを絞り込んでいるそうなんですが、機種依存性がかなり大きくて、「このMacでは取れた」というレベルにとどまっている、と正直に説明されています。
ここは、ハードウェア違いをまたいでちゃんと動かすのが難しい部分ですよね。
メモリに関しても、「available がすぐゼロになりやすい」といった挙動があって、OS側の計算方法、たとえば圧縮メモリの扱いなどと、ユーザーの直感がズレてしまうことがある、と。
そこで、used だけを出すのではなく、available / free / swap も並べて表示することで、「体感」と「実際の状態」のギャップをうまく伝えられるようにした、という工夫が語られています。
Rust と Tauri でデスクトップアプリを作ってみたい人にも、また、「どうやってシステム情報を分かりやすく見せるか」というUIデザインの観点でも、参考になる内容でした。
。。。。
そして最後、五つ目の記事です。
テーマは、AIコーディングエージェントのワークフロー設計。
最近、AIを使った開発フローって、どうしても「重くて画一的」になりがちですよね。
どんな小さな修正でも、巨大なワークフローを全部通さなきゃいけなかったり、人間のレビューや判断が弱くなってしまう、といった問題があります。
この記事では、そうした課題に対して、AWS の AI-DLC という仕組みがどう応えようとしているか、という話が紹介されています。
AI-DLC は、「AIが段階を提案し、人間が各ステージで承認する」という、多段階の開発ライフサイクルをきちんと構造化したフレームワークになっています。
最新版のバージョン二では、五つのフェーズ、三十二のステージ、十一のエージェント、九つのスコープという、かなり細かい構造を持っていて、それらを Markdown と YAML の定義ファイルを正本とした「core」からビルドするアーキテクチャに進化しているそうです。
この「core」を元にして、Claude Code や Kiro など、複数の実行環境向けにワークフローを自動生成できるようになっている、というのがポイントです。
各ステージの定義も工夫されていて、「何をするか」と「どう進めるか」を一つのファイルに併記します。
「何をするか」の部分には、そのステージの依存関係や、生成する成果物が書かれていて、「どう進めるか」の部分には、LLMに対する具体的な指示が書かれている、という構造です。
ルーティング、つまり「次にどのステージに進むのか」といった判断は、決定論的なエンジンがコードで行うようになっていて、LLMはあくまで「実行だけ」を担当する。
これによって、再現性をしっかり確保している、というのが特徴です。
また、人間が行った訂正や、そこから得られた学びは、「承認ゲート」のルールとして蓄積されていきます。
次回以降のワークフローにはその知見が反映される一方で、いま進行中の実行には影響を与えないようにして、安定性を損なわないようにしているところも、よく考えられていますね。
さらに、「Intent」と「Space」という単位で複数タスクを同時に管理できるようになっていて、チーム固有のルールや業界固有の要件は、`memory/` ディレクトリやプラグインとして追加できる設計になっています。
これによって、フレームワーク本体をフォークせずに、各組織ごとの調整ができるようになっている。
AIエージェントを「チームとしてどう使いこなすか」を真剣に考えている人には、とても刺激になる内容だと思います。
。。。。
というわけで、きょうの「zenncast」では、
GitHub Actions のステップ並列でデプロイやCIの時間とコストを最適化した話、
生成AI導入のリスクと向き合いながら、安全に全社展開していくための整理の仕方、
AIと一緒に三次元CAD設計ができる「cad-coworker」のブラウザツール、
Rust と Tauri ＋ React で作る懐かしのMac風システムモニタ「sysgauge」、
そして、AWSの AI-DLC が目指す、人間が主導権を持った多段階AI開発ワークフロー、
この五本の記事をご紹介してきました。
気になった記事があった方は、ぜひショーノートから元の記事もチェックしてみてください。
ここでは触れきれなかった細かいノウハウやコードの工夫なんかも、たっぷり載っています。
この番組「zenncast」では、皆さんからの番組の感想や、「こんなテーマを取り上げてほしい」といったリクエストもお待ちしています。
普段どういうふうにZennの記事を活用しているのか、なんて話も教えてもらえると嬉しいです。
それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。
きょうも良い一日をお過ごしください。