どうも、マイクです。おはようございます。
六月三十日、火曜日の朝七時をまわりました。「zenncast」今日も元気にお届けしていきます。
この番組では、エンジニアのみなさんに向けて、Zennで話題になっているトレンド記事をゆるっと、でも中身はしっかりめにご紹介していきます。
通勤・通学のおともに、作業のおともに、最後までお付き合いください。
さて、今日は全部で五本の記事をご紹介していきます。
プロダクトデザインからインフラ運用、AIエージェントの育て方にFAQサイト運用の話まで、けっこう幅広いラインナップになっています。
それでは、まず一つ目の記事からいきましょう。
一つ目は、「Claude Design」という新しいデザインプラットフォームを、実務でどう活用していくか、具体的な使い方をまとめた記事です。
Claude本体と同じようにチャットができる画面に、キャンバスがくっついていて、そこでプロトタイプを生成していきます。で、出てきた画面を見ながら、チャットで「ここをもう少しこうして」「このボタンの位置変えて」みたいにコメントしたり、キャンバス上を直接編集したりしながら、どんどん細かく調整していけるんですね。
完成したものは、エイチティーエムエルやPDF、パワーポイントのピー・ティー・エックス形式など、いろいろな形式で書き出せるので、仕様書にも提案資料にも、そのまま流し込みやすいのがポイントです。
特徴的なのが、自社プロダクトの既存のアプリやデザインファイル、コードベースから、デザインシステムを取り込めることです。これによって、会社やサービスごとに決まっているトンマナ──色使いやコンポーネントの形、フォントなど──をきちんと守ったまま、UIを自動生成できるんですね。「AIに任せたら、なんか全然違う雰囲気の画面が出てきちゃった」っていうのを避けられる、というわけです。
記事の中では、主な使い方を三つに整理しています。
一つ目は、仕様書をペタっと貼り付けて、その内容からプロトタイプを作ってもらう、という使い方。テキストでざっと書いた要件から、いきなり画面ベースの議論に持っていけるので、プロダクトマネージャーさんやデザイナーさんとの認識合わせが早くなります。
二つ目は、逆方向の使い方で、完成したデザインから操作内容や画面遷移をClaudeに読み取ってもらい、そこから仕様書を自動生成する、というものです。で、その仕様をさらにClaude Codeにつなげて、そのまま実装に落としていくという、一気通貫の流れを想定しています。
三つ目は、プロトタイプから短いデモ動画を作る、という使い方。これを社内の認識合わせに使ったり、関係者への共有に使ったりすることで、「どう動くサービスなのか」が、非エンジニアにも伝わりやすくなります。
一方で、課題も挙げられています。
まず、Gitのブランチのように、デザイン案を気軽に分岐させて、複数パターンを並行して試す、というところはまだやりにくいそうです。プロダクトのフェーズによっては、「AパターンとBパターンを並べてABテストしたい」とか「過去の分岐にすぐ戻りたい」といったニーズもあるので、この辺は今後の改善ポイントですね。
それから、MCP経由で既存のコードベースと連携して、ハンドオフを自動化する部分については、複雑なプロダクトになればなるほど、まだ精度に課題があると。読み取れていないルールや例外が出てくるので、完全自動というよりは「かなり手伝ってくれるけど、最終チェックは人間が必要」というスタンスで使うのが現実的だろう、という話です。
全体としてこの記事では、「デザイン作成から仕様化、そして実装までを一気通貫で回せる」という点に価値がある、とまとめています。
いままで「仕様書書く人」「デザインする人」「実装する人」とバトンリレーになっていたところを、Claude DesignとClaude Codeを組み合わせて、一本の太いパイプにしていく。その最初の実用的な手応えが出てきている、という内容でした。
。。。。
続いて、二つ目の記事です。
こちらはがらっと変わって、エディタのVim、ウィンドウズ版のインストーラーを、およそ八年ぶりに作り直した話です。テーマは「より柔軟で、現代的なインストール体験を提供すること」です。
新しいインストーラーでは、まず大きなポイントとして、「管理者権限なしで、現在のユーザーの環境だけにインストールする」というスタイルに対応しました。会社支給のPCなど、管理者権限が取りづらい環境でも、ユーザー自身の領域にだけきちっと入れられるようになったわけですね。
フォルダー構成も整理されていて、実行ファイルが決まったパスに置かれるように変更されています。これによって、「どこにvim.exeが入ったのか分からない」みたいなことが減って、ほかのツールからパスを通すときにも扱いやすくなっています。
コマンドラインから使う人への配慮も大きく進化していて、従来の「バッチファイルで起動する方式」をやめて、小さなランチャーの実行ファイルを用意し、そこにPATH追加機能を持たせています。
さらに、サイレントインストール用の詳細なコマンドラインオプションも整備されていて、wingetからのインストール・アップデートを、かなり細かく制御できるようになったそうです。企業環境での一括展開には、このあたりすごく効いてきそうですね。
インストーラー形式としては、MSIやMSIXへの移行も検討されたそうなんですが、多言語対応や三十二ビット・六十四ビットの共存といった課題を考えると、現時点ではコストが高すぎる、という判断で、今回は従来どおりNSISを継続する決断をしています。
「最新だから乗り換える」のではなく、プロジェクトの事情やユーザーの環境を踏まえて、あえて変えない選択をしている、というのが面白いところです。
開発プロセス面の話も紹介されていて、GitHub Copilotによるレビューを取り入れた結果、多数の有用な指摘が得られたエピソードも書かれています。
また、ランチャー実行ファイルのサイズを小さくするための工夫や、インストーラー関連のリポジトリを本体から分離する運用など、「ツールとしてのVim」だけでなく、「Vimを配布するための仕組み」をどうきれいに保つか、という視点も含まれています。
ウィンドウズでVimを使っている方には、日々当たり前に触れている「インストールする」という体験の裏側で、どんな判断と工夫があったのかが分かる、読み応えある記事になっていました。
。。。。
三つ目の記事は、インフラ運用まわりのお話です。
手動でやっていたECS、具体的にはFargateへのデプロイを、Terraformとecspressoで役割分担しながら自動化していった事例ですね。
ポイントは、「Terraformはインフラ専任、ecspressoはアプリのデプロイ専任」と、きれいに役割を分けたことです。
まず、これまでありがちだった「レイテストタグ運用」、コンテナイメージを全部`:latest`で上書きしていくスタイルをやめて、ECRのイメージタグをコミットのSHAに固定しました。これによって、「この環境は、いつ、どのコミットのイメージが入っているのか」が一意に追えるようになり、いつでも特定のコミットにロールバックできるようになります。
Terraform側で、タスク定義のイメージタグ更新まで面倒を見ようとすると、ちょっとしたデプロイのたびに、インフラ全体へ`terraform apply`を走らせることになってしまって、状態のズレも起きやすくなる。
そこで、ECSサービスとタスク定義の更新は、思い切ってecspressoに移譲しています。インフラの定義はTerraform、アプリの更新とロールバックはecspresso、という住み分けですね。
ダウンタイムなしでの移行手順も、かなり丁寧に書かれています。
まず、`ecspresso init`で、既存のECSクラスターやサービスから定義を吸い出して、ecspresso用の設定を生成。
次に、それをテンプレート化して、`ecspresso diff`で、実際のECSの状態との間に差分が出ないことを確認します。
その上でTerraformには、`removed`ブロックに`destroy = false`を指定して、ECS関連のリソースを「もうTerraformでは管理しないけど、実物は消さない」という扱いにして、ステートから外していきます。
こうすることで、本番のサービスを止めることなく、管理ツールだけをスイッチできるようにしているんですね。
GitHub Actionsでの運用も工夫されています。
ブランチごとに対象の環境を決めておき、ビルドしてECRにプッシュ、その後`ecspresso deploy --wait-until=stable`を実行して、サービスが安定するまで待つようにしています。
さらに、GitHub Actionsのconcurrency設定で「同じブランチからのデプロイは必ず直列に実行される」ようにして、「古いイメージを後から上書きしてしまう」という事故を防いでいます。
イメージタグは、コミットSHAを短縮したものに固定し、同じタグのイメージが既に存在する場合は、ビルドやプッシュをスキップする仕組みにしています。これによって、ジョブの再実行にも強いワークフローになっているんですね。
通知の部分もよくできていて、全ジョブの結果をまとめて、Slackに一通だけ通知を送るようになっています。
その中には、対象サービス、ブランチ、コミットのSHA──つまりイメージタグ──実行者、そしてログへのリンクが全部まとまっているので、状況を一目で把握できます。
ロールバックが必要になったときも、この通知に出ているSHAを、そのままecspressoの`rollback`や`deploy`に指定するだけで、狙ったバージョンに戻せるようになっている、というわけです。
「レイテストタグは楽だけど、後から困るよね」という経験がある方には、かなり参考になる構成だと思います。
。。。。
四つ目は、AIエージェントの「学習のさせ方」に踏み込んだ記事です。
テーマは、AIエージェントが同じ失敗を何度も繰り返してしまう問題と、逆にメモリを増やしすぎるとノイズだらけになってしまう問題、これをどう解決するかという話です。
著者の方は、Claude Code向けに「cc-retrospective-learner」という仕組みを自作し、三か月ほど運用した記録をまとめています。
ポイントは、セッション履歴を「一次資料」と見なして、そこから学びを抽出していくための「漏斗」を作ったことです。
全セッションのログを、ショートターム、ロングターム、フィードバック、CLAUDE.md、スキル、という段階で、少しずつ絞り込んでいく構造になっています。
これによって、同じ型のバグが三回起きた時点で、自動的にルールとして成文化されて、それ以降は事前に防げるようになります。
単に「このときはこう失敗しました」というメモに留めるんじゃなくて、「こういう状況では、こういう条件を確認してから進める」とか、「このライブラリを使うときは、このパターンのバグが出やすいので、必ずテストを書く」といった、再利用可能なルールとしてAIに返しているわけですね。
面白いのは、失敗だけじゃなくて「成功パターン」もちゃんと記録しているところです。
たとえば「AIレビューは鵜呑みにしないための手順」とか、「対になる概念AとBを、最初からセットで考える『仕事の構え』」みたいな、ちょっと抽象度の高い価値観までフィードバックに落とし込んでいます。
それらが最終的には、毎回自動で適用されるルールや、スラッシュコマンドとして呼び出せる機能に昇格していく。つまり、セッションを重ねるほど「自分のやり方で働いてくれるAI」を少しずつ育てていくイメージです。
もちろん実務では、短期記憶が増えすぎてコンテキストを圧迫してしまったり、プロジェクト間で記憶が混ざってしまったりといった問題も出てきます。
そこで記事では、古いログを間引いていったり、索引をシンプルにしたり、プロジェクトごとにサブエージェントを分けたり、「普遍的な知識」と「そのプロジェクト固有の知識」を、異なる場所に配置したりすることで、情報の洪水にならないようにコントロールしている様子が紹介されています。
結果として、「セッション履歴からAIを継続的に育てる」という運用が、ちゃんと現場レベルで回せることを実証できた、とまとめられています。
日々AIと一緒に開発している方には、「ログを捨てずにどう活かすか」の具体的なヒントがたくさん詰まった内容でした。
。。。。
そして五つ目、最後の記事です。
こちらはFAQサイト運用の話で、外部のSaaSで運用していたFAQサイトを、Cloudflare Workers上でホストするAstro製の静的サイトに移行した事例です。
狙いは、FAQコンテンツをGitで管理できるコードベースに載せ替えて、型チェック付きのMarkdown運用にすることで、安全かつ拡張しやすい状態にすることでした。
技術的には、AstroのContent CollectionsとZodを組み合わせて使っています。
Markdownのフロントマターに書く必須項目──たとえばタイトルやカテゴリ、公開ステータスなど──がちゃんと埋まっているか、カテゴリ参照が定義済みのものになっているか、といった検証を、ビルド時に自動で行えるようにしています。
UIの部分は、shadcn/uiなど既存のコンポーネントライブラリを組み合わせて、ゼロから作り込むのではなく、実装コストを抑えながら、そこそこリッチな見た目を実現している形ですね。
検索機能も、バックエンドを持たずに工夫しています。
ビルド時に全記事のJSONを生成しておき、それをフロントエンドだけで読み込んで、キーワード一致検索を行う実装です。
これなら、Workers上の静的ホスティングだけで完結しつつ、ユーザーにはそれなりにレスポンスのいい検索体験を提供できます。
移行作業もかなり本格的で、旧サービスからエクスポートしたCSVを元に、Markdownの記事ファイルや画像、スラッグの正規化、内部リンクの変換、さらには三百一リダイレクトの設定まで、一括で生成するスクリプトを用意しています。
表記ゆれには、機械的なルールだけでなく、例外テーブルも併用して対応していて、「だいたい同じだけど微妙に違う」ケースもできるだけ自動で吸収できるようにしていました。
さらに、新旧サイトを自動で突き合わせる検証スクリプトも作っています。
本文の類似度をスコアリングして、「中身がちゃんと移行できているか」を数値でチェックしたり、sitemapの差分を比較したり、リダイレクト先のページがちゃんと生きているかを機械的に確認するなど、かなり手厚い検証を行った上で切り替えています。
その結果、ダウンタイムゼロで、かつSEO評価も引き継いだ形で、新しいFAQサイトにスムーズに移行できたそうです。
記事の締めくくりでは、生成AIの普及で、非エンジニアでもMarkdownやコードに触れやすくなった今こそ、外部SaaSから自前の静的サイトに移行して、記事作成フローの自動化や品質向上など、FAQ運用を開発プロセスと一体で改善していく余地が広がっている、と述べられています。
「ドキュメントもプロダクトの一部」と捉えているチームには、かなり刺さる内容ですね。
。。。。
というわけで、今日は五本の記事をご紹介してきました。
Claude Designでトンマナを守りながらプロトタイプから実装までつなぐ話、Vimのウィンドウズインストーラーを八年ぶりに作り直して、現代的なインストール体験にアップデートした話、ECSのデプロイをTerraformとecspressoで役割分担して自動化・ロールバックしやすくした話、AIエージェントをセッション履歴から継続的に「育てる」仕組みの話、そしてFAQサイトをAstroとCloudflare Workersで静的サイト化して、Gitと型チェック付きMarkdownで運用改善した事例まで、一気に駆け足で振り返ってみました。
気になった記事があれば、詳しい内容はショーノートにリンクをまとめておきますので、ぜひ本編も読んでみてください。ここで紹介しきれなかった細かい工夫やコードの断片なんかも、実際の記事の方にたくさん載っています。
「zenncast」では、番組の感想や「こんな記事を取り上げてほしい」といったリクエストも、いつでもお待ちしています。
あなたの現場での工夫や失敗談なんかも、ぜひ教えてくださいね。
それでは、今日も良い一日をお過ごしください。
お相手はマイクでした。また次回お会いしましょう。