こんにちは、ファインディのCTO室でスタッフエンジニアを担当している及川(@rojoudotcom)です。 4月14日(火)〜16日(木)にDevOpsDays Tokyo 2026が開催されました。本記事は、スポンサー登壇者として参加してきたレポートです。 DevOpsDaysは、世界各地で開催されるエンジニア向けの国際カンファレンスです。 開発（Dev）と運用（Ops）の連携、自動化、組織文化、最新の事例やプラクティスを発表しています。日本では DevOpsDays Tokyo として、年に1回開かれています。 本記事では、開発組織の成果を経営層にどう伝えたらいいのかを悩まれている方や、AIを導入したのに成果が見えないと感じる方に向けて書きました。3日間のイベント参加を通じて改めて確信した「可視化は組織が動き出すための前提条件である」というメッセージを、登壇・基調講演・現地での会話の3つの角度から振り返ります。 開発組織は、経営から「見えない」 成果を見やすい形で可視化すれば、見える投資に変わる 経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 組織設計に意図を持つことで組織の活動が見える 成果を見る側に立って翻訳する 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 可視化がない改善は、AIに増幅されない 「可視化されてはじめて、人は動く」 おわりに 開発組織は、経営から「見えない」 DevOpsという言葉についてのおさらいですが、もともと「DevとOpsの壁を壊す」ことから始まりました。コンテナ、CI/CD、SREといった方法論が広まり、Dev-Ops間の景色が変わったと感じる方は多いと思います。 一方で、 Devと経営(Biz)の間の壁は依然として高いままではないでしょうか 。 開発部門が作るソフトウェアは形がなく、損益計算書には給与や販管費などの「費用」としてしか記録されません。経営層の関心は売上向上や費用削減にあるのに対して、開発の関心は製品開発におけるリリース頻度の向上やリードタイム削減にあります。お互いが重要だと思う指標が異なることが、すれ違いを生み続けていると考えています。 成果を見やすい形で可視化すれば、見える投資に変わる 今回の登壇では、ファインディ以前に在籍していた現場の事例を話しました。経営層から状況が見えないと言われていた開発組織を意図を持って再設計し、活動の良し悪しを計測したことで投資の判断ができる状態とした体験談です。 テーマは「Dev-Bizの壁をどう越えるか」。20分のスポンサーセッションで持ち時間は短かったものの、自分の問題意識を言語化する貴重な機会になりました。   経営から「見えない」と言われた開発組織を、仕組み・文化・習慣の3層で診断 私が過去に在籍していたある企業の開発部門の話です。配属された開発部門は発足から20年が経つ自社サービスを担当しており、内製化を進めていたところでした。歴代の担当者は退職済みで、ドキュメントもなく、現場の判断は開発担当者の属人的なナレッジに委ねられていました。 エンジニアリングマネージャとして組織の状況を把握するために現場関係者にヒアリングを始めると、様々なことが見えてきました。 まず、組織のサイロ化が進む仕組みが見えてきました。開発に関わるメンバーはプロジェクトの終了と共に解散するため組織ナレッジが溜まりにくいこと、そして新機能開発チーム（Dev）と運用改善チーム（Ops）は分断されており、特にOpsチームに届けられる改善要求は、その背景が不透明なまま改修が行われていました。 次に、受け身の文化が根付いていました。歴史的に要求は事業部が作成し、開発側は要求を待つ立場だったためです。さらに、上位下達の関係性から、開発側からの提案や意見を出しづらい状況でした。 最後に、経営層からすると、PLやBSの数字以上に開発の状況が見えない状態が続いていて、それ以上踏み込めない状況が習慣化されていました。リソースをどこに集中すべきか、開発予算は適正なのかの判断ができない状況でした。 組織設計に意図を持つことで組織の活動が見える 見えない状態は、組織の設計に「なぜそうしたか」の意図がないことが原因です。最初の取り組みとしてTeam Topologiesで組織体制を再設計しました。すると、顧客の要望がどこからきてどこに流れていくのか（バリューストリーム）を見えるようになり、それぞれの開発チームの責任範囲やチーム間の関係性も明確になりました。 組織の枠組みが整ったところで次はチームの中身（マインドセットや運用ルール）です。アジャイル開発のスクラムフレームワークを導入し、自己管理化を進めていきました。チーム自身が開発案件の優先度や実現方法を話し合うようになりました。さらに、システム的観点から事業部の要望に対する逆提案が生まれるようになりました。 そして、新体制が動き出してきたところでFindy Team+を導入し、開発チームのリードタイムやボトルネックを可視化し、定量的なデータを取り始めました。半年後にはリードタイムが従来比8割短縮、デプロイ頻度も3割増加し、経営層に対しても改善を数字で示せるようになりました。 成果を見る側に立って翻訳する Four Keysによる開発活動の成果や、新機能が完成したときに得られるであろう期待される売上やコスト削減効果は重要な数字ではありますが、経営層が理解するにはもう一歩踏み込む必要があります。 例えば開発生産性が向上したことで稼働可能な人月が増えたと同等の効果と捉えれば、管理会計の項目のどこに増減の影響が生まれるのか。あるいは、リリース回数が増えたことで事業計画がどの程度短縮できるのか。こうした情報は決算書にも書けるような話題で、経営層にとって必要な情報です。 このように、投資判断を行う経営層の立場に立ち、開発の活動を翻訳して伝えることで、ようやく開発部門に対する投資判断の議論ができるようになりました。 仕組みを作り、文化を育て、習慣を変えれば、見えない現場は見える投資に変わる 以上、目の前の問題の直接解決ではなく、問題を生み出す構造（仕組み・文化・習慣）に目を向けて根本解決を促すストーリーでした。 さらに詳しい内容はスライドをご覧いただけるとうれしいです。 見えない開発現場を、見える投資に変える — Speaker Deck 可視化がない改善は、AIに増幅されない 「可視化が大事」とは言われ続けてきました。それでも今このテーマで登壇しようと思ったのは、AI時代に入って、その重要性が以前にも増して大きくなっていると感じていたからです。そして、その直感はカンファレンスの基調講演で裏付けられました。 Google CloudでDORA（DevOps Research and Assessment）プログラムを率いるNathen Harvey氏によれば、 2025年の調査でAI採用率は90%に達した そうです（前年比＋14%）。 一方で、コード品質や個人の生産性は上がったものの、 ソフトウェアデリバリーの安定性は悪化していました 。Harvey氏はこの現象を踏まえて、AIの役割を「 増幅器（amplifier） 」と表現していました。 良いシステムには良い結果を、悪いシステムには悪い結果を増幅するもの という意味合いです。 この比喩がしっくり来たのは、増幅されるためにはまず「何が起きているか」が見えていなければならない、という当たり前の前提が浮かび上がるからです。 可視化されていないデータをAIに与えてもノイズを増幅するだけです。可視化されていない開発組織は、AIを入れても何が良くなったのか悪くなったのかすら判断できません。 AI採用は、可視化された土台の上ではじめて成果に結びつく 基調講演から受け取ったメッセージはそこに集約されていました。 そして、もう一つの基調講演でDevOpsムーブメントの礎を築いた一人であるAndrew Clay Shafer氏が残した「 行動を変えるまでは、何も学んでいない 」という一言も、同じことを別の角度から言っていると感じました。見えなければ学ぶことはできないですし、闇雲に行動することになります。それは学んでいないのと同じことです。 ここで触れた2つの基調講演のセッション情報は次のとおりです。 confengine.com confengine.com 「可視化されてはじめて、人は動く」 3日間で一番心に残ったのは、技術的な議論ではなく、夜の懇親会で交わした一つの会話でした。 懇親会で日本酒を参加者に勧めていたとき、たまたまDay1の基調講演スピーカーのNathen Harvey氏が近くにいました。興奮して握手を交わし自己紹介をすると、彼は「 ファインディのプロダクトを見せて欲しい 」とリクエストしてくれました。 その場でブース担当者を呼んで、開発生産性可視化のデモをしました。彼はそれを見終えた後、こう言いました。 可視化することで、ようやく人は動き出すんだよね。 自分の登壇で伝えたかったことも、基調講演で語られていたDORAの研究も、3日間で出会った人たちが共有していた問題意識も、この一文で言い表されていると感じました。 Four Keysのような生産性指標で 内側の現在地 を、DORAのような調査レポートで 外側の方向性 を捉え、両者のギャップを埋めていきます。 可視化はゴールではなく、組織が動き出すための出発点です。 Dev-Bizの壁を越えるにも、AIを増幅器として活かすにも、共通して まず見えていること が要ります。これが3日間を貫いていたメッセージでした。 翌日のスピーカーインタビューのアイスブレイクで「日本に来てどうですか？」と聞かれたHarvey氏が「 ファインディに会えたことが思い出になった 」と答えてくれたのは、嬉しいおまけでした。 おわりに 開発組織を率いるマネジメント層にとって、可視化は「あれば便利な機能」ではなく「動き出すための前提条件」だと、今回の3日間で改めて確信しました。当社は指標を計測するサービスを提供する側だからこそ、組織を歪ませない設計に責任があると、身が引き締まる思いです。 DevOpsDays Tokyoに参加することで、スピーカー同士、運営の方々、そして海外登壇者との繋がりをつくることができ、DevOps文化に貢献したい気持ちも高まりました。来年の開催も楽しみにしています。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers

私にとって 2026 年 5 月 4 日週、最もエキサイティングだったニュースは、 Amazon Bedrock AgentCore が最初のマネージド支払い機能をプレビュー したことです。これにより、AI エージェントが API、MCP サーバー、ウェブコンテンツ、その他のエージェントに自律的にアクセスして支払いを行うことが可能になります。Coinbase や Stripe と提携して構築されているため、請求、認証情報管理、コンプライアンスを実現するためにカスタマイズしたシステムを構築するという、差別化されていない面倒な作業が不要になります。 Coinbase CDP ウォレットまたは Stripe Privy ウォレットを支払い接続として接続し、セッションレベルの支出制限を設定すると、エージェントは実行中に自律的に取引を行います。私が最もワクワクしているのは、AgentCore 決済で何ができるかということです。例えば、リアルタイムの市場データに対してその場で支払いができるリサーチエージェントや、タスクの途中で有料 API を呼び出すコーディングエージェントなどです。 詳細については ブログ投稿 にアクセスし、 ドキュメント を使用してさらに詳しく調べた上で、 AgentCore CLI の使用を開始してください。 2026 年 5 月 4 日週のリリース 2026 年 5 月 4 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Agent Toolkit for AWS – AI コーディングエージェントがエラーを減らし、トークンコストを削減して、エンタープライズグレードのセキュリティコントロールを実現しながら AWS で構築するのに役立つ、本番環境ですぐに利用できるツールとガイダンスのスイートです。追加料金なしでご利用いただけます。Agent Toolkit for AWS は、 AWS ラボ で利用可能な MCP サーバー、プラグイン、スキルの後継です。使用を開始するには クイックスタートガイド にアクセスするか、 GitHub で利用できるスキルとプラグインをご参照ください。 AWS MCP サーバーの一般提供開始 – 少数の固定ツールセットを通じて、すべての AWS サービスに対するセキュアかつ認証済みのアクセスを AI エージェントやコーディングアシスタントに付与する、マネージドリモートモデルコンテキストプロトコル (MCP) をご使用いただけます。これは Agent Toolkit for AWS の一部です。詳細については、 Seb Stormacq のブログ投稿 をご覧ください。 AI エージェント向け Amazon WorkSpaces (プレビュー) – AI エージェントを使用して、マネージド WorkSpaces 環境からデスクトップアプリケーションに安全にアクセスして操作できます。この機能により、組織はエンタープライズグレードのガバナンスとコンプライアンスを完全に維持しながら、日常のワークフローを大規模に自動化できるようになります。詳細については、 Micah Walter のブログ投稿 をご覧ください。 Amazon EC2 M8idn/M8idb インスタンスと R8idn/R8idb インスタンス – これらのインスタンスは、AWS および最新の第 6 世代 AWS Nitro Card でのみ利用可能なカスタムの第 6 世代 Intel Xeon Scalable プロセッサを搭載しています。前世代のインスタンスと比較して、これらのインスタンスは vCPU あたりのコンピューティングパフォーマンスを最大 43% 向上させます。M8idn/R8idn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供し、M8idb/R8idb インスタンスは最大 300 Gbps の EBS 帯域幅を提供します。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 2 周年を迎える Valkey – Valkeyは、オープンでコミュニティ主導型のテクノロジーが、単一ベンダーのどのモデルよりもイノベーションが早く、拡張性が高く、より多くの価値をもたらすことを証明しています。Valkey では Docker のプルが 1 億回 (前年比で 17 倍に増加) を超え、225 人以上のコントリビューターが 1,500 件を超えるプルリクエストを提出しました。これは、同時期の Redis の開発ペースの約 2 倍です。 Amazon ElastiCache では最新の Valkey 9.0 を使用することもできます。 SQL を使用した数十億スケールのベクトルのクエリ – 標準 SQL を使用して Amazon Aurora PostgreSQL-Compatible Edition の Amazon S3 Vectors をクエリする方法と、ベクトルの類似性の結果を 1 つのクエリでリレーショナルフィルターと組み合わせる方法を学ぶことができます。例えば、意味論的に最も類似した製品を見つけてから、1 つの SQL ステートメントにおいて価格、在庫状況、またはテナントでフィルタリングする方法などです。 AWS DevOps エージェントを使用したエンドツーエンドのエージェンティック SRE の構築 – Amazon CloudWatch、Splunk 、GitHub、Slack とシームレスに統合して、調査範囲を定義する DevOps エージェントスペースを設定する方法を学びましょう。また、Webhook を介して自動調査をトリガーする方法、緩和計画を作成する方法、エージェント対応仕様を Kiro などのコーディングエージェントに渡して実装する方法も学ぶことができます。 AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 5 月 11 日週のニュースは以上です。2026 年 5 月 18 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

本ブログは、KDDI 株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部 アライアンスシステムグループ 中野 利彦 氏、久保田 剛史 氏と、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 マネージドサービスを組み合わせたサーバーレスアーキテクチャは開発・運用の効率化に大きく貢献する一方で、複数サービスにまたがる複合的なインシデントへの対応は依然として難しい課題です。今回は、 KDDI株式会社 （以下、KDDI）が AWS DevOps Agent を活用し、インシデント対応のリードタイムを大幅に短縮した取り組みをご紹介します。AWS DevOps Agent は、インシデント発生時に自律的にメトリクス・ログ・デプロイ履歴を横断分析し、根本原因の仮説と対応案を提示する AI エージェントです。AI を「答え合わせ」のパートナーとして位置づけることで、精度と速度を両立した新しいインシデント対応ワークフローの実践例をご紹介します。 導入背景 KDDI は通信事業を基盤としながら、au PAY・Pontaポイント・エンタメ・エネルギーなど、ユーザーの生活に密着した多彩なサービスを展開しています。今回ご紹介するのは、そのパーソナル事業を支えるシステムの一つ、Web サービス向けのビジネスロジックプラットフォームです。このシステムは、Webフロントシステムに対するポイントの集計や抽選などのリワードの提供・エンタメサービス連携など、多彩なサービスを提供しており、サーバーレスアーキテクチャを採用しています。AWS Lambda によるリクエスト処理、Amazon RDS Proxy を介したデータアクセス、データレイクへの蓄積を軸に、複数の外部システムと SFTP 連携による大量ファイル分析も行う大規模な構成です。 Webサービス向けのビジネスロジックプラットフォームのアーキテクチャ 本プラットフォームで、Amazon API Gateway の 5XX エラーと AWS Lambda のスロットリングが複数の Lambda で同時発生するインシデントが起きました。オンラインリクエストの応答に支障をきたすインシデントです。リクエスト数は急増しておらず、スロットリング発生を起点に特定の Lambda の処理時間が高止まりするという挙動から、AWS Lambda / Amazon RDS Proxy / Amazon Aurora にまたがる複合的な問題が疑われました。 障害発生時のメトリクス こうした複数のマネージドサービスが絡む問題は、ユーザー側では深いところまで把握できないため原因の特定が難しく、メトリクスやログのやり取りを繰り返しながら数週間を費やすことも珍しくありませんでした。たどり着いた対応策が暫定的なものにとどまり、再び同じ調査ループに入ってしまうケースも少なくありませんでした。 ソリューション：AWS DevOps Agent を「先行調査官」として活用する この課題を打開するために、本プラットフォームの運用チームでは AWS DevOps Agent を試験的に導入しました。 AWS DevOps Agent は、2025年12月の AWS re:Invent でパブリックプレビューとして発表され、2026年3月31日に 一般提供が開始 されたサービスです。アラートが発生した瞬間から自律的に調査を開始し、Amazon CloudWatch をはじめ Datadog・Dynatrace・Grafana・New Relic・Splunk などのオブザーバビリティツール、CI/CD パイプラインのデプロイ履歴、ソースコードリポジトリなど複数の情報源を横断的に分析して根本原因の仮説と対応案を提示します。プレビュー期間中の実績では、MTTR を最大75%削減、調査時間を 80% 短縮、根本原因の特定精度 94% という効果が報告されています。 特徴的なのは、チャットで深掘りしながら精度を上げていける点です。AWS DevOps Agent は誤った推論をした場合もチャット上で指摘・修正できるため、一方的に出力を受け取るのではなく、対話を重ねながら仮説の精度を高めていくことができます。また、ソースコードや設定値、ログを統合的に分析できるため、AWS Lambda の autocommit 設定と Amazon RDS Proxy の挙動の関係など、単一のメトリクスだけでは見えにくい問題箇所も特定しやすくなりました。 DevOps Agentとのやり取り 重要なのは、AWS DevOps Agent の出力をそのまま正解として扱うのではなく、「AWS サポートへの問い合わせ前の仮説整理ツール」として位置づけた点です。AWS DevOps Agent が提示した対応案を持って AWS サポートに問い合わせ、「この提案の有効性を確認したい」「他に見落としている観点はないか」という形で対話することで、サポートとのコミュニケーションが格段にスムーズになりました。 AWS サポートとの連携が変わった 従来は、インシデント発生後に KDDI の運用チームが個別にメトリクス・ログを分析し、AWS サポートへ問い合わせ、追加情報の提供と原因調査を繰り返すサイクルに数週間を費やすこともありました。対応策の効果が限定的な場合は最初のステップに戻るループも発生していました。 AWS DevOps Agent の導入後は、このやり取りの質が大きく変わりました。従来は「何が起きているかを一から説明する」ところから始まっていたやり取りが、「AWS DevOps Agent からこういう提案が出ているが、この観点は正しいか」という形に変わりました。AWS DevOps Agent で原因調査・複数対応案の策定・初期有効性判断を先に行い、その結果をもとに AWS サポートへ「答え合わせ」的に問い合わせることで、双方が同じ情報・同じ仮説を共有した状態で議論できるようになりました。根本原因分析の共有コストが下がり、複数の対応案を同時並行で検証環境に適用できるため、全体のリードタイムを数日単位に圧縮することができました。 AWS DevOps Agent の「 Ask for human support 」機能からサポートケースを作成することで、調査ログが自動的に AWS サポートへ共有されるため、調査内容の全文を手動で説明する手間がありません。AWS DevOps Agent が客観的な第三者として仮説を整理し、KDDI の運用チームと AWS サポートがその仮説を検証・補強するという三者の役割分担が自然に生まれました。AI が大量のメトリクス・ログ・設定値を横断的に分析して仮説を提示し、AWS サポートはその有効性を確認・深掘りする。このやり取りが、調査の精度と速度を同時に高めることにつながりました。 今回のインシデントでは、AWS サポートとの調査を通じて、AWS Lambda と Amazon RDS Proxy 間のセッション管理の設定に起因する根本原因が特定されました。障害自体はその後自然解消しユーザー影響も収束しましたが、再発防止に向けて書き込みと読み取りのリクエストを適切に分離する構成への変更が有効であることを AWS サポートとの連携で確認済みであり、現在 KDDI 側で検証を進めています。 【注意】 AWS DevOps Agent から AWS サポートへのケース起票・チャット連携を利用するには、AWS サポートプランの契約が必要です。Basic サポートではテクニカルサポートケースを作成できないため、この機能は利用できません。Developer サポートではケースの起票は可能ですが、チャットによるやり取りには対応しておらず、AWS Support Center での対応となります。DevOps Agent 上の統合チャット体験を含むすべての機能を活用するには、Business サポート以上のプランが必要です。詳細は AWS サポートプランのページ をご参照ください。 導入効果と今後の展望 AWS DevOps Agent の活用により、KDDIのインシデント対応は「数週間」から「数日」へと大幅に短縮されました。被疑箇所の特定から複数の対応案の策定・検証まで、リードタイムを数日単位に圧縮できたことは大きな成果です。AI を万能な答えとして扱うのではなく、仮説生成と優先順位付けのパートナーとして活用し、AWS サポートとの協働で精度を担保するというアプローチは、マネージドサービスを多用するサーバーレスアーキテクチャにおいて特に有効です。KDDI では今後も AWS DevOps Agent の活用を深めていく予定です。今回はインシデント発生後の原因調査という使い方が中心でしたが、プロアクティブな障害予防機能にも期待しています。過去のインシデントパターンを学習して再発防止策を提案するこの機能を活用することで、障害が起きてから対応するのではなく、起きる前に手を打てる運用への転換を目指しています。また、Amazon CloudWatch・Amazon EventBridge・Amazon SNS と連携することで、現在は手動で行っている DevOps Agent の調査起動をアラーム発火と同時に自動化することも視野に入れています。調査完了後はその結果を Kiro に渡し、チケット起票やリポジトリの調査といった後続の運用作業をそのまま Kiro と連携して進める流れも検討しており、検知から対応までの一連のサイクルをより効率化していきたいと考えています。 まとめ 本ブログでは、KDDI による AWS DevOps Agent を活用したインシデント対応効率化の事例をご紹介しました。 今回の取り組みで特に印象的だったのは、「AI に答えを出させる」のではなく「AI と一緒に問いを立てる」という使い方です。AWS DevOps Agent が仮説を整理し、AWS サポートがその仮説を検証・補強する。この役割分担によって、人と AI とサポートの三者がそれぞれの強みを発揮できる新しい協働モデルが生まれました。 マネージドサービスを多用する現代のクラウドアーキテクチャでは、インシデントの原因が単一サービスに収まらないケースが増えています。そうした複雑な状況だからこそ、「まず仮説を持ってから相談する」というアプローチが、解決までの道のりを大きく変えます。本事例が、同様の課題を抱えるチームにとって一つのヒントになれば幸いです。 著者 中野 利彦 様 （右） KDDI株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部 グループリーダー 久保田 剛史 様 （左） KDDI株式会社 パーソナル事業統括本部 システム開発本部 ライフデザインプラットフォーム部 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト