Skip to content
Published on

Cohere Forward Deployed Engineer合格ガイド：AIプラットフォーム展開スペシャリストへの完璧ロードマップ

🇰🇷KO🇺🇸EN🇯🇵JA
Split View✨Start Quiz
Authors

1. CohereとAgentic Platformチーム分析（ぶんせき）

Cohereとは何（なに）か

Cohereは2019年にトロントで設立（せつりつ）されたエンタープライズAI専門企業（きぎょう）です。Google Brain出身（しゅっしん）のAidan Gomez（Transformer論文（ろんぶん）「Attention Is All You Need」共同著者（きょうどうちょしゃ））、Ivan Zhang、Nick Frosstが共同創業（きょうどうそうぎょう）しました。OpenAIがコンシューマー市場（しじょう）を攻略（こうりゃく）する中、Cohereは最初（さいしょ）からエンタープライズB2Bに集中（しゅうちゅう）しており、これが核心的（かくしんてき）な差別化（さべつか）ポイントです。

主要（しゅよう）プロダクトラインナップ：

  • Command R+：エンタープライズ級（きゅう）大規模（だいきぼ）言語（げんご）モデル（LLM）でRAG（Retrieval-Augmented Generation）に最適化（さいてきか）
  • Embed v3：多言語（たげんご）エンベディングモデルで100以上（いじょう）の言語をサポート、検索（けんさく）と分類（ぶんるい）に特化（とっか）
  • Rerank v3：検索結果（けっか）の関連性（かんれんせい）を再評価（さいひょうか）するリランキングモデル
  • Aya：101言語をサポートするオープンソース多言語モデルプロジェクト

Cohereがエンタープライズ市場で強力（きょうりょく）な地位（ちい）を占（し）める理由（りゆう）は、データプライバシーへの徹底的（てっていてき）なアプローチにあります。顧客（こきゃく）のデータが外部（がいぶ）に流出（りゅうしゅつ）しないよう、プライベートクラウドとオンプレミスデプロイメントを核心戦略（せんりゃく）としています。

North AIプラットフォームとは

North AIプラットフォームはCohereのエンタープライズAI展開（てんかい）プラットフォームです。以前（いぜん）はCohere Toolkitと呼（よ）ばれていたものが進化（しんか）した形態（けいたい）で、企業が自社（じしゃ）インフラ内でCohereのAIモデルを安全（あんぜん）に実行（じっこう）できるようにします。

Northの核心的特徴（とくちょう）：

  • プライベートクラウドおよびオンプレミス環境（かんきょう）での完全なAIスタック展開
  • Kubernetesベースのアーキテクチャで多様（たよう）なインフラに展開可能（かのう）
  • Helmチャートによる標準化（ひょうじゅんか）されたデプロイプロセス
  • GPUリソース管理（かんり）とモデルサービング最適化
  • エンタープライズ級セキュリティ、モニタリング、ロギング統合（とうごう）

Agentic Platformチームのミッション

Agentic PlatformチームはCohere内（ない）で最（もっと）も顧客接点（せってん）が高（たか）いチームの一（ひと）つです。このチームのミッションは、企業顧客がAIエージェントを自社環境で安全かつ効率的（こうりつてき）に運用（うんよう）できるようにすることです。

AIエージェントとは単純（たんじゅん）なチャットボットを超（こ）えて、ツールを使用（しよう）し、多段階（だんかい）推論（すいろん）を行（おこな）い、実際（じっさい）のビジネスワークフローを自動化（じどうか）するシステムです。金融機関（きんゆうきかん）での文書分析エージェント、ヘルスケアでの医療記録要約（ようやく）エージェント、通信会社（つうしんがいしゃ）での顧客サービス自動化エージェントなどが代表的（だいひょうてき）な事例（じれい）です。

主要顧客分析

Cohereのエンタープライズ顧客は産業別（さんぎょうべつ）に非常（ひじょう）に多様で、各顧客にはそれぞれ固有（こゆう）のインフラ要件（ようけん）があります。

RBC（Royal Bank of Canada）- 金融

  • カナダ最大（さいだい）の銀行（ぎんこう）で、グローバル金融規制（きせい）（OSFI、GDPR、SOX）への準拠（じゅんきょ）が必須（ひっす）
  • エアギャップ環境でのAI展開が核心課題（かだい）
  • データレジデンシー要件：カナダ領土内（りょうどない）でのデータ保管（ほかん）義務（ぎむ）
  • 金融データの機密性（きみつせい）による極度（きょくど）のセキュリティ要求（ようきゅう）

Dell Technologies - IT/ハードウェア

  • Dell自社のサーバーとストレージインフラ上にAI展開
  • Dell PowerEdge + NVIDIA GPUの組（く）み合（あ）わせによるオンプレミスAIインフラ
  • マルチテナンシー環境での隔離（かくり）されたAIワークロード管理
  • Dellの顧客にもAIソリューションを提供（ていきょう）する二次（にじ）デプロイメントシナリオ

LG CNS - ITサービス/韓国

  • 韓国の個人情報保護法（PIPA）およびデータ3法への準拠
  • 韓国語特化AIモデル性能最適化の要求
  • 金融（LGグループ系列（けいれつ））、製造（せいぞう）、物流（ぶつりゅう）など多様な産業対応（たいおう）
  • 韓国市場特有のオンプレミス選好（せんこう）文化（ぶんか）への対応

Forward Deployed Engineerの起源（きげん）

Forward Deployed Engineer（FDE）という職名（しょくめい）はPalantir Technologiesが最初に生（う）み出（だ）した概念（がいねん）です。軍事用語（ぐんじようご）の「前方配置（ぜんぽうはいち）（Forward Deployed）」から着想（ちゃくそう）を得（え）て、エンジニアを顧客現場（げんば）の最前線（さいぜんせん）に配置するという意味（いみ）を込（こ）めています。

一般的（いっぱんてき）なソフトウェアエンジニアが社内（しゃない）でプロダクトを開発（かいはつ）するのとは異（こと）なり、FDEは顧客の環境を直接（ちょくせつ）理解（りかい）し、その上にソリューションを構築（こうちく）します。PalantirのFDEはアメリカ政府（せいふ）、軍（ぐん）、情報機関（じょうほうきかん）と直接協力（きょうりょく）してデータ分析プラットフォームを展開する役割（やくわり）でした。

このモデルが成功（せいこう）したことで、Databricks、Scale AI、Anyscaleなど多くのAI/データ企業が類似（るいじ）の役割を導入（どうにゅう）し、Cohereもこのモデルを採用（さいよう）しました。

FDE vs SE vs SA 役割比較（ひかく）

区分（くぶん）Forward Deployed Engineer (FDE)Solutions Engineer (SE)Solutions Architect (SA)
核心業務（ぎょうむ）顧客現場で直接デプロイ/構築技術営業（えいぎょう）支援、デモ、PoCアーキテクチャ設計（せっけい）、技術コンサルティング
コーディング比率（ひりつ）60-70%（実戦実装（じっそう））30-40%（デモ、スクリプト）10-20%（プロトタイプ）
顧客接点深層的（しんそうてき）（数週間（すうしゅうかん）～数ヶ月常駐（じょうちゅう））営業段階（だんかい）集中設計段階集中
技術深度（しんど）非常に深い（インフラ+コード）広いが深さは普通広くアーキテクチャレベルで深い
出張（しゅっちょう）20-40%（顧客現場）10-20%10-15%
報告（ほうこく）ラインエンジニアリング組織（そしき）営業/プリセールス組織営業またはCTO組織
成功指標（しひょう）デプロイ成功率、稼働時間（かどうじかん）ディール成約率（せいやくりつ）、PoC転換率（てんかんりつ）技術採用率、顧客満足度（まんぞくど）

2. JDライン・バイ・ライン完全解剖（かいぼう）

主要責任（せきにん）分析

「Lead North AI platform deployments across private cloud and on-premises environments」

この一行（いちぎょう）がこのポジションの本質（ほんしつ）です。「Lead」は単なる参加（さんか）ではなく、デプロイの全過程（かてい）を主導（しゅどう）するという意味です。プライベートクラウド（Azure Private Cloud、AWS Outposts、GCP Anthosなど）とオンプレミス（顧客データセンター）の両方（りょうほう）を扱（あつか）う必要があります。

実際にはこれは以下を意味します：

  • 顧客インフラ環境の事前調査（じぜんちょうさ）（Pre-assessment）
  • デプロイアーキテクチャの設計と文書化（ぶんしょか）
  • Kubernetesクラスターのセットアップと検証（けんしょう）
  • HelmチャートによるNorthプラットフォームのデプロイ
  • GPUノードの設定（せってい）とモデルローディング
  • 統合テストとパフォーマンス検証
  • 顧客運用チームへの引き継（ひきつ）ぎ

「Partner with enterprise IT teams on infrastructure and security assessments」

エンタープライズITチームとの協業（きょうぎょう）は技術力と同（おな）じくらいコミュニケーション能力（のうりょく）を要求（ようきゅう）します。大企業のITチームは、セキュリティポリシー、ネットワークアーキテクチャ、変更管理プロセスが厳格（げんかく）です。

インフラ評価（ひょうか）での確認（かくにん）事項：

  • ネットワークトポロジー：VPC/VLAN構成、サブネット、ファイアウォールルール
  • セキュリティポリシー：認証（にんしょう）/認可（にんか）メカニズム、TLS証明書管理
  • コンピューティングリソース：CPU/GPU仕様（しよう）、メモリ、ストレージIOPS
  • Kubernetes環境：バージョン、CNIプラグイン、イングレスコントローラー
  • 規制準拠：データレジデンシー、監査（かんさ）ログ、アクセス制御（せいぎょ）

「Design tailored deployment strategies ensuring data privacy compliance」

カスタマイズされたデプロイ戦略は顧客ごとに異なります。金融機関はエアギャップ環境を要求し、ヘルスケアはHIPAA準拠が必須であり、EU顧客はGDPR要件を満（み）たす必要があります。

デプロイ戦略設計時の考慮（こうりょ）要素：

  • データフロー：学習（がくしゅう）データと推論データの移動経路（けいろ）
  • 暗号化（あんごうか）：保存時（at rest）と転送時（in transit）の暗号化
  • アクセス制御：モデルへのアクセス権限（けんげん）とAPI呼び出し権限
  • 監査証跡（しょうせき）：すべてのアクセスと変更のロギング
  • データ保持（ほじ）：データ保管期間と削除（さくじょ）ポリシー

「Troubleshoot deployment issues and minimize system downtime」

本番（ほんばん）環境でのトラブルシューティング能力はFDEの核心能力です。顧客のプロダクション環境で障害（しょうがい）が発生（はっせい）した場合、即座（そくざ）の対応が必要です。

一般的なトラブルシューティングシナリオ：

  • Pod CrashLoopBackOff：OOM、設定エラー、依存関係（いぞんかんけい）の問題
  • GPU割り当（わりあ）て失敗（しっぱい）：ドライバー不一致（ふいっち）、リソース不足（ふそく）
  • ネットワーク接続（せつぞく）問題：DNS、イングレス、サービスメッシュ設定
  • モデルローディング失敗：ストレージアクセス権限、モデルファイル破損（はそん）
  • パフォーマンス低下（ていか）：リソース競合（きょうごう）、スケーリングの問題

必須資格（しかく）要件分析

「Direct customer-facing experience」

顧客対面（たいめん）経験（けいけん）とは、単に顧客と会話（かいわ）した経験ではありません。技術的に複雑（ふくざつ）な内容を非技術的な意思決定者（いしけっていしゃ）に説明（せつめい）し、技術チームとは深いレベルの技術議論（ぎろん）ができる能力が必要です。

「Production Kubernetes cluster administration and Helm expertise」

プロダクションレベルのK8s運用経験を要求しています。個人（こじん）プロジェクトのminikubeではなく、実際のトラフィックを処理（しょり）するマルチノードクラスターを管理した経験が必要です。Helmは単純な使用ではなく、チャート開発とカスタマイゼーションレベルが期待（きたい）されます。

「Cloud infrastructure (Azure, AWS, GCP), networking, virtualization」

マルチクラウドの知識（ちしき）が必須です。顧客ごとに異なるクラウドを使用するため、3つすべてについての基本的（きほんてき）な理解が必要です。特にネットワーキング（VPC、サブネット、ピアリング、プライベートエンドポイント）と仮想化（かそうか）（VMware、KVM）の知識が重要（じゅうよう）です。

3. 技術スタック深掘（ふかぼ）り

3-1. Kubernetes深掘り（プロダクションクラスター運用）

Kubernetesはこのポジションの最も核心的な技術です。プロダクション環境でのクラスター運用能力が合否（ごうひ）を左右（さゆう）します。

クラスターアーキテクチャの理解

                     ┌─────────────────────────────┐
                     │       Control Plane          │
                     │  ┌─────────┐ ┌───────────┐  │
                     │  │kube-api │ │ scheduler │  │
                     │  │ server  │ │           │  │
                     │  └────┬────┘ └───────────┘  │
                     │  ┌────┴────┐ ┌───────────┐  │
                     │  │  etcd   │ │controller │  │
                     │  │         │ │ manager   │  │
                     │  └─────────┘ └───────────┘  │
                     └──────────────┬──────────────┘
                                    │
              ┌─────────────────────┼─────────────────────┐
              │                     │                     │
     ┌────────┴────────┐  ┌────────┴────────┐  ┌────────┴────────┐
     │   Worker Node 1  │  │   Worker Node 2  │  │  GPU Node (AI)  │
     │  ┌─────┐┌─────┐ │  │  ┌─────┐┌─────┐ │  │  ┌─────┐┌─────┐│
     │  │ Pod ││ Pod │ │  │  │ Pod ││ Pod │ │  │  │ Pod ││ Pod ││
     │  └─────┘└─────┘ │  │  └─────┘└─────┘ │  │  │ GPU ││ GPU ││
     │  kubelet+kproxy  │  │  kubelet+kproxy  │  │  └─────┘└─────┘│
     └──────────────────┘  └──────────────────┘  └─────────────────┘

Control Planeの核心コンポーネント：

  • kube-apiserver：すべてのAPIリクエストのエントリーポイント。REST APIでクラスター状態（じょうたい）を管理
  • etcd：クラスターのすべての状態を保存（ほぞん）する分散（ぶんさん）キー・バリューストア。バックアップが非常に重要
  • kube-scheduler：Podを適切（てきせつ）なノードに配置するスケジューラー。GPU要求時にGPUノードに配置
  • kube-controller-manager：Deployment、ReplicaSet、DaemonSetなどの状態を管理

プロダクションデプロイ戦略

# Rolling Update - 最も一般的
apiVersion: apps/v1
kind: Deployment
metadata:
  name: north-ai-api
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    spec:
      containers:
        - name: north-api
          image: cohere/north-api:v2.1.0
          resources:
            requests:
              memory: '4Gi'
              cpu: '2'
            limits:
              memory: '8Gi'
              cpu: '4'
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 60
            periodSeconds: 30

デプロイ戦略比較：

戦略ダウンタイムロールバック速度（そくど）リソース使用適した状況（じょうきょう）
Rolling Updateなし普通（ふつう）漸進的（ぜんしんてき）増加一般的なアップデート
Blue-Greenなし即時（そくじ）2倍（ばい）重要なアップデート
Canaryなし即時わずかに増加リスクの高い変更
Recreateあり遅い同一互換性（ごかんせい）問題時

RBAC（ロールベースアクセス制御）

エンタープライズ環境でのRBAC設定はセキュリティの基本（きほん）です。

# 顧客別ネームスペース隔離
apiVersion: v1
kind: Namespace
metadata:
  name: customer-rbc
  labels:
    customer: rbc
    environment: production
---
# 最小権限の原則に基づくRole定義
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: customer-rbc
  name: north-deployer
rules:
  - apiGroups: ['apps']
    resources: ['deployments', 'statefulsets']
    verbs: ['get', 'list', 'watch', 'create', 'update', 'patch']
  - apiGroups: ['']
    resources: ['pods', 'services', 'configmaps', 'secrets']
    verbs: ['get', 'list', 'watch', 'create', 'update']
  - apiGroups: ['']
    resources: ['pods/log']
    verbs: ['get']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: customer-rbc
  name: north-deployer-binding
subjects:
  - kind: ServiceAccount
    name: north-deploy-sa
    namespace: customer-rbc
roleRef:
  kind: Role
  name: north-deployer
  apiGroup: rbac.authorization.k8s.io

NetworkPolicyによるネットワーク隔離

# North AIプラットフォームPod間通信のみ許可
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: north-platform-policy
  namespace: customer-rbc
spec:
  podSelector:
    matchLabels:
      app: north-platform
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: north-platform
      ports:
        - protocol: TCP
          port: 8080
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: north-platform
      ports:
        - protocol: TCP
          port: 8080
    - to: # DNS許可
        - namespaceSelector: {}
      ports:
        - protocol: UDP
          port: 53

リソース管理

# LimitRangeでネームスペースのデフォルト値設定
apiVersion: v1
kind: LimitRange
metadata:
  name: north-limits
  namespace: customer-rbc
spec:
  limits:
    - default:
        memory: '2Gi'
        cpu: '1'
      defaultRequest:
        memory: '512Mi'
        cpu: '250m'
      type: Container
---
# ResourceQuotaでネームスペース全体の制限
apiVersion: v1
kind: ResourceQuota
metadata:
  name: north-quota
  namespace: customer-rbc
spec:
  hard:
    requests.cpu: '32'
    requests.memory: '64Gi'
    limits.cpu: '64'
    limits.memory: '128Gi'
    requests.nvidia.com/gpu: '8'
    pods: '50'

GPUノード管理

AIモデルサービングにおいてGPU管理は特に重要です。

# GPUノードへのPod配置のためのtolerations + nodeSelector
apiVersion: apps/v1
kind: Deployment
metadata:
  name: north-model-server
spec:
  template:
    spec:
      nodeSelector:
        accelerator: nvidia-a100
      tolerations:
        - key: 'nvidia.com/gpu'
          operator: 'Exists'
          effect: 'NoSchedule'
      containers:
        - name: model-server
          image: cohere/north-model:latest
          resources:
            limits:
              nvidia.com/gpu: 4
          volumeMounts:
            - name: model-storage
              mountPath: /models
            - name: shm
              mountPath: /dev/shm
      volumes:
        - name: model-storage
          persistentVolumeClaim:
            claimName: model-pvc
        - name: shm
          emptyDir:
            medium: Memory
            sizeLimit: '16Gi'

モニタリングスタック

# Prometheus ServiceMonitor設定
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: north-platform-monitor
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: north-platform
  endpoints:
    - port: metrics
      interval: 30s
      path: /metrics

核心モニタリングメトリクス：

  • Podレベル：CPU/メモリ使用率、再起動回数（かいすう）、OOM Kill回数
  • ノードレベル：ノード可用性（かようせい）、ディスク使用量、GPU活用率（かつようりつ）
  • クラスターレベル：スケジューリング遅延（ちえん）、etcdレイテンシー、APIサーバー応答時間（おうとうじかん）
  • AIワークロード：推論レイテンシー、トークン/秒スループット、キュー深度（しんど）

障害対応手順（てじゅん）

# 1. 問題ノードの特定
kubectl get nodes -o wide
kubectl describe node problematic-node

# 2. ノードcordon（新規Podスケジューリングをブロック）
kubectl cordon problematic-node

# 3. 既存ワークロードの安全な移動（drain）
kubectl drain problematic-node --ignore-daemonsets --delete-emptydir-data

# 4. 問題解決後にノードを復旧
kubectl uncordon problematic-node

# 5. Pod状態確認
kubectl get pods -n customer-rbc -o wide
kubectl logs -n customer-rbc pod-name --previous

推奨（すいしょう）資格証経路：

  1. CKA（Certified Kubernetes Administrator）：クラスター管理に集中 - 必須
  2. CKAD（Certified Kubernetes Application Developer）：アプリケーションデプロイ - 推奨
  3. CKS（Certified Kubernetes Security Specialist）：セキュリティ - 優遇（ゆうぐう）

3-2. Helmマスタークラス

HelmはKubernetesのパッケージマネージャーで、このポジションで毎日使うツールです。North AIプラットフォームのデプロイ単位がHelmチャートなので、チャート開発能力は必須です。

Helmチャート構造（こうぞう）

north-ai-platform/
  Chart.yaml          # チャートメタデータ
  Chart.lock          # 依存関係ロックファイル
  values.yaml         # デフォルト設定値
  values-production.yaml   # プロダクションオーバーライド
  values-staging.yaml      # ステージングオーバーライド
  templates/
    _helpers.tpl      # 共通テンプレート関数
    deployment.yaml   # Deploymentリソース
    service.yaml      # Serviceリソース
    ingress.yaml      # Ingressリソース
    configmap.yaml    # ConfigMap
    secret.yaml       # Secret
    hpa.yaml          # HorizontalPodAutoscaler
    pdb.yaml          # PodDisruptionBudget
    networkpolicy.yaml
    serviceaccount.yaml
    NOTES.txt         # インストール後のガイドメッセージ
  charts/             # サブチャート（依存関係）
  tests/
    test-connection.yaml

values.yaml環境別オーバーライド戦略

# values.yaml（デフォルト値）
replicaCount: 1
image:
  repository: cohere/north-platform
  tag: 'latest'
  pullPolicy: IfNotPresent

modelServer:
  replicas: 1
  gpu:
    enabled: false
    count: 1
    type: ''
  resources:
    requests:
      memory: '8Gi'
      cpu: '4'
    limits:
      memory: '16Gi'
      cpu: '8'

ingress:
  enabled: true
  className: nginx
  tls:
    enabled: true

monitoring:
  enabled: true
  prometheus:
    scrape: true

security:
  networkPolicy:
    enabled: true
  podSecurityContext:
    runAsNonRoot: true
    runAsUser: 1000

# values-production-rbc.yaml（RBC顧客用オーバーライド）
replicaCount: 3

image:
  repository: harbor.rbc.internal/cohere/north-platform
  tag: '3.5.0'
  pullPolicy: Always
  pullSecret: rbc-harbor-secret

modelServer:
  replicas: 2
  gpu:
    enabled: true
    count: 4
    type: nvidia-a100-80gb
  resources:
    requests:
      memory: '64Gi'
      cpu: '16'
    limits:
      memory: '128Gi'
      cpu: '32'

ingress:
  enabled: true
  className: nginx
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: 'true'
    nginx.ingress.kubernetes.io/client-max-body-size: '100m'
  hosts:
    - host: north-ai.rbc.internal
  tls:
    enabled: true
    secretName: rbc-tls-secret

persistence:
  enabled: true
  storageClass: rbc-premium-ssd
  size: 500Gi

Helmフック活用

# pre-installフック：データベースマイグレーション
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
  annotations:
    'helm.sh/hook': pre-install,pre-upgrade
    'helm.sh/hook-weight': '-5'
    'helm.sh/hook-delete-policy': hook-succeeded
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migration
          image: cohere/north-migration:latest
          command: ['./migrate', '--direction', 'up']

チャートテスト

# リント検査
helm lint ./north-ai-platform

# テンプレートレンダリング確認
helm template my-release ./north-ai-platform -f values-production-rbc.yaml

# ドライランでインストールシミュレーション
helm install my-release ./north-ai-platform --dry-run --debug

# チャートテスト実行
helm test my-release

Helmfileによる複数（ふくすう）チャート管理

# helmfile.yaml
repositories:
  - name: bitnami
    url: https://charts.bitnami.com/bitnami

releases:
  - name: north-platform
    chart: ./charts/north-ai-platform
    namespace: north-system
    values:
      - values/common.yaml
      - values/production.yaml

  - name: monitoring
    chart: prometheus-community/kube-prometheus-stack
    namespace: monitoring
    values:
      - values/monitoring.yaml

  - name: ingress
    chart: ingress-nginx/ingress-nginx
    namespace: ingress
    values:
      - values/ingress.yaml

3-3. クラウドインフラストラクチャ（Azure/AWS/GCP）

マネージドKubernetes比較

特性（とくせい）AKS（Azure）EKS（AWS）GKE（Google）
Control Planeコスト無料（むりょう）約（やく）0.10 USD/時間無料（Standard）
GPUサポートA100、H100A100、H100、P5A100、H100、TPU
最大ノード5,000500（マネージドノードグループ）15,000
プライベートクラスターサポートサポートサポート
サービスメッシュIstio、OSMApp Mesh、IstioAnthos SM
GitOps統合Flux（ネイティブ）ArgoCDConfig Sync
MLプラットフォームAzure MLSageMakerVertex AI
エアギャップサポートAzure StackOutpostsAnthos

ネットワーキング核心概念

┌─────────────────────────────────────────────┐
│                    VPC                       │
│  ┌──────────────────┐ ┌──────────────────┐  │
│  │  Public Subnet    │ │  Public Subnet    │  │
│  │  (AZ-1)          │ │  (AZ-2)          │  │
│  │  Load Balancer   │ │  Load Balancer   │  │
│  └────────┬─────────┘ └────────┬─────────┘  │
│           │                     │            │
│  ┌────────┴─────────┐ ┌────────┴─────────┐  │
│  │  Private Subnet   │ │  Private Subnet   │  │
│  │  (AZ-1)          │ │  (AZ-2)          │  │
│  │  K8s Worker      │ │  K8s Worker      │  │
│  │  Nodes           │ │  Nodes           │  │
│  └────────┬─────────┘ └────────┬─────────┘  │
│           │                     │            │
│  ┌────────┴─────────┐ ┌────────┴─────────┐  │
│  │  Data Subnet      │ │  Data Subnet      │  │
│  │  (AZ-1)          │ │  (AZ-2)          │  │
│  │  DB, Storage     │ │  DB, Storage     │  │
│  └──────────────────┘ └──────────────────┘  │
│                                              │
│  ┌──────────────────────────────────────┐   │
│  │  Private Endpoint (Storage/DB)       │   │
│  └──────────────────────────────────────┘   │
└─────────────────────────────────────────────┘

推奨資格証：

  • Azure：AZ-104（Azure Administrator）またはAZ-305（Solutions Architect）
  • AWS：SAA-C03（Solutions Architect Associate）
  • GCP：Professional Cloud Architect

3-4. DevOpsとCI/CD

GitOpsワークフロー

Developer -> Git Push -> GitHub/GitLab
                             │
                    ┌────────┴────────┐
                    │                 │
              CI Pipeline        ArgoCD/Flux
              (Build/Test)     (watches repo)
                    │                 │
              Container        Sync to K8s
              Registry         Cluster
                    │                 │
                    └────────┬────────┘
                             │
                      K8s Cluster
                    (Desired State)

CI/CDパイプライン例（GitHub Actions）

name: North Platform CI/CD
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Helm Lint
        run: helm lint ./charts/north-ai-platform
      - name: Template Validation
        run: |
          helm template test ./charts/north-ai-platform \
            -f values/test.yaml \
            | kubectl apply --dry-run=client -f -

  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Trivy Chart Scan
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: config
          scan-ref: ./charts/north-ai-platform

  build-and-push:
    needs: [lint-and-test, security-scan]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and Push Chart
        run: |
          helm package ./charts/north-ai-platform
          helm push north-ai-platform-*.tgz oci://registry.example.com/charts

IaC：TerraformでK8sクラスタープロビジョニング

# Azure AKSクラスタープロビジョニング
resource "azurerm_kubernetes_cluster" "north" {
  name                = "north-aks-cluster"
  location            = azurerm_resource_group.main.location
  resource_group_name = azurerm_resource_group.main.name
  dns_prefix          = "north"
  kubernetes_version  = "1.29"

  default_node_pool {
    name       = "system"
    node_count = 3
    vm_size    = "Standard_D4s_v3"
  }

  identity {
    type = "SystemAssigned"
  }

  network_profile {
    network_plugin = "azure"
    network_policy = "calico"
  }

  private_cluster_enabled = true
}

# GPUノードプール
resource "azurerm_kubernetes_cluster_node_pool" "gpu" {
  name                  = "gpupool"
  kubernetes_cluster_id = azurerm_kubernetes_cluster.north.id
  vm_size              = "Standard_NC24ads_A100_v4"
  node_count           = 2

  node_taints = [
    "nvidia.com/gpu=present:NoSchedule"
  ]

  node_labels = {
    "accelerator" = "nvidia-a100"
  }
}

3-5. プライベートクラウドとオンプレミスデプロイ

このセクションはこのポジションで最も重要な差別化技術です。パブリッククラウドでのK8s運用は多くのエンジニアができますが、エアギャップ環境でのデプロイ経験は稀少（きしょう）です。

エアギャップ環境の特殊性（とくしゅせい）

エアギャップ環境は外部インターネットと完全に隔離されたネットワークです。金融（RBC）、軍事、医療機関で主に使用されます。

エアギャップ環境での主要課題：

  1. コンテナイメージの配信（はいしん）：Docker Hub、GitHub Container Registryへのアクセス不可
  2. パッケージインストール：apt、yum、pip、npmリポジトリへのアクセス不可
  3. Helmチャートダウンロード：チャートリポジトリへのアクセス不可
  4. 証明書管理：Let's Encryptなどの外部CA使用不可
  5. 時刻（じこく）同期（どうき）：NTPサーバーへのアクセスが制限（せいげん）される場合あり

Harborミラーレジストリ構築

# Harborインストール（エアギャップ環境用）
# 1. インターネット接続環境で全イメージをダウンロード
docker pull goharbor/harbor-core:v2.10.0
docker pull goharbor/harbor-db:v2.10.0
docker pull goharbor/harbor-jobservice:v2.10.0
docker pull goharbor/harbor-portal:v2.10.0
docker pull goharbor/nginx-photon:v2.10.0
docker pull goharbor/registry-photon:v2.10.0

# 2. イメージをtarとして保存
docker save -o harbor-images.tar \
  goharbor/harbor-core:v2.10.0 \
  goharbor/harbor-db:v2.10.0 \
  goharbor/harbor-jobservice:v2.10.0 \
  goharbor/harbor-portal:v2.10.0

# 3. 物理メディアを通じてエアギャップ環境に転送

# 4. エアギャップ環境でイメージをロード
docker load -i harbor-images.tar

データレジデンシーと規制準拠

規制地域（ちいき）核心要件
GDPREUデータ処理同意、忘れられる権利、DPO指名
PIPA韓国個人情報収集・利用同意、国外移転制限
FISC日本金融システムセキュリティ基準、国内データ保管
OSFIカナダ金融機関テクノロジーリスク管理
HIPAAアメリカ医療データ保護、暗号化必須

GPUインフラ管理

# NVIDIA GPU Operatorインストール（エアギャップ環境）
apiVersion: v1
kind: Namespace
metadata:
  name: gpu-operator
---
# NVIDIA Device Plugin DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nvidia-device-plugin
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: nvidia-device-plugin
  template:
    metadata:
      labels:
        name: nvidia-device-plugin
    spec:
      tolerations:
        - key: nvidia.com/gpu
          operator: Exists
          effect: NoSchedule
      containers:
        - name: nvidia-device-plugin
          image: harbor.internal/nvidia/k8s-device-plugin:v0.14.0
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop: ['ALL']
          volumeMounts:
            - name: device-plugin
              mountPath: /var/lib/kubelet/device-plugins
      volumes:
        - name: device-plugin
          hostPath:
            path: /var/lib/kubelet/device-plugins

3-6. AIモデルデプロイ技術

LLMサービングフレームワーク

フレームワーク特徴適した状況
vLLMPagedAttentionによる高スループット汎用（はんよう）LLMサービング
TensorRT-LLMNVIDIA最適化、最高性能NVIDIA GPU環境
Tritonマルチモデル、マルチフレームワーク複合モデルパイプライン
Text Generation InferenceHuggingFaceエコシステム統合HFモデル使用時

RAGアーキテクチャ

ユーザークエリ
    │
    ▼
┌──────────┐    ┌──────────────┐
│ Embed v3 │───▶│ Vector DB    │
│ (クエリ   │    │ (検索)       │
│  埋め込み) │    │ Pinecone/    │
└──────────┘    │ Weaviate/    │
                │ pgvector     │
                └──────┬───────┘
                       │ Top-K文書
                       ▼
                ┌──────────────┐
                │ Rerank v3    │
                │ (関連性再順位) │
                └──────┬───────┘
                       │ 精選文書
                       ▼
                ┌──────────────┐
                │ Command R+   │
                │ (回答生成)    │
                └──────────────┘
                       │
                       ▼
                   最終回答

モデル最適化技法（ぎほう）

  • 量子化（りょうしか）（Quantization）：FP32 -> FP16 -> INT8 -> INT4でモデルサイズとメモリを削減（さくげん）
  • 知識蒸留（ちしきじょうりゅう）（Distillation）：大きなモデルの知識を小さなモデルに転移（てんい）
  • KVキャッシュ最適化：PagedAttentionによるメモリ効率改善（かいぜん）
  • バッチ処理：Continuous Batchingによるスループット最大化（さいだいか）

3-7. 顧客対応能力（ソフトスキル）

FDEポジションは技術力と同じくらい顧客対応能力が重要です。

技術プレゼンテーションスキル

  • 聴衆（ちょうしゅう）に合わせる：CTOにはアーキテクチャレベル、ITチームには実装レベルで調整（ちょうせい）
  • デモ準備（じゅんび）：ライブデモには必ずバックアップ録画（ろくが）を用意
  • 質問（しつもん）への対応：わからないことは正直（しょうじき）に認（みと）め、フォローアップを約束（やくそく）

言語能力

このポジションは日本ベースなので：

  • 英語：技術文書作成、グローバルチームとのコミュニケーション（必須）
  • 日本語：日本の顧客対応（非常に有利）
  • 韓国語：LG CNSなど韓国顧客対応（ボーナス）

障害対応時の顧客コミュニケーションテンプレート

[障害検知時]（5分以内）
「現在、[システム名]で[症状]が確認されました。
原因分析を開始しており、[予想時間]以内にアップデートをお伝えします。」

[原因特定時]
「原因が[根本原因]であると確認されました。
[解決方法]を進行中で、推定復旧時間は[ETA]です。」

[解決完了時]
「[時刻]にサービスが正常復旧しました。
根本原因：[詳細説明]
再発防止策：[対策]
詳細RCA（Root Cause Analysis）レポートは[期限]までにお届けします。」

4. 面接（めんせつ）予想質問25選

Kubernetesとインフラ（8問）

Q1. プロダクションKubernetesクラスターでノード障害が発生した場合の対応手順を説明してください。

回答ポイント：障害検知（モニタリングアラート）-> 影響範囲（えいきょうはんい）の把握（はあく）-> cordonで新規スケジューリングをブロック -> drainでワークロードを移動 -> ノード問題解決または交換（こうかん）-> uncordonで復旧 -> 事後分析（Post-mortem）

Q2. etcdのバックアップとリカバリー戦略を説明してください。

回答ポイント：etcdスナップショットの定期（ていき）バックアップ、バックアップ周期（しゅうき）の決定基準、復旧手順、分散環境でのクォーラム維持（いじ）、etcdパフォーマンスがクラスター全体に与（あた）える影響

Q3. PodがPending状態から抜（ぬ）け出せない場合のデバッグ手順を説明してください。

回答ポイント：kubectl describe podでイベント確認 -> リソース不足（CPU/メモリ/GPU）確認 -> PVCバインディング確認 -> nodeSelector/affinity/taint確認 -> スケジューラーログ確認

Q4. NetworkPolicyを使用したマイクロサービス間通信制御方法を説明してください。

回答ポイント：デフォルト拒否（きょひ）（deny-all）ポリシー設定 -> 必要な通信のみホワイトリスト -> ネームスペース間隔離 -> egressでの外部通信制限

Q5. KubernetesでGPUリソースを管理する方法を説明してください。

回答ポイント：NVIDIA Device Plugin、resource limits、nodeSelector、tolerations、MIG設定、モニタリング（DCGM exporter）

Q6. PodDisruptionBudget（PDB）の役割と設定戦略を説明してください。

回答ポイント：自発的中断（アップグレード、スケールダウン）時の最小可用Pod保証、minAvailable vs maxUnavailable戦略、StatefulSetとの関係

Q7. Horizontal Pod AutoscalerとVertical Pod Autoscalerの違いと各使用シナリオを説明してください。

回答ポイント：HPAはPod数を調整、VPAはリソース要求量を調整。AI推論サービスではGPU Podの水平（すいへい）スケーリングが主に使用。カスタムメトリクスベースのスケーリング（キュー長、レイテンシー）

Q8. マルチテナンシー環境でネームスペースレベルの隔離を実装する方法を説明してください。

回答ポイント：ネームスペース + RBAC + NetworkPolicy + ResourceQuota + LimitRange + Pod Security Standardsの組み合わせ

Helmとデプロイ戦略（5問）

Q9. Helmチャートのvalues.yamlオーバーライド戦略を説明してください。複数環境（dev/staging/prod）ではどのように管理しますか？

回答ポイント：基本values.yaml + 環境別オーバーライドファイル、Helmfile活用、シークレット管理戦略（Sealed Secrets、SOPS）

Q10. Helmフックを活用したデプロイ自動化の経験を共有してください。

回答ポイント：pre-install/pre-upgradeでDBマイグレーション、post-installで初期設定、フックウェイトで実行順序制御

Q11. エアギャップ環境にHelmチャートをデプロイする全プロセスを説明してください。

回答ポイント：チャートパッケージング -> イメージリスト抽出（ちゅうしゅつ）-> イメージダウンロード/保存 -> 物理メディア転送 -> 内部レジストリにロード -> values修正（イメージパス変更）-> インストール

Q12. KubernetesとHelmでCanaryデプロイを実装する方法を説明してください。

回答ポイント：別のDeploymentでCanaryバージョンをデプロイ、Serviceのselectorを活用、IstioのVirtualServiceでトラフィック比率を制御、メトリクスベースの自動昇格（しょうかく）/ロールバック

Q13. HelmチャートでCRD（Custom Resource Definition）を管理する戦略を説明してください。

回答ポイント：crds/ディレクトリの使用、CRDアップグレード時の注意事項、HelmはCRDを削除しないポリシー、別チャートでCRDを管理するパターン

クラウドとネットワーキング（5問）

Q14. Azure、AWS、GCPの各マネージドKubernetesサービスの長所短所を比較してください。

回答ポイント：セクション3-3の比較表の内容 + 実際の運用経験に基づくインサイト

Q15. AIワークロードのためのVPC設計で考慮すべきネットワーキング要素を説明してください。

回答ポイント：サブネット分離（パブリック/プライベート/データ）、帯域幅（たいいきはば）要件（GPUノード間通信）、Private Endpoint、NAT Gateway、DNS名前解決

Q16. ハイブリッドクラウド環境でオンプレミスとクラウド間のセキュアな接続を構築する方法を説明してください。

回答ポイント：VPN Gateway、ExpressRoute/Direct Connect/Interconnect、mTLS、証明書管理、帯域幅計画

Q17. Terraformでマルチクラウドインフラを管理した経験があれば共有してください。

回答ポイント：プロバイダー別モジュール分離、リモート状態管理（Backend）、ワークスペース戦略、モジュール再利用パターン

Q18. プライベートエンドポイントを通じたストレージアクセス設定の経験を説明してください。

回答ポイント：Azure Private Endpoint / AWS VPC Endpoint / GCP Private Service Connect、DNS設定、ネットワークルール

AIデプロイとトラブルシューティング（4問）

Q19. 大規模LLMをKubernetes環境でサービングする際の主要な課題と解決方法を説明してください。

回答ポイント：GPUメモリ管理、モデルロード時間、コールドスタート問題、バッチ処理最適化、モデルアップデート戦略（ダウンタイム最小化）

Q20. RAG（Retrieval-Augmented Generation）システムのアーキテクチャ設計とデプロイの経験を共有してください。

回答ポイント：Vector DB選択基準、エンベディングモデルサービング、検索-リランキング-生成パイプライン、文書チャンキング戦略、パフォーマンスチューニング

Q21. AIモデルサービング時にOOM（Out of Memory）エラーが繰り返し発生する場合のデバッグプロセスを説明してください。

回答ポイント：GPUメモリ vs システムメモリの区別、nvidia-smiでGPU使用量確認、バッチサイズ調整、量子化適用、KVキャッシュサイズ制限、shared memory設定

Q22. モデルアップデートをゼロダウンタイムで実行する戦略を説明してください。

回答ポイント：Blue-Greenデプロイで新モデルバージョンを準備、Health Checkでモデルロード完了確認後にトラフィック切（き）り替（か）え、ロールバック計画、A/Bテストの可能性

顧客対応と状況（3問）

Q23. 顧客のプロダクション環境で緊急障害が発生した場合、どのように対応しますか？

回答ポイント：即座の対応（10分以内）、影響範囲の把握、一時的な対処（workaround）の適用、顧客コミュニケーション（定期アップデート）、根本原因分析、RCAレポート、再発防止

Q24. 顧客のITチームがKubernetesの経験が不足している状況でNorth Platformをデプロイする必要がある場合、どのようにアプローチしますか？

回答ポイント：顧客チームの能力評価、段階的トレーニング計画の策定（さくてい）、文書化（デプロイガイド、運用ガイド）、運用引き継ぎ計画、ポストデプロイサポート期間

Q25. 顧客が技術的に不可能な要件を提示した場合（例：エアギャップ環境でのリアルタイムモデルアップデート）、どのように対応しますか？

回答ポイント：要件の本質的ニーズの把握、代替案（だいたいあん）の提示（定期アップデートサイクル、準エアギャップ構成）、トレードオフの明確な説明、技術的根拠（こんきょ）の文書化

5. 8ヶ月学習ロードマップ

月テーマ目標（もくひょう）核心プロジェクト
1ヶ月Kubernetes基礎 + CKA準備クラスターインストール、Pod/Service/Deploymentの理解minikubeで3層アプリデプロイ
2ヶ月Kubernetes深化 + CKA取得RBAC、NetworkPolicy、ストレージ、モニタリングkubeadmでマルチノードクラスター構築
3ヶ月Helmマスター + クラウド基礎チャート開発、テンプレートエンジン理解、AKS/EKS経験カスタムHelmチャート作成とデプロイ
4ヶ月クラウドインフラ + TerraformVPC設計、IAM、TerraformでIaC実習TerraformでK8sクラスタープロビジョニング
5ヶ月CI/CD + GitOpsGitHub Actions、ArgoCD、コンテナセキュリティGitOpsパイプライン構築
6ヶ月エアギャップ/オンプレミスデプロイHarbor構築、オフラインデプロイ、RKE2エアギャップ環境シミュレーション
7ヶ月AIモデルデプロイvLLM、RAGアーキテクチャ、GPU管理LLMサービングパイプライン構築
8ヶ月統合プロジェクト + 面接準備ポートフォリオ完成、模擬（もぎ）面接フルスタックAIデプロイプラットフォーム

月別詳細（しょうさい）計画

1ヶ月目：Kubernetes基礎

  • 第1-2週：K8sアーキテクチャの理解、kubectl習熟（しゅうじゅく）
  • 第3-4週：Deployment、Service、ConfigMap、Secretの実習
  • 毎日1時間CKA問題演習（えんしゅう）
  • ツール：minikube、kind

2ヶ月目：Kubernetes深化 + CKA

  • 第1週：RBAC、ServiceAccount
  • 第2週：NetworkPolicy、Ingress
  • 第3週：PV/PVC、StorageClass、StatefulSet
  • 第4週：CKA試験受験（じゅけん）
  • ツール：kubeadm、Vagrant

3ヶ月目：Helm + クラウド入門

  • 第1-2週：Helm基礎、既存チャートの分析
  • 第3週：カスタムチャート開発、テンプレートエンジン
  • 第4週：AKSまたはEKSの初体験
  • プロジェクト：マイクロサービスアプリをHelmチャートとしてパッケージング

4ヶ月目：クラウドインフラ + Terraform

  • 第1週：VPC設計、サブネット、セキュリティグループ
  • 第2週：IAM、サービスアカウント、ワークロードアイデンティティ
  • 第3-4週：Terraform基礎、モジュール作成
  • プロジェクト：TerraformでプライベートK8sクラスター構築

5ヶ月目：CI/CD + GitOps

  • 第1週：GitHub Actionsパイプライン構築
  • 第2週：ArgoCDのインストールと設定
  • 第3週：コンテナイメージスキャニング、Trivy
  • 第4週：統合CI/CD + GitOpsパイプライン
  • プロジェクト：Push-to-Deploy自動化の実装

6ヶ月目：エアギャップ/オンプレミス

  • 第1週：Harborのインストールと運用
  • 第2週：オフラインイメージ/チャートバンドル作成
  • 第3週：RKE2でエアギャップK8sクラスター構築
  • 第4週：セキュリティ強化（Falco、OPA/Gatekeeper）
  • プロジェクト：完全エアギャップ環境でのアプリデプロイ

7ヶ月目：AIモデルデプロイ

  • 第1週：vLLMでLLMサービング
  • 第2週：GPU管理、NVIDIA Device Plugin
  • 第3週：RAGパイプライン構築
  • 第4週：モニタリングと最適化
  • プロジェクト：K8s + HelmでLLMサービング構築

8ヶ月目：統合 + 面接準備

  • 第1-2週：ポートフォリオプロジェクト完成
  • 第3週：技術面接模擬練習
  • 第4週：行動面接準備、履歴書（りれきしょ）の最終レビュー
  • 毎日：面接質問25選の繰り返し練習

6. ポートフォリオプロジェクトアイデア3選

プロジェクト1：K8s + HelmでLLMサービングパイプライン

目標：オープンソースLLMをKubernetes環境でHelmチャートを使ってデプロイ・運用する完全なパイプラインの構築

技術スタック：Kubernetes、Helm、vLLM、Prometheus、Grafana、NVIDIA GPU Operator

実装内容：

  • vLLMベースのモデルサービング用カスタムHelmチャート開発
  • GPUノード管理とオートスケーリング設定
  • Prometheus + Grafanaで推論メトリクスダッシュボード構築
  • Health Checkと自動復旧メカニズム
  • モデルアップデートのためのBlue-Greenデプロイ戦略

プロジェクト2：エアギャップ環境シミュレーションデプロイ

目標：完全にインターネットが隔離された環境をシミュレーションし、その中でAIサービスをデプロイする全プロセスの実習

技術スタック：Vagrant、RKE2、Harbor、Helm、コンテナイメージバンドリング

実装内容：

  • Vagrantでネットワーク隔離されたVM環境構築
  • Harborミラーレジストリのインストールと構成
  • RKE2でエアギャップK8sクラスター構築
  • すべてのイメージとチャートをオフラインバンドルとしてパッケージング
  • バンドルによるアプリケーションデプロイ自動化スクリプト
  • 内部CAによるTLS証明書管理

プロジェクト3：マルチクラウドAIデプロイ自動化

目標：TerraformとHelmでAzure、AWS、GCPの3つのクラウドに同一のAIサービスをデプロイする自動化システムの構築

技術スタック：Terraform、Helm、Helmfile、GitHub Actions、AKS/EKS/GKE

実装内容：

  • Terraformモジュールでクラウド別K8sクラスタープロビジョニング
  • Helmfileでクラウド非依存のアプリケーションデプロイ
  • GitHub ActionsでCI/CDパイプライン統合
  • クラウド別差異（ストレージ、IAM、ネットワーキング）の抽象化
  • コスト比較分析ドキュメント
  • 災害復旧（さいがいふっきゅう）（DR）戦略を含む

7. 履歴書作成戦略

STAR形式で経験を整理

履歴書の各経験はSTAR（Situation-Task-Action-Result）形式で構成すべきです。

良い例：

「レガシーVMベースのデプロイシステムからKubernetesへのマイグレーションを主導（S/T）。Helmチャートを開発し、ArgoCDベースのGitOpsパイプラインを構築してデプロイ自動化を実現（A）。結果としてデプロイ時間を2時間から15分に87%短縮し、デプロイ関連障害を月3件から0件に削減（R）。」

FDEポジションに合った核心キーワード

履歴書に必ず含めるべきキーワード：

  • インフラ：Kubernetes、Helm、Terraform、Docker、CI/CD
  • クラウド：Azure/AWS/GCP、VPC、IAM、プライベートクラウド
  • セキュリティ：RBAC、NetworkPolicy、TLS、エアギャップ、規制準拠
  • AI/ML：LLMデプロイ、GPU管理、モデルサービング、RAG
  • ソフト：顧客対応、技術プレゼンテーション、ドキュメンテーション、トラブルシューティング

顧客対応経験の強調（きょうちょう）

FDEポジションで最も差別化される要素は顧客対応経験です。

強調すべきポイント：

  • 顧客との直接コミュニケーション経験（技術ミーティング、デモ、トレーニング）
  • 顧客環境での直接デプロイ/運用経験
  • 障害対応およびRCA（Root Cause Analysis）経験
  • 技術ドキュメント作成と提供経験
  • 非技術的な意思決定者への技術説明経験

8. Cohereで働（はたら）くということ

福利厚生（ふくりこうせい）と文化

Cohereの福利厚生はAIスタートアップの中でもトップレベルです。

主要な福利厚生：

  • 6週間の休暇（きゅうか）：日本の法定休暇と比較しても非常に手厚（てあつ）い
  • 育児休暇（いくじきゅうか）100%トップアップ（6ヶ月）：政府支援金に加えて給与100%を保証
  • リモートワークの柔軟性（じゅうなんせい）：日本のどこからでも勤務（きんむ）可能、EMEA/APACリージョンへの出張
  • 健康保険（けんこうほけん）：包括的な医療、歯科、眼科保険
  • 学習支援（がくしゅうしえん）：資格証、カンファレンス、書籍購入支援
  • ストックオプション：スタートアップの成長に伴う資産形成（しさんけいせい）の機会

成長機会（きかい）

AI最前線での経験：

  • 世界最高水準のLLMを直接扱い、デプロイする経験
  • エンタープライズAIデプロイの最新トレンドと技術を学習
  • 金融、医療、通信など多様な産業でのAI適用事例の経験

グローバルネットワーク：

  • RBC、Dell、LG CNSなどグローバルエンタープライズ顧客との協業
  • 多国籍チーム（カナダ、アメリカ、日本、ヨーロッパ）との協業経験
  • グローバルAIカンファレンスとコミュニティへの参加機会

チャレンジ

正直（しょうじき）に言って、このポジションの課題も知っておくべきです。

出張（20-40%）

  • 月に1-2週間は顧客現場にいる可能性
  • 日本国内 + アジア太平洋地域への出張
  • リモートワークとのバランスが必要

顧客現場でのプレッシャー

  • 顧客のプロダクション環境での障害は高いストレスを伴う
  • さまざまな顧客のさまざまな環境に素早（すばや）く適応（てきおう）する必要
  • 技術的限界と顧客の期待の間の調整

技術範囲の広さ

  • K8s、Helm、クラウド、ネットワーキング、セキュリティ、AIすべてを扱う必要
  • 継続的（けいぞくてき）な学習が必須
  • 幅（はば）と深さを同時に維持するのが課題

9. クイズ

学んだ内容を確認しましょう。

Q1. Forward Deployed Engineer（FDE）はどの会社が最初に作った概念で、一般的なソフトウェアエンジニアとの最大の違いは何ですか？

A：Palantir Technologiesが最初に作った概念です。一般的なソフトウェアエンジニアが社内でプロダクトを開発するのとは異なり、FDEは顧客現場で直接技術ソリューションを構築・デプロイします。顧客のインフラ環境を理解し、その上にカスタマイズされたソリューションを提供することが核心的な差別化ポイントです。

Q2. エアギャップ環境でコンテナイメージをデプロイするにはどのようなプロセスを経る必要がありますか？

A：1）インターネットに接続された環境で必要なすべてのコンテナイメージをダウンロードします。2）docker saveコマンドでイメージをtarファイルとして保存します。3）物理メディア（USB、外付けディスクなど）を通じてエアギャップ環境に転送します。4）docker loadでイメージをロードします。5）Harborのような内部レジストリにイメージをプッシュします。6）Helmチャートのイメージパスを内部レジストリに変更してデプロイします。

Q3. KubernetesのプロダクションRolling UpdateにおけるmaxUnavailableとmaxSurgeの設定の意味と推奨値は何ですか？

A：maxUnavailableはアップデート中に同時に利用不可になれるPodの最大数で、maxSurgeは希望（きぼう）するPod数を超えて追加作成できるPodの最大数です。一般的にmaxUnavailable: 1、maxSurge: 1に設定すると、常に少なくともreplicas-1個のPodがサービスを維持しながら段階的にアップデートされます。AI推論サービスのように可用性が非常に重要な場合はmaxUnavailable: 0、maxSurge: 1に設定するとゼロダウンタイムでアップデートできます。

Q4. CohereのRAGアーキテクチャでEmbed v3、Rerank v3、Command R+はそれぞれどのような役割を果たしますか？

A：Embed v3はユーザークエリと文書をベクトルに変換し、類似度ベースの検索を可能にします。Rerank v3は初期検索結果の関連性を再評価し、最も適切な文書を上位に配置します。Command R+は最終的に選別された文書をコンテキストとして活用し、ユーザーの質問に対する正確な回答を生成します。この3つのモデルが検索-再ランキング-生成のパイプラインを構成します。

Q5. HelmチャートのValues.yamlオーバーライド戦略で環境別（dev/staging/prod）設定分離が重要な理由と、シークレットの管理方法は？

A：環境別設定分離は、同一チャートで複数環境に一貫してデプロイしながらも、環境特性に合った設定（リソースサイズ、レプリカ数、イメージタグなど）を適用できるようにします。基本values.yamlに共通設定を置き、values-dev.yaml、values-staging.yaml、values-production.yamlでオーバーライドします。シークレットは絶対にvaluesファイルに平文で保存してはならず、Sealed Secrets（Bitnami）、SOPS（Mozilla）、External Secrets Operator（AWS/Azure/GCP Secret Manager連携）などを活用すべきです。

10. 参考資料（さんこうしりょう）

公式（こうしき）ドキュメント

  1. Cohere公式ドキュメント - docs.cohere.com - Cohere APIとモデルガイド
  2. Kubernetes公式ドキュメント - kubernetes.io/docs - Kubernetesの完全リファレンス
  3. Helm公式ドキュメント - helm.sh/docs - Helmチャート開発ガイド
  4. NVIDIA GPU Operator - docs.nvidia.com/datacenter/cloud-native - GPU管理ガイド

資格証準備

  1. CKA試験ガイド - training.linuxfoundation.org - CNCF認定K8s管理者
  2. CKAD試験ガイド - training.linuxfoundation.org - CNCF認定K8s開発者
  3. Azure AZ-104 - learn.microsoft.com - Azure管理者資格証
  4. AWS SAA-C03 - aws.amazon.com/certification - AWSソリューションアーキテクト

学習リソース

  1. Kubernetes The Hard Way - Kelsey HightowerのK8s深層学習
  2. Helmチャート開発ベストプラクティス - helm.sh/docs/chart_best_practices
  3. Terraform Up and Running - Yevgeniy Brikman著、IaCのバイブル
  4. vLLM公式ドキュメント - docs.vllm.ai - LLMサービングフレームワーク

業界（ぎょうかい）動向（どうこう）

  1. Cohereブログ - cohere.com/blog - 最新モデルと技術アップデート
  2. CNCF Landscape - landscape.cncf.io - クラウドネイティブエコシステムマップ
  3. AI Infrastructure Alliance - ai-infrastructure.org - AIインフラ動向

コミュニティ

  1. CNCF Slack - slack.cncf.io - クラウドネイティブコミュニティ
  2. Kubernetes subreddit - reddit.com/r/kubernetes - K8sコミュニティ
  3. MLOps Community - mlops.community - ML運用コミュニティ

まとめ

CohereのForward Deployed Engineer（Infrastructure Specialist）ポジションは、AI時代（じだい）で最もエキサイティングな役割の一つです。単にコードを書くのではなく、世界最高水準（さいこうすいじゅん）のAI技術を企業現場に直接届（とど）ける仕事（しごと）です。

このガイドで取り扱った内容をまとめると：

  • Cohereはエンタープライズ AIに集中する企業で、Northプラットフォームが核心プロダクト
  • FDEは顧客現場で直接デプロイするユニークな役割
  • KubernetesとHelmが技術的な核心で、エアギャップデプロイ経験が大きな差別化要素
  • 8ヶ月の体系的（たいけいてき）学習で必要な技術を身（み）につけることが可能
  • 顧客対応能力が技術と同じくらい重要

このロードマップに沿って体系的に準備すれば、Forward Deployed Engineerとしてのキャリアを開始するための確実（かくじつ）な基盤（きばん）になるでしょう。AIインフラ分野は急速（きゅうそく）に成長しており、この能力を備えたエンジニアへの需要（じゅよう）は今後（こんご）も増（ふ）え続（つづ）けるでしょう。

頑張（がんば）ってください！

Discuss on Twitter • View on GitHub