> For the complete documentation index, see [llms.txt](https://docs.keeper.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.keeper.io/keeperpam/jp/secrets-manager/integrations/jira-workflow.md).

# Jira Workflow

<figure><img src="https://859776093-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FPL6k1aGsLiFiiJ3Y7zCl%2Fuploads%2FAjElfQTd1l1eVAdwf3cx%2Fimage.png?alt=media&#x26;token=28e3b004-188f-46f4-9449-c740df5c760d" alt=""><figcaption></figcaption></figure>

## 概要

Keeper Security for Jiraは、Atlassian Forge上で動作するアプリケーションであり、JiraチケットからKeeperボルトの操作を直接管理できるようにします。本連携により、プロジェクト管理ワークフローとシークレット管理を統合し、Jira環境を離れることなく、認証情報のリクエスト、承認、実行を行えます。

また、本Jira連携では、コンパニオンITSMアプリが作成したチケットを通じて、エンドポイント特権マネージャー (KEPM) の承認およびSSOデバイス管理承認を管理できます。ボルトはNSF (階層型共有サブフォルダ) モードとClassicモードの両方に対応しています。すべての操作は、タイムスタンプおよび実行ユーザー情報付きでJiraのコメントとして記録されます。

## レコード管理機能

<table><thead><tr><th width="238.94921875">機能</th><th>説明</th></tr></thead><tbody><tr><td>新規レコード作成</td><td>認証情報、セキュアノート、支払いカード、カスタムレコードタイプを追加</td></tr><tr><td>レコード更新</td><td>既存のボルトレコードの情報を更新</td></tr><tr><td>レコード共有</td><td>チームおよびユーザーに対するフォルダ単位のアクセス管理</td></tr><tr><td>権限管理</td><td>共有フォルダ内のレコードに対する詳細なアクセス権を制御</td></tr><tr><td>共有フォルダ管理</td><td>チームおよびユーザーに対するフォルダ単位のアクセス管理</td></tr></tbody></table>

ボルトはデフォルトで**NSF**モードです。**\[従来の権限モデルを使用する]** にチェックを入れるとClassicモードに切り替わります。レコードとフォルダのピッカードロップダウンにはNSF/Classicバッジが表示されます。NSFモードではロールベースの権限を、Classicモードでは個別の権限チェックボックスを使用します。ロール一覧とフラグの詳細は、[ボルトモードと権限モデル](#vault-modes-and-permission-models)をご参照ください。

## エンドポイント特権管理機能

<table><thead><tr><th width="294.27734375">機能</th><th>説明</th></tr></thead><tbody><tr><td>リアルタイム承認ワークフロー</td><td>エンドポイントからの特権昇格リクエストを確認し、承認または拒否</td></tr><tr><td>リクエストのリアルタイム監視</td><td>保留中のリクエストをカウントダウンタイマーおよび詳細情報とともに表示</td></tr><tr><td>ワンクリック操作</td><td>監査証跡を保持したまま、即時に承認または拒否</td></tr><tr><td>リクエスト詳細情報</td><td>ユーザー情報、アプリケーション、申請理由、有効期限の状態を表示</td></tr></tbody></table>

## 要件

Keeperの厳格なゼロ知識暗号化モデルを維持するため、本Jira連携では、お客様環境のVM上でコマンダーサービスモードのコンテナをホストし、Jira Cloud上でカスタマイズされたForgeアプリをホストする必要があります。

<table><thead><tr><th width="318.1171875">要件</th><th>説明</th></tr></thead><tbody><tr><td>Keeperコマンダーサービスモード</td><td>REST APIアクセスが可能なコマンダーサービスモードを実行するサービスアカウント。リクエストのルーティングには<strong>Ngrok</strong>または<strong>Cloudflare Tunnel</strong>を使用。</td></tr><tr><td>Jira Cloud管理者アクセス</td><td><p>Forgeアプリのインストールおよび設定には、<strong>Jira管理者</strong>または<strong>Manage Apps</strong> (アプリを管理) 権限が必要。</p><p><strong>Jira設定</strong> → <strong>アプリ</strong>から接続設定を実施。</p></td></tr><tr><td>Jiraエンドユーザーアクセス</td><td>Keeperパネルを表示および使用するには、<strong>Edit Issues</strong> (イシュー編集) および<strong>Add Comments</strong> (コメント追加) 権限が必要。すべてのJira Cloudプロジェクトタイプで動作し、追加設定は不要。詳細については<a href="https://support.atlassian.com/jira-cloud-administration/docs/manage-project-permissions/">こちらのAtlassianのウェブサイト</a>をご参照ください。</td></tr><tr><td>Keeper標準機能</td><td><p>ボルトアクセスを含む<a href="https://keepersecurity.com/">Keeperビジネス、エンタープライズ、PAM</a>のいずれかのサブスクリプションが必要。</p><p>レコードの作成、更新、共有が可能なサービスアカウント権限が必要。</p></td></tr><tr><td>エンドポイント特権マネージャー機能</td><td><ul><li>有効なKeeperPAMサブスクリプションが必要。</li><li>Keeper環境でKEPMモジュールが有効化および設定済みであること。</li><li>KEPMのデプロイメント、エージェント、ポリシーが構成済みであること。</li><li>詳細については、<a href="/pages/E0meS23gWQShu5HMEtDC">エンドポイント特権マネージャーの概要ページ</a>をご参照ください。</li></ul></td></tr><tr><td>Keeper Security ITSMアプリ</td><td>EPMおよびSSOデバイス管理承認ワークフローに必要です。ITSMアプリがWebhook処理とJiraチケット作成を担当し、Connector Hubが検出する `ITSM_` ラベルを付与します。</td></tr></tbody></table>

## セットアップおよび構成

JiraサービスとKeeper間で通信を行うには、お客様側でNgrokまたはCloudflare Tunnelを使用したKeeperコマンダーサービスモードのインスタンスをホストする必要があります。構成方法はIT要件に応じて異なります。

コマンダーサービスモードは、任意のマシン上でフォアグラウンドサービスとして実行することも、ローカルまたはリモートサーバー上でDockerコンテナとして実行することも可能です。

### 手順1. コマンダーのセットアップ

Keeperコマンダーをインストールし、サービスを起動するには、[コマンダーサービスモードREST API](https://github.com/Keeper-Security/gitbook-jp-secrets-manager/tree/main/commander-cli/service-mode-rest-api.md)のページに記載のセットアップ手順に従ってください。Forgeアプリからコマンダーインスタンスへリクエストを正しくルーティングするため、NgrokまたはCloudflare Tunnelを使用した設定手順を必ず実施してください。コマンダーサービスモードは、CLI上で直接実行することも、ローカルマシンでバックグラウンド実行することも、リモートサーバー上でサービスとして実行することも、Dockerコンテナで実行することも可能です。Dockerの使用を推奨します。

#### 重要事項

以下の点を必ず確認してください。

1. リクエストキューシステム (API v2) を有効にする必要があります (例: `-q=y`)
2. ボルト管理機能を使用する場合は、次のコマンドが許可リストに含まれていることを確認します。

```
record-add,list,ls,get,record-type-info,record-update,share-record,share-folder,rti,record-permission,service-status
```

3. ボルト + SSOデバイス承認 + KEPM機能を使用する場合は、以下のコマンドが許可リストに含まれていることを確認します。

```
record-add,list,list-sf,ls,get,search,record-type-info,record-update,share-record,share-folder,rti,record-permission,nsf-list,nsf-get,nsf-record-add,nsf-record-update,nsf-share-record,nsf-share-folder,nsf-record-permission,epm,device-approve,service-status
```

コマンドに関する注意:

* **list-sf:** Rotate-on-Expirationフォルダの適格性チェックに必要
* **nsf-\*:** NSF (階層型共有サブフォルダ) モードに必要。従来型のみのデプロイメントでは省略可
* **epm:** KEPM承認パネルの操作およびステータス確認に必要
* **device-approve:** SSOデバイス管理承認の操作および保留中リクエストの確認に必要

4. Ngrokトンネリングを使用する場合は、次のパラメータを含めます。

```
-ng <ngrok-auth-token> -cd <custom-domain>
```

5. Cloudflareトンネリングを使用する場合は、次のパラメータを含めます。

```
-cf <cloudflare-tunnel-token> -cfd <cloudflare-custom-domain>
```

サービス作成後、APIキーがコンソール出力に表示されます。必ずコピーして安全に保管します。Dockerを使用している場合は、次のコマンドでログからAPIキーを取得します。

```
docker compose logs | grep -i "generated api key"
```

コマンダーサービスが正常に起動していれば、エンドポイントに対して以下のようにcurlリクエストを送信できます。

```bash
curl -X POST 'https://mytunnel.company.com:8080/api/v2/executecommand-async' \
--header 'Content-Type: application/json' \
--header 'api-key: <your-api-key>' \
--data '{"command": "ls"}'
```

トンネルが稼働しており、APIキーが正しければ、次のようなレスポンスが返されます。

```json
{
    "success": true,
    "request_id": "550e8400-e29b-41d4-a716-446655440000",
    "status": "queued",
    "message": "Request queued successfully..."
}
```

サービスが正常に稼働していることを確認したら、Jiraの設定手順に進みます。

***

### 手順2. Keeper Forgeアプリのインストール

連携設定を行う前に、Jira CloudインスタンスにKeeper Forgeアプリをインストールする必要があります。

詳細な手順については、[Forgeアプリのインストールについてのページ](/keeperpam/jp/secrets-manager/integrations/jira-workflow/forge-app-installation.md)をご参照ください。

***

### 手順3. Jiraの構成

Atlassian Jiraインスタンスで、管理者として連携の構成を行います。

* Jiraで **\[Apps]** (アプリ) → **Keeper**に移動します。
* **API URL** (/api/v2 パスを含む) および**APIキー**を入力します。
* URLの例
  * Ngrok: `https://your-subdomain.ngrok.io/api/v2`
  * Cloudflare: `https://your-subdomain.trycloudflare.com/api/v2`
* **\[Test Connection]** (接続をテスト) をクリックし、成功することを確認します。
* 設定を保存します。

<figure><img src="/files/Bss878vKlkVQVK8IUgyX" alt=""><figcaption></figcaption></figure>

Jira管理者の構成が完了しました。

***

### 手順4. EPMおよびデバイス承認のITSMチケット作成

EPMおよびSSOデバイス承認チケットは、コンパニオン**Keeper Security ITSM**アプリが作成します。Connector HubはEPM Webhookイベントの処理やEPMチケットの作成を行わなくなりました。ForgeアプリからEPM Webhook (ウェブトリガー) およびチケット作成フローは**削除**されています。

ITSMアプリによる承認フローを構成します。

1. 同じJiraインスタンスにKeeper Security ITSM連携をインストールおよび構成します。
2. ITSMアプリでWebhook URLと認証トークンを構成します。
3. **Keeper管理コンソール** > **\[レポートとアラート]** > **\[アラート]** で、以下のアラートを構成します。
   * **エージェントが承認リクエストを作成** (EPM)
   * **承認リクエストのステータスを変更** (EPM)
   * **デバイス管理承認がリクエストされました** (SSOデバイス承認)
4. これらのアラートの受信者として、ITSMアプリのWebhook URLとトークンを追加します。

<figure><img src="https://762006384-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MJXOXEifAmpyvNVL1to%2Fuploads%2FHgvR92oiSiRz2mSVvMN9%2FScreenshot%202026-02-07%20at%207.08.52%E2%80%AFPM.png?alt=media&#x26;token=93d5a37d-6747-4691-b291-65f6b78043a9" alt=""><figcaption><p>Keeper管理コンソールのWebhook構成</p></figcaption></figure>

5. ITSMアプリは、以下のラベル付きチケットを作成します。

* `ITSM_approval_request_created`: EPM特権昇格リクエスト
* `ITSM_device_admin_approval_requested`: SSOデバイス承認リクエスト

6. Connector Hubは、ITSMアプリが作成したチケット上のこれらのラベルを検出し、適切な管理パネルを表示します。

{% hint style="warning" %}
Connector Hub Forgeアプリでは、Web Trigger URL、EPM Webhook構成画面、EPMチケット作成フローは利用できなくなりました。以前Connector HubでEPM Webhookを直接構成していた場合は、Webhookおよびチケット作成をJira ITSMアプリへ移行してください。
{% endhint %}

***

### Jiraワークフローのユーザーガイド

* **Jiraプロジェクト (例: IT Support、Security Operations) に移動します。**
  * 新しいチケットを作成します。
* **Jira課題ページを開きます。**
  * 画面右側のパネルにある**Keeperパネル**を確認します。
  * パネルが読み込まれ、利用可能なKeeperアクションが表示されます。
  * アクションを選択します: **Request Access to Record** / **Request Access to Folder** / **Request Record Permission Change**。
  * フォームに必要事項を入力します (必須項目には \* が付いています)。
* **ボルトモード**
  * パネルはデフォルトで**NSF**モードです。**\[従来の権限モデルを使用する]** にチェックを入れるとClassicモードに切り替わります。NSFでは**ロール**ドロップダウン、従来型では権限の**チェックボックス**を使用します。詳細は[ボルトモードと権限モデル](#vault-modes-and-permission-models)をご参照ください。
* **承認のため送信します。**
  * 初回送信時は、**\[Save Request]** をクリックして管理者承認へ送信します。
  * 既存のリクエストを更新する場合は、**\[Update Request]** をクリックして保存済みのリクエストを修正します。
  * 送信後、「**Request submitted successfully**」または「**Request updated successfully**」という確認メッセージが表示されます。

<table><thead><tr><th width="241.28125">アクション</th><th>使用する場面</th></tr></thead><tbody><tr><td><a href="https://github.com/Keeper-Security/gitbook-jp-secrets-manager/tree/main/commander-cli/command-reference/sharing-commands/README.md#share-record-command"><strong>Request Access to Record</strong></a></td><td>個別レコードへのアクセス付与または取り消し。期間限定アクセス、一時的なアクセス、チーム共有に利用。</td></tr><tr><td><a href="https://github.com/Keeper-Security/gitbook-jp-secrets-manager/tree/main/commander-cli/command-reference/sharing-commands/README.md#share-folder-command"><strong>Request Access to Folder</strong></a></td><td>ユーザーまたはチームに対するフォルダ単位のアクセスおよび権限の管理。一時的なプロジェクト対応や外部委託先へのアクセスに有効。</td></tr><tr><td><a href="https://github.com/Keeper-Security/gitbook-jp-secrets-manager/tree/main/commander-cli/command-reference/sharing-commands/README.md#record-permission-command"><strong>Request Record Permission Change</strong></a></td><td>共有フォルダ内のレコードに対する詳細なアクセス権の管理。最小権限の原則やコンプライアンス要件の徹底に使用。</td></tr><tr><td><a href="/pages/-McB8Ys3vRnDF6Uz7Bf1#record-add-and-record-update-commands"><strong>Create New Secret</strong></a><br><strong>(管理者のみ)</strong></td><td>Keeperボルトに新しいレコードを追加。新規ユーザーのオンボーディングや認証情報のプロビジョニングに最適。</td></tr><tr><td><a href="/pages/-McB8Ys3vRnDF6Uz7Bf1#record-add-and-record-update-commands"><strong>Update Record</strong></a><br><strong>(管理者のみ)</strong></td><td>パスワード、ユーザー名、URL、カスタムフィールドなど既存レコードの情報を更新。認証情報の更新やパスワードローテーションに使用。</td></tr><tr><td><a href="https://github.com/Keeper-Security/gitbook-jp-secrets-manager/tree/main/commander-cli/command-reference/endpoint-privilege-manager-commands/README.md#action"><strong>Endpoint Privilege Approval</strong></a><br><strong>(管理者のみ)</strong></td><td>エンドポイントからの特権昇格リクエストを確認し、承認または拒否。チケットはITSMアプリが `ITSM_approval_request_created` ラベル付きで作成します。</td></tr><tr><td><strong>Device Admin Approval</strong><br><strong>(管理者のみ)</strong></td><td>SSOログインデバイス承認リクエストを確認し、承認または拒否。チケットはITSMアプリが `ITSM_device_admin_approval_requested` ラベル付きで作成します。</td></tr></tbody></table>

### ボルトモードと権限モデル <a href="#vault-modes-and-permission-models" id="vault-modes-and-permission-models"></a>

共有および権限アクションは2つのボルトモードに対応しています。パネルはデフォルトで**NSF (階層型共有サブフォルダ)** モードです。**\[従来の権限モデルを使用する]** にチェックを入れると**従来型**モードに切り替わります。レコードとフォルダのピッカードロップダウンには**NSF**または**従来型**バッジが表示され、どちらのモデルが適用されるかを確認できます。2つのモードでは権限の表現方法が異なります。

* **NSFモード**では、権限のセットをまとめた**ロールe**ドロップダウンを使用します。
* **従来型モード** では、個別の権限**チェックボックス**を使用します。

**NSFロール**

| ロール               | ユーザーに付与される権限              |
| ----------------- | ------------------------- |
| **閲覧者**           | コンテンツおよび参加者の表示            |
| **共有管理者**         | 共有権限の管理、他ユーザーの招待、リクエストの承認 |
| **コンテンツ管理者**      | コンテンツの管理                  |
| **コンテンツおよび共有管理者** | コンテンツおよび共有権限の管理           |
| **全管理者**          | 編集、共有、所有権の管理              |

**ロールのルール:** アクションが**付与**の場合は**ロール**が必須です。**r取り消す**の場合、ロールは任意でフィルターとして機能します。フォルダの**削除**アクションおよびレコードの**所有者** (所有権移転) アクションではロールは無視されます。

**従来型権限:** 従来型モードでは、各アクションごとに個別の権限チェックボックスが表示されます。

* **レコードへのアクセスをリクエスト:** 共有許可、書き込み許可
* **フォルダへのアクセスをリクエスト:** レコードの管理、ユーザーの管理、レコードの共有、レコードの編集
* **フォルダ内のレコード権限を更新:** レコードの共有、レコードの編集、子フォルダにも適用

***

### レコードへのアクセスをリクエスト

**説明**: 特定のKeeperレコードに対する共有アクセスをリクエスト

**主な機能**

* メールアドレス指定でユーザーへのレコードアクセスを付与または取り消し
* レコード所有権の移管
* ボルトモードに応じた権限の設定
  * **NSF:** **ロール**を選択 (閲覧者、共有管理者、コンテンツ管理者、コンテンツおよび共有管理者、全管理者)。アクセス付与時は必須
  * **従来型:** **共有を許可**および/または**書き込みを許可**にチェック
* アクセス有効期限の設定 (特定の日時または期間指定)
* フォルダ内のすべてのレコードに対して権限を再帰的に適用
* NSFおよび従来型ボルトモードの両方に対応 ([ボルトモードと権限モデル](#vault-modes-and-permission-models)を参照)

<figure><img src="/files/EdqyYwkW3WVjJCybmSND" alt=""><figcaption><p>Request Access to Record</p></figcaption></figure>

### フォルダへのアクセスをリクエスト

**説明**: ユーザーまたはチームに対するKeeper共有フォルダへのアクセスをリクエスト

**主な機能**

* フォルダアクセスの付与または削除 (アクション: 付与 / 削除)
* 個別ユーザーまたはチームへの割り当て
* ボルトモードに応じたフォルダ権限の設定
  * **NSF:** **ロール**を選択 (閲覧者、共有管理者、コンテンツ管理者、コンテンツおよび共有管理者、全管理者)。アクセス付与時は必須
  * **従来型:** **レコードの管理**、**ユーザーの管理**、**レコードの共有**、**レコードの編集**のいずれかにチェック
* アクセス有効期限の設定
* NSFおよび従来型ボルトモードの両方に対応 ([ボルトモードと権限モデル](#vault-modes-and-permission-models)を参照)

<figure><img src="/files/pld9RENJMm7J1jtODEpy" alt=""><figcaption><p>Request Access to Folder</p></figcaption></figure>

### 新しいシークレットの作成

**説明**: Keeper内に新しいシークレットレコードを直接作成

**主な機能**

* 利用可能なレコードタイプ (ログイン情報、銀行口座、SSHキーなど) から選択
* レコードタイプに応じたフィールドを動的に入力
* シークレットをKeeperボルトに安全に保存
* NSFおよび従来型ボルトモードの両方に対応

{% hint style="info" %}
Jira管理者およびプロジェクト管理者のみ利用可能
{% endhint %}

<figure><img src="/files/xnjJ7L3Nfj0UvCAVKq3i" alt=""><figcaption><p>Create New Secret - Login type record</p></figcaption></figure>

### レコードの更新

**説明**: 既存のKeeperレコードを更新

{% hint style="info" %}
Jira管理者およびプロジェクト管理者のみ利用可能
{% endhint %}

**主な機能**

* ボルト内のレコードを検索して選択
* レコードフィールド (title、login、password、URL、notes など) を変更
* 警告を上書きして更新する強制更新オプション
* NSFおよび従来型ボルトモードの両方に対応

注: Keeperパネルを表示および使用するには、「Edit Issues」(イシュー編集) 権限が必要です。

<figure><img src="/files/sf07Gi9AMc6cpdapp2rP" alt=""><figcaption><p>Update Record</p></figcaption></figure>

### KEPM承認リクエストの管理

**説明**: Jira上でKeeperエンドポイント特権マネージャー (KEPM) のリクエストを確認し、承認または拒否

EPMチケットは、コンパニオンJira ITSMアプリが `ITSM_approval_request_created` ラベル付きで作成します。Connector Hubはこのラベルを検出してEPM承認パネルを表示します。ForgeアプリからEPM Webhook (ウェブトリガー) およびチケット作成フローは削除されています。

**主な機能**

* リクエスター情報、アプリケーション名、申請理由を含む保留中のリクエストを確認
* リクエストの自動失効までの残り時間を示すライブカウントダウンタイマー (30分間)
* 特権昇格またはコマンド実行を承認または拒否
* Jira外で既に処理済みのリクエストを自動検出

<figure><img src="/files/S6DHbzf4eM6YK7rII5Q7" alt=""><figcaption><p>KEPM承認リクエスト</p></figcaption></figure>

***

### デバイス管理承認リクエストの管理

**説明**: Jira上でSSOログインデバイス承認リクエストを確認し、承認または拒否

ユーザーが新しいデバイスでSSOログインすると、ITSMアプリが `ITSM_device_admin_approval_requested` ラベル付きのJiraチケットを作成します。Connector Hubはこのラベルを検出してデバイス承認パネルを表示します。

**主な機能**

* リクエスターのメールアドレス、デバイス名、マシン名、IPアドレス、クライアントバージョンを含む保留中のSSOデバイス承認リクエストを表示
* `device-approve --approve` / `--deny` コマンドでデバイス登録を承認または拒否
* Jira外で既に処理済みのリクエストを自動検出 (例: Keeper管理コンソール経由)
* デバイス承認は自動失効しません (EPMリクエストとは異なります)

<figure><img src="/files/356CQo6ZvUqqiI0wUqwm" alt=""><figcaption><p>SSOデバイス承認</p></figcaption></figure>

***

### 有効期限切れ時のローテーション (PAM自動ローテーション)

**説明**: 対象となるPAM認証情報では、期間限定の共有アクセスが失効した時点でパスワードを自動的にローテーションします。一時アクセスのために公開した認証情報が、許可期間の終了後も有効なまま残ることを防ぎます。

**表示条件**: **レコードへのアクセスを申請**または**フォルダへのアクセスを申請**で有効期限を設定し、対象がローテーション対象の場合、「有効期限後にパスワードをローテーションする」チェックボックスが表示されます。有効にすると、リクエストに `--rotate-on-expiration` フラグが追加されます。

**対象条件**:

* **レコード:** 選択したレコードが `pamUser` タイプであること
* **フォルダ:** 選択した共有フォルダがROE対象 (ローテーション対象のPAMレコードを含む) であること。パネルは `list-sf <uid> --roe-eligible` でこれを検証するため、`service-create` で `list-sf` コマンドを有効にする必要があります

PAMレコード以外、対象外のフォルダ、有効期限未設定の場合は、チェックボックスは自動的に非表示になります。

**主な機能**

* 共有アクセス失効時にPAMパスワードを自動ローテーション (手動対応は不要)
* 日時指定 (Expire At) および期間指定 (Expire In) の両方の有効期限設定に対応
* NSFおよび従来型ボルトモードの両方に対応
* Jiraチケットに記録: アクションコメントに *"Password will auto-rotate upon expiration"* と記載

{% hint style="info" %}
Rotate on Expirationは、有効期限付きの共有でのみ利用できます。Expire At または Expire In を設定せずに有効にした場合、リクエストは *"Expiration is required when rotate-on-expiration is enabled."* というメッセージで拒否されます。
{% endhint %}

{% hint style="info" icon="triangle-exclamation" %}
対象は、ローテーションが有効化され、必要な設定が完了しているPAM Userレコードである必要があります。ローテーションが未設定の場合、構成エラーによりリクエストは失敗します。以下を確認してください。

* レコードが `pamUser` タイプであることを確認
* 当該レコードでローテーションが有効であることを確認 (`pam rotation edit`)
* Keeperゲートウェイがアクティブで接続されていることを確認
  {% endhint %}

<figure><img src="/files/zBFh6LpX9t9cFs04ZVlI" alt=""><figcaption></figcaption></figure>

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

#### デバッグモード

コマンダーサービスモードREST APIが想定どおりに動作しない場合は、以下のようにデバッグモードを有効にして詳細ログを取得します。

```bash
keeper service-create -p=9009 -c="list,get,record-add" -rm=foreground -q=y --debug
```

Dockerの場合

```bash
docker run -d -p 9009:9009 keeper-commander service-create -p 9009 -c "list,get,record-add" -rm foreground -q y --debug
```

デバッグモード有効時の動作

* コンソールまたはDockerログに詳細なリクエスト/レスポンスのトレースを表示
* 構成ミスやAPI通信の問題特定に有効
* 機密情報を含む可能性があるため、本番環境では**無効化**を推奨

#### サービスステータスの確認

1. CLIでコマンダーサービスモードの状態を確認します。

```
keeper service-status
```

2. APIの到達性およびステータス確認を確認します。

* APIエンドポイントを検証してサービス状態を確認します (以下のコマンドを参照)。
* サーバーが起動しており、Jiraからアクセス可能であることを確認します。
* ファイアウォール設定でアクセスが許可されていることを確認します。

{% code fullWidth="false" %}

```bash
curl -X POST 'http://localhost:8081/api/v2/executecommand-async' \
--header 'Content-Type: application/json' \
--header 'api-key: <your-api-key>' \
--data '{"command": "service-status"}'
```

{% endcode %}

3. コマンダーサービスモードを再起動します。

{% hint style="info" %}
EPMおよびSSOデバイス承認チケットは、コマンダーサービスモードの状態に関係なく、Jira ITSMアプリがWebhookペイロードデータを用いて作成します。Connector Hubはこれらのチケットを作成しません。サービスモードが利用可能になると、承認パネルにKEPM承認ビューおよび `device-approve` コマンドからのライブステータスが反映されます。
{% endhint %}

### 問題の対処

<table><thead><tr><th width="220.8203125">エラー / 症状</th><th width="190.07421875">原因</th><th>推奨される対処方法</th></tr></thead><tbody><tr><td>Connection Failed / Timeout</td><td>コマンダーサービスモードが起動していない、またはトンネルに接続できない</td><td>コマンダーサービスモードインスタンスが稼働中でアクセス可能か確認。NgrokまたはCloudflareトンネルが有効で正しいポートを指していることを確認</td></tr><tr><td>401 Unauthorized / 403 Forbidden</td><td>APIキーが無効または期限切れ</td><td>コマンダーサービスモードログから正しいAPIキーを取得し、Jira設定画面で更新。余分な空白や文字が含まれていないか確認</td></tr><tr><td>404 Not Found</td><td>API URLが誤っている、または不完全</td><td>/api/v2 を含む完全なAPI URLを使用 (例 <code>https://xxxxx.ngrok.io/api/v2</code> または <code>https://xxxxx.mycompany.com/api/v2</code>)。トンネルがコマンダーサービスモードと同じポートに転送していることを確認</td></tr><tr><td>502 Bad Gateway / 503 Service Unavailable</td><td>コマンダーサービスモードが停止している、または応答していない</td><td>コマンダーサービスモードを再起動し、完全に初期化されるまで待機。直近のログで構成や認証エラーを確認</td></tr><tr><td>接続成功後も操作が失敗する</td><td>必要なコマンド未有効、または権限不足</td><td>コマンダーサービスモードで必要なコマンドが有効か確認。操作実行アカウントのKeeperボルト権限を確認</td></tr></tbody></table>

{% hint style="info" %}
フィードバックや機能のご要望がございましたら、[Issueを作成](https://github.com/Keeper-Security/jira-connector-hub/issues)してください。
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.keeper.io/keeperpam/jp/secrets-manager/integrations/jira-workflow.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.