What is the difference between a coding agent and GIIP FDE Ops?
公開日 2026-08-13 · 更新日 2026-08-13 · 最終検証日 2026-08-13
結論
The difference isn't how many features each has — it's the unit of work. A coding agent's unit of work is a code change in a repository, and the job is done once the change is merged. An operations service's unit of work is the state of a live production system, and the job is done only as long as that state keeps matching what's expected. That leaves approval of production changes, management of permissions and secrets, the monitoring intake, first response to incidents, rollback mechanisms, audit logs, on-call, and SLAs outside the former's scope.
この文書の適用条件
| 対象製品 | GIIP FDE Ops (compared against a general-purpose coding agent) |
|---|---|
| 確認バージョン | A design-level explanation independent of product version |
| 適用環境 | AWS, Azure, on-premise |
| 必要権限 | Repository read access for the checks below, plus read access to your monitoring and access-management systems |
| 実行影響 | Read-only (the commands in this article do not change state) |
| 再起動 | Not required |
| 最終検証日 | 2026-08-13 |
そのまま実行できるコマンド
- 対象
- Your application repository and production deployment
- 権限
- Repository read access
- 変更作業
- None (read-only)
- Production実行
- N/A (run locally or in CI)
# 対象: 自組織のアプリケーションリポジトリと本番デプロイ
# 権限: リポジトリの読み取り権限
# 変更作業: なし（参照のみ）
# Production 実行: 該当なし（手元またはCIで実行）
# 1) 本番ブランチに入った変更が、レビュー（マージ）を経ているか
git log --first-parent --since="90 days ago" --date=short --pretty=format:"%h %ad %an %s" origin/main | head -n 50
# 2) レビューを経ずに直接積まれたコミットが残っていないか
git log --no-merges --since="90 days ago" --pretty=format:"%h %an %s" origin/main | head -n 50
# 3) いま本番で動いているリビジョンを即答できるか
# デプロイ時にコミットハッシュを埋め込んでいなければ、この問いには答えられない
curl -s https://example.com/healthz | head -n 5If you can't answer item 3 — "what revision is actually running in production" — then even if code changes are tracked, the state of production is not. This is the classic point where a coding agent's definition of "done" diverges from operations' definition of "done."
- 対象
- Your operational infrastructure (monitoring, permissions, on-call, audit)
- 権限
- Read access to each system
- 変更作業
- None (checking only)
- Production実行
- N/A (a review exercise)
# 対象: 自組織の運用基盤（監視・権限・オンコール・監査）
# 権限: 各基盤の参照権限
# 変更作業: なし（確認のみ）
# Production 実行: 該当なし（確認作業）
[1] 監視と通知の受け口
- 本番が停止したとき、最初に気づくのは人か仕組みか
- アラートは誰の端末に届き、誰も応答しない場合に次へ渡る仕組みがあるか
- 通知が届く先は個人のアカウントか、退職しても残る共有の受け口か
[2] 本番変更の承認
- 本番への変更に承認者がいるか。承認は記録に残るか
- 承認なしで本番に適用できる経路（手動デプロイ、直接SSH、DB直接接続）が残っていないか
[3] 権限とシークレット
- 本番の認証情報はどこに保管され、誰が参照でき、いつ更新されたか
- 退職・契約終了時に権限を剥奪する手順が文書化されているか
[4] 障害時の一次対応
- 深夜に落ちたとき、最初の30分で誰が何をするかが決まっているか
- 切り分けの手順（どのログを見るか、どのクエリを流すか）が書かれているか
[5] ロールバック
- 直前のバージョンに戻す手順が、実際に試された状態で存在するか
- データベースのマイグレーションを戻す手順があるか
[6] 監査ログ
- 誰が・いつ・何を・どの承認で本番に適用したかを後から再構成できるか
[7] オンコールとエスカレーション
- 一次対応者が判断できない場合の連絡先と判断権限者が決まっているか
- 対応時間の約束（SLA）があり、その根拠となる監視間隔が定義されているか
[8] 複数システムにまたがる影響判断
- あるサービスを停止したとき、連鎖して止まる下流を一覧できるかWhichever of the 8 items above has "no one assigned" is the area that stays blank even after you adopt a coding agent. The more blanks there are, the more code productivity improves without production stability changing at all.
結果の読み方
| 列 | 意味 | 確認するポイント |
|---|---|---|
| Unit of work | A code change in a repository (diff/PR/commit) | The state of a live production system (processes, data, configuration, dependencies) |
| Definition of done | The change is merged and tests pass | The state keeps matching what's expected — there is no single point of completion |
| Approval of production changes | Largely out of scope; depends on human reviewers and merge permissions | Design an approval gate: define and record who approves what, under what conditions |
| Permission and secret management | Out of scope; scanning the repo for leaked keys can be part of it | Operate storage, issuance, revocation, and auditing of production credentials as a standing procedure |
| Monitoring and alert intake | Out of scope; can write the monitoring config code | Operate the actual intake that receives alerts, responds, and escalates when no one responds |
| Incident first response and triage | Out of scope; can propose a hypothesis from pasted logs | Carry out detection through triage to confirming the scope of impact, under time pressure |
| Securing a rollback path | Can revert code; reverting data or schema is out of scope | Prepare a pre-change snapshot and rollback procedure before applying the change |
| Change history and audit logs | Commit history exists, but it is separate from a record of what was applied to production | Record who ran what, when, with what input/output, and under whose approval, at the unit of each production change |
| On-call | Out of scope; only engages once paged | Fill every time slot, including rotation, handover, and backup coverage |
| SLA and escalation | Out of scope | Define response/recovery commitments and the escalation path to a decision-maker |
| Judging impact across multiple systems | Only has visibility within the given repository | Estimate the cascading impact of stopping or changing something, based on configuration and dependency data |
こういう状況で使います
- After adopting a coding agent, development velocity went up, but the number of production incidents and the time to resolve them haven't changed.
- "The code is written" but the work to get it into production never seems to finish.
- No one can immediately answer which version is currently running in production.
- It's undefined who responds to a late-night alert.
- The record of what was applied to production only exists in someone's personal chat history.
考えられる原因（可能性の高い順）
01
Comparing things with different units of work as if they differ only in feature count
A coding agent is a tool that completes code changes; an operations service is a duty that keeps a state running. Adding the latter's features to the former doesn't fill in elements that belong to people and organizations, like on-call duty or approval authority.
02
No permission design exists for the production environment
Automating production changes first requires deciding what may be executed under whose approval. Without that design, the safe default is to push everything back to manual work.
03
The alert intake is tied to an individual
If alerts only reach one person's account, monitoring effectively stops whenever that person is unavailable. This is a problem with how the intake is designed, not whether a monitoring tool exists.
04
Rollback stops at "it should be reversible"
A rollback procedure that has never actually been tried only reveals its failures during an incident. Database schema changes and data deletions in particular cannot be undone by reverting code.
確認手順
- 1
Check the revision currently running in production
参照のみPull the commit hash running in production from deployment records or the app's health endpoint. If you can't, change tracking doesn't actually cover production.
- 2
Check for production changes that bypassed review
参照のみUse the git command above to surface commits that landed on the production branch without going through a merge.
- 3
Check whether an audit log exists
参照のみCheck whether who ran it, when, what it did, and who approved it can all be reconstructed after the fact for production changes. Missing even one of these makes it an insufficient audit log.
- 4
Check the on-call roster and alert routing
参照のみFor alerts from the last month, check who responded and when. An alert with no recorded response may mean no one noticed it.
- 5
Verify that a rollback can actually be performed
中In an environment equivalent to production, run through reverting to the previous version and rolling back a migration once.
対応方法
すぐに実施できる低リスクの対応
Make the production revision visible
低Embed the commit hash and build time in the app at deploy time and have the health endpoint return them. This secures a starting point for tracking.
Consolidate production change approvals into one place
低Replace chat- or verbally-given approvals with approvals recorded in a PR or a ticket. The goal is to close off any path that leaves no record.
Move alert destinations to a shared account
低Switch notifications away from personal accounts to a shared intake that can be rotated among on-call staff.
事前検討が必要な変更
Close off direct paths to production
中Consolidate manual deploys, direct SSH to production servers, and direct connections to the production database into paths that require approval and leave a record. Confirm that existing operational procedures won't break before closing them.
Run rollback procedures as drills
中Actually perform a rollback multiple times a year and record how long it takes and where it fails. An untested procedure isn't a procedure.
Maintain configuration data to judge blast radius
低Catalog dependencies between services and the databases/external APIs each service relies on. This removes the need to re-research this every time a shutdown decision comes up.
専門家のレビューが必要な作業
Audit and redesign permissions and secrets
高Review where production credentials are stored, who can read them, and how they're revoked. Existing integrations may stop working during this work, so investigate impact first.
Design the scope of automated execution with approval gates
専門家レビュー必須Define which operations may run automatically and where human approval becomes mandatory. Getting this boundary wrong lets irreversible operations run without approval, so this requires expert review.
!注意事項
- This comparison isn't a knock on coding agents' capabilities. They're an effective tool for the unit of work that is code change — think of this as a division of labor, not a replacement.
- Filling operational gaps involves changing production permissions. Permission changes can break existing integrations, so investigate impact and prepare a rollback procedure before making them.
- The premise that "automation means you don't need people" doesn't hold. Approval, escalation, and judging business impact are matters of accountability, not technical correctness.
- This article organizes design and division of labor — it does not mean adopting any particular product will eliminate incidents.
バージョン・環境による違い
これで解決しない場合に確認すること
Re-read the first-response record from a recent incident
Check how many minutes passed from detection to triage, and where it stalled. Wherever it stalled is the gap that needs filling.
Count every path into production
CI/CD, manual deploys, SSH, DB clients, cloud console, admin screens. Identify which of these paths leaves no record.
Check whether a backup is defined for when someone is unavailable
Verify the same procedure still runs when the primary owner is on vacation. If it doesn't, that's reliance on a specific person, not automation.
Check whether monitoring covers "what it takes for the service to actually work"
Verify monitoring looks beyond whether a process is alive, to whether the path users actually take still works.
この文書の根拠と限界
実運用で確認した内容
The comparison table and checklist are a general operational design, independent of any specific product. Only the "GIIP's scope" paragraph describes GIIP's own operating model — it is not a customer case study. Figures such as recovery time, incident counts, or cost savings are not included anywhere, since they cannot be verified.
よくある質問
Does this mean coding agents can't be used for production operations?
It's less that they can't, and more that the unit of work is different. They're effective for producing code changes. Keeping production in its expected state, though, requires elements that sit outside the repository — approval, permissions, alert intake, on-call.
If we use both, where should we draw the line?
The practical line is "can it be undone." Code changes and pre-review proposals can be undone. Anything that touches production data, schema, permissions, or secrets is hard to undo, so put it on the side that requires approval and a record.
Do small teams need an approval gate too?
Yes. The smaller the team, the more likely the approver and the executor are the same person. Even then, keeping the form of "write down the procedure and rollback before executing" preserves both the record and reproducibility.
How much should an audit log record?
At minimum five things: who executed it, when, what it did, input and output, and who approved it. With all five in place, you can reconstruct "what happened" after the fact. Missing even one forces root-cause analysis to rely on guesswork.
How far can we let AI handle production operations?
Up to operations where the impact is reversible, the scope is explicitly limited, and a rollback procedure exists before execution. Irreversible operations like data deletion or schema changes should be designed to require human approval. See the article on approval and rollback for automated execution for more detail.
この文書がカバーする質問
- Can a coding agent automate operations too?
- After AI writes the code, who handles production operations?
- What's the difference in scope between FDE Ops and a coding agent?
リスク表示の意味
- 参照のみデータと設定を変更しません。
- 低影響は限定的ですが、権限と負荷の確認が必要です。
- 中性能・ロック・コストに影響する可能性があります。
- 高障害・データ損失・復旧作業が発生する可能性があります。
- 専門家レビュー必須本番適用前に別途レビューが必須です。
GIIPの対応範囲
Everything above is a general design discussion that doesn't assume any particular product. As for where GIIP itself fits in: GIIP has AI agents and human experts continuously monitoring and operating multiple databases and roughly 30 web services on AWS and Azure. AI agents run continuous monitoring and routine checks, while irreversible operations or decisions with business impact are executed only after a human operator approves them. Which of the gaps discussed in this article your organization keeps in-house versus hands off to someone else depends on how you design your own operating model.
執筆・技術検証
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 it takes to bring an AI-generated application to production
We organize the remaining work between "the code works" and "it can run in production" into 14 items, with commands for detecting hardcoded keys and auditing dependency vulnerabilities.
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.
incident-responseWhat database incidents AI agents can handle, and what humans must decide
We split incident response into phases to separate what AI can own (detection, triage, limited initial response) from what requires human judgment (irreversible actions, shutdown decisions), and provide read-only triage queries.
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.
関連サービス
Map out where the gaps in your operations are, together
同じ確認を複数の環境で継続する必要がある場合は、運用体制ごと相談できます。
Map out where the gaps in your operations are, together