はじめに
生成AIに質問するとき、長い一文だけで投げていないでしょうか。
EC2が立ち上がらないんだけど原因と対策教えて
これでも返答は来ます。
ただ、現場で使うには情報が足りません。AIは足りない前提を補おうとして、もっともらしい推測を始めます。
この記事では、AIへの依頼をMarkdownで構造化し、出力の事故を減らす考え方を整理します。
動画版
この記事は、以下のYouTube動画をQiita向けに再構成したものです。
先に結論
AIへの依頼は、長い一文で投げるより、次の5つに分けると安定します。
| 項目 | 書くこと | 例 |
|---|---|---|
| 役割 | AIにどの立場で答えてほしいか | AWSインフラエンジニアとして |
| 目的 | 何を解決したいか | EC2起動失敗の原因を切り分けたい |
| 前提 | いま分かっている事実 | OS、エラー、直前の変更 |
| 制約 | やってほしくないこと | 推測で断定しない、公式確認点を出す |
| 出力形式 | どんな形で返してほしいか | 表、手順、チェックリスト |
まずは「目的」「前提」「制約」「出力形式」だけでも十分です。
用語の短い説明
この記事で使う用語を短く整理します。
| 用語 | 短い説明 |
|---|---|
| Markdown | 見出し、箇条書き、表、コードブロックを簡単に書ける記法 |
| プロンプト | AIへ渡す依頼文や条件のこと |
| ハルシネーション | AIが事実のようにもっともらしい誤りを返すこと |
| RAG | 検索や資料参照を組み合わせ、外部情報を根拠に回答させる考え方 |
| マスキング | 顧客名、IP、パスなどを公開してよい形に置き換えること |
悪い依頼と改善後
たとえば、次のような依頼はAIが推測しやすくなります。
# 悪い例: 目的や前提が少なく、AIが推測しやすい
EC2が立ち上がらないんだけど原因と対策教えて
これをMarkdownで分けると、かなり扱いやすくなります。
<!-- 何を解決したいかを先に書く -->
## 目的
EC2インスタンスが起動後にStatus Check Failedになる原因を切り分けたいです。
<!-- AIが推測しないよう、分かっている事実を並べる -->
## 前提
- OSはAmazon Linux 2023です。
- 直前にセキュリティグループを変更しました。
- SSH接続はできません。
- CloudWatch Logsの設定は未確認です。
<!-- やってほしくないことを明示する -->
## 制約
- 推測で断定しないでください。
- 不明点は先に質問してください。
- 公式ドキュメントで確認すべき点を分けてください。
<!-- 欲しい形を指定すると、レビューしやすい回答になる -->
## 出力形式
| 優先度 | 確認場所 | 見るもの | 次の判断 |
| --- | --- | --- | --- |
ポイントは、AIに「何を知らないか」まで渡すことです。
プロンプトは質問ではなく設計書に近い
プロンプトエンジニアリングという言葉は難しく見えますが、考え方はシンプルです。
AIからほしい回答を得るために、入力文を設計することです。
エンジニアなら、仕様が曖昧な状態で実装すると手戻りが出ることを知っています。AIも同じです。
目的が曖昧
前提がない
制約がない
出力形式がない
この状態で依頼すると、AIは「たぶんこういうことだろう」と補完します。
それが便利に見えることもありますが、技術作業では事故の原因になります。
なぜMarkdownが効くのか
Markdownは、見出しや箇条書きで情報の塊を分けられます。
<!-- この4見出しだけでも依頼の形が安定する -->
## 目的
## 前提
## 制約
## 出力形式
人間にとって読みやすいだけでなく、AIにとっても「どれが背景で、どれが守るべき条件か」を分けやすくなります。
長い一文に全部を詰め込むより、見出しと箇条書きに分けた方が、条件漏れや取り違えが減ります。
黄金の5ステップ
まずは、この5つだけで十分です。
<!-- 役割を指定すると、回答の視点が揃いやすい -->
## 1. 役割
あなたは10年の経験を持つAWSインフラエンジニアです。
<!-- 目的は1文で書く -->
## 2. 目的
起動に失敗するEC2インスタンスの原因を切り分けたいです。
<!-- 分かっている事実だけを書く。推測は混ぜない -->
## 3. 前提・背景
- OSはAmazon Linux 2023です。
- エラーメッセージはStatus Check Failedです。
- 直前にセキュリティグループを変更しました。
- インスタンスタイプはt3.mediumです。
<!-- AIの回答範囲を制御する -->
## 4. 制約
- 推測で断定しないでください。
- 不明な点があれば、先に追加で必要な情報を質問してください。
- 公式ドキュメントで確認すべき点は明示してください。
<!-- 表で出してほしい列を指定する -->
## 5. 出力形式
以下の表で出力してください。
| 優先度 | 確認場所 | コマンド例 | 期待される結果 | 次の判断 |
| --- | --- | --- | --- | --- |
この形にすると、AIはかなり答えやすくなります。
特に重要なのは、制約の中にあるこの一文です。
不明な点があれば、先に追加で必要な情報を質問してください。
AIは情報が足りなくても、親切に答えようとします。技術作業では、その親切さがハルシネーションにつながります。
だから、分からないときは止まってもらう指示を入れます。
そのまま使えるテンプレート
毎回ゼロから書くのが面倒なら、まずはこの形で十分です。
<!-- 役割は短く。長く書きすぎない -->
## 役割
あなたは〇〇に詳しいエンジニアです。
<!-- 目的は「何をしたいか」まで書く -->
## 目的
私は〇〇をしたいです。
<!-- 分かっていることと未確認のことを分ける -->
## 前提
- 現在の状況:
- 直前に変更したこと:
- 分かっているエラー:
- まだ確認していないこと:
<!-- 危ない回答を避けるための条件 -->
## 制約
- 推測で断定しないでください。
- 不明点があれば、先に質問してください。
- 公式情報や実機確認が必要な点を分けてください。
- 機密情報を求めないでください。
<!-- 最終的にほしい形 -->
## 出力形式
1. まず確認すべきこと
2. 原因候補
3. 確認コマンドまたは確認場所
4. 次の判断
テンプレートを使うだけでも、AIの回答は「それっぽい説明」から「確認手順」に寄りやすくなります。
ハルシネーションを前提にする
ハルシネーションとは、AIが事実のようにもっともらしい誤りを返すことです。
AWS CLIの存在しないオプション、古い仕様、実際には動かない設定例などは、現場でそのまま使うと危険です。
AIは「真実かどうかを保証する装置」ではありません。
だから、次の前提で使います。
- 公式ドキュメントを正とする
- 最新仕様は必ず確認する
- AIの回答は下書きとして扱う
- コマンドやコードは自分の環境で検証する
- 設計書や顧客提出物へ入れる前に人間がレビューする
「AIが言ったので」は、現場では理由になりません。
公式情報を貼ると精度が上がる
最新仕様や社内ルールを確認したいときは、AIの記憶だけに頼らない方が安全です。
公式ドキュメントや、確認済みの社内ルールをプロンプトに貼り、その範囲から回答させます。
<!-- 参照範囲を明示して、根拠のない補完を減らす -->
## 参照情報
以下のドキュメント抜粋だけを根拠に回答してください。
不明な場合は「この抜粋だけでは判断できない」と書いてください。
```text
# ここに公式ドキュメントや社内ルールの抜粋を貼る
[抜粋本文]
```
<!-- 回答してほしい問いを最後に置く -->
## 質問
この条件で、設定変更時に注意すべき点を整理してください。
これは手元でできる簡易RAGのような使い方です。
ただし、貼る情報に機密が含まれていないかは必ず確認します。
セキュリティで一番危ないのは「少しだけなら大丈夫」
AIに投げてはいけないものは、APIキーやパスワードだけではありません。
以下も危険です。
- 顧客名
- 個人名
- 本番IPアドレス
- 内部サーバー名
- リポジトリURL
- 社内パス
- プロジェクト固有の関数名
- 顧客独自の業務データ
- 契約条件
- 障害時の生ログ
顧客名だけ伏せても、IP、パス、関数名、ログの組み合わせで特定できることがあります。
AIへ貼る前に、一般化・マスキングします。
# beforeは機密が混ざっている例
before:
/var/www/customer-a/payment-batch/prod/...
10.12.34.56
customerAChargeSettlement()
# afterは意味を残して一般化した例
after:
/path/to/app/batch/prod/...
192.0.2.10
runSettlementJob()
マスキングしても意味が通じる形にするのがコツです。
プロンプト自体をAIに作らせる
慣れないうちは、最初からきれいなプロンプトを書こうとしなくて大丈夫です。
ぐちゃぐちゃなメモを渡して、プロンプトの形に直してもらいます。
<!-- AIに答えではなく、依頼文の形を整えてもらう -->
## 依頼
今からAWSの障害調査について相談したいです。
以下のメモをもとに、AIが精度高く回答できるMarkdownプロンプトへ整形してください。
<!-- 機密確認も同時に依頼する -->
## 条件
- 機密情報が入りそうな箇所は、伏せ字にする候補として指摘してください。
- 足りない情報があれば質問リストにしてください。
- 最終出力は「役割」「目的」「前提」「制約」「出力形式」の5項目にしてください。
<!-- ここは箇条書きで十分 -->
## メモ
ここに雑なメモを貼る
これはメタプロンプトです。
AIを「答えを出す相手」としてだけでなく、「聞き方を整える相手」として使います。
現場で使う前のチェックリスト
AIに投げる前に、次を確認します。
- 顧客名、個人名、IP、パス、Secretが入っていないか
- 無料版、個人版、会社契約版、API利用のどれを使っているか
- 入力データが学習に使われるかを確認したか
- 現場のルールでAI利用が許可されているか
- 出力を公式ドキュメントや実機で確認する前提になっているか
- 不明点はAIに質問させる指示が入っているか
特に技術相談では、次の3つを入れるだけでも事故が減ります。
# 技術相談で最低限入れたい3点
1. 直前に変更したこと
2. 実際に出ているエラー文
3. まだ確認していないこと
まとめ
AIへの依頼は、長い一文よりMarkdownで構造化した方が安全です。
- プロンプトは質問ではなく設計書に近い
- 役割、目的、前提、制約、出力形式を分ける
- 「不明なら質問して」と明示する
- ハルシネーションを前提に公式情報で確認する
- 顧客情報や秘密情報は投げない
- プロンプト自体もAIと一緒に作れる
参考・確認先
- Qiita Markdown記法 チートシート
- Google Search Central: Creating helpful, reliable, people-first content
- IPA: 情報セキュリティ
おわりに
生成AIは、便利な道具です。
ただし、現場で信頼されるのは、AIを使う人ではなく、AIの出力を安全に扱える人です。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。
会社の取り組みは、会社サイトにまとめています。
https://wealthy-design.com/
この記事はYouTube台本をQiita向けに再構成したものです。各AIサービスの規約、データ利用、オプトアウト設定は変わるため、使う直前に公式情報を確認してください。