コーディングエージェントとGIIP FDE Opsは何が違うのか

この文書の適用条件

そのまま実行できるコマンド

# 対象: 自組織のアプリケーションリポジトリと本番デプロイ
# 権限: リポジトリの読み取り権限
# 変更作業: なし（参照のみ）
# 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 5

# 対象: 自組織の運用基盤（監視・権限・オンコール・監査）
# 権限: 各基盤の参照権限
# 変更作業: なし（確認のみ）
# Production 実行: 該当なし（確認作業）

[1] 監視と通知の受け口
    - 本番が停止したとき、最初に気づくのは人か仕組みか
    - アラートは誰の端末に届き、誰も応答しない場合に次へ渡る仕組みがあるか
    - 通知が届く先は個人のアカウントか、退職しても残る共有の受け口か

[2] 本番変更の承認
    - 本番への変更に承認者がいるか。承認は記録に残るか
    - 承認なしで本番に適用できる経路（手動デプロイ、直接SSH、DB直接接続）が残っていないか

[3] 権限とシークレット
    - 本番の認証情報はどこに保管され、誰が参照でき、いつ更新されたか
    - 退職・契約終了時に権限を剥奪する手順が文書化されているか

[4] 障害時の一次対応
    - 深夜に落ちたとき、最初の30分で誰が何をするかが決まっているか
    - 切り分けの手順（どのログを見るか、どのクエリを流すか）が書かれているか

[5] ロールバック
    - 直前のバージョンに戻す手順が、実際に試された状態で存在するか
    - データベースのマイグレーションを戻す手順があるか

[6] 監査ログ
    - 誰が・いつ・何を・どの承認で本番に適用したかを後から再構成できるか

[7] オンコールとエスカレーション
    - 一次対応者が判断できない場合の連絡先と判断権限者が決まっているか
    - 対応時間の約束（SLA）があり、その根拠となる監視間隔が定義されているか

[8] 複数システムにまたがる影響判断
    - あるサービスを停止したとき、連鎖して止まる下流を一覧できるか

結果の読み方

こういう状況で使います

• コーディングエージェントを導入して開発速度は上がったが、本番障害の件数も対応時間も変わらない
• 「コードは書けたが、本番に載せる作業が終わらない」という状態が続いている
• 本番で今どのバージョンが動いているのかを即答できない
• 深夜のアラートに誰が応答するかが決まっていない
• 本番に適用した変更の記録が、個人のチャット履歴にしか残っていない

考えられる原因（可能性の高い順）

1. 01

   作業の単位が違うものを、機能の多少で比較している

   コーディングエージェントはコード変更を完了させる道具で、運用サービスは状態を維持し続ける役務です。前者に後者の機能を足しても、当番や承認権限といった「人と組織に属する要素」は埋まりません。

2. 02

   本番環境に対する権限の設計が無い

   本番の変更を自動化するには、何を誰の承認で実行してよいかという権限設計が先に必要です。設計が無い状態では、安全側に倒すために結局すべてを人手に戻すことになります。

3. 03

   通知の受け口が個人に紐づいている

   アラートが特定個人のアカウントにしか届かない場合、その人が不在の時間帯は監視が実質停止します。監視ツールの有無ではなく、受け口の設計の問題です。

4. 04

   ロールバックが「戻せるはず」で止まっている

   実際に試していないロールバック手順は、障害時に初めて失敗が判明します。特にデータベースのスキーマ変更やデータ削除は、コードの取り消しでは戻りません。

確認手順

1. 1

   本番の稼働リビジョンを確認する

   参照のみ

   本番で動いているコミットハッシュを、デプロイ記録またはアプリのヘルスエンドポイントから取得します。取得できない場合、変更の追跡は成立していません。

2. 2

   レビューを経ない本番変更が無いかを確認する

   参照のみ

   上記の git コマンドで、マージを経ずに本番ブランチへ入ったコミットを洗い出します。

3. 3

   監査ログの有無を確認する

   参照のみ

   本番への適用について、実行者・時刻・内容・承認者の4点が後から再構成できるかを確認します。1つでも欠けていれば監査ログとしては不十分です。

4. 4

   オンコール表と通知経路を確認する

   参照のみ

   直近1か月のアラートについて、誰がいつ応答したかを確認します。応答記録が無いアラートは「誰も気づいていない」可能性があります。

5. 5

   ロールバックを実際に実施できるかを確認する

   中

   本番と同等の構成を持つ環境で、直前バージョンへの切り戻しとマイグレーションの巻き戻しを1度実行します。

対応方法

バージョン・環境による違い

これで解決しない場合に確認すること

• 直近の障害の一次対応記録を読み返す

  検知から切り分けまでに何分かかり、どこで止まったかを確認します。止まった箇所が、埋めるべき空白です。

• 本番に触れる経路を全部数える

  CI/CD、手動デプロイ、SSH、DBクライアント、クラウドコンソール、管理画面。数え上げた経路のうち記録が残らないものを特定します。

• 不在時の代替が決まっているかを確認する

  主担当が休暇中でも同じ手順が回るかを確認します。回らない場合、それは自動化ではなく属人化です。

• 監視の対象が「サービスの成立条件」を覆っているかを確認する

  プロセスの死活だけでなく、実際にユーザーが使う経路が成立しているかを見ているかを確認します。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• コーディングエージェントで運用まで自動化できますか
• AIにコードを書かせた後、本番運用は誰がやるのか
• FDE Ops と コーディングエージェントの守備範囲の違いを知りたい

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

ここまでの整理は特定の製品を前提としない一般的な設計の話です。そのうえで GIIP がどこを担当しているかを述べると、GIIP は AWS と Azure 上の複数データベースおよび約30の Web サービスを、AI エージェントと人間の専門家が継続的に監視・運用しています。AIエージェントが常時監視と定型の確認作業を実行し、不可逆な操作や業務影響を伴う判断は人間の担当者が承認してから実行する、という役割分担で運用しています。本記事で挙げた空白のうち、どれを自組織で持ち、どれを外部に委ねるかは体制の設計次第です。

関連サービス

• GIIP FDE Ops の対応範囲
• コーディングエージェントとFDE Boxの違い
• AIエージェントによるIT運用