本ブログは 2026 年 7 月 20 日に公開された AWS Blog “ Introducing the Amazon GuardDuty investigation agent: on-demand AI-powered threat assessment ” を翻訳したものです。 Amazon GuardDuty の新しい調査エージェント (現在パブリックプレビュー) は、 Amazon Web Services (AWS) 環境全体のセキュリティ検出結果を調査し、調査にかかる時間を数時間から数分に短縮します。 GuardDuty は、AWS アカウントとワークロードを継続的にモニタリングして、不審なアクティビティ、悪意のある可能性のあるアクティビティ、不正な動作を検出するマネージド型の脅威検出サービスです。可視化と修復のために詳細なセキュリティ検出結果を提供します。 単一の不審な検出結果を調査する場合でも、組織全体のセキュリティポスチャを評価する場合でも、調査エージェントはリスクレベル、信頼度スコア、具体的な対応につながる推奨事項を含む構造化された評価を提供します。 セキュリティチームは、セキュリティ検出結果の調査や複数のツールにまたがるデータの関連付けに何時間も費やすことがあります。GuardDuty 調査エージェントはこの関連付けを自動化し、すぐに対応に活かせるインテリジェンスを提供します。この機能は GuardDuty に直接組み込まれており、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、AWS API、または AWS SDK を通じてオンデマンドでアクセスできます。 この記事では、以下の内容を説明します。 GuardDuty コンソールで調査エージェントを有効化する コンソールまたは AWS CLI を使用して最初の調査を作成する AWS MCP サーバーと調査エージェントを組み合わせて、AI 支援型のセキュリティオペレーションを実現する GuardDuty 調査エージェントの主な機能 GuardDuty 調査エージェントは、GuardDuty で既に使い慣れたパターンに沿った API を提供します。完了した各調査は、リスクレベル、信頼度評価、 MITRE ATT&CK® テクニックマッピング、リソースマッピング、優先順位付けされた推奨事項を返します。 コンソールからは、特定の検出結果、アカウント、または組織全体のすべてのアカウントを対象に調査のスコープを設定できます。また、AWS CLI と API では、最大 2,048 文字の自由形式のトリガープロンプトを受け付けます。これにより、調査対象を自然言語で記述し、懸念事項、疑わしい根本原因、調査の優先事項を指定して、エージェントの分析をガイドできます。 調査エージェントの API は、 Agent Toolkit for AWS の一部である公式の AWS MCP サーバー経由でも利用できるため、既存のセキュリティツールチェーンや AI を活用したワークフローに統合できます。エージェントを直接管理したり操作したりする必要はありません。API エンドポイントを呼び出すと、エージェントが検出結果を調査し、証拠を関連付け、複雑な設定を管理する必要なく評価を提供します。 調査エージェントによる検出結果の分析の仕組み 調査を作成すると、エージェントはクロスリージョン推論を使用してスコープに基づいて検出結果を処理し、構造化された出力を生成します。 クロスリージョン推論 – GuardDuty の調査は Cross-Region Inference Service (CRIS) を使用します。CRIS は、お客様の地域内で調査の評価を処理するのに最適な AWS リージョンを選択します。データは調査リクエストが発生したリージョンにのみ保存されます。ただし、調査データと概要結果は、そのリージョン外で処理される場合があります。データは、Amazon が提供する安全なネットワーク上で暗号化されて送信されます。 リクエストがルーティングされる可能性のある推論リージョンの詳細については、 Amazon GuardDuty ユーザーガイド の調査セクションにあるクロスリージョン推論ルーティングテーブルを参照してください。 調査の出力 – 完了した各調査では、以下のインサイトが生成されます。リスクレベル (Info、Low、Medium、High、または Critical)、信頼度 (Unknown、Low、Medium、または High)、概要 (検出結果と主な観察事項の説明)、調査の詳細 (追加のコンテキスト)、推奨アクション (AWS CLI コマンドを含む詳細なアクション) です。 アカウントのスコープ設定 – アカウントの指定が必要なのは、特定のメンバーアカウントを調査する場合のみです。組織全体などのより広いスコープの場合、アカウント ID は不要です。エージェントは、後述の認可モデルに従ってアクセスを許可されたアカウント内の検出結果のみを調査します。 前提条件 始める前に、以下の前提条件が満たされていることを確認してください。 アカウントで Amazon GuardDuty が有効になっていること サポート対象リージョンの AWS アカウントがあること (「利用可能なリージョンと料金」セクションを参照) 必要な IAM アクセス許可 3 つの新しいアクセス許可が必要です。新しい調査を開始するための guardduty:CreateInvestigation 、結果を取得するための guardduty:GetInvestigation 、特定のディテクターの調査を表示するための guardduty:ListInvestigations です。 IAM ポリシーの例: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:CreateInvestigation", "guardduty:GetInvestigation", "guardduty:ListInvestigations" ], "Resource": "*" } ] } 認可モデル 管理者アカウントは、自身とメンバーアカウントに対して、調査の作成、結果の取得、調査リストの表示を行えます。メンバーアカウントは、自身のアカウントの結果の取得と調査リストの表示のみが可能です。メンバーアカウントは調査を作成できず、他のアカウントや管理者アカウントに属する調査にはアクセスできません。アカウントの指定が必要なのは、特定のメンバーアカウントを調査する場合のみです。自身のアカウントや組織全体のアカウントを対象とする場合、アカウント ID は不要です。 調査エージェントを有効化して最初の調査を作成する 始める前に、前提条件に記載されている必要な IAM アクセス許可があることを確認してください。 サポート対象のリージョンで AWS マネジメントコンソールを開き、Amazon GuardDuty に移動します ナビゲーションペインで [Investigations] を選択します 図 1: GuardDuty 調査ダッシュボード 調査が有効になっていない場合は、 [Go to Settings] を選択し、 [Enable] を選択して調査を有効にします 図 2: GuardDuty 調査の有効化画面 調査を有効化したら、調査ページに戻ります ナビゲーションペインで [Initiate Investigation] を選択します 図 3: GuardDuty 調査の開始 調査のスコープを選択します GuardDuty Finding ID を入力: 特定の GuardDuty 検出結果を詳しく調査したい場合に使用します AWS Account ID を入力: 特定の AWS アカウントの全体的なセキュリティポスチャを評価したい場合に使用します All accounts : 組織全体のセキュリティ評価や、ラテラルムーブメント (横展開) の可能性を調査する場合に使用します [Initiate investigation] を選択します 図 4: GuardDuty 調査のセットアップ 調査が完了するまで待ちます (プレビュー期間中は、通常アカウントレベルの調査で 2～5 分、特定の検出結果の調査で 10～12 分かかります)。ステータスは自動的に更新されます 調査が完了したら、調査タイトルを選択して評価の全文を表示します 図 5: GuardDuty 調査完了メニュー 調査の評価には、全般情報、調査の概要、マッピング、脅威評価、推奨アクションなど、調査に関する詳細な情報が含まれています。 [General Information] セクションには、調査 ID、ステータス、トリガー元アカウント、作成日時が表示されます。 図 6: 評価の [General Information] セクション [Summary] セクションでは、主な観察事項と検出結果が説明されます。 図 7: 評価の [Summary] セクション [Mapping] セクションには、攻撃手法と影響を受けた AWS リソースが表示されます。 図 8: 評価の [Mapping] セクション (MITRE ATT&CK) [Threat Assessment] セクションには、リスクレベル、信頼度スコア、詳細な脅威分析が表示されます。 図 9: [Threat Assessment] セクション [Recommended Actions] セクションには、優先順位付けされた修復手順が一覧表示されます。 図 10: 評価の [Recommended Actions] セクション 調査は、以下の API エンドポイントを使用して AWS CLI または SDK からも実行できます。 CreateInvestigation – GuardDuty の調査を開始します。セキュリティ検出結果を自動的に分析し、関連するアクティビティを関連付け、アカウントレベルの分析を実行し、推奨される次のステップを含む構造化された調査概要を生成します GetInvestigation – 特定の調査のステータスと結果を取得します。完了時には、エージェントによる評価、関連付けられた証拠、推奨アクションが含まれます ListInvestigations – フィルタリングとページネーションを使って、環境全体の調査を表示します AWS CLI を使用して調査を実行する エージェントは複数のデータソースへのクエリ、サービス間での検出結果の関連付け、AI ベースの分析を実行するため、調査は非同期で行われます。調査を作成した後は、完了するまで定期的にステータスを確認する必要があります。 ステップ 1: ディテクター ID を確認する 各 GuardDuty のデプロイには、アカウントごと、リージョンごとに一意のディテクター ID があり、これによってお客様固有の GuardDuty 設定が識別されます。このディテクター ID はすべての AWS CLI オペレーションで必要になります。特に複数のリージョンで GuardDuty を有効にしている場合は注意が必要です。ディテクター ID は、GuardDuty コンソールの [Settings] で確認するか、リージョンを指定して以下のコマンドを実行することで確認できます。例えば、対象の GuardDuty ディテクターが us-east-1 (バージニア北部) リージョンにある場合は次のように実行します。 aws guardduty list-detectors –-region=us-east-1 想定されるレスポンス: { "DetectorIds": [ "12abc34d567e8fa901bc2d34eexample" ] } 注記: レスポンスの DetectorID の値は、以降のすべてのコマンドで使用します。 同じリージョンでのみ作業する場合は、繰り返しの入力を避けるため、セッションで環境変数を設定することもできます。例えば Linux では次のようにします。 export AWS_DEFAULT_REGION=us-east-1 その他のオペレーティングシステムでの設定方法については、 AWS CLI のドキュメントを参照してください。 ステップ 2: 調査を作成する 以下は、特定の検出結果を調査するコードの例です。 aws guardduty create-investigation us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt "Investigate this finding ID 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6" --trigger-prompt パラメータは、GuardDuty のメタデータには含まれておらず、API 経由でも取得できないコンテキストがある場合に役立ちます。 想定されるレスポンス: { "InvestigationId":"a1b2c3d4-5678-90ab-cdef-ef1234567890" } AWS アカウント全体の検出結果を調査するには、以下の例を使用します。 aws guardduty create-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt “Investigate findings in Account 123456789012” 組織全体の検出結果を調査するには、次のようにします。 aws guardduty create-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --trigger-prompt “Investigate findings across my AWS Organization” ステップ 3: 調査のステータスを確認する 以下のように、 AWS CLI の --query オプションを使用して出力をフィルタリングし、 Status セクションのみを簡潔に表示して、調査のステータスを確認します。 aws guardduty get-investigation –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --investigation-id a1b2c3d4-5678-90ab-cdef-ef1234567890 --query 'Investigation.Status' Status フィールドに COMPLETED と表示されるまで、このコマンドを繰り返し実行します。 完了時のレスポンス出力の例: { "Investigation": { "InvestigationId": "a1b2c3d4-5678-90ab-cdef-ef1234567890", "Status": "COMPLETED", "TriggerPrompt": "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012", "TriggeredBy": "123456789012", "RiskLevel": "Critical", "Risk": "Active multi-stage runtime compromise on EKS worker node with root-privileged reverse shell, Docker socket access, malicious file execution, and 500 multi-tactic runtime signals — behavioral evidence is consistent with a genuine intrusion.", "Confidence": "High", "Summary": "{\"keyObservations\":{\"title\":\"...\",\"narrative\":\"...\",\"observations\":[...]},\"countermeasures\":[...],\"threatAssessment\":{...}}", "Cloud": { "Provider": "AWS", "Region": "us-east-1", "Account": "123456789012" }, "Metadata": { "Product": { "Name": "AmazonGuardDuty AI Analyst", "Feature": "Investigation" }, "Version": "1.0.0" }, "StartTime": 1705319400.0, "EndTime": 1705319700.0 } } ステータス値 – RUNNING 、 COMPLETED 、 FAILED 所要時間 – 調査時間は変動することがあります。30 秒ごとにステータスを確認すれば結果を得るのに十分です ステータスが FAILED の場合 – レスポンス内のエラーメッセージを確認し、アクセス許可が認可モデルの要件を満たしていることを確認してください 特定のディテクターのすべての調査を一覧表示するには、以下を実行します。 --max-results オプションは省略可能ですが、返される結果の数を絞り込むのに便利です。 aws guardduty list-investigations –-region=us-east-1 \ --detector-id 12abc34d567e8fa901bc2d34eexample \ --max-results=10 手動で調査を実行するだけでなく、API ファーストの設計により、GuardDuty の検出結果をサードパーティのツールに送信するという一般的なお客様のパターンにも対応しています。既存のパイプラインに自動調査を追加できるため、チームは生のアラートではなく、コンテキストが付加され優先順位付けされたインテリジェンスを受け取れます。 GuardDuty の検出結果を Amazon EventBridge 経由でセキュリティ情報およびイベント管理 (SIEM) プラットフォームにルーティングし、アナリストが各アラートを手動で調査しているお客様を考えてみましょう。調査エージェントを使用すると、パイプラインに AWS Lambda 関数を組み込み、検出結果 ID を指定して CreateInvestigation を呼び出し、完了を待ってから、コンテキストが付加された結果 (リスクレベル、信頼度スコア、MITRE ATT&CK マッピング、推奨アクション) を元の検出結果とともに SIEM に転送できます。Critical の検出結果は、さらなる分析や自動化のために、お客様のインシデント対応キューに直接ルーティングされます。信頼度の高い低リスクの検出結果は、自動的にクローズしたり、週次レビュー用にまとめたりできます。これにより、アナリストは繰り返しのログ関連付け作業から解放され、評価の検証と確認済みの脅威への対応に時間を使えるようになります。 このパターンは、API や EventBridge のメッセージングを使用するようにカスタマイズできる SIEM、チケットシステム、自動化プラットフォームで機能します。調査エージェントは、パイプラインの最終地点としてではなく、処理ステップとして組み込むことができます。 このエージェントは、GuardDuty の検出結果を調査するようにファインチューニングされており、 AWS Security Agent や AWS DevOps Agent といった他の AWS フロンティアエージェントとは異なるものです。調査エージェントのスコープは、GuardDuty の検出結果に特化した分析を提供することに絞られています。 AWS MCP サーバーとの統合 Model Context Protocol (MCP) は、AI アシスタントが外部のデータソースやツールに安全に接続できるようにするオープン標準です。AWS MCP サーバーはこの標準を AWS のサービス向けに実装しているため、Kiro、Anthropic の Claude、その他の MCP 対応クライアントなどのツールを使用して、AI を活用したワークフローに GuardDuty の調査を組み込めます。 AWS MCP サーバーを設定する MCP クライアントが AWS MCP サーバー に接続するように設定します 自然言語を使用して調査を呼び出します (例: 「アカウント 123456789012 の最近の Unauthorized Access の検出結果を調査して」 ) MCP クライアントを通じて返される調査結果を確認します。結果は、使用するモデルやエージェント、設定、AI の非決定的な性質によって異なる場合があります 結果を既存のエージェント自動化に統合するか、検出結果に基づいて手動で対応します。 その他の使用例 「本番アカウントの最新の重要度が高い検出結果を調査して」 「アカウント 987654321098 の検出結果 ID abc123 の調査を作成し、何が起きたかを要約して」 「過去 24 時間の調査を一覧表示し、人によるレビューが必要なものにフラグを付けて」 調査エージェントと AWS Security Incident Response の関係 re:Invent 2024 で、AWS は AWS Security Incident Response (AWS SIR) を発表しました。これは、セキュリティインシデントへの準備、対応、復旧を迅速に行うためのマネージドサービスです。AWS SIR と GuardDuty 調査エージェントは、セキュリティワークフローの異なる段階に対応しています。GuardDuty 調査エージェントは、オンデマンドの評価機能を提供します。特定の検出結果、アカウントのセキュリティポスチャ、または組織全体のセキュリティポスチャについてより深いコンテキストが必要な場合に、調査を作成すると、リスクレベル、信頼度スコア、MITRE ATT&CK® テクニックマッピング、具体的な対応につながる推奨事項を含む構造化された評価が得られます。セキュリティアナリストはこれを使用して、GuardDuty が検出した内容の範囲と重大度をすばやく把握できます。 AWS SIR で AWS がサポートするケースを作成すると、SIR の調査エージェントがアクティブになり、AWS Security Incident Response のエンジニアと並行して証拠を収集し、数分以内に調査の概要を提供します。AWS SIR は、封じ込めと復旧を調整するために AI を活用した自動化と人間の専門知識の両方が必要となる、進行中のセキュリティイベントに特化して構築されています。 セキュリティチームはこれらの機能を活用することで、GuardDuty 調査エージェントによるオンデマンドでの検出結果の評価と優先順位付け、裏付けとなる証拠を添えた確認済みの問題の関係者へのエスカレーション、さらに追加のサポートが必要な場合には AWS がサポートするケースの作成または更新による AWS SIR チームの迅速な関与を実現できます。 利用可能なリージョンと料金 GuardDuty 調査エージェントのパブリックプレビューは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (パリ)、欧州 (ストックホルム)、アジアパシフィック (東京) を含む 10 の AWS リージョンで利用できます。 パブリックプレビュー期間中は、調査エージェントを無料で利用できます。使用量は、アカウントあたり 1 日 10 件の調査に制限されており、プレビュー期間中のアカウントあたりの累計上限は 100 件です。失敗した調査はこれらのクォータにはカウントされません。 今すぐ検出結果の調査を始める Amazon GuardDuty 調査エージェントは、調査にかかる時間を数時間から数分に短縮し、セキュリティチームが手動での関連付け作業ではなく、確認済みのセキュリティイベントに集中できるようにします。 開始手順 GuardDuty コンソールで調査エージェントを有効化する 最近の GuardDuty の検出結果を使用して最初の調査を作成する リスクレベルや推奨される次のステップを含む、構造化された評価を確認する AWS MCP サーバーを使用している組織では、お好みの AI アシスタントで自然言語を使って調査を呼び出すこともできます。 詳細情報 Amazon GuardDuty 調査エージェントのドキュメント – 設定と使用方法の詳細なガイダンス GuardDuty の IAM アクセス許可リファレンス – 調査オペレーションに必要なアクセス許可 Amazon EventBridge ユーザーガイド – 調査イベントを下流のシステムにルーティングする方法 MITRE ATT&CK® フレームワーク – 入門リソース AWS Security Incident Response – AWS セキュリティブログの記事 AWS Activation Days – AWS を使用して成果を達成するための具体的なガイダンスを提供する、今後開催される無料イベントに関する情報 Allan Holmes Allan は、セキュリティとコンプライアンス、ネットワーキング、DevOps にわたる 20 年以上の経験を持ち、現在はセキュリティスペシャリストとして活躍しています。この経験により、クラウドセキュリティの課題を包括的な視点で捉えることができます。AWS、ISC2、CompTIA の複数の技術認定資格と MBA を保有しており、深い技術的専門知識とビジネス戦略の橋渡しを行っています。仕事以外では、熱心なガーデナーであり電子工作愛好家でもあり、革新的なテクノロジーを実際に手を動かして探求することを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

はじめに こんにちは！トモニテで開発をしている吉田です。 2026/3/20〜2026/3/22に開催されたPHPerKaigi 2026にスタッフとして参加してきました！ PHPerKaigi（ペチパーカイギ）とは以下のようなイベントです！ PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、 現在PHPを使用している方、過去にPHPを使用していた方、 これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、 技術的なノウハウとPHP愛を共有するためのイベントです。 phperkaigi.jp しかしながら私自身、普段の業務でPHPは書いていません。どうして私が今回参加したのか、PHPを書いていない私が参加してどうだったのか書いていきます。 参加経緯 一番初めのきっかけは昨年開催されたiOSDC 2025で当日スタッフをしたことです。普段はGo言語やTypeScriptを書いていてiOSとは無縁でしたが、スタッフとして参加できました。 iOSDCとPHPerKaigiは実行委員長が同じです。その関係でiOSDC 2025終了後にスタッフの方からPHPerKaigiのスタッフについても話を聞いて、ぜひやってみたいと思い参加させてもらうことにしました！ そんな私がどうして普段触る技術領域以外のカンファレンスでスタッフをしているのか。それは 仕事をしてるだけだと出会わない人たちと出会ってみたい！新しい世界を知りたい！ と思ったからです。 ここからは実際に参加してみての感想を書いていきます。 参加してみて スタッフについて スタッフにはコアスタッフと当日スタッフの2種類があります。当日スタッフは会期前に事前の顔合わせを行い、当日の運営を担当します。コアスタッフは開催に向けて早い段階から事前準備を進めていてます。 私はコアスタッフとして参加しました。事前準備では名札を首から下げるためのストラップ制作を担当しました。 会期中はTrack Aを担当し、セッションごとに司会や演出を担当したりしていました。演出は場面に応じてスクリーンに映す内容を切り替えるといった役割です。 Track Aではオープニングや通常セッションに加えて、PHPer コードバトルやルーキーズLT、LT大会といった多様なコンテンツが行われていました。 もちろんメインは担当としての仕事ですが、シフトの合間にはスポンサーブースを回ったり、セッションも聞いていました。PHPのカンファレンスではありますが、スピーカーが話す内容はPHPを書いていないと分からないということはなく、それぞれが課題に対してどういうアプローチを取ったのかという手法の部分は、普段の技術領域にも活かせることがあるのではと感じました。 聞いたもの全て興味深かったのですが、特に面白かったものを紹介します。 PHPer コードバトル PHPer コードバトルは、指示された動作をする PHP コードをより短く書けた方が勝ちという 1 対 1 の対戦コンテンツです。予選を勝ち上がったプレイヤー6名がトーナメント形式で対決します。 スコアはコードの空白を除去したバイト数になります。 普段のサービスを動かすためのコードとはまた違うテクニック的な要素も必要になります。 ルールは分かるのですが、正直プレイヤーが具体的にどんなテクニックを使っているのかは分かりません（笑）。 ただ、会場のスクリーンにはリアルタイムにプレイヤーが書いているコードやその瞬間のプログラムサイズが表示され、解説者による解説があります！ 個人的にはさながらスポーツ観戦をしているような臨場感で、プレイヤーが大きくプログラムサイズを減らすと会場がどよめくような瞬間もありました。 何より解説があるのでプレイヤーがどういう工夫をしているのか観戦者も知ることができます。 私がコードバトルで学んだのは && と and は優先順位が違うということです。いつかどこかで役立てたいと思います。 参考： PHP: 論理演算子 - Manual コードバトルはシフトが当たっていなくても会場に見に行っていたくらい面白かったです。Track Aの担当にならなければ見ることはなかったと思うので、スタッフをやったからこそ知れた面白さでした！ ルーキーズLT/LT大会 ルーキーズLT大会はPHPerKaigiで初めてトークする「ルーキー」たちによる5分のショートトーク、LT大会はスピーカーを限定しないLT大会です。LT大会では参加者がペンライトを振る場面があるのですが、これが会場にとても綺麗な彩りを添えていました！ 特に印象に残ったトークを2つ紹介します。まずルーキーズLTから： AI時代の脳疲れと向き合う「言語学としてのPHP」 - プロポーザル / 登壇資料 AI疲れは私自身実感していましたが、それを言語学の観点から考察しているのが新鮮で勉強になりました。ハイコンテキストな日本語話者がローコンテキストな指示を出そうとしていて、これが疲れの原因らしいです...。 「なんでこんな疲れるんだろう...」の原因を知ることができたので、これからは対策が取れそうです。 LT大会からは以下のトークです。 よし、PHPで円でも描いてみるか - プロポーザル / 登壇資料 PHPerKaigi 2024の登壇でもらった質問から「PHPで円を書いてみよう」ということになったそうです！ Webやコンソールで描いてみたり、途中では電子工作をされていたり、最終的にはアニメーションする円を実現されていたりと、多種多様な円をPHPで描かれていました。実現過程も面白かったですが話術もすごくてたくさん笑わせてもらいながら聞いていました。 最後に PHPを書いていない私でも参加してみてどうだったかというと、十分に楽しめたし学びもありました。セッションで語られる課題へのアプローチは言語を問わず通じるものが多く、普段の開発にも持ち帰れる気づきがありました。また、コードバトルのようにスタッフとしてTrack Aを担当したからこそ出会えたコンテンツもあり、「仕事をしてるだけだと出会わない人たちと出会ってみたい、新しい世界を知りたい」という動機は十分に満たされました。 これからもカンファレンスのスタッフ活動を続けていきたいと思います！

作業の合間に窓の外を眺めることはありますか？ 筆者の席は会社のビルの西側で、午後になると大きな窓から強烈な西日が射し込んできます。 それがあまりに強烈なので、いつもブラインドが閉まっていて外があまり見えません。 そのせいでオフィス内の移動中などに窓から見えた空が真っ暗で驚くということがよくあります。それで困るというわけではありませんが、少し味気ない感じがします。 空の色で時間の移ろいを感じたい。 隙間から覗くこともある というわけで、机に置いて空の色で時間帯を知らせてくれるデバイスを作ることにしました。それだけでもつまらないので、机の上にあったら嬉しいポモドーロタイマーの機能も付けてみ