人工知能 (AI) に投資した 1 ドルごとに 2 ドルのリターンが得られるのであれば、コストの増加は非効率ではなく、プラスの投資収益率 (ROI) を示すことになります。しかし、AI 支出とビジネス価値の関係を明らかにすることは複雑で難しく、取り組みを拡大すべき時期や見直すべき時期を判断するための明確な指標を得られないことがあります。ROI を算出するには (図 1 を参照)、まずコストを配分し、次に、そのコストが貢献するビジネス成果と対応付けます。これにより、ROI の基礎的な構成要素である成果当たりコスト (Cost per Outcome) を求められます。各成果にかかるコストを測定できるようになれば、そのコストと成果がもたらす価値を比較するだけで ROI を算出できます。 本記事では、AI への投資をビジネスインパクトと結び付けるための実践的な方法論を概説します。ユースケースを分類し、コストを紐付け、測定可能な価値を生み出している取り組みを特定する方法について詳しく解説します。 図 1：ROI の算出プロセス AI ユースケースを分類する AI ユースケースの価値を評価する前に、まず自社で導入している AI がどのように使用されているかを把握し、それぞれの用途が分かるような名称を付けて分類しておく必要があります。この評価で使用する 2 つのカテゴリは、「内部向け」と「外部向け」です。 外部向け 外部向け AI は、収益を生み出す活動に直接対応付ける必要があります。そうすることで、その AI のコストを売上原価の一部として計上できます。外部向け AI が収益活動とどう結び付くかを理解するために、まずは自社の収益を生み出しているものは何かを考えてみてください。そのうえで、それらに対して AI が直接的または間接的にどのように貢献しているかを確認します。 内部向け 内部向け AI は、一般的に開発者の生産性向上 (コーディングアシスタント、ワークフローの自動化) や、より広範な従業員の業務効率化を支援します。また、ビジネス活動の強化、自動化、効率化を実現します。内部向け AI の ROI への紐付けは、外部向け AI より難しい場合があります。こうしたデプロイは、収益を生み出す活動に直接結び付かないことが多いためです。この課題は AI に固有のものではなく、業務生産性向上へのあらゆる投資に共通します。リターンを測定するには、後述の「ビジネス価値指標を決定する」セクションで説明する、定量化可能な成果に焦点を当ててください。 これらのユースケースでは、構造化された利用と構造化されていない利用も区別する必要があります。構造化された利用とは、明確な目標、具体的な KPI、予測可能な実行パターンを備えたエージェントの利用を指します。たとえば、顧客の注文履歴に関する質問に回答するために構築されたアシスタントが該当します。構造化された利用は、構造化されていない利用よりもコストを配分しやすくなります。一方、構造化されていない利用とは、コーディングアシスタントやチャットインターフェイスのような、アドホックで汎用的なやり取りを指し、エージェントの振る舞いが特定の用途に限定されず、柔軟に拡張できます。構造化されていない利用は開発者の生産性を大きく向上させますが、ビジネス価値指標と対応付けるには、さらに詳細なコスト配分が必要になる場合があります。この違いを認識しておくことが、より正確なコスト配分につながります。 コストを算出する AI コストの増加は、AI 投資の ROI を判断するための重要なきっかけになります。コストは、誤った対象に配分されたり、過少に見積もられたりすることがあります。コストを判断する際の最初の要素は、総所有コスト (Total Cost of Ownership：TCO) が算出できているかを確認することです。 AI の TCO を把握するには、まず  Amazon Bedrock 、 Claude Platform on AWS 、 Kiro  などのマネージド AI サービスの直接コストを算出します。組織が独自にインフラストラクチャを管理している場合は、 Amazon Elastic Compute Cloud (Amazon EC2) 高速コンピューティングインスタンス および  Amazon SageMaker AI  のコストも算出する必要があります。 直接コストを定量化したら、次に間接コストおよび関連コストを算出します。これらのコストは通常、次の 4 つのカテゴリに分類されます。 ストレージ – AI のトレーニングには、大量のデータが必要になる場合があります。ストレージコストとデータ取得コストの両方が含まれていることを確認してください。また、AI 推論では、 検索拡張生成 (RAG)  や参照データを利用する場合があります。これらは ベクトルデータベース のコストとして計上され、場合によっては AI 推論の規模に比例して高額になることがあります。 データ転送 – AI ソリューションでデータの読み書きが必要な場合、その情報が境界 (AZ やリージョン等) を越えて移動し、データ転送トラフィックが発生することがあります。また、AI システムによっては、追加のサービスや外部システムとの通信が必要になることもあります。こうしたデータフローによって、データ転送コストが発生する場合があります。 モニタリングとレポート – AI の利用状況を把握して追跡するには、ログや利用状況データを生成することが重要です。これらのデータは、ダッシュボードやレポートシステムで報告・分析する必要があるかもしれません。モニタリング、データ、およびダッシュボードユーザーのライセンスにかかる費用を、AI ソリューションの総コストに含める必要があります。 エージェンティック AI  – エージェンティック AI システムは、目標を達成するために意思決定を行い、タスクを実行します。目標を達成するために、 AWS Lambda  関数や  Amazon API Gateway  を使用して、追加のサービスまたは外部システムと連携する場合があります。エージェンティック AI のコストは、AI ユースケースによって大きく変動する可能性があります。 詳細なコスト配分 可視化とコスト配分によって、AI コストをビジネス価値に結び付けることができます。詳細な帰属情報がなければ、AI 支出は単一の明細項目として表示されるため、どのチーム、アプリケーション、ユースケースがコストを発生させているのかを特定できません。Amazon Bedrock では、アプリケーションが使用する API エンドポイントに応じて、複数のコスト帰属メカニズムを利用できます。 bedrock-runtime IAM プリンシパルベースのコスト配分 – API 呼び出しごとに呼び出し元の ID を自動的に記録します リクエストレベルメタデータ – 個々の推論呼び出しにキーと値のペアでタグを付け、その情報をモデル呼び出しログに記録します アプリケーション推論プロファイル – 特定モデル用の ARN を作成し、bedrock-runtime 呼び出し時にモデル ID の代わりに渡すことができます bedrock-mantle Projects – OpenAI 互換の Responses API および Chat Completions API で使用します Workspaces – Anthropic 互換の Messages API で使用します これらのメカニズムでは、コストデータが表示される場所が異なります。IAM プリンシパル、アプリケーション推論プロファイル、Projects、Workspaces はいずれも、 AWS Cost Explorer および AWS Cost and Usage Reports (CUR) に表示される集約されたコスト配分データを生成します。そのため、財務部門主導のチャージバックとショーバックに適しています。これに対して、リクエストレベルメタデータは、プロンプトごとのトークン数を、コストデータではなくモデル呼び出しログに記録します。どのアプローチを選択するかを判断するうえで、この違いは重要です。財務チーム向けの請求データに基づくレポートが目的であれば、コスト配分をサポートする方法を使用してください。エンジニアリング最適化のためにリクエスト単位の詳細情報が必要な場合は、リクエストレベルメタデータも有効にするとよいでしょう。 これらのアプローチは競合するものではなく、相互に補完するものです。一般的には、IAM プリンシパルベースのコスト帰属を有効にして、常時かつ自動的に ID を追跡します (コードの変更は必要ありません)。集約されたコストの配分には Projects / Workspaces、またはアプリケーション推論プロファイルを使用し、必要に応じて、プロンプト単位の詳細を把握するためにリクエストレベルメタデータを使用します。まずは、当面のニーズに対応するメカニズムからはじめ、コスト帰属に関する要件が成熟するにつれて、追加の方法を組み合わせてください。目標は、AI 支出を、ビジネス価値を生み出しているユースケース、チーム、またはアプリケーションに帰属させることです。これが、次のセクションで成果当たりコストを算出するための基盤になります。 ビジネス価値指標を決定する ビジネス価値指標とは、ビジネスの健全性や収益性を判断するのに役立つ指標です。ビジネス指標を設定する際、最初に確認すべきことは、その指標が測定可能であることです。また、そのビジネス指標を恣意的に操作できないことも重要です。 グッドハートの法則 (Goodhart’s Law)：「指標が目標になると、それは良い指標ではなくなる。」 たとえば、「開発者が作成したコード行数」を指標に選んだ場合、開発者は AI にコード内のドキュメント行を追加するよう簡単に指示できるため、この指標を水増しできます。代わりに、AI 投資による成果がビジネス価値と整合していることを確認する必要があります。前述の開発者の例で言えば、ソフトウェア開発を支援するためにリリースした機能の数や、修正したバグの数などが考えられます。 ビジネス価値指標は、次の 3 つのカテゴリに分類できます。 事業およびプロダクト収益： AI ソリューションに直接結び付く売上高レベルの財務リターンを測定します。 指標の例： 製品売上、サブスクリプション、回避したリスクや不正、請求済みクレジット 課題： 売上高は、営業活動の遂行、マーケティング支出、競争環境など、AI 以外の変数に大きく影響されるため、直接的な帰属は困難です。AI は売上原価を構成する一要素になります。 開発指標： 収益を支える開発の進行速度と運用上の成果を追跡します。 指標の例： デプロイ頻度、提供した機能、解決したバグ 課題： 成果を正規化する必要があります。ストーリーポイント、機能、修正は、その複雑さ、対象範囲、実際のビジネスインパクトが大きく異なります。 収益支援指標： 収益を間接的に支える、後続のエンゲージメント指標およびコンバージョン指標を測定します。 指標の例： 広告表示回数、クリックスルー率、リテンション率、信頼度および満足度スコア 課題： 直接収益と同様に、これらの指標は外部からの影響や AI 以外の要因 (ユーザーエクスペリエンスの更新やプロモーションキャンペーンなど) の影響を受けやすくなります。 指標を定義したら、AI 導入前のベースラインを確立し、AI の導入状況と併せて指標の推移を追跡します。この指標を定期的に、また大きな変更が発生するたびに再評価してください。 ROI を算出する 上記の前提条件を定義したら、ROI の定量化に役立つ成果当たりコストの算出を開始できます。 成果当たりコスト = AI コスト / ビジネス価値指標 開発者の生産性を例に、ビジネス価値指標として修正したソフトウェアバグの数を使用すると、次のような分析を実施できます。 注：この例では、開発者にかかるコストは、分析期間を通じて変動しない固定費であると仮定しています。AI を使用して開発者の能力を拡張している場合は、開発者コストが AI の利用状況に応じて変動するため、そのコストを総コストに含める必要があります。また、この例では、価値が直ちに得られるものと仮定しています。多くの場合、AI を導入してからビジネス価値指標に影響が現れるまでには、立ち上がり期間があります。 この例では、週 5 件のバグ修正をベースラインとします。開発者に AI を提供した後、最初の成果当たりコストの測定は、たとえば次のようになります。 週 15 件のバグ修正、AI の総コストは $5,000。新たに修正できた 10 件 (15 件 – ベースラインの 5 件) は AI による成果であるため、計算は次のようになります。 バグ修正 1 件当たり $500 = $5,000 / 10 件のバグ修正 この指標は、AI 投資の現在および将来の価値を判断するための出発点です。AI を使用してバグを 1 件修正するごとに $500 かかることが分かります。 さらに数週間にわたって測定すると、次の 2 つの値の変化を観察できます。 1. ビジネス価値指標： 開発者の効率が向上すれば、修正するバグの数は増加します。一方、解決するバグが複雑になった場合 (または、修正対象のバグが少なくなった場合) には、修正数は減少します。コストが一定であると仮定すると、次のようになります。 バグの修正件数が増加する場合：成果当たりコストは減少します。AI 投資からより高い効率が得られていることになります。 バグの修正件数が減少する場合：成果当たりコストは増加します。AI 投資から得られる効率は低くなっていることになります。 成果当たりコストが増加したからといって、必ずしも ROI が低下していることを意味するわけではありません。重要なのは、修正されたバグの重要度を評価し、AI がより複雑なバグの解決を可能にしているのかどうかを見極めることです。高度な ROI 分析では、バグの複雑さなどの追加のビジネス価値指標を取り入れ、バグ修正に AI を活用することがより良いユーザーエクスペリエンスにつながっているかを判断します。 2. コスト： 開発者が AI を使用して修正するバグの数が変わったり、含めるコンテキストが変動したり、トークンコストの異なる新しいプロバイダーやモデルを使用したりすることで、AI コストは変動する可能性があります。 コストが増加する場合：成果当たりコストは増加します。AI 投資から得られる効率は低くなっていることになります。 コストが減少する場合：成果当たりコストは減少します。AI 投資からより高い効率が得られていることになります。 上記の例は、各変数が成果当たりコストに与える影響を示すために簡略化しています。実際には、モデルの変更、利用パターンの変化、作業自体の複雑さの増減に伴い、分子 (コスト) と分母 (ビジネス価値) の両方が時間の経過とともに変化します。成果当たりコストそのものは ROI ではありません。ROI を判断するための単位レベルの基礎的な構成要素です。 成果 1 件当たりにかかるコストを把握したら、その金額を、その成果が支える事業およびプロダクト収益の項目に関連付けます。この例では、修正したバグは、顧客に販売される製品またはサブスクリプションに関連するかもしれません。これらの追加コストは、純利益および ROI の計算における売上原価の一部になります。 成果当たりコストを定期的に追跡することで、ROI への影響を評価して、効果のある取り組みを拡大し、効果のない取り組みは方向転換し、支出が価値を上回るタイミングを把握するためのデータを得ることができます。この方法に従うことで、ROI を一度限りの見積もりではなく、再現可能で根拠のある指標として算出できます。 まとめ AI の ROI を算出することは、「AI によって生み出された成果 1 件当たりのコストはいくらで、その成果には自社のビジネスにとってどれくらいの価値があるのか」という問いに答えるものです。 成果当たりコストの計算がその基盤となります。それを、その成果が支える事業収益と関連付けることで、ROI を算出できます。ただし、この計算だけを AI 戦略の判断材料にすべきではありません。イノベーションには、実験の余地が必要です。一部の取り組みでは短期的な ROI が低く見えても、長期的なリターンや競争優位性によって、新たな収益源を生み出せる可能性があります。ROI を使用してエージェンティックワークロードを可視化し、しきい値を設定し、継続または中止を判断してください。その一方で、まだ標準的な指標に適合しない、高いポテンシャルを持つプロジェクトを育てる柔軟性も維持してください。 まず、上記で説明したコスト配分メカニズムを使用して、主要な 3 つの AI ワークロードにタグを付けます。それぞれについてビジネス価値指標を 1 つ特定し、今四半期中に最初の成果当たりコストを算出してください。事後対応型のコスト追跡から、先を見越した価値管理へとシフトすることで、AI を単なる明細項目から、ビジネスを推進する戦略的なエンジンへと変革できます。 翻訳はテクニカルアカウントマネージャーの西村が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS の Senior Optimization Solutions Architect であり、AI コストの最適化、tokenomics 戦略、AI 向け FinOps を専門としています。Amazon Q などのお客様向け機能の策定に携わり、AWS re:Invent、FinOps X、業界ウェビナーなどで定期的に登壇しています。Adam は、FinOps Foundation AI Working Group で AWS を代表し、AI ワークロードにおける tokenomics と財務オペレーションに関する広範な議論に貢献しています。

キャッチ。 伊藤さん、バトンを受け取りました。 冷房の効いた室内と近年とりわけ気候変動によって過熱している屋外とで、寒暖差の激しい日々が続いておりますが、いかがお過ごしでしょうか。 ノーコードテストツールのバトンは画鋲付きで渡した気分でした。 しかし、誠実に答えてくださり、ありがとうございました。 テスト自動化は運用が大切、というのは私自身、伊藤さんから繰り返し学んでいたことでしたね。 そして、ノーコードかコードベースかといった軸とは全く違うパラダイムの進化というのは大変示唆的です。 そもそも生成AIの多くは、LLMにチャットというインターフェースを使って接続するものです。チャットを組み込んだことはLLMにおける大きなUXの発明です。 しかし、これは今では当たり前になり、誰もそのことを意識しないようになってしまいました。これもパラダイムの進化だと思っています。 それでは、受け取ったバトンを見てみます。 非常に鋭く、かつ本質的な問いがありますね。 伊藤さんからいただいた「テスト自動化は本当に『当たり前』になったのか」「なぜ冷静な視点が必要なのか」という2つの問いについて、私の視点からお答えしつつ、これからの自動テストが向かうべき新たなパラダイムについて考えてみたいと思います。 「当たり前」の現在地 伊藤さんからの最初の問いである「幅広いコミュニティから見て、テスト自動化は本当に当たり前になったのか」について。 私の実感としても、テスト自動化が前提の技術として扱われる機会は確実に増えていると感じます。 プログラミングやアジャイルの文脈を問わず、様々なカンファレンスで自動テストに関するセッションはありますし、「今だからこそ、確かなテストや品質保証が大事である」という共通認識は、かつてないほど高まっていると感じます。 そういった背景もあって、私が「QAエンジニア」あるいは「テスター」という肩書きのまま、受け入れられているという側面があります。 こういった、テストの専門性を受け入れるような”暖かい”雰囲気がある一方、冷静に見極めなければならない「ズレ」があるとも考えます。 世間で当たり前になりつつあるのは、あくまで「どうテスト実行を自動化するのか」に留まっているケースが多いのではないか、ということです。 プロダクトの特性やコンテキストを分析し、合理的なテスト計画と設計に基づき、真に必要な活動を「自動テスト」として成熟しているかというと、そこにはまだ大きな隔たりがあるという肌感覚があります。 (これに対しては、いわゆる”テストエンジニア”による歩み寄りが必要で、その歩み寄り方自体についてもきちんと向き合って考えるべきことだと個人的に思っていますが、ここでは深入りしません) 伊藤さんが指摘された「生成AIという次のブームに押し出されて、自動化の流行りが落ち着いた（ように見える）」という視点は的を射ていると感じます。 これは私自身にも言えることですが、私たちは「知ったつもり」になるのをやめ、その当たり前の中身を問い直さなければなりません。 なぜ「冷静な視点」が必要なのか 私は手動テストの設計時のような「冷静な視点」が必要だと伝えました。そのまま返ってきましたね。 現在、生成AIの台頭によってプロダクトコードが大量かつ高速に生み出されるようになりました。 これに伴い、現場では「開発スピードに合わせて、テストも急いで大量に作らなければならない」という焦燥感のようなプレッシャーが生まれているように感じることがあります。 他方、プレッシャーとは逆の視点で、「難しいコードを書かなくても実装できるぞ！」という熱を垣間見ることもあります。 以前、テストマネジメントの記事でも述べたことですが、私は「コストや期間の制約を考えれば、テストは極力すべきではない（最小限に抑えるべきである）」というのを基本的なスタンスとしています。 むやみにテストを自動化し、ただコードの量を積み上げることは、それこそ運用の破綻を招くだけだと考えます。 ここで問われているのは、大量生産への追随ではなく、「何をテストすべきで、何をテストしなくてよいのか」を見極める、本質的なテストマネジメントの力に他ならないと考えています。 これはプロダクトコードにおけるプロダクトマネジメントの考え方にも通じるものがあります。 生成AIを発端とする熱狂や過剰な期待にただ熱くなるのではなく、事実に基づいてソフトウェアテストの責任をどう果たすか。 これが私の考える「冷静な視点」です。 生成AIがもたらすリアルな制約 ここで、現状の生成AIを使ったテストの「リアル」についても触れておきます。 今後、テスト自動化の現場は「コードを書く」ことから「プロンプトを書く」ことへとシフトしていく可能性が高いです。実際に、BDD（振る舞い駆動開発）のようなプラクティスも再び注目を集めています。 しかし、現状の生成AIを組み込んだテスト運用には、実行時間の制約や、スケールさせた際の予算的な制約が存在します。 その他、並列処理のための最適化などの自動テスト実行環境を綿密に整備しないかぎり、AIによるテストの量産は現実的な運用に乗せられないというのが2026年7月の私の見解です。 ただし、この予算やリソースの制約をクリアした先、あるいは「価値がある」と計算し切れた先には、全く新しい展望があると考えています。 制約を乗り越えた先にあるgTAAの気候変動 その展望とは、組織が集めたプロファイルや顧客データなどに基づいて、品質特性の質感（代用特性としての確らしさ）、つまり「品質が良さそうだ」と判断する根拠に対する感覚が今とは全く異なったものになることです。 ※この意見はスクラムフェス新潟2026のきょんさん、nacoさん、じゅんぺいさんの以下の発表とその後の対話から、私なりに受け取り、解釈したものです。 そして、自動テストの文脈で言えば、JSTQBのテスト自動化エンジニアシラバスで定義されている「gTAA（汎用テスト自動化アーキテクチャ）におけるテスト生成レイヤー」の構築がより簡単になると考えます。 参考： https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf これは、gTAAにおける水平レイヤーそれぞれで生成AIを使ったパイプラインを使用し、例えばテスト生成レイヤーの出力をそのレイヤーの中で検証し、それぞれのレイヤーで確からしく実装まで繋がっていく様子をシームレスに確認できるような、発展した形の汎用テスト自動化アーキテクチャです。 そして、生成AIが当然に用いられるプロダクト開発において、「決定論的に見極められる事実を確認する」という意味でテストが重要視されるでしょう。 ※これは冒頭で話した「今だからこそ、確かなテストや品質保証が大事である」の単なる言い換えでしかありません。 「生成AIを活用する」という目的で作るTAAは、「手動テストをただ単に自動化する」という、かつてのテスト自動化の熱狂と同じ構造を持っているのではないでしょうか。 もちろん、それが学習の途中で辿る道であり、私もその中にいることすらあると思っています。 テストが持つ本質的な役割を理解した上で、それをどう生成AIと統合していくかということが、今後の”冷静な”論点になりうると考えています。 そして、その論点を踏まえた上で、自動テストは新しいパラダイムでの「TAA（テスト自動化アーキテクチャ）」を語る熱量が上昇するのではないか、と考えています。 伊藤さんへのバトン 単にテストを自動化する・コードを生成するという次元を超えて、システムや組織のデータそのものをインプットとした「TAAの再定義」という変化が来ているという私の見通しがあります。 ここで、MagicPodのエヴァンジェリストであり、ISTQB Advanced Level Test Automation Engineerの翻訳者のひとりである伊藤さんに、ぜひ最後のバトンをお渡ししたいです。 生成AIが前提の開発において、自動テストアーキテクチャ（TAA）にはどのような変化があるのでしょうか？ そういった状況の中で、テストエンジニアは、ソフトウェアエンジニアリングの世界にどのような良い影響を与えうると見通されていますか？ 私の上記の見解もまた、冷静ではなかったりしますかね？ ←これには答えなくていいです。 一人の専門家としての見解を、ぜひお聞かせください。 The post 【第3回】E2Eテスト自動化でつなぐ③〜テスト自動化における寒暖差〜｜専門家2人による往復書簡 first appeared on Sqripts .

こんにちは！セーフィーでQAエンジニアをしている福山です。 「シフトレフト」という言葉を本気で実践しようとしたとき、私は思わぬ落とし穴にハマりました。 それは、上流工程に出ていくほど 「品質の言葉」だけでは仲間になれず、むしろ“後から検証しに来るブレーキ役”に見えてしまう ことがある、ということです。 この記事では、一般社団法人UXインテリジェンス協会が提供するUX検定の学習を通じてデザイナーとの「共通言語」を少しずつ獲得し、上流での対話が回り始めた経験を共有します。 🎯 この記事は以下のような方に向けた内容です シフトレフト推進で、他部署との対話が噛み合わないと感じるQAエンジニ