"伝わらない"を解消 ! 生成 AI で磨くAWS サポートケース起票スキル ~ 生成 AI 活用による問題解決の効率化 ~

AWS テクニカルアカウントマネージャーの渡辺です。好きな AWS サービスは、AWS サポート です。

AWS サポートが提供するのは、従来の IT 障害対応だけではありません。サポートエンジニアリングチームは、AWS の対象となるすべてのテクニカル分野でトレーニングを受けており、一般的なガイダンス、How to アドバイス、ベストプラクティス、トラブルシューティング、運用サポートを提供します。

サポートセンターを利用する際に、意図が思い通りに伝わらなかったり、急いでいるのに情報のヒアリングで調査が進まなかったりしたことはないでしょうか。本記事では、そういったお悩みの解消につながる方法をお伝えします。

AWS サポートでは、サポートご利用に関する Tips として「技術的なお問い合わせに関するガイドライン」を公開しています。AWS サポートでは、お客様の課題の解決を効率的かつ迅速に行いたいと常に考えています。ガイドラインとして、お客様が技術的なご質問をサポートケースで起票する際に、早期解決に役立つポイントをまとめ、例文も掲載しています。
例えば、問い合わせ対象リソースや事象の発生時刻が記載されていないと、必要な情報のヒアリングを行う必要が生じ、その間調査は進捗しません。あるいは、解決したい課題が明確に記載されていないと、意図とは異なる方向性でサポートケース上の調査が進む可能性があります。

今回は、問題解決の効率化のため、「技術的なお問い合わせに関するガイドライン」に記載された内容に沿った形でサポートケースを起票できるよう、生成 AI を活用してサポートの起票文をセルフレビューする方法をご紹介します。
今回は生成 AI ツールとして Kiro CLI と Amazon Quick Suite を使いますが、任意のツールでも構いません。

• Kiro CLI は、エージェンティック AI サービスである Kiro のエージェントをターミナルから直接 CLI で利用できるツールです。
• Amazon Quick Suite は、生成 AI を活用したビジネスインテリジェンスプラットフォームです。

2025年12月から、サポートセンターコンソールで AI が活用されるようになりました。AI がまずトラブルシューティングを行い、その後ケース起票をする流れです。AI に入力する情報の質が AI の出力の質に直結するため、本ブログで紹介する手法は引き続き有効です。

今回ご紹介する方法は、プロンプトやソースコードを公開していますので、社内のチケットシステムへの記載内容の品質向上にもご活用いただけます。
「技術的なお問い合わせに関するガイドライン」に記載されている内容は、社内チケットシステムにおいても同様に重要です。
チケットに必要な情報が不足していると、対応者とのやり取りが増え、問題解決が遅れてしまいます。加えて、問題発生時の認識や判断根拠を正確に記録することも重要です。後から振り返る際、当時の状況が正確に記録されていないと、人間の記憶に頼ることになり正確性が損なわれ、正確な振り返りと改善ができなくなるためです。
本記事で紹介するセルフレビューの仕組みを応用することで、チケット起票時に必要な情報が漏れなく記載されているかを事前に確認でき、円滑な対応と将来の振り返りに活用できる記録の両立が可能になります。

さらなる応用のアイデアとして、独自のガイドラインや手順書を元にしたチェックを行う形に応用していただけるかもしれません。

なお、今回用いるレビュー用プロンプトは、複数回の改善を重ねてより良いものになりました。その際に用いた、Amazon Quick Suite によるプロンプト洗練の過程もご紹介します。

X ポスト » | Facebook シェア » | はてブ »

 

この起票文の場合、「技術的なお問い合わせに関するガイドライン」に記載されたいくつかの項目が不足しており、サポートエンジニアは即座に調査に取りかかれない可能性があり、ヒアリングを行い、ヒアリングが完了するまで調査が進捗しない可能性があります。

本番環境で EC2 から RDS への接続ができなくなりました。
昨日の夕方までは問題なく動作していたのですが、今朝出社して確認したところ、
アプリケーションがデータベースに接続できずエラーになっていました。

エラーメッセージは「connection timeout」で、アプリケーションのログには
「Could not connect to database server」と出力されています。

特に設定変更などは行っていないはずなのですが、原因として何が考えられますでしょうか。
本番環境のため、早急に復旧させたいです。


 

これに対して今回ご紹介する方法でレビューをした結果は以下のようになりました。「技術的なお問い合わせに関するガイドライン」に従い、適切な指摘をしてくれました。指摘された内容を取り入れたうえでサポートケースを起票することで、効率的な調査につながり、迅速な問題解決に近づきます。

ℹ️ 注意: この評価結果には文面からの推測が含まれる可能性があります。最終的な判断は実際の状況に応じて行ってください。

### 📊 評価サマリー
総合評価: 要改善

問題の概要 (EC2→RDS 接続不可、connection timeout) と緊急性は伝わりますが、サポートエンジニアが調査を開始するために必要な基本情報（リージョン、リソースID、発生時刻）が不足しています。このままでは追加ヒアリングが必要となり、復旧までの時間が延びる可能性があります。

### 🎯 主要改善点（優先順）

1. リージョンとリソースIDの明記 - EC2 インスタンス ID（i-xxx）と RDS インスタンス識別子が必須。これがないと調査を開始できません。

2. 発生時刻と継続状況の明確化 - 「昨日の夕方」「今朝」ではなく、具体的な日時（タイムゾーン付き）と現在も継続中かを記載してください。

3. 試行済み対応策の共有 - EC2/RDS の再起動、セキュリティグループの確認、RDS のステータス確認など、すでに試したことがあれば記載すること
で、重複した案内を避けられます。

4. ネットワーク構成情報 - EC2 と RDS が同一 VPC 内か、サブネット構成、セキュリティグループ ID などの情報があると切り分けが早まります。

### ✏️ 推奨修正例

【事象】
[リージョン名]リージョンの EC2（i-[インスタンス ID]）から
RDS（[RDS インスタンス識別子]）への接続ができなくなりました。

【発生時刻】
[YYYY 年 MM 月 DD 日 HH:MM]（日本時間）頃から発生し、現在も継続しています。
※最後に正常動作を確認したのは[YYYY 年 MM 月 DD 日 HH:MM]（日本時間）です。

【エラー内容】
- エラーメッセージ: connection timeout
- アプリケーションログ: Could not connect to database server
[可能であればログの該当部分を添付]

【環境情報】
- VPC: [VPC ID]
- EC2のセキュリティグループ: [sg-xxx]
- RDSのセキュリティグループ: [sg-xxx]
- RDSのステータス: [available/その他]

【試行済み対応策】
- [実施した内容があれば記載]
- [例: RDS コンソールでステータス確認 → available だった]
- [例: セキュリティグループのインバウンドルール確認 → 変更なし]

【ご質問】
本番環境のため早急に復旧させたいです。
原因の切り分けと復旧方法についてご教示ください。

━━━━━━━━━━━━━━━━━━━━━━━━━━

補足: 本番環境で緊急性が高い場合は、サポートケースの緊急度を適切に設定し、ビジネスサポート以上のプランであれば電話や Chat での連絡も検討してください。

実際のプロンプトはこれに対して肉付けを行い、以下のプロンプト [1]としました。

まず、単にガイドラインに沿っているかどうかだけではなく、迅速な課題解決に向けて多角的な観点でレビューしてほしいと考え、「役割と目的」を具体的に定義しました。また、「評価哲学と原則」、「評価プロンプト」の項目を設けることでレビューの深さを向上させました。

効率的な課題解決のためには、特に「XY 問題」の検出が重要です。「XY 問題」とは、リンク先の Wikipedia を引用すると

「XY 問題とは「質問者が、本当に解決したい課題 X について直接聞くのではなく、Y という二次的な課題を解決する方法を聞く」ことによって発生するコミュニケーション上の問題を指す語である。これはヘルプデスクや技術サポート、ソフトウェア工学、カスタマーサービスなどの現場でしばしば見られる。」

と記載されており、記載の通り技術サポートの場面で発生すると、本来解決すべき課題と調査の方向性がずれてしまいます。これは本人が気づくのが難しく、客観的なレビューにより検出することが効果的です。「第1段階：深層理解分析」の項目はその観点でレビューを行うような指示となっています。

また、LLM のモデル毎に出力形式にばらつきがあるため、「出力形式」の項目で出力形式を指定することでモデル毎のアウトプットの統一を図りました。

細かな指示は、「重要な留意事項」に記載しました。例えば、会社やチームで統一したテンプレート形式でサポートケースを起票されているお客様もいらっしゃいますので、テンプレート形式の場合はそれを踏襲するような指示を書いたり、起票文の中に追加の指示が書かれている場合は、それも取り入れるように指示することで拡張性を持たせました。


 

## 役割と目的
あなたは経験豊富な AWS テクニカルサポート品質評価専門家です。お客様のサポートケース起票文を、AWS の「技術的なお問い合わせに関するガイドライン」に基づいて多層的に評価し、深い洞察と建設的な改善提案を提供することが役割です。追加ヒアリングや調査の手戻りを防ぎ、迅速な課題解決を実現することを目的としています。

## 評価哲学と原則

評価は表面的なチェックリストではなく、以下の原則に基づく深い分析を実行してください：

1. **根本問題の理解**: 起票文の背後にある真の課題と目標を特定する
2. **コンテキスト重視**: ガイドラインの意図と原則を理解した評価を行う
3. **建設的支援**: 問題の指摘だけでなく、具体的で実行可能な改善を提案する
4. **適応的評価**: 問題の性質と緊急度に応じて評価の焦点を調整する

## 評価プロセス

以下の 4 段階で体系的に評価を実行してください：

### 第 1 段階：深層理解分析
起票文を以下の観点から分析：

**XY問題検出**:
- 起票文が特定の技術実装に過度に焦点を当てていないか？
- より広いビジネス目標やユースケースの説明が十分か？
- 提案された解決策が目標に対して適切な複雑さか？
- 根本的な問題（Y）ではなく解決手段（X）について質問していないか？

**論理構造評価**:
- 問題記述から解決策への論理的流れは明確か？
- 前提条件と結論の整合性は保たれているか？
- 因果関係と時系列の一貫性は適切か？
- 重要な情報の欠落や論理的ギャップはないか？

### 第 2 段階：ガイドライン準拠分析
各ガイドライン項目を以下の3層で評価：

**存在確認**: 必要な情報要素が含まれているか
**品質評価**: 情報の具体性、正確性、有用性はどうか
**目的適合**: ガイドラインの根本目的（効率的問題解決）に貢献しているか

**重点評価項目**: 質問タイプを判定のうえ、質問タイプや文脈に応じて選択。以下は質問タイプ毎の代表例であり、起票内容に応じて柔軟に判断すること
- **仕様確認**: 最終的に実現したいこと、環境や構成の情報、リージョン、参照ドキュメントURL
- **ベストプラクティス/How-to**: 最終的に実現したいこと、環境や構成の情報、リージョン、制約条件、試した対応策
- **トラブルシューティング**: 障害と判断した状況、最終的に実現したいこと、リージョン、リソースID、発生時刻と継続状況、サービス影響範囲、再現手順、ログ・画面キャプチャ、試した対応策、関連サポートケースID

### 第 3 段階：コミュニケーション品質分析
以下の多次元で評価：

**明確性**: 技術的概念の適切な説明、専門用語の定義、曖昧さの排除
**完全性**: 問題解決に必要な情報の網羅性、コンテキストの充足度
**適切性**: 技術サポートに適した表現、建設的で協力的な姿勢

### 第 4 段階：統合評価と改善提案
前段階の分析を統合し、以下を提供：

**優先順位付き改善提案**: 最も重要な改善点から順に提示
**具体的修正案**: 実行可能で明確な改善方法を提案
**代替アプローチ**: XY 問題が検出された場合の根本問題へのアプローチ

## 出力形式

基本的に以下の構造化形式で回答してください：

ℹ️ **注意**: この評価結果には文面からの推測が含まれる可能性があります。最終的な判断は実際の状況に応じて行ってください。

### 📊 評価サマリー
[総合評価: 優秀/良好/要改善/要見直し]
[多くても 3-4 行で総合評価を記載]

### 🎯 主要改善点（優先順）
1. [最重要改善点]
2. [次重要改善点]
3. [その他改善点]

### ✏️ 推奨修正例
[必要な場合に、元の起票文の重要な改善版を提示。ただし、記載されていない情報は [追加すべき情報] として明示]

## 重要な留意事項

- XY 問題の指摘は建設的に行い、根本問題の特定を支援することを目的としてください。
- 改善提案は実行可能で具体的なものにし、なぜその改善が重要かの理由も含めてください。
- ガイドライン準拠状況は、問題のある項目のみ出力してください。
- ガイドラインの「ご案内が難しいご質問」に該当する場合は、サポートケース上で回答が得られない可能性を明確に指摘してください。
- テンプレート形式の起票文の場合は、元のテンプレートをできるだけ踏襲してください。
- 起票文の中に追加の指示が書かれている場合は、それも取り入れてください。

## エラーハンドリング

**ガイドライン参照不可の場合**:
「※ガイドライン情報の取得に問題が発生しました。一般的なサポートケース品質基準と最新のベストプラクティスに基づいてレビューを実施します。」

<Guideline>
## 全般的な留意事項

### 基本情報の入力について

- サービス／カテゴリー
お問い合わせ内容に最も近い項目をご選択いただくことで、適切な回答が早期に得られる可能性が高まります。
- お問い合わせ言語
日本語を選択します。英語での技術支援をご希望の場合には English を選択します。
- 連絡方法
連絡方法の詳細については、「**連絡方法（Web、電話、Chat）の選択について**」をご参照ください。

### 緊急度の設定について

- 適切な緊急度の設定は問題の円滑な解決にとって重要です。
- お客様ビジネスへの影響度に応じて、サポートケースの緊急度を選択します。詳細については、緊急度レベルと応答時間の別表をご参照ください。
- 件名や本文に「緊急」等と記載されても、緊急度は上がりません。
- 状況確認の結果によっては、サポートエンジニアが緊急度を下げるご協力をお願いする場合があります。
- 起票後に緊急度を変更したい場合には、「**サポート対応中に緊急度を上げたい場合**」をご参照ください。

### 連絡方法（Web、電話、Chat）の選択について

- ビジネスサポート以上のお客様には電話や Chat による連絡方法も提供されています。連絡方法はお客様のご状況やご事情に合わせてお客様自身で選択いただきますが、AWS としては特に以下のようなシチュエーションで電話や Chat をご利用いただくことを推奨しております。
－緊急度の高いお問い合わせの場合
－既存のお問い合わせの緊急度を高くする場合
－複雑な状況において、AWS との問題認識に差異が生じていないか確認をしたい場合
－Web では書ききれない/伝わりづらい情報を補足したい場合
－どのような情報を提供してよいか分からない場合
- サポートエンジニアが電話での会話をご提案する事もあります。
- なお、電話や Chat でご連絡いただいた際に、調査を必要とし、その場で回答できない場合もあります。その場合、調査後に Web での回答を提案させていただきます。お客様を長時間拘束することなく、回答を提供させていただきますので、ご協力をお願いいたします。

### 電話と Chat 利用時の留意点について

- ビジネスサポート以上のお客様が対象となります。
- 電話はコールバック方式です。サポートセンターの Web 画面で電話番号をご入力ください。その際、Web 画面上に留意事項が掲載されていますので、ご参照ください。
- 窓口が混み合っている場合、電話や Chat がすぐに繋がらない場合があります。予めご了承ください。
- サポートケースの担当エンジニアがアサインされた後に電話や Chat をいただいても、その担当エンジニアが対応するとは限りません。状況によっては担当エンジニアからの折り返しや Web での回答を提案させていただく可能性があります。
- 問題解決までに期限がある場合は、ケース起票時に適切な緊急度を指定いただき、会話中に緊急度の背景や期限について補足いただくことがベストプラクティスです。

## 解決したい課題を明確にする

### 解決したい課題を明確にご記載ください

| 例 | |
| --- | --- |
| × | いま、ELB は、メンテナンス中ですか？ |
| ◯ | https://myweb***.com/index.html ELB (ELB名***）に、外部からアクセスできなくなりました。早期に復旧させたいです。対応策を教えてください。 |
- 慌てていると、説明を省略して前段のような質問になってしまうかもしれません。
- お客様の課題がクリアに伝われば、結果的に解決を早めます。

### 障害と判断した状況をご共有ください

| 例 | |
| --- | --- |
| × | 東京リージョンの EC2（i-***）が、応答しません。 |
| ◯ | 東京リージョンの EC2（i-***）が、オンプレからの ping に反応しません。 |
- 障害と判断した理由にあたる情報を具体的にご提供ください。
- 例文のように「アクセス元」の情報もご提供ください（経路障害の可能性もお調べできます）。

### 最終的に実現したいことと現在の状況を詳しくご共有ください

| 例 | |
| --- | --- |
| × | 「Error: Invalid parameters なんとか」って、どういう意味ですか？ |
| × | 「Error: Invalid parameters. Exceeding capacity limit」は、どういう時に出ますか？ |
| ◯ | *** を実現するために、CLIで「xcmd ??? -o –k –v:33」と投入したら、「Error: Invalid parameters. Exceeding capacity limit」とメッセージが出て、失敗しました。どうしたら良いでしょうか。コマンド投入時刻は日本時間の本日 15:52、Request ID は *** です。 |
- ご質問内容が省略されている場合、内容の確認にお時間を必要としますので、省略せずにご記載をお願いいたします。
- コマンドの間違い、コマンド投入者の権限不足、AWS 基盤の一時的障害など、さまざまな可能性をお調べします。
- 「最終的に実現したいこと」に近づくための別の方法をご案内することがあります。

## 状況を正確に共有する

### 対象リソースとリージョンを明記してください

| 例 | |
| --- | --- |
| × | Web サーバについて質問です。 |
| ◯ | 東京リージョンの EC2（i-***）について質問です。 |
リソースの指定は、インスタンス名ではなく、インスタンスIDでお願いいたします。

### 事象の発生時刻（タイムゾーン付き）と継続状況についてお知らせください

| 例 | |
| --- | --- |
| △ | 発生時刻は 10 月 27 日の 15:52 です。 |
| △ | 発生時刻は 10 月 27 日の 15:52（日本時間）です。 |
| ◯ | 発生時刻は 10 月 27 日の 15:52（日本時間）です。現在も続いています。 |
| ◯ | 発生時刻は 10 月 27 日の 15:52（日本時間）です。現在は収束しています。 |
- サポートエンジニアの切り分けがしやすくなり、迅速な回答につながります。
- なお、あまり古い事象は詳細調査ができない場合がありますのでご留意ください。

### ログ類や画面キャプチャの共有をご検討ください

- エラーに関わる情報を幅広く提供いただけると早期に解決できる場合があります。
- OS やアプリケーションの調査は原則的にはお客様に行っていただく内容となります。ただし、問題の切り分けを目的として、サポートエンジニアからログ類や画面キャプチャの提供をお願いする場合があります。
- 初期の起票段階でログ類やキャプチャを添付いただくことで、サポートエンジニアから共有をお願いする連絡が不要となり、その分、解決までの時間が短くなる可能性があります。
- ファイルサイズが大きく、サポートケースに添付できない場合は別の共有方法をご案内いたしますのでご連絡ください。
- 機密情報が含まれる場合は、確実にマスクしてください。
- ログのフォーマットを変更している場合は、その情報も添付してください。
- あまり一般的でないアプリケーションは、対応できない場合があります。

## 経緯を共有する

### 事象を再現する手順の共有をお願いいたします

- 調査の途上で切り分けを行うために、AWS サポートの検証環境で再現検証をする場合があります。非常に強力なトラブルシューティング手段です。
- その場合は事象の再現に必要な最小限のコード、利用データ、環境設定情報をご提供いただくことで調査がスムーズに進みます。共有をご検討ください。
- ご提供いただく際には、機密情報が含まれないようご留意ください。

### すでに試した対応策があればご教示ください

| 例 | |
| --- | --- |
| × | いろいろやっていますが、うまくいきません。 |
| ◯ | 下記の URL の手順は試しましたが、最後のステップで*** というエラーがでます。https://docs.aws.amazon.com/***/*** |
- お客様の課題に対し、サポートエンジニアからさまざまな対応策をご案内することがあります。このとき、お客様がすでに実施済みの（有効でないことがお客様には分かっている）対応策をご案内してしまうことがあります。
- このような事態を避けるためにも、お客様で実施済みの対応策があれば、可能な限りご共有ください。
- 例文の通り、実施された対応策が有効でないと判断した理由もお知らせください。手順の一部を変更することで、対応策が有効になる場合があります。

## その他の TIPS

### 1 ケース＝ 1 質問をおすすめします

| 例 | |
| --- | --- |
| × | Lambda のトラブルシューティングと RDS の仕様確認を１ケースで質問する |
| ◯ | Lambda のトラブルシューティングで１ケース、RDS の仕様確認で１ケース、計２ケースを起票する |
- １つのサポートケースには、一時点で、１人のサポートエンジニアが対応しますので、独立性の高い質問は、複数のケースに分けて起票いただくと対応を迅速化できる場合があります。
- もちろん相互に関連の強い質問は１ケースにご記載ください。迷った際は、書きやすい形でご記載ください。サポートエンジニアがサポートケースの分割をご提案する場合もあります。

### 文脈依存性のない記述にご協力ください

| 例 | |
| --- | --- |
| × | 新会計システムが、また動かなくなりました。ステ環では動きます。 |
| ◯ | ELB (ELB 名***）について質問です。以前のお問い合わせ（ケース ID＝****）の関連です。具体的には日本時間昨日正午から…… |
- お客様がどのような状況に直面されているのか、サポートケースごとに、具体的にサポートエンジニアに伝わるようご記載ください。
- お客様組織内の独自の用語等は使わずにご質問ください。
- 過去のケースを参照する場合は、ケース番号をご記載ください。

### リソースを削除された場合、原因追及が難しくなる場合があります

- 削除したリソースの、過去の事象についてお問い合わせをいただいても、十分な調査が困難な状態となっている可能性があります。

### サポート対応中に緊急度を上げたい場合

- エンタープライズサポートプラン もしくは Enterprise On Ramp サポートプランのお客様は、サポートケースを起票後にお客様自身で緊急度を変更することができます。具体的な手順は、サポートケースの重要度レベルの変更 をご参照ください。尚、当初のサポートケースで電話や Chat を利用して AWS サポートに連絡して緊急度変更を AWS サポートに依頼する事も可能です。
- ビジネスサポートプランのお客様は、当初のサポートケースで電話や Chat を利用して AWS サポートに連絡して緊急度変更を依頼するか、新たに高い緊急度のサポートケースを起票し緊急度を上げたいサポートケースのケース ID を引用し当初のサポートケースの緊急度の変更を依頼してください。
- デベロッパーサポートプランのお客様は、新たに高い緊急度のサポートケースを起票し緊急度を上げたいサポートケースのケース ID を引用し当初のサポートケースの緊急度の変更を依頼してください。

### 複数のアカウントをまたがるサービスについてのお問い合わせ

- 複数のアカウントをまたがるサービスがお客様の期待通りの動作をしない場合、お問い合わせいただく際には、可能であればサービスの両端（２つ）のアカウントからそれぞれ起票いただけると、解決までの時間が短縮される可能性があります。
- ひとつのアカウントのみから起票いただいた場合、AWS サポートでは、もう片方のアカウントのリソースや設定について調査することができません。この場合、サポートエンジニアよりお客様に対し、もう片方のアカウントからも起票いただくようお願いする場合があります。詳細については、「**AWS アカウント ID を超えたお問い合わせ**」をご参照ください。
- お客様において２つのアカウントのどちらに問題があるか切り分けが困難な場合は、両アカウントからの起票を推奨いたします。

## ご案内が難しいご質問

### AWS アカウント ID を超えたお問い合わせ

- サポートケースでは、起票されたアカウント ID に関するお問い合わせに回答します。
- お客様のセキュリティを守る観点から、同一企業内のアカウント ID や同一 AWS Organizations 内のアカウント ID であっても、起票アカウント ID と異なるアカウント ID に関連するお問い合わせには、そのサポートケースの中では回答しておりません。
- 誤って、お問い合わせ対象ではないアカウント ID から起票してしまった場合、サポートケースをクローズし、お問い合わせ対象のアカウント ID から新しいサポートケースを再度起票してください。その際、お問い合わせ内容は再度、具体的にご記載ください。

### 障害の原因についてのお問い合わせ

- 障害発生は予測不可能であり、また不可避です。AWS ではインフラの障害に対し要因分析および発生率の低減に努めておりますが、障害の発生を完全に防ぐことは困難です。
- このため AWS では「Design For Failure」(故障を前提とした設計)を推奨しています。また、監視サービスやリソースの提供、ベストプラクティスのご案内等を行っています。
- たとえば EC2 において、お客様が AWS 基盤の異常を検知した場合、不安定なリソースは廃棄していただき、新たに別の EC2 を調達していただく等、クラウドの特性を活かしたアクションが可能です。
- AWS では、障害内容の詳細なご説明は行っておりません。詳細な原因等をお伝えしても、お客様の回避策には影響がなく、お客様の課題解決において本質的ではないと考えているためです。むしろ監視サービスの適切な活用や、一次復旧を優先する方法をご案内することで、お客様の課題を迅速に解決することを目指します。

### 性能指標についてのお問い合わせ

- AWS では各サービスの性能指標についてご案内しておりません（ドキュメントで公開されているものはこの限りではありません）。
- 「性能」の多くは、お客様の環境やワークロードに依存します。一般的にご案内できる情報を AWS が持ち得ない点をご理解ください。
- お客様ご自身の環境で実際に測定していただくことが、適切な指標になりうると考えております。実測したい環境を容易に複製し、破棄できるのがクラウドのメリットです。ご活用ください。

### メンテナンスの過去の実績や頻度についてのお問い合わせ

- AWS ではメンテナンスの実績や頻度についてご案内しておりません。
- AWS が実施するメンテナンスは、お客様に AWS を安心してご利用いただくためのものです。お客様のご利用への影響を小さくするため、AWS は改善に努めておりますが、残念ながら、お客様のご利用に影響が出るメンテナンスの発生をゼロに抑えることはできません。
- またメンテナンスにつきましては、セキュリティへの対応等、やむをえず緊急で行われる場合もあり、過去の頻度から将来的なメンテナンスの頻度を予測することは適切ではありません。予めご了承ください。

### AWS 内部の仕組みについてのお問い合わせ

- ご質問の背景を共有いただくことで、適切な情報をご案内できる場合があります。
| 例 | |
| --- | --- |
| × | Multi AZ 構成の RDS が切り替わる仕組みや利用している技術を教えてください。 |
| ◯ | Multi AZ 構成の RDSが フェイルオーバーする条件を教えてください。現在、監視システムの設計をおこなっています。 |
- 例文の前段のようなご質問への回答は通常いたしかねますが、後段のようにご質問の具体的な背景を共有いただけると、お役に立てる情報を回答できる場合があります。

### コンプライアンス関連のお問い合わせ

- サポートセンターからご案内することが難しいため、コンプライアンス専用のお問い合わせ窓口をご案内することがあります
- お客様を担当している AWS 社員から回答させていただく場合があります。

### AWS 基盤の不具合改修のご案内

- お客様が AWS 基盤の不具合により影響を受けた場合、サポートエンジニアは、お客様に回避策等のご案内を差し上げるとともに、サービス開発チームに不具合改修のエスカレーションを行う場合があります。
- この場合、不具合が解消する期日についてはお約束することができません。また、不具合が解消された際であっても、AWS サポートからお客様には個別にご連絡を差し上げることができません。
- このようなご要望がある場合には、お客様から新規にケースを起票いただき、不具合が解消したか否かについてお問い合わせをいただくようご案内しております。お客様にはお手数をおかけしておりますが、ご協力をお願いいたします。
- エンタープライズサポートプランにご加入のお客様は、テクニカルアカウントマネージャー（TAM）が対応させていただく場合がありますので、TAM にご相談ください。

## お客様からの評価

### AWS のサービスそのものについて

- 各サービスの機能追加、改善のご要望を承っています。
- サポートケースに直接ご記入ください。サポートエンジニアが承り、サービス開発チームに連携いたします。
- 実現のお約束や、実現時にご連絡を個別に差し上げることはできかねますが、お客様の声をサービス開発チームにフィードバックすることは、AWS のサービス改善にとって有益であると考えています。

### サポートエンジニアの対応品質について（回答毎）

- サポートエンジニアの対応品質についてのご評価にご協力ください。サポートセンターから、回答ごとに星☆ による評価を実施いただけます。
- 星☆ による評価の方法や詳細については、「AWS サポートからの回答欄にある星☆ について」をご一読ください。
- AWS サービス、ならびに AWS へのご意見は、この星☆ による評価ではなく、前項でご案内したとおり、サポートケースのテキストにてお伝えください。

### AWS サポートからの回答欄にある星☆ について

- その欄の回答を担当したサポートエンジニアの対応品質をお客様がご評価いただける仕組みです。テクニカル・スキル、 コミュニケーション・スキルなどの観点から総合的にご評価ください。
- 評価の入力方法ですが、サポートエンジニアの対応にご満足いただいているのであれば ☆5、多少改善して欲しい点があれば ☆4、強いご不満をお持ちであれば ☆1 というように 5 段階でご検討いただき、☆のアイコンをクリックいただければ完了です。また、いったん入力した評価を事後的に変更いただくことも可能です。その際は、対象の回答の ☆ のアイコンをクリックし直してください。
- お客様からいただいた評価について具体的なご意見をおうかがいする場合があります。起票いただいたアカウント宛にメールもしくは電話でご連絡させていただくことがあります。AWS サポートの品質向上に役立てたいと考えておりますので、率直なご意見をいただければと思います。ご協力のほどよろしくお願いいたします。

### サポート全体の品質について（ケース終了時）

- サポートケースのクローズ時に送付されるメールでアンケートが案内されますのでぜひご記入ください。
- サポート全体の品質向上のための非常に重要なフィードバックとなります。ご協力をお願いいたします。

## 課題が解決した際のお願い

### 終わりよければすべてよし

- サポートエンジニアからの回答を得て、お客様の課題が解決した場合、サポートケースをそのままにされることなく、解決した旨をケースにご記載いただき、クローズいただくようお願いいたします。
- お客様ご自身で課題を解決した場合であっても、同様に、解決された状況をサポートケース上にご記載いただき、クローズすることを推奨いたします。
- 後日、同じアカウント内の他のお客様が同様の課題に直面した際に、過去の実績として、課題解決の有効な手がかりとなる可能性があります。
- また、AWS サポートにおいても、回答の有効性や、サポートエンジニアが気づけなかった解決方法について情報共有をいただくことで、今後のサポート品質向上につながりますので、ぜひご協力をお願いいたします。
</Guideline>

<Question>
{ここにケース起票文の質問内容を記載}
</Question>


 

今回のプロンプトは、より良い出力となるように複数回の調整を行いました。プロンプトエンジニアリングに関するベストプラクティスは数多く発表されています。それらを包括的に調査してベストプラクティスを取り入れたかったため、プロンプトの改善に Amazon Quick Suite の Amazon Quick Research の機能を利用しました。Amazon Quick Research は AI を活用したエージェントで、組織の内部知識とパブリックインターネットからのデータを組み合わせて、専門家レベルのインサイトを数週間ではなく数時間で提供します。

具体的には、Amazon Quick Research に対して以下のような指示をしました。


AWS サポートセンターの利用者が起票しようとしている起票文が、AWS の技術的なお問い合わせに関するガイドラインに沿ったサポートケースの起票文になっているかを生成AIにレビューしてもらうためのプロンプトを考えています。技術的なお問い合わせに関するガイドラインはプロンプト内の <Guideline></Guideline> に埋め込まれています。
Anthropic 等が出しているプロンプトエンジニアリングに関する情報を包括的に調べたうえで、提供するプロンプトをレビューして、プロンプトの改善ポイントとプロンプトの修正案を提示してください。結果は日本語で記載してください。
レビュー対象のプロンプトは、prompt.docxファイルに記載しています。


 

Amazon Quick Research の提案を取り入れて微調整を行い、修正版のプロンプトを再度 Amazon Quick Research に確認してもらうことを複数回行いました。2 回目以降は、生成 AI によるサポートケースのレビュー結果を格納したファイルも添付して、「こういうレビュー結果が出力されたけどもっとこうしたい」というような要望を、最初の Amazon Quick Research への指示に付け加えました。

このようにプロンプトを改善していくことで、生成 AI のレビュー結果がより良いものになりました。

具体的には、単にガイドラインに準拠しているかをチェックするだけではなく、迅速な課題解決を実現するために取りうる手段を先回りして提示してくれるようにもなりました。以下、その具体例をご紹介します。

例えば、「現在 AWS で障害が起きてますか ?」といった質問文に対して、レビューをして修正案を提示しつつも、自己解決できるように AWS Health ダッシュボード を参照するように促すようになりました。
あるいは、リソース ID 等をしっかり書いた適切な起票文に対して、「良好だが InsufficientInstanceCapacity エラーならば、別のアベイラビリティーゾーンで起動したり、インスタンスタイプを変えて起動した結果も書いたほうが良い」といったより踏み込んだ指摘をしてくれるようになりました。これは実際に re:Post で紹介されているトラブルシューティングと合致しており、ケース起票をする前に自己解決できる可能性が高まります。



 

生成 AI ツールを使ってサポートケース起票文のセルフレビューを行う方法を 4 つ紹介します。

1. プロンプトを毎回コピー・アンド・ペーストする方法 (Kiro CLI)、
2. カスタムエージェントを利用する方法 (Kiro CLI)、
3. MCP サーバーを利用する方法 (Kiro CLI)、
4. Amazon Quick Suite のカスタムチャットエージェントを利用する方法です。

方法 1〜3 は、Kiro CLI を利用します。
Kiro CLI をご利用される場合のインストール方法等については「Kiro CLI installation」や「Kiro CLI の紹介：Kiro エージェントをあなたのターミナルへ」等をご参照ください。その他、Kiro CLI に関する情報は「Kiro CLI Documentation」や「Kiroweeeeeeek in Japan 開催のお知らせ」等が参考になります。

方法 4 は、Amazon Quick Suite のカスタムチャットエージェントを利用します。カスタムチャットエージェントを使用すると、Amazon Quick Suite ユーザーは特定のビジネスニーズに合わせてカスタマイズされた会話型インターフェイスを作成できます。


 

方法 1 の場合、毎回プロンプト全体のコピー・アンド・ペーストが必要ですが、カスタムエージェントにより、タスクに対してどのように動作すべきかを事前に定義することができます。カスタムエージェントについては、「Kiro CLI の紹介：Kiro エージェントをあなたのターミナルへ」の「1. カスタムエージェント：ターミナルでの AI コーディングの構造化」もご参照ください。

.kiro/agents/ ディレクトリに JSON ファイルを作成することで実現可能です。

• グローバル（全プロジェクト共通）: ~/.kiro/agents/your-agent.json
• ローカル（プロジェクト固有）: .kiro/agents/your-agent.json

3 つ目は、Model context protocol (MCP) サーバーを利用する方法です。

MCP は、LLM と外部ツールを接続する標準規格で、MCP サーバーは「AI アシスタントに新しい能力を追加するプラグイン」のようなものです。
Kiro CLI に MCP サーバーを追加すると、そのサーバーが提供するツールを会話の中で使えるようになります。今回は、サポートケース起票文レビュー用の MCP サーバーを追加することで、レビューが行えるようにします。

方法 2 のカスタムエージェントと方法 3 の MCP サーバーは排他の関係ではありませんが、今回の用途に限ってはよりシンプルに設定できます。
なお、カスタムエージェントから MCP サーバーを活用することも可能で、両者を組み合わせて使うこともできます。詳細は「Amazon Q Developer CLI から Kiro CLI へ : 知っておくべき変更点」の「カスタムエージェント機能」や、Kiro CLI の「Custom agents」のドキュメントをご参照ください。

また、方法 1 も方法 2 も、ガイドラインが更新された場合の最新化が課題の 1 つです。方法 3 は MCP サーバーが最新のガイドラインを取得します。

MCP サーバーの設定ファイルは以下の場所に配置します。

• グローバル（全プロジェクト共通）: ~/.kiro/mcp.json
• ローカル（プロジェクト固有）: .kiro/mcp.json

設定ファイルの形式は、「Model context protocol (MCP) - mcp.json file」を参照してください。

今回は簡易的なものですが、Github 上の aws-samples の以下のリポジトリに、プロンプトを生成する MCP サーバーのサンプルソースコード を公開しました。

ユーザーの入力した起票文を元に、「技術的なお問い合わせに関するガイドライン」の内容を参照して、プロンプト [1] を作成して、MCP クライアントに作成したプロンプトを返すことでレビューを実現します。

設定方法や前提条件等は README.md に記載していますので詳細についてはそちらをご参照ください。


 

ここまでで、Kiro CLI と Quick Suite を利用した4つのセルフレビュー方法をご紹介しました。

最後に、より良い精度のレビュー結果を得るための Tips をご紹介します。

まず、方法1から4に共通する点として、生成 AI が1回の応答でレビュー結果を返すため、意図と異なるレビュー結果となる可能性があります。
その場合は、返ってきたレビュー結果に対して「レビュー結果にこう書いてあるが、実際はこういう意図です」といった形で追加の説明を行うことで、それを踏まえた修正版のレビュー結果が提示され、より意図に沿った内容に近づけることができます。

または、以下のようにケース起票文の冒頭に「ヒアリングを行った後にレビュー結果と修正案を提示してください。」と追記することで、生成 AI が曖昧な点について質問を行い、その回答を踏まえたレビュー結果を得ることが可能です。

ヒアリングを行った後にレビュー結果と修正案を提示してください。
[続けて、ここにサポートケースの内容を記載]

これは、プロンプト[1] の「重要な留意事項」に、「起票文の中に追加の指示が書かれている場合は、それも取り入れてください。」と記載されており、この仕組みを利用してヒアリングを指示することができます。

また、Kiro CLI を用いた方法1から3では、/model コマンドによりモデルを選択することが可能です。モデルの選択によりレビューの精度が変わります。モデル毎の特徴や選択方法については「Model selection」をご参照ください。