Yunosuke Yamada

Cloud Deploy は継続的デリバリーを行うための Google Cloud のフルマネージドサービスです。標準では Google Kubernetes Engine と Cloud Run (service と job) へのデプロイをサポートしていますが、カスタムターゲットを定義することでそれ以外の対象にもデプロイすることができます。今回はカスタムターゲットを利用して Cloud Run functions へのデプロイを自動化してみます。本記事では Cloud Deploy の基本的な概念（ターゲット、リリース、デプロイパイプラインなど）については説明しません。これら...

Cloud Deploy で Cloud Run functions に継続的デリバリーする

!本記事はネタ記事です！Cloud Run functions は Google Cloud の FaaS です。ユーザはコンテナ、ランタイム、Web サーバーを管理することなく、コードを書くだけでデプロイすることができます。本来はコンテナ化が不要な Cloud Run functions ですが、コンテナをデプロイできることをご存知でしょうか。 Cloud Run functions の仕組みユーザが Cloud Run functions にデプロイしたコードは複数の抽象化レイヤーの上で動きます。[1]一番内側にユーザが書いたコードがあり、その下にはまず Func...

「Cloud Run functions」にコンテナがデプロイできるの知ってる？

本記事は 3-shake Advent Calendar 2024 シリーズ 1 の 7 日目の記事です。 はじめにOWASP Top 10 for LLM Applications の 2025 年版が 11 月 18 日に発表されました。[1]OWASP Top 10 は Web アプリケーションのセキュリティリスクの中で最も重要な 10 個をリスト化したものであり、OWASP Top 10 for LLM Applications は名前の通り LLM を利用したアプリケーションに関するものです。本家は数年に一度の改訂ですが、こちらは LLM の技術進歩が早いためほぼ毎年...

セキュアな LLM アプリ開発：OWASP Top 10 for LLM 2025 と Vertex AI による実践

用語について オンライン評価とオフライン評価評価はそのタイミング、やり方によってオンライン評価とオフライン評価に分けられます。オンライン評価とは、システムやモデルが実際の運用中にリアルタイムで評価される手法です。オフライン評価は、事前に用意されたデータセットを使用し、システムやモデルの性能をテスト環境で評価する方法です。生成 AI アプリケーションの場合には、オンライン評価は実際のユーザが生成 AI を利用した際の入出力に対して評価を行います。特徴としては、模範解答を用意することができないため生成 AI による評価（LLM as a Judge）をします。オフライン評...

Google Cloud で生成 AI アプリを評価するアーキテクチャパターン

背景Google Cloud では Google Cloud Next '24 にて Vertex AI Studio の Prompt Version Management とその SDK Support が発表されました。[1]将来的には Google Cloud におけるプロンプト管理はこの機能を使うことになると思われますが、本記事執筆時点では SDK Support は公開されていません。そのため現時点で Google Cloud でプロンプトを管理するのにどのサービスを使うべきか検討した結果を共有します。検討にあたっては以下の観点を考慮しました。バージョン管理機...

Google Cloud でのプロンプト管理は Vertex AI Studio を使おう

2024 年現在、生成 AI のアプリケーションへの応用が進んでおり^{[要出典]}、運用のためのツールやサービスが登場しています。生成 AI 専用のサービスとしては LangSmith と Langfuse が有名で、それぞれモデルへの入出力やトレースなどを取ることができます。監視 SaaS である Datadog でも LLM Observability の機能がリリースされています。また先月末には Google Cloud のブログにて GenOps についての記事が投稿され、その中でロギングや評価についての記載もありました。https://cloud.google.com...

生成 AI アプリで収集するべきテレメトリは何か

2024 年 8 月 31 日に Google Cloud のブログにて「GenOps: learning from the world of microservices and traditional DevOps」という記事が投稿されました。https://cloud.google.com/blog/products/devops-sre/genops-learnings-from-microservices-and-traditional-devopsこれまでも LangSmith や Langfuse といった LLMOps ツールや Datadog の LLM Observ...

Google の提唱する GenOps って何？

Cloud Run はコンテナ化されたアプリケーションを実行するための Google Cloud のフルマネージドサービスです。Google Cloud 上でコンテナアプリを動かす場合、Cloud Run がファーストチョイスとなります。Next.js のデプロイ先としては Vercel が有名ですが、Google Cloud 上で動かしたい場合は Cloud Run になるでしょう。Next.js には Experimental ではありますが OpenTelemetry サポートがあり、Vercel でも Pro 以上のプランにすることでテレメトリを収集することができます。今...

Cloud Run 上の Next.js を OpenTelemetry で計装する

先日『フロントエンド監視の全体像と実現方法』という記事を投稿しましたが、その中でテレメトリについては触れませんでした（※本記事は上記記事の内容を知らなくても読み進められるようになっています）。というのは、テレメトリは可観測性を実現するための重要な概念ではあるものの、テレメトリを軸に監視を考えるのは手段の目的化になってしまうと考えているからです。重要なのはサービスにとって何を観測するべきかを考えることであり、テレメトリはそれを設計や実装に落とし込む際に現れるものです。一方で監視に対する理解を深める上では、テレメトリを軸に考えることも重要でしょう。そこで本記事ではフロントエンド監視に...

フロントエンドで収集するべきテレメトリは何か

必要性フロントエンドの監視はバックエンドやインフラのそれらと比べ、優先度が低くなりがちです。バックエンドやインフラでの障害はサービス継続に直結するため、これは当然と言えば当然なのですが、別の理由もあると考えています。それは計算リソースをサービス提供側が管理していないことです。例えばアプリケーションがインフラとして AWS を利用しているなら、AWS のリソースを管理するのはサービス提供側です。これは AWS 以外のクラウドサービスプロバイダやオンプレであっても同様です。一方でフロントエンドはエンドユーザのブラウザ上で動作し、これを管理しているのはエンドユーザです。フロン...

フロントエンド監視の全体像と実現方法

背景React ではフォームライブラリを利用する場合、ナイーブに実装するとフォームの UI とフォームライブラリが密結合になります。これは特定のフォームライブラリに限った話ではなく、React Hook Form, Formik, React Final Form といった主要なフォームライブラリ全てで当てはまる問題です。例えば React Hook Form では、フォーム全体の設定をuseFormで行い、各属性ではregister, Controller, useControllerを使って UI と React Hook Form を接続します。つまりフォームコンポーネ...

フォームライブラリに依存しないReactコンポーネント設計

最近、React のフォームライブラリを調査しました。その中でパフォーマンスについての言及は見かけるものの、実際に計測しているものが見当たらなかったので計測してみました。結論としては React Hook Form でなくても良いけど、パフォーマンスを気にするなら React Hook Form を選んでおくのが無難というところに落ち着きました。 要約入力欄 10 個、CPU 6× slowdown での計測結果ライブラリ1 文字入力した場合の再描画React Hook Form8ms 前後Formik100ms 前後Formik（<F...

パフォーマンスを気にするならReact Hook Formが無難

Linkerd は Kubernetes 用の軽量サービスメッシュです。複雑な設定なしにセキュリティ、可観測性、信頼性をクラスタに追加できるのが特徴とされています。また CNCF では Graduated Project としてホストされています。（ちなみにサービスメッシュのデファクトスタンダードとされている Istio は CNCF では Incubating Project です。）Linkerd の機能の 1 つにトラフィックの制御があります。これはある Pod にリクエストを投げられるのは特定の Pod だけというような制限をかけるためのものです。トラフィック制御の設...

Linkerdにおけるトラフィック制御

Codecov は、PR へのコメントや README のバッジのような方法でコードのカバレッジを可視化できるツールです。カバレッジを開発者に対して頻繁にフィードバックすることで、開発者はテストを意識するようになります。一方で世の中には星の数ほど言語がありますが Codecov がサポートしているものは意外と少ないです。https://docs.codecov.com/docs/supported-languagesまた色々な理由で Codecov を使いたくない / 使えないという場合もあるかと思います。この記事では Codecov 非対応の言語でも Codecov みたいな...

Codecov非対応の言語でもCodecovみたいなことをしたい時

React や TypeScript に限らず、明示的に型をつけた方が良いという主張です。帰結として React.FC をやめる必要はないと思います。 なぜ明示的に型を付けた方が良いのか 理由 1: コードが少しだけ分かりづらくなる型推論をコンパイラに任せたコードは書くのが楽で見た目もスッキリします。一方で読み手の人間の負担は少しだけ増えます。ソースコードに書かれていない情報を読み取る必要が出るからです。最近のエディタ / IDE はマウスホバーで型情報を表示してくれますね。しかし例えば GitHub 上で PR を見ているときは違います。型を確認するにはコードの別...

React.FCをやめる必要はない

タイトルの通りです。普通（？）のオブジェクト型に対して一部のプロパティを取り出したり削除したりしたい時にはPickやOmitを使いますね。ただPickとOmitはUnion typesに対して分配的には効きません（後述）。そこでUnion typesに対して分配的にPickやOmitをする方法を考えていきます。実際に作ろうと思ったときと同じ手順で説明していくので、これからGeneric typesを書いていきたい方の参考にもなればと思います。 結論// 補助的な型type KeyOfUnion<T> = T extends T ? keyof T : neve...

Union typesに対してPickやOmitをしたい時

LexicalはDraft.jsの後継となるテキストエディタフレームワークです。元々Metaで開発されていたものがOSSとして公開されました。https://github.com/facebook/lexicalLexicalは主にリッチテキストを実装するためのフレームワークですが、高度に抽象化されているためソースコードエディタを実装するのにも利用できます。ただコードに関するモジュールである@lexical/codeはドキュメントが虚無なため、本記事で使い方の紹介ができればと思います。https://lexical.dev/docs/api/lexical-code @...

Lexicalでシンタックスハイライトする

TypeScriptにはプロパティを必須にするRequiredというUtility Typeがある。type Props = {  a?: number;  b?: string;};const obj: Required<Props> = { a: 5, b: "test" }; // a, bが必須になるhttps://www.typescriptlang.org/docs/handbook/utility-types.html#requiredtypeRequiredは全てのプロパティを必須にする。なのでPropsのaのみ必須にしたい場合は次のようなU...