本ブログは 2026 年 8 月 5 日現在の内容を元に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。AWS 認定に上位・下位関係があることはご存知の方も多いかと思います。しかし、 「具体的にどの認定を更新すると、どの認定が一緒に更新されるのか」 を正確に把握されている方は意外と少ないのではないでしょうか ? 今回は、この上位・下位関係を図とともに整理してお伝えします。 はじめに AWS 認定には Foundational、Associate、Professional、Specialty の 4 カテゴリがありますが、このうち Specialty 以外の 3 カテゴリには明確な上位・下位関係が定義されています。この記事では、その関係を図で整理しつつ、再認定時の活用方法と注意点を解説します。 上位・下位関係の定義されている AWS 認定の 3 つのカテゴリ 上位・下位関係の定義されている AWS 認定は、以下の 3 つのカテゴリに分かれており、上位カテゴリの認定を取得 (または更新) すると、その下位にあたる認定も自動的に更新されます。 Professional (上級): Solutions Architect Professional、DevOps Engineer Professional など、青緑のバッジのもの Associate (中級): Solutions Architect Associate、Developer Associate など、青いバッジのもの Foundational (基礎): Cloud Practitioner、AI Practitioner など、グレーのバッジのもの ※ 上記に加えて、Specialty (専門) という別カテゴリの認定もあります (後述)。 具体的な上位・下位関係は以下の通りです。 Solutions Architect 系 Solutions Architect Professional (上位) └→ Solutions Architect Associate (中位) └→ Cloud Practitioner (下位) DevOps Engineer 系 DevOps Engineer Professional (上位) ├→ CloudOps Engineer Associate (中位) ├→ Developer Associate (中位) └→ SysOps Administrator Associate (中位) └→ Cloud Practitioner (下位) Generative AI Developer 系 Generative AI Developer Professional (上位) ├→ Data Engineer Associate (中位) └→ Machine Learning Engineer Associate (中位) ├→ Cloud Practitioner (下位) └→ AI Practitioner (下位) つまり、例えば Solutions Architect Professional を更新すれば、Solutions Architect Associate と Cloud Practitioner も一緒に更新されることになります。こちらの内容をまとめたものが下図となります。 ただし、注意点があります。上位認定を更新した場合に下位認定も更新されるのは、 その下位認定をすでに取得している場合に限ります。 上位認定を取得・更新したからといって、まだ取得していない下位認定が自動的に付与される (取得されたことになる) わけではありませんのでご注意ください。加えて、 認定が更新されるのは「そのタイミングで有効な認定のみが対象となる」 点も注意が必要です。上位認定を更新した際に、失効状態の下位の認定が後から再度有効になることはありません。下位の認定を有効にしたい場合は再度認定を取得しなおしていただく必要があります。 この仕組みを活用した再認定戦略 複数の認定を持っている場合、上位・下位関係を理解しておくと、効率的に再認定ができます。 例えば: Cloud Practitioner と Solutions Architect Associate を持っている場合 → Solutions Architect Associate を再認定すれば Cloud Practitioner も更新される Associate 複数と Professional を持っている場合 → Professional の再認定をすればその下位に紐づく Associate と Foundational も更新される さらに、 認定に合格すると「次回以降の試験で使える50%オフのバウチャーコード」が特典として付与されます。 再認定の際にはこちらを活用することで、費用を抑えながら継続的にチャレンジいただけます。 再認定の具体的な方法 (試験の再受験、認定更新プログラムなど) については、こちらのブログ記事で詳しく解説しています: →　 AWS 認定の新しい更新方法についてのブログ記事 Specialty は独立している もう一つ押さえておきたい点は、 Specialty (専門) 認定は、ここまででご案内してきた上位・下位関係に含まれない ということです。 つまり、Specialty 認定は他の認定と上位・下位の関係がないため、Professional を更新しても Specialty は更新されませんし、その逆も同様です。Specialty を維持したい場合は、Specialty 自体を個別に再認定する必要があります。 なお、AWS Certified Advanced Networking – Specialty は 2026 年 8 月 25 日をもってリタイア (廃止) となる予定です。リタイア後は新規受験ができなくなりますのでご注意ください。 まとめ 本ブログをまとめると下記の内容となります。 AWS 認定には Professional、Associate、Foundational、Specialty の 4 カテゴリがある その中の 3 つのカテゴリには Professional → Associate → Foundational という上位・下位関係がある 上位の認定を更新すると、取得している有効な下位の認定も自動的に更新される 複数認定を持っている場合は、上位・下位関係を活用して効率的に再認定が可能 Specialty 認定はこの上位・下位関係に含まれない (独立して再認定が必要) ぜひこの上位・下位関係をうまく活用して、効率的な再認定計画を立ててみてください。皆さまの継続的なスキルアップを応援しています ! 著者について 室橋 弘和 (Hirokazu Murohashi) AWS トレーニングサービス本部 Technical Instructor 兼 Customer Success Manager Cloud Quest とデカ盛りのお店巡りをこよなく愛するマン。老眼鏡が必要になってきました。

本稿は、弁護士ドットコム株式会社 CTO 田中 慎司 氏、プロダクト開発本部 Platform & Reliability Engineering 部 (以下、PRE 部) 部長 熊谷 晃 氏、同 PRE 部 原口 慎太郎 氏による寄稿です。 はじめに 弁護士ドットコム株式会社は、『「プロフェッショナル・テック」で、次の常識をつくる。』というミッションのもと、国内最大級の法律相談ポータルサイト「 弁護士ドットコム 」や契約マネジメントプラットフォーム「 クラウドサイン 」などを運営しています。また、最近ではリーガル特化型 AI エージェント「 Legal Brain エージェント 」を開発し、AI を活用したリーガルサービスの進化にも取り組んでいます。PRE 部は、これらのサービスを支えるインフラの信頼性と運用効率の向上を担っています。本記事では、 AWS DevOps Agent を用いたインシデント対応の自動化と運用組織のあり方の見直しを進めている事例を紹介します。 導入のきっかけ 弁護士ドットコムでは、事業の拡大に伴いサービス数・トラフィックの増加が続いており、PRE 部として対応するアラートの量と種類も年々増えています。量の増加に加え、調査対応が一部の熟練エンジニアに依存していたため、属人化の解消も急務でした。そのため、検知から原因特定までを人手を介さずに、または非常に少ない労力で完結できれば、この課題を根本的に解消できると考えていました。 AWS DevOps Agent との出会い こうした課題の解決策として、GA 前から DevOps Agent のトライアルを開始しました。 DevOps Agent は MCP による機能拡張が可能です。連携可能なツールとして Datadog、GitHub、Slack といったサードパーティ製のツールもあります。Datadog Monitor のアラートをトリガーに DevOps Agent が自動起動し、検知から根本原因の特定までを人手を介さずに完結できるところが、弁護士ドットコムが抱えていた課題の構造そのものに合致するものでした。トライアル段階から本番環境に組み込むという判断にあたっては、「新しい技術に早期に触れ、自社の運用にフィットするかを実環境で見極める」という方針のもと、本番環境の監視データに DevOps Agent を接続する構成で試行運用を開始しました。DevOps Agent は参照権限のみで動作する点も、本番環境への適用を安心して行えるポイントでした。 AWS DevOps Agent について AWS DevOps Agent は、2026年3月31日に一般提供 (GA) が開始された「AI ベースの運用支援エージェント」で、マルチアカウント対応やオンプレミス、他社クラウド、サードパーティなどとの連携が可能です。詳細は AWS DevOps Agent の公式ページ をご覧ください。弁護士ドットコムでは、既に Datadog を中心とした監視基盤を構築していたため、MCP を活用することで既存の環境を変更することなく組み込むことができました。 導入後のインパクトと効果 ここからは、DevOps Agent がトライアル運用中に実際のインシデントで威力を発揮した事例を紹介します。 事象の発生 2026年3月のある日、弁護士ドットコムが運用するサービスの一つでパフォーマンスが大幅に劣化しているという報告が上がりました。「リクエスト数は増えていないのに、レイテンシだけが悪化している」という状態です。試行運用中だった DevOps Agent は、Datadog Monitor のアラート発火をトリガーに自動起動し、人手を介さず即座に調査を開始してくれました。 約10分で根本原因を特定 以下は、DevOps Agent が Slack に投稿した調査のタイムラインです。 経過時間 DevOps Agent のアクション 0 分 調査開始 (Investigation started) 約 3 分 レイテンシ劣化の定量分析完了。平均レイテンシが 0.67s から 1.85s に悪化 (2.8 倍)、P99 は 2.10s から 9.00s に悪化 (4.3 倍) していることを特定。同時にリクエスト数の安定も確認し、トラフィック起因ではないことを確認 約 4 分 ECS へのデプロイ履歴との相関分析を実施。直前のデプロイ完了時刻がパフォーマンス劣化開始時刻と完全に一致することを特定 約 8 分 APM トレースを分析し、該当デプロイで導入された機能がキャッシュなしの DB クエリを繰り返し呼び出す N+1 問題を引き起こしていることを特定。ページあたり20回以上の追加クエリが発生していた 約 9 分 ホスト単位の影響分析を実施。3秒超のトレースが特定の Spot インスタンスに集中しており、N+1 問題の影響が CPU 競合によって増幅されていたことを解明 約 10 分 調査完了 (Investigation complete)。根本原因、影響範囲、定量データを含む調査レポートを Slack に投稿 調査開始から根本原因の特定まで、わずか約10分でした。調査完了後は Jira に Issue も自動登録され、Slack の通知とあわせて迅速な対応が可能になりました。その結果、本事例では迅速なロールバックで影響を早期に収束させました。 DevOps Agent の分析の深さ DevOps Agent が出力した調査レポートの特筆すべき点は、その分析の深さです。まず、インシデント前後のリクエスト数を比較し、パフォーマンス劣化がトラフィック起因ではないことを数値で裏付けました。次に、ECS へのデプロイ履歴を確認し、直前のデプロイとの時間的相関を特定しました。さらに APM トレースを掘り下げ、該当デプロイで導入されたコードの N+1 問題まで踏み込んで原因を特定しています。全体では数倍のレイテンシ劣化でしたが、特定のタスクでは15倍まで増幅されていることを発見し、テイルレイテンシ (P90/P99) が不均衡に悪化した理由まで説明しました。 以下は、対象サービスのレイテンシをベースラインとインシデント時で統計値ごとに比較した表です。 統計値 ベースライン インシデント時 劣化倍率 Average 0.67s 1.85s 2.8x P90 1.10s 4.70s 4.3x P99 2.10s 9.00s 4.3x 特定 ECS タスク 0.50s 7.50s 15.0x 以下は、DevOps Agent が Slack 上で根本原因を特定した調査ログの一例です。 対応の加速 DevOps Agent が約10分で根本原因を特定した調査結果を開発チームに共有したところ、並行して調査していた開発チームの経験豊富なエンジニアの調査結果とも一致し、ロールバック判断を迅速に行うことができました。従来であれば、アラートを認知してから原因を特定し対応するまでの一連のプロセスに、慣れたエンジニアでも30分程度はかかっており、さらにこのプロセスを実行できるエンジニアは限られていました。DevOps Agent はその作業を短時間で完了し、誰でも読めるレポートとして出力してくれるため、対応時間を大幅に短縮することができました。 導入によって確認できた効果 トライアル運用開始以降、パイプライン全体で次の効果を確認できています。 チケット管理 アラートのたびに誰かが調査を開始し、あとから Jira に起票する運用では、対応の遅れや起票漏れが起きることがありました。今回、自動調査と自動起票をセットにしたことで、調査が完了した事象は必ず Jira 上に登録されるようになっています。これにより、対応漏れの懸念が解消されました。 属人化の排除 調査結果が構造化されたレポートとして Slack に投稿されるようになりました。これにより、アプリケーションの内部構造に詳しくないエンジニアでも、レポートを読んで対応方針を判断できるようになっています。人手による調査では、担当者の経験や知識によって分析の範囲にばらつきが生じてしまいますが、DevOps Agent はメトリクス、APM トレース、デプロイ履歴、ホスト単位の影響分析を毎回網羅的に実施するため、見落としのリスクが低減されています。 コード修正が必要なアラートでは、エージェント対応仕様により「何をどのリポジトリでどう直すか」が構造化されて届くため、仕様を確認して承認するだけで修正フローに進めます。調査結果の解釈から仕様の説明までを DevOps Agent に任せられることで、対応完了までのリードタイムも短縮されています。 効果を支えるアーキテクチャと運用フローの整備 ここまで紹介した効果は、既存の対応フローに合わせて DevOps Agent を組み込んだ以下の構成によって実現しています。 全体構成 DevOps Agent は外部からの通知を webhook で受けることができます。この機能を活用し、Datadog Monitor のアラートをトリガーとして DevOps Agent を自動起動する構成を採用しています。 監視基盤: Datadog トリガー: Datadog Monitor のアラート エージェント: AWS DevOps Agent 通知: Slack 連携による調査結果のリアルタイム配信 チケット管理: Jira 監視・調査対象: AWS 上で稼働するアプリケーションサービス Jira 連携 調査の自動化だけでは、アラート対応の記録や追跡は別途人手が必要になります。Skills は、DevOps Agent に社内の運用手順や判断基準を教え込むための拡張機能です。弁護士ドットコムでは、この Skills と Jira の MCP を組み合わせ、調査完了後に Jira へ Issue を自動登録する仕組みを構築しました。 調査完了時に Slack への投稿と Jira の Issue を自動作成する Skills を実装しています。 作成した Skills 例 弁護士ドットコムでは、Jira で Issue を登録するために以下の Skills を作成しました。 工夫した点としては、調査は完了しているのに Jira Issue が作成されないケースがあったため、Skills の終了条件に「既存 Issue の確認、または新規 Issue 作成の完了」を明示しました。Skills は今後、運用しながら最適化していく予定です。Skills には、調査の前後で踏むべき手順と「調査完了」の定義を記述しています。骨子は次のとおりです。 調査開始前: 関連するランブック (手順書) や過去のインシデント報告、サービスの所有者情報といった背景情報を収集する 調査実施時: 収集した知見とリアルタイムのテレメトリ・ログを照らし合わせ、過去の根本原因を参照して重複調査を避ける。ランブックがある場合は独自判断より優先する 調査完了時: まず既存チケットを検索し、見つからなければ新規 Issue を作成する。Issue には検出内容 (トリガー)、特定した根本原因または仮説、実施した対応、今後の推奨アクション、参照したリンク、重要度を日本語で記載する 終了条件: これらの Issue 作成 (または既存チケットの確認) が完了するまで、調査を「完了」と宣言させない データフロー ポイントは、Datadog Monitor のアラート発火から DevOps Agent の調査完了まで、エンジニアの介入なしに自動で進行する点です。アラート発生から調査結果の配信までのデータフローは以下のとおりです。 エンジニアが最初に目にするのは、Slack に投稿された調査完了レポートです。同時に Jira 上にも対応用の Issue が起票されているため、調査結果の共有とアラート管理を別作業として行う必要がありません。従来は「アラートに気づく → 誰かが調査を始める → 原因を特定する → チケットを起票する」という人手に依存したフローでしたが、DevOps Agent の導入により「アラート発火 → 自動調査 → 原因特定済みのレポートが届く → Jira に Issue が用意される」というフローに移行を進めています。 また、DevOps Agent に設定した IAM の権限に基づき Datadog のデータだけでなく、Amazon ECS のデプロイ履歴やタスク状態、Amazon CloudWatch のメトリクスなど、AWS リソースの情報も横断的に分析します。これにより、「いつデプロイされた何が原因か」まで踏み込んだ根本原因分析が可能になっています。 既存の修正フローとの組み合わせ 弁護士ドットコムでは、DevOps Agent を既存の修正フローと組み合わせて運用しています。 役割 担当 初動調査、根本原因分析 AWS DevOps Agent アラートのチケット起票・管理 AWS DevOps Agent コード・設定変更の仕様策定 AWS DevOps Agent 修正、PR 作成 既存の修正フロー (コーディングエージェント) DevOps Agent が「何が起きて、なぜ起きたか」を素早く明らかにし、Jira 上の Issue として記録を残すことで、調査結果の共有とアラート管理を同時に進められます。恒久対応が必要な場合は、DevOps Agent が出力する「エージェント対応仕様」を活用します。これは、コードまたは設定の変更に関する推奨事項を、コーディングエージェントに直接渡せる形式でまとめた構造化ドキュメントです。変更に必要なコンテキストが自動で揃うため、エンジニアは仕様を確認しコーディングエージェントに渡すだけで、迅速に修正に着手できます。これにより、「検知 → 原因特定 → チケット起票 → 仕様確認 → コード修正」までの一連の対応を、エンジニアがゼロから状況を説明し直すことなく進められるようになりました。 今後の展望 予防的改善の自動化 (Proactive Incident Prevention の活用) DevOps Agent はインシデント発生時の調査だけでなく、運用全体を改善するための「予防」機能も備えています。弁護士ドットコムで運用を始めると1週間ほどで、何度も繰り返されるアラートに対する予防策が提示されました。提案はオブザーバビリティ、インフラストラクチャ、ガバナンス、コード最適化の4カテゴリに分類されて届くため、優先順位を決めて対応することが可能になります。 現在はインシデント発生時の調査自動化を中心に活用していますが、今後はこの Proactive Incident Prevention 機能の活用を本格化させたいと考えています。この機能は、過去のインシデント調査をもとに「同じ種類の障害を防ぐにはどうすればよいか」を提案してくれるものです。 インシデント発生時にはすでにエージェント対応仕様で修正着手を加速している一方、予防提案と仕様生成が組み合わされれば、「検知 → 原因特定 → 改善提案 → コード修正」のサイクルを障害の前にも回せる可能性があります。 トポロジーによるインフラとアプリの可視化 弁護士ドットコムでは、長年運用してきたアプリケーションの内部構造の理解が属人化の一因になっています。「トポロジー」機能によってリソース間の依存関係が自動的に可視化されれば、インシデント調査時だけでなく、日常の運用においてもシステム全体の理解が深まります。PRE 部のメンバーからも、トポロジーによって担当外サービスへの理解が進んだという声が上がっています。 まとめ 今回の DevOps Agent の導入は、弁護士ドットコムにおける AI 活用の軸を、プロダクトから開発・運用プロセスそのものへと広げる取り組みと位置づけています。アラート発生からアラート管理・修正の仕様化までを一つのパイプラインとして実現した点も、運用面での大きな変化です。DevOps Agent に「調査・起票・修正仕様の整理」を任せ、エンジニアは「仕様の確認と判断・修正の承認」に集中する環境に大きく前進したと考えています。 正確性と信頼性が強く求められるリーガルテック領域において、運用の信頼性を AI エージェントとともに高次元で両立させることは、ユーザーがサービスを安心して使い続けられる環境を提供し続けるための至上命題です。同様の課題を抱えるチーム、および AI エージェントを運用領域に組み込むことを検討されている技術責任者の皆様にとって、本記事が一つの参考となれば幸いです。 執筆者 田中 慎司 弁護士ドットコム株式会社 執行役員 CTO NTT 研究所、はてな CTO、メルカリ (US, UK含む) VP を経て、2024 年より弁護士ドットコム CTO。エンジニア組織を活性化させ、一人一人のエンジニアのポテンシャルを生かせる組織にアップデート中。 AI 駆動開発を始めとする、昨今のLLMの進化と応用の可能性、その基礎となるニューラルネットワークの面白さにどハマり中。 熊谷 晃 弁護士ドットコム株式会社 Platform & Reliability Engineering部 部長 / Head of AI CoE 2023 年 12 月より弁護士ドットコム株式会社にて、SRE と Platform Engineering チームを束ねる部門長として活動。また、2026 年 5 月からは、新たに AI CoE を設立し、全社 AX の推進も担っている。 原口 慎太郎 弁護士ドットコム株式会社 Platform & Reliability Engineering 部 / AI CoE 2023 年 4 月より弁護士ドットコム株式会社にて SRE として業務に従事。プロジェクトマネージャーの経験を活かし、エンジニアリングに閉じない、組織横断の信頼性向上に取り組んでいます。最近は AI CoE としても活動中。モータースポーツが好きで、とくに F1 が大好き。

こんにちは。 アプリケーションサービス本部、DevOps担当の兼安です。 最近、SNS上でAIによるGitHubリポジトリの誤操作を見かけるようになりました。 怖いですね。 ということで、今回はGitHubのブランチ保護と、 各種AIエージェントによるパーミッションでgit pushを禁止する方法を紹介します。 なお、本記事ではAIエージェントとして、Claude CodeとKiro CLIを取り上げます。 AIによるGitHubリポジトリの誤操作とは Gitのおさらい ブランチの意味と、直接git pushしてはいけないブランチ Gitのアップロードは2段階、git commitとgit p…