Azure

はじめに 顧客が明確に伝えたニーズを正しく理解できないまま、無理に案件を受注しようとする「くれくれ営業」は、顧客の時間を奪うだけでなく、会社の信頼そのものを損ないます。 この記事では、Entra IDに関する依頼を巡って発生した認識のズレと、その後の営業報告書を巡る不可解なやり取りを紹介します。 本記事は、エンジニアや企業を貶めることを目的としたものではありません。情報収集が困難な業界内情を提供し、今後のキャリアに役立てていただくこと、そして業界への監査を行うことを目的としています。 チャンスを自ら潰す案件潰しPL その2 案件依頼 これは、大手メーカー系SierのB社の下請けとして開発案件を受けている、岡山県のシステム会社A社での出来事。 A社は数十名規模のシステム会社で、B社から受注した案件をPL（プロジェクトリーダー）とエンジニア数名の体制で回すことが多かった。 ある日、B社からA社のエンジニアCに、Entra IDでのユーザー管理設計に関する問い合わせがメールで届いた。 顧客B社 🙂 「別案件でEntra IDのユーザー管理設計をする必要があるんですけど、Cさんはその辺の知見ってありますか？」 C 😐 「僕はちょっと詳しくないんですけど、社内で該当の知見があるエンジニアを探してみます。」 Cは該当のエンジニアを探すため、営業報告書を作成しPLに提出した。すると、PLからこう返信が来た。 PL 🤔 「社内ルールで、クライアントのニーズをFace to Faceで確認しないと、営業報告書出しても『クライアントのニーズを詳細に聞け』って突っ返されるんよ。」 PLは社内で適切なエンジニアを探すため、顧客に対面で詳細な打合せをしたい旨をメールで連絡した。 打合せ 打合せが始まると、顧客が丁寧に背景を説明し始めた。 顧客 🙂 「A社さんに依頼をした背景なんですけど、ユーザーがオンプレからクラウドへの移行を検討中で、クラウド化にあたりいくつか課題があります。」 顧客 🙂 「A社さんにはそのうち、『Entra IDの部分』を対応していただきたいと考えているんですよ。」 分かったような顔で頻繁に相槌を返すPL。 C 😶 （本当に分かってるのかな……。） 顧客の話によると、クラウド化にあたってリソースをIaC化することなど複数の課題があり、そのうち依頼したいのはEntra IDによるセキュリティ設計の部分のみだという。 顧客の説明が一通り終わったところで、PLが口を開いた。 PL 🤔 「C君は（Entra IDの設計）できんのかなぁ？」 C 😳 「え!? もともと私が対応できないから、社内で技術者を探すって話でしたよね?」 すると、PLが声を張り上げ、驚愕の発言をした。 PL 😤 「社内で（技術者を）探したけど、いなかったんよ!!」 C 😨 「!?」 そもそもこの打合せは、社内で該当のスキルセットを持つエンジニアを探すために、クライアントのニーズを聞く必要があるという理由で開催されたものだった。 ニーズを聞かなくても社内でエンジニアを探せるなら打合せを開く意義は薄れるし、既に社内に該当のスキルセットを持つエンジニアがいないと分かっているなら、なおさら打合せを開く意味がない。

はじめに Azure SRE Agent では、ユーザーが特定のタスクを実行するための特化したエージェントを、カスタムエージェントとして定義・作成することができます。 本記事では、カスタムエージェントの定義方法から実際の活用方法まで、詳しく解説します。 カスタムエージェントとは カスタムエージェントは、ユーザーが入力した特定のタスクを実行するために特化したエージェントです。 標準的なSREエージェントではカバーしきれない、特殊な役割や機能を必要とする場合に活用します。 カスタムエージェントの定義方法 カスタムエージェントは以下のようにYAML形式で定義できます。 name: database_expert system_prompt: |You are a database specialist. Analyze query performance, diagnose connection issues, and recommend optimizations. handoff_description: Handles SQL and database troubleshooting tools: - execute_kusto_query - azure_cli connectors: - azure_sql enable_skills: true # Can use skills for additional expertise 定義要素の説明 要素 説明 name カスタムエージェントの識別子 system_prompt カスタムエージェントの役割や動作を定義するプロンプト handoff_description オーケストレーターがこのカスタムエージェントにタスクを委任する判断基準となる説明文 tools カスタムエージェントが使用できるツール（azコマンド、外部APIなど） connectors 接続するAzure リソースやサービス enable_skills 有効にするとカスタムエージェントがスキルに動的にアクセス可能 重要な注意点 SRE エージェントのカスタムエージェントは、Claude Code のサブエージェントとは異なり、使用するモデルを指定することができません。

はじめに Azure SRE Agentは、Azure Monitorやログなどの監視データを活用してインシデント対応を支援するAIエージェントです。 その能力を最大限に引き出す鍵となるのが「コネクタ」機能です。 コネクタを設定することで、SREエージェントはAzure Monitor、Application Insights、Log Analyticsといった監視サービスや、GitHubリポジトリ、Teamsなどの外部サービスとシームレスに連携できるようになります。 本記事では、Azure SRE Agentのコネクタの概要、サポートされているサービス、導入するメリット、そしてApplication InsightsとLog Analyticsの違いについて解説します。 Azure SRE エージェントのコネクタ エージェントには、Azureサービスへの組み込みアクセスが用意されています。 コネクタは、外部サービスとSREエージェントを接続し、SREエージェントから外部サービスへのクエリの実行や、コードの読み取り、通知の送信を可能にします。 Azure公式ドキュメント: SREエージェントのコネクター サポートされているコネクタ Azure Monitor Application Insights Log Analytics Azure Resource Graph GitHubリポジトリ Teams カスタムAPI コネクタのメリット コネクタが設定されていない場合でも、SREエージェントは az コマンドが組み込まれているので、azコマンドを使ってApplication Insights、Log Analyticsなどへのクエリの検索は可能です。 敢えてコネクタを設定するメリットとしては、以下の点があります。 コネクタを使用するメリット： 毎回対象を指定しなくてもよい - 特定のLog AnalyticsワークスペースやApplication Insightsリソースをエージェントが継続的に認識 接続先のデータがコンテキストに入る - 接続先の監視データが前提知識として扱われやすくなり、調査時の文脈理解が速くなる 高度な診断がしやすくなる - 接続されたリソース全体をまたいだMCPベースの診断に使え、組み込みで提供されたToolsが使える コネクタは「単にクエリできるようにする」ためだけでなく、「どの監視データを常に見てよいかをエージェントに覚えさせ、継続的な診断能力を上げる」させることができます。 Application InsightsとLog Analyticsの違い Application Insightsで表示できるメトリクスはLog Analytics Workspacesに保存されます。 Log Analyticsだけでなく、Application Insightsを使うメリットとしてはLAWの情報を抽象化（アプリケーションマップなど機能）が使えるようになることです。

はじめに Azure SRE Agent には、過去のインシデント対応やユーザーとのやり取りから学習した知識を蓄積し、次回以降の対応に活かす「メモリ」という仕組みがあります。 本記事では、メモリの種類や自動学習の仕組み、ユーザーメモリの操作方法、ナレッジベースとの違いについて解説します。 メモリ メモリとは過去のインシデントで何が機能していたかなど、エージェントに蓄積することができる知識情報です。 メモリの種類 情報源 発見内容 最適な用途 過去のインシデント 同様の問題を解決した手順 以前、どのようにこれを修正したのですか。 ユーザーメモリ 明示的に保存するファクト “私の環境設定が使用することを覚えておいてください…” ナレッジベース アップロードしたランブックとドキュメント “標準手順に従う” 自動学習 SREエージェントはユーザーとの会話から自動で学習し、メモリに記録します。 スレッドが更新されなくなってから30分後、エージェントは会話を評価し、学習のインデックスを作成します。 プロアクティブな知識の永続化 完了したスレッドから学習するだけでなく、エージェントは会話中に重要と判断した知識をナレッジファイルに保存します。 ナレッジファイルは memories/synthesizedKnowledge/ 配下に保存され、次回セッション開始時に自動読み込み、より賢い回答を生成します。 ナレッジファイルの種類 ファイル 内容 文字数上限 overview.md サービスの概要とインデックス 約2,000文字（常にコンテキストに読み込まれる） トピックファイル 特定の主題に関する詳細な注意事項（例: aks-networking-gotchas.md） 各1,000文字 team.md チームメンバー、役割、専門知識 最大500文字 architecture.

はじめに 2026年6月2日〜3日に開催された Microsoft Build 2026 で、AIエージェント開発プラットフォームの Microsoft Foundry が大きく前進しました。 本記事では、機能の仕様を羅列するのではなく、「ぶっちゃけ何ができるのか」「自分たちにどう嬉しいのか」 を中心に、実務エンジニア向けにかみ砕いて解説します。 Microsoft Build 2026 公式サイト Foundryって、ざっくり何？ 一言で言うと、。 「AIエージェントを、作って・動かして・賢くし続けるための、全部入りプラットフォーム」 「エージェントを作って・動かして・賢くし続ける」ための機能が一通り揃い、本格的な本番利用に耐えるプラットフォームになりました。 従来のつらみ（Before） 社内用のAIアシスタントを1つ作りたい、となったら、どうなるか。 エージェントのロジックを書く（これが本来の本題） ↓ でもその前にやることが山積み…… □ 社内文書を検索する仕組み（RAG）を自作 □ Outlook、Teams、Jiraなどと連携するコード □ ユーザー認証と権限制御 □ セキュアに動かすサーバー基盤 □ ログ、監視、コスト管理 □ 「前回の会話を覚える」機能 ↓ やっと本題……でも予算も時間も尽きた 😫 一番大事な「エージェントを賢くする」ことに集中できない のが、従来の最大の問題でした。 Foundryだと（After） Foundryを使うと、こうなります。 エージェントのロジックを書く（ここに集中できる） ↓ 回りは全部Foundryにお任せ ✅ 社内文書検索 → Foundry IQ ✅ ツール連携 → Toolboxes ✅ 認証・権限 → 自動で処理 ✅ 本番サーバー → Hosted Agents ✅ 監視・コスト管理 → 自動で取得 ✅ 会話を覚える → Memory 「エージェントがどう答えるか」という中身だけ書けば、回りのインフラ仕事はFoundryが全部面倒を見てくれる。

はじめに Azure SRE Agent は、Azure 環境における運用業務を効率化・自動化するために登場した AI エージェントです。 従来の監視ツールやオペレーション自動化ツールとは異なり、インシデントの検知だけでなく、その原因調査や対応支援、さらにはリソース操作までを一貫して実行できる点が大きな特徴です。 本記事では、Azure SRE Agent の基本機能や料金体系、活用方法について整理し、実運用でどのように活かせるのかを解説します。 Azure SRE Agentとは Azure SRE Agent は、Azure 上のリソースに対して継続的なヘルスチェック、インシデント調査、復旧支援を行うことができるAI エージェント。 以下のような特徴があります。 様々な種類のトリガーで起動できる (チャットベース、Webhook通知、cronによる定期実行) azコマンドを内部で実行できるのでAzure上のリソースに対する操作が可能 ハーネス機能が実装されている (Skills, サブエージェント作成、 MCP連携) 料金体系 Azure SRE Agentの料金は Azure Agent Units（AAU） を基準に算出されます。 発生する料金として以下の2種類があります。 常時稼働フロー（固定費） アクティブフロー（従量課金） Azure SRE Agent: 料金ページ 常時稼働フロー（Always-on flow） エージェントの稼働時間に応じて発生する固定のコスト。日本円(1ドル150円)換算： AAU単価：0.10ドル (15円) 1エージェント：4 AAU / 時間 = 0.4ドル / 時間 60円 / 時間 1,440円 / 日 43,200円 / 月 24時間365日分の課金を避けるには、監視が不要な時間帯はSREリソースを削除し、使用する際に再作成するといったフローが必要になる。

AzureでもClaude Codeを使いたい！ Claude CodeでMicrosoft Foundryのモデルを使う手順 はじめに 2025年11月のAzureのアップデートで、Microsoft Foundry(旧AI Foundry)でもAnthropic系のモデルが使用できるようになりました。 今までAzureプラットフォームでしかLLMを使用できないユーザーはClaudeモデルを使用することができませんでしたが、今回のアップデートからClaudeモデルが使用できることになります。 そこで、この記事では、Claude CodeでMicrosoft Foundryのモデルを使用する手順を紹介します。 1. Microsoft Foundryリソースのプロビジョニング Azure で Claude リソースを作成します。 Microsoft Foundryポータルに移動する 新しいリソースを作成し、リソース名をメモします。 Claude モデルのデプロイメントを作成します。 Claude Opus Claude Sonnet Claude Haiku 2. MS Foundryへのアクセス情報を取得 Claude Codeは、Microsoft Foundryでは、APIキーとEntra IDでの認証の2つの認証方法をサポートする。 自身のAzureユーザーアカウントにMicrosoft Foundryへのアクセス必要なRABCのロールが付与されている場合は、EntraIDを使用した方が、セキュアなアクセスになるので、おすすめです。 APIキー認証 エンドポイントとキーのセクションからAPIキーをコピーして控えます。 後述の環境変数の設定で、APIキーを設定します。 ANTHROPIC_FOUNDRY_API_KEY=xxx Microsoft Entra ID認証 ローカル環境でEntra IDを使用する場合は、一般的に Azure CLI を使用します。 Azure CLIをインストールして、Claude Codeの起動前に以下のコマンドを実行します。 az login 3.環境変数を設定 Claude Codeのsettings.jsonに以下を設定します。 ※Entra ID認証の場合は、ANTHROPIC_FOUNDRY_API_KEYの行は不要です。また、漏洩させないようにGit 管理しないようにしましょう。 { "companyAnnouncements": [ "Success to load ~/.

はじめに Microsoft Foundry（旧：Azure OpenAI Service）では、API キーを使用したローカル認証（Local Auth）と、Azure AD（Microsoft Entra ID）を使用した認証方法の2つが利用できます。 しかしセキュリティ要件が厳しい環境では、API キーの使用を禁止し、Azure AD 認証に統一したいケースも少なくありません。 そこで本記事では、Microsoft FoundryのAPIキー（Local Auth）をCLI経由で無効化する手順を紹介します。 Azure Portal からはまだ UI が提供されていないため、Azure CLI の az rest コマンドを使ったREST API実行が必要です。 APIキーを無効化することで得られるメリット API キー（Local Auth）を無効化し、Azure AD 認証に統一することで以下のメリットがあります。 セキュリティが強化される API キーは漏洩しやすく、権限の細かい制御ができません。 Azure AD に統一することで、ユーザー単位のアクセス制御や条件付きアクセスが適用でき、より厳格なセキュリティが実現できます。 キー管理の手間が不要になる API キーのローテーションや再配布、キーが漏洩した場合の緊急対応などの運用負荷が削減されます。 監査性が向上する Azure AD ベースの認証であれば、誰がいつアクセスしたかを確実に追跡できるため、ログや監査レポートの精度が大きく向上します。 API キーを無効化すると以下の点に注意が必要です。 既存の API キーを利用したアプリケーションは すべて動作しなくなる → 事前にコードを Azure AD 認証に対応させておく必要があります。 Azure Functions や Logic Apps など、一部サービスは追加設定が必要な場合がある チームメンバーや開発者に事前共有しないと混乱が起きやすい 本番環境で実行する場合は、事前に非本番環境でのテストを強く推奨します。 APIキーを無効化する APIキーを無効化するには、Azure CLIからRest APIを実行します。

はじめに この記事では、Azure、Google クラウド、Google Cloudの3大クラウドサービスのAIサービスの新規機能リリース履歴をまとめています。 主に以下のURLの情報をもとに新機能のキャッチアップを行っています。 Azure公式ドキュメント: Azure OpenAI Serviceニュース Azure公式ドキュメント: Azure AI Agent Serviceニュース Github: Azure公式ドキュメント管理リポジトリ Github: Azure OpenAI APIプレビューバージョン一覧 Github: Azure OpenAI API安定版バージョン一覧 AWS公式ドキュメント: AWS Bedrockリリースノート Google Cloud公式ドキュメント: Vertex AIリリースノート Anthropic公式ドキュメント: APIバージョン一覧 Azure 2025年12月01日: GPT-image-1.5モデルが利用可能に OpenAIの最新画像生成モデルGPT-image-1.5がリリースされました。 パフォーマンス、品質、編集コントロール、顔の保持機能が向上しています。 編集モードでは、高い入力忠実度をサポートし、入力画像の一部を追加/削除しながら他の部分を保持できます。 主な機能: テキストから画像生成 画像から画像生成（編集） インペインティング 高品質な画像生成（最大1024x1536および1536x1024ピクセル）

はじめに この記事ではOpenAIのGPTシリーズや、AnthropicのClaudeシリーズ、GoogleのGeminiシリーズなどの主要モデルについて比較表にまとめています。 免責事項: 本記事の料金や仕様は公開時点の情報であり、変更される可能性があります。最新情報については各サービスの公式ドキュメントをご確認ください。 提供プロパイダー 各モデルの提供団体は以下の通りです。 プロパイダー モデル 設立 国 備考 OpenAI GPT 2015年12月11日 米国 GPTは「Generative Pre-trained Transformer」の略。2017年にGoogleが発表したLLM「Transformer」がベース。事前に大量のデータで訓練されたLLMを示す。 Anthropic Claude 2021年ごろ 米国 Claudeはフランス語圏に多い名前。 数学者クロード・シャノン（Claude Shannon）など Google Gemini 1998年9月4日 米国 Geminiはラテン語で双子座を意味する。Google社内の2つの研究チームが合併したこと、Geminiの共同技術責任者がLLM開発はロケットを打ち上げる精神と同じと共鳴したことが由来。 Meta Llama 2004年2月4日 米国 Large Language Model Meta AI 料金 以下のリンクから各LLMの料金をまとめたExcelを表示できます。 LLM料金表 注記: 最新の料金情報は各公式ドキュメントでご確認ください 料金参考リンク OpenAI系モデル OpenAI公式ドキュメント: OpenAI APIの料金 Azure公式ドキュメント: Azure OpenAIの料金 Anthropic系モデル Anthropic公式ドキュメント: Anthropic APIの料金 AWS公式ドキュメント: AWS Bedrockの料金 Google Cloud公式ドキュメント: Google クラウド Vertex AIの料金 Google系モデル Google Cloud公式ドキュメント: Google クラウド Vertex AIの料金 Meta系モデル AWS公式ドキュメント: AWS Bedrockの料金 Google Cloud公式ドキュメント: Google クラウド Vertex AIの料金 Model ID参考リンク OpenAI系モデル OpenAI公式ドキュメント: モデル一覧 Azure公式ドキュメント: モデル一覧 Anthropic系モデル Anthropic公式ドキュメント: モデル一覧 AWS公式ドキュメント: AWS BedrockのAnthropicモデルID覧 Google Cloud公式ドキュメント: モデルガーデン Google系モデル Google公式ドキュメント: Vertex AIのモデル一覧 Meta系モデル AWS公式ドキュメント: AWS BedrockのAnthropicモデルID覧 Google公式ドキュメント: Vertex AIのモデル一覧 機能要件 プラットフォーム 入力 出力 機能 モデル名 Azure AWS Google クラウド テキスト 画像 音声 動画 PDF テキスト 画像 音声 日本語対応 Thinking Streaming Fuction Calling Structured outputs GPT-4o 〇 〇 〇 〇 〇 〇 〇 〇 GPT-4o-mini 〇 〇 〇 〇 〇 〇 〇 〇 GPT-4.