Claude Codeでアプリを作ったが、本番投入の方法が分からない

はじめに：「動いた！でも本番投入が怖い」——あなただけじゃない

Claude Codeを使って、業務の課題を解決するツールを作ってみた。思ったより簡単にできた。デモも問題なく動いた。でも、いざ「これをチームや会社全体で使おう」と考えたとき、急に不安になってくる——そういう経験をしている方は多いはずです。

「APIキーをコードに直書きしてしまっているが、大丈夫だろうか」
「エラーが起きたとき、誰が対応するのか」
「自分が担当から外れたら、誰もメンテできないのでは」
「セキュリティの問題が起きたら、自分の責任になるのか」

これらはすべて、正当な懸念です。そしてこの不安を感じている時点で、あなたはすでに正しい方向を向いています。問題を認識せずに本番投入してしまう方が、はるかにリスクが高いからです。

この記事では、「Claude Codeで作ったアプリをそのまま放置するのも嫌、でも何から手をつければいいか分からない」という状況に向けて、本番運用までに必要なステップを順番に解説します。自分でできる範囲と、専門家の支援が必要な範囲も整理しながら説明しますので、自社の状況に合わせて参考にしてください。

なお、本記事は「既にClaude Codeで何かを作った方」を対象としています。生成AIアプリを本番化する上での包括的なリスク解説は別記事「AI試作品を業務システムへ。中小企業・DX担当者が知るべきAIコード本番化の全工程」でも取り上げていますので、あわせてご参照ください。

お問い合わせはこちら

第1章：本番化の前に——今のアプリの状態を自己診断する

いきなりすべてを対応しようとすると、どこから手をつければいいか分からなくなります。まずは今の状態を客観的に把握することが、効率的な本番化の第一歩です。

リスクレベルの3段階

以下の診断項目をもとに、現在のアプリのリスクレベルを確認してください。

レベルA（緊急対応が必要）

• APIキー・パスワード・トークンをソースコード内に直書きしている

• ログイン機能・認証が一切ない（URLを知れば誰でもアクセス可能）

• インターネットから直接アクセスできる状態で稼働している

レベルB（本番化前に対応が必要）

• Gitでバージョン管理されていない

• エラーが起きても誰にも通知されない

• 担当者以外がコードの内容を理解できない

• 本番・開発・テスト環境が分離されていない

レベルC（運用しながら改善できる）

• テストコードがない

• ドキュメント・READMEが不足している

• CI/CDが整備されていない

• ライブラリの更新管理ができていない

診断結果の読み方

レベルAの項目が1つでも当てはまる場合、現在の状態での本番投入は推奨できません。まずこのステップの対応から始めてください。

第2章：ステップ1——Secrets・認証の対応（最優先）

本番化に向けた作業の中で、最初に取り組むべきなのがSecretsの管理と認証の実装です。この2つはセキュリティインシデントに直結する項目であり、他のすべての対応より優先されます。

Secrets管理：APIキーをコードから分離する

Claude Codeが生成するコードには、動作確認を優先したサンプル実装として、APIキーや接続文字列がコード内にそのまま書かれていることがあります。このままGitにコミットしたり、コードを共有したりすると、機密情報が外部に流出します。

まず、コード内のすべての機密情報を洗い出します。grep -r "sk-" . や grep -r "password" . などで検索すると見つかりやすいです。次に、それらを環境変数に置き換えます。Pythonであればos.environ.get("API_KEY")、Node.jsであればprocess.env.API_KEYで参照するよう変更します。

環境変数の値は.envファイルに記載し、.gitignoreに.envを追加してGitの追跡対象から除外します。本番環境では.envファイルをサーバー上で直接管理するか、クラウドサービスのシークレット管理機能（AWS Secrets Manager、Azure Key Vault、GCP Secret Managerなど）を利用します。

すでにAPIキーをGitにコミットしてしまった場合、履歴からも削除が必要です。また、漏洩した可能性がある場合はAPIキーを即座に再発行してください。

認証の実装：「誰でもアクセスできる」状態を解消する

社内ツールだからといって認証なしで運用するのは、予期しないアクセスや情報漏洩のリスクを生みます。「社内ネットワーク内だから大丈夫」という考え方も、テレワーク環境やVPN経由のアクセスが一般化した現代では通用しにくくなっています。最低限の認証として、以下のいずれかを実装することを推奨します。

選択肢1：Basic認証（最も手軽）
nginxやApacheのリバースプロキシ設定で追加できます。完全ではありませんが、社内限定の簡易ツールには有効です。

選択肢2：シンプルなID/パスワード認証
Pythonのauthlib、Node.jsのpassportなど、既存ライブラリを活用して実装します。

選択肢3：Googleアカウント等のOAuth連携
社内のGoogleアカウントやMicrosoftアカウントと連携すれば、パスワード管理の手間を省きながら本人確認ができます。

認証機能はセキュリティの根幹に関わるため、実装に不備があると「認証があるのに突破できる」という最悪の状態になりかねません。Claude Codeで認証コードを生成した場合でも、必ずセキュリティの観点でレビューすることを推奨します。特に、セッション管理・トークンの有効期限・パスワードのハッシュ化（平文保存は厳禁）の3点は重点的に確認してください。

第3章：ステップ2——Git管理・Docker化（環境を「再現できる」状態へ）

Secretsと認証の対応が完了したら、次は開発基盤の整備です。Git管理とDocker化は、「自分のPCでは動く」状態から脱するための基盤となります。

Gitでバージョン管理を始める

バージョン管理されていないコードは、変更の追跡も以前の状態への復元もできません。「昨日まで動いていたのに今日は動かない」という事態に対処できなくなります。既存プロジェクトのGit初期設定はgit init → .gitignore設定 → git add → git commitの順で進めます。

GitHubやGitLabなどのリポジトリサービスを使えば、バックアップとチームへの共有も同時に実現できます。リポジトリは必ずプライベート設定にしましょう。誤ってパブリックにすると、Secretsがなくても業務ロジックや顧客データ構造が外部に公開されてしまいます。

ブランチは最低限main（本番）とdevelop（開発）の2つを分けることを推奨します。本番に直接コミットする運用は、誤ったコードが即座に影響を与えるリスクがあります。

Dockerで環境を統一する

「自分のPCでは動いたのに、別のPCやサーバーでは動かない」という問題は、環境の差異が原因です。Dockerを使うことで、実行環境ごとの差を吸収できます。

Dockerfileは依存パッケージのインストールとアプリの起動コマンドを定義したファイルです。複数のサービス（アプリ＋データベース等）がある場合はdocker-compose.ymlでまとめて管理し、env_fileで.envを参照する形にすれば、SecretsをDockerコンテナ内でも安全に扱えます。

第4章：ステップ3——ログ・監視・障害通知（「誰も気づかない障害」をなくす）

アプリが稼働し始めると、次の問題は「何か起きたときに分かるか」です。エラーが発生しても誰にも通知されない状態は、障害が長時間放置されることを意味します。

ログ設計：何が起きたか記録する

ログは障害調査・監査対応・セキュリティインシデント対応の基盤です。最低限、アプリケーションログ（エラー・警告・主要な操作の記録）とアクセスログ（誰がいつどのURLにアクセスしたか）の2種類を記録するようにします。Pythonであれば標準のloggingモジュール、Node.jsであればwinstonやpinoが使いやすいです。ログはファイルへの書き出しに加え、標準出力にも流すとDockerログとしても収集できます。

死活監視：サービスが止まったら知る

最も手軽な死活監視として、UptimeRobot（無料プランあり）などの外部監視サービスを活用できます。設定したURLに定期的にアクセスし、応答がなければメールやチャットで通知してくれます。アカウント登録・URL登録・通知先設定の3ステップで始められ、技術知識がなくても導入できます。

連携可能なビジネスチャットへのエラー通知：リアルタイムで異常を受け取る

Webhookを使えば、例外発生時にビジネスチャットのチャンネルへ自動通知を送ることができます。Webhook URLを環境変数に入れ、try-exceptのexceptブロックでHTTPリクエストを投げるだけで実装できます。このような通知の仕組みがあるかないかで、障害への対応速度は大きく変わります。

第5章：ステップ4——テスト・ドキュメント（「自分しか分からない」を脱する）

ここまでのステップで、セキュリティと可用性の最低ラインは確保できます。次は「担当者が変わっても維持できる」状態を作るためのテストとドキュメントの整備です。

最低限のテストを追加する

「テストを書く時間がない」という状況はよく分かります。ただし、テストがまったくない状態でAIに修正をかけると、別の機能が壊れていても気づかないまま本番に反映されるリスクがあります。まず優先するのは「最も壊れると困る処理」のテストです。ビジネス上のクリティカルなパス（計算ロジック・認証処理・外部API連携など）から1〜3件だけでも書いておくだけで、AI修正時の安全網になります。テストが1件でも存在すればpytestなどでCIに組み込むことができます。ゼロとイチの差は大きいです。

READMEで引き継ぎを可能にする

READMEがなければ、担当者が変わった瞬間にアプリの起動方法すら分からなくなります。以下の項目を最低限カバーしたREADMEを用意してください。

Claude Codeに「このコードのREADMEを書いて」と依頼すれば、ドラフトを生成してくれます。ただし生成された内容は必ず実際の動作と照合して修正してください。

第6章：どこまで自力でできる？限界のラインと判断基準

ここまでのステップを読んで、「全部は難しそう」と感じた方もいるかもしれません。自力で対応できる範囲と、専門家のサポートが必要になるラインを整理します。

自力で対応しやすい作業

専門知識が必要になるケース

• 認証の実装：設計が不適切だと認証をすり抜けられる脆弱性を生む場合がある

• 本番サーバーへのデプロイ設定：ファイアウォール・ネットワーク設定を誤ると意図しない公開状態になる可能性がある

• CI/CD構築：設定ミスにより誤ったコードが自動デプロイされるリスクがある

• セキュリティレビュー全般：自己チェックには限界がある

• 複数サービスが絡む複雑な構成：依存関係の管理が難しくなる

「どこまで自力でできるか」は技術力だけでなく、リスク許容度とリソースの問題でもあります。また、本番化の作業を途中まで自力で進めた後、設定の誤りや構成の不整合が重なって「元の状態より対応が難しくなった」というケースもあります。「ここから先は自分では判断できない」と感じた時点で早めに相談することが、結果的にコストと時間を節約することにつながります。

第7章：一人で進めるのが難しいと感じたら——国際ソフトウェアへご相談を

ここまでのステップを読んで、「全部対応するのは現実的に難しい」「途中まで進めたが、ログイン機能の実装あたりで止まっている」と感じている方もいるかもしれません。

国際ソフトウェアは、Claude CodeなどのAIで作られたアプリを、実運用レベルへ改善・整備する支援を行っています。本記事で解説したパスワード・合言葉の分離・ログイン機能の実装・環境の統一・記録（ログ）設計・監視の構築・テスト追加・引き継ぎ資料整備まで、一括してサポートします。

「今のアプリがどの程度リスクがあるか知りたい」という段階からでも相談できます。現状のヒアリングと簡易診断は無料で対応しています。すべてを一度に対応する必要はなく、リスクの優先度に応じた段階的なプランをご提案します。

本番化後も、システムの稼働確認・障害時の初期対応・外部AIサービスの仕様変更への追従・外部ソフトウェアの更新対応など、継続的な保守支援を提供しています。中小企業・情シス不在企業・DX担当者1人体制のスタートアップなど、社内に技術リソースが少ない組織を中心に支援しています。お気軽にお問い合わせください。

国際ソフトウェア株式会社へ相談する

まとめ：本番化ロードマップ——今日からできる第一歩

Claude Codeで作ったアプリを本番運用するために必要なステップを振り返ります。

「今日からできる第一歩」は、まず自己診断でレベルAの項目を洗い出すことです。APIキーの直書きがあればすぐに環境変数へ移行し、認証がなければ最低限のBasic認証から始めてください。

一度に完璧を目指す必要はありません。リスクの高い順に一つずつ対応していくことが、現実的な本番化への道です。途中で壁にぶつかったり、専門知識が必要な局面が来たりしたときは、専門チームへの相談を遠慮なく検討してください。

本番化は「一度やれば終わり」ではなく、ライブラリ更新・セキュリティパッチ・AI APIの変更追従など継続的なメンテナンスが必要です。「作って終わり」にならないための保守運用体制をセットで考えておくことが、長期的に安定したシステム運用につながります。

Claude Codeで作った「動くもの」を、「使い続けられるシステム」へ。その一歩を、今日から始めましょう。

本記事で紹介したコードサンプルは説明用の簡略例です。実際の実装にあたっては、利用環境・要件に合わせて適切に調整してください。本記事の情報は執筆時点のものです。