「AIに聞いてみたけど、なんだか的外れな回答だった」
そう感じたこと、ありませんか。
正直に言うと、私も最初はそうでした。AIを使い始めたころ、「思ったような答えが返ってこない」ことばかりで、「やっぱり実務では使えないな」と一度は距離を置いたくらいです。
でも、使い込むうちに気づきました。
問題はAIの性能じゃない。私の聞き方でした。
同じことを聞くにしても、伝え方を変えるだけで、返ってくる答えの質はまったく変わります。そして、その「伝え方」にはいくつかの決まった型があります。
今回は、運用保守の現場で私が実際に使っている「プロンプトの型」を5つ紹介します。コピペしてそのまま使える形にしてあります。
そもそも、なぜ「型」が必要なのか
AIは、こちらが渡した情報の範囲でしか考えられません。
当たり前のことですが、これが意外と抜けます。
私たちは現場のことを知りすぎているので、「これくらい言わなくてもわかるだろう」と省略してしまう。でもAIは、その現場を見ていません。
- どんな環境なのか
- 何が起きているのか
- どういう答えが欲しいのか
この3つが抜けたまま質問すると、AIは一般論を返すしかない。だから「的外れ」に感じるんです。
型を使う理由は、この抜けを防ぐためです。毎回ゼロから考えなくても、型に沿って埋めていけば、必要な情報が自然に揃う。それだけのことです。
型①：状況説明型【障害・トラブルを相談するとき】
一番よく使う型です。
障害やトラブルの相談は、情報が足りないと役に立つ答えが返ってきません。だからこそ、最初に状況を構造化して渡します。
テンプレート
【環境】
（OS、ミドルウェア、バージョン、構成）
【発生している事象】
（何が、いつから、どういう頻度で）
【確認済みのこと】
（すでに調べたこと、切り分け済みの内容）
【知りたいこと】
（原因の候補が知りたい／確認手順が知りたい 等）ポイントは**「確認済みのこと」**を必ず書くことです。
これがないと、AIは「まずログを確認してください」といった、すでにやったことから提案してきます。それで「使えない」と感じてしまう。
「ここまでは調べた」を伝えるだけで、その先の話をしてくれるようになります。
型②：たたき台生成型【文書を作るとき】
報告書、手順書、顧客への連絡文——運用保守は文書作成が意外と多い仕事です。
ここでAIに丸投げすると、たいてい「それっぽいけど使えない文章」が出てきます。
コツは、AIに完成品を求めないことです。あくまで、たたき台を作ってもらう。
テンプレート
以下の内容で【文書の種類】のたたき台を作ってください。
【読み手】
（顧客の情報システム部門 / 社内の上長 / チームメンバー 等）
【伝えたいこと】
（箇条書きで要点だけ）
【トーン】
（丁寧に / 簡潔に / 謝罪を含む 等）
【分量】
（A4半分程度 / 300字程度 等）特に効くのが**「読み手」の指定**です。
同じ障害報告でも、顧客向けと社内向けでは書くべきことが違います。読み手を指定するだけで、文章の温度感がぐっと現場に近づきます。
出てきたたたき台を自分の言葉で直す。この使い方が、一番早くて確実です。
型③：制約明示型【手順やコマンドを聞くとき】
「バックアップの手順を教えて」だけだと、教科書的な一般論が返ってきます。
現場で使いたいのは、自分の環境で動く手順です。
テンプレート
【やりたいこと】
（目的を一文で）
【環境・前提】
（OS、バージョン、権限、使えるツール）
【制約】
（本番環境なので再起動不可 / GUIは使えない / 追加インストール不可 等）
【出力してほしい形式】
（手順書形式 / コマンドのみ / スクリプト 等）この型の肝は**「制約」**です。
現場には必ず制約があります。「本番だから止められない」「追加ソフトは入れられない」「作業は夜間帯のみ」——こういう条件を先に伝えておかないと、使えない提案が返ってきます。
制約を書くのは面倒に感じますが、書かないと結局やり直しになる。先に書いたほうが早いです。
型④：レビュー依頼型【自分の考えを検証したいとき】
これは、私が一番価値を感じている使い方かもしれません。
AIに答えを出してもらうのではなく、自分の考えをチェックしてもらう。
テンプレート
以下の【手順／計画／構成】をレビューしてください。
【内容】
（自分が作ったもの）
【前提・背景】
（なぜこうしたか、どういう状況か）
【特に見てほしい観点】
（抜け漏れ / リスク / 効率化の余地 等）
指摘は、重要度の高い順に挙げてください。運用保守の現場では、自分の判断が正しいか確認したい場面が多い。
でも夜間対応中や、周りに相談できる人がいない状況もあります。そういうとき、この型が効きます。
「重要度の高い順に」と指定するのがポイントです。そうしないと、細かい指摘と重大な指摘が同じ重みで並んで、判断に困ります。
型⑤：役割設定型【視点を変えて考えたいとき】
AIに立場を与えると、答えの角度が変わります。
テンプレート
あなたは【役割】です。
その立場から、以下について意見をください。
【状況】
（背景説明）
【検討したいこと】
（判断に迷っていること）役割の例としては、こんな指定が現場で使えます。
- 顧客の情報システム部門の担当者 → 提案が顧客目線で刺さるか確認したいとき
- セキュリティ監査の担当者 → 自分の運用設計に穴がないか見たいとき
- 経験の浅い新人メンバー → 手順書がわかりやすいか検証したいとき
私がよく使うのは、最後の「新人視点」です。
自分で書いた手順書は、自分にはわかりやすい。でも新人が読んで詰まらないかは、自分では判断できません。役割を与えて読ませると、「ここは前提知識がないと理解できません」と指摘してくれます。
型を使うときに、守っていること
便利な型ですが、運用保守で使う以上、守るべき一線があります。
1. 顧客情報・機密情報は入れない
ホスト名、IPアドレス、顧客名、アカウント情報——これらはそのまま渡さない。伏せ字や汎用名に置き換えてから聞きます。
2. 出てきた答えを、そのまま本番に適用しない
特にコマンドやスクリプトは要注意です。必ず内容を理解してから、検証環境で確認する。AIの回答は「たたき台」であって「正解」ではありません。
3. 判断そのものは、自分でする
AIは判断材料を増やしてくれますが、最終的に責任を負うのは自分です。「AIがそう言ったから」は、現場では通用しません。
この3つさえ守れば、AIは運用保守の強い味方になります。
まとめ
運用保守で使えるプロンプトの型5選をまとめます。
- 状況説明型 — 障害・トラブルの相談に。「確認済みのこと」を必ず書く
- たたき台生成型 — 文書作成に。「読み手」の指定が効く
- 制約明示型 — 手順・コマンドを聞くときに。現場の制約を先に伝える
- レビュー依頼型 — 自分の考えの検証に。「重要度順」を指定する
- 役割設定型 — 視点を変えたいときに。新人視点が特に使える
守ること
- 顧客情報・機密情報は入れない
- 出てきた答えをそのまま本番に適用しない
- 判断そのものは自分でする
AIがうまく使えないと感じている人の多くは、性能ではなく聞き方でつまずいています。
まずは、次にAIに相談するとき、型①だけでも試してみてください。返ってくる答えが変わるのが、すぐにわかると思います。
コメント