本記事は 2026 年 4 月 7 日に公開された Deepak Singh の「 We’re bringing back the Kiro startup credits program 」を翻訳したものです。 起業家の皆さん、12 月の スタートアップクレジット にたくさんのご応募をいただきありがとうございました。昨年 Kiro スタートアップクレジットプログラムを開始した際、その反応は予想を大きく上回るものでした。数千もの応募が寄せられ、ニーズは明確でした。アーリーステージのチームには、成長に合わせてスケールする開発者ツールが必要だということです。 そこで、このプログラムを復活させます。本日より、対象となるスタートアップは最大 1 年分の Kiro Pro+ を無料で申請できます。仕様駆動開発と高度な AI エージェントを活用して、コストを気にせず開発を加速できます。 提供内容 アーリーステージから Series A までのスタートアップであれば、最大 1 年分の Kiro Pro+ クレジットを受け取れます。クレジットは AWS アカウントに自動的に適用されます。チーム規模に応じて 3 つのティアを用意しています。 Starter ティア – 最大 2 ユーザー Growth ティア – 最大 10 ユーザー Scale ティア – 最大 30 ユーザー 申請は順次審査し、結果はメールでお知らせします。ティアのユーザー上限を超えた場合や Pro+ 以上にアップグレードした場合は、追加料金が発生することがあります。 注意: すでに AWS Activate クレジットを受け取っている場合、本プログラムの対象外となります。 仕様駆動開発が重要な理由 IDE でも CLI でも、すぐにコードを書き始めるスタイルでも事前に計画・設計するスタイルでも、Kiro はツール、環境、チームを横断して AI コーディングに構造をもたらします。私たちが仕様駆動開発を推進しているのは、構造化によってコード品質が向上し、手戻りが減り、開発時間全体を短縮できると確信しているからです。多くのツールを使い分けたり、プロンプトエンジニアリングに何時間も費やす代わりに、Kiro では要件を定義するだけで、テスト済みのコードを数分でリリースできます。ドキュメント作成、テスト、レビューは AI エージェントが自動で処理するため、本当に重要なプロダクト開発に集中できます。 MVP からプロダクトマーケットフィットへ進む起業家にとって、これはすべてを変える力になります。イテレーションが速くなり、チームの足並みが揃い、複雑さが増してもスケーリングがボトルネックになりません。開発速度は短距離走ではなく、持続可能な前進になります。 「Kiro のおかげで開発チームをスケールでき、デバッグの高速化、テストカバレッジによるコード品質の向上、革新的な PoC の迅速な作成が可能になりました。テスト開始まで 24〜32 週間かかると見積もっていたプロジェクトが、わずか 5〜7 週間で完了しました。現在、Terraform コード、ユニットテスト、Playwright のオブジェクトモデルの 80% を Kiro で生成しており、プラットフォームチームは週 8〜12 時間を節約しています。さらに、MCP サーバーやエージェント全体を 80% の AI 支援で構築できるようになりました。これはイノベーションのスピードを根本から変える成果です。」 — Matthew Trevathan、SVP Architecture and Innovation、Nymbus 「CoverTree では、住宅向けの保険商品とインフラを構築しています。複雑なルール、エッジケース、そして間違えれば実際のコンプライアンスリスクにつながる領域です。何を作るのか、どう作るのかを明確にすることが日々欠かせません。Kiro は、適切な場面で立ち止まり、コードを書く前に要件をしっかり考える習慣をチームにもたらしてくれました。Kiro 導入以降、自動テストカバレッジは 60% 以上向上し、テストやドキュメント作成にかかる時間は約 60〜70% 削減されました。以前はテスト可能な状態になるまで 3〜4 週間かかっていた機能が、今では数日で準備できます。Kiro は要件定義からテスト生成、コードレビューまで、コアとなるエンジニアリングの作業全体で活用されています。日々の開発プロセスの一部となっており、プロダクトの成熟とともに Kiro チームと一緒に成長していけることを楽しみにしています。」 — Divyansh Sharma、Co-founder and CTO、CoverTree 申請方法 本プログラムはほとんどの国でグローバルに利用可能です。 今すぐ申請して 、Kiro で 1 年間の高速開発を始めましょう。 利用規約 もご確認ください。 ハッシュタグ  #KiroforStartups または #BuildwithKiro を使って、あなたが作っているものをぜひ共有してください。 X 、 LinkedIn 、 Instagram では @kirodotdev、 Bluesky では @kiro.dev でお待ちしています！ スタートアップ向けのその他のリソース AWS Activate は Amazon Web Services のスタートアップ専用プログラムで、プロモーションクレジット、テクニカルサポート、ビジネスリソースを提供し、構築とスケーリングを支援します。コンピューティングや機械学習からデータベース、セキュリティまで、AWS Activate はスタートアップの成長に必要なインフラとサポートを提供します。 お困りですか？ Kiro コミュニティの Discord に参加して、他のビルダーとつながり、ベストプラクティスを共有し、テクニカルサポートを受け、最新機能の情報を入手しましょう。コミュニティがあなたの成功をサポートします。 翻訳は App Dev Consultant の宇賀神が担当しました。

はじめに PSSLの佐々木です。 AIコーディングアシスタントの進化により、テストコードの自動生成が身近になりました。しかし、ここに大きな落とし穴があります。 AIが実装コードを見ながらテストを書くと、実装のロジックをそのままテストにコピーしてしまう ので仕様の不具合に気づくことができません。 これを「トートロジカルテスト（同義反復テスト）」と呼びます。 // 実装コード function calculateTax(price: number): number { return Math.floor(price * 0.1); } // AIが生成した"テスト"（実装を見て書いた場合） it('税額を計算する', () => { const price = 1000; const expected = Math.floor(price * 0.1); // 実装と同じロジック！ expect(calculateTax(price)).toBe(expected); }); このテストは 常に成功 します。なぜなら、実装が間違っていてもテストも同じ間違いをするからです。カバレッジは100%でも、バグは検出できません。 解決策：AIに実装コードを「見せない」 この問題を解決するため、 仕様書のみを参照してテストを生成する ワークフローを構築しました。 Claude Codeのエージェント機能を使い、 テスト生成エージェントには Read ツールを与えない という技術的制約を設けます。 # .claude/agents/test-generator.md --- name: test-generator description: 仕様書のみに基づいてテストを生成する tools: Write, Bash # Readがない = 実装コードを読めない --- これにより、AIは仕様書（ spec.md ）だけを頼りにテストを書くしかなくなります。 アーキテクチャ全体像 specs/features/{feature}/ ├── spec.md # 仕様書（Given/When/Then形式） └── plan.md # 実装計画 ↓ 並列実行 ┌─────────────────┐ ┌─────────────────┐ │ implementer │ │ test-generator │ │ (tools: 全て) │ │ (tools: Write, │ │ │ │ Bash) │ │ 実装コードを │ │ 仕様書のみ参照 │ │ 自由に読み書き │ │ src/は読めない │ └────────┬────────┘ └────────┬────────┘ │ │ ▼ ▼ src/lib/*.ts src/lib/*.test.ts src/app/**/* e2e/*.spec.ts 仕様書のフォーマット テスト生成の精度を上げるため、仕様書は Given/When/Then形式 で記述します。 ## 受け入れ条件 ### AC-01: 定額割引の適用 - Given: 価格1000円の商品がある - When: クーポンコード「SAVE100」を適用する - Then: 割引後価格は900円になる ### AC-02: パーセント割引の適用 - Given: 価格2000円の商品がある - When: クーポンコード「OFF10」（10%割引）を適用する - Then: 割引後価格は1800円になる この形式により、AIはテストケースを正確に生成できます。 核心となるルール：仕様整合ルール テストが失敗した場合、 どちらを修正するか という判断が重要です。 私たちは「 仕様整合ルール 」を採用しました： テストが失敗し、かつテストが仕様書と整合している場合、 実装を修正する （テストを修正しない） # .claude/rules/src-lib.md ## 仕様整合ルール（Spec-aligned Rule） テスト失敗時の対応: 1. テストが仕様書（spec.md）と整合しているか確認 2. 整合している → 実装を修正 3. 整合していない → テストを修正 これにより、仕様書が「信頼できる唯一の情報源（Single Source of Truth）」として機能します。 実際のワークフロー Step 1: 仕様書を作成 # specs/features/discount-calculator/spec.md ## 概要 クーポンコードを適用して割引価格を計算する機能 ## 受け入れ条件 ### AC-01: 定額割引 - Given: 価格1000円 - When: SAVE100を適用 - Then: 割引後900円 ### AC-04: 無効なクーポン - Given: 価格1000円 - When: INVALIDを適用 - Then: エラー「無効なクーポンコードです」 Step 2: 並列エージェントを実行 # 2つのエージェントを同時に起動 claude --agent implementer "specs/features/discount-calculator/plan.mdに基づいて実装" claude --agent test-generator "specs/features/discount-calculator/spec.mdに基づいてテスト生成" Step 3: テストを実行して結果を確認 npm run test:run npx playwright test Step 4: 失敗があれば仕様整合ルールに従って修正 実際のプロジェクトでは、以下のような失敗がありました： FAIL src/lib/discount.test.ts ✕ SAVE100で100円割引が適用される Expected: 100 Received: 0 テストは仕様書通り「100円割引」を期待しています。実装側のバグなので、実装を修正しました。 GitHub Actions での自動化 CI/CDパイプラインで品質を担保します： # .github/workflows/ci.yml jobs: test: steps: - name: Type check run: npx tsc --noEmit - name: Run unit tests run: npm run test:run - name: Run unit tests with coverage run: npm run test:coverage e2e: steps: - name: Run E2E tests run: npx playwright test さらに、ミューテーションテストで「テストの質」も検証します： # .github/workflows/mutation.yml - name: Run mutation tests run: npm run test:mutation # Stryker 技術スタック 用途 ツール フレームワーク Next.js 15 (App Router) 単体テスト Vitest E2Eテスト Playwright ミューテーションテスト Stryker AIエージェント Claude Code 得られた効果 1. テストが仕様の検証になる 実装を見ずに書かれたテストは、「仕様通りに動くか」を純粋に検証します。 2. バグが確実に検出される 実際に3件の実装バグがテストで検出されました： 割引額の計算ミス クーポン情報の返却漏れ 0円時の割引処理 3. リファクタリングが安全になる テストが仕様に基づいているため、内部実装を変更しても「振る舞いが変わっていないこと」を確認できます。 注意点とトレードオフ 仕様書のメンテナンスコスト 仕様書が古くなると、テストと実装が乖離します。仕様変更時は必ず spec.md を更新する運用が必要です。 E2Eテストのセレクター問題 仕様書だけではDOM構造がわからないため、E2Eテストでは data-testid の命名規則を事前に決めておく必要があります。 # 仕様書に記載 ## UI要素のTestID - 価格入力: `data-testid="price-input"` - 計算ボタン: `data-testid="calculate-button"` - 結果表示: `data-testid="discounted-price"` 初期設定の手間 エージェント設定、ルール定義など初期構築には時間がかかります。ただし、一度作れば再利用可能なテンプレートになります。 まとめ AIによるテスト生成の最大の罠は、「実装を見てテストを書く」ことです。 これを防ぐため： テスト生成エージェントから Read ツールを剥奪 仕様書（Given/When/Then）を信頼できる情報源に 仕様整合ルールでテスト失敗時の判断を明確化 このワークフローにより、AIが生成するテストは「実装の複製」ではなく「仕様の検証」になります。 テンプレートはGitHubで公開しています。ぜひ活用してください。 https://github.com/atomic-kanta-sasaki/-claude-test-driven-template ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIがテストを書くと「実装をコピーしたテスト」になる問題を解決するテンプレート公開！ first appeared on SIOS Tech Lab .

こんにちは、SCSKの松岡です🕸️ Webクローリングおよび名寄せの検証において、AWS lambdaと Amazon Bedrock を活用したデータ収集アーキテクチャを検討した際の試行錯誤を整理しました。 従来のルールベースのクローリングと比較し、生成AIを用いた柔軟な情報抽出を取り入れることで、サイト構造の差異に耐えるデータ収集方式をどのように実現したか、また収集データと既存マスタを突合する名寄せの課題についても紹介します。   背景 データ活用基盤において、外部サイトからの商品情報を収集し、分析や業務活用に利用したいというニーズがありました。特に、複数サイトに分散した商品情報を横断的に収集し、一覧化・比較可能な形で整理することが求められています。 一方で、Webクローリングはサイトごとに構造が異なり、HTMLの変更や表記ゆれの影響を受けやすく、安定したデータ取得が難しいという課題があります。従来のルールベースの実装では、サイトごとに個別対応が必要となり、対象サイトの増加に伴って運用負荷が増大し、継続的な運用が困難になります。 また、収集処理の実行環境についても、特定端末に依存した構成では運用が属人化しやすく、安定したデータ収集基盤としては適さない状況でした。そのため、クラウド上で完結し、既存のワークフロー（例： AWS Step Functions ）に組み込める形で実装することが求められました。 さらに、収集した商品情報をそのまま利用するだけでなく、既存のマスタデータと突合し、サイトごとに同一商品の整理（名寄せ）を行う必要がありました。しかし、商品名や型番の表記ゆれ、情報粒度の違いなどにより、単純な一致条件では対応できず、曖昧一致を前提とした設計が必要となります。 このような前提のもと、Webクローリングと生成AIを組み合わせたデータ収集方式および、名寄せの実現方法について検証を行いました。   構成と選定理由 背景の内容を踏まえ、このような構成でAWS環境でのWebクローリングを実現しました。 サイトごとに構造が異なるWebページから商品情報を収集するため、仮想ブラウザによるクローリング方式を採用しました。これにより、単純なHTTP取得では対応できない動的コンテンツやJavaScriptレンダリングにも対応可能としています。実行環境には、コンテナイメージを利用可能な AWS Lambda を採用し、特定端末に依存しないクラウド上での実行基盤を構築しました。 次に、サイトごとのHTML構造の差異に対応するため、ルールベースではなく、 Amazon Bedrock を用いた生成AIによる情報抽出を採用しました。これにより、ページ構造や表現の違いを吸収しながら、商品名や型番といった必要な情報を柔軟に取得できる構成としています。 また、収集処理をクラウド環境にて実行する運用を見据え、AWS CodeBuildを用いてDockerイメージをビルドし、Amazon ECRへ登録（プッシュ）してLambdaへデプロイを行う構成としました。これにより、環境差異のない再現性の高い運用を実現しています。 コンテナイメージを使用して Lambda 関数をデプロイする さらに、収集したデータはCSV形式で Amazon S3 に出力し、後続の名寄せ処理やデータ活用基盤での利用を前提とした中間データとして蓄積します。本検証では名寄せ処理そのものは後段としつつ、曖昧一致を前提としたデータ構造で保持することを重視しました。 このように、「構造差異への対応」「運用の非属人化」という課題に対して、それぞれ適したサービスを組み合わせることで、柔軟かつ実運用を見据えたWebクローリングの基盤を構成しました。 ※なお、Webクローリングの実施にあたっては、対象サイトの利用規約や過度なアクセスによる負荷の回避、取得データの利用範囲（著作権・利用条件）の確認など、法的および倫理的な観点に十分配慮する必要があります。   気にしたポイント 実際に実装したWebクローリングの、処理順序ごとに気にしたポイントを整理します。 ①収集対象サイトの指定(パラメータ化) Lambda実行時に、対象URLをパラメータとして受け取る構成としました。これにより、単一の関数を使い回し、ジョブネットやワークフローから複数サイトの収集処理を横展開できるようにしています。 固定URLをコードに埋め込むのではなく、実行時に切り替えることで、対象サイト追加時の改修を不要とし、運用の柔軟性を高めています。   { "url": "https://example.com" , "prompt": "商品名と価格を抽出してください。\n列は name, price。\nCSV形式で出力してください。" } また、urlと同様に、後述する生成AIでの解析処理時のpromptについてもパラメータ化しています。これにより、プロンプトの調整のみで対応可能なケースであれば、改修不要で対応可能な設計としています。 ②WebサイトからHTMLの取得 HTML取得にはPlaywrightを採用しました。 Playwright Playwrightは、Microsoftが開発したオープンソースのブラウザ自動操作ライブラリです。Chromium・Firefox・WebKitといった複数ブラウザをプログラムから制御できます。 単純なHTTPリクエストではなく、実際のブラウザを起動してページを描画するため、JavaScriptによる動的コンテンツにも対応可能です。 ブラウザ設定は、動作確認をしながら、以下のような設定に調整しています。 # playwright ブラウザ設定 browser = p.chromium.launch( headless=False, args=[ "--no-sandbox", "--disable-setuid-sandbox", "--disable-dev-shm-usage", "--disable-gpu", "--single-process", "--ignore-certificate-errors" ], env={"DISPLAY": os.environ["DISPLAY"]} ) context = browser.new_context( ignore_https_errors=True, locale="ja-JP", timezone_id="Asia/Tokyo", user_agent=( "Mozilla/5.0 (Windows NT 10.0; Win64; x64) " "AppleWebKit/537.36 (KHTML, like Gecko) " "Chrome/124.0.0.0 Safari/537.36" ), viewport={"width": 1920, "height": 1080} ) context.set_default_navigation_timeout(90_000) context.set_default_timeout(30_000) page = context.new_page() page.set_extra_http_headers({"Accept-Language": "ja,en-US;q=0.9,en;q=0.8"}) LambdaはGUIを持たないため、ブラウザ描画のためにXvfbによる仮想ディスプレイを用意しています。本実装では、ヘッドレスブラウザではなく、仮想ディスプレイ上でブラウザを起動（疑似ヘッドフル）する構成としています。これにより、サイト側の描画差異や要素の非表示問題を回避し、安定したHTML取得を実現しています。 動作を安定させるために、不要なリソース消費をおさえるための無効設定を入れています。 サイト側に、人間が操作している通常のブラウザだと思わせるためのコンテキスト設定をしています。 レスポンシブサイトでは解像度によりメニューや要素が折りたたまれるため、画面解像度を1920×1080に固定しています。 Accept-Languageの指定で日本語表示を優先し、取得データの言語揺れを防止しています。 タイムアウト設定を明示的に指定し、操作のハング防止や、海外サイトアクセス時のネットワーク遅延を許容しています。 ③取得したHTMLの解析 取得したHTMLは、従来のようなルールベースで解析するのではなく、 Amazon Bedrock を用いて解析させています。 本実装では、モデルにAnthropic Claude 3.5 Sonnetを採用しました（2025年検証当時の最新バージョン）。検証の結果、HTMLが適切に取得できている前提であれば、生成AIの知能由来による商品情報の抽出漏れはほとんど発生せず、実用レベルの精度で抽出可能であることを確認しました。※実際の精度は、対象サイトの構造や収集対象に依存するかと思います。 Amazon Bedrock ユーザーガイド Anthropic Claude Messages API 解析の設定にあたり、以下の点を考慮しています。 temperature=0.0とすることで、出力の揺らぎを抑え、同一入力に対して安定した結果を得られるようにしています。 HTML本文はそのまま投入するとトークン上限に達する可能性があるため、文字数を制限しています。これにより、不要なコスト増加や処理遅延を防止しています。 Bedrockの推論プロファイルを利用することで、モデル呼び出し時のリソース管理を柔軟に制御できる構成としています。 推論プロファイルを使用してモデル呼び出しリソースを設定する プロンプトは「ユーザープロンプト」と「システムプロンプト」に分けて設計しています。 ユーザープロンプトは、Lambdaのパラメータとして外部から指定可能とし、対象サイトや抽出内容に応じて柔軟に変更できる構成としています。一方で、システムプロンプトでは出力形式を厳密に制御し、後続処理で扱いやすいデータ形式を担保しています。 # システムプロンプト sys = SystemMessage( content=( "あなたはWebページ本文から情報を抽出するツールです。" "出力は必ずCSVのみ（ヘッダなし、カンマ区切り、LF改行）。" "説明文や前置きは禁止。価格が無い場合は「記載なし」と明記してください。" ) ) このように制約を明示することで、生成AIの自由度を抑えつつ、構造化データとして利用可能な形式で出力させています。   改善ポイント ブラウザ操作が必要なサイトへの対応 本実装では、Playwrightによるブラウザ操作と生成AIによる情報抽出を組み合わせることで、一定の汎用性を持ったWebクローリングを実現しています。 しかし一部のサイトでは、単純なページ遷移やテキストベースのクリックでは対応できず、明示的なブラウザ操作が前提となるケースが存在します。 具体的には以下のようなケースです。 初回アクセス時にポップアップ広告や同意画面が表示され、操作しないとページが閲覧できない JavaScriptによる動的表示の後、ボタン操作によるメニュー切り替えが必要 タブ切り替えやアコーディオン展開など、ユーザー操作を前提としたUI構造 これらのケースでは、仮想ブラウザ起動後にサイト特性に応じた操作が必要となります。Playwrightを用いて個別に実装することは可能ですが、サイトごとに処理を作り込む必要があり、これまでの「汎用的なクローリング」という思想とトレードオフになります。 この課題に対するアプローチとして、 browser-use のようなライブラリを利用することで、ブラウザ操作自体を自然言語で制御する仕組みの導入が考えられます。 browser-use browser-useは、生成AIがブラウザを直接操作するためのオープンソースライブラリです。自然言語による指示を解釈して、クリックなどのアクションを自律的に実行してくれます。 これを導入することで、ポップアップの回避や複雑なメニュー遷移といった動的なUI操作をAIがその場で判断して完結できるようになり、サイトごとに個別コードを追加する手間を解消してくれる可能性があります。 収集した商品情報とマスタ情報の名寄せ 本記事でここまで触れていませんでしたが、収集した商品情報は、既存のマスタデータと紐付ける名寄せ処理を行うことで、実際の業務活用につなげることを想定しています。 しかし、複数のWebサイトから収集した商品情報は、サイトごとに表記ゆれ（例：「iPhone 15」と「アイフォン15」）や型番の記述粒度が異なるため、単純なID一致では突合できないケースが多く存在します。 この、曖昧な条件での名寄せを実現するためには、様々なアプローチが考えられます。 Pythonによるカスタムロジックの実装：Levenshtein距離などを用いた文字列類似度の算出 Pythonによるカスタムロジックの実装：ベクトル化による文脈ベースの類似度検索（Embedding） AWSマネージドサービスの活用：AWS Entity Resolutionを利用したルールベース／MLベースのマッチング AWS Entity Resolution は、AWS上のデータに対して、ルールベースおよび機械学習ベースのマッチングをスケーラブルに提供するサービスです。 AWS Entity Resolution 本検証では、業務ロジックに応じた柔軟なカスタマイズ性を重視し、Pythonベースでの名寄せロジックの検証を実施しています。 一方で、Entity Resolutionについても2025年初旬に検証を行っていました。当時は機能面で発展途上と判断し採用を見送りましたが、現在は高度なルールベースのファジーマッチング機能が強化されており、改めて適用可能性を検討したい領域です。 AWS Entity Resolution の高度なルールベースファジーマッチングを使用して不完全なデータを解決する   まとめ 本記事では、Webクローリングと生成AIを組み合わせたデータ収集基盤について、設計から実装、改善検討までの試行錯誤を整理しました。従来の構造依存のクローリングから、生成AIによる柔軟な情報抽出へ転換することで、サイト構造差異に対する耐性を向上させることができました。一方で、ブラウザ操作の高度化や名寄せの精度向上といった課題も残っており、今後はAIによる操作制御やマネージドサービスの活用も含め、さらなる実用化に向けた検証を進めていきたいと考えています！   (宣伝) クラウドデータ活用サービス 今回ご紹介した内容は、SCSKで提供しているクラウドデータ活用サービスの中で扱っているテーマの一部になります。 お客様のデータ活用状況に応じて、基盤構築から可視化、データ連携、データマネジメント、高度データ活用までを段階的にご支援しています！ ご関心あれば、以下のサービスページもご参照ください。 クラウドデータ活用サービス｜サービス｜企業のDX戦略を加速するハイブリッドクラウドソリューション クラウドデータ活用サービスは、お客様のデータ活用状況に合わせ、適切なご支援が可能です。 www.scsk.jp