ゼロからの開発で欠かせない「外部ライブラリ」と「ファイル構造」の理解に焦点を当て、Vue.jsプロジェクト作成の手順に沿って解説します。Vue.jsとNode.jsの役割の違い、npm、Vite、Vue CLIといった主要なツールについて説明し、Viteで作成されたプロジェクトの基本的なファイル構成とその役割を具体的に示します。開発の土台となる知識を固めることの重要性を強調します。

2026 年 1 月 26 日週、私たちは ラバ祭り を祝いました。これは、旧正月まで残りわずかであることを告げる中国暦の伝統的な祝日です。ラバ祭りは、中国の多くの人々にとって振り返りと準備にまつわる祝日であり、今年の出来事をまとめ上げ、未来に目を向けます。 2026 年 2 月 9 日週は、春の始まりであり、二十四節気最初の節季である 立春 です。中国の伝統では、春は成長が始まり、新しい節目がやってくる季節として捉えられることがよくあります。「一年の計は春にあり」ということわざもあり、春が自分の方向を定め、新たなスタートを切るときだという考え方を反映しています。 2026 年 1 月 26 日週のリリース 2026 年 2 月 2 日週私が注目したリリースをご紹介します。 Amazon Bedrock がサーバーサイドツールと拡張されたプロンプトキャッシュでエージェントワークフローのサポートを強化 – Amazon Bedrock に、開発者が AI エージェントを構築して運用する方法を改善する 2 つのアップデートが導入されました。 Responses API がサーバーサイドツールの使用をサポート するようになりました。このため、エージェントは AWS のセキュリティ境界内でウェブ検索、コード実行、データベース更新などのアクションを実行できます。 Bedrock には、プロンプトキャッシュのための 1 時間有効期限 (TTL) オプションも追加されました 。この延長は、長時間にわたるマルチターンエージェントワークフローのパフォーマンス向上とコスト削減に役立ちます。Amazon Bedrock では、OpenAI GPT OSS 20B および 120B モデルで サーバーサイドツールを利用でき、1 時間のプロンプトキャッシュ TTL は 一部の Anthropic Claude モデルに一般提供されています。 Amazon SageMaker Unified Studio が AWS PrivateLink を用いたプライベート VPC 接続を追加 – Amazon SageMaker Unified Studio が AWS PrivateLink のサポートを開始しました。このサポートにより、VPC と SageMaker Unified Studio 間のプライベート接続が提供されるため、カスタマーデータをパブリックインターネット経由でルーティングする必要はありません。VPC にオンボードされた SageMaker サービスエンドポイントを使用すると、データトラフィックが AWS ネットワーク内に留まり、IAM ポリシーによって制御されるため、より厳格なセキュリティとコンプライアンス要件をサポートできます。 Amazon S3 がデータ移動を必要としないオブジェクト暗号化の変更をサポート – Amazon S3 では、データを移動または再アップロードしなくても、既存の暗号化されたオブジェクトのサーバー側暗号化タイプを変更できるようになりました。 UpdateObjectEncryption API を使用することで、オブジェクトプロパティとライフサイクル適合性を維持しながら、SSE-S3 から SSE-KMS への切り替え、お客様管理の AWS Key Management Service (AWS KMS) キーのローテーション、または S3 バッチオペレーションによるバケット全体での暗号化の大規模な標準化を行うことができます。 Amazon Keyspaces が予測可能な高スループットワークロードのためのテーブルの事前ウォーミングを導入 – Amazon Keyspaces (Apache Cassandra 向け) がテーブルの事前ウォーミングをサポートするようになりました。これは、ウォームスループットのレベルを事前に設定して、テーブルが大量の読み取りおよび書き込みトラフィックを瞬時に処理できるようにするため、コールドスタートによる遅延が発生しません。事前ウォーミングは、製品のリリースやセールスイベントなど、トラフィックが急激に増加するときのスロットリングの軽減に役立ち、マルチリージョンテーブルを含めたオンデマンドキャパシティモードとプロビジョニングキャパシティーモードの両方で動作します。この機能は、一貫的な低レイテンシーパフォーマンスをサポートしながら、スループットの準備状態をより細かく制御できるようにします。 Amazon DynamoDB MRSC グローバルテーブルが AWS Fault Injection Service と統合 – Amazon DynamoDB マルチリージョン強整合性 (MRSC) グローバルテーブルが AWS Fault Injection Service に統合されました。この統合を利用することで、強力な整合性を備えたマルチリージョンワークロードのためにリージョン障害をシミュレートし、レプリケーション動作をテストして、アプリケーションのレジリエンシーを検証できます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS Verified Access を使用したマルチアカウント AWS 環境でのゼロトラストアクセスの構築 – この記事では、一元化された共有サービスアーキテクチャに AWS Verified Access を実装する方法を詳しく説明します。AWS IAM アイデンティティセンターおよび AWS Resource Access Manager (AWS RAM) と統合して、アプリケーション層にゼロトラストアクセスコントロールを適用し、マルチアカウント AWS 環境全体で運用オーバーヘッドを削減する方法を紹介します。 Amazon EventBridge がイベントのペイロードサイズを 1 MB に増加 – Amazon EventBridge が 最大 1 MB のイベントペイロードをサポートするようになりました。これは、以前の 256 KB 上限からの増加となります。この更新は、イベント駆動型アーキテクチャが、ペイロードを分割したり外部ストレージに依存したりすることなく、単一のイベント内でより充実したコンテキスト (複雑な JSON 構造、テレメトリデータ、機械学習出力、生成 AI 出力など) を確保できるようにします。 AWS MCP サーバーがデプロイエージェント SOP を追加 (プレビュー) – AWS がデプロイ SOP (Standard Operating Procedure) を導入しました。この SOP では、AI エージェントが Kiro、Cursor、Claude Code といった MCP 互換の統合開発環境 (IDE) やコマンドラインインターフェイス (CLI) での単一の自然言語プロンプトから AWS にウェブアプリケーションをデプロイできます。エージェントは、AWS Cloud Development Kit (AWS CDK) インフラストラクチャを生成し、AWS CloudFormation スタックをデプロイして、AWS ベストプラクティスに従った継続的インテグレーションと継続的デリバリー (CI/CD) ワークフローを設定します。プレビューでは、React、Vue.js、Angular、Next.js などのフレームワークがサポートされています。 AWS Network Firewall がウェブカテゴリフィルタリングによる生成 AI トラフィック可視性を追加 – AWS Network Firewall が、定義済みのウェブカテゴリを通じて生成 AI アプリケーショントラフィックの可視性を提供するようになりました。ファイアウォールルール内でこれらのカテゴリを直接使用することで、生成 AI ツールやその他ウェブサービスへのアクセスを制御できます。TLS インスペクションと組み合わせると、カテゴリベースのフィルタリングを完全な URL レベルで適用できます。 AWS Lambda が Kafka イベントソースマッピングのオブザーバビリティを強化 – AWS Lambda に、Kafka イベントソースマッピングのための強化されたオブザーバビリティが導入されました。これは、イベントポーリング設定、スケーリング動作、イベント処理状態を監視するための Amazon CloudWatch Logs とメトリクスを提供します。この更新により、Kafka ベースの Lambda ワークロードの可視性が向上し、チームが設定上の問題、許可エラー、および関数の失敗をより効率的に診断できるようになります。この機能は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) イベントソースとセルフマネージド Apache Kafka イベントソースの両方をサポートします。 AWS CloudFormation 2025 年の振り返り – 1 年を振り返るこの記事では、2025 年に行われた CloudFormation 更新が紹介されており、早期検証、より安全なデプロイ、改善された開発者ワークフローに焦点を当てています。改善されたトラブルシューティング、ドリフト認識変更セット、スタックリファクタリング、StackSets 更新、および CloudFormation 言語サーバーや Infrastructure as Code (IaC) MCP サーバーを含めた新しい IDE と AI 支援ツールなどの機能強化が取り上げられています。 今後の AWS イベント カレンダーを確認して、近日開催予定のイベントにサインアップしましょう。 AWS Community Day Romania (2026 年 4 月 23～24 日) – このコミュニティ主導の AWS イベントでは、AWS ヒーロー、ソリューションアーキテクト、および業界エキスパートによる 10 を超えるプロフェッショナルセッションのために、開発者、アーキテクト、起業家、学生が一堂に会します。参加者は、エキスパートによるテクニカルトーク、世界的なカンファレンスで経験を積んだ講演者からのインサイト、参加者だけのネットワーキングブレイクでつながる機会を期待できます。これらはすべて、コラボレーションとコミュニティエンゲージメントをサポートするために設計されたハイクラスな会場で行われます。 このイベント外でもつながりを維持する方法をお探しの場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学び、構築し、つながりましょう。 2026 年 2 月 9 日週の Weekly Roundup もお楽しみに! – Betty 原文は こちら です。

はじめに こんにちは、リテールハブ開発部の杉森です。 近年、AIを活用した開発ツールが急速に普及しています。私たちのチームでも積極的にAIツールを導入し、要件定義でのユーザーストーリー作成、設計ドキュメントの生成、コードの自動補完、テストコードの生成など、各開発フェーズの作業効率化を図ってきました。 しかし、個々の作業は確かに早くなっているのに、プロダクト開発フロー全体を見ると期待したほどの生産性向上を実感できないという課題に直面しました。 本記事では、この課題に対するアプローチとして導入を検討しているAI-DLC（AI-Driven Development Lifecycle）について紹介します。 AI-DLCとは AI-DLCは、AWSが提唱するAIネイティブな開発方法論です。方法論のホワイトペーパーで理論的な枠組みが定義されており、これを実装するためのワークフローがaidlc-workflowsとしてGitHub上で公開されています。 AWSの公式ブログでは、現在のAI活用における2つのアンチパターンが指摘されています。 AI-Assisted: 人間が設計を主導し、AIはコード補完など狭い範囲の支援にとどまる。生産性向上は限定的で、AIの能力を十分に引き出せない AI-Managed: 複雑な問題をAIに丸投げし、自律的にすべてを解決することを期待する。出発点が曖昧なためAIが多くの仮定を立て、プロトタイプ以外ではほぼ機能しない AI-DLCは、これらのアンチパターンに対するアプローチとして設計されています。AIが作業計画の作成やタスク分解を主導し、人間がその内容を検証・承認し、AIが承認された計画に基づいて実行するというサイクルで、開発ライフサイクル全体を進めます。 AI駆動開発ライフサイクル（AWS公式ブログ） aidlc-workflows（GitHub） 従来の開発手法との違い AI-DLCは、既存の開発手法にAIを後付けするのではなく、AIを前提とした開発プロセスをゼロから設計しています。ホワイトペーパーでは、以下の設計思想が示されています。 AIが会話を主導する: 従来は人間がAIに指示を出していたが、AI-DLCではAIがタスク分解や提案を行い、人間は承認・判断に集中する Intent / Unit / Bolt: ビジネス目標（Intent）を作業単位（Unit）に分解し、数時間〜数日の短いサイクル（Bolt）で実装を回す。ScrumのSprintに近いが、サイクルが短い 各ステップで人間がチェックする: AIの出力を段階ごとに検証し、誤りを早期に検出する。ホワイトペーパーでは「損失関数のように機能する」と表現されている 設計技法を方法論に組み込む: ScrumやKanbanがチームに委ねていたDDD等の設計技法を、方法論の一部として標準化する aidlc-workflowsの設計原則 aidlc-workflowsは、上記の設計思想を実装するにあたり、以下の5つの設計原則に基づいています。 原則 説明 No Duplication 設定やルールを一箇所で管理し、重複を排除する Methodology First 特定のツールに縛られず、方法論そのものを軸にする Reproducible ルールを明文化し、使うAIモデルが変わっても結果がぶれないようにする Agnostic IDE・エージェント・モデルを問わず動作する Human in the Loop 重要な判断には必ず人間の承認を挟む 3フェーズ構成 AI-DLCは、以下の3つのフェーズで構成されています。 INCEPTION PHASE: WHATとWHYの決定 CONSTRUCTION PHASE: HOWの実装 OPERATIONS PHASE: デプロイと監視（aidlc-workflows上は未実装） INCEPTION PHASE 「何を作るか（WHAT）」「なぜ作るか（WHY）」を決定するフェーズです。方法論のホワイトペーパーでは「Mob Elaboration」というプラクティスとして定義されており、共有画面を使ってチーム全体でAIの質問と提案を検証します。AIがビジネス意図（Intent）を明確化する質問を投げかけ、ユーザーストーリー、非機能要件、リスク記述を生成し、凝集度の高い作業単位（Unit）へ分割します。 aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。 ステージ 説明 Workspace Detection プロジェクトの状態を分析（新規/既存の判定） Reverse Engineering 既存コードベースの理解（Brownfieldの場合） Requirements Analysis 要件の収集と整理 User Stories ユーザーストーリーの作成 Workflow Planning 実行計画の策定 Application Design アプリケーション設計 Units Generation 作業単位への分割 CONSTRUCTION PHASE 「どう作るか（HOW）」を決定し、実際にコードを生成するフェーズです。方法論のホワイトペーパーでは、Domain Design（ビジネスロジックのドメインモデリング）→ Logical Design（非機能要件を含むアーキテクチャ設計）→ Code & Unit Tests（コードとテストの生成）→ Deployment Units（デプロイ可能な成果物の構築）という流れで進みます。「Mob Construction」でチームがリアルタイムで技術的決定とアーキテクチャの選択を行います。 aidlc-workflowsでは、このフェーズが以下のステージに細分化されています。 ステージ 説明 Functional Design 機能設計（ユニットごと） NFR Requirements/Design 非機能要件の設計 Infrastructure Design インフラ設計 Code Generation コード生成 Build and Test ビルドとテスト OPERATIONS PHASE デプロイと監視を担当するフェーズです。方法論としては定義されていますが、aidlc-workflowsには含まれておらず、将来的にワークフローが追加される予定です。 対応プラットフォーム 公式では以下のプラットフォームがサポートされています。 Kiro CLI Amazon Q Developer IDE plugin Kiro IDE（Coming Soon） 試してみる 導入の背景 私たちのチームの課題は、まさにAI-Assistedパターンに該当します。AIを個々の作業の効率化には活用できているものの、生産性向上は限定的にとどまっていました。 私たちのチームでは、Kiro CLIをすぐに使える環境ではなかったため、Claude Code向けにカスタマイズして使用しました。AI-DLCはツールに依存しない設計を謳っているため、ルールファイルを調整すれば他のAIツールでも問題なく適用できると考えています。 Claude Code向けのカスタマイズ 以下のようにClaude Code向けにカスタマイズしました。 1. カスタムコマンド（スキル）の作成 .claude/commands/aidlc.md にワークフロー定義を配置し、 /aidlc コマンドで起動できるようにしました。 .claude/ ├── commands/ │ ├── aidlc.md # メインワークフロー │ ├── aidlc-pr.md # PR作成用 │ └── aidlc-archive.md # アーカイブ用 └── aidlc-rule-details/ ├── common/ # 共通ルール ├── inception/ # INCEPTIONフェーズ ├── construction/ # CONSTRUCTIONフェーズ └── operations/ # OPERATIONSフェーズ 2. ルールファイルの分割 各ステージの詳細指示を .claude/aidlc-rule-details/ 以下に分割配置しています。これにより、AIが必要なタイミングで必要なルールのみを読み込み、コンテキストを効率的に使用できます。 クーポン機能を題材にした検証 AI-DLCの有効性を検証するため、小売向けアプリのクーポン機能開発を題材に検証を実施しました。 検証概要 対象システム: Flutter + Laravel + Vue.js + Goで構成されたマルチプラットフォームアプリ 題材: ポイント後付けクーポンと即時値引きクーポンの2種類 検証範囲: モバイルアプリ、管理画面、バックエンドAPI、バッチ処理 チーム構成: PdM1人+エンジニア2人 検証の進め方 「クーポン機能を追加したい」というビジネス意図（Intent）を起点に、AI-DLCのフェーズに沿って進めました。 INCEPTION PHASE（3人で実施）: AIが要件を深掘りする質問を投げかけ、ユーザーストーリーや非機能要件を生成。PdMとエンジニアがその内容を検証・修正し、作業単位（Unit）に分割 CONSTRUCTION PHASE（1人で実施）: Unitごとにドメイン設計、コード生成、テスト生成を実施。各ステージでAIの出力を確認し、承認・修正を繰り返した 今回は検証目的だったこともあり、各フェーズ半日ずつの計1日で実際に動くものまで作成できました。Inceptionフェーズの要件・設計をより作り込み、Constructionフェーズではガードレールの整備やAIが自律的に改善できる体制を組むことで、さらに短縮できる余地があると感じています。 実際の様子 AIからの深掘り質問（Inceptionフェーズ） Requirements Analysisでは、AIが要件の曖昧な部分を選択肢付きで質問してきます。以下はその一例です。 AI : クーポン利用状態の管理について確認させてください。ユーザーがクーポンを「利用」した後の状態管理はどうなりますか？ A) 1回利用したら即座に使用済みになる（再利用不可） B) 有効期限内であれば何度でも利用可能 C) クーポンごとに利用回数を設定可能（1回、3回、無制限など） AI : クーポンの種類と適用範囲について確認させてください。 A) 全ての種類が両方のクーポンタイプで使用可能 B) クーポンタイプごとに使用可能な種類が決まっている このように、AIが仕様の選択肢を提示し、人間が判断するというサイクルでRequirements Analysisが進みます。初回の質問10問、追加の深掘り質問6問を経て、要件定義ドキュメントが生成されました。 人間による設計修正（Inceptionフェーズ） Application Designでは、AIが設計の選択肢を提示し、人間が判断するケースがありました。 人間 : アクティブユーザーではないユーザーにもレコードが作成されてしまいませんか？ AI : 2つの選択肢があります。 A) クーポン公開時に全ユーザー分のuser_couponsレコードを作成 B) クーポン利用開始時にのみuser_couponsレコードを作成 人間 : B 生成されたユーザーストーリー（Inceptionフェーズ） User Storiesでは、管理者向け6件、会員ユーザー向け6件、システム向け1件の計13件が生成されました。以下はその一部です。 US-01: クーポン新規作成 As a 管理者 I want to 管理画面から新しいクーポンを作成したい So that 会員ユーザーに対してキャンペーンを提供できる Acceptance Criteria: クーポンタイプ（ポイント後付け/即時値引き）を選択できる クーポン名と説明文を入力できる 有効期限（開始日・終了日）を設定できる 対象店舗を選択できる 生成されたコード（Constructionフェーズ） Constructionフェーズでは、Unitごとにドメイン設計 → コード生成 → テスト生成が進みます。最終的に以下の規模のコードが生成されました。 Unit 対象 生成ファイル数 主な成果物 Backend Laravel 51ファイル Enum, Model, Migration, Service, Controller, Test Dashboard Vue.js 16ファイル Composable, Component, Schema, Page Mobile Flutter 38ファイル Entity, Repository, Provider, Widget, Page わかったこと / 今後の展望 良いと感じた点 実際にAI-DLCを触ってみて、以下の点が良いと感じました。 Human in the Loopの実現: AIが実行し、人間が監視するという関係性が明確。各ステージで人間の承認が必要なため、重要な意思決定は人間がコントロールできる コンテキストの保存と再開: aidlc-state.md でプロジェクトの状態を追跡しているため、セッションが途切れても前回の続きから再開できる ドキュメント化による追跡可能性: audit.md にすべてのやり取りが記録されるため、なぜその決定をしたのかを後から追跡できる 適応的なワークフロー: プロジェクトの複雑さに応じて、実行するステージが自動的に調整される 試した上で見つかった課題 Inception前の準備の必要性 今回「クーポン機能を追加したい」というリクエストからInceptionを開始しましたが、背景知識や「なぜこの機能が必要なのか」がアウトプットに反映されにくいことがわかりました。また、要件の解像度が低い状態でInceptionを始めると、議論が発散しやすくなります AI-DLCのInceptionに入る前に、ビジネス背景や目的を整理するステップが必要だと感じました。 仕様とAI実装のギャップ Inceptionフェーズで仕様を決め切った上でも、以下の2つの問題が発生しました。 仕様の記載漏れ: Inceptionフェーズで決めた仕様に漏れがあり、Constructionフェーズで初めて気づくケース。例えば、APIレスポンスのラッパー形式やお気に入り店舗のパラメータなど、実装段階で判明した考慮漏れがありました 仕様通りに実装されない: 仕様として記載されているにもかかわらず、AIが異なる実装をするケース。例えば、既存の認証方式と異なるパターンで実装したり、既存のアーキテクチャパターンに従わない実装が生成されることがありました 前者は要件定義やアプリケーション設計の精度を上げていく必要があります。今回検証だったので細部まで確認できていないところがありました。そのため、実業務に導入した場合はよりこの部分に時間を使うべきだと思いました。 後者はモデルの進化を待ちつつ、コンテキストの渡し方の工夫や、実装が仕様に準拠しているかを監査するサブエージェントの整備など、ガードレールを張っていくことが必要だと感じました。 コンテキスト管理の課題 AIツール固有の課題として、コンテキスト管理の難しさがあります。実装フェーズではコードの読み書きが多く発生するため、auto-compact（コンテキストの自動圧縮）が頻発しました。その結果、audit.mdへの書き込みが不安定になったり、要件定義ファイルへの指摘を繰り返してもアウトプットに反映されないことがありました。 対策として、コンテキストの使用量を抑えるためにルールファイルを分割して必要なタイミングでのみ読み込む方式にしたり、サブエージェントを活用して処理を分散させるなどの工夫が必要です。 レビュー負荷への対応 AIのアウトプット量が増えることで、人間のレビュー負荷が増大するという課題があります。この課題に対しては、以下のアプローチを検討しています。 レビューを軽減するプロセスの構築: 自動テストやLintの活用 AIの出力品質を上げる工夫: プロンプトの改善、ルールの整備 段階的なレビュー: 各ステージでの承認による分散 これらの最適解は、チームやプロダクトによって異なるため、継続的に改善していく必要があります。 最後に AI-DLCは、AIを活用した開発における「ボトルネックを特定し、解消していく」ためのフレームワークとして有望だと感じています。 今回見えてきた課題はAI-DLCのフレームワーク自体の問題ではなく、AIと人間が協働する上で必然的に発生する問題です。今後も継続的に活用しながら、チームに最適な形にカスタマイズしていきたいと考えています。