
AI駆動開発をAWSで実践する手順と体制
AI駆動開発をAWS上で始めようとすると、最初に話題になるのはたいていツールの選定です。ところが実際に現場が止まるのは、どのタスクをAIに任せるかと、生成物を誰がどこで見るかが決まっていないときでした。この記事では、AWSで実践するために先に決めることと環境の構成、AI-DLCとの重なり、医療情報基盤への適用例を順に整理します。
AI駆動開発をAWSで進める前に適用範囲を決める
どのAWSサービスを使うかより先に、AIに任せる範囲と人が判断する範囲の線引きが要ります。gaipackがAIDD(AI駆動開発)の適用可否を判断するとき、まず見るのはタスクの性質です。
| タスク分類 | 適用性 | 理由 | 適用例 |
|---|---|---|---|
| 定型・反復業務 | ★★★ | 文法・規則の学習に強く、定型タスクで効果が出やすい | テストケース生成、設計書ドラフト、API仕様書 |
| ドキュメント生成 | ★★★ | 構造化・整理されていて個人差が小さい | README、ガイドライン、運用手順書 |
| コード実装 | ★★☆ | 既存コードと開発ルールをインプットにできる場合は効果が大きい | 定型のCRUD実装、データ処理ルーチン |
| 初期テスト | ★★☆ | ケース生成には効果があり、実行は自動化が前提になる | ユニットテスト、E2Eのシナリオ定義 |
| 要件定義・企画 | ★☆☆ | 創造性と判断が主体で、AIは補完役にとどまる | 要件書ドラフト、提案資料の下書き |
| 意思決定・判断 | ★☆☆ | 人間の判断が必須で、AIは根拠の整理を支援する | 優先度判断、リスク許容度、体制判断 |
押さえたいのは★☆☆の行を無理にAI化しないという判断です。範囲を絞り込むほうが結果として品質は安定します。この線引きはAWS環境かどうかにかかわらず先に済ませます。
インプット品質からAWS上での適用可否を判断する
範囲が決まったら、既存の資料がどれだけ読める状態にあるかを評価します。開発スピードを2倍以上に短縮できるのはインプット品質が80%以上そろっている場合で、条件を外すと同じようには再現しません。起票時に整理度合いを評価し、そこから適用の深さを決めます。
Loading diagram...
整理度合いが30%程度以下なら見送るか範囲を限定する、という判断まで含めている点が実務的です。資料が散らばったまま着手すると、生成物を人が読み直す時間のほうが増えます。進め方の全体像はAI駆動開発にまとめています。
AWS上でAIDD環境を構成する要素
線引きが決まったら環境を組みます。gaipackのAIDD環境は、クラウド上の開発環境とAIエージェント、そしてスキルの配布と評価の仕組みで構成されています。
| コンポーネント | 役割 |
|---|---|
| GitHub Codespaces | クラウド開発環境 |
| Dev Container | 開発コンテナの標準化 |
| Claude Code | AI駆動開発エージェント |
| GitHub Projects | タスク管理 |
| Chrome Enterprise | セキュアブラウザ環境 |
| SKILL Marketplace | 組織横断でのスキル共有・配布基盤 |
| APM(Agent Package Manager) | スキルをAI統制ポリシー付きでチームへ配布する |
| WAZA | スキルが効いているかを評価する |
AIの作業ルールはAGENTS.mdへ集約し、タスク別のSKILL.mdを.agents/skills/配下に置きます。エージェントが参照する指示と生成された成果物が、これで構造として分かれます。
標準の技術スタックはTypeScript / React / Next.js / Pythonで、案件要件に応じてJavaやGoにも対応します。GitHubの年次調査Octoverse 2025は、2025年8月にTypeScriptがPythonとJavaScriptを抜いて最も使われる言語になったと報告し、型のある言語ほどエージェント支援のコーディングが確かになりやすい傾向として説明しています。AWSのMCPサーバーを設計と実装へ組み込んだ実践はAWS MCPをAIDDの設計・実装に組み込むで扱っています。
AI駆動開発とAWSのAI-DLCはどう重なるか
AWSが提唱するAI-DLC(AI駆動開発ライフサイクル)は、AIを前提に開発のライフサイクルそのものを組み替える考え方で、AWS公式ブログに手法が公開されています。gaipackのAIDDスキームとは目的が近く、対象としている層が違います。
| 観点 | AI-DLC(AWSが提唱) | AIDDスキーム(gaipack) |
|---|---|---|
| 位置づけ | 開発ライフサイクルの再構成モデル | 受託開発の現場に落とす実行スキーム |
| 主な射程 | 構想から運用までのフェーズ設計 | 体制・完了条件・承認フローまで含む |
| 適用範囲の決め方 | 手法として全体に適用する | タスク分類とインプット品質から判断する |
| 前提環境 | AWSのサービス群と親和性が高い | クラウドは案件要件に合わせて選ぶ |
両者は排他ではありません。AI-DLCの考え方をAWS上で具体化するときに、適用判断とレビュー設計を足すのがgaipackの立ち位置です。AI-DLCの定義と3フェーズはAI-DLC(AI駆動開発ライフサイクル)とは、両者の対応関係はAI-DLCとgaipack AIDDの重なりで扱っています。
AWSで動く医療情報基盤にAI駆動開発を適用した実例
医療機関向けの院内基盤システムとPHRアプリを開発した案件では、AWS上でAIDDを適用しました。ブロックチェーンとHL7 FHIRという国際標準規格への対応があり、医療情報保護法をはじめとする法規制の遵守も外せないという条件が重なっています。
| 領域 | 採用したもの |
|---|---|
| AI基盤 | Amazon Bedrock、Amazon Bedrock Knowledge Bases |
| インフラ | AWS Amplify、AWS CDK |
| セキュリティ | AWS WAF、マイナンバーデジタル認証アプリ連携 |
当初1年と見積もられていたリニューアルを半年で市場投入し、開発コストは約4分の1になりました。運用に入ってからの修正対応も、従来2週間程度かかっていたものが早ければ当日中に反映できる状態になっています。複雑なFHIRのデータ構造をAIに読み込ませて処理実装を任せ、人間はデータ整合性とセキュリティ設計に集中するという役割分担が、この短縮を支えました。案件の詳細は医療情報基盤の導入事例をご覧ください。
AI駆動開発をAWSで始めるときにつまずく点
ここまでの手順を踏んでも、着手の順番を取り違えると同じところで止まります。相談を受けた案件で繰り返し見えたのは次の3つでした。
つまずき1:ツールの選定から始めてしまう
エージェントやIDEを先に決めても、任せる範囲が決まっていなければ生成物の使い道が案件ごとにばらつきます。タスク分類とインプット品質の評価を済ませてから必要な環境を足すほうが、手戻りは小さくなります。
つまずき2:レビューの置き場を決めないまま走る
生成が速くなるほど人が見る量は増えます。担当と観点を工程ごとに割り当てず最後にまとめて確認する運びにすると、承認待ちが新しいボトルネックになります。誰がどのフェーズで何を見るかを、着手前にスケジュールへ入れておきます。
つまずき3:運用フェーズを後回しにする
リリースまでを短縮しても、運用の調査や修正が従来のままだと体感のスピードは戻ってしまいます。監視から調査、修正、承認までの流れをどこまでAIに寄せるかは、開発の設計と同じタイミングで決めておきます。運用側の受け皿はgaipack オプスにまとめています。
AI駆動開発とAWSに関するよくある質問
着手前の相談で受けることの多い質問をまとめました。
AWSのサービスを使わないとAI駆動開発はできませんか
できます。AIDDは開発プロセスの考え方であり、特定のクラウドに依存しません。ただしAWS上で動いているシステムが対象なら、既存の権限管理や監視をそのまま活かせる分だけ着手は速くなります。
AI-DLCとAI駆動開発は同じものですか
同じではありません。AI駆動開発はAIを前提に開発プロセスを組み替える取り組み全般を指す広い言葉で、AI-DLCはその中でAWSが提唱している具体的なライフサイクルモデルにあたります。AI-DLCを採ったうえで、適用範囲の判断やレビュー設計を自社の運用に合わせて足す重ね方ができます。
既存のAWS環境にも後から適用できますか
適用できることが多いです。分かれ目はクラウド環境そのものよりも、既存コードと設計資料がどれだけ読める状態にあるかにあります。整理度合いが30%程度以下であれば、まず資料の前整理から入り、そのうえで適用範囲を再評価します。既存資産の刷新を伴う場合はAIDD モダナイズが受け皿になります。
小さなチームでもAWS上でAI駆動開発を始められますか
始められます。タスク分類で★★★にあたるドキュメント生成やテストケース生成のように、範囲を絞って効果が出やすいところから入るのが現実的です。人数が少ないチームほどレビューの担い手が限られるため、対象を広げすぎないことが品質を守ります。
まとめ
AI駆動開発をAWSで実践するときに先に決めるのは、任せるタスク、インプットの整理度合い、レビューの置き場の3つです。環境の構成やAI-DLCとの重ね方は、その線引きが決まってから具体化するほうが手戻りは小さくなります。制約の多い医療情報基盤でも、役割分担を先に固めたことで半年での市場投入と当日中の修正反映が両立できました。
どこから適用できるかは、扱う資料と体制によって変わります。自社のAWS環境での進め方について、お気軽にご相談ください。
※ 本記事の内容は公開時点の情報です。サービスの名称・内容・料金は予告なく改訂されることがあります。




