こんにちは！　Mercari Adsチームのインターン生の @uta です。 本記事では、フロントエンドを中心に経験してきた私が、AIを活用しながらバックエンドを含む機能開発に挑戦した3ヶ月間を振り返ります。インターン中に取り組んだ機能開発を通じて、複数のサービスにまたがる開発の難しさや、AIを活用するなかで得た学びを紹介します。 はじめに 私は2026年7月から9月末までの3ヶ月間、フロントエンドエンジニアとしてメルカリのインターンに参加しました。以前にもメルペイでインターンを経験しましたが、その後、AIの普及によって開発の進め方や日々の業務は大きく変化しました。そうした変化のなかで、メルカリの開発がどのように進められているのかを改めて知りたいと考え、今回の参加を決めました。 これまでの開発経験は主にフロントエンドでしたが、今回はバックエンドを含む機能開発に本格的に取り組みました。以前から、技術領域にとらわれずサービスに必要な開発へ取り組めるようになりたいと考えていたことに加え、AIによって未経験の技術やコードベースを理解するハードルが下がった今なら、経験の少ない領域にも挑戦できるのではないかと考えたためです。 この記事では、主に次の内容を紹介します。 商品グループへの価格条件追加 課題と実装方針 難しかった点 そのほかに取り組んだこと インターンを振り返って AIと取り組んだバックエンド開発 経験して初めて分かったこと 挑戦を支えてくれたチーム この記事が、メルカリのインターンに挑戦しようと考えている方や、AIを活用した未経験領域への挑戦に関心がある方の参考になれば幸いです！ 商品グループへの価格条件追加 私が所属したAds Operationチームでは、広告主が広告の設定や運用を行うためのAds Managerを開発しています。Ads Managerでは、広告グループ作成、クリエイティブ入稿、商品情報をまとめたデータフィードの登録、配信状況や成果の確認、レポート作成など、広告運用に必要な作業を行えます。 今回のインターンでは、その中でも商品グループに価格条件を追加する機能をメインタスクとして担当しました（図1.1）。 図1.1 商品グループの価格条件設定画面 課題 Ads Managerには、商品名や価格などの商品情報をまとめた「データフィード」を登録する機能があります。商品グループは、そのデータフィード内の商品を条件に応じてまとめ、広告として配信する商品を決めるための仕組みです。 これまでは、広告主が商品に付けたカスタムラベルで商品を絞り込めましたが、価格帯では絞り込めませんでした。そこで今回、価格の下限と上限を指定し、その範囲に含まれる商品からグループを作成できるようにしました。一見すると画面に価格の入力欄を追加するだけの機能に見えますが、入力された条件を保存し、対象となる商品を判定して広告へ反映するまでの仕組み全体を変更する必要がありました。 実装方針 実装範囲は、フロントエンド、データベースのスキーマとマイグレーション、GraphQL API、広告を生成するworker、広告を更新するloaderにまたがりました。画面で入力された価格条件は、GraphQL APIを通じてデータベースへ保存されます。広告グループを作成すると、workerが保存された条件を評価して広告を生成します。その後、データフィードによって商品の情報が更新された場合は、loaderが条件を再評価して広告へ反映します（図1.2）。 図1.2 価格条件が保存され、広告へ反映されるまでの流れ データベースは、既存のカスタムラベル条件を保存する構造を拡張し、条件の種類と価格の下限・上限を保存できるようにしました。価格条件ではカスタムラベルの値を使わないため、既存カラムについて、NULLを許容する定義へ変更しました。また、workerやloaderを含む各サービスでは、条件の種類に応じて商品が商品グループに属するかを判定できるよう、ロジックを変更しました。 難しかった点 難しかったのは、価格を比較するロジックそのものよりも、既存の仕組みをどのように拡張し、複数のサービスへ安全に反映するかを考えることでした。 実装の影響範囲を確認するなかで、ログや監視、パフォーマンス、既存の挙動を含めた動作確認の範囲など、実装時に考慮すべき観点が次々に見つかりました。データ分析用途のBigQueryへのデータ同期のように、追加で必要になる作業もありました。当初は、自分がまだ認識できていない観点や作業まで想像できず、必要な工数を十分に見積もれていませんでした。実装を進めるなかで想定外の作業が次々に見つかり、当初の見積もりが甘かったことを実感しました。リリースとロールバックの設計も、その一つです。 価格条件では、カスタムラベル条件で必須だった値がNULLになります。そのため、価格条件のデータが作成された後にworkerやloaderを以前のバージョンへロールバックすると、値が必ず存在することを前提とした処理でエラーが発生する可能性がありました。そこで、まずNULLを読み取っても処理が失敗しないよう防御的な変更を加えたworkerとloaderを先行して公開し、その後に価格条件へ対応した機能を公開する手順を検討しました。実際に利用されているサービスへ機能を追加する際は、公開までの手順だけでなく、問題が起きた場合のロールバックまで考えて準備する必要があると学びました。 実装やリリースの準備を進めるなかで、最初のデータベース設計が後段の処理に与える影響に気づきました。既存カラムをNULL許容にしたことで、値が必ず存在することを前提にしていた複数のサービスにとっては、その前提を崩す実質的に破壊的な変更になりました。バックエンドやデータベース設計の経験が少なかった私は、設計時点では既存の処理を再利用できることに注目し、後段の処理や動作確認、リリース、ロールバックへの影響まで見通せていませんでした。今振り返ると、既存構造を全面的に作り直さなくても、価格の値だけを専用テーブルへ分ける選択肢を、より慎重に検討すべきだったと思います。この経験から、データベース設計ではコード上の変更量だけでなく、既存データや各サービスが持つ前提、動作確認、デプロイ、ロールバックまで含めて影響を考える必要があると学びました。 そのほかに取り組んだこと 価格条件の追加を進める一方で、インターン期間中には、Ads Managerの利便性や開発環境を改善するタスクにも取り組みました。 広告主による計測タグの導入の手間を減らすため、Ads Managerに「計測タグ」タブを追加しました。これまではガイドを確認しながらパラメータやアカウントIDを設定する必要があり、設定ミスが問い合わせにつながることもありました。今回の対応では、ログイン中のアカウントIDを反映した導入用スクリプトと、商品詳細の表示・カートへの追加・購入といったイベントごとのコードを画面上に表示し、そのままコピー＆ペーストできるようにしました（図2.1）。 実装自体は短期間でしたが、リリース後にはSales teamへの共有、広告主への案内メールの配信、管理画面マニュアルの更新まで進みました。画面の実装だけでなく、複数のチームを通じて広告主へ機能を届けるまでの流れを見ることができました。 図2.1 Ads Managerに追加した計測タグ画面 社内の管理ツールからAds Managerへ移動するリンクを追加した際には、Ads Managerへアクセスできない場合に表示する専用画面がないことに気づき、別のチケットとしてアクセス拒否画面も追加しました。また、リリースノートの作成を支援するツールで著者情報が正しく表示されないケースを見つけ、原因を調査して修正しました。 Ads Managerのテーブル画面では、自動ルール一覧への作成日時の追加、クリエイティブ一覧への入稿日時の追加、横スクロールバーの追従表示など、広告運用時の操作性を高める改善に取り組みました。また、画面遷移や再読み込み後もテーブル画面のソート設定を維持できるよう、設定をsessionStorageへ保存し、画面へ戻ったときに復元する対応も行いました。 そのほか、インターン期間中にSales teamからProduct Managerを通じて届いた要望をもとに、テーブルのカラムに、その指標の意味を補足するツールチップを追加しました。実際の利用者に近いところから上がった要望が、Product Managerによって仕様に整理され、すぐに開発タスクとなって画面へ反映されるまでの一連の流れを経験できたことが印象に残っています。 メインタスクから日々の改善まで、規模や領域の異なる開発を経験できました。ここからは、それらの経験を通じて得た学びを振り返ります。 インターンを振り返って AIと取り組んだバックエンド開発 今回は、既存コードの調査から実装計画の作成、コードの実装、テストケースの検討まで、開発のさまざまな場面でAIを活用しました。これにより、経験の少なかったバックエンド領域を含む機能開発も進めやすくなりました。 また、複数のサービスの役割を調べるなかで、ORMやデータベースマイグレーション、GraphQL、Pub/Sub、ポーリングなど、分からない概念や処理はその都度AIを使って確認しました。説明を実際のコードと結びつけることで、実装を進めながらバックエンドへの理解も深められました。 今回のように経験の少ないバックエンド領域へ取り組むことは、AIがなければ私には難しかったと思います。AIが実装の大部分を担い、分からない概念や処理の理解にも役立ったことで、経験の少ない技術領域へ踏み出すハードルは大きく下がったと感じました。 経験して初めて分かったこと 一方で、AIを使って実装を進められることと、その変更が十分かを自分で判断できることは別でした。実際の開発では一般的な技術知識だけでなく、既存の設計や過去の経緯、チームで共有されている前提を踏まえた判断も必要でした。価格条件の追加でも、ログ、監視、データ同期、パフォーマンス、リリースなど、チームメンバーとの会話を通じて初めて気づいた観点が多くありました。 振り返ってみると、AIを使って自分で調査を続けられるからこそ、ある程度理解を整理してから相談しようとして、相談のタイミングが遅くなることもありました。この経験から、AIで理解を深めることと、チームメンバーに方向性を確認することは、どちらか一方を選ぶものではなく、状況に応じてバランスよく組み合わせることが大切だと学びました。時間のかかる作業に入る前に方向性を確認したり、調査する時間をあらかじめ決めたりすることも、今後は意識したいです。 今回、バックエンドを含む機能開発に取り組み、実装だけでなく、影響範囲の確認やリリースまでを考える一連の流れを経験できました。この経験を通じて、次にバックエンド開発へ取り組む際は、必要な作業や確認事項を以前より早い段階で想像し、より見通しを持って進められると思います。技術的な判断の基準は、このような経験を重ねるなかで身につくものだと感じました。これからもAIを活用しながら、実装やレビュー、チームとの対話を一つずつ経験として積み重ね、少しずつ自分で判断できる範囲を広げていきたいです。 挑戦を支えてくれたチーム 今回、経験の少ない領域に挑戦できたのは、分からないことを相談したときに、丁寧に支えていただける環境があったからです。相談への回答だけでなく、同じ問題で次に困る人が出ないよう、仕組みそのものも改善してくださいました。 CIでE2Eテストが失敗した際、レポートの見方が分からず相談したところ、確認方法のドキュメントを作成していただいたうえ、失敗時のレポートを自動で公開し、Pull Requestから確認できるようCI自体も改善してくださいました。また、Datadogを使った調査がうまくいかず相談した際には、個人が持っていた知識を整理し、AIが参照できる手順書（Skill）として共有できる形に整えていただきました。 特に印象に残ったのは、困りごとを曖昧なままにせず、すぐに向き合い、個人の経験で終わらせずにチーム全体が使える改善へつなげてくださったことです。そうした姿勢から、Be a Pro、Move Fast、All for Oneが日々の開発に根づいていることを実感しました。私自身が経験の少ないバックエンド領域に挑戦できたことはもちろん、メルカリがGo Boldを実践し続けられる背景にも、互いの挑戦を支える文化があるのだと感じました。 おわりに 本記事では、Mercari Adsチームでのインターンで取り組んだ、商品グループへの価格条件追加やAds Managerの改善、そこから得た学びを紹介しました。フロントエンドを中心に経験してきた私にとって、複数のサービスにまたがるバックエンド開発へ挑戦し、実装だけでなく設計、監視、リリースまで考えた経験は、大きな学びになりました。 このような経験ができたのは、メンターの@dwjさんをはじめ、設計や実装のレビューだけでなく、日々の疑問に向き合い、学びやすい仕組みまで整えてくださったチームのみなさんのおかげです。経験の少ない領域への挑戦を支えてくださったことに、この場を借りて改めて感謝します。ありがとうございました！ 現在、メルカリでは複数のインターンを募集しています。この記事を通じて、メルカリでのインターンに少しでも興味を持っていただけたらうれしいです。気になる方は、以下の募集要項もチェックしてみてください！ Class of 2028, 28卒対象 / Software Engineer Internship Class of 2028, 28卒対象 / Security Engineer Internship Build Internship Plus, Software Engineer (Internship)

こんにちは、エス・エム・エスでカイポケコネクトのエンジニアをしている加我 ( @TAKA_0411 ) です。 私事ではありますが、日本のDatadogコミュニティの活動や社外での登壇の実績を評価されまして、2026年度の Datadog Ambassadors に選出いただきました。 もともと好きが高じて続けてきた活動ではありますが、それらがオフィシャルに評価されたというのは感慨深いものです。今後も積極的なDatadog活用や知見の共有、仲間集めのためのコミュニティ運営を続けていきます。 そういえば、3月に開催されたJAWS DAYS 2026では私も登壇者・ブース担当者として参加していたのですが、Datadog社のブースにて非常に気になるデモを拝見しました。 DatadogのWeb UIから生成AIと会話し、データの調査や分析を行う機能……それが私とBits Chat（当時はBits Assistant）との初めての出会いでした。直感的にこの機能に可能性を感じ、担当営業の方を通じてPreviewにおけるBits Assistantの利用について相談しました。相談から少し時間が経ったタイミングで利用が可能になったので使ってみたところ、非常に便利でした。これは自分だけではなく開発組織全体に知ってもらいたい。そう思ったのがこの記事を書いたきっかけです。 面白いものを見つけたぞのノリで社内共有します Bits Chatについて Bits ChatはDatadogのWeb UIからチャット形式でやり取りすることにより様々な支援を受けられる、生成AIを活用したサービスです。Datadogに蓄積されているデータに対し、下記の機能を提供しています。 問題の調査と対処 テレメトリデータの探索と分析 Datadogの概念や使い方の学習 オブザーバビリティの設定と最適化 docs.datadoghq.com 画面右上のAsk Bitsから呼び出すことができます Bits Chatが活躍するユースケースとして、Monitorのエラー通知からの原因調査、ダッシュボードにおける特定期間のデータ分析、用途を伝えるだけで最適なダッシュボードを作成してもらうといったことが可能になります。つまり、これまで私たちが手動で行ってきた多くの作業をBits Chatがこなせるようになります。 余談ですが、Bits ChatはPreviewによるサービス提供当初はBits Assistantと呼ばれていました。2026年6月に開催されたDASH 2026にてBits Chatと名称変更がされ、BitsというAI機能群のうちの1つとなりました。Datadogには多くの機能があり、新機能も次々と追加されますが、Bits Chatをハブにして活用方法を学んだり実際に設定してみたりすることが可能になります。 www.datadoghq.com さて、私はPreviewでの機能利用が可能になった段階から社内でもりもりBits Chatを使い込んできました。そんな私が得られた知見や開発チームの変化についてご紹介します。 Datadog民主化の鍵はBits Chatである 使ってみて気づいた1つめの大きなメリットがこちらです。Bits Chatを活用することにより社内のDatadog推進者 / Datadogチャンピオン *1 への依存が軽減され、開発者が自発的にDatadogを利用する文化の醸成に貢献してくれます。 Bits ChatはDatadogについて熟知しています。ユーザーが実現したいことや抱えている問題、テレメトリデータの分析方法、ダッシュボードの作成など、様々なテーマについてアドバイスを得ることが可能です。このような動きをするBits Chatを私は「Bits Chat as an Internal Datadog Champion」と表現しています。そうです、Bits Chatは社内で一番Datadogに詳しいチャンピオンなのです。 自社もしくは自分が担当しているプロダクトへのDatadog導入を推進したことがある方はご理解いただけるかと思いますが、Datadogを導入してから安定した運用に至るまでには下記のような多くの問題が発生します。挙げ始めたらキリがありません。しかし導入を推進する人は強い推進力とオーナーシップを持っているため、これらの問題を1つずつ解決し、社内のドキュメントに残し、設定をコード化することで安定したDatadog活用に導くわけです。 そもそもDatadogの使い方がわからない（学習コスト） Datadogがあっても別のツールを使おうとする（ツールのサイロ化） UIが複雑で機能がどこにあるかわからない データの表示切り替え方法がわからない いい感じのダッシュボードを作るのが困難 意図したアラートを設定できない Datadog推進者のSPOF問題 社内のDatadog推進者が色々な問題を解決し、運用を安定させていくにつれて発生する別の問題があります。それは「Datadogの社内活用の拡大が推進者に依存してしまう」「Datadog推進者がSPOFになってしまう」という問題です。 皮肉にもDatadog推進者が強いオーナーシップを発揮するほど「Datadog推進者の人がやってくれる」「Datadog推進者の人にお願いすれば良い」という空気感が出来上がってしまい、Datadogの民主化、ひいてはオブザーバビリティの民主化からどんどん離れていってしまうのです。解像度の高い話をしているなと思った読者のあなた、鋭いですね。これは過去の私自身への自戒です。 Datadog活用のあるべき姿 Datadogは開発組織全体で使うことにメリットがあると私は考えています。特定の誰かが使えるだけではDatadogを活用できている状態とは言えないのです。過去にDatadog推進者のSPOFという原因の一端を担ってしまった私がBits Chatを見て感じた可能性が「Bits ChatこそがDatadog民主化の鍵」でした。 開発者が自発的・自律的にBits Chatへ現在発生している問題や実現したいことを相談すれば、開発組織全体でDatadogを活用でき、結果としてサービスのオブザーバビリティが高まると私は信じています。 ちなみに、Datadogの民主化を促すために最近私が力を入れているのがBits Chat誘導員という役割です。以前はBits Assistantのアシスタントなどと言っていた時期もありました。開発者がDatadogの活用で困ったらすぐさまフォローに入りつつBits Chatへ誘導し、本人にBits Chatとの会話を通じて自身で課題を解決する体験をしてもらうことを率先してやっています。また、アラートが発生した場合は自分が積極的に調査に参加してBits Chatの活用事例を知ってもらう機会も作っています。 こうした取り組みの結果、開発者がBits Chatを活用して自発的に課題を解決したエピソードも生まれています。とある非同期処理をバックエンドで実装するにあたり、処理が別スレッドに移ったこと、そしてスレッドプールが溢れないことをテレメトリデータから確認したいというニーズがありました。これに対し、社内のエンジニアはBits Chatと対話することでSpanの計装とスレッドプールの監視を自力で完遂していました。ご本人曰くDatadogに特別詳しいわけではないそうですが、対話を重ねることで無理なく実装できたと言っていました。 私というDatadogチャンピオンの出番がないまま解決してしまったわけで、これは民主化の一歩と呼べる出来事でした。 Bits Chatとの会話ログの一部を見せてもらいました テレメトリデータ分析会の活性化 私が所属しているチームでは定期的にサービスのCUJ (Critical User Journey) のデータをまとめたダッシュボードの分析会を行っています。しかし、以前はダッシュボードを見てもデータの分析方法がよくわからなかったり、どのデータを見たら問題発見や改善アクションに繋げられるのか迷うことも多く、価値のある時間であるとは言い難いものでした。テレメトリデータはDatadogに蓄積されているため、ダッシュボードを作り直そうかなどと考えていたのですが、このデータ分析自体をBits Chatにやらせてみようという取り組みを始めました。 分析するなら意味のある会にしたいという議論もありました 分析の方法として、CUJのデータをまとめたダッシュボードに対してBits Chatから「ダッシュボードのデータの分析をしてください。分析するための条件は〜〜です。分析したデータはNotebookにまとめておいてください」といった形で分析を依頼していました。数回やっているうちにNotebookのCustom Templates機能を使えばある程度再現性のある形で実行・保存できるのでは？と気づき、最近では専用のNotebookテンプレートを用意し、そのフォーマットに沿って分析依頼を行っています。 分析用のプロンプト例 (クリックすると展開されます) Custom Templatesの例 # 分析用のプロンプト例 CUJに関するデータについて下記の観点を中心に比較・分析し、Notebookとして保存してください。 Notebookのテンプレートは「CUJ分析レポート - {mm-1}月 vs {mm}月比較 」を使用し、テンプレート中の{mm}には当月の数字を、{mm-1}には前月の数字を、{対象サービス}には"sample-app" を入れて置き換えてください。 また、Notebookへのデータ追加時にはテンプレートのフォーマットを必ず遵守してください。 以下は分析対象です。 ■ 分析対象 ・CUJサービス: service:sample-app (GraphQL Operation別に集計) ・重点分析サービス: service:sample2-app ・RUM: sample-frontend ■ 条件 ・分析対象の期間: 前月1日〜前月11日 vs 当月1日〜当月11日 ・環境: production ・Operation: ◯◯関連のOperationName呼び出し回数Top10 + △△関連のOperationName呼び出し回数Top10 ■ 比較観点 ・GraphQL Operationの呼び出し回数の変化 ・レイテンシ(P95)の変化 ・エラー数の変化（エラー率も算出） ・CUJのLatencyのP95で500msecを超えるGraphQL Operationの有無 ・sample2-appの新規Operation出現有無 ■ RUM分析 ・全体: ビュー数/セッション数/P95ロード時間/エラー合計 ・遅延ページ: P95 > 1秒のCUJページ抽出 ・XHRボトルネック: 最も遅い外部リクエストの特定 ・エラー分類: Top10エラーの分類と対応要否判定 ■ 計測単位 ・呼び出し回数: リクエスト単位（@_top_level:1） ・エラー: 子スパン単位とリクエスト単位を併記 ■ P95 > 1秒判定のデータソース ・custom.sample-app.graphql.request.duration メトリクス （スパン保持期間を超える場合に対応） ■ 追加分析（可能であれば） ・アクティブユーザー数との相関 （データソース: Sheets「ユーザー数管理」） ■ 出力形式 ・サマリー（全体評価テーブル + キーインサイト）を冒頭に ・推奨アクション（優先度高/中/ポジティブな変化）を末尾に ■ 関連リソース ・ダッシュボード: /dashboard/aaa-bbb-ccc/cuj-dashboard この分析方法に変えてからダッシュボードの分析会に変化が見られました。Bits Chatがまとめてくれたデータを見つつ、データに対する疑問だったりデータの見せ方の工夫に関する意見が積極的に出るようになりました。 なぜこのエンドポイントでのエラーがこんなに発生しているのか エラー数はリクエスト単位とスパン単位でデータを出し分けた方がいいのではないか（Next Actionへ） このエラーは原因を調べて対処したほうがいいのではないか（Next Actionへ） ユーザー数の増加とGraphQL Operationの実行回数に相関はあるのか フロントエンドのボトルネックは◯◯が原因そうなので調べてみてもいいのではないか ユーザーの利用増加を数字から感じられて良い 実際私もダッシュボードの分析会で発見したエラーの原因を調査し、バックエンドのエラーハンドリングを改善するといった対応を行うことができました。Bits Chatは具体的なソースコードの改善方法も提案してくれるので、私のような開発経験が少ない人間でも積極的にサービスの改善に繋げることができます。 突出しているエラーの改善をやったりしてます 最高のデバッガーを支えるBits Chat とある日の午後、1つのアラートが発生しました。レスポンスタイムが基準値を上回っていました。私も調査に入りつつBits Chatにアラート原因の分析を依頼し、別のエンジニアはログの分析をしてくれていました。 Bits Chatを使いつつトレース・ログ・メトリクスのデータを分析してみます。どうやら別のチームがオーナーとなっているシステムが関連していそうです。そして私はあまりそのシステムの中身を知りません。Bits Chatがまとめたデータを見てみると該当の時間帯にECSのCPU使用率が高まっていることがわかりました。じゃあなぜこのタイミングで使用率が高まるのかを調べてみます。自分も実際に関係しそうなソースコードを見て、微力ながら議論に参加していたわけですが、結論としてはデプロイ中にリクエストを受けるとタイミング次第でリソース消費量が高まってしまうという現象であることがわかりました。 私はデータの拡充という観点からDatadog Continuous Profilerを有効化し、オーナーであるチームはリソース消費量を抑えるための具体的な施策について議論していました。また、デプロイ完了のタイミングも改善が可能では？という議論が続きます。 今回のアラート対応を経て、私が開発であまり携わっていないシステムのことについても少しだけ詳しくなり議論に加わることができました。自分がよく知らないシステムの調査は大変です。しかしBits Chatの助けを借りることで仕様の理解と現象の理解を無理なく行えるのがよくわかりました。 そしてこれは、私だからできたという話ではありません。書籍『オブザーバビリティ・エンジニアリング』では、オブザーバビリティを実践しているチームにおける最高のデバッガーは好奇心が強いエンジニアであると述べられていました。裏を返せば、デバッグに必要なのは深いシステム知識ではなく好奇心ということになります。その知識の差はBits Chatが埋めてくれます。開発経験が少ない私でも越境して調査に加われました。好奇心さえあれば、多くの開発者が同じように動けるはずです。Bits Chatの力と好奇心を武器に、どんどんアラート対応して学んでいきたい所存です。 www.oreilly.co.jp まとめ Bits Chatのユースケースや社内での活用例、その結果もたらされたものについて書いてみました。改めてBits Chatが私たちの開発組織にもたらしたものを3つ挙げます。 社内のDatadogチャンピオン（例えば私）を頼ることなく、開発者が自発的にBits Chatと対話し、エラーの原因分析や計装の改善を進めるようになりました。社内で一番Datadogに詳しいのはもう私ではなくBits Chatです。 ダッシュボードの分析会が「データを眺めるだけの会」から「Next Actionが生まれる会」に変わりました。分析そのものをBits Chatに任せることで、私たちはデータへの疑問や改善アクションの議論、ひいてはユーザーへの価値提供に時間を使えるようになりました。 開発経験の多寡を問わず、担当していないシステムの調査にも越境して加われるようになりました。よく知らないシステムであっても仕様の理解と現象の理解を無理なく進められます。 Bits Chatは便利です。開発組織にとても多くのメリットをもたらしてくれます。Datadogを使っているけど上手く使い切れていないという課題を感じている方は導入をオススメします。一見コストが高いと感じられるかもしれませんが、利用することで得られるものは少なくないはずです。 今後の課題 一方でBits Chatはトークンを消費してアクションを行うので、どのように運用すればトークンが最適化されるのかを考えなければなりません。複数人でアラート対応をしている際、各自がばらばらにBits Chatへ質問をするとトークンが無駄になる可能性があるため、この場合の最適な運用フローを今後整備していく必要性を感じています。また、Bits Chatへ頼りきってしまい、ダッシュボードの整備が全くできていないという状況を招かないよう気をつけていきたいと思います。 私個人としましては、エンジニアが自分の言葉でBits Chatとやり取りして問題を解決する（もしくは解決の糸口を見つける）というのは大事な体験であると思っているので、あまり制限せずに効率的な運用ができたらなーと考えています。Bits Chat愛好家のみなさま、コスト最適化についてぜひディスカッションしましょう！ *1 : 強いモチベーションと推進力で導入を牽引する人。公式のDatadog Championsではありません

1. はじめに 以前、以下の記事でAWS AI Leagueについて紹介しました。 https://zenn.dev/nttdata_tech/articles/a907eb00cbbe4b AWS AI Leagueは、競技形式で生成AIの技術を学ぶプログラムです。主に、次の2つのテーマが用意されています。 Amazon SageMaker AIを利用したモデルのファインチューニング Amazon Bedrock AgentCoreを利用したAgentic AI Agentic AIチャレンジでは、AIエージェントがマップ上を移動し、コインの取得や質問への回答などを行いながら、