はじめに こんにちは。2026年4月にInsight Edge（以下、IE）へデータサイエンティストとして新卒入社した田中です。 本記事を執筆している2026年9月時点で、入社から約5か月が経ちました。新卒データサイエンティスト（DS）の2期生として、新卒研修から最初の案件への参画までを経験する中で、入社前には見えていなかったIEの特徴が少しずつ分かってきました。本記事では、実際に働いて感じたことを新卒の視点からお伝えします。 IEへの新卒入社を検討している学生の方はもちろん、商社グループでデータサイエンティストとして働くことに興味がある方にとっても、本記事が参考になれば幸いです。 目次 1. 自己紹介とIEを知ったきっかけ 1.1 大学での研究 1.2 IEを知ったきっかけ 2. 新卒でInsight Edgeに入社した理由 2.1 幅広い事業領域と少数チームの機動力 2.2 メンターから感じた高い技術力と温かい人柄 2.3 学び続けながら柔軟に働ける環境 3. 入社して初めて分かった3つのこと 3.1 分野横断の研修と早期の案件配属 3.2 オフィスで実感した住友商事との距離の近さ 3.3 案件外の活動を通じた学びと交流 4. まとめ 1. 自己紹介とIEを知ったきっかけ まずは自己紹介として、学生時代のバックグラウンドとIEを知ったきっかけについて紹介します。 1.1 大学での研究 大学時代は、経営工学を専攻しており、さまざまな産業領域のテキスト・表・画像・動画データから知識抽出をすることに焦点を当てた研究分野と、自動運転を中心とする強化学習の応用研究の両方を専門とする研究室に所属していました。当時は25人ほどいた学生のうち6〜7割が留学生で、ミーティングは常に英語で行われる国際色豊かな環境でした。 修士の頃は、産総研との共同研究として、スポーツの試合から収集したプレーデータや映像をもとに、テキスト速報や実況・解説を生成する応用研究に取り組んでいました。 1.2 IEを知ったきっかけ IEを知ったきっかけは、修士1年の夏に受講した大学のデータサイエンス講義です。毎回異なる企業が登壇し、さまざまなデジタル活用事例を紹介する講義でした。ある回にIEの社員が登壇し、そこで初めてIEを知りました。 講義では、IEが住友商事グループ内のDX推進を担っている会社であることが紹介されていました。また、案件としては商社ならではの幅広い産業分野を扱い、その中でPoCからプロダクト開発までを内製の少人数のチームで進めていることも知りました。 講義を通じて、私はIEに次のような魅力を感じました。 さまざまな事業領域に触れられそうで、面白そう 海外案件に関わり、研究室で英語を使ってきた経験も生かせそう 優秀な技術者と働きながら、若いうちから裁量を持って成長できそう いずれも自分の就職活動の軸と合っていたため、講義の最後に案内されたインターンシップへの応募を決めました。 その後、面接を経て、2024年夏の1か月間のインターンシップに参加しました。このインターンシップは、講義だけでは分からなかったIEの詳しい仕事内容や組織体制などを、より深く知る機会になりました。その内容については次の章で詳しく説明していきます。 また、インターンシップで取り組んだ内容は、 こちらの記事 で紹介していますので、興味のある方はぜひこちらもご覧ください。 2. 新卒でInsight Edgeに入社した理由 本章では、インターンシップでの経験を踏まえた、私がIEへの入社を決めた理由について、3つ紹介します。 2.1 幅広い事業領域と少数チームの機動力 IEは住友商事グループの内製的なパートナーとして、コーポレートや、グループ内の事業会社の方々と目標を共有しながらプロジェクトに取り組みます。案件によっては、提示された要件を実装するだけでなく、課題がまだ明確になっていない段階から議論し、PoCや開発、現場での活用まで継続して関わります。IEがデータやAIに関する知見を提供する一方で、クライアントからは業務や事業について学び、双方の知見を持ち寄って解決策を考えられることに、内製パートナーならではの健全な関係性を感じました。 また、住友商事グループには多様な事業会社があり、海外案件を含むさまざまな業界の事業や課題に触れられることも魅力でした。IEは、住友商事グループの幅広い事業基盤をフィールドとしつつ、比較的少人数でのプロジェクトを進めます。新しい技術を積極的に取り入れ、まずは自分たちで検証してみるという姿勢が根付いており、成長環境として理想的だと感じていました。 2.2 メンターから感じた高い技術力と温かい人柄 インターンシップでは、3人の方にメンターとしてご指導いただきました。皆さんが豊富な経験と高い技術力を備えながらも、新しい技術に強い好奇心と探究心を持ち、学んだことを楽しみながら仕事に生かそうとする姿勢を持っていたことが印象に残っています。経験を積んだ後も学び続ける方々と働ける環境は、技術者として成長していくうえで非常に魅力的だと感じました。 加えて、私の話や疑問へ耳を傾け、気さくに応じてくださった姿も印象的でした。入社後に活躍できるか、不安を持つ新卒もいると思いますが、私の場合は、「IEであれば大丈夫」と思えたことも入社を決めた理由の1つです。 2.3 学び続けながら柔軟に働ける環境 働く環境や制度の充実も、IEへの入社を決めた理由の1つです。例えば、業務時間の一部を自己研鑽や勉強会に充てられる制度があります。目の前の案件に必要な知識だけでなく、自分が興味を持った技術を試し、将来の仕事につなげる時間も用意されています。そこに、社員の継続的な成長を大切にする姿勢を感じました。 また、業務内容やチームの状況に応じて、テレワークやサテライトオフィスを利用できる点にも魅力を感じました。私自身は出社派で、対面で働くことから得られるものも大きいと感じています。一方、その日の業務や生活に合わせて働く場所を選べる点は、ライフステージが変化しても働き続けるうえで大きな魅力だと思いました。 IEに入社してから、「いろいろな選択肢があった中で、なぜ新卒でIEに入社したの？」と聞かれることがあります。私にとっては 大企業グループの幅広い事業にパートナーとして関われること 技術力と人間的な魅力を備えた社員の方々と働けること 新しい技術を学びながら柔軟に働けること の3つが、私がIEへの入社を決めた大きな理由でした。以上が本章のまとめです。 3. 入社して初めて分かった3つのこと 夏季インターンシップ後に本選考を経て、内定をいただきました。その後、自ら志願し、修士2年の4月から約6か月間、内定者インターンシップに参加しました。途中で1か月の研究留学を挟みましたが、このインターンシップでは音声対話型マルチエージェントに関する調査に主に取り組みました。この内容に興味がある方は、ぜひ こちらの記事 をご覧ください。 2つのインターンシップを通じてIEへの理解は深まりましたが、それでも、入社して初めて分かったことがいくつかありました。ここからは、新卒研修や最初の案件への参画を通じて特に強く感じたことを、3つに分けて紹介します。 3.1 分野横断の研修と早期の案件配属 研修 入社後の最初の2か月間は、新卒研修として座学とアプリ開発に取り組みました。開発したアプリの詳細は割愛しますが、アプリ開発研修では1つのアプリを企画から開発まで形にしました。参加者は私一人だったため、データサイエンティスト（DS）だけでなく、エンジニア（ENG）やプロジェクトマネージャー（PM）の業務も体験しました。各職種に求められる基礎知識と、プロジェクトにおける役割を学べるように設計された研修でした。 新卒研修で体験したPM・ENG・DSの役割（筆者作成） この研修で特に良いと感じたのは、アプリ開発の進捗に合わせて、その時点で必要となる技術を座学で学べるようなスケジュールが組まれていたことです。座学で得た知識をすぐにアプリ開発で試せるため、知識を学ぶだけで終わらず、実践を通して理解を深めることができました。 この座学研修で学んだ内容を、DS・ENG・PM・その他の分野に分けると、次のようになります。 分野 座学研修で学んだ分野 DS ・データ前処理・後処理 ・時系列分析 ・画像処理 ・統計 ・数理最適化 ENG ・エンジニア心構え ・データベースモデリング ・オブザーバビリティ ・Webを支える技術（TCP/IP） ・ソフトウェアテスト ・AIコーディング ・生成AI概論 ・GitHub/Gitワークフロー ・IaC・CI/CD ・UI/UX ・良い設計・良いコード ・セキュリティ PM ・プロジェクトマネジメント ・開発プロセス その他 ・テクニカルライティング ・スライド作成技術 研修を通じ実感したことは、DSに求められるのは、与えられたデータを分析してモデルを作ることだけではないということでした。IEのプロジェクトでは、エンジニアチーム内のPM・ENG・DSがそれぞれの専門性を持ち寄ります。PMの視点を知ることは、プロジェクトでのヒアリングや課題整理、検証計画について、技術者の立場から意見を出す際に役立ちます。また、ENGの視点を知ることで、PoC後の本番開発を見据えてコードやインフラを整備したり、PMが整理した要件を開発へつなげたりしやすくなります。 生成AIをはじめとするツールによって、技術の調査やコーディングの進め方は変わりつつあります。だからこそ、これからのDSには自分の専門領域だけに閉じない姿勢が必要で、PMやENGの仕事も自分ごととして捉え、プロジェクト全体を前に進める力がより重要になると私は考えています。分野を横断して学ぶこの研修は、私にとって、将来どのようなDSを目指したいかを考えるきっかけを与えてくれました。 案件配属 5月に研修を終え、6月から実際のプロジェクトチームに参画しました。私が配属されたチームは比較的少人数で、新卒の私にも早い段階からタスクを任せていただき、議論の中で意見を求められました。たとえばMVP開発の方針提案を検討する場面では、対象モデルの仕様を調査し、その内容をチームに報告した上で、推奨する活用方針などを提案しました。指示された作業をこなすだけでなく、研修や学生時代に学んだことをプロジェクトに生かし、技術者の一人として自分の考えをチームに伝えることが期待されている点は、入社前の想像以上に印象的でした。 早い段階からタスクを任せていただきながら、一方で分からないことや判断に迷うことがあれば、いつでもメンターに相談できる環境が整っていました。案件への配属後も、案件について相談する機会や、仕事の進め方・今後伸ばしたいスキルについて話す機会が設けられています。 このサポート体制には、現在も大きく助けられています。うまくできた点は評価していただき、改善すべき点は具体的に指摘していただけます。そのため、これまでの経験を振り返り、学びを次にどう生かすかを考える力を日々鍛えることができています。一人の新人にきちんと向き合い、成長を支えてくれる方々がいることは、IEの良さだと感じています。 3.2 オフィスで実感した住友商事との距離の近さ 私は新卒DSの2期生ということもあり、入社前は、IE社内で同世代とのつながりをどの程度持てるのかは、少し気になっていたポイントでした。実際に入社してみると、1つ上の先輩方が優しく接してくださったので安心しました。 また、オフィスの同じフロアには、住友商事の複数のデジタル関連部門が集まっています。そこで働く新卒社員の方々に自分から声をかけ、一緒にランチへ行くなど、会社や部署の枠を越えて交流できました。IE社内に限らず、住友商事グループまで視野を広げて同世代とのつながりを持てることは、入社前には想像していませんでした。 交流の中では、互いの仕事や担当領域について話すこともあります。そうした会話を通じて、住友商事の方々がどのような視点で事業やデジタル活用を捉えているのかを知ることができます。一方で、私から技術的な考え方を伝えることもあり、それぞれの立場や専門性を生かした意見交換ができています。将来同じプロジェクトに関わる際も、こうした日頃の関係が連携のしやすさにつながると感じています。 「住友商事グループと近い距離で働く」という言葉を、入社前は主に仕事上の関係として捉えていました。実際には同じフロアで働き、日常的に会話できる環境があります。そのため、同じグループの仲間として働いていることをより実感できました。 3.3 案件外の活動を通じた学びと交流 IEには、担当案件以外にも、業務時間内の自己研鑽や、社員同士で交流するための活動があります。 私が実際に参加している学習活動には、次のようなものがあります。 勉強会 ：業務時間の10％を目安に自己研鑽へ充てる取り組みがあり、執筆時点では、私は先輩社員と一緒に統計の勉強をしています。疑問点を相談し、考え方を共有しながら学べることに、一人で勉強する場合にはない良さを感じています。 DSチームのLT会 ：DSチームのメンバーが最近学んだ技術や試したことを、短い発表形式で共有する会です。自分の担当案件だけを追っていると触れにくい技術も知ることができ、継続的なキャッチアップの機会になっています。 海外グループとの技術交流会 ：私は有志として、住友商事グループの海外拠点で働く方々と英語で技術情報を交換する会に参加しています。海外での技術活用や異なる考え方に触れられるだけでなく、実際に英語で技術について議論する経験にもなっています。これは将来、海外案件に参加するための良い練習だと感じており、積極的に参加しています。 このように、基礎をじっくり学ぶ機会、新しい技術を社内で共有する機会、海外の方々から異なる視点を得る機会など、案件外でも自分を高める機会がたくさんあります。こんなにたくさん学びの機会があるとは入社前は知りませんでした。 また、技術に関する活動だけでなく、部活動やシャッフルランチなど、社員同士の交流を目的とした取り組みもあります。仕事の性質上、少人数のチームで案件を進め、テレワークも利用できる環境では、担当案件が異なる社員との接点が少なくなることもあります。そのため、こうしたイベントが会話のきっかけとなり、案件や職種を越えて、社内にどのような経験や専門性を持つ人がいるのかを知ることができます。 入社前は、勉強会や社内活動を、それぞれ独立した制度のように捉えていました。しかし実際には、技術を学ぶ場であると同時に、普段は一緒に仕事をしない人とつながる入り口にもなっています。用意された機会を自分から活用することで、学べる範囲も、相談できる相手も国内外へ広げていけることが、入社して分かったIEの特徴の1つです。 4. まとめ 入社前の私は、IEに対して「住友商事グループの幅広い事業に関われる」「優秀な技術者と働ける」「新しい技術に挑戦できる」という印象を持っていました。入社して5か月が経った今、その印象は大きく変わっていません。一方で、実際にIEの一社員として働いたからこそ、それぞれの魅力をより具体的に理解できるようになりました。 分野横断の研修を経て、早い段階から案件に入り、新卒でも一人の技術者として意見を求められること。その一方で、メンターをはじめ、困ったときに相談できる方々がいること。住友商事のデジタル関連部門と同じフロアで働き、会社の枠を越えて日常的に交流できること。そして、案件外にも技術を学び、人とつながるための機会が用意されていること。これらは、入社前には十分に想像できていなかったIEの姿でした。 IEは私にとって、データサイエンスの専門性を深めるだけでなく、他職種やグループ内会社の方々と協力しながら、技術を企業価値につなげる経験を積める環境だと感じています。一方で、こうした環境を生かすためには、自分から学び、周囲に働きかける姿勢も必要です。入社からまだ5か月で、私自身も学ぶことばかりですが、これから1つずつ経験を積んでいきたいと思います。 本記事が、IEへの新卒入社や、商社グループでデータサイエンティストとして働くことに興味を持つ方にとって、少しでも参考になれば幸いです。 Insight Edgeでは、新卒採用に加えてインターンシップの募集も行っています。少しでも興味を持っていただけた方は、ぜひ 新卒採用、インターンシップ募集ページ をご覧ください。

人工知能 (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 .