Blog

- 決済 SDKを再利用可能なReact共通コンポーネントとして実装した経験 - 1. SDK共通コンポーネントとして実装するに至った経緯 実際の決済画面で処理すべきビジネスロジックは、単にSDKを呼び出すだけにとどまらない幅広いものでした。 * 会員および非会員顧客キーの設定 * 決済金額の変更内容のリアルタイム反映 * バックエンドでの決済データ生成および連携 * インラインおよびポップアップ決済方式の同時サポート * 決済成功時および失敗時のリダイレクト処理 * 決済エラー発生時のバックエンド状態更新 * 重複決済リクエスト防止ロジックの適用 * React Native WebView環境への対応 このようなロジックを各画面で個別に実装すると、重複コードが増えるだけでなく、決済処理ルールの一貫性を維持することが非常に難しくなりま

- ダウンロードボタン一つのためにパッケージ全体を取り込んでいた問題を解決するまで - 1. はじめに この第3四半期、社内メッセンジャーサービスLoopinの7.2アップデートを担当しました。その中の一つに、「チャットで受け取ったファイルも自分のファイルボックスに残るようにしたい」という要件がありました。 同じ機能はすでに存在していました。ファイルストレージドメインであるvaultのFileDownloadItemコンポーネントは、ファイル名と容量を表示し、ダウンロードボタンを押すとファイルをダウンロードした後、ユーザーのStashフォルダーに自動登録し、すでに受け取ったファイルであればアイコンを変えて表示するところまで行っていました。ソースは150行ほどの小さなコンポーネントです。チャットで同じものを作り直す理由はなさそうだったので、そのまま利用することにしました。 ところがimportを1行追加しただけでpnpm-lock.yamlに828行が追加され、ビルド成果物にはチャットで使っていないPDFビューアーのワーカーファイル（1MB）が入り込んでいま

1. Edge Computingとは？ Edge Computingは、データが生成される場所の近くでデータを処理する分散コンピューティングパラダイムです。中央のデータセンターにデータを送信してから処理する方式とは異なり、ネットワークのエッジ（Edge）にコンピューティングリソースを配置し、データの収集、処理、分析などの作業を行います。 データが生成される場所の近くで必要な処理を行うことで、データ転送量と処理遅延を削減できます。また、中央システムとのネットワーク接続が不安定な環境でも、一部の機能を独立して実行できます。 Edge Computingは中央システムを置き換えるための構成ではなく、互いに役割を分担する構成です。データの収集や即時処理が必要な作業はEdgeで行い、大規模なデータ保存や複数の現場のデータを統合して処理する作業は中央システムで行うことができます。 2. IoT環境でEdge Computingが必要な理由 IoT環境では、センサーや機器などさまざまなDeviceから継続的にデータが生成されます。これらのデータをすべて中央

はじめに ここ数か月、私が参加したプロジェクトにLLMエージェントを適用しました。ユーザーが自然言語で依頼すると、エージェントが必要な照会ツールを選択し、結果を確認したうえで回答を作成したり、追加の判断が必要な場合に再度質問したりする構成です。この記事では、その過程でモデルを包み込み、ツール呼び出しと会話の流れを制御するagent harnessを作り、複数のモデルを入れ替えて試した経験を整理します。 当初、私はharnessを「どのモデルを接続しても安定して動作する汎用制御層」だと考えていました。そのため、ローカルモデルがスキーマから逸脱したり、ツール呼び出しを誤ったりするたびに、パーサー、再試行、推論ルールを追加しました。当時は失敗を一つずつ防げていたため、合理的な対応に見えました。 しかし、同じharnessでモデルだけを変更して繰り返し実行すると、結果は異なりました。ローカルのオープンモデルでは、タスク全体を終える前に、形式エラー、誤った引数、空の応答、過度な遅延が繰り返し発生しました。一方、gpt-5.6は同じツールと同じ依頼に対して、最後まで最も安

はじめに 今回、echoサービスでSnap機能を担当して開発することになりました。Snapは、ユーザーがヘッダーのカメラアイコンを押すと、現在見ている画面をそのままキャプチャする機能です。文章だけで説明するのではなく、画面のスクリーンショットも一緒に送るため、キャプチャ結果は何が間違っているのかを示す説明であり、証拠でもあります。 そのため、この機能は速度と正確性を一定の基準以上に引き上げる必要がありました。まず速度については、目標を1秒前後としました。報告しようとしている流れをキャプチャが妨げてはいけないからです。もう一つは正確性で、報告者が見た画面とスクリーンショットが同じでなければなりません。異なっていれば、証拠としての意味がありません。 最初に改善作業を始めたときは、速度だけを改善すれば問題は解決すると思っていました。速度を改善しながらさまざまなスクリーンショットを撮る過程で、正確性にも問題があることを把握しました。この記事では、その二つの段階をそれぞれどのように解決したのか、そしてその結果、現在どのようなパイプラインが動いているのかをまとめます。結果

1. はじめに チーム単位のオフラインイベントで行われる対抗活動をデジタル化するため、参加チームが仮想通貨で資源を購入して成果物を作り、リアルタイムで変動する条件に対応しながら得点を競うWebベースのアプリケーションを、1人開発体制で企画・実装しました。従来は紙の台帳と手計算で進めていた活動だったため、進行役のミスがそのまま得点に反映されたり、参加者が自分の資源状況をリアルタイムで確認できなかったりするという課題が明確にありました。こうした非効率を実際に経験した立場から、「この規模のシステムなら、1人でもきちんと作れるのではないか」という考えがプロジェクトの出発点となりました。 同時に個人的には、AIを単なる補助ツールではなく、設計・実装・デバッグの全工程にわたる開発パートナーとして活用した場合、実際にどこまで生産性を高められるのかを検証してみたいという目標もありました。企画からデプロイまでの全工程を1人で担わなければならない制約はむしろ、Claudeとの協業方法をさまざまな角度から試し、その効果をありのままに確認できる良い機会となりました。管理者向けダッシュボー

1. プロンプト一つで終わるという幻想、そして直面した壁 最近では Claude Code、Antigravity、Cursor、Codex などの優れた AI コーディングツールが普及し、プロンプト一行で「機能を追加して」と依頼すれば、コードがあっという間に完成するという驚きの体験を、誰もが一度は味わったことでしょう。 トイプロジェクトや単純なスクリプト作成の段階では、AI エージェントを一つだけ起動し、対話形式でコーディングしても十分に優れた成果を得られます。しかし、複数の開発者が協業し、複雑なビジネスルール、厳格な DDD アーキテクチャ、トランザクション境界が絡み合う実際のエンタープライズバックエンド環境に入った瞬間、単一エージェント方式は急激に限界を露呈し、失敗し始めます。 チームプロジェクトで自分に割り当てられた複雑な機能チケットに対応する際、たった一つのエージェントセッションに、DB マイグレーション DDL から JPA リポジトリ、ドメインエンティティ、サービスロジック、REST API、テストコードまでの全工程を丸ごと任せると、ほどなくして

- ダウンロードおよび更新が可能なアプリケーションのDB Migration管理 - 1. はじめに アプリケーションを開発していると、機能の変更に伴ってデータベーススキーマも継続的に変更されます。新しいテーブルを追加したり、既存のカラムの型を変更したりすることもあれば、データ構造そのものを変更し、既存のデータを新しい構造へ移行しなければならない場合もあります。 一般的なWebサービスであれば、このようなデータベースの変更をデプロイパイプラインの一部として管理できます。開発チームがサーバーとデータベースの環境をすべて管理しているのであれば、アプリケーションのデプロイと同時に必要なSQLを実行する方法も利用できます。 しかし、私が携わっているVizend Platformには、少し異なる要件があります。 VizendのApplicationは、1つの中央サーバーだけで運用される形態ではなく、ユーザーが自分の環境にダウンロードしてインストールできます。インストール後は、新しいバージョンのApplicationを再度ダウンロードしたり、更新したりすることもで

- Windows React Native APK パス制限の解決方法 - 1. 概要 Windows で Expo CNG ベースの React Native アプリの Android APK ビルドが、次のように失敗することがあります。 ninja: error: Stat(...): Filename longer than 260 characters この問題はアプリコードの問題ではなく、Windows のパス長制限と CMake/Ninja のネイティブビルド成果物のパス構造によって発生します。 推奨される解決方法は次の 3 つです。 1. プロジェクトルートに Junctionを作成してビルドの実行パスを短くする。 2. CMake の buildStagingDirectoryを短い絶対パスに移動する。 3. 既存の .cxx キャッシュを削除してから、全体を再構成する。 Junction 생성

1. 作業の背景 今回の作業は、本人認証機能をゼロから設計した事例ではなく、既存の実装で発生したエラーを分析・修正した保守事例です。プロジェクトでは、React Nativeアプリの共通WebViewからVueで実装されたWeb画面を提供しており、その画面にはN*** CheckPlus本人認証がすでに連携されていました。 WebブラウザとiOSアプリでは正常に動作していましたが、React Native Android WebViewでのみ認証に失敗していました。担当範囲は既存の連携構造を全面的に変更することではなく、プラットフォームごとの差異を基準に原因を絞り込み、共通WebViewの他の機能への影響を最小限に抑えながら認証フローを正常化することでした。 2. エラーの発生と分析の手がかり 2.1 確認されたエラー AndroidアプリのWebViewでN***本人認証を進めると、認証が完了せず、失敗ページへ遷移しました。当時の記録には次のエラーが残っていました。 SecurityError: Failed to read a named

Androidエミュレーター環境からローカル開発サーバーに接続する際に遭遇するネットワーク問題の原因と解決方法についてまとめます。フロントエンド開発やモバイルアプリ開発を進めていると、ローカル環境でコードを修正し、その結果をすぐに確認する作業が欠かせません。このとき、ViteやWebpackなどのビルドツールを利用してローカルサーバーを起動すると、ターミナルウィンドウに開発サーバーのアドレスが表示され、そのアドレスをブラウザに入力して画面を確認します。 開発中の主な作業環境は一般的なPCブラウザであるため、アドレスバーに入力する値の意味やネットワークの流れを深く意識することはあまりありません。自分のPCで直接ターミナルを開いてサーバープロセスを起動し、同じPCにインストールされたブラウザから接続するため、リクエストを送信する主体とサーバーが存在する環境が一致しているからです。しかし、モバイル環境でのレスポンシブレイアウトを検証したり、WebViewの動作をテストしたりするためにAndroid Emulatorの標準AVD環境を起動すると、PCブラウザとは異なるネットワー

先の企画プロセスで要件とサービスポリシーを整理し、IAとメニュー構造、ユーザーフローまである程度整理した後は、これらの内容を実際の画面単位に落とし込む画面設計書の作成を進めました。 最初は、画面にどのような機能が必要なのか、どのようなデータを表示するのかだけを整理すれば、画面設計書として十分だと考えていました。しかし、実際のプロジェクトで複数の画面を作成する中で、画面設計書と併せて考慮すべき内容は、想像以上に多いことに気づきました。 その後、開発段階に入ってからは、作成した画面設計書を基準に、機能が実装されているかを自分でテストしました。この過程で、企画段階で見落としていた例外的な状況や、開発中に発生したエラーを確認できました。また、企画で画面を設計し、開発した後、実際のテストまで行って初めて、一つの機能が正しく完成するのだということを経験しました。テスト中に見つかったエラーを再度確認して修正しながら、サービスのエラー率を下げることにも意識を向けるようになりました。 このようなプロセスを経る中で、画面設計とQAそれぞれの段階において、私が重要だと考える基準が生ま

近年、Webアプリケーション内にExcel環境をそのまま実装するため、SpreadJSを導入するプロジェクトが増えています。私が担当するシステムでもSpreadJSを使用しています。SpreadJSを使用する中で発生した問題の一つが、「特定のファイルが画面上でまったく開けない問題」でした。 初期開発では旧バージョンを使用していましたが、新バージョンへのアップデート後、ユーザーがさまざまなファイルをアップロードするようになり、原因不明の解析エラーやランタイムエラーに直面することになりました。この原因は、旧バージョンではファイルを開く際に「open()」だけを使用していた一方、新バージョンで「import()」と「fromJSON()」が導入され、これらを混在させていたことにありました。 この経験を踏まえ、二度と同じミスを繰り返さないよう、3種類のフォーマット（.xlsx、.ssjson、.sjs）に応じた正確なAPIの対応関係と、正しいサンプルコードを整理しました。 エラーの原因：ファイルの特性とmethodの不一致 SpreadJSでファイルを開けない本質

1. 問題発生 運用中のKafkaメッセージが正常にConsumeされていないという問い合わせを受けました。 該当サーバーのログを確認した結果、Consumer GroupのRebalancingが約10分間隔で繰り返し発生していました。 Rebalancingが発生する原因を確認するため、Consumer設定と実際のメッセージ処理時間を併せて確認しました。 当時、max.poll.interval.msは10分に設定されており、1つのKafkaメッセージを処理するのに10分以上かかっていました。 max.poll.interval.msは、Consumerがpoll()を呼び出してから次のpoll()を呼び出すまでに許容される最大間隔です。そのため、メッセージ処理時間がこの設定値を超えたことで、Consumerが正常な処理間隔を維持できず、Rebalancingが発生したと判断しました。 問題を確認した当時の設定は以下のとおりでした。 max.poll.interval.ms=600000 ログと設定を併せて確認することで、今回の問題はK

見知らぬ人たちのための画面 現在取り組んでいる「班長ノート」は、特定の組織に所属する人だけが使うものではなく、半導体の建設現場で働く日雇い作業員の方々や班長の方々を対象としたアプリです。現場で人を募集したり、働きたいときに仕事を探したりする方々。私とはこれまでほとんど接点がなく、ややなじみの薄い領域にいる方々です。そのため、このアプリを作り始めた当初から、どこか途方に暮れるような感覚がありました。 専門家向けのソフトウェアを作るときは、ユーザーはすでに業務の文脈を理解しているという前提で画面を設計できます。しかし、班長ノートではその前提をそのまま当てはめるのは難しいです。ユーザー層の年齢やスマートフォンの利用スキルをあらかじめ決めつけるのではなく、初めて画面を見たときに、どのような点を不慣れに感じる可能性があるのかをより詳しく考える必要がある、ということです。ユーザーがすでに知っているという前提なしに画面を設計しなければならない。この違いは、思っていた以上に大きいものでした。画面を一つ作る際に考慮すべきことの種類そのものが変わるからです。 理解してもらえるだ

はじめに 入力項目が非常に多い多段階フォームは、それ自体が保守しにくいだけでなく、下書き保存や初期値の設定などの機能が組み合わさると、非常に速いスピードで複雑化します。そのため、formを扱うには効率的な「戦略」が必要です。本稿では、TypeScript、Reactの環境でreact-hook-form(RHF)、Zod、Jotaiを活用し、複雑なフォームを戦略的に管理する方法を整理します。 複雑なフォームはいつから壊れ始めるのか？ フォームが巨大になるほど、次のような問題が発生します。 1. コンポーネントが巨大になる。 - 入力フィールド、検証ロジック、条件付きレンダリング、エラー処理ロジックが増加し、そのフォームを管理するコンポーネントが幾何級数的に大きくなります。 2. 値の欠落、または不要なデータが発生する。 - 条件付きフィールドがある場合、現在の条件に合わないフィールドの値が失われたり、不要なまま保存されたりします。 3. タイミングが多様になるほど、構造が急激に複雑になる。 - 下書き保存機能がある場合や条件付きフィー

背景 新人開発者の頃、幸運にもコードレビューを受けられる環境で開発を始めました。最初は、レビューの基準が何なのかもよく分かっていませんでした。単に機能が正常に動作すれば開発は終わりだと思っており、レビューで指摘される内容も、最初は些細なことに感じていました。 importの順番や変数名のように、機能とは直接関係がないように見える部分についても、次のような質問を受けることがありました。 * 「この状態値は本当に必要ですか？」 * 「watchで処理していますが、イベントで処理するほうが適切ではありませんか？」 * 「このコンポーネントは責任を持ちすぎていませんか？」 * 「null、undefined、空の配列を適切に処理できていますか？」 最初は、一つひとつ修正するのが面倒に感じることもありました。しかし、チーム単位での開発や運用中のサービスを直接経験する中で、少しずつ考え方が変わっていきました。「今、機能が動作しているか？」で終わるのではなく、「

数週間かけて丹念に作り上げたSSE（Server-Sent Events）を取り除きました。最初にSSEを提案し、実装を始めたのは私でした。そして議論の末に取り除くことを最終的に決めたのも、ほかならぬ私自身でした。 SSEを導入してからpollingに切り替えるまでの技術的な判断については、一緒に作業したチームメンバーが前回の記事にまとめています。 この記事では、その判断に至るまでの過程をたどりながら、AIとともに素早く答えを完成させる間に、ループの外側で何がさらに必要だったのかを扱います。 AIは与えられた問題を素早く解決する QraはVizendでアプリケーションのデプロイを実行し、その状態を表示するサービスです。デプロイには数十秒、長い場合は数分かかります。当時私に与えられた課題は、ユーザーが段階ごとのデプロイの進行状況を確認できる機能を提供することでした。私は以前、別のプロジェクトで時間のかかる非同期処理の進行状況をSSEで可視化した経験を思い出し、今回も自然にSSEで問題を解決できるだろうと考え、その方向で進めました。 当時、私たちのチームは

1. はじめに プロジェクトを進めていると、要件に対応する中で別の問題を発見することがよくあります。今回は、マイページに部署ごとの役割情報を追加する顧客要件に対応する過程で発見した、部署名の多言語データの保存エラーと、その改善経験についてまとめます。 2. 問題を発見した背景 この問題は、マイページに部署ごとの役割情報を表示する機能を追加している途中で発見しました。顧客要件は、ユーザーが所属する部署と、その部署で持っている役割をマイページで確認できるようにすることでした。 フロントエンドでは、バックエンドから返される部署名と役割情報を画面に表示すればよい作業でした。しかし開発中、一部の部署名が空の値として渡される現象を確認しました。最初は、フロントエンドのマッピングの問題やレスポンスデータの処理に問題があるのではないかと疑いました。ところがAPIレスポンスを確認すると、フロントエンドで値が欠落したのではなく、バックエンドから返される部署名自体が空になっていました。 その後、バックエンドの参照ロジックを確認しました。参照ロジックは、現在の画面言語に合わ

フロントエンドエコシステムにおいて「React」というキーワードは、もはや選択肢ではなく必須に近い存在です。Web開発にとどまらず、モバイルアプリ開発にまでその領域が拡大する中、多くの開発者や企業が「Webで作ったサービスをモバイルアプリへどのように移行するか？」という課題を抱えています。 このとき最も多く議論される選択肢が、既存のWebを活用する方法（React）と、モバイルネイティブアプリを構築する方法（React Native）です。両技術は「React」という思想と構文を共有していますが、動作原理と適用すべきタイミングはまったく異なります。 この記事では、フロントエンドおよびUI/UXパブリッシングの観点からReactとReact Nativeの根本的な違いを確認し、プロジェクトの性質に応じて、いつどの技術を選択するのが正しいのか、その明確な基準を共有します。 1. ReactとReact Native：何が違うのか？ どちらの技術もFacebook(Meta)によって開発され、コンポーネントベースのアーキテクチャと、状態（State）およびプロパ

-imageId単独取得の問題発見からcineroomIdベースのアクセス制御とdevelop/stg検証まで- 1. 適用の背景 今回の作業は、proms-imageプロジェクトで画像リソースのアクセス権限を点検する過程で始まりました。最初は、特定の画面で画像が正常に表示されるか、アップロードと取得に問題がないかを確認する程度の作業だと考えていました。しかし実際に確認したところ、画像の所有病院情報とリクエスト元の病院情報が一致していなくても、画像を取得できる問題が再現しました。 proms-imageは、告知事項、病院登録画像、問診画像、AMISアンケート様式画像など、複数の機能で共通して使用される画像の保存および取得を担当しています。そのため、単にある画面で画像が正常に表示されるだけでは不十分でした。画像がどの病院またはどのcineroomに属するリソースなのかを確認し、リクエスト元がそのリソースを閲覧できるかどうかまで併せて検証する必要がありました。 本稿では、実際の業務で発見した画像所有権の検証漏れをどのように再現し、どのコードパスを修正し、dev

TPS超過によるサーバーダウン 船上で収集したデータを陸上のデータレイクへ再送するパイプラインを構築している途中で、限界テストを実施する必要が生じました。船上のPodが保持していたメッセージを陸上のデータレイクへ再送するには、EMQXとCCMDという2つの中継区間を必ず通過する必要がありました。これらの区間には、1秒あたりに処理できるメッセージ数、つまりTPSの制限が設定されていたためです。 複数の船上では通信環境が不安定で、データが届かないことが頻繁にあり、データレイク側ではバッチによって受信できなかったデータをまとめて再要求するように設計されていました。通常時のトラフィックだけを見ると制限TPSを大きく下回っていますが、バッチ処理が動く短い瞬間には、その数倍に達するメッセージが同時に押し寄せます。平均流入量を基準に設計されたパイプラインがこの瞬間に耐えられなければ、中継区間のサーバーはダウンし、メッセージはエラーひとつ表示されないまま静かに失われます。 結局、この状況で必要だったのは「このパイプラインは1秒あたり何件まで処理できるのか」ではなく、「瞬間的に

-SpreadJS Designerの活用方法とバグ解決記- はじめに プロジェクトに携わることになり、初めてSpreadJSライブラリに触れました。このライブラリは、画面上でexcelの参照や編集を可能にするために使用しました。本記事では、適用する過程で経験したことを整理します。具体的には、再読み込み・import時にサイドバーとバインディングパスが消えるバグと、顧客の要件により追加されたシート追加防止およびセル削除防止機能についてです。どちらの問題も、最終的にはSpreadJS Designerのコマンド体系を理解しなければ解決できないものでした。結果として、ドキュメントに記載されていない部分を自分で分析し、要件を実装する必要があった経験となりました。 再読み込み・再取得時にサイドバーとバインディングパスが消える現象 テンプレートを初めて取得したときは、Excel画面とともにサイドバーにもバインディングパスのツリーが正常に表示されます。しかし、再読み込みボタンを押したりファイルを再度開いたりすると、Excel画面にもバインディングパスが表示されず、

-定員超過問題を解決するための同時実行制御と適用プロセス- 1. 導入の背景：先着順の受講申請で発生した定員超過問題 オンライン講義や教育プラットフォームでは、特定の講座の定員を制限し、先着順で受講申請を受け付ける機能がよく使われます。例えば定員が100人の場合、100人目の申請者までは受け付け、それ以降のリクエストは受付終了として処理する必要があります。 一般的な状況では、現在の受講者数を取得し、定員未満であれば申請を保存する方式で実装できます。しかし、複数のユーザーがほぼ同時に申請すると問題が発生します。定員が100人で現在99人の時点に、2つのリクエストが同時に99人という値を読み取ると、どちらも申請に成功し、最終的な人数が101人になる可能性があります。 これは、複数のトランザクションが同じデータを同時に読み取り、変更することで発生する同時実行の問題です。そのため、単純なCRUDロジックだけでは、定員というビジネスルールを安定して保証することは困難です。 2. 単純な実装の限界 最も簡単に実装できる方法は、現在の人数を取得して定員を確認し

[Modern Backend] 講座 Part 1、第6回の2つ目の講義、「スコープ値（Scoped Values）（2）」です。 今回の講義では、Java 25の正式な仕様であるスコープ値（Scoped Value）の4つの基本設計原則から、実際のAPI使用パターン、専用キャッシュメカニズム、さらに実務で適用する際に必ず考慮すべき限界と判断基準まで、詳しく扱います。 📌 主な学習内容： * スコープ値の4つの設計原則（不変性 Immutable、動的スコープ Dynamic Scope、一方向伝達 One-way、構造的継承 Structured） * ThreadLocalとScopedValueの有効期間（Timeline）およびシャドーイング（Shadowing）の動作比較 * ScopedValueの宣言およびバインディングパターン（where、run、call、Carrierオブジェクトの理解） * 未バインド経路