2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

はじめに

最近はClaude CodeやGitHub Copilotなど、AIコーディングエージェントを使ってアプリケーションを簡単に作ることができるようになりました。

一方で、「AWSインフラ構築でも本当に使えるの?」という疑問を持っていました。

そこで今回、AWS IoT Core for LoRaWANを中心としたIoTシステムをClaude Code主体で構築してみました。

構築したシステムはこちらです。

AWS IoT + Amazon Bedrockを利用したスマート菜園PoC

AWS IoT+Amazon Bedrockの構築事例⁠

最終的には

  • AWS IoT Core
  • Lambda
  • DynamoDB
  • S3
  • Amazon Bedrock
  • API Gateway
  • React Nativeアプリ

まで一通り動作する環境を構築できました。

この記事では、Claude CodeでAWS構築を行った実体験を書いてみます。

構築したシステム

全体構成はこのようなシンプルなIoT構成です。
image.png

PoCなので複雑な構成ではありませんが、実際にAWSサービスを横断してサーバレスで構築しています。

Claude Codeに任せたこと

今回、AIでどこまで構築できるのかを検証するため、ClaudeCodeでCDKを実装することにしました。

ちなみに、AWSの公式からAgent向けのToolkitが公開されていますが今回は使用しませんでした。Claudeだけでどこまで実現できるのか試してみたかったからです。

進め方

Claude Codeに実現したい要件や制約を伝え、対話しながらアーキテクチャを検討していきます。
ただし、AIが提案した設計をそのまま採用することはしていません。

例えば、
・セキュリティ要件を満たしているか
・将来の機能追加に耐えられる構成か
・運用や保守がしやすいか
・コストが妥当か

といった観点で人間がレビューを行い、必要に応じて設計を修正していきます。
AIは設計案を高速に作ることは得意ですが、その設計がプロジェクトの目的や制約に適しているかを判断するのは人間の役割となります。

具体的な開発の流れ

  1. AWS CLIインストール
  2. AWS Configureで認証情報をローカルに設定
  3. プロジェクトフォルダを用意
  4. .CLAUDE.mdにルールや禁止事項、ディレクトリ構成を記載
  5. 要件.mdにシステムで実現したいことを箇条書きで記載
  6. 要件.mdをINPUTにしてClaudeにシステム構成案を出させる
  7. 自分の想定と概ね合致するまで対話を繰り返し、構成をまとめる
  8. 構成案ができたらClaudeに設計をさせる
  9. 各サービスの設計書のmdをレビュー→指摘&修正を繰り返す
  10. 各サービスの設計書.mdをINPUTにしてClaudeにCDKの実装を指示
  11. cdkのビルドが通るまで修正を繰り返し、デプロイを実行
  12. デプロイに失敗したらエラーを調査させ設計書とCDKを修正させる(9に戻る)
  13. デプロイが成功したらアプリとセットで動作確認を行う

といった流れでClaudeとの開発をバイブコーディング形式で進めました。
こうやって見てみると人と一緒に仕事をしているのと変わりませんね。

※注意

ちなみに、大規模システムのアプリケーション開発の現場では、チームで開発を行うため、マルチエージェント設計やコンテキストエンジニアリング、ハーネスエンジニアリングといった手法を駆使し、誰もが同様に安定した出力を得られる仕組みづくりが求められます。
今回は趣味の範囲であり、一人で開発を行っているため、手軽なバイブコーディング形式を採用しています。最適な手法として推奨しているものではない点、あらかじめご了承ください。

出力された設計書

大量のMarkdown設計書をレビューするのは骨が折れますが、図や表にして記載してくれるためわかりやすくレビューが捗りました。

image.png

image.png

実装されたCDK

スタックをどのように分割するかいつも悩みますが、Claudeの提案するスタックは理想的だと感じました。

image.png

驚いたこと

AWSサービス間の接続設計がほぼ完璧だということです。

例えば、権限であるIAMとサービス間のパラメータ定義です。

AWS構築の経験豊富な人間でさえ、最適なIAMの権限定義とサービス間の整合性の考慮はわりと苦労する作業です。

これをやってくれるのは本当に助かりました。

一方で、複数の実現方法がある場合に「どれを選ぶべきか」という設計判断はプロジェクトによって変わります。

AIは候補を提示することは得意ですが、最終的な選択には経験や運用を踏まえた判断が必要でした。

もちろん失敗もする

当然ですが、1回で100%成功することはありません。

例えば、いざ動かしてみるとIAMポリシー不足でエラーになるといったことは少なからずありました。

ただ、エラー発生からのトライ&エラーについても人間より遥かに高速に実行することができるため、解決に至るスピードも速いです。

一番便利だった使い方

個人的には、エラー解析が最強でした。

AWSのエラーは手がかりが少なく、さまざまなログをわたり歩くことになり、原因分析にはいつも苦労していました。
しかし、AIによる状況分析と推測の能力は高く、原因の特定は私より遥かに速いです。
結果や解説を見て「なるほど」と勉強させられる場面も多いです。

AIが答えを出してくれるというより、「原因調査を大幅に高速化してくれる」という感覚です。

最終的な判断は人間が行いますが、調査時間は体感で数分の一になったと思います。

AI駆動クラウド構築で感じたこと

AIは非常に優秀な実装者です。
しかし、システム開発で本当に難しいのは「何を作るか」「どのように実現するか」を決めることです。

例えば、

・業務要件、非機能要件の整理
・セキュリティやガバナンス
・運用設計
・障害時の復旧方法
・コストと性能のバランス
・将来の拡張性

これらはプロジェクト全体を理解した上で意思決定する必要があります。
AIは選択肢を提示できますが、最終的な意思決定と責任を持つことはできません。

だからこそ、AI時代のSIerには『実装する会社』ではなく、『AIを活用して最適なシステムを設計・実現する会社』としての役割が求められると感じました。

まとめ

今回のPoCでは、Claude Codeを活用することでAWSインフラ構築のスピードは大幅に向上しました。

一方で、AIが得意なのは「実装を高速化すること」であり、「システムとして成功するかどうか」を判断することではありません。

要件を整理し、適切なアーキテクチャを選択し、品質・セキュリティ・運用まで含めて設計することは、依然として人間の重要な役割です。

今後は『AIか人間か』ではなく、『AIを前提として、より高品質なシステムを短期間で提供できるか』がSIerの競争力になっていくと感じました。

AIはSIerの仕事を奪う存在ではなく、エンジニアがより本質的な設計や顧客価値の創出に集中するための強力なパートナーだと考えています。


※本記事の内容は個人の見解であり、所属する組織の公式見解ではありません。

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?