Aarif Sumra

Md Abdur Rafi Ibne Mahmood

Abdur Rafi

Abinash Ghosh

Md. Abu Farhad

Adrian Macarenco

Ahmed Madkor

Ahmed Naseef Chowdhury

Akito Ando

Alexander Bondarenco

Amdadul Hoque

An Wonho

Andrei Hogea

Andrew Bailly Lloyd

Antonin Joly

Aquibur Rahman Khan

Arifena Tamrin

Md. Arman Morshed

Arman Morshed

S M Asad Rahman

Md. Aslam Hossin

Aslam Hossin

Md Atiqur Rahman

Atiqur Rahman

Azat Martirosyan

Bob De Kort

Brett R. Toomey

Carmen Mihaila

Cheryl Cheng

Chris Combs

Christian Weinberger

Christofer Henriksson

Cuong Le

Daichi Kakimoto

Daisuke Hirata

Daisuke Oba

Patrick Dan Lacuna

Danny Lee

Deniz Tunç Tuncer

Dennis Haulund Nielsen

Dinakar Maurya

Dipanjal Maitra

Dominik Hádl

Dominik Ringler

Dongyu Wang

Eduard Ablekimov

Emelie Lindh

Enkh Amgalan

Enric Macias Lopez

Esmaeil Abedi

Fahim Ahmed

Faisal Ahmed

Faisal Islam

Felipe Chaves

Ferdous Al-Quraeshi

Genita Tahiri

Go Nakano

Graham Campbell

Golam Shakib Khan

Gwanmuk Kang

Hans Hofner

Harol Higuera

Hassan Saleh

Heidi Puk Hermann

HieuLuan Quan

Hiroki Saito

Hitoshi Hasumi

HongYang Chen

Hui Zhou

Inna Marchenko

Mohammed Istiaque ISLAM

Jahid Hasan Naiem

Jakob Mygind

James von Hagel

Japan Security Testing Team

Jigna Patel

Jinma Yamashita

Jiri Bucek

Joao Alves

Johnny Sørensen

Jonas Stokholm Olsen

Jonas Schwartz

Jose Nieto

Juan Eduardo Castaño Nestares

Juraj Longauer

Kamel Mohamad

Kento Morita

Khairullo Abdulaev

Kiyotaka Kunihira

Kousar Sharmin JENNY

Kun Luo

Li Huang

Lin Chen

Diarmaid Lindsay

Lucas Sales

Luis Forero

Mahamud Hasan Rashel

Mahmudul Hasan

Majid Mvulle

Marius Constantinescu

Markus Rubey

Marthy Maisog

Masumi Kanazawa

Matko Smoljan


この記事では、IT管理の仕事からバックエンド・インフラエンジニアに転向してみて意外だったこと、そして思っていた以上に役に立ったスキルについて書いてみます。

数年間、私はIT管理の仕事をしていました。毎日コードを書くわけではなく、会社がスムーズに回るようにするのが役割でした。ユーザーアカウントや権限の管理、海外のITチームとの調整、そして組織全体が使うツールの選定などです。

新しいEDR（エンドポイント検知・対応）やMDM（モバイルデバイス管理）を導入するときは、製品の比較検討からPoCの実施、全拠点への展開のリードまで担当していました。

今は、バックエンド・インフラエンジニアとして働いています。

技術的に馴染みのある部分もありますが、仕事の中身はまったくの別物です。振り返って一番意外だったのは、学ばくてはいけないことの多さ……ではなく、これまでの経験が今も毎日のように役立っていることでした。

## 同じツールを、違う立場から見る

個人的に一番面白いと感じているのが、かつて自分が管理していたツールを、今度は使う側で触っていることです。

IT管理者だった頃は、JiraやConfluence、Miroをはじめ、いくつものSaaSを管理していました。プロジェクトの設定や権限の管理、ライセンスの割り当て、それに「このボードにアクセスできない」「このスペースに追加してほしい」といった依頼への対応もしていました。ツールのことは隅々まで分かっているつもりでしたが、それはあくまで"管理者としての視点"でした。

でも今は、ただの一ユーザーです。

スプリントプランニングでJiraのチケットを動かし、Miroで設計のアイデアを出し合い、チームのみんなが実際に読んでくれるドキュメントを書く。管理していたときと使っているときとで、同じツールなのに感じ方がこんなに違うのか、とちょっと面白くなります。

この立場の変化は、新しい視点もくれました。裏側の仕組みが分かっているので、なぜ権限が足りないのか、なぜワークフローがこう動くのか、だいたい見当がつきます。その一方で、使う側になってみて、昔の自分が下していた管理上の判断が、毎日ツールを使う人たちにとっては地味にストレスだったんだろうな、とも気づきました。

小さなことですが、大事な学びでした。両方の立場を経験すると、関わる人みんなの気持ちが自然と分かるようになる、ということです。

## IT管理から持ち込めたもの

ITからソフトウェアエンジニアへの転向は「ゼロからのやり直し」だと思われがちです。でも、私の場合はそうではありませんでした。ITで身につけたスキルの多くが、思った以上にそのまま活きています。

EDRやMDMの導入は、ソフトを入れて終わり、ではありませんでした。要件をまとめ、ベンダーを比較し、試験導入をして、展開を計画し、ユーザーとやり取りし、導入後のサポートまでやる。これは、機能をアイデアから本番まで届けるソフトウェア開発と、そんなに変わりません。

海外のITチームと働いた経験も、分かりやすく伝えること、決めたことを記録に残すこと、非同期で仕事を進めること、文化や時差を越えて協力することを教えてくれました。こうしたスキルは、エンジニアリングでもITのときと同じくらい大事です。

セキュリティも一つの例です。ID・権限・アクセス権を何年も管理してきたおかげで、最小権限、認証、認可といった考え方は体に染みついています。違うのは、今はそういう仕組みを"設定する"側ではなく、"作る"側にいることです。

仕事の向きが変わったんですね。以前は誰かが作ったツールを運用する立場でしたが、今は自分でシステムを作れる立場になりました。

## AI時代にエンジニアになるということ

一つ、予想していなかったことがあります。AIが驚くほど良いコードを書けるようになった、まさにそのタイミングで、私はエンジニアになりました。

少し前まで、開発者はまず「書いたコードの質」で評価されるものでした。でも今は、AIがきれいに動くコードを数秒で書いてしまうこともあります。

そこで自然と、こんな疑問が浮かびます。コードをAIが書くなら、エンジニアはどこで価値を出すのか？

これについてはずいぶん考えました。そして、シンプルな結論にたどり着きました。価値は、もうコードを書くことだけにはない。その"まわり"すべてにある、ということです。

機能を最初から最後まで自分ごととして持つことは大事です。AIは関数を生成できても、ビジネスの背景を理解したり、チームと連携したり、本番にデプロイしたり、リリース後にその機能を支えたりはできません。

チームを助けることも、同じくらい大事です。ソフトウェアはみんなで作るものです。コードをレビューしたり、知識を共有したり、ドキュメントを良くしたり、詰まっている人を助けたり。そういうことが、チーム全体の力を底上げします。

そして、たぶん一番大事なのがクライアントを理解することです。クライアントが本当に必要としているものをそのまま言葉にしてくれることは、めったにありません。これはエンジニアになるずっと前、会社全体のツールを選んでいた頃に学びました。最初の要望の裏にある"本当の課題"をつかみ、前提を疑い、ビジネスのゴールを技術的な判断に落とし込む。ここはまだ、人の判断が必要な部分です。

AIはとてつもなく便利な道具ですが、こういう"理解"の部分までは代わってくれません。

むしろAIは、「良いエンジニアとは何か」の意味を変えたのだと思います。コードを書くことは今も大事ですが、それだけでは足りなくなりました。

## おわりに

インフラを管理する側から作る側へ移ったことは、これまでのキャリアで特に良かった決断の一つです。

これまでの経歴は、足かせになるどころか、しっかりした土台になってくれました。プロジェクトを自分ごととして進める姿勢、海外チームとの協働、セキュリティの感覚、そして自分たちが作るシステムを使う人への理解です。

AIの台頭と同じ時期にエンジニアのキャリアを始めたことは、思いがけない形で強みになりました。最初から、コードを書くこと以外のスキルに向き合わざるを得なかったからです。課題を理解すること、機能を最初から最後まで見届けること、そして周りの人がうまくいくように手を貸すこと。

もし今ITの仕事をしていて、次はエンジニアかな……と迷っているなら、こう言いたいです。あなたはたぶん、自分で思っている以上に"活かせるスキル"を、もう持っていますよ。

_Article Photo by [Brett Sayles](https://www.pexels.com/photo/blue-wires-connected-to-server-4716292/) on Pexels_


インフラを管理する側から、作る側へ

クラウドサービスが普及した現在では、システム基盤としてAWSやGCP、Azureなどを利用するケースが一般的になっています。

一方で、製造業や公共分野などでは、インターネットへ接続できないオンプレミス環境でシステムを構築・運用するケースも依然として存在します。

今回、「既存の Windows Server を利用したい」、「インターネット接続ができない」という制約の中で、Linuxコンテナを利用したシステムを構築する機会がありました。

そこで、Windows Server 2025上にWSL2とPodmanを導入し、TCPサーバーをコンテナとして常駐運用できる環境の構築を検証しました。

本記事では、構築手順を細かく説明するというよりも、実際に構築して分かったことや苦労した点をお話します。


## 検証環境

今回利用した環境は以下の通りです。

| 項目 | バージョン |
| -- | -- |
| OS | Windows Server 2025 Standard |
| WSL Distribution| podman-machine-wsl-os 5.3 |
| Podman | 5.8.4 |
| コンテナ | Linux Container |


また、サーバーはインターネットへ接続できない環境を想定しています。

そのため、
- WSL
- Podman
- コンテナイメージ

はすべてオンライン環境で取得し、USBメモリ経由で持ち込む構成としました。

## ゴール

> Windows Serverを再起動しても、自動的にLinuxコンテナが起動し、TCPサーバーとして待ち受けを継続できる環境を構築すること


最終的には次のような構成になりました。
![]({{ sitePrefix }}/assets/img/articles/2026-10-13-Building-a-Production-Ready-Offline-Podman-Environment-on-Windows-Server/stack_layer.webp)


また、
- Windows起動時にタスクスケジューラでPodman Machineを自動起動
- コンテナはsystemd管理
- コンテナ障害時は自動再起動
- メンテナンス時は明示的にコンテナを停止可能

という、実運用を意識した構成を実現できました。 

## 構築手順

構築の流れは次のようになります。

太字表記の工程は、インターネット接続環境であればコマンド１つで完了する手順ですが、オフラインの場合は工夫が必要です。

1. **Windows ServerでWSL2を有効化**
2. **WSLを更新**
3. Podman for Windowsをインストール
4. **Podman Machineを構築**
5. **コンテナイメージをインストール**
6. コンテナ起動
7. systemdサービス化
8. タスクスケジューラでWindows起動時にPodman Machineを起動

今回特に便利だと感じたのは、

```powershell
podman machine init --image-path
```

が[rootfs](https://github.com/containers/podman-machine-wsl-os)を指定して初期化できる点でした。

オンライン環境で取得しておいたrootfsを利用することで、インターネット接続がない環境でもPodman Machineを構築できます。

( *オンライン環境で Podman Machine を作成して、machine イメージダンプをオフラインサーバに持ち込む... という手順を踏むと、沼に溺れます* )

## 構築中にハマったこと

一番時間を使ったのは、ネットワーク周りでした。

Windows起動後、

- WSLは正常起動
- コンテナも正常起動
- portproxy設定も存在

しているにも関わらず、TCPサーバーに接続できない問題が発生しました。

```powershell
netstat
```
を確認すると

- 127.0.0.1 は 常時 LISTEN
- NIC側IP は LISTENしていないことが**たまにある**

という現象が発生しました。 

再現率が100%ではない問題は、わたしのエンジニア魂に火がつきます。

原因を切り分けるため、
- WSL
- Podman
- Windows ファイアウォール
- portproxy
- IP設定

を順番に確認しましたが問題は見つかりませんでした。

最終的に、portproxy を管理している `IP Helperサービス` を再起動することで、NIC側IPがLISTENしました。

```powershell
Restart-Service iphlpsvc
```

現時点では、

**Windows起動時のIP Helperサービス初期化タイミングが影響している可能性が高い**

と考えています。

暫定対応として、

1. Windows起動後 WSL(podman machine) 起動
2. 約60秒待機
3. IP Helperサービスを再起動

というタスクをタスクスケジューラ登録することで安定して動作しました。 

## わかったこと

今回の検証で感じたことは3つあります。

### Windows + WSLは考慮事項が多い

Linuxだけで完結する環境とは異なり、
- Windows
- Windows ファイアウォール
- WSL
- Podman
- systemd

という複数のレイヤーが存在します。

障害が発生した場合も、どのレイヤーの問題なのか切り分けが重要でした。

### ネットワーク構成は理解が重要

TCP通信一つを取っても、

![ネットワークレイヤー]({{ sitePrefix }}/assets/img/articles/2026-10-13-Building-a-Production-Ready-Offline-Podman-Environment-on-Windows-Server/network_layer.webp)

という経路になります。

Linux単体よりも、通信経路を把握しておく必要があると感じました。

### オフライン環境は準備がすべて

クラウド環境では当たり前に取得できる

- インストーラー
- コンテナイメージ
- Linux rootfs

も、オフラインでは事前に準備しておかなければなりません。

「インターネットが使える前提」がいかに多いかを改めて実感しました。

## 今後やってみたいこと

今回の構築は一通り実現できましたが、まだ改善したい点があります。

- PowerShellとシェルスクリプトによる環境構築の自動化
- systemdサービス生成の簡略化
- Windows起動時の処理をさらに安定化
- portproxy周りの挙動を継続調査


## まとめ

クラウドネイティブなツールが前提になりがちですが、今回は **「既存資産を活かす」**、**「インターネットに繋がらない」** という達成すべき要件が先にあり、その要件を満たす手段としてWSL2+Podmanを選びました。

今回の検証を通じて、Windows Server上でも、WSL2とPodmanを組み合わせることで、オフライン環境においてLinuxコンテナを実運用できる構成を構築できました。

一方で、Windows・WSL・Linuxの境界部分では、ネットワークや起動順序など、Linux単体では意識しない課題にも遭遇しました。

今後も自動化や運用改善を進めながら、オフライン環境でも再現性の高いコンテナ実行基盤を目指していきたいと思います。

Windows ServerにWSL・Podman環境を構築し、オフライン環境でLinuxコンテナを運用してみた


モンスターラボのエンジニアリングマネージャーの奥田です。

現代のソフトウェア開発は生成AIの進化によって大きく変わってしまったように見えます。
しかし全て変わってしまい、これまでの知識や考え方は全く通用しなくなってしまったのでしょうか。
ソフトウェア開発の何が変わって何が変わっていないのか。ソフトウェア開発における普遍的な価値とはなんなのか。
その謎を解明するためXP祭り2026に参加してきました。

# XPとは

XPはeXtreme Programming(エクストリーム・プログラミング)の略で、高品質で変更に柔軟に対応できるソフトウェアを開発するためのアジャイル開発手法の一つです。
XPはスクラムとは異なり開発サイクルやバックログ管理には詳しく言及していないため、プロジェクトにそのまま適用するのは難しい印象があります。
しかし、ペアプログラミング、継続的インテグレーション、テスト駆動開発などのプラクティスは現代のソフトウェア開発で広く取り入れられており、間接的にXPを実践している組織も多いと思います。

# XP祭りとは

XP祭りは、日本XPユーザグループ(XPJUG)が主催しているイベントで、2002年より毎年秋に開催されています。
2026年は9月5日(土)にオンラインとオフラインのハイブリッドで開催され、オフライン会場は横浜にある三菱電機さんのオフィス、Serendie Street Yokohamaでした。

イベントページ: https://fortee.jp/xpfest-2026

# 印象的だったセッション

## 基調講演: サンキュー、XP (角 征典)

基調講演は、多くの書籍の翻訳を手がけておられる角さんでした。私も「リーダブルコード」、「メタプログラミングRuby」、Cleanシリーズなどの翻訳本を読ませてもらってます。
講演は「サンキュー、チャック」へのオマージュで現在→全盛期→過去と時系列を逆に辿る全3部で構成され、表層的なXPへの理解から徐々に本質を掘り下げていくものでした。

映画に関する深いサンプリングもあり、90分間と長丁場でしたがとても楽しく拝聴さしていただきました。でも、一言でXPが何か、っていうのは言い表せないなと思いました。
引用を用いて説明されること、「シンプリシティ」における「agency(行為主体性)」や「simplicity」も、ソフトウェアクラフトマンシップ宣言や「Clean Craftsmanship」における「プログラマーの誓い」も、XPの5つの価値も、プログラマやソフトウェア開発の文脈ではあるけど、人類が尊厳を持って生きるために重要なものを言葉を変えて表現しているものなんだなと思います。
全編を通して"XP contains multitudes"が一つのテーマだったと思いますが、それはソフトウェア開発が人類の営みなのであって、つまりオマージュ元の"I (人間) contain multitudes"ということなんだなと納得しました。

スライド: https://kdmsnr.com/slides/20260905_xp

## XPについて語るときに私たちの語ること (関将俊、深谷美和)

Ruby CommitterでありdRubyの開発者でもある関さんとeXtremeテスター深谷さんのセッションでした。
XPの方法論について具体的に触れられたわけではないものの、25年所属された「あのチーム」を離れて新しいチームに所属されても、いつも通りソフトウェアを触って（テストして）、チームと関わっていたらまたいい感じになったというお話でした。
再現性があったのは、元のチームメンバーの考え方や相性もあったと思いますが、お二人のプロダクトをより良くしたいという、意識とか考えとも違う、もっと根本的な気持ち（当たり前）だから浸透したんだろうなと思います。
忍者式テストの「全部テストする」とか、「マニュアル見ながらテストしてても問題に気づけない」という言葉とかはそういう当たり前の中から出てくるものだなと思います。
それはそうというのはわかるけど、実際そこまでできるかというと、みたいな現実的に見えて建設的でない気持ちの背筋をピキッと伸ばされました。

スライド: https://speakerdeck.com/m_seki/what-we-talk-about-when-we-talk-about-xp

# まとめ

ソフトウェア開発の方法論やツールは生成AIの進化によって大きく変わりました。それは間違いないです。
一方で人が作り、人が使うという本質が変わらない以上、ソフトウェア開発（に限らずプロダクト開発全般、さらには人類の営み）の核となる部分は普遍だなと実感しました。
人（仲間や顧客）を信頼・尊重し、良いコードやプロダクトを作るための努力を怠らず、世の中をちょっと良くする取り組みを続けていく。
それを続けていこうと思える良い機会となりました。サンキュー、XP！サンキュー、XP祭り！

# 終わりに

私は今回XP祭りに参加するために島根県松江市からサンライズ出雲(!)に乗って横浜まで行きオフライン参加しました。
モンスターラボでは知識やスキルの向上のためにカンファレンスやコミュニティ、勉強会への参加を積極的に支援しています。
そしてより良いプロダクトの開発に一緒に取り組む仲間を募集中です！

求人ページ: https://monstar-lab.com/jp_ja/careers


サンキュー、XP。サンキュー、XP祭り。 - XP祭り2026に参加してきました

AI-DLC実践ガイド: AWS提唱のAI駆動開発ライフサイクルを現場で回す【実測データ公開】


生成 AI を「使う」だけでなく「アプリに組み込む」とどうなるのか。これを手を動かして理解したくて、人物写真をアップロードすると顔の属性（性別的な見た目）だけを別の性別に変換する学習用 Web アプリを個人で作りました。外部の画像生成 API には一切頼らず、推論まですべてローカルで完結させているのが特徴です。本記事では、その構成と実装上の判断、つまずいた点を技術寄りに整理して共有します。

## なぜ「ローカル完結」にこだわったのか

顔写真は最もセンシティブな個人データのひとつです。学習目的とはいえ、自分や知人の顔画像を外部の画像生成サービスへ送るのは気が進みませんでした。そこで最初の制約として「画像は外部に送らない。検出も生成もすべて自分のマシン上で行う」と決めました。

この制約は副次的に良い学習効果も生みました。クラウド API を叩くだけでは、モデルのロードコスト、推論の重さ、デバイス（CUDA / MPS / CPU）ごとの挙動差といった「現実の運用で効いてくる部分」が見えません。ローカルに閉じることで、これらと正面から向き合うことになりました。

## 全体構成

アプリはシンプルな 3 ステップのフローで動きます。画像アップロード → 人物・顔の検出 →  顔属性を選んで変換、という流れを 1 枚の SPA から試せるようにしています。

技術スタックは以下の通りです。

| カテゴリ | 採用技術 |
|---|---|
| バックエンド | Python 3.12, FastAPI, Uvicorn |
| 顔検出 | MediaPipe, OpenCV |
| 画像変換 | Diffusers, Transformers, PyTorch |
| パッケージ管理 | uv |
| インフラ | Docker, Docker Compose, devcontainer |
| Lint / テスト | Ruff, pytest |

API は 3 本だけです。ヘルスチェックの `GET /health`、画像を受け取って検出結果を返す `POST /upload`、性別を指定して変換画像を返す `POST /transform`。変換は非同期ポーリングではなく、1 リクエストで結果を返す同期方式にしました。学習アプリとして「リクエストを送る → 結果が返る」という因果関係を体感しやすくするためです。

## 入口を固める: バリデーションと検出

AI に画像を渡す前に、まず入力を厳しく検証します。受け付けるのは JPEG / PNG / WebP のみ、サイズは最大 5 MB。拡張子・MIME タイプ・サイズを「AI 処理が始まる前」にチェックするのがポイントで、ここを通過しないものは一切モデルに触れさせません。

検出は人物検出と顔検出の 2 段構えにしています。顔検出には MediaPipe の `FaceDetection` を使い、検出器はモジュールレベルでキャッシュしてリクエストごとの初期化コストを避けています。

```python
_detector: mp.solutions.face_detection.FaceDetection | None = None


def _get_detector() -> mp.solutions.face_detection.FaceDetection:
    global _detector
    if _detector is None:
        _detector = mp.solutions.face_detection.FaceDetection(
            min_detection_confidence=0.5
        )
    return _detector
```

顔のバウンディングボックスは相対座標で返ってくるので、画像サイズを掛けてピクセル座標に変換し、画像の境界をはみ出さないようにクランプしています。この bbox は検出だけでなく、後段のマスク生成でもそのまま再利用します。

なお人物の人数カウントは現状プレースホルダ実装（常に 1 人とみなす）で、YOLO による厳密な人数判定は次フェーズの宿題として切り出しています。学習アプリでは「動く最小構成を先に通す」ことを優先し、検出の差し替えポイントだけ用意しておく、という割り切りです。

## 中核: 顔領域だけを inpaint する

最初は画像全体を `StableDiffusionImg2ImgPipeline` で変換する方式を試しました。これは手軽ですが、背景や構図、服装まで一緒に変わってしまい「同じ人の顔属性だけ変えた」感が出ません。

そこで主実装は `StableDiffusionInpaintPipeline` による顔領域インペインティングに切り替えました。顔の bbox から白黒マスクを生成し、白い部分（顔）だけを再生成、黒い部分（背景・構図・照明）は維持する、という発想です。

マスクは矩形ではなく楕円で、しかも 1.5 倍に拡張して描いています。検出矩形ぴったりだと髪の生え際やあごのラインで継ぎ目が目立つため、余白を持たせて自然に馴染ませる狙いです。

```python
def generate_face_mask(
    image: Image.Image,
    bbox_px: tuple[int, int, int, int],
    expand_ratio: float = 1.5,
) -> Image.Image:
    img_w, img_h = image.size
    x, y, w, h = bbox_px

    cx = x + w / 2
    cy = y + h / 2
    half_w = w * expand_ratio / 2
    half_h = h * expand_ratio / 2

    x1 = max(0, int(cx - half_w))
    y1 = max(0, int(cy - half_h))
    x2 = min(img_w, int(cx + half_w))
    y2 = min(img_h, int(cy + half_h))

    mask = Image.new("L", (img_w, img_h), 0)
    draw = ImageDraw.Draw(mask)
    draw.ellipse([x1, y1, x2, y2], fill=255)
    return mask
```

プロンプトも試行錯誤の塊でした。「同じ人物・同じポーズ・同じ背景・同じ照明」を繰り返し指示しつつ、ネガティブプロンプトで「複数人物」「西洋的な顔立ち」「CG・アニメ調」「過度なエアブラシ肌」を強く抑制しています。inpaint 側は `strength=0.75`, `guidance_scale=8.0`, `num_inference_steps=30` で、顔をしっかり作り替えつつ破綻しないバランスを探りました。

## モデルのロードコストとどう付き合うか

Diffusers のパイプラインはロードが重く、リクエストのたびに読み込んでいたら使い物になりません。対策として、パイプラインのロードを最初の `transform()` 呼び出しまで遅延させ、一度ロードしたサービスインスタンスはリクエストをまたいでキャッシュしています。

```python
_service_cache: dict[tuple[str, str], GenderTransformService] = {}


def get_transform_service(
    settings: Settings = Depends(get_settings),
) -> GenderTransformService:
    key = (settings.LOCAL_INPAINT_MODEL_ID, settings.LOCAL_DEVICE)
    if key not in _service_cache:
        _service_cache[key] = LocalInpaintTransformService(
            model_id=settings.LOCAL_INPAINT_MODEL_ID,
            device=settings.LOCAL_DEVICE,
        )
    return _service_cache[key]
```

FastAPI の `Depends` をファクトリにしておくと、テスト時に `dependency_overrides` でスタブサービスへ差し替えられるのも利点です。実際、CI ではモデルを一切ロードしないスタブ実装（元画像をコピーして返すだけ）に差し替えて、API の入出力契約だけを高速に検証しています。

デバイスまわりも素直にはいきませんでした。CUDA では `float16` が効きますが、Apple Silicon の MPS では `float16` だと精度問題が出やすく、`float32` の方が安定します。ここはデバイスを見て dtype を出し分けています。

```python
dtype = torch.float16 if self._device == "cuda" else torch.float32
```

## エラーは「ユーザーが次に何をすべきか」で分類する

学習アプリとはいえ、失敗時の体験は丁寧に設計しました。変換失敗を一括りにせず、画像起因（`ValueError`）とサーバー起因（`RuntimeError`）に分けて投げ分けています。画像が壊れている・顔が検出できない場合は「別の画像を試してください」と再アップロードへ誘導し、モデルのロードや推論が落ちた場合は「しばらく待って再試行してください」とリトライへ誘導する。原因の所在によって、ユーザーに促すアクションを変えるという方針です。

加えてログポリシーとして「画像バイナリや base64 はログに出さない。記録するのはファイル名・サイズ・モデル名・デバイス名などメタデータのみ」と決めています。ローカル完結という当初の方針を、ログの粒度でも一貫させた形です。

## 学んだこと

一番の収穫は、生成 AI を組み込んだアプリの難所が「モデルそのもの」よりも「その周辺」に集中していると体感できたことです。前処理（検出・マスク生成）、重いリソースのライフサイクル管理、デバイス差の吸収、そして失敗時の導線設計。これらはどんな AI 機能を作るときにも付いて回ります。

また「全体 img2img から顔 inpaint への切り替え」のように、最初の素朴な実装が体験として物足りないと分かってから設計を見直す、という流れそのものが良い学習でした。マスクを楕円で 1.5 倍に拡げる、といった細部のチューニングは、実際に出力を見比べないと出てこない判断です。

次フェーズでは、プレースホルダのままの人物検出を YOLO で本実装し、複数人物の扱いや顔の向き（横顔・後ろ向き）への対応を進める予定です。小さく作って動かし、物足りなさを起点に育てていく。学習用アプリだからこそ取れるこの進め方は、結果的に「現実の AI アプリ開発で効く勘所」を一通りなぞる良い教材になりました。

---

_本記事のコードは筆者が個人の学習目的で実装したものです。アプリは人物写真をローカルで処理し、外部サービスへ画像を送信しません。_

### 参考リンク

- [Diffusers ドキュメント (Inpainting)](https://huggingface.co/docs/diffusers/using-diffusers/inpaint)
- [MediaPipe Face Detection](https://developers.google.com/mediapipe/solutions/vision/face_detector)
- [FastAPI 公式ドキュメント](https://fastapi.tiangolo.com/)
- [uv (Python パッケージマネージャ)](https://docs.astral.sh/uv/)



FastAPI × Diffusers でローカル完結の「顔属性変換」学習アプリをつくる

AIで生演奏のピッチ検出を試してみた


Large Language Model (LLM) は驚くべき汎用性を持っていますが、次の二つのケースでは決まって失敗します。学習時に見ていない情報を尋ねられたとき、そしてその情報が学習期間の締め切り日 (cut-off date) 以降に変化したときです。

ファインチューニング、つまりモデルを自分のデータでさらに学習させて自分のドメインの詳細を吸収させる手法は、この二つの失敗に対する一つの答えです。ただし、コストが高く、反復が遅く、根底のデータが変わった瞬間に古くなります。多くのチームにとって本当に欲しいのは、クエリ時にモデルに新鮮なプライベートコンテキストを与える方法です。それが Retrieval-Augmented Generation (RAG) のしていることです。

この記事では RAG を三つのレイヤーで説明します。まず、概念として、RAG とは何か、どんなときに有効かを整理します。次に、プロトタイプが実際のユーザーの活用に耐えられるかの実践プラクティス。最後に、Amazon Bedrock と Amazon OpenSearch Serverless を使った AWS 上でのハンズオン構築です。

## RAG とは

考え方はシンプルです。ユーザーが質問をしたとき、まず自分が管理するコーパスから関連するドキュメントを少数 **取得 (retrieve)** し、それをコンテキストとしてプロンプトを **拡張 (augment)** し、そのコンテキストに基づいて LLM が **生成 (generate)** します。

これはモデルが学習した結果ではありません。答えがすでにコンテキストとして含まれた、より良いプロンプトを受け取っているだけです。

## RAG パイプラインの構造

すべての RAG システムには二つのパスがあります。

**取り込みパス (Ingestion path)** はオフラインで、コーパスが変わったときに実行されます:

1. ドキュメントを LLM のコンテキストウィンドウに快適に収まる程度の小さなパッセージに **チャンク化 (chunk)** する。
2. 埋め込みモデルを使って各チャンクをベクトルに **埋め込む (embed)**。
3. 近似最近傍探索をサポートするストアにベクトルを **インデックス化 (index)** する。

**クエリパス (Query path)** はユーザーリクエストごとに実行されます:

1. 同じ埋め込みモデルでユーザーの質問を **埋め込む**。
2. ベクトルインデックスから類似度の高い上位 k 件のチャンクを **取得する**。
3. 取得したチャンクをプロンプトのコンテキストとして渡し、回答を **生成する**。

## RAG とファインチューニング

| ユースケース | 適している方 | 理由 |
|---|---|---|
| プライベートまたはドメイン特化文書の Q&A | RAG | クエリ時に事実を取得するので、回答が常に新鮮で出典付きにできる。 |
| 一貫したトーン、スタイル、フォーマット | ファインチューニング | モデルが直接その振る舞いを学習する。 |
| 頻繁に更新されるサポートナレッジベース | RAG | 再インデックス化は再学習よりも簡単。 |
| 専門ドメインの執筆 | 両方使うことが多い | RAG が事実を供給し、ファインチューニングが言い回しや慣習を補う。 |
| 厳格な出力スキーマ | ファインチューニングまたは構造化プロンプティング | 知識の取得よりも振る舞いの制御が重要。 |

RAG とファインチューニングは相互排他的ではなく、多くの本番システムは両方を使います。振る舞いはファインチューニングし、知識は取得しましょう。

![RAG アーキテクチャ概要]({{ sitePrefix }}/assets/img/articles/2026-06-23-RAG-From-Concepts-to-a-Bedrock-and-OpenSearch-Serverless-Build/rag-architecture-overview.jp.png)

## ベストプラクティス

以下の実践は、最も重要なベストプラクティスの一部です。中でも、検索品質が最も効果的な改善ポイントです。

1. **構造を意識したチャンク化と豊富なメタデータでクリーンに取り込む。** チャンク化の前にテキスト抽出を正しく行うこと: PDF はテキストレイヤーを読み込むため、スキャン文書には OCR フォールバックが、スプレッドシートや HTML にはフォーマット固有のパーサーが必要です。境界を意識した分割 (まずページ区切り、次に段落、最後に文) を優先し、構造がないときだけ固定サイズにフォールバックします。500 トークン、50 トークンのオーバーラップは出発点として妥当ですが、ドキュメントタイプごとに調整してください。FAQ やサポートコンテンツには小さなチャンク、密度の高い技術文書や法務文書には大きなチャンクを。各チャンクにメタデータ (ソース URL、セクション、ページ、最終更新日) を常に保持して、フィルタリングや引用を可能にします。

2. **インデックスごとに埋め込みモデルとバージョンを固定する。** 埋め込みモデルは各チャンクを固定サイズの浮動小数点数ベクトルにマッピングします。*次元 (dimension)* はそのベクトルの長さです (Titan v2 は 1024 次元を出力します)。埋め込み空間は互換性がないので、モデルを変えるとコーパス全体を再インデックス化する必要があります。インデックスにモデル名、バージョン、次元をメタデータとしてタグ付けし、クエリ時の埋め込みと食い違わないようにします。モデルの入力上限を尊重してください: 長いチャンクは事前に分割しないと黙って切り詰められます。

3. **ハイブリッド検索、リランキング、調整された kNN インデックスで取得する。** ベクトル検索だけでは弱点があります: 固有名詞、完全一致フレーズ、レアな用語に弱いです。ベクトル類似度と BM25 キーワードスコアを組み合わせて **ハイブリッド検索** を行います。top-k はクエリタイプごとに調整するパラメータで、定数ではありません。**リランカー** (Cohere Rerank のようなクロスエンコーダー、または自分でファインチューニングしたもの) を上位 20〜50 件の候補に適用し、リランク後の上位 3〜5 件を保持します。kNN インデックス自体にも調整すべきパラメータがあります: HNSW の `m` (グラフの接続性、デフォルト 16)、`ef_construction` (構築時の精度、通常 256〜512)、`ef_search` (クエリ時の精度とレイテンシのトレードオフ)。埋め込みモデルのドキュメントで指定された類似度メトリックに従ってください (正規化された埋め込みには `cosinesimil` が一般的ですが、モデルによっては内積や L2 を指定します)。

4. **レスポンスパスに、拒否、引用、検証を設計する。** 検索が関連するものを返さなかった場合に何が起きるか、明示的に決めてください: モデルは適当に作るのではなく、拒否すべきです。コンテキストチャンクに番号を振り、モデルに引用するよう指示します: 「コンテキストのみを使って答えてください。出典は [1]、[2] のように引用してください。」厳格な出力スキーマには、プロンプトのヒューリスティックやファインチューニングよりも、モデルの function-calling や構造化出力 API を優先し、プログラム的な動作を駆動するものには下流のバリデーターと組み合わせてください。取得したテキストはサニタイズしてください: プロンプトインジェクションを運んでくる可能性があるので、制御トークンを除去し、インデックスされたコンテンツと出力の両方から PII をフィルタリングします。

5. **評価、予算管理、運用。** 測れないものは改善できません。ゴールデンセット (50〜200 件の質問と回答のペア) を初日に作成し、二つの指標を別々に計測します: **検索の recall@k** (正しいチャンクが上位 k 件に入っているか) と **生成の忠実度 (faithfulness)** (回答が取得したコンテキストのみに基づいているか)。RAG は従量課金です。10 万チャンクを 100 万トークンあたり $0.10 で埋め込むのが一つのコスト、生成にフロンティアモデルを使うのがもう一つのコストです。各ステージにレイテンシ予算を設定し (embed: <100ms、retrieve: <50ms、generate: <2s)、それぞれを計測します。インデックスがどれくらい新鮮である必要があるかを決めてください。書き込み時の差分アップサートは夜間の完全再インデックス化よりもシンプルですが、より多くの実装が必要です。

## AWS 上での構築

Amazon Bedrock を埋め込みと生成に、Amazon OpenSearch Serverless をベクトル検索に使った AWS 上での最小限のエンドツーエンド RAG サービスを見ていきましょう。

![AWS RAG アーキテクチャ]({{ sitePrefix }}/assets/img/articles/2026-06-23-RAG-From-Concepts-to-a-Bedrock-and-OpenSearch-Serverless-Build/aws-rag-architecture.jp.png)

**コンポーネント:**

- **S3**: 元ドキュメントが配置される場所。
- **取り込み Lambda**: S3 PutObject でトリガーされ、チャンク化し、Bedrock 経由で埋め込み、OpenSearch にインデックス化します。
- **OpenSearch Serverless**: `VECTORSEARCH` タイプのベクトルコレクション。
- **API Gateway + クエリ Lambda**: 公開クエリエンドポイント。質問を埋め込み、kNN を実行し、拡張プロンプトで Bedrock を呼び出します。
- **Bedrock**: 埋め込みには `amazon.titan-embed-text-v2:0`、生成には `anthropic.claude-3-5-sonnet`。

### OpenSearch Serverless (Terraform)

```hcl
resource "aws_opensearchserverless_security_policy" "encryption" {
  name = "${var.app.prefix}-rag-enc"
  type = "encryption"
  policy = jsonencode({
    Rules = [{
      Resource     = ["collection/${var.app.prefix}-rag"]
      ResourceType = "collection"
    }]
    AWSOwnedKey = true
  })
}

resource "aws_opensearchserverless_collection" "rag" {
  name = "${var.app.prefix}-rag"
  type = "VECTORSEARCH"

  depends_on = [aws_opensearchserverless_security_policy.encryption]
}
```

ネットワークおよびデータアクセスポリシーも同じパターンに従います。コレクションは、Lambda が SigV4 で認証する HTTPS エンドポイントを公開します。

### 取り込み Lambda (Go)

```go
func handler(ctx context.Context, evt events.S3Event) error {
    for _, rec := range evt.Records {
        body, err := s3Get(ctx, rec.S3.Bucket.Name, rec.S3.Object.Key)
        if err != nil {
            return fmt.Errorf("s3 get: %w", err)
        }

        chunks := chunkText(string(body), 500, 50)

        vecs, err := embedAll(ctx, chunks, 8)
        if err != nil {
            return fmt.Errorf("embed: %w", err)
        }

        if err := aossBulkIndex(ctx, rec.S3.Object.Key, chunks, vecs); err != nil {
            return fmt.Errorf("index: %w", err)
        }
    }
    return nil
}
```

`embedAll` は `bedrock:InvokeModel` の呼び出しを境界のあるワーカープールで並列実行し、チャンク順にベクトルを返します。`aossBulkIndex` は全チャンクとベクトルのペアを含む 1 回の SigV4 署名済み `POST /_bulk` を発行します。インデックスされる各ドキュメントは `{"text": chunk, "embedding": vec, "source": key}` の形をしています。

### クエリ Lambda (Go)

```go
func handler(ctx context.Context, req events.APIGatewayProxyRequest) (*events.APIGatewayProxyResponse, error) {
    var body struct {
        Question string `json:"question"`
    }
    if err := json.Unmarshal([]byte(req.Body), &body); err != nil {
        return utils.BadRequest("invalid json"), nil
    }

    qvec, err := bedrockEmbed(ctx, body.Question)
    if err != nil {
        return nil, fmt.Errorf("embed query: %w", err)
    }

    chunks, err := aossKNN(ctx, qvec, 5)
    if err != nil {
        return nil, fmt.Errorf("retrieve: %w", err)
    }

    prompt := buildPrompt(body.Question, chunks)
    answer, err := bedrockGenerate(ctx, prompt)
    if err != nil {
        return nil, fmt.Errorf("generate: %w", err)
    }

    return utils.SuccessResponse(200, map[string]any{
        "answer":  answer,
        "sources": chunkSources(chunks),
    }), nil
}
```

`buildPrompt` は取得したチャンクに番号を振り、Claude に引用するよう指示します。`aossKNN` は `embedding` フィールドに対して OpenSearch の `knn` クエリを実行します。

### 推奨される次のステップ

- **リランキングを追加する。** `aossKNN` と `buildPrompt` の間にクロスエンコーダーの呼び出しを差し込みます。
- **ハイブリッド検索を追加する。** OpenSearch はネイティブにサポートしています: `knn` クエリと `match` 句を組み合わせ、重みを調整します。
- **評価を追加する。** 正解がわかっているテスト質問のセットを少数保持し、変更のたびに再実行することで、検索と回答が良くなっているか悪くなっているかを判断できます。

## まとめ

RAG は応用 LLM の中でも最もレバレッジの効くパターンの一つです。始めるのは簡単ですが、スケールでうまく機能させるのは難しい。コンセプトはシンプルで、ベストプラクティスが本番で生きるところで、上記の AWS 構築はゴールではなくスタートラインです。

これを土台にして構築するなら、それぞれ独立した記事に値する二つのフォローアップは **評価 (evaluation)** (検索が実際によくなっているか知る方法) と **リランキング (reranking)** (ハイブリッド検索の次に最大の精度レバー) です。この二つの領域が、RAG システムがデモのままで終わるか、本番で信頼できるものになるかの大部分を決定します。

## 参考文献

- [Amazon Bedrock: User Guide](https://docs.aws.amazon.com/bedrock/latest/userguide/)
- [Amazon OpenSearch Serverless: Vector Search](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/serverless-vector-search.html)
- [Anyscale: Building RAG-based LLM Applications for Production](https://www.anyscale.com/blog/a-comprehensive-guide-for-building-rag-based-llm-applications-part-1)


RAG: コンセプトから Bedrock + OpenSearch Serverless での構築まで


モンスターラボのエンジニアリングマネージャーの奥田です。

AIによりコードが大量に生成されるようになった今、ソフトウェアの品質担保はこれまで以上に重要なテーマとなりました。品質担保のためにテストコードを書くというのは多くの開発現場で行われていますし、テストコードも生成AIが書けるようになったことでテストカバレッジは大幅に向上していると思います。

一方で、大量に生成されたプロダクトコード、テストコードをチェックするのは大変な作業ですし、AIなどのツールを利用するにしてもガードレールとチェックポイントを適切に設定する必要があります。

本記事では、**ゴールデンテスト（Golden Test）** というテスト手法を紹介し、AI時代のソフトウェア開発における実践的な適用方法と、AI駆動開発との相性の良さについて解説します。

---

# ゴールデンテストとは

ゴールデンテストは、**テストコードの出力を「ゴールデンファイル」と呼ばれる期待値ファイルと比較する**テスト手法です。VRT(Visual Regression Test)と呼ばれる視覚的な正しさを担保する回帰テストなどで使われることが多いと思います。
通常のユニットテストでは期待値をコード内にアサーションとして記述しますが、ゴールデンテストでは期待値を外部ファイルとして管理し、テスト実行時に実際の出力とファイルの中身を比較します。

## 基本的な流れ

1. テスト対象の関数/APIを実行し、出力を取得する
2. ゴールデンファイル（期待値ファイル）が存在しない場合 → 出力をそのまま保存する
3. ゴールデンファイルが存在する場合 → 出力とファイルの内容を比較する
4. 差分がある場合 → テスト失敗として差分を報告する
5. 意図した変更の場合 → ゴールデンファイルを更新してコミットする

## 通常のユニットテストとの違い

| 観点 | ユニットテスト | ゴールデンテスト |
|------|--------------|----------------|
| 期待値の管理場所 | テストコード内 | 外部ファイル |
| 期待値の作成 | 手動で記述 | 初回実行時に自動生成可能 |
| 大きな出力への対応 | アサーションが膨大になる | ファイル比較で簡潔に対応 |
| 変更検知 | 明示的にチェックした箇所のみ | 出力全体の変更を検知 |
| 期待値の更新 | テストコードを手動で修正 | ファイルを更新してコミット |

# ゴールデンテストの何がいいのか

## テストコードをシンプルに保ちやすい

関数やAPIの入力を定義し、出力はゴールデンファイルと比較するだけなのでテストコードをシンプルに保ちやすいです。

## リファクタリング時のテスト更新コストが低い

コードをリファクタリングした結果、出力のフォーマットが微妙に変わることがあります。個別のアサーションを大量に持つテストではどこが変わったのかを把握し、失敗するアサーションに適切に対処する必要があります。そもそも、適切なアサーションがなければ出力の微妙な変化に気づけません。ゴールデンテストであれば、ゴールデンファイルの差分により確実に差分を検出できますし、ゴールデンテストの差分に問題がなければコミットするだけでテストを更新できます。

## 人がレビューしやすい

GitHub上のプルリクエストなどでコード差分をレビューする際、ゴールデンファイルを見るだけで差分があるのかないのか、あるとしたらどこなのかをすぐに確認することができます。ゴールデンファイルが画像であってもテキストであっても、レビューしやすく便利です。

```diff
# git diff で出力の変更が一目瞭然
- {"status": "ok", "data": {"userId": 1, "name": "Taro"}}
+ {"status": "ok", "data": {"userId": 1, "name": "Taro", "email": "taro@example.com"}}
```

「何が変わったか」をアサーションの修正履歴ではなく、**出力の差分として直接把握**できるため、レビューの効率が劇的に向上します。


## AIが意味のないテストケースを生成しにくい

AI が生成するテストコードは、テストを通すための無意味なアサーションや不適切なモックを使いがちです。大量の無意味なテストケースにより本質的に確認すべきポイントが見失われ、テストコード自体のメンテナンスコストが上昇し、テストを書く効率が落ちる一方で品質が向上しないという本末転倒な事態にも陥りかねません。
ゴールデンテストの場合、ゴールデンファイルが出力の期待値であるため、AIが期待値を「捏造」するリスクがありません。

## ゴールデンファイルは仕様書にもなる

入力と出力を適切に出力すれば、ゴールデンファイルは仕様書にもなりえます。

私が過去に担当したプロジェクトでは、OpenAPIなどでAPI仕様書を記述せず、ゴールデンファイルにリクエスト、レスポンスを出力することでAPI仕様書として管理していました。

また別のプロジェクトでは、生成AIに投げるシステムプロンプトをユーザ状態に応じて合成して生成していたので、そのシステムプロンプトのテストをゴールデンテストで記述しました。ユーザ状態ごとに生成されたシステムプロンプトをゴールデンファイルで確認できるので便利でした。

実装から出力されるのでコードとの乖離もなく、プロジェクト次第では仕様書として十分機能すると思います。

# ゴールデンテストが向いているテスト

## API レスポンスの回帰テスト

REST API や GraphQL のリクエスト/レスポンスは、構造が複雑でフィールド数も多くなりがちです。個々のフィールドに対してアサーションを書くよりも、レスポンス全体をゴールデンファイルとして管理する方が効率的です。またゴールデンファイルにリクエスト、レスポンスを出力することでAPIの仕様書として扱うこともできます。

## データ変換処理の検証

CSV → JSON、XML → オブジェクトなど、入出力の変換処理は出力が大きく予測しづらいケースがあります。ゴールデンテストなら、変更差分を簡単にチェックできます。

## 設定ファイル・テンプレートの生成

Infrastructure as Code のテンプレート（CloudFormation、Terraform）や設定ファイルの生成結果を検証する際にも有効です。

# 適用に注意が必要なケース

- 非決定的な出力（タイムスタンプ、UUID、ランダム値）を含む場合は、マスキングや正規化が必要です
- 環境依存の出力（ホスト名、パスなど）がある場合は、テスト環境を固定するか出力をサニタイズする
- そもそもゴールデンファイルとの差分を検知するため回帰テスト向きです。新たにテストケースを作成した場合はゴールデンファイルに問題がないかしっかり確認する必要があります

# 導入方法

ここでは、TypeScript（Jest）を使ったバックエンドAPIのゴールデンテスト導入例を示します。

### Step 1: ゴールデンテストユーティリティの作成

```typescript
// src/test-utils/golden.ts
import * as fs from "fs";
import * as path from "path";

const GOLDEN_DIR = path.resolve(__dirname, "../../__golden__");
const UPDATE_GOLDEN = process.env.UPDATE_GOLDEN === "true";

/**
 * 実際の出力をゴールデンファイルと比較する。
 * ゴールデンファイルが存在しない場合、または UPDATE_GOLDEN=true の場合はファイルを更新する。
 */
export function expectMatchesGoldenFile(
  testName: string,
  actual: unknown
): void {
  const sanitized = sanitizeOutput(actual);
  const content = JSON.stringify(sanitized, null, 2) + "\n";
  const filePath = path.join(GOLDEN_DIR, `${testName}.json`);

  if (!fs.existsSync(GOLDEN_DIR)) {
    fs.mkdirSync(GOLDEN_DIR, { recursive: true });
  }

  if (UPDATE_GOLDEN || !fs.existsSync(filePath)) {
    fs.writeFileSync(filePath, content, "utf-8");
    if (!fs.existsSync(filePath)) {
      console.log(`Golden file created: ${filePath}`);
    }
    return;
  }

  const expected = fs.readFileSync(filePath, "utf-8");
  expect(content).toBe(expected);
}

/**
 * 非決定的な値（タイムスタンプ、UUIDなど）をマスキングする
 */
function sanitizeOutput(obj: unknown): unknown {
  if (obj === null || obj === undefined) return obj;
  if (typeof obj === "string") {
    return obj
      .replace(
        /\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}.\d{3}Z/g,
        "<<TIMESTAMP>>"
      )
      .replace(
        /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/gi,
        "<<UUID>>"
      );
  }
  if (Array.isArray(obj)) return obj.map(sanitizeOutput);
  if (typeof obj === "object") {
    const result: Record<string, unknown> = {};
    for (const [key, value] of Object.entries(obj as Record<string, unknown>)) {
      result[key] = sanitizeOutput(value);
    }
    return result;
  }
  return obj;
}
```

### Step 2: API ハンドラーのゴールデンテストを書く

```typescript
// src/handlers/__tests__/getUser.golden.test.ts
import { expectMatchesGoldenFile } from "../../test-utils/golden";
import { handler } from "../getUser";

describe("GET /users/:id - Golden Tests", () => {
  it("正常系: ユーザー取得", async () => {
    const event = {
      pathParameters: { id: "user-001" },
      headers: { authorization: "Bearer test-token" },
    };

    const response = await handler(event);

    expectMatchesGoldenFile("getUser/success", {
      statusCode: response.statusCode,
      body: JSON.parse(response.body),
    });
  });

  it("異常系: 存在しないユーザー", async () => {
    const event = {
      pathParameters: { id: "non-existent" },
      headers: { authorization: "Bearer test-token" },
    };

    const response = await handler(event);

    expectMatchesGoldenFile("getUser/not-found", {
      statusCode: response.statusCode,
      body: JSON.parse(response.body),
    });
  });
});
```

### Step 3: npm scripts の設定

```json
{
  "scripts": {
    "test": "jest",
    "test:update-golden": "UPDATE_GOLDEN=true jest"
  }
}
```

### Step 4: ゴールデンファイルの運用

```bash
# 初回実行: ゴールデンファイルが自動生成される
npm run test:update-golden

# 生成されたファイルを確認
cat __golden__/getUser/success.json

# 内容に問題がなければコミット
git add __golden__/
git commit -m "Add golden files for getUser API"

# 以降は通常のテストとして実行
npm test

# コード変更後にゴールデンファイルを更新する場合
npm run test:update-golden
git diff __golden__/  # 差分を確認
git add __golden__/ && git commit -m "Update golden files"
```

### 生成されるゴールデンファイルの例

```json
// __golden__/getUser/success.json
{
  "statusCode": 200,
  "body": {
    "id": "user-001",
    "name": "山田太郎",
    "email": "taro@example.com",
    "createdAt": "<<TIMESTAMP>>",
    "updatedAt": "<<TIMESTAMP>>"
  }
}
```

```json
// __golden__/getUser/not-found.json
{
  "statusCode": 404,
  "body": {
    "error": {
      "code": "USER_NOT_FOUND",
      "message": "指定されたユーザーが見つかりません"
    }
  }
}
```

## まとめ

ゴールデンテストはシンプルですが、AI駆動開発が主流となった現代でも活用できるテスト手法だと思います。

AIがコードを書く時代だからこそ、「何が変わったか」を確実に可視化できる仕組みが重要です。ゴールデンテストは、その仕組みを最小限のコストで実現する、実践的な選択肢と言えるでしょう。


ゴールデンテスト - AI駆動開発における実践的なテストコードを考える


本記事では、github/spec-kit（以下、Spec Kit）をオフショア × AI駆動開発のプロジェクトに導入するにあたって、標準のSpec Kitに対してどんな設計判断を重ねてきたかを書き残します。**本格運用はこれから始まります**。だからこそ、判断のプロセスと、設計時点で見えている懸念を、後から検証可能な形で残しておきたいと考えました。

## オフショア × AI駆動開発で感じている摩擦

ある一覧APIの仕様書には、「並び順に従って表示する」とだけ書いてあります。実装したエンジニアは、既存の同様のAPIに合わせて、並び順の値が `null` のものをリストの末尾に並べて返しました。ビジネスアナリストが画面を確認すると、「`null` のものは出さない想定だった」と言います ── 運用上は表示する必要がありません。仕様書を見直すと、`null` の扱いについては書かれていません。**書かれていないことを、それぞれが「自然な解釈」で埋めていたのです**。エンジニアは既存実装との整合で、ビジネスアナリストは運用目線で。

書かれていないことの判断は、AIに任せても人間に任せても、結局どこかで分岐します。仕様の解像度がチーム共通の前提として揃っていない以上、AI駆動開発で増えた速度はそのまま摩擦に転化してしまいます。

オフショア協業の現場で、この摩擦は珍しいものではありません。私たちのチームは日本とベトナムの両方にビジネスアナリスト（以下BA。要件を理解し仕様策定を担当する）がいて、両者とも日本語の仕様書を読み書きできる体制です。それでも「書かれていないことは判断が分岐する」という一点だけは、仕組みでしか解けません。

私が担当しているプロジェクトでもAI駆動開発を取り入れることになりました。弊社では技術選定はプロジェクト単位で行っており、本プロジェクトの特性に合わせて、こうした摩擦への仕掛けとして選びつつあるのが Spec Kit です。仕様書を原本としてgit管理し、コードを書かせる前にAIと一緒に spec の曖昧さを潰しに行く ── そのアプローチが、私たちのチームにどう機能するかを試すフェーズにあります。

Spec Kitは、仕様 → 技術設計 → タスク → 実装の各段階を、`/speckit.specify`、`/speckit.plan`、`/speckit.tasks`、`/speckit.implement` といったコマンドで進めるフレームワークです。各段階の成果物（`spec.md`、`plan.md`、`tasks.md`、実装コード）はMarkdownとしてリポジトリに残るため、コードと同じレビュー基盤に乗せられます。

## ロール設計：BAとエンジニアの分業をAIの文脈で組み直す

Spec Kitを紹介する記事の多くは、個人開発者が spec → plan → tasks → implement を一人で回す前提で書かれています。私たちのフローは違います。**BAが `/speckit.specify` と `/speckit.clarify` を回し、エンジニアが `/speckit.plan` 以降を担う** ── 仕様策定と実装をフェーズで分業する形です。

元々この分業は、オフショア体制では既にありました。日本とベトナム両方にいるBAが仕様書を書き、エンジニアが実装する。Spec Kitが提供する段階分割（spec / plan / tasks / implement）は、この既存の境界線にほぼ重なります。私たちのSpec Kit導入は「新しい分業を作る」のではなく、**既にある分業を、AIが介在する文脈で組み直す**作業でした。

具体的には、BAは `/speckit.specify` で仕様の原本（`spec.md`）を作成します。このコマンドはカスタマイズしてあり、AIが作成過程で検出した曖昧さをBAに一問一答で確認する設計にしてあります ── 標準のSpec KitだとAIが「推奨値」で勝手に決めてしまうところを、**判断はBAに残す**方に倒しました。

書き上がった `spec.md` にまだ曖昧さが残っている場合は、`/speckit.clarify` で体系的なスキャンをかけます。完成済みの仕様書を業務スコープ・エッジケース・用語の一貫性などの観点から見直し、`/speckit.specify` で取りこぼした曖昧さを補完するコマンドです。冒頭の `null` の事例で言えば、これは「エッジケース」の観点で `/speckit.clarify` が拾い上げる類のものです。

Backendエンジニアは `spec.md` を起点に `/speckit.plan` で技術設計（`plan.md` と `openapi.yaml`）を起こし、`/speckit.tasks` でタスクに分解、`/speckit.analyze` で整合性を確認した上で `/speckit.implement` を回します。FrontendエンジニアはSpec Kitのコマンドを使いません ── 完成した `spec.md` と `openapi.yaml` を参照して実装する立場です。レビューを経た `openapi.yaml` が信頼できる原本として手元に届くため、FEは仕様の解釈ブレなく実装に入れる、というのがFE側の恩恵です。

もう一つの設計判断として、**BAがGitHubでドラフトPRを開く**運用を選びました。仕様書をコードと同じリポジトリでgit管理し、コードと同じプロセス（PR・レビュー・Approveラベル）で承認します。BAにとっては仕様書を書く媒体がドキュメントツールからMarkdownとgitに変わります。これを選んだのは、これがなければ「仕様書をgit管理する」という根幹思想が運用レベルで成立しないからです。具体的なゲート運用は後の章で扱います。

## ツール選定：Spec Kit + Copilot の理由

ツール選定では2つの判断を重ねました。spec駆動の枠組みとしてSpec Kitを、AIアシスタントとしてGitHub Copilotを。それぞれに別の選択肢があり、**個人的な好みより組織的な事情を優先した判断**が含まれています。

Spec Kitを採用した理由は、生成物がすべてMarkdownでgit管理可能で、コードと同じレビュー基盤に乗ることです。spec / plan / tasks / implement の段階分けが前章で書いた分業境界と素直に重なるのも、選定の決め手になりました。**特定のAIツールに依存しない構造**であるのも重要なポイントで、Copilotで運用しても、Claude Codeに切り替えても、Spec Kitの仕組みはそのまま乗せ換えられます。

Copilotを選んだのは、**ベトナム側のメンバーが現時点でCopilotを使っている**、という事情が大きな理由です。個人的にはClaude Codeを日々使っていますが、チーム標準としてはベトナム側に合わせました。

## カスタマイズ方針：標準のSpec Kitから何を変えたか

標準のSpec Kitに対して、本プロジェクトに合わせた変更を加えました。各フェーズのプロンプト、shellスクリプト、運用ガイドまで、ひと通り手を入れています。本記事では、このうちプロンプト側のカスタマイズを中心に扱います。設計思想として一貫しているのは次の2点です。

### 原則① 仕様と実装の整合性をコマンド側に埋め込む

`/speckit.plan` には、標準のSpec Kitにはない **Spec-Code Consistency Check** という GATE を差し込みました。`spec.md` の内容を既存コードベースと6つの次元で照合し、矛盾が見つかれば **その時点で plan の作成を止め、BAに差し戻す** 仕組みです。

| 次元 | 何をチェックするか |
|------|------------------|
| データモデル | spec内のデータ項目が既存テーブルにあるか |
| API重複 | 同目的の既存エンドポイントがないか |
| ビジネスルール | spec前提が既存ロジックと矛盾しないか |
| 認証・権限 | 認証想定が既存方式と合うか |
| 命名規則 | spec用語が既存コード命名と揃うか |
| APIパターン | spec内に実装詳細が漏れていないか |

注目したいのは最後の「APIパターン」次元です。これだけは spec → コード の方向ではなく、**plan時にspecを逆検査します**。本来、specにはWhatだけを書き、Howはplanで決めるのが原則ですが、実際には既存システムを参考にしながら要件を整理するうちに、`spec.md` に実装詳細が混入することがあります。「データはPostgreSQLのJSONB型で保存する」のような書き方が混じっていたら、それを検出して「planで決めるべき内容」として差し戻す ── 仕様にHowが漏れ込むのを、planの段階で構造的に弾く仕組みになっています。

### 原則② AIに過剰な権限を渡さない

AIは「親切に動こうとして、頼まれていないところまで触る」傾向があります。これを構造的に封じる仕掛けを、各エージェントに散らしました。

- `/speckit.plan` のAIは、`specs/{ticket-id}/` ディレクトリの外に書き込めません。`.github/` や `src/`、`docs/` への変更は明示的に禁止しています
- `/speckit.clarify` のAIは、BAに対して**技術的なHowを質問できません**。「どのDBを使うか」「APIをどう設計するか」は禁止リストに入っており、許可されているのは業務ルール、ユーザー操作、アクセス制御などWhatに属する事項のみです
- `/speckit.implement` のAIは、生成した実装コードに `FR-001` や `T001` のようなSpec Kit由来のIDを残してはいけません。コードはSpec Kitの文脈を知らない第三者が読んでも自然であるべき、という設計です

これらは「AIの暴走を事後に止める」というより、**AIの役割と動ける範囲を、最初から明示しておく**という方向の設計です。

---

この2つの原則はそれぞれ、AIに「何を検証させるか」「何をさせないか」に対応しています。標準のSpec Kitは便利な土台ですが、本プロジェクトの運用に収めるには、この2軸は明示的に手を入れる必要がありました。

なお、これらのカスタマイズ作業そのものも、AIに依頼して進めました。各エージェントの定義ファイル（Markdown）を書き換える作業は、プロジェクト固有の事情を渡せばAIが大筋を組み立ててくれます。**Spec Kitをプロジェクトに合わせて調整するハードルは、思ったより高くありませんでした**。

## 想定している運用フローと、現時点で見えている懸念

設計はここまでです。実際の運用フローは、**BAが開いた一つのドラフトPRが3段階のゲートを通って閉じる**形を想定しています。

![BAが開いた一つのドラフトPRが、spec → plan → 実装の3段階のゲートを通って閉じる流れ]({{ sitePrefix }}/assets/img/articles/2026-05-14-speckit-customization-design/flow-gates.webp)

ゲート1は仕様承認です。BAが `/speckit.specify` で生成した `spec.md` をドラフトPRとして開き、他BAやTL（テックリード、技術判断を担う役割）のレビューを経て `spec approved` ラベルが付くまでです。**あるスプリント内でこのラベルが付かなかった仕様は、次のスプリントの実装対象にしません** ── 設計上の制約として明文化しています。ゲート2は技術設計承認 ── 同じPRにエンジニアが `plan.md` と `openapi.yaml` を追加コミットし、TLレビューを通します。ゲート3は実装承認 ── 実装コードを載せたPRがマージされます。

一つのドラフトPRが spec → plan → 実装と通り抜けることで、git履歴には「仕様 → 設計 → 実装」が時系列で残ります。**「実装後に仕様書を更新し忘れる」という問題は、すべてを同じPRに含めるルールにすることで根本から消しています**。

ただし**本格運用はこれから始まります**。この段階で「うまくいくはず」と書くのは設計編としても誠実ではありません。現時点で見えている懸念を、仮説として4つだけ挙げておきます。

- BAがAI対話とドラフトPR運用に慣れるまでの学習コスト
- 既存コードがレガシー寄りだと、Spec-Code Consistency Check がノイズだらけになるリスク
- 実装PRに spec 修正を含めるルールが、レビュー負荷を上げる可能性
- あるスプリント内で spec approved が付かない場合、次のスプリントの実装が空白になる進捗リスク

最後にもう一つ、設計編としての誠実さとして書き残しておきます。**仕組みだけでは運用の漏れを防ぎきれない、という観測は既に出ています**。BA向けプロンプトには「DBカラム名等の技術用語を `spec.md` に混入させない」という明示の禁則を入れていますが、実際に書かれた仕様の一部にはその漏れが起きています。これは「ガードレールを強化する」だけでは解けない、レビュー文化との両輪が要る話だと考えています。

## 結び：導入後の振り返りについて

導入後の振り返り ── BAが実際にspecを書いてみての感触、エンジニア側で起きた引き継ぎの齟齬、Copilotが想定通り効いた／効かなかったケース、カスタマイズの調整履歴 ── は、運用しながら試行錯誤を重ねて磨いていくものです。その過程を、機会があればまた書き残してみたいと思います。

## 参考リンク

- [GitHub Spec Kit](https://github.com/github/spec-kit) ── 本記事で扱った spec 駆動開発フレームワーク
- [GitHub Copilot](https://github.com/features/copilot) ── AIコーディングアシスタント

---

_本記事内の画像は ChatGPT で生成したものを使用しています。_


「ビジネスアナリストが仕様を書き、エンジニアが実装する」をAI時代に再設計する ── Spec Kitをオフショア開発にカスタマイズした話（設計編）

CSS のコンテナクエリを `@property` と組み合わせたときに予想外の挙動に出会い、原因を追ううちに「CSS のプロパティ値処理」の仕様にたどり着きました。本記事では、その仕様を踏まえて `@property` 有無で挙動が変わる理由を解説し、学んだ知識で他の CSS 挙動（`line-height` や `width` の `%` 解釈）も読み解いていきます。

---

## 前提: @property・コンテナクエリ・cqi

まず状況を説明する上で前提となる、`@property`・コンテナクエリ・`cqi` の 3 つについて簡単に紹介します。

### @property

カスタムプロパティ（CSS 変数）に**型や初期値を宣言**できる仕組みです。`syntax: "<length>"` のように型を指定することで、CSS エンジンはその変数を単なる文字列ではなく型付きの値として扱うようになります。

### コンテナクエリ

メディアクエリのようなビューポートではなく**親要素のサイズ**を基準にスタイルを切り替えられる仕組みです。`container-type: inline-size` を指定した要素がコンテナになります。

### cqi

コンテナクエリに対応する単位です。`width: 100cqi` と書くと「最も近い祖先コンテナの幅（正確にはインラインサイズ）の 100%」になります。

詳しい使い方などは MDN（[@property](https://developer.mozilla.org/ja/docs/Web/CSS/@property) / [コンテナクエリ](https://developer.mozilla.org/ja/docs/Web/CSS/CSS_containment/Container_queries)）を参照してください。

---

## 理解できない挙動との出会い

### やりたかったこと

`cqi` は常に最寄りのコンテナを基準にするので、コンテナが入れ子になっていると参照先が内側に切り替わってしまいます。「**特定の祖先コンテナを基準に指定する方法**はないのか」と興味本位で調べていました。

```html
<div class="container-a">
  
  <div class="container-b">
    
    <div style="width: 100cqi">
      
    </div>
  </div>
</div>
```

外側コンテナ A の 100%（1000px）が欲しいのに、内側コンテナ B の 100%（400px）として処理されてしまいます。

コンテナには名前をつけられるので `name/100cqi` のように「コンテナ名 + 単位」で指定するような構文があるんじゃないかなと思って調べてみましたが、そのような構文はありませんでした。

### カスタムプロパティを試してみた

「ならカスタムプロパティに入れて、A の配下で `--a-width: 100cqi` と書いておけば固定できるのでは？」と思ったのですが、これもうまくいきませんでした。

```html
<div class="container-a">
  
  <div style="--a-width: 100cqi">
    
    <div class="container-b">
      
      <div style="width: var(--a-width)">
        
      </div>
    </div>
  </div>
</div>
```

子孫で `var(--a-width)` を使っても、結局その場の最も近いコンテナ B を基準に解釈されてしまいます。

### @property を付けると実現できた

AI に相談したところ「`@property` で型を宣言すれば解決する」と返ってきました。

```css
@property --a-width {
  syntax: "<length>";
  inherits: true;
  initial-value: 0px;
}
```

```html
<div class="container-a">
  
  <div style="--a-width: 100cqi">
    <div class="container-b">
      
      <div style="width: var(--a-width)">
        
      </div>
    </div>
  </div>
</div>
```

半信半疑で `@property` を追記したところ、子孫要素で `--a-width` を参照するとコンテナ A を基準にした値（1000px）が取得できました。

ただ型を宣言しただけで、同じ `100cqi` の解釈先がコンテナ B からコンテナ A に切り替わるのが直感的に納得できず、仕様を追いかけることにしました。

---

## 仕様を読んで原因を探る

まず `@property` の[仕様](https://www.w3.org/TR/css-properties-values-api-1/#substitution)を読んでみることにしました。

すると、原因と関係がありそうな一節が見つかりました。「`@property` で宣言されたカスタムプロパティは、**書いたままの記述**ではなく**計算値**として置換される」というものです。

「**計算値**」という言葉が引っかかったので深掘りしてみると、CSS のプロパティ値処理を定めた[仕様](https://www.w3.org/TR/css-cascade-5/#value-stages)にたどり着きました。そこには、プロパティ値は**複数段階の計算**を経て最終値になる、と定められていました。

なんとなく値が内部で変換されていることはわかっていましたが、**複数段階に分かれている**とは思っていなかったので、ここで自分の認識を改めました。

処理の流れを簡単な図にすると、次のようになります（例として `width: 2em`、その要素の `font-size` が 16px の場合）。

```text
宣言値         : "2em"    ← CSS に書いた形
  │ カスケード（適用する宣言を決める）
  ▼
カスケード値    : "2em"
  │ 継承・初期値で埋める
  ▼
指定値         : "2em"    ← 相対単位のまま
  │ 相対単位を絶対値化・キーワードを置換
  ▼
計算値（算出値） : "32px"   ← 自要素の font-size (16px) 基準で絶対値に解決
  │ レイアウト結果が必要な値を解決（width の % など）
  ▼
使用値         : "32px"
  │ 描画時の制約を反映
  ▼
実効値         : "32px"
```

そして、**`@property` の有無で挙動が変わる理由**の決め手になったのが、この図中にある「**計算値（Computed Values）**」の項の記述でした。そこには「**継承で親から子へ渡されるのはこの値である**」と明記されています。つまり、計算値の段階で確定した値が子に渡るわけです。

ここまでで分かった 3 つのルールが揃ったところで、先ほどの `@property` と `cqi` の挙動を理解できそうに思えました。

- `@property` で型宣言したカスタムプロパティは、計算値として解決される
- プロパティ値は段階を踏んで処理される
- 継承されるのは計算値

---

## ルールを踏まえて今回の挙動を考えてみる

先ほど整理した 3 つのルールを使って、最初に挙げたカスタムプロパティのケースを見直していきます。

### @property を使わない場合

まずは `@property` なしのパターンから。

型宣言がないカスタムプロパティは、CSS エンジンから見ると**ほぼただの文字列**として扱われます（[仕様](https://www.w3.org/TR/css-variables-1/#defining-variables)上は「未解決のトークン列」）。

```css
/* container-a の配下に置いた中間要素で宣言 */
.a-scope {
  --a-width: 100cqi;
}
/* CSSエンジンの理解: --a-width には "100cqi" という文字列が入っている */
```

型が分からない以上、**計算値フェーズで解決しようがない**ので、文字列のまま子孫に継承されることになります。

そうすると、`var(--a-width)` を受け取った側で初めて型が決まる。そこで `cqi` が解決されるとき、基準になるのは当然「**そのときの最寄りのコンテナ**」なので、コンテナ B の 400px になってしまうわけです。

### @property を使った場合

次に `@property` ありのパターン。

`syntax: "<length>"` と宣言することで、CSS エンジンが `--a-width` を length 型の値として扱うようになります。こうなると通常の `width` や `padding` と同じで、**計算値フェーズで解決される**対象になります。

つまり `--a-width: 100cqi` と書いた場所でそのまま **`1000px` に確定**する。あとはこの計算値が子孫に渡るだけなので、途中にコンテナ B が挟まろうと影響を受けない、というのが型宣言で挙動が変わる理由なんですね。

```css
/* container-a の配下に置いた中間要素で宣言 */
.a-scope {
  --a-width: 100cqi;
  /* @property ありの場合、ここで 1000px に確定する */
}
.child {
  width: var(--a-width);
  /* 受け取るのは 1000px。コンテナ B の影響を受けない */
}
```

### 答え合わせ

`@property` の有無で挙動がどう変わるかを並べると次の通りです。

- なし: 計算値フェーズがスキップ → **文字列のまま**子孫に渡る
- あり: 計算値フェーズで `100cqi` → `1000px` に解決 → **計算値**が子孫に渡る

「型を宣言する」という行為が、値がいつ・どこで確定するかまで変えている、というのが面白いポイントでした。`@property` は単に型を書く機能というより、カスタムプロパティを通常のプロパティと同じ処理パイプラインに乗せるためのスイッチなんですね。

---

## 応用: 学んだ仕様で他の CSS 挙動を読み解く

`@property` と `cqi` の話はここまでですが、今回学んだ段階処理と計算値の継承は他の CSS 挙動にも当てはまります。自分が「そういうものだ」で済ませていた挙動を言語化できるようになった例を 2 つ紹介します。

### line-height: 150% と 1.5 の違い

`line-height` の「パーセント（`150%`）」と「単位なしの数値（`1.5`）」どちらも同じ「1.5 倍」なのに、子孫での挙動が変わります。

```css
.case-a {
  font-size: 16px;
  line-height: 150%;
}
.case-b {
  font-size: 16px;
  line-height: 1.5;
}
.child {
  font-size: 32px;
}
```

```html
<div class="case-a">
  親 (16px)
  <span class="child">子 (32px)</span>
</div>
<div class="case-b">
  親 (16px)
  <span class="child">子 (32px)</span>
</div>
```

- **ケース A（`150%`）**: 子の line-height も `24px`（親で確定した値がそのまま引き継がれる）
- **ケース B（`1.5`）**: 子の line-height は `48px`（`32px × 1.5`）

これは、`line-height` の[仕様](https://www.w3.org/TR/css-inline-3/#line-height-property)で**単位なしの数値**について、**計算値は指定値と同じ**、**使用値は要素のフォントサイズとの掛け算で決まる**と定義されているためです。`1.5` は数値のまま計算値として子孫に届き、受け取った要素ごとに font-size と掛け算されて使用値になります。一方、`150%` や `1.5em` は親の時点で絶対値まで解決された値が計算値になるので、子の line-height は親で解決された値のまま固定され、子の font-size を変えても変わりません。

### width: % は使用値フェーズまで解決されない

ここまで「相対単位は計算値フェーズで絶対値に解決される」という話をしてきましたが、すべての相対単位がそうではありません。同じ `%` でも**プロパティによって解決されるフェーズが違います**。

先ほどの `line-height: 150%` は計算値フェーズで絶対値に解決されますが、`width: 50%` は計算値フェーズでは解決されず、**使用値フェーズ**まで持ち越されます。

これは、先の図にあった通り、**レイアウト結果が必要な値は使用値フェーズに持ち越される**ためです。`line-height` の基準（自要素の `font-size`）は計算値フェーズで確定済みなので解決可能、`width` の基準（包含ブロックの幅）はレイアウトが終わるまで決まらないので保留されます。

```css
.parent {
  width: 800px;
}
.child {
  width: 50%;
}
.grandchild {
  width: inherit; /* width は通常継承されないので明示的に継承 */
}
```

```html
<div class="parent">
  
  <div class="child">
    
    <div class="grandchild">
      
    </div>
  </div>
</div>
```

- `.child` の計算値: `50%`（パーセントのまま）
- `.child` の使用値: `400px`（包含ブロックである `.parent` の幅が決まってから算出）
- `.grandchild` は `.child` から計算値 `50%` を継承 → 包含ブロックが `.child`（400px）になるので使用値は `200px`

もし使用値（`400px`）が継承されていれば孫も `400px` になるはずですが、実際は `200px` になります。これは**継承されているのは計算値（`50%`）であり、使用値フェーズでの解決は受け取った要素ごとに行われる**ためです。

---

## まとめ

- CSS のプロパティ値は「宣言値 → カスケード値 → 指定値 → 計算値 → 使用値 → 実効値」と段階を踏んで処理されます
- 親から子へ渡るのは計算値です
- カスタムプロパティでは、`cqi` のような相対単位がいつ絶対値になるかが `@property` の有無で変わります

CSS を「宣言型の言語」と捉えると見過ごしがちですが、内部では**いつ・どこで値が確定するか**が細かく定義されていて、どの段階で解決されるかはプロパティと単位の組み合わせで決まっています。段階処理を念頭に考えると、継承される値の挙動も理解しやすくなるはずです。

最初は「なんだこの挙動？」から始まった話でしたが、辿ってみれば全部仕様通りの綺麗な動作でした。普段何気なく書いている CSS の下に、こんな細かい処理モデルが敷かれているとは思いませんでした。

---

## 参考

- [CSS Cascading and Inheritance Level 5（§ 4 Value Processing） - W3C](https://www.w3.org/TR/css-cascade-5/#value-stages)
- [CSS Properties and Values API Level 1（§ Substitution） - W3C](https://www.w3.org/TR/css-properties-values-api-1/#substitution)
- [CSS Inline Layout Level 3（line-height property） - W3C](https://www.w3.org/TR/css-inline-3/#line-height-property)
- [@property - MDN](https://developer.mozilla.org/ja/docs/Web/CSS/@property)
- [CSS プロパティ値処理 - MDN](https://developer.mozilla.org/ja/docs/Web/CSS/Guides/Cascade/Property_value_processing)
- [CSS Properties and Values API - MDN](https://developer.mozilla.org/ja/docs/Web/CSS/CSS_Properties_and_Values_API)
- [CSS Container Queries - MDN](https://developer.mozilla.org/ja/docs/Web/CSS/CSS_containment/Container_queries)

CSS：@property を書くとカスタムプロパティの継承値が変わる

複数案件の経験から得た Java / Spring Boot バージョンアップ実践ガイド


AIでコードを書くのは速くなった。一方で、仕様決めのAI壁打ちには少し飽きてきた。同じように感じている人、いませんか？

「これどう思う？」と聞くと丁寧に答えてくれるし、「他の案は？」と聞けば、3つくらい出してくれる。非常に便利になったと理解しています。

でも、なんだろう、この**インタビューしてる感**。自分がずっと聞き手で、AIがずっと回答者。1対1の問答がずっと続く。

この記事では、BMAD-METHODと呼ばれる、ディスカッション形式でAI駆動のアジャイル開発を進めるOSSを活用し、これらの課題を解決する方法について紹介します。

## チャットで育った世代の違和感

![チャットで育った世代のイメージ]({{ sitePrefix }}/assets/img/articles/2026-04-16-BMAD-METHOD/1.webp)

思えば自分たちの世代は、Slackなどのチャット文化で育ってきたと思っています。

誰かが発言すると、別の誰かが「いや、それよりこっちじゃない？」と返す。そこに第三者が「両方試せばよくね？」と入ってくる。

同意された時、ひどく批判された時、色々ありましたが、あのテンポ感が自分には合っていました。

あのザワザワした感じの中でこそ、アイデアが磨かれてきた。

なのにAIとの対話は、壁に向かってボールを投げているような感覚。

返ってはくるけど、**いきいきとした会話**がない。

## BMAD-METHODという選択肢

![BMAD-METHODのイメージ]({{ sitePrefix }}/assets/img/articles/2026-04-16-BMAD-METHOD/2.webp)

[BMAD-METHOD](https://github.com/bmad-code-org/BMAD-METHOD)は、AI駆動のアジャイル開発フレームワークとして作られたOSSです。

ざっくり言うと：

- **PM、アーキテクト、開発者、UXデザイナー**など12以上の専門エージェントが定義されている
- **分析 → 計画 → 設計 → 実装**の4フェーズが型として用意されている
- 各フェーズで適切なエージェントが登場し、**ディスカッション形式**で進行する

正直に言うと、Claudeに「PMの視点でレビューして」と頼めば同じようなことはできます。

BMADの価値は、**それを毎回自分で考えなくていい**ところ。レシピ本みたいなものです。料理の腕（AI）は同じでも、手順があると失敗しにくい。

上述のような価値は大事です。しかし、私が一番注目しているのはそこではありません。

BMADはペルソナを設定することで、**AIの中に疑似チームを作れる**。PM、アーキテクト、QA...それぞれの専門家が、それぞれの立場で意見をぶつけ合う。

しかも、各ペルソナの性格やチーム全体の雰囲気まで自分で決められる。

慎重なアーキテクトと攻めのPM、みたいな組み合わせも自由自在です。

つまり、自分の手元にあっという間に**理想のチームが出来上がってしまう**。

採用も調整もいらない。これが壁打ちとは決定的に違うところです。

## 実際のディスカッションを覗いてみよう

![ディスカッションのイメージ]({{ sitePrefix }}/assets/img/articles/2026-04-16-BMAD-METHOD/3.webp)

では、BMADを使うと実際にどんな会話が生まれるのか。自分のターンが来るまで、チーム全員が勝手に会話を進めてくれるイメージです。

たとえば、タスク管理アプリを開発中にクライアントから「編集ボタンをつけてほしい」と要望が来たとします。

**BMAD（ディスカッション）：**

> **PM**：クライアントから「タスクに編集ボタンをつけてほしい」って要望が来てるんだけど
---
> **自分**：了解、じゃあ編集機能つけようか
---
> **UXデザイナー**：ちょっと待って。何を編集したいの？タイトル？ステータス？全部？
---
> **自分**：えーと...聞いてないな。たぶん全部？
---
> **アーキテクト**：全フィールド編集可能にすると、変更履歴の管理とか権限まわりが一気に複雑になるよ
---
> **ジュニアエンジニア**：あ、それ僕が実装する側なんですけど...編集の取り消し機能とかも要ります？正直けっこう重いです
---
> **PM**：そもそもなんで編集したいんだろう。タスクの書き間違いを直したいだけなら、作成後5分以内だけ編集可能とかでよくない？
---
> **UXデザイナー**：あるいはステータス変更だけなら、ドラッグ＆ドロップで十分だよね。わざわざ編集画面を開かせる必要ある？
---
> **QA**：ちなみに編集機能つけると、テストケースが爆発するよ。権限×フィールド×状態の組み合わせで。本当に必要なら覚悟してね
---
> **アーキテクト**：ドラッグ＆ドロップなら実装もシンプルだし、APIも薄くて済む
---
> **PM**：一回クライアントに「編集で具体的に何がしたいですか？」って聞き返した方がよさそうだね
---
> **自分**：たしかに。「編集ボタン」って言われてそのまま作るとこだった。聞いてみるわ

コードを1行も書く前に、こんなやりとりが勝手に始まる。

1対1の単調なやりとりと違って、会話にリアリティが生まれる。

気づいたら没頭していて、**アイデアに磨きがかかっている**。

Slackで育った世代の自分にとって、これが何より大きなメリットだと感じています。

## 没頭できるから、アウトプットが変わる

![没頭のイメージ]({{ sitePrefix }}/assets/img/articles/2026-04-16-BMAD-METHOD/4.webp)

壁打ちとディスカッション、やっていることは似ているかもしれません。でも体験がまるで違う。

壁打ちは「自分が次に何を聞くか」を常に考えなければいけない。

ディスカッションは、勝手に議論が転がっていく中で「お、それいいね」「いや、ちょっと待って」と参加するだけ。

この**没頭感**が、実はいちばん大きなメリットだと思っています。

集中のスイッチが入りやすい。

考えるべきことに集中できる。

結果として、アウトプットの質も上がる。「ツールの性能が上がった」のではなく、**自分のパフォーマンスが上がる**。そういう種類の改善です。

## まとめ

BMAD-METHODは魔法のツールではありません。Claudeにできないことを可能にするわけでもない。

でも、AIとの協業を「壁打ち」から「チーム開発」に変えてくれる。チャット世代の自分にとって、それだけで十分に価値がありました。

壁打ちに飽きたあなたへ。一度、会議に参加してみませんか。


AIとの壁打ちに飽きた人たちへ

リモートワークからリモートAIワークへ



# EMConf 2026 参加レポート 

## 1. はじめに — 参加の動機

3/4に開催された EMConf 2026に参加してきましたので、当日の様子や感想などをレポート形式ご紹介します。

私はエンジニアリングマネージャーとしてフルサイクルチームを立ち上げ、AI駆動を推進しています。

{{ogp-link="https://engineering.monstar-lab.com/jp/post/2025/10/07/FullCycle-Team-is-launched/"}}

## 2. 講演 — 学びと気づき

### 安斎勇樹さんのキーノート「冒険する組織のつくりかた」
{{ogp-link="https://2026.emconf.jp/keynote-opening/"}}

もともと、 安斎さんの著書である[冒険する組織のつくりかた](https://amzn.to/3NjA6Je)は、[fukabori.fm #128](https://fukabori.fm/episode/128) で知り、目標設定に関する内容も含まれるということで、読んでいました。
しかし、いかにメンバーの個人目標をALIVEなものにしてもらうかという点で課題を持っており、詳しく知れるといいなと楽しみにしていました。
講演は期待通りで、特に半径5mから変革できる、4つのマネジメントという、絶妙なスコープ感が良い講演でした。
また、講演後のAsk the Speakerで直接話を伺うことができ、イベントの開始から大変満足度の高い経験を得られました。

{{ogp-link="https://amzn.to/4b8EsuA"}}

### こにふぁーさんの講演「マネージャー版 "提案のレベル" を上げる」

{{ogp-link="https://fortee.jp/emconf-2026/proposal/2d4c316d-154e-482d-9c7d-d19483880712"}}
<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/7fb910bbb5fe45818715d3a05e0b4120" title="マネージャー版 &quot;提案のレベル&quot; を上げる" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>

こにふぁーさんの講演は、提案のレベルについてのマネージャー向けバージョンでした。発表の中でこにふぁーさん自身の貴重な失敗談が共有されました。

特に部署・ロールを跨いだ提案をする際に準備しすぎてしまった体験談が心に残りました。
私もEMになって日が浅いときに、[DataAnalyzeAI](https://monstar-lab.com/jp_ja/lp/ai-solution/dataanalyzeai)のプレス発信を目指して、他部署に協力を求めた際の不安と重なり、強く共感しました。
レベルは上げるものだという先入観に対して、
**「意図して提案のレベルを下げる」** という手段が目からウロコでした。


### 江副さんの講演「『開発生産性』ではなく『事業生産性』こそが本質 〜 ROICで紐解く、開発の「稼ぐ力」の最大化 〜」

{{ogp-link="https://fortee.jp/emconf-2026/proposal/a5d1c2f1-dc7b-47fe-ac37-c5c4e2bc8595"}}

エンジニアの生産性を、開発生産性から更に踏み込んで、「事業生産性」をどう見るかという講演でした。
企業の本質的な「稼ぐ力」を示す経営指標 ROIC（投下資本利益率）とほぼ同義であると定義しています。
これは、モンスターラボのビジネスモデルではまた異なると思われるのですが、きちんと経営指標について学び、自分たちの事業貢献を測れるようにしたいと思える講演でした。

## 3. アンカンファレンス

ポッドキャストの公開収録セッションに参加しました。941さんが収録準備をする様子を見ていると、なぜか3本目のマイクが出てきて、いつの間にか飛び入りゲストでだいくしーさんの出演が決まっていました。（とてもアジャイルな流れに感動しました！）

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">あらたまいくおのマネジメントラジオ、公開収録中。ポッドキャストの収録機材をシュッと提供した。 <a href="https://twitter.com/hashtag/emconf_jp?src=hash&amp;ref_src=twsrc%5Etfw">#emconf_jp</a> <a href="https://t.co/9Emhsj2To6">pic.twitter.com/9Emhsj2To6</a></p>&mdash; 941 / kushii (@941) <a href="https://twitter.com/941/status/2029050305384727029?ref_src=twsrc%5Etfw">March 4, 2026</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>


また、「EMの年収を上げるには」というセッションでは、つい数日前に株式会社フォークウェル代表取締役に就任された赤川さん中心に会話が進行しました。

この中で、参加者のEMたちの感覚として、EMの給与の妥当なゾーンは8百万円~12百万円と、思っている傾向にあることが見えました。
その上で、さらに給与レンジを引き上げるにはという意欲的な話が始まったのですが、残念ながら時間が足りずに終わってしまいました。しかし、この **ライブ感 もアンカンファレンスの魅力** ですね。また、機会があれば続きをお話したいです。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">アンカンファレンス「EMの給料を上げる方法を考えよう」でのワーク。<br><br>ではお集まりいただいたEMの皆さん、まずは手を挙げてください。<br>そして、この給料ならEMとしての給料の最低限ってラインになったら手をおろしてください。<br><br>500万円…誰もいませんね？<br><br>600万円…まだいない… <a href="https://t.co/zDmjuiZmQA">https://t.co/zDmjuiZmQA</a></p>&mdash; 赤川朗／『ITエンジニアの転職学（講談社）』発売中！ (@Akira_Akagawa) <a href="https://twitter.com/Akira_Akagawa/status/2029169385001070701?ref_src=twsrc%5Etfw">March 4, 2026</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

## 4. スポンサーブース

講演だけでなく、スポンサーブースも活気が溢れていました。各社工夫してEMConfを盛り上げようとネタを仕込まれていました。

その中で、リンクアンドモチベーション社のEMとの会話で、目標設定に課題を感じている話をしていました。
話を聞かせてもらった方は、目標設定はレバレッジが効くコスパの良いイベントだと捉えられていました。目標設定をしっかりやり切る事で、半年間メンバーが自走しながら事業貢献できるはずで、それはずっとマネージャーが都度指示を出すよりも、圧倒的にコスパが良いとおっしゃってました。
自分には、まったくなかった観点で、とても良く、目標設定に対する取り組む姿勢をもっと改めようと思えました。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">いよいよ本日開催のEMConf JP 2026、リンクアンドモチベーションはブースを出展しております。<br><br>組織マネジメントのセルフチェックや、組織論に基づく実践知をまとめた論文集、新作ノベルティなどご用意しております。<br>ぜひブースでお会いしましょう！<a href="https://twitter.com/hashtag/emconf_jp?src=hash&amp;ref_src=twsrc%5Etfw">#emconf_jp</a> <a href="https://twitter.com/hashtag/%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E3%83%92%E3%83%B3%E3%83%88?src=hash&amp;ref_src=twsrc%5Etfw">#マネジメントのヒント</a> <a href="https://t.co/frFOzuQJUH">pic.twitter.com/frFOzuQJUH</a></p>&mdash; リンクアンドモチベーション技術広報 (@LinkandM_dev) <a href="https://twitter.com/LinkandM_dev/status/2028971507532349688?ref_src=twsrc%5Etfw">March 3, 2026</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

## 5. ビンゴ＆景品
スポンサーブースを回ったり、スタッフの方と交流することでマスがうまるビンゴがあり、参加者中6番目に全部埋めることができました。
景品として、タオル、Tシャツ、サーモスのタンブラーをゲットしました！

![埋まったビンゴカード]({{ sitePrefix }}/assets/img/articles/2026-03-06-EMConf2026Report/bingocard.webp)
![ノベルティ]({{ sitePrefix }}/assets/img/articles/2026-03-06-EMConf2026Report/goods.webp)

## 6. あらたまさんのサイン
書籍の販売ブースでは著者のサイン会がされており、あらたまさんにサイン頂きつつ少しお話をさせてもらえました。
私はKindle派なので仕事用ノートにサインをもらったのですが、あらたまさんが自著の漢字を忘れてしまっていて、その様子にほっこりしました。

![あらたまさんのサイン]({{ sitePrefix }}/assets/img/articles/2026-03-06-EMConf2026Report/sign.webp)

## 7.懇親会 — 交流と内省
懇親会では、ポッドキャストリスナーとして、いくおさんに挨拶できました。
また、その他多くの参加者の方とEM同士で胸襟を開いて話し合い、スポンサーブースでも話した目標設定の課題などワイワイと意見交換できました。

<blockquote class="twitter-tweet"><p lang="ja" dir="ltr">大変お待たせしました！<br>ついに懇親会スタートです🍻🎉<br>参加される皆さん、リラックスして楽しいひとときをお楽しみください！<br>ここでも素敵な「繋がり」が「増幅」しますように✨<a href="https://twitter.com/hashtag/emconf_jp?src=hash&amp;ref_src=twsrc%5Etfw">#emconf_jp</a> <a href="https://t.co/TrmAPsrQN0">pic.twitter.com/TrmAPsrQN0</a></p>&mdash; EMConf JP オフィシャル (@emconf_jp) <a href="https://twitter.com/emconf_jp/status/2029126638697628119?ref_src=twsrc%5Etfw">March 4, 2026</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

## 8. まとめ 

EMConf2026への参加は、EMとしての学びを得られただけでなく、マネジメント活動に向き合うエネルギーチャージの場になりました。
こういった場に送り出してくれた会社には深く感謝しています。

ところで、EMConfは [DE&Iポリシー](https://2026.emconf.jp/de-and-i/)を掲げています。今回はまず女性の参加者増に焦点を当てられたとのことですが、なんと弊社には海外出身のEMが複数在籍しています。
https://www.talent-book.jp/monstar-lab/knowhows/52224
次回はそういったメンバーも連れていって、DE&I実現に協力したいなと野望を持ちました。

最後にモンスターラボでは一緒に働く仲間を募集しています。

![jobboard]({{ sitePrefix }}/assets/img/articles/2026-03-06-EMConf2026Report/jobboard1.webp)
![jobboard]({{ sitePrefix }}/assets/img/articles/2026-03-06-EMConf2026Report/jobboard2.webp)

こんな社員の背中を押してくれる会社やEMたちと働きたいと少しでも感じていただけたら、下記から採用情報を眺めて頂けると幸いです。

{{ogp-link="https://monstar-lab.com/jp_ja/careers"}}


EMConf 2026 参加レポート 


## はじめに

弊社は世界各国に拠点を持ち、グローバルな体制でプロジェクトを推進しています。特に日本とベトナム（ハノイ・ダナン）の拠点間での協業は、多くのプロジェクトで積極的に採用されている体制です。

近年、AI による翻訳技術や音声認識の飛躍的な進化により、言語の壁を越えたコミュニケーションは以前と比べて格段にやりやすくなりました。リアルタイム翻訳ツールや AI 支援によるドキュメント作成など、テクノロジーがグローバルチームの協業を強力にサポートしています。

しかし、技術的な支援が充実した今でも、オフショア拠点とのプロジェクト運用には依然として特有の課題が存在します。私自身がベトナムチームとのシステム運用を通じて直面したのは、単なるコミュニケーションの問題だけでなく、タスクの依頼方法や協業の進め方そのものに関わる本質的な課題でした。

今回は、プロジェクトマネジメント的な話になってしまいますが、私自身エンジニアとしてチームをリードする立場として参画したプロジェクトで、チームのやり方を考えたこれらの経験から得られた、オフショアチームとの運用を円滑に進めるための実践的なポイントをご紹介したいと思います。

グローバルな働き方をするリードエンジニアの方に役立てば嬉しいです。

## 今回の例の前提となるチーム構成

下記でご紹介する課題と改善ポイントについて、私は下記のようなチーム構成で体験をしました。
チームの概要は以下のとおりです。

- すでに本番稼働しているプロダクトを運用中
- 10 名以下で構成される小規模チーム
- アジャイル・スクラムの考え方を適用
- チーム外にベトナム側の技術リーダーが存在
- 数年続くプロジェクトで、体制再編や人の入れ替わりが発生する

このような環境の中で、私たちは日本とベトナム間でのチームコミュニケーションに課題を抱えていました。

## 直面していた課題

チームでは当初、以下のような進め方をしていました。

1. 日本側メンバーがタスクチケットを作成し、内容を簡単に記載
2. スプリントプランニング前日に通訳メンバーへ説明して翻訳を依頼
3. スプリントプランニングで PO と実施予定タスクを確認してスプリント開始
4. スプリントレビューで実施したチケットを振り返り

一見すると問題なさそうに見えるこのフローですが、実際には以下のような課題が発生していました。

- **通訳メンバーへの負荷集中**：スプリント切り替わりの数日間、通訳メンバーの負荷が極端に上がる
- **認識のズレ**：ベトナムメンバーが実施した作業が、日本側メンバーの認識と異なった内容で実施されてしまう
- **完了判断の迷い**：ベトナムメンバーがチケットをクローズしてよいか判断できない

これらの課題の根本原因は、「暗黙のルール」に頼ったコミュニケーションにありました。これまでのやり方や流れを都度アドリブで対応していたため、認識の齟齬が生まれやすい状態だったのです。

## 3 つの改善ポイント

これらの課題を解決するために、私たちは以下の 3 つのポイントを意識してコミュニケーションフローを改善しました。

### ポイント 1：依頼内容と一緒に「背景・目的・ゴール」を明確にする

改善前は、タスクチケットに「何をするか」だけを記載していました。しかし、これでは「なぜそれをするのか」「どうなれば完了なのか」が伝わりません。

改善後は、以下の情報を必ず記載するようにしました。

- **背景**：なぜこのタスクが必要なのか
- **目的**：このタスクで達成したいこと
- **ゴール（Acceptance Criteria）**：どうなれば完了と言えるのか

これにより、ベトナムメンバーがタスクの意図を正しく理解し、期待通りの成果物を出せるようになりました。また、完了判断も明確になり、「クローズしてよいか迷う」という問題が解消されました。

### ポイント 2：作業内容を一緒に考える

タスクを「渡す」のではなく、作業内容を「一緒に考える」プロセスを取り入れました。

具体的には、以下のようなフローに変更しました。

1. 日本側メンバーがタスクの背景・目的・ゴールを記載したチケットを作成
2. **ベトナムメンバーがチケットの内容を読み、TODO を自分で記載**
3. スプリントリファインメントで、実施に必要な情報が網羅されているかをお互いに確認し、合意してから Ready にする
4. スプリントプランニングで、すべてのタスクが Ready になっていることを確認してスプリント開始

このプロセスで最も重要なのは、**ベトナムメンバー自身が TODO を考える**という点です。ただ渡されるタスクではなく、自分で作業内容を考えることで、タスクに対する理解と責任感が醸成されます。

また、リファインメントで事前に認識を合わせることで、スプリント開始時点で「やることとゴールをきちんと理解した状態」でスタートできるようになりました。

### ポイント 3：協業先拠点のリーダーを頼る

改善を進める中で気づいたことがあります。開発メンバーに直接伝えても、意図が十分に伝わらないことがあったのです。

そこで、複雑な内容や方針の変更については、ベトナム側の技術リーダーを介して伝えてもらうようにしました。

具体的には、以下のような流れで進めました。

1. リーダーメンバー向けに、変更したい理由や細かい意図を記載したドキュメントを作成
2. リーダーメンバーと認識を合わせるためのミーティングを実施
3. リーダーメンバーからチームへ、背景を含めてトップダウンで展開

この方法に変えたところ、チームのやり方がスムーズに変わりました。

これは単なる日本、ベトナムメンバー間の「信頼性」の問題ではないと考えています。通訳を介することで抜け落ちやすい「なぜそうするのか」という背景情報を、リーダーメンバーがネイティブの言葉で詳しく伝えてくれたことがポイントでした。

## 現地出張で得られた気づき

上記のポイントの他に、ベトナム拠点に出張して感じたことが、チームとの円滑な協業をするうえで大きな気付きとなりました。

### 相手の状況を肌で感じる

現地に行くことで、ベトナムメンバーがどのようなタイムラインで仕事をしているのかを把握できました。勤務時間や休憩時間といった、リモートでは見えにくい情報が理解できたことで、コミュニケーションのタイミングや期待値の調整がしやすくなりました。

### 「顔を見る」ことの価値

メンバーの顔やひととなりを直接認識することで、チーム内の距離が一気に縮まった感覚がありました。言葉が完全に通じなくても、振る舞いを見ることで「どういった人なのか」という解像度が明らかに高くなります。

興味深いことに、ベトナムのメンバーからは「怖い人だと思っていたけど、会ってみたら違った」という声をもらいました。（怖い人だと思わせてごめんなさい。。。）
お互いに、一緒に仕事をする相手がどういう人なのかを憶測ではなくきちんと理解することで、気持ちよく仕事ができるようになったと感じています。

## まとめ

本記事では、ベトナムチームとのシステム運用を円滑に進めるための 3 つのポイントをご紹介しました。

1. **依頼内容と一緒に「背景・目的・ゴール」を明確にする**
2. **作業内容を一緒に考える**
3. **協業先拠点のリーダーを頼る**

これらの取り組みによる変化について、チームメンバーからは以下のような声がありました。

- 「以前より情報整理の負荷は増したが、代わりに認識違いによるやり直しのロスが減った」
- 「スプリント開始までにやることとゴールをきちんと理解してスタートできるようになった」

## さいごに

振り返ってみると、今回ご紹介した内容は、たとえメンバー全員が日本人であってもチームマネジメントとして大切なことばかりです。
しかし、言語や文化の違いがある環境では、これらをより明確に、より丁寧に行う必要があると強く感じました。

体制変更などにより、新しいチームが発足したときなどは、最初にこういったルールやポリシーの明確化ができると良いと思います。
また、歴史があるプロジェクトでも、なんとなく進められているからと見過ごされてしまいがちですが、コミュニケーションが上手くできていないと感じる場合はこれまでの暗黙の了解に頼らず、明確なコミュニケーション構造をチームで検討するべきだと思います。

これらは決して特別なことではありませんが、オフショアチームとの協業においては、意識的に実践することで大きな効果を発揮すると実感しました。

これからも、グローバルチームで高い価値を提供していきたいと思います。


ベトナムチームとのシステム運用でうまく協業するポイント




[AI & Digital Partners](https://monstar-lab.com/jp_ja/whymonstarlab) をビジョンに掲げるモンスターラボでは、全社員にDifyアカウントが提供されています。これにより、誰でも自由にワークフローやエージェントを開発し、社内に展開できる環境が整っています。当社では、顧客企業をはじめとする各種規定を遵守しつつ、AI活用を推進できるよう、AIの活用に関する社内ポリシーを制定しています。

しかし、DifyからGoogle Driveと連携しようとすると一つの壁にぶつかります。会社のGoogle Workspaceでは、ドライブの共有範囲が組織内に限定されており、先述のポリシーに則った利用の場合も制限が掛かってしまう場合があります。

本記事では、この制約を回避するためにGoogle Apps Script（GAS）でAPIを作成し、Default Application Credentialsで認証する方法を紹介します。

## 背景：なぜGAS APIが必要なのか

DifyにはGoogle Drive連携の機能がありますが、組織のセキュリティポリシーによっては直接アクセスできないケースがあります。そこで、GASをAPIのプロキシとして利用することで、Difyから間接的にGoogle Driveやスプレッドシートにアクセスできるようになります。

## GASでAPIを作成する

### 開発環境の準備

GASの開発には [clasp](https://github.com/google/clasp) が便利です。ローカルでTypeScriptを使った開発ができ、AIコーディングアシスタントとの相性も良いです。

```bash
npm install -g @google/clasp
clasp login
clasp create --type webapp
```

### APIエンドポイントの実装

GASでは `doGet` や `doPost` 関数を定義することでHTTPリクエストを受け付けられます。

```typescript
function doGet(e: GoogleAppsScript.Events.DoGet): GoogleAppsScript.Content.TextOutput {
  console.log('GET request received');
  
  // ここでGoogle Driveやスプレッドシートの操作を行う
  
  return ContentService.createTextOutput(JSON.stringify({ status: 'success' }))
    .setMimeType(ContentService.MimeType.JSON);
}

function doPost(e: GoogleAppsScript.Events.DoPost): GoogleAppsScript.Content.TextOutput {
  const payload = JSON.parse(e.postData.contents);
  
  // スプレッドシートへのデータ追記など
  
  return ContentService.createTextOutput(JSON.stringify({ status: 'success' }))
    .setMimeType(ContentService.MimeType.JSON);
}
```

### デプロイ

GASエディタから「デプロイ」→「新しいデプロイ」を選択し、ウェブアプリとして公開します。

公開後、以下の形式のURLでAPIを呼び出せます：

```
https://script.google.com/macros/s/{DEPLOYMENT_ID}/exec
```

## 認証の課題

ここで問題が発生します。組織内ユーザーにアクセスを限定している場合、APIを呼び出すにはGoogleアカウントの認証が必要になります。

DifyからこのAPIを呼び出すには、何らかの方法でアクセストークンを取得し、リクエストに含める必要があります。

## 解決策：Default Application Credentials

今回は [Application Default Credentials（ADC）](https://cloud.google.com/docs/authentication/application-default-credentials) を利用してアクセストークンを取得します。

ADCは、Google Cloud SDKやクライアントライブラリが認証情報を自動的に検出するための仕組みです。ローカル開発環境では `gcloud auth application-default login` で作成した認証情報が使われます。

### 必要なスコープ

GASウェブアプリへのアクセスに必要な最小限のスコープは以下の通りです：

|スコープ            |必要性|理由                                        |
|----------------|---|------------------------------------------|
|`openid`        |必須 |認証の基本                                     |
|`drive`         |必須 |GASウェブアプリへのアクセスに必要                        |
|`userinfo.email`|任意 |`Session.getActiveUser().getEmail()` を使う場合|
|`cloud-platform`|任意 |gcloud CLIが要求するだけ。直接取得なら不要                |

### 認証情報の作成

```bash
gcloud auth application-default login \
  --scopes="openid,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/drive"
```

実行すると、認証情報が以下に保存されます：

```bash
# macOS / Linux
~/.config/gcloud/application_default_credentials.json

# Windows
%APPDATA%\gcloud\application_default_credentials.json
```

### アクセストークンの取得

保存された認証情報からアクセストークンを取得するには、refresh_tokenを使ってトークンエンドポイントにリクエストします：

```bash
curl -X POST https://oauth2.googleapis.com/token \
  -d "client_id={CLIENT_ID}" \
  -d "client_secret={CLIENT_SECRET}" \
  -d "refresh_token={REFRESH_TOKEN}" \
  -d "grant_type=refresh_token"
```

### Dify 上でのトークン取得

前述のように、Default Application Credentials として保存された認証情報を用いてアクセストークン取得APIを叩きます。
今回は、DifyのHTTPリクエストブロックを利用しました。

application_default_credentials.jsonに記載されている、 `client_id`, `client_secret`, `refresh_token`を利用します。
Difyには、認証情報をシークレットとして安全に管理してください。

HTTPリクエストブロックは、下図のように設定します。
- ヘッダー
	- `Content-Type: application/x-www-form-urlencoded`
- ボディ
	- `x-www-form-urlencoded`
	- `client_id` : シークレットに保存した client_id
	- `client_secret` : シークレットに保存した client_secret
	- `refresh_token` : シークレットに保存した refresh_token
	- `grant_type: refresh_token` 

![blog_dify_gas_get_access_token]({{ sitePrefix }}/assets/img/articles/2026-02-05-How-to-access-google-drive-from-dify/blog_dify_gas_get_access_token.webp)

### Difyからの呼び出し

取得したアクセストークンをAuthorizationヘッダに付与してGAS APIを呼び出します。
リクエストするメソッドとURLは先述の通り、GASのDeploymentに応じて `https://script.google.com/macros/s/{DEPLOYMENT_ID}/exec` を呼び出します。

```
Authorization: Bearer {ACCESS_TOKEN}
```

![blog_dify_gas_request_api]({{ sitePrefix }}/assets/img/articles/2026-02-05-How-to-access-google-drive-from-dify/blog_dify_gas_request_api.webp)

## セキュリティ上の考慮事項

この方法を採用する際は、以下の点に注意が必要です：

- **認証情報の漏洩リスク**：Default Application Credentialsが漏洩すると、なりすましが可能になります。このリスクを、以下の条件のもとコントロールしています。
	- **スコープの最小化**：必要最小限のスコープのみを指定し、権限を絞っている
	- **アクセス制限**：Difyが社内からのアクセスに限定されている
	- **シークレット管理**：Dify上では認証情報をシークレットとして管理し、ワークフロー定義に直接書かない

## まとめ

DifyからGoogle Drive上のファイルにアクセスする手段として、GASを用いたAPIを作成しました。組織のアクセス制限を回避するため、Default Application Credentialsを使ってアクセストークンを取得し、認証を行っています。

この仕組みにより、Difyを活用した社内のAI駆動DXをさらに推進できます。

## 参考リンク

- [Application Default Credentials（ADC）- Google Cloud](https://cloud.google.com/docs/authentication/application-default-credentials)
- [clasp - Google Apps Script CLI](https://github.com/google/clasp)
- [Dify Documentation](https://docs.dify.ai/)


Dify × GAS：社内Difyから組織限定のGoogle Driveにアクセスする


私は長年にわたり業務でFlutterアプリを開発してきましたが、バックエンドの状況がFirebaseからSupabase、そしてカスタムNode.js APIへと進化していくのを目の当たりにしてきました。

この進化の中で、それぞれのソリューションにはトレードオフがありました。Firebaseはベンダーロックインの問題があり、Supabaseはカスタムロジックが必要になるまでは素晴らしいものでした。そして、別途Node.jsバックエンドを維持する場合は、TypeScriptとDartの間でコンテキストスイッチが必要になるという課題がありました。

正直なところ、新しいバックエンドソリューションを積極的に探していたわけではありません。しかしServerpodはフィード、Flutterニュースレター、他の開発者との会話など、至る所で目や耳にする機会も増え、その注目度が本物であることを身をもって感じていました。

そこで、これらの注目度に比例するような実態があるかどうかを確かめてみたく、週末を使って試してみることにしました。
今回は、私が試用の中で発見したいくつかのポイントについてご紹介します。

---

## セットアップ: 最初の驚き

通常のセットアップの摩擦を予想していました。Dockerの設定、環境変数、データベース接続文字列、認証ミドルウェア。確かに、ClaudeやCursorに定型文のヘルプを頼むこともできますが、AIエージェントがスピードアップしてくれても、バックエンドスタックを立ち上げるには、実際のビジネスロジックを書く前に1時間のセットアップが必要です。

代わりに:

```bash
$ serverpod create weekend_experiment
Creating project...
✓ Server setup complete (packages/weekend_experiment_server)
✓ Client library generated (packages/weekend_experiment_client)
✓ Flutter app created (weekend_experiment_flutter)
✓ Database migrations ready
✓ Docker compose configured
```

プロジェクト構造は、Flutterの開発者にとってすぐに馴染みのあるものでした:

```
weekend_experiment/
├── weekend_experiment_server/     # バックエンドコード
├── weekend_experiment_client/     # 自動生成されたAPIクライアント
├── weekend_experiment_flutter/    # Flutterアプリ
└── docker-compose.yaml            # PostgreSQL + Redis準備完了
```

サーバーディレクトリで**docker compose up**を実行しました。PostgreSQLとRedisが起動しました。次に**dart run bin/main.dart --apply-migrations**でデータベースを初期化しました。

<figure>
  <img src={{ sitePrefix }}/assets/img/articles/2026-02-03-Serverpod-for-a-Weekend-The-Good-The-Bad-and-The-Surprising/serverpod-architecture-ja.webp>
  <figcaption>図1: Serverpodの統合アーキテクチャ - 1つのコードベース、完全な型安全性</figcaption>
</figure>

---

## 良い点: 実際に感銘を受けたこと

### 1. あなたと戦わないORM

私は良いデータベースツールがどのように感じられるかを知るのに十分なSQLを書いてきました。また、恐ろしいクエリを生成し、簡単なことを難しくするORMに苦しんできました。

ServerpodのORMをテストするためにモデルファイルを作成しました:

```yaml
# user.spy.yaml
class: User
table: user
fields:
  name: String
  email: String
  age: int?
  premium: bool
  createdAt: DateTime

indexes:
  - fields: email
    unique: true
```

**serverpod generate**を実行しました。フレームワークは以下を生成しました:

- すべてのフィールドを持つDartクラス
- JSONシリアライズ/デシリアライズ
- データベースアクセスメソッド
- クライアント側モデル
- マイグレーションファイル

ここで興味深くなりました。クエリAPIは**自然**に感じられました:

```dart
// 25歳以上のすべてのプレミアムユーザーを作成日順で検索
final users = await User.db.find(
  session,
  where: (t) => t.premium.equals(true) & t.age.greaterThan(25),
  orderBy: (t) => t.createdAt.desc(),
  limit: 20,
);

// リレーションを使った複雑な結合
final postsWithAuthors = await Post.db.find(
  session,
  where: (t) => t.publishedAt.isNotNull(),
  include: (t) => [t.author, t.comments],
);
```

**型安全。文字列のカラム名なし。SQLインジェクション不可能。IntelliSenseが利用可能なフィールドを表示。**

意図的に壊れたクエリでテストしました:

```dart
where: (t) => t.nonExistentField.equals(true)  // コンパイルエラー!
```

Dartアナライザーがすぐにそれを検出しました。ランタイムのサプライズなし。タイプミスによる本番環境の問題のデバッグなし。

<figure>
  <img src={{ sitePrefix }}/assets/img/articles/2026-02-03-Serverpod-for-a-Weekend-The-Good-The-Bad-and-The-Surprising/orm-query-flow-ja.webp>
  <figcaption>図2: Dart式から最適化されたPostgreSQLへの型安全なクエリ</figcaption>
</figure>

### 2. 実際に機能するリアルタイム

ほとんどのリアルタイム実装には、WebSocketサーバーのセットアップ、接続/切断の処理、サブスクリプションの管理、再接続ロジックの処理、状態の同期が含まれます。

Serverpodのストリーミング機能を簡単なカウンターでテストしてみました。

**サーバーエンドポイント:**

```dart
class CounterEndpoint extends Endpoint {
  Stream watchCounter(Session session) async* {
    for (int i = 0; i < 100; i++) {
      await Future.delayed(Duration(seconds: 1));
      yield i;
    }
  }
}
```

**クライアントの使用:**

```dart
client.counter.watchCounter().listen((count) {
  print('Counter: $count');
});
```

以上です。ServerpodはWebSocket接続管理、ネットワーク損失時の自動再接続、クライアントが遅い場合のバックプレッシャー、クリーンなストリームの廃棄を処理します。

データベース駆動のリアルタイム更新の場合:

```dart
class ChatEndpoint extends Endpoint {
  Stream watchRoom(Session session, int roomId) async* {
    await for (var message in Message.db.watch(
      session,
      where: (t) => t.roomId.equals(roomId),
    )) {
      yield message;
    }
  }
}
```

そのチャットルームのメッセージへのデータベース変更は、接続されているすべてのクライアントに自動的にストリーミングされます。手動pub/subセットアップなし。Redisチャンネルなし。メッセージキューなし。

### 3. 理にかなったコード生成

Serverpodの生成は単純明快です。YAMLで定義されたモデル、サーバー構造から生成されたコード。出力は読みやすいDartです—マジックなし、複雑さを隠す抽象化なし。何か問題があるとき、実際に何が起こっているかを見ることができます。

```bash
$ serverpod generate
Analyzing server...
✓ Found 5 models
✓ Found 3 endpoints
Generating...
✓ Client library (packages/weekend_experiment_client/)
✓ Protocol models
✓ Database migrations

Time: ~5 seconds
```

### 4. 涙なしの認証

認証のセットアップは年々簡単になってきました—多くのライブラリがOAuthフローを処理します。しかし、それらを統合するには、設定、コールバックのテスト、環境全体で機能することの確認が必要です。

Serverpodには、Google、Apple、メール認証をサポートする**serverpod_auth**モジュールが含まれています。

**サーバーセットアップ:**

```dart
import 'package:serverpod_auth/server.dart';

// 認証はserverpod_authパッケージを通じて設定されます
```

**クライアントセットアップ:**

```dart
import 'package:serverpod_auth/client.dart';

// Googleでサインイン
final result = await client.auth.signInWithGoogle();
if (result.success) {
  print('Welcome ${result.userInfo.userName}');
}
```

セッションには自動的に認証されたユーザーが含まれます:

```dart
class ProfileEndpoint extends Endpoint {
  Future getMyProfile(Session session) async {
    final userId = session.userId;
    if (userId == null) throw Exception('Not authenticated');

    return await Profile.db.findById(session, userId);
  }
}
```

JWT解析なし。ミドルウェアチェーンなし。認証ヘッダー管理なし。

_(プロのヒント: iOSアプリにGoogle Sign-Inを追加する場合、Apple Sign-Inも忘れないでください。さもないとAppleはアプリを喜んで拒否します。)_

<figure>
  <img src={{ sitePrefix }}/assets/img/articles/2026-02-03-Serverpod-for-a-Weekend-The-Good-The-Bad-and-The-Surprising/authentication-flow-ja.webp>
  <figcaption>図3: Google、Apple、メールを使用した組み込み認証</figcaption>
</figure>

### 5. 開発者体験

これは微妙ですが重要です: **すべてがDartです**。

- サーバーコード? Dart。
- クライアントコード? Dart。
- データベースモデル? Dart (YAMLを介してですが、Dartのように感じます)。
- テスト? Dart。
- ツール? Dart CLI。

クライアントとサーバーの両方をDartで書くことで、言語のコンテキストスイッチが排除されます。ツール、パターン、規約はスタック全体で一貫しています。エコシステムを切り替える認知的オーバーヘッドなしに、フロントエンドとバックエンドの作業の間を移動できます。

---

## 悪い点: 不足しているところ

ここで物事は完璧ではありませんでした。

### 1. 小さなパッケージエコシステム

サードパーティのパッケージエコシステムは、ExpressやDjangoと比較して限られています。いくつかのコミュニティパッケージ(Stripe統合など)は見つかりますが、同じ幅広い選択肢はありません。特定のCMS統合が必要ですか? Elasticsearchコネクタ? Twilioラッパー? おそらく自分で構築するか、既存のDartパッケージを適応させることになります。

AIコーディングアシスタントは一般的なDartパターンで役立ちますが、Serverpod固有の知識は限られています。標準的なCRUD操作と基本的なサーバーパターンには役立ちますが、主流のフレームワークよりもドキュメントとソースコードを読むことが多くなります。

プロジェクトが特殊なサービスとの統合に大きく依存している場合、または広範なサードパーティツールが必要な場合は、追加の実装時間を考慮してください。

### 2. 複雑な機能の学習曲線

基本はスムーズです。エンドポイントの作成、モデルの定義、シンプルなクエリ - すべて直感的です。

高度な機能は? ドキュメントは基礎となる概念を理解していることを前提としています。

複雑な認可パターン、高度なトランザクション処理、複雑なデータベースリレーションシップには、GitHubイシューとAIからのソリューションを組み合わせる必要があります。

### 3. マイグレーションの複雑さ

データベースマイグレーションは、シンプルな変更—nullableフィールドの追加、テーブルの作成—ではうまく機能します。複雑な変更には手動介入が必要です:

- データ変換
- データを保持しながら列の名前を変更
- テーブルの分割
- 複雑な制約の変更

マイグレーションシステムはこれらのシナリオを自動的に処理しません。生成されたSQLマイグレーションを手動で編集できますが、これにより型安全なORMの利点の一部が減少し、慎重なテストが必要になります。

### 4. 本番環境ドキュメントのギャップ

ローカルで始めるには? 完璧です。

本番環境にデプロイするには? ドキュメントはDockerの基本とヘルスチェックエンドポイントをカバーしていますが、本番環境のDevOpsの詳細は自分で理解する必要があります:

- Kubernetes固有の設定(liveness/readinessプローブ、HPA)
- ゼロダウンタイムデプロイのためのグレースフルシャットダウン
- データベースのバックアップと災害復旧戦略
- ログの集約と集中監視
- 本番環境グレードのセキュリティ強化

コミュニティの[serverpod_vps](https://pub.dev/packages/serverpod_vps)パッケージが役立ち、GitHubディスカッションがいくつかのギャップを埋めますが、包括的な本番運用ガイドは価値があるでしょう。

### 5. パフォーマンスデータ

[ユーザーの証言](https://serverpod.dev)では、Serverpodが本番環境で1日あたり100,000以上のリクエストを処理していることに言及しており、他のフレームワークと比較するコミュニティベンチマークがあります。しかし、包括的なパフォーマンスドキュメントは乏しいです。

- さまざまな負荷下でのレイテンシ分布
- 水平スケーリングパターン
- 負荷下でのメモリフットプリント
- データベース接続プールのベストプラクティス
- キャッシング戦略ガイドライン

これにより、大規模アプリケーションのキャパシティプランニングがより不確実になります。

---

## 驚き: 予想していなかったこと

### 1. ファイルアップロードシステムが実際に良い

ほとんどのファイルアップロード実装は苦痛です。Serverpodはここで私を驚かせました。

```dart
// サーバーエンドポイント
class FileEndpoint extends Endpoint {
  Future getUploadDescription(Session session, String fileName) async {
    return await session.storage.createDirectFileUploadDescription(
      storageId: 'public',
      path: fileName,
    );
  }
}

// クライアントはクラウドストレージに直接アップロード
final uploadDescription = await client.file.getUploadDescription('photo.jpg');
await uploader.upload(uploadDescription, fileBytes);
```

これにより、直接クラウドストレージアップロード用の事前署名されたURLが生成されます。サーバーを通過するファイルデータはありません。S3とGoogle Cloud Storageをサポートしています。

**若いフレームワークでこのレベルの洗練を期待していませんでした。**

<figure>
  <img src={{ sitePrefix }}/assets/img/articles/2026-02-03-Serverpod-for-a-Weekend-The-Good-The-Bad-and-The-Surprising/file-upload-flow-ja.webp>
  <figcaption>図4: 事前署名されたURLによる効率的なファイルアップロード</figcaption>
</figure>

### 2. キャッシングレイヤーが組み込まれている

Redis統合はボルトオンではなく、コアAPIの一部です:

```dart
// ユーザープロファイルをキャッシュ
await session.caches.redis.put(
  'profile:$userId',
  profile,
  lifetime: Duration(minutes: 5),
);

// キャッシュから取得
final cached = await session.caches.redis.get('profile:$userId');
```

自動シリアライズを伴う型安全なキャッシング。キャッシュはセッションスコープで、手動の依存性注入なしにどこでも利用可能です。

### 3. 非同期バックグラウンドジョブのFuture Calls

ユーザー登録後にレスポンスをブロックせずにメールを送信する必要がありました:

```dart
class UserEndpoint extends Endpoint {
  Future register(Session session, User user) async {
    final created = await User.db.insertRow(session, user);

    // Fire and forget - バックグラウンドで実行
    await session.messages.sendFutureCall(
      'email',
      'sendWelcome',
      {'userId': created.id},
      delay: Duration(seconds: 10),
    );

    return created;  // レスポンスはすぐに送信
  }
}
```

これらの「future calls」はPostgreSQLに永続化され、サーバーの再起動を生き延び、正確に1回の実行セマンティクスを提供します。AWS SQS不要、RabbitMQ不要。

**これにより、通常は別のメッセージキューインフラストラクチャを必要とするものが置き換えられました。**

---

## 評決: もう一度使うか?

週末の探索の後、これが私の正直な評価です:

### Serverpodを使用すべき場合:

- チーム全体がDartで作業するFlutter中心のアプリケーションを構築する場合
- フルスタック全体での型安全性が優先事項である場合
- リアルタイム機能が製品のコアである場合(チャット、コラボレーション、ライブ更新)
- エコシステムの成熟度よりも開発速度が重要な場合
- チームが単一言語エコシステムに留まることを好む場合

### 代替案を検討すべき場合:

- サードパーティ統合が広範で特殊な場合
- チームが複数の言語とスタックにまたがる場合(Python MLサービス、Goマイクロサービスなど)
- 本番環境のデプロイに包括的な運用ドキュメントが必要な場合
- レガシーシステムまたは独自APIとの統合が重要な場合
- プロジェクトが大規模な規模で実証されたスケーラビリティパターンを必要とする場合

## 結論

Serverpodの素晴らしい評判は妥当であると感じました。
クライアントからデータベースまでの型安全性を維持しながら、重要な定型文を排除する最新のフルスタックDartフレームワークでした。コード生成はクリーンで、ORMは実用的で、リアルタイム機能はWebSocketの複雑さを管理せずに機能します。

エコシステムはまだ発展途上であり、ドキュメントにはギャップがあるため、多くのエンジニアにとっては確立されたフレームワークよりも多くの統合コードを書くことになる可能性があります。しかし、リアルタイムアプリケーションを構築するFlutterチームであれば、最初の学習曲線を超えると高い生産性と優れた開発者体験を実感することができるはずです。

**私はチームにそれを勧めますか?**
はい、エコシステムの成熟度と統合の制限について明確な期待を持って。

**Node.js + Expressよりもそれを選びますか?**
チームがFlutterを知っている場合? 絶対に。そうでない場合? おそらくそうではありません。


週末でServerpodを試してみた - 良い点、悪い点、そして驚き

# ミニマムな生成AIの対話環境を構築してハルシネーションを軽減させる試み

## はじめに

　近年、ChatGPTをはじめとする生成AIの台頭により、Google検索を使う代わりに生成AIに問い合わせする機会が増えてきました。
しかし、レスポンスは断定口調で返却されるにもかかわらず、実際にはハルシネーションを起こしていた、ということが依然として発生しており、情報の信頼性を担保する難しさを感じています。

　ハルシネーションを軽減するための施策は様々ありますが、今回は異なる言語モデルを用いて、それぞれを回答生成役・検証役に分けロールプレイをさせることによって、質問に対する検証を行うミニマムな対話環境を構築しました。

## 目的
- シンプルかつミニマムに構築する
- 1をキープした上で精度を上げる工夫をする

## ミニマムにやってみる

　筆者は普段Claudeを利用しているため、実装のシンプルさの観点からSonnetとOpusの議論モデルを利用することを検討しました。しかし、単一ベンダのモデル同士では、訓練データや学習手法の傾向が似ているため、同じ誤りを見逃す可能性があります。異なるベンダのモデルを組み合わせることで、片方が持つバイアスや知識の欠落をもう片方が補完できると考え、以下の構成を採用しました。
- 回答生成モデル：claude-sonnet-4-5-20250929
- 検証・修正提案モデル：gemini-2.5-flash-lite

実際にLLMに渡している箇所は以下になります。
```typescript
import Anthropic from '@anthropic-ai/sdk';
import { GoogleGenerativeAI } from '@google/generative-ai';

const anthropic = new Anthropic({ apiKey: ANTHROPIC_API_KEY });
const genAI = new GoogleGenerativeAI(GOOGLE_API_KEY);

async function callClaude(prompt: string, conversationHistory: Message[]): Promise<string> {
  const messages = conversationHistory
    .map(msg => ({
      role: msg.role === 'claude' ? 'assistant' as const : 'user' as const,
      content: msg.content
    }))
    .concat([{ role: 'user' as const, content: prompt }]);

  const response = await anthropic.messages.create({
    model: 'claude-sonnet-4-5-20250929',
    max_tokens: 4096,
    messages
  });

  const content = response.content[0];
  return content.type === 'text' ? content.text : '';
}

async function callGemini(prompt: string, conversationHistory: Message[]): Promise<string> {
  const model = genAI.getGenerativeModel({
    model: 'gemini-2.5-flash-lite',
    generationConfig: {
      maxOutputTokens: 4096
    }
  });

  const history = conversationHistory.map(msg => ({
    role: msg.role === 'gemini' ? 'model' as const : 'user' as const,
    parts: [{ text: msg.content }]
  }));

  const chat = model.startChat({ history });
  const result = await chat.sendMessage(prompt);
  return result.response.text();
}
```


こちらの構成では、ClaudeとGeminiのAPI Keyが必要です。
2025年12月現在では、以下の方法で取得することができます。

[Claude APIキーの取得手順](https://platform.claude.com/docs/ja/get-started)
[Gemini APIキーの取得手順](https://ai.google.dev/gemini-api/docs/api-key?hl=ja)

実際に動作させる際は、`ANTHROPIC_API_KEY`と`GOOGLE_API_KEY`を.envファイルなどに定義し、環境変数から値を取得するようにコードを記述してください。

## 検証

```
質問
firebase経由で10000件のPUSH通知を送信するとき、おおまかに何秒くらいかかるか。手法別に検討してください。
```

```
回答1
最終回答: Firebase経由で10,000件のプッシュ通知を送信する際の所要時間は、手法によって大きく異なります。

1.  **Topic Messaging:**
    *   **所要時間:** 1-3秒（FCMサーバー側での送信リクエスト完了時間）
    *   **特徴:** 全デバイスに同一メッセージを送信する場合に最も高速。ただし、これはサーバー処理時間であり、デバイスへの通知到達時間ではありません。

2.  **HTTP v1 API (並列送信・バッチ処理):**
    *   **所要時間:** 10秒未満（1秒あたり数千件の送信レートが期待できる）
    *   **特徴:** HTTP/2を基盤とし、リクエストごとに複数のメッセージを送信できるバッチ処理により、高いスループットを発揮します。個別のメッセージ送信に最も実用的で高速な方法です。

3.  **Admin SDK (sendAllまたはsendMulticastによるバッチ送信):**
    *   **所要時間:** 20-40秒
    *   **特徴:** 1リクエストあたり最大500件の送信が可能。10,000件の場合は約20バッチ必要となり、この時間が見込まれます。個別のメッセージ送信に実用的です。

4.  **Legacy HTTP API (並列送信):**
    *   **所要時間:** 10-20秒
    *   **特徴:** 同時接続数を管理して送信する場合。HTTP v1 APIほどの効率はありません。

5.  **Legacy HTTP API (単一送信):**
    *   **所要時間:** 500-1000秒 (8-17分)
    *   **特徴:** 1リクエストにつき1通知のため、最も時間がかかります。実用的ではありません。

**注記:**
*   上記所要時間は、ネットワーク遅延、サーバーリソース、FCMのレート制限などの要因によって変動する可能性があります。
*   Topic Messagingの1-3秒は、あくまでFCMサーバーが送信リクエストを処理するまでの時間であり、デバイスへの通知到達までの時間ではありません。
*   HTTP v1 APIは、レガシーAPIよりも効率的で高いスループットが期待できます。
```

```
回答2
最終回答：Firebase経由で10,000件のプッシュ通知を送信する際のおおよその所要時間は、手法によって以下のようになります。

1.  **Admin SDK (Node.js) の `sendAll`**:
    *   **所要時間**: 10-20秒 (5-10並列実行時)、20-80秒 (直列実行時)
    *   **解説**: `sendAll` は最大1000件を1バッチで送信します。10,000件には最低10バッチが必要です。Node.jsの非同期処理 (`Promise.all`) を用いた並列実行により、大幅な時間短縮が可能です。

2.  **HTTP v1 API の `batchSend`**:
    *   **所要時間**: 10-30秒 (並列最適化時)、20-100秒 (直列実行時)
    *   **解説**: `batchSend` エンドポイントは最大500件を1リクエストで送信します。10,000件には最低20リクエストが必要です。Admin SDKと同様に、並列実行で高速化されます。

3.  **Legacy FCM API (非推奨)**:
    *   **所要時間**: 20-40秒
    *   **解説**: 最大1000件を1バッチで送信可能でした。10,000件には10リクエストが必要です。このAPIは2024年6月に廃止されています。

4.  **Cloud Functions for Firebase経由**:
    *   **所要時間**: 60-300秒
    *   **解説**: コールドスタートの遅延、関数の並列実行数、タイムアウト設定に依存します。Admin SDKを直接使用する場合に比べて、関数起動などのオーバーヘッドが追加されるため、一般的に時間がかかります。

**最速の実現方法**:
Admin SDKの `sendAll` またはHTTP v1 APIの `batchSend` を、10-20並列で実行することです。これにより、**10-20秒程度** で完了する可能性があります。

**注意点**:
上記時間はあくまで目安であり、実際の所要時間はネットワーク環境、Firebaseバックエンドの負荷、実行環境のスペック、メッセージの複雑さなど、多くの要因によって変動します。並列度を上げすぎると、コネクション管理のオーバーヘッドやFirebase側のレート制限に抵触する可能性があるため、適切な調整が必要です。
```

## 起きた問題

　検証している中で、以下の問題が発生しました。
- 途中から会話が意味のない文章で構成されるようになり、議論が飽和する
    - お礼を言い合ってお互いを褒め称える事象が観測された

- 検証に用いるGeminiのトークンが枯渇してエラーになってしまった
    - 検証の方がレスポンスサイズが大きいので、その分でリソースを食っているのかも
    - Outputのトークンサイズを調整することで解決

- 同一の質問を複数回投げかけた時、回答に一意性がない
    - ハルシネーションを排除できているなら一意性が発生するはず
    - サンプルとして「firebase経由で10000件のPUSH通知を送信するとき、おおまかに何秒くらいかかるか。手法別に検討してください。」と５回リクエストしたところ、それぞれ想定されるレスポンスタイムが異なった
    - ただし大枠は一致しており、「どの手法が最速か」という点においては一致した

## まとめ

### 異なるモデルの組み合わせの有効性
　サンプルの質問例では、具体的な数値にばらつきはあったものの、「どの手法が最速か」という大枠の結論においては一貫性が見られました。
この結果は、異なる言語モデルのLLMにロールプレイ対話をさせることで、検証役がハルシネーションの発生を抑制している可能性を示唆しています。
が、細かい数値を見るとレスポンスごとに若干の差異があることから、より信頼性を担保するには、さらなるプロンプトの追加や、質問をしたい領域に絞ったRAGの導入などのアプローチが必要そうです。

### 初手レスポンスの重要性
　同一の質問を複数回投げかけた際に回答の一意性が損なわれるという問題は、おそらく初手のレスポンス形式が議論の土台となり、検証の効率と精度を大きく左右していると考えられます。
初手のレスポンスをベースにしてそれ以降の議論が検証されるため、初手のレスポンスの形式をいかに固定するかが鍵になりそうです。


ミニマムな生成AIの対話環境を構築してハルシネーションを軽減させる試み


「動的プライシング（Dynamic Pricing）」は、需要と供給のバランスに応じて価格を自動的に調整することで、売上最大化や在庫最適化を実現する手法です。近年、ECサイトや配車アプリ、ホテル予約サイトなど、現代の多くのサービスでこの動的プライシングが採用されています。

本記事では、価格戦略の最適化に興味のあるエンジニアに向け、動的プライシングの基本的な考え方から、Pythonを使った実装方法まで、実際に動かしてみた結果も含めて紹介します。

# 動的プライシングとは

動的プライシングとは、市場の状況（需要、在庫、競合価格、時間帯など）に応じて、商品やサービスの価格をリアルタイムで変更する価格戦略です。

従来の固定価格では、需要が高い時期に在庫が余ってしまったり、需要が低い時期に価格が高すぎて売れなかったりする問題がありました。動的プライシングを導入することで、これらの課題を解決できます。

## 動的プライシングが使われる場面

- **ECサイト**: 在庫状況や需要予測に基づいて価格を調整
- **配車アプリ（Uber、Lyftなど）**: 需要が高い時間帯や地域で価格を上昇させるサージプライシング
- **ホテル・航空券**: 予約状況や季節に応じて価格を変動
- **コンサートチケット**: 人気公演では価格を上昇させ、空席が多い公演では割引

## 動的プライシングの基本的な考え方

動的プライシングでは、複数の要素を組み合わせて最適な価格を決定します。ここでは主要な変化要素を紹介します。

![動的プライシングの変化要素]({{ sitePrefix }}/assets/img/articles/2026-01-27-dynamic-pricing/pricing_factors.png)

# 動的プライシングの変化要素

## 価格弾力性

価格弾力性とは、価格の変化に対する需要の変化の度合いを示す指標です。価格を1%上げたときに需要が何%減るかを表します。

- **弾力性が高い（-2.0など）**: 価格が上がると需要が大きく減る
- **弾力性が低い（-0.5など）**: 価格が上がっても需要はあまり減らない

## 曜日効果とは

需要は曜日によって系統的に変動します（例: 週末は需要が高くなりやすい）。この「曜日効果」をモデルに取り込むことで、より正確な需要予測が可能になります。

## 競合価格: 競合他社の価格を参考に調整

競合他社の価格を参考に自社の価格を調整します。市場の価格水準を把握し、競争力のある価格設定を行うことが重要です。

## ランダムノイズとは

実データには、天候や突発的なイベント、計測誤差など説明しきれない揺らぎ（ノイズ）が含まれます。シミュレーション時にランダムノイズを入れることで、より現実的な挙動を再現できます。

![ランダムノイズの影響]({{ sitePrefix }}/assets/img/articles/2026-01-27-dynamic-pricing/random_noise.png)

# 需要予測モデルの精度の見方

モデルの精度を評価する際は、複数の指標を併用します。

- **R²（決定係数）**: 0〜1で説明力を示す指標。高いほど良い
- **MAE / RMSE**: 誤差の絶対量を評価。小さいほど良い

学習データと検証データの両方で評価し、過学習の有無を確認することが重要です。

# 動的プライシングの実装

それでは、実際に動的プライシングを実装してみます。今回は、シンプルな需要予測ベースの動的プライシングシステムを構築します。

最終的に、以下のような価格と需要・収益の関係を可視化し、収益を最大化する最適価格を導き出します。

![価格と需要・収益の関係]({{ sitePrefix }}/assets/img/articles/2026-01-27-dynamic-pricing/pricing_analysis.png)

この結果を得るために、以下のステップで実装を進めていきます。

1. **データの準備**: 過去の販売データをシミュレート
2. **需要予測モデルの構築**: 価格と需要の関係を学習
3. **最適価格の計算**: 収益を最大化する価格を探索
4. **動的な価格調整**: 在庫や時間帯を考慮した調整

## データの準備

まず、過去の販売データをシミュレートします。実際のプロジェクトでは、既存の販売データを使用します。

```python
import pandas as pd
import numpy as np
from datetime import datetime, timedelta
import matplotlib.pyplot as plt
import warnings
warnings.filterwarnings('ignore')

# 過去90日間の販売データをシミュレート
np.random.seed(42)
dates = pd.date_range(start='2024-01-01', periods=90, freq='D')

# 需要データ（価格が低いほど需要が高い）
base_demand = 100
price_elasticity = -1.5  # 価格弾力性

data = []
for date in dates:
    # 曜日効果（週末は需要が高い）
    weekday_factor = 1.2 if date.weekday() >= 5 else 1.0

    # ランダムな価格（1000円〜3000円）
    price = np.random.uniform(1000, 3000)

    # 需要 = ベース需要 × 価格弾力性 × 曜日効果 × ランダムノイズ
    demand = base_demand * (price / 2000) ** price_elasticity * weekday_factor * np.random.uniform(0.8, 1.2)
    demand = max(0, int(demand))  # 需要は0以上

    data.append({
        'date': date,
        'price': price,
        'demand': demand,
        'revenue': price * demand
    })

historical_data = pd.DataFrame(data)
print(f"データ数: {len(historical_data)}日分")
print(historical_data.head())
```

## 需要予測モデルの構築

過去のデータから、価格と需要の関係を学習します。モデルの精度を適切に評価するため、データを学習用と検証用に分割します。

```python
from sklearn.linear_model import LinearRegression
from sklearn.preprocessing import PolynomialFeatures
from sklearn.pipeline import Pipeline
from sklearn.model_selection import train_test_split

# 価格と需要の関係を学習
X = historical_data[['price']].values
y = historical_data['demand'].values

# データを学習用（80%）と検証用（20%）に分割
X_train, X_val, y_train, y_val = train_test_split(X, y, test_size=0.2, random_state=42)

# 多項式特徴量を使用（価格と需要の関係は非線形の可能性があるため）
model = Pipeline([
    ('poly', PolynomialFeatures(degree=2)),
    ('linear', LinearRegression())
])

# 学習データでモデルを学習
model.fit(X_train, y_train)

# 学習データと検証データの両方で予測精度を確認
train_score = model.score(X_train, y_train)
val_score = model.score(X_val, y_val)

print(f"学習データでの予測精度 (R²): {train_score:.3f}")
print(f"検証データでの予測精度 (R²): {val_score:.3f}")

# 過学習のチェック
if train_score - val_score > 0.1:
    print("警告: 学習データと検証データの精度に大きな差があります。過学習の可能性があります。")
else:
    print("学習データと検証データの精度が近いため、モデルは適切に汎化できています。")
```

## 最適価格の計算

需要予測モデルを使って、収益を最大化する価格を計算します。エラーハンドリングを追加して、予測値が負の値になった場合や、価格範囲が無効な場合に対応します。

```python
def calculate_optimal_price(model, price_range=(500, 4000), step=10):
    """
    収益を最大化する価格を計算

    Args:
        model: 需要予測モデル
        price_range: 価格の探索範囲（最小値, 最大値）
        step: 価格の刻み幅

    Returns:
        最適価格とその時の予測需要、予測収益

    Raises:
        ValueError: 価格範囲が無効な場合
    """
    try:
        min_price, max_price = price_range
        if min_price >= max_price or min_price < 0:
            raise ValueError("価格範囲が無効です。最小価格は最大価格より小さく、0以上である必要があります。")

        prices = np.arange(min_price, max_price, step)
        if len(prices) == 0:
            raise ValueError("価格の探索範囲が狭すぎます。")

        optimal_price = None
        max_revenue = 0
        optimal_demand = 0

        for price in prices:
            try:
                predicted_demand = model.predict([[price]])[0]
                predicted_demand = max(0, predicted_demand)  # 需要は0以上
                revenue = price * predicted_demand

                if revenue > max_revenue:
                    max_revenue = revenue
                    optimal_price = price
                    optimal_demand = predicted_demand
            except Exception as e:
                print(f"価格 {price} での予測中にエラーが発生しました: {e}")
                continue

        if optimal_price is None:
            raise ValueError("最適価格が見つかりませんでした。")

        return optimal_price, optimal_demand, max_revenue

    except Exception as e:
        print(f"エラーが発生しました: {e}")
        raise

# 最適価格を計算
try:
    optimal_price, optimal_demand, optimal_revenue = calculate_optimal_price(model)
    print(f"最適価格: {optimal_price:.0f}円")
    print(f"予測需要: {optimal_demand:.1f}個")
    print(f"予測収益: {optimal_revenue:.0f}円")
except Exception as e:
    print(f"最適価格の計算に失敗しました: {e}")
```

## 在庫を考慮した動的プライシング

在庫状況も考慮して価格を調整します。エラーハンドリングを追加して、在庫数が負の値や無効な値の場合に対応します。

```python
def dynamic_pricing_with_inventory(model, current_inventory, target_inventory=50, base_price=None):
    """
    在庫を考慮した動的プライシング

    Args:
        model: 需要予測モデル
        current_inventory: 現在の在庫数（0以上）
        target_inventory: 目標在庫数（0より大きい値）
        base_price: ベース価格（Noneの場合は最適価格を計算）

    Returns:
        調整後の価格

    Raises:
        ValueError: 在庫数が無効な場合
    """
    try:
        if current_inventory < 0:
            raise ValueError("在庫数は0以上である必要があります。")
        if target_inventory <= 0:
            raise ValueError("目標在庫数は0より大きい値である必要があります。")

        if base_price is None:
            base_price, _, _ = calculate_optimal_price(model)

        # 在庫調整係数
        inventory_ratio = current_inventory / target_inventory

        if inventory_ratio > 1.5:  # 在庫が目標の1.5倍以上
            # 在庫が多いので価格を下げて需要を喚起
            adjustment_factor = 0.9
        elif inventory_ratio < 0.5:  # 在庫が目標の半分以下
            # 在庫が少ないので価格を上げる
            adjustment_factor = 1.1
        else:
            adjustment_factor = 1.0

        adjusted_price = base_price * adjustment_factor
        return adjusted_price

    except Exception as e:
        print(f"エラーが発生しました: {e}")
        raise

# 在庫が少ない場合の価格調整
try:
    low_inventory_price = dynamic_pricing_with_inventory(model, current_inventory=10, target_inventory=50)
    print(f"在庫が少ない場合の価格: {low_inventory_price:.0f}円")
except Exception as e:
    print(f"価格調整に失敗しました: {e}")

# 在庫が多い場合の価格調整
try:
    high_inventory_price = dynamic_pricing_with_inventory(model, current_inventory=100, target_inventory=50)
    print(f"在庫が多い場合の価格: {high_inventory_price:.0f}円")
except Exception as e:
    print(f"価格調整に失敗しました: {e}")
```

## 時間帯を考慮した動的プライシング

時間帯や曜日によって需要が変動する場合の価格調整も実装します。エラーハンドリングを追加して、日時が無効な場合に対応します。

```python
def dynamic_pricing_with_time(model, current_time, base_price=None):
    """
    時間帯を考慮した動的プライシング

    Args:
        model: 需要予測モデル
        current_time: 現在の日時（datetimeオブジェクト）
        base_price: ベース価格

    Returns:
        調整後の価格

    Raises:
        ValueError: 日時が無効な場合
    """
    try:
        if not isinstance(current_time, datetime):
            raise ValueError("current_timeはdatetimeオブジェクトである必要があります。")

        if base_price is None:
            base_price, _, _ = calculate_optimal_price(model)

        # 曜日効果
        if current_time.weekday() >= 5:  # 週末
            time_factor = 1.1  # 週末は需要が高いので価格を上げる
        else:
            time_factor = 1.0

        # 時間帯効果（例: 夜間は需要が低い）
        hour = current_time.hour
        if 9 <= hour <= 18:  # 営業時間
            hour_factor = 1.0
        else:
            hour_factor = 0.95  # 営業時間外は価格を少し下げる

        adjusted_price = base_price * time_factor * hour_factor
        return adjusted_price

    except Exception as e:
        print(f"エラーが発生しました: {e}")
        raise

# 週末の営業時間の価格
try:
    weekend_price = dynamic_pricing_with_time(model, datetime(2024, 1, 6, 14, 0, 0))
    print(f"週末の営業時間の価格: {weekend_price:.0f}円")
except Exception as e:
    print(f"価格調整に失敗しました: {e}")

# 平日の夜間の価格
try:
    weekday_night_price = dynamic_pricing_with_time(model, datetime(2024, 1, 3, 20, 0, 0))
    print(f"平日の夜間の価格: {weekday_night_price:.0f}円")
except Exception as e:
    print(f"価格調整に失敗しました: {e}")
```

## 可視化の改善

価格と需要、収益の関係を可視化します。さらに、残差プロットを追加して、モデルの予測精度を視覚的に確認できるようにします。

```python
def visualize_pricing(model, optimal_price, X_train, y_train, X_val, y_val):
    """
    価格と需要、収益の関係、および残差プロットを可視化

    Args:
        model: 需要予測モデル
        optimal_price: 最適価格
        X_train: 学習データの特徴量
        y_train: 学習データの目的変数
        X_val: 検証データの特徴量
        y_val: 検証データの目的変数
    """
    # 価格と需要の関係を可視化
    prices = np.arange(500, 4000, 50)
    demands = [max(0, model.predict([[p]])[0]) for p in prices]
    revenues = [p * d for p, d in zip(prices, demands)]

    fig = plt.figure(figsize=(16, 10))

    # 1. 価格と需要の関係
    ax1 = plt.subplot(2, 3, 1)
    ax1.plot(prices, demands, label='Predicted Demand', linewidth=2)
    ax1.axvline(optimal_price, color='r', linestyle='--', label=f'Optimal Price ({optimal_price:.0f} yen)')
    ax1.set_xlabel('Price (yen)')
    ax1.set_ylabel('Demand (units)')
    ax1.set_title('Price vs Demand')
    ax1.legend()
    ax1.grid(True, alpha=0.3)

    # 2. 価格と収益の関係
    ax2 = plt.subplot(2, 3, 2)
    ax2.plot(prices, revenues, label='Predicted Revenue', linewidth=2, color='green')
    ax2.axvline(optimal_price, color='r', linestyle='--', label=f'Optimal Price ({optimal_price:.0f} yen)')
    ax2.set_xlabel('Price (yen)')
    ax2.set_ylabel('Revenue (yen)')
    ax2.set_title('Price vs Revenue')
    ax2.legend()
    ax2.grid(True, alpha=0.3)

    # 3. 学習データの残差プロット
    ax3 = plt.subplot(2, 3, 3)
    train_pred = model.predict(X_train)
    train_residuals = y_train - train_pred
    ax3.scatter(train_pred, train_residuals, alpha=0.5, color='blue')
    ax3.axhline(y=0, color='r', linestyle='--', linewidth=2)
    ax3.set_xlabel('Predicted')
    ax3.set_ylabel('Residuals')
    ax3.set_title('Training Data Residuals')
    ax3.grid(True, alpha=0.3)

    # 4. 検証データの残差プロット
    ax4 = plt.subplot(2, 3, 4)
    val_pred = model.predict(X_val)
    val_residuals = y_val - val_pred
    ax4.scatter(val_pred, val_residuals, alpha=0.5, color='orange')
    ax4.axhline(y=0, color='r', linestyle='--', linewidth=2)
    ax4.set_xlabel('Predicted')
    ax4.set_ylabel('Residuals')
    ax4.set_title('Validation Data Residuals')
    ax4.grid(True, alpha=0.3)

    # 5. 学習データの予測値 vs 実際の値
    ax5 = plt.subplot(2, 3, 5)
    ax5.scatter(y_train, train_pred, alpha=0.5, color='blue')
    min_val = min(min(y_train), min(train_pred))
    max_val = max(max(y_train), max(train_pred))
    ax5.plot([min_val, max_val], [min_val, max_val], 'r--', linewidth=2, label='Perfect Prediction')
    ax5.set_xlabel('Actual')
    ax5.set_ylabel('Predicted')
    ax5.set_title('Training Data: Actual vs Predicted')
    ax5.legend()
    ax5.grid(True, alpha=0.3)

    # 6. 検証データの予測値 vs 実際の値
    ax6 = plt.subplot(2, 3, 6)
    ax6.scatter(y_val, val_pred, alpha=0.5, color='orange')
    min_val = min(min(y_val), min(val_pred))
    max_val = max(max(y_val), max(val_pred))
    ax6.plot([min_val, max_val], [min_val, max_val], 'r--', linewidth=2, label='Perfect Prediction')
    ax6.set_xlabel('Actual')
    ax6.set_ylabel('Predicted')
    ax6.set_title('Validation Data: Actual vs Predicted')
    ax6.legend()
    ax6.grid(True, alpha=0.3)

    plt.tight_layout()
    plt.savefig('pricing_analysis_improved.png', dpi=150, bbox_inches='tight')
    print("可視化結果を 'pricing_analysis_improved.png' に保存しました。")
    plt.show()

# 可視化を実行
visualize_pricing(model, optimal_price, X_train, y_train, X_val, y_val)
```

# やってみた結果

実際に上記のコードを実行してみた結果を紹介します。

## 需要予測モデルの精度

過去90日間のデータを学習用（72日分）と検証用（18日分）に分割し、モデルの精度を評価しました。

- 学習データでのR²: 0.847
- 検証データでのR²: 0.812

学習データと検証データの精度差が小さく、モデルが適切に汎化できていることが確認できました。

## 最適価格の計算結果

シミュレーション結果では、最適価格は2,010円でした。この価格では、予測需要は約149.8個、予測収益は約301,098円となりました。

![価格と需要・収益の関係]({{ sitePrefix }}/assets/img/articles/2026-01-27-dynamic-pricing/pricing_analysis.png)

## 在庫・時間帯を考慮した価格調整の効果

| 条件 | 調整後の価格 |
|------|------------|
| 在庫が少ない場合（10個） | 2,211円 |
| 在庫が多い場合（100個） | 1,809円 |
| 週末の営業時間 | 2,211円 |
| 平日の夜間 | 2,100円 |

# まとめ

本記事では、動的プライシングの基本的な考え方から、Pythonを使ったシンプルな実装方法まで紹介しました。

- 動的プライシングは、需要・在庫・競合価格・時間帯などを考慮して価格を動的に調整する手法
- 価格弾力性、曜日効果、ランダムノイズなどの要素を組み合わせてモデルを構築
- シンプルな需要予測モデルでも、収益最大化や在庫最適化に活用可能


動的プライシングで実現する最適な価格戦略


この記事は、　[開発生産性コミュニティD-Plus🐬 Advent Calendar 2025](https://qiita.com/advent-calendar/2025/d-plus) 15日目の記事です。
14日目の記事は、あれ？いない？？？

D-Plusには、 今年5月に大阪で [Engineering managerのタスク管理](https://speakerdeck.com/kuchitama/task-management-of-engineering-manager) という発表で登壇させていただきました。
この１回しか参加していないのですが、温かみのあるコミュニティだったので、家事育児と折り合いがついたら、また参加したいなと思っています。


## はじめに

先日、モンスターラボでミドルマネージャー向けの研修を受けてきました。
研修の中で、自分のピープルマネジメントの経験を振り返る機会があったのですが、そこで衝撃的な気づきがありました。

**自分がピープルマネジメントのつもりでやっていたことが、実はパフォーマンスマネジメントだった**ということです。

この記事では、その気づきと研修で学んだことを共有したいと思います。

## モンスターラボのマネジメント4領域

テック界隈でマネジメントというと、広木大地さんの「[4つのP](https://levtech.jp/media/article/column/detail_661/)」が有名です。エンジニアリングマネージャーの活動領域を、ピープル・プロジェクト・プロダクト・プラットフォーム（テクノロジー）の4つに整理したフレームワークですね。

モンスターラボでは、エンジニアリングに限らずマネージャーの役割を4つの領域に分けて定義しています。

1. **ピープルマネジメント** - メンバーの成長を支援する
2. **パフォーマンスマネジメント** - 成果・生産性を管理する
3. **ストラテジーマネジメント** - 戦略を立案・実行する
4. **フィロソフィーマネジメント** - 組織の文化・価値観を浸透させる

（余談ですが、ストラテジーだけ言い換えられたら、こっちも4つのPになるのに...と思ったりしました。Portfolio Managementとかどうだろうか？）

## これまでの自分のピープルマネジメント（だと思っていたもの）

エンジニアリングマネージャーとして、自分なりにメンバーと向き合ってきたつもりでした。

- 1on1を定期的に実施
- 案件の状況をヒアリング
- 案件の課題を確認して、解決策を一緒に考える
- メンバーをぼっちにしないことを意識

以前、[人と組織の"エン"を結ぶ - 受託開発EMの価値創出と潜在力の引き出し](https://speakerdeck.com/kuchitama/ren-tozu-zhi-no-en-wojie-bu-shou-tuo-kai-fa-emnojia-zhi-chuang-chu-toqian-zai-li-noyin-kichu-si)という発表でも、エンゲージメント・エンパワーメント・エンカレッジメントという3つの「エン」を意識したチームマネジメントについて話しました。メンバーの潜在能力を引き出したり、不安を解消して勇気づけたり、それなりにピープルマネジメントできているつもりでいました。

<iframe class="speakerdeck-iframe" frameborder="0" src="https://speakerdeck.com/player/983d4dfdffe04b15bc7bf7e72ca49dbd" title="人と組織の&quot;エン&quot;を結ぶ - 受託開発EMの価値創出と潜在力の引き出し" allowfullscreen="true" style="border: 0px; background: padding-box padding-box rgba(0, 0, 0, 0.1); margin: 0px; padding: 0px; border-radius: 6px; box-shadow: rgba(0, 0, 0, 0.2) 0px 5px 40px; width: 100%; height: auto; aspect-ratio: 560 / 315;" data-ratio="1.7777777777777777"></iframe>


でも、研修を通じて振り返ってみると、 **自分が向き合っていたのはメンバーではなく、メンバーの「仕事」だった** ことに気づきました。

チームメンバーの案件の状況や課題にフォーカスしていたので、結果的に生産性やパフォーマンスを上げることに注力していたのです。つまり、 **パフォーマンスマネジメントをしていた** というわけです。


## 研修で学んだ本当のピープルマネジメント

ピープルマネジメントとは、 **メンバーの成長を支援すること** です。そのためには、メンバーの **Will（やりたいこと）・Can（できること）・Must（やるべきこと）** を理解することが重要です。


<figure>
  <img src="{{ sitePrefix }}/assets/img/articles/2025-12-15-PeopleManagementTrainingNotice/will-can-must.webp" alt="Will Can Mustの図">
</figure>


研修では、一緒に参加した別チームのマネージャーがメンバー役のWill・Can・Mustを見事に引き出していました。その方はブランディングデザインに強い人だったのですが、確かにブランディングって、強み・弱みなどを引き出してまとめていく手法です。
そういうスキルがピープルマネジメントにも活きるのかと、なるほどと思いました。

ちゃんとメンバーと向き合い、Will・Can・Mustを引き出し、明確にすることで、メンバーの成長を支援できるのだと学びました。
と、同時に私はあまりメンバーの内面に踏み込むのが苦手なんだなということにも気づきました。

研修後に、思わずブランディングデザインに関する書籍を購入していました。

何かヒントを得て、ピープルマネジメントについて、「苦手でやれていない」から「苦手だけどある程度できる」ぐらいのレベルまで引き上げたいなと思っています。


## まとめ

というわけで、マネージャーとしてピープルマネジメントに力を注いでいたと思っていたら、実は生産性 ≒ パフォーマンスに力を向けていた話でした。

もちろん、パフォーマンスマネジメントも大事な仕事です。でも、メンバーの成長を支援するという視点が欠けていたことに気づけたのは大きな収穫でした。

また、研修の中で、別のマネージャーは、自分がマネージャーとして完璧でなくても、他のマネージャーの力を借りてメンバーの力を引き出せれば良いという趣旨の経験談を話してくれました。
ちょうど、自分のピープルマネジメントの課題に気づいたタイミングだったので、とても励みになりました。

これからは、1on1の中でもメンバー自身のWill・Can・Mustにもっとフォーカスして、本当の意味でのピープルマネジメントを実践していきたいと思います。

## 最後に

こんなまだまだ未熟なEMですが、モンスターラボでは一緒に成長していける仲間を集しています。

特に、社内で↓のような新チーム立ち上げの取り組みをしています。

[AI時代の新しいエンジニアの形 - モンスターラボにおけるフルサイクルエンジニアとは](https://engineering.monstar-lab.com/jp/post/2025/10/07/FullCycle-Team-is-launched/)

「Turn Vision into Reality」 の精神で、一緒にフルサイクルエンジニアを目指す仲間を募集しているので、ご興味ある方はぜひご応募ください。

[株式会社モンスターラボ の求人|FullCycleエンジニア](https://hrmos.co/pages/monstar-lab-recruit/jobs/0002501)


俺のピープルマネジメントはピープルマネジメントじゃなかった


大規模なモバイルアプリケーション向けのヘッドレスCMSの実装を任されたとき、私は慣れない領域に足を踏み入れることになりました。フロントエンド開発者として、バックエンド開発はデータベース設計、API実装、認証システム、デプロイインフラストラクチャなど、困難な要素の組み合わせのように感じられました。

Payloadは、既存のTypeScriptスキルを活用しながら、必要なバックエンド機能を提供するアプローチを提供しました。本番環境へのデプロイと、複数回の高トラフィック期間を通じたシステムの保守を経て、この記事ではPayloadでバックエンドシステムを構築する際の実践的な現実を振り返ります。

## Payloadとは？

<figure>
  <img src="{{ sitePrefix }}/assets/img/articles/2025-11-13-Frontend-Dev-Experience-with-PayloadCMS/payloadcms-wordmark.svg">
</figure>

[Payload](https://payloadcms.com/docs/getting-started/what-is-payload)は、TypeScriptとNext.jsで構築されたオープンソースのヘッドレスコンテンツ管理システム（CMS）です。WordPressやDrupalなどの従来のCMSプラットフォームとは異なり、ヘッドレスCMSはAPIを介してコンテンツを配信するため、あらゆるフロントエンドスタックがコンテンツを利用できます。

Payloadの主要な特徴は、コードファーストの哲学です。ContentfulやStrapiなどの他のヘッドレスCMSが管理画面を通じてスキーマを定義する必要があるのに対し、PayloadではすべてをTypeScriptで定義できます。このアプローチは、モダンなJavaScriptフレームワークに慣れていて、同じ開発体験をバックエンドのインフラにも拡張したい開発者にアピールします。

Next.jsの上に構築されたPayloadは、フレームワークのサーバーサイドレンダリングとAPIルーティングを活用しながら、独自のデータベース抽象化レイヤーも提供します。PostgreSQLとMongoDBの両方をサポートし、RESTとGraphQL APIを提供し、AWS Lambdaなどのサーバーレスプラットフォームや従来のサーバーにデプロイできます。

バックエンド作業に取り組むフロントエンド開発者にとって、これは慣れ親しんだTypeScript環境内で、完全に新しいバックエンドスタックを学ぶ必要なく、コンテンツの管理、データ構造の定義、APIの公開をすべて行えることを意味します。

## コードとしての設定

Payloadは、GUIの設定やSQL文ではなく、コードとしてスキーマ定義を管理することで差別化を図っています。Payloadでは、`collections`はTypeScriptの設定オブジェクトであり、強く型付けされた`fields`を持ち、自動的にデータベーステーブルのカラムに変換されます。

```ts
export const Articles: CollectionConfig = {
  slug: "articles",
  fields: [
    {
      name: "title",
      type: "text",
      required: true,
    },
    {
      name: "body",
      type: "richtext",
    },
    {
      name: "category",
      type: "relationship",
      relationTo: "categories",
    },
  ],
};
```

フロントエンド開発者の視点から見ると、この構文は馴染みやすく、データベーススキーマを定義するというよりも、コンポーネントのプロップスを定義するような感覚です。さらに、コードがバージョン管理システム内に存在するため、変更を追跡し、共同でレビューし、必要に応じてロールバックできます。

上記のコレクションは、自動的にいくつかの成果物を生成します：

### データベーススキーマ

フィールド設定に基づいてデータベーステーブルが作成されます。上記のコレクションは、以下のカラムを持つ`articles`テーブルを生成します：

<figure>
  <img src="{{ sitePrefix }}/assets/img/articles/2025-11-13-Frontend-Dev-Experience-with-PayloadCMS/payloadcms-collection-erd.webp">
</figure>

### REST APIエンドポイント

すべてのコレクションは、追加の設定なしで完全なREST APIも受け取ります：

```
GET    /api/articles          # ページネーション付きでリストを取得
GET    /api/articles/:id      # 単一のエンティティを取得
POST   /api/articles          # 新規作成
PATCH  /api/articles/:id      # 既存のものを更新
DELETE /api/articles/:id      # エンティティを削除
```

フィルタリングとソートを簡単に行うためのデフォルトのクエリパラメータも提供されています。例えば、タイトルに「frontend」を含む最初の10件の記事を作成日順に取得するには：

```
/api/articles?where[title][contains]=frontend&sort=createdAt&limit=10
```

### TypeScript型定義

コレクション設定に基づいて型インターフェースも生成され、モダンなIDEで型チェックと自動補完のサポートを提供します。

```ts
export interface Articles {
  id: number;
  title: string;
  body?: {
    root: {
      type: string;
      children: {
        type: string;
        version: number;
        [k: string]: unknown;
      }[];
      direction: ("ltr" | "rtl") | null;
      format: "left" | "start" | "center" | "right" | "end" | "justify" | "";
      indent: number;
      version: number;
    };
    [k: string]: unknown;
  } | null;
  category?: {
    relationTo: "category";
    value: number | Category;
  } | null;
  createdAt?: string | null;
  updatedAt?: string | null;
}
```

この自動的な成果物生成により、かなりの量のボイラープレートコードとメンテナンスが不要になり、バックエンド開発がより速く、より信頼性の高いものになります。

## バックエンドの学習曲線を低減

Payloadのいくつかの機能により、フロントエンド開発者にとってバックエンド開発がよりアプローチしやすくなります：

### 組み込み管理画面

Payloadには、開発中に即座のフィードバックを得るためにNext.jsのHot Module Replacement（ホットモジュール置換）を活用する、事前構築された自動生成管理画面が含まれています。本番環境対応の管理画面は、TypeScriptスキーマの変更を自動的に反映し、複雑なUI要件を持つプロジェクトのために高度にカスタマイズ可能です。

<figure>
  <img src="{{ sitePrefix }}/assets/img/articles/2025-11-13-Frontend-Dev-Experience-with-PayloadCMS/payloadcms-dashboard.webp">
  <figcaption>Payloadのデフォルト管理画面ダッシュボード</figcaption>
</figure>

<figure>
  <img src="{{ sitePrefix }}/assets/img/articles/2025-11-13-Frontend-Dev-Experience-with-PayloadCMS/payloadcms-create-new-article.webp">
  <figcaption>「新規記事作成」ページ</figcaption>
</figure>

### 多言語対応

多言語のサポートは、複雑なセットアップではなく、設定を通じて処理されます。フィールドを`localized`としてマークでき、コンテンツ編集者が管理画面で直接翻訳を管理できるようになります。システムは、ロケール固有のクエリを自動的に処理し、翻訳が欠落している場合のフォールバック動作を提供します。

```ts
export const Articles: CollectionConfig = {
  slug: "articles",
  fields: [
    {
      name: "title",
      type: "text",
      localized: true, // ロケールごとのコンテンツを有効化
    },
  ],
};
```

APIリクエストは、クエリパラメータを介してロケールの設定を指定でき、Payloadは適切なコンテンツバージョンを取得するために基礎となるデータベースクエリを処理します。例えば、`/api/articles?locale=ja&fallback-locale=en`をリクエストすると、利用可能な場合は日本語のコンテンツを返し、それ以外の場合は英語にフォールバックします。

### データリレーションシップモデリング

データ構造間の関係を作成するには、上記のサンプルコレクションで示されているように、`relationship`フィールドタイプを使用します。Payloadは基礎となるデータベース結合を処理し、関連コンテンツを選択するための機能的な管理UIを提供します。

### フック

コレクションレベルおよびフィールドレベルのフック（`beforeRead`、`afterRead`、`beforeChange`、`afterChange`など）は、Reactのライフサイクルメソッドを模倣しており、比較的簡単にビジネスロジックを実装できます。

```ts
export const Articles: CollectionConfig = {
  slug: "articles",
  fields: [
    {
      name: "title",
      type: "text",
      required: true,
    },
    {
      name: "slug",
      type: "text",
    },
    //...
  ],
  hooks: {
    beforeChange: [
      ({ data }) => {
        data.slug = data.title.toLowerCase().replace(/\s+/g, "-");
      },
    ],
  },
};
```

### カスタムエンドポイント

標準的なCRUD操作を超えて、より複雑なワークフローを処理するためにカスタムエンドポイントを定義できます。

```ts
export const Articles: CollectionConfig = {
  slug: "articles",
  fields: [
    /* ... */
  ],
  endpoints: [
    {
      path: "/:id/summary", // エンドポイントを定義
      method: "get", // メソッドを定義
      handler: async req => {
        if (!req.user) {
          return Response.json({ error: "Unauthorized" }, { status: 401 });
        }
        const article = await req.payload.findByID({
          collection: "articles",
          id: req.routeParams.id as string,
        });

        // 複雑な操作を実行、外部APIを呼び出すなど
        const summary = await generateAISummary(article.body);

        return Response.json({ success: true, summary });
      },
    },
  ],
};
```

### アクセス制御

認可は、コレクションレベルとフィールドレベルの両方で強制でき、UIの可視性に依存するのではなく、データレイヤーでセキュリティが一貫して処理されることを保証します。

```ts
export const Articles: CollectionConfig = {
  slug: "articles",
  access: {
    // 誰でも「published」の記事を読むことを許可
    read: ({ req: { user } }) => {
      if (user) return true;
      return { status: { equals: "published" } };
    },
    // 認証済みユーザーのみが記事を作成、更新、削除できる
    create: ({ req: { user } }) => Boolean(user),
    update: ({ req: { user } }) => Boolean(user),
    delete: ({ req: { user } }) => Boolean(user),
  },
};
```

この宣言的なアプローチにより、すべてのルートハンドラーで手動で権限をチェックするよりも、アクセス制御がシンプルでメンテナンスしやすくなります。セキュリティはすべてのリクエストに対して一貫して強制され、データレイヤーが保護されていることを確信できます。

## 注意点と課題

Payloadは魅力的な開発者体験を提供しますが、本番環境への移行では考慮する価値のあるいくつかの課題が浮上します。

### データベースとスキーマ管理

開発中は、TypeScriptからデータベースへのワークフローがシームレスに感じられますが、PostgreSQLを使用する本番環境では、明示的なマイグレーション管理が必要になります。Payloadはマイグレーションスクリプトを提供しますが、すべてのスキーマ変更に対して`payload migrate:create`を実行し、環境全体でマイグレーションの順序を慎重に管理する必要があります。これにより、複数の開発者が同時にスキーマを更新している場合、調整のオーバーヘッドが追加される可能性があります。

### サーバーレスデプロイメントの複雑さ

Payloadをサーバーレス関数としてデプロイすることは、予想以上に複雑になる可能性があります。コールドスタートはパフォーマンスに影響を与える可能性がありますが、実稼働サービスでは、一般的なトラフィックパターンと適切なメモリ割り当てにより、通常は問題になりません。さらに、Payloadはサーバーレス環境でスケジュールされたタスクやバッチ処理をネイティブにサポートしていないため、スケジュールされた公開などの機能には、Lambda関数とEventBridgeスケジューリングを使用した別個のインフラストラクチャの構築が必要です。

### ReactとNext.jsの統合

PayloadはApp Routerを使用したNext.jsの上に構築されているため、React Server Componentの課題も継承します。カスタム管理画面コンポーネントは、サーバー/クライアント境界を慎重にナビゲートする必要があり、ブラウザAPIとやり取りするカスタムフィールドを構築する際にハイドレーションの不一致が発生する可能性があります。以前にNext.jsのハイドレーションエラーに苦しんだことがある場合は、ここでも同じ問題に遭遇することが予想されます。

## まとめ

フロントエンド開発者として、Payloadを使った作業は、まったく新しいバックエンドフレームワークを学ぶというよりも、TypeScriptのツールセットを拡張するような感覚でした。その馴染みやすいパターン、自動API生成、強力なスキーマ型付けにより、バックエンド開発は予想以上にアプローチしやすくなりました。

まだ課題はあります — マイグレーションの管理、サーバーレスデプロイメントの最適化、基礎となるデータベース構造の理解には意図的な努力が必要です。しかし、Payloadは、既存のTypeScript経験をバックエンドシステムに適用することで、フロントエンドとバックエンド開発の間のギャップを狭めます。Payloadがすべてをカバーするわけではありません — 高度なデータベース最適化、分散システム、インフラストラクチャ管理には専門的な学習が必要です。しかし、実用的なエントリーポイントを提供します。

Reactとモダンなビルドパイプラインに慣れている開発者にとって、慣れ親しんだ領域を離れることなくバックエンドシステムを構築できることを証明しています。

---

*Payload、Payloadのデザイン、および関連するマーク、デザイン、ロゴは、米国およびその他の国におけるPayload CMS, Inc.の商標または登録商標です。*


フロントエンド開発者としてバックエンドを構築する：Payload CMSでの経験


## はじめに

株式会社モンスターラボは、**AI & デジタルパートナー**として企業のデジタル変革を支援する新たなステージに進化しています。

その取り組みをTech領域から推進する存在として、私たちはフルサイクルエンジニアチームを立ち上げ、その新しいチームの一員として活躍していただけるメンバーの募集を開始しました。

この記事では、モンスターラボにおけるフルサイクルエンジニアの役割、働き方、求める人物像について、モンスターラボのフルサイクルエンジニアチーム 初代エンジニアリングマネージャーの立場から紹介します。

## モンスターラボのAI & デジタルパートナー戦略

### AIを活用したデジタル変革のリーディングカンパニーへ

私たちモンスターラボは、[2025年度第2四半期の決算発表](https://ssl4.eir-parts.net/doc/5255/tdnet/2677143/00.pdf)において、AI駆動開発を起点に戦略及び組織を再設計し、AIネイティブな開発パートナーへの基盤整備を行っていることを発表しました。

この変革の中心となるのが、以下の3つの柱です：

1. **AI駆動開発** - 開発プロセスのあらゆる領域でAIを活用し、高品質化と高生産性を実現
2. **AIのプロダクトへの組み込み** - 当社が開発するシステムにAIを機能として実装し、高度化したソリューションを提供
3. **AIによる業務改革支援** - クライアントの業務をAIを活用して改革し、生産性や付加価値向上を実現

私たちが立ち上げたフルサイクルチームは、この戦略を技術面から推進するとともに、AI時代の新しいエンジニアリングの形を模索し、実践する役割を担っています。

## なぜ今、フルサイクルエンジニアなのか

「フルサイクルエンジニア」という言葉に馴染みのない方もいらっしゃるかもしれません。これは元々、Netflixが提唱したエンジニアロールの概念で、ソフトウェア開発の全工程に関わり、プロダクトのライフサイクル全体に責任を持つエンジニアのことを指します。


![FullCycleEnginner](https://miro.medium.com/v2/resize:fit:1118/format:webp/1*_nN4aj7uohV4v8bnqJCw3g.png)
*出典: [Full Cycle Developers at Netflix — Operate What You Build](https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249)*

私は当初、フルサイクルエンジニアという概念は、開発者リソースが限られたスタートアップか、Netflixのようなスーパーエンジニアが在籍するビッグテックでしか実現できないものだと考えていました。なぜなら、設計からデプロイ、運用まで、全般的な知識と実行スキルが必要になるからです。

しかし、生成AIの急速な進化により、状況は大きく変わりました。

### 生成AIがもたらす変革

Findyの最新調査によると、生成AIの登場以降、フルスタックエンジニアの採用枠が顕著に増加しています。これは単なるトレンドではなく、エンジニアリングの本質的な変化を示しています。

[エンジニア調査レポート 2025年9月版](https://findy-code.io/job-market-trends/20250924)

生成AIは、エンジニア個人の能力を大幅に拡張します。これまで専門知識が必要だった領域でも、AIのサポートにより、一人のエンジニアがより広範囲の技術領域をカバーできるようになりました。

モンスターラボでは、この変化の先にあるビジョンとして、フルスタックであることにとどまらず **フルサイクルエンジニアがソフトウェア開発の新しいスタンダードになる** と考えています。

今回のフルサイクルエンジニアチームの立ち上げは、そのビジョンを見据えた第一歩です。

## モンスターラボが描くフルサイクルエンジニア像

私たちが求めるフルサイクルエンジニアは、単に複数の技術を扱えるジェネラリストではありません。

### 核となる価値観

1. **プロジェクト全体への責任感**
   - 要件定義から運用まで、プロジェクトのライフサイクル全体に当事者意識を持つ
   - 品質、納期、顧客満足度すべてに責任を持つ

2. **専門性とAI活用のハイブリッド**
   - 自身の強みとなる主軸の専門領域を持ちながら、他の領域ではAIを効果的に活用
   - バックエンド、フロントエンド、インフラ、QAなど、主軸は何でも構わない

3. **技術的意思決定力**
   - 開発プロセス、アーキテクチャ設計、コードレビューを通じてプロジェクトの成功に貢献できる
   - プロジェクトの技術選定について、最適な意思決定ができる

### フルサイクルエンジニアの活動領域

以下の図は、フルサイクルエンジニアが関与する主な活動領域を示しています。
元々は、このブログの [モンスターラボの環境でTechLeadとして働くこと](https://engineering.monstar-lab.com/jp/post/2022/02/17/Work-at-ML/) でTech Leadの役割を紹介した図をベースにしていますが、フルサイクルエンジニアはさらに広範囲にわたります。

![FullCycleRole in Monstarlab]({{ sitePrefix }}/assets/img/articles/2025-10-07-FullCycle-Team-is-launched/FullCycle_Role.webp)

また、現時点でフルサイクルチームのメンバーがこれだけの領域をカバーしているわけではありません。
この図は、あくまで今後のビジョンです。
フルサイクルチームは現在これだけの領域を補佐できる AIを育て、開発プロセスを整備することになります。チームのミッションは、この図の実現のため、モンスターラボの現在の情報を踏まえて、会社組織をこの図に近づけることです。

## チームの現在とビジョン

私たちのフルサイクルエンジニアチームは、まだ立ち上がったばかりです。正直なところ、ビジョンが先行し、役割の実態や具体的なプロセスはまだ完全には確立されていません。

先にも述べた通り、現在はフルサイクルエンジニアをAIがサポートできるように、AI強化と開発プロセスの整備に注力しています。

**「Turn Vision into Reality」** の精神で、私たちは新しいエンジニアリングの形を一緒に創造していく仲間を求めています。

## 求める人材像

### 必須スキル・スタンス

- 生成AIツール（GitHub Copilot、ChatGPT、Claude等）の活用経験
- 新しい技術や手法を積極的に学ぶ意欲
- 「できない理由」より「どうすればできるか」を考える
- 技術的な挑戦を楽しめる
- 自分の経験、スキルを言語化できる
- **「Turn Vision into Reality」** の精神

## キャリアパス

フルサイクルエンジニアは立ち上がったばかりですが、その後のキャリアパスは以下のようなものが考えられるのではないかと思っています：

1. **Technical Expert**: 特定領域を極めながら、フルサイクルの視点を持つスペシャリスト
2. **Tech Lead**: プロジェクトの技術的意思決定を主導
3. **Engineering Manager**: チームマネジメントと技術的リーダーシップを両立
4. **Project Manager**: Tech領域に限らず、プロジェクト全体を統括

## 最後に

フルサイクルエンジニアという新しい働き方は、まだ発展途上です。しかし、生成AIという強力なパートナーを得た今、一人のエンジニアができることの可能性は大きく広がっています。

フルサイクルエンジニアとして、AI時代の新しいエンジニアリングを一緒に創造したい方は、ぜひご応募ください。

モンスターラボで、エンジニアリングの新しい未来を一緒に創りませんか？
「Turn Vision into Reality」 の精神で、一緒にフルサイクルエンジニアを目指す仲間を募集しているので、ご興味ある方はぜひご応募ください。

[株式会社モンスターラボ の求人|FullCycleエンジニア](https://hrmos.co/pages/monstar-lab-recruit/jobs/0002501)


AI時代の新しいエンジニアの形 - モンスターラボにおけるフルサイクルエンジニアとは

Claude Codeとの開発体験から学んだ、生成 AI 時代のエンジニアリング

OpenSearchでサクサク検索してみよう

エンタープライズデータ基盤における dbt の活用戦略


データ駆動型ビジネスが当たり前となった今日、多くの企業がデータ分析の課題に直面しています。複雑な SQL クエリの管理、データの整合性確保、分析プロセスの再現性など、様々な問題が山積みです。そんな中で注目を集めているのが「dbt（data build tool）」です。

本記事では、データエンジニアリングの深い知識がなくても理解できるよう、dbt の基本と魅力について解説します。

## dbt とは？

dbt は、SQL を中心としたデータ変換ワークフローを管理するためのオープンソースツールです。従来の SQL スクリプト管理とは一線を画し、以下のような特徴を持っています：

1. モジュール化された SQL コード
2. バージョン管理との統合
3. 自動テスト機能
4. ドキュメンテーション自動生成

これらの機能により、データ分析のプロセス全体を効率化し、品質を向上させることができます。

## dbt が解決する主な問題

### 1. SQL コードの再利用性と保守性

dbt では、SQL クエリを再利用可能なモジュールとして管理できます。例えば：

`models/staging/stg_orders.sql:`

```sql
SELECT
    order_id,
    customer_id,
    order_date,
    status
FROM raw.orders
```

`models/intermediate/int_customer_orders.sql:`

```sql
SELECT
    customer_id,
    COUNT(order_id) as total_orders,
    MIN(order_date) as first_order_date
FROM {{ ref('stg_orders') }}
GROUP BY customer_id
```

`{{ ref('stg_orders') }}`で他のモデルを参照でき、依存関係が明確になります。

### 2. データの信頼性向上

dbt には組み込みのテスト機能があります。YAML ファイルでテストを定義できます：

`models/staging/stg_orders.yml:`

```yaml
models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: status
        tests:
          - accepted_values:
              values: ["pending", "shipped", "delivered", "returned"]
```

これにより、データの整合性を自動的に検証できます。

### 3. チーム協働の促進

dbt プロジェクトは Git などのバージョン管理システムと統合できるため、チームでの協働が容易になります。また、自動生成されるドキュメントにより、チーム全体でのナレッジ共有が促進されます。

## dbt の主要機能

### モデリング：SQL の力を最大限に活用

dbt のモデルは基本的に SQL ファイルですが、Jinja templating を使用することで、動的な SQL の生成が可能になります：

`models/intermediate/int_order_payments.sql:`

```sql
{% set payment_methods = ['credit_card', 'coupon', 'bank_transfer'] %}

SELECT
    order_id,
    {% for payment_method in payment_methods %}
    SUM(CASE WHEN payment_method = '{{ payment_method }}' THEN amount ELSE 0 END) as {{ payment_method }}_amount,
    {% endfor %}
    SUM(amount) as total_amount
FROM payments
GROUP BY order_id
```

このように、繰り返しの多い SQL を簡潔に書くことができます。

### テスト：データ品質を自動チェック

YAML でのテスト定義に加え、カスタム SQL テストも作成可能です：

`models/intermediate/int_order_payments.sql:`

```sql
SELECT
    order_id,
    total_amount,
    credit_card_amount + coupon_amount + bank_transfer_amount as sum_of_methods,
    total_amount - (credit_card_amount + coupon_amount + bank_transfer_amount) as difference
FROM {{ ref('order_payments') }}
WHERE ABS(total_amount - (credit_card_amount + coupon_amount + bank_transfer_amount)) > 0.01
```

このテストは、合計金額が各支払い方法の合計と一致することを確認します。

### ドキュメント：自動生成されるデータカタログ

dbt は、プロジェクトの構造やデータの定義を自動的にドキュメント化します。さらに、モデルやカラムにドキュメントを追加することもできます：

`models/intermediate/int_customer_orders.yml:`

```yaml
models:
  - name: customer_orders
    description: "One row per customer with their order history"
    columns:
      - name: customer_id
        description: "The unique identifier for a customer"
      - name: total_orders
        description: "The total number of orders placed by this customer"
```

## dbt を使う利点

1. **分析者とエンジニアの協働促進**: SQL を共通言語として使用することで、両者のスキルセットを最大限に活用できます。

2. **データの一貫性と信頼性の向上**: 自動テストとバージョン管理により、データの品質と一貫性が向上します。

3. **分析プロセスの効率化**: モジュール化と自動化により、新しい分析の作成や既存の分析の更新が迅速に行えるようになります。

## 簡単なユースケース例

ある小売企業が、顧客のライフタイムバリュー（LTV）を計算したいとします。dbt を使用すると：

1. 注文データ、顧客データ、商品データを個別のステージングモデルとして定義
2. これらのモデルを組み合わせて、顧客ごとの総購入額を計算するマートモデルを作成
3. LTV 計算のロジックを別のモデルとして定義
4. 各ステップでテストを実行し、データの整合性を確認
5. 最終的な LTV モデルを定期的に更新し、ビジネスユーザーに提供

このプロセスが自動化されることで、データチームは計算ロジックの改善や新しい指標の開発に注力できるようになります。

各ステップでコード例も含めて解説します。

1. ステージングモデルの定義

まず、注文データ、顧客データ、商品データのステージングモデルを定義します。

models/staging/stg_orders.sql:

```sql
{{ config(materialized='view') }}

select
    order_id,
    customer_id,
    order_date,
    status
from {{ source('raw', 'orders') }}
```

models/staging/stg_customers.sql:

```sql
{{ config(materialized='view') }}

select
    customer_id,
    first_name,
    last_name,
    email
from {{ source('raw', 'customers') }}
```

models/staging/stg_products.sql:

```sql
{{ config(materialized='view') }}

select
    product_id,
    product_name,
    price
from {{ source('raw', 'products') }}
```

2. マートモデルの作成

次に、これらのステージングモデルを組み合わせて、顧客ごとの総購入額を計算するマートモデルを作成します。

models/marts/fct_customer_orders.sql:

```sql
{{ config(materialized='table') }}

with order_items as (
    select
        order_id,
        product_id,
        quantity
    from {{ ref('stg_order_items') }}
),

order_prices as (
    select
        oi.order_id,
        sum(p.price * oi.quantity) as order_total
    from order_items oi
    join {{ ref('stg_products') }} p on oi.product_id = p.product_id
    group by 1
)

select
    o.customer_id,
    count(distinct o.order_id) as number_of_orders,
    sum(op.order_total) as total_order_value
from {{ ref('stg_orders') }} o
join order_prices op on o.order_id = op.order_id
group by 1
```

3. LTV 計算ロジックの定義

LTV 計算のロジックを別のモデルとして定義します。

models/marts/customer_ltv.sql:

```sql
{{ config(materialized='table') }}

with customer_orders as (
    select * from {{ ref('fct_customer_orders') }}
),

ltv_calc as (
    select
        customer_id,
        total_order_value as ltv,
        total_order_value / nullif(number_of_orders, 0) as average_order_value
    from customer_orders
)

select
    c.customer_id,
    c.first_name,
    c.last_name,
    c.email,
    coalesce(l.ltv, 0) as customer_ltv,
    coalesce(l.average_order_value, 0) as average_order_value
from {{ ref('stg_customers') }} c
left join ltv_calc l on c.customer_id = l.customer_id
```

4. テストの実行

各ステップでデータの整合性を確認するためのテストを追加します。

models/staging/schema.yml:

```yaml
version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('stg_customers')
              field: customer_id

  - name: stg_customers
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null

  - name: stg_products
    columns:
      - name: product_id
        tests:
          - unique
          - not_null
```

models/marts/schema.yml:

```yaml
version: 2

models:
  - name: fct_customer_orders
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: total_order_value
        tests:
          - not_null

  - name: customer_ltv
    columns:
      - name: customer_id
        tests:
          - unique
          - not_null
      - name: customer_ltv
        tests:
          - not_null
```

5. 定期的な更新と提供

最後に、dbt Cloud のジョブ機能を使用して、この LTV モデルを定期的に更新し、ビジネスユーザーに最新のデータを提供します。dbt Cloud でジョブを設定し、例えば毎日午前 5 時にモデルを更新するようにスケジュールします。

このプロセスにより、データチームは LTV 計算の自動化を実現し、計算ロジックの改善や新しい指標の開発に注力できるようになります。また、dbt の利点である版管理、テスト、ドキュメンテーションなどの機能を活用して、より信頼性の高いデータパイプラインを構築できます。

## 自社での dbt 活用事例

当社でも、dbt を社内のデータ基盤に導入し、成果を上げています。導入前は各担当がバラバラに SQL スクリプトを管理し、データの不整合や分析の遅延が問題となっていました。dbt の導入後、以下のような改善が見られました：

- データモデルの標準化により、部署間のデータ解釈の違いが解消
- テスト自動化による数値の信頼性向上
- ドキュメント自動生成によるナレッジ共有の促進

## まとめ：dbt がもたらすデータ文化の変革

dbt は、SQL を知っているデータ専門家にとって非常に強力なツールです。データの信頼性向上、チームの協働促進、分析プロセスの効率化を通じて、組織全体のデータ活用レベルを引き上げます。

SQL の知識を持つ方々にとって、dbt の学習曲線は比較的緩やかであり、すぐに生産性の向上を実感できるでしょう。データを真の資産として活用したい組織にとって、dbt は強力な味方となります。

あなたの組織でも、dbt の導入を検討してみてはいかがでしょうか？データエンジニアリングの世界に新しい風を吹き込む dbt の魅力を、ぜひ体験してください。

## 参考：dbt と他のデータ変換ツールの比較

| 特徴           | dbt             | Apache Airflow   | Talend         | Informatica    |
| -------------- | --------------- | ---------------- | -------------- | -------------- |
| 主な用途       | データ変換      | ワークフロー管理 | ETL            | ETL/データ統合 |
| 言語           | SQL, Jinja      | Python           | 独自 GUI, Java | 独自 GUI       |
| 学習曲線       | 中              | 高               | 中             | 高             |
| オープンソース | ○               | ○                | ×              | ×              |
| バージョン管理 | 優れている      | 可能             | 限定的         | 限定的         |
| テスト機能     | 組み込み        | プラグイン       | 限定的         | あり           |
| コスト         | 無料/有料版あり | 無料             | 有料           | 有料           |

dbt は特に SQL 中心のデータ変換に特化しており、バージョン管理やテスト機能が充実している点が特徴です。

注意点としては下記の通りです。

- データの抽出・ロードは別のツールで行う必要がある(Fivetran, Airbyte、Azure Data Factory など)
- ジョブスケジューラは別のツールで行う(Airflow, Prefect, cron, GCP Cloud run など)
- CUI ツールである

逆に、様々な既存ツールと組み合わせることができる柔軟性も持ち合わせているツールとも言えます。

## 参考：よくある質問（FAQ）

Q1: dbt を導入するのに、どのくらいの期間がかかりますか？

A1: 組織の規模やデータの複雑さによりますが、一般的に小規模なチームであれば 1-2 週間、大規模な組織でも 1-3 ヶ月程度で基本的な導入が可能です。

Q2: dbt は無料で使えますか？

A2: はい、dbt Core は無料のオープンソースソフトウェアです。ただし、dbt Cloud の一部の機能は有料プランでのみ利用可能です。

Q3: どのデータベースをサポートしていますか？

A3: Snowflake、BigQuery、Redshift、PostgreSQL など、主要なデータウェアハウスやデータベースをサポートしています。最新の対応状況は公式サイトで確認してください。

Q4: dbt を使用するのに、プログラミングのスキルは必要ですか？

A4: 日常的には基本的な SQL の知識があれば十分ですが、より高度な使用には Python や Jinja2 の知識が役立ちます。また、ソフトウェア開発のプラクティス（git, CI/CD など）を理解していると、より効果的に dbt を活用できます。

Q5: 既存の ETL プロセスを dbt に移行するのは難しいですか？

A5: 既存の SQL を段階的に dbt モデルに変換していくことができるため、比較的スムーズに移行できます。ただし、ベストプラクティスに従った再構築が推奨される場合もあります。

---

## 関連リンク

- [dbt 公式サイト](https://www.getdbt.com/)
- [dbt 公式ドキュメント](https://docs.getdbt.com/)
- [dbt GitHub リポジトリ](https://github.com/dbt-labs/dbt-core)
- [dbt Slack コミュニティ](https://community.getdbt.com/)

- _記事の画像: [Unsplash](https://unsplash.com/ja/%E5%86%99%E7%9C%9F/%E7%99%BD%E3%81%84%E3%82%B5%E3%83%A0%E3%82%B9%E3%83%B3%E3%82%AE%E3%83%A3%E3%83%A9%E3%82%AF%E3%82%B7%E3%83%BC%E3%82%BF%E3%83%96%E3%82%92%E6%8C%81%E3%81%A3%E3%81%A6%E3%81%84%E3%82%8B%E4%BA%BA-jrh5lAq-mIsa)より_


データエンジニアリング初心者でも分かる！dbtの魅力と基本

2024-10-10-FlutterNinjas Conference: My Participation Experience


モンスターラボにバックエンドエンジニアとして入社して1年が経過しました。
率直な振り返りを記事にしてみます。
実際にどのような経験ができるのか、それはどんな感じなのか、１つの視点として参考になれば幸いです。

フロントエンドエンジニアの Yuki Nakano さんの記事と共鳴するものがありますので、そちらも是非参照ください。

関連エントリ：[モンスターラボの環境でTechLeadとして働くこと(2022年2月17日)]({{ baseurl }}/post/2022/02/17/Work-at-ML/)

### やったこと (What I Did)
#### クライアントワーク - 最初の半年

入社後は、次のような開発に関わることができました。

1. インフラ基盤として Google Cloud をフル活用したシステムのスクラッチ開発

私が本格的にクラウドサービスプロバイダに触れたのはAWSが最初でしたが、Google Cloudの最初の利用サービスは、BigQueryとLookerです。
その時の開発体験が非常に良かったことから「もっとGoogle Cloudを使ってみたい」と思っており、入社後すぐにこの希望が叶うことになります。

このプロジェクトでは、AWS、Azureなどを使った開発も行われていたため、新領域としてAzureの世界も垣間見ることができる良い機会となりました。

#### クライアントワーク - 次の半年

後半では一転して、Azureに関して多くの経験値が得られる期間となりました。

1. Azureを使った新たなWebアプリのモック開発
2. Azureの運用下における、オンプレ→クラウド移行のためのPoCや、新規課題の調査・改善

前者は、モックに最適なサービス・プランを選定し、0から構築して機能開発・改善を進めます。
後者は、既にある仕組みが現状に至る背景の把握や、課題の深堀り、解決がそもそも必要なのか、妥協点はあるかという観点も視野に入れた活動です。

Azure Entra ID認証を正しく理解し、運用管理者と足並みをあわせて協同することも重要です。
Durable Functions について追加の Functions を書いたり、DBデータ移行ツールの機能を調査したり、App Service の中身(Kudu)を覗くこともあります。

目的や成熟度がそれぞれに異なるシステム開発に関わる中、興味をもって様々なニーズに対応していたら、Azureの知識も自然と溜まってきます。
取り組みの中で「点」として集めた知識が別の「点」と繋がり、時間を置いて、全く別の場面でも生きるということが起きました。

#### 社内での多彩な活動

「Life at Monstarlab」ーーーバックエンドチームの週次ミーティングの資料に、おそらく何気なく書かれている言葉ですが、私はこのフレーズをとても気に入っています。

モンスターラボでの仕事は、クライアントワークだけでなく、ITエンジニアとしての多彩な活動が含まれることをシンプルに表現していると感じるからです。
RFPに対する提案、商談のほか、開発におけるスタンダード策定、Backend Tech Talk Session、生成AIの全社向け運用、輪読会など、さまざまな取り組みが存在します。

生成AIの全社向け運用では、Azure OpenAI活用チームのメンバーとして、日々のリクエストに応じたリソースの払い出しや、改善活動をしています。世の中のLLMプラットフォームの選択肢が複数ある中、会社としても活用を奨励しているので、まずは好きな生成AIを見つけて関わっていくアプローチもありと思います。

このブログ記事の章立て・構成検討においても、モンスターラボの有志が運用してくれている「Dify」で立てたGPT-4oと対話して仕上げています。

Backend Tech Talk Sessionは、自由にテーマが持ち寄られる会で、過去のセッションも後から視聴できます。

私の発表回では、Azureで認証を取り扱う機会が増えそうな気配を感じたことから
「Azure アプリケーションにおけるMicrosoft ID基盤を使った認証設置パターン 〜App Serviceを例に〜」というテーマを設定しました。

このように、個々人の興味分野や能力を発揮できそうな領域が何かと見つかる環境だと思います。
私自身に対しては、インプットとアウトプットのバランスを取る場として丁度良い具合にフィットしています。

### わかったこと (What I Learned)

Google Cloudの Cloud Load Balancing、Cloud Run、Cloud Functions、Cloud Storage、Eventarc、Artifact Registry、Certificate Managerといった、巨大パブリッククラウドの強力なサービスの数々を組み合わせて実際にシステム構築することができるようになりました。

利用基盤が決定していたことから、その中でサービス選定や各種設計を進めれば良かったので、集中してサービス特性の理解に取り組むことができました。

最も興味深く見ていたのは以下のようなことです。

- **Cloud Functions(第2世代)とCloud Runの関係**:
  第2世代のCloud FunctionsはCloud Run上に配置されています。
- **Cloud Runの扱いやすさ**:
  事前設定を何もしなくても、容易にログにたどり着けるところが素晴らしいと思います。
  Cloud Run ジョブも十分にシンプルで、実行時には設定をオーバーライド可能です。
- **Private Service Connect の仕組みと実装**:
  特に次の解説シリーズは繰り返し読み込みました。感謝。 
  [初めての Private Service Connect #1 PSCってなに？ 編](https://medium.com/google-cloud-jp/psc-01-ac1aba58b161)
- **TerraformのTLS Providerと組み合わせて、Self-signed certificatesをスマートに扱える**:
  つまり、以下のようなコードです。

```hcl
# TLS Provider
# テスト用の自己署名証明書

resource "tls_private_key" "default" {
  algorithm = "RSA"
  rsa_bits  = 2048
}

resource "tls_self_signed_cert" "default" {
  private_key_pem = tls_private_key.default.private_key_pem

  # 証明書の有効期限
  validity_period_hours = 24 * 365

  # 証明書の有効期限の7days以内にTerraformが実行された場合、新しい証明書を生成
  early_renewal_hours = 24 * 7

  is_ca_certificate = true

  allowed_uses = [
    "key_encipherment",
    "digital_signature",
    "server_auth"
  ]

  dns_names = ["*.${var.domain_name}"]

  subject {
    common_name  = "*.${var.domain_name}"
    organization = "ACME Examples, Inc"
  }
}
```

```hcl
# Google Cloud provider

resource "google_compute_region_ssl_certificate" "default" {
  name_prefix = "my-certificate-"
  private_key = tls_private_key.default.private_key_pem

  # ここで証明書を指定できる
  certificate = tls_self_signed_cert.default.cert_pem

  region      = var.region
  lifecycle {
    create_before_destroy = true
  }
}
```

Azureでは以下のような気づきを得ました。
- **C#とAzureの恩恵**:
  C#アプリは、(例えばnode.jsと比較して)Azureとの親和性が高そうです。なお、App Service自体もほとんどC#で開発されているとか。
- **Azure Entra IDの強さ**:
  強力な認証基盤ゆえに、選択肢として優位に立つケースが十分にあります。
- **App Serviceはその名の通りのコンセプトであること**:
  中でもAzure PortalからApp Serviceの内側であるKuduサイトにアクセスできるのが印象的です。
  任意のexeを配置してcmdで実行したいといったシンプルな話だと、VMを準備しなくても、App Serviceで足りてしまうケースがありそうです。
- **サポートリクエストをオープンする際の、説明事項の大切さ**:
  テキストだけでなく、ファイルを添付することで精細な情報を伝えることも可能なので、初めの手間を惜しまないことがスムーズなやりとりのコツです。
  地味で基本的なことですが、忘れないようにしたいです。

### 次にやること (What I Will Do Next)

#### 一旦置いておくこともあり

優先度の兼ね合いで、完遂しなかった課題もありました。
- Google CloudのVMで、Windows 起動スクリプトをterraformで仕込むこと
- C#でテストコードを作成すること（なお、モンスターラボでC#はレアです）
- PowerBIのデータ前処理で、ちょっと複雑なMクエリを書くこと

これらはまた機会があれば取り組もう、というモチベーションにしておきます。

#### 集中と発散で、より遠くへ

入社前は長く1つのプロダクトに関わっていたこともあり、ここ最近は「発散」をテーマにしていて、未経験の技術やサービス利用を実践できる環境が良いと思っていました。モダンという指向も重要です。

入社後は順調に実績解除を重ねており、これまでのところ大小さまざまな階段を、無理のないペースで上がることができています。

また、後ろ向きな意味でなく、純粋に「自分の伸びしろってまだあったんだ」ということも感じました。
今後も引き出しを増やして、設計・実装・様々な会話・アイデアにより高い価値が生まれるよう、楽しみながら活動し続けたいと思います。

以上、モンスターラボに興味を持つ方の参考になれば幸いです。

_Article Photo by [Patrick Tomasso](https://unsplash.com/photos/CJcdrG2fX6c)_


モンスターラボの環境での実践と発見、未来への一歩

AWS ECS App Mesh リトライ戦略


web アプリケーションのセキュリティを確保する際、認証・認可にはさまざまな選択肢があります。特に人気があるのは PASETO と JWT です。

JWT は何年も前から広く利用されてきましたが、PASETO は比較的新しい技術であり、その高度なセキュリティ機能から注目を集めています。

PASETO（Platform-Agnostic Security Tokens）は、セキュアなステートレス・トークンの仕様およびリファレンス実装であり、JWT に代わる安全性の高い技術です。

### トークン・ベース認証の理解

セキュアな API でユーザーを認証するための典型的なフローは以下です。

1. ユーザーは認証のためにユーザー名とパスワードを提供する。
2. 認証に成功すると、API はアクセストークン（JWT または PASETO）を返す。
3. アクセストークンは、保護されたエンドポイントへのリクエスト時に Authorization ヘッダーに含める。
4. API サーバーはトークンを検証し、アクセスが有効であれば適切に保護されたデータで応答する。

![Modern Token Base Authentication]({{ sitePrefix }}/assets/img/articles/2023-05-16-An-overview-of-PASETO-Token-Based-Authentication/token_based_authentication.webp)

### JWT と制限の理解

JWT は 3 つのコンポーネントで構成されます。

- ヘッダー：トークンの署名アルゴリズムを含む。
- ペイロード：認証されたユーザーに関する情報と追加データを保持する。サーバーはペイロードのこの部分をカスタマイズできる。
- 署名：秘密鍵を使用してサーバーが生成する。この署名によって、サーバーは検証プロセス中に JWT の真正性を検証できる。

![JWT Demo]({{ sitePrefix }}/assets/img/articles/2023-05-16-An-overview-of-PASETO-Token-Based-Authentication/jwt.webp)

_Photo by [Wallarm](https://www.wallarm.com/what/token-based-authentication)_

JWT はデジタル署名アルゴリズムと検証の実装の選択に柔軟性を提供しますが、この柔軟性は脆弱性ももたらします。

ECDSA（Invalid-Curve Attack に弱い）や RSA PKCSv1.5（Padding Oracle Attack に弱い）のように、弱く攻撃されやすいアルゴリズムが複数あります。

JWT の実装はエラーも起こしやすく、JWT 検証の破綻のようなセキュリティの脆弱性をもたらす可能性があります。

JWT を正しく使用すれば、信頼性が高く柔軟な認証システムになります。しかし、サーバーが潜在的な攻撃にさらされないよう、注意を払う必要があります。

これに対して PASETO は、実装プロセスを単純化することで、これらの問題に対処しています。

## PASETO Solution

JWT が柔軟な実装を提供するのに対し、PASETO はより厳格なアプローチをとります。しかし、この厳格さが実装エラーや誤用を防ぐのに役立っています。

PASETO はユーザーフレンドリーに設計されており、JWT と比較して高い cryptographic resilience を提供します。

PASETO を使用する場合、ユーザーは 2 つの設定

- PASETO のバージョン(**`v1`**, **`v2`**, **`v3`**, or **`v4`**)を トークンの **`version`** フィールドで指定する。
- 暗号化と復号化を対称にするか非対称にするかを、トークンの **`purpose`** フィールドで指定する。

を行うだけです。

### PASETO Token の構造

JSON Web Token（JWT）と同様に、PASETO Token はドット区切りの base64url エンコードされたデータで構成され、以下の形式で編成されます：

```
version.purpose.payload.footer
```

- **`version`**: Token 形式のインクリメンタルな改良を許可する。2024 年 7 月現在のバージョンは "v1"、"v2"、"v3"、"v4 "です。
  - **`v1`**: 現在広く利用可能な強力な暗号理論を使用。
  - **`v2`**: より新しく強力な暗号理論を利用するが、サポートする暗号ライブラリの数は少ない。
- **`purpose`**: Token の形式を "local "または "public "のどちらかを表す簡潔な文字列。
  - **`local`**: Token のペイロードは暗号化され、共有鍵を持つパーティのみがアクセスできる。
  - **`public`**: ペイロードは暗号化されず、公開鍵を使って署名・検証される。
- **`payload`**: Token のバージョンと目的に応じてエンコードされたデータ。
- **`footer`** (optional): 暗号化されていない JSON。通常、トークン検証のための公開鍵の ID を格納するために使用される。

すべての PASETO Token 形式は改ざん防止に対応しており、トークンに変更が加えられた場合、検証は失敗します。

### Local Token (対称暗号化)

Local Token は常に共有秘密鍵を用いて対称暗号化される。つまり、Local PASETO Token の内容は、正しい秘密鍵なしには見ることができません。

![Symmetric encryption]({{ sitePrefix }}/assets/img/articles/2023-05-16-An-overview-of-PASETO-Token-Based-Authentication/symmetric.webp)

これはデコードされたペイロード、オプションのフッター、情報に署名するために使用される署名鍵を含む、Local PASETO Token の例です。

![Symmetric encryption]({{ sitePrefix }}/assets/img/articles/2023-05-16-An-overview-of-PASETO-Token-Based-Authentication/paseto_symmetric_demo.webp)

### Public Token （非対称暗号化）

Public PASETO Token は、関係者全員と秘密鍵を共有するのが安全でないシナリオに適しています。

Public Token は暗号化されませんが、デジタル署名されます。つまり、攻撃者が Public PASETO Token を入手した場合、PASETO Token に使用されているデジタル署名により、その内容を閲覧することはできますが、検出されずに変更することはできません。

悪意を持って変更された Public PASETO Token を検証しようとすると、エラーが発生します。

![Asymmetric encryption]({{ sitePrefix }}/assets/img/articles/2023-05-16-An-overview-of-PASETO-Token-Based-Authentication/asymmetric.webp)

以下は、デコードされたペイロード、オプションのフッター、情報に署名するために使用される公開鍵と秘密鍵を含む、Public PASETO Token の例です。

![Asymmetric encryption]({{ sitePrefix }}/assets/img/articles/2023-05-16-An-overview-of-PASETO-Token-Based-Authentication/paseto_asymmetric_demo.webp)

### Versions

PASETO の各バージョンは、前のバージョンよりも改良されています。PASETO を仕様通りに正しく実装するには、バージョンごとに提供されているドキュメントを参照してください。

[https://github.com/paseto-standard/paseto-spec/tree/master/docs/01-Protocol-Versions](https://github.com/paseto-standard/paseto-spec/tree/master/docs/01-Protocol-Versions)

### Libraries

以下のリンクには、一般的なすべての言語とそのサポートバージョンの PASETO を実装したライブラリがあります。

[https://paseto.io/](https://paseto.io/)

### Ruby ライブラリを使った実装

PASETO を実装した Ruby ライブラリの使用例を以下に示します。

[https://github.com/bannable/paseto](https://github.com/bannable/paseto)

事前に gem のインストールが必要です。

```bash
gem 'ruby-paseto'
gem 'rbnacl', '~> 7.1.1' # optional - PASETO version 4 を使う場合のみ使用
```

### 対称暗号化 (local)

```ruby
require 'paseto'

####################
####### 暗号化 ######
####################

# 通常、この32バイトの共有鍵は、認証サーバーとクライアントサーバーの両方に格納される。
shared_secret_key = SecureRandom.bytes(32)

# PASETO 暗号化/復号化の初期化をする。
crypt = Paseto::V4::Local.new(ikm: shared_secret_key) # version: v4 / 用途: local

# 平文のペイロード
claims = { "company" => "monstarlab" }
footer = { "viewable" => "yes" }

# ペイロードをエンコードし、PASETOを取得する。
encrypted_token = crypt.encode(claims, footer: JSON.dump(footer))
# => "v4.local.E1Y_KQ6Ek8lSOKrJ6kI1YjWXfAKJ0OEcdhUPywznjBjK5SGDUr4-6rbaZk-CIM_mdQgQHGPj8yAWQswktkCe_Sm_Nj9eEfDxNBFeAC2KsgqFCjF07VJo5ail0jnSTNM0-PekMytJleea8OvNkKdoLs4GKAsZTTJ_-DEMmOMyVlddlmaWoVwnF2JkpjBzFRO7d6PlIIY29rQWOXSvZxoLEqkE5XJvHpFs4NTuCHnF4Pko10X_sgHCPkTGXkWNDg.eyJ2aWV3YWJsZSI6InllcyJ9"

####################
####### 復号化 ######
####################

# 通常、この32バイトの共有鍵は、認証サーバーとクライアントサーバーの 両方に保存される。
shared_secret_key = SecureRandom.bytes(32)

# PASETO 暗号化/復号化の初期化をする。
crypt = Paseto::V4::Local.new(ikm: shared_secret_key) # version: v4 / 用途: local
encrypted_token = "v4.local.E1Y_KQ6Ek8lSOKrJ6kI1YjWXfAKJ0OEcdhUPywznjBjK5SGDUr4-6rbaZk-CIM_mdQgQHGPj8yAWQswktkCe_Sm_Nj9eEfDxNBFeAC2KsgqFCjF07VJo5ail0jnSTNM0-PekMytJleea8OvNkKdoLs4GKAsZTTJ_-DEMmOMyVlddlmaWoVwnF2JkpjBzFRO7d6PlIIY29rQWOXSvZxoLEqkE5XJvHpFs4NTuCHnF4Pko10X_sgHCPkTGXkWNDg.eyJ2aWV3YWJsZSI6InllcyJ9"

# トークン `eyJ2aWV3YWJsZSI6InllcyJ9` の最後の部分は、base64エンコードされた文字列であることに注意。
# つまり、誰でもその内容を見ることができる。
Base64.decode64("eyJ2aWV3YWJsZSI6InllcyJ9")
# => "{\"viewable\":\"yes\"}"

# トークンをデコードし、ペイロードを取得する。
crypt.decode(encrypted_token)
# => <Paseto::Result
#           claims={
#              "exp"=>"2023-05-10T11:18:41+09:00",
#              "iat"=>"2023-05-10T10:18:41+09:00",
#              "nbf"=>"2023-05-10T10:18:41+09:00",
#              "company"=>"monstarlab"},
#           footer={"viewable"=>"yes"}
#    >

# トークンが悪意を持って変更された場合、エラーが発生する。
encrypted_token[-1] = "M"
crypt.decode(encrypted_token)
# Paseto::InvalidAuthenticator: Paseto::InvalidAuthenticator
# from /Users/tony_duong/.rvm/gems/ruby-3.1.3/gems/ruby-paseto-0.1.2/lib/paseto/symmetric_key.rb:53:in `decrypt'

```

### 非対称暗号化（公開）の使い方

公開鍵と秘密鍵のペアの生成が必要です。

```bash
ssh-keygen
# Output: 公開鍵と秘密鍵
```

```ruby
require 'paseto'

####################
###### 暗号化 #######
####################

# PASETO 暗号化/復号化の初期化をする。
pem = File.read('private_key')
signer = Paseto::V4::Public.new(pem)

# 平文のペイロード
claims = { "company" => "monstarlab" }
footer = { "viewable" => "yes" }

# ペイロードをエンコードし、PASETOを取得する。
signed_token = signer.encode(claims, footer: footer)
# => "v4.public.eyJleHAiOiIyMDIzLTA1LTEwVDExOjQ2OjA0KzA5OjAwIiwiaWF0IjoiMjAyMy0wNS0xMFQxMDo0NjowNCswOTowMCIsIm5iZiI6IjIwMjMtMDUtMTBUMTA6NDY6MDQrMDk6MDAiLCJjb21wYW55IjoibW9uc3RhcmxhYiJ9taKQPCARAZHv85xk7yaWPDeWHaHt981eHmoiYIrIcA-monnIbMax2EDxIjObgr6qLLuYzAH4BK5N6q0TJANeBg.eyJ2aWV3YWJsZSI6InllcyJ9"

####################
###### 復号化 #######
####################

verifier = Paseto::V4::Public.new('public_key')

# 公開鍵で初期化された場合、検証/復号のみ実行可能。
# エンコードが呼び出されるとエラーが発生する。
verifier.encode({'foo' => 'bar'})
# => ArgumentError

signed_token = "v4.public.eyJleHAiOiIyMDIzLTA1LTEwVDExOjQ2OjA0KzA5OjAwIiwiaWF0IjoiMjAyMy0wNS0xMFQxMDo0NjowNCswOTowMCIsIm5iZiI6IjIwMjMtMDUtMTBUMTA6NDY6MDQrMDk6MDAiLCJjb21wYW55IjoibW9uc3RhcmxhYiJ9taKQPCARAZHv85xk7yaWPDeWHaHt981eHmoiYIrIcA-monnIbMax2EDxIjObgr6qLLuYzAH4BK5N6q0TJANeBg.eyJ2aWV3YWJsZSI6InllcyJ9"
verifier.decode(signed_token)
# => <Paseto::Result
#           claims={
#              "exp"=>"2023-05-10T11:18:41+09:00",
#              "iat"=>"2023-05-10T10:18:41+09:00",
#              "nbf"=>"2023-05-10T10:18:41+09:00",
#              "company"=>"monstarlab"},
#           footer={"viewable"=>"yes"}
#    >
```

## 結論

JSON Web Token（JWT）の不注意な使用から発生する可能性のある脆弱性について説明しました。JWT は、正しく使用されれば、認証をシステムに組み込む効果的な手段として機能しますが、その柔軟な仕様は、潜在的に実装エラーやその後のセキュリティ問題を引き起こす可能性があります。

このような懸念に対処するため、PASETO は、特定の設計目標を念頭に置いた代替ソリューションとして導入されました。

- 使用方法の簡素化： PASETO は、**`purpose`** と **`version`** のパラメータを指定するだけで、トークン作成プロセスを簡素化します。
- 実装エラーへの耐性： JWT とは異なり、PASETO では安全でない可能性のある暗号アルゴリズムを広範囲から選択する必要がないため、実装ミスのリスクを軽減することができます。

PASETO は、開発者の意思決定プロセスを合理化することで、セキュリティ・トークンに対する開発者ファーストのアプローチを取っています。対称または非対称のセキュリティモデルという 2 つの異なる目的を提供することで、PASETO は認証された暗号化とデジタル署名に最適なオプションを自動的に選択します。これにより、トークンの安全性が確保され、暗号の脆弱性を回避することができます。

全体として、PASETO はセキュリティー・トークン管理により強固でわかりやすいアプローチを提供し、JWT に関連するリスクを軽減すると同時に、システムのセキュリティーを高いレベルで維持します。

## References

- [PASETO: The JWT Killer? - article by Sandesh Dahake](https://www.linkedin.com/pulse/paseto-jwt-killer-sandesh-dahake/)
- [PASETO: Platform-Agnostic Security Tokens - Github repository](https://github.com/paseto-standard/paseto-spec)
- [Why PASETO is better than JWT for token-based authentication? - Youtube video by Tech School](https://www.youtube.com/watch?v=nBGx-q52KAY&ab_channel=TECHSCHOOL)
- [Introducing JPaseto: Security Tokens For Java - article by Brian Demers](https://developer.okta.com/blog/2020/07/23/introducing-jpaseto)
- [Encode or Decode PASETO](https://token.dev/paseto/)
- [Paseto - Github repository](https://github.com/bannable/paseto)

_Article Photo by [Erik Mclean](https://unsplash.com/photos/XUJcmgEhpjA)_


PASETO トークンベース認証の概要


## はじめに
現代のクラウドコンピューティングの世界では、アプリケーションのデプロイや管理の方法が多様化しています。特に注目されるのがサーバーレスとコンテナ技術です。これらの技術の違いや、それぞれの適切な利用シーンについて解説します。

## サーバーレスとは
サーバーレスは、開発者がインフラの管理を意識することなく、コードの実行に集中できるようにするものです。主な特徴として以下の点が挙げられます。

- **サーバーの抽象化**：開発者はサーバーを直接管理する必要がありません。
- **イベント駆動型の実行**：イベントが発生したときにコードが実行されます。
- **自動スケーリング**：需要に応じて自動的にスケールします。
- **料金体系**：実行時間と使用リソースに基づいて料金が発生します。

代表的なものは、AWS Lambda、Azure Functions、Google Cloud Functionsなどがあります。

## コンテナとは
コンテナは、アプリケーションとその依存関係を一緒にパッケージ化し、一貫した実行環境を提供する技術です。主な特徴として以下の点が挙げられます。

- **軽量でポータブル**：どの環境でも一貫して動作します。
- **隔離されたアプリケーション実行**：他のアプリケーションから隔離された環境で実行されます。
- **開発と本番環境の一貫性**：開発環境と本番環境で同じコンテナを使用できます。

代表的なものは、AWS ECS、EKS、Kubernetesなどがあります。

## 比較
サーバーレスとコンテナは、それぞれの特徴によって異なるメリットとデメリットがあります。以下にそれぞれの比較を示します。

### デプロイと管理
- **サーバーレス**：クラウドプロバイダーによって管理され、インフラストラクチャの管理は不要です。
- **コンテナ**：コンテナオーケストレーションの管理が必要で、任意のインフラストラクチャで実行可能です。

### スケーラビリティ
- **サーバーレス**：需要に応じて自動的にスケールします。
- **コンテナ**：オーケストレーションツールでスケールしますが、設定が必要です。

### コスト
- **サーバーレス**：実行ごとに課金され、変動するワークロードに対してコスト効果が高いです。
- **コンテナ**：稼働中のインスタンスに対して課金され、安定した高スループットのワークロードに対してコスト効果が高いです。

### ユースケース
- **サーバーレス**：短期間での実行、ステートレスなアプリケーション、イベント駆動型アーキテクチャ、リアルタイム処理、マイクロサービスに適しています。
- **コンテナ**：長期間の実行、複雑なマイクロサービスアーキテクチャ、レガシーアプリケーションのモダナイズ、一貫したランタイムが必要な環境に適しています。

## メリットとデメリット
### サーバーレス
- **メリット**：サーバー管理不要、自動スケーリング、バーストワークロードに対してコスト効果が高い。
- **デメリット**：コールドスタート遅延、実行時間の制限、環境の制御が少ない。

### コンテナ
- **メリット**：環境の制御が高い、一貫した駆動環境。
- **デメリット**：管理の複雑さ、運用のオーバーヘッドが高い。

サーバーレスとコンテナの選択は、アプリケーションの要件、開発者のスキル、予算、セキュリティ要件などに依存します。特に、サーバーレスは短期間の実行やイベント駆動型アーキテクチャに適しています。一方、コンテナは長期間の実行や複雑なマイクロサービスアーキテクチャに適しています。インフラプロバイダーによって提供されるサーバーレスプラットフォームやコンテナオーケストレーションプラットフォームを比較し、適切な選択を行うことが重要です。

## ハイブリッドアプローチ
システムによっては、サーバーレスとコンテナの両方を組み合わせることが有効な場合があります。例えば、サーバーレス関数を使用してイベント駆動型の処理を行い、コンテナを使用して長期間の実行や複雑なマイクロサービスを実行することができます。このようなハイブリッドアプローチは、アプリケーションの要件に応じて柔軟に対応できる利点があります。

その実装の例を少し紹介すると、サーバーレス関数をトリガーとしてコンテナを起動することができます。このようなアーキテクチャは、サーバーレスとコンテナの両方の利点を組み合わせることができます。

### 実装サンプル
以下は、TerraformとECSでコンテナを管理し、Serverless FrameworkとAPI GatewayでAPIを提供するサーバーレスとコンテナのハイブリッドアーキテクチャのコードのサンプルです。その間にSQSを使用してイベント駆動型の処理を行います。

```yaml
# serverless.yml
service: example-service

provider:
  name: aws
  runtime: nodejs12.x
  stage: dev
  region: us-east-1

functions:
  longRunningTask:
    handler: index.longRunningTaskHandler
    events:
      - sqs:
          arn:
            Fn::GetAtt:
              - LongRunningTaskQueue
              - Arn

  shortRunningTask:
    handler: index.shortRunningTaskHandler
    events:
      - http:
          path: short-task
          method: post

resources:
  Resources:
    LongRunningTaskQueue:
      Type: AWS::SQS::Queue
      Properties:
        QueueName: long-running-task-queue
    ShortRunningTaskApi:
      Type: AWS::ApiGateway::RestApi
      Properties:
        Name: short-running-task-api
```

```hcl
# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_ecs_cluster" "example" {
  name = "example-cluster"
}

resource "aws_ecs_task_definition" "example" {
  family = "long-task"
  container_definitions = jsonencode([
    {
      name = "long-task-container"
      image = "some-long-task-image"
      cpu = 256
      memory = 512
    }
  ])
}

resource "aws_ecs_service" "example" {
  name = "long-task-service"
  cluster = aws_ecs_cluster.example.id
  task_definition = aws_ecs_task_definition.example.arn
  desired_count = 1
}
```

```javascript
// index.js
const AWS = require('aws-sdk');
const ecs = new AWS.ECS();
const env = process.env;

exports.longRunningTaskHandler = async (event) => {
  // some logic to handle long running task
  // ...

  // params for starting ECS Task
  const params = {
    cluster: env.ECS_CLUSTER_NAME,
    taskDefinition: env.ECS_TASK_DEFINITION_ARN,
    count: 1,
    launchType: 'FARGATE',
    networkConfiguration: {
      awsvpcConfiguration: {
        subnets: [env.SUBNET_ID],
      },
    },
  };

  try {
    // start ECS Task
    const data = await ecs.runTask(params).promise();
    console.log('ECS Task started:', data);

    // return response
    return {
      statusCode: 200,
      body: JSON.stringify('ECS Task started successfully'),
    };
  } catch (error) {
    // handle error
    console.error('Error starting ECS Task:', error);

    // return error response
    return {
      statusCode: 500,
      body: JSON.stringify('Error starting ECS Task'),
    };
  }
};

exports.shortRunningTaskHandler = async (event) => {
  // some logic to handle short running task
  // ...

  // if you need to run long running task in handler, send message to SQS
  // you can consider using AWS Step functions, SNS or EventBridge as well
  const sqs = new AWS.SQS();
  const params = {
    MessageBody: JSON.stringify({ key: 'value' }),
    QueueUrl: env.LONG_TASK_QUEUE_URL,
  };
  await sqs.sendMessage(params).promise();

  // return response
  const response = {
    statusCode: 200,
    body: JSON.stringify('Short running task completed successfully'),
  };
  return response;
};
```

## まとめ
- サーバーレスはサーバーの管理を意識せずにコードを実行できる。
- コンテナはアプリケーションとその依存関係をパッケージ化し、一貫した実行環境を提供する。
- サーバーレスとコンテナの選択はアプリケーションの要件に依存する。
- ハイブリッドアプローチはサーバーレスとコンテナの両方を組み合わせることができる。

両方の技術を理解し、適切に利用することで、クラウドネイティブなアプリケーションを設計・構築することができます。サーバーレスとコンテナの適切な利用とハイブリッドアプローチを検討し、アプリケーションの要件に応じて最適な選択を行いましょう。


サーバーレスとコンテナの適切な利用とハイブリッドの考え方

夢のマイホームKubernetesクラスターを建てよう

An Introduction to HTMX

レスポンシブウェブデザイン：手法とベストプラクティス


こんにちは、モンスターラボで Backend の Tech Lead をしている国平です。<br />
前回の投稿から約1年ぶりの登場です。

先日、弊社ソリューションアーキテクト(以下、SAとも表記)である松下が執筆した 「ソリューションアーキテクトが起こす、小さな現場革命: 「炎上案件 ゼロ」を実現する上流工程の仕事術」 が Kindle Direct Publishing にて出版されました。

[![](https://m.media-amazon.com/images/I/81Z966FuA+L._SY522_.jpg)](https://www.amazon.co.jp/dp/B0CNZWPJQ2)

これまで、IT業界でアーキテクトというと、 システムアーキテクトを指すことが一般的だったと思います。<br />
その影響か、ソリューションアーキテクトという新しい役割に対して、実態と期待値にズレが起こりがちだったように思います。<br />
また、各クラウドベンダーもそれぞれの資格試験の中でソリューションアーキテクトという資格を設定しており、それもズレの元になっているように思います。<br />
私自身、著者の松下がSAとして参画しているプロジェクトに配属されており、松下の参画当初はスケーリングやSLAなどプロジェクトの課題となっていたり、なりそうな点を考慮した、AWSの設計に踏み込み、そこで成果を出してくれることを勝手に期待してしまいました。<br />
実際の著者の活躍と私が持っていた期待値のズレは、一緒に働く中で解消されましたが、本著を通してギャップなくプロジェクトにSAを迎えられるのではないでしょうか。

この本では、IT業界において比較的新しい役割であるソリューションアーキテクトについて、 著者自身の経験に基づいた解説がされています。
SAがやるべきこと、働き方、考え方がまとまっており、SAおよびSAを目指す人はもちろん、私のようにSAと一緒に働く人にとっても有用な本となっています。

プロジェクトにおいて、役割の責任範囲とその役割に対する期待値にギャップがあると、コミュニケーションやタスクの受け渡しがうまくいかず、プロジェクトの進行に淀みが発生してしまいます。
SAという役割が得意とする領域、責務を知り、業務における役割認識や期待値を揃えることは、円滑なプロジェクト進行の助けになります。

特に本書は価格・ボリュームも程よくまとまっており、ソリューションアーキテクトについて知りたい人向けの入門書としてとても良いと思いました。<br />
しかも、Kindle Unlimited を契約している Amazon Prime会員は、本書を無料で読めます。めちゃくちゃお得ですね。

本の具体的な内容はぜひ本書を手にとっていただきたいのですが、今回はこの書籍が誰にとって有用なのかを紹介します。

## 1. 自身のキャリアパスに悩むエンジニア

この本の1章には、ソリューションアーキテクトが、キャリアパスのどの辺りの位置にいて、どういう人に向いているか、どういう人に向いていないか、が書かれています。
SAを目指す人はもちろんなのですが、SAを目指さない人も、一度手にとってSAというキャリアパスが自分にとってアリかナシかを判断するのに役立つと思います。

プロジェクトの進行においてスコープアウトの重要性は一般的に触れられますが、本書でも以下のように説かれています。

> 「やらないこと・できないことを決める」という作業も要件定義では非常に重要です。

人生設計においてもこれは同様かと思います。その点で、SAについて知って判断する機会を得られると思います。

## 2. ソリューションアーキテクトと一緒に働くプロジェクトメンバー 

この記事冒頭で既に触れてしまいましたが、SAという役割に対して実態と期待値のズレを無くせます。
SAと一緒に働く人は、SAに何を期待できるのか、SAとしては何を期待されたいのかのすり合わせに役立つでしょう。

プロジェクトマネージャーは、プロジェクトを進める上で必要な能力に抜け漏れが無い様にチームの体制を組む必要があります。SAという役割が何をしてくれる人なのかを前提として把握して、さらに実際のSA個人が役割を越えたスキルを持っていて発揮してくれるのかを知ることが重要になるはずです。

また、他のプロジェクトメンバーにとっても、SAにどういったタスクをお願いできるのかを知っておくことは、ボールのパスミスを減らすという点で非常に役立ちます。

一緒に働くプロジェクトメンバーのことを知るために、ドラッカー風エクササイズのようなプラクティスが存在しますが、本書を読むこともその助けになるでしょう。

## 3. IT業界で働くジュニアやノービスといったこれからの成長に期待される人全般やその指導に当たる立場の人

本書には、SAに限らず著者がこれまで実践している仕事術・仕事への向き合い方・考え方がまとまっています。仕事術の専門書でない分、すぐに実践でき効果の大きいプラクティスが凝縮されていますし、SA以外の役割においても、著者の豊富な経験に裏付けされた仕事術は非常に役立ちます。

仕事術としては、当たり前のことが書かれているだけかもしれませんが、当たり前のことを全て実践するのは非常に難しいです。なので、 **まずは** 本書にまとまっている仕事術を身につけるところから始めると良いと思います。<br />
と言いつつ、朝のお散歩など、のほほんとした仕事術も紹介されてます。何故お散歩が仕事に影響するのか気になる方はぜひ本書をお手に取ってください。

## おわりに

私と著者は、同じプロジェクトで働いていると冒頭で述べました。
著者はいったいいつ本書を書く暇があったんだというぐらい、普段の業務でもパワフルに活躍されています。もちろん、働き方がパワフルなだけでなく、本書にまとまっている知見を存分に発揮して成果を出しています。
松下はモンスターラボの[Value](https://www.join.monstar-lab.com/mission-values)を体現し活躍している社員を四半期ごとに表彰するTHE BEST Monstars Awardにて、Do what's right賞を受賞しているモンスターラボ社員のロールモデルです。

そんな著者の経験と知識と熱意が詰まった本書をぜひお手にとっていただければと思います。

_Article Photo by [Olha Ruskykh](https://www.pexels.com/ja-jp/photo/5984617/)_


ソリューションアーキテクトについて知ろう。いい本が出たよ

技術の進歩によって現代は様々なコンテンツを見れるようになってきている中で、動画についてはTVからインターネットとプラットフォームへ変化してきています。

グローバル化も進み、国を超えて多様な動画を見るようになった今、言語という問題は楽しむことに大きな影響を及ばしています。

以前からこの問題に対してプロの翻訳家に依頼し、音声吹き替えや字幕のような形で解決していましたが、費用や品質に対しての課題が発生していました。ITを駆使して解決しようとする動きはあったもの、人と機械の間には品質において差があったため限界がある状況でした。

しかしながら、最近は人工知能（AI）を活用して、より精度の高い結果が出せるようになってきています。
本ブログではその一つであるOpenAIのWhisperを利用した字幕起こしについて紹介します。

# 字幕とは
字幕は、以下のように定義されています。

> 字幕（じまく）は、映像（動画）上に表示される文字情報および、その技術のことである。一般的な情報の提示のほか、映像本来の音声を何らかの理由で利用できない利用者のために表示される。
> 
> https://ja.wikipedia.org/wiki/%E5%AD%97%E5%B9%95

補助手段として利用されるものも、精度によっては動画の理解に大きな影響を及ぶこともあるものになります。

## 自動字幕起こしとは
音声を自動的に字幕に変換することを意味します。
メディアから音声を分析してテキストで読めるようにするものです。

今回はOpenAIのWhisperを利用し、実践していきます。

# OpenAI Whisper
OpenAIのWhisperは以下のように紹介されています。
> We’ve trained and are open-sourcing a neural net called Whisper that approaches human level robustness and accuracy on English speech recognition.
> 
> https://openai.com/research/whisper

OpenAIが研究し、Open Sourceとして公開されていますので、Githubから誰でも確認できます。

> [whisper](https://github.com/openai/whisper)

## 仕組み
<img src="https://raw.githubusercontent.com/openai/whisper/main/approach.png">
まずは一定の幅でメディアを分割し、言語の分析と文字起こしを行って正しい時間を付与して字幕を作成しています。

### メディアの分割
メディアを丸ごと処理して字幕を作成しているわけではなく、最大30秒という時間軸で分割して一つ一つ字幕を作成していきます。

### 言語の分析
パラメータとしてメディアの言語が指定されている場合はスキップされます。

言語を指定しないこともでき、その場合はこの段階で言語を検知して字幕を作成します。

### 文字起こし
この段階でWhisperのModelを利用して音声がテキストに変換されます。

Whisperには英語への翻訳機能もあり、利用設定をした場合はここで音声が英語に翻訳されたテキストで出力されます。

### 時間を付与
テキストの結果に時間情報を組み合わせてテキストをまとめます。終わったら最初に戻って次のトークンを遂行します。

# Setup
PyTorchが駆動できる環境を必要とするので、以下のWhisperのSetupに従って構築しましょう。

> [Setup](https://github.com/openai/whisper/tree/main#setup)

## モデルについて
Whisperをどのモデルで実行するかによって字幕の質が変わります。
基本的に提供されるモデルには色々な種類がありますので、こちらから選んで始めてみましょう。

[Available models and languages](https://github.com/openai/whisper/tree/main#available-models-and-languages)
> | Size   | Parameters | English-only model | Multilingual model | Required VRAM | Relative speed |
> |--------|------------|--------------------|--------------------|---------------|----------------|
> | tiny   | 39 M       | tiny.en            | tiny               | ~1 GB         | ~32x           |
> | base   | 74 M       | base.en            | base               | ~1 GB         | ~16x           |
> | small  | 244 M      | small.en           | small              | ~2 GB         | ~6x            |
> | medium | 769 M      | medium.en          | medium             | ~5 GB         | ~2x            |
> | large  | 1550 M     | N/A                | large              | ~10 GB        | 1x             |

Sizeはtinyからlargeまであり、要求されるVRAMと文字起こしの速度が異なります。

Whisperを実行しようとするマシンのスペックによって、適切なモデルを選ぶことになります。largeであるほど字幕の質が良いものになる可能性は高くなります。

また、Modelのパラメータによって、表記より多く必要とされることもありますので、実際に実行してみながら確認しましょう。

# やってみる
Setupを終えて利用するモデルが決まったら、いざ実行です。

## Whisper using CPU
AI駆動には専用のデバイスが必要と聞いた方もいるかもしれません。ただ、汎用的な演算装置であるCPUでも駆動してみることはできますので、こちらからやってみましょう。

### 実行環境
- MacBook Pro 13-inch, 2020
- macOS 12.6.7
- Python 3.9
- Whisper v20231117

### 実行
OpenAI WhisperのGithub レポジトリのサンプルを実行してみましょう。
```python
import whisper

model = whisper.load_model("base")
result = model.transcribe("jfk.flac")
print(result["text"])
```
> **_Note:_** AudioファイルはWhisperのGithubレポジトリのtestsのフォルダーにあるjfk.flacを利用しています。

```zsh
% python3 sample1.py
/Users/gwanmuk_kang/Library/Python/3.9/lib/python/site-packages/whisper/transcribe.py:115: UserWarning: FP16 is not supported on CPU; using FP32 instead
  warnings.warn("FP16 is not supported on CPU; using FP32 instead")
 And so my fellow Americans, ask not what your country can do for you, ask what you can do for your country.
```

最後の行にAudioファイルがテキストに変換されていることが確認できます。

Warningが出力されていることも確認できますが、Whisperのデフォルト設定がGPUを想定しているのでCPUで実行した際には設定が変更されるという内容になります。

次は日本語の音声ファイルを実行してみます。

```python
import whisper

model = whisper.load_model("base")
result = model.transcribe("rusuden_04.wav")
print(result["text"])
```
> **_NOTE:_**
日本語音声は、[あみたろの声素材工房](https://amitaro.net/voice/voice_dl/)でダウンロードしています。

実行した結果は以下になります。

```zsh
お電話ありがとうございます大変申し訳ございませんが本日の影響は全て終了させていただきましたまたのお電話をお待ちしております
```
問題なく作成されたことがわかります。

次はもっと長い音声でやってみましょう。


```python
import whisper

model = whisper.load_model("base")
result = model.transcribe("japanese-conversation-23645.mp3")
print(result["text"])
```
> **_NOTE:_** 
> 日本語音声は、[pixabay](https://pixabay.com/sound-effects/search/japanese/)でダウンロードしています。

結果は次のようになります。

```zsh
介石長ドレ sir attending Nahはいじゃあ 者さんのおごどら應該全部折菩すいませんと。キュウシュメン分けに行かないので知してください。さわ eli、いただきます。てことを� Sharline Line Flash給批が練した日の James B executiveの本名は翻ね落下了 forし敢用をrus連園浴様ですコンマイチ星ハイ合字を描いて教えてどうもあれはそうです。どこに出したことで、こっちは電源を間に当たした。あげろと。安心してくるな。あんたの側に動き地に話し付けてきました。さらに、やっぱりセイスだす。もういこう、もう無駄に出来しまえんで。そこで帰って、よくすぐにといて帰りながら行きましょう。そんな話見てやるんすね。どうも!
```

理解できない日本語が出力されています。今まで利用していたbaseのモデルでは正確さに限界があるので、次はモデルをlargeに変えて実行してみます。

```python
import whisper

model = whisper.load_model("large")
result = model.transcribe("japanese-conversation-23645.mp3")
print(result["text"])
```

時間はかなりかかりますが、結果は次のように良くなったことがわかります。

```zsh
はい、じゃあちょっと良くなったらお願いします。はい、じゃあ皆さん戻られたらお待ちしていただきます。はい、ではテスト行きます。ちょっと奥にあるのでありますが、テストいただきます。テスト、よーい、はい。彼女を連れ回して申し訳ありません。ぜひ、仕事に追われて、調整した彼女を見ていただいたら、気持ちもある。いかがしてくれるでしょうか。そうですな。どんなサボった味でこっちは天や万やだしたか。まあ、けど安心してください。はい。あんたの代わりに、ご機嫌、きっちり話しつけときました。三年契約成立がする。もう一個も無駄にできてしまえんで、さっさと帰って、曲作りに取りに行って帰りながらやるでしょう。え、あんたの契約?そんな話聞いてないのですかよ。ちょっとお待ちください。君は彼女の彼女に雇われているんだろう。
```

テキストの結果は確認できています。次はここから字幕のファイルを作成してみます。

```python
import whisper
from whisper.utils import get_writer

model = whisper.load_model("large")
result = model.transcribe("japanese-conversation-23645.mp3")

# save the result to srt file
writer = get_writer("srt", "./")
writer(result, "japanese-conversation-23645.srt")
```

> **_NOTE:_** utilsにあるWriteSRTを利用しています。

```srt
1
00:00:00,000 --> 00:00:15,920
はい、じゃあちょっと良くなったらお願いします。

2
00:00:19,920 --> 00:00:22,420
はい、じゃあ皆さん戻られたらお待ちしていただきます。

...省略...

22
00:01:45,760 --> 00:01:46,500
ちょっとお待ちください。

23
00:01:47,960 --> 00:01:50,000
君は彼女の彼女に雇われているんだろう。
```

発話者ごとに字幕が作られています。時間は概ね合っていますが、雑音まで含めてしまったので正確な時間であるとは言えない結果になりました。

ここで、transcribeのword_timestampsをtrueに指定するともっと時間が正確になる可能性があるので、試してもいいでしょう。

> word_timestamps: bool
> 
> Extract word-level timestamps using the cross-attention pattern and dynamic time warping, and include the timestamps for each word in each segment.
>
> https://github.com/openai/whisper/blob/e58f28804528831904c3b6f2c0e473f346223433/whisper/transcribe.py#L87

今までは、CPUを利用してWhisperを駆動してみました。結果の品質をあげようとするとそれなりの時間を要することにもなります。

CPUは汎用的な演算を前提にしているため、早めにAIの演算を遂行するために専用的なデバイスを利用することも可能です。

その中で、比較的に接しやすいGPUを利用してまた実行してみます。

# Acceleration with GPU
GPGPUと呼ばれるもので、CPUの演算の一部をGPUに担当させる技術を意味します。

このために各GPUのVendorから公表されている技術があり、NVIDIAのCUDAやAMDのROCmがその例です。

## Whisper with CUDA
PyTorchはCUDAにも対応していて、WhisperもCUDAで学習しているので比較的に使いやすい所があります。

> [PyTorch](https://pytorch.org/get-started/locally/)

NVIDIAのデバイスをお持ちの方は試してみてもいいでしょう。

## Whisper with ROCm
AMDではNVIDIAのCUDAに対抗してROCmを発表しています。

Whisperが利用しているPyTorchはROCmもサポートしているため、実行してみることができます。ただ、リファレンスなどはCUDAよりサポートが弱いこともあるので試行錯誤が必要です。

筆者のGPUでは、PyTorch 1.13とROCm 5.2の組み合わせで実行させることができました。

インストールは以下のようにできます。

```zsh
pip install torch==1.13.1+rocm5.2 torchvision==0.14.1+rocm5.2 torchaudio==0.13.1 --extra-index-url https://download.pytorch.org/whl/rocm5.2
```

ROCmがCUDAと交換性があるので実行できますが、バージョンによってはできなくなるなどが発生されますので、検証して利用しましょう。

# まとめ
AIの研究進み、AIの発展によって様々な開発がされています。グローバルな時代で言語よる障壁はAIでサポートすることが可能になってきています。

未熟な部分もありつつ、十分に利用可能な領域まで発展されていると感じられています。

今回は字幕というテーマでOpenAIのWhisperを利用してみて、どのような結果が得られるかを試しました。

字幕の品質を向上するために、設定値を変更するかAIモデルをチューニングすることも可能で、いずれ紹介できればと思っています。

これからAIの発展に伴い、どのようにAIを活用していけるか考えていきましょう。


Whisperを利用して字幕を作ってみましょう

モバイルアプリ・AI知識の強化-3Dメガネ


## はじめに

こんにちは！
Backendチーム所属の森田です。  
最近少し関わった案件で、「Azureのソリューションを使った、グローバルな（リージョン間の）負荷分散を実現したWebアプリケーションを構築したい」というものがありました。  
グローバルな負荷分散について検討するのは初めてだったため色々と調べていたのですが、その中でAzure Front Door周りの挙動で気になる部分があったため共有いたします。  
お話の内容としては「Azure Front DoorはWebSocketに対応していないと言っているけど、実は対応しているのでは？」という内容です。  

## どんな人がターゲットか

- Azure Front Doorを使ったL7でのリージョン間負荷分散がしたい人
- WebSocketを使ったWebアプリケーションを負荷分散できるようにしたいが、Azure Front Doorが対応していないっぽくて気になっていた人

## おさらい：リージョン間の負荷分散の選択肢について

Azureでリージョン間の負荷分散を実現するためには、以下のようなものを選択することができます。

| サービス | グローバル | 推奨されるトラフィック|
| ---- | ---- | ---- |
|Azure Front Door|グローバル|HTTP(S)|
|Azure Traffic Manager|グローバル|非HTTP(S)|
|Azure Load Balancer|リージョン/グローバル|非HTTP(S)|
|Azure Application Gateway|リージョン|HTTP(S)|

それぞれのサービスについての詳細と、どのようなケースで使うのが良いかについては、以下の公式ドキュメントに記載されています。  
https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview

サービスを分類するための2つの次元について簡単に説明すると、「グローバルな（リージョン間での）負荷分散ができるかどうか」と「HTTP(S)以外のトラフィックを扱えるかどうか」の2つです。  
1つめの次元、「グローバルな（リージョン間での）負荷分散ができるかどうか」について見てみると、Azure Application Gateway以外の3つのサービスがグローバルな負荷分散を実現できることがわかります。  

2つめの次元、「HTTP(S)以外のトラフィックを扱えるかどうか」について見てみましょう。  
非HTTP(S)な通信（ソケット通信など）を使いたい場合は、Azure Traffic ManagerかAzure Load Balancerを使うことになります。  
逆に、Azure Front DoorとAzure Application GatewayはL7レイヤーのロードバランサーなので、HTTP(S)通信を扱う場合はこの2つのサービスが候補に入ってきます。  

これらのサービスは1つだけを選択するだけではなく、組み合わせて使うこともできます。  

みなさんがアプリケーションを構築したいとき、どのような負荷分散オプションを使用すればよいか（あるいは組み合わせればよいか）は[こちらのデシジョンツリー](https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview)によくまとまっています。

## Webアプリケーションをグローバルに負荷分散したい場合は何を選ぶべきか

先程リンクを張ったデシジョンツリーを見ると、Webアプリケーションをグローバルに負荷分散したい場合はAzure Front Door(もしくはそれと他のサービスの組み合わせ)を使用するのが良さそうです。

実際、Azure Front DoorはCDNの機能も有しており（以前はAzure CDN Standardが提供していましたが、Front Doorに統合されました）、WAF(Web Application Firewall)も提供しています。  
AzureでWAFを使いたい場合、Front DoorかApplication Gatewayの2つの選択肢が存在しますが、Application Gatewayはリージョン内での負荷分散をするものなので、グローバルな負荷分散をしたい場合はFront Doorを選択するほうが適切です。  
SSL終端処理もできますし、パスベースのルーティングやキャッシュ、高速フェールオーバーなどL7ロードバランサーとしての機能は非常に充実しています。  

上記の理由からWebアプリケーションをグローバルに負荷分散したい場合はFront Doorを使えば問題ないように見えますが、公式ドキュメントを見ると気になる文言があります。  

## 疑問：Azure Front DoorではWebSocketをサポートしていない？

前のセクションでリンクを貼った公式ドキュメントには、2023年9月現在、重要な一文があります。  

```
現時点では、Azure Front Door では Web ソケットをサポートしていません。
```

最近のWebアプリケーション（特にチャット機能を持つもの）ではWebSocketを使うことはよくあることで、これがサポートされていないのはかなり気になるところです。  
以下は直近1年でMicrosoftに寄せられたQAの一例ですが、コメント等を見ればわかるようにかなり多くの開発者がこの件について不満に思っていたことがわかります。  
https://learn.microsoft.com/en-us/answers/questions/1051011/azure-front-door-web-socket-connectivity-issue
https://github.com/MicrosoftDocs/architecture-center/issues/4011

少なくとも2022年10月の時点では、Microsoftから「WebSocketについてはサポートしていない」という回答が出ています。  

しかしながら、以下の機能リクエストに気になるコメントが付いていることを見つけました。  
https://feedback.azure.com/d365community/idea/c8b1d257-8a26-ec11-b6e6-000d3a4f0789

```
Azure Front Door now supports WebSocket connections, enabling real-time, bidirectional communication for interactive web applications, such as live chats and online gaming, enhancing user experience and engagement.

```

Front DoorでWebSocketがサポートされた、というコメントです。  

一方でその直後に
```
Just checked with Microsoft team. No WebSocket support so far. 
```

というコメント（訳：公式に聞いてみたがサポートされていないみたいだよ）も付いており、見ただけでは果たしてWebSocketがサポートされているのかいないのか、よくわかりません。  
そこで、実際に簡単なWebSocketを使ったチャットアプリケーションを作成、デプロイし、Front Door経由でアクセスしてみることで検証してみます。  


## Front DoorがWebSocketをサポートしていないのか試してみる

### 前提条件

- 簡単なWebSocketを使ったアプリケーションをデプロイし、Front Doorからアクセスして検証してみる
- グローバルな負荷分散については一旦考慮しない
  - 本来なら実施したかったのですが、WebSocketを複数サーバ間で伝播させるためにはRedisやMQTTなどを用いてサーバー間の連携を行う必要があり、時間がかかりそうだったため一旦スコープ外としています。
- WebアプリケーションはContainer Appsに配置する

### テスト用のチャットアプリの作成とデプロイ

まずは施行するためのアプリケーションを作成します。  
今回の主眼は「Azure Front Doorは本当にWebSocketをサポートしていないのかを検証すること」なので、検証用のアプリケーションはごく簡単なものを使います。  
Socket.ioの公式ページにある、[チャットアプリケーション](https://socket.io/get-started/chat/)を使います。  
```index.js
const express = require('express');
const app = express();
const http = require('http');
const server = http.createServer(app);
const { Server } = require("socket.io");
const io = new Server(server);

app.get('/', (req, res) => {
  res.sendFile(__dirname + '/index.html');
});

io.on('connection', (socket) => {
    socket.on('chat message', (msg) => {
      console.log('message: ' + msg);
      io.emit('chat message', msg);
    });
  });

server.listen(8080, () => {
  console.log('listening on *:8080');
});
```

```index.html
<!DOCTYPE html>
<html>
  <head>
    <title>Socket.IO chat</title>
    <style>
      body { margin: 0; padding-bottom: 3rem; font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; }

      #form { background: rgba(0, 0, 0, 0.15); padding: 0.25rem; position: fixed; bottom: 0; left: 0; right: 0; display: flex; height: 3rem; box-sizing: border-box; backdrop-filter: blur(10px); }
      #input { border: none; padding: 0 1rem; flex-grow: 1; border-radius: 2rem; margin: 0.25rem; }
      #input:focus { outline: none; }
      #form > button { background: #333; border: none; padding: 0 1rem; margin: 0.25rem; border-radius: 3px; outline: none; color: #fff; }

      #messages { list-style-type: none; margin: 0; padding: 0; }
      #messages > li { padding: 0.5rem 1rem; }
      #messages > li:nth-child(odd) { background: #efefef; }
    </style>
  </head>
  <body>
    <ul id="messages"></ul>
    <form id="form" action="">
      <input id="input" autocomplete="off" /><button>Send</button>
    </form>
    <script src="/socket.io/socket.io.js"></script>
    <script src="/socket.io/socket.io.js"></script>
    <script>
      var socket = io();
    
      var messages = document.getElementById('messages');
      var form = document.getElementById('form');
      var input = document.getElementById('input');
    
      form.addEventListener('submit', function(e) {
        e.preventDefault();
        if (input.value) {
          socket.emit('chat message', input.value);
          input.value = '';
        }
      });
    
      socket.on('chat message', function(msg) {
        var item = document.createElement('li');
        item.textContent = msg;
        messages.appendChild(item);
        window.scrollTo(0, document.body.scrollHeight);
      });
    </script>
  </body>
</html>
```

完全なコードを確認したい場合は、以下のリポジトリを参照ください（殆ど上記のリンクそのままです）
https://github.com/Kent-Morita/test-ws-app

localhostで`node index/js`を実行して動作確認すると、以下のような画面が表示されます。  
![localhostで動いています]({{ sitePrefix }}/assets/img/articles/2023-10-05-Use-WebSocket-APP-On-Azure-Front-Door/localhost.webp)
どうやら、localhostではきちんと動いているようです。  

続いて、Dockerfileを作成して、アプリケーションをコンテナ化します。  
コンテナ化が完了したら、作成したアプリケーションをAzure Container Appsで動くように、Container Appsを作成します。  
以下の公式ドキュメントを元に、Container Appsを作成します。  
https://learn.microsoft.com/ja-jp/azure/container-apps/tutorial-code-to-cloud?tabs=bash%2Ccsharp&pivots=acr-remote

詳細はリンクを参照いただければと思いますが、簡単な流れを記載します。  

- Azure CLIをインストールしておく（やっていなければ）
- リソースグループを作成する
- Azure Container Registryを作成する
- アプリケーションをビルドする
- Container Apps環境を作成する
- Container Appsにデプロイする

上記が完了すると、先程ローカルホストで確認したものと同じようなアプリケーションが公開されていることがわかります。  

![containerAppsでも動いています]({{ sitePrefix }}/assets/img/articles/2023-10-05-Use-WebSocket-APP-On-Azure-Front-Door/containerapps.webp)

### Front Doorを作成する

https://learn.microsoft.com/ja-jp/azure/frontdoor/create-front-door-portal#create-front-door-profile---quick-create
上記のリンクを参考に、Front Doorプロファイルを作成します。  

![できました]({{ sitePrefix }}/assets/img/articles/2023-10-05-Use-WebSocket-APP-On-Azure-Front-Door/frontdoordeployed.webp)

### 実際にアクセスしてみて試してみる

作成したFront DoorのURLにアクセスして、動いているかを確認します。  

![動いている]({{ sitePrefix }}/assets/img/articles/2023-10-05-Use-WebSocket-APP-On-Azure-Front-Door/frontdoor.webp)

動いています。  
Azure Front Door経由でWebSocket通信ができていることが確認できました。  
別ブラウザ及び別端末からも試してみましたが、通信ができているようです。  

## まとめ

Azure Front DoorがいつWebSocketに対応したのかについては定かではなく（確認できる限りでは、2023年8月頃から対応していた可能性があります）、今回の検証だけでは不足している部分もあるかと思いますが、少なくとも公式ドキュメントの記載は現時点では正しくないように見えています。  

このサポートにより、今までFront Doorを採用することが難しかった双方向コミュニケーションのためのWebアプリケーションにおいてもFront Doorを採用することが可能になりますし、WebアプリケーションをL7でグローバルに負荷分散したい場合、より多くの場合でFront Doorを使うことができるようになるはずです。  
Microsoft公式から発表が出るまでは断言ができないところですが、今までWebSocketが使えないことを理由に、Front Doorを使わずApplication Gatewayを（無理やり）使っていた皆さんは一度試してみても良いと思います。

## 参考

https://learn.microsoft.com/ja-jp/azure/architecture/guide/technology-choices/load-balancing-overview

Azure FrontDoorは実はWebSocketをサポートしているのではないか？

Flutterを使用したデスクトップアプリの構築：チュートリアル

モバイルアプリ・AI知識の強化

ブロックチェーンを通じてモバイル アプリケーションを強化する: 私たちの旅 パート2


# 序章

急速にデジタル化が進む世界において、安全で透明性のある分散型の運用モードの必要性はますます高まっています。それがブロックチェーンの領域です。ブロックチェーンは、世界中の産業に革命をもたらした画期的な技術です。しかし、モバイルアプリケーションとの関係はどのようなものなのでしょうか？さらに深く探ってみましょう。

ブロックチェーンは、その核となる分散型台帳であり、暗号化を用いて保護された連続的に成長する記録のリスト（ブロック）を維持します。ブロックチェーンの最も魅力的な特徴は、データの改変に対する無傷性であり、信頼性、透明性、セキュリティを持つ技術です。

ブロックチェーンの骨格を背負っている Web3 という概念に出会います。Web3 または Web 3.0 は、分散化の原則に基づいて構築された新しいインターネットの時代を代表しています。Web3 は、ユーザーが自分自身のデータと相互作用を制御するオンライン環境を作り出すことを目指しており、これはブロックチェーンと本質的に相互に共生する概念です。

それに基づいて、ブロックチェーンと Web3 をモバイルアプリに統合することは、様々な産業において革新をもたらすと期待されており、非常に大きな可能性を秘めています。その影響が見られるであろう主な領域には、分散型金融、アプリ内デジタルアイデンティティまたは分散型ソーシャルネットワークなどがあります。

そのため私たちはこの技術が近い将来、モバイルアプリへの活用がされると考え、チーム内でキャッチアップすることにしました。基本的にはブロックチェーンとの実験環境を作り上げ、経験を積むことができるようにまずは簡単なプロジェクトを作成することで、将来のプロジェクトに活用することも視野に入れました。

次のセクションでは、ブロックチェーンに関連するいくつかの重要な用語を紹介し、私たちの市役所アプリがブロックチェーンを活用するアイデアを共有します。ゆくゆくは、パート 2 にて開発プロセスと技術的な背景を公開する予定です。

この旅は、モバイルアプリの領域におけるブロックチェーン技術の未来と、デジタルプラットフォームとの関わり方を革新する可能性についての洞察を提供します。それでは、ブロックチェーンとモバイル・アプリケーションの興味深い世界へ、探検を進めましょう！

# 新しい専門用語

### dApps

dApps は**分散型アプリケーション**（Decentralized Applications）の略称です。dApps は通常、ブロックチェーン技術を活用した分散型ネットワーク上で実行されるソフトウェアアプリケーションです。従来のアプリケーションが中央集権的なサーバーに依存するのに対し、dApps はデータやトランザクションが複数のノードに分散されたネットワーク上で動作します。ノードとは、ブロックチェーン全体のコピーを保持し、トランザクションの妥当性を検証するコンピュータやデバイスのことです。

主な特徴：

- **分散化**：dApps は分散型ネットワーク上で動作するため、単一の制御点や障害点が存在しません。アプリケーションのロジックとデータはブロックチェーンや類似の分散型台帳技術に格納され、処理されます。

- **オープンソース**：dApps はオープンソースでもあり、そのソースコードは一般に公開されており、透明性があります。

- **トークン化**：多くの dApps は独自のトークンや仮想通貨を持っており、アプリケーション内でのトランザクションを容易にしたり、所有権や価値を表現したりします。

- **スマートコントラクト**：dApps におけるスマートコントラクトは、ブロックチェーン上で事前に定義されたルールを自動的に実行するプログラムです。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2023-07-12-Empowering-Mobile-Applications-through-Blockchain-Our-Journey-Part-1/image1.png>
<figcaption>分散型アプリケーション（dApps）のイメージ、 ソース: https://cryptoadventure.com/wp-content/uploads/2020/06/dapps-developpment.jpg</figcaption>
</figure>

このブログでは、**分散化**された機能と**スマートコントラクト**を備えたシンプルな dApp の開発について説明します。

### スマートコントラクト

スマートコントラクトは、複数の当事者間の契約や合意の条件を自動化し、検証し、強制するコンピュータプログラムです。それは、条件と規定が直接コードに書き込まれた自己実行契約です。

スマートコントラクトの主な特徴は次のとおりです：

- **自動化**：スマートコントラクトは、事前に定義された条件が満たされた場合、自動的なアクションやトランザクションを実行します。コード自体が条件を強制するため、仲介者や中央権限の必要性がなくなります。

- **デジタルと変更不可能**：スマートコントラクトは、コードで書かれたデジタル形式で存在し、ブロックチェーンに保存されます。一度展開されると、コードは変更や改ざんができない不変性を持ちます。

- **分散化**：スマートコントラクトは、複数の参加者がトランザクションを検証し記録するブロックチェーンなどの分散型ネットワーク上で動作します。この分散化の性質により、透明性が確保され、単一の中央権限の必要性が排除されます。

- **信頼とセキュリティ**：スマートコントラクトは、暗号技術を活用してトランザクションを保護し、当事者が契約の実行と結果を信頼できるようにします。ブロックチェーンの分散型コンセンサスメカニズムは、追加のセキュリティ層を提供します。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2023-07-12-Empowering-Mobile-Applications-through-Blockchain-Our-Journey-Part-1/image2.webp>
<figcaption>Polygonscanに展開されたスマートコントラクトの例</figcaption>
</figure>

このブログで説明されているプロジェクトでは、スマートコントラクトを展開し、ブロックチェーンにレコードを追加するために、[Metamask](https://metamask.io/) で **ウォレット** を作成しました。

### ウォレット

Web3 ウォレットは、個人が分散型の世界でデジタルアイデンティティ、資産、および相互作用を制御するための暗号化ツールです。セキュアなキー管理、認証メカニズム、ユーザーフレンドリーなインターフェースの組み合わせを包含し、ユーザーがブロックチェーンベースの資産を安全に保管、送信、受け取り、管理できるだけでなく、dApps やブロックチェーンネットワークとシームレスに対話することができます。

このブログで説明されているプロジェクトでは、Metamask でウォレットを作成しました。Metamask は、ブラウザ拡張機能を介してユーザーとブロックチェーンネットワークとの橋渡しとして機能します。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2023-07-12-Empowering-Mobile-Applications-through-Blockchain-Our-Journey-Part-1/image3.webp>
<figcaption>Metamask, https://metamask.io/</figcaption>
</figure>

スマートコントラクトの作成、トークンの送信、レコードの追加など、ブロックチェーンに変更を引き起こすすべての操作は、Metamask ウォレットで表示される**トランザクション**に記録されます。

### トランザクション

トランザクションは、ブロックチェーンで実行される操作です。このような操作はスマートコントラクトとの対話を含み、指定された関数呼び出しとパラメータに従ってコントラクトのコードが実行されます。スマートコントラクトは内部の状態を変更し、残高を更新し、イベントを発行したり、トランザクションのロジックに基づいてさらなるアクションをトリガーすることがあります。

ブロックチェーンネットワークでトランザクションが発生すると、以下の手順が行われます：

1. **開始と検証**：トランザクションは、ユーザーまたはアプリケーションによって作成され、開始されます。その後、トランザクションはブロックチェーンネットワークにブロードキャストされ、検証プロセスを経ていきます。マイナー（プルーフオブワークネットワーク）またはバリデータ（プルーフオブステークネットワーク）は、送信者が十分な資金を持っているか、トランザクションの形式が正しいか、ネットワークのコンセンサスルールによって課される追加の条件が満たされているかを確認し、トランザクションの正当性を検証します。

2. **ブロックへの含蓄**：トランザクションが検証されると、他の検証済みトランザクションと共にグループ化され、ブロックを形成します。ブロックにはトランザクションのコレクションが含まれ、ブロックチェーン上で永久的な記録として機能します。

3. **マイニングまたはブロックの最終化**：ブロックチェーンにおけるマイニングは、トランザクションの検証とそれらをブロックチェーンに追加するプロセスであり、そのための報酬を獲得することです。一方、ブロックチェーンのマイナーは、計算能力を使用してトランザクションを検証し処理し、ブロックチェーンに追加し、ネットワークのセキュリティとコンセンサスを確保する参加者です。彼らはその取り組みに対して暗号通貨で報酬を受け取ります。プルーフオブワークネットワークでは、マイナーは計算作業を必要とする暗号パズルの解決を競います。最初にパズルを解いたマイナーが新しいブロック（トランザクションを含む）をブロックチェーンに追加します。プルーフオブステークネットワークでは、バリデータは自分のステークと選択アルゴリズムに基づいてブロックを追加する順番を決めます。

4. **コンセンサスと確認**：新しく追加されたブロックはネットワーク内の他のノードに伝播され、彼らはその含蓄を検証し確認します。確認とは、トランザクションを含むブロックの上に追加された後続のブロックの数を表します。トランザクションが受け取る確認の数が多いほど、そのトランザクションの確定性とセキュリティは高まります。

5. **ブロックチェーンの状態の更新**：トランザクションが実行されると、ブロックチェーンの状態が変更されます。これには、口座残高の更新、スマートコントラクトの状態の変更、およびトランザクションに関連するイベントやログの記録などが含まれます。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2023-07-12-Empowering-Mobile-Applications-through-Blockchain-Our-Journey-Part-1/image4.webp>
<figcaption>スマートコントラクトのトランザクションのリスト</figcaption>
</figure>

このブログで説明されているプロジェクトでは、以下 2 種類のトランザクションに実行しました：

- スマートコントラクトの展開時

- 年金や税金の記録をブロックチェーンに追加するために、ブロックチェーンの状態を更新するメソッドを呼び出す際

### 私たちのアイデア：市役所の住民税記録アプリ

このブログ投稿でのプロジェクトは、ユーザーがブロックチェーンに保存されている年金と税金の記録を確認できるモバイルアプリです。わかりやすいように、このアプリをマネキンと呼んでいます。Manekin は **Money（お金）と Kin（金）** を組み合わせたものです。

私たちは、今後はこのようなアプリが、従来のクラウドベースのシステムではなく、ブロックチェーンベースのシステムで開発される可能性があると考えました。なぜなら、年金や税金の記録をブロックチェーンに保存することで、信頼性とセキュリティが向上するからです。特に、ブロックチェーンから取得したデータは不変で信頼性があります。ただし、ブロックチェーン技術はすべての種類のアプリケーションに適しているわけではなく、実際の製品ではスケーラビリティやパフォーマンスなどの制約も考慮に入れる必要があります。

以下は、私たちのアプリの主な特徴です：

- **ユーザー認証**
  - アプリでは、ユーザーがユーザー ID を入力することで認証できるログインプロセスを提供しています。
  - ユーザー ID は QR コードをスキャンするか、テキストフィールドを介して手動で入力することができます。
  - ユーザー認証により、認可された個人のみが特定の記録にアクセスできるようになります。
  - ログアウトプロセスにより、次回のログインまでレコードへのアクセスが停止されます。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2023-07-12-Empowering-Mobile-Applications-through-Blockchain-Our-Journey-Part-1/image5.webp>
<figcaption>私たちのアプリのモックアップ</figcaption>
</figure>

- **税金と年金記録の取得**
  - アプリはスマートコントラクト内のメソッドを呼び出し、ブロックチェーンとやり取りして、ユーザー ID に関連する記録を取得します。
  - 取得した記録には、支払金額、タイムスタンプ、貢献の種類（税金または年金）、および記録に関する関連情報のノートなどの詳細が含まれています。

<figure>
<img src={{ sitePrefix }}/assets/img/articles/2023-07-12-Empowering-Mobile-Applications-through-Blockchain-Our-Journey-Part-1/image6.webp>
<figcaption>私たちのアプリのモックアップ</figcaption>
</figure>

- **使いやすいインターフェース**
  - 使いやすく、直感的なインターフェースを提供しています。
  - アプリケーションはスマートコントラクトと通信し、ブロックチェーンテストネットワーク上に展開されます。これはすべて裏側で行われ、ユーザーは通常のデータベースのような体験ができます。
  - 使いやすいインターフェースとスマートコントラクトとのシームレスな統合により、アプリはユーザーが安全に自分の記録にアクセスして確認することができます。

# 市役所アプリを超えて

上記のアイデアは、デジタルアイデンティティとセキュリティの分野からのアイデアです。ここでは、ユーザーが個人データを制御し、従来の集中型認証システムに依存せずに情報がより安全になるという特徴があります。デジタルアイデンティティとセキュリティは、近い将来においてもブロックチェーン技術を活用した影響を受ける分野の一つです。他の分野からの例としては、以下のようなものが挙げられます：

1. **分散型ファイナンス（DeFi）**：銀行アプリが、ユーザーがスマートフォンから直接アクセスできる分散型金融サービス（貸出、借入、仮想通貨の取引など）を提供します。ブロックチェーンベースのスマートコントラクトにより、金融取引の透明性とセキュリティが確保され、仲介業者なしでP2Pのやり取りが可能となります。

2. **サプライチェーン管理**：ファッションブランドがブロックチェーン技術と統合されたアプリです。製品の由来や正当性をサプライチェーン全体で追跡・検証できます。この透明性により、偽造品の対策、公正な取引慣行の確保、消費者からの信頼向上に役立ちます。

3. **分散型ソーシャルネットワーキング**：Web3 を活用したモバイルアプリは、ユーザーがデータと相互作用を制御できる分散型ソーシャルネットワーキングを実現します。コンテンツが分散型ネットワーク上に分散されるため、データ漏洩や検閲への懸念なく、ソーシャルプラットフォームに参加することができます。

4. **投票とガバナンス**：選挙アプリは、安全で透明性のある投票システムを実現し、選挙や意思決定プロセスの誠実さを保証します。分散化と不変性の原則に基づく Web3 技術は、ガバナンスにおける信頼と参加を高めます。

ブロックチェーンと Web3 がモバイルアプリとの統合により、ユーザー中心の安全で透明な体験の可能性が広がります。技術の進化とユーザーの採用増加に伴い、モバイルアプリとのインタラクション方法においてパラダイムシフトが起こることを期待できます。これにより、個々の人々が力を持ち、さまざまな産業が変革がもたらされます。

# つづく。。。

結論として、ブロックチェーン と Web3 のモバイルアプリへの統合は、技術とイノベーションの刺激的なフロンティアを示します。ブロックチェーン技術の分散型の性質と Web3 の原則の組み合わせにより、個人はデータ、プライバシー、デジタルインタラクションに対してより大きな制御権を持つことができます。

ブロックチェーン と Web3 のモバイルアプリにおけるポテンシャルは非常に大きく、技術の進化に伴い、さらに革新的なユースケースが期待されます。開発者や起業家たちはこれらの可能性を探求し、個人がデジタルライフにおいてより大きな制御と所有権を持つ分散型の未来への道を切り開いています。

次のブログでは、この新しく進化する技術を使用してアプリ開発をするための開発フェーズや取り組みについて詳しく掘り下げます。詳細を、お楽しみに！


ブロックチェーンを通じてモバイル アプリケーションを強化する: 私たちの旅 パート 1


こんにちは！モンスターラボで Backend チームに所属している植田です。
最近関わったプロジェクトで、gRPC を使おうという話があがったため、サクッと快適な開発環境を立ち上げる方法について、あれこれ試行錯誤をしました。
本記事ではその方法についてご紹介します。
コードは Connect-go のチュートリアルをベースとして使用しました。Dev Container でコンテナ開発環境を構築し、Air などを使用して Hot Reload を導入し、protoc-gen-validate を使用して validation を行うまでを紹介します。
開発環境の構築にフォーカスするため、gRPC、Connect に関する技術的な説明やアーキテクチャ設計や CI/CD に関しては本記事の対象外とします。
サンプルコードのリポジトリは[こちら](https://github.com/Yukio0315/connect-sample)です

## 目次

- 動作環境
- 技術スタック
- 動作方法
- 環境構築について
- VSCode Dev Container の初期設定
  - Features の導入
    - Oh My Zsh の設定
  - Extensions のインストール
  - Golang 開発用の Dockerfile の設定
- Connect-go の環境構築
  - Extensions の導入
  - サンプルコードの記入
  - Hot Reload の導入
  - リクエストバリデーション機能の追加
- 動作確認
- 終わりに

## 動作環境

下記の環境で動作検証をしております。

- M1 MacBook Pro (Ventura 13.4.1)
- Docker Desktop for Mac Version 4.20.1
- VSCode Version 1.79.2
- Dev Containers v0.295.0

## 技術スタック

- [VSCode Dev Containers](https://code.visualstudio.com/docs/devcontainers/containers)
- [Golang](https://go.dev/)
- [Air](https://github.com/cosmtrek/air)
- [Connect-go](https://connect.build/docs/go/getting-started)
- [protoc-gen-validate(PGV)](https://github.com/bufbuild/protoc-gen-validate)

## 環境構築について

個人的には快適な開発環境の条件は 3 つあると考えています。

1. 人間の注意力に頼らず、一定以上のコード品質を保てること
2. 書いたコードがすぐにコンパイルされて、フィードバックを得られること
3. 誰もが開発をすぐに始められること

これらを踏まえて gRPC の開発環境で実現するために、
IDE は VSCode Dev Container、言語は Golang, gRPC のライブラリでは Connect、Hot Reload の実現のために Air などのライブラリを選定しました。
今回選定したツールはデファクトスタンダードであることと、自分で使ってみて好みだったものを選定しています。

## VSCode Dev Container の初期設定

Dev Containers extension の Add Dev Container Configuration Files コマンドで作成した Go の[テンプレート](https://github.com/devcontainers/templates/tree/main/src/go)をベースにして、設定を追加します。
Container に Go の設定をインストールするため、Container の build は Dockerfile に設定しました。
その他の設定項目は主に以下の 3 つです。git の pre-commit の設定など、他にももっとやりたいことがありますが、gRPC 開発を走りだすことを最優先にし、最小限の構成に抑えました。

- Features を導入すること。
- VSCode の設定をし、Extensions を導入すること。
- Dockerfile に go の開発に必要なツール類をインストールすること。

### Features の導入

#### Oh My Zsh の設定

快適な Shell 環境を整えるために、 Oh My Zsh を採用しました。
Shell に関しては人それぞれこだわりがあると思うので、好きなものを採用するのが良いと思います。
Oh My Zsh を Dev Container に導入する方法は以下の 4 ステップです。

##### 1. Zsh と Oh My Zsh のインストール

Features として[common-utils](https://github.com/devcontainers/features/pkgs/container/features%2Fcommon-utils)のインストールすることで、この 2 つは導入できます。
Features に以下のように設定します。

`devcontainer.json`

```json
{
  // Features to add to the dev container. More info: https://containers.dev/features.
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {
      "configureZshAsDefaultShell": true
    }
  }
}
```

##### 2. default shell を zsh に設定

Dev Container の dockerfile に下記のスクリプトを書くことで、デフォルト shell を zsh に変更できます。
参考：[stack overflow](https://stackoverflow.com/questions/55987337/visual-studio-code-remote-containers-change-shell)

`.devcontainer/Dockerfile`

```Dockerfile
RUN echo "if [ -t 1 ]; then" >> /root/.bashrc
RUN echo "exec zsh" >> /root/.bashrc
RUN echo "fi" >> /root/.bashrc
```

##### 3. .zshrc に Oh My Zsh の設定を記載

.devcontainer の.zshrc に Oh My Zsh の設定を記載します。
記載内容は Oh My Zsh の [zsh-template](https://github.com/ohmyzsh/ohmyzsh/blob/master/templates/zshrc.zsh-template) を使用しました。

##### 4. .zshrc を container にコピー

最後に Dockerfile に以下の一文を追加し、container の home directory にコピーします。

`Dockerfile`

```Dockerfile
ADD .zshrc $HOME
```

### VSCode の設定をし、Extensions の導入

いよいよ VSCode の設定に入ります。まずは settings.json の設定ですが、公式の[Default settings](https://code.visualstudio.com/docs/getstarted/settings#_default-settings)を使用します。あとは個人の好みに合わせてカスタマイズしてください。
Extensions の導入ですが、ここは最も好みが反映される箇所です。自分の場合は以下のようにしました。
全て有名な Extensions だと思うので、それぞれの Extensions の詳細は省きます。
それぞれ必要の都度、設定ファイルに設定を書き込むことも忘れないようにします。

`.devcontainer.json`

```json
{
  // Configure tool-specific properties.
  "customizations": {
    "vscode": {
      "extensions": [
        "EditorConfig.EditorConfig",
        "streetsidesoftware.code-spell-checker",
        "wayou.vscode-todo-highlight",
        "ms-azuretools.vscode-docker",
        "shardulm94.trailing-spaces",
        "bungcip.better-toml"
      ]
    }
  }
}
```

### Golang 開発用の Dockerfile の設定

Golang 開発に欠かせないのが、Extensions の[Go](https://github.com/golang/vscode-go)です。
とりあえずこれだけインストールしておけば、開発はできます。

`.devcontainer.json`

```json
{
  // Configure tool-specific properties.
  "customizations": {
    "vscode": {
      "extensions": ["golang.go"]
    }
  }
}
```

Dockerfile には Extensions の Go が依存する gopls, dlv などをインストールし、その他必要そうなツールをインストールして、
Golang の開発環境は完成です。

`Dockerfile`

```Dockerfile
RUN go install github.com/cweill/gotests/gotests@latest
RUN go install github.com/josharian/impl@latest
RUN go install github.com/go-delve/delve/cmd/dlv@latest
RUN go install honnef.co/go/tools/cmd/staticcheck@latest
RUN go install golang.org/x/tools/gopls@latest
```

## Connect-go の環境構築

前章までで一通り Golang を動かせる環境が整ったので、ここからは Connect-go を動かせるようにします。
基本的に[チュートリアル](https://connect.build/docs/go/getting-started/)の通りにやれば簡単に動きます。

### Extensions の導入

Dockerfile にチュートリアルのように以下のコマンドを Dockerfile に書き込みます。

`Dockerfile`

```Dockerfile
RUN go install github.com/bufbuild/buf/cmd/buf@latest
RUN go install github.com/fullstorydev/grpcurl/cmd/grpcurl@latest
RUN go install google.golang.org/protobuf/cmd/protoc-gen-go@latest
RUN go install github.com/bufbuild/connect-go/cmd/protoc-gen-connect-go@latest
```

### サンプルコードの記入

あとはチュートリアルに従って、go.mod や buf.yaml, buf.gen.yaml を作成し、
本体のコードを書いて、main.go を run して動けば Connect-go の環境構築は完了です。

### Hot Reload の導入

快適な開発環境の構築に向けて、Hot Reload を導入します。
Hot Reload の導入には２ステップ必要です。

1. Code の自動生成
2. Golang コードの Hot Reload

#### Code の自動生成

Code の自動生成には`buf generate`コマンドを proto ファイル保存時に叩く必要があります。
そこで今回は VSCode Extensions の[Run on Save](https://github.com/emeraldwalk/vscode-runonsave)を使用しました。

使い方は単純で、devcontainer の extensions に `"emeraldwalk.RunOnSave"` を追加します。
そして設定を.vscode の settings.json に以下のように記載します。

```json
{
  // Run on Save
  // proto-gen
  "emeraldwalk.runonsave": {
    "commands": [
      {
        "match": "\\.proto$",
        "cmd": "rm -rf gen | buf generate"
      }
    ]
  }
}
```

この cmd では gen 配下のディレクトリを全て消去しています。これは`buf generate`コマンドでは誤って生成したファイルが消されないためです。

規模が大きくなってきたときはこの辺は少し見直さないといけない部分になります。

#### Golang の Hot Reload(Air)の導入

Golang の Hot Reload は[Air](https://github.com/cosmtrek/air)を導入しました。
インストール方法はいろいろありますが、Dockerfile に `RUN go install github.com/cosmtrek/air@latest`を記入すれば完成です。
あとは設定ファイルですが、`air init`コマンドを container 内で実行すれば、.air.toml ファイルが生成されるので、
[.air_sample.toml](https://github.com/cosmtrek/air/blob/master/air_example.toml)を参考に cmd などを変更します。

また、今回は`delay=500`に設定しています。もし delay がないと RunOnSave が動作したときに gen ディレクトリ配下のファイル を読み取ることができなくなってしまうためです。

Hot Reload 設定後は Container が立ち上がった後に Air が自動で立ち上がるようにします。
以下のように Dev Container の postStartCommand を使用します。

`devcontainer.json`

```json
{
  "postStartCommand": "air -c .air.toml"
}
```

これで Hot Reload の設定が全て完了しました。

### リクエストバリデーション機能の追加

ここからは実際に使うことを想定して、リクエストのバリデーション機能を追加してみます。
Connect のバリデーションには、[protoc-gen-validate(PGV)](https://github.com/bufbuild/protoc-gen-validate)を使用します。

Dockerfile に`RUN go install github.com/envoyproxy/protoc-gen-validate@latest`を追加します。
あとはドキュメントにある通り、buf.gen.yaml と buf.yaml に設定を追加しますが、この環境に合わせて、opt を追加することを忘れないように注意が必要です。

`buf.gen.yaml`

```yaml
plugins:
  - plugin: buf.build/bufbuild/validate-go
    out: gen
    opt: paths=source_relative
```

`buf.yaml`

```yaml
deps:
  - buf.build/envoyproxy/protoc-gen-validate
```

この後に`buf mod update`コマンドを実行し、`buf.gen.yaml` ファイルを生成します。
ちなみに`bef generate`を自動で動作させていると、Error メッセージを受け取ることができないので、要注意です。
うまく動かない場合は、手動でコマンドを動かすことをお勧めします。

それでは実際に Validation を働かしてみます。
`greet.proto` ファイルに validate を import し、GreetRequest に validation rule を以下のように変更します。

`greet/v1/greet.proto`

```proto
syntax = "proto3";

package greet.v1;

import "validate/validate.proto";

option go_package= "connect-sample/gen/greet/v1;greetv1";

message GreetRequest {
  string name= 1 [(validate.rules).string = {min_len: 5, max_len: 10}];
}

message GreetResponse {
  string greeting = 1;
}

service GreetService {
  rpc Greet(GreetRequest) returns (GreetResponse) {}
}

```

buf generate コマンドを起動すると、`gen.pb.validate.go`というファイルが生成されます。
ファイルの中身を読んでみるとわかるのですが、`GreetRequest`　 type struct に`Validate`や`ValidateAll`などのメソッドが定義されているため、
これを使用します。
以下のように Validate を追加しました。

```go
func (s *GreetServer) Greet(
 ctx context.Context,
 req *connect.Request[greetv1.GreetRequest],
) (*connect.Response[greetv1.GreetResponse], error) {
 if err := req.Msg.Validate(); err != nil {
  return nil, err
 }
 log.Println("Request headers: ", req.Header())
 res := connect.NewResponse(&greetv1.GreetResponse{
 Greeting: fmt.Sprintf("Hello, %s!", req.Msg.Name),
 })
 res.Header().Set("Greet-Version", "v1")
 return res, nil
}
```

これで Validation の設定は完了です。

## 動作確認

以下の３コマンドで動作確認ができます。

```shell
git clone https://github.com/Yukio0315/connect-sample

devcontainer open # if devcontainer CLI installed

root ➜ /workspaces/connect-sample (main) $ go run ./cmd/client/main.go
YYYY/MM/DD hh:mm:ss unknown: invalid GreetRequest.Name: value length must be between 5 and 10 runes, inclusive
```

これでサーバーが問題なく動作し、バリデーションも効いていることを確認できました。

## 終わりに

本記事では Connect-go を用いて快適な gRPC 開発環境を Dev Container で高速に立ち上げる方法について解説しました。
Lint や Hot Reload などを導入し、ある程度快適な環境を作れたと思います。
まだまだ足りない部分などがあるとは思いますが、最低限開発を始めるのに必要十分な環境を整えることができました。
この記事が gRPC 開発などの役に立てたら嬉しいです。

_Article Photo by [Simon Berger](https://unsplash.com/photos/aZjw7xI3QAA)_


Connect-goとVSCode Dev Containerを用いた快適なgRPC開発環境構築


私たちは毎日のように様々な場面で、"ねぇ Google"、"OK Google"、"音楽をかけて"、"電気をつけて" と音声アシスタント機能を使用していますが、その背景で何が起こっているのか考えたことはありますか？このようなシステムがどのように機能するかを調べるために、`ml-bot` という名前の小さなチャットボットを作りました。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/about-this-blog.webp)

# Dialogflow とは？

Dialogflow は Google の AI サービスで、多言語で利用できます。
これを使うことで、会話型の音声ボットやチャットボットを簡単に作ることができます。
最近では、高度でかつ高速な要望が増えてきており、ゼロからコードを書くことが難しくなってきています。ビジネスシーンでは、数時間から 1 日程度でボットのサンプルを作成する必要があるかもしれません。このような場合に Web やモバイルアプリへの組み込みが非常に簡単な Dialogflow の利用を検討することができます。

## Dialogflow のメリット

- ML/AI を採用
- 簡単に使える
- 複雑な会話を処理する
- 多くの言語で利用できる
- 他のツールとの統合がしやすい
- Webhook との連携が容易（Dialogflow システム内の特定のアクションに対する HTTP リクエストイベント）

# ダイアログフローサービスの種類

## 1. Dialogflow CX(カスタマーエクスペリエンス)

複雑な会話の流れのために設計は、会話の状態を管理するためにステートマシンを使用します。
以下は、ピザ配達における食品注文フローがどのようなものであるかの例です。食品注文システムは、Dialogflow CX が使用できるわかりやすい例だと思います。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/cx.webp)
_Image source: [Google](https://cloud.google.com/dialogflow/cx/docs/basics)_

## 2. ダイアログフロー ES(エッセンシャルズ)

Dialogflow の旧バージョンで、ES に改名されたものです。ボットを設計する際に、シンプルで小さなエージェントがあれば、ES を使うべきでしょう。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/es.webp)
_Image source: [Google](https://cloud.google.com/dialogflow/es/docs/basics)_

# Dialogflow はどこで使うべき？

- Slack のようなメッセージングツールは Dialogflow との統合が非常に簡単です。詳しくは[こちら](https://cloud.google.com/dialogflow/es/docs/integrations/slack)をご覧ください。
- 音声ボットは Dialogflow で簡単に作ることができ、あらゆるタイプのユーザーに対応することができます。
- モバイルアプリのプラットフォーム（Android、iOS、Flutter など）や、いくつかの種類のウェブアプリでチャットボットを実現できます。非常に正確で高速な応答が可能です。

# CX を使ってコードを書いたりボットを設計したりする前に知っておくべきことは何ですか？

### **エージェント**とは何ですか？

エージェントは、ボットシステムへの入り口です。エージェントは基本的にエンドユーザーと対話し、システムの背後にある情報を処理します。

エージェントの例 - ここでは、"ml-bot" がエージェント名です。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/ml-bot-agent.webp)

### **Intent**とは？

インテントとは、簡単に言うと「ユーザーが言いたいこと」です。
エンドユーザーの意図のようなものです。また、多くのインテントを組み合わせることで、より多くのことを一緒に行うことができます。

Dialogflow CX のインテントの例 - "WecomeIntent", "No", "Yes" など。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/intent.webp)

ページ上のウェルカムインテントの例
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/intent-start.webp)

"hi"、"just going to say hi"、"long time no see"、"hello hi "などです。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/intent-types-user-say.webp)

### **Entity** と **Entity types** とは何ですか？

Entity とは、ユーザーが取得したデータのことです。下の写真では、エッグベネディクトがエンティティの一例です。
ユーザーのデータを取得する方法をエンティティタイプと呼びます。下の図では、`breakfast-type`がエンティティタイプで、`eggs benedict`が同義語（eggs, Eggs, eggs benedict）を持つエンティティであることを示しています。同義語とは、ユーザがメッセージを入力するための方法です。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/entity-types.webp)

### **ルート**とは何ですか？

ルートは、ページ内の流れを制御する方法です。フロー内の条件ロジックについて詳しく説明します。

### **ページ**とは何ですか？

ページは、CX のセッションを表します。開始すると、会話ページがアクティブになります。フローの開始と終了の状態は、特別なページで処理されます。
下の例では、レストランで料理を注文するときに、「朝食」と「コーヒー」のページがあります。
ここでは、「注文ページ」と、すでに作成されている「朝食」「コーヒー」のページを追加する例を示します。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/Add-page-page-example.webp)

### **Parameters**とは？

ユーザーからボットに送られた値を受け取ることができます。この値をパラメータと呼びます。

### **フロー**とは？

フローは、会話の単純な部分とその流れを定義するモジュールまたはユニットです。フローは、会話における経路として機能します。以下の例では、「朝食」はレストランで料理を注文する際の会話の一部である。
コーヒーのフロー例
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/coffee-flow.webp)

### **フルフィルメント** - ボットのレスポンスとは？

ボットがユーザーに対して行う応答をフルフィルメントと呼びます。
「しばらくお待ちください」は、朝食の注文が入った後にエージェントが言うフルフィルメントの一例です。

# ダイアログフローのシステム構成

以下は、ユーザーがボットに「こんにちは」と言った場合の例です。このメッセージはシステムに送られ、システムは Dialogflow API に接続します。そして、Webhook があれば、それを使ってリトライします。
そして、プロセスは戻り、Dialogflow API はインテントを検知してレスポンスを返し、それがシステムに返され、最終的にユーザーに到達します。

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/cx-interaction-sequence.webp)
_Image source: [Google](https://cloud.google.com/dialogflow/cx/docs/basics)_

# CX ビジュアルビルダーでチャットボット(ml-bot)を実装する。

以下の手順で行います：

## ステップ 1

[Google Dialog](https://dialogflow.cloud.google.com/)でプロジェクトを作成し、Dialogflow Cloud にログインします： Cloud Console > New Project > Name を入力し、以下の画像のように他の詳細を選択します。

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/create-project.webp)

## ステップ 2

[Dialogflow API を有効化する](https://console.cloud.google.com/marketplace/product/google/dialogflow.googleapis.com?project=nodal-crawler-347903)。添付の画像は、API を有効にした後のものです。最初に`Enable`ボタンが表示されるはずです。

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/enable-api.webp)

API を有効にすると、Dialogflow の API が使えるようになります。

## ステップ 3

[.json ファイルをダウンロードする](https://console.cloud.google.com/apis/credentials?project=nodal-crawler-347903)。プロジェクトを選択 →「CREATE CREDENTIALS」ボタンをタップ → サービスアカウントを選択 → サービスアカウントの詳細を入力します：
]
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/create-credentials.webp)
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/create-credentials2.webp)

すべての情報を入力した後、「KEYS」タブで.json ファイルを作成し、ダウンロードします。
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/create-service-account-key.webp)

## ステップ 4

CX ビジュアルビルダーを使用して、Dialogflow CX チャットボットを作成します。

### ステップ 4.1

Project > Select Agent > Create agent > type details を選択してエージェントを作成します。

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/create-agent.webp)

### ステップ 4.2: 空のボード

空のボードに、デフォルトのスタートフローから始めて、ページ、フロー、引数、インテントなどを追加することができます。

### ステップ 4.3： すでに作られたコーヒーの例があるボード

これは、Dialogflow CX のビジュアルビルダーで、すでに作成された例を示しています：
![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/dialog-flow-board.webp)
ここでは、何でもできます。

### ステップ 4.4： チャットボットをテストする

これは Dialogflow CX のビジュアルビルダーで、すでに作成された例です。

#### 例 1 - アボカドを頼む

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/test-chat-bot.webp)

#### 例 2 - 卵を頼む

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/test-chat-bot-eggs.webp)

#### 例 3 - チャットを終了するために「いいえ」と言う

![]({{ sitePrefix }}/assets/img/articles/2022-06-06-How-to-create-a-chat-bot-using-Googles-Dialogflow/test-chat-bot-no.webp)

ここでは、ボットにあらゆる種類の質問をすることができます。回答は CX ビジュアルビルダーで定義したとおりになります。

## コードを書く

### APIs をフォローする

- [Dialogflow CX API](https://cloud.google.com/dialogflow/cx/docs/reference)
- [Dialogflow ES APIs](https://cloud.google.com/dialogflow/es/docs/reference)
  - [Dialogflow Essentials(ES) Dialogflow Essentials & Flutter で [Android 用ボイスボットを作ろう](https://codelabs.developers.google.com/codelabs/dialogflow-flutter#0)

## 結論:

Dialogflow の基礎とその種類（CX、ES）についての紹介と完全ガイドをまとめ、Dialogflow CX のビジュアルビルダーを使ったクイックチャットボット（ml-bot）を作り、私のボット Ask-Me-Any-Thing からビジュアルビルダーを使っていくつか質問してみました。

ゼロからチャットボットを実装するのは時間と手間がかかるので、今回ご紹介させていただいた Google Dialogflow の利用検討をお勧めします。

## 参考文献

- [Dialogflow ドキュメント](https://cloud.google.com/dialogflow/)
- [Dialogflow ES コンプリートガイド](https://dialogflow.cloud.google.com/#/getStarted)
- [Dialogflow CX コンプリートガイド](https://codelabs.developers.google.com/codelabs/dialogflow-cx-retail-agent#0)
- [サービス.json の作成](https://console.cloud.google.com/apis/credentials?project=nodal-crawler-347903)
- [DialogFlow API の有効化ページ](https://console.cloud.google.com/marketplace/product/google/dialogflow.googleapis.com?q=search&referrer=search&project=nodal-crawler-347903)
- [Dialogflow CX 入門／Youtube](https://www.youtube.com/watch?v=Xfgn9iA1KMk&list=PLJLSPq0cTRmat9ec-c0hOJJhhNfObZXy3&index=1)
- [チャットボットの分解 / Youtube](https://www.youtube.com/watch?v=O00K10xP5MU&list=PLIivdWyY5sqK5SM34zbkitWLOV-b3V40B&index=1)
- [DialogFlow の価格](https://cloud.google.com/dialogflow/pricing)

記事写真：[Robin Worrall](https://unsplash.com/photos/FPt10LXK0cg)


GoogleのDialogflowを使ったチャットボットの作り方


スケーラブルでパフォーマンスと保守性に優れたエンタープライズサービスを構築する必要性が高まる中、その解決策としてマイクロサービスやイベント駆動アーキテクチャがよく持ち出されますが、こうしたアーキテクチャでサービスを構築する場合、どのような点に留意すべきでしょうか。

## はじめに

本記事では、イベント駆動アーキテクチャを利用する動機、コアとなる概念、主な課題について解説します。
また、バックエンドに NestJS、通信ツールに RabbitMQ を使用し、イベントやメッセージングを扱うイベント駆動アーキテクチャの実装方法についても解説しています。

## マイクロサービスとその欠点

スケーラブルでモジュール化された保守性の高いシステムに対する必要性が高まる中、マイクロサービスアーキテクチャは、複雑な企業システムを構築するための事実上標準的なアーキテクチャとなりつつあります。
マイクロサービス・アーキテクチャでは、システムをより小さなフォールトトレラント・モジュールに分解し、個別に拡張、デプロイ、保守することができます。個々のサービスは、サービスが担当するドメインやタスクにより適した異なるテクノロジースタックを使用することもできます。例えば、ほとんどのサービスが Java で書かれているシステムで、機械学習モデルを担当するサービスには Python を使用することができます。

マイクロサービスアーキテクチャを採用する大きなメリットの 1 つは、サービスが疎結合であるため、あるサービスに障害が発生しても、他のサービスに障害が発生することがなく、単一障害点となりません。しかし、サービス間のブロッキング通信で単一障害点になってしまうと、その利点が失われてしまうことがあります。この問題は、2 つのサービスが HTTP/TCP でリクエスト/レスポンス方式で通信している場合に非常によく見られます。

また、依存するサービスがレスポンスを生成するための処理時間が長くなってしまう場合、エンドユーザーが感じる待ち時間が遅くなる可能性があります。

## イベント駆動アーキテクチャ

上記の問題を解決するためには、ノンブロッキングの通信方法が必要であり、イベント駆動型アーキテクチャがそれらの問題を解決することができます。 イベント駆動アーキテクチャでは、サービスがリクエスト/レスポンス方式で通信する代わりに、**イベントプロデューサー**は、**イベントコンシューマー**によって消費されるメッセージの形で**イベントキュー**にイベントを登録します。 使用する技術によってメッセージを届けるプロトコルは異なり、リアルタイムデータのストリーミングをサポートしているものもありますが、基本的なアーキテクチャは以下の通りです：

![Event-driven architecture diagram]({{ sitePrefix }}/assets/img/articles/2023-05-23-Introduction-To-Event-Driven-Architecture/eda-general.webp)

イベントプロデューサーがイベントを生成すると、そのイベントはイベントキューに登録され、イベントプロデューサーはそのイベントのレスポンスを気にすることなく、他のタスクを開始することができる。 イベントはキューに格納され、イベントコンシューマーがイベントメッセージを読み込んで必要な処理を行うことができるようになります。必要な処理が正常に終了すると、メッセージはキューから削除されます。

また、イベントキューのインスタンスを複数起動させることができるため、イベントキューの耐障害性をし、サービスが真の意味で疎結合になったことを保証することができます。コンシューマーが使えなくなった場合でも、プロデューサーは正常に動作し、イベントはキューにスタックされ、必要なコンシューマーが回復した時点でイベントメッセージをピックアップすることができます。これは、イベントキューにメッセージを必要なだけ保存し、コンシューマがイベント メッセージを処理するために必要なだけ再実行できるため、データ損失に関する問題にも非常に役立ちます。

## イベント駆動型アーキテクチャの主なコンセプト

ここでは、イベント駆動型アーキテクチャに関する主なコンセプトについて説明したいと思います：

- イベント: イベントとは オブジェクトやリソースのステータスが変化することを指します。例: _新たな注文が入りました_
- イベントプロデューサー: イベントキューにイベントを生成するサービスです。
- イベントキュー/ブローカー: イベントプロデュサーから送信されたイベントメッセージを保持し、イベントコンシューマーに消費（処理）されるためのキューです。
- イベントコンシューマー: イベントキューにあるイベントを消費し、必要な処理を行うサービスです。
- デッドレターキュー(DLQ): 何らかの理由で処理できなかったイベントメッセージが移動されるメインイベントキューの並列キューです。 DLQ があることで、エラーが発生したイベントメッセージを後から解析したり、再実行することができるようになります。
  - 例えば、何らかの破損した情報を持つメッセージがその最大リトライ回数に達すると、DLQ に移行されます。
- Ack: 英語の Acknowledgment という言葉からの略語。 Event が正常に処理され、キューから安全に取り除くことができることを確認するものです。

## イベント駆動型アーキテクチャの課題

マイクロサービス・アーキテクチャの多くの問題に対処しているにもかかわらず、イベント駆動アーキテクチャには独自の課題があります。

### 複雑性

イベント駆動アーキテクチャをベースとしたエンタープライズシステムを開発できるようになるには、アーキテクチャの設計と実装の両方でかなりの学習コストが必要です。

### 互換性

イベントベース通信がウェブサービスのペアやグループに最適かどうかを判断するのは難しいことです。 あるサービスが他のサービスの処理終了を待つ必要が全くない場合もありますが、一方で消費するサービスプロセスからの応答が、タスクを進めるために必要不可欠である場合もあります。

しかし、イベントベース通信が当該サービスにとって最適な答えであるかどうかが明確でない場合もあり、さまざまな通信パターンのトレードオフを考慮して、どちらがより特定のケースに適しているかを判断する必要があります。

### イベント複製・イベント順序性

マイクロサービスのフォールトトレラントと水平スケーリングの特性により、キューが複数のインスタンスで動作しているため、イベントの重複は、「もし」ではなく「いつ」の問題です（つまり、いつかは必ず起こります）。例：顧客に 2 回請求したり、顧客の財布に 2 回資金を追加したりすること。
メッセージブローカーによっては、_独自のトレードオフを伴いながら_、すぐにこの解決策を提供するものもあり、イベント ID やその他のテクニックを使って、重複排除ロジックを自ら実装することを好むものもあります。

同様に、イベントの順序が重要な場合、イベントが意図した順序で処理されることを保証するロジックを実装することが重要です。インターネットに接続できないシステムでは、サーバーに転送する前に大量のイベントがスタックされる可能性があり（例：IoT システム）、それを防止するロジックが実装されていないと、イベントがすべて順序不同になる可能性があります。

### エラー処理

イベント駆動型アーキテクチャによって導入された、より多くの可動部、異なる状況、異なる通信方法などによって、エラー処理はより複雑になりますが、サービスの微調整を行う上で重要な部分でもあります。

## イベント駆動型アーキテクチャのパターン

### シンプルなイベント処理

![Simple event processing]({{ sitePrefix }}/assets/img/articles/2023-05-23-Introduction-To-Event-Driven-Architecture/simple-event-processing.webp)

### 複雑なイベント処理

![Complex event processing]({{ sitePrefix }}/assets/img/articles/2023-05-23-Introduction-To-Event-Driven-Architecture/complex-event-processing.webp)

### ストリーミングイベント処理

![Streaming event processing]({{ sitePrefix }}/assets/img/articles/2023-05-23-Introduction-To-Event-Driven-Architecture/streaming-event-processing.webp)

## イベント駆動型アーキテクチャを使うべき場合

- サービス間に非同期処理がある場合や、現在の同期式サービスを非同期式に改造しても、大きな欠点がない場合
- 他のサービスからのレスポンスがすぐに必要でなく、処理結果を状態/ステータス遷移で管理してもよい場合 (例: Processing, Billing, Completed, Fail, など)。
- 処理の再実行が必要な場合、または（あるいは、それに加えて）失敗したときにデータ損失を回避しなければいけない場合

## イベント駆動型アーキテクチャを使うべきでない場合

- サービスからのレスポンスが、プロセスを継続するために不可欠である場合。(例：不正行為の検知)
- イベント駆動型アーキテクチャのメリットが、運用コストや複雑な実装を上回るほどシステムが複雑でない場合。
- チームがイベント駆動型アーキテクチャに慣れておらず、新アーキテクチャに移行するための時間が十分に確保できない場合。

## メッセージブローカーとその関連技術

- RabbitMQ: AMQP プロトコルを使用したキュー、Pub/Sub メッセージブローカーとして動作します。シンプルで信頼性が高いため、人気があります。
- Apache Kafka: 分散型イベントストアとストリーミング処理プラットフォーム。その性能と実装の可能性から、より人気のある選択肢の 1 つです。
- AWS SQS/SNS, GCP Pub/sub: クラウドで実装をしながら、運用のオーバーヘッドを少なくしたい方に最適なクラウド型メッセージキューサービスです。
- AWS Kinesis: AWS のマネージドデータストリーミングプラットフォームです。Kafka と似ていますが、運用のオーバーヘッドが少ないです。

_RabbitMQ と Kafka のマネージドバージョンは、いくつかのクラウドプロバイダーでも見つけることができます。_

## アーキテクチャーの例

イベント駆動型アーキテクチャを利用した注文アプリの簡単な例です：

![Ordering app architecture example]({{ sitePrefix }}/assets/img/articles/2023-05-23-Introduction-To-Event-Driven-Architecture/ordering-app-architecture.webp)

このアーキテクチャでは、Orders サービスは Billing サービスから切り離され、エンドユーザーへの低レイテンシー、障害時に再試行が可能な疎結合サービスによる耐障害性、Billing サービスが独自のデータベースを持つ必要がないためデータの重複がないことを実現しています。

一方、Billing サービスは、Fraud サービス（不正検知サービス）と密結合しており、不正の兆候があれば、すぐに注文をキャンセルする必要があります。しかし、Fraud サービスの処理に障害が発生した場合でも、Billing サービスは処理が終了してからイベントメッセージを**Ack**するので、イベント駆動型アーキテクチャと Rabbit MQ のおかげで、ここでもリトライが可能です。

## コードの例

ここでは、**NodeJS**と**RabbitMQ**のバックエンドフレームワークを使用した、このアーキテクチャの主要コンポーネントのコードスニペットをいくつか紹介します。

### イベントプロデューサー

`orders.controller.ts`:

```typescript
@Controller("orders")
export class OrdersController {
  constructor(private readonly ordersService: OrdersService) {}

  @Post()
  async createOrder(@Body() createOrderRequest: CreateOrderRequest) {
    return await this.ordersService.createOrder(createOrderRequest);
  }
}
```

`orders.service.ts`:

```typescript
@Injectable()
export class OrdersService {
  constructor(
    @InjectModel(Order.name) private orderModel: Model<OrderDocument>,
    @Inject(BILLING_SERVICE) private billingClient: ClientProxy
  ) {}

  async createOrder(
    createOrderRequest: CreateOrderRequest
  ): Promise<OrderInterface> {
    try {
      const order = new this.orderModel({
        ...createOrderRequest,
        status: "PENDING",
      });

      await order.save();
      const orderPayload: OrderInterface = {
        orderId: order._id.toString(),
        productName: order.productName,
        price: order.price,
        buyer: order.buyer,
        status: order.status,
      };

      await lastValueFrom(
        this.billingClient.emit("order_created", {
          orderPayload,
        })
      );

      return orderPayload;
    } catch (error) {
      throw error;
    }
  }
}
```

エントリーポイントは **controller** で、注文データを **service** レイヤーに送信し、注文を **PENDING** として保存し、**order_created** イベントを **BILLING** キューにペイロードとともに送信します。キューは **BILLING_SERVICE**という const 変数で登録される。( `export const BILLING_SERVICE = 'BILLING';`)

### イベントコンシューマー

`billing.controller.ts`

```typescript
@Controller()
export class BillingController {
  constructor(
    private readonly billingService: BillingService,
    private readonly rmqService: RmqService,
    @Inject(ORDERS_SERVICE) private ordersClient: ClientProxy
  ) {}

  @EventPattern("order_created")
  async handleOrderCreated(
    @Payload("orderPayload") order: Order,
    @Ctx() context: RmqContext
  ) {
    //check for fraud
    if (await this.billingService.isFraud(order)) {
      order.status = "CANCELED_FRAUD";
    } else {
      this.billingService.bill(order);
      order.status = "PROCESSED";
    }

    // emit and event to update the order status
    await lastValueFrom(
      this.ordersClient.emit("order_procesed", {
        order,
      })
    );

    // if no errors happened, acknowledge the order_created process is over and remove it from the queue
    this.rmqService.ack(context);
  }
}
```

課金サービスは、**_order_created_**という**イベントパターン** を監視し、不正をチェックし、注文を請求しようとします。エラーが発生しない場合は、新しい注文ステータスを持つ **_order_processed_** イベントを **発信** します。 そして、エラーが発生しなければ、**_order_created_**イベントメッセージを**Ack**します。

その後、Order サービスは新しいステータスでデータベースを更新し、**order_processed** イベントメッセージを **ack** して、全プロセスを終了します。

### イベントブローカー

`rmq.module.ts`(RabbitMQ を Producers として使用するサービスに必要な設定。)

```typescript
@Module({
  providers: [RmqService],
  exports: [RmqService],
})
export class RmqModule {
  static register({ serviceName, serviceEnvVar }: RmqModuleOptions): DynamicModule {
    return {
      module: RmqModule,
      imports: [
        /*
          Creates a dynamic module based on the serviceName
          This module creates/connects to a queue as an event producer
        */
        ClientsModule.registerAsync([
          {
            name: serviceName,
            useFactory: (configService: ConfigService) => ({
              transport: Transport.RMQ,
              options: {
                urls: [configService.get<string>('RABBIT_MQ_URI')],
                queue: configService.get<string>(serviceEnvVar),
              },
            }),
            inject: [ConfigService],
          },
        ]),
      ],
      exports: [ClientsModule],
    };
}
```

**register**メソッドは、RabbitMQ を**Producers**として使用する必要があるサービスによって使用されます。サービスには、**_serviceName_**、**_RabbitMQのURI_**（例：実行中のコンテナ）、 **_serviceEnvVar_** を **_queue name_** を持つ環境変数として提供する必要があります。
例えば、次のような環境変数がありましたら `RABBIT_MQ_BILLING_QUEUE=BILLING`, **_register_** メソッドを次のように呼びます like `RmqModule.register({ serviceName: 'BILLING', serviceEnvVar: 'RABBIT_MQ_BILLING_QUEUE'}),`.

`rmq.service.ts`:

```typescript
@Injectable()
export class RmqService {
  constructor(private readonly configService: ConfigService) {}

  // return the config options to subscribe to a queue as an event consumer
  getOptions(queue: string, noAck = false): RmqOptions {
    return {
      transport: Transport.RMQ,
      options: {
        urls: [this.configService.get<string>("RABBIT_MQ_URI")],
        queue: this.configService.get<string>(queue),
        noAck,
        persistent: true,
      },
    };
  }
}
```

RabbitMQ キューから消費するサービスに必要な設定を返します。(queue 変数は環境変数名と一緒になります)

### イベントメッセージ Ack

`rmq.service.ts`:

```typescript
@Injectable()
export class RmqService {
  constructor(private readonly configService: ConfigService) {}

  ack(context: RmqContext): void {
    const channel = context.getChannelRef();
    const originalMessage = context.getMessage();
    channel.ack(originalMessage);
  }
}
```

不要になったイベントメッセージをキューから**Ack**するために必要なメソッドです。

## 参考リンク

- 上記のアーキテクチャの全てのコードは、[この Github リポジトリで見ることができます](https://github.com/FelipeCO14/nest-event-driven-app)
- [NestJS + RabbitMQ の統合](https://docs.nestjs.com/microservices/rabbitmq)
- [IBM のイベント駆動型アーキテクチャの記事](https://www.ibm.com/topics/event-driven-architecture)

_Article Photo by [Krusche & Company](https://kruschecompany.com/)_


イベント駆動アーキテクチャの入門

## はじめに：
目まぐるしく変化をしていく現代では企業や開発者にとって、堅牢で使いやすいモバイルアプリケーションを作ることは非常に重要です。しかし、アプリの構築プロセスは複雑で時間がかかることがあります。その点で、FlutterFlowが大いに役立ちます。FlutterFlowは、GoogleのFlutterフレームワークを使用してアプリ開発プロセスを簡素化する強力なビジュアル開発プラットフォームです。本記事では、FlutterFlowの特徴と利点、そしてどのようにアプリ開発のワークフローを革新できるのかについて探っていきます。

### FlutterFlowとは？
FlutterFlowは直感的でパワフルなビジュアル開発プラットフォームであり、開発者がビジュアルインターフェースを使用してモバイルアプリケーションの設計、プロトタイプ、構築をできるようにします。GoogleのFlutterフレームワークの力を借りて、iOSとAndroid向けの高品質なネイティブアプリを作成します。

### 驚くべきビジュアルインターフェース：
FlutterFlowの特筆すべき機能の1つは、ビジュアルインターフェースです。このインターフェースにより、開発者はコードを1行も書かずにアプリの画面をデザインし、インタラクティブなプロトタイプを作成することができます。ドラッグアンドドロップの機能を使用して、迅速にUIレイアウトを構築し、コンポーネントを追加し、画面間の相互作用を定義することができます。このビジュアルアプローチにより、アプリのデザインを繰り返し改善することが容易になり、開発プロセスでの時間と労力を節約できます。

### 簡単なコード生成：
FlutterFlowはアプリ開発のビジュアルデザインの側面を簡素化しますが、ビジュアルのみのワークフローに制限されることはありません。FlutterFlowは、デザインに基づいてクリーンで本番向けのFlutterコードを生成し、従来のコーディング手法を使用してアプリの機能をカスタマイズや拡張する柔軟性を提供します。これにより、開発者はビジュアルインターフェースからコードの記述にシームレスに移行でき、両方の利点を最大限に活用することができます。

### エレメントライブラリ：
FlutterFlowには、美しいアプリインターフェースを作成するために使用できる、事前に作成された豊富なUIコンポーネントライブラリが付属しています。ボタンや入力フィールドからリストやグリッドのような複雑な要素まで、FlutterFlowは幅広い使いやすいコンポーネントを提供しています。これにより、開発者は車輪の再発明から解放され、開発プロセスを加速させることができます。

### リアルタイムコラボレーション：
アプリ開発プロジェクトでは、コラボレーションが重要です。FlutterFlowはリアルタイムコラボレーション機能を提供し、チームワークを効率化します。複数のチームメンバーが同じプロジェクトで同時に作業できるため、アイデアの共有、フィードバックの収集、進捗の追跡が容易になります。FlutterFlowのコラボレーション機能により、効率的なコミュニケーションを確保し、生産性を最大化することができます。

### バックエンドサービスとの統合：
完全なアプリを構築するには、バックエンドの統合が必要です。FlutterFlowは、人気のあるバックエンドサービスとシームレスに統合する機能を提供しています。データベースへの接続、ユーザーの認証、APIからのデータの取得など、FlutterFlowは組み込みの統合機能を通じてプロセスを簡素化します。Firebase、GraphQL、REST APIなどのサービスとの連携が簡単で複雑なバックエンドの開発なしで機能的なアプリができます。

## FlutterFlowの利用手順：

1. アカウントの登録とプロジェクトの作成:
   * [FlutterFlowのウェブサイト](https://flutterflow.io/)にアクセスし、アカウントを登録します。
   * ログイン後、「プロジェクトの作成」ボタンをクリックして新しいプロジェクトを作成します。

2. アプリのデザイン:
   * プロジェクトを作成すると、FlutterFlowのビジュアルエディタに移動します。
   * サイドバーからUIコンポーネントをキャンバスにドラッグアンドドロップして、アプリの画面をデザインします。
   * ビジュアルインターフェースを使用して、コンポーネントの外観をカスタマイズし、レイアウトを定義し、画面間の相互作用を追加します。

3. データソースの設定:
   * アプリがバックエンドサービスやAPIからデータを必要とする場合、FlutterFlowでデータソースを設定できます。
   * FirebaseやREST API、GraphQLなどの外部サービスに必要な設定をFlutterFlow内で行い、アプリを接続します。

4. ロジックと機能の追加:
   * FlutterFlowはビジュアルデザインを簡素化しますが、コードブロックを使用してアプリにロジックと機能を追加することもできます。
   * FlutterFlowの組み込み機能ブロックを活用するか、Dartコードスニペットを使用してカスタムなロジックを作成します。

5. プレビューとテスト:
   * FlutterFlowのプレビューモードを使用して、ビジュアルエディタ内でアプリのデザインと相互作用をテストします。
   * アプリを異なるデバイスサイズや向きでプレビューし、レスポンシブ性を確認します。

6. Flutterコードの生成:
   * アプリのデザインと機能に満足したら、Flutterコードを生成できます。
   * 「コードのエクスポート」ボタンをクリックして、FlutterFlowプロジェクトに基づいてクリーンで構造化されたFlutterコードを生成します。

7. Flutterへのインポート:
   * 好みのFlutter開発環境（Android StudioやVisual Studio Codeなど）を開き、新しいFlutterプロジェクトを作成するか、既存のプロジェクトを開きます。
   * FlutterFlowから生成されたFlutterコードをコピーし、Flutterプロジェクト
   
## FlutterFlowを使って、シンプルな画面を作成しましょう。

FlutterFlowのウェブサイト(https://flutterflow.io/）にアクセスし、アカウントを作成してください。

プロジェクトの詳細を入力するように促されますが、このブログではFirebaseの統合は行いません。

![]({{ sitePrefix }}/assets/img/articles/2023-06-08-Streamlining-App-Development-with-FlutterFlow/create-project.webp)

## ツール：

FlutterFlowは、ビジュアル開発プロセスをサポートするために、インターフェースの左側と右側にツールとパネルを提供しています。それぞれの側面とそれぞれのツールについて詳しく見てみましょう。

左側パネルのツール：

* スクリーンの選択：左上隅には、ドロップダウンメニューがあり、アプリ内の異なるスクリーンを選択して切り替えることができます。ここでプロジェクト内のさまざまなスクリーンを管理し、アクセスすることができます。

* コンポーネントツリー：スクリーン選択のドロップダウンの下には、コンポーネントツリーパネルがあります。これは、現在選択されたスクリーンに存在するすべてのUIコンポーネントの階層ビューを提供します。ツリーを展開・折りたたんで、特定のコンポーネントを編集するためにナビゲートしたり、選択したりすることができます。

* プロパティパネル：左側に位置するプロパティパネルは、選択されたUIコンポーネントのプロパティと属性を表示します。これらのプロパティを変更して、選択したコンポーネントの外観、動作、スタイルをカスタマイズすることができます。

* データソース：データソースパネルでは、アプリにデータソースを管理し、接続することができます。データモデルを定義し、APIを統合し、このパネルを使用してアプリのための動的なコンテンツを作成することができます。データとAPIの接続を管理するためのビジュアルインターフェースが提供されています。

* アクション：アクションパネルを使用すると、アプリ内でインタラクティブな動作を定義し、管理することができます。ボタンのクリックやフォームの送信など、ユーザーの操作に応答するイベントとアクションを作成できます。このパネルを使用して、コードを書かずにアプリにロジックとインタラクティビティを追加することができます。

右側パネルのツール：

* ウィジェットライブラリ

：右側にあるウィジェットライブラリパネルには、ドラッグアンドドロップでアプリのスクリーンに追加できる、さまざまなカテゴリのプリビルドUIコンポーネントが用意されています。ボタン、テキストフィールド、画像、リストなどのウィジェットが含まれています。これらのウィジェットをカスタマイズしてデザイン要件に合わせることができます。

* スタイル：スタイルパネルを使用して、UIコンポーネントにスタイルを管理し適用することができます。テキストスタイル、カラー、スペーシング、その他のビジュアルプロパティを定義してカスタマイズするオプションが提供されています。再利用可能なスタイルを作成して、アプリ全体で一貫性を保つことができます。

* アセットマネージャー：アセットマネージャーパネルを使用して、アプリで使用するアセット（画像、アイコン、フォントなど）をアップロードして管理することができます。アセットをアップロードし、フォルダに整理し、簡単にアプリのスクリーン内でアクセスして使用することができます。

* コンポーネント構造：コンポーネント構造パネルは、アプリのコンポーネントとスクリーンの階層的な概要を表示します。アプリの全体構造の視覚的な表現を提供し、スクリーンとコンポーネント間を簡単に移動できます。

* プレビューとシミュレーター：右上隅には、アプリのデザインと機能のプレビューをするためのボタンがあります。さまざまなデバイスサイズや向きでアプリの外観を表示し、内蔵のシミュレーターを使用してプレビューされたアプリと対話することができます。

以下の画像では、Columnを親ウィジェットとしてドラッグアンドドロップし、pageViewコンポーネントを配置しました。コンポーネントをクリックすると、要素を配置しデザインするためのオプションが表示されます。
![]({{ sitePrefix }}/assets/img/articles/2023-06-08-Streamlining-App-Development-with-FlutterFlow/first-step.webp)

次に、Rowを持つContainerウィジェットを追加し、さらに3つの画像コンポーネントを持つContainerを追加しました。
![]({{ sitePrefix }}/assets/img/articles/2023-06-08-Streamlining-App-Development-with-FlutterFlow/second-step.webp)

その後、下部にListViewコンポーネントを追加し、画像付きのカードを追加しました。右側のオプションを選択してListViewを展開し、水平スクロールが可能になっています。
![]({{ sitePrefix }}/assets/img/articles/2023-06-08-Streamlining-App-Development-with-FlutterFlow/third-step.webp)

最後に、画面の外観に満足したら、実行オプションを選択してアプリのプレビューを表示します。以下は、その見た目です。
![]({{ sitePrefix }}/assets/img/articles/2023-06-08-Streamlining-App-Development-with-FlutterFlow/final.webp)

## いくつかの不利な点があります：

1. 限られた柔軟性：FlutterFlowはさまざまなUIコンポーネントを提供していますが、特定の専門的なまたはカスタムのコンポーネントが必要な場合もあります。そのような場合には、カスタムコードの記述や追加のFlutterパッケージの統合が必要になる場合があります。
2. プラットフォームの制約：FlutterFlowはクロスプラットフォーム開発を可能にしますが、特定のプラットフォーム固有の機能や機能を視覚的なインターフェースだけで簡単に実装することができない場合もあります。そのような状況では、開発者はプラットフォーム固有のコードの記述に頼る必要があります。

## 結論:

FlutterFlowはモバイルアプリ開発において画期的な存在です。その視覚的なインターフェース、コード生成の機能、幅広いコンポーネントライブラリ、シームレスなバックエンド統合は、効率的に高品質なネイティブアプリを開発したい開発者にとって頼りになるプラットフォームです。開発プロセスを簡素化し、コラボレーションを促進することで、FlutterFlowは開発者に素早く効果的にアプリのアイデアを具現化する力を与えてくれます。初心者でも経験豊富な開発者でも、FlutterFlowはアプリ開発のポテンシャルを引き出すために探求する価値のあるツールです。

ただし、FlutterFlowは強力なビジュアル開発ツールですが、その機能を最大限に活用するためには、FlutterとDartプログラミングの基本的な理解が必要です。FlutterFlowはビジュアルインターフェースとコード生成によって開発ワークフローを補完しますが、アプリの機能をカスタマイズしたり拡張するためには手動でのコーディングが必要になる場合もあります。

FlutterFlowのドキュメンテーション、チュートリアル、コミュニティリソースを参照して、その機能を詳しく探求し、この強力なアプリ開発プラットフォームを最大限に活用しましょう。

最後に、FlutterFlowの真のパワーを体験する最良の方法は、実際に試してみることをお勧めします。




FlutterFlowによるアプリ開発の効率化：入門

フロントエンドエンジニアとして、フルスタックエンジニアになることは大変難しい事に思えるかもしれません。しかし、適切なツールと知識を持っていれば、フロントエンドとバックエンドの両方のロジックと機能を組み込んだ、スケーラブルな Web アプリケーションを構築することが可能です。この記事では、Universal JavaScript を使用して、インフラや API 機能のための Serverless Framework、CI/CD のための GitHub Actions を組み合わせて、フルスタックアプリケーションを構築する方法を探ります。

---

## はじめに

この記事は、実際にリリースされたプロジェクトをもとに書いています。個人的な経験から、そのプロジェクトはフロントエンドエンジニアにとって素晴らしい修業となりました。シングルページアプリケーションの開発から API やクラウドインフラストラクチャ、DevOps などの分野のスキルを広げられる機会をいただきました。これから、フロントエンドエンジニアがフルスタックの道を歩むために始めることができる手がかりを見てみましょう。

## Universal JavaScript/Typescript を学ぶ

![Javascript]({{ sitePrefix }}/assets/img/articles/2023-05-15-From-frontend-to-fullstack/javascript.webp)

フロントエンドエンジニアがフルスタックアプリケーションを構築するための重要な要素の 1 つは、Universal JavaScript/Typescript の技術スタックを使用することです。 Universal JavaScript は、開発者がクライアントとサーバーサイドの両方で実行できる JavaScript コードを書くことができるようにするアプローチです。このアプローチにより、フロントエンドエンジニアは新しい言語を学ぶことなく、サーバーサイドの開発を開始できます。また、同じチームが両方を同時に書くため、不要なコミュニケーションを減らし、開発をより迅速かつ効率的に行えます。流行っている Universal JavaScript のテックスタックには、React、Node.js、OpenAPI などが含まれています。

## Serverless Framework を使用してインフラストラクチャと API 機能を構築する

![Serverless]({{ sitePrefix }}/assets/img/articles/2023-05-15-From-frontend-to-fullstack/serverless-title.webp)

Universal JavaScript を適用したら、次のステップはインフラのセットアップとサーバーサイド機能をアプリケーションに組み込むことです。これを行うためよく使われる方法の一つが、Serverless Framework です。

### Serverless Framework について

Serverless Framework は、サーバーレスアプリケーションの構築とデプロイをサポートするオープンソースの開発者向けフレームワークです。サーバーレス関数とリソースの定義、デプロイ、管理を簡単かつ一貫性があり、クラウドサービスプロバイダに依存しない方法で提供することで、開発者がクラウドネイティブなアプリケーションを簡単に構築および運用ができるようになります。

Serverless Framework は、**Infrastructure as Code (IaC)** のコンセプトに基づいています。他の人気ある IaC サービスと比較することで、その強みを理解しやすくなります。

|                        | ![Serverless]({{ sitePrefix }}/assets/img/articles/2023-05-15-From-frontend-to-fullstack/serverless.webp) | ![Terraform]({{ sitePrefix }}/assets/img/articles/2023-05-15-From-frontend-to-fullstack/terraform.webp) | ![CloudFormation]({{ sitePrefix }}/assets/img/articles/2023-05-15-From-frontend-to-fullstack/cloudformation.webp) |
| ---------------------- |-----------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------|
|                        | Serverless                                                                                                | Terraform                                                                                               | CloudFormation                                                                                                    |
| Infrastructure as Code | YAML/JSON config ファイル                                                                                     | HCL/JSON config ファイル                                                                                    | YAML/JSON config ファイル                                                                                             |
| プラットフォーム       | AWS, Azure, Google Cloud など                                                                               | AWS, Azure, Google Cloud など                                                                             | AWS だけ                                                                                                            |
| 強み                   | クラウドネイティブアプリケーションのための**オールインワン開発ソリューション**                                                                 | **どんな環境**でもリソースをプロビジョニング、変更、バージョン管理できる                                                                  | AWS およびサードパーティのリソースのプロビジョニングおよび管理                                                                                 |

### Serverless Framework の簡単なサンプル

Serverless Framework を利用して作成された Lambda ベースの API のサンプルを見てみましょう。他のサンプルコードを確認したい場合は、[こちら](https://github.com/serverless/examples)を閲覧してください。

サンプルコードのフォルダ構造から分かるように、サーバーレスプロジェクトは、アプリケーションコードとインフラストラクチャの構成ファイルの 2 つの主要なパーツで構成されています。
![Folder Structure]({{ sitePrefix }}/assets/img/articles/2023-05-15-From-frontend-to-fullstack/sample-folder.webp)

ここの **handler.ts** ファイルは、簡単なメッセージを返す API を作成します。

```
import { APIGatewayProxyEvent, APIGatewayProxyResult } from "aws-lambda";

export const hello = async (
 event: APIGatewayProxyEvent
): Promise<APIGatewayProxyResult> => {
 return {
   statusCode: 200,
   body: JSON.stringify(
     {
       message: "Hello Serverless!",
       input: event,
     },
     null,
     2
   ),
 };
};
```

**serverless.yml** ファイルでは、関数と関連するハンドラーファイルを指定することで、インフラを簡単に定義できます。API Gateway などの他のリソースも自動的に作成されます。

```
service: serverless-http-api-typescript
frameworkVersion: '3'

provider:
 name: aws
 runtime: nodejs14.x

functions:
 hello:
   handler: handler.hello
   events:
     - httpApi:
         path: /
         method: get

plugins:
 - serverless-plugin-typescript
```

それで、 **`$ serverless deploy`** という 1 つのマジックコマンドで、API が使用可能になります。

プラグインを利用することで、より多くクラウドリソースや機能を有効にすることもできます。上記の例では、TypeScript プラグインが追加されました。実際のプロジェクトでは、バックエンドで RDS、Data API、SQS などを使用するためのプラグインを追加しました。フロントエンドでは、 `Sveltkit` ベースの SPA であるため、ビルドされたファイルを S3 にデプロイし、関連する Cloudfront ディストリビューションを作成するために別のプラグインが使用されました。

これらの機能は、フロントエンドエンジニアにとって非常に役立ちます。インフラやバックエンド開発の知識が限られていても、最小限の前提条件でフルスタック開発を開始することができます。

### Serverless Framework のまとめ

以下が Serverless Framework の主な特徴です：

- インフラのコード化: Serverless Framework は、開発者が構成ファイルを使用してインフラやリソースをコードとして定義することを可能にし、バージョン管理、テスト、チームメンバーとの共有が容易に行えます。

- 簡単なデプロイメント: Serverless Framework は、一つのコマンドでサーバーレスアプリケーションをデプロイすることが容易であり、パッケージング、デプロイメント、リソース管理タスクを自動化できます。

- プラグインアーキテクチャ: Serverless Framework は新しいプラグインを追加したり、独自のプラグインを作成したりすることで、フレームワークの機能を拡張およびカスタマイズできます。

- ローカル開発: Serverless Framework は、`Serverless Offline`プラグインを使用して、サーバーレスアプリケーションのローカルでのテストおよびデバッグを可能にします。

まとめると、Serverless Framework は、クラウドリソースを管理とデプロイを一貫したことにより、開発者がサーバーレスアプリケーションを構築および運用するための優れたツールと機能を提供しています。

## Serverless Framework に GitHub Actions で CI/CD の構築

フルスタックアプリケーションの信頼性を高くにするためには、継続的インテグレーションおよび継続的デプロイメント（CI/CD）のプラクティスを使用することが重要です。GitHub Actions は、Serverless Framework と良く統合される人気のある CI/CD ツールです。GitHub Actions と Serverless Framework を組み合わせることで、自動化されたテスト、Lint、およびデプロイメントプロセスを設定して、コードが常に最新でスムーズに動作することを保証できます。

### CI の Workflow

最初に、新しいプルリクエストが作成されると、リントとテストのジョブが実行されます。最後に、 **静的コード解析**スキャンも実施されます。開発者は、テストとスキャンの結果がプルリクエストのコメントに更新されるため、人によるコードレビューがなくても、検出された問題を修正することができます。

_check.yml:_

```
name: status check

on:
  pull_request:
    types: [opened, synchronize, reopened]

jobs:
  check:
    name: lint and check App
    runs-on: ubuntu-latest
    environment: develop
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v3
        with:
          node-version: 16.x

      - name: Install Dependencies
        run: npm install

      - name: Make envfile
        uses: SpicyPizza/create-envfile@v1.3
        with:
          envkey_VITE_EXAMPLE: test

      - name: Build
        run: npm run build
        env:
          CI: true

      - name: check format & lint
        run: npx lint-staged

      - name: test and coverage
        run: npm run coverage

      - name: SonarCloud Scan
        uses: sonarsource/sonarcloud-github-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
```

### CD の Workflow

デプロイの場合は、プルリクエストが対象のブランチにマージされると実行されます。デプロイ前と後には、Slack でデプロイのステータスが通知されます。AWS や Slack のキーなどの環境変数は、GitHub リポジトリの設定の**Environments**で設定できます。デプロイコマンド _npm run deploy:staging_ の背後には、**package.json** に定義されたスクリプトです：

```
"deploy:staging": "serverless deploy --stage staging"
```

_deploy-staging.yml:_

```
name: Deploy - Staging

on:
  push:
    branches:
      - develop

concurrency:
  group: staging
  cancel-in-progress: false

jobs:
  deploy:
    name: Deploy App
    runs-on: ubuntu-latest
    environment: develop
    steps:
      - name: Post to a Slack channel
        id: slack
        uses: slackapi/slack-github-action@v1.21.0
        with:
          channel-id: ${{ secrets.SLACK_BOT_POST_CHANNEL }}
          slack-message: 'FRONTEND STAGING RELEASE started'
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_OAUTH_TOKEN }}
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16.x
      - uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      - name: install
        run: npm install
      - name: Make envfile
        uses: SpicyPizza/create-envfile@v1.3
        with:
          envkey_VITE_ENVIRONMENT: ${{ secrets.VITE_ENVIRONMENT }}
          ...
           # .env variables here - name: deploy
      - name: deploy
        run: npm run deploy:staging
      - name: Post to a Slack channel - success
        if: success()
        id: slack-success
        uses: slackapi/slack-github-action@v1.21.0
        with:
          channel-id: ${{ secrets.SLACK_BOT_POST_CHANNEL }}
          slack-message: 'FRONTEND STAGING RELEASE finished'
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_OAUTH_TOKEN }}
      - name: Post to a Slack channel - failure
        if: failure()
        id: slack-failure
        uses: slackapi/slack-github-action@v1.21.0
        with:
          channel-id: ${{ secrets.SLACK_BOT_POST_CHANNEL }}
          slack-message: 'FRONTEND STAGING RELEASE failed'
        env:
          SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_OAUTH_TOKEN }}

```

## 学びと実践を続けましょう

フルスタックエンジニアになるには、学びと実践が継続的に必要です。フロントエンドとバックエンドの最新のトレンドやテクノロジーについて常にアップデートし、自分のスキルを向上するための方法を常に模索してください。オンラインコミュニティに参加したり、カンファレンスやミートアップに参加したり、他のチームメンバーと協力して最新情報を得て、フルスタックエンジニアとして成長し続けましょう。

フルスタック開発をマスターするためには、フルスタックプロジェクトをもっと参加し続ける必要があります。まずは、フロントエンドとバックエンドのコードを統合する練習ができる小さなプロジェクトから始めましょう。自信をつけたら、より大規模、複雑な幅広くなツールやスキルを必要とするプロジェクトに取り組むことができます。

まとめると、Universal JavaScript、Serverless Framework、GitHub Actions を組み合わせることで、スケーラブルなクラウドネイティブアプリケーションを効果的に構築できます。これらのツールを習得し、フルスタックプロジェクトを構築することで、開発チームのより貢献できる、重宝なメンバーになりましょう。

_Article Photo by [Midjourney](https://www.midjourney.com/)_

フロントエンドエンジニアのフルスタック修業 - with Serverless Framework

FlutterでのChatGPTの統合

Flutter on the Webを触ってみた


## モンスターラボの開発におけるAI技術活用について

当社では、AIを活用した設計やコーディング支援ツールの導入により、開発プロセスの効率化と品質向上に取り組んでいます。

## ChatGPT

ChatGPTは、OpenAIが開発した言語モデルであり、当社の設計プロセスにおいて活用しています。ChatGPTを用いることで、設計メンバーが提案するドキュメントの品質向上が期待できます。ChatGPTは自然言語処理を利用しており、提案されたドキュメントを解析し、適切なフィードバックを提供することができます。また、ChatGPTは、プロジェクト全体で共通の用語や表現を学習し、設計ドキュメントのスタイル統一を実現することができます。

## GitHub Copilot

GitHub Copilotは、AIを活用したコーディング支援ツールであり、当社の開発プロセスにおいて活用しています。GitHub Copilotを用いることで、開発メンバーはよりスムーズにコードを記述することができます。GitHub Copilotは、開発メンバーが入力したコードの文脈を把握し、次に入力するべきコードを予測します。これにより、開発メンバーはより効率的にコードを記述することができます。また、GitHub Copilotは、コードの品質も向上させることができます。GitHub Copilotが提供するコードは、コーディングスタイルやベストプラクティスに基づいて生成されるため、プロジェクト内でコードのスタイルが統一され、コードの品質が向上することが期待できます。さらに、GitHub Copilotは、多言語対応が可能であり、開発メンバーが複数の言語に対応した開発を行う際にも大きな支援となります。

## まとめ

AIを活用した設計やコーディング支援ツールの導入により、開発プロセスの効率化と品質向上が実現できると考えています。AIが自動生成するコードや文章は、必ずしも完全なものではありませんが、開発メンバーがAIが提供するものを利用しながら、改善やカスタマイズすることで、より優れた成果物を生み出すことができます。AI技術を活用することで、開発メンバーの負担軽減につながるだけでなく、開発プロセスのスピードアップや品質向上、生産性の向上など多くのメリットが得られます。

モンスターラボでは、AI技術の活用により、開発プロセスの改善を実現することで、お客様のビジネス課題を解決するサービスを提供しています。今後も、AI技術を活用した新しい支援ツールの導入や、AI技術を活用した新しいサービスの提供に取り組んでいく予定です。

.<br>
..<br>
...

# ここから人間が書いています

ここまで読んでいただいた方はすでにお気づきかもしれませんが、上記の文章は ChatGPT で生成してもらったものです。もちろんレビューはしましたが、ほとんど生成されたそのままの文章です。
上記を生成するまでにこちらからお願いしたことは以下の3つのみです。

1. 弊社で ChatGPT や GitHub Copilot など AI を利用して設計やコーディングを効率化していることをアピールするブログの文章を教えて下さい
2. もっと詳細に、長い文章にしてもらえますか
3. 先程回答してもらった内容をマークダウン形式にしてもらえますか

ChatGPT が生成した内容と、モンスターラボの取り組みに齟齬はありませんが、もう少し補足します。

## 情報共有

モンスターラボでは技術トピックごとに Slack チャンネルを作成しており、ChatGPT に関するチャンネルもあります。そこでは関連記事やどういうクエリに対してどういう回答が出るのかの共有にとどまらず、開発したデモなどの共有も行われています。

## GitHub Copilot のプラン

現在のところ、モンスターラボでは Business プランは契約しておらず、利用したいエンジニアが Individual プランで利用しています(技術の調査・検証のためテクノロジーラインで購入しています。)
情報流出を避けるため、Individual プランを利用する場合は個人レベルで以下の設定を行うことを必須としています。

- `Suggestions matching public code` を `Block` に設定する
  - GitHub 上の Public なコードに一致する提案をブロックします
- `Allow GitHub to use my code snippets for product improvements` のチェックを外す
  - Private なコードを GitHub に送信し学習モデルとして利用されることを避ける

## まとめ

モンスターラボでは、最新の技術を活用し、生産性、品質の高いプロダクト開発を目指しています。また AI を利用するプロダクトの開発にも積極的に関わっています。
モンスターラボは AI を活用し、新しいプロダクトを開発することに興味のあるエンジニアを募集しています！<br>
https://www.join.monstar-lab.com


Dev with AI


私たちのチームは最近、2つの別々のAndroidアプリケーションを必要とするクライアントとのコラボレーションで、Jetpack Composeと全く新しいプロジェクトを行う機会を得ました。このプロジェクトは無事リリースされ、クライアントは最終製品に非常に満足していました。
このブログでは、Jetpack Compose ナビゲーションのパラメータの扱いについて、特に最初はかなり厄介だったので、その過程で得たいくつかの学びを共有したいと思います。

執筆時点では、Jetpack Compose Navigationの最新バージョンは **[2.5.3](https://mvnrepository.com/artifact/androidx.navigation/navigation-compose/2.5.3 "2.5.3")** でしたが, しかし、私たちは2.5.0を使用しました。

この記事に記載するすべてのコードは、カスタムのビジネスロジックを削除し、必要最低限に絞り込み、教育目的にのみ使用されています。

# アプリのデザイン

## ロジックの流れ
ログイン画面では、ログインに成功した後、データベースに初回ログインかどうかのフラグがあるかどうかをチェックする。初回ログインの場合は、「パスワード変更画面」に遷移し、パスワードを変更する。それ以外の場合は、「ホーム画面」に送られる。

![Login Flow Design](/assets/img/articles/2022-07-13-Navigation-parameters-with-Jetpack-Compose/project_login_flow.webp "Login Flow Design")

ただし、パスワードの変更画面は、ホーム画面からもいつでも呼び出すことができます。

![Home Screen to Change Password](/assets/img/articles/2022-07-13-Navigation-parameters-with-Jetpack-Compose/change_password_home.webp "Home Screen to Change Password")

パスワードの変更画面で、もし `firstLogin` が **false** ならば、ユーザーはまず現在のパスワードを入力するよう求められます。**true** の場合、現在のパスワードの入力は必要ありません。

## 主な課題 : ダイナミックな `startDestination` を実現する。

Googleは、`startDestination`を:

> ランチャーからアプリを起動したときに、ユーザーが最初に見る画面です。また、「戻る」ボタンを押した後にランチャーに戻ったときにも、この画面が表示されます。

そしてさらに、次のように明記しています : 

> 作るすべてのアプリは、[固定されたスタート地点](https://developer.android.com/guide/navigation/navigation-principles#fixed_start_destination) を持っています。

しかし、私たちのアプリの設計では:

> パスワード変更画面でAndroidの戻るボタンが押された場合。
>  - firstLogin == trueの場合、アプリを終了します。
>  - firstLogin == falseの場合、通常通り（ホーム画面へ）戻る。
 
したがって、`startDestination`を変更する方法を見つけなければなりません。

# Jetpack Composeのナビゲーション

## プロジェクトの基本レイアウト

Jetpack Composeプロジェクトの基本的な構造（パラメータなし）は、次のようなものです：

```Kotlin
@Composable
fun MainScreen(
    mainViewModel: MainViewModel = viewModel()
) {
    val navController = rememberNavController()

    Scaffold {
        val startDestination = mainViewModel.startDestination.collectAsState().value

        NavHost(
            navController = navController,
            startDestination = startDestination
        ) {
            composable(AppRoute.LOGIN.route) {
                LoginScreen(
                    navController = navController
                )
            }
            composable(AppRoute.HOME.route) {
                HomeScreen(
                    navController = navController
                )
            }
            composable(AppRoute.CHANGE_PASSWORD.route) {
                ChangePasswordScreen(
                    navController = navController
                )
            }
        }
    }
}

@Composable
fun LoginScreen(navController: NavController) { ... }

@Composable
fun HomeScreen(navController: NavController) { ... }

@Composable
fun ChangePasswordScreen(navController: NavController) { ... }

```

この文脈では、`MainViewModel`は以下のようになります： 

```Kotlin
class MainViewModel(application: Application) : AndroidViewModel(application) {
    private val _startDestination = MutableStateFlow(AppRoute.LOGIN.route)
    val startDestination: StateFlow<String> get() = _startDestination

    private fun updateStartDestination(value: String) {
        _startDestination.value = value
    }
}
```

また、`AppRoute` enumは以下のように定義されています： 

```Kotlin
enum class AppRoute(
    val route: String
) {
    LOGIN("login"),
    HOME("home"),
    CHANGE_PASSWORD("change_password")
}
```

この設定では、デフォルトの `startDestination` は `AppRoute.LOGIN.route` に設定されているので、アプリが起動しログイン画面が表示されることになります。

## パラメータの追加

将来的に複数のパラメータを追加したい場合は、すべてのパラメータをデータクラスに格納することをお勧めします。データクラスは、[GSONライブラリ](https://github.com/google/gson)を使って、JSONとの変換や解析が簡単にできるのが便利です。

```Kotlin
data class ChangePasswordScreenArguments(
    val isFirstLogin: Boolean
)
```

JSONのシリアライズ/デシリアライズを抽象化するための便利なJSON/String拡張ファイル： 

```Kotlin
object ExtensionJSON {
    fun ChangePasswordScreenArguments.toJson(): String =
        URLEncoder.encode(Gson().toJson(this), StandardCharsets.UTF_8.toString())

    fun String.toChangePasswordScreenArguments(): ChangePasswordScreenArguments =
        Gson().fromJson(this, ChangePasswordScreenArguments::class.java)
}
```

パスワード変更画面NavHostの構成定義に、初回ログインを表すパラメータを追加する必要があるようになります：

```Kotlin
NavHost(/**/) {
	/**/
	composable("${AppRoute.CHANGE_PASSWORD.route}/{${AppRouteParameter.CHANGE_PASSWORD_SCREEN_ARGS.value}}") { backStackEntry ->
        val changePasswordScreenJson =
                        backStackEntry.arguments?.get(AppRouteParameter.CHANGE_PASSWORD_SCREEN_ARGS.value) as String
        ChangePasswordScreen(
            navController = navController,
            arguments = changePasswordScreenJson.toChangePasswordScreenArguments()
        )
    }			
}

@Composable
fun ChangePasswordScreen(navController: NavController, arguments: ChangePasswordScreenArguments) { /**/ }
```

このパラメータを追加することで、このパラメータに依存する `ChangePasswordScreen` のビジネスロジックを実装することができます。しかし、動的な `startDestination` の問題はまだ解決していません。

## パラメータを持つ startDestination

### 1度目の挑戦：クラッシュ

`MainViewModel` では、`init` ブロックに、アプリが起動した後に、現在ログインしているユーザーの `firstLogin` の値を取得し、それに応じて startDestination を更新するコードを追加します。


```Kotlin
class MainViewModel(application: Application) : AndroidViewModel(application) {
    // ユーザーデータを含むFirestoreコレクション用のレポです。このブログとは関係ない内容です。
    private val userRepository: UserRepository =
        getApplication<App>().userRepository

    init {
        viewModelScope.launch {
            if (userRepository.isFirstLogin()) {
                updateStartDestination(
                    "${AppRoute.CHANGE_PASSWORD.route}/{${AppRouteParameter.CHANGE_PASSWORD_SCREEN_ARGS.value}}"
                )
            } else {
                updateStartDestination(AppRoute.HOME.route)
            }
        }
    }
}
```

現在、`firstLogin` を `false` に設定すると、アプリは正常にホーム画面にナビゲートされます。
しかし、`firstLogin` を `true` に設定すると、アプリは次のような例外を発生してクラッシュします：

```
java.lang.IllegalArgumentException: navigation destination change_password/{isFirstLogin:true} is not a direct child of this NavGraph

```

調べてみると、Jetpack Compose Navigation は Navhost 内のコンポーザブルの定義と `startDestination` が一致する必要があり、ルートに引数が含まれるとややこしいことになるようです。

### 2度目の挑戦：成功

解決策は、startDestinationとして使用する引数に `defaultValue` を指定し、さらにその `type` を指定する必要があります。今回の場合、引数はJSONで、これはStringです。

```Kotlin
composable(
    route = "${AppRoute.CHANGE_PASSWORD.route}/{${AppRouteParameter.CHANGE_PASSWORD_SCREEN_ARGS.value }}",
    arguments = listOf(navArgument(AppRouteParameter.CHANGE_PASSWORD_SCREEN_ARGS.value ) {
        //必要な変更点は以下の2行です。
        type = NavType.StringType; defaultValue = ChangePasswordScreenArguments(
            isFirstLogin = true
        ).toJson()
})
) {
    backStackEntry ->
    val changePasswordScreenJson =
        backStackEntry.arguments?.get(AppRouteParameter.CHANGE_PASSWORD_SCREEN_ARGS.value) as String
    ChangePasswordScreen(
        navController = navController,
        arguments = changePasswordScreenJson.toChangePasswordScreenArguments()
    )
}
```

# Credits

_Article Photo by [Leue, Holger](https://www.lookphotos.com/en-us/search?photographer=f5520)_

_Jetpack Compose logo [Google Developers](https://developers-jp.googleblog.com/2019/06/whats-new-with-android-jetpack.html)_

_Sextant Image [Freepik](https://www.freepik.com/free-photos-vectors/sextant)_


Jetpack Composeでナビゲーションパラメータ、ダイナミックなstartDestinationを実現


　こんにちは、モンスターラボで BackEnd の TechLead をしています、国平です。<br />
　このブログには、 [Docker on Lima](https://engineering.monstar-lab.com/jp/post/2022/01/12/Docker-on-Lima/) 以来の投稿になります。
今回は、モンスターラボの新卒採用における内定者イベントのレポートをしてみたいと思います。普段の技術的な話題から離れて、新卒内定者向けのイベントレポートを通して、会社の雰囲気をお伝えしてみようと思います。

　11 月初旬、モンスターラボで内定者向けに実際のプロジェクトに参加したメンバーから、プロジェクトの様子を伝えて、モンスターラボのプロジェクトはどのように行われているのか、その雰囲気を知ってもらうイベントが開催されました。
イベント参加者12 人に向けて、実際の案件に参加したメンバーがそれぞれの役割を話し、内定者からの質疑応答に答えるという内容で、リモートでの実施です。
![Event image]({{ sitePrefix }}/assets/img/articles/2022-12-20-New-Graduate-event-report-202211/event_image.webp)

　今回は、その題材として、角上魚類ホールディングス株式会社様と開発した[セリ原票アプリ](https://monstar-lab.com/cases/kakujoe/)の事例を取り上げてお話ししました。
私は、このプロジェクトにインフラエンジニアとして参画しており、その経験をお話ししました。また、私の他に UX デザイナーもこのイベントに参加しており、そちらは現場観察による行動分析をデザインに反映した経験をお話ししたようです。セリ原票アプリ開発における現場観察の様子は[こちらの記事](https://monstar-lab.com/ml-news/20221007_kakujo/)に少し紹介があります。

　私から特にお伝えしたのは以下の 2 点です。

1. **インフラがしっかりしていないとサービスが動かずお客様に迷惑がかかってしまう、大事な役割であること**

   特に今回のサービスは、学生が通常触るような To-Be サービスではなく、業務を支えるアプリケーションであり、その基盤であるインフラがしっかりしていないと、業務に支障が出てしまうことを伝えました。

1. **重要度が高いが、当然いくらでもコストを掛けられるわけではないので、プロジェクトの特性と予算に合わせる必要があること**

   特に、コストなどの制約は学生からはイメージしにくいのではないかと思って、あえて取り上げました。AWS Solution Architect のような資格でも、コスト最適化は重要な出題範囲となっています。

　セッションは、学生を 6 人ずつの 2 グループに分けて、15 分 x2 回行われました。
![Session image]({{ sitePrefix }}/assets/img/articles/2022-12-20-New-Graduate-event-report-202211/session_image.webp)

　インフラエンジニアと言う役割が、新卒内定者という学生たちからどのようなイメージを持たれているのか、うまく想像力が働かず、話す内容の選定に苦労しました。<br />
　特に 12 人の内定者は情報工学部卒に限らず広く採用されているため、個々人で知識レベルに差があることが予想されました。<br />
　また、学生たちからの質問を多く受け付けて、学生自身が積極的に今回の会に参加できるようにしてほしいという、ちょっとした隠しミッションも存在しました。<br />
　そのため、学生のインフラエンジニアに対するイメージが想像できなかったのとなるべく質問を受け付けたかったので、当日はあえて詳細な資料を作らず、こちらからどんなイメージを持っているのか、質問して持っている前提知識をヒアリングしながら進めてみました。<br />
　話してみて感じたのは、学生のデジタルサービスに対する理解度が高いということでした。インフラエンジニアの業務について知識はなくても、Web サービスやアプリがどのように動いているのかはすでに知識があり、アプリ、ブラウザ、サーバーが相互に通信してサービスが提供されているということは、前提知識としてちゃんと持っていました。この辺り、教科 情報によるリテラシー向上の結果でしょうか。<br />
　反応を見た感じだと、資料がなく口頭だけで伝えた内容もちゃんと受け取ってくれている感じがありました。<br />
　ただ、前提となること、伝えたいことは、もう少し資料にまとめておいた方が良かったなと反省しています。学生の理解力の高さに救われましたが、もう少し相手の出方に合わせ過ぎるのではなく、こちらの伝えたいことはまとめておいた方が短いセッション時間を有効に使えたとおもいます。

　また、私はインフラ専門のエンジニアではなく、バックエンドのテックリードとしてプロジェクトに参加することが多いのですが、そのテックリードとしての普段の業務内容についても質問を受けました。<br />
　そのほか、海外の開発拠点メンバーとのコミュニケーションについても質問を受けました。この経験談は、世界中に拠点を持つモンスターラボらしさが出る話ができたと思います。とても良い質問を投げてくれて感謝です。<br />

　このようにモンスターラボでは新卒採用も行っており、内定者に向けた会社理解度を高める取り組みなども行っています。
社員側としても、学生と話せる貴重な機会で、今の学生のリテラシーについて知れましたし、フレッシュな良い刺激を得られました。システム開発のプロジェクトとは、少し離れた機会ですが、良い経験になりました。
エンジニア業務として、こういったイベントへの参加が多いわけではありませんが、モンスターラボでは開発業務以外にもこういった色々な刺激を受けられる交流が行える会社であることを再認識できました。

24新卒採用も開始しております。<br />
少しでもご興味のある方は、こちら（[https://www.join.monstar-lab.com/newgraduate](https://www.join.monstar-lab.com/newgraduate)）よりエントリーお願いいたします！

多くの方とお会いできることを楽しみにしております。


モンスターラボ2023年度新卒内定者向けイベントレポート


10 月 25 日に第 6 回 Next.js カンファレンスが開催され、Rust ベースのバンドラーである[Turbopack](https://vercel.com/blog/turbopack)、Server component を実装した **app** ディレクトリ、既存コンポーネントのアップデート等が紹介されました！

[**Next.js conference**](https://nextjs.org/conf)

今回の大型アップデートの一つである **app** ディレクトリは数年前から議論がなされてきた**Layout RFC**の一つであり、
**Layout RFC** には **app** ディレクトリやそれに合わせて今回のアップデートで紹介された機能が含まれております。
本記事ではそのいくつかを紹介いたします。

**app** ディレクトリは beta 版ではありますが **Layout RFC** で議論されてきた内容が反映されており、
割と大きな変更であるため本記事を見てまず概要を抑えていただければと思います。

## NOTE

- この記事は Next.js を触ったことがある方向けです。
- **Layout RFC** の中で特に大きく変更のあるものについて書いてます、全てではありません。

# そもそも Layout RFC って？

Next.js の共同開発者である Tim Nuekens 氏により 2016 年から[Github discussion](https://github.com/vercel/next.js/discussions/37136)で話し合いがされている RFC(Request for comments)です。

2022 年 5 月に[こちらで](https://nextjs.org/blog/layouts-rfc)概要が発表されています。

それでは早速中身を見てみましょう！

## ルーティング

新たなルートとして **app**ディレクトリが追加されました。

大きな違いとして、従来の page ディレクトリでは、**ファイル名からパスが生成**されていましたが、**app** ディレクトリでは**ディレクトリ名をもとにパスが生成される**ようになります。

### **従来パターン**

ルート：**pages**

pages/index.js → `/`

pages/dashboard/**index.js** → `/dashboard`

pages/dashboard/**settings.js** → `/dashboard/settings`

![スクリーンショット 2022-10-11 22.19.55.webp]({{ sitePrefix }}/assets/img/articles/2022-12-08-nextjs-conf-assets/route_1.webp)

### **app ディレクトリパターン**

ルート：**app**

app/page.js → `/`

app/**dashboard** → `/dashboard`

app/dashboard/**settings** → `/dashboard/settings`

![スクリーンショット 2022-10-11 22.19.55.webp]({{ sitePrefix }}/assets/img/articles/2022-12-08-nextjs-conf-assets/route_2.webp)

この通り、フォルダ内がそのままルートパスになります。

かなり大きな変更ではありますが、**app** ディレクトリは pages ディレクトリと**並行して利用できる**ため、今回の RFC が実装されたとしても、従来の方法で使用されている pages ディレクトリには大きく影響がないと思われます。

## 命名規約に沿ったファイルの作成

上の **app**ディレクトリの場合に疑問に思った方もいらっしゃると思いますが、ディレクトリ名でパスが決まるのであれば**ファイル名はどうしたら良いのでしょうか**？

RFC によると各ディレクトリ下のファイルはその名前によって機能が定義されてます。

RFC では以下のファイル名が定義の対象とされてます。

- **`page.js`**
  - ディレクトリパスが呼ばれた際に読み込まれるページコンポーネント
- **`layout.js`**
  - ディレクトリパスが呼ばれた際にディレクトリ下で有効なレイアウトコンポーネント
- **`loading.js`**
  - ディレクトリパスが呼ばれた際のフォールバック用コンポーネント
- **`error.js`**
  - エラーが返された場合に遷移されるコンポーネント

`page.js`や`layout.js`についてもう少し詳しく見てみましょう。

## `page.js`

`page.js` は従来の Next.js において各ページディレクトリで定義されていた`index.js` に近い分類ですが、大きく違う点は page.js では**React18 で新たに実装された、server component がデフォルトで適応される点です。**（下記で紹介しています。）

### 従来パターン

![indexjs.webp]({{ sitePrefix }}/assets/img/articles/2022-12-08-nextjs-conf-assets/indexjs.webp)

### RFC パターン

![pagejs.webp]({{ sitePrefix }}/assets/img/articles/2022-12-08-nextjs-conf-assets/pagejs.webp)

## `layout.js`

layout.js も元々存在している layout コンポーネントですが、**今回の実装でネスト化されたルート内のみにレイアウトを適応することが可能となりました。**

### 従来のレイアウトコンポーネント

![layout_component_1.webp]({{ sitePrefix }}/assets/img/articles/2022-12-08-nextjs-conf-assets/layout_component_1.webp)

### ネスト化されたレイアウトコンポーネント

![nested_layout.webp]({{ sitePrefix }}/assets/img/articles/2022-12-08-nextjs-conf-assets/nested_layout.webp)

## React server component がデフォルトで実装

**app** ディレクトリ下で使用される`page.js` では React18 で新たに実装された server component がデフォルトで適応されます。

これにより`page.js` で定義されたコンポーネントはサーバー側で server component としてレンダーされるようになります。

React server component については[こちら](https://zenn.dev/g4rds/articles/287c53498d17a1)の記事で詳しく説明されています。（日本語）

[React 公式サイト](https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html)でデモも紹介されています。（英語)

React18 では`.server.js` , `.client.js` と拡張子によって各機能を定義するようにしており、Next.js では`page.js`に `.client` を追加することで client component として使用可能です。

</br>

`page.js` → server component (e.g. dashboard/**page.js**)

`page.client.js` → client component(e.g. dashboard/**page.client.js**)

</br>

ちなみに、**従来の page ディレクト下では server component を使用することはできません。**

server component を使用したい場合は新たに **app**ディレクトリを作成する必要があります。

[https://nextjs.org/blog/layouts-rfc#server-components-as-the-default](https://nextjs.org/blog/layouts-rfc#server-components-as-the-default)

## Data fetching

従来の`pages` ディレクト下ではページ単体で制限されていた Data fetching が今回のアップデートで`layout.js` でも呼び出しが可能となりました。

以下のようなフォルダ構成の場合、`blog/layout.js` でカテゴリーを Fetch し、サイドバーとして Render させ、`blog/[slug]/page.js` で blog データを Fetch、Render するような形が可能となります。

```
app
|_blog
 |_layout.js // カテゴリーデータをフェッチし、サイドバーがレンダーされる
 |_[slug]
  |_page.js; // ブログデータをフェッチし,コンテンツがレンダーされる
```

```jsx
// app/blog/layout.js
export async function getStaticProps(){
  const categories = await getCategoriesFromCMS();

  return {
    props: { categories };
  }
}

export default function BlogLayout({ categories, children }){
  return (
    <>
      <BlogSidebar categories={categories} />
      {children}
    </>
  )
}
```

```jsx
// app/blog/[slug]/page.js
export async function getStaticPaths() {
  const posts = await getPostSlugsFromCMS();

  return {
    paths: posts.map(post => ({
      params: { slug: post.slug },
    })),
  };
}

export async function getStaticProps({ params }) {
  const post = await getPostFromCMS(params.slug);

  return {
    props: { post },
  };
}

export default function BlogPostPage({ post }){
  return <Post post={post>
}
```

また、上記の場合`app/blog/[slug]`全体のルートが React server component としてビルド時に静的に生成され、クライアント側では server component で生成された静的なスナップショットを読み込むだけとなるためクライアント側で実行される JavaScript の量が更に少なくなりより早くページがインタラクティブな状態となります。

## 最後に

以上大まかではありますが、今回のアップデートで紹介された **Layout RFC** の機能をいくつか紹介させていただきました。

**Layout RFC** では上記以外にも[ルートのグループ化](https://nextjs.org/blog/layouts-rfc#advanced-routing-patterns)や[エッジケースに対応したルートパターン](https://nextjs.org/blog/layouts-rfc#advanced-routing-patterns)など紹介されていますので一読されることをお勧めします。

今回紹介させていただいた機能は NextJS13 のアップデートの一部であり、
Turbopack 等の紹介は割愛しておりますのでアップデートの詳細等は下記公式サイトからご確認ください。

# 参考

NextJS13:

[https://nextjs.org/blog/next-13](https://nextjs.org/blog/next-13)

NextJS13 へアップグレードしたい方

[Upgrade guide](https://nextjs.org/docs/upgrading)

# 出典

Photo source:

[NextJS Layout RFC](https://nextjs.org/blog/layouts-rfc)


[NextJS13] Layout RFC発のアップデート機能紹介！


# 初めに

この記事は、Figma でプラグイン作りたいがどうやって始めればいいかわからない、SolidJS で何かプロジェクトを始めたいけどアイデアをもらいたい方に向けて記載しています。<br>
Figma のプラグインを自分でも作れることを知っていましたか？<br>
Figma は Javascript で動作しており、プラグインも Javascript で作ることができます。<br>
今回はこの Figma の Plugin の UI 部分を Javascript フレームワークである SolidJS とビルドツールである、Vite（ヴィート）を使って、Figma のプラグインを作っていこうと思います。

# 使用する技術

### Solid.js 　

https://www.solidjs.com/

Plugin のメイン UI 部分になります。書き方、設計思想など React に影響されており、React に慣れ親しんだ人であれば違和感なく記述できます。<br>
React との大きな違いは、仮装 DOM を使わないので描画のパフォーマンスがいいなどが挙げられます。

### Vite（ヴィート）

https://vitejs.dev/

ビルド部分を処理するためのビルドツールです。フランス語で「高速」の意味で、Vue.js を開発された Evan You 氏が開発に携わっています。<br>
開発時にバンドルしないので、開発時のビルド速度が早くストレスなく開発できます。

### TypeScript

https://www.typescriptlang.org/<br>

フロントエンドの開発をする上で非常に頼りになる存在。<br>
最初から入れておくことで堅牢なコードを書くことができます。

# Figma プラグインを作る

実際に Figma プラグインを作るとなると、このブログでは書ききれない量になるので、サンプルコードを準備しました。<br>
サンプルコードをダウンロードしてから、フォルダ構成などを説明していきます。

### サンプルコードのダウンロード

```
git clone https://github.com/yuta-hidaka/figma-plugin-vite-solidjs.git
```

### サンプルコードのフォルダ構成

サンプルをダウンロードが完了したらフォルダの中身を覗いて見ましょう。 👀<br>
ファイル構成は以下のようになっています。

```
figma-plugin-vite-solidjs
├── README.md
├── dist                 # ビルドしたファイルたち
│   ├── code.js          # main.tsをES Buildしたファイル（Figmaとの疎通部分）
│   └── index.html       # Viteでビルドしたファイル（UI部分）
│
├── manifest.json        # Figma Pluginのメタ情報
├── src
│   ├── app.tsx          # Figma PluginのUI部分ソースコード
│   ├── index.html　　　  # app.tsx 読み込みHTML
│   └── main.ts　　　　　　# Figmaプラグインからのイベントをリッスンしたり、Figma APIを実行する。
├── tsconfig.json        # Typescript config
└── vite.config.ts.      # vite config
```

# 開発準備

依存関係の取得をして開発ができるようにします。

```
yarn install

yarn dev
```

# Figma Plugin を Figma で表示する

### Figma の準備

最初に Figma を開きましょう。<br>
Figma のダウンロードはこちら ⇨ https://www.figma.com/downloads/

### Figma にプラグインを読み込ませる

1. 右クリックで以下のボタンをクリック Plugins > Development > Import plugin from manifest...
   ![]({{ sitePrefix }}/assets/img/articles/2022-11-16-Create-Figma-plugin-with-Sloidjs-and-Vite/step1.webp)

2. manifext.json を選択して開く
   ![]({{ sitePrefix }}/assets/img/articles/2022-11-16-Create-Figma-plugin-with-Sloidjs-and-Vite/step2.webp)

3. プラグインを立ち上げる
   ![]({{ sitePrefix }}/assets/img/articles/2022-11-16-Create-Figma-plugin-with-Sloidjs-and-Vite/step3.webp)

4. オブジェクトを作ったりして遊べます！
   ![]({{ sitePrefix }}/assets/img/articles/2022-11-16-Create-Figma-plugin-with-Sloidjs-and-Vite/step4.webp)

# 仕組み解説

Figma とプラグインへの疎通方法<br>
このサンプルでは、以下のようにして Figma と疎通しています。<br>
Figma のプラグインは iFrame 内で動いているので、Figma のアプリに命令を出すときには parent.postMeaage を利用しています。逆の場合には figma.ui.postMeaage を利用します。

![]({{ sitePrefix }}/assets/img/articles/2022-11-16-Create-Figma-plugin-with-Sloidjs-and-Vite/diagram-ja.webp)

Plugin -> Figma への伝達方法<br>
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

Figma -> Plugin への伝達方法<br>
https://www.figma.com/plugin-docs/api/properties/figma-ui-postmessage/

ソースコードの`src/app.tsx:7`を見ると以下のようなコードがあり、Figma と疎通している部分を確認できます。

```
parent.postMessage({ pluginMessage: { type, payload } }, "*");
```

# もっと FigmaPlugin 開発について知りたい方

ここで紹介したサンプルコードは基本的な部分しか紹介していませんが、SolidJS の Store を利用することで状態管理しながら、複雑なプラグインの開発もできます。<br>

⇨ Figma の公式ドキュメントでもっと多くのことを試せるのでぜひ Figma の Plugin 開発者サイトも覗いてみてください。<br>

https://www.figma.com/plugin-docs/


Figma Plugin を Solid.js と Viteで作る


膨大な量のデータの時代に、バッチはアプリケーションと同じくらい、欠かせない処理です。<br>
バッチを起動するためにはフレームワークを選びつつデプロイ先も思考する必要があります。<br>
一般的と言えば Spring Batch, Kubernetes の Job や Cronjob、分散システムの場合 Hadoop、Apache Spark などの技術を使って Kubernetes 上デプロイの形です。<br>
ただし、小規模のプロジェクトまたは単独のバッチだと上記の導入は困難です。<br>
したがって以下の懸念点がありました：

- 導入&運用コスト
- モニタリングとログ記録
- ジョブの優先度&リトライ設定

そのため今回はクラウドプロバイダーから提供しているサービスを目指して AWS のバッチサービスを紹介したいと思います。
![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/aws_batch_console.webp)

## 概要

AWS Batch は AWS 上の各種リソースに、バッチ処理を簡単かつ、効率的に行うことができるサービスです。なお、先述した問題を解決できます。<br>
以下は基本の特徴をリストアップしながらプレビューしましょう。

#### コスト最適化

- フルマネージドサービスなので導入&運用コストゼロ
- AWS Batch に対する追加料金は発生しません。AWS リソースの費用のみがかかります。

#### モニタリングとログ記録

- メトリクスは AWS マネジメントコンソールに表示される
- コンピューティング性能や、実行中、完了済みなどのジョブの状態も確認することができる
- ログ AWS CloudWatch に書き込まれ、バッチ毎にログを確認できる
  ![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/batch_computing_monitoring.webp)

#### ジョブ実行、優先度&リトライ設定

- 複数ジョブキューで優先度を設定できて、リソースの無駄をコントロールが可能
- 条件によるリトライの仕組みがある。例: エラーコード=3 の場合リトライをする
- ML に応じるマルチノード並列、GPU の実行が可能
  ![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/fifo_multi_queue.gif)

主な機能を紹介しましたので、AWS の構成をみていきましょう。

## 構成

基本的に 3 つに分かれています：**ジョブ定義** (Job Definition)、**キュー** (Job Queue)、**コンピューティング環境** (Computing environment)
![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/batch_infra.webp)
実行できるまでには、最低限、以下のフローのように定義しなければなりません。

1. コンピューティング環境の準備<br>
   - バッチジョブ実行に必要とする CPU、メモリのリソースです。
   - 「コンピューティング環境画面」で設定できます。
     ![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/computing_env.webp)
2. ジョブキューの定義<br>
   バッチジョブにコンピューティング環境と優先順位を付ける設定です
   ![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/ba_create_job_queue_1.webp)
3. ジョブ定義<br>
   コマンド、コンテナ、パラメータなどの指定
   ![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/job_definition.webp)
4. ジョブ実行<br>
   ジョブ定義から実行できるジョブ設定が生成され、キューに入る
   このステップの入り口がいくつがあり、一般的にはイベントとしてトリガーしますが、Batch のコンソールで手動起動の形も可能です。

これで簡単のバッチを作成できますが、実際、自動化、通知などを求められるケースが多かったのです。その際にコンテナイメージ作成やトリガーの Eventbridge 設定必要となり、次に伝えます。

## スタディケース

AWS Batch は AWS プラットフォームと統合されていることから、AWS を利用している場合構築が最適的です。
以下のように crontab で DynamoDB を書き込むバッチを起動して結果を担当者へ通知するシステムを構築してみました。
![]({{ sitePrefix }}/assets/img/articles/2022-10-28-AWS-Batch/batch-practice.webp)
①② バッチスクリプトを含むイメージは、開発者がソースコードを変更した時点で（Github Actions で）ビルドされる。<br>
③ 開発者が AWS にログインし、EventBridge、Batch でジョブ定義、cron、通知などを設定する。<br>
④⑤ cron で起動したバッチジョブには、スポットインスタンスも同時にプライベート subnet 中に作成される。<br>
⑥⑦ バッチスクリプトが入ったコンテナ起動後、コマンドが実行される。DynamoDB のアクセスがプライベートで行われる。<br>
⑧ ログは Cloudwatch に送信されるが、AWS Batch コンソールから参照することができる。<br>
⑨ ジョブのイベント、ステータスを EventBridge で管理するため、実行エラーの際に SNS 経由で関係者を通告する。<br>
このようにセキュリティ向上のプライベートシステムができました。ややこしく見えましたが、実際に AWS Batch をメインに作業しますので、Kubernetes より実装しやすいと思います。

## 最後に

個人的にはすごく使いやすく良いサービスなのに、プラットフォーム利用料金が 0 というのはありがたいです。
AWS を使うのであれば AWS Batch は最強の選択肢であり、開発者の負担を減らしてプログラミングに集中することができるのです。
ぜひ活用してみてください。

## 出典

Photo source:<br>
https://aws.amazon.com/<br>


AWS Batchの活用


昨今 SNS などで **”カジュアル面談のはずが面接のような質問攻めだった”** など面談・面接の考え方に違いがあるようなコメントを見かけることがあります。せっかくお時間をいただけるのであれば有意義な時間にしたいなと考えております。そこで本日は弊社のカジュアル面談とはというテーマで弊社での定義を記事にさせていただきました。

## カジュアル面談の目的

モンスターラボのカジュアル面談は、転職活動において疑問をなんでも聞いていただける場としてご用意しています。お互いを事前に知り合える第一歩として懸念やご質問は惜しみなくディスカッションをさせてください。

![]({{ sitePrefix }}/assets/img/articles/2022-09-01-What-is-Monstarlabs-casual-interview/article_image1.webp)

事業や組織、ご興味をお持ちのポジションがあれば業務内容などをご説明させていただき、 **求めていらっしゃるキャリアとどのくらいマッチしているか** ご判断いただけるお時間を目的としております。

弊社では様々な職種の採用活動をしているので、ご志向性に合わせて **適切なポジション** のご紹介も可能です。

「転職をいますぐ考えているわけではないが、長期的なキャリアの観点からお話だけ聞いてみたい」  
「選考前に、事業や組織、社風についてより詳しく聞いてみたい」等、お気軽にご連絡ください！

## アジェンダ

形式として定めてはおりませんが、大まかなトピックは以下となります。各候補者様のご状況により内容は変更になる可能性がありますのでご了承ください。事前にご準備いただくものはありませんが、あらかじめ質問したいことをまとめておいていただけるとスムーズに進められるかと思います。

- キャリアのご志向性のヒアリング
- 弊社ビジネス概要のご案内
- 該当ポジションのご説明
- 面接プロセス
- 質疑応答

## お約束

弊社では、 **カジュアル面談はあくまでも弊社をご理解いただくお時間** にしていただきたいと考えているため選考要素は伴いません。

- 弊社カジュアル面談担当については各ポジションの採用リードまたは現場メンバーにてスケジュールが合う面接官を予定しております。
- 転職意向は必要なく、繋がりや発見をいただく機会の為、履歴書や職務経歴書等の書類の事前提出も必要ございません。
- もしカジュアル面談の実施後、ご興味を持っていただけるようであれば、正式にご応募いただければと存じます。
- 応募方法について面談もしくはメールでご案内いたします。

## 実施方法

オンラインで実施いたします。平日 10:00 開始 〜 20:00 終了の枠にて 30 分予定です。

![]({{ sitePrefix }}/assets/img/articles/2022-09-01-What-is-Monstarlabs-casual-interview/article_image2.webp)

## ご注意事項

当社にて現時点で適したポジションのご提案が難しいと判断した際は、面談を実施しないことがございますのであらかじめご了承いただけますと幸いです。  
オンラインの場合はネットワークの良い場所にてご参加いただき、画面共有しながらお話をさせていただくこともあるため、可能であれば PC よりご入室いただく方が見やすくなります。  
重複ご応募の確認のため、ご連絡先をご共有いただきます。

## 最後に

サイトからではお伝えしきれない情報も惜しみなく共有できればと思いますので、お気軽にご相談ください。弊社では皆様のキャリア・スキルアップを大優先で考えております。ご縁がある際は是非キャリアのサポートパートナーとして伴走できる日が来ることを楽しみにしております。

[採用情報](https://www.join.monstar-lab.com/)より弊社最新の求人をご参考ください。
どのポジションが最適なのかわからない場合はお気軽に[お問合せ](https://monstar-lab.com/contact/)ください。


Monstarlabのカジュアル面談とは


**TL;DR:** [NestJS Framework](https://github.com/nestjs/nest)を基に Node.js の backend スターターキットを構築しました。**モノリシック** なアーキテクチャを採用し、**REST API** を実装しています。

スターターキットはオープンソースでこちらの[Github Repo](https://github.com/monstar-lab-oss/nestjs-starter-rest-api)にて公開しています。

## はじめに

[Monstarlab](https://monstar-lab.com/jp/)では最新の技術ソリューションを用いて、企業様が抱えるビジネス課題を解決するべく、製品開発およびコンサルティングを行っております。

Monstarlab のエンジニアは 4〜6 ヶ月毎に新しいお客様のプロジェクトに関わることが多いです。新しいプロジェクトを開始するたびに、技術スタックやソフトウェアアーキテクチャなど、選定に多くの時間を費やしていることに気付きました。

ダイレクトな解決策がない点は仕方ないのですが、上記については改善の余地があるという結論に達しました。例えばロガーサービス、リクエストバリデータ、JWT 認証ミドルウェアは毎回設計をし直す必要がありません。

**Tada!** そこで、こちらのスターターキットを用意しました。

## ゲームプラン

このようなことが必要と思ったのは、私たちが初めてではありません。以前にもこの問題を解決しようとしましたが、意見の相違、モチベーション、時間管理など様々な理由で残念ながら失敗しています。
今回も同じような結果となることを心配していたので、異なる方法にて再度挑戦することにしました。

#### オープンソースにしておく

過去にこのような試みを行った際に、様々な理由からモチベーションが下がってしまったことが挙げられました。オープンソースにすることで、社外でも本プロジェクトが共有されるので、達成感がうまれました。

#### ハッカソン形式へ

このプロジェクトに貢献できるのはほとんどのメンバーが空いた時間にしかできませんでした。平日はクライアントプロジェクトに取り組むことが多いので、費やせる時間は非常に限られていました。
ブレインストームをした後に、私たちはこのスタータキットへの取り組みを週末に行うこととしました。Monstarlab はハッカソンを行ううえで多くのサポートをしてくれました。そのため、プロジェクトリリースやスケジュールを維持することができたのです。

![]({{ sitePrefix }}/assets/img/articles/2022-07-19-NestJS-Starter-Kit-Monstar-Lab-Edition-Jp/Q3-B&W.webp)

#### We need to go left, no right

このスターターキットに何を入れるか。または何を**入れてはいけないのか**。このようなディスカッションはいつも難しく時間がかかるものでした。

このプロジェクトに貢献できるのはほとんどのメンバーが空いた時間にしかできませんでした。平日はクライアントプロジェクトに取り組むことが多いので、費やせる時間は非常に限られていました。

結果:

- スターターキットはモノリシックパターンとマイクロサービスに基づくものの２種類に別ける
- モノリシックの中で、さらに REST API と GraphQL を構築
- 軽量にする
- 高度な機能を含めるために、スターターキットに構築された実際の制作プロフェクトを紹介する[サンプルソリユーションリポジトリ](https://github.com/monstar-lab-oss/nestjs-sample-solutions)を作成する

## Features

前述のようにスターターキットはできるだけ軽量にすることが大原則です。そこを踏まえスタータキットに追加された機能をご紹介します。

#### 認証

認証は、ほとんどの全てのプロジェクトで必要とされるものです。私たちは、ここで車輪の再発明したわけではありません。JWT 実装では、人気の高い Node.js ライブラリである PassportJS を使用して、重い作業のほとんどを代わりに行っています。bcrypt ライブラリを使用して、salts などを使ったパスワードのハッシュ化などが正しく行われていることを確認しています。よりエンタープライズグレードのプロジェクトでは、KeyCloak や Okta などの堅牢な ID 管理プロジェクトを使用するよう、皆さんにお勧めしたいと思います。今後、このような例を作っていくかもしれませんので、[サンプルソリューションレポジトリ](https://github.com/monstar-lab-oss/nestjs-sample-solutions)にご注目ください。ご質問がございましたらお気軽にご相談ください。

#### Authorization

認証の上に、多くのプロジェクトで次に必要とされるのが可能です。認可とは、ユーザーが何をすることができるかを決定するプロセスを指します。私たちは、基本的なロールベースアクセスコントロール（RBAC）認可モジュールを実装しています。このモジュールがどのように動作し、どの程度簡単に使用できるかを確認するには、プロジェクトリポジトリ内のこの[ドキュメントファイル](https://github.com/monstar-lab-oss/nestjs-starter-rest-api/blob/master/docs/acl.md)を参照してください。

#### ORM インテグレーション

ORM（Object-relational mapping とは、オブジェクト指向のパラダイムを使ってデータベースのデータを照会・操作できるようにする技術です。TypeORM はデータを操作するのに必要なコードをカプセル化するので、生の SQL を使う必要はもうありません。

#### DB マイグレーション

マイグレーションは、データベース内の既存のデータを保持しながら、アプリケーションのデータモデルと同期させるために、データベースのスキーマを段階的に更新する方法を提供します。DB スキーマのマイグレーションは、リレーショナル・データベースに関しては、常に多くの人にとって悪夢のようなものでした。TypeORM では、移行ファイルを簡単に生成することができます。

#### ロギング

NestJS には、独自のロガーが内蔵されています。しかし、それはテキストベースのロガーであり、プロダクションの要件には合いません。そこで、私たちは、非常に人気のあるプロダクションロギングパッケージである Winston をベースに、独自のカスタムロガーを実装しました。さらに良いのは、コールスタック全体でリクエストコンテキストを渡すことで、リクエスト ID、リクエストユーザーなどの追加情報を使って**コンテキストロギング** を行うことができることです。

#### バリデーションリクエスト

ウェブアプリケーションに送信されるデータが正しいかどうかを検証することは、ベストプラクティスです。NestJS は、強力な[class-validator パッケージ](https://github.com/typestack/class-validator)とその宣言的な検証デコレータを利用します。

#### ページ分割

REST API は、基本的なページングがないと完全とは言えません。私たちは、limit や offset といった単純なページネーションパラメータのサポートを追加しました。また、レスポンスには常に meta と呼ばれる子プロパティが含まれます。このプロパティには、リソースの総数などの情報が含まれており、フロントエンドアプリケーション側でのページネーションの実装をさらにスムーズにします。

#### Docker 準備

Need we say more?
![]({{ sitePrefix }}/assets/img/articles/2022-07-19-NestJS-Starter-Kit-Monstar-Lab-Edition-Jp/memegenerator.webp)

#### 自動生成された OpenAPI

これは NestJS で最も愛されている機能の一つです。OpenAPI 仕様は、RESTful な API を記述するために使用される、言語に依存しない定義フォーマットです。Nest では、デコレータを利用してこのような仕様を生成するための専用モジュールを提供しています。

#### 追加機能

上記の機能以外にも、私たちのスターターキットには、prettier integration、commit-linting husky hooks、package import sorting、SonarCloud github actions、データベース依存のための docker-compose など、たくさんの細かい素晴らしい機能が搭載されています。

## 最後に

先日、Monolithic + REST API をベースとしたスターターキットのメジャーバージョンをリリースしました。
長い間「作業中」でしたが、ようやく皆さんに試していただき、貴重なフィードバックを提供できる準備が整いました。

## What's next

#### ChangeLog の自動生成

このスターターキットのバックログは、これが最後です。この機能を最後に、このスターターキットに手をつけることはしばらくないと考えています。

次のロードマップは、GraphQL を使用したスターターキットです。

## リソース

- [Official NestJS Website](https://nestjs.com/)

_Article Photo by [Gaelle Marcel](https://unsplash.com/@gaellemarcel)_  
_Docker Meme Photo by [Meme Generator](https://memegenerator.net/)_


Monstarlab版NestJS スターターキット


入社して間もない頃、先輩から初めてコードレビューを依頼されたとき、光栄に思う反面戸惑いも覚えました。先輩の長年のコーディング経験に対して、自分のような若輩者が指摘できることなどあるのだろうかと戸惑ったのです。その時私が理解していなかったのは、最高のコードなんてものは存在しない、ということでした。ベストなコードとは、コードがないことなのです。[1](https://blog.codinghorror.com/the-best-code-is-no-code-at-all) 

プロジェクトに追加される新しいコードの１行は、すべからく、ビルド、テスト、レビュー、デバッグ、そして後で必要ならロードテストが必要となります。たとえば、仮にあなたがチームの中で最も経験豊富な開発者であったとしましょう。そのときあなたがどんな解決策を提案しようとも、それを承認してもらうことなく追加することができるような、白紙委任状を与えられたような状態になってしまってはいけません。

コードを書くということは、簡単に言えば、解決すべき問題の理解度とそれを解決する人のスキルによって、最適な解決策を提案することです。人間である以上、間違いや判断ミス、無知はつきものです。だからこそ、効果的なコードレビューを実施することが重要なのです。

この記事では、まず、コードレビューのベストプラクティスをいくつか紹介します。次に、採用候補者のコードチャレンジのレビューにおける、具体的なケースを簡単に説明します。

## 時間はかけても無駄にはしない

コードのレビュー時間は、短すぎるのも問題ですが、かといって長すぎるのもよくありません。レビューの要求ペースに圧倒されてしまい、基本的なチェックだけで済ませてしまいたくなることはよくあります。しかしコードレビューの時間は、タスクのしっかり見積もり、時間をとるべきです。「どうせこれは手作業でテストするのだから」という罠にはまらないようにしましょう。

また、レビュー時間が長くなってしまうことは、タスクの分割がうまくできていれば避けられます。必ず、特定のロジックだけを扱うような、小さなタスクに分割するようにしましょう。一度に全機能をレビューするよりも、そうした方が楽です。

## チェックリストの使用

レビューチェックリストを用意することで、コードの一貫性を担保することができます。コードは同じ基準で評価され、抜け漏れがないことを確認することができます。このリストは、チームの経験値に合わせて常に更新していく必要があります。

![]({{ sitePrefix }}/assets/img/articles/2022-04-06-Best-practices-for-doing-code-reviews/spring-boot-java-checklist.webp)

## 自動コードレビューツールの使用

コードレビューのプロセスを支援するための、効率的でカスタマイズ可能なコードレビューツールやアナライザツールがたくさんあります。 [2](https://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools).

![]({{ sitePrefix }}/assets/img/articles/2022-04-06-Best-practices-for-doing-code-reviews/sonar-cloud.webp)

![]({{ sitePrefix }}/assets/img/articles/2022-04-06-Best-practices-for-doing-code-reviews/linting.webp)

## ローカルでビルドし、必要なときにテストする

コードを見るだけでは、重要なエラーを発見できないことがあります。例えば、バッチ処理をレビューする場合、コードのビルドをローカルで実行することで、目視で確認するよりも多くの情報を得ることができます。しかし、この時点で発見されたものは、テストコードの品質が低いことを意味する可能性もあることに注意してください。

## コードレビューのやり方

コードレビューの実施方法はチームによって様々です。多くの方は GitHub にコメントを書いたり、Slack でフィードバックメッセージを送ったりするのが主なレビュー方法かと思います。

しかし時間が許す限り、ペアプログラミングを行ったり、開発者とのレビューミーティングを行ったりしましょう。これらの方法はただコメントを残すよりも効果的で、よりインタラクティブであり、良いメンタリングの手段でもあります。

命令するのではなく提案をし、なぜそれがより良い方法だと思うのか、常に理由を伝えましょう。そうすることで開発者がよりよく理解できるようになります。

間違いを見つけることだけに集中せず、ポジティブなコメントも常に歓迎されます。あなたが感動するような、巧妙で魔法のようなコードに出会ったら、親指を立てたり、褒め言葉を書いたりしてください。そうすることで開発者に感謝され、よりよい仕事上の関係を築くことができます。

## レビューの際に確認すべきこと

- 要件は満たされていますか？
- コードは良い設計原則に従っていますか？
- コードはどの程度複雑ですか？読みやすいでしょうか？
- パフォーマンスとスケーラビリティの問題はどうでしょう？データはシステムの最も重要な部分であることを常に念頭に置き、大規模なスケールでどのように動作するかを常に考える必要があります。
- セキュリティの問題は？SQL インジェクション、XSS、個人情報の取り扱いなど、潜在的なセキュリティ上の脅威がないかどうかを確認します。
- コードにきちんとコメントが書かれていますか？
- 保守性についてはどうですか？コードは DRY でしょうか？
- コードのスタイルは、事前に定義したガイドラインに従っていますか？
- 再利用性、命名規則などについてはどうでしょうか？

## コードチャレンジのレビュー

上記の内容のほとんどは、採用候補者コードチャレンジのレビューをする際にも当てはまります。解決すべき問題は通常単純であっても、候補者を次の採用ステップに進めるかどうかを判断するのに役立つ興味深い点があります。

審査基準には、以下のものが含まれますが、これらに限定されるものではありません。

- 与えられた要件を理解する能力
- 問題解決へのアプローチ
- 提案されたソリューションのコア・アーキテクチャとデザイン
- 初期設定の複雑さ：OS に依存せず、箱から出してすぐに動くこと。
- 使用する技術スタックの選択
- 提案されたコードの品質...

また、コードレビューを行う側への注意として、採用候補者のコードレビューを行う際に、これらのコードチャレンジはコンテストではない、ということを常に念頭に置いておくべきです。候補者が提案したソリューションが、以前にレビューした他の候補者のコードよりも見劣りしたからといって、ペナルティを課してはいけません。

## 結論

優れたコードレビューは、本番環境に移行する前に潜在的な問題を発見することで、時間とコストの節約になります。さらに、技術やヒントを共有することで、より良いチームコラボレーションを構築することができます。特に、多くの開発者が孤立して時間を過ごしているこの時代、GitHub にコメントを残すだけでなく、コードレビューのために会う時間を取りましょう。

### Thanks for reading!

## References

[1] [The Best Code is No Code At All](https://blog.codinghorror.com/the-best-code-is-no-code-at-all)

[2] [TOP 40 Static Code Analysis Tools](https://www.softwaretestinghelp.com/tools/top-40-static-code-analysis-tools)

[3] [How to do a code review](https://google.github.io/eng-practices/review/reviewer)


コードレビューをしよう

Ousama Abdellaoui

インフラを管理する側から、作る側へ