AI駆動開発の社内ハッカソンでAWS上にアプリケーションを構築した時に工夫したこと

はじめに

手動でのコーディングが禁止の社内のハッカソンでAWS上にWebアプリケーションを作成しました。
今回やってみて良かったなということを、AWS関連にフォーカスして以下の3つの課題を軸にまとめてみました。

AIがAWSインフラの状態を把握できない
AIが最新のベストプラクティスに沿わないコードを生成してしまう
人間の承認待ちが開発のボトルネックになってしまう

課題1: AIがAWSインフラの状態を把握できない

AIにコードを書かせるときに課題になるのが コンテキストの不足 です。
「S3バケットにファイルをアップロードするLambda処理を書いて」と指示しても、AIは次のことを知りません。

バケット名は何か
S3の設定がどうなっているか
バックエンドのLambdaはどんな権限を持っているか

その結果、AIが生成するコードが実際の構成と噛み合わない設定になってしまい、動くまでに大量の手直しが発生する可能性があります。

解決策: インフラをIaCで定義し、コンテキストとして共有する

IaC（Infrastructure as Code） を利用することで、この問題を根本から解決できます。

IaCでインフラを定義すると、すべての構成がコードとして記述されます。
これをAIのコンテキストウィンドウに渡すだけで、AIはインフラの全体像を把握した上でコードを生成できます。

今回ハッカソンでAmplify Gen2 / CDKを利用したので、コードサンプルもそちらを利用しています。
amplify/backend.tsの実装例：

// 一部抜粋なので単体では動作しません
// S3の設定
const storage = defineStorage({
  name: "reviewStorage",
  access: (allow) => ({
    "uploads/*": [allow.authenticated.to(["read", "write"])],
  }),
});

// LambdaにS3アクセス権限を付与
backend.uploadFunction.resources.lambda.addToRolePolicy(
  new PolicyStatement({
    effect: Effect.ALLOW,
    actions: ["s3:GetObject", "s3:PutObject"],
    resources: [backend.storage.resources.bucket.bucketArn + "/uploads/*"],
  }),
);

上記のようなIaCのコードがあれば、バケット名や「Lambdaからは /uploads/* だけにアクセスできる」といった情報をAIが読み取り、プロジェクトの構成に沿ったコードを生成できるようになります。
今回はAIを使う前提ですが、人間がソースを見る場合でもIaCを利用することでインフラの把握に役立つので、ぜひ活用してみてください。

課題2: AIが最新のベストプラクティスに沿わないコードを生成してしまう

AWSのサービスは日々アップデートされているため、ベストプラクティスも更新されます。
AIモデルの学習データには カットオフ日 があるため、次のような問題が起きます。

古いSDKの書き方を提案される（非推奨だったり、そもそもビルドが通らなかったり）
最新のセキュリティガイドラインに準拠していない設定を書かれる

解決策: AWS公式MCPサーバーで最新情報を参照させる

MCP（Model Context Protocol） を活用すると、AIが外部の最新情報にアクセスできるようになります。
AWSは公式のMCPサーバーを提供しており、Claude CodeなどのMCP対応ツールと組み合わせることで、AIがリアルタイムでAWS公式ドキュメントやベストプラクティスを参照しながらコードを書けるようになります。

今回使ってみたMCPサーバー：

MCPサーバー	できること
aws-documentation-mcp-server	AWS公式ドキュメントの検索・参照
aws-iac-mcp-server	CDKとCloudFormationのベストプラクティスを参照（cdk-mcp-serverの方は執筆時点で非推奨なので注意）
context7	各種ライブラリの最新ドキュメントを参照（AWSの公式MCPではありませんが、色々なライブラリの最新情報を参照できます）

MCPを使ったAIは、最新のドキュメントを必要に応じて参照してコードを生成するため、「学習データが古い」問題を大幅に軽減できます。
具体的な利用例だと、MCP無しだとBedrockの設定でClaude 3.7系（執筆時点で1年前のモデル）を設定していたのが、MCPを利用すると最新のモデルを設定してくれるようになりました。
自分で最新の情報やベストプラクティスを調べる手間が減り、作業時間の短縮にもつながりました。

注意点としてMCPを利用するとコンテキストを追加で使ってしまう弊害もあるので、利用するものは精査してください

課題3: 人間の承認待ちが開発のボトルネックになってしまう

一般的なAIエージェントを利用しているとアプリケーションのログ確認やテスト環境へのデプロイコマンド発行など、ツール利用時にAIエージェントのツール利用で毎回人間が確認していると、以下の問題が発生します。

AIがものすごく速く実装してくれるのに、人間の承認待ちで動きが止まってしまう
重要でないツールの確認に埋もれて、重要なツールの確認がおろそかになってしまう（疲れていると適当に承認してしまいそうになる）

解決策: AIエージェント許可設定やIAM設定で自律範囲を設定する

1. AIエージェントが実行してよい操作を許可する

.claude/settings.json での許可設定例（詳しくはこちら）:

{
  "permissions": {
    "allow": [
      "Bash(aws logs describe*)",
      "Bash(aws logs get-log-events*)",
      "Bash(aws logs filter-log-events*)",
      "Bash(npx ampx sandbox*)"
    ]
  }
}

サンプルで載せている上記の例だと、アプリケーションのデバッグ時のCloudWatch Logsの確認やAmplifyのsandbox環境更新を自動で実行してくれるようになります。
AIでのデバッグ中にログ確認のたびにAIの動きが中断されることがなく、自律的にAIが作業をできたため、かなりスムーズにデバッグができました。

プロジェクト特性上AIが勝手に実行してよい操作だけを許可するように注意してください。

2. IAMで操作できる範囲を事前に定義する

AIの権限設定をしているとはいえプロジェクトによって、AIが自律的にAWSの操作を行わせるのは難しい場合があると思います。
その場合は、AIエージェントを利用するターミナルではReadOnlyの権限のセッション利用するなど、各プロジェクトのフェーズや特性に応じてIAMの制限を行います。
そうすることで、AIエージェントがAWS CLIコマンドで本来すべきではない操作をしようとした場合に、IAMレベルでガードすることができます。

まとめ

課題	解決策
AIがAWSインフラの状態を把握できない	IaCでインフラをコード化し、AIに読ませる
AIが最新のベストプラクティスに沿わないコードを生成してしまう	MCPを利用して最新ドキュメントをAIに参照させる
人間の承認待ちが開発のボトルネックになってしまう	AIエージェント許可設定やIAMで自律範囲を設定する

今回ハッカソンで手でコードを一切編集せずにWebアプリケーションの作成することを通じて、「コンテキスト提供」、「最新情報提供」、「問題ない操作の許可」をすることで、AIエージェントを利用した開発の効率が上がることが改めて分かりました。
みなさんもAIエージェントを利用して色々なものをビルドしてみてください！

AI駆動開発の社内ハッカソンでAWS上にアプリケーションを構築した時に工夫したこと

はじめに