おはようございます！ zenncast、MCのマイクです。今日は11月14日、土曜日。朝のひととき、皆さんいかがお過ごしでしょうか。
今日もZennでトレンドの記事から、気になる話題をお届けします。今回は、SlackでのMarkdown共有から、仕事を手伝うAIエージェント、AWSの開発とテスト、そしてAIと一緒に学ぶための工夫まで、全部で5本をご紹介します！
....
まず1本目は、Slackの入力欄にMarkdownを貼り付けて共有するお話です。
Markdownで書いた内容をSlackの入力欄に貼り付けると、表や、コードを色分けして表示するコードブロックを、そのまま共有できます。別の場所でまとめた情報を、チームに渡しやすくなるのは便利ですね。
表は、表示するだけでなく、コピーやダウンロードもできます。ただし、Markdownで指定した列の中央寄せや右寄せ、それからセルの中の文字装飾は反映されません。元の見た目がすべて再現されるわけではない、という点は押さえておきたいところです。
コードブロックでは、言語名を付けると、PythonやJavaScriptなどでコードが色分けされます。さらに、行番号とコピーボタンも表示されるんですね。コードを読む人にも、手元で試したい人にも、うれしい機能です。
見出しは3段階に対応していて、太字、斜体、箇条書き、引用、リンクも使えます。ただ、これまでのSlack独自の記法とは、一部ルールが違います。慣れている書き方でも、同じ表示になるとは限らないんです。
また、チェックボックス、数式、Mermaidの図、HTMLなどは変換されません。貼り付けたら、送信前に一度、表示を確認しておくと安心です。
うまく表示されない場合は、Slackを再読み込みしたり、環境設定の入力オプションを確認したりしてみてください。なお、BotやAPIから送る場合は仕様が異なるので、入力欄からの送信と同じだと思わず、別途確認が必要です。
便利に使いつつ、最後はプレビューをひと目チェック。このひと手間が大切ですね！
....
続いて2本目は、仕事を先回りして手伝うAIエージェント、Claude Duetについてです。
Claude Duetは、クラウド上の専用コンピューターで動き、Slackやカレンダーを定期的に確認して、仕事をサポートします。既存の接続設定や社内ルールをそのまま引き継げる、というのが特徴です。
たとえば、予定が重なっていないか、会議への招待が漏れていないかを見つけたり、次に取り組む作業や、文章の下書きを提案したりします。こちらが毎回お願いするだけではなく、定期的な確認を通じて手伝ってくれるわけですね。
筆者の検証では、日本のTeamプランでも、組織で機能を有効にすると利用できたそうです。ただし、導入時には気をつけたい点もありました。
管理画面でできるのは、全員を一括でオン、またはオフにする操作だけ。利用する人を限定したり、操作記録を確認したりする点には、制約があったといいます。
組織共通の指示文を書いて、エージェントの動きを抑える方法も、確実とはいえません。そのため筆者は、リスクを理解した人から、段階的に使う運用を勧めています。
先回りしてくれる便利さと、組織としてどこまで管理できるか。この両方を確認してから取り入れたい、というお話ですね。
....
3本目は、AWS Emulatorを、テストのどこに位置づけるかという話題です。
AWS Blocksには、実際のAWSを使わずに開発できるモックが備わっています。ただ、そのモックの動作と、実際のAWSが返す応答との違いまでは、十分に検証できていないという課題があります。
そこで筆者は、実際の動作を比較しました。そのうえで、AWS Emulatorはモックの代わりにするものではなく、モックと実際のAWSの間を埋める、もうひとつのテストの層になると考えています。
検証では、モックだけでは見つけにくい、S3のメタデータや削除処理の違いを再現できたそうです。手軽なモックでは通ってしまう処理でも、もう少し実際の環境に近いところで確かめると、違いが見えてくるんですね。
まずは、開発中のコードを自動でテストする用途に有効だと述べられています。
ただし、これで何もかも確認できるわけではありません。アクセス権限やデータベース操作などは、十分に確認できないため、手軽に使えるモックも、実際のAWSでの検証も、引き続き必要です。
どれかひとつに置き換えるのではなく、それぞれの得意な範囲を組み合わせる。テストの役割分担を考えるうえで、参考になる記事ですね。
....
続いて4本目もAWS Emulatorの話題です。今度は、アプリを手元のPCで動かして、開発の待ち時間を減らす方法をご紹介します。
基本の構成は、AWS Emulator側にテーブルやバケットを作り、アプリはcdkd localで、手元のPCから実行するというものです。コードを修正しても再デプロイが不要になるので、変更したらすぐに動作を試せます。この往復が短くなるのは、開発中にはありがたいですよね。
起動時にaws-emulatorオプションを指定すると、接続先や認証情報などが自動で設定されます。さらにfrom-stateオプションも付けると、作成済みのリソース情報から、テーブル名などを取得できます。環境変数を設定する.envファイルに、ひとつずつ手書きする手間が省けるわけです。
もうひとつのポイントが、接続先をAWSのサービスごとに切り替えられることです。
たとえば、APIキーやテストユーザーは実際のAWSにあるものを使い、データの書き込み先はAWS Emulatorにする、という組み合わせができます。これなら、既存のデータをローカル用に用意し直さずに試せますね。
ただし、切り替えられるのはサービス単位です。同じサービスの中で、このテーブルは実際のAWS、別のテーブルはAWS Emulator、という分け方はできません。
また、通常のCDK CLIを使い続けたい場合には、単体ツールのcdk-localでも、同様のローカル実行ができるそうです。
再デプロイを待たずに試す工夫と、実際のAWSを必要なところだけ組み合わせる工夫。日々の開発を進めやすくする、具体的な方法でした。
....
最後、5本目は、AIに作業を任せながらも、自分の理解を置き去りにしないための工夫です。
この記事で大切にしているのは、AIに丸投げするのではなく、自分の言葉で説明できるまで理解すること。そのために、AIに任せる作業と、自分で確認、判断する部分を、最初に決めておきます。
具体的には、CLAUDE.mdに、教師としてどのように進めてほしいかを書いておきます。いきなり答えを出すのではなく、まず質問やヒントを出してもらう。そして、コードを変更するときには、先に許可を求めてもらう、という設定です。
さらに、作業別の指示書である「スキル」を用意して、調査、設計、セルフレビューで役割を切り替えます。ただし、何でも一問一答にすればいいわけではありません。自分が分からないところに絞って説明を受けるほうが、効率よく進められます。
設計の段階では、なぜその変更が必要なのか、別の案とは何が違うのかを確認します。そして、自分が納得してから実装を任せる。この順番が大事なんですね。
また、別のAIにレビューしてもらったとしても、それを正しさの保証にはしません。最後は自分で確認する、という姿勢を保ちます。
他の人のコード変更を読むときには、背景や変更点を整理した「PR理解ガイド」をAIに作ってもらう方法も紹介されています。ただし、実装理由は、資料に書かれている内容に限定します。AIにもっともらしい理由を補ってもらうのではなく、確認できる情報をもとに理解するわけです。
そのうえで、元のコードも自分で確認して、自分の言葉でコメントします。
AIに手伝ってもらうことと、自分で考えることは両立できる。任せる範囲を決めることが、その第一歩になりそうですね。
....
さて、今日のzenncastは、5本の記事をお届けしました。
SlackにMarkdownを貼り付けて共有する方法、Claude Duetの機能と導入時の注意点、モックと実際のAWSをつなぐAWS Emulatorの役割、cdkd localを使ったローカル開発、そして、自分の理解を大切にするAIとの付き合い方をご紹介しました。
便利な道具ほど、できることと、確認が必要なことを知っておく。その大切さが、いろいろな場面で見えてきましたね。
各記事の詳しい内容は、ショーノートに書いてあります。気になった話題は、ぜひチェックしてみてください。
番組への感想もお待ちしています。「この機能を試してみました」「AIとはこんなふうに勉強しています」など、皆さんのお話も聞かせてくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入っていただけたら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回また皆さんにお会いできるのを楽しみにしています。お相手はマイクでした。今日も、すてきな1日をお過ごしください！