AWSエンジニアの私が生成AIで変わった働き方、考え方(2025-06)
2025.06.18生成AIが流行りだしてから、 AWSエンジニアとしての働き方やマインドが結構変わってきたなと感じています。
少なくともここ一年で生成AIとチャットすることが常態化しました。 最近では Claude Code がまさに仕事の進め方を変えつつあります。
本ブログは私の振り返りも兼ねて、 現時点で思っていることをダンプしたポエムです。 (移り変わりが激しいので、来年にはまた変わっていそうです)
目次
- 要約/翻訳
- Finding や Notification を要約/翻訳してもらうようになった
- Terraform や CDK の diff を要約してもらうようになった
- コーディング/コマンド
- コードやSQLを書くことが減った
- ちょっとしたLambda関数を作る心理的ハードルが下がった
- Emacsのカスタマイズが捗った
- パイプにLLMを活用するようになった
- コミュニケーションや学習
- 文章を整理してもらうことが増えた
- 運用ドキュメントの一部をGitHubに移行した
- 試験勉強に生成AIを活用するようになった
- タスク管理/推進
- 1日のやったことをまとめてもらうようになった
- 良い差分が出るようなタスク管理をするようになった
- Claude Code とタスク管理/推進をするようになった
要約/翻訳
Finding や Notification を要約/翻訳してもらうようになった
GuardDuty や Security Hub の検出結果JSONや、 AWS Health からのメンテナンス通知の長文を とりあえず生成AIに要約/翻訳してもらう癖が付きました。
使い方はこんな感じです。
```
(長い検出結果JSON)
```
これなに
AI-Starter[1] で GuardDuty 検出結果を調査
「これなに」は生成AIに一番使っているフレーズな気がします。
要約された内容を読んでから、 実物の要所要所を見ていきます。 生成AIによる要約は、ネクストアクションの 方向性を決めるにはうってつけです。
将来的には Bedrock で通知する仕組みも作って、 利用部門により分かりやすいセキュリティ通知をお届けしたいですね。
Terraform や CDK の diff を要約してもらうようになった
Terraform や CDK の diff もよく要約してもらっています。
- 作られる予定のリソース教えて
- plan/diff に出てきている この Warning は何？
あたりをよく質問しています。
terraform plan の結果をサマってもらう
最近 CDKも少し触っているのですが、 バージョンアップなどを実施すると、 内部的に管理しているリソースの変更が diff にたくさん出てきます。 それを読み取ってくれるのがとてもありがたいですね。
cdk diff の結果をサマってもらう
コーディング/コマンド
コードやSQLを書くことが減った
もともとそんなにコードをがっつり書く働き方はしていませんでした。 たまに業務効率化としてシェルスクリプトを書いたり、 どうしてもLambda関数で実現したい内容があったら PythonでLambda関数のコードを書いたりしていました。
生成AIのおかげで、 「たまにちょっとコードを書く」から 「ほとんど自分でコードを書かない」に変わってしまいました。 軽量なものであれば、 だいたいミス無く生成AIが作ってくれるのです。
同様にSQLも生成AIにたたき台を作ってもらうようになりました。 具体的なユースケースとしては、 CURのコスト分析や、VPC Flow Logs の解析あたりです。
また、まだ試験的ではありますが、 そもそもSQLを書かずに、 自然言語での問い合わせによる分析も実現したいです。 例えば DuckDB MCPサーバーを使って 以下のようなコスト分析自動化を試したりしていました。
ちょっとしたLambda関数を作る心理的ハードルが下がった
生成AIにより、Lambda関数作成の 心理的ハードルがだいぶ下がりました。 参照権限の範囲内、 もしくは軽量な処理ぐらいであれば 「積極的にLambda関数で自動化しよう」 という気持ちになっています。
例えばセキュリティ通知の仕組みや、 各種AWSリソースの棚卸し処理、 定期的なレポート生成などです。
今までだったら Step Functions でがっちりフローを組もう、 みたいなことを考えていました。 ただ、ASL のような「制限のある記述形式」よりも 自由度の高いLambdaのほうが 生成AIには向いているのでは、とも感じています。
とはいえ Lambda関数が増えてくると 維持運用がチリツモで大変になってきます。 そのためにも最低限 GitHubなどで管理して、 生成AIと協働してメンテナンス負荷を抑えられる 仕組みは整えたいですね。
Emacsのカスタマイズが捗った
いきなり Emacs の話？と思われるかもですが、 私は普段 Emacs org-mode を使って タスク管理や推進を行っています(参考ブログ)。 そんな Emacsですが、 生成AIによってカスタマイズが格段にやりやすくなりました。 枯れた技術、Emacs Lispとの相性も抜群です。
例えば、org-agenda(タスクの集約ビュー) の見た目を 自分好みに調整したりしています。 Emacs Lisp を書くのは得意ではないのですが、 生成AIのサポートがあれば気軽に実装できます。
org-agenda を自分好みにカスタマイズ
カテゴリ別の色分けやアイコン表示など、 以前は大変で諦めていた見た目の改善も 生成AIがあれば実現できるようになりました。
パイプにLLMを活用するようになった
シェルスクリプトのパイプで生成AIを活用するようになりました。 使っているのは llm というツールです。 以下ブログにも紹介しています。
# 243 aws
# 127 git
# 77 cd
# 71 pbp # aliased to pbcopy
# 70 pbc # aliased to pbpaste
# 47 llm # ⭐️NEW!
# 42 cut
# 41 cat
# 38 mkdir
# 37 l # aliased to ls -1A
help コマンド出力をインプットさせて質問したり、 awsやcurlコマンドの出力を翻訳/要約させたりしています。
awsのhelpコマンドから使い方を教えてもらう
AWS What's New をサマってもらう
ただ、後述する Claude Code によって 使う頻度は少し落ち気味です。
コミュニケーションや学習
文章を整理してもらうことが増えた
伝えたいことがあるときに、 生成AIに文章を整えてもらうことが増えました。 イメージはこんな感じです。
- (伝えたいことを思ったままに書きなぐる#1)
- (伝えたいことを思ったままに書きなぐる#2)
- (伝えたいことを思ったままに書きなぐる#3)
- ...
上記を分かりやすく説明したい。良い感じの文章作って。
必要に応じて「技術的な専門用語をなるべく使わずに」 や「失礼のないように、でも かしこまりすぎないような依頼文に」 みたいな感じで調整しています。
SlackやBacklogでのコメント返信などで活躍中です。 あまり本筋ではない部分で悩むことが減り、 脳のリソース消費を抑えられています。
運用ドキュメントの一部をGitHubに移行した
社内のエンジニアチームにてナレッジサイト(Classmethod Cloud Guidebook[2])を運営しています。
運営に必要なドキュメントの一部を Notion から GitHub に移行しました。 例えば 執筆ガイドラインやレビューガイドラインなどです。
理由としては Claude Code や Cursor、GitHub Copilot といった 生成AIツールを活用しやすくするためです。 「このガイドラインに沿ってレビューして」や 「この手順に沿って雛形を作成して」といった コンテキストを付与した依頼ができるようになります。
まだ発展段階ですが、 この流れを機に暗黙的なアクションや考えを、 どんどん明文化していきたいと考えています。
現在検証中のClaude Code Actions。執筆体験向上にも役立ちそう
試験勉強に生成AIを活用するようになった
現在 AWS 全冠に向けて頑張ってます。 そのAWS試験の勉強も生成AIのおかげで、 だいぶやりやすくなったと感じています。
生成AIチャット画面で AWSサービスについてのあれやこれを聞きながら、 もう片方でAWS公式ドキュメントや参考記事/動画を確認する、 みたいな勉強スタイルです。
- 自分の分からないところ/気になっているところを言語化して質問する
- 自分が解釈したことを合っているかどうか確認する
上記を生成AIと対話しながら進めます。 インプット効率が良い気がします。
そこまで活用はしていませんが、 試験のサンプル問題を作らせる試みもやっています。
タスク管理/推進
1日のやったことをまとめてもらうようになった
まず、生成AIを使い始めてから、 タスク管理を git管理に移行しました。 もともと Emacs org-mode でプレーンテキスト管理していたので、 特に問題なく移行できました。
そして 1日の終わりに、その日に進めたことを 生成AIにまとめてもらうようにしています。 依頼内容はシンプルで、 git diff -U0 の結果を添付して、 用意したプロンプトで日報を生成してもらいます。 プロンプトには出力形式や記載ルール、 ファイル構造の説明を記載しています。
生成AIの出力サンプル
精度は良い感じです。 特に Claude Sonnet 4 になってからは 手直しがかなり減りました。
良い差分が出るようなタスク管理をするようになった
さきほどの内容に関連する内容です。 良い感じの「やったことまとめ」を出すために "差分" を意識しました。
例えば Emacs org-mode の Checkboxes 機能を使えば、 チェックボックスおよびその進捗率を出せます。
org-modeのCheckboxesサンプル
チェックの入っている割合によって、 見出し部分が [80%] や [5/8] といった感じで 自動計算されます。これが差分として現れます。 実績を出す際に「 50% → 80%: XXXの実装 」 といった形で進捗の変化を示せるようになります。
また、以下のような点を より意識するようになりました。
- 課題を先に立てる : 事前に目的/目標を明文化しておく
- やることを先にリスト化する : 進捗を追跡しやすくする
- 実施したログをテキストに残す : 実行ログや調査内容、参考URLなどを記録に残す
(こう書くと当たり前っぽい感じがしますね。 でも、だらしないときや、忙しいときは疎かになってしまいがちです)
Claude Code とタスク管理/推進をするようになった
Claude Code をタスク管理/推進で使い始めてから、 org-mode の管理方法が大幅に変わりました。
もともとは「1ファイル = 1案件」で管理していました。 膨大な量の情報を管理できるのが org-mode のメリットなので、 多いもので数千行の orgファイルができていました。
しかし、それでは Claude Code に読み込ませたときに コンテキストがとても膨らみます。 AIエージェントフレンドリーでは無かったのです。
そのため 基本的に「1ファイル = 1タスク」にしました。 以下のイメージです。
タスク管理ワークスペースの Before/After (ファイル名やサイズは適当です)
管理方法を変えてから、 タスクの推進も Claude Code と協働 しやすくなりました。 例えば Claude Code に調査や要約を依頼して、 その結果を直接 buffer に追記してもらっています。 一緒に進めている感覚をとても感じます。
Claude Code とのタスク推進イメージ
実のところ、まだ本格的に使い始めて1週間程度です。 この1週間で、自分の中ではかなりインパクトを感じています。自分の手を動かす作業が、どんどんClaude Codeに置き換わっていく感覚です。
おわりに
思ったことを書き殴ってみました。
現時点で、馴染んでいるAIツールをまとめるとこんな感じです。
| ツール | 主な用途 | 使う場所 | ここ最近の使用頻度の遷移 |
|---|---|---|---|
| AI Starter | チャットツール | Chrome | 高 → 中 |
| llm | 単発のLLM実行 | iTerm2 | 高 → 中 |
| gptel | 単発のLLM実行 | Emacs | 中 → 中 |
| Claude Code | AIエージェント | iTerm2 | 低 → 高 |
やっぱり Claude Code の影響は大きいです。 先週から本格的に使い始めたのですが、あっという間に馴染みました。(AWS CLIコマンドを作成/実行することもほとんど無くなると思うと少しさみしい)
AIツールは便利だと思う一方で、 自分の考え方や立ち回りも変えていかないとなあという気持ちになっています。 より上位レイヤーを意識する必要性を感じていて、 大事なのは目標や目的を意識すること、 そして「考えていることを頭の中から ひねり出してAIに渡す 」力なのかなと思いました。 言語化が更に大事になってくるのでは無いでしょうか。
以上、また来年には使っているツールも変わっている気がしますが、現時点の思っていることでした。
