> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Runbooks
> インシデント発生時にAIエージェントが修復手順を検索・実行できるよう、チームのオペレーショナルランブックを接続します
本番環境でインシデントが発生すると、チームにはランブック—ポッドの再起動、データベースフェイルオーバー、スケーリング操作といった一般的な障害に対するステップバイステップの手順—があります。問題は、深夜3時に適切なランブックを見つけ、プレッシャーの中で正確に実行することです。
CloudThinker Runbooksはそのギャップを解消します。[RCA調査](/ja/guide/incident/root-cause-analysis)中、AIエージェントが接続されたランブックソースを自動検索し、関連する手順を見つけて修復コマンドを実行します—破壊的な操作には人間の関与を保つポリシー駆動の承認コントロールが付随します。
手動アップロードと接続リポジトリを持つRunbook Sourcesダッシュボード
***
## ランブックの仕組み
既存のランブックリポジトリ（Confluence、GitHub、GitLab）をリンクするか、Markdownファイルを直接アップロードします。
インシデントが[Root Cause Analysis](/ja/guide/incident/root-cause-analysis)をトリガーすると、AIエージェントはインシデントのコンテキストと影響を受けたサービスに基づき、接続されたソースから関連ランブックを検索します。
コマンドを実行する前に、ワークスペースの[承認ポリシー](/ja/guide/approval)に照らして評価します。ポリシーに応じて、コマンドは自動実行・承認待ちキュー・ブロックのいずれかになります。
承認が必要なコマンドについては、メール・Slack・アプリ内通知でお知らせします。任意のチャンネルから直接承認または拒否できます。承認されたコマンドはただちに実行されます。
***
## ランブックソースの接続
**Deep Response Engine > Runbooks** に移動してソースを管理します。CloudThinkerは4種類のソースタイプをサポートしており、それぞれ異なるワークフローに対応しています。
Confluence設定を使った新しいランブックソースの追加
### Confluence
ConfluenceナレッジベースをAIエージェントに接続し、オペレーション手順のウィキページを検索できるようにします。
**セットアップ:**
1. Runbooksページで **Add Source** をクリック
2. 名前を入力（例：「SRE Runbooks」）
3. ソースタイプとして **Confluence** を選択
4. Atlassianの接続を選択（[Connections > Atlassian](/ja/guide/connections/atlassian) で設定）
5. オプションで特定の **Space Key**（例：`SRE`）に検索範囲を限定
6. **Labels** を追加してページをフィルタリング（例：`runbook`、`incident-response`）
7. **Add Source** をクリック
**エージェントの検索方法：** RCA中、エージェントはConfluenceのCQLクエリ言語を使用し、設定済みのスペースおよびラベルフィルタ内でインシデントのコンテキストに一致するページを検索します。
### GitHub
GitHubリポジトリにあるランブックのMarkdownファイルをエージェントに指定します。
**セットアップ:**
1. **Add Source** をクリック
2. ソースタイプとして **GitHub** を選択
3. GitHubの接続を選択（[Connections](/ja/guide/connections/overview) で設定）
4. ランブックを含む **repository** を選択
5. **branch** を設定（デフォルトは `main`）
6. オプションで **path prefix** を設定して検索範囲を制限（例：`docs/runbooks/`）
7. **file patterns** を設定してマッチするファイルを指定（デフォルトは `*.md`）
8. **Add Source** をクリック
**エージェントの検索方法：** エージェントはGitHub APIを使用してパスとパターンフィルタに一致するファイルを一覧・読み込みし、現在のインシデントとの関連性を分析します。
### GitLab
GitHubと同じワークフローで、GitHubの代わりにGitLabの接続を使用します。
**セットアップ:**
1. **Add Source** をクリック
2. ソースタイプとして **GitLab** を選択
3. GitLabの接続を選択
4. **repository**・**branch**・**path prefix**・**file patterns** を選択
5. **Add Source** をクリック
**エージェントの検索方法：** エージェントはGitLab APIを使用してリポジトリから一致するファイルを検索・取得します。
### 手動アップロード
外部システムに手順が保存されていない場合は、Markdownのランブックファイルを直接アップロードします。
**セットアップ:**
1. Runbooksページで **Upload Runbook** をクリック
2. `.md` ファイルをドラッグ＆ドロップ（最大20ファイル、各5 MB）
3. 確認前に必要に応じてファイル名を編集
4. **Confirm Upload** をクリック
アップロード後、CloudThinkerはMarkdownのコードブロックから書き込みコマンド（`kubectl apply`・`aws` のミューテーション・`helm install` など）を自動抽出します。この抽出されたコマンドが[コマンドごとのパーミッション](#コマンドごとのパーミッション)の基礎となります。
***
## コマンドごとのパーミッション
手動ランブックには独自の安全機能—**コマンドごとのパーミッションコントロール**—が備わっています。Markdownファイルをアップロードすると、CloudThinkerのAIがコードブロックを読み取り、すべての書き込み/変更コマンドを抽出します。これにより、エージェントが自律的に実行できる操作を細かく制御できます。
pod-crashloopbackoffランブックのコマンドごとのパーミッションコントロール
### 仕組み
1. **自動抽出**：アップロード後、システムはすべてのコードブロックを解析し、インフラを変更するシェルコマンド（例：`kubectl set resources`・`kubectl rollout restart`・`kubectl delete`）を特定します
2. **読み取り専用コマンドはスキップ**：`kubectl get`・`kubectl describe`・`kubectl logs` などのコマンドは抽出されません—エージェントは常に読み取り専用コマンドを実行できます
3. **各コマンドにパーミッションを割り当て**：抽出されたすべての書き込みコマンドはデフォルトで **Require Approval** から始まります
### パーミッションレベル
| パーミッション | 動作 |
| -------------------- | -------------------------------------------- |
| **Allow** | エージェントが人間の承認なしにコマンドを即時実行します |
| **Require Approval** | エージェントは実行前に承認をリクエストします。メール・Slack・アプリ内で通知されます |
| **Deny** | エージェントはこのコマンドを実行できません |
### コマンドの管理
ランブック詳細ダイアログから：
* **すべてのパーミッションを一括変更**：「Set all to...」ドロップダウンを使用して、すべてのコマンドをAllow・Require Approval・Denyに一括変更します
* **個別パーミッションの変更**：任意のコマンドの横のドロップダウンをクリックしてパーミッションレベルを調整します
* **コマンドの追加**：新しいコマンドパターンを入力してEnterを押すと、リストに追加されます
* **コマンドの削除**：削除アイコンをクリックしてポリシーからコマンドを削除します
* **コマンドの全文表示**：展開矢印をクリックして複数行または長いコマンドを全文表示します
コマンドごとのパーミッションは現在、手動アップロードのランブックで利用可能です。外部ソース（Confluence、GitHub、GitLab）では、すべてのコマンドがデフォルトで承認必須となります。外部ソースへのコマンドごとのコントロールは近日公開予定です。
***
## 承認ワークフロー
RCA中にエージェントが関連ランブックを見つけ、ポリシーが承認を必要とする場合、次のフローが実行されます。
### 承認フロー
1. **エージェントがランブックを発見**：調査中、エージェントはソースを検索して一致する手順を特定します
2. **ポリシー評価**：システムはワークスペースの承認ポリシーをランブックとそのコマンドに照らして確認します
3. **通知の送信**：承認が必要な場合、設定されたすべてのチャンネルで通知が届きます：
* **メール**：ランブックのタイトル、ソースリンク、ポリシーの理由
* **Slack**：インシデントのコンテキストを含むインタラクティブ通知
* **アプリ内**：承認待ちを示すインシデントのバッジ
4. **承認または拒否**：承認をクリックしてエージェントの続行を許可するか、拒否をクリックして実行をブロックします
5. **エージェントが続行**：承認されるとエージェントはランブックコマンドを実行します。拒否された場合、エージェントはそのランブックを実行せず調査を続けます
### 承認ステータス
| ステータス | 意味 |
| ------------ | -------------------------------- |
| **Pending** | 人間の承認待ち—エージェントはこのステップで一時停止中 |
| **Approved** | 人間が承認済み—コマンドが実行中または完了 |
| **Rejected** | 人間が拒否—エージェントはこのランブックをスキップして調査を継続 |
### 実行ステータス
承認後、各実行はその結果を追跡します：
| ステータス | 意味 |
| --------------- | ----------------------------- |
| **Not Started** | 承認済みだがコマンドがまだ実行されていない |
| **Completed** | すべてのコマンドが正常に実行された |
| **Failed** | 実行中に1つ以上のコマンドが失敗した |
| **Skipped** | 実行がスキップされた（例：承認の有効期限切れまたは上書き） |
### 実行履歴の確認
Runbooksページの **Execution History** タブに切り替えると、インシデントをまたいだすべてのランブック実行を確認できます。以下の操作が可能です：
* ランブックタイトルで検索
* ポリシーの決定・承認ステータス・実行結果を確認
* どのランブックがどのインシデントに使用されたかを追跡
***
## ベストプラクティス
**ソースの整理：**
* ソースにわかりやすい名前を付ける（例：「K8s Emergency Runbooks」「Database Failover Procedures」）
* パスプレフィックスとファイルパターンを使用して検索を集中・高速化する
* Confluenceではラベルでドメイン別にランブックを分類する（例：`kubernetes`・`database`・`networking`）
**パーミッション戦略：**
* 信頼が構築されるまで、すべてのコマンドを（デフォルトの）**Require Approval** から始める
* 十分にテストされた低リスクのコマンド（スケーリング操作・ログ収集など）を徐々に **Allow** に移行する
* 破壊的なコマンド（delete・drop・force）は永続的に **Require Approval** に維持する
* 自動化してはならないコマンド（本番データベースのdropなど）には **Deny** を使用する
**ランブックの品質：**
* シェル言語ヒント付きの明確なコードブロックでMarkdownのランブックを作成する（` ```bash `）
* 最良の抽出結果のために1行に1コマンドを使用する
* 各手順をいつ使用すべきかのコンテキストを含める—エージェントはこれをランブックとインシデントのマッチングに使用する
* ランブックは集中させる：すべてを1つのドキュメントにまとめるより、1ファイルに1手順の方が効果的
***
## 次のステップ
AIエージェントがインシデントを調査する方法と、分析ワークフロー中にランブックがトリガーされるタイミングを学びます。
エージェントが自律的に実行できる操作を制御するワークスペースレベルの承認ポリシーを設定します。