Amazon Web Services ブログ

Amazon Q Developer CLI カスタムエージェントで開発の混乱を乗り越えよう

本記事は米国時間 7 月 31 日に公開された “Overcome development disarray with Amazon Q Developer CLI custom agents” を翻訳したものです。

ワークフローを強化するために Model Context Protocol (MCP) の力を受け入れてきた開発者として、Amazon Q Developer CLI にカスタムエージェントが追加されたことを心より嬉しく思います。この新しい機能は、私が信頼してきた能力を全く新しいレベルに引き上げ、異なる開発コンテキストをシームレスに管理し、簡単に切り替えることを可能にしてくれます。

前回の投稿では、MCP サーバーが AWS サービスやデータベース、その他の重要なツールとの関わり方にどのような革命をもたらしたかについて説明しました。 Amazon Q Developer の MCP 統合によって、データベーススキーマのクエリ、インフラストラクチャにおけるデプロイの自動化、その他多くのことができるようになりました。しかし、複数のプロジェクトを掛け持ちするようになり、それぞれに独自の技術スタックや要件があるため、これらの多様な開発環境を管理するために、より構造化されたアプローチが必要であることに気づきました。

そこで、カスタムエージェントの登場です。この新しい機能により、開発段階に適したタスクのために、特定のツール、プロンプト、コンテキスト、ツール許可をまとめることで、カスタムエージェントを作成・使用することができるようになりました。

背景

私が多層ウェブアプリケーションに取り組んでいるとしましょう。このアプリケーションには、TypeScript で書かれた React フロントエンドと Python で書かれた FastAPI バックエンドがあります。チームには私の他に、Figma を使用するデザイナーとPostgreSQL データベースを管理するデータベース管理者がいます。そこには、デザイナーとデータベース管理者とのコミュニケーション方法に微妙な違いがあります。例えば、私がデザイナーと「テーブル」について議論するとき、それは HTML テーブルとそのページがどのように構成されているかを指している可能性が高いです。しかし、私がデータベース管理者と「テーブル」について議論するときは、SQL テーブルとデータの格納方法について話すことが多いです。

以前、私の環境では、Figma Dev Mode MCP サーバーと Amazon Aurora PostgreSQL MCP サーバーの両方を設定していました。これにより、フロントエンドとバックエンドのどちらのコードでも簡単に作業できるようになりましたが、いくつかの課題も発生しました。もし私が Amazon Q Developer に「テーブルはいくつありますか？」と尋ねたら、Amazon Q Developer は私が HTML テーブルについて話しているのか SQL テーブルについて話しているのかを推測しなければならないでしょう。もし HTML に関しての質問であれば、Figma サーバーを使用すべきです。もし SQL に関しての質問であれば、Aurora サーバーを使用すべきです。これは技術的な制限ではなく、言語の制限です。私がデザイナーやデータベース管理者と話すために前提を調整しなければならないのと同じように、Amazon Q Developer も同じ調整をしなければなりません。

そこで、Amazon Q Developer CLI カスタムエージェントの登場です。カスタムエージェントを使用することで Amazon Q Developer の設定をシナリオごとに最適化することができます。私のフロントエンドとバックエンドの構成を見て、その影響を理解してみましょう。

フロントエンドエージェント

私のフロントエンドカスタムエージェントは React と Figma を使用したフロントエンドウェブ開発用に最適化されています。以下のコード例は、~/.aws/amazonq/agents/front-end.json に格納されている私のフロントエンドエージェントの設定です。それでは、この設定の主なセクションについて説明しましょう。

  • mcpServers – ここでは Figma Dev Mode MCP サーバーを設定しました。ローカルにインストールされた Figma Web Design App と通信するだけです。これは、~/.aws/amazonq/mcp.json に保存されていた MCP 設定を置き換えることに注意してください。
  • tools と allowedTools – この 2 つのセクションは関連しているため、一緒に説明します。 tools は Amazon Q Developer が利用可能なツールを定義し、 allowedTools は信頼できるツールを定義します。言い換えると、Amazon Q Developer は設定されたツールを使用することができ、fs_read や fs_write 、@Figma を使用するために私に許可を求める必要がありません。@Figma は、Amazon Q Developer が許可を求めることなく、すべての Figma ツールを使用することができます。
  • resources – ここではコンテキストに追加するファイルを設定しました。README.md (プロジェクトフォルダに格納されている) と、React に関する私自身の設定 (プロファイルに格納されている) を含めました。詳しくは、コンテキスト管理とプロファイルを参照してください。
  • hooks – リソースに加えて、フックも用意しました。このフックはコマンドを実行し、実行時にそれをコンテキストに追加します。この例では、現在の git status を追加しています。詳しくは、コンテキストフックの使用を参照してください。
{
  "description": "Optimized for front-end web development using React and Figma",
  "mcpServers": {
    "Figma": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://127.0.0.1:3845/sse"
      ]
    }
  },
  "tools": ["*"],
  "allowedTools": [
    "fs_read",
    "fs_write",
    "report_issues",
    "@Figma"
  ],
  "resources": [
    "file://README.md",
    "file://~/.aws/amazonq/react-preferences.md"
  ],
  "hooks": {
    "agentSpawn": [
      {
        "command": "git status"
      }
    ]
  }
}

バックエンドエージェント

私のバックエンドカスタムエージェントは Python とPostgreSQL を使用したバックエンド開発に最適化されています。以下のコード例は、~/.aws/amazonq/agents/back-end.json に格納されている私のバックエンドエージェントの設定です。先ほどのようにセクションを説明するのではなく、フロントエンドとバックエンドの違いに焦点を当てます。

  • mcpServers – ここでは Amazon Aurora PostgreSQL MCP サーバーを設定しました。これにより、Amazon Q Developer が私の開発用データベースにクエリを発行し、スキーマを知ることができます。誤ってデータベースを更新しないように、読み取り専用の接続を設定していることに注意してください。
  • tools と allowedTools – 今回も Amazon Q Developer ですべてのツールを使用可能にしました。しかし、信頼できるツールについては、より制限しています。Amazon Q Developer は、fs_write や @PostgreSQL/run_query の使用許可を求める必要があります。Figma でやったように MCP サーバー全体を許可することもできますし、ここでやったように特定のツールを許可することもできます。
  • resources – ここでも、README.md (プロジェクトフォルダに格納されている) と Python と SQL に関する私自身の設定 (どちらも私のプロファイルに格納されている) を含めました。ここで glob パターンを使用可能なことに注意してください。例えば、file://.amazonq/rules/**/*.md には Amazon Q Developer IDE プラグインによって作成されたルールが含まれます。
  • hooks – 最後にフロントエンドとバックエンド用のフックも用意しました。フロントエンドには npm run 、バックエンドには pip freeze のようにプロジェクト固有のオプションを含めることもできます。
{
  "description": "Optimized for back-end development with Python and PostgreSQL",
  "mcpServers": {
    "PostgreSQL": {
      "command": "uvx",
      "args": [
        "awslabs.postgres-mcp-server@latest",
        "--resource_arn", "arn:aws:rds:us-east-1:xxxxxxxxxxxx:cluster:xxxxxx",
        "--secret_arn", "arn:aws:secretsmanager:us-east-1:xxxxxxxxxxxx:secret:rds!cluster-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx-xxxxxx",
        "--database", "dev",
        "--region", "us-east-1",
        "--readonly", "True"
      ]
    }
  },
  "tools": ["*"],
  "allowedTools": [
    "fs_read",
    "report_issues",
    "@PostgreSQL/get_table_schema"
  ],
  "resources": [
    "file://README.md",
    "file://~/.aws/amazonq/python-preferences.md",
    "file://~/.aws/amazonq/sql-preferences.md"
  ],
  "hooks": {
    "agentSpawn": [
      {
        "command": "git status"
      }
    ]
  }
}

カスタムエージェントの使用

エージェントの本当の力は、これらの異なる開発コンテキストを切り替える必要がある時に明らかになります。React と Figma で作業しているときは q chat --agent front-end を、Python と SQL で作業しているときは q chat --agen``t back-end を実行するだけです。Amazon Q Developer は私の好みに合わせて適切なエージェントを設定してくれます。

以下の画像は、Amazon Q Developer CLI における設定を見ることができます。フロントエンドエージェントには Figma という追加のツールがあり、バックエンドエージェントには PostgreSQL という追加のツールがあることに注目してください。さらに、フロントエンドエージェントは fs_write とすべての Figma ツールを信頼しますが、バックエンドエージェントは fs_write の使用許可を求め、2 つの PostgreSQL ツールのうち 1 つだけを信頼します。

Amazon Q Developer CLI における設定

同様に、フロントエンドエージェントとバックエンドエージェントのコンテキスト設定を見てみましょう。以下の画像では、フロントエンド開発用の React の設定とバックエンド開発用の Python と SQL の設定を含めています。

カスタムエージェントのコンテキスト設定

このように、カスタムエージェントを使用することで Amazon Q Developer CLI をタスクごとに最適化することができます。もちろん、フロントエンドとバックエンドのエージェントはただの一例です。開発やテストのエージェント、データサイエンスや分析のエージェントなどがあるかもしれません。カスタムエージェントを使用することでほとんどのタスクに対応した構成にすることができます。

おわりに

Amazon Q Developer CLI カスタムエージェントは、複雑な開発環境を管理する上で重要な改善となります。開発者が異なるコンテキスト間をシームレスに切り替えられるようにすることで、異なるタスクのためにツールや権限を手動で再設定する認知的なオーバーヘッドを排除します。開発ワークフローを合理化する準備はできましたか？今すぐ Amazon Q Developer を始めましょう。