こんにちは、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

はじめに Jenkins Pipelineは、ビルド・テスト・デプロイといった一連の作業を Jenkinsfileとしてコード化（Pipeline as Code） する仕組みです。 作業手順を人の手からコードへ移すことで、次のようなメリットが得られます。 再現性：誰が実行しても同じ結果になる レビュー可能：Jenkinsfileをコードレビューできる 変更履歴が残る：いつ・誰が・何を変えたか追跡できる 運用の自動化：手作業のミスや抜け漏れを減らせる しかし、Jenkinsfileは単なるスクリプトではありません。 設計思想をコードとして表現するための言語 といえます。

本記事は 新人ブログマラソン2025 の記事です。 こんにちは。新人のtknです。 温かい日差しと春の風を感じることが多くなり、大量の花粉が舞い踊る…そんな日々ですが、皆さまいかがお過ごしでしょうか。 赤々とした杉を見るとついつい睨みそうになりますが、杉は二酸化炭素の吸収効率が良く、地球温暖化防止に役立つそうなので、それなら、しょうがないですかね……。 さて本日は、私が学生時代に ChatGPTとちまちま作ったコードをKiro先生に添削させるとどれくらいの時間・コストがかかるのか？ を調査していきたいと思います。 はじめに 2年前、学生の間でもChatGPTがすっかり身近になった頃、私の研究室では研究のお供にChatGPTを使うことが多くなりました。 用途としては、研究テーマや実験の案出し、参考文献の翻訳・要約、システムの実装サポート、実験データの分析サポート、論文の添削、自身の論文の英語化などに使用していました。 その中でも私は「 システムの実装サポート 」にChatGPTを最も活用していました。実際に使用していた方法は以下の通りです。 システムの概要（目的や機能、使用言語など）と実装したい機能を指示して、コード案を出してもらう エラー文と状況を送って、エラーの原因と改善案を教えてもらう 実装中のコードを添付して、そのコードの説明をしたうえで改善案を出してもらう お察しいただけたでしょうか。 ChatGPTはIDEに統合されているサービスではない ため、私はChatGPTを実装サポートに使用する際、 プロンプトに 一定の情報を記載 したうえで指示を与える＋必要に応じて コードを添付 する ChatGPTが結果を出力する 出力結果を見て必要なものを コピーしてIDE上のコードファイルにペースト する というように 無駄な往復作業を繰り返していました 。 結果として、システム全体の構築には3か月くらいかかっていた気がします。 また、その他には以下のような問題が発生していました。 GPTはシステムの全体像や入力した内容以外のコードを把握していない ため、目的に沿わないコード案を出すことがある GPTがシステムの内容を忘れる ことがあり、時々一から説明する必要がある そこで、現在の私は「IDE統合型のKiroのSpecモードで学生時代のコードを読み込んだら、 あの頃の無駄な手間がどれくらいスマートになるのか？ 」という疑問を持ちました。 そのため今回は、実際にKiroにコードを読み込ませ、その理解から修正まで行った結果について、 かかった時間とコストの観点 を含めてお届けしたいと思います。   Kiro Specモードの実行 実際にKiroを使用してシステムの改修を行う前に、Kiroについて簡単にご説明したいと思います。 Kiroとは KiroとはAWSが開発したエージェント型統合開発環境（Agentic IDE）であり、プロトタイプから本番品質のアプリケーションまで構築することができます。KiroはVS CodeをベースとしたIDEであり、既存のVS CodeユーザはVS Code上の設定をKiroに簡単に連携することが可能です。 Kiroの画面（右のチャット部ではVibe/Specモードを指定してAIエージェントとの対話を始められる） また、KiroはVibe Coding（自然言語のプロンプトからAIがコードを生成・修正する開発手法）にも優れていますが、その強みとしてSpecモードとAgent Hooksが挙げられます。 Specモード：仕様駆動開発 （事前に定義した仕様書に基づいて設計・実装・テストなどを進める開発手法）を実現する機能 プロンプトを入力すると要件定義書の作成を開始し、ユーザの確認と許可に応じて要件定義フェーズ→設計フェーズ→実装フェーズと遷移して実装を進めていく Agent Hooks：特定のイベントに基づいてアクションを自動で行わせることができるツール コードの変更時にREADMEファイルを自動で更新するなどのアクションを設定でき、コードの一貫性や品質を保持するのに役立ちます このように、Kiroは従来の人手による開発を支援する機能がたくさん詰まっている画期的なIDEなのです。 Kiro のご紹介 – プロトタイプからプロダクションまで、あなたと共に働く新しい Agentic IDE | Amazon Web Services コンセプトからプロダクションまで、AI エージェントとの作業を簡素化した開発者体験を通じて開発を支援する AI IDE（統合開発環境）、Kiro の発表を嬉しく思います。Kiro は Vibe Coding "も" 得意ですが、それをはるか... aws.amazon.com Kiro の AI エージェントフックで開発ワークフローを自動化する | Amazon Web Services ソフトウェアプロジェクトが成長するにつれ、ドキュメントやテスト、コードの可読性とパフォーマンスを同期させ続けるのは難しくなります。Kiro のエージェントフックは、こうした重要な作業をバックグラウンドで自動化し、テスト更新やドキュメント同期... aws.amazon.com ①KiroのSpecモードでコードを理解させる それでは、早速Kiroに過去のコードを読み込ませたいと思います。コードの特徴は以下の通りです。 構成：フロントエンド（React）+ バックエンド（Node.js/Express）+ MySQLをDockerで動かす 総ファイル数：69ファイル、総行数：約5,600行 私が最初に行った指示は以下の通りです。 これからこのアプリを改修したい。まずはアプリの内容や構成・機能を理解して、その結果を設計書として出力して このとても雑な指示を受け、Kiroはなんと 2分6秒 で私の過去のコードを全て解読しました！そのコストは 0.39クレジット です！ Kiroは毎月50クレジットが無料で付与され、初回利用では期間限定で500クレジット付与されるため、0.39クレジットはほぼ無いに等しいと言えます。また、有料版でも1クレジットあたり0.04ドルで追加購入できるため、0.04×0.39×156円/ドル≒ 2.4円 となり、これぞ実質無料ですね！ また、Kiroは分析と同時に、アプリについて記載した573行のmdファイルを出力しました。 そこにはアプリの機能やデータの流れ、コンポーネント構成などについて詳細に記載されており、たった2分でアプリの強力な理解者を1人得ることができました。ファイルには以下のように図を用いた説明もあり、 自身の理解だけでなく、他者に見せた際にも理解しやすいドキュメント となっているのが良い点です。 ②KiroのSpecモードでコードの修正案を出力させる さて、3か月かけて作成したコードを2分で理解されたところで、Kiroに次の指示を出しました。 次はこのアプリの改善点や問題点を挙げたレポートを作成して 過去に一生懸命作った自分には悪いですが自ら斬られにいったところ、Kiroは 2分9秒で33項目もの指摘ポイントを挙げました 。 学会の質疑だったらと思うとぞっとする量です。 先ほどと同様にKiroが出力したレポートを見ると、エラーハンドリング不足やバックエンドでの認証検証不足などが指摘されていました。 当時は内部での実験用アプリとして作成したため、優しいユーザたちにより重大な問題は起きていませんでしたが、本番利用するとなるとこれだけの改修が必要なことが2分で分かりました。 また、Kiroは問題を挙げるだけでなく、その優先度や改修にかかる時間、改修のロードマップ例も示してくれるため、ただこちらを絶望させるだけでなく 今後どうするべきか？を前向きに考えるポイントをくれる ことも良い点です。 ③KiroのSpecモードでコードの重要修正タスクを実行させる Kiroは33項目の指摘を挙げてくれましたが、ロードマップを見ると最長で6か月とあり、今対処するには負担が大きいように感じます。 そこで、まずは 最重要の改修だけを行う ことにしました。 今回は緊急対処が必要な項目だけ対応したい。そのための計画を立てて その結果、Kiroは3分15秒で EMERGENCY_FIX_PLAN を作成してくれました。 しかし、1つあたりの課題の工数やかかる日数が極端に多いように感じたため、そこについて修正を依頼し、最終的には全体で5～7.5時間で終わる見積もりとなりました。 コードに基づいた緊急対応課題の洗い出しは正確でしたが、各課題対応の 細かいタスクについて自動で洗い出しまで行っていないため、表記からの憶測で時間を多めに見積もってしまった ようでした。 適切な修正プランができたところで、KiroのSpecモードを使用して実際に修正を行う準備を整えることにしました。 ブログ前半で示したように、KiroのSpecモードではユーザの指示から 要件定義書の作成→設計書の作成→実装タスク定義書の作成 を行います。今回は「要件定義書・デザイン～を作成してください」と指示していますが、Specモードを選択して「○○という改修を行いたい」などのプロンプトを入力するだけでも、自動で要件定義書の作成から開始してくれます！ さて、要件定義書の作成を指示すると、Kiroがこちらに「 今回の改修は、新しい機能の追加または既存のバグの修正のどちらか？ 」と質問をしてきました。ここもKiroを利用する際のありがたいポイントです！ Kiroは、こちらからの 指示の中で不足している情報がある場合や、実行の選択肢が複数ある場合などに追加の情報を求めてくれます 。 そのため、全く意図と異なる仕様で計画書を完成させて、クレジットを無駄にしたという場合を減らすことができます。クレジットを最適に使用するには、ある程度のプロンプトの工夫が必要になってきますが、凝っていないプロンプトでもエージェント側が最適になるように判断して動いてくれるのは、AI初心者にもありがたい仕様ですね。 また、Specモードでは次のフェーズに移行する際には、 必ずユーザの許可が必要 になります。 次のフェーズに進んでから前のフェーズのドキュメントを修正した場合も、自動で以降のドキュメントに修正を反映してくれるため、こちらの意図が反映された一貫性のあるドキュメントを手軽に作成できるのも良いポイントです。 さて、各フェーズで少しの修正を加えた結果、24分12秒で3つのドキュメントが完成しました。 最終的に作成されたtasks.mdは以下のようになっており、Startボタンを押すだけでエージェントがタスク定義に基づいて実装を開始してくれます。 早速、1つ目のタスク1.1から順に実行していきます。 すると、上記のTask.mdにおいて定義したように、バグの存在をテストコードで確認し、バグの根本的な原因を確認してくれました。 また、タスクが定義通りに終了したかをKiroが確認したうえで判定をしてくれるため、少しの安心感がある一方で、Kiroへの指示書（ドキュメント）の精度が問われる場面とも言えるかと思います。 上記のように全てのタスクを順に実行していった結果、Kiroが行った修正以外に何もすることなく、以下のようにローカル環境でシステムを立ち上げて一通りの機能を動かすことができました！ 今回は大幅な修正が無かったことからKiroの修正のみで起動できましたが、新規機能追加などではエラー対応が必要な場合があります さて、全ての修正が完了したということで、最終的にかかった時間とコストは以下の通りになりました。 時間：ドキュメント作成 1,776s ＋ タスク実行 14,555s ≒ 4時間30分   （※Kiroの動作時間） プロンプトの作成やドキュメントの確認時間などを含めると、 合計7時間 くらいかと思われます コスト：142.72 Credits ≒ $2.85（453円） Kiroは無料プランで50Credits/月、PROプラン（$20/月）で1000Credits/月利用可能（参考： Kiro | Pricing ） 今回は$0.02/Creditsとして換算していますが、 実際に利用する場合にはPROプランに入る必要があります 2年前のChatGPTとKiroを用いたコード開発の比較 各AIツールでの作業結果をまとめた表は以下の通りです。   Web版 ChatGPT (2年前) Kiro サービス形式 Web上でのAIチャット IDE統合型AIエージェント 利用用途 システム開発 システム改修 使用コスト $66（10,494円） ※$22/月プランを3か月利用 $20（3,180円） ※$20/月プランを1か月利用 使用時間 30時間 ※動作時間30分/日で3か月間平日のみ利用 5時間 プロンプトの構成 参照してほしい情報は全て含めたうえで、 指示文を入力する 参照してほしい情報は確認を依頼したうえで、指示文を入力する 前提として、両者には2年もの歳月差があり、AIツールとしての位置づけや利用用途も異なるため、対照に比較することは難しい点をご了承ください。 それでもKiroでは、 IDE統合型というユーザ環境を理解しやすい特性と、AIエージェントによるタスク実行などの利点 により、時間やコストを大幅に抑えられたことがお分かりいただけるのではないでしょうか。 何より、 事前に把握してほしい情報を「確認して」の一言で理解してきてくれること が、私には非常に便利に感じられました。前提の共有に時間を取られず、開発そのものに集中できるのはエンジニアのたまごとして非常にありがたい限りです。 もっとも、Kiroを実際の開発業務に使用するにはまだまだ工夫が必要となります。その具体的なノウハウについては、今後の試行錯誤を通じて改めて共有できればと思います。   おわりに いかがでしたでしょうか。厳密な比較ができないものを並べて語ってしまいましたので、理系畑の方の視線が怖くはありますが、KiroのSpecモードの便利さが少しでも伝わっていましたら幸いです。 私はKiroを利用し始めて早4か月、すっかりKiro先生に懐いています。Kiro先生のおかげで初めて知ったことも多くありますので、新人には嬉しい強力なパートナーです。 初めて利用する方は、期間限定でボーナス500Creditsがもらえます ので、少しでも興味がある方は始めてみることをおすすめいたします！私の場合ですが、開発で頻繫に利用していても500Creditsの利用には半月ほどかかるため、十分な機能検証ができるのではないかと思います。 今回も最後までお付き合いいただきありがとうございました。 企業の技術ブログらしくかっこよく技術情報をお届けしたいのですが、毎度やかましい文章になってしまうのはなぜなんでしょうか。。次回頑張りたいと思います。 暦の上では春分を迎え、春らしい日差しが増える季節となってまいりました。まだまだ寒い日もありますので、皆さまお身体ご自愛ください。