アマゾンジャパン品川オフィス3階

森のようなアトリウム

1. はじめに
2. Text2SQLとは
3. ワークショップの内容
4. 参加者の声
5. PoCから本格導入まで

1.はじめに

営業担当から突然、「この商品の半年分の売上推移のデータください」と言われ、思いがけないタイミングでデータ集計に時間を取られてしまう--。そんな依頼を様々な部署から受け、毎日追われている、というご経験がある方もいらっしゃるのではないでしょうか？

こうした課題を解決する手段として注目されているのがText2SQLです。

今回、アクセルユニバースは アマゾン ウェブ サービス ジャパン合同会社様（以下、AWS Japan）と共催し、 Text2SQLワークショップを開催しました。本記事では、その内容と当日の様子をご紹介します。

2.Text2SQLとは

Text2SQLとは、自然言語（プレーンテキスト）の質問を、Amazon RDS や Amazon Redshift などのデータベースで実行可能なSQLクエリに自動変換する技術です。

例えば、「先月の売上トップ10の商品を教えて」と入力すると、AIがSQLを生成し、データベースから結果を取得します。

このように、AIがユーザーの指示を理解し、事前に設定された目標を達成するために、自律的に計画・実行をする仕組みは「AIエージェント」と呼ばれており、DX領域で注目されています。今回のワークショップでは、Claude（Anthropic社が提供する生成AIモデル※）、 Kiro を利用し、Text2SQLの構築とカスタマイズを体験していただきました。

Kiro は、AIを活用したアプリケーション開発を支援する開発環境であり、AIとの対話を通じて要件整理や処理設計、実装を進めることができます。これにより、従来は専門知識が必要だったデータ分析基盤の構築も、よりスピーディに試行・改善できるようになります。これにより、SQLを書けない人でもチャット形式でデータ分析が可能になります。

※ClaudeはAnthropic PBCの商標または登録商標です

3.ワークショップの内容

今回のワークショップは、参加企業の自社データを用いてText2SQLの構築とデータ分析を体験していただく内容で、2部構成で実施しました。

成果物としては、セミナーに参加された皆様に、翌日からどのようなエージェントでどのように業務を変え、それによりどんな強み / 価値が強化されるのかというストーリーがまとまる状態を目指して実施しました。

3-1.第1部：座学パート

まずはAIエージェント時代のビジネスについて理解するため 座学セッションを行いました。

3-1-1.AI BPR（ビジネスプロセス・リエンジニアリング）について

アマゾンウェブサービスジャパン合同会社

Senior Machine Learning Developer Relations

久保 隆宏様

​​

AWS Japanの久保様より、AIエージェント時代のビジネスについてご講演いただきました。今回のワークショップでは、Text2SQLの構築だけでなく、AI BPR（AI-driven Business Process ReEngineering：AIを前提とした業務プロセスの見直し）が重要なテーマです。

生成 AI の技術は仕事を任せられる方向へ進化していますが、組織の差別化要因はこれからも人間です。AI BPR が目指すのは、人間の作業を置き換えることではなく、人間の強みをデータ x AI エージェントで強化 することです。

AI BPR は以下の３つの特徴で、従来の "BPR" や生成 AI 適用が抱えている課題を解決します。

• 「問題」から始めるのではなく、業務を通じた強みや顧客へのアウトカムの特定から始めること
• 技術的に可能か否かの議論に時間を費やすのではなく、担当者がどのように強み・価値に注力するかという適応を議論すること
• ヒアリングや要件調整に時間をかけるのではなく、ステークホルダーが同じ時間・場所に集まり、生成AIを用いてリアルタイムに成果物を作成すること

今回のワークショップでは、単にText2SQLの構築を体験するだけでなく、こうしたAI BPRの考え方を実際の手順の中で体験していただきました。

3-1-2.Text2SQLのデモ

アクセルユニバース株式会社 システム部

齋藤 敬明

​​

弊社エンジニアの齋藤より、 Text2SQLについてご説明しました。自然言語で質問すると、AIがSQLを生成し、データベースから結果を取得する様子をご覧いただきました。

特にデモのときには、参加者の皆様に興味をもってみていただき、参加者の皆様は「自社データで試してみる」ことへの期待が大きくなっているようにみえました。

3-2.第2部：Text2SQLの構築ハンズオン

後半は、実際にText2SQLを構築するハンズオンを実施しました。

アマゾンジャパン品川オフィス

ハンズオン会場

​​

今回はこんな素敵な空間にある５つのお部屋で、参加企業ごとに部屋を分け、 それぞれのデータを使って構築を進めました。

3-2-1.ハンズオンの手順

1. Kiro IDEの環境構築
2. ノンカスタマイズのText2SQLをデプロイ
3. Kiro IDE を使った自社業務プロセスの分析
4. Kiro IDE が生成した文書を使って Kiro で Text2SQL のカスタマイズ
5. チャット形式でデータ分析
6. 分析結果のまとめ（最終レポート作成）

3-2-2.参加企業の例

参加者
情報システム部の方と、分析実務担当の方　

課題
営業担当から突然「例）この商品の半年分の売上推移のデータください」と依頼があり、想定外のタイミングでデータ集計作業が発生する

当日使用したデータ
市場データ（2か月分）

3-2-3.体験中の様子

最初はAIの集計結果に半信半疑の様子でしたが、手元の手動集計データと比較した結果、正確な集計であることが確認できました。

その後は積極的にAIへ質問を行い、「商品種別ごとの傾向」や「注目ポイント」などをチャットで会話しながら確認され、その回答に今後の活用への期待感を抱いていただけたようでした。参加者からは「営業担当と一緒に使えば、さらに価値が出そう」という感想もいただきました。

ハンズオンの一場面

環境構築の様子

​​

4.参加者の声

環境構築を終え、Kiroが生成した最終レポートを確認した際には、自然と拍手が起こる場面もありました。

アンケートでは以下の声をいただきました。（一部抜粋）

• AIと対話しながら業務プロセスを分解し、改善のイメージを持つことができた。
• やりとりの質が高く、言語化できていない要素を整理・言語化するのに最適だと感じた。
• ハンズオンでアプリを作れたことで理解が深まった。
• グラフなど、視覚的な分析ができる点が良いと感じた。
• AIが自動でクエリを再生成する仕組みに驚いた。

「業務プロセスの分解や言語化に役立つ」「AIとの対話を通じて活用イメージが具体化した」といった感想もあり、AI BPRの考え方が実体験を通して伝わっていたことがうかがえました。

一方で、データ準備や環境構築に関する課題も一部挙がっており、実運用に向けて検討すべきポイントも明らかになりました。 こうしたフィードバックは、今後のワークショップ内容の改善や実践支援を行う上での貴重な示唆となりました。

5.PoCから本格導入まで

アクセルユニバースでは、今回のデモ環境をベースにPoCから本格導入までの支援を行っています。

一例ですが、約3か月のPoCを通して、

• 自社データでの検証
• 活用シナリオの検討
• 定着化

を進めることが可能です。

AIの活用が重要になることは感じていても、

• どこから始めればよいのか分からない
• 何を作ればいいのか分からない

という方も多いと思います。

そうした段階でも、課題整理から一緒に検討させていただきます。ぜひお気軽にご相談ください。

AUCへのお問い合わせ　

1. はじめに
2. 生成AIプロジェクトで起きがちなこと
3. リリース前に起きる問題とよくある対応
4. 本質的に必要なアプローチ
5. おわりに

1.はじめに

「PoCではうまくいっていたのに、本番が近づくと急に問題が噴出する」

いくつかの生成AI案件を進める中で、この現象には共通する構造があることに気づきました。PoCでは「使えそう」だったものが、本番直前で「このままでは出せない」と判断されるのです。

原因はモデルの性能不足だけではありません。

多くの場合、課題は進め方にあります。生成AIは、曖昧な要件でもそれらしく動いてしまう一方で、評価基準が定まらないまま進めると、後工程で揺らぎが顕在化します。

本記事では、生成AI活用でよくある失敗パターンと、 安定した成果を出すために必要な考え方について整理してみます。

2.生成AIプロジェクトで起きがちなこと

生成AIを使ったプロジェクトの初期段階では、次のような状況がよく見られます。

• 生成AIの活用範囲を模索する段階で、要求がまだ抽象的な状態にある
• 具体的な評価基準が定まらないままPoCが進む
• 「なんとなく良い」という評価で次のフェーズに進む

この段階では、大きな問題は表面化しません。むしろ「思ったよりできる」という印象を持つことも多いでしょう。
なぜこのようなことが起きるのでしょうか。

たとえば「わかりやすく説明して」という指示に対して、明確な基準がなくても、それらしい文章を出力します。これは生成AIの強みでもあります。 評価基準がまだ固まっていない段階でも一定品質の出力が得られるため、想定以上に「使えそうだ」という感触のPoCが出来上がることがあります。

その結果、「十分に良いのではないか」という評価のもと、仕様や判断基準が明確に整理されないまま、プロジェクトが次のフェーズへ進んでいくケースも見られます。

3.リリース前に起きる問題とよくある対応

しかし、リリースや本格運用が近づくにつれて状況は変わります。

• 「ここはこうしてほしい」という具体的な要望が出てくる
• これまで許容されていた回答の揺れが問題視される
• リリースを目前にして、初めて「こんなのでは困る」という具体的な目標がわかってくる

つまり、ここで初めて評価基準が具体化するのです。PoC段階では曖昧だった「正解」が、急に具体的な形を持ち始めます。
その結果、これまで見えていなかったズレが一気に顕在化します。

◆よくある対応の落とし穴

多くのプロジェクトで見られるのが、指摘されたケースを例示として追加し、few-shotで挙動を矯正する対応です。

一見、直ったように見えます。 しかし、修正を重ねるほど次のような問題が起きやすくなります。

• 特定のケースに合わせた指示になるため、そのケースではうまく動くが、少し条件が変わると対応できなくなる
• 新しい入力パターンでは通用しない
• few-shotによる例示がどんどん増えていき、全体の一貫性が失われる（あらゆる箇所に「最重要」などの強い指示が増えていく）

結果として、安定して使える状態になりにくくなります。

4.本質的に必要なアプローチ

安定した成果を出す為には、指摘を足していくだけではいずれ限界が来ます。 重要なのは、次のようなプロセスです。

• お客様からもらった指示をそのままプロンプトに落とし込むのではなく、背景や意図を考える
• その指示が必要な理由を掘り下げる
• 期待される結果や出力の形を整理する
• 複数の要望を共通の判断基準にまとめる
• その判断基準に沿ってプロンプトを組み立てる

この整理を挟むかどうかで、プロジェクトの安定性は大きく変わります。 判断基準が曖昧なまま具体例だけを増やしても、安定した成果にはつながりません。
「やっとわかってきた具体的要求を噛み砕いて、生成AIにプロンプトという形で指示を与える。」 それは、従来の開発における上流工程で実施していた要求分析から設計、実装に落とすフェーズや、PMがメンバーに業務を指示してきたことに近いのです。

5.おわりに

生成AI案件では、目標が曖昧で、正解が一意でなく、評価基準も途中で変わることが少なくありません。だからこそ、修正のたびに要望をそのまま追加していくのではなく、一度立ち止まることが重要になります。お客様の要望をそのままプロンプトに足し続けると、全体の構造が崩れ、プロンプトが複雑化していきます。
その前に、「本当に必要なことは何か」「本当にモデルに指示するべき内容は何か」を整理することが、安定した設計につながります。

求められるのは、曖昧な要求を整理し、背景意図を読み取り、具体的な期待値を噛み砕いてプロンプトに落とす力です。

生成AIや機械学習の知識だけではなく、「要求をどう整理し、どう指示するか」が成功の鍵となります。 そのため、生成AI活用を成功させるには、単に技術に強いだけでなく、要求分析や要件定義を丁寧に行えるパートナーかどうかという視点も重要になります。

アクセルユニバースでは、こうした要求整理のプロセスを重視し、曖昧なアイデアや構想の段階から整理しながら、生成AIを組み込んだシステムをオーダーメイドで開発しています。生成AIの特性を踏まえた設計を行うことで、PoCにとどまらない実運用につながる形での活用を支援しています。

それが、生成AI活用プロジェクトの難しさであり、面白さであるのかもしれません。

AUCへのお問い合わせ　

X（旧Twitter）・Facebookで定期的に情報発信しています！
Follow @acceluniverse

目次

1. はじめに
2. Kiroについて
3. 実際に触ってみた
4. 感想
5. おまけ

1. はじめに

AIを使用してコーディングする場面を思い浮かべてください。
コード生成した結果、周辺とは違った書き方をされたり、余計な箇所を直されたり、意図しない修正をされて困った経験はありませんか？
他機能への影響が限定的な箇所や、とても簡単な機能の修正は、思い通りにいくことが多いですが、
他機能への影響が大きい改修など、機能の複雑度が高くなればなるほど上手くいかないことは顕著になりませんか？
本来はそんな(レバレッジの効きやすい)大規模な修正作業こそ、AIに任せたいものですよね。(しみじみ)

これらの問題の多くは、AIに「何を作りたいか」を正確に伝えられていないことが原因であることが多いと思います。
つまり、AIとの対話において、必要な情報を適切な形で提供できていないことが原因です。
プロンプトを調整したり、サービスとやり取りするチャットのセッションをリセットしたり、AIへの依頼方法を調整する行為をプロンプトエンジニアリングの上位概念として「コンテキストエンジニアリング」と言うらしいです。

調整したコンテキストをAIに依頼する。という熟練者達の暗黙知を
手段として提供しているAIコーディングエージェント「AWS Kiro」について、特徴や実際の操作についてまとめてみたので紹介します。

2. Kiroについて

AWS Kiroは、AIコーディングエージェントで、特にSpecモードが特徴的です。
公式ドキュメント

2.1. Spec駆動開発：AIとの対話を構造化する

従来のAIコーディングエージェントでは、「何を作りたいか」「どう作るか」はユーザの任意のタイミングで伝える必要がありました。
しかし、KiroのSpecモードは、開発プロセスを3つのフェーズに分けることで、AIとの対話を構造化してます。

• フェーズ1: 要件定義（Requirements）
  • 「何を作るか」を明確にする
  • ユーザーストーリーと受入基準を定義
  • この段階でレビュー・修正が可能
• フェーズ2: 設計（Design）
  • 「どう作るか」を設計する
  • アーキテクチャ、コンポーネント、テスト戦略を定義
  • 要件を基に自動生成され、レビュー・修正が可能
• フェーズ3: 実装計画（Tasks）
  • 「どの順番で作るか」を計画する
  • 具体的なタスクリストを生成
  • 設計を基に自動生成され、レビュー・修正が可能

この段階的なアプローチにより、各フェーズで必要な情報だけに集中することができ、AIに対して適切な情報を適切なタイミングで提供することができます。
結果として、AIが生成するコードの品質が安定し、意図しない実装を最小限にすることができます。

2.2. なぜSpec駆動開発が効果的なのか

Specモードの最大の特徴は、「AIに必要な情報を段階的に整理させる」という点です。

• 情報の整理
  • 各フェーズで必要な情報だけに焦点を当てられる
  • 前のフェーズの成果物が次のフェーズの入力になる
  • 情報の抜け漏れを防ぐ
• レビューポイントの明確化
  • 各フェーズで人間がレビュー・修正できる
  • 早い段階で方向性の誤りを修正できる
  • 実装前に要件と設計を確定できる
• 品質の安定化
  • 要件から実装までのトレーサビリティ
  • （ドキュメント次第ではありますが）プロパティベーステストを含む包括的なテスト戦略
  • 個々のエンジニアの経験に依存しにくい

つまり、Specモードは「AIとの対話の仕組み」そのものを改善することで、
（ある程度のレベルまでは）誰でも適切にAIに情報を伝えられるようになっています。

3.実際に触ってみた

今回はIDE版で進めていきます。
インストール・セットアップの手順については本記事では割愛します。
詳細は公式ドキュメントをご参照ください。

対象のプロジェクトに移動して「kiro .」でkiro.appが開きます
※kiro.appを開いて対象のプロジェクトを開くでも問題ないです。

「Spec」を選択して、早速以下のプロンプトを渡してみました

Kiroが requirements.md(要件ドキュメント) を作成してくれました
中身はこんな感じです

要件を確認して、修正したいところがあれば修正します。
今回はこのまま進めます。 Move to design phase を押下します。

要件に沿って Kiro が design.md(設計ドキュメント) を作成してくれました
アーキテクチャ、コンポーネント、データの永続化の方法論や、正常性プロパティ、テスト戦略まで、結構細かい粒度で設計をアウトプットしてくれました。

設計についてもこのまま進めます。 Move to implementation plan を押下します。

tasks.md(実装計画)が作成されました。
一部のタスクをオプション化してまずはコア機能のみの計画にするか or 最初から包括的に作成する計画にするか
聞かれたので、包括的に作ってもらいました。

Kiroにタスクの実行してもらいます。（チャットに「run all tasks」と入力） 実行中は以下のような感じで、進行状況がわかるようになってます。

最終的にできたアプリはこちらです。

• タスクの追加、削除、do/undoができる
• データの永続化ができてる（localstrageの範囲で）
• レスポンシブでシンプルなデザイン

4. 感想

「実際に触ってみた」のセクションで見てきたように、Specモードを使った開発では、
最初の簡単なプロンプトから

• 要件定義、設計、実装計画が段階的に生成
• 各フェーズで必要な情報が整理・確認することができ
• tasks.mdの実行中に何度かエラーが発生し（エラー解析＞修正を繰り返し）つつも、最終的に要件を満たすアプリを完成することができました

実際には、AIが提案する要件や、設計に対して、修正しながら進めていく事になると思います。
「要件定義、設計、実装計画」に時間をかける事で、品質や満足度の高いものを提供していければなと思いました。

AWS KiroのSpec駆動開発は、AIとの対話を構造化することで、品質を一定以上に得られる仕組みだと思います。
プロンプトの書き方ばかりに時間をかけるのではなく、最初から仕組み化されたツールを選ぶことも大切ですね。
ぜひ一度、試してみてはいかがでしょうか。

5. おまけ

AWS KiroにはCLI版の提供もあります。
以下の通り、インストール、pathの設定後に「kiro-cli」にて起動できます。 （メッセージは英語表示になってますが、日本語の質問すると日本語で返ってきました。）
エディターの縛りなく使用が可能です！！

最後に、「設計を明確にしてからAIに依頼することが大切」という観点でCursorのPlanモードについても記事を書いてます。
興味がありましたら、一緒に読んでいただけると嬉しいです。
CursorのPlanモードについての記事はこちら

最後の最後までお読みいただき、ありがとうございました。