What it takes to bring an AI-generated application to production
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
Once working code exists, only the feature implementation is done. Before production launch, you still need environment separation, secrets externalization, authentication and authorization, input validation and rate limiting, log masking, monitoring hooks, migration and rollback procedures, backup and recovery testing, dependency vulnerability checks, CI test and build reproducibility, deploy and rollback procedures, domain and TLS, cost caps and alerts, and operational documentation. The items most often missed are secrets externalization and rollback procedures.
この文書の適用条件
| 対象製品 | AI-generated applications in general (language/framework agnostic) |
|---|---|
| 確認バージョン | Design-level explanation independent of product version (command examples assume npm 6+ / pip-audit 2.x) |
| 適用環境 | AWS, Azure, on-premise |
| 必要権限 | Read access to the repository. Checking deploy configuration requires read access to each platform |
| 実行影響 | Read-only (the commands in this article do not change code) |
| 再起動 | Not required |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- Your organization's application repository (any language)
- 権限
- Read access to the repository
- 変更作業
- None (search only)
- Production実行
- Not applicable (run locally or in CI)
# 対象: 自組織のアプリケーションリポジトリ（言語不問）
# 権限: リポジトリの読み取り権限
# 変更作業: なし（検索のみ）
# Production 実行: 該当なし（手元またはCIで実行）
# 1) 代表的なキー名に値が直接代入されていないかを探す
# 環境変数から読んでいる行は除外して、残ったものを目視で確認する
grep -rInE "(api[_-]?key|secret|password|passwd|token|access[_-]?key)[[:space:]]*[:=]" --exclude-dir=.git --exclude-dir=node_modules --exclude-dir=vendor . | grep -vF -e "process.env" -e "os.environ" -e "getenv" -e ".example" -e ".sample"
# 2) 秘密鍵そのものが混入していないか
grep -rIn -- "-----BEGIN" --exclude-dir=.git .
# 3) 接続文字列の形（ユーザー名とパスワードが埋め込まれたURL）を探す
grep -rInE "(postgres|mysql|mongodb|redis|amqp)://[^:@/]+:[^@/]+@" --exclude-dir=.git .
# 4) 現在のコードから消しても履歴には残る。過去のコミットも確認する
git log --oneline -S "BEGIN PRIVATE KEY" | head -n 20If even one match is found, deleting it from the code alone is not enough. Treat that key as already leaked and revoke and reissue it. Removing it from history rewrites the repository, so you need to notify collaborators beforehand.
- 対象
- Node.js / Python application repository
- 権限
- Read access to the repository and network access to the package registry
- 変更作業
- None (audit only; no remediation commands included)
- Production実行
- Not applicable (run in CI or a development environment)
# 対象: Node.js / Python のアプリケーションリポジトリ
# 権限: リポジトリの読み取り権限とパッケージレジストリへの通信
# 変更作業: なし（監査のみ）
# Production 実行: 該当なし（CIまたは開発環境で実行）
# Node.js: ロックファイルを基準に既知の脆弱性を照合する
npm audit --audit-level=high
# Python: requirements もしくはインストール済み環境を監査する
pip-audit -r requirements.txt
# コンテナで配布する場合は、ベースイメージ側のパッケージも別途監査対象になる
# （アプリの依存監査だけではOSパッケージの脆弱性は検出されない）Automatic fixes such as `npm audit fix` are not run here. A major version bump can change behavior, so apply fixes only after confirming CI tests still pass.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| Environment separation (Dev / Stg / Prod) | Staging and production do not share the same credentials or the same database | Development machines cannot connect directly to the production database |
| Secrets management | Keys live in environment variables or a secrets store, not in code | A repository search turns up zero keys, including in history |
| Authentication and authorization | Who can log in is separated from what they can do after logging in | A request specifying another user's ID is rejected (horizontal privilege check) |
| Input validation and rate limiting | The system does not break under unexpected input or excessive requests | Type, length, and range validation exist. Unauthenticated endpoints have a request cap |
| Logging and masking | Logs are detailed enough to investigate, without exposing personal data or keys | Requests can be traced by request ID. Passwords, tokens, and personal data are not logged |
| Error handling and monitoring hooks | Failures are not swallowed and can be observed externally | Uncaught exceptions reach a notification channel. The health endpoint reflects failures in dependencies |
| Migration and rollback | Schema-change apply and rollback procedures exist as a pair | Rollback has been run at least once in a test environment |
| Backup and recovery testing | Not just taking backups, but confirming restoration works | There is a record confirming the app can be restored from backup and started |
| Dependency vulnerabilities | Known vulnerabilities are identified and a response policy is decided | Audit command results are recorded, with reasons noted for anything left unaddressed |
| CI automated testing and build reproducibility | The same commit always produces the same artifact | Lockfiles are pinned, and tests and builds pass in CI |
| Deploy and rollback procedure | The procedure for reverting to the previous version is documented | There is a recorded measurement of rollback duration |
| Domain and TLS certificate | HTTPS works on the proper domain and renewal is automated | Certificate expiry and renewal success/failure are monitored |
| Cost cap and alerts | Unexpected charges can be noticed when they occur | Budget alerts are configured and the notification channel is active |
| Operational documentation | People other than the original author can start, stop, and investigate the system | Startup steps, shutdown steps, and common failure responses are documented |
こういう状況で使います
- It works locally, but once it is time to go to production you don't know where to start
- Production API keys are written directly into configuration files
- The development and production environments point at the same database
- Errors occur with no notification to anyone, and you only find out from user reports
- Deploys work, but there is no procedure for reverting to the previous version
- Unexpected cloud charges turn up at the end of the month
考えられる原因（可能性の高い順）
01
Generation is aimed only at "making it work"
The instructions given to AI are usually "implement this feature," which does not include environment separation or monitoring hooks. Anything not in the instructions is not in the output, so everything beyond the feature itself tends to be systematically missing.
02
Sample-code conventions are carried over unchanged
Learning-material samples hardcode keys for brevity, skip error handling, and assume a single environment. Generated output can inherit these same conventions.
03
Operational requirements were never written down
Without defined availability targets, recovery objectives, log retention periods, and cost caps, there is no way to implement them. Without requirements, you can't even detect what's missing.
04
There is no staging environment equivalent to production
Without a staging environment, or with one configured differently from production, you cannot rehearse migrations or rollbacks. A procedure you have never tried will fail for the first time in production.
確認手順
- 1
Search the repository for secrets
参照のみUse the grep commands above to find hardcoded keys. Treat any key you find as something to be revoked.
- 2
Cross-check connection targets across environments
参照のみLine up each environment's config files or environment variables and confirm that database, external API, and storage endpoints are separated per environment.
- 3
Audit dependency packages
参照のみRun `npm audit` or `pip-audit` and review the highest-severity findings first.
- 4
Enumerate and check endpoints that require authentication
低Call each endpoint without an auth token to check for anything unintentionally exposed. Do this in a test environment.
- 5
Run a migration rollback in a test environment
中Run apply and rollback once through to confirm no data loss occurs. Do not do this in production.
- 6
Restore from backup and start the app
中Restore an existing backup into a separate environment and confirm the app starts and key operations work.
対応方法
すぐに実施できる低リスクの対応
Move keys into environment variables or a secrets store
中Remove keys from code and read them from environment variables or a managed secrets store instead. Revoke and reissue the existing keys at the same time.
Separate credentials between production and staging
中Eliminate the practice of reusing the same key in both environments. Separation keeps incidents during testing from spilling over into production.
Configure a notification channel for uncaught exceptions
低Fix the situation where application exceptions go nowhere. First just confirm that notifications arrive at all.
Set a cloud budget alert
低Make sure a notification fires when spending exceeds the expected amount. Tune the threshold over time as you operate.
事前検討が必要な変更
Separate environments into Dev / Stg / Prod
中Separate network, credentials, and data per environment. Making Stg match production's configuration gives migration and rollback testing real meaning.
Define and apply a log-masking policy
中Add shared logic that keeps passwords, tokens, and personal data out of logs. If existing logs already contain them, also decide a retention and deletion policy.
Pin automated tests and builds in CI
低Pin lockfiles so the same commit always produces the same artifact. If builds aren't reproducible, the artifact you'd roll back to isn't reproducible either.
Document the rollback procedure and measure it
中Write the steps for reverting to the previous version, then run them in a test environment and time them.
Automate and monitor TLS certificate renewal
低Set up automatic renewal, then add renewal success/failure and expiry date to what you monitor. An auto-renewal setting alone won't tell you when it fails.
再起動・サービス影響を伴う変更
Remove keys from repository history
高This rewrites history and breaks consistency with existing clones and forks. It requires collaborator agreement and dedicated time. Prioritize revoking the key and plan history removal as follow-up work.
Apply a schema change to the production database
高Table-definition changes are hard to undo and may involve locks while running. Prepare a pre-change snapshot and rollback procedure before proceeding.
!注意事項
- Even after deleting a key from code, treat that key as already leaked. It may remain in places the repository was shared, or in logs. Revocation and reissuance come first.
- Migrations against the production database are hard to undo. Do not run them until a pre-change snapshot and rollback procedure are both in place.
- Taking backups alone does not make them useful. Don't count a backup as a recovery mechanism unless you've confirmed you can restore and start from it.
- Automatic fixes like `npm audit fix --force` can bump major versions. Apply them only after confirming CI tests still pass.
- Meeting every item listed here does not mean failures will stop happening. The goal is not to eradicate failures, but to build a state where you notice them and can revert.
バージョン・環境による違い
これで解決しない場合に確認すること
Count the endpoints reachable before authentication
Confirm there are no unauthenticated endpoints besides the health check. If there are, prioritize rate limiting and input validation.
Sample logs to check for leaked personal data
Pull recent logs and confirm email addresses, phone numbers, and tokens are not being output.
Check the behavior when a dependent external API goes down
Confirm the whole app doesn't become unresponsive when an external API times out.
Confirm certificate expiry is included in monitoring
Having auto-renewal configured doesn't help if there's no way to notice when it fails.
Confirm someone other than the original operator can start and stop the system
Hand the runbook to a different person and have them execute it, to surface assumed knowledge that was never written down.
この文書の根拠と限界
一般的な技術説明
This article is a general pre-release checklist that does not depend on any specific product. The command examples are based on the published specifications of npm and pip-audit. Only the "GIIP's scope" paragraph describes GIIP's own operational procedures, and it is not a customer case study. Figures such as time spent, reduction rates, or failure rates are not included because they cannot be verified.
よくある質問
What should be done first?
Secrets externalization and environment separation. Until these two are done, later work can end up affecting production. Next comes the rollback procedure, which makes it easier to try further changes afterward.
Is it safe once I delete the key from the code?
No. It may remain in commit history, CI logs, or shared copies. Treat the key as already leaked, revoke and reissue it, then address the code and history.
Do even small apps need all three environments — Dev / Stg / Prod?
You need at least two: production and non-production. Without somewhere to rehearse migrations and rollbacks, procedural gaps only surface in production. If Stg can match production's configuration, three environments is preferable.
Can't I just have the AI write the operational code too?
It can generate things like logging and health endpoints. But decisions such as who's on call for notifications, who has approval authority, and whether a cost cap is reasonable sit outside the code. Separate what can be generated from what must be decided.
What if a large number of vulnerabilities are detected?
Address the ones that are both high-severity and reachable from outside first. You don't need to resolve everything at once, but record a reason and a re-check date for anything left unaddressed.
If I satisfy this checklist, will production be problem-free?
Not necessarily. The goal isn't to eradicate problems, but to be able to notice them and revert when they occur.
この文書がカバーする質問
- What is a productionization checklist for an AI application
- What is missing before publishing AI-generated code to production
- What should be checked first for AI-generated app security
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
Your organization can carry out all of the items above without outsourcing them. The judgment call is which items to satisfy before this release and which to defer. At GIIP, when bringing an AI-generated application to production, we satisfy environment separation, secrets externalization, and a measured rollback procedure, plus a monitoring integration, before publishing. If you lack the information to prioritize, we can also help by reviewing your current setup and identifying the gaps.
執筆・技術検証
GIIP プロダクション運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に約30年従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスを、AIエージェントと人間の専門家が継続的に監視・運用しています。
What is the difference between a coding agent and GIIP FDE Ops?
Coding agents and operations services differ in their "unit of work." We compare the boundary between the two across nine dimensions, with commands you can run to check your own organization.
ai-operationsWhy AI automated execution needs approval and rollback, and how to design for it
Design elements for automated execution — snapshots, approval gates, dry-run separation, allowlists, idempotency, audit logs, staged rollout, and a kill switch — are summarized, along with where to draw the line on what can run without approval.
monitoringWhat to Configure When Monitoring Servers and Databases 24/7
A checklist, organized by layer, of what to monitor, how to think about thresholds, the escalation structure, and why synthetic monitoring is necessary when designing 24/7 monitoring.
awsWhat to Check When Reviewing AWS Database Costs
A checklist for reviewing AWS database spend in order of increasing impact: stop what is unused → right-size → storage → backups → non-production → commitments.
関連サービス
Get a gap review before your production launch
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
Get a gap review before your production launch