この記事は カオナビ Advent Calendar 2025 (シリーズ1) 18日目です。
はじめに
QAエンジニアのfenecrg1218です。
昨年のアドカレで取り上げたPlaywrightでのテスト自動化は各チームで取り組み中です。併行して、GitHub CopilotまたはClaude Code、各種MCPサーバーと組み合わせてバイブコーディングを実践中です。
今年は、テスト環境の制約により実装確認が遅れそうな状況に対して、ローカル開発環境の構築で解決した事例を共有します。
忙しい人向けの要約
- QAエンジニアがローカル開発環境の構築を試みる
- 具体的な操作で躓いたらAIを活用
- プロダクト特有の問題はエンジニアにご教示いただく、エラー解説や操作詳細はAIがサポート
- 特殊な問題に遭遇した場合は社内の人たちに頼る
といった記事になります。
背景・課題
プロジェクトを進める中で、以下のような課題に直面しました。
- 各種事情により、案件リリース後まで 普段利用しているテスト環境が使えない
- 動作確認できる環境は1つだけあるが、数ヶ月先まで別途利用中
- つまり、QAエンジニアが早期に実装確認・仕様確認をする環境が存在しない
このままだと、開発は進むが実装確認はできない。数ヶ月後のテスト期間になってようやく問題が発覚するリスクを抱えていました。
解決のアイデア
ローカル開発環境をQAエンジニア側でも構築、使いこなせば問題解決できるのでは？ と考えました。
実践:ローカル開発環境の構築
環境
- Windows
- WSL2 + Ubuntu
- GitLab
- Docker CLI
- Laravel
- Node.js
- その他プロダクトで使われている技術スタック
【補足】エンジニア向け社内手順書は基本的にMac向けの内容です。QAエンジニアの一部は顧客環境を再現して検証をするため、Windowsを利用しています。Mac向けの手順をそのままWindows環境で実施できないケースが多く、OSのギャップを埋めることに苦労したため、Windows向けかつ非エンジニア向け手順書の整備を別途進めていきました。
構築プロセスと直面した課題
1. 基本的なセットアップでの躓き
使い慣れていない基本的なコマンドや設定で躓くことが多々ありましたが、AIに「このコマンドの意味と使い方を教えて」、「このエラーの意味と解決方法を教えて」と聞くことで各種問題を解決していきました。
- （大前提として、各種参考書や技術系サイトを参考しつつ）
- ナービィ（Slackの社内用AIチャットボット）、Gemini、GitHub Copilotなどを駆使して、Linux、Docker、Nodeなどの各種コマンドの使い方を質問
- エラーログを渡して、エラー内容の解説と解決策を提示してもらう
# 具体例その1:
# （コンテナ名は「mysql」だと仮定）
# 「docker compose up -d --build」を実行で「mysql」コンテナが「Started」と表示されるが、
# その後に「docker compose ps」を実行すると「mysql」コンテナが表示されない
pc:~/***/***$ docker compose up -d --build
[+] Running xxx/xxx
✔ Container ***-1 Started 0.8s
✔ Container ***-2 Started 0.8s
✔ Container mysql Started 0.7s
（以降、コンテナ毎に同様の表示）
pc:~/***/***$ docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
（「mysql」コンテナだけここに表示されない）
# 具体例その2:
# ローカル開発環境の構築手順「yarn run dev」を実行で「FATAL ERROR」が発生
（上部のログ）
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
----- Native stack trace -----
（下部のログ、エラー詳細）
2. プロダクト固有の問題
AIだけでは具体的な解決方法が分からないプロダクト固有の問題は、エンジニアの皆様にもご教示いただきました。
- ローカル開発環境のカオナビにログインして、メンバー新規作成を実行でエラーが発生
- Laravelアプリケーションのログ をAIに渡して、エラー内容の解説と解決策を提示してもらう
- まだ解決しないため、エンジニアの皆様にご教示いただく
- 先ほどのエラーは解消したが、新たなエラーが発生
上記を繰り返していきました。
ポイント:
お聞きする際、事前にAIで調べて「エラー内容は○○とのことで、AIから提示された△△を試したがまだ解決しません。」 と具体的に質問/相談することでスムーズにサポートいただけました。
3. AWSアクセスキーが古い問題
原因: AWSのcredentialが古いままで更新できていなかった。
解決プロセス:
- 社内ナレッジやAIを駆使して思いつく限りの解決策を試す
- slackの分報にて「こういう状況で困っています」とつぶやく
- 他チームのエンジニアさんたちから複数の解決策をご教示いただく
- 無事解決！
# 具体例その3:
pc:~/***/***$ docker ps -a --filter volume=（該当ボリューム名）
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
（該当ID） ***:latest "/***..." （更新ステータス内容） ***/*** ***
pc:~/***/***$ docker stop （該当ID）
pc:~/***/***$ docker rm （該当ID）
pc:~/***/***$ docker volume rm （該当ボリューム名）
pc:~/***/***$ docker compose pull （該当コンテナ名）
[+] Pulling xxx/xxx
pc:~/***/***$ docker compose down
[+] Running xxx/xxx
pc:~/***/***$ docker compose up -d
[+] Running xxx/xxx
pc:~/***/***$ docker exec $(docker compose ps -q （該当コンテナ名） 2>/dev/null || docker ps --filter "name=（該当コンテナ名）" -q | head -1) ls -l /root/.aws/
total 8
（更新日時） credentials
学び:
困った時は一人で抱え込まず、適切なタイミングで助けを求めること の大切さを実感しました。（普段の勤務態度、信頼の積み重ね、人脈なども重要です。）
4. 弊社特有の環境、WSL2 + VPN特有の問題
とあるタイミングにて、WSL2とVPNの組み合わせで外部へ接続できない問題が再発しました。
解決策と学び:
- Windowsを利用中のインフラエンジニアさんが既に対策を調査済み、顔見知りでしたので、爆速で解決策をご教示いただき無事に解決しました。（普段の勤務態度、信頼の積み重ね、人脈などの重要性その2。）
やってみた結果
定量的な成果
- 当初の予定よりも2ヶ月以上早く検証を開始できました！
- 環境待ちによるボトルネックを解消
定性的な成果
-
早期に仕様と実装の乖離を発見
- 仕様書と実際の挙動を比較し、気になる挙動を発見
- 現在、開発チームに仕様質問中
- リリース後の手戻りを未然に防げる可能性が高まった
-
技術的な成長
- Linux、Dockerなど開発環境全般の知識が向上
- 開発チームとのコミュニケーションがよりスムーズに
- 問題解決能力の向上
学んだこと
1. AIツールの効果的な活用
- 基本的なコマンドやエラーの調査にAIは非常に有効
- ただし、プロダクト固有の問題は人に聞く方が早い
- AIと人、それぞれの強みを理解して使い分けることが重要
2. 全体で助け合う文化
- 分報での気軽な情報共有が問題解決につながった
- 異なるチーム・職種のメンバーからも助けをいただけた
- 「困っています」と発信することの重要性
3. QAエンジニアの技術力向上の価値
- 開発環境を理解することで、より深い検証が可能に
- 開発チームとの会話の解像度が上がった
- 問題の切り分けや報告の質が向上
おわりに
最初は「非エンジニアがローカル開発環境を構築するなんて…」と不安もありましたが、AIツールの活用と周囲のサポートのおかげで、想定以上の成果を得ることができました。
テスト環境が無くて困っている誰かの参考になれば幸いです！
謝辞
環境構築をサポートしてくださったエンジニアの皆様、インフラエンジニアの皆様、そして分報で助言をくださった皆様、本当に有難うございました！！！！！
お読みいただきありがとうございました！
明日のカオナビ Advent Calendarもお楽しみにです！！