Prompts as playbooks; how infrastructure teams codify operational knowledge｜インフラチームがプロンプトを運用マニュアル化 | AIニュース最前線

![image](https://storage.ghost.io/c/d6/fe/d6feb101-a8e6-444b-bae8-3ca714794abb/content/images/2026/03/forkbomb.eth_stack_of_books_switzerland_hills_and_mountains___afc324f2-3cd7-430d-9c54-855bc0b1734a_2--1-.png) 私が知るインフラエンジニアの誰もが、頭の中で「プロンプト」を実行しています。ただ、彼らはそれをそう呼んでいないだけです。 新しいサービスを本番環境にデプロイする際、あなたは意識せずに既知の手順を踏みます。既存の本番ワークロードに影響を与えずにサービスが稼働することを保証するためです。こうした手順は数十回も繰り返してきたものです。ドキュメントを参照する必要はありません。チェックリストはすでに筋肉記憶として定着しており、深夜 2 時にトラブルに見舞われたデプロイの経験によって磨き上げられています。 では、あなたが退職したときや、新しいエンジニアが加わったときはどうなるでしょうか？あるいは、その特定のスタックに触れたことのない担当者がオンコールローテーションを回されたらどうなるでしょう。知識は引き継がれません。チャットのやり取りの中にあり、6 ヶ月前には正確だったウィキページにあり、今まさに眠っている他のメンバーの頭の中にあります。 これが「ランブック（実行手順書）の問題」です。多くのインフラチームはこの問題を事業のコストとして受け入れています。しかし、私は彼らが必要ないと思っています。 ## 従来のランブックは、一般的な操作の手順を記述したものです。問題なのは、それが常に間違っているか古くなっていることだけではありません（実際によくある話ですが）、重要なのは「実行を強制できない」点にあります。 ランブックには「VPC ピアリング接続がアクティブであることを確認せよ」と書かれていても、実際にその手順を実行したかどうかを確認することはできません。疲れていたり、過信していたりして手順を飛ばしても止めることはできません。 私の働き方を変えた気づきは、ランブックとプロンプトの間に大きな隔たりがないということです。ランブックには「OOMKilled イベントがあるかポッドログを確認せよ」と書かれていますが、Cline を使ったプロンプトも同じことを伝えます。ただし、Cline は実際にログをチェックし、出力を解析して何が見つかったかを教えてくれます。これにより、手順は理論上のものから実行可能なものへと変わります。 なぜプロンプトがプレイブックになるのか すべてのプロンプトがプレイブックというわけではありません。多くのプロンプトは単発の依頼です。「このエラーを直せ」や「なぜこのポッドがクラッシュループしているのか」といったものです。これらはその場限りの作業には適していますが、一時的なものでしかありません。会話が終了すると消えてしまいます。 プレイブックとは、強化されたプロンプトのことです。具体的には、単なる理論上の検討ではなく、実際のインフラ環境でテスト済みであることを意味します。また、操作対象のコードと一緒にバージョン管理され、他のプレイブックと組み合わせることで多段階の操作も可能になります。そして何より、作成者ではない誰かが実行できるものであることが重要です。 Cline におけるこの仕組みは、.clinerules です。これはプロジェクト内の .clinerules/ ディレクトリに配置される Markdown ファイルです。これを有効化すると、その内容が Cline のシステムプロンプトに直接追加されます。これらは単なる受動的なドキュメントではなく、Cline がインフラストラクチャをどのように推論するかを能動的に形作るものです。リポジトリ内の通常のファイルと同様、プルリクエストレビューやバージョン管理、CI プロセスの対象となります。 プロンプトからプレイブックへの移行は、従来のプレイブックや自動化スクリプトを作成する際の典型的なパターンと似ています。最初は特定の課題に対してワンオフのプロンプトで対応し、一週間後に同じ問題が発生した際に「また同じことを繰り返している」と気づきます。そこでそのパターンを .clinerules ファイルとして抽出します。チームメンバーがそれを利用し、見落としだったエッジケースを発見してルールを更新する。こうして、チームの集合的な運用ノウハウは誰かの頭の中ではなく、バージョン管理された Markdown として蓄積されていきます。 まずは Terraform モジュールレビューから始めるのがおすすめです。最も簡単なアプローチは、すでに頭の中で適用しているレビュー基準をコード化することです。以下は私が Terraform の作業で使用する .clinerules ファイルの例です： # terraform-review.md Terraform コードのレビューや生成時には、以下の基準を厳守してください。 変数名：スネークケースを使用する。リソース名には環境プレフィックス（例：prod_, staging_）を含める必要がある。リージョン、ゾーン、マシンタイプなどの値はハードコードせず、適切なデフォルトを持つ変数として定義すること。 プロバイダーの制約：すべてのモジュールは、`~>`演算子を使用してプロバイダーのバージョンを固定する必要があります。上限なしで `>=` を使用することは禁止です。`required_providers` ブロックが存在し、最新であるかを確認してください。 ステートの安全性：ステートフルなリソース（データベース、永続ディスク、暗号化キーなど）において、`lifecycle { prevent_destroy = false }` を使用しているリソースはすべてフラグを立ててください。明示的なコメントで理由が説明されていない限り、デフォルトでは `prevent_destroy = true` であるべきです。 セキュリティのパターン：インラインの IAM ポリシーは禁止します。プリミティブなロールではなく、カスタムロールを使用した `google_project_iam_member` を利用してください。`roles/editor` や `roles/owner` の使用もフラグを立ててください。JSON キーファイルの使用は常に避け、Workload Identity を採用してください。もし `google_service_account_key` リソースが見つかった場合は、それを指摘し、代わりに Workload Identity を提案してください。 コストへの意識：`n1-standard` マシンタイプはフラグを立て、`n2` または `e2` の代替案を提示してください。500GB を超える永続ディスクについても、サイズを正当化するコメントがない場合はフラグを立ててください。長期間稼働するインスタンスについては、コミットド・ユース・ディスカウントの適用可否も確認してください。 これは高度な技術というより、私が以前頭の中で実行していたチェックリストに似たものです。異なる点は、チームのすべてのエンジニアが同じ基準を適用していることです。Cline は、急いでいる時に人間が見落としがちな問題を検出します。そしてルールは私たちが学ぶにつれて進化していきます。この知識は永続化され、コード化されるため、将来の変更においても見落とされることなく適用可能になります。 インシデント対応をプレイブックとして インシデント対応において、属人的な知識の依存が最も大きなコストを生みます。生産環境のすべてを知っているエンジニアでも、休暇中にシステムがダウンすれば手を打つことができません。 こうした知見を体系化したインシデントトリアージプレイブックの例を示します。 # incident-triage.md 生産環境でのインシデント対応では、以下の手順を順に実行してください。手順を飛ばしたり、診断を完了する前に復旧措置に進んだりしないでください。 ## ステップ 1：影響範囲の特定 どのサービスが影響を受けているかを特定します。アプリケーションログだけでなく、イングレスコントローラーのログも確認してください。問題は特定のポッド、ノード、ネームスペースに限定されているのか、それともクラスター全体に影響しているのかを判断し、その後の手順に進む前に影響範囲を報告します。 ## ステップ 2：タイムラインの構築 最初の異常信号を探し出します。対象サービスの監視ダッシュボードを確認し、そこから時間を遡って調査を進めます。当社のスタックでよく見られる初期兆候には以下があります。接続プール枯渇は、ユーザーがエラーを感知する 3〜5 分前に /healthz のレイテンシ上昇として現れます。OOMKilled イベントはポッドの再起動に先立ち発生します。証明書有効期限切れの警告は、イングレスコントローラーのログに障害発生の 30 日前に表示されますが、しばしば無視されています。 ## ステップ 3：変更箇所の特定 対象ネームスペースのデプロイ履歴を確認します。kubectl rollout history を実行し、関連する環境ブランチにマージされた直近の PR と照合してください。過去 24 時間以内に Terraform の適用が実行されていないかも確認しましょう。インフラストラクチャの変更とアプリケーションのデプロイは、どちらも同程度に原因である可能性があります。 ## ステップ4：是正策の提案 診断結果に基づき、具体的な是正策を提示します。各アクションに対して、「何が変わるのか」「ロールバック手順は何か」「成功を確認する検証方法は何か」を明記してください。「なぜクラッシュしたかを理解せずに単にポッドを再起動する」といった安易な提案は避けてください。 ## ステップ5：適用前のドラフト実行 是正策がインフラの変更（Terraform、Helm、kubectl apply など）を含む場合、事前に計画書や差分出力を表示してください。直接適用してはいけません。また、ロールバックを伴う場合は、対象となるリビジョンが既知の安定版であることを確認します。 これはシニアエンジニアが暗黙的に持っている知識です。これをランブックとして文書化すれば簡易的なチェックリストになりますが、.clinerules のプレイブック形式にすることで、「この障害の調査を手伝って」と指示した際に Cline が実際に辿るフローそのものになります。Cline はプレイブックに従い、ログを適切な順序で確認し、結論を急ぐ前に時系列を整理した上で、ロールバック経路を含む是正策を提案します。 ### 多段階操作のためのワークフローとフック シンプルな .clinerules ファイルは常時ガイドとして機能しますが、インフラ運用の中にはより構造化されたアプローチが必要なケースがあります。明確な手順の定義、承認ゲートの設置、そしてどのコマンドを実行するかを厳密に制御する仕組みです。そのような場合にこそ、Cline の「ワークフロー」と「フック」が力を発揮します。 ワークフローは、.clinerules/workflows/ディレクトリに保存される Markdown ファイルです。チャット内で /workflow-name.md と入力することで、必要に応じて呼び出します。 ルールが常時有効であるのに対し、ワークフローは明示的に呼び出したときのみ実行されます。自然言語による指示と XML 形式のツール構文を組み合わせることで、高いレベルでの推論ステップと、厳密に実行すべきコマンドを柔軟に混在させることが可能です。 以下に、インシデント対応ワークフローの具体例を示します。 # incident-response.md ガイド付きインシデント対応ワークフロー。診断が完了する前に手順をスキップしたり、修復処理に進んだりしないでください。 ## ステップ 1: インシデントの検出と範囲特定 イングレスコントローラーのログとアプリケーションログを確認し、影響を受けるサービスを特定します。問題が特定の Pod、ノード、名前空間に限定されているのか、それともクラスター全体に影響しているのかを判断してください。 kubectl get events --sort-by=.lastTimestamp -A | head -50 次に、拡大範囲（ブラスト・レイジ）を報告してから次の手順へ進んでください。 ## ステップ 2: コンテキストのスナップショット取得 修復処理後の比較基準となるよう、影響を受けたリソースの現在の状態を記録します。 kubectl get pods -A -o wide | grep -v Running ## ステップ 3: タイムラインの特定と対応策の提案 最初の異常信号を探し出し、デプロイ履歴や直近の Terraform の適用状況と照合してください。診断結果に基づき、具体的な修復策を提案します。各提案に対しては、「何を変更するのか」「ロールバック手順は何か」「成功を確認するための検証方法は何か」を明記してください。 ## ステップ 4: 承認ゲート Here is the proposed remediation. Proceed with dry run? ["Yes, run dry run", "Modify the plan", "Abort"] ## ステップ 5：事前実行（ドライラン） 本番環境への適用前に、事前実行モードで修復計画を実行します。変更内容や差分を出力して確認してください。 必ずレビューを経ずに直接適用することは禁止です。 ## ステップ 6：適用と検証 承認後に変更を適用し、復旧を確認します。影響を受けるサービスが正常に動作していることを確認してから、インシデントの解決としてマークしてください。 `/incident-response.md` と入力すると、Cline が各ステップを順次実行し、それぞれの段階であなたの承認を待ちます。このツールは明確な承認ゲートを設けており、あなたが選択するまで Cline は次に進みません。また、特定の診断コマンドが曖昧に解釈されることなく、記述された通りに正確に実行されるようブロックが機能します。 ワークフローでは表現しきれないプログラムによる強制が必要な場合、Cline の Hooks（フック）機能が役立ちます。これは、ツールの実行前やタスク開始時、コマンド完了時など、ライフサイクルの重要なタイミングで自動的に実行されるスクリプトです。例えば、PreToolUse フックを設定すれば、対応する `kubectl diff` コマンドが先に実行されない限り `kubectl apply` をブロックしたり、変更ウィンドウ外での Terraform の適用を防いだりできます。 フックは JSON 形式のレスポンスを返すことで、操作の許可またはキャンセルを決定します。これにより、ガードレール（安全装置）は指示ではなくコードによって強制されます。 ワークフローとフックは互いに補完し合います。これらは検出、診断、承認、実行、検証という構造化されたパイプラインと同じ役割を果たし、すべてがインフラストラクチャコードと共にバージョン管理されます。 意思決定こそが成果物である これは単なるツールの話を超えた、より本質的な課題です。コードレビューのための .clinerules プレイブックを作成する際、あなたは長年の経験で蓄積された判断をコードに刻み込むことになります。「どの CIDR 範囲が環境間で競合しないか」「ワークロードに対してコストとパフォーマンスのバランスが取れたマシンタイプは何か」「本番環境でも安全と言える IAM のパターンはどれか」「チームのデプロイフローが実際にうまくいったとき、どのような状態になるのか」。こうした問いへの答えこそが重要です。 これらの判断こそが難所であり、それを実装するコード自体は比較的単純です。ジュニアエンジニアや Cline であっても、明確に仕様が定められたコード変更を正しく適用することはできます。しかし、「どのモジュールを使うべきか」「変数には何を入れるべきか」「セキュリティ上の影響はどうなるか」を判断するには、経験が必要です。 プレイブックとは、その経験をパッケージ化し、蓄積させて消え去らせないための手段です。質の高いプレイブックは、オンボーディングの加速、インシデントの減少、そして自動化への自信につながります。これは「Infrastructure as Code」の考え方と同じで、インフラコードをどう使い、いつ使うかという運用知識のレイヤーに適用したものです。 ### 始め方 もしあなたがインフラエンジニアとしてこの考え方に興味を持っているなら、まずはここから始めてみてください。 定期的に繰り返すタスクを一つ選びましょう。デプロイ、証明書ローテーション、ログ分析、容量レビューなど、反復可能な構造を持つものであれば何でも構いません。その手順を .clinerules という Markdown ファイルに書き出します。 難しく考えすぎず、自分のスタックを見たことがない有能なエンジニアに説明するように書いてください。作成したファイルをプロジェクトの .clinerules/ ディレクトリに置き、Cline で有効にしてタスクを実行してみましょう。するとすぐに、プレイブックが曖昧すぎる箇所（Cline が確認質問をしてくる部分）や、状況に応じた柔軟性が欠けている箇所（Cline が指示された通りに厳密に実行してしまう部分）が浮き彫りになります。それを改善し、更新版をコミットしてください。 そして、共有しましょう。Cline Community Prompts リポジトリはまさにそのために存在しています。Terraform、Kubernetes、CI/CD パイプライン、観測性（Observability）、インシデント対応など、インフラ関連のあらゆるドメインでプレイブックを作成したのであれば、それをどのように構成したかをコミュニティが共有することで恩恵を受けます。 インフラに関する知見は特定の個人やチームに属するべきではありません。バージョン管理され、ピアレビューを受け、実行可能なものであるべきです。それこそがプレイブックの本質です。 cline/prompts リポジトリにインフラのプレイブックを共有するか、Discord や Reddit で自チームで機能している方法について議論しましょう。.clinerules やワークフローについてさらに深く知りたい場合は、Cline のドキュメントから始めてください。

インフラチームがプロンプトを運用マニュアル化

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト