はじめに - 元経営者の開発挑戦記録
こんにちは！元経営者で現在会社員をしている、あばんです。
実は私、典型的な文系出身の非エンジニアでした。しかし、7ヶ月前からAIを活用した開発に挑戦し、これまでにAWS Lambda + Bedrock + Supabase + React + LINE連携というシステムを何とか構築してきました。
今回はその続編として、SuperClaudeを使って開発環境を整備し、特に既存のプロジェクトにエラー通知システムを追加した体験談をお書きします。同じように非エンジニアから開発を始めた方の参考になれば嬉しいです。
これは私の2度目のQiita記事です。前回の経験を踏まえ、今回は既存プロジェクトの運用を安心して行えるような環境作りに挑戦しました。
なぜ開発環境の整備に取り組んだのか？
既存プロジェクトの運用で感じていた不安
- エラーへの対処 - 業務で使っているツールでエラーが起きても気づかない
- 作業効率の限界 - 手作業での確認・修正が多くて時間がかかる
- 品質への心配 - 本番で動いているシステムに問題がないか不安
特に、業務改善ツールとして使っているSAPプロジェクトで、深夜にエラーが発生して翌朝気づくということが何度かあり、「何とか自動で教えてくれる仕組みが欲しい」と思ったのがきっかけでした。
今回取り組んだ内容
🔧 既存プロジェクトに追加した仕組み
AIの力を借りながら、既存のフロントエンドプロジェクトに以下のような監視・自動化システムを追加しました：
導入した主な技術：
- SuperClaude Framework - Claude Codeの機能拡張
- Sentry + LINE通知 - エラーの自動検知・通知
- AWS CDK - インフラ管理のコード化
- GitHub Actions - 自動テスト・デプロイの改善
- MCP統合 - 各種ツールの連携
実感できた改善効果
📊 監視体制：手動確認 → 自動エラー検知
🛡️ エラー対応：翌朝気づく → すぐにLINEで通知
⚡ デプロイ：手作業 → 自動化でミス減少
🔧 メンテナンス：個別対応 → 統一された手順
SuperClaude Frameworkを使ってみた感想
SuperClaudeとは？
SuperClaudeは、Claude Codeをより使いやすくしてくれる無料のツールです。特に、既存プロジェクトの分析や改善提案を自然な言葉で指示できるのが便利でした。
実際の導入手順
1. 環境の準備
# Python環境の確認
python --version
2. SuperClaudeのインストール
# インストール（思ったより簡単でした）
pip install SuperClaude
3. 既存プロジェクトでの活用
# プロジェクト分析（これが本当に便利でした）
echo "このプロジェクトを分析して"
使ってみて良かった点
- 既存コードの分析が早い - 「このプロジェクトを調べて」と言うだけで課題を見つけてくれる
- 改善提案をくれる - セキュリティやパフォーマンスの問題点を指摘
- 安全に作業できる - 実装中のプロジェクトを壊さないよう注意深く動作
参考にした記事
SuperClaudeについては、以下の記事がとても参考になりました：
既存プロジェクトへのエラー通知システム追加
Sentry + LINE通知の追加
既存のプロジェクトにSentryを組み込み、LINEに通知が来るようにしました。
実装したもの
1. 既存プロジェクトへのSentry統合
- 環境変数ファイル（.env.local、.env.production）にSentry設定を追加
- 既存のReactアプリケーションにエラー監視機能を統合
- 開発環境と本番環境での設定分離
2. LINEへの即座通知
- 重要なエラーはすぐにLINE通知
- 軽いエラーは自動で再試行を設定
- 毎日の状況レポートも受信
実際の効果
以前は朝起きてから業務ツールのエラーに気づくことがありましたが、今はエラーが起きると即座にLINEで教えてくれるので、とても安心です。特に業務で使っているツールなので、早期発見できるのは本当に助かっています。
注意したポイント
実装中のプロジェクトに影響を与えないよう、以下の点に注意しました：
- 複数のClaudecodeセッションでの同時編集を避ける
- テスト環境での十分な動作確認
- 本番環境への段階的な適用
Sentryの学習に使った記事
AWS CDKでの既存インフラ管理改善
なぜCDKを導入したか
既存プロジェクトのAWS設定を手作業で管理していましたが、設定の記録や再現が困難でした。CDKを使うことで、インフラ設定をコードで管理し、同じ設定を確実に再現できるようにしました。
既存環境に追加した内容
1. 現在の設定のコード化
- 既存の一部設定をCDKコードで再現
- Lambda関数とAPI Gatewayの設定管理
2. 監視機能の追加
- CloudWatchでの詳細監視
- エラー発生時の自動通知設定
3. デプロイメントの自動化
- 手作業だった更新作業の自動化
- 環境別設定の管理
実感している改善
手作業で30分程度かかっていたデプロイ作業が、コマンド一つで完了するようになりました。また、設定忘れや手順ミスがなくなったのも大きな改善点です。
CDK学習で参考にした記事
GitHub Actionsでの継続的改善
既存プロジェクトのCI/CD改善
既存のGitワークフローに、自動テストとデプロイメントの仕組みを追加しました。
追加した機能
1. 品質チェックの自動化
- コードプッシュ時の自動テスト実行
- セキュリティチェック
- コード品質の確認
2. 段階的デプロイメント
- 開発環境での自動テスト
- 問題がない場合の本番環境反映
GitHub Actions参考記事
実際の作業時間と効果
構築にかけた時間
- 計画・調査：2時間
- SuperClaude導入・既存プロジェクト分析：1時間
- Sentry統合・LINE通知設定：1時間
- CDK・GitHub Actions設定：2時間
- 合計：約6時間
途中、実装中のプロジェクトで競合が発生してGitで戻すトラブルもありましたが、全体としては予定通り完了できました。
実感している効果
運用面での改善
- エラー検知：翌朝気づく → 即座にLINE通知
- デプロイ作業：手作業30分 → 自動化で5分
- 設定管理：メモとスクリーンショット → コードで管理
安心感の向上
- 業務ツールのエラーを見逃す心配がなくなった
- インフラ設定の記録が残るようになった
- 全体的に既存プロジェクトの保守に集中できるようになった
構築時に困ったことと解決方法
実際に発生したトラブル
1. 実装中プロジェクトでの競合
- 複数のClaudecodeセッションで同時に開発作業をしてしまい、コードが競合
- 解決方法：Gitで元に戻し、作業中プロジェクトには触らないルールを設定
2. GitHub認証がうまくいかない
- 環境変数での設定が反映されない問題
- 解決方法：MCPサーバーに直接トークンを設定する方法で解決
3. Windows環境での各種設定
- GitBashでの環境変数読み込み問題
- 解決方法：PowerShellでの実行に切り替え
この環境整備で変わったこと
既存プロジェクトの運用が安心に
以前
- エラーが起きても気づかない不安
- 手作業での確認・更新が負担
- 設定を忘れて同じ作業を繰り返す
現在
- エラーが起きてもすぐ分かるから安心
- 自動化で手作業の負担が軽減
- コード化されているので設定を再現しやすい
特に価値を感じている点
「業務ツールを安心して使える環境」
既存の業務改善ツールにエラー監視システムを追加したことで、「問題が起きても早期に気づける」という安心感が生まれました。これにより、ツールを積極的に活用できるようになりました。
まとめ - 既存プロジェクトの改善でも大きな価値
今回の取り組みを振り返って
6時間をかけて、既存のプロジェクトにSuperClaudeを活用した監視・自動化システムを追加できました。ゼロから作るわけではありませんでしたが、既存システムの運用不安を大きく軽減できる仕組みができたと思います。
最も価値があった部分
- 既存プロジェクトへのエラー通知追加 - 業務ツールの安心感が向上
- インフラ設定のコード化 - 手作業ミスと設定忘れの削減
- SuperClaudeでの既存コード分析 - 改善点の早期発見
これから同様の改善を考える方へ
新しくシステムを作らなくても、既存プロジェクトの改善でも大きな価値が得られます。重要なのは：
- 小さく始める - まずは監視システムの追加から
- 実装中は触らない - 動いているプロジェクトの安全を最優先
- 段階的に改善 - 一度に全部やろうとせず、少しずつ
この記事が、同じように既存プロジェクトの運用改善を考えている方の参考になれば嬉しいです。質問や感想があれば、コメントでお気軽にどうぞ！
参考リンク
- SuperClaude GitHub Repository
- AWS CDK Developer Guide
- GitHub Actions Documentation
- Sentry Documentation
この記事は、実際の体験に基づいて書いています。環境や状況により結果は異なる場合があります。