- 初日から大きなシステムに飛びつく必要はありません。効果を測れる仕事を1つ選んで始めるほうが安全です。
- うまくいく順番は、まず質問に正確に答えられるようにし、次にシステムに実際の操作を任せ、そのあとで対象の仕事を広げることです。
- 最初から最後まで追い続けるべき指標は1つ、用件を最後まで済ませられる顧客が増えているかどうかです。
従来のWebサイトやアプリの限界
多くの会社は、画面の隅にチャットボットを置くところから始め、そのまま何年も足踏みしています。質問には答えられても、用件を1つとして最後まで片づけたことがないからです。だから問うべきは「AIを次にどこに入れるか」より、「いま顧客の何パーセントが用件を最後まで済ませられているか」です。
多くの企業はチャット欄から始め、デモの受け答えがよいので、急いで実際の操作（Action）をつなぎます。ところが、テストセットも、正となるデータ（Source of Truth）も、承認のルールもまだありません。そのため、試験導入から本番公開に踏み切れなくなります。
質問には答えられても先へ進めないチャットボットのデモを抱えている組織は少なくありません。データの責任者、API、権限、効果の測定、システムが間違えたときの対応計画がまだないからです。会話から一気に、人の代わりに仕事をするエージェントへ飛ぶと、準備よりも速くリスクが膨らみ、チームは「AIは実務には使えない」と誤った結論を出してしまいます。
開発チーム向け · 技術的な詳細
よいロードマップは、能力と責任を1段階ずつ増やしていきます。SearchとAnswerから始め、Assist、Recommend、Reversible Action、Orchestrationへと進みます。段階ごとにOutcome、Guardrail、Evidenceがあるので、企業は課題に合わせて投資を選べます。将来のユースケースを待つために大きなプラットフォームを作ることはしません。
| 従来の形 | 新しい世代のAIプロダクト |
|---|---|
| モデルを選び、プロンプトを書いて、質問を受け付ける | 意図、コンテキスト、ツール、承認、実行、フィードバック、評価、監視までのプロダクトのループを設計してから、自律性を1段階ずつ上げる |
開発チーム向け · 技術的な詳細
ロードマップのどの段階も、Identity、Knowledge、API、Policy、Evaluation、Monitoringという共通の基盤（Foundation）の上に載せます。こうした層をモデルから切り離しておけば、技術を入れ替えたり操作を追加したりしても、利用の流れ全体を作り直さずに済みます。
ビジネスに使える新しい機能
安全な道筋は、1段ずつ進むことです。まず、答えがはっきりしている質問に正確に答えられるようにします。正確になったら、予約や下書き書類の発行のように、元に戻せる作業を任せます。お金や契約に関わる仕事に広げるのは、管理しきれると証明できてからです。
ロードマップの全体像
最初の段階では、データを検索・引用できるようにします。次の段階では、人が確認する前提で下書きや要約を手伝わせます。そのあとでツールをつないで元に戻せる操作を任せ、最後に複数の段階や複数のエージェントにまたがる連携を加えます。段階を飛ばすのが必ず間違いとは限りません。ただし、前の段階の土台はシステムの中に備わっていなければなりません。
積み上げるべき能力
どの段階でも、プロンプトを足すだけで終わらせず、知識の管理責任（Knowledge Ownership）、ID管理（Identity）、権限、ツールの取り決め（Tool Contract）、評価、承認、監視、フィードバックのループを加えていきます。利用者側の機能も、自律性のレベルに応じて、回答から、案内付きのワークスペース、操作をまとめたアクションセンター、例外キューへと少しずつ移っていきます。
再利用できる部品としての技術
アーキテクチャは、Web・モバイルの画面、バックエンドとAPI、知識、エージェントの実行環境、ポリシー、評価、オブザーバビリティを分けておくべきです。そうすれば、モデルを替えたりユースケースを増やしたりしても、全体を作り直さずに済みます。AIによる自律型開発（AI Autonomous Development）は、プロトタイプ、コード、テストの作業を速められますが、明確なアーキテクチャ、レビュー、セキュリティの実践の枠内で使う必要があります。
段階的に進める利点
経営層は、一つひとつの投資がどの問いに答えるものなのかを把握できます。チームは、重要な業務をまだ実績のないシステムに預けることなく、試験導入から学べます。作った部品は次のユースケースにも使えます。データ、価値、準備のいずれかが足りないときに、筋の通った理由で中止を決められるのもロードマップの利点です。
- レベル1 回答：出典を示せる情報をもとに答える
- レベル2 補助：下書きや提案をし、操作は人がクリックして行う
- レベル3 承認付きの実行：操作を準備してから承認を求める
- レベル4 範囲を限った自律：決められた範囲内で定型のケースを処理し、監査の記録を残す
架空のケース
具体的な利用場面
ある企業は、日程調整エージェントをまず提案だけのモードで使い始め、次に予約の下書きを作らせます。重複予約、タイムゾーン、キャンセル、権限の確認がテストセットで合格してから、ようやく実際の予約確定を有効にします。
架空のケースとして、ある小売企業は、返品ポリシーについての質問に出典つきで答えるアシスタントから始めます。第2段階では、スタッフの確認つきで注文状況を要約させます。第3段階では、顧客が配送日時を選び直せるようにします。これは元に戻せる操作です。その次の段階になってはじめて、在庫、配送、通知の連携に進みます。
段階ごとに合格基準は異なります。たとえば回答の正確さ、引き継ぎの漏れのなさ、操作の成功率、重複処理の件数などです。連携先のシステムが止まったときは、情報の提供や担当者への引き継ぎに切り替えられるので、いちばん賢い部分が使えないせいで利用の流れ全体が止まることはありません。
Autonomy Ladder
自律の度合いを上げるのは、根拠、元に戻せること、監視の準備が整ったときです。チームの腕前を見せるために上げてはいけません。
どのレベルにも、続行か中止かを決める基準（Stop/Go Criteria）と責任者が必要です。
範囲、リスク、効果の測り方
開発チーム向け · 技術指標
ロードマップの評価に、ユースケースの数や到達した自律性の最高レベルを使うべきではありません。Outcome、Adoption、Error Impact、Recovery、Cost per Successful Task、公開後の運用負担を測ります。どの試験導入にも、Stop/Go Criteriaと、業務プロセスを変える権限のある責任者が必要です。そうでなければ、システムはデモと本番のあいだで止まったままになります。
抽象化の層を置かずに、プロダクトを1つのモデルに縛りつけてはいけません。AIに広い範囲の認証情報を持たせるのも、コストと成果を測る前に規模を広げるのも避けてください。
開発チーム向け · 技術指標
追跡すべき指標：Accepted Outcome、Tool Success、Approval Rate、Rollback、Incident、Latency、Total Cost
- Discover：実際の業務を追い、通常のケースと例外の実例を集めます。
- Assist：人が主導権を持ったまま、AIに下書きや提案をさせます。
- Act：テストセットに合格してから、ツールを1つずつ使えるようにします。
- Scale：監視、フォールバック、コスト管理、責任者がそろってから範囲を広げます。
試験導入に責任者がいない、データが安定しない、1件あたりのコストが上限を超えた、過去のエラーが検知されないまま再発した。こうしたときは拡大を止めるべきです。土台の修正に戻ることも、AI活用の前進に数えられます。
BUSINESS & PRODUCT READINESS
自律性を上げる前にプロダクトの土台を固め、試験導入をデモ止まりにしない
開発チーム向け · 技術的な詳細
Capability Inventoryを作ります。モデルが何を理解できるか、データはどこから来るか、ツールは何をするか、権限は誰にあるか、結果を元に戻せるかを洗い出します。そのうえで、ユースケースをValue、Feasibility、Risk、Reversibilityで順位づけします。データがまだはっきりしない仕事で、高いレベルから始めるべきではありません。
開発チーム向け · 技術的な詳細
操作を有効にする前にEvaluation Setを作り、Happy Path、不完全なデータ、Prompt Injection、Tool Error、重複、Permission Testを含めます。Owner、Incident対応、Cost Budget、Model Change Processもすべて決めておきます。モデル、データ、利用者の行動はどれも変わるので、AIを使うプロダクトは継続的にテストしなければなりません。
開発チーム向け · 技術指標
組織がいまデータ、API、Identity、Owner、効果測定でどのレベルにあるかをCapability Inventoryで把握し、ユースケースごとに見合った自律性のレベルを当てはめます。元に戻せない仕事や高い権限が絡む仕事は、Human Approvalを恒久的に残してもかまいません。Fully Autonomousまで進む必要はありません。
開発チーム向け · 技術的な詳細
Evaluation Setは最初から作り、通常のケース、欠けたデータ、Prompt Injection、Tool Error、重複した指示、例外を含めます。あわせて実行と運用のコストも見積もります。品質の低下をどう検知するかを決めておくことは、デモの日にプロトタイプが動くと証明することと同じくらい大切です。
最初に目指す成果は何か
自律性はどのレベルが適切か
元に戻せない操作はどれか
品質の低下にどうやって気づくか
まず正しい課題を選び、それに見合った賢さを選ぶ
DNA Makerは、経営者の実際の業務プロセスとデータをもとに、AIの活用機会と自律性のマップ（AI Opportunity/Autonomy Map）を作るお手伝いをします。何をWebサイト、アプリ、ワークフロー、ナレッジ検索、エージェントにすべきかを切り分け、技術を選ぶ前にガードレールと価値の仮説を書き出します。
プロダクトディスカバリーの段階では、ユーザージャーニー、アーキテクチャの選択肢、データ・システム連携のマップ、プロトタイプを作り、利用者と意思決定者に試してもらいます。試験導入はビジネス上の問いに答えられるように設計し、続行か中止かの基準も持たせます。モデルを披露するだけでは終わらせません。
私たちは、実際の業務プロセスからAIの活用機会と自律性のマップを作り、データとシステム連携、UX、アーキテクチャ、ガードレールから評価まで、引き続き積み上げていけるプロダクトの土台を設計します。どんな課題もエージェントに押し込むことはしません。Webアプリ、ワークフロー、検索のほうがシンプルで責任ある答えなら、そちらを提案します。
試験導入の対象が決まれば、プロトタイプ、Web・モバイルアプリ、バックエンド、AIエージェント、ツール、承認、監視、運用ドキュメントまで開発できます。AIによる自律型開発で作業を速めつつ、エンジニアがレビューします。アイデアがいくつもあるなら、業務プロセス、サンプルデータ、気がかりな点をお持ちください。効果を測れて、次の段階の土台にもなる最初のプロジェクトに絞り込むお手伝いをします。
エンジニアリングチームは、Web・モバイル・バックエンド、AIエージェント、ツールとAPI、人による承認、評価、オブザーバビリティ、管理運用の機能を、本番運用まで開発できます。コードレビュー、テスト、セキュリティの実践のもとで、AIによる自律型開発を使って作業を速めます。
DNA Makerは、たくさんのアイデアを、はっきりしていて効果を測れ、まだ実証されていない選択肢に組織を縛りつけない試験導入へと絞り込むお手伝いをします。どこから始めればよいかわからないなら、業務プロセス、サンプルデータ、気がかりな点を持ってご相談ください。
SOFTWARE ENGINEERING GLOSSARY
ソフトウェア開発用語集
最後の用語のまとめでは、エージェント型プロダクトの考え方を、自律性のレベル、テストセット、代替手段、モデルの切り離しと結びつけます。提供元を替えたりユースケースを増やしたりできるロードマップを責任をもって描くための、共通の言葉として使ってください。
| 用語 | 意味 | わかりやすい例 | 開発チームへの質問 |
|---|---|---|---|
| Agentic Product | AIが手順を計画し、決められた範囲内でツールを使うプロダクト。ツール、ルール、追跡の仕組みのもとでAIが複数の段階を計画・実行するもので、文章を生成するだけのチャット画面とは違う | エージェントが予約を準備し、人に確認を求める | 成果と範囲の責任は誰にあるのですか？ |
| Autonomy | システムが自分の判断で動ける度合い。操作ごとに分けて決めるべきで、同じシステムでも、自動で回答はできるが、データの変更や取引の前には人の承認が必要、ということがある | 定型のケースは、段階ごとに待たずに処理する | どんな根拠を満たせば、自律の度合いを上げるのですか？ |
| Evaluation Set | 品質を繰り返しテストするための事例集。通常のケース、欠けたデータ、例外、攻撃を含め、専門家が認めた正解や基準もそろえる | 通常のケース、リスクの高いケース、不完全なデータ | 実際に起きる例外まで網羅していますか？ |
| Fallback | AIやツールが失敗したときの代替手段。仕事とその文脈を失わないことが条件で、たとえば手作業の流れに切り替えたり、人に引き継いだりする。システム障害のメッセージを出すだけでは足りない | データを失わずに、仕事を人の作業キューに回す | チームはフォールバックの手順を練習していますか？ |
| Model Abstraction | プロダクトをモデルの提供元から切り離す層。プロダクトのロジックを提供元から分けておくことで、バージョンの切り替え、コストの管理、代替案のテストを、システムへの影響を抑えながら行える | ワークフローを作り直さずにモデルを替える | 品質やコストの違いは、どうテストしているのですか？ |