どうも、マイクです。おはようございます。
今日は二千二十六年七月十六日、木曜日の朝七時を回りました。ここからの時間は「zenncast」、きょうも最新のテックトピックを、Zennのトレンド記事からピックアップしてご紹介していきます。
きょう紹介する記事は、ぜんぶで五本です。モバイルアプリ開発、メールの新しい運用方法、AIでの調査ノートの作り方、Gitの履歴の読み解き方、そして企業でのClaude導入戦略まで、かなり幅広いラインナップになっています。
まず一本目。
モバイルアプリ開発、とくにReact Nativeまわりが、この数年で「Reactエンジニアにとても優しくなったよ」という話題です。
昔のReact Nativeって、Bridge方式でネイティブと通信していて、古いタイプのNative Moduleも相まって、「パフォーマンス微妙だなぁ」とか「バージョンアップつらすぎる…」っていうイメージ、あった人も多いと思うんですよね。描画がカクカクしたり、起動が遅かったり。
それが、いまはいわゆる「New Architecture」と呼ばれる仕組みが入ってきていて、状況がガラッと変わりました。
具体的には、JSI、Fabric、TurboModules、Codegenみたいな新しい仕組みと、専用のJavaScriptエンジンであるHermes。このあたりのおかげで、アプリの描画のカクつきや、起動のもたつきが大きく改善してきている、と記事では説明しています。
さらに、Expoの立ち位置もだいぶ変わりました。
昔は「学習用ツール」とか「プロトタイプ作るときに便利」くらいの印象だったと思うんですが、いまはExpo Go、Development Build、EASといった機能が揃っていて、「実運用でも使える標準レール」になってきた、と。ビルドやストア申請周りの面倒な作業も、かなり自動化されるようになっているそうです。
ルーティングも、Expo Routerを使うと、Next.jsみたいなファイルベースルーティングができて、Webフロントの感覚で画面遷移を組めるのもポイント。
技術選定の面でも、「TypeScript と Expo、TanStack Query、Zustand、React Hook Form、Zod、NativeWind、gluestack-ui、MMKV、Supabase」といった、いわば「定番構成」がもう見えてきていて、Webフロントエンドの知識を、ほぼそのままモバイルに持ち込めるようになっている、とまとめています。
この結果として、Reactエンジニアが、そこまで大きな学習コストを払わなくても、夏休みの個人開発レベルのアプリから、本格的なプロダクトまで、モバイルアプリ開発にチャレンジしやすい環境が整ってきたんじゃないか、というのが筆者の主張ですね。
「昔つらかったからReact Nativeはちょっと…」という方ほど、いまの環境を一度見直してみると、印象がずいぶん変わるかもしれません。
。。。。
続いて二本目。
Cloudflareの新機能「Email Sending」を使って、独自ドメインのメール送受信を、CloudflareとGmailだけで完結させちゃおう、という記事です。
ポイントは二つあって、まず「受信」は、Cloudflareの無料機能であるEmail Routingを使います。
自分の独自ドメインに届いたメールを、自動的にGmailに転送してくれる機能ですね。これで、受信に関しては別サービスを契約しなくても済む。
一方、「送信」のほうは、CloudflareのEmail Sendingが、SMTPに対応したことで実現します。
Gmailには「他のメールアドレスから送信」という機能があるので、そこにCloudflare Email SendingのSMTPサーバーを設定してあげる。そうすると、Gmailの画面からメールを書くんだけど、差出人は自分の独自ドメインのアドレスで送れる、というわけです。
これまでだと、たとえばPurelymailみたいなメールサービスを別契約したり、GmailのSMTPを使おうとすると、「example@gmail.com の代理」みたいな表記が出ちゃって、ちょっと見た目が微妙だったりしましたよね。
この記事の方法を使うと、その「代理」表示を避けつつ、Gmailのインターフェース一本で独自ドメインメールを完結できるのが魅力です。
ただし注意点もあって、CloudflareのEmail Sendingを使うには、月五ドルのWorkers有料プランが必要です。
送信量は、月三千通までは追加料金なしという条件。個人利用や小さめのサイトなら、この枠で十分収まるケースも多そうですが、そこは送信ボリュームとコストを見ながら、という感じですね。
。。。。
三本目。
こちらは、Claude Code用の「調査ノート作成スキル」を紹介している、サービス紹介系の記事です。
論文や公式発表を横断して調べるときに、「調査して」とか「サーベイして」と指示すると、自動でいい感じの日本語ノートを作ってくれる、というものですね。
このスキルがやってくれることは、ざっくりいうと、arXivの論文、公式発表、公式ドキュメント、技術ブログ、それからベンチマークを出している会社の発表なんかを集めてきて、一次情報と二次情報を分けながら整理してくれる、という流れです。
特徴は四つ挙げられていて、
まず一つ目が、「媒体ごとに手順を決めた収集フロー」。どこからどういう順番で情報を拾うか、ルールを決めているので、調査の抜け漏れが起きにくいようになっています。
二つ目が、「数値や主張の一次情報と二次情報を、必ず見分けて裏を取る」という規律。
たとえば、ある性能指標の数字が出てきたときに、「これは論文本体に書いてある一次情報なのか」「誰かのブログが勝手にまとめた二次情報なのか」をきちんと区別して、必要なら元のソースまでたどる、という動きをしてくれます。
三つ目は、セキュリティハーネス。
Webページを「信用できない入力」として扱って、危険なコマンドを実行しないようにしている点です。たとえば、拾ってきたスクリプトをいきなり実行しちゃう、みたいなことはしないように、あらかじめガードをかけている。
四つ目が、読者のレベルに応じて専門用語解説を三段階で切り替えられるオプション。
初心者向けに、かなりかみ砕いた説明にするか、専門家向けに用語の前提知識がある前提で書くか、というのを切り替えられるので、あとからチーム内で共有するときにも便利、という話が出てきます。
実際に、新しいモデルのベンチマーク調査にこのスキルを使うと、Bashみたいなコマンドラインを一切触らなくても、安全に、出典付きのノートができあがるそうです。
あとから「このグラフどこから持ってきたんだっけ？」と根拠をたどりやすくて、専門外のメンバーにも共有しやすい。AIにざっくり調べさせる、から一歩進んで、「ちゃんと出典管理された調査ノートをAIに作ってもらう」という方向性の事例として、おもしろい記事になっています。
。。。。
四本目。
ここからはGitの話で、「git log --graph --oneline --decorate --all」を使って、コミット履歴から開発状況を読み解こう、という内容です。
このコマンドを実行すると、一画面の中で、どのブランチがどこで分岐して、どこでマージされたか、記号付きでざーっと表示されます。
アスタリスクや縦棒、スラッシュ、バックスラッシュみたいな記号が並ぶんですけど、その意味が分かると、「ああ、ここでfeatureブランチが生えて、ここでmainにマージされたのね」とか、図を描かなくても頭の中にブランチの流れを思い描けるようになります。
さらに、「(HEAD -> main)」みたいな表示から、いま自分がどのブランチ、どのコミットを見ているかが分かります。
HEADがどこを指しているかをちゃんと意識することで、「あれ、別ブランチで作業してたつもりなのに、mainでコミットしちゃった…」みたいな、ブランチ取り違えのミスを減らすことができる、というわけですね。
タグの表示も重要で、「(tag: v一・一・ゼロ)」みたいな形で出てきます。
どのコミットがリリース版なのかがひと目で分かるので、そのタグの位置と、そのあとに続いているコミットを見比べれば、「この修正はまだリリースされてないな」とか、「この機能は次のリリース候補だな」といった判断がしやすくなります。
それから、「origin/main」みたいなリモート追跡ブランチの表示もポイントです。
ローカルのmainが、リモートのmainより進んでいるのか、遅れているのかが一目で分かるので、「これはpushすべきタイミングか、それともまずpullして取り込むべきか」をすぐ判断できます。
記事では、こういった四つの観点――
記号でブランチの流れを読むこと、HEADの位置を意識すること、タグでリリース状況を把握すること、リモート追跡ブランチで同期状況を知ること――
これらを押さえるだけで、履歴から「いまの開発の状況」と「自分が次に取るべき操作」を一気に読み取れるようになる、と説明しています。
なんとなく`git log`を眺めているだけ、という人には、ちょっとしたコツ集として役立ちそうな内容でした。
。。。。
そして最後、五本目。
ここでは、Claude CoworkやClaude Codeを、企業で本格導入するなら、「Amazon Bedrock経由がいいんじゃないか」というオピニオンが語られています。
業務の中でエージェントを使おうとすると、扱うデータがかなり機密度の高いものになりますよね。
たとえば、社内の業務資料とか、ソースコードとか、お客さんの情報とか。ここでは、単に「便利かどうか」だけじゃなくて、認証をどうするか、データをどう扱うか、監査ログをどう残すか、コストをどう管理するか、といった設計が課題になってきます。
この記事の筆者は、そこに対して「Amazon Bedrockを経由することで、二つの大きな価値がある」と整理しています。
ひとつは、顧客データがモデル学習に使われない、という明確なデータ保護モデルが用意されていること。
もうひとつは、既存のAWSの認証、監査、請求の仕組みにそのまま乗せられることです。
たとえば導入のステップとしては、最初のPoC段階ではAPIキーで素早く試してみて、うまくいきそうだとなったら、本番ではIAM Identity Centerや、アプリ内のAWSサインイン、外部IdPとの連携、それから必要に応じてLLM Gatewayなんかも組み合わせていく。
そうすることで、「誰がどのエージェントをいつ使ったのか」といった監査ログをきっちり残したり、部署やユーザーごとに利用権限を分けたり、コストを細かく配賦したり、といった企業向けの要件を満たしやすくなります。
筆者が言っているのは、「単にClaudeのAPIを直接叩ければいい、という話じゃない」というところですね。
CoworkとCodeを、安全に、そして大規模にスケールさせて展開していくための基盤として、Amazon Bedrockを位置づけるべきだ、と締めくくっています。
社内でAIエージェント導入の企画をしている人には、「技術的に動けばOK」から一歩踏み込んで、ガバナンスやコスト管理まで含めた議論の材料になりそうな内容でした。
。。。。
というわけで、きょうのzenncast、ざっとおさらいしていきましょう。
まずは、React Nativeまわりの世界がNew ArchitectureやExpoの進化で、Reactエンジニアにとても優しい環境になってきた、という話。
次に、CloudflareのEmail SendingとEmail Routingを組み合わせて、CloudflareとGmailだけで独自ドメインメールを運用する方法のお話。
三本目は、Claude Code用の「調査ノート作成スキル」で、論文や公式発表を安全に横断サーベイして、出典付きノートを自動生成するサービス紹介。
四本目は、「git log --graph --oneline --decorate --all」を使って、ブランチの流れ、HEAD、タグ、リモート追跡ブランチから、履歴だけで開発状況と次の一手を読み取るテクニック。
そして五本目、Claude Cowork / Codeを企業で本格導入するなら、データ保護や認証・監査・コスト管理の観点から、Amazon Bedrock経由を基盤として検討しよう、というオピニオンでした。
それぞれの記事の詳しい内容や、実際の設定方法、図解なんかは、ショーノートのほうにリンクをまとめておきますので、気になったトピックがあった方は、あとでじっくり読んでみてください。
この番組「zenncast」では、みなさんからの感想やフィードバックもお待ちしています。
「こんなテーマを取り上げてほしい」「この技術の裏話聞きたい」みたいなリクエストも大歓迎ですので、ぜひ送ってください。
それでは、きょうはこのへんで。
ここまでのお相手はマイクでした。次回のzenncastで、またお会いしましょう。お仕事や勉強の合間に、よい一日をお過ごしください。