AIエージェントは「作れる」だけでは価値を生まない

AWSの講演から読み解く、試作・本番運用・業務変革の間にある大きな溝

生成AIが登場した当初、企業の関心は「AIに何を答えさせるか」に向いていた。社内文書を検索する。メールを下書きする。資料を要約する。コードを書く。こうした用途は、個人の生産性を上げるうえで有効である。

AIエージェントの段階になると、対象は回答生成だけではない。情報を集め、判断し、複数のシステムを操作し、継続的に監視し、人に承認を求め、条件が満たされれば次の処理を実行する。

AWSジャパンの講演で紹介されたAmazon Quick、Kiro、AWS Transform、Strands Agents、Amazon Bedrock AgentCoreは、一見すると別々の製品群に見える。しかし、共通するのは、AIエージェントを「モデルを呼ぶコード」ではなく、企業の業務システムとして扱おうとする考え方である。

本稿では製品の機能一覧ではなく、IT技術者が向き合うべき次の溝に注目する。

試作品が動く
  ↓
業務で役に立つ
  ↓
安全に実行できる
  ↓
継続的に評価・改善できる

AIエージェントは「作れる」だけでは価値を生まない。本番の業務へ組み込み、権限・品質・障害・コストを管理できて初めて、価値になる。

ルールベース自動化とAIエージェントは、失敗の仕方が違う

従来の業務自動化では、人が処理手順を細かく決める。たとえば請求書処理なら、メールを受信し、添付を保存し、金額を読み取り、取引先コードを照合し、会計システムへ登録する、という経路をルールとして実装する。入力形式と条件が安定していれば、RPAやワークフローで十分に機能する。

一方、実務には曖昧さがある。書式が取引先ごとに違う。必要な情報が本文と添付資料に分かれる。例外が多い。過去事例を読まなければ判断できない。状況に応じて次の行動が変わる。

AIエージェントは、非定型情報を解釈し、目的に向けて次の処理を選べる。だが、自律性が高くなるほど、誤判断が後続業務へ与える影響も大きくなる。

種類	主な強み	主な失敗	必要な統制
ルールベース処理	決められた処理を再現する	条件漏れ、例外未実装	ルール・例外テスト
生成AIの回答支援	非定型文の要約・作成	誤回答、根拠不足	根拠表示、人の確認
AIエージェント	検索・判断・ツール実行を連鎖する	誤認識や誤操作の連鎖	最小権限、承認、停止、トレース

重要なのは、AIエージェントを「高性能なチャット」と見なさないことだ。外部システムへ接続し、状態を持ち、複数ステップで行動するなら、それは分散アプリケーションとして設計・運用する必要がある。

AIエージェントの価値は三つの領域で現れる

講演で扱われた活用領域は、大きく三つに整理できる。

1. 個人と組織の生産性向上

調査、要約、翻訳、資料作成、会議準備、定型作業の支援である。比較的導入しやすく、利用者が成果を実感しやすい。ただし、ここでの成功をそのまま業務の自律実行へ拡張してはいけない。

2. ソフトウェア開発の加速

コード生成だけでなく、要件、設計、実装、テスト、セキュリティ確認、デプロイ、運用、改修までを支援する。速度が上がるほど、仕様・テスト・変更管理の不足が表面化する領域でもある。

3. 業務プロセスの変革

書類審査、保守、監査、顧客対応、発注、モニタリングなどで、エージェントが複数システムをまたいで動く。影響範囲が大きいため、権限、承認、監査、復旧を前提に設計しなければならない。

資料の翻訳を誤ることと、誤った部品を発注することは同じ精度基準で扱えない。まず対象業務の影響度と可逆性を決め、そのリスクに合わせて自律性を設計する必要がある。

Amazon Quickは「調べる・分析する・実行する」をつなぐ

Amazon Quickの公式ドキュメント では、Quick Research、Quick Flows、Quick Automate、Quick Index、Quick Sight、アプリケーション構築を、同じAIサービスの機能として位置付けている。Quickは、従来のQuickSightをQuick Sightとして含み、BIだけでなく調査、業務フロー、エージェントによる自動化まで扱う構成である。

• Quick Research: 接続データやWebをもとに、出典付きの調査レポートを作る
• Quick Flows: 個人・チームが繰り返す短い業務フローを作る
• Quick Automate: 長時間・高頻度の業務プロセスを、エラー処理やケース管理を含めて自動化する
• Quick Index: 文書やデータソースを接続し、根拠のある回答に使う
• Quick Sight: 構造化データを分析・可視化し、自然言語で深掘りする

特に重要なのは、チャット、BI、調査、ワークフローを別々の画面で終わらせず、業務の流れとしてつなごうとしている点である。Quickのアーキテクチャ説明 では、データソース、エージェント、ツール、MCPやOpenAPIによるアクション接続を組み合わせる構成が示されている。

従来は、BIで異常を発見し、担当者が原因を調べ、関係者へ連絡し、別システムで処理していた。エージェント型の設計では、異常検知、原因調査、対応案の作成、チケット起票、担当者通知までを一つのワークフローにできる。

ただし、Quick FlowsとQuick Automateを同じ「自動化」として扱ってはいけない。AWSのQuick Automateの説明 では、前者を個人・チーム向けの比較的短い反復作業、後者を企業向けの長時間・高頻度プロセスとして区別している。本番化する処理には、所有者、入力データ、例外、実行上限、承認者、停止方法が必要になる。

車両保全のPoCが示すのは、AI分析よりデータの結合である

講演では、東急電鉄の車両保全を対象に、走行データ、故障履歴、装置名、時系列データを組み合わせ、優先度判断や故障兆候の把握を試みたPoCが紹介された。故障履歴の自由記述から装置名を推定・補完する処理や、大規模な時系列データの分析も、講演内で紹介されている。

ここで示唆されるのは、「AIが分析できた」ことだけではない。予知保全では、センサーデータ、点検記録、自由記述の故障履歴、装置マスター、整備実績、現場の所見を、保全判断という目的のために結び付けなければならない。

AIがデータ基盤の不足を補うわけではない。むしろ、次の欠落を可視化する。

• 時系列データに正しい装置IDが付いていない
• 故障履歴のラベルや発生日がそろっていない
• センサー値と保全作業の因果を追えない
• 現場の判断基準が記録されていない
• 正式な保全手順と過去の暫定対応が区別されていない

講演で紹介された処理件数や時間短縮などの数値は、公開資料で検証できる条件が十分に確認できない。外部公開では講演内のPoC値として扱い、自社で評価する際は、予兆検知率だけでなく、見逃し率、誤検知率、保全工数、機械停止時間、安全性への影響を測るべきである。

AIコーディングの本体は、コード生成ではなく仕様と制約の管理になる

AIに自然言語で作りたいものを伝え、試作品を作る「バイブコーディング」は有効だ。しかし、本番システムに必要なのは、動くコードだけではない。要件を満たすこと、セキュリティ基準に適合すること、テストされること、既存システムと整合すること、障害時に復旧できることが必要になる。

AWSが提供するKiro は、自然言語の依頼から、詳細な仕様、コード、ドキュメント、テストへ進むエージェント型開発環境として説明されている。仕様駆動開発の狙いは、AIにいきなりコードを書かせるのではなく、要件、設計、実装タスク、テストの関係を保つことにある。

たとえば「顧客問い合わせを管理するWebアプリを作る」という依頼に対して、先に検討すべきことは多い。

• 誰が利用するか
• どのデータを扱い、どのデータを保存しないか
• 閲覧・更新・管理の権限をどう分けるか
• 必要な画面、外部API、失敗時の挙動は何か
• どの非機能要件を満たすか
• どのテストで受け入れを判定するか

仕様駆動開発は、AIの暴走を防ぐ「外側の制約」として働く。AIが速く実装できるほど、仕様、設計、タスク、テストを同期させる変更管理が重要になる。

KiroのAgent Hooksは、ファイル保存・作成・削除などのイベントを契機に処理を起動する機能として説明されている。保存時のテスト生成、API変更時のドキュメント更新、依存関係の確認、規約逸脱の検知などを工程へ埋め込める。ただし、AIが生成したテストを実行しただけで品質が保証されるわけではない。重要なシステムでは、静的解析、SAST、DAST、依存関係スキャン、人間によるレビュー、結合試験、性能試験と組み合わせる必要がある。

AIが力を発揮するのは、差別化しにくい重労働である

AI導入の目的を「開発者を減らすこと」に置くと、現場の抵抗を招きやすい。実務では、人間が事業固有の判断へ集中するために、反復的で差別化しにくい作業をAIへ移す方が効果を測りやすい。

人間が中心になる仕事	AIへ任せやすい仕事
顧客課題の理解	既存コードの調査
アーキテクチャと非機能要件の判断	テストコードの下書き
リスクとトレードオフの決定	ドキュメント更新
優先順位付け	単純な変換・一覧化
例外の受容判断	移行候補・依存関係の整理

この分担は、開発に限らない。AIの出力を採用するか、どのリスクを許容するか、顧客や社会にどの影響を与えるかを判断する仕事は、人間に残る。

レガシー刷新で難しいのは、コードを変換した後である

AWS Transform は、インフラストラクチャー、アプリケーション、コードのモダナイゼーションを、専門化されたエージェントで支援するサービスである。AWSは、メインフレーム、VMware、.NET、カスタム変換などを対象に、発見、計画、実行を支援すると説明している。AWS TransformのFAQ でも、必要に応じたHuman in the Loopを含む構成が示されている。

だが、古いコードを新しい言語へ変換できても、モダナイゼーションが完了するわけではない。本当に難しいのは、次の問いに答えることだ。

• この処理は今後も必要か
• 暗黙の業務ルールを残すべきか、廃止できるか
• 外部システムとの依存関係は何か
• 現行の振る舞いをどこまで再現すべきか
• テストされていない例外処理をどう確認するか

AIは、コードや依存関係を読み、候補を整理し、変換・検証の作業を速くできる。しかし、「なぜこの業務ルールが必要なのか」「同じ挙動を維持すべきか」という判断は人間が担う。モダナイゼーションでは、古いものを速く写すことより、残すものと変えるものを選ぶことが重要である。

Strands Agentsで作れることと、企業で運用できることは別である

Strands Agents は、モデル、ツール、MCP、メモリ、マルチエージェント連携などを組み合わせるSDKである。公式ドキュメントでは、Amazon Bedrockだけでなく、OpenAI、Anthropic、Google、カスタムプロバイダーなどを扱える構成も示されている。モデルプロバイダーの一覧 が示すように、開発時にモデルを切り替えることは以前より容易になった。

これは試作を速くする。一方で、SDKを使ってエージェントが動いたことは、本番運用の開始条件ではない。本番環境では少なくとも次が必要になる。

• 利用者・エージェント・サービスの認証
• 読み取りと書き込みを分けた認可
• セッションと状態の分離
• 秘密情報・APIキーの管理
• 長時間実行、同時実行、障害復旧
• ツール呼び出しの制限と入力値の検証
• ログ、トレース、監視、費用の可視化
• データ保護、保持期間、監査証跡

また、Strands Agentsのツールの説明は、エージェントが読み込んで実行するツールコードを信頼できるものに限定する責任が利用者側にあることを明示している。Strands Agentsのツール設計に関する注意 は、MCP接続を含め、ツールを増やすほどサプライチェーンと権限の管理が重要になることを示している。

AgentCoreが対象とするのは、エージェント固有の運用問題である

Amazon Bedrock AgentCoreは、エージェントを本番で運用するための機能群として、Runtime、Memory、Gateway、Identity、Observabilityなどを提供する。通常のWebアプリケーションは短いリクエストを処理して応答することが多い。対してエージェントは、複数回モデルを呼び、状態を保持し、外部ツールを使い、長時間・非同期で動き、大きなファイルを扱う場合がある。

実行基盤: Runtime

Runtimeはエージェント実行をホストするための基盤である。重要なのは、エージェントを「関数呼び出し」ではなく、セッション、状態、スケーリング、失敗を持つ実行単位として扱うことだ。

アイデンティティ: Identity

エージェントが誰の権限で動き、外部サービスへどの資格情報でアクセスするかを管理する。AgentCoreの公式セキュリティガイドは、本番でJWTベースのユーザー識別を優先し、実行ロールは必要最小限に絞ることを推奨している。AgentCore Runtimeのセキュリティベストプラクティス を踏まえ、万能な管理者権限をエージェントへ与えない設計が必要である。

ツール接続: Gateway

API、Lambda、MCPサーバー、業務システムなどへの入口を、ポリシー付きで管理する。外部認証の説明では、Gatewayを統制された単一の入口として使い、認可、ガードレール、リクエスト・レスポンスの検査、オブザーバビリティを適用できるとしている。AgentCoreの認証・認可の説明 を見ても、接続方式だけでなく、誰が何を呼べるかの制御が中心である。

メモリ: Memory

会話や継続タスクの状態を扱う。メモリは便利だが、誤った前提、古い情報、権限外の情報を持ち続けるリスクもある。保存対象、保持期間、更新・削除、ユーザー・テナント分離を設計する必要がある。

オブザーバビリティ: Observability

最終回答だけでなく、モデル呼び出し、ツール実行、エラー、遅延、状態遷移、費用を追う。AgentCoreの公式ドキュメントでは、Runtime、Memory、Gateway、Identityを含むリソースに対して、CloudWatchとOpenTelemetryを使ったメトリクス、スパン、トレースの取得を説明している。AgentCore Observability は、エージェント運用で処理全体の追跡が必要になることを表している。

この五つは、完成したエージェントの付加機能ではない。本番エージェントの最低限の土台である。

医療書類・監査の事例は、完全自動化率ではなく判断品質で見る

講演では、Fast Doctorによる小児医療関連書類の処理と、LayerXによるシステム監査のエージェント化が紹介された。前者では、自治体ごとに異なる書式や受給条件の確認を支援し、後者では、ログ収集、ポリシー照合、予備評価、証跡保全を継続的に行い、人間が最終判断と是正へ集中する構成が示された。

講演で紹介された自動化率や処理時間は、講演内の事例値として読むべきであり、公開資料で条件まで検証できない数値を一般化することはできない。それでも、二つの事例には共通する設計原則がある。

• AIが書類・ログを読み、候補や不足を整理する
• 明確なルールは従来の判定・照合処理で確認する
• 不確実な箇所、例外、高リスク案件を人へ渡す
• 人間は最終判断、是正、責任を引き受ける
• 参照情報、判断過程、実行結果を監査できるようにする

医療・行政書類なら、読み取り精度、条件判定精度、修正率、見逃し率、再処理率、監査可能性を測る。監査エージェントなら、AI自身も監査対象にする。どのログを読み、どのポリシーを適用し、どのモデルとプロンプトで判定し、誤検知・見逃しがどの程度だったかを追跡しなければならない。

Human in the Loopは一つの方式ではない

Human in the Loopを「最後に人が承認すること」とだけ理解すると、過剰な承認で速度を失うか、誤った前提を見逃すかのどちらかになりやすい。実務では、処理ごとに三つの方式を使い分ける。

方式	向く処理	設計上の注意
事前承認	高額発注、顧客への正式回答、契約判断	承認者が根拠と影響を確認できるようにする
例外承認	大量の定型書類、既知パターンの処理	信頼度・ルール外・データ欠損の閾値を明確にする
事後監査	可逆で影響が限定的な処理	サンプリング、アラート、取消・復旧を用意する

すべてを事前承認にすれば、人間がボトルネックになる。すべてを自動実行にすれば、誤りの影響が拡大する。影響度、可逆性、金額、安全性、法的責任、誤りの検出可能性によって、自律性を決める必要がある。

さらに重要なのは、最終承認の前段で品質を作ることだ。AIが誤った部品を特定したまま、見積、発注準備、承認依頼まで進めば、承認者は金額だけを見て通してしまうかもしれない。検索根拠、対象条件、計算結果、AIの不確実性を、各段階で確認できるようにする必要がある。

「エージェンティックOS」は、共通の統制基盤として捉える

講演で使われた「エージェンティックOS」は、特定製品の名称というより、複数のエージェントを企業全体で動かすための共通基盤と考えると理解しやすい。

利用者・業務イベント
        ↓
認証・認可
        ↓
エージェント実行・状態管理
        ↓
モデル選択 / ポリシー / ガードレール
        ↓
ツール接続（API・MCP・業務システム）
        ↓
検証・信頼度判定
        ↓
自動実行 / 人間承認 / 停止
        ↓
ログ・トレース・評価・監査

各部門が独自に認証、ログ、ツール接続、権限を実装すると、野良エージェントが増える。共通基盤があれば、現場の開発速度を保ちながら、アイデンティティ、接続、監視、評価の再利用ができる。

ただし、フルスタックのクラウド基盤を採用することが、そのまま最適解になるわけではない。AWSのサービスを使う場合でも、次の境界を確認する。

• モデルやエージェントフレームワークを変更できるか
• MCPやOpenAPIなど、標準的な接続を使えるか
• ログ、評価データ、プロンプト、ツール定義を外部へ取り出せるか
• データとメモリを削除・移行できるか
• 自社のポリシー、監査、ID基盤を適用できるか

可搬性は「対応モデルが多い」だけでは決まらない。認証、メモリ、監視、ワークフローまで含めて、どこに固有依存が生まれるかを把握する必要がある。

PoCから本番へ進むための段階的ロードマップ

多くの企業は、最初から権限付き自律実行を目指す必要はない。価値とリスクを測りながら、次のように進める方が安全である。

第1段階: 支援

AIが情報を探し、要点や候補を提示する。人間が判断し、実行する。まずは根拠の質、検索漏れ、利用者の作業時間を評価する。

第2段階: 下書き

AIが回答、申請、分析、処理案を作る。人間が修正して実行する。修正率と修正理由を集め、どの判断が任せられないかを把握する。

第3段階: 条件付き実行

一定の対象、金額、時間帯、信頼度、ルールを満たす処理だけを実行する。例外は人へ渡す。実行前の権限と、失敗時の停止・取消を設計する。

第4段階: 継続監視

AIがバックグラウンドでイベントやログを監視し、条件に応じて調査、通知、チケット起票を行う。監視漏れ、誤検知、通知疲れ、実行コストを測る。

第5段階: 権限付き自律実行

定義された予算、対象、期間、リスク範囲内でAIが自律実行する。ここでは、権限委譲の根拠、監査証跡、異常検知、取り消し、責任分界が必須になる。

各段階で「次へ進む条件」を決める。試作が動いたことを合格条件にせず、業務品質、運用コスト、権限試験、障害対応、利用者評価を通過条件にするべきである。

本番エージェントは、回答精度だけで評価しない

AIエージェントでは、回答が自然かどうかだけを測っても足りない。評価は少なくとも四つの観点で行う。

観点	代表的な指標
業務成果	処理時間、リードタイム、完了件数、顧客満足度、機会損失の減少
品質	正答率、見逃し率、誤実行率、人間の修正率、再処理率、根拠の正確性
運用	成功率、タイムアウト率、ツール失敗率、平均実行時間、復旧時間
リスクとコスト	権限逸脱、データ漏えい、監査証跡不足、一件当たり費用、人間レビュー費

エージェントが処理した件数だけをKPIにすると、誤処理や不要な自動化を増やす恐れがある。速度と同時に、正しさ、停止可能性、再現性、監査可能性を測るべきである。

まとめ: 価値を生むのは、自律性ではなく「統制された自律性」である

AWSの講演では、個人向けのAIアシスタント、AI開発支援、レガシー刷新、医療書類、システム監査まで、幅広いサービスと事例が紹介された。一見すると製品群の紹介に見えるが、背後には一貫した考え方がある。

AIエージェントを本番で使うには、モデルだけでなく、データ、ツール、実行環境、アイデンティティ、メモリ、オブザーバビリティ、人間の承認を統合しなければならない。

エージェントを作ること自体は以前より簡単になった。SDKを使えば、モデルにツールを呼ばせる試作品を短時間で作れる。しかし、それは本番業務に使えることを意味しない。

企業で必要なのは、次を説明できるエージェントである。

• 誰の権限で動くのか
• 何を実行してよいのか
• どのデータを使ったのか
• なぜその判断・ツール呼び出しを行ったのか
• 不確実なときに誰へ渡すのか
• 失敗時にどう止め、取り消し、復旧するのか
• 後からどう検証し、改善するのか

AIエージェントの価値は、自律性を最大化することではない。業務リスクに応じて、自律性を制御できることにある。

クラウド事業者は実行基盤を提供できる。モデル事業者は推論能力を提供できる。しかし、何をAIへ任せ、何を人に残し、どこで止め、何を成功とするかを決めるのは企業自身である。

AIエージェント導入の競争は、「誰が最も賢いモデルを使うか」という競争から、「誰が最も安全で再現可能な業務システムとしてAIを運用できるか」という競争へ移っている。そこに、IT部門、アーキテクト、業務設計者の最も重要な役割がある。

作成日: 2026年7月23日