本記事は 2026 年 4 月 3 日 に公開された「 Introducing OpenTelemetry & PromQL support in Amazon CloudWatch 」を翻訳したものです。 Kubernetes やマイクロサービスのワークロードを AWS で実行している場合、メトリクスには namespace、pod、container、node、deployment、replica set、カスタムのビジネスディメンションなど、多数のラベルが付いているでしょう。環境全体を把握するために、メトリクスパイプラインを分割しているケースも多いはずです。AWS メトリクスには Amazon CloudWatch を使い、高カーディナリティ (多数のラベルの組み合わせを持つ) なコンテナやアプリケーションのメトリクスには別の Prometheus 互換バックエンドを使う、といった具合です。さらに進んだチームでは、Prometheus CloudWatch エクスポーターで GetMetricData API を呼び出し、AWS リソースメトリクスを Prometheus バックエンドに取り込んでいることもあります。運用負荷とコストは増えますが、すべてを一箇所でクエリできるようになります。 Amazon CloudWatch で OpenTelemetry メトリクス のネイティブ取り込みと、 Prometheus Query Language (PromQL) によるクエリがサポートされました。このプレビュー機能では、メトリクスあたり最大 150 ラベルをサポートする高カーディナリティメトリクスストアが導入され、ラベルの多いメトリクスを変換や切り捨てなしで CloudWatch に直接送信できます。AWS Vended メトリクスの自動エンリッチメントと組み合わせることで、CloudWatch がインフラストラクチャ、コンテナ、アプリケーションメトリクスの一元的な送信先になり、すべて PromQL でクエリできるようになりました。 本記事では、以下の内容を説明します。 AWS アカウントで OpenTelemetry メトリクスの取り込みと AWS リソースの自動エンリッチメントを有効化する方法 Amazon Elastic Kubernetes Service (Amazon EKS) クラスターに Amazon CloudWatch Container Insights をデプロイする方法 Amazon CloudWatch と Amazon Managed Grafana で PromQL を使ってインフラストラクチャと AWS リソースのメトリクスをクエリする方法 OpenTelemetry SDK でカスタムアプリケーションメトリクスを作成し、AWS コンテキストで自動エンリッチメントされる様子 CloudWatch における OpenTelemetry サポートが何を意味するか OpenTelemetry Protocol (OTLP) は、OpenTelemetry (OTel) プロジェクトの標準ワイヤープロトコルです。メトリクス、トレース、ログを含むテレメトリデータのエンコードとコンポーネント間の転送方法を定義しています。このプレビューにより、CloudWatch は OpenTelemetry 互換のコレクターや SDK がメトリクスを送信できるリージョナル OTLP エンドポイントを公開します。 CloudWatch はメトリクスを受信し、新たな高カーディナリティのメトリクスストアに保存します。カウンター、ヒストグラム、ゲージ、アップダウンカウンターなどの OpenTelemetry メトリクスタイプは変換なしでそのまま保持されます。今回のリリースで、CloudWatch はオブザーバビリティの 3 本柱すべてで OpenTelemetry をサポートするようになりました。CloudWatch はすでに OTLP エンドポイント 経由でトレースとログを受け付けており、ネイティブ OTLP メトリクス取り込みが加わったことで、すべてのテレメトリをオープンスタンダードで、単一のプロトコルを通じて CloudWatch に送信できるようになりました。3 つの機能がこのことを重要にしています。 拡張されたラベルとカーディナリティのサポート OTLP で取り込まれたメトリクスは最大 150 ラベルをサポートし、CloudWatch カスタムメトリクスの 30 ディメンション制限を超えています。Kubernetes、マイクロサービス、OpenTelemetry ワークロードでフィルタリングや集計に高カーディナリティラベルを使う際の主要な制約が解消されます。制限は今後も進化するため、最新情報は クォータページ をご確認ください。 PromQL クエリのサポート OTLP 経由で取り込んだメトリクスを PromQL でクエリできます。すでに Prometheus を使っている場合、同じクエリ言語を CloudWatch や Amazon Managed Grafana で直接使えます。新しい構文を覚える必要はありません。 AWS リソースの自動エンリッチメント この機能により、AWS インフラストラクチャ全体でメトリクスをクエリ・フィルタリングする方法が根本的に変わります。CloudWatch は取り込んだすべてのメトリクスに AWS リソースコンテキスト (アカウント ID、リージョン、クラスター Amazon Resource Name (ARN)、AWS Resource Explorer からのリソースタグ) を付与します。このエンリッチメントは追加の計装なしで自動的に行われます。Container Insights、カスタムアプリケーション、AWS サービスのいずれから来たメトリクスでも、AWS アカウント、リージョン、環境タグ、アプリケーション名でフィルタリングやグループ化ができます。エクスポーター不要、カスタムラベル不要、追加の API 呼び出し不要です。 図 1: Amazon CloudWatch における OpenTelemetry メトリクスの取り込みとエンリッチメントアーキテクチャ OTLP 取り込みと AWS リソースエンリッチメントの有効化 OTLP メトリクスを取り込んでクエリする前に、2 つのアカウントレベルの設定を有効にします。1 つ目は、AWS Resource Explorer で確認できるものと同じリソースタグをテレメトリに伝播させる設定です。2 つ目は、CloudWatch の OTLP 取り込みを有効にする設定です。 両方のエンリッチメント設定は、Amazon CloudWatch コンソールまたは AWS CLI から有効にできます。 コンソールを使用する場合 CloudWatch コンソールでエンリッチメントを有効にする手順は以下のとおりです。 Amazon CloudWatch コンソールを開きます。 ナビゲーションペインで 設定  を選択します。 リソースタグのテレメトリへの伝播を有効にします。 AWS メトリクスの OTel エンリッチメントを有効にします。 両方の設定を有効にすると、アカウントでリージョナルエンドポイントへの OTLP メトリクス受信の準備が整います。 図 2: CloudWatch コンソール設定での OTel エンリッチメントとリソースタグの有効化 AWS CLI を使用する場合 AWS CLI で両方のエンリッチメントレイヤーを有効にすることもできます。以下のコマンドを実行します。 # Enable resource tags on telemetry aws observabilityadmin start-telemetry-enrichment # Enable OTel enrichment for CloudWatch aws cloudwatch start-o-tel-enrichment 両方のエンリッチメント設定がアクティブであることを確認するには、以下のコマンドを実行します。 aws cloudwatch describe-o-tel-enrichment-status エンリッチメントを有効にすると、OTLP エンドポイント経由で取り込まれたすべてのメトリクスに AWS リソースコンテキストが自動的にタグ付けされます。CloudWatch が追加する属性は以下のとおりです。 Attribute 説明 例 @aws.account AWS アカウント ID 123456789012 @aws.region AWS リージョン us-west-2 cloud.resource_id EKS クラスターの完全な ARN arn:aws:eks:us-west-2:123456789012:cluster/prod k8s.cluster.name EKS クラスター名 production-cluster k8s.namespace.name Kubernetes namespace karpenter k8s.container.name コンテナ名 controller @instrumentation.name 計装ソース cloudwatch-otel-ci リソースタグ AWS Resource Explorer からのタグ (@aws.tag.Application、@aws.tag.CostCenter、@resource.ec2.tag.ManagedBy など) env=production これらの属性は CloudWatch によって追加され、手動の計装は不要です。カスタムパイプラインの構築やエクスポーターの実行なしに、AWS アカウント、リージョン、リソースタグをまたいでクエリできるのはこのためです。 OpenTelemetry メトリクスを使った Amazon CloudWatch Container Insights OpenTelemetry と CloudWatch の連携を実際に確認するため、Container Insights から始めましょう。Amazon EKS 向け Amazon CloudWatch Container Insights で Prometheus と OpenTelemetry メトリクスが サポートされました 。コンテナメトリクスが OpenTelemetry attribute で標準化され、PromQL でクエリできるようになります。Container Insights は、コンソールまたは AWS CLI から Amazon EKS アドオンを使って 有効化 できます。 Container Insights ダッシュボード Container Insights をデプロイすると、CloudWatch は CPU 使用率、メモリ使用量、Pod 数などのクラスターレベルのメトリクスを表示するダッシュボードを自動的に作成します。ダッシュボードを表示するには、CloudWatch コンソールを開き、ナビゲーションペインから Container Insights を選択し、ドロップダウンからクラスターを選択します。クラスター、namespace、Pod レベルのビューを切り替えて、特定のワークロードを詳しく確認できます。 図 3: Amazon CloudWatch Container Insights ダッシュボード CloudWatch Query Studio で PromQL を使ってメトリクスをクエリする OTLP で取り込んだメトリクスは、CloudWatch コンソール、Amazon Managed Grafana、または PromQL と AWS Signature Version 4 (SigV4) をサポートするクエリインターフェースで PromQL を使ってクエリできます。 CloudWatch Query Studio には、コンソールで直接メトリクスを探索・可視化するための PromQL エディターが組み込まれています。PromQL クエリモードを選択して開始します。 図 4: PromQL クエリモードの Amazon CloudWatch Query Studio インターフェース エンリッチされた AWS リソースコンテキストを使ったクエリ エンリッチメントが有効になっているため、CloudWatch が自動的に追加するタグを使って AWS リソースの境界を越えてクエリできます。エクスポーター不要、カスタムラベル不要です。 # AWS Lambda function duration for functions tagged with application "order-pipeline" Duration{"@aws.tag.appname"="order-pipeline"} # Amazon EC2 CPU utilization for production delivery workloads CPUUtilization{"@aws.tag.Environment"="production", "@aws.tag.Application"="delivery"} # Running pods grouped by AWS account and namespace sum by (aws_account_id, k8s_namespace_name) (kube_pod_status_phase{phase="Running"}) 最後のクエリは、カスタム計装なしで AWS アカウントと Kubernetes namespace ごとにグループ化された実行中の Pod 数を返します。 aws_account_id ラベルはエンリッチメントレイヤーによって自動的に追加されます。 図 5: Lambda duration メトリクスをクエリする CloudWatch Query Studio Grafana で PromQL を使ってメトリクスをクエリする Amazon Managed Grafana で OTLP 取り込みメトリクスを可視化するには、CloudWatch PromQL エンドポイントを指す Prometheus データソースを追加します。このセクションでは、AWS Signature Version 4 (SigV4) 認証でデータソースを設定する手順を説明します。 Amazon Managed Grafana ワークスペースを開きます。 Data Sources を選択します。 Add data source を選択します。 データソースタイプとして Prometheus を選択します。 URL には、リージョンの CloudWatch PromQL エンドポイントを入力します: https://monitoring.<AWS Region>.amazonaws.com/v1/metrics Authentication で SigV4 を選択します。 SigV4 認証用の適切な IAM ロールを設定します。 Save & Test を選択して接続を確認します。 Save & Test が成功すると、「Data source is working」という確認メッセージが表示されます。失敗した場合は、IAM ロールに cloudwatch:GetMetricData と cloudwatch:ListMetrics の権限があること、SigV4 署名が正しく設定されていることを確認してください。 データソースを設定すると、Grafana ダッシュボードで同じ PromQL クエリを使用できます。 図 6: CloudWatch PromQL を使った Grafana Explore カスタムアプリケーションメトリクス CloudWatch OTLP 取り込みはカスタムアプリケーションメトリクスもサポートしています。OpenTelemetry SDK で計装されたアプリケーションは、クラスターで実行中の CloudWatch エージェント経由でメトリクスを送信でき、計装コードの変更は不要です。 実際の動作を確認するため、 aws-otel-community リポジトリからサンプル Python アプリケーションをデプロイします。このアプリケーションは OpenTelemetry Python SDK を使用して、カウンター、ヒストグラム、ゲージ、アップダウンカウンターなど、すべての OTel メトリクスタイプをカバーするカスタムメトリクスを出力します。例えば、アプリは API レスポンス時間を測定する latency_time ヒストグラムを定義しています。 from opentelemetry import metrics meter = metrics.get_meter(__name__) # Histogram --- measures API latency distribution latency_time = meter.create_histogram( name="latency_time", description="Measures latency time", unit="ms", ) サンプルアプリケーションのデプロイ サンプルアプリケーション とすべてのデプロイマニフェストは、GitHub の aws-otel-community リポジトリにあります。先ほどデプロイした Container Insights アドオンには、OpenTelemetry コレクターとして機能する CloudWatch エージェントが含まれています。 OTEL_EXPORTER_OTLP_ENDPOINT 環境変数を設定して、サンプルアプリをエージェントに向けます: http://cloudwatch-agent.amazon-cloudwatch.svc.cluster.local:4317 このウォークスルーでは CloudWatch エージェントを使用していますが、OTLP/HTTP をサポートする任意の OpenTelemetry 互換コレクターや SDK を使用して、CloudWatch OTLP エンドポイントに直接メトリクスを送信できます。 PromQL でアプリケーションメトリクスをクエリする アプリケーションをデプロイしたら、CloudWatch Query Studio を開くか、Amazon Managed Grafana ワークスペースで Explore に移動し、CloudWatch PromQL データソースを選択します。 以下のクエリは、Amazon Managed Grafana でデモアプリの p99 レイテンシーを、自動エンリッチされた @aws.region ラベルでグループ化して表示します。 histogram_quantile(0.99, sum by (le, aws_region) (rate(latency_time_bucket{resource_service_name="python-demo-app"}[5m])))` 図 7: Amazon Managed Grafana でのサンプルアプリケーションの P99 レイテンシー エンリッチメントが有効になっているため、すべてのアプリケーションメトリクスに AWS リソースコンテキストが自動的に付与されます。例えば、 cpu_usage をクエリすると、追加の計装なしで以下のラベルが返されます。 図 8: カスタム OTel 計装からのエンリッチされた全ラベルの表示 料金 OTLP 取り込み機能と PromQL クエリは、プレビュー期間中は追加料金なしで利用できます。現在の料金の詳細については、Amazon CloudWatch の 料金ページ をご覧ください。 このウォークスルーで使用した Amazon EKS と Amazon Managed Grafana のリソースは、標準料金で課金されます。継続的な課金を避けるため、ウォークスルー終了後は次のセクションのクリーンアップ手順に従ってください。 クリーンアップ サンプルアプリケーションを削除します。 kubectl delete -f demo-app.yaml EKS クラスターから Amazon CloudWatch Observability アドオンを削除します。 aws eks delete-addon \ --cluster-name \ --addon-name amazon-cloudwatch-observability Grafana ワークスペースから Prometheus データソースを削除します (Grafana コンソールにログインし、Data Sources に移動して、設定した CloudWatch PromQL データソースを削除します)。 Amazon Managed Grafana ワークスペースを削除します (このウォークスルー用に作成した場合のみ)。 aws grafana delete-workspace --workspace-id Amazon EKS クラスターを削除します (このウォークスルー用に作成した場合のみ)。 aws eks delete-cluster --name OTel エンリッチメントを無効にします (アカウントで不要になった場合)。 # Disable OTel enrichment aws cloudwatch stop-o-tel-enrichment # Disable telemetry enrichment aws observabilityadmin stop-telemetry-enrichment このウォークスルー用にアタッチした IAM ポリシーをデタッチします。 aws iam detach-role-policy \ --role-name \ --policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy まとめ 本記事では、Amazon CloudWatch でのネイティブ OpenTelemetry メトリクス取り込みについて説明しました。エンリッチメントレイヤーの有効化、Amazon EKS への Container Insights のデプロイ、OpenTelemetry SDK でのカスタムアプリケーションメトリクスの送信、PromQL でのクエリを紹介しました。 このプレビュー機能により、メトリクスパイプラインを CloudWatch に統合できます。拡張されたラベル制限を持つ高カーディナリティメトリクス、PromQL クエリ、AWS リソースの自動エンリッチメントが連携し、インフラストラクチャメトリクス、コンテナメトリクス、アプリケーションメトリクスがすべて同じパイプラインを流れ、同じ AWS リソースコンテキストを持つようになります。別々のバックエンド、エクスポーター、AWS メトリクスを統合ビューに取り込むための追加 API 呼び出しは不要です。 OpenTelemetry を使ったアプリケーションレベルの計装の実践例については、以下のリソースをご覧ください。 AWS Observability Best Practices Guide:  OpenTelemetry SDK でアプリケーションを計装するパターン One Observability Workshop : AWS でのメトリクス、トレース、ログのハンズオンラボ AWS Observability Accelerator: テレメトリ収集とクエリを自動化する CDK パターンと Terraform モジュール プレビューは、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー) で追加料金なしで利用できます。開始するには、アカウントでエンリッチメントレイヤーを有効にし、Amazon EKS クラスターに CloudWatch Observability アドオンをデプロイしてください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Rodrigue Koffi AWS のオブザーバビリティ担当スペシャリストソリューションアーキテクトです。オブザーバビリティ、分散システム、機械学習に情熱を持っています。DevOps とソフトウェア開発のバックグラウンドがあり、Go でのプログラミングを好みます。仕事以外では、水泳や家族との時間を楽しんでいます。LinkedIn: /grkoffi

みなさん、こんにちは。AWS ソリューションアーキテクトの古屋です。 日々のお客様との会話の中で、「業務課題を解決するために新たな機能やシステムの開発が必要ではあるが、外部リソースを確保する余力もなく、自社に十分なエンジニアもいないため実現が難しい」というお声をいただきます。同様のお悩みをお持ちの方も少なくないのではないでしょうか。 近年、そういった状況に対して、 Amazon Bedrock や Amazon Q Developer をはじめとする AWS の生成 AI サービスの登場により、限られた開発リソースの中でも、業務を最もよく知る現場の担当者自身が課題解決の仕組みを構築できる環境が整いつつあります。 今回は、まさに生成 AI を活かし、非エンジニアのメンバーが中心となって契約書管理 AI エージェントを構築された大成株式会社様の事例をご紹介します。本事例では、Amazon Q Developer によりプログラミング経験が限られたメンバーでも AWS 上でのシステム構築が可能となり、さらに Amazon Bedrock を利用することでインフラ構築や運用管理なしに Claude のような高性能な基盤モデルを API 一つで呼び出せるため、従来手作業で数十分かかっていた情報抽出を数分に短縮する仕組みを短期間で実現いただきました。 お客様の状況と経緯 大成株式会社様（以下、大成様）は、「ビルトータルソリューション」を掲げ、ファシリティマネジメント、プロパティマネジメント、不動産投資事業、修繕工事や改修工事などの建築事業を展開する総合サービス企業です。 大成様のプロパティマネジメント業務では、ビルオーナー様やテナント様との間で締結される多数の契約書が業務の根幹をなしています。しかしながら、従来の契約書管理では、以下の課題が存在していました。 契約書の検索が手作業に依存しており、必要な情報を見つけるために複数の PDF を開いて目視で確認する必要がある テナント様ごとに契約内容の仕様が異なるため、ビル名やテナント名だけでは目的の契約書にたどり着けない場合がある ビルオーナー様からの問い合わせに対し、契約書の特定から情報確認、回答までに多くの時間を要し、迅速な顧客対応の妨げとなっている これらの課題を解決するため、業務改善やシステム利活用を担当している IT 戦略推進室が本取り組みに参加しました。大成様では社内 SE、内製開発を行うエンジニアを擁していないため、同部にて生成 AI を活用した契約書管理システムの構築を検討されることになりました。 ソリューション／構成内容 本プロジェクトでは、非エンジニアのプロジェクトマネージャーが中心となり、Amazon Q Developer の支援を受けながらシステムを構築しました。Amazon Q Developer は自然言語での指示に基づいてコードを生成する AI アシスタントであり、プログラミング経験が限られた担当者でも実用的なシステムを構築できます。 本システムでは、Amazon Bedrock、 AWS Lambda 、 Amazon S3 、 Amazon DynamoDB を組み合わせて活用しています。Amazon Bedrock は生成 AI の中核を担い、Anthropic 社の Claude AI モデルを通じて契約書 PDF の解析と重要情報の抽出を実行します。 Amazon Bedrock + Claude を採用したポイントとして、Claude の高度な文書理解能力が挙げられます。契約書は法的な専門用語を含む複雑な文書であり、テナント様ごとにフォーマットが異なりますが、Claude は PDF などの非構造化データから文脈を理解した上で必要な情報を正確に抽出できます。また、AWS Lambda を中心としたサーバーレスアーキテクチャにより、非エンジニアが中心のチームでもインフラ管理に煩わされることなくシステムを運用できる点、そして日常的に使用している Slack との統合が容易で導入時の移行障壁を低く抑えられる点も、AWS を選択された理由です。 導入効果 実際にご利用いただいた結果、以下のような効果が得られています。 契約書からの情報抽出にかかる作業時間を 約 70〜80% 削減 。従来 1 件あたり数十分を要していた作業が数分で完了 将来的には、CSV 形式でのデータ出力機能を実装し、契約書情報の一括管理および分析を可能とする仕組みの構築を検討 AI による解析で情報抽出の精度と一貫性が向上し、人手による見落としや誤読のリスクを低減 Slack 上のシンプルなワークフローにより、従業員の受け入れがスムーズに また、非エンジニアでも Amazon Q Developer の支援により AWS の各種サービスを組み合わせた実用的なシステムを構築できることが実証されたことにより、他の業務領域でも生成 AI を活用した業務改善の取り組みが始まるきっかけとなっています。 大成様では今回の成功を踏まえ、契約書の自動要約機能や自然言語での高速検索機能の追加を検討されています。さらに、施設管理報告書の自動生成やメンテナンス記録の分析など、プロパティマネジメント業務全般での AI 活用拡大も計画されています。 お客様の声 大成株式会社 IT 戦略推進室 石川 静華様からは、「AWS のサービスを使うことで非エンジニアでも実業務の課題を自らの手で解決できる喜びを実感しました。」とのコメントをいただいています。 まとめ 今回は大成様が Amazon Bedrock と Amazon Q Developer を活用し、非エンジニアの手で契約書管理 AI エージェントを構築された事例をご紹介しました。Claude の高度な文書理解能力とサーバーレスアーキテクチャの組み合わせにより、専門的な開発リソースがなくても実用的な業務改善システムを実現されています。スモールスタートで確実に成果を出すアプローチは、これから生成 AI 活用を検討される企業にとっても参考になる取り組みです。 生成 AI を活用した業務改善にご興味をお持ちのお客様は、ぜひ AWS までお問い合わせください。 大成様 IT 戦略推進室 推進課 課長　田島 宏美 IT 戦略推進室 戦略課 主任　石川 静華 IT 戦略推進室 推進課 主任　鎌倉 由佳 Account Team： ソリューションアーキテクト　森   瞭輔 アカウントマネージャー　植木　輝 記事執筆： ソリューションアーキテクト　古屋　楓

はじめに BASE Order Section でWebアプリケーションエンジニア をしている Capi(かぴ) です。 2026/3/20（金）- 3/22（日）の3日間、BASE株式会社もゴールドスポンサーとして協賛した PHPerKaigi 2026 が開催されました。今回はPHPerKaigi 2026に参加したメンバーのコメントや感想をお届けします！ PHPerKaigiとは PHPerKaigiは、オープンソースのスクリプト言語 PHP （正式名称 PHP:Hypertext Preprocessor）を使用している方、過去にPHPを使用していた方、これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、技術的なノウハウとPHP愛を共有するためのイベントです。コミュニティ貢献活動の一環として、今年もゴールドスポンサーとして協賛しました。 登壇者コメント 川島慧 モジュラモノリスを導入してから4年が経ち、「そろそろ答え合わせができるのでは」という気持ちで今回の発表に臨みました。 「何を解決しようとしているのか分からないままマイクロサービス（orモジュラモノリス）を開始しようとするのはほとんど悪いアイディアだ」という、技術主導は大抵誤りであるという意識を４年前からずっと持って挑んできました。結果的に思いがけないつまづきもありましたが、無事に解決するべきIssueの解像度が上がった４年間でした。 スライド中では「AIに要約させながら読むことを推奨」と書いたのですが、アップロード後に試してみると、意外なことにChatGPTやGeminiでは何度訂正させても全く違う内容が返ってきました。どうやら100枚超のスライドをAIに要約させるのはまだ難しいようです。ClaudeとNotebookLMだとある程度うまくやってくれます。 個人的にはかなり痛手です。これほどの文量を読むエンジニアは今の時代にまずいないので、ほとんどの人に届かない内容になってしまったと思います。スライドを読む際はご自身の目でしっかり読んでいただくか、動画を見るか、ClaudeまたはNotebookLMあたりににお願いするのがおすすめです（個人の感想です）。 speakerdeck.com プログラミングをするパンダ セール開始のバッチのパフォーマンスをチームで改善したという話を共有しました。発表後に「うちでも遅いバッチがある」という話を聞いたり、「しっかり遅いことに気づいて改善に持っていける体制が作られているのが素晴らしい」とお褒めの言葉をいただいたりしました。 特にポストモーテム共有会をやっているということが今回のバッチの改善の起点になったのですが、その取り組みがとても良いと言ってもらうことが多く、ポストモーテム共有会も別のメンバーが始めていたので大変ありがたいなと思っています。 スライドの最後の方でも触れましたが、今回の発表を機にもう一段改善できるところを見直そうと思うので、さらに早くできるのではないかなと思っています。当日発表を聞きに来てくださった方、ありがとうございました。そうでない方もぜひスライドを一度ご覧ください。皆様のお役に立てれば幸いです。 speakerdeck.com 02 PHP8.5に追加されたarray_first / array_lastの歴史的背景について話しました。5分という短い時間で7年分の議論の流れを追いましたが、重要な話はできるだけ削らずに伝えられたと思います。 さまざまな観点から議論を重ねて未解決の疑問をなくす必要がある一方で、発散した議論はスコープを絞ったり、特定の観点を重視して仕様を決めたり・・・仕事の進め方やファシリテーション、マネジメントなど、普段のプロダクト開発で重要な力が、RFCの採択においても重要だという所感を感じました。 PHP Internalsの議論の流れを追う中で学びが多く、今回のarray_first / array_last以外の議論も追ってみたいと思いました。興味を持った皆さんも、まずは参考文献のURLからarray_first / array_lastの議論を追ってみてください！ speakerdeck.com パンフレット記事執筆者コメント meihei 「カンファレンスが終わったあとに」というパンフレットを寄稿しました。先日のPHPerKaigiでは多くの学びがあったかと思います。それらを自分の中で、またチームメンバーとともに知識として再構築し、今後さまざまな機会で活かせる武器にしてもらえたら嬉しいです。 パンフレットはマンガで解説していますので、お気軽にお読みください！ 現地で見たセッションを一部紹介 当日イベントに参加した自分含む弊社メンバーが現地で見たセッションのうち特に気になったセッションのレポートです！ 1. 「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜 by 武田 憲太郎さん 高トラフィックを捌く技術的な解決を自信持って行うためにできることを紹介していただきました。アプリケーションコードよりもミドルウェアの話が中心でした。 Keep Alive、Persistent Connection、コネクションプール… 単語は知っているけれど自分が使いこなせていないものがたくさん出てきて非常に勉強になりました。スライドには図やグラフ、コードが添付されていたので難しい内容でも理解しやすかったです。興味のある方はぜひスライドだけでもみていただきたいです。オススメです。 自分は登壇の中で武田さんがおっしゃっていた「計測は仮説を持って行う」という言葉が印象に残っています。また、登壇を聞きながらシステムの接続はとても奥が深く技術者の腕の見せ所なのではないかと考えました。 (BASE Order Section @Capi) 2. プログラミング言語論から覗くPHPの正体 by うさみけんたさん 「PHPがどんな歴史を積み重ね、今の書き方になったのか」を紐解いていきました。PHPがゆるふわ言語というのは自分もなんとなく理解していますが、想像以上にゆるふわ言語であることを知り、PHPらしさを再度認識する良い機会になりました。 また、登壇の中ではPHP作者Rasmus Lerdorf(ラスマス・ラードフ)氏の発言を取り上げていました。言語作者の人となりを知るのも面白いなと登壇を聞きながら考えました。なぜ言語が作られたのか、どんな思想で言語が成長してきたのかを知ることでその言語への愛着が強まります。 登壇で出てきたこのスライドが自分は好きです笑 (BASE Order Section @Capi) 3. 俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために by 髙橋直規さん 持続可能なチーム開発を目指す中で、「アーキテクチャを刷新する必要があるが、トップダウンで決めるのは避けたい」という背景から、「最強アーキテクチャ決定戦」を開催したという内容のライトニングトークでした。 2人程度で似たようなイベントを開催したことはありましたが、経験値に差があるチームで実施したことはなかったため「すべての処理を神メソッドで実現する」という提案のハードルを下げるための工夫や、イベントの流れなど開発チームの運営において大変参考になる内容が多かったです。（Pay ID Engineering Section 岡部 @rerenote） 4.AI時代の脳疲弊と向き合う ~言語学としてのPHP~ by さくらいさん 日々の業務の中で、何かしらAIとやりとりする機会が増えています。その中で、抽象的な内容を具体的な表現に落とし込む場面が以前より多くなっていると感じていました。また、AIと長時間やりとりした後に強い疲労感を覚えることも増えてきています。 このライトニングトークでは、こうした疲れがどこから生じるのか、そしてその対策について解説されていました。対策の中でも「意識して時間を使い分ける」はすぐに実践できそうだと感じ、早速取り入れています。以前と比べて、疲労感を覚える場面が少なくなってきたように感じています。（Pay ID Engineering Section 岡部 @rerenote） おわりに 去年に引き続きレポーターとしてPHPerKaigiに参加させていただきました。 今年も協賛活動、社員のスピーカー参加を通して PHPコミュニティの盛り上がりに貢献でき、弊社としても大変有意義な時間となりました。 スタッフの方々には業務でお忙しいにも関わらず、多くの時間をイベント準備へ注いでいただいたかと思います。この場を借りて御礼申し上げます。