> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# トラブルシューティング

> Vantage 3.0 セルフホスト型の オペレーター、ArgoCD、シークレット、データベース、ingress、mesh、オートスケーリングの問題を診断します。

このページでは、インストール時および導入後の運用でよく発生する問題を、それぞれの診断コマンドと対処方法とともにまとめています。各項目は **症状 → 診断 → 修正** の構成になっています。

行き詰まった場合は、ABBYY の担当チームに連絡する前に、オペレーター のログ、`Vantage` リソースのステータス、および問題が発生している ArgoCD アプリケーションのステータスを取得してください。

```bash theme={null}
# オペレーターのログ（オペレーターのpodを特定してログを読み取る）
kubectl -n $operator_namespace get pods
kubectl -n $operator_namespace logs $operator_pod_name --tail=500

# Vantageリソース（ステータスのconditionおよびdegradationReasons）
kubectl -n $install_namespace get vantages.vantage.abbyy.com $release_name -o yaml

# オペレーターが管理するArgoCDアプリケーション
argocd app list -l vantage.abbyy.com/managed-by=vantage-operator
```

<div id="operator-and-crd">
  ## オペレーター および CRD
</div>

<div id="force-a-retry-after-fixing-an-out-of-resource-issue">
  ### リソース不足の問題を解消した後で再試行を強制する
</div>

**症状。** 障害の根本原因 (不足していた Key Vault シークレットの追加、RBAC の付与、データベースの修復) は解消したものの、オペレーター がまだリコンシルしていません。

**診断。** オペレーター は `Vantage` リソース自体のイベントに応答します。そのため、リソース外での状態変更 (Key Vault の権限、ネットワークポリシー、外部サービス) はリコンシルのトリガーになりません。`Vantage` リソースは変更可能ですが、Vantage のインストールを再試行するには、リソースに `vantage.abbyy.com/reprocess` (任意の値) というアノテーションを付与する必要があります。

**対処法。** `Vantage` リソースに `vantage.abbyy.com/reprocess` (任意の値) というアノテーションを付与し、プレフライト フェーズからリコンシルを強制的にやり直します。

```bash theme={null}
kubectl -n $install_namespace annotate vantages.vantage.abbyy.com/$release_name \
  vantage.abbyy.com/reprocess="$(date +%s)" --overwrite
```

再試行するたびに、annotation の値 (タイムスタンプなど) を更新してください。オペレーター が再度リコンシルを実行するのは、annotation の値が変更された場合のみです。

<div id="vantage-resource-stuck-in-progressing">
  ### `Vantage` リソースが `Progressing` のまま止まる
</div>

**症状。** `kubectl describe vantages.vantage.abbyy.com $release_name -n $install_namespace` を実行すると、`Progressing=True` が長時間表示されたままで、`Ready` が `True` になりません。

**診断。** リソースの `status.degradationReasons[]` を確認してください。問題が発生している component はそこに オペレーター によって表示されます。次に、対応する ArgoCD アプリケーションを確認します:

```bash theme={null}
kubectl -n $install_namespace get vantages.vantage.abbyy.com $release_name \
  -o jsonpath='{.status.degradationReasons}' | jq .
```

**対処方法。** ArgoCD の同期エラーの根本原因を解消してください。よくある原因としては、依存先の Helm チャートがクラスターにまだ存在しない値を必要としている (Key Vault シークレットがない、[イメージの取得に失敗している](#pods-stuck-in-imagepullbackoff)) 場合や、ingress gateway が存在しない場合があります。根本原因を解消したら、インストールを再試行するために `Vantage` リソースに `vantage.abbyy.com/reprocess` のアノテーションを追加してください ([再試行を強制する](#force-a-retry-after-fixing-an-out-of-resource-issue)) 。

<div id="operator-never-picks-up-a-new-vantage-resource">
  ### オペレーター が新しい `Vantage` リソースを検知しない
</div>

**症状。** `Vantage` リソースを適用し、`kubectl get vantages` では表示されるものの、オペレーター がステータスをまったく報告しません。

**診断。** オペレーター が実行中で、リコンサイルを行っていることを確認してください。

```bash theme={null}
kubectl -n $operator_namespace get pods
kubectl -n $operator_namespace logs $operator_pod_name | grep -i 'watching\|reconcile'
```

**修正方法。** オペレーターはクラスター全体で `Vantage` リソースを監視します。チャートには、監視対象の名前空間を制限するための値は用意されていません。オペレーターが実行中なのに、ログに対象リソースに対するリコンシルの試行がまったく表示されない場合は、CRD がオペレーターの想定するバージョン (`vantage.abbyy.com/v1alpha1`) になっていること、およびクラスター内にオペレーターのインスタンスが 1 つだけインストールされていることを確認してください。チャートが実際に受け付ける値を確認するには、`helm show values $charts_uri/vantage-operator --version $operator_version` を実行してください ([Helm チャートの値](/ja/vantage/self-hosted/v3.0/helm-chart#inspecting-available-values)) 。

<div id="crd-apply-fails-with-validation-error">
  ### CRD の適用がバリデーションエラーで失敗する
</div>

**Symptom.** `kubectl apply` により、`Vantage` リソースが CEL のバリデーションメッセージ付きで拒否されます。

**Diagnosis.** このエラーメッセージは、CRD の CEL ルールによるものです。よくある原因として、`enabled: true` なのに `destination` がない `ociMigration` ブロックや、`keepPreviousVersion: true` なのに `previousVersion` がない `techcore` ブロックがあります。

**Fix.** バリデーションメッセージで指定されている field を設定してください。完全なバリデーションルールについては、[API リファレンス](/ja/vantage/self-hosted/v3.0/api-reference#vantagespec)を参照してください。

<div id="oci-migration">
  ## OCI 移行
</div>

<div id="oci-migration-job-never-starts">
  ### OCI 移行ジョブが開始されない
</div>

**症状。** `Vantage` リソースが `Progressing` のままで、インストール先の名前空間に `$release_name-oci-migration` という名前のジョブが存在しません。

**診断。** operator のログで operator のプレフライトチェックを確認し、あわせてリソースが劣化状態になっている理由を確認してください。ジョブが作成されるのは、プレフライトチェックに合格した後だけです。

**対処法。** 失敗しているプレフライトチェックを解消してください。プレフライトチェックでは、シークレットの設定を含む構成が検証されるため、まずはシークレットプロバイダーにすべての必須エイリアスが存在することを確認してください ([Secrets and Key Vault](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault#secret-aliases)) 。

<div id="oci-migration-job-runs-but-fails">
  ### OCI 移行ジョブは実行されるものの失敗する
</div>

**症状。** `kubectl -n $install_namespace get jobs` を実行すると移行ジョブは表示されますが、`Complete` 状態になりません。

**診断。** ジョブのログを確認します。

```bash theme={null}
kubectl -n $install_namespace logs job/$release_name-oci-migration --tail=200
```

**対処法。** 失敗の大半は認証関連です。つまり、ジョブがソース レジストリから pull できなかった (各 `vantage.ociMigration.sources[]` エントリの `credentialsRef.name` シークレットまたは Username/password を確認してください) か、宛先に push できなかった (`vantage.ociMigration.destination` の認証情報と、Azure Workload Identity を使用している場合は workload identity の RBAC を確認してください) かのいずれかです。ジョブの pod 自体がそのイメージをまったく pull できない場合は、[`ImagePullBackOff` で停止した pod](#pods-stuck-in-imagepullbackoff)を参照してください。

<div id="image-pulls">
  ## イメージの取得
</div>

<div id="pods-stuck-in-imagepullbackoff">
  ### pod が `ImagePullBackOff` のままになる
</div>

**症状。** オペレーター の pod、OCI 移行ジョブの pod、または Vantage のワークロード pod で `ImagePullBackOff` または `ErrImagePull` が報告され、`kubectl describe pod` に registry からの `unauthorized: authentication required` が表示されます。

**診断。** 問題のある pod と registry エラーを確認します。

```bash theme={null}
kubectl -n $operator_namespace get pods | grep -Ei 'imagepull|errimage'
kubectl -n $install_namespace get pods | grep -Ei 'imagepull|errimage'
kubectl -n $install_namespace describe pod $pod_name
kubectl -n $install_namespace get pod $pod_name -o jsonpath='{.spec.serviceAccountName}{"\n"}'
```

**対処法。** 問題が発生しているコンポーネントに、レジストリへのプルアクセスを付与します。

* **オペレーター pod**: `--set "manager.imagePullSecrets[0].name=my-pull-secret"` を指定して、`vantage-operator` リリースをアップグレードします。
* **OCI 移行ジョブ**: プルシークレットを持つ ServiceAccount でジョブを実行するか (`vantage.ociMigration.serviceAccountName=my-service-account`) 、ソースエントリでシークレットを参照します (`vantage.ociMigration.sources[0].credentialsRef.name=my-pull-secret`) 。
* **Vantage ワークロード**: `vantage.serviceAccountName` で指定された ServiceAccount の `imagePullSecrets` にプルシークレットを追加します。問題が発生している pod が `default` を含む別の ServiceAccount を使用していると報告している場合は、その ServiceAccount にプルアクセスを付与するか、意図した Vantage ServiceAccount を使用するようコンポーネントを設定します。
* **AKS の場合**: プルシークレットの代わりに、クラスターの kubelet ID にそのレジストリの `AcrPull` を付与します。

設定全体については、[Azure image pull access](/ja/vantage/self-hosted/v3.0/providers/azure#image-pull-access) または [self-managed registry access](/ja/vantage/self-hosted/v3.0/providers/self-managed#configure-registry-access) を参照してください。

<div id="secrets">
  ## Secrets
</div>

<div id="pods-fail-to-start-with-mountvolumesetup-failed-for-volume-secrets-store">
  ### pod が `MountVolume.SetUp failed for volume "secrets-store"` エラーで起動しない
</div>

**症状。** Vantage の pod が起動せず、pod のイベントに CSI driver のマウント失敗が表示されます。

**診断。** Secrets Store CSI driver が Key Vault からシークレットを取得できませんでした。主な原因は次のとおりです。

```bash theme={null}
kubectl -n $install_namespace describe pod <pod-name>
```

* `vantage.secrets.azure.identityMode` で選択された ID に、指定されたシークレットまたは証明書への読み取りアクセス権がありません。
* Key Vault オブジェクト名が Vantage で想定されるエイリアスと一致しておらず、`objects` マッピングも指定されていません。
* CSI ドライバー用の Azure プロバイダーがインストールされていません。

**対処方法。** 設定されている ID に、[Secrets and Key Vault](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault#secret-aliases) に記載されたすべてのエイリアスに対する `get` 権限があることを確認してください。Key Vault オブジェクト名がエイリアスと異なる場合は、`vantage.secrets.azure` の下で `objects` マッピングを指定してください。各モードでどの ID が使用されるかについては、[Identity modes](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault#identity-modes) を参照してください。

<div id="paired-tls-secrets-are-missing">
  ### 対となる TLS シークレットが不足しています
</div>

**症状。** Auth サービスが起動せず、4 つある TLS シークレットのエイリアスのうち 1 つが Key Vault に存在しません。

**診断。** Vantage では、PEM エンコードされた 4 つの項目を Key Vault シークレットとして保存する必要があります。具体的には、auth 署名用の証明書と秘密鍵、そして無効化された auth トークン用の証明書と秘密鍵です。

**対処法。** 4 つのエイリアス `authSigningTlsCrt`、`authSigningTlsKey`、`authDeactivatedTlsCrt`、`authDeactivatedTlsKey` がすべて存在することを確認してください。[シークレットと Key Vault → 証明書エイリアス](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault#certificate-aliases)を参照してください。

<div id="kubernetes-secret-provider-fails-preflight">
  ### Kubernetes Secret provider の プレフライト が失敗する
</div>

**症状。** セルフマネージド インストールが プレフライト 中に、Secret が見つからない、キーが見つからない、または `forbidden` エラーで失敗します。

**診断。** オペレーターは プレフライト 中に `$install_namespace` 内のネイティブ Secret を読み取ります。指定された Secret が存在しない、`objects` のマッピングが誤った名前を指している、Secret に想定されるデータキーが含まれていない、またはチャートによって作成された RoleBinding で、インストールされたオペレーターの ServiceAccount が正しく指定されていない可能性があります。

影響を受ける Secret のいずれかに対するオペレーターの権限を確認してください:

```bash theme={null}
kubectl auth can-i get secret/$secret_name \
  --as=system:serviceaccount:$operator_namespace:$operator_service_account \
  --namespace $install_namespace
```

**修正。** インストール先の名前空間にすべての Secret が存在することを確認し、次に `vantage.secrets.kubernetes.objects` を [シークレットエイリアス一覧](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault#secret-aliases) と照合します。認可に失敗する場合は、Vantage チャートの `operator.namespace` と `operator.controllerManagerServiceAccount` の値が、インストールされているオペレーターを指していることを確認してください。外部シークレットコントローラーが Secrets を作成している場合は、新たにオペレーターのリコンシルを強制する前に、同期が正常に完了したと報告されるまで待機してください。

<div id="databases">
  ## データベース
</div>

<div id="postgresql-workloads-report-dataprovider-not-found">
  ### PostgreSQL ワークロードで `DataProvider` が見つからないと表示される
</div>

**症状。** データベースの起動時、またはマイグレーション pod で、`DataProvider '<value>' not found` エラーが発生して失敗します。

**診断。** `vantage.databaseProvider` では大文字と小文字が区別されます。PostgreSQL ランタイム プロバイダーの名前は、正確に `PostgreSQL` です。

**修正。** 次のように設定します。

```yaml theme={null}
vantage:
  databaseProvider: PostgreSQL
  reportingEnabled: false
```

`Postgresql` や `PostgreSql` のような値は、ランタイムでは無効です。修正した値を適用し、[強制的に再試行](#force-a-retry-after-fixing-an-out-of-resource-issue)してください。

<div id="postgresql-schema-is-not-up-to-date">
  ### PostgreSQL スキーマが最新の状態ではありません
</div>

**症状。** 複数のサービスが、`postgres database schema is not up to date` またはマイグレーションのバージョン競合により起動に失敗します。

**診断。** 複数のサービスが同じ論理 PostgreSQL データベースを使用しています。各サービスはそれぞれ独自のマイグレーション履歴を保持するため、個別のデータベースを使用する必要があります。

**対処方法。** データベースエイリアスごとに個別のデータベースを作成してください。汎用の `Database__ConnectionString` キーを使用するワークロードでは、個別の Kubernetes Secrets を作成し、`vantage.secrets.kubernetes.objects` を使用して各エイリアスをマッピングしてください。詳細は [PostgreSQL とサービスごとの Secrets](/ja/vantage/self-hosted/v3.0/secrets-and-keyvault#postgresql-and-per-service-secrets) を参照してください。

<div id="argocd">
  ## ArgoCD
</div>

<div id="argocd-application-shows-outofsync-after-install">
  ### インストール後、ArgoCD application が `OutOfSync` と表示される
</div>

**症状。** `kubectl get application -A` を実行すると、オペレーター はそれ以外では `Ready` を報告しているにもかかわらず、オペレーター が管理する application の 1 つが `OutOfSync` と表示されます。

**診断。** application の `status.conditions[]` を確認します。

```bash theme={null}
argocd app get <app-name>
```

**対処法。** ドリフトの原因がオペレーター管理のオブジェクトに対する手動編集である場合は、それらを元に戻してください。これらのオブジェクトはオペレーターの管理下にあり、再同期されます。ドリフトがチャートの値にある場合は、`Vantage` リソース (または `vantage-selfhosted` Helm リリース) を通じて更新してください。基盤となる ArgoCD `Application` オブジェクトを直接編集しないでください。

<div id="argocd-applicationset-sync-stuck">
  ### ArgoCD ApplicationSet の同期が止まる
</div>

**症状。** ArgoCD アプリケーションが同期ウェーブを先に進みません。

**診断。** ArgoCD のインストールで ApplicationSet Progressive Syncs が有効になっていることを確認してください。

```bash theme={null}
kubectl -n $argocd_namespace get configmap argocd-cmd-params-cm -o yaml | grep -i progressive
```

**修正。** [ArgoCD のドキュメント](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Progressive-Syncs/#enabling-progressive-syncs)に従って Progressive Syncs を有効にし、ApplicationSet コントローラーを再起動します。

<div id="keda-and-prometheus">
  ## KEDA と Prometheus
</div>

<div id="scaledobject-resources-cannot-create-hpas">
  ### `ScaledObject` リソースでは HPA を作成できません
</div>

**症状。** KEDA が `Ready=False` または `ScaledObjectCheckFailed` を報告し、ArgoCD では影響を受けるワークロードアプリケーションが Degraded と表示されます。

**診断。** インストールされている KEDA のバージョンと、`ScaledObject` のイベントを確認します。

```bash theme={null}
kubectl get deployment --all-namespaces | grep keda-operator
kubectl -n $install_namespace describe scaledobject <scaledobject-name>
```

現在の Vantage ワークロード チャートでは、KEDA 2.17.x が必要です。KEDA 2.18 以降では、これらのチャートで使用している scaler field が削除されています。

**対処法。** KEDA 2.17.3 をインストールしてから、影響を受ける ArgoCD アプリケーションを再同期します。

<div id="hpa-metrics-show-unknown">
  ### HPAのメトリクスに `<unknown>` が表示される
</div>

**症状。** KEDA リソースは存在しますが、`kubectl get hpa` で Vantage のメトリクスが `<unknown>` と表示され、ワークロードが想定どおりにスケールしません。

**診断。** `ScaledObject` リソースは `http://prometheus-operated.observability.svc.cluster.local:9090` にクエリを実行します。Service が存在しない、Vantage の `ServiceMonitor` が選択されていない、またはサービスメッシュによってスクレイプがブロックされている可能性があります。

**修正。** Prometheus Service が存在すること、Vantage のターゲットが `UP` であること、および `observability` チャートの値がトップレベルにあることを確認してください。

```bash theme={null}
kubectl -n observability get service prometheus-operated
kubectl -n $install_namespace get servicemonitor
```

トリガーの動作と検証については [KEDA を使用したオートスケーリング](/ja/vantage/self-hosted/v3.0/performance/autoscaling) を、Istio と Linkerd の構成については [Prometheus を使用した監視](/ja/vantage/self-hosted/v3.0/monitoring/prometheus) を参照してください。

<div id="skill-installation">
  ## Skillのインストール
</div>

<div id="skills-are-missing-after-the-install-reports-ready">
  ### インストール後に `Ready` と表示されても Skill が表示されない
</div>

**症状。** `Vantage` リソースは `Ready` と表示され、Vantage にアクセスできるにもかかわらず、想定していた Skill が表示されず、ArgoCD にも Skill 関連の項目が何も表示されません。

**診断。** Skill は、ArgoCD では表示されない別個の Kubernetes job によってインストールされるため、`argocd app list` には表示されません (このページ上部の診断用抽出結果にも含まれません) 。その job は `Ready` になった後も引き続き実行中の場合がありますが、その間も Vantage は使用できます。job を確認してください:

```bash theme={null}
kubectl -n $install_namespace wait --for=create job/$install_namespace-skill-installer-job
kubectl -n $install_namespace wait --for=condition=Complete job/$install_namespace-skill-installer-job
kubectl -n $install_namespace logs job/$install_namespace-skill-installer-job --tail=200
```

**修正。** ジョブがまだ実行中の場合は、`Complete` に達するまで待機してください。ジョブが失敗した場合は、根本的なエラーを特定して解決するために、そのログを確認してください。失敗が続く場合は、ジョブのログをオペレーターのログとあわせて ABBYYアカウントチームに提供してください。

<div id="service-mesh-and-ingress">
  ## サービスメッシュと Ingress
</div>

<div id="503-from-the-ingress-application-traffic-blocked">
  ### ingress から `503` が返され、アプリケーションのトラフィックがブロックされる
</div>

**症状。** pod は `Ready` を報告しているにもかかわらず、`https://$your_vantage_hostname` から `503` が返されます。

**診断。** AKS で組み込みの Istio ingress を使用している場合、外部ゲートウェイが正常でない可能性や、TLS シークレットが `ingress.tls.secretName` と一致していない可能性があります。顧客管理の ingress を使用している場合、コントローラーに一致するルートがない、バックエンドのサービス名またはポートが誤っている、または TLS 証明書の準備が完了していない可能性があります。

**対処法。** Istio の場合は、ゲートウェイと TLS シークレットを確認します。

```bash theme={null}
kubectl get gateway -A
kubectl -n <istio-system-or-equivalent> get pods | grep gateway
```

チャートに指定した名前の `kubernetes.io/tls` 型のシークレットが外部ゲートウェイの名前空間に存在し、その証明書が `dnsRecord` に対して有効であることを確認します。

顧客側で管理する ingress の場合は、コントローラーのログとルートのステータスを確認します。ルートのホスト名が `vantage.dnsRecord` と一致し、TLS が使用可能な状態であり、各バックエンド Service が `$install_namespace` に存在することを確認します。[ingress と TLS を Configure する](/ja/vantage/self-hosted/v3.0/providers/self-managed#configure-ingress-and-tls)を参照してください。

<div id="sign-in-redirects-or-oidc-metadata-use-http">
  ### サインインのリダイレクトまたは OIDC メタデータで `http://` が使用される
</div>

**症状。** Vantage は HTTPS で提供されているにもかかわらず、platform-administrator のサインインが失敗する、または `/auth2/.well-known/openid-configuration` で `http://` の issuer やエンドポイントが通知されます。

**診断。** TLS は ingress コントローラーで終端されていますが、認証ワークロードが転送された HTTPS スキームを正しく認識していません。

**修正。** ingress が `X-Forwarded-Proto: https` を送信していること、および `auth-identity`、`auth-adminapi2`、`api-gateway`、`api-registry` のアプリケーション コンテナーに次が設定されていることを確認してください。

```text theme={null}
ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
```

お使いのワークロードチャートでこの環境設定を公開していない場合は、影響を受けるpodを再起動する前に、承認済みのadmission mutationを適用してください。[Forwarded HTTPS スキーム](/ja/vantage/self-hosted/v3.0/providers/self-managed#forwarded-https-scheme)を参照してください。

<div id="prometheus-scrape-targets-show-as-down-for-metrics-text">
  ### `/metrics-text` の Prometheus スクレイプターゲットが `DOWN` と表示される
</div>

**症状。** メッシュ内の Prometheus で、Vantage アプリケーションのターゲットが `DOWN` と表示されます。

**診断。** Istio では、Prometheus pod にサイドカーがないか、Istio の出力証明書が `/etc/prom-certs/` に書き込まれていない可能性があります。Linkerd では、厳格な認可ポリシーによって、メッシュに参加していない Prometheus からの平文のスクレイプがブロックされる場合があります。

```bash theme={null}
kubectl -n observability get pods -o jsonpath='{.items[*].spec.containers[*].name}'
```

**対処方法。** Istio では、Prometheus pod に 3 つのコンテナー (`prometheus`、`config-reloader`、`istio-proxy`) が含まれており、`OUTPUT_CERTS: /etc/istio-output-certs` を含む `proxy.istio.io/config` アノテーションが存在することを確認してください。Linkerd では、`observability` 名前空間へのインジェクションを有効にするか、お使いのポリシーで必要なクライアント証明書を使用するように `ServiceMonitor` と Prometheus を設定してください。[Prometheus を使用した Monitoring](/ja/vantage/self-hosted/v3.0/monitoring/prometheus)。

<div id="day-2-operations">
  ## Day-2 の運用
</div>

<div id="after-upgrade-the-operator-reports-the-new-version-but-vantage-is-still-on-the-old-one">
  ### アップグレード後、オペレーター では新しいバージョンが報告されるのに、Vantage はまだ古いバージョンのままです
</div>

**Symptom.** Helm releases をアップグレードしても、`status.installedVantageVersion` が変わりません。

**Diagnosis.** `vantage-operator` と `vantage-selfhosted` の releases が同じ新しいバージョンになっていないか、ArgoCD がまだコンポーネントごとの変更を適用中である可能性があります。両方の Helm releases と、ArgoCD application の同期ステータスを確認してください。

**Fix.** 両方の charts を同じバージョンにアップグレードしてから、ArgoCD applications の同期が完了するまで待ちます。オペレーター に `Degraded` condition が表示されている場合は、その reason をたどって障害が発生している component を特定し、問題を解決してから、再試行するために `Vantage` resource に `vantage.abbyy.com/reprocess` の annotation を追加します ([再試行を強制する](#force-a-retry-after-fixing-an-out-of-resource-issue)) 。[Upgrading](/ja/vantage/self-hosted/v3.0/upgrading) を参照してください。

<div id="whats-next">
  ## 次のステップ
</div>

<CardGroup cols={2}>
  <Card title="アーキテクチャ" icon="diagram-project" href="/ja/vantage/self-hosted/v3.0/architecture">
    診断時に役立つ、リコンシルのたびにオペレーターが行う処理の説明。
  </Card>

  <Card title="既知の制限事項" icon="triangle-exclamation" href="/ja/vantage/self-hosted/v3.0/known-limitations">
    実際にバグかどうかの判断材料となる、現在の制約事項。
  </Card>
</CardGroup>