製造業のGKEマニフェストをClaude Codeでレビューする: 本番反映前の確認表

製造業の検査ラインで、朝8時に不良品登録画面が開かない。現場のPCには「再読み込みしてください」だけが出て、品質保証の担当者は紙に戻り、昼前にはCSVの突合作業が積み上がります。原因を追うと、前日の夜にGKEへ反映したマニフェストで、readinessProbeがなく、replicasが1つ、image tagがlatestのままでした。

この記事では、製造業のMES、検査記録、工程進捗、在庫照会のような小さな社内WebアプリをGKEへ出す前に、Claude Codeでマニフェストをレビューする手順を書きます。Kubernetesの入門ではなく、製造現場で止めると損が出るYAMLを、公開前の確認表に落とす記事です。

この記事の要点

• 製造業のGKEレビューでは、Deploymentのきれいさより「ライン停止、検査記録漏れ、CSV手戻り」を先に見る。
• 本番反映前の確認表には、image tag、replicas、probes、resources、Service公開範囲、secret、serviceAccountNameを入れる。
• Claude Codeには、マニフェストの差分、kubectl確認コマンド、戻し方、現場への連絡文を作らせる。
• 人が見る範囲は、反映時刻、停止許容時間、品質記録、現場責任者の承認、認証情報、外部公開の有無。
• 成果は、障害件数だけでなく、検査入力の遅れ、紙戻り回数、復旧までの分、夜間呼び出し件数で見る。

現場で起きる失敗シーン

製造業の社内システムは、ECサイトのように「数分落ちてもあとで買ってもらう」とはいきません。検査結果、工程進捗、出荷判定、在庫照会、設備点検の画面が止まると、人は紙とExcelに戻ります。復旧後に入力し直すため、検査漏れ、時刻ズレ、CSVの二重登録が起きます。

GKEのマニフェストで事故になりやすいのは、難しいクラスタ設計ではなく、レビューで止められる小さな抜けです。「image: latest」のまま、「replicas: 1」のまま、readinessProbeなし、resourcesなし、Secretを平文でenvに置く、ServiceをLoadBalancerで外へ出す。どれもYAMLとしては通ります。だから危ないのです。

参考にした一次情報は、Google Cloud: Best practices for GKE、GKE Workload Identity Federation、Kubernetes Deployments、Kubernetes probes、Kubernetes resource managementです。社内の手順へ移す時は、公式情報と実クラスタの設定を一緒に見ます。

業務フロー: 本番反映前に現場の時間割へ合わせる

製造業のGKE反映では、まずマニフェストではなく時間割を見ます。朝礼、段取り替え、検査ピーク、出荷締め、夜間バッチ、棚卸しの時刻を並べます。反映タイミングが悪いと、Deployment自体は正常でも現場の入力が詰まります。

次に、対象アプリを分類します。検査記録の登録画面、工程進捗の閲覧、在庫照会、ラベル印刷、設備点検、出荷判定では止めてよい分数が違います。ラベル印刷や出荷判定は、画面が止まるとすぐ作業待ちになります。レビュー表にも「止めてよい分」「紙代替の有無」「戻し方」を書きます。

確認項目	見るファイル/画面	止める判断
image tag	Deployment YAML、CIの成果物	latestや手元ビルドなら止める
probes	readinessProbe、livenessProbe	起動直後にTrafficが流れるなら止める
replicas	Deployment spec	業務画面で1なら理由を書く
resources	requests、limits	未設定なら負荷時の影響を確認する
Service公開	Service、Ingress	意図しない外部公開なら止める
secret	env、Secret、Secret Manager	平文の認証情報なら止める
Workload Identity	serviceAccountName、IAM	default service accountなら止める

Claude Codeには、この表を渡して差分を読ませます。「このYAMLは安全か」ではなく、「製造現場の本番反映前レビューとして、止める条件と確認コマンドを出して」と頼むほうが、現場で使える返答になります。

Claude Codeに任せる範囲と人が見る範囲

Claude Codeに任せる範囲は、YAML差分の読み取り、抜けの検出、kubectl確認コマンド、ロールバック手順、現場向けの短い連絡文です。Deployment、Service、Ingress、ConfigMap、Secret、ServiceAccount、HPA、Namespace、CIログを読ませると、レビュー表の下書きが作れます。

人が見る範囲は、反映時刻、ライン停止の許容、品質記録の扱い、現場責任者の承認、認証情報、外部公開、障害時の電話連絡です。Claude Codeが「replicasを2に」と書いても、PLC連携やラベルプリンタのセッション制約で増やせないアプリもあります。AIの指摘は開始点で、最後の判断は現場と運用責任者が持ちます。

Workload Identityは、GKE上のワークロードがGoogle Cloud APIへアクセスするための仕組みです。初心者向けに言うと、Podへ鍵ファイルを持たせず、KubernetesのServiceAccountとGoogle Cloud側の権限をつなぐ考え方です。製造業では、検査画像のCloud Storage、BigQueryの品質集計、Pub/Subの設備イベントなどに触れるため、ここを雑にしない方が後で楽です。

3つのUse case

Use case 1: 検査記録APIのDeploymentをレビューする

• 入力: Deployment YAML、CIで作ったimage tag、検査画面の利用時間、直近の障害メモ。
• 出力: image tag、replicas、probes、resources、rollbackコマンドを含む公開前チェック表。
• 人の確認: 反映時刻が検査ピークと重ならないか、紙代替があるか、品質保証の承認があるかを見る。

このUse caseでは、Claude Codeに「YAMLの正しさ」だけを見せません。検査記録は、止まると紙に戻り、その後の転記でミスが出ます。レビュー表には、技術項目と一緒に現場の代替手順を書きます。

Use case 2: ラベル印刷サービスの公開範囲を確認する

• 入力: Service、Ingress、Namespace、NetworkPolicy、ラベル印刷端末のIP範囲。
• 出力: Service type、Ingressの有無、社内限定か、外部公開の可能性、確認コマンド。
• 人の確認: ラベル印刷端末以外から見えていないか、外部公開が意図したものか、現場責任者が承認したかを見る。

ラベル印刷は、外から見える必要がないことが多いです。Claude Codeには、「type: LoadBalancer」、公開Ingress、広すぎるCIDR、認証なしの管理画面を探させます。見つかったら、反映を止める条件に入れます。

Use case 3: 品質集計ジョブの権限を見直す

• 入力: CronJob、ServiceAccount、IAMロール、BigQuery dataset、Cloud Storage bucket、Secretの扱い。
• 出力: Workload Identityの確認表、過剰権限候補、Secretを平文で置いていないかのチェック。
• 人の確認: datasetやbucketの範囲、個人情報や取引先情報の有無、監査ログの保存期間を見る。

品質集計ジョブは、検査画像や不良理由を扱います。Claude Codeにはロール名とマニフェストの対応を見せ、default service accountを使っていないか、secretがYAMLへ直接入っていないか、BigQueryの権限が広すぎないかを見ます。

コピペで使えるプロンプト

あなたは製造業のGKE本番反映前レビュー担当です。
目的は、検査記録、工程進捗、ラベル印刷、品質集計の画面を止めないことです。

入力:
- Deployment / Service / Ingress / ConfigMap / Secret / ServiceAccount / CronJob のYAML
- CIで作ったimage tag
- 反映予定時刻
- 現場の利用ピーク
- 障害時の戻し方

確認してほしいこと:
1. image tagがlatestや手元ビルドではないか
2. replicas、readinessProbe、livenessProbe、resourcesがあるか
3. ServiceやIngressが意図せず外へ出ていないか
4. SecretやAPI_KEYを平文で置いていないか
5. serviceAccountNameとWorkload Identityの対応があるか
6. kubectlで確認するコマンドとrollbackコマンド
7. 現場責任者が見る確認表

制約:
- 料金、品質判定、出荷可否、個人情報、認証情報は人が確認する
- 反映可/保留/差し戻しの3段階で出す
- 初心者が今日見るべきYAML行を5つに絞る

動く確認コード

製造業のGKEマニフェストは、すべてをクラスタにapplyしてから気づくより、公開前に雑な抜けを検査した方が早いです。次のコードは、わざと危ないDeploymentとServiceを入れています。実行すると、止めるべき項目が表で出ます。

// verify-gke-manifest.mjs
// No dependencies. Run with: node verify-gke-manifest.mjs
const manifest = `
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inspection-api
spec:
  replicas: 1
  template:
    spec:
      containers:
        - name: app
          image: asia-northeast1-docker.pkg.dev/factory/prod/inspection-api:latest
          env:
            - name: CAMERA_API_KEY
              value: "plain-secret"
---
apiVersion: v1
kind: Service
metadata:
  name: inspection-api
spec:
  type: LoadBalancer
  ports:
    - port: 80
`;

const checks = [
  {
    name: "pinned image tag",
    failed: /:latest\b/.test(manifest),
    fix: "use a digest or release tag approved by QA"
  },
  {
    name: "replica count",
    failed: /replicas:\s*1\b/.test(manifest),
    fix: "set replicas to at least 2 for customer-facing production screens"
  },
  {
    name: "readiness probe",
    failed: !/readinessProbe:/.test(manifest),
    fix: "add readinessProbe before routing traffic"
  },
  {
    name: "liveness probe",
    failed: !/livenessProbe:/.test(manifest),
    fix: "add livenessProbe with a safe initial delay"
  },
  {
    name: "resources",
    failed: !/resources:\s*[\s\S]*requests:\s*[\s\S]*limits:/.test(manifest),
    fix: "set CPU and memory requests and limits"
  },
  {
    name: "plain secret",
    failed: /API_KEY[\s\S]*value:\s*["'][^"']+["']/.test(manifest),
    fix: "move secrets to Secret Manager or an approved secret flow"
  },
  {
    name: "service exposure",
    failed: /type:\s*LoadBalancer/.test(manifest),
    fix: "confirm whether an internal Service or controlled Ingress is intended"
  },
  {
    name: "service account",
    failed: !/serviceAccountName:/.test(manifest),
    fix: "use a named Kubernetes service account and Workload Identity"
  }
];

const failures = checks.filter((check) => check.failed);
if (failures.length > 0) {
  console.table(failures.map(({ name, fix }) => ({ name, fix })));
  process.exitCode = 1;
} else {
  console.log("GKE manifest release checklist passed.");
}

この検査コードは、YAMLを完璧に読むツールではありません。狙いは、初心者がレビュー表に入れる項目を手元で確認する点です。本番では、kubeconform、conftest、OPA Gatekeeper、Kyverno、CIの承認フローなどに分けてください。まずは「latest」「probeなし」「resourcesなし」「平文secret」「外部公開」「default権限」を止める癖をつけます。

Pitfall: よくある落とし穴

製造業のGKEレビューでよくある落とし穴は、kubectl applyが通ったら安全だと思うことです。原因は、YAMLの構文チェックと、現場の運用チェックを混ぜている点です。直し方は、apply前に「現場影響」「戻し方」「監視」「権限」を別の列で見ることです。

二つ目は、readinessProbeとlivenessProbeを同じpathに置く流れです。起動に時間がかかる検査APIで、livenessProbeが早すぎるとPodを自分で落とし続けます。readinessはTrafficを流してよいか、livenessは再起動すべきかを見るものです。初回起動が長いならstartupProbeも検討します。

三つ目は、「replicas: 2」だけで安心する流れです。DB migration、ラベルプリンタ、設備接続、ファイルロックのあるアプリでは、単純にPodを増やすと別の事故になります。Claude Codeには「増やしてよいアプリか」「増やせないなら停止時間をどう減らすか」を聞きます。

四つ目は、Secretをbase64にしただけで安全だと思うことです。base64は暗号ではありません。認証情報をGitに置かない方針、Secret Manager、Workload Identity、CIの環境変数、監査ログを合わせて見ます。

よくある質問

Q. 製造業でもGKEは大げさですか。

A. 小さな画面1つならCloud Runや社内VMで足りる場合があります。複数の社内Web、検査API、集計ジョブ、イベント処理を同じ運用基盤で見たい時にGKEを検討します。入れる前に、運用できる人数と戻し方を見ます。

Q. image tagは何を使えばよいですか。

A. latestではなく、CIが作ったrelease tagやdigestを使います。製造業では「昨夜どのimageを出したか」を追える状態が大事です。障害時に戻すため、commit、build番号、承認者も紐づけます。

Q. Claude Codeに本番YAMLをそのまま貼ってよいですか。

A. 認証情報、社内IP、取引先名、設備名、個人情報はマスクします。構造、項目名、差分、エラー、ログの抜粋だけでレビューできることが多いです。権限やsecretは人が確認します。

Q. 何から始めればよいですか。

A. 今日まず、直近で反映予定のDeploymentを1つ選び、image tag、replicas、readinessProbe、resources、serviceAccountNameの5行を確認してください。そこからレビュー表に広げます。

研修・相談につなげるなら何を見るか

製造業のGKE記事から相談へ進めるなら、見る数字はPVだけではありません。検査画面の停止分、紙戻り回数、CSV再入力件数、夜間呼び出し件数、反映差し戻し件数、復旧までの分を見ます。ここが減るなら、マニフェストレビューや運用研修へ進む理由がはっきりします。

GKEのDeployment、Service、Ingress、Workload Identity、CIレビュー、ロールバック演習までまとめて整えたい場合は、ClaudeCodeLabの研修・相談で相談できます。まずはこの記事の確認コードを走らせ、自社YAMLで止めたい条件を5つに絞ってください。

実際に試した結果

この記事では、Google Cloud公式のGKEベストプラクティス、Workload Identity、Kubernetes公式のDeployment、probes、resourcesの説明を確認しました。さらに、slug、frontmatter、内部リンク、外部リンク、CTA、コードブロック、10言語ファイルの有無、記事キューの削除対象を確認しています。今日まず見る1手は、反映予定のDeployment YAMLを開き、image、replicas、readinessProbe、resources、serviceAccountNameの5行をチェックする作業です。