Jotai への移行途中で見えた構造的課題

こんにちは、ENECHANGE でエンジニアをしている清水です。

今年の7月に電力料金シミュレーション領域のチームへジョインしました。

当時、チームではフロントエンドの状態管理の複雑さを解消するため、 Jotai への移行が進められていました。

しかし、実際にコードを追うにつれ、根本的なつらさの原因は状態管理の手段ではなく「判定の所在」という構造そのものにあることに気づきました。

本記事では、5回の「なぜ」で真因に辿り着き、仕組みを足さずに判定の所在を変えるだけで解決した過程をご紹介します。

Claude Code Desktop × Playwright MCPでシナリオテストはもっとシンプルになるのか？（実験編）

こんにちは、エンジニアの川野邉です。

前回の準備編では、社内で運用しているシナリオテスト自動化ツールの課題を振り返りながら、Claude DesktopとPlaywright MCPを使ったプロトタイプを用意しました。

tech.enechange.co.jp

今回検証するポイントは、「HTMLのセレクタ情報を一切持たないテストシナリオだけで、Claude Desktop上でシナリオテストを実行し、結果をレポートできるのか。」です。

結論として、HTMLセレクタを持たないテストシナリオでも、Claude Desktop＋Playwright MCPでテスト実行と結果レポートは可能でした。一方で、ツール利用上限やテストデータの自動補正など、運用上の課題も見えました。

Claude Code Desktop × Playwright MCPでシナリオテストはもっとシンプルになるのか？（準備編）

こんにちは、エンジニアの川野邉です。

最近、Claude CodeとPlaywright MCPを使って、シナリオテストの自動化について検証してみました。

この記事は「Playwright MCPを使ってみた」という紹介ではありません。

社内で長年運用してきたシナリオテストの仕組みを振り返りながら、「AIを使えばもっとシンプルに運用できるのでは？」と思い立ち、検証・実験をしてみた話です。

今回はその前編として、検証に至った背景や環境構築、テストシナリオの準備までを紹介します。

記事は以下の2本構成を予定しています。

• 準備編：背景・環境構築・シナリオ作成
• 実験編：実行結果・評価・業務利用できるかの考察

世間は夏休みということもあり、本記事は私の夏休みの自由研究という位置付けでお届けします。☀️🏝️

Step Functions のテストを「配線」と「中身」に分けて考える

はじめに

こんにちは。システム開発部 石橋です。

複数の Lambda・ECS・Batch を組み合わせたワークフローを Step Functions で構築した。いざテストしようとすると、「ステートマシン全体を通しで動かすしかないのか？」という壁にぶつかる。

この記事では、ステートマシンのテスト対象を 「配線」と「中身」に分離する 考え方と、それに基づくテスト戦略を紹介する。

人間によるレビュー指摘を蓄積してAIコードレビューの精度を高める

はじめに

弊社の開発では ClaudeCode をはじめとした AI エージェントによるPRコードレビューを利用するのが日常になっていますが、商用製品としてのクオリティを担保するためにも必ずマージ前に人間によるレビューも行っています。

しばらくこの運用を続けていると 複数PRに渡り人間が何度も同じ種類の指摘をしている という問題が顕在化してきました。

例えば以下のような指摘が頻繁にあがっています。

• 責務の分離・配置：「この処理は呼び出し元ではなく処理側で自己完結させるべき」「定型コンテンツは別ファイルに切り出すべき」といった、コンポーネント間の役割の境界に関する指摘
• 実装品質：「同一リソースへの重複アクセスを避ける」「同一リソースへの操作を冪等に設計する」「使用したリソースは必ずクリーンアップする」といった実装の堅牢性に関する指摘
• ドキュメントの明確さ：「前提条件や操作対象を明示してほしい」「具体的なコード例をドキュメントに含めてほしい」「新機能を追加したら利用方法も記載してほしい」といった記述スタイルに関する指摘

中には CLAUDE.md に記載のポイントも含まれておりエージェントによるレビュー時も考慮されているはずですが、同じ指摘が繰り返される状況が続いていました。

そこで、過去の人間レビューコメントからレビュー観点を抽出し、蓄積して AI レビューで活用する仕組みを作りました。

この記事では、その仕組みの設計と実装について紹介します。