Blog

[Modern Backend] 講座 Part 1の5回目、「並列API呼び出しのリファクタリング（1）」の講義です。 今回の講義では、掲示板プロジェクトの添付ファイル検証およびサムネイル生成ロジックを、従来の CompletableFuture 方式から Java 25 の構造化並行性（StructuredTaskScope）ベースのコードへ移行するための、事前の構造分析とリファクタリング設計のプロセスを進めます。 📌 主な学習内容： * リファクタリング対象ファイルの分析および、従来の CompletableFuture ベースの並列API呼び出し方式の検討 * 従来方式の限界の分析（例外発生時に、他の並列タスクへ cancellation／キャンセルを伝播できない問題、およびスレッドのライフサイクルに関する問題） * 単体テスト（PostCreationCoordinatorTest）を通じたキャンセル未伝播現象の確認 *

[Modern Backend] 講座 Part 1の4回目、「構造化された並行性（Structured Concurrency）」の講義です。 今回の講義では、Java 25でプレビュー（JEP 505）として提供される構造化された並行性の概念と必要性、そして従来の並列処理方式が抱えていた問題をどのように解決するのかを見ていきます。 📌 主な学習内容： * 並列処理の基本概念（Fork & Join、Thread Pool） * 同時性（Concurrency）と並列性（Parallelism）の明確な違い * CompletableFutureベースの従来の非同期／並列処理における3つの問題点（キャンセルの伝播漏れ、リソースリーク、例外処理の断片化） * 仮想スレッド（Virtual Thread）の時代に構造化された並行性が必要な理由 * StructuredTaskScopeを活用した

最新のバックエンド技術スタックである Java 25, Spring Boot 4, GraalVM Native, そして Spring AI 2.0を扱う [Modern Backend] マスタークラス講座のオリエンテーション動画です。 本講座は、既存のSpring Boot環境でサービスを構築・デプロイした経験のある開発者を対象に、 次世代バックエンド技術スタックへの移行を目指して企画されています。

概要 プロジェクトを進めていると、OOMまたはOOMKilledに遭遇することがあります。特にKubernetes環境では、「PodがOOMKilledによって再起動された」という状況にしばしば遭遇します。 OOMKilledは単にサーバーが再起動されたように見えることがありますが、原因を把握しないまま放置すると、サービス負荷が高い状況で繰り返し発生し、致命的な障害につながる可能性があります。 この文書は、プロジェクトを進める中で遭遇したOOMKilledとは何か、なぜ発生するのか、そしてどのように分析・解決すべきかを調査・検討した内容をまとめたものです。 OOMとOOMKilledの違い OOMであれOOMKilledであれ、どちらもメモリ割り当てに関連して発生する問題です。しかし、両者には発生主体と動作方式に違いがあります。 OOM (Out Of Memory Error)はJVM内部で発生します。Heapメモリがいっぱいになり、これ以上オブジェクトを割り当てられなくなると、JVMがjava.lang.OutOfMemoryErrorを発

- 2026年、Javaベースのバックエンドの基準が変わりました。- 過去8か月間の変化 2026年7月現在を基準にすると、過去8か月間でJavaバックエンドスタックの主要な構成要素が同時に世代交代し、変化しました。 この期間における各技術の新しいバージョンへの変化を個別に見れば、単なる時間の経過に伴う変化だと単純に考えることもできます。しかし、これらの変化は互いに変化を必要としています。 * Spring AI 2.0は、Spring Boot 4.xとSpring Framework 7を前提として設計されています。 * Spring Boot 4.xは、Jakarta EE 11とJackson 3の上で動作します。 このような連鎖的なエコシステムの変化は、実務現場における迅速な移行を求めています。 しかし、いつものことですが、実際の現場におけるバージョン分布がこの速度に追いついていないのも事実です。 [AzulのState of Java 2025調査結果] *

1. はじめに アンケート管理サービスは、利用者がオンラインでアンケートに回答し、担当職員や管理者がその結果を確認・管理するサービスです。一見すると単純ですが、利用者・職員・管理者など役割ごとに権限や画面遷移が異なり、会員登録の有無によって認証方式も複数に分かれています。さらに、外部連携システムとのデータ同期まで関係しているため、個々の機能が正常に動作するだけでは、サービス全体の品質を保証することが難しい構造でした。 本プロジェクトではQAを担当し、要件定義書を基に統合テストシナリオを自ら作成し、それを開発(dev)、ステージング(stg)、本番(prod)の3段階の環境で実行・管理する業務を行いました。その結果、最終的に71個のテストシナリオ(TS)と376個の詳細テストケース(TC)で構成された統合テストドキュメントを作成し、運用しました。 この記事では、単に「テストを実施した」という結果報告にとどまらず、なぜこのような構成でシナリオを設計したのか、どのような基準で例外ケースを導き出したのか、そしてドキュメントをどのように管理すれば長期にわたって信頼でき

一般的なサーバーアプリケーションでは、エンティティ間の関係はデータベースの外部キーとJPAの関連関係で表現されることが多くあります。この方式は強力です。親のない子の保存を防ぎ、親を削除した際に子の削除を伝播させることができ、オブジェクトグラフに沿って保存と削除をまとめて処理することもできます。 しかし、実際のドメインにおける関係の変化は、単純なリポジトリレベルの関係処理よりも広いものです。あるエンティティが削除されると別のエンティティも削除しなければならない場合がありますが、場合によっては空の親を先に作成したり、兄弟エンティティを同時に作成したり、関連する値を再計算したりする必要があります。この記事では、Vizendの基本プロジェクトにおけるJPO構造を出発点として、なぜ関係をアプリケーションレベルで扱おうとするのか、そしてその補完方法を整理します。 1. JPOを簡潔に保つということ Vizendの基本プロジェクトのJPOは、概して簡潔です。JPOはJPA Entityですが、関係を豊富に表現するORMモデルというよりは、ドメインオブジェクトを永続化するた

– 良いプロンプトはどのように設計するのか？ 1. はじめに Claude Codeの講義を制作する中で、説明のためにさまざまなソースコードを生成し、変更し、テストしました。AI以前の時代には、実習用のコードを作るためにかなりの時間をかけて考え、修正する作業が日常的でした。一方、今では数語のプロンプトによって、数分で望んだコード、動作するコード、テストケースを一度にすべて通過するコードを作れるようになりました。そのたびに、コードを作る人から、作られたコードを検証する人になったのだと感じるようになりました。 そして、AIとの協業において重要なのは、生成されたコードをさまざまな観点から検証することです。また、最初にコードを生成するために何を考慮し、どのようにプロンプトを作るのがよいのかという普遍的な課題について、改めて考えるようになりました。 掲示板の例を構成する際、次のようなプロンプトを入力しました。 “게시글에 댓글 기능을 추가해줘.” 結果は数分で出ました。Commentエンティティが作成され、Service、Controller、JPAベース

パート1. データ可視化と協業プロセス 1. 背景：アジャイル手法とSIエコシステムの制約 1.1. アジャイル手法の本質：変化への機敏な対応と柔軟性 現代のソフトウェアエンジニアリングエコシステムにおいて、不確実性の高い市場環境に対応するための手法として、アジャイル（Agile）の価値は継続的に強調されてきました。アジャイル手法の本質は、事前に策定された固定的な計画を厳格に遵守することではなく、プロジェクトの進行過程で発生する 変化に機敏かつ柔軟に対応することにあります。 短い開発サイクル（IterationまたはSprint）を繰り返しながら実行可能なソフトウェアを継続的に納品し、そこから得られたフィードバックを製品に段階的に反映していくプロセスが、アジャイルの目指す中核的なプロセスです。 1.2. 開発PMとしての自覚とプロジェクト管理システム（PMS）の発展方向 さまざまなビジネスドメインでプロジェクトを高度化する開発PMの視点から、複数の協業ツールやプロジェクト管理システム（Project Management System、以下

Webアプリケーションの規模が巨大化し、複雑性が幾何級数的に増大するにつれて、私たちが使用する開発ツールや言語にも大きな変化が訪れました。その中心にあるのが、かつてWebブラウザ向けの簡単な動的スクリプティングのために設計されたJavaScriptの限界を克服するために登場した「TypeScript」です。本稿では、TypeScriptの核心概念を深く分析し、実務で直面するさまざまな特性や注意点を徹底的に解説します。 1. TypeScriptを使う理由 JavaScriptは世界で最も広く使われているプログラミング言語の一つですが、生来の柔軟性ゆえに、大規模プロジェクトでは深刻な欠陥を引き起こすことがあります。TypeScriptは、このようなJavaScriptの欠点を補うために開発されました。TypeScriptを導入すべき主な理由は、次の3つにまとめられます。 1.1. コンパイル時のエラー検出による安定性の確保 JavaScriptは「動的型付け（Dynamic Type）言語」です。変数の型が実行時（Runtime）に決定されるため、開発者がコ

VaultはVizend内のファイル管理サービスです。Vaultでは、ファイルのデータ構造が参照ファイルと物理ファイルに分けられています。 参照ファイルは物理ファイルを参照する構造であり、実際のファイルを複数人が所有することになっても、実際に使用されるストレージ容量は1つのファイル分だけです。 私がVaultの機能を保守する中で経験した限りでは、大きく3種類に分かれるようです。 vaultは大きく3種類のストレージに分かれます。 ストレージの種類 1) 個人ストレージ：Stash * フォルダー構造を持つ個人ストレージ 2) 一般ストレージ：Cabinet / Clip 告知や投稿の添付ファイルなど、「一般的な添付ファイルストレージ」として使用されます。 * Cabinet：Clipのまとまり（コンテナ）という概念 * Clip：ClipFile（参照ファイル）のまとまりという概念 * 適用範囲／単位は、サービス（devli

最近、VizendではThirdPartyログイン機能の導入およびリファクタリングを行いました。ThirdPartyログインは、Google、Apple、Facebook、Keycloakなどの外部認証手段を通じてユーザーを確認し、その結果をVizendの内部ユーザー体系と連携する機能です。ユーザーから見える画面では、よくある「外部アカウントでログイン」ボタンのように見えますが、サーバーの観点では、外部認証の結果を内部アカウント、登録ポリシー、アカウント連携ポリシー、セッションポリシーにどのように結び付けるかが重要です。 今回の作業で重視した点は、外部認証と内部ログインを分離することでした。外部providerは、ユーザーが特定のアカウントの所有者であるという事実を確認できます。しかし、そのユーザーがVizend内部でアクティブな状態か、どの企業に所属しているか、どの権限を持つべきか、サービスへのアクセス条件を満たしているかは、providerには判断できません。この判断は、Vizendのユーザーモデルと認証ポリシーの中で行う必要があります。 したがって、Thir

1. トークン交換（Token Exchange）の基本概念 マイクロサービスアーキテクチャ（MSA）環境で、複数のサービス間で権限を委譲したりトークンを再発行したりする必要がある場合、Keycloakが提供するトークン交換（Token Exchange）機能は非常に有用なソリューションです。これは、認証済みのクライアントが既存のトークンを提出すると、Keycloakがそれを検証した後、送信先に適した新しい権限と対象を持つトークンに交換してくれる技術です。サービス間の信頼関係を明示的に定義し、権限の範囲を制御できるため、エンタープライズセキュリティの中核基盤となります。 2. 連携要件とImpersonationの採用 最近のプロジェクトの進行中、すでに他社プラットフォームで認証を完了したユーザーが自社サービスにアクセスする際、ログイン画面や別途の追加ログイン処理なしで利用できるようにしてほしいという要件がありました。ユーザーが二度ログインせずに済む、シームレスなUXを実現することが課題でした。 正統なKeycloak V2標準エンジンを適用しようとし

はじめに 私たちの環境にはサーバーがたくさんあります。1、2台ではなく、100台を超えるサーバーが存在しています。そして、それらのサーバーには共通してNexusが導入されています。外部ライブラリやパッケージを取得する際、毎回インターネットから直接取得する代わりに、近くのNexusが一度取得してキャッシュし、高速に配布してくれる「中間倉庫」の役割を果たします。外部ネットワークが不安定な環境では、これはかなり重要な仕組みでした。 問題は、これらのNexusごとにproxy設定を同じように行う必要があり、さらにRepositoryを追加したり、複数の設定を追加したりすることも多い点でした。どの外部リポジトリを参照するか、どのリポジトリをまとめて表示するかを、サーバーが数十台もある場合は何十回も設定しなければなりませんでした。1台に入って設定し、そこから出て次の1台に入り、また同じ設定をするという作業の繰り返しでした。 最初の数台は何とかなりました。しかし、サーバーが徐々に増えるにつれて、あるサーバーでは設定を忘れ、別のサーバーでは入力ミスがあり、また別のサーバーで

自己自身をデプロイするプラットフォームのサブスクリプション設計 Vizend Kollex サブスクリプションで直面した分散デプロイの整合性問題と解決策 1. 背景と問題定義 Vizend Showcaseは、Kollex（複数のマイクロサービスをまとめたデプロイ単位）をPavilion（テナント）単位のKubernetesクラスターにGitOps方式でプロビジョニングするプラットフォームです。Kollexは、ユーザーに公開される画面単位であるEpisodeと、そのEpisodeを支えるプラットフォームバックエンドサービスであるDrama（gate・metro・porto・showcaseなど）で構成されます。ユーザーがKollexをサブスクライブすると、Showcaseはサブスクリプションの事実をSubscriptionLifecycleEventとしてMetro（認可・サブスクリプション状態を管理するプラットフォームサービス）に発行し、同時にGitOpsリポジトリへKubernetesマニフェストを書き込んだ後、ArgoCDで同期します。つまり、デプロイ

1. 背景 最近のプロジェクトでプログラムを運用する過程において、「kubectl get nodes」で「NotReady」状態になっていたり、「kubectl exec」が応答しなくなったり、Podが突然Evicted状態に変わったりするなど、さまざまな問題に遭遇しました。そこで、実際の運用中に遭遇した4種類の障害に基づき、事例を中心としたKubeEdge環境での問題対応ガイドを以下のようにまとめます。 2. はじめに Kubernetesベースの一般的なクラスターとは異なり、KubeEdgeにはクラウドとエッジノードの間に CloudCore ↔ EdgeCore トンネルが追加で存在します。そのおかげで、ネットワークが不安定な現場環境でもエッジノードを運用できますが、同時に障害の原因もさらに複雑になります。 3. 障害の種類 障害の種類1 kubectl execの失敗 — "unexpected EOF" (1) 症状  $ kubectl exec -it my-app-6jf2m -n iot

産業用 IoT やロボティクス環境でシステムを設計していると、必然的に多数のセンサーデータや制御命令をリアルタイムで処理しなければならない課題に直面します。ROS2(Robot Operating System 2)は、このような問題の解決に活用できます。 ROS2には「オペレーティングシステム(OS)」という名前が含まれていますが、WindowsやLinuxのような実際のオペレーティングシステムではなく、ロボットアプリケーションを容易に開発できるよう支援するソフトウェアフレームワークです。名前に「ロボット」と入っていますが、その本質は強力な非同期分散通信アーキテクチャです。効果的なセンサーデータ収集に活用されるROS2のデータフローを理解したうえで、これをどのように設計し、デバッグするのかを見ていきましょう。 1. ROS2通信：DDSと非同期Pub/Subパターン ROS2アーキテクチャを理解するうえで、最初に知っておくべき概念はDDS(Data Distribution Service)です。DDSは、分散システム環境でデバイス間のデータを高速かつ安定

1. はじめに 私は、複数の人が一つのチャットルームに集まり、メッセージをやり取りしたり写真を共有したりするリアルタイムチャットサービスを開発しています。一般的に使われているメッセンジャーのように、更新ボタンを押さなくても相手が送ったメッセージがすぐに自分の画面に表示されるサービスです。 リアルタイムチャットを作る際に、最初に直面する悩みは、「誰かがメッセージを送ったとき、同じ部屋にいるほかの人たちへ、どうすればすぐに知らせられるのか」ということです。一つの部屋に10人いて、そのうち1人がメッセージを送ったら、残り9人の画面にほぼ同時にそのメッセージが表示されなければなりません。 最も単純に思いつく方法は、「メッセージ本文をそのまま9人にリアルタイムで送ること」です。しかし、私たちはこの方法を選びませんでした。代わりに、メッセージ本文ではなく「何かが起きた」という軽い通知だけを送り、実際の内容はクライアントが再度取得するように設計しました。 この記事では、なぜこのような選択をしたのか、どのように適用したのか、その過程でどのような問題に遭遇し、どう解決した

1. 概要 この記事では、履修登録や予約申請のような先着順の申請システムで発生する大量リクエストの処理について、DBトランザクションを中心とした最適化の経験をまとめています。 このシステムは、申請開始直後に 短時間で数万件のリクエストが集中するという特徴があります。ユーザーは照会、申請、キャンセルを繰り返しながら、最大単位数、申請可能人数、予約上限など、複数の条件を満たす必要があります。そのため、データの整合性を維持するためのデータベーストランザクション処理が非常に重要です。 実際の運用環境では、約2万人のユーザーが同時にサービスを利用し、5分から10分の間に、約8万件から10万件程度の申請およびキャンセルリクエストが発生しました。この環境では、申請情報の作成と申請者数集計データの更新が主要なトランザクション処理の対象でした。 2. 初期実装と性能問題 プロジェクトの開発完了後、Apache JMeterを使用して、運用環境と類似した条件で負荷テストを実施しました。初期実装では、申請APIとキャンセルAPIのそれぞれで、APIの開始時点から終了時点まで

スケジュールのプレッシャーとドメイン設計における現実的な落とし穴 新しいプロジェクトを始める際、多くの開発者はドメイン駆動設計（DDD、Domain-Driven Design）の価値を頭では理解しながらも、現実的な妥協案を選びがちです。特にビジネスの早期リリースを求められるスケジュールのプレッシャーの中では、精緻なドメインモデリングに長い時間を費やすことは困難です。 現場人員管理プラットフォームのプロジェクトでも、開発初期からDDDの思想に基づいてビジネスコードを作成しようと試みました。しかし、逼迫した開発スケジュールの中で急いでドメインを設計していくうちに、アーキテクチャ上重要な核心部分を見落としてしまいました。 当時直面した設計上の限界は、大きく三つありました。 1. ドメインアグリゲート（Aggregate）の範囲設定の欠如: 個々のドメインオブジェクトが、どのライフサイクルとトランザクション範囲を共有すべきかを明確に定義できていませんでした。 2. 値オブジェクト（Value O

「資料をLLMに放り込めば、文書一冊くらいすぐに作れるだろう」と考えた瞬間から、実際の問題解決が始まりました。 最近参加したアーキテクチャコンサルティングプロジェクトで、数十個のビジネス境界（Bounded Context）と数百個のサービスを整理した大規模なサービス定義書を作成する必要がありました。入力資料は、複数のシートで構成されたサービスカタログのExcelファイルと、既存の分類体系を整理した24ページのWord文書でした。目標は、これらの資料を基に分類軸を変更した新しい定義書を、統一された書式のWord文書として作成することでした。 最初は単純に考えていました。資料をLLMに渡し、「この構造で文書を作成して」と依頼すればよいと思っていたのです。しかし、実際の成果物は予想とはまったく異なりました。最初の成果物はなんと187ページにも及び、分量だけでなく書式や構造も、そのままでは使用できない状態でした。 この記事では、LLMで大規模な技術文書を生成する際に直面した、分量の急増と書式崩壊の問題を、入力分割・構造再設計・生成ツールの切り替え・整合性検証という4

1. はじめに プロジェクトを進める中で、ユーザーが画面上で確認したデータをExcelとしてダウンロードする機能を開発することになりました。単にデータを書き出すのではなく、ユーザーが画面上で見ている形式とできるだけ同じ結果をExcelでも提供することこれが要件でした。 たとえば、ステータス値に応じて文字色が変わったり、特定の行が強調表示されたり、ヘッダーに個別の背景色が適用されたりする場合など、ブラウザ上の視覚的な要素もExcelで維持する必要がありました。 最初は、ag-Gridが提供するexportDataAsExcel()メソッドを呼び出すだけで、画面と同じ結果が生成されると思っていました。しかし実際には、ブラウザのレンダリング方式とExcel Exportの動作方式が異なるため、スタイルが維持されませんでした。この問題を解決するために経験した試行錯誤と解決プロセスを共有したいと思います。本記事はag-Grid v28.0.2環境を基準に作成しており、バージョンによって一部の動作やサポート機能が異なる場合があります。 2. 画面とExcelのデー

これまで主にウェブ環境でパブリッシング業務を行ってきました。レスポンシブウェブ制作の経験はありましたが、モバイル環境で本格的にUIを構成し、動作を実装したのは今回が初めてでした。最初は、モバイルも結局はウェブ技術を基盤としているため、従来の方法と大きくは変わらないだろうと考えていました。しかし、実際に作業を進める中で、モバイルは単に画面サイズが小さいウェブではないということを、さまざまな面で実感しました。 モバイル環境では、レイアウト構造だけでなく、ユーザーの入力方法、画面の高さの計算方法、スクロールの処理方法、アクセシビリティへの対応方法など、さまざまな要素を同時に考慮する必要がありました。特に、ウェブで自然に使用していた方法がモバイルではそのまま適用できないケースが多く、新しい基準を継続的に学んでいく過程でもありました。 モバイルで最初に実感した違いは、ユーザーの入力方法でした。ウェブ環境ではマウスを基本とするため、hover状態を活用したインタラクションが非常に一般的です。 .button:hover{ background-color: #f5f5f5

複数の製品ラインアップを同時に開発・運用・拡張しなければならない環境で、実務デザイナーが直面する構造的な問題を解決するための考察を行います。提示された3つの主要なブランドアーキテクチャモデル（ハウス・オブ・ブランズ、ブランデッド・ハウス、ハイブリッド）の概念を深く掘り下げ、ビジネスコンテキストとデザインインフラ構築の実務的な接点を詳しく定義します。 1. マルチプロダクト環境におけるデザイナーの現実的な課題とブランドアーキテクチャの必要性 会社が成長し、ビジネスが高度化するにつれて、単一プロダクト体制から複数の製品を同時に運用するマルチプロダクト環境への移行は必然的に起こります。デザイナーにとって、製品が1つだけのときは、1つの画面と固定されたブランドガイドラインだけに集中すればよいため、インターフェースの構造的な断片化や全体的な結合度について悩むことは比較的少ないかもしれません。しかし、新しいサービスが次々とリリースされたり、ビジネスドメインが拡張されたりする瞬間、デザイナーの前には、従来の単一システムでは簡単に解決できない、まったく新しい次元の問いが突きつけ

はじめに 最近のプロジェクトで、React Hook Form（RHF）とMaterial UI（MUI）をベースに、さまざまなフォーム画面を実装しました。 プロジェクトの初期段階では、フォームUIの一貫性を維持するために共通Fieldコンポーネントを構築し、使用していました。 <Field.Text name="name" label="Name" /> 開発者は上記のような方法で入力フィールドをすばやく構成でき、React Hook FormとMUIを直接接続する必要もなく、共通コンポーネントだけを使用すればよい状態でした。 実際のサービスでは、次のようなさまざまな入力コンポーネントを提供していました。 * Field.Text * Field.Select * Field.Autocomplete * Field.DatePicker * Field.DateTimePicker *