re:Invent 2025 において、AWS の Vice President of Databases である Colin Lazier は、アイデアのスピードで構築することの重要性を強調しました。これは、コンセプトから稼働中のアプリケーションまでの道のりを迅速に進めることを可能にするものです。お客様は既に、本番対応の Amazon DynamoDB テーブルと Amazon Aurora DSQL データベースを数秒で作成できます。Colin は、同じスピードで Amazon Aurora サーバーレス データベースを作成できることを 事前公開 し、その後、お客様からこの機能への迅速なアクセスとスピードを求める声が寄せられました。 2025 年 3 月 25 日、Amazon Aurora PostgreSQL 向けの新しいエクスプレス設定の一般提供の開始をお知らせします。これは、数秒で使用を開始するのに役立つよう設計された事前設定済みのデフォルト設定を備えた、合理化されたデータベース作成エクスペリエンスです。 わずか 2 回クリックするだけで、Aurora PostgreSQL サーバーレスデータベースを使用する準備が数秒で整います。新しい設定では、データベースの作成中および作成後に、特定の設定を柔軟に変更できます。例えば、作成時にサーバーレスインスタンスのキャパシティ範囲を変更したり、リードレプリカを追加したり、データベースが作成された後にパラメータグループを変更したりできます。 エクスプレス設定を備えた Aurora クラスターは、 Amazon Virtual Private Cloud (Amazon VPC) ネットワークなしで作成され、お気に入りの開発ツールからのセキュアな接続のためのインターネットアクセスゲートウェイを含みます。VPN や AWS Direct Connect は不要です。また、エクスプレス設定では、管理者ユーザーのために AWS Identity and Access Management (IAM) 認証がデフォルトでセットアップされるため、追加設定なしで最初からパスワードレスデータベース認証が有効になります。 作成後、高可用性や自動フェイルオーバー機能のための追加のリードレプリカのデプロイなど、Aurora PostgreSQL サーバーレスで使用可能な機能にアクセスできます。今回のリリースでは、Aurora 向けの新しいインターネットアクセスゲートウェイルーティングレイヤーも導入されました。新しいサーバーレスインスタンスでは、この機能はデフォルトで有効になっています。これにより、幅広い開発ツールから PostgreSQL ワイヤプロトコルを使用して、世界中のどこからでも、アプリケーションがインターネット経由でセキュアに接続できます。このゲートウェイは複数のアベイラビリティゾーンに分散されており、Aurora クラスターと同等の高可用性を提供します。 Aurora の作成と接続が数秒で完了するということは、Aurora の利用を開始する方法は根本的に変わります。弊社は、Aurora を利用したアプリケーションのオンボーディングと実行をサポートするために、連携して動作する複数の機能をリリースしました。Aurora は AWS 無料利用枠 で現在利用可能です。これにより、初期費用なしで Aurora を実際に体験できます。作成後、 AWS CloudShell で Aurora データベースを直接クエリしたり、Aurora 用の新しいインターネットアクセス可能なルーティングコンポーネントを介してプログラミング言語やデベロッパーツールを使用したりできます。 Vercel の v0 などの統合により、自然言語を使用して、Aurora の機能とメリットを活用したアプリケーションの構築を開始できます。 Aurora PostgreSQL サーバーレスデータベースを数秒で作成 利用を開始するには、 Aurora および RDS コンソール にアクセスし、ナビゲーションペインで [ダッシュボード] を選択します。その後、ロケットアイコンの付いた [作成] を選択します。 [エクスプレス設定で作成] ダイアログボックスで、事前構成済みの設定を確認します。必要に応じて、DB クラスター識別子またはキャパシティ範囲を変更できます。 [データベースを作成] を選択します。 また、パラメータ --express-configuration を設定して AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用することで、単一の API コールでクラスターとクラスター内のインスタンスの両方を作成できます。これにより、数秒でクエリを実行できる状態になります。詳細については、「 Creating an Aurora PostgreSQL DB cluster with express configuration 」にアクセスしてください。 クラスターを作成するための CLI コマンドを次に示します: $ aws rds create-db-cluster --db-cluster-identifier channy-express-db \ --engine aurora-postgresql \ –with-express-configuration Aurora PostgreSQL サーバーレスデータベースは数秒で準備完了となります。作成が完了すると成功バナーが表示され、データベースのステータスが [使用可能] に変わります。 データベースの準備が完了したら、 [接続とセキュリティ] タブに移動して、3 つの接続オプションにアクセスします。SDK、API、またはエージェントなどのサードパーティーツール経由で接続する場合は、 [コードスニペット] を選択します。.NET、Golang、JDBC、Node.js、PHP、PSQL、Python、TypeScript など、さまざまなプログラミング言語を選択できます。各ステップのコードをツールに貼り付けてコマンドを実行できます。 例えば、次の Python コードは認証設定を反映するために動的に生成されます: import psycopg2 import boto3 auth_token = boto3.client('rds', region_name='ap-south-1').generate_db_auth_token(DBHostname='channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', Port=5432, DBUsername='postgres', Region='ap-south-1') conn = None try: conn = psycopg2.connect( host='channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port=5432, database='postgres', user='postgres', password=auth_token, sslmode='require' ) cur = conn.cursor() cur.execute('SELECT version();') print(cur.fetchone()[0]) cur.close() except Exception as e: print(f"Database error: {e}") raise finally: if conn: conn.close() const { Client } = require('pg'); const AWS = require('aws-sdk'); AWS.config.update({ region: 'ap-south-1' }); async function main() { let password = ''; const signer = new AWS.RDS.Signer({ region: 'ap-south-1', hostname: 'channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port: 5432, username: 'postgres' }); password = signer.getAuthToken({}); const client = new Client({ host: 'channy-express-db-instance-1.abcdef.ap-south-1.rds.amazonaws.com', port: 5432, database: 'postgres', user: 'postgres', password, ssl: { rejectUnauthorized: false } }); try { await client.connect(); const res = await client.query('SELECT version()'); console.log(res.rows[0].version); } catch (error) { console.error('Database error:', error); throw error; } finally { await client.end(); } } main().catch(console.error); コンソールから直接起動する AWS CLI に迅速にアクセスするには、 [CloudShell] を選択します。[ CloudShell を起動] を選択すると、特定のクラスターに接続するための関連情報がコマンドに事前に入力されていることが確認できます。シェルに接続すると、SQL コマンドを実行するための psql login と postgres => prompt が表示されます。 pgAdmin など、ユーザー名とパスワードの認証情報のみをサポートするツールを使用する場合は、 [エンドポイント] を選択することもできます。 [トークンを取得] を選択すると、ユーティリティによって生成された AWS Identity and Access Management (IAM) 認証トークンがパスワードフィールドに使用されます。このトークンは、データベースの作成時にセットアップするマスターユーザー名について生成されます。トークンは 1 回につき 15 分間有効です。使用しているツールが接続を終了した場合、トークンを再生成する必要があります。 Aurora データベースを利用してアプリケーションをより迅速に構築 re:Invent 2025 では、 AWS 無料利用枠プログラムの強化を発表し 、AWS サービス全体で使用できる最大 200 USD 相当の AWS クレジットを提供しました。サインアップ時に 100 USD 相当の AWS クレジットが付与され、Amazon Relational Database Service (Amazon RDS)、AWS Lambda、Amazon Bedrock などのサービスを利用することで、さらに 100 USD 相当のクレジットを獲得できます。さらに、Amazon Aurora は、対象となる一連の幅広い 無料利用枠データベースサービス でご利用いただけるようになりました。 デベロッパーは、自然言語だけで本番対応のアプリケーションを構築できる Vercel などのプラットフォームを採用しています。弊社は、 Vercel Marketplace との統合を発表しました 。これにより、Vercel から AWS データベースを数秒で直接作成して接続できるようになります。また、AI を利用したツールである Vercel の v0 との統合も発表しました。v0 は、数分でアイデアを本番対応のフルスタックウェブアプリケーションに変換します。これには、Aurora PostgreSQL、Aurora DSQL、DynamoDB データベースが含まれています。また、Vercel を利用してエクスプレス設定を通じて作成した既存のデータベースも接続できます。詳細については、「 AWS for Vercel 」にアクセスしてください。 Vercel と同様に、当社はデータベースをそれらのエクスペリエンスとシームレスに統合し、広く普及しているフレームワーク、AI アシスタントコーディングツール、環境、デベロッパーツールと直接統合して、アイデアのスピードで開発を進めることを可能にしています。 さらに、 Kiro powers との Aurora PostgreSQL 統合 も導入しました。デベロッパーはこれを利用して、 Kiro を通じた AI エージェント支援開発を活用することで、Aurora PostgreSQL を利用するアプリケーションをより迅速に構築できます。Aurora PostgreSQL 向けの Kiro power は、 Kiro IDE 内で、または Kiro powers のウェブページ から、ワンクリックでインストールして使用できます。この Kiro Power の詳細については、「 Introducing Amazon Aurora powers for Kiro 」および「 Amazon Aurora Postgres MCP Server 」をお読みください。 今すぐご利用いただけます Aurora PostgreSQL サーバーレスデータベースは、すべての AWS 商用リージョンで数秒で今すぐ作成できます。リージョンごとの利用可否と今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。 お支払いいただくのは、Aurora Capacity Units (ACU) に基づいて消費したキャパシティについての料金のみであり、キャパシティがゼロの状態から秒単位で課金されます。アプリケーションのニーズに基づいて、キャパシティが自動的に起動、シャットダウン、スケールアップ、スケールダウンされます。詳細については、 Amazon Aurora の料金ページ にアクセスしてください。 Aurora および RDS コンソール でお試しいただき、 AWS re:Post for Aurora PostgreSQL に、または通常の AWS サポート担当者を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

はじめに Webアプリケーションの回帰テストを自動化する際、適切なツールの選択は品質保証とチームの生産性に大きく影響します。 プロジェクト背景 KINTOテクノロジーズ（以下、KTC）では、これまでAutify NoCodeWebを活用して回帰テストの自動化を進め、品質保証体制を構築してきました。Autify NoCodeWebのノーコードプラットフォームは、QA専任メンバーが中心となってテスト自動化を迅速に導入する上で非常に有効であり、多くの成果を上げてきました。 しかし、プロジェクトの成長に伴い、新たな課題も見えてきました: より高速なテスト実行が求められるようになった CSVファイルの編集・アップロードなど、複雑なファイル操作を伴うテストシナリオの増加 データ駆動テストによる大量のテストパターンの実行ニーズ エンジニアチームの拡大により、コードベースのテスト資産の管理が可能になった このような背景から、現在のKTCの体制と要件に最適なツールを再検討する必要が生じました。本記事では、これまでお世話になってきたAutify NoCodeWebと、新たな選択肢としてのPlaywrightを、実際の回帰テストシナリオにおいて詳細に比較します。 どちらのツールも優れた特徴を持っており、組織の状況によって最適な選択は異なります。本記事が、皆様のツール選定の一助となれば幸いです。 ツール概要 Playwright 開発元: Microsoft タイプ: オープンソースのE2Eテストフレームワーク 対応言語: JavaScript/TypeScript、Python、.NET、Java 対応ブラウザ: PC：Chromium（Chrome、Edge）、Firefox、WebKit（Safari相当） モバイル：デバイスエミュレーション（Chromium、WebKit） 　※実機のモバイルブラウザ操作は非対応 特徴: コードベースで柔軟性が高く、高速な実行速度 Autify NoCodeWeb 開発元: オーティファイ株式会社（日本企業） タイプ: ノーコードAI搭載テスト自動化プラットフォーム 対応ブラウザ: PC：Chrome、Edge、Firefox、Safari（WebKit） モバイル：iOS、Android 特徴: 操作をレコーディングしてテストシナリオを作成、AI による要素認識と自動修復機能 ツール選択のためのデシジョンフローチャート 自社に最適なツールを選ぶ際の判断フローを視覚化しました。このフローチャートを参考に、組織の状況に応じた選択を行ってください。 graph TD Start[QAチームにプログラミング可能なエンジニアがいる] Start -->|No| AutifyNoCodeWeb1[Autify NoCodeWeb: ノーコードで容易、迅速な導入、AI自動修復] Start -->|Yes| Speed{実行速度を重視?} Speed -->|Yes| Playwright1[Playwright: 高速、柔軟、無料] Speed -->|No| Requirements{要件に応じて選択} Requirements -->|インフラ管理は避けたい| AutifyNoCodeWeb2[Autify NoCodeWeb] Requirements -->|メール連携や頻繁なUI変更がある| AutifyNoCodeWeb2 Requirements -->|コストを優先したい| Playwright2[Playwright] Requirements -->|データ駆動テストや複雑なファイル操作がある| Playwright2 フローチャートの使い方 このデシジョンフローは、以下の優先順位で判断することを推奨しています： チーム構成の確認: まず、開発チームにプログラミング可能なエンジニアがいるかを確認します。エンジニアリソースが限られている場合は、Autify NoCodeWebが最適な選択となります。 実行速度の重視度: エンジニアがいる場合、次に実行速度の重要性を評価します。CI/CDパイプラインでの高速フィードバックが重要な場合、Playwrightが適しています。 詳細要件の評価: 実行速度がそれほど重要でない場合は、具体的なテスト要件に基づいて判断します： graph LR C1[インフラ管理は避けたい] --> AutifyNoCodeWeb[Autify NoCodeWeb] C2[メール連携や頻繁なUI変更がある] --> AutifyNoCodeWeb[Autify NoCodeWeb] C3[コストを優先したい] --> Playwright C4[データ駆動テストや複雑なファイル操作がある] --> Playwright ハイブリッドアプローチの検討: 上記の要件が混在している場合、両ツールを併用するハイブリッドアプローチも有効な選択肢です。 機能別詳細比較 # 比較項目 Playwright Autify NoCodeWeb 1 CSVの編集とアップロード ✅ 可能 ⚠️ 制限あり 2 特定ファイルのダウンロード ✅ 可能 ⚠️ 検証に制限 3 特定ステップのスクリーンショット ✅ 柔軟なカスタマイ즈可能 ✅ 自動取得で便利 4 画面上の文字状態の判断 ✅ 詳細な検証可能 ✅ AI認識で安定 5 データ駆動テストの循環使用 ✅ 可能 ⚠️ 制限あり 6 異なる画面間の切り替え ✅ 完全対応 ✅ 対応 7 外部メール内容の確認 ✅ API連携で対応可能 ✅ 統合機能で便利 8 動的要素のロケート ✅ 高精度な制御 ✅ 高精度な制御 / JS指定 9 画面の比較(VRT) ✅ ピクセル単位の精密比較 ✅ AI支援で大規模変更に対応 10 スクリプトの実装難易度 ⚠️ プログラミングスキル必要 ✅ ノーコードで容易 11 スクリプトの修正難易度 ✅ テキスト編集で迅速 ⚠️ GUI操作が必要 12 スクリプトの実行速度 ✅ 基準速度 (高速) ⚠️ 比較的遅い傾向 1. CSVの編集とアップロード Playwrightの場合: input[type="file"] 要素に対して setInputFiles() メソッドを使用することで、CSVファイルのアップロードが柔軟に実装できます。また、ファイルの動的生成やデータ駆動テストとの組み合わせも可能です。コードベースの利点を活かし、複雑なファイル操作シナリオに対応できます。 Autify NoCodeWebの場合: 基本的なファイルアップロード機能は提供されていますが、複雑なCSV編集を伴うシナリオには制約があります。シンプルなファイルアップロードであれば、ノーコードで簡単に実装できる点は大きなメリットです 2. 特定ファイルのWebページからのダウンロード Playwrightの場合: page.waitForEvent('download') を使用してダウンロードイベントを捕捉し、ファイル名や内容の検証まで完全に制御できます。ダウンロードしたファイルの内容を自動的に検証するシナリオも実装可能です Autify NoCodeWebの場合: ダウンロード操作の記録と実行は可能です。基本的なダウンロード動作の確認には十分対応しており、ノーコードで実装できる利点があります。より詳細なファイル検証が必要な場合は、他の手段との組み合わせを検討する必要があります。 3. 特定ステップのスクリーンショット Playwrightの場合: page.screenshot() や locator.screenshot() を使用して、任意のタイミングで全画面または特定要素のスクリーンショットを取得できます。保存先やファイル名も自由に設定可能で、細かい制御が必要な場合に優れています Autify NoCodeWebの場合: 全てのテストステップで自動的にスクリーンショットが撮影されるため、設定の手間が不要です。テスト失敗時の原因調査が容易になり、特にテスト自動化に不慣れなメンバーでも、確実に証跡を残せる点が優れています。 4. 画面上の文字状態の判断 Playwrightの場合: expect(locator).toHaveText() 、 toContainText() 、 toBeVisible() など、豊富なアサーションメソッドで文字列の存在、内容、表示状態を詳細に検証できます。正規表現による柔軟なパターンマッチングも可能で、複雑な検証ロジックに対応できます。 Autify NoCodeWebの場合: テキストの存在確認や表示状態の検証が可能です。特にAIによる要素認識により、画面デザインが変更されても同じテキスト要素を識別できる点が優れています。HTMLの細かい変更に強く、メンテナンスコストを削減できます 5. データ駆動テストの循環使用 Playwrightの場合: テストデータを配列やCSVファイルから読み込み、 test.describe() やforループを使用して複数のデータセットで同じテストロジックを実行できます。テストの再利用性が非常に高く、大量のテストパターンを効率的に実行できます。 // CSVファイルからデータを読み込む testData = await readCSV('C:\\××××××××\\testData4.csv'); for (const data of testData) { const { password, surname, katakanaSurname, yearOfBirth, monthOfBirth, dayOfBirth, sex, postCode1, postCode2, cellphoneNumber1, cellphoneNumber2, cellphoneNumber3, typeOfHousing, yearsOfResidence, numberOfPeople1, numberOfPeople2, annualIncome, purposeOfUser, licenseNumber, route, fileName, profession, corporateName, positionOfCorporateName, nameOfCorporate, katakanaNameOfCorporate, department, postCodeOfCorporate1, postCodeOfCorporate2, cellphoneNumberOfCorporate1, cellphoneNumberOfCorporate2, cellphoneNumberOfCorporate3, lengthOfWork } = data; Autify NoCodeWebの場合: 個別のテストシナリオを作成することで、複数のパターンに対応できます。ノーコードで各シナリオを管理できるため、プログラミングの知識がなくても運用可能な点がメリットです。ただし、データ量が多い場合はシナリオ数が増加します。 6. 異なる画面間の切り替え Playwrightの場合: 複数タブ、複数ウィンドウ、iframe間の切り替えを完全にサポートしています。 page.context().pages() で全ページを取得したり、 page.waitForEvent('popup') で新しいページを待機することができます。複雑な画面遷移ロジックも実装可能です。 Autify NoCodeWebの場合: 画面遷移やタブ切り替えの操作を記録・実行できます。基本的な画面間の移動には十分対応しており、ノーコードで実装できる利点があります。 7. 外部メール内容の確認（URLのクリックなど） Playwrightの場合: メールテストAPIサービス（例：MailSlurp、Mailinator）と連携してメール内容を取得し、URLを抽出してナビゲーションすることが可能です。柔軟な連携が可能ですが、追加の実装とAPI費用が必要になる場合があります。 Autify NoCodeWebの場合: メール検証機能がプラットフォームに組み込まれており、追加の設定や実装なしでメール内のリンクをクリックしたり、内容を確認したりできます。この統合機能は大きな強みであり、特に非エンジニアのQAメンバーでも簡単に利用できる点が優れています。 8. XPathなどによる頻繁に変動する要素のロケート Playwrightの場合: CSS Selector、XPath、text、roleなど、多様なロケーター戦略をサポートしています。複数のロケーターを組み合わせたり、厳密な条件指定が可能で、動的要素に対しても高い精度で特定できます。 # ENT番号取得 xpath1 = '//*[@id="app"]/div/main/div/div[1]/div[1]/div[2]/div/div[3]/div[1]' display_text1 = (await page.locator(f'xpath={xpath1}').text_content() or '').strip() last1 = display_text1[-5:] shinsa_number = '97016QAP00' + last1 # メールアドレス取得 xpath2 = '//*[@id="app"]/div/main/div/div[1]/div[1]/div[2]/div/div[7]/div[2]' display_text2 = (await page.locator(f'xpath={xpath2}').text_content() or '').strip() # 名前取得 xpath0 = '//*[@id="app"]/div/main/div/div[1]/div[1]/div[2]/div/div[7]/div[1]/a' display_text0 = (await page.locator(f'xpath={xpath0}').text_content() or '').strip() lastname = display_text0[4:] Autify NoCodeWebの場合: AIによる要素認識を採用しており、HTMLが変更されても要素を識別しようとします。この機能は画面の小規模な変更に対して非常に強く、手動でのメンテナンスを大幅に削減できます。特にデザイン調整が頻繁に行われる開発フェーズでは、この自動修復機能が大きな価値を発揮します。複雑な動的要素については、認識精度を確認しながら運用することが推奨されます。 そして、Javascriptによって要素の指定も簡単にできます。 function getEmailInputValue() { var selector = "#__next > main > div > div > div.o-emailPasswordForm > div > div.m-inputField > div:nth-child(1) > div > div.m-inputField__container > div > div > input[type=email]"; var element = document.querySelector(selector); if (!element) { throw new Error("Error: cannot find the element with selector(" + selector + ")."); } return element.value; } // 実行例 console.log(getEmailInputValue()); 9. 画面の比較（ビジュアルリグレッションテスト） Playwrightの場合: toHaveScreenshot() メソッドでピクセルレベルの画面比較が可能です。差分の許容範囲を設定したり、特定領域をマスクしたりできます。細かい視覚的変更の検出に優れており、意図しないUI変更を確実に捉えます Autify NoCodeWebの場合: 画面全体の変更を検出し、AIが変更箇所を識別します。特に大規模なデザイン変更時には、変更点の確認とテストシナリオの更新が比較的容易です。AIによる変更の影響分析機能により、どのテストシナリオを更新すべきかの判断がしやすく、大規模リニューアル時のメンテナンス工数を削減できる点が優れています。 10. スクリプトの実装難易度 Playwrightの場合: JavaScript/TypeScriptなどのプログラミング言語とテストフレームワークの知識が必要です。習得には一定の時間がかかりますが、公式ドキュメントが充実しており、コミュニティも活発です。エンジニアチームが確立されている組織に適しています。 Autify NoCodeWebの場合: ブラウザ操作を記録するだけでテストシナリオが作成できるため、プログラミング経験がない非エンジニアでも容易に使用できます。この実装の容易さは、Autify NoCodeWebの最大の強みの一つです。QA専任メンバーが主体となってテスト自動化を推進できるため、エンジニアリソースが限られている組織や、迅速にテスト自動化を開始したい場合に特に有効です。 11. スクリプトの修正難易度 Playwrightの場合: テキストエディタでスクリプトを直接編集できるため、小規模な修正は数秒で完了します。バージョン管理システム（Git）との親和性も高く、差分確認やロールバックが容易です。複数人での並行開発やコードレビュー文化とも相性が良いです。 Autify NoCodeWebの場合: GUI上で操作を再記録するか、手動で修正する必要があります。ただし、AIによる自動修復機能により、画面の小規模な変更には自動的に対応されるため、実際の修正作業は最小限に抑えられます。この自動修復機能は、メンテナンスコストの削減に大きく貢献します。 12. スクリプトの実行速度 Playwrightの場合: ヘッドレスモードでの実行やネットワークリクエストの最適化により、非常に高速なテスト実行が可能です。並列実行にも標準対応しており、大規模なテストスイートでも短時間で完了します。 Autify NoCodeWebの場合: クラウドベースのプラットフォームであり、ネットワークレイテンシーや処理のオーバーヘッドにより、Playwrightと比較して実行速度が遅くなる傾向があります。ただし、実際の速度差はテストケースの複雑さ、ネットワーク環境、Autify NoCodeWebのサーバー負荷などの要因によって大きく変動する可能性があります。大規模なテストスイートでは実行時間が増加する可能性がありますが、並列実行機能を活用することで全体の実行時間を最適化できます。 :::message 実行速度は環境やテストケースによって大きく異なるため、具体的な数値比較は控えます。各ツールの特性を理解し、実際の使用環境でのパフォーマンスを評価することをお勧めします。 ::: 追加の比較ポイント 📊 要約比較表 項目 Playwright (エンジニア主導) Autify NoCodeWeb (QA・非エンジニア主導) コスト 完全無料 (OSS) サブスクリプション型 (有料) 導入障壁 プログラミングスキルが必要 低い (ノーコードで即時開始) CI/CD 柔軟かつ強力な統合 シンプルなAPI連携 メンテナンス コードベース・Git管理 AIによる自動修復 (Self-healing) 1. コストと導入障壁 Playwright: 完全無料のオープンソース 学習コストは必要だが、長期的なランニングコストはゼロ CI/CD環境への組み込みも容易 エンジニアチームの人件費は考慮が必要 Autify NoCodeWeb: サブスクリプション型の有料サービス 初期導入が簡単で、迅速にテスト自動化を開始できる テストシナリオ数や実行回数に応じた費用体系 インフラ管理コストが不要 エンジニアリソースが限られている場合、トータルコストで優位性がある場合も 2.チーム構成との適合性 Playwrightが適しているチーム: エンジニア主導のQA体制が整っている コードレビュー文化が定着している 複雑なテストロジックや高度なカスタマイズが必要 Git等のバージョン管理システムを活用している Autify NoCodeWebが適しているチーム: QA専任メンバーが中心（プログラミング経験が少ない） エンジニアリソースが限られている 迅速にテスト自動化を開始したい メンテナンスコストを抑えたい（AIによる自動修復活用） ノーコードでテスト資産を管理したい 3. CI/CD統合 Playwright: GitHub Actions、GitLab CI、Jenkins など主要CI/CDツールとの統合が容易 テスト結果のレポート生成、アーティファクト保存が柔軟 並列実行、シャーディングなど高度な実行戦略が可能 開発フローに深く統合できる Autify NoCodeWeb: APIを介したCI/CD統合が可能 独自のテスト実行環境を使用 クラウドベースのため、インフラ管理不要 CI/CD統合の設定がシンプル 4.メンテナンス性と長期運用 Playwright: スクリプトをバージョン管理できる リファクタリングやスクリプトの再利用が容易 コミュニティが活発で、最新のベストプラクティスにアクセスしやすい 長期的なスクリプト資産の管理に優れる Autify NoCodeWeb: AIによる要素の自動認識で、画面変更時のメンテナンス工数を削減 自動修復機能により、軽微な変更への対応が自動化される プラットフォーム上での一元管理が可能 ノーコードのため、担当者の変更による影響が少ない それぞれのツールが特に優れているシーン Playwrightが最適なケース 大量のデータパターンテスト: 同一ロジックで数百〜数千パターンのテストデータを処理する必要がある場合 高頻度の実行: CI/CDパイプラインで1日に何度もテストを実行し、迅速なフィードバックが必要な場合 複雑なファイル操作: CSV編集、複数ファイルの同時アップロード、ダウンロードファイルの内容検証など エンジニア主導のQA: 開発チームとQAチームが密接に連携し、テストスクリプトもコードレビューの対象とする場合 長期的な資産管理: テストスクリプトをソースコードと同様に管理し、継続的に改善していく場合 Autify NoCodeWebが最適なケース 迅速な導入: プログラミング経験のないQAメンバーが、短期間でテスト自動化を開始したい場合 メール連携テスト: 外部メールの検証を含むシナリオが多い場合 頻繁なUI変更: デザイン調整が頻繁に行われる環境で、AI自動修復機能を活用したい場合 インフラ管理の負担軽減: テスト実行環境の構築・管理リソースが限られている場合 ノーコード資産管理: テスト資産をコード化せず、ビジュアルに管理したい場合 大規模リニューアル: 画面全体の大幅な変更時に、AIによる影響分析と効率的な更新が必要な場合 KTCにおける選択理由 KTCでは、これまでAutify NoCodeWebによって品質保証の基盤を築いてきましたが、プロジェクトの成長と共にいろいろな課題が顕在化しました。（上記のプロジェクト背景で述べた課題） これら課題を解決する選択肢として、Playwrightを導入することにしました。ただし、これはAutify NoCodeWebを完全に置き換えるものではありません: Playwrightが担う領域: データ駆動テスト、高速実行が求められるCI/CD統合、複雑なファイル操作を伴うシナリオ Autify NoCodeWebが引き続き価値を発揮する領域: メール連携テスト、ノーコードで管理すべきシナリオ、QA専任メンバーが主導するテスト 両ツールの強みを活かしたハイブリッドアプローチにより、KTCの品質保証体制をさらに強化していく予定です。 まとめ：どちらを選ぶべきか Playwrightの主な強み: 高速な実行速度 柔軟なカスタマイズ性 精密な要素制御とデータ駆動テスト オープンソースでコストゼロ バージョン管理システムとの親和性 Autify NoCodeWebの主な強み: ノーコードで実装が容易 AIによる自動修復でメンテナンスコスト削減 統合されたメール検証機能 非エンジニアでも運用可能 インフラ管理不要 最適な選択は、組織の状況によって異なります: エンジニアリソースが限られ、迅速にテスト自動化を開始したい → Autify NoCodeWeb エンジニアチームが確立され、高度なカスタマイズと高速実行が必要 → Playwright 両方のメリットを活かしたい → ハイブリッドアプローチ どちらのツールも、現代のWebアプリケーション開発において品質を担保するための重要な選択肢です。本記事の比較内容を参考に、自社のチーム構成、スキルセット、プロジェクト要件、予算、長期的な運用計画などを総合的に考慮して、最適なツールを選定してください。 Autifyは世界中で支持されているノーコードテスト自動化プラットフォームであり、特にエンジニアリソースが限られている組織において、品質保証体制を迅速に構築できる優れたソリューションです。KTCも、Autifyのサービスを通じて多くの成果を上げてきました。 今後も、両ツールの進化に注目し、それぞれの強みを最大限に活用していくことが重要です。

こんにちは。SCSKの井上です。 複雑なマイクロサービス環境で、障害の原因を素早く特定するにはAPMが欠かせません。本記事では、分散トレーシングの仕組みとAPMをPHPアプリに導入する手順もあわせて解説します。   はじめに APM（Application Performance Monitoring）は、アプリケーションのパフォーマンスを監視し、問題を早期に発見するための仕組みです。遅延の原因はインフラ側かアプリケーション側か、詳細な分析で原因の特定を行うことができます。この記事ではAPMの重要な機能の一つである分散トレーシングの仕組みとPHPアプリケーションの導入手順について解説します。   APMの概要 APMはアプリケーションの稼働状況をユーザー目線で可視化します。ユーザーに影響を与える可能性がある問題を特定したり、アプリケーションのパフォーマンスを改善する手助けになります。対応言語はGo, Java,.NET,Node.js,PHP,Python,Rubyをはじめとする主要な言語に対応しています。開発担当者が安心してリリースを継続でき、ユーザー影響を最小限に抑えながら市場の変化に迅速に対応するためには、APMが必要不可欠になってきています。 主に以下の機能を提供します。 アプリのレスポンス、エラー率、スループットをリアルタイム監視 トランザクション分析や分散トレーシングでボトルネックを特定 データベースや外部サービスのパフォーマンスを可視化 アラート設定やカスタムダッシュボードで運用を効率化   New Relic APM Features Features newrelic.com   APMが必要とする背景 ユーザーに影響を与えている問題を検出して対策するには、ユーザー目線でアプリケーションを監視することが必要になってきます。検出できてもその問題の分析や特定といった処置が遅れてしまうとビジネス影響は拡大していきます。特定や解決に時間がかかると工数もかかり、機会損失にもつながります。APMは、ユーザー目線での監視を実施することで、アプリケーション内の構成要素や処理の流れを可視化し、特定から対処までの時間を短縮することができます。APMが重要視されている背景について2つの観点から紹介します。 1つ目はアーキテクチャの変化 。クラウドやサーバｰレスの技術が普及することで、1つのユーザーリクエストが複数のサービスを経由して処理されるようになっています。いくつものコンポーネントを経由する構成では、どのサービスで遅延やエラーが発生しているかを特定するのが難しくなります。 APMを導入することで、サービス間の依存関係の可視化、トランザクションの遅延やエラーの原因追及、構成変更の影響分析が可能になります。 2つ目は開発プロセスの変化 。クラウドやAIなどの技術進化が速く、新しいサービスや機能が次々と登場しています。顧客は最新トレンドを取り入れたいというニーズが高まっており、従来のウォーターフォール型開発では市場の変化に対応できない状況です。そのため、CI/CDによる頻繁なリリースと、価値を早く提供することが求められていますが、システム変更には性能劣化や障害のリスクがあります。 APMを導入することで、構成変更の影響や変更前後の性能を追跡し、安心してリリースを継続できます。   New Relic実践入門 第2版 オブザーバビリティの基礎と実現 | 翔泳社 あらゆるデータを収集・分析・可視化して、システム／サービスの変化に能動的に対処せよITシステムやサービスが複雑化する現代において、オブザーバビリティ（Observability：可観測性）という考え方が極めて重要になっています。オブザーバビ... www.shoeisha.co.jp   APMでできること ページの表示速度、API応答時間、フロントエンドからバックエンドまでの経路などユーザーが操作する視点で確認することで、ユーザー満足度の低下やビジネス機会損失の影響を最小限に抑えます。APMを導入することで、以下のようなことが実現できます。 できること 説明 導入効果 サービスレベルの可視化 ユーザー視点での各サービスの可用性、レイテンシ、エラーレートなどのサービス単位の健康状態を表示 重要サービスの健全性を一目で把握 SLO逸脱の早期検知 E2Eの可視化(New Relicブラウザモニタリングが有効の場合) ユーザー操作からレスポンスまで、外部を含めた全経路を横断的に表示 ユーザー影響の把握 依存関係の可視化 トランザクションの可視化 1つの処理（購入、決済、検索等）の流れを時系列で可視化（ステップごとの時間・結果） 遅延ステップの特定 リトライ・タイムアウトの検知 UX改善の根拠提示 分散トレーシング 一連のトランザクションの処理を横断的に分析 遅延、エラーの原因箇所を迅速特定 MTTR短縮 サーバーレスアプリ監視 Lambda、Functions等の実行時間、失敗率、同時実行数 実行コストと性能の最適化 イベント連鎖の不具合検知 スケール時の安定性向上 エラートラッキング 頻度、ユーザー影響の継続的追跡 優先度付け（頻度・影響） 脱ログ中心の確認 インフラ・フロントエンド監視統合 サーバ、ネットワーク、コンテナとブラウザを同画面で表示 インフラ・アプリ運用のコミュニケーション円滑化 構成変更の記録 パラメータ、バージョン、リリースノート等のリリース前後の影響範囲 いつ・誰が・何を変えたかを追跡し障害と変更の相関を即確認 変更管理の品質向上 脆弱性の検出と可視化 サードパーティーライブラリの脆弱性をスキャンして可視化 重大脆弱性の早期発見・優先度付け パッチ適用計画の支援 コンプライアンス強化   New Relic実践入門 第2版 オブザーバビリティの基礎と実現 | 翔泳社 あらゆるデータを収集・分析・可視化して、システム／サービスの変化に能動的に対処せよITシステムやサービスが複雑化する現代において、オブザーバビリティ（Observability：可観測性）という考え方が極めて重要になっています。オブザーバビ... www.shoeisha.co.jp   分散トレーシング 分散トレーシングは、複数のサービスで構成されたシステムで、1つのリクエストがどのように処理されているかを追跡する技術です。マイクロサービスが主流になり、1つのリクエストが複数のサービスを経由します。例えば、Web画面 → API → 在庫サービス → データベースという流れのとき、どこで遅延やエラーが起きているかを1つ1つログを確認して見つけるには時間がかかり、迅速な復旧が難しくなります。そのため分散トレーシングを使ってリクエストの流れを可視化し、問題箇所を特定します。 分散トレーシングを必要とする理由 分散トレーシングを導入することで、障害対応の迅速化により本番環境で発生した問題を素早く特定し、解決までの時間を短縮できます。また、遅延の原因となるボトルネックを明確にして対策することで、システム全体のパフォーマンスを最適化できます。チーム間のコミュニケーションにおいては、開発と運用の両チームが共通の画面で確認することで、 コードの問題か、インフラの負荷が問題か、認識の齟齬が軽減され、問題がユーザー体験に与える影響を把握し、初動を早めることが可能 になります。サービス間の依存関係を分析することでアーキテクチャを改善し、リソース計画やスケーリングの判断に役立つデータも得られます。 基本構造 New Relicの分散トレーシングはOpenTelemetryの標準をベースに、スパン単位で操作を記録し、トレース全体をツリー構造で管理しています。 Trace 複数のサービスを通過する単一のリクエストのE2E経路を表し、一意のトレースIDで識別されます。1つのユーザ操作やリクエスト全体を識別するためのIDで、トレースが終わるまで不変の値です。この値が変わってしまうと、処理の繋がりが追えなくなってしまうためです。   Span サービス内の個々の操作や動作を表します。開始時間と終了時間、所要時間、関連するメタデータに関する情報を含みます。各スパンは、ステップがいつ始まり、いつ終わったか、そして何か問題があったかどうかを確認できます。SpanにもIDがついています。Span ID は各スパン固有のIDで、親子関係を示すために Parent ID とともに使われます。   Context metadata トレースの連続性を維持するためにサービス間で伝播される情報を指します。トレースIDはトレースを一意に識別するものであり、親スパンIDのような他のコンテキスト情報も含まれます。トレースコンテキストは、各サービスが自らのスパンを正しいトレースにリンクし、全体のトレース構造を維持できるようにします。各区間を同じ経路に結びつける重要な情報が入っており、途中で何も失われないようにしています。   ディストリビューティッド（分散）トレーシング：マイクロサービス全体でリクエストを追跡 | New Relic Documentation What is distributed tracing? An intro to New Relic's distributed tracing feature. docs.newrelic.com   ディストリビューティッド（分散）トレーシングに関する技術的な詳細 | New Relic Documentation Technical details of New Relic's distributed tracing, including limits, explanation of sampling, trace data structure, a... docs.newrelic.com   分散トレーシングのサンプリング 全リクエストを記録すると、システムのパフォーマンスに影響するだけでなく、データコストも増加します。そのため、New Relicではデフォルトでヘッドベースサンプリングを採用し、トレースの一部のみを選んでNew Relicに送信しています。テールベースサンプリングを利用する場合は、All Capabilitiesから「Infinite Tracing settings」を選択して有効化する必要があります。 項目 ヘッドベースサンプリング テールベースサンプリング サンプリングのタイミング リクエスト開始時に決定 リクエスト完了後に決定 メリット – 導入が簡単 – 起動が速い – パフォーマンスへの影響ほぼなし – コストが低い – 完了したトレースを見て判断できる – エラーや遅延を含むトレースを優先的に保存 – 問題箇所を確実に把握 デメリット – エラーや遅延があるか事前にわからない – データ送信・保存コストが高い – 管理が複雑 適した環境 – トランザクション量が少ないアプリ – マイクロサービス混在環境 – エラー調査や異常検知を重視する環境 – 高精度なトレース分析が必要な場合   ディストリビューティッド（分散）トレーシングに関する技術的な詳細 | New Relic Documentation Technical details of New Relic's distributed tracing, including limits, explanation of sampling, trace data structure, a... docs.newrelic.com   Complete Guide to Distributed Tracing Learn about distributed tracing, a powerful diagnostic tool, and how to use it, including examples from New Relic. newrelic.com   W3C Trace Context トレースコンテキストは、分散トレーシングにおいてサービス間のリクエストを関連付けるため、複数のサービス間を流れるリクエストを一意に識別し、関連付けるメタデータです。New Relicでは、HTTPヘッダーに以下の表のデータを伝播させることで、E2Eのトレースを構築しています。分散トレーシングの標準仕様であるW3C Trace Contextに準拠することで、トレースIDやスパンIDのフォーマットが標準化し、異なるAPMツールやオープンソース（例：OpenTelemetry）においても統一的な分散トレーシングが可能になっています。 属性名 説明 traceId トレース全体を一意に識別するID。分散トレーシングで全サービス共通。 guid / parentId 現在のスパンID。次のサービスに渡すときは「親ID」として利用。 parent.type 親の種類（ブラウザ、モバイル、APMなど）。 timestamp ペイロード作成時のUNIXタイムスタンプ（ミリ秒）。 transactionId トランザクションイベントの一意識別子。 priority サンプリング優先度（ランダム値）。サンプリング制御に利用。 sampled true / false。このトレースを収集するかどうか。 traceparent W3C標準ヘッダー。トレースID、スパンID、サンプリング情報を含む。 tracestate ベンダー固有情報を追加するためのW3C標準ヘッダー。   ディストリビューティッド（分散）トレーシングに関する技術的な詳細 | New Relic Documentation Technical details of New Relic's distributed tracing, including limits, explanation of sampling, trace data structure, a... docs.newrelic.com   ブラウザモニタリング New Relicブラウザモニタリング機能を導入することで、APMはサーバー側、Browserはクライアント側としてエンドツーエンドの監視が可能になります。ユーザー操作からシステム内部の導線を一つのトレースで確認可能になることでボトルネックがフロントかバックエンドかを即座に判断できます。ブラウザモニタリングはAPM導入と同時に設定することができます。ブラウザモニタリングの機能については、別記事にて紹介します。   分散型トレーシングにおけるブラウザデータ | New Relic Documentation Browser: How to enable browser-side (end-user) data for distributed tracing in New Relic. docs.newrelic.com   PHPエージェント導入前提条件 New Relic PHPエージェント導入にあたり、PHPバージョンの要件や動作条件があります。サポート外のPHPバージョンまたはプラットフォームを使用している場合は、パッケージ管理による自動更新によって互換性の問題が発生する可能性があります。PHPエージェントのパッケージ自動更新を無効化にすることが推奨されています。 サポートされているPHPバージョン情報は以下をご参照ください。 PHP エージェントの EOL ポリシー | New Relic Documentation Policies, start and end dates for support of New Relic PHP agent releases. docs.newrelic.com   PHPバージョンを含め、New Relic PHPエージェントが動作するOS、アーキテクチャの情報は以下をご参照ください。 PHPエージェントの互換性と要件 | New Relic Documentation A summary of the New Relic PHP agent's system requirements and the supported PHP frameworks and libraries. docs.newrelic.com   ファイアウォールやセキュリティポリシーで外部との通信制限がされている場合は、以下をご参照ください。New Relicエージェントがデータ送信できるようにドメインやエンドポイントを追加する必要があります。 New Relicネットワークトラフィック | New Relic Documentation Network connections used by New Relic for sending and receiving data: IP addresses, domains, ports, endpoints. docs.newrelic.com   エージェント導入前の注意事項 システム要件を確認したうえで、PHPエージェント導入にはいくつか注意点があります。既存システムへの影響がないことをテスト環境で十分に検証し、その後本番環境へ導入することを推奨します。以下は一例になります。 WEBサーバーの再起動 本番環境で導入する場合は、インストールのタイミング調整が必要です。エージェント導入後や設定の変更、PHPおよびPHPエージェントのアップデート後はApacheやPHP-FPM、NginxなどのWEBサーバーを再起動する必要があります。WEBサーバーが起動して PHP を読み込むと、PHP エージェントも読み込まれます。 ウェブサーバーを再起動する理由と実施のタイミング（PHP） | New Relic Documentation Why and when you must restart your web server when using the New Relic PHP agent, with links to detailed procedures and ... docs.newrelic.com   拡張モジュールの競合 競合製品がすでに導入されていないかを確認する必要があります。Xdebug、Blackfire、DrupalなどPHPのデバックやパフォーマンス監視、他APM製品が導入されている場合、競合により動作不具合やオーバーヘッドが増加する可能性があります。 PHP agent v11.5.0.18 | New Relic Documentation PHP agent v11.5.0.18 docs.newrelic.com   長時間実行される処理がある 本番環境へ導入する前に、テスト環境にてエージェント導入後、リソースが高騰していないかを確認する必要があります。処理が数分から数時間続く場合、New Relicへのデータ送信が遅れ、メモリ使用量が増える可能性があります。エージェントはトランザクションデータをメモリに保持します。長時間タスクでは保持時間が長くなるため、メモリ使用量が増加し、オーバーヘッドが大きくなります。 長時間実行されるPHPタスクでの高いメモリ負荷 | New Relic Documentation Using the PHP Agent with an application that has long running tasks can cause high memory usage. docs.newrelic.com   セキュア情報が含まれるログの扱い ログに個人情報や認証に関わるデータが出力されていないかを確認する必要があります。New Relicのプラットフォームはデータ転送は暗号化され、データ保存はセキュアな環境で管理されていますが、個人情報や機密データはNew Relicに送信しないよう対処する必要があります。 Data privacy with New Relic | New Relic Documentation Links to detailed information about how New Relic protects you and your customers' data privacy. Also see our security w... docs.newrelic.com   SQLクエリのリテラル値（文字列や数値）はNew Relicエージェント側で難読化処理したうえで、New Relicにデータを送信します。また、ユーザーがフォームに入力した値はデフォルトで収集対象外となっていますが、ログに出力される場合はマスキングや該当ログは転送除外設定が必要です。   Security and transaction traces | New Relic Documentation An explanation of the data security features for transaction traces in APM. docs.newrelic.com   データ転送量の増加 必要に応じて取得するデータ量の調整が必要となる場合があります。PHPエージェントに限らず、APMを導入すると、アプリケーションのトランザクション、エラー、SQLに加え、複数のサービスやシステムを経由するリクエストの流れを追跡する分散トレーシング機能が有効になります。そのため、New Relicへ送信されるデータ量は増加します。   PHPエージェント導入手順 PHPエージェントを導入すると、アプリケーションのレスポンス時間やデータベースのクエリの詳細を可視化でき、問題の特定や改善が容易になります。本手順では、Linux環境へエージェントのインストールから設定までの流れを説明します。 PHPエージェントのインストール方法(Linux) PHPエージェントのインストール方法は以下が用意されています。 方法 説明 On a host (CLI) New Relicが提供するインストールスクリプトをコマンドラインで実行して導入する方法。CLIで手動実行。 On a host (tar archive) 汎用的なインストール方法。tarファイルを展開して手動で設定する。パッケージ管理を使わない。 On a host (package manager) Linuxのパッケージ管理ツール（aptやyum）を使ってインストール。依存関係の自動解決やアップデートが容易。自動更新を有効にすると互換性リスクあり。 Docker Dockerコンテナ内でエージェントをインストール。コンテナ化されたアプリケーション向け。 Kubernetes Kubernetesクラスタにエージェントを導入。Podやノードの監視に対応。 Ansible,Chef,Puppet 構成管理ツールで自動化による導入。   PHPエージェントのインストール手順(Linux) PHPエージェントのインストールをCLI形式で実行した場合は、Infrastructureエージェントのインストールも同時に行われます。PHPエージェントインストール後は、設定ファイルを編集する必要があるため、その反映にはWEBサーバーの再起動は再度必要になります。インストール作業は、WEBサーバへの既存の監視アラート（死活監視）の無効化や再起動によるサービス影響を確認した上で実施してください。 1.「Integrations & Agents」から、「Guided install」をクリックします。 2.APMのタブをクリックし、「PHP」を選択します。 3.この手順ではOn a host (CLI)で進めます。 4.User keyを入力し、「Continue」をクリックします。 5.「Copy to clipboard」をクリックします。 6.対象のサーバにログインし、コピーしたコマンドを実行します。途中、APMの名前を入力する箇所がありますので、任意の名前を入力します(後ほど名前変更可能です)。 7.WEBサーバの再起動の許可を選択する画面が表示されます。後から再起動する場合は、Nと入力します。本手順ではYで進めます。 8.PHPエージェントのインストール許可を選択する画面が表示されます。Yを入力します。 9.実行後、以下の赤枠でinstalledとなっていることを確認します。 10.項番5の画面で「Continue」をクリックします。New Relicと通信状態が表示されます。導入環境によって表示項目は異なります。Apacheへの導入は「Install Apache」をクリックします。 11.「Guided」をクリックします。 12.同様にUser keyを入力後に表示されるコマンドをコピーし、対象のサーバーで実行後、以下の赤枠が表示されていることを確認します。 13.New Relicとの通信確認でApacheがinstalledとなっていることを確認します。「See your data」をクリックします。本記事ではAWSとのインテグレーション設定はスキップします。 14.APMのサマリー画面が表示され、収集されたデータを確認することができます。   PHPエージェントのインストレーション概要 | New Relic Documentation Overview of installing the New Relic PHP agent for RedHat, CentOS, Ubuntu, or Debian, or for the tar archive. docs.newrelic.com   Apache monitoring integration | New Relic Documentation Apache monitoring integration docs.newrelic.com   設定ファイルの編集 設定できる内容が多いので、基本設定やデータ削減に関係のある個所のみを主にピックアップして下記にデフォルト値を記載しています。設定ファイルを編集後はWEBサーバーの再起動が必須になります。PHPエージェント導入後、データ転送量が増大している場合は、必要に応じて設定値を調整する必要があります。 設定ファイル：/etc/php.d/newrelic.ini   機能カテゴリ 設定項目 意味 基本設定 newrelic.enabled = true エージェントの有効化（falseで無効）   newrelic.license = “*********************NRAL” New Relicライセンスキーの設定 環境変数で外出しが望ましい   newrelic.appname = “アプリケーションの名前” APM上で表示するアプリケーション名 ログ設定 newrelic.loglevel = “info” PHPエージェントのログ出力レベル（info, debugなど）   newrelic.daemon.loglevel = “info” デーモンのログ出力レベル エラー収集 newrelic.error_collector.enabled = true PHPエラーの収集を有効化 ブラウザ監視 newrelic.browser_monitoring.auto_instrument = true HTMLにブラウザ監視スクリプトを自動挿入 トランザクション詳細 newrelic.transaction_tracer.enabled = true トランザクション詳細トレースを有効化   newrelic.transaction_tracer.threshold = “apdex_f” トレース対象の閾値（例：apdex_f）   newrelic.transaction_tracer.slow_sql = true 遅いSQLクエリの収集を有効化   newrelic.transaction_tracer.stack_trace_threshold = 500 スタックトレースを取得するSQLの閾値（ms）   newrelic.transaction_tracer.explain_enabled = true SQLのEXPLAINを有効化   newrelic.transaction_tracer.explain_threshold = true EXPLAINを実行するSQLの閾値（ms） イベント設定 newrelic.transaction_events.enabled = true トランザクションイベントの有効化   newrelic.custom_events.max_samples_stored =  カスタムイベントの最大保持件数 ログ収集 newrelic.application_logging.enabled = true アプリケーションログ収集を有効化   newrelic.application_logging.forwarding.enabled = true アプリケーションログをNew Relicへ転送を有効化 PHPエージェントの設定 | New Relic Documentation New Relic PHP agent configuration: How to edit newrelic.ini config settings (like app name, slow traces, parameters, log... docs.newrelic.com   UIから設定できる項目もあります。UI上から設定した場合、エージェント設定ファイルと競合する箇所は上書きされ、UIの設定が優先となりますが、 PHPの場合は例外とされています。 サーバーサイドのエージェント設定 | New Relic Documentation New Relic APM server-side config lets you manage some agent settings from the New Relic side, instead of the agent confi... docs.newrelic.com   ユーザ体験の可視化指標：Apdex アプリケーションのパフォーマンスに対するユーザー体験を数値化する指標としてApdexがあります。1.0に近いほど、ユーザー体験は問題ないとされています。以下についてはベンダーごとに評価基準は異なります。 Apdex 値の範囲 評価（ Rating） 0.94 ～ 1.00 Excellent（非常に良い） 0.85 ～ 0.93 Good（良い） 0.70 ～ 0.84 Fair（普通） 0.50 ～ 0.69 Poor（悪い） 0.00 ～ 0.49 Unacceptable（許容外）   Application Performance Index – ApdexTechnical Specificationの資料によると、計算式については以下と定義されています。 Apdex(T) = (Satisfied count + (Tolerating count ÷ 2)) ÷ Total samples 不満と感じるのは満足の閾値から4倍の値と上記資料で報告されています。計算する際は満足・許容・不満の3つのカテゴリに分けられています。 満足（Satisfied）      ：レスポンスタイム ≤ T 許容（Tolerating）    ：T < レスポンスタイム ≤ 4T 不満足（Frustrated）：レスポンスタイム > 4T 実際の計算式についてNew Relicの公式サイトを参考に算出します。今回、外形監視を例に、ログインからログイン完了後のページを表示する際に満足できるレスポンスタイムを3秒(=T)とします。デフォルトではApdex Tの値が0.5秒となっています。 満足（Satisfied）      ： レスポンスタイム ≤  3秒 許容（Tolerating）    ：3秒 < レスポンスタイム ≤ 12秒 不満足（Frustrated）：レスポンスタイム > 12秒   100回測定した結果が以下となったとします。 満足数：60回 許容数：30回 不満足 :10回 これらを先ほどの式に当てはめてみると、Apdex(T3)=(60+(30÷2))÷100 =0.75となりました。0.75はApdexの範囲で示すと”普通”に該当します。ただし、この基準はあくまで目安です。ユーザー体験はレスポンスタイム以外にもユーザーインタフェースのわかりやすさや、機能の充実度などにも影響します。普段とは大きくApdexスコアが下がっているなど、傾向と合わせて確認することで効率的に活用できます。 デフォルト値で設定されているtransaction_tracer.threshold = “apdex_f” の場合、上記の結果では不満足の10 件(12 秒を超えているもの)がトランザクショントレース対象になります。10件すべてを記録するわけではなく、1分間の収集サイクルで閾値を超えたものをプールし、最も遅い1件だけをトレースとして記録しています。 参考: https://www.apdex.org/index.php/documents/   Apdex：ユーザー満足度の測定 | New Relic Documentation New Relic uses Apdex to measure whether users are satisfied, tolerating, or dissatisfied with your app's response time. docs.newrelic.com トランザクショントレースの概要 | New Relic Documentation In APM, transaction traces record in-depth data from your application's slowest HTTP requests and database queries. docs.newrelic.com   トラブルシューティング New RelicのPHPエージェントは、バックグラウンドで動作するnewrelic-daemonプロセスにデータを渡します。このデーモンがデータを集約し、New Relicのプラットフォームへ送信する仕組みです。エージェント関連で問題が発生した場合は、状況に応じて以下のログを確認します。 状況・問題 確認するログ ログで確認するポイント 次のアクション New Relicにデータが送信されない newrelic-daemon.log ・daemonが起動しているか ・サーバーへの接続エラー ・キューが溜まっていないか ・daemonを再起動 ・ネットワーク疎通確認 ・Proxy設定確認 ・アクセス権の確認 PHPアプリのメトリクスがNew Relicに表示されない php_agent.log ・エージェントが正しく読み込まれているか ・設定ファイル読み込みエラー ・php.ini設定確認 ・PHP再起動   New Relic デーモンのプロセス | New Relic Documentation Information about daemons for New Relic PHP agent installations prior to 3.0. docs.newrelic.com   データが表示されない（PHP） | New Relic Documentation Start here if your encounter problems with your New Relic PHP agent installation. docs.newrelic.com   エージェントの再送処理 エージェントは、トランザクション、エラー、カスタムイベントなどのデータを即時送信せず、メモリに一時保持します。その保持したデータを定期的にNew Relicのコレクターへ送信するタイミングをハーベストサイクルと言います。この仕組みにより、アプリへの負荷を防ぎ、New Relicとの通信を効率化させています。いずれもメモリ上限やイベント種別ごとの制約により、すべて送信されるわけではありません。 データ内容 再送 理由 トランザクションイベント 〇 メモリに保持し、ハーベストサイクルで送信。 エラーイベント 〇 メモリに保持し、再送可能。 カスタムイベント 〇 最大30,000件/分（newrelic.custom_events.max_samples_storedで調整可）。HTTPリクエストが1MBを超える場合は破棄。New Relicに送信できるイベント数は833件/5秒 のため、イベント数によってはすべて送信されずサンプリングとなる場合あり。 スパンイベント（分散トレーシング） 〇 再送可能。上限超過分は破棄。 メトリクス（レスポンスタイム等） 〇 集計値をメモリに保持し、再送可能（CPU,メモリなどのインフラメトリクスは再送不可）。 ログ（ログフォワーディング） × リアルタイム送信のみ。通信切断時は保持されない。 Event limits and sampling for APM and mobile monitoring | New Relic Documentation How APM and mobile agents limit the reporting of events and perform sampling when those limits are exceeded. docs.newrelic.com   APM: Report custom events and attributes | New Relic Documentation How to report APM custom events and attributes in New Relic. docs.newrelic.com   PHPエージェントの更新 最新の技術を使うためにはエージェントの更新が必要となってきます。更新により、最新のセキュリティ対策やパフォーマンス改善が適用され、より正確な計測や新機能の利用が可能になります。古いバージョンを使い続けると、互換性の問題やサポート切れによるリスクが生じるため、定期的な更新が重要になります。   PHPエージェントの更新 | New Relic Documentation How to update your APM PHP agent, and notes on EOL support for early agent versions. docs.newrelic.com   PHP agent release notes | New Relic Documentation PHP agent release notes docs.newrelic.com   さいごに この記事では、分散トレーシングの機能とPHP環境へのAPM導入手順、設定について解説しました。分散トレーシングは奥が深く、実際の障害対応や運用を通じて理解をさらに深め、設定をブラッシュアップしていくことが重要です。今回はPHP環境を紹介しましたが、今後はJavaなど他言語への導入方法ついても、より幅広い環境での可観測性向上の一助となる情報を目指していきます。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。