- はじめに
- AWSインフラ改修業務における従来の課題
- 今回のタスクにおける要点
- q chatを有効活用するための事前準備
- AWS CLIでAWSリソースを調査する
- 開発環境で検証する
- q chat活用の成果
- まとめ
はじめに
Amazon Q Developerのq chatをAWSインフラリソースの改修業務で活用したところ、作業体験が良かったので記事にしました。 本記事では、実際の業務での活用を通じてq chatでどのように作業効率を向上させたか、その方法などをご紹介します。
Amazon Q Developer / q chat とは
前回投稿した以下の記事をご参照ください。
対象読者
- AWS環境で開発・運用を行う開発者、インフラエンジニア
- Amazon Q DeveloperなどのAIエージェントの利用経験がある、または興味がある方
- プロジェクトの生産性向上や作業効率化に関心がある方
環境
- AWSアカウント
- Amazon Q Developer
- ローカルマシンにAmazon Q Developer CLIとAWS CLIがインストール済みであること
- ターミナル（コマンドライン）の基本的な操作知識
AWSインフラ改修業務における従来の課題
本番環境で稼働中のAWSリソースを操作する際、以下のような課題に直面したことはないでしょうか？特に開発・検証環境が用意されていない場合やIaCでインフラをソースコード管理されていない場合、以下のような作業がボトルネックになりがちです。
1. リソースの調査
- AWSコンソールやAWS CLIを駆使して現在の設定状況を確認
- 関連するリソースの依存関係を調査
2. 開発環境での再現・検証
- 本番環境と同等の構成を開発環境に構築
- 開発環境でリソース操作を実施
- 開発環境で検証して想定外の影響がないことなどを確認
人手でこれらの作業を行うと、本番環境での実作業に至るまでに多くの準備作業が必要となり、構成が大規模かつ複雑になるほど作業時間と負荷が増大することや、 作業の心理的な負荷も高くなるといった課題がありました。 そこで今回はこれらの課題を解決するためにq chatを利用しました。
今回のタスクにおける要点
前提条件
q chatを利用して作業を進める前に大元の設計に関する資料や要件が定義されたドキュメントがすでにあることを前提とします。 今回はDesignDocベースのフォーマットであらかじめ設計方針や具体構成を作成していたため、その内容をコンテキストとして利用しました。
本記事におけるタスクについて
今回の記事でご説明する範囲のタスクは具体的には 移行により2つに分かれたS3バケットのALBログをAthenaを使って横断的に解析する技術検証を実施する です。
大元の要件としては 複数のバケットにまたがるログを解析できることを証明し、関連する手順書を改修すること です。
よって手順書の改修に関するキーワードもところどころ出てきますが、主に 開発環境での検証作業 に焦点を当てて記事を構成しています。
以降の内容はこれらを念頭に読み進めてもらえればと思います。
q chatを有効活用するための事前準備
まずはタスクを進める上でポイントとなる コンテキストの読み込み と、進捗管理をさせるための 進捗計画 を実行させます。
設計や要件定義のドキュメント（designdoc.md）が存在するディレクトリでq chatを開始します。
ユーザー実行
$ q chat ✓ awslabsaws_diagram_mcp_server loaded in 2.16 s ✓ aws_doc_mcp loaded in 3.59 s ✓ awslabscdk_mcp_server loaded in 3.87 s ⢠⣶⣶⣦⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣤⣶⣿⣿⣿⣶⣦⡀⠀ ⠀⠀⠀⣾⡿⢻⣿⡆⠀⠀⠀⢀⣄⡄⢀⣠⣤⣤⡀⢀⣠⣤⣤⡀⠀⠀⢀⣠⣤⣤⣤⣄⠀⠀⢀⣤⣤⣤⣤⣤⣤⡀⠀⠀⣀⣤⣤⣤⣀⠀⠀⠀⢠⣤⡀⣀⣤⣤⣄⡀⠀⠀⠀⠀⠀⠀⢠⣿⣿⠋⠀⠀⠀⠙⣿⣿⡆ ⠀⠀⣼⣿⠇⠀⣿⣿⡄⠀⠀⢸⣿⣿⠛⠉⠻⣿⣿⠛⠉⠛⣿⣿⠀⠀⠘⠛⠉⠉⠻⣿⣧⠀⠈⠛⠛⠛⣻⣿⡿⠀⢀⣾⣿⠛⠉⠻⣿⣷⡀⠀⢸⣿⡟⠛⠉⢻⣿⣷⠀⠀⠀⠀⠀⠀⣼⣿⡏⠀⠀⠀⠀⠀⢸⣿⣿ ⠀⢰⣿⣿⣤⣤⣼⣿⣷⠀⠀⢸⣿⣿⠀⠀⠀⣿⣿⠀⠀⠀⣿⣿⠀⠀⢀⣴⣶⣶⣶⣿⣿⠀⠀⠀⣠⣾⡿⠋⠀⠀⢸⣿⣿⠀⠀⠀⣿⣿⡇⠀⢸⣿⡇⠀⠀⢸⣿⣿⠀⠀⠀⠀⠀⠀⢹⣿⣇⠀⠀⠀⠀⠀⢸⣿⡿ ⢀⣿⣿⠋⠉⠉⠉⢻⣿⣇⠀⢸⣿⣿⠀⠀⠀⣿⣿⠀⠀⠀⣿⣿⠀⠀⣿⣿⡀⠀⣠⣿⣿⠀⢀⣴⣿⣋⣀⣀⣀⡀⠘⣿⣿⣄⣀⣠⣿⣿⠃⠀⢸⣿⡇⠀⠀⢸⣿⣿⠀⠀⠀⠀⠀⠀⠈⢿⣿⣦⣀⣀⣀⣴⣿⡿⠃ ⠚⠛⠋⠀⠀⠀⠀⠘⠛⠛⠀⠘⠛⠛⠀⠀⠀⠛⠛⠀⠀⠀⠛⠛⠀⠀⠙⠻⠿⠟⠋⠛⠛⠀⠘⠛⠛⠛⠛⠛⠛⠃⠀⠈⠛⠿⠿⠿⠛⠁⠀⠀⠘⠛⠃⠀⠀⠘⠛⠛⠀⠀⠀⠀⠀⠀⠀⠀⠙⠛⠿⢿⣿⣿⣋⠀⠀ ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠈⠛⠿⢿⡧ ╭─────────────────────────────── Did you know? ────────────────────────────────╮ │ │ │ Use /model to select the model to use for this conversation │ │ │ ╰──────────────────────────────────────────────────────────────────────────────╯ /help all commands • ctrl + j new lines • ctrl + s fuzzy search ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 🤖 You are chatting with claude-4-sonnet
ユーザー実行
>designdoc.mdを読み込んで内容を把握してください。
まずは全体的な計画を立てるところから始めます。
チェックリストを作ってドキュメント化してください。
それを元に私とあなたで方針を擦り合わせながらタスクを遂行してもらう認識です。
q chatの対応 q chatはまずDesignDocを読み込んで内容を把握し、その後段階的にチェックリストを作成してくれました。
最終的に生成されたチェックリスト（一部抜粋）
# フェーズ1 手順書改修タスク チェックリスト ## 重要な日程情報 - **ログ移行実施日**: 2025年2月12日頃 - **旧ログ完全削除予定**: 2026年2月12日頃（移行日の1年後） ## 1. 事前準備・現状調査 - [ ] 既存手順書の内容確認 - [ ] 移行前後のバケット対応関係の整理 - [ ] 調査時に考慮すべき制約事項の洗い出し ## 2. 手順書改修内容の設計 - [ ] 改修方針の決定 - [ ] 必要な改修内容の詳細化
進捗管理の重要性
タスクが長時間の作業となる場合、q chatが管理するコンテキストウィンドウが溢れるとq chatはそれまでの会話内容を要約または削除してしまいます。
q chatの出力（実際に発生したオーバーフローメッセージ）
The context window has overflowed, summarizing the history... ✔ Conversation history has been compacted successfully!
この状態になると、それまでの詳細な作業履歴や中間成果物の情報が完全に失われるわけではありませんが、細かいニュアンスや特定の指示といったコンテキストが失われる可能性があります。
Amazon Q Developerの公式ドキュメントでは、コンテキストウィンドウの制限について以下のように説明されています：
Amazon Q Developer maintains context within a conversation, but there are limits to how much conversation history can be retained. When the context window becomes full, older parts of the conversation may be summarized or removed to make room for new interactions.
参考URL: Amazon Q Developer の制限事項
この制限により、長時間の複雑なタスクでは作業の継続性を確保するための対策が必要になります。
また上記のケース以外に、/quitコマンドで意図的にq chatを終了して作業を中断することもあるかと思います。
この場合、次回q chat起動時には前回までの作業内容を完全に忘却した状態からスタートします。
こうなると全体タスクに対して、どこまで作業が進んでいたのかをq chatが判断できず、うまく作業を継続できない状況に陥る可能性があります。
この対策としても、先述の指示で作成させた進捗管理のドキュメントが機能します。
今回はメインのチェックリスト（task_checklist.md）と、作業の進捗記録（task_progress.md）が作成されたので、個別タスクの完了のタイミングでそれぞれのリストを更新させるように進めました。
こうすることで、コンテキストウィンドウが溢れてしまったり作業を途中で中断しても、それまでの作業状況を理解した上でq chatが作業を再開できるような状況ができます。
ユーザー実行（作業中断からの再開時の指示例）
>チェックリスト（task_checklist.md）と進捗記録（task_progress.md）を確認して、続きから作業を再開してください。
q chatの出力
チェックリストを確認しました。
「2. 手順書改修内容の設計」で「必要な改修内容の詳細化」が未完了ですね。
既存手順書の構造を分析して、具体的な改修箇所を特定します。
ちなみに先述のオーバーフローメッセージが出力されたあとも、q chatはチェックリストを参照して作業状況を把握していることも確認できました。
q chatの出力（オーバーフローメッセージ直後の出力）
> Based on the conversation summary and the checklist items you've highlighted, ...
AWS CLIでAWSリソースを調査する
自然言語でCLIを実行
個人的にq chatを利用していて最も体験が良いと思う機能は、自然言語でAWS CLIコマンドを実行してくれることです。
ユーザーの実行
>dev-profileプロファイルを使って、S3バケット一覧を確認してください
q chatの出力
🛠️ Using tool: use_aws (trusted) ● Running aws cli command: Service name: s3api Operation name: list-buckets Parameters: - query: "Buckets[].{Name:Name,CreationDate:CreationDate}" Profile name: dev-profile Region: ap-northeast-1 Label: S3バケット一覧の確認 [ { "Name": "example-bucket-1", "CreationDate": "2025-02-12T05:00:00+00:00" }, { "Name": "example-bucket-2", "CreationDate": "2023-05-15T02:30:00+00:00" } // ... 他のバケット情報 ]
従来は任意のS3バケット内のプレフィックスやオブジェクトを把握する際、実際にAWSコンソールへサインインして確認しに行くか、AWS CLIを実行してリストアップする作業が必要でした。
大量のバケットに対する操作やバケット内に大量のプレフィックスが存在する場合、それらを手作業で全て把握するためには時間がかかっていましたが、q chatは自然言語で指示するだけでAWS CLIを実行して、結果情報もよしなに出力してくれます。
注意すべきポイント
q chatでAWS CLIを実行できることは利便性が高いですが、一方で注意すべきポイントがあります。
1. AWS CLI プロファイル設定
リソースを調査する際や特に本番環境で作業する場合、対象のタスクが構築作業や設定変更作業ではない限り必ず読み取り専用権限のプロファイルを指定します。
書き込み・編集権限が付与されているプロファイルは、意図しない変更を防ぐためできる限り使用を避けるべきです。
デフォルトではAWS CLIコマンドを実行する前に確認メッセージはプロンプトに出力されますが、事故を起こさないためにも読み取り専用権限のプロファイルを使用することを強く推奨します。
多重防止策として、利用する権限について指示をするのも良いと思います。
ユーザーの実行（安全な指示例）
>dev-profileプロファイルを使って、読み取り専用でバケット一覧を確認してください
2. API制限への配慮
q chatはAWS CLI実行によるリクエスト数やその実行に対する負荷を気にせずに実行してしまう可能性があります。
例えば、本番環境の構成によってはAWS CLI実行によってコールされるAPIが他の稼働中システムによって実行されるAPIとバッティングしてしまった場合にスロットリングが発生したり
レート制限に抵触してしまうと、システムの障害に発展してしまう可能性があります。
こういったことを避けるためにも、特に本番稼働中のシステムがあるAWS アカウントに対してq chatでAWS CLIを実行させる場合は、事前に制限を確認しておいて必要に応じて実行頻度を調整させるなどの考慮が必要です。
開発環境で検証する
今回のプロジェクトでは、実際に開発環境で技術検証を実施して、DesignDocに記載されている要件を満たすことができるかどうかのフィジビリティ調査を実施する必要がありました。
q chatを利用して、この技術検証プロセスを実施させます
1. 開発環境での検証環境構築
本番環境を模擬した検証用のリソースを開発環境に構築します。
ユーザー実行
>開発環境（profile=default）で本番環境を模擬した検証環境を構築してください。 まずは、移行前・移行後の両バケットを作成し、意図した検索結果が得られる程度のサンプルデータ（ログオブジェクト）を本番環境からローカル環境へダウンロードして開発環境に同じプレフィックスでアップロードしてください。 その後、クエリを実行できるAthena環境も構築してください。
q chatの実行プロセス
プロンプトの入出力結果を記載すると非常に長くなるので、実行された主なタスクとそのコマンド/クエリの概要をいくつかピックアップました。
S3バケット構築
# 移行前/後バケット模擬環境 aws s3 mb s3://test-elb-prd-access-log-verification-123456789012 --profile default aws s3 mb s3://test-elb-dev-access-log-verification-123456789012 --profile default # 移行前/後サンプルデータのアップロード aws s3 cp verification_samples/pre_migration/ s3://test-elb-prd-access-log-verification-123456789012/yyyy/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/2025/02/12/ --recursive --profile default aws s3 cp verification_samples/pre_migration/ s3://test-elb-dev-access-log-verification-123456789012/yyyy/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/2025/02/13/ --recursive --profile default
Athena環境構築
-- データベース作成 CREATE DATABASE IF NOT EXISTS alb_log_verification_db; -- 移行前バケット用テーブル作成 CREATE EXTERNAL TABLE alb_log_verification_db.alb_logs_pre_migration ( type string, time string, elb string, client_ip string, client_port int, target_ip string, target_port int, request_processing_time double, target_processing_time double, response_processing_time double, elb_status_code int, target_status_code string, received_bytes bigint, sent_bytes bigint, request_verb string, request_url string, request_proto string, user_agent string, ssl_cipher string, ssl_protocol string, target_group_arn string, trace_id string, domain_name string, chosen_cert_arn string, matched_rule_priority string, request_creation_time string, actions_executed string, redirect_url string, lambda_error_reason string, target_port_list string, target_status_code_list string, classification string, classification_reason string, conn_trace_id string ) STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3://test-elb-prd-access-log-verification-123456789012/yyyy/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/' TBLPROPERTIES ( 'projection.enabled'='true', 'projection.day.type'='date', 'projection.day.range'='2025/02/01,NOW', 'projection.day.format'='yyyy/MM/dd', 'storage.location.template'='s3://test-elb-prd-access-log-verification-123456789012/yyyy/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/${day}/' ); -- 移行後バケット用テーブル作成 （割愛）
特に、Athenaのテーブル作成のクエリに関しては公式ドキュメントを人手で読み込んで試行錯誤を繰り返す作業は慣れていなければ数時間かかることもあると思いますが、 q chatがよしなにAWS CLIでクエリを実行してAthenaの環境構築まで数分で実行してくれました。
2. 実際に解析を実行する
環境ができたのでクエリを実行して妥当性を確認します。
ユーザー実行
開発環境に構築したAthena環境で新旧両バケットのログデータに跨った検索結果が得られるようにクエリを実行して
q chatの実行結果
SELECT COUNT(*) FROM ( SELECT *, 'pre_migration' as source FROM alb_logs_pre_migration UNION ALL SELECT *, 'post_migration' as source FROM alb_logs_post_migration ); -- 結果: 28件
クエリの実行から結果までq chatの指示で完結しました。
q chat活用の成果
作業時間の大幅削減
今回の個別タスク（リソース調査と開発環境での検証）に要した時間を試算したところ、従来の方法と比較して作業コストを約50%削減できる見込みであることが分かりました。
従来の方法: 1.5日
- リソース調査: 0.5日
- 関連情報の収集・分析: 0.5日
- 検証環境での確認: 0.5日
q chat活用後: 半日
- 全体計画立案: 30分
- リソース調査（AWS CLI実行）: 2時間
- 開発環境での技術検証: 2時間
- 情報の整理・分析: 1時間
もちろん前提として、個別タスクを精度高く実行させるためのコンテキスト（今回はDesignDocなど）が充実している必要があるため、それらのドキュメント作成などを含めた全体のタスクとして捉えると半分以上の作業コスト削減になるとは言い切れません。 また、指示を出す人のタスクに対する習熟度、アウトプットに対する理解度も作業時間を左右する重要なポイントとなります。 それらを差し引いて今回のような個別タスクに切り出して考えると、全てを人手で作業する場合と比較して全体的にタスク進行の体験も非常に良く、作業負荷の軽減や品質向上も期待できそうな感覚を得ることができました。
まとめ
q chatを活用することで、従来は数日かかっていたAWSリソースの調査・分析作業を1日で完了できるようになりました。特に以下の点で大きな効果を実感しました。
- 体系的なドキュメント管理: 進捗の可視化と継続性の確保
- 自然言語でのCLI実行: コマンド構文を調べたり試行錯誤する時間が減少
- 実証的な技術検証: 開発環境で実際動作確認するための環境構築までのスピード感と品質
また本記事で触れたように、意図しないリソース変更を防ぐための権限管理や本番環境のシステムの安定稼働を維持するための配慮、そして長時間の作業でも安定して成果を出すためのコンテキスト管理など、AIエージェントを効果的かつ安全に使いこなすための理解が不可欠なことを体感できました。
今後もq chatをはじめとしたAIエージェントを効果的で価値ある使い方を模索しながら、生まれた時間をより創造的な活動に活用していきたいと思います。
