【AWS】なんでも効率化！Community Builderが伝えるAWS Developer Toolsの魅力【DevTools】

はじめに

2025年にAWS Community Builders に選出いただいてから、DevToolsの魅力をもっと多くの人に知ってもらいたいと思い、アウトプットを続けています。
今回の記事ではシステム構築に関する各工程で使われる代表的なDevToolsを各工程ごとに解説しています。

↓ この記事の海外向け版はこちら

AWS Summit Japan 2025のCommunityStageで登壇しました

このブログ記事と同様の内容をAWS Summit Japan 2025のCommunityStage 1日目で登壇させていただきました
その時の資料のリンクも掲載しておきます。
とても貴重な機会を与えていただいたAWS様にここでも感謝を述べさせていただきます。

↓ AWS Summit Japan 2025 AWS ユーザー コミュニティ - Community Stage で登壇しました

DevToolsとは

AWS製品説明ページ

AWS製品説明のページではこのように説明されています。

• 構築、テスト、およびデプロイなど開発にかかわる作業をより迅速かつ効果的に行うことができるようにするもの
• セキュリティや速度、コード品質などを向上させるために使われるもの

↓ AWSの製品説明ページ

DevToolsサービスの種類

DevToolsに分類されるAWSのサービスの一覧は見る資料によって多少の違いがありますが、AWSのホワイトペーパーには以下のようなサービスがDevToolsとして紹介されています。

• AWS Infrastructure Composer
• AWS Cloud9
• AWS CloudShell
• AWS CodeArtifact
• AWS CodeBuild
• Amazon CodeCatalyst
• AWS CodeCommit
• AWS CodeDeploy
• AWS CodePipeline
• Amazon Corretto
• AWS Fault Injection Service
• Amazon Q Developer
• AWS X-Ray

↓ AWSホワイトペーパー

ソフトウェア開発ライフサイクル(SDLC)

システムの開発の流れを表すものとしてソフトウェア開発ライフサイクル(SDLC)というものがあります。ソフトウェアの開発プロセスを計画、設計、実装、テスト、デプロイ、運用などのステップに分けたものです。
SDLCのそれぞれでのステップでAWSの様々なDevToolsを利用することができます。
必ずしもすべてのツールを使う必要はありませんが、
目的に合ったツールを適切なタイミングで使うことで、その作業は効率化することができます

↓ SDLCの各フェーズとDevTools

実装フェーズで活かせるDevTools

AWSにおける実装は例えばLambda関数のコードを実装したり、AWSマネジメントコンソール画面で各リソースの設定を変更したりすることがあります。
これらの実装作業においてDevToolsを活用することで効率化が図れます。

IaCツール

インフラ構成のコード化による変更履歴管理

IaCツールによってインフラ構成をコード管理することができます。
コードで管理できるためGitなどの変更履歴管理ツールと合わせて運用することにより、いつだれがどのように変更を加えたかの変更履歴の管理が可能になります。
また、複数のAWSリソースの定義が1枚のテンプレートに定義できるため、各AWSサービスのコンソール画面を毎回開いて確認する必要がなく、IaCコードを見るだけで俯瞰で構成を各リソースの定義を確認することができます。

インフラ構成のコード化による手作業の作業負荷の軽減

IaCコードに定義されたインフラ構成はAWSアカウントに一括反映することが可能です。
同じ構成を複数のAWS環境に定義する場合、AWSコンソール画面からリソースを手作業で定義する方法では各リソースに対して同じ作業を何度も行う必要があります。同じ作業を繰り返す場合はその時々で操作ミスが発生する可能性があります。
IaCコードを使ったAWS構成の定義では、IaCコードに必要な定義がされており、それを一括で反映するだけなので、操作ミスの可能性を減らすことができます。

AWS CloudFormation

AWSのIaCツールの基本

AWS CloudFormationはAWSのIaCツールとして初めに学習する人が多いツールです。
CloudFormationテンプレートと呼ばれるファイルをyaml形式かJSON形式で作成し、それをAWSアカウントに反映します。
AWS CloudFormationを利用することでリソースの設定を詳細に定義することが可能です。AWS CDKのように抽象化されないので、定義項目が冗長になってしまう問題がありますが、抽象化されていない分、目的に合ったリソース定義が可能です。また、CloudFormationGuardやRainなどの関連ツールも充実しています。

AWS Infrastructure Composer

CloudFormationテンプレートの可読性低下の対策に

CloudFormationテンプレートは詳細な定義ができる反面、コード量が多くなります。その結果、可読性が低下し、テンプレートにどのような構成が定義されているか直感的に理解することが難しくなります。
AWS Infrastructure Composer ではCloudFormationテンプレートの定義内容をリソースのつながりを示した図で視覚的に理解できます。

SAMテンプレートの定義をGUIで直感的に実現

AWS Infrastructure Composerを利用することでインフラ構成をGUIで定義することが可能です。
AWSサービスが定義されたカードをGUIのキャンバス上に配置し、カード同士を紐づけ、カードの詳細を設定することで、その内容をIaCコードに書き起こしてくれます。

AWS Infrastructure Composerの具体的な活用例

AWS Infrastructure Composerの具体的な活用例は別記事で解説しておりますので、こちらをご参照ください

↓ 【AWS】DevTools布教活動InfrastructureComposer編【アドカレ2025】

AWS Infrastructure Composer のカード接続時のポリシー過剰付与問題の対応(IAM Policy Autopilot)

※AWS SUMMIT後に追記
AWS Infrastructure ComposerではGUI操作時にAWSリソースを定義するカードをつなげた際に、リソースの操作の許可(ポリシー)が過剰に付与されてしまう問題がありました。
AWSのベストプラクティスに照らし合わせると、AWSのリソースの許可範囲は最小限にするべきであるため、過剰なポリシーが付与された後で余計なポリシーを目視で判定して削除する必要がありました。
2025年のre:Invent期間中に発表された「IAM Policy Autopilot」ではプログラムのコードなどを解析して最小限のポリシーを設定することができます。
最小限のポリシー設定を効率的に行えるため、以下の「IAM Policy Autopilot」に関する記事も合わせてご参照ください。

↓ 【AWS】IAM Policy AutopilotでInfrastructureComposerのポリシーを修正する【アドカレ2025】

以下のキャプチャのようにKiroから自然言語でポリシー設定を最小のものに設定することが可能です。

AWS CDK

抽象化により少ないコードでインフラ構成を定義

AWS CDKを利用することでL2コンストラクタなどの抽象化された定義により、より少ないコードで効率的にリソース定義が可能になります。

↓ 各IaCツールのイメージ図

AWS CDK に関する具体的な活用手順

AWS CDK に関する具体的な活用手順については私の別の記事で解説していますので、ご参照ください。

↓ 【AWS】DevTools布教活動CDK編【アドカレ2025】

Amazon Q Developer によるコード開発

Amazon Q Developer を利用することで自然言語でAmazon Q Developerに依頼を出すだけでコード生成が可能です。AIによるコード生成時にはチームの独自ルールに従ったコード生成ができるか不安になるものですが、ルールを記載した資料を準備し、それを元にコード生成するように依頼を出すことにより、そのルールに従ったコード生成が可能になります。
以下のキャプチャ画像の例では、CDKコンストラクトデザインガイドラインをdocsフォルダに配置して、それを元にAmazon Q Developerに新しいL2コンストラクトの作成を依頼をしました。その結果、実装したガイドラインの準拠要素の説明文とともに、ガイドラインに準拠した新しいL2コンストラクトのコードが生成されました。

↓ Amazon Q Developer によるCDKコンストラクトデザインガイドラインを参照した新しいL2コンストラクトの作成

Amazon Q Developer in GitHubでノーコード開発

変更管理のみではない、AmazonQDeveloperによる自動Issue対応

GitHubと言えばアセットの変更管理サービスとして有名ですが、2025年5月6日(日本時間) にAmazonQDeveloperを活用した新しいサービスが利用可能になりました。
Amazon Q Developer in GitHubでは、GitHub上でAmazon Q Developer を担当者にしてIssue(課題)を設定することで、その課題の内容と既存の成果物からAmazonQDeveloperが課題の対応を実装してプルリクエストを作成してくれます。
作成された実装内容に対しても人がコメントを入れながら、AmazonQDeveloperと対話しながらノーコードでシステム構築や課題対応が可能です。
プルリクエスト前にはAmazonQDeveloperがセルフレビューでセキュリティのチェックなども行ってくれます。

チームの一員のようにAmazon Q Developerに課題を割り当て

これまでのAIを活用した開発では、人がAIと対話しつつ一緒に課題に沿ったコードを実装するいわゆるバイブコーディングやコーディング支援のような形が主流でした。
Amazon Q Developer in GitHubのようなサービスでは、人は課題を作るだけで実装の大部分を任せ、人は結果をレビューするような形もとれるようになります。

↓ Amazon Q Developer in GitHub による開発のイメージ

過去のAmazon Q Developer in GitHubに関する記事

Amazon Q Developer in GitHubのより詳しい操作方法については以下の過去の私の記事で解説していますので、ご参照ください。

↓ 【AWS】GitHubとAmazonQDeveloperが統合されたから試してみた【AmazonQ】

AWS CodeCommit による変更管理　★AWS SUMMIT 後に追記！★

AWS SUMMIT後に内容追記
このKiroに関する記載はAWS SUMMIT後に追記しています
AWS SUMIT時にはAWSCodeCommitが廃止予定となっていたため登壇内容には含めていませんでした。

2024年7月に段階的な廃止が発表されたAWSCodeCommitが2025年11月24日に廃止が取りやめになり、再度GAになりました。
AWS SUMMIT後の内容になりますが、この記事に内容を追記しておきます。

アセットの変更管理

手動での修正が不可能な問題のある変更が加わった際の安定バージョンへの戻し

AWSCodeCommitのような変更履歴管理ツールを利用しない場合、変更内容の管理は例えば日ごとにファイルのバックアップを手動で作るなど大変手間のかかる作業になります。
変更履歴管理ツールを使うことで変更履歴の管理が容易になり、いつでも動作検証済みの安定バージョンへの戻し作業も容易になります。

誰がいつどのような変更を加えたかの履歴の追跡

AWSCodeCommitのような変更履歴管理ツールを使うことで変更履歴を作る際に変更した担当者名やメッセージなどの付属情報の付与が可能になります。
変更した日付やコード内のコメントだけではなく、変更したアセット一式に対してどのような変更を加えたのかが把握できるため、変更履歴の追跡が明確で容易になります。

他サービスと連携した通知機能などの実装

AWSCodeCommitでは他のAWSサービスとの連携が容易になります。
例えば、プルリクエスト作成時にAmazon SNSを通じてSlackにプルリクエストが行われたことの通知などが可能です。
サービスを利用しない場合プルリックエスト作成時のオペレーションとして、マージ担当者への連絡が必要になると思いますが。AWSCodeCommitと他サービスの連携によりその作業を自動化することで作業負荷の軽減や連絡忘れなどのリスク低減が可能になります。

AWS CodeCommitの具体的な活用方法

①CodeCommitのコンソール画面でリポジトリ作成

②ユーザーの認証情報の作成

③リポジトリのURLでローカル環境にGitCloneする

git clone 【コピーしたURL】

より詳細には過去の私の記事を参照ください

以下の記事でコミット、プッシュ、プルリクエストの作成、マージなどの操作方法を解説しています。ご参照ください。

↓ 【AWS】DevTools布教活動CodeCommit編【アドカレ2025】

テスト/レビューフェーズで活かせるDevTools

繰り返し行われるテストを自動化することで工数を削減する

例えば退行テストのようにシステム全体が正常に稼働していることを変更が加わるたびに繰り返し行われるテストでは、毎回同じ作業が発生します。
これらの作業を自動化することで毎回の人の手間を減らすことができます。
テストコードを書く工数や自動テストを実装する手間はかかりますが、何度も繰り返す作業を自動化することで長期的に大きな工数削減につながります。

AWS CloudFormation Guard でポリシーチェック

AWS CloudFormation Guard (Cfn-guard)

AWS CloudFormation GuardではCloudFormationテンプレートにおいて守らなければいけない定義内容(ポリシー)をチェックすることでPolicy as Code(PaC) を実現します。
チェックのために事前に定義したルールファイルとCloudFormationテンプレートファイルを比較してルールと合致しているかを判定します。
以下のキャプチャ画像の例ではLambdaのタイムアウト設定やメモリ設定、ランタイムの設定を定義したポリシーコードを準備してデプロイ前のチェックを行う例を示しています。

↓ Cfn-guard利用の例

Cfn-guardの具体的な実装方法の紹介

Cfn-guardの具体的な実装方法は以下の記事で紹介していますので、ご参照ください

↓ 【AWS】AWS CDKのテストとベストプラクティス【テスト】

Amazon Q Developer (/test) でテストコードを自動生成

テストコード生成の工数を削減

テストコードは設計や要件を基に作成し、実装内容が求められている値を返すか、必要なエラー処理をしているかを確認します。
手作業でテストを実装する場合、テストパターンも考慮して実装を進めるため、場合によっては機能実装と同じかそれ以上の工数がかかってしまいます。
この作業を効率化するためにAmazonQDeveloperなどの生成AIによりテストコード生成の効率化の支援が得られます。

Amazon Q Developer (/test)で実装内容を基にテストコード作成

単体テストコードを作成する場合、Amazon Q Developer のチャット欄に /test と入力するだけでAmazon Q Developer が成果物をスキャンして、それらに対応したテストコードを生成してくれます。
AIによるテストコード生成により人間の負担を減らしてくれます。
ただし、実装内容を基にして作成されたテストコードになっているので、実際に設計や要件に求められているテストが実装されているかどうかは人による確認が必要です。
不足しているテストの追加や設計と要件と異なるテストの修正などを加えることでより質の良いテストが可能になります。

↓ Amazon Q Developer (IDE) によるテストコード生成のイメージ

Amazon Q Developer (/review) でコードレビューを自動化

人依存のレビューの課題

人依存のレビューを行う場合、そのレビューの品質は人の経験や理解度によって異なります。そのため、熟練の技術者にレビュー負荷が偏ることもあります。
レビュー担当者のスケジュールも考慮する必要があり、必要な時に必要なレビューが実施できないリスクもあります。

Amazon Q Developer (/review) でコードレビューを自動化

実装内容のレビューに関しても、Amazon Q Developer のチャット欄に /review と入力するだけでレビューが可能です。
以下のキャプチャ画像の例ではレビューの結果AWS Lambda 関数でエラーハンドリングの実装がないことのレビュー指摘がされています。
AmazonQDeveloperによるレビューが実現できることで、実施する時間を問わず常に一定の品質のレビューが実現できます。
案件におけるコードに現れない制約事項等もあるため、人の経験や知識を基にしたレビューも加えることで、人が見落としてしまうレビュー観点をカバーしながら、AIではチェックしきれない隠れた要件を漏れを防止した良いレビューが実現できます。

↓ Amazon Q Developer (IDE) によるレビューのイメージ

デプロイフェーズで活かせるDevTools

デプロイに関する課題

デプロイという作業はプログラムコードを新しいものに置き換えるだけがすべてではありません。
デプロイ内容をテストし、テストが完了したらデプロイ内容の差分を表示して、差分の確認を責任者に依頼し、デプロイの承認をしてもらい、デプロイし、デプロイ後に問題があれば戻し作業を行うなど、場合によっては数多くの工程が発生します。
テストの自動化と同様に１回限りの作業であればよいですが、繰り返し同様の作業をする際には自動化できる仕組みを実装することにより、作業ミスが減り効率的なデプロイの実施が可能になります。

AWS CodePipeline

デプロイに関する一連の工程を自動化

AWS CodePipeline を利用することでデプロイに関する一連の工程を自動化することで、繰り返し行われる人の作業負荷を軽減してくれます。

AWS CodePipelineによる工程の自動化の例 ~ CloudFormationテンプレートの変更セットの作成とデプロイ承認 ~

以下のキャプチャ画像の例ではデプロイ工程の例として以下の工程を自動化する例を示しました。

• 開発者が改修内容をIaCコードをアップロードし
• Cloud Formation の変更セットを作成し
• 変更セットができたことを責任者に通知し
• 責任者がデプロイを承認することでデプロイを実行する
  これらの工程をAWS CodePipeline を利用することで人が行う作業を、開発者がIaCコードをアップロードする作業と責任者が承認を行う作業だけにすることができます。

↓ AWS CodePipeline の利用例

AWS CodePipelineの具体的な実装例

AWS CodePipelineを使ったデプロイ工程の自動化については、過去に記事を投稿しています。
CDKによる定義になりますが、具体的な実装はこちらを参照下さい。

↓ 【AWS】CodePipelineを利用したCloudFormationテンプレートのデプロイ【Pipeline】

AWS CodeDeploy

安全なデプロイ(問題発生時の影響範囲の制限や素早いロールバックなど)を実現

デプロイ作業はデプロイ実行までで完了ではありません。
デプロイ実行後にエラーなどの問題発生に備えて、新バージョンにアクセスする人を一時的に制限したり、一定時間問題が発生しないかを監視し、問題が発生した際には元の安定したバージョンに戻す作業が必要になります。
AWS CodeDeploy を利用することでこれらの作業を自動化することができます。

デプロイ戦略の例 ～ カナリアデプロイ ～

初期段階で新バージョンにごく一部のトラフィックを流す

以下のキャプチャではAWS Lambda の改修版をデプロイする際にカナリアデプロイを実現した例を示しています。
カナリアデプロイでは、初期段階では新しいリソース(今回はLambda関数)へのトラフィックを10％などのごく少数の割合だけ流れるようにし、残りのトラフィックを既存のバージョンに流すように設定します。
これは新バージョンで問題が発生した際に影響範囲をごく一部に制限することを実現します。
もしも初期段階から100％のトラフィックを新バージョンに流していて、新バージョンに問題があった場合全てのユーザーに問題の影響が出てしまいます。
初期段階で一部のトラフィックのみ新バージョンにすることは、問題発生時の影響範囲の制限をするために有効な手段になります。

問題発生時に自動ロールバック

事前に設定した期間、事前に設定した件数分のエラーが発生したらCloudWatchアラームを出すように設定し、問題発生時のアラームが出たらCodeDeployにより元のバージョンに戻されます。
もし手動でのロールバックをする場合であれば、戻し作業が必要か否かの判断と、手動での戻し作業の準備と実施などで時間がかかり、その間発生した問題の影響が長時間発生してしまします。
素早いロールバックをすることにより、影響範囲を制限することにつながります。

問題が発生しなければ100％のトラフィックを新バージョンに流す

設定した時間、アラームが出なければCodeDeployにより新バージョンにすべてのトラフィックを流されることでデプロイ完了になります。

↓ AWS CodeDeploy の利用例

AWS CodeDeployによるデプロイ戦略の具体的な実装方法

AWS CodeDeployを利用した具体的な実装方法は以下の記事に投稿しましたので、こちらをご参照下さい。

↓ 【AWS】DevTools布教活動CodeDeploy編【アドカレ2025】

運用/監視で活かせるDevTools

問題発生時の人による調査の課題

システム運用中に問題が発生した際には関連するログを収集し、内容を確認し、原因を特定して、修正を加える必要があります。
これらの作業には問題の内容によっては多くの時間がかかり、どれだけ効率的に作業できるかも担当者の経験や知識に依存してしまいます。

Amazon Q Developer による運用調査（AIオペレーション）

CloudWatchのコンソールから利用できるAIオペレーションを利用することで、ログのインサイトやメトリクス、アラームをAmazon Q Developer がその内容を分析し、問題の発見と原因の仮説を報告してくれます。
これにより、人が行う必要のある作業の負荷を軽減することが可能になります。
以下のキャプチャ画像の例ではAIがログを解析することでDynamoDBに関する設定ミスの可能性を指摘してくれています。

↓ AIオペレーションの画面

↓ AIオペレーションによる監査結果

↓ AIオペレーションによる仮説(根本原因の報告)

計画/設計で活かせるDevTools

人手によるドキュメント作成、管理の課題

人手によるドキュメント管理を行う場合、改修が進むにつれて実装と設計書の乖離が発生することや設計書の記載粒度が人によってまちまちになることがあります。
設計書の粒度については担当者の工数の余裕や適切な記載粒度の理解度、要件の理解度に依存する部分が大きく、その案件に参加している人全員に同じ基準で成果物を作れるようになるには多くの時間が必要になります。
また、設計書を基に実装を行っていても実装中に設計書に記載されていない部分を補うような実装をした際に、設計書への反映が忘れられ、実装と設計書の乖離が発生することもあります。

Amazon Q Developer によるドキュメント自動生成

Amazon Q Developer のチャット欄で /doc と入力することで、すでに作成された成果物からREADMEファイルを生成できます。
READMEファイルは文章によるプロジェクト説明やデプロイ方法の説明だけではなく、データフローや構成図なども記載されている充実した内容になっています。
実装を基にAIがドキュメントを更新するので、一定の粒度で記載漏れのないドキュメントが生成され、実装から設計書への記載の反映の手間も減らすことができます。

↓ Amazon Q Developer (IDE)　でのドキュメント生成のイメージ

記載内容や粒度が要件と合わない場合は適宜修正が必要

READMEファイルの構成図はAWSサービスアイコンがなく直感的にわかりにくいものになっていますが、MCPサーバーを利用することでAWSサービスアイコンを使用したアーキテクチャ図を生成することが可能です。Amazon Q Developerにアーキテクチャ図を作成するMCPサーバーである aws diagram mcp server を利用してアーキテクチャ図を作るように依頼すると、AWSサービスアイコンを使用した直感的でわかりやすいアーキテクチャ図が生成できます。

↓ aws diagram mcp server を利用したアーキテクチャ図作成

Kiroによる仕様駆動開発　★AWS SUMMIT 後に追記！★

AWS SUMMIT後に内容追記
このKiroに関する記載はAWS SUMMIT後に追記しています
AWS SUMMIT時にはAmazonQDeveloperが主流でしたがKiroの登場により、一部勢力図が変わったため追記しております。

仕様駆動開発による要件、仕様、タスクリストの自動生成

上記のAWS SUMMIT時の内容では成果物を基にAmazonQDeveloperを活用してドキュメントを作成するというものでしたが、Kiroの登場により要件書、設計書、(実装に必要な)タスクリストの生成がDevToolであるKiroによって自動生成することが可能になりました。
実際のプロジェクトの成果物としては、プロジェクトの制約等もあり人が作成した要件書や設計書が採用されることが多いと思いますが、仕様駆動開発の登場によりAIが理解できる形で作られた仕様書を実装に活用することができるようになりました。

↓ Kiroに仕様を伝えて仕様書を作成している画面キャプチャ

↓実際に作成された仕様書

具体的なKiroの活用方法

以下の記事で具体的な活用方法を解説しています。ご参照ください。

↓ 【AWS】DevTools布教活動Kiro編【アドカレ2025】

その他：ツール活用の幅を広げる MCP

AIの機能だけに頼らないMCP活用という選択

AmazonQDeveloperなど1つのツールに頼って作業を来ない場合、そのツールの性能のみが頼りの作業になってしまいます。
MCPサーバーを利用することにより、外部ツールの機能利用が可能になり活用の幅が広がります。
AWSに関するMCPサーバーでは以下の図に示すように、AWSドキュメントを検索して正しい情報を得るMCPサーバーや、CDKコードの実装時にベストプラクティスに沿った実装を支援するためのMCPサーバーなど様々なものが提供されています。

AWS CDK MCP Serverは廃止されました
AWS SUMMIT用の資料として使用した以下の表では「AWS CDK MCP Server」は現在廃止され、その機能は後継の「AWS IaC MCP Server」の機能に含まれます。

MCPツールの設定方法と活用例

MCPサーバーの具体的な使い方は以下の私が書いた記事をご参照ください（AWS SUMMIT後に記載したKiroの記事になります）
MCPサーバーにはインターネット経由で利用が可能なリモートMCPサーバーと、GitHubなどで公開されているMCPサーバーをローカルのPCにインストールして使うローカルMCPサーバーがあります。
2025年にはMCPサーバー利用時のクレジット消費を効率化するpowersというものも登場しました。
どのMCPサーバーもmcp.jsonという設定ファイルに参照先や環境変数を設定して利用します。

リモートMCPサーバー利用でいつでも最新情報を利用

AWSのサービスの使用やベストプラクティスなどの時間の経過とともに情報が変わるものに対してはリモートMCPサーバーを利用して最新情報を得ることが有効です。
以下の例ではAWSの公式ドキュメントを参照して推奨事項などを得られる「AWS Documentation」と、CDKのベストプラクティスを反映しながら実装ができる「Build AWS infrastructure with CDK and CloudFormation」の活用方法を解説しました。

↓ リモートMCPサーバー：【AWS】KiroでワンクリックMCPインストール【アドカレ2025】

↓ 【AWS】Kiroのpowersで誰でも書けるCDKのベストコード【Kiro】

↓ MCP利用時はAIに自然言語で問い合わせることで利用できます

MCPサーバーで外部ツールとの連携も可能

MCPサーバーはAWSのサービスのみにとどまらず、他のツールとの連携も可能です
以下の記事では課題管理などでりようされる「Backlog」の課題を取り込みKiroで実装をしてもらう活用方法と、APIのテストなどで利用できる「POSTMAN」を通してAWSのAPIGatewayのテストを行う方法を解説しています。

↓ リモートMCPサーバー(powers)：【AWS】Kiro powers でKiroをパワーアップ 【アドカレ2025】

↓ 自然言語での依頼により、POSTMANでのAPIテストの作成と実行を完了できました
自然言語でのテスト実行依頼のキャプチャ

POSTMANでのテスト定義の確認のキャプチャ

↓ ローカルMCPサーバー：【AWS】Backlogの課題をMCPサーバー経由で取得してKiroに改修してもらう【Kiro】

↓ Backlogに作成した課題を自然言語で取得して自動で改修まで行うことができました

さいごに

DevToolsは種類が多く、必ずしもすべてを利用する必要はありません。どのように活かすか、どのように組み合わせるかは利用者の工夫次第です。プロジェクトの特性や工程、チームの特性に合わせて適切なツールを選択してください。
DevToolsは日々進化しており、新しいツールも登場しています。これまでの作業の進め方にこだわらずに、たまには改善できる内容がないかを振り返ってみてほしいです。
この記事で皆さんが少しでもDevToolsに興味をもち、魅力を感じていただければ嬉しいです。もっと多くの使い方や工夫の仕方、学び方を知りたい方は他のエンジニアのアウトプットを見たりしてAWS Communityの世界に触れてみてください。