はじめに 2025年はAIエージェントによるコーディングがかなり浸透した1年だったのではないでしょうか。Claude Code、GitHub Copilot、Cursor をはじめとするAIエージェントによるコード生成ツールが普及する中、現場のエンジニアは実際にどのような効果を実感し、どのような課題に直面しているのでしょうか。 本レポートでは、2025年12月末に社内のエンジニア・マネージャー約100名を対象に実施したアンケート調査の結果をもとに、 満足度・生産性・コード品質・スキル向上 の4つの観点からAIツールの活用実態を分析します。 主な発見 観点 結果 満足度 約9割が満足、NPS +32と高い推奨意向 生産性 約65%が1日1時間以上を節約、バグ対応・コード理解で特に効果を実感 コード品質 「やや高い」が最多だが、約9割が何らかの修正を実施 スキル 新技術習得は加速する一方、「自力で書く力」への懸念も約4割 経験年数による傾向 若手〜中堅層（1〜5年） ：満足度・生産性向上の実感が高い一方、スキル低下への懸念も強い ベテラン層（10年以上） ：慎重な評価だが、確立されたスキルの上でAIを活用 以下、各セクションで詳細を見ていきます。 回答者の基本情報 社内エンジニア・マネージャー約100名から回答を得ました。 項目 概要 職種 バックエンド・フロントエンド中心、インフラ・マネジメント・モバイルも多数 経験年数 1〜10年がボリュームゾーン（詳細は下図） 使用言語 TypeScript/JavaScript最多、Ruby・PHP・Pythonが続く 利用ツール GitHub Copilot と Q Developer/Kiro で約8割 利用頻度 約7割が「ほぼ毎日」、週3〜4日含め9割超が日常的に活用 経験年数 使用言語 利用頻度 AIツールへの満足度 AIツールに対する満足度を「全体満足度」「期待との比較」「同僚への推奨度（NPS）」の3軸で調査しました。結果として、 全体的に高い満足度 が確認されましたが、一部に注意すべき声も見られました。 約9割が「満足」と回答 全体満足度では、 合計約90%が満足 と回答しました。「非常に不満」はゼロであり、AIツールが日常業務に定着していることを裏付けています。 期待を上回る効果を実感 導入前の期待と比較して、 約65%が期待以上の効果を実感 しています。「期待通り」を含めると96%以上がポジティブな評価であり、導入判断が正しかったと言えます。 NPS +32：高い推奨意向 同僚への推奨度を問うNPS調査では、平均スコアが 約8.0 、NPSは +32 となりました。これは「良好」とされる水準であり、多くのエンジニアが同僚にも利用を勧めたいと考えています。 推奨の声と懸念の声 推奨する理由（抜粋） 壁打ち相手として最適 AIツールがなかった時代にはもう戻れない 懸念・注意点（抜粋） 使い方を誤ると逆効果。リテラシーが必要 自分で考える時間が減り、成長が滞る可能性 PRが増えてレビュー負荷が高まっている これらの声から、AIツールは 「使いこなせば強力な武器」 である一方、 組織としての運用ガイドラインや教育 が求められていることが読み取れます。 経験年数による回答の傾向 経験年数 平均スコア 推奨者(9-10) 中立者(7-8) 批判者(0-6) 1年未満 8.4 50% 43% 7% 1〜3年 8.2 50% 35% 15% 3〜5年 8.3 45% 45% 10% 5〜10年 8.0 42% 46% 12% 10年以上 6.9 22% 45% 33% 経験年数別に観察しますと、 若手〜中堅層（1〜5年）は特に高い満足度 を示していました。「非常に満足」の割合は38〜43%、NPS平均も8.0〜8.4と高水準でした。学習効率の向上や開発スピードの改善を実感している声が多く見られました。 ベテラン層（10年以上）はやや慎重な評価 となりました。「非常に満足」は22%にとどまり、NPS平均も6.9と他層より低い結果です。自由記述では「AIの出力を見抜く力が必要」「本人ができないことをAIで補う使い方には懐疑的」といった声があり、 AIツールの限界を理解した上での活用 を重視していることがうかがえます。 生産性への影響 AIツールの導入により、エンジニアの日常業務はどのように変化したのでしょうか。時間節約効果、業務品質の変化、そして残された課題について詳しく見ていきます。 1日1〜2時間の節約が最多、「2時間以上」も4人に1人 「AIツールにより1日あたりどの程度の時間を節約できているか」を尋ねたところ、 最も多かったのは「1〜2時間」で約38% でした。さらに 「2時間以上」と回答した人も約24% に達し、AIツールが単なる補助ではなく、業務時間を大幅に短縮する「生産性を向上させるツール」として機能しています。 ただし「ほとんど節約できていない」という回答も存在し、ツールの活用度合いや業務内容によって効果に差があることも示唆されています。 5つの業務指標すべてで改善傾向 導入前後の変化を5段階評価で調査した結果、 すべての項目で「向上」「やや向上」が過半数 を占めました。 ただし「集中状態（フロー）への入りやすさ」は改善効果が限定的 で、「向上」は約45%にとどまり、「やや悪化」も約12%存在します。AIとの対話や提案の確認作業が集中を中断させること、また生成待ち時間に別作業を行うようになったことが要因と考えられます。 課題の中心は「AIの限界」と「検証コスト」 AIツール利用時に感じる課題を複数選択で尋ねたところ、 上位3つは以下の通り でした。 コンテキストの理解が不十分 （約45%） AIの出力を検証する負担が大きい （約40%） セキュリティ面での不安 （約38%） これらの課題は相互に関連しています。AIがプロジェクト固有の文脈を十分に理解できないと、ロジックの誤りや不適切なコードが生成されやすくなります。その結果、開発者はAI出力の検証に多くの時間を割く必要があり、見落としによるセキュリティリスクへの不安にもつながっていると考えられます。 AIが最も力を発揮するのは「バグ対応」と「コード理解」 「生産性向上に最も貢献している作業」を上位3つまで選択してもらった結果、 問題解決（バグ対応）や理解支援 といった「思考を補助する」用途で高く評価されています。エンジニアがAIを「コードを書かせる道具」ではなく、 「一緒に考えるパートナー」 として活用し始めていることを示しています。 コード品質への影響 生産性の向上が確認された一方で、「品質は犠牲になっていないか？」という懸念もあります。本セクションでは、AIツールが生成するコードの品質評価と、導入後の品質指標の変化を詳しく見ていきます。 品質評価は「やや高い」が最多——ただし検証は必須 AIが生成するコードの品質について、 「やや高い」が約50% で最多となりました。一方で「普通」も約40%を占め、 「非常に高い」はわずか約3% にとどまっています。 この評価を裏付けるように、出力の検証・修正状況では 約9割が何らかの修正を加えている と回答。「ほぼそのまま使用」はわずか2%でした。 注目すべきは、 「大幅な修正が必要」がゼロ だった点です。AIの出力は「使い物にならない」レベルではなく、 「手直しすれば十分使える」品質 といえます。エンジニアはAIを「完璧なコードを生成する」ものではなく、 「たたき台を素早く作るツール」 として活用しているようです。 経験年数による傾向：若手ほど「改善」を実感 経験年数別に品質評価を分析すると、 若手〜中堅層（1〜5年）は「やや高い」の割合が高く 、AIツールの品質に対して好意的な評価を示しています。一方、 ベテラン層（10年以上）は「普通」「やや低い」の割合が相対的に高く 、より厳しい目で品質を評価していることがうかがえます。 これは満足度セクションで確認された傾向と一致しており、ベテラン層が 「AIの出力を見抜く力が必要」 と考えていることの表れと考えております。 学習・スキルへの影響 AIツールの活用は、エンジニアのスキル向上にどのような影響を与えているのでしょうか。本セクションでは、スキルへの影響、依存への懸念、そして今後の利用意向について詳しく見ていきます。 新技術の習得速度が最も向上、一方で「自力で書く力」には懸念 スキル向上への影響を4つの観点から調査した結果、 項目によって明暗が分かれる 結果となりました。AIツールが「学習のハードルを下げる」役割を果たす一方で、頼りすぎによる基礎力低下のリスクが懸念されています。 自由記述では以下のような声が見られました。 学習効率向上を実感する声： 他チームメンバーに聞かなくても、壁打ち相手になってくれるので、自身の理解向上やチームの生産性向上に大きく貢献しているため スキル低下への懸念を示す声： 仕事自体は進むが、成長の側面で考えると良くないと感じる部分も多いため スピードや品質は向上するが、深く理解しないままAIで一定のコードや正解らしき情報が出力されるため、自分で深く考えたり調査したりする時間が減り、技術的な成長が滞るため 約4割が依存に「懸念あり」——ただし意見は二分 AIツールへの依存について尋ねたところ、 約45%が何らかの懸念を示しました 。一方で、 「あまり懸念なし」「全く懸念なし」も約39% と拮抗しており、エンジニアの間で意見が分かれています。 自由記述では、懸念の有無にかかわらず 「使い方次第」 という認識が共通して見られました。 利用できるのであれば、使わない理由はないと思っている。ただし、エンジニアとしての今後の成長を考えるのであれば、利用範囲、パターンは考えた方が良いとは思っている また、経験年数による活用の違いを指摘する声もありました。 エンジニア歴が非常に浅い人には鵜呑みにしてほしくないと思っています。理由は書いたコードの説明ができない程、自分の頭を使わないようになってコードに責任を持てない可能性がある為です。歴が長い人であれば生成されたコードが期待通りなのかそうではないのか判断がつくのでお勧めできます 一見万能に見えるが、正しい使い方を知らなければかえって効率が悪くなる。また、手作業の方が早いタスクもある。ただ使うだけで他メンバーに迷惑をかけるような人材には勧めない。リスクやデメリットもしっかりあるものだと理解している人だけに勧めたい 経験年数による傾向：若手ほど「自力で書く力」への悪影響を実感 経験年数 自力で書く力に「悪影響」「やや悪影響」と回答した割合 1年未満 約40% 1〜3年 約50% 3〜5年 約55% 5〜10年 約40% 10年以上 約35% 興味深いのは、 1〜5年目の若手〜中堅層で「自力で書く力への悪影響」を感じる割合が高い 点です。基礎スキルを習得・定着させる時期にAIツールに頼りすぎることへの自覚があると考えられます。 一方、ベテラン層（10年以上）は「悪影響」の割合が相対的に低く、 すでに確立されたスキルの上にAIを活用している ため、悪影響を感じにくい傾向がうかがえます。 継続利用意向は97%——「なくてはならないツール」へ 今後の継続利用意向を尋ねたところ、約97%が継続利用を希望しています。スキルへの懸念がありながらも継続利用を希望する声が圧倒的多数であることから、AIツールは 「課題を認識しつつも手放せない存在」 になっていることがわかります。 組織への要望：「ガイドライン整備」が最優先 AIツールの活用促進のために組織に取り組んでほしいことを尋ねた結果、 上位は以下の通り でした。 順位 取り組み内容 選択率 1位 利用ガイドライン/ベストプラクティスの整備 約55% 2位 セキュリティポリシーの明確化 約40% 3位 効果的な活用事例の共有 約38% 4位 社内勉強会・ナレッジ共有の機会 約32% 5位 ライセンスの追加付与 約30% 6位 新しいツールの試験導入 約28% 「利用ガイドライン/ベストプラクティスの整備」が過半数を超え、最も強く求められている ことがわかります。これは生産性セクションで確認された「社内ルール/ガイドラインとの整合性」への課題意識と一致しています。 自由記述でも、組織としての取り組みを求める声が見られました。 間違いなくAIを使った方がいいが、各個人単位ではなくPJや組織としてのAIを活用する前提での開発フローの共有が欲しい 今後に向けて AIツールの効果を最大化し、リスクを最小化するためには、以下の取り組みが求められます。 重点施策 1. 利用ガイドラインの整備 サイボウズ株式会社の新人研修資料 では、「裏取りは必ず行うこと」と明記し、AI出力を盲信しない姿勢を研修段階からエンジニアに伝えています。 弊社でも、セキュリティポリシーの明確化に加え、AI出力の検証プロセスをガイドラインとして整備していきます。 2. ナレッジ共有の促進 READYFOR株式会社のアンケート では、組織に求めるサポートとして「チーム内での経験・課題共有の場」が67%と高い割合となっています。 弊社のアンケートでも同様の声が見られました 。 また、 株式会社エブリー では、AIツールを用いた開発効率化の勉強会を開催し、知見を共有しています。 弊社でも、効果的な活用事例や失敗事例を共有する場を定期的に設けていければと考えております。 3. スキル育成との両立 本アンケートでは、1〜5年目の若手〜中堅層で「自力で書く力への悪影響」を感じる割合が高い結果となりました。この課題に対し、他社では以下のようなアプローチを取っています。 フリー株式会社 : 新卒研修を「前半6週間はAI禁止」「後半5週間はAI全力活用」の2段階構成とし、基礎スキル習得とAI活用のバランスを設計 クラウドエース株式会社 : AIの出力に対する「なぜこの実装なのか」を問う習慣化を徹底し、AIの言いなりにならない開発者を育成 弊社でも、特に若手層に対する基礎力強化の機会を確保しつつ、AI活用スキルを高める両輪のアプローチを検討していきます。 継続的な改善に向けて 定量的な効果測定 今後はアンケート結果だけでなく、ツールの使い方を定量的にメトリクスをもとに分析していきます。 フリー株式会社のAI駆動開発2025レポート では、トークン消費量やリクエスト数などの定量データを継続的に測定しています。 組織的な推進体制 組織戦略としては、 合同会社DMM.comのAX戦略 や フリー株式会社の組織設計 も参考に、組織全体での利活用を促進する仕組みを整えていきます。 おわりに AIは「完璧なコードを書く」ツールではなく、 「たたき台を素早く作り、一緒に考えるパートナー」 です。この認識のもと、組織として適切な活用体制を整えていきます。 最後までお読みいただき、ありがとうございました。

こんにちは。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のライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

みなさん、こんにちは。 いなりく です。 新年あけましておめでとうございます。みなさん Kiro ライフをいかがお過ごしでしょうか。 Kiro CLI 1.24.0 では、 大規模なドキュメントセットの段階的な読み込みを可能にする Skills 、 カスタム Diff ツール 、 18 言語に対応した組み込みコードインテリジェンス 、 リモート認証 、 web_fetch ツールの詳細な権限管理 、 長時間のセッションをスムーズに維持する会話 圧縮の詳細なコントールが導入されました。これらのアップデートが私の Kiro ライフを更に快適にしてくれたので、今回はこれらの追加された機能を深堀ってご紹介します。Kiro って何？という方は「 Kiroweeeeeeek in Japan 開催のお知らせ 」を読んでいただけると Kiro の全体像を掴んでいただけると思います。気になるアップデートのセクションおよび移行ガイドだけを読んでいただいても問題ありません。Kiro CLI の v.1.21.0 から v.1.23.0 までのアップデートに関しては「 Kiro CLI 新機能まとめ : v1.21.0 から v1.23.0 」をぜひお読み下さい。 アップデート１ : Skills による段階的なコンテキスト読み込み アップデート２ : カスタム Diff ツール アップデート 3 : AST パターンツールによる正確なリファクタリング アップデート 4 : 改善されたコードインテリジェンス アップデート 5 : 会話圧縮の詳細なコントロール アップデート 6 : web_fetch ツールの詳細な URL 権限管理 アップデート 7 : リモート認証 移行ガイド アップデート 1 : Skills による段階的なコンテキスト読み込み Skills は起動時にはメタデータ（名前と説明）のみが読み込まれ、エージェントが必要と判断したときにのみ完全なコンテンツが読み込まれます。これにより、コンテキストウィンドウを効率的に管理しながら、広範なドキュメントへのアクセスを提供できます。 Skills の仕組み 従来の Steering ファイルは、エージェント起動時にすべてのコンテンツをコンテキストウィンドウに読み込みます。これは小規模なファイルには適していますが、大規模なドキュメントセットではコンテキストウィンドウを圧迫してしまいます。 Skills は以下のアプローチを採用しています。 起動時 ：名前と説明のみが読み込まれる 実行時 ：エージェントが関連性を判断し、必要に応じて完全なコンテンツを読み込む 効率性 ：使用されないドキュメントはコンテキストを消費しない Skills ファイルの作成 Skills ファイルには、YAML フロントマターで記述された説明的なメタデータが必要です。エージェントが完全なコンテンツを読み込むタイミングを確実に判断できるよう、具体的な説明を記述してください。 --- name: dynamodb-data-modeling description: DynamoDB データモデリングのベストプラクティスガイド。DynamoDB スキーマの設計または分析時に使用。 --- # DynamoDB データモデリング ## 概要 DynamoDB は NoSQL データベースで、適切なデータモデリングが重要です... ## パーティションキーの設計 パーティションキーは均等に分散する必要があります... ## ソートキーのパターン ソートキーを使用すると、効率的なクエリパターンが可能になります... Skills と Steering の使い分け Skills を使用する場合： 大規模なドキュメントセット（API リファレンス、アーキテクチャガイドなど） 特定のタスクでのみ必要な専門知識 コンテキストウィンドウの効率的な管理が必要な場合 複数のトピックに分かれた参照ドキュメント Steering を使用する場合： すべての会話で常に必要な小規模なファイル（README、設定ファイルなど） プロジェクトの基本情報やコンテキスト エージェントの動作を常に制御したいコーディング規約やスタイルガイド カスタムエージェント設定での Steering/Skills の使用 カスタムエージェントでは Skills/Steering ファイルは自動で読み込まれず、カスタムエージェント設定ファイルの resources フィールドで明示的に指定する必要があります。Glob パターンを使用すると、複数の SKill ファイルを一度に含めることができます。エージェントは各 Skills のメタデータを読み込み、会話の文脈に基づいて関連する Skill を自動的に読み込みます。 以下の例では README.md と Steering ファイル（coding-standards.md、project-rules.md）はカスタムエージェントで常に読み込まれ、Skills として、api-reference.md、architecture-guide.md、deployment-guide.md が必要なときだけ読み込まれます。 詳細については、 Skills リソースのドキュメント を参照してください。 { "resources": [ "file://README.md", "file://.kiro/steering/coding-standards.md", "file://.kiro/steering/project-rules.md", "skill://docs/api-reference.md", "skill://docs/architecture-guide.md", "skill://docs/deployment-guide.md" ] } アップデート ２ : カスタム Diff ツール Kiro がファイルの変更を提案する際、デフォルトでは組み込みの Diff ツールを使用して変更内容を表示します。1.24.0 では、外部の Diff ツールを設定できるようになり、シンタックスハイライト、サイドバイサイド表示、お気に入りの GUI ツールなど、好みの Diff 表示方法を選択できます。 設定方法 chat.diffTool 設定で、好みの Diff ツールを指定します。 kiro-cli settings chat.diffTool delta カスタム Diff ツール (delta を利用した場合) 組み込みの Diff には以下のコマンドで戻すことができます。 kiro-cli settings -d chat.diffTool 組み込み diff ツール ターミナルツール ターミナルで直接 Diff を表示するツールは、ワークフローを中断しません。 delta ：Git ユーザー向けのシンタックスハイライトと行番号表示 difftastic ：フォーマットの違いを無視する言語対応の構造的 Diff icdiff ：素早いサイドバイサイドのカラー比較 diff-so-fancy ：クリーンで人間が読みやすい出力 colordiff ：シンプルなカラー表示の Diff bat ：Git 統合を備えたシンタックスハイライト GUI ツール 変更内容を別ウィンドウで確認できる GUI ツールもサポートしています： VS Code ： code Meld ： meld KDiff3 ： kdiff3 FileMerge (macOS) ： opendiff Vim ： vimdiff Neovim ： nvim 注意： GUI Diff ツールは表示専用の一時ファイルを開きます。GUI ツールで行った編集は保存されず、Kiro の提案された変更には適用されません。 カスタム引数の使用 引用符で囲むことで、ツールの動作をカスタマイズできます。 # delta でサイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" 詳細については、 カスタム Diff ツールのドキュメント を参照してください。 アップデート 3 : AST パターンツールによる正確なリファクタリング 新しい pattern-search と pattern-rewrite ツールにより、エージェントはテキストの正規表現ではなく、構文木パターンを使用してコードを検索および変換できます。これにより、文字列リテラルやコメント内の誤検出がなくなります。 pattern-search の使用例 # すべての async 関数を検索 > async function $NAME($$$PARAMS) { $$$ } という構造のコードを検索して # 特定のメソッド呼び出しを検索 > $OBJ.setState($$$ARGS) のパターンを検索して pattern-rewrite の使用例 # var を const に変換 > var 宣言をすべて const に書き換えて # 古い API を新しい API に変換 > $O.hasOwnProperty($P) を Object.hasOwn($O, $P) に書き換えて メタ変数を使用してパターンを定義します。 $VAR ：単一のノード（識別子、式）にマッチ $$$ ：ゼロ個以上のノード（文、パラメータ）にマッチ これらのツールは、コードの構造を理解するため、テキストベースの検索置換よりも正確で安全なリファクタリングが可能です。 アップデート 4 : 改善されたコードインテリジェンス Kiro CLI は、セットアップ不要で 18 言語に対応した組み込みのコードインテリジェンスを提供します。エージェントは、シンボル検索、定義へのナビゲーション、構造的なコード検索を即座に実行できます。 対応言語 Bash、C、C++、C#、Elixir、Go、Java、JavaScript、Kotlin、Lua、PHP、Python、Ruby、Rust、Scala、Swift、TSX、TypeScript 組み込み機能 シンボル検索 ：コードベース全体で関数、クラス、変数を検索 ドキュメントシンボル ：ファイル内のすべてのシンボルをリスト表示 シンボルルックアップ ：定義に即座にジャンプ パターン検索 ：AST ベースの構造的コード検索 パターン書き換え ：AST パターンを使用した自動コード変換 コードベースマップ ：ディレクトリ構造の探索とコード構成の理解 コードベース概要 任意のワークスペースの概要を素早く取得できます。 /code overview クリーンな出力には --silent を使用します。 /code overview --silent これは以下の場合に便利です： 新しいコードベースへのオンボーディング プロジェクト構造に関する Q&A セッション 未知のパッケージを素早く理解 LSP 統合（オプション） 参照の検索、ホバードキュメント、リファクタリングのリネームなどの拡張機能を使用するには、LSP 統合を有効にできます。プロジェクトルートで以下のコマンドを実行することで、 .kiro/settings/lsp.json 設定が作成され、言語サーバーが起動します。 /code init 使用例 # シンボルを検索 > UserRepository クラスを検索して # すべての参照を検索 > Person クラスの参照をすべて検索して # 定義に移動 > UserService の定義を検索して # ファイル内のシンボルを取得 > auth.service.ts にはどんなシンボルがある？ # ホバードキュメントを取得 > AuthService の authenticate メソッドのドキュメントは？ # 利用可能なメソッドを発見 > s3Client インスタンスで使えるメソッドは？ 詳細については、 コードインテリジェンスのドキュメント を参照してください。 アップデート 5 : 会話圧縮の詳細なコントロール /compact コマンドを利用することで会話履歴を要約し、重要な情報を保持しながらコンテキストスペースを解放することができます。今回のアップデートでは保持するメッセージと最小コンテキストウィンドウの割合を指定することが可能になりました。 圧縮の仕組み 圧縮は、古いメッセージを要約しながら最近のメッセージを保持します。これにより、会話の文脈を維持しながら、コンテキストウィンドウを効率的に使用できます。 手動圧縮 ： /compact コマンドを実行 自動圧縮 ：コンテキストウィンドウがオーバーフローすると自動的にトリガー 設定 保持するメッセージの量を設定できます。 compaction.excludeMessages （デフォルト：2）：保持する最小メッセージペア数 compaction.excludeContextWindowPercent （デフォルト：2）：保持する最小コンテキストウィンドウの割合 両方の設定が評価され、より保守的な（大きい）値が優先されます。 圧縮後の操作 # 手動で圧縮を実行 /compact # 元のセッションに戻る /chat resume 詳細については、 会話の圧縮のドキュメント を参照してください。 アップデート 6 : web_fetch ツールの詳細な URL 権限管理 エージェント設定を通じて、エージェントがアクセスできる URL を制御できるようになりました。正規表現パターンを使用して、信頼できるドメインを自動的に許可したり、特定のサイトをブロックしたりできます。 設定方法 エージェント設定ファイルの toolsSettings で URL ベースの権限を設定します。 { "toolsSettings": { "web_fetch": { "trusted": [".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com.*"], "blocked": [".*pastebin\\.com.*"] } } } パターンの動作 パターンは正規表現で、自動的に ^ と $ でアンカーされます blocked は trusted よりも優先されます blocked の無効な正規表現は、すべての URL を拒否します（フェイルセーフ） trusted の無効な正規表現はスキップされます 信頼されたパターンに一致しない URL は、承認を求めるプロンプトが表示されます 使用例 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/myorg/.*", ".*stackoverflow\\.com.*" ], "blocked": [ ".*pastebin\\.com.*", ".*privatesite\\.internal.*" ] } } } この設定により、AWS ドキュメント、組織の GitHub リポジトリ、Stack Overflow への自動アクセスが許可され、特定のサイトがブロックされます。 詳細については、 web_fetch ツールのドキュメント を参照してください。 アップデート 7 : リモート認証 リモートマシン（SSH、SSM、コンテナ経由）で Kiro CLI を実行する際、Google または GitHub でサインインできるようになりました。ポートフォワーディングにより、認証が機能します。 Builder ID と IAM Identity Center Builder ID と IAM Identity Center の場合、デバイスコード認証がそのまま機能します。URL とコードをローカルブラウザに入力するだけです。 ソーシャルログイン（Google または GitHub） ソーシャルログインの場合、CLI は PKCE 認証を使用し、ポートフォワーディングが必要です。OAuth コールバックは localhost にリダイレクトされるため、トンネルなしではリモート CLI に到達できません。 リモートマシンでのサインイン手順 kiro-cli login を実行し、「Use for Free with Google or GitHub」を選択 表示されたポート番号をメモ（毎回異なります。例： 49153 ） ローカルマシンの新しいターミナルで、ポートフォワーディングを設定： ssh -L <PORT>:localhost:<PORT> -N user@remote-host <PORT> をステップ 2 のポートに、 user@remote-host をリモート認証情報に置き換えます。 CLI で Enter キーを押し、ローカルブラウザで URL を開きます 認証を完了すると、コールバックがトンネル経由で CLI に到達します SSH ポートフォワーディングの例 # 基本的なポートフォワーディング（49153 を実際のポートに置き換え） ssh -L 49153:localhost:49153 -N user@remote-host # カスタム ID ファイルを使用（EC2 で一般的） ssh -i ~/.ssh/my-key.pem -L 49153:localhost:49153 -N user@remote-host # SSH 設定エイリアスを使用 ssh -L 49153:localhost:49153 -N myserver 詳細については、 リモート認証のドキュメント を参照してください。 移行ガイド 既存の Kiro CLI ユーザーが 1.24.0 にアップグレードする際のガイドラインです。 ステップ 1：常に読み込みが必要ではない Steering ファイルを Skills に変換 既存の Steering ファイルの中に常に読み込みが必要ではないものがある場合は、Skills に変換することを検討してください。 変換前： { "resources": [ "file://docs/api-reference.md", "file://docs/architecture-guide.md" ] } 変換後： 1. 各ファイルに YAML フロントマターを追加 --- name: api-reference description: API リファレンスドキュメント。API エンドポイント、リクエスト/レスポンス形式、認証方法について記載。 --- # API リファレンス ... 2. エージェント設定を更新： { "resources": [ "skill://docs/api-reference.md", "skill://docs/architecture-guide.md" ] } ステップ 2：カスタム Diff ツールの設定 お気に入りの Diff ツールがある場合は、設定してください。 # delta を使用する場合 kiro-cli settings chat.diffTool delta # サイドバイサイド表示を有効化 kiro-cli settings chat.diffTool "delta --side-by-side" ステップ 3：URL 権限の設定 web_fetch ツールを使用している場合は、信頼できるドメインを設定してください。 { "toolsSettings": { "web_fetch": { "trusted": [ ".*docs\\.aws\\.amazon\\.com.*", ".*github\\.com/your-org/.*" ] } } } ステップ 4：コードインテリジェンスの有効化 プロジェクトルートで LSP を初期化 /code init まとめ Kiro CLI 1.24.0 は、開発者の生産性を向上させる多くの新機能を提供します。Skills による効率的なコンテキスト管理、カスタム Diff ツールによる柔軟な変更レビュー、18 言語に対応した組み込みコードインテリジェンス、会話の圧縮による長時間セッションのサポート、詳細な URL 権限管理、リモート認証のサポートなど、開発ワークフローを強化する機能が満載です。 今すぐ Kiro CLI 1.24.0 にアップグレードもしくは インストール して、これらの新機能をお試しください！みなさんの Kiro ライフがより快適になることを願っています！ 著者 稲田 大陸 – いなりく AWS Japan で働く Kiro をこよなく愛すソリューションアーキテクト。普段は製造業のお客様を支援しています。その活動の傍ら、最近は AI 駆動開発ライフサイクル (AI-DLC) の日本のお客様への布教活動もしつつ、 Kiro のブログ などを執筆しています。