2026年5月アーカイブ

1. はじめに
2. 環境構築手順
3. Store Manager Agentで実現できること
4. まとめ

1.はじめに

店舗運営において、こんなお悩みはありませんか。

• 売上データは見ているが、次に何をすべきか判断に迷う
• 売場づくりや品揃えが、どうしてもベテラン頼みになってしまう
• 在庫・売上・時間帯など、考えるべき要素が多すぎる
• 数字の振り返りはしているものの、改善アクションに落とし込めない

こうした課題は、特定の業種だけのものではありません。
例えば、

• スーパーマーケットでは、時間帯等を踏まえた発注や値引き判断
• コンビニでは、限られた売場での品揃えや補充タイミングの最適化
• アパレル店舗では、売場づくりやセールタイミングの判断
• ドラッグストアでは、多数の商品カテゴリを踏まえた陳列や販促設計
• 家電量販店では、在庫・販売戦略と接客のバランスをみた在庫管理

といったように、店舗運営では日々さまざまな意思決定が求められています。

一つひとつの判断はシンプルに見えても、実際には売上・在庫・時間帯・顧客動向など、多数の要素が複雑に絡み合っています。 その結果、多くの現場では経験豊富な店長やベテランスタッフの判断に依存しているケースも少なくありません。 また、多くの企業ではPOSデータや売上データは蓄積されているものの、「次に何をすべきか」という具体的な改善行動まで落とし込めていないケースも多くあります。

こうした背景の中で注目されているのが、AIエージェントが店舗運営の意思決定を支援する、 店舗運営支援エージェント によるアプローチです。
Store Manager Agent for Retail Tech（SMART） は、売上データや現場の声を店舗運営支援エージェントが分析し、「今どのような改善行動を取るべきか」を支援するサンプルアプリケーションです。なお、このアプリケーションはAWSよりOSSとしてGitHub上で公開されているため、誰でもソースコードを確認したり、自身の環境で試したりすることができます。

本記事では、実際にStore Manager Agent for Retail Techを構築・検証してみた結果をご紹介します。

2．環境構築手順

Store Manager Agent for Retail Techの構成は下記の通りです。

主要コンポーネント

アプリケーション構成

• S3: フロントエンドアセットの配信
• CloudFront: グローバルCDN配信
• WAF: アクセス制御
• API Gateway: REST APIエンドポイント
• Lambda: API処理とビジネスロジック実行
• AgentCore Runtime: Strands Agentsの実行環境
• AgentCore Memory: エージェントの会話履歴管理

データベース構成

• S3 Tables: Iceberg形式のテーブルストレージ
• Amazon Athena: SQLベースのデータクエリエンジン

構築手順の概要

AWS公式の DEPLOYMENT.md に従ってデプロイを進めていきます。本ブログでは今回実行した手順と、注意点を記載します。

１．環境のセットアップ

認証情報の設定を行います。当社はAWS IAM Identity Centerからのログインを行っているため、今回はaws configure ssoにて認証情報を設定しました。
デプロイ先の AWS アカウントとリージョンを決定します。今回は環境変数でリージョン指定を行いました。
ローカル環境において、Lambdaで作成したAPIの修正や追加などの開発を行う場合はDockerをセットアップしましょう。今回はDockerを使用しませんでしたが、アプリケーションは問題なく動作してくれました。

２．AWS 環境の準備

自分が環境を構築するリージョンで、 Amazon Bedrockの利用ができるかを確認しましょう。
AWSマネジメントコンソールを開き、リージョンを設定してAmazon Bedrockを開きます。左メニューのテストからPlaygroundを選択して、カテゴリはAnthropic、モデルはClaude Haiku4.5、推論は推論プロファイルのJP Anthropic Claude Haiku4.5を選択して適用します。
呼び出しが成功すれば、対象リージョンでClaude Haiku4.5が利用できることがわかります。
次に、Amazon API Gateway のタイムアウトに関するクォータ（Quota）緩和申請を行います。 設定はAWSマネジメントコンソールのTimeout Quota （Maximum integration timeout in milliseconds） から行うことができます。デプロイ対象のリージョンであることを確認し、申請しましょう。
次に、Amazon S3 Tables と分析サービスの統合設定を行います。S3 tables コンソール画面から、簡単に設定することができました。

３．プロジェクトの取得

今回はgit cloneを行いました。

４．AWS CDK 環境の準備

npm モジュールのインストールを行います。 初回デプロイ時のみ、AWS CDK の Bootstrap 実行を行います。 次に、 AWS Lake Formation で２つのプリンシパルを追加します。CLIでもコンソールでも設定できますが、今回はCLIで実行しました。

５．CDK 設定のカスタマイズ

アプリケーション画面でのユーザー作成可否、サインアップ可能なメールアドレスのドメイン制限、IP 制限などのパラメータを調整することができます。
今回はデフォルトのままで設定しました。

６．CDK デプロイ

cdk deploy を実行します。私の場合は10分程度で終了しました。

７．初期データのセットアップ

Amazon S3 Tables のテーブルを作成し、テストデータを投入します。

↓実際にS3に投入されるテーブル一覧。例えば下から２つ目の「t_sales」には、売上情報が登録されています。

↓「t_sales」のデータ

８．デプロイ結果の確認

AWS CloudFormation のスタックの出力から、アプリケーションの URL を取得しましょう。

９．ユーザー作成

AgentとAdminでそれぞれ初回ログイン用のユーザーを作成しましょう。Adminユーザーは、Agentユーザーに提供されるサービスに加えて、アンケート質問の編集、メッセージ管理等の機能を使用することができます。

１０．Amazon Bedrock モデル呼び出し権限の追加

2025年10月に実施された「モデルアクセスの自動有効化」に関する仕様変更に伴い、「Daily Insights」機能で追加の権限が必要となる場合があります。
その場合、sample-store-manager-agent-for-retail-tech/cdk/lib/constructs/agentcore-resources.ts に以下の AWS Marketplace 関連の権限を付与することで解消する可能性があります。

• aws-marketplace:ViewSubscriptions
• aws-marketplace:Subscribe

3. Store Manager Agentで実現できること

早速Agentユーザーでログインしてみます。ログインすると、以下のような画面になりました。

機能は大きく分けて

1. Daily Survey（日次アンケート、AIチャット）
2. Daily Insights（インサイト生成）
3. History（Daily SurveyとDaily Insightsの履歴）

の３つがあり、それぞれの機能はDashboardまたは左メニューから開くことができます。

(1)Daily Survey（日次アンケート、AIチャット）

Daily Surveyは、日次アンケートとAIチャットが連動した機能です。
スタッフがその日の固定アンケートに回答すると、AIエージェントがその回答内容をトリガーにして、自然な対話形式でさらに深いヒアリングを開始します。
最初に表示されるアンケートにすべて回答すると、AIチャットに移動することができます。

AIチャット画面では、AIエージェントがアンケートに関連した追加質問を行います。
その質問に答えると、AIエージェントがさらに深堀り質問をしてくれるので、それに答えていく形式で会話を進めます。
例えば今回は、「パンツがよく売れたが、それはなぜか？」という観点で質問をされました。その後、「新商品のデニムのデザインが人気だったから」と回答すると、「どんなお客様に人気だったか？」というように深堀り質問がありました。

このように、AIエージェントの質問に答えるだけで一日の営業の振り返りを行うことができ、手書きやExcelでの日報作成にかかっていた時間を店舗運営や接客に充てることができます。
また、現場のスタッフから日々の「生の声」を収集・蓄積することで、今後の仕入れや販売戦略の立案、商品の強みの再発見につなげることができます。

(2)Daily Insights（インサイト生成）

Daily Insightsでは、Daily SurveyによるアンケートやAIチャットから得られた定性データと、売上や来客数などの定量データが掛け合わせて分析され、AIエージェントが改善提案付きレポートを生成します。
例えば今回のフィードバックでは、まず昨日の売上や来客数、購入件数、購入率を振り返ったあとに分析に入ります。

1. 売上達成／阻害要因の分析

• 定量データより、来客数の増加に対して購入件数は変化しておらず、来客一人あたりの購入率は低下
• 定性データより、サービス満足度は高く、スタッフの営業評価も高い

よって、サービス品質は良好だが、商品ラインナップや価格設定、販売促進の工夫が不足していた可能性が考えられる。

2. AIの気づき

• 商品の品揃え、価格、販売提案に課題がある可能性がある
• サービス満足度は高いが購買行動に結びついていない

3. アクション提案

• 購入率を上げるため、スタッフへの販売スキル研修を実施する
• 好調なパンツカテゴリーの在庫を確保しつつ、トップスや小物の売上向上策を検討する

などのフィードバックが得られました。

Daily Insights機能では、単なる日報の記録やレポート出力ではなく、売上データに加え、

• どの商品を強化すべきか
• どの売場改善を優先すべきか
• どの時間帯の施策を見直すべきか

といった、次のアクションにつながる示唆を得られる点が特徴です。
なお、売上や来客数などの定量データは別途S3に登録する必要があります。

＜サンプルデータの利用に際して注意点＞
初期デプロイ時に投入されるテストデータは「前日」および「前々日」のデータです。 システムは直近のデータを参照する仕様のため、デプロイから１日以上経過するとデータが過去のものとなり、Insights 機能が動作しなくなります。 その場合は、再度テストデータを投入してください。

(3)History（Daily SurveyとDaily Insightsの履歴）

Daily SurveyとDaily Insightsの履歴を一覧で確認できる画面です。
他店舗間でもインサイトを共有することができます。

売上データに加え、

• アンケート回答
• AIエージェントとの対話履歴
• 日々の気づき

などの定性データも蓄積されます。
これにより、売上などの定量データだけでは見えなかった「現場の背景」まで含めて分析できるようになります。

(４)Admin

Adminユーザーでログインすると以下の画面になり、左メニューにAdminの画面が増えていることがわかります。
Adminユーザーは管理者専用の機能を使うことができます。

管理者（Admin）専用の機能は以下の２つです。

1. Announcementsの編集（店舗へのお知らせの編集）
2. Survey Questionsの編集（店舗への固定された質問の編集）

ここで編集したお知らせと質問が、Daily Surveyのアンケート画面に反映されます。

4. まとめ

店舗運営では、これまで「経験」や「勘」に依存する意思決定が数多く存在していました。
しかし今後は、AIエージェントによって現場データと日々の気づきを蓄積・分析し、「誰でも改善判断ができる状態」を作れる時代になりつつあります。
特にポイントは以下の4点です。

4-1.店舗スタッフの業務負担軽減と本来業務への集中

手書きやExcelでの日報作成から解放されます。
AIエージェントがスタッフの回答をもとに自然な対話で深掘り質問をしてくれるため、現場の状況を簡単にデータ化できます。
これによって店舗スタッフの事務作業の負担を減らし、スタッフは本来の店舗運営や接客により集中できるようになります。

4-2.データに基づいた客観的フィードバックの早期獲得

AIエージェントとの対話やアンケートから得た「定性データ」と、売上などの「定量データ」を掛け合わせて統合分析された、改善インサイトを取得できます。
また、客観的な分析による「改善提案付きレポート」が自動生成され、店舗側でフィードバックとして受け取ることができます。

4-3.リアルな現場の声の蓄積と、ナレッジの組織的な横展開

これまでの定型フォーマットでは伝わらなかった現場の細かいニュアンスやリアルな声が、構造化されたデータとして蓄積され、本部に届くようになります。
個人の頭の中に留まりがちだった成功事例や工夫がデータとして可視化されるため、店舗間でのナレッジ共有が進み、組織全体の学習と横展開がしやすくなります。

4-4.導入のしやすさと柔軟なカスタマイズ性

GitHubから20分かからずにデプロイが完了し、すぐに利用を開始して効果検証（PoC）に進むことができます。
本部側の管理画面から、アンケートの質問項目（選択式、テキスト、評価など）をノーコードで簡単に追加・編集できます。
プロンプト（テキストファイル）を編集するだけでコードを変更せずにAIエージェントの振る舞いを調整できるほか、SQLを記述してAIエージェントが参照するデータソース（商品情報や在庫など）を拡張することも可能です。

「店舗運営にAIエージェントをどう組み込めるのか」を検討している方は、ぜひ一度試してみてはいかがでしょうか。デモ視聴や、導入時の課題整理・改善提案なども可能ですので、お気軽にお問い合わせください。

AUCへのお問い合わせ

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

1. はじめに
2. AI BPRとは
3. ワークショップの内容
4. 参加者の声
5. 組織への展開と本格導入

1.はじめに

売上や現場の数字を見ながら、次々と判断を下す毎日。「これAIでやってくれないかなぁ」と感じたことはありませんか。

生成 AI のニュースは毎日のように流れてきますが、自社の業務で「使える」という実感を持てている方は、まだ少ないのではないでしょうか。業務の中で日々判断を重ねている方ほど、目の前の業務を AI が肩代わりしてくれる姿は具体的にイメージしにくいものです。

こうした課題に向き合う手法として、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS Japan）が今年3月に提唱した手法が AI BPR（AI を前提とした業務プロセスの再設計）です。AWS Japan がすでに複数の大手企業で実施した AI BPR では、参加者の81％が「AI エージェントによってビジネスモデルが変わると確信した」と回答するなど、確かな成果が出ています。 ※ AI BPRの紹介はこちら：Amazon Web Services ブログ/AI 駆動の業務変革手法 :「課題は何ですか？」と聞くのをやめた日

アクセルユニバース（以下、AUC）は、AWS Japan と共催で AI BPR ワークショップを継続的に開催しています。今回は2回目の開催（前回開催報告はこちら）で、Data Analytics Agent をテーマに 7 社 30 名のお客様にご参加いただきました。終了後アンケートでは、参加者の 85% が「AI エージェント前提への業務変換は実現可能」、90% 以上が「ワークショップ全体に満足」、60%以上 が「経営層に報告したい」、つまり全社を巻き込んで実施する価値があると回答しています。

本記事では、当日の内容と参加者の声、そしてワークショップを起点に何を変えていけるのかをご紹介します。

2.AI BPRとは

AI BPR とは、ビジネスモデルや業務プロセスに対し、AIエージェントが業務の一部を担うことを前提に組み替える4〜5 時間のプログラムです。

従来型の BPRは、「何が問題か」から出発するアプローチであり3〜4 割しか成功してこなかったと言われています。 理由は次の3点に集約されます。

• 問題から始めると、人は防衛的になる
• ヒアリングと資料化の往復で、変革の主体が現場から奪われる
• AI 導入は本来「適応課題」なのに「技術課題」として扱ってしまう

また、「とりあえず AI を導入してから業務を考える」というデジタルファースト型のアプローチでも、現場で定着せずに止まってしまうケースが多くあります。AI BPR は、こうした失敗パターンを回避するために設計されています。

これまでの「業務改善」や「DX」と AI BPR が決定的に違うところは、既存業務を効率化することにとどまらず、「AI エージェントが業務の一部を担う」ことを前提に、仕事の組み立てそのものを設計し直すという点です。

特徴は大きく 4 つあります。

1. 強み起点：問題点を洗い出すのではなく、自社が何で価値を出せているか、強みは何かから出発する
2. 対話的アウトプット：AI と対話しながら、その場で成果物を作成する（持ち帰って資料化する時間を必要としない）
3. 実用性の実証：実データを使って、明日から本当に使えるかをその場で検証する
4. 再現可能性：進め方がパッケージ化されており、特定の人の職人芸に頼らず一定の成果が出せる

たとえば「強み起点」は、「クレーム対応が遅い」という問題から出発するのではなく、「当社の強みは常連客のリピート率の高さ。この強みをさらに伸ばすために、AI に何を任せるか？」と問い直す。問題ではなく、もっと伸ばせる余地に目を向けるからこそ、参加者の議論がポジティブに前進します。

そして進め方は、Observe（業務フロー可視化）・Shift（AI 委譲判断）・Simulate（プロトタイプ検証）・Forecast（展開計画策定）の 4 ステップ。「見て、決めて、試して、計画する」というシンプルな流れに沿って、半日で業務変革の第一周目を回します。

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

今回のワークショップは、参加企業ごとに事前に決定した自社業務を題材に、AI BPR を体験していただくことを目的に、座学とハンズオンの2部構成で実施しました。

成果物として、参加企業様には次の2点を持ち帰っていただきました。

• 実際に動くデータ分析エージェント環境
• 「明日からどの業務をどの AI エージェントに任せ、そのことで自分たちのどんな強み・価値が強化されるのか」というストーリーがまとまった資料

当日の流れは以下の通りです。各ステップの間で参加者が迷わず進められるよう、環境のデプロイは AI エディタ Kiro との対話で完結する設計とし、事前にデータ取り込みの動作確認を済ませた状態でワークショップを開始しました。

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

ハンズオンに入る前に、AI BPR の考え方と、当日構築する Data Analytics Agent についての座学セッションを実施しました。

3-1-1.AI BPR vs 従来型BPR とその理由

AI BPR セッションの様子
座学セッションはオンラインセミナー形式で行いました。

アクセルユニバース株式会社

竹中 涼香

AUC は、AWS Japan が提唱する AI BPR について公式のトレーニングを受け、AI BPR ワークショップを提供しています。

セッションでは、従来型 BPR の3つの失敗理由（問題起点/ヒアリング往復/技術課題扱い）と、それに対して AI BPR がどう答えているかを対比しながらご説明しました。

ここで大切にしているのは、AI BPR を「今日限りのワークショップの方法論」として伝えるのではなく、参加者ご自身が社内で AI 活用を進める際の思考の型として持ち帰っていただくことです。そのため、対比はあえてシンプルな表現に絞り込み、社内で説明する場面を想像していただきながら進めました。

AWS Japan 様が実施した AI BPR では、すでに複数の大手企業で確かな成果が出ており、顧客満足度は 5 点満点で 4.86、参加者の 81％ が「AI エージェントによってビジネスモデルが変わると確信した」と回答しています。今回のワークショップでも、こうした手法を単に説明するのではなく、参加者の皆様ご自身に体験していただくことを大切にしています。

3-1-2.本日の構築対象「Data Analytics Agent（D360）」のご紹介

ハンズオンの題材は、Discovery360（以下、D360）と呼んでいるデータ分析AIエージェントです。「データ分析の依頼を、SQL もダッシュボード操作もなしに、日本語の対話だけで完結させる」ことを目指して開発されました。

たとえば「先月、関東で離反した顧客の特徴を教えて。対策を検討して。」と入力すれば、その場で答えが返ってきます。さらに管理者向けの画面では、どのデータを使うか、どのような目的で使用するか等、自社の業務に合わせて調整することができます。

構成はシンプルで、Web の画面、AI エージェント、データベースの 3 層で成り立っています。ユーザーは聞きたいことを日本語で入力するだけ。AI が裏でデータを取得・集計し、答えを返してくれます。SQL も、複雑なダッシュボード操作も必要ありません。

Data Analytics Agent の構成

D360 はオープンソースとして公開されており、構築方法は GitHub からご確認いただけます。Discovery360 (D360) - AWS Samples

ワークショップでは、Observe で業務を見て Shift で AI に任せる範囲を決めていく思考の流れを通じて、この D360 をご自身の業務・目的に合った仕様に仕上げていく、という流れで進めました。

3-2.第2部：D360構築とAI BPRハンズオン

後半は、実際に D360 を構築しながら AI BPR の 4 ステップを体験するハンズオンを実施しました。

参加企業ごとに部屋を分け、それぞれのチームで議論を深めながら構築を進めていただきました。

今回のワークショップで大切にしたことは、「自社の環境で、自社のデータで、AI エージェントが応答する」体験を、説明や事例紹介ではなくご自身の手で作っていただくことです。実データをインポートし、AI に質問を送り、精度を調整する、というサイクルを実際に回していただきました。

各社の議論を覗いていると、印象的な変化が起こっていました。最初は「本当にうまく答えてくれるのか」と慎重に質問を送っていた方が、何回かのやりとりの後に「これなら現場で使える」と表情が変わる。ある参加企業では、Shift のステップで「これは AI に任せたいけど、ここは絶対に人が判断したい」という線引きが、メンバー間でその場で言語化されていく場面も見られました。

ハンズオンの最後には、ご自身の業務に AI エージェントを実装するための展開計画を、AI との対話を通じてその場で作成いただきました。

4.参加者の声

ワークショップ終了後、ご参加いただいた 30名の皆様にアンケートをご協力いただきました。

• ワークショップ全体満足度：90% 以上
• 進行・フォロー満足度：85％以上
• 「AI エージェント前提への業務変換は実現可能」：85%
• 「この内容を経営層に報告したい」：63%　
  
  

特に注目したい部分は、最後の結果です。参加者の6割以上が「この内容を経営層に報告したい」と回答されました。自分のチームで試すだけでなく、会社全体で取り組む価値があると感じていただけたことが、このワークショップの一つの成果だと考えています。

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

• 他業務でも転用できるノウハウを伺えた。
• 根本的な課題がかなりクリアになった。
• 質問に答えるだけで AI エージェントの作成・動作確認ができるのが新鮮だった。
• 言語化や可視化のスピードが、人手とは比にならない。
• AI で業務整理を進める過程そのものがとても参考になった。
  

「業務の言語化に AI が想像以上に役立つ」「自社の業務にどう AI を組み込むかが具体的にイメージできた」といった感想もあり、AI BPR の考え方が実体験を通して伝わっていたことがうかがえました。

また、「次のステップで必要な支援」としては、自社データを使った検証が 56%、他社事例の共有が 41%、業務部門向けデモ・勉強会が 30% と、当日の気づきを自社の実データへの適用に進めたいというご意向を、多くの方から頂戴しました。

5.組織への展開と本格導入

​​「ワークショップ当日は盛り上がったが、結局その後動かなかった」――AI 活用の取り組みでよく聞く話です。なぜそうなるのか。多くの場合、原因は次のどちらかに偏ってしまうことにあります。

• 計画偏重：きれいな展開計画はできたが、実装が伴わず絵に描いた餅で終わる
• 実装偏重：技術的には動くものができたが、業務との接続が弱く現場で使われない
  
  

AUCでは、AI BPRの実践とAWS上での構築、どちらも行っています。当日作成された展開計画をお客様の状況に合わせて実装フェーズに接続し、業務での定着まで伴走することができます。今回のD360はもちろん、他テーマでも同様にご支援が可能です。

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

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

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

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

• どこから始めればよいのか分からない
• 何を作ればよいのか分からない
• 経営層や現場を巻き込んでどう進めればいいか分からない
  
  

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

そうした段階でも、課題整理から一緒に検討させていただきます。本記事をきっかけに、AI BPR や D360 にご関心をお持ちいただけましたら、ぜひお気軽にご相談ください。

AUCへのお問い合わせ

1. はじめに
2. 開発フローと注意点
3. まとめ

1.はじめに

現在、多くの企業で「今動いているシステムをどうするか」という課題に直面しています。長年使い続けてきたシステムは、業務に深く根付いている一方で、技術的な老朽化やブラックボックス化が進み、手を入れること自体が難しくなっているケースも少なくありません。既存システムの設計書や仕様書が存在しない、"触れないシステム"が現場に残り続けているのが実情です。

しかし一方で、こうしたシステムは企業にとって重要な業務データやノウハウの塊でもあります。単純な作り直しではなく、「既存の資産を活かしながら、より良い形へと進化させる」ことが求められています。こうした背景の中で、AIを活用したシステムリプレイスが注目されています。AIに、人間が時間をかけて行っていた解析・整理・確認作業を担わせることで、既存資産を理解・再構成しながら、システムを進化させることが可能になります。

本記事では、AIを活用したシステムリプレイスの考え方と、その具体的なアプローチについて紹介していきます。

2.開発フローと注意点

本章では、システムリプレイスにおけるAI駆動開発の流れと、各フェーズのポイントを解説します。

AIは膨大なコードやデータを読み解き、構造を整理し、改善のヒントを導き出すことを得意としています。特に、既存システムを理解し、再構成していくプロセスにおいて、その力を大きく発揮します。

【前提】

AI駆動開発では、AIが要件や仕様を理解できるように、「AIが参照しやすい形」で情報を蓄積することが重要です。

特に、マークダウン形式のデータはAIが構造を解釈しやすいため、要件管理には Backlog などのマークダウン形式で保存できるツールを活用することをおすすめします。 本記事では、Backlogに蓄積された要件情報をMCPサーバー経由でAIと接続し、業務・要件・コードを分断しない形で開発を進める構成を前提としています。

2-1. 分析フェーズ：レガシーシステムを理解する

分析フェーズでは既存のソースコード（レガシー）を起点に、システムの構造、挙動を把握します。

AIを活用することで、

• システムの機能・処理内容
• 画面構成・画面遷移
• データ構造・項目定義

といった情報を抽出し、現行システム仕様書として整理します。これにより、ブラックボックス化していたシステムの全体像を可視化することが可能になります。

さらに、AI開発用のルールや観点をまとめた「スキル（AI向けルール定義）」を活用することで、

• 不要な機能の洗い出し
• 問題点の指摘
• 改善案の提示

までを同時に実行しています。最初にスキルを完璧な状態にしなくても、ある程度の状態で開始して、運用しながら改善することも可能です。従来は、「現状を理解する工程」と「改善を検討する工程」を分けて進めるケースが一般的でした。AIを活用することで、現行システムの理解と改善の方向性検討を同時に進めることが可能になります。

ただし、外部システム連携や業務上の運用ルールなど、コードから読み取れない情報は含まれません。そのため、後続フェーズで補完していく必要があります。

2-2. 仕様フェーズ：現行仕様から新仕様へつなげる

分析フェーズで現行システムの理解が進んだ後、新しいシステム仕様書を作成します。このフェーズでは、以下の情報を統合します。

• 現行システム仕様書
• Backlogに蓄積された要件
• 業務フロー情報

特に重要となるのが業務フローの整理です。

業務フローが属人化している場合、人によって認識が異なっていたり、システムと実際の運用が一致していないケースも少なくありません。そのため、必要に応じて業務フローを可視化し、関係者間の認識を整理していきます。

これにより、

• 要件の明確化
• 関係者間の認識の統一
• 開発意思決定の迅速化

が実現され、プロジェクトの円滑な進行につながります。

ここで重要なのは、「業務フローを作ること」ではなく、既存の情報を活かしながら最適な形に整理することです。

2-3. 実装準備フェーズ：テストと実装計画を整える

仕様が整理できたら、次にテスト仕様書と実装計画を作成します。2−2で作成したシステム仕様書をもとにAIがテスト仕様書を作成します。

これにより、

• 仕様の抜け漏れを網羅的に検出
• 人では見落としがちな観点の補完
• 作業時間の削減

が可能になります。人がミスしやすい「網羅性の担保」をAIが担います。さらに、システム仕様書とテスト仕様書をもとに、実装計画を作成します。

機能が大きい場合は、「スライス」と呼ばれる単位で分割し、「まずはここまで作る」、「次にここを実装する」といった具体的な開発ステップに落とし込みます。このフェーズの本質は、実装しやすい状態をつくることです。AIが計画や分割を担うことで、人間は判断に集中できる状態になります。

2-4. 実装フェーズ：AIが作成し、人が判断する

実装フェーズでは、バックエンド・フロントエンドの開発と並行して、テスト仕様書に基づく検証を行います。また、コーディング規約や開発ルールのチェックもAIが自動で実行します。

これにより、

• チェック漏れの防止
• レビュー工数の削減
• 品質の均一化

が実現されます。

ここで重要なのは、AIは「人ができないこと」を代替しているわけではないという点です。人がやると時間がかかる/抜け漏れが発生する、といった作業をAIが担うことで、

• 仕様の妥当性の判断
• ビジネス的な意思決定
• 最終的な品質判断

といった、人間の強みがより発揮される構造になります。AIは人を置き換えるのではなく、人の強みを引き出すための仕組みです。

最終的なレビューは人間が行いますが、AIによる事前チェックがあるため、短時間で本質的な確認に集中できます。また、AIレビューを行う場合は、新しいセッションで実施することで、より客観的で精度の高い評価が可能になります。

3.まとめ

本記事では、システムリプレイスにおけるAI駆動開発の進め方を、分析・仕様・実装準備・実装の各フェーズに分けて解説しました。

特に重要なポイントは以下の3点です。

• ソースコードから仕様を再構築し、「分からない状態」から脱却できること
• テスト・計画・チェックといった工程をAIが担うことで、開発の土台を整えられること
• 人間が判断や意思決定といった、本来の強みに集中できる構造を作れること

従来のリプレイスは、「全てを人が理解し、設計し、作り直す」ことが前提でした。しかしAI駆動開発では、「AIが理解と整理を担い、人が判断する」という役割分担に変わります。

この変化により、これまで手が出せなかったレガシーシステムにも、現実的なアプローチが可能になります。システムリプレイスにおいて重要なのは、すべてを作り直すことではなく、既存の資産を理解し、活かしながら進化させることです。

また、Backlogに蓄積された（マークダウン形式で蓄積された）要件とAIを接続することで、業務・要件・コードが分断されない状態を実現できます。これは単なる開発効率化ではなく、業務とシステムを一体として捉え直すアプローチです。

重要なのは、AIを導入することではなく、AIが自然に機能する構造をどう設計するかです。その設計こそが、これからのシステム開発における競争優位になると考えられます。

システムリプレイスにおいて、「現行システムが理解できない」「仕様が不明確で進められない」といった課題をお持ちの場合は、お気軽にご相談ください。

AUCへのお問い合わせ　

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