はじめに こんにちは。KINTOテクノロジーズ（以下、KTC）の AIファーストG に所属している、野村宏樹です。 このたび、2026年6月1日付で Microsoft MVP（Most Valuable Professional）を Microsoft Foundry カテゴリ で受賞しました。Azure 上での生成AI／AIエージェント開発を中心に発信してきた活動を評価いただいたもので、とても光栄に思っています。本記事では、受賞のご報告と、その背景にあったKTCでの活動についてご紹介します。  Microsoft MVP として届いたトロフィー 受賞の証として、MVPプロフィールも公開されています。 https://mvp.microsoft.com/ja-JP/mvp/profile/93ebd9f1-a8c0-492c-8cc2-adc7f5f980e9 Microsoft MVP プロフィールページ Microsoft MVP とは Microsoft MVP は、Microsoft 製品・技術に関する深い知見と、技術コミュニティへの継続的な貢献を称えて Microsoft 社が「個人」に授与するアワードです。直近およそ1年間の活動が審査対象で、毎年の更新審査があります。技術領域ごとにカテゴリが分かれており、世界で約 3,000 名が受賞しています。受賞すると、製品の早期アクセスや製品チームと直接つながれるチャネル、年次の Global MVP Summit への招待などの機会があります。 私が受賞した Microsoft Foundry カテゴリ は、比較的新しいカテゴリ名です。 :::message Microsoft Foundry のカテゴリーは、Azure 上で生成AIアプリやAIエージェントを開発するための基盤に関する領域です。Azure AI Foundry がリブランディングされたもので、モデルやエージェントの開発・運用をまとめて扱うエコシステムを指します。 ::: 受賞につながった活動：KTCのカルチャーに支えられて 今回の受賞は、KTC の Output文化・登壇文化 、そして全社的に生成AIの業務活用を進めている環境に、大きく後押ししていただいたものでした。2025年8月にKTCへ入社して以来、「やってみたことを外に出す」「登壇して共有する」が当たり前にある雰囲気のなかで、自然と活動を続けることができました。 発信は、大きく2つの軸で行ってきました。 ① KTC事例の共有 KTCでは2023年から社内向けの生成AIチャットツールを導入し、全社で生成AIの活用を進めています。その現場で得た学びを、たとえば「社内で使うチャットアプリを自分たちで内製する意義」といったテーマで共有してきました。このテーマは、NoMaps 2025（札幌）で当時のチームリーダーである和田颯馬さんと共同で登壇しています。 https://no-maps.jp/program/tech/121500/ 社内で使うものを自分たちの手で作るからこそ、現場のフィードバックを素早く反映でき、業務に本当に必要な形へ磨き込んでいけます。そうした内製ならではの価値を、実体験ベースでお話ししました。 ② ユースケースを軸とした技術活用の共有 個人的に「面白い」「使えそう」と感じた技術を PoC で試し、ブログにまとめ、少し抽象化したものを登壇してOutputする、というサイクルで発信してきました。テーマは MCP（Model Context Protocol）、マルチエージェント（AutoGen / Microsoft Agent Framework）、Azure AI Foundry エコシステム、ローカルLLM／SLM（Foundry Local・phi-4）など。単に「何ができるか」だけでなく、 どんなユースケースで、どう使うか まで踏み込むことを意識しています。 コミュニティ活動としては、KTCが主催する 名古屋LLM MeetUp をはじめ、なごあず（JAZUG 名古屋支部）、JAZUG、すきやねん Azure など各地のコミュニティで登壇させていただきました。2025年度は個人として、ブログ31本・登壇11回ほどの活動になりました。 2025年度の登壇は以下のとおりです。 日付 イベント タイトル 2025/6/21 なごあず（JAZUG 名古屋支部） AzureでMCPサーバ！！どう活用する？ 2025/7/23 名古屋LLM MeetUp（KTC主催） チャットアプリ失敗談！製造業業務への生成AI導入 2025/8/16 JAZUG×なんでもCopilot #jaznancopa Azure AI Foundry Portal デモ 2025/9/15 NoMaps 2025（札幌） 生成AI最前線：最新トレンドと活用事例（和田颯馬さんと共同） 2025/11/21 名古屋LLM MeetUp（KTC主催） AzureでのAIエージェントはここから！Azure Functions × AI 2025/11/27 YonaAz AzureでAIエージェント、さて何から始める？ 2025/11/29 JAZUG Shizuoka リアルタイム音声モデル gpt-realtime を使った音声対話ツール 2025/12/6 なごあず（JAZUG 名古屋支部） ローカルとクラウドLLMのハイブリッドAI活用 2025/12/26 すきやねんAzure ハイブリッド構成 Queue Polling 2026/2/28 AgentCon Tokyo エージェント開発とライフサイクル管理 ～構築から AgentStore 基盤まで～ 2026/3/14 なごあず（JAZUG 名古屋支部） gpt-realtime-1.5 モデルでスタックチャン これから これからも、 「どう使うか（ユースケース）」を大事にしながら、技術のOutputを続けていきたい と思っています。AIにより技術のキャッチアップや開発は非常にしやすくなっています。大事なのはその手段をどこにどう使うと価値がでるのか？だと思っています。引き続きAzure・生成AI・AIエージェント領域の技術を突き詰めながら、ユースケースを軸にした発信を続けていきます。 改めて、日々の活動を支えてくれているKTCの環境と、関わってくださったみなさまに感謝します。 発信内容は、個人のZennにもまとめています。よろしければこちらもご覧ください。 https://zenn.dev/nomhiro 最後に KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！ 最後までお読みいただき、ありがとうございました。

【トラブル対策】AWSとAzureをSite-to-Site VPNで接続する際の3つの注意点 はじめに こんにちは！ エデュケーショナルサービス課の三角（みすみ）です。 AWS運用において、他クラウドとの連携は避けて通れないテーマになってきました。特に、AWSのVPCを仮想プライベートゲートウェイ（VGW）で、Azureの仮想ネットワーク（VPN Gateway）とSite-to-Site VPNでつなぐマルチクラウド構成の要件は増えています。 両者はどちらも標準的なIPsecをサポートしているため簡単に繋がりそうに思えますが、「クラウドごとのデフォルト設定の違い」や「コンソール画面上の表記…

藤原です。 みなさん、システムコストの管理、どうしていますか？ システムコストがどの程度発生しているのか、どんな機能から発生しているのか、特定の機能が利用された際にどの程度のコストがかかっているかを気にしたことはありませんか。 本エントリでは、Datadog Cloud Cost Managementを使ったマルチクラウド環境におけるコスト管理ダッシュボードの作成事例および、コスト計算を実現する方法について事例ベースで解説します。 複数クラウドのコスト管理 コスト管理を複数のクラウドサービスにまたがって行うには、多くの課題が生じがちです。 おそらくは以下のいずれかで管理している方が多いかと思います。 毎月の初めに個別クラウドの請求書をダウンロードしてスプレッドシートに転記の上、報告資料を準備 (1.よりももう少しスマートな形で)毎月の初めに個別クラウドのAPIを叩いてスプレッドシートに転記して報告資料を準備 もちろん、これを特定のワークフローの中で定義していたり、AIの支援のもと効率的に実行できるようにしている方はいると思います。 今回はDatadogのCloud Cost Managementを中心に、Datadogの機能を活用してコストのo11yを高めることを事例として提示します。 複数クラウドを横断したコスト管理の課題 結局のところ、複数クラウドを利用する場合の課題とはなんでしょうか。 おおよそ以下のようなところに集約されると思います。 異常なコスト発生の検知やコストコントロールのための打ち手を考えたいが、情報源が散逸しているので情報集約の手間が辛すぎる 情報源が散逸しているので、コストの相関関係をみていくための分析も大変 個別のクラウドサービスにはコスト管理のためのマネージドサービスが存在 1 するので、 単一のクラウドのみにオールインする形でプロダクトを提供している場合はこのような悩みは生じません。 弊社はAWS, Google Cloud, Azureいずれも使う形をとっています。したがって、特定のクラウドプロバイダのコスト管理サービスでOKとはなりません。 Datadog Cloud Cost Management Datadog Cloud Cost Management は A unified cost observability platform for Engineering and FinOps という謳い文句のとおり、エンジニアリングとFinOpsを結びつけるためのプラットフォームサービスです。 AWSやGoogle Cloud、Microsoft Azureなどいわゆるメガクラウドと呼ばれるクラウドサービスプロバイダはもちろん、GitHubやAnthropic、OpenAIなどのサービスにも対応しています。 個別クラウドサービスプロバイダのコスト管理サービスとDatadog Cloud Cost Managementの比較 先ほども述べたとおり、クラウドサービスプロバイダ固有のコスト管理サービスは存在しています。 それらと比較した場合のDatadog Cloud Cost Managementのメリット・デメリットを見てみましょう。 その上で利用事例を見た上で判断すると良いでしょう。 クラウドサービスプロバイダ固有のコスト管理サービス メリット zero configurationで単一クラウド内の情報を取得できる デメリット 複数クラウドに横断する形のコスト管理には対応していない 個別クラウドごとのサービス利用方法を理解する必要がある Datadog Cloud Cost Management メリット 複数クラウドプロバイダー横断での各種メトリクスの集計とダッシュボード化 すべての分析、設定操作をDatadogの中で実施する形となるので設定方法の習得コストは低くなる デメリット 有償 2 個別クラウドのメトリクスを取得するための設定が必要 クラウド固有のコスト管理サービスの強みは、原則としてZero configuraionな点です。 ひとまず何かしらの分析をしようと思えば特に設定することなく、メトリクスがそこに存在しダッシュボード化できるという点が魅力です。 ただし、特定クラウドの中のサービスなので、カスタムメトリクスで数値情報を何かしかの情報で取り込むなどしない限りはクラウドサービス横断で情報を集計するといったことは困難でしょう。 翻って、Datadog Cloud Cost Managementについては、メリットとしては複数のクラウドプロバイダーのメトリクスを集約してダッシュボード化できるという点が挙げられます。 また、複数のクラウドプロバイダのコスト情報を同じ操作感で調査、ダッシュボード作成ができます。 一方で有償サービスであること、個別のクラウドプロバイダとの繋ぎ込みの設定が必要なことデメリットと言えるでしょう 3 。 活用事例 ここからは活用事例です。 具体何を見ているかと言われると、現状は以下を実現しています。 全体としてのコスト概要 クラウドプロバイダ別のコスト詳細 個別テナント・機能別のコスト統計 全体としてのコスト概要 確定分のコストとして、ひと月前とふた月前のシステムコスト統計を比較できるようにしています(図1)。 図1. 全体としてのコスト比較 基本的には、 クラウドプロバイダ単位で意図しない大きなコスト変動が発生していないか？ や、 コスト削減のためのアクションを実施したけれどもどれくらいの効果が全体で見た時に出ているか？ などをウォッチする目的です。 詳細は別のダッシュボード(タブ)に任せています。 クラウドプロバイダ別のコスト詳細 クラウドプロバイダ別に環境やサービス、とくにコスト総額が大きかったり変動比率が大きいサービスについてトレンドや、直近2ヶ月のコストを比較できるようにしています。 図2. クラウドプロバイダ別のコスト傾向 とくにコスト観点で注目したいサービスについてはサービスごとにふた月前まで含めたコスト比較をできるようにしています。 図3. とくにコスト観点で着目すべきサービスは別途具体的な数値ベースで比較できるようにしている 利用金額がそもそも大きいサービスや、新規に利用を開始したばかりのサービスなどについてはトレンドだけでなく、詳細をウォッチするようにしたほうが良いでしょう。 個別テナントごとのシステムコスト 個別テナント毎の平均システムコスト（≒ システム原価）を見えるようにもしています。 システムコスト総額をテナント数で除算した結果がシステムコストのテナントあたりの平均システムコストになります(図4)。 図4. テナントごとのシステム原価を見れるようにする 図4のようにテナント数の変動を見つつ、システム原価をさまざまな試算パターン別に見れるようにしています。 従量によるコスト発生度合いの大きい機能についてのモニタリング さらに追加で、変動要素の多いものとしてAI系の機能についてのコストも算出できるようにしています。 具体的には以下のようなものをみています。 個別機能毎のコスト総額 テナント別の機能利用に伴うコスト統計 弊社では、AIに関連した機能提供に際しては、Vertex AIを利用しています。 Vertex AIのクライアントでリクエスト時に追加のラベル（どの機能からの呼び出しなのか、どのテナントからの呼び出しなのか）を設定することで、どの機能、どのテナントがどれくらいのコストを発生させているのか？を確認できるようになっています 4 。 図5. どの機能別にコストが発生しているかを可視化 どのテナントが、積極的に利用しているのか？なども見ることができます。 図6. テナント別の利用料金変動の概観 とくにたくさん利用されているテナントについては、ヘビーユーザーだと思うので、ヒアリングしてみるといったアクションも取れるかもしれないですね。 機能別の処理単価 最後は機能別に処理を1回実行するとどの程度のコストが発生しますか？も概算を見れるようにしています。 この辺りが見えるようになると、さらに精緻にコスト戦略を練れるようになるでしょう。 あまりにもコスト的に上振れしていればなんらかのコストコントロール施策のための作業が必要になるでしょうし、あまりに低ければもっと豪勢なモデルを使ってもいいんでないか？といった議論ができるかもしれません。 基本的には以下の情報が必要になるでしょう。 機能別のコスト総額 機能別の呼び出し回数 1については、すでに図5で取得できることがわかっています。 2についてはどうでしょうか、特定機能の呼び出し回数を計測することは案外大変です。パッとは取れません。 そこで、ALBのアクセスログからDatadogのカスタムメトリクスを作成し、エンドポイントごとの呼び出し回数を測定できるようにしました。 エンドポイントとAI機能の対応関係が取れるため、それをベースに個別機能の呼び出し回数を取れるようにしました(図7)。 1の数値はGoogle Cloudからの取得、2の数値はAWSからの取得という形で複数クラウドを横断する形でコスト分析をできるようになっており、その好例と言えるかもしれません。 最終的に、機能別のコスト総額を機能別の呼び出し回数で除算することで機能別の呼び出し単価を計算できるようになりました。 図7. 機能別の1回呼び出しごとの発生コストの推移 これで対象機能のプロンプトを変更したり、モデルを変更した際のコスト推移を見ることができるようになりました。 まとめ ここまで、複数クラウド環境でのコストのo11yを改善するための手段としてDatadog Cloud Cost Monitoringについての事例を解説しました。 もちろんメリット・デメリットありますが、毎月のコストモニタリングの手間やクラウド横断でのコスト分析に苦労している人にはおすすめできる機能だと思うのでぜひ利用を検討してみると良いのではないでしょうか。 AWSであれば、 Billing and Cost Management 、Google Cloudであれば Cloud Billing 、Microsoft Azureであれば Cost ManagementとBilling といったクラウドプロバイダ固有のサービスが存在します。 ↩ 具体的な料金設定は 公式ページ を参照してください。なお、クラウドサービスプロバイダによってはAWSのCloudWatchのように ダッシュボード作成が有償 といった場合もあるのでご注意ください。 ↩ ただし公式のインテグレーション機能が用意しているため設定自体は難しくはありません。 ↩ なお、この仕組みは個別プロダクトの開発メンバーの協力のもと、プロダクトコードにてラベル埋め込みを進めました。 ↩