はじめに Azure Functionsを運用していると、突然関数リストが表示されなくなり、「We were not able to load some functions in the list due to errors」というエラーメッセージが表示されることがあります。 本記事では、Application InsightsでOpenTelemetry（OTEL）を使用している場合に発生する、OTEL_SERVICE_NAME環境変数が未定義であることが原因のエラーについて、その原因と対処方法をご紹介します。 エラーの症状 Azure PortalでFunctionsのページを開いたときに、以下のようなエラーメッセージが表示され、関数のリストが読み込めなくなります。 We were not able to load some functions in the list due to errors. Refresh the page to try again. Error while loading Ask questions and use troubleshooting tools to investigate these errors. Diagnose and solve problems この状態では: 関数の一覧が表示されない 個別の関数の詳細も確認できない コード上ではApplication Insightsへのデータ送信は正常に動作している エラーの原因 このエラーは、Application InsightsでOpenTelemetry（OTEL）を使用している場合に、OTEL_SERVICE_NAME環境変数が設定されていないことが原因です。 Azure FunctionsでOpenTelemetryを使用してテレメトリデータを送信する際、サービス名を識別するためにOTEL_SERVICE_NAME環境変数が必要になります。

はじめに 本記事では、Azure Durable Functions を使用して開発・運用されている方向けに、デプロイスロットを併用する環境で発生する「リクエストが別スロットにルーティングされる事象」について解説します。 特に、本番と検証で同一のストレージアカウントを利用している場合は注意が必要です。 Azure Durable Functionsとは Azure Durable FunctionsはAzure Functionsの拡張機能です。 詳細は以下の記事をご参照ください。 Azure Durable Functionsとは 事象 Azure Durable Functions において2つのスロット(production と staging)で運用をしていました。 上記構成においてstagingスロット上のアプリにリクエストしていたにも関わらず、オーケストレーター関数がproductionのアクティビティ関数を実行する事象が発生していたため調査を行いました。 原因 Durable Functions では、状態管理およびオーケストレーション処理に Azure Storage（Queue や Table）を使用しています。 このとき、本番と検証のスロットで同一のストレージアカウントおよび同一の TaskHubName を利用している場合、Durable Functions のステート情報が混在し、スロット間でリクエストが交差してしまうことがあります。 詳細は以下の Stack Overflow のディスカッションもご参照ください： Azure Durable Functions invoked in mixed slots 対策 1. host.json の Task Hub 名をスロットごとに分ける Durable Functions では host.json ファイルで durableTask.hubName を指定できます。スロットごとに異なる名前を明示的に設定することで、ステートの混在を防止できます。 { "version": "2.

はじめに Azureにおいて、従量課金プランのFunctionsを作成した際に、エラーが発生し、Functionsが作成できなるなることがあります。 本記事では、上記事象の原因と対応方法についてご紹介します。 Linux dynamic workers are not available in resource group ＜リソースグループ名＞エラー 上記のエラーはAzure の仕様により、同一リソースグループ内に Windows と Linux の App Service Plan を混在できないことを示しています。 対象のリソースグループに一度でも Windows の App Service Plan を作成すると、たとえ削除しても Azure 基盤側にその情報が保持され、そのリソースグループ内では Linux の Dynamic SKU（従量課金プラン）を新規作成できなくなります。 公式ドキュメント 対処方法 結論としては、別のリソースグループを新たに作成し、そちらに Azure Functions（Linux/Consumption Plan）を作成することでFunctionsの作成が可能になります。 おわりに 本記事では、「Linux dynamic workers are not available in resource group」というエラーの原因とその対処方法について説明しました。 a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A1CfX"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/789749/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/J6100281917861.jpg?1696410860000"}}); a8adscript('body').showAd({"req": {"mat":"3HREPM+6UHH82+279M+HUSFL","alt":"商品リンク","id":"3IzcOOW-g7-u2A2FzR"},"goods": {"ejp":"h"+"ttps://ebookjapan.yahoo.co.jp/books/721208/","imu":"h"+"ttps://cache2-ebookjapan.akamaized.net/contents/thumb/m/F0100169654961.jpg?1663322311000"}});

はじめに この記事では、VertexAIのGroundingをREST API仕様についてまとめています。 公式ドキュメントにはSDKを使った例は載っていたのですが、REST APIを使った例が古いAPI仕様に基づくものになっていたので、紹介します。 Groundingとは Vertex AIの「Grounding」は、生成AIモデルの出力を信頼できる情報源に結びつけ、回答時に出典が明記したレスポンスを生成する機能です。 現状は、以下の2種類のGroundingが可能です。 Google 検索によるGrounding ユーザー独自データでのGrounding Google Cloud公式ドキュメント: Grounding 料金 VertexAI GroundingでGemini 2.0 Flashを使った場合の料金は以下のようになっています。 1日1500件までは無料ですが以降は1000件当たり、$35と割高 1日のリクエスト数 料金（米ドル 備考 ～1,500件 無料 無料枠 1,501～1,000,000件 $35 / 1,000件 従量課金 1,000,001件以上 要問い合わせ アカウント担当者に要連絡 公式ページ: Vertex AI Pricing ちなみに、AzureでGroundingをする場合も1000件当たり$35。 プラン名 最大コール数 料金 主な特徴 Grounding with Bing Search 1秒あたり150トランザクション1日あたり100万件 $35 / 1,000トランザクション - Bing Search APIを活用したグラウンディング- Azure AI Foundry Agentの知識ソースとして利用可 Grounding with Bing Custom Search 1秒あたり150トランザクション1日あたり100万件 $35 / 1,000トランザクション - カスタム検索空間を指定してグラウンディング- Azure AI Foundry Agentの知識ソースとして利用可 公式ページ: Microsoft Bing Grounding API Pricing

はじめに この記事では、Azure、AWS、Google Cloudの3大クラウドサービスのAIサービスの新規機能リリース履歴をまとめています。 主に以下のURLの情報をもとに新機能のキャッチアップを行っています。 Azure公式ドキュメント: Azure OpenAI Serviceニュース Github: Azure公式ドキュメント管理リポジトリ Github: Azure OpenAI APIプレビューバージョン一覧 Github: Azure OpenAI API安定版バージョン一覧 AWS公式ドキュメント: AWS Bedrockリリースノート Google Cloud公式ドキュメント: Vertex AIリリースノート Anthropic公式ドキュメント: APIバージョン一覧 Azure 2025年05月20日: Azure AI Foundry Agent Serviceの一般提供が開始 Azure AI Agent Serviceは、AI エージェントの構築・管理ができるマネージドサービスです。 Azure AI Agent Serviceは、以下のような機能を持ちます。 AI Foundry PortalやAzure AI Foundry SDKを使って、エージェントの構築、管理が可能 複数のAIエージェントを組み合わせるマルチエージェントの構築が可能 A2A（Agent2Agent）、MCP（Model Context Protocol） などの業界標準プロトコルをサポート モデル料金

はじめに この記事では、ObsidianのGit Pluginを使って、WindowsとAndroid間でノートを同期する方法を、実際の画面操作を交えながら解説します。 Obsidianは強力なノートアプリですが、標準ではクラウド同期機能が有料です。 そこで、無料で使えるGitを活用し、複数端末でノートを安全かつ簡単に同期する手順を紹介します。 2025/07/11追記 Android版のGitプラグインが不安定で起動に失敗するケースが多いようなので、代替方法をこちらの記事に記載しました。 必要なもの GitHubアカウント ノートを保存するリポジトリ作成に必要です。 Gitクライアント Windows PCでGit操作を行うために必要です。 Obsidian ノート管理アプリ本体。Windows版・Android版をそれぞれインストールしてください。 Obsidian Git Plugin ObsidianでGit操作を自動化するためのプラグインです。 Termux（Androidのみ） AndroidでGitコマンドを利用するためのLinux環境アプリです。 F-Droid（Androidのみ） Termuxをインストールするためのオープンソースアプリストアです。 Gitリポジトリを作成 Obsidianのノートを格納するためのリポジトリをGitHubで作成します。 リポジトリ名を入力し、Privateリポジトリを作成します。 Gitのパーソナルアクセストークンを発行 ObsidianがGitを操作するために使用するパーソナルアクセストークン(PAT)を発行します。 Windows PCの操作 ローカルにリポジトリをクローン 以下のコマンドを実行し、リポジトリをローカルPCにクローンする。 git clone https://{Gitパーソナルアクセストークン}@github.com/{ユーザー名}/{リポジトリ名}.git ObsidianにGit Pluginをインストール Obisidianを開き、Git Pluginをインストールします。 Obsidianの「設定」→「コミュニティプラグイン」から「Obsidian Git」を検索し、インストールします。 インストールが完了したら、画面下部の歯車アイコンをクリックし、Gitの設定を行います。 Auto commit-and-sync interval (minutes)とAuto commit-and-sync after stopping file edits:を設定すると、編集後に自動的にGitに変更内容が反映されるようになります。 各設定値の意味はこちらのブログに分かりやすくまとめられていましたので、ご参照下さい。 note: Obsidian Git の導入とカスタマイズ設定

はじめに この記事では、Azure、AWS、Google Cloudの3大クラウドサービスのAIサービスの新規機能リリース履歴をまとめています。 主に以下のURLの情報をもとに新機能のキャッチアップを行っています。 Azure公式ドキュメント: Azure OpenAI Serviceニュース Github: Azure公式ドキュメント管理リポジトリ Github: Azure OpenAI APIプレビューバージョン一覧 Github: Azure OpenAI API安定版バージョン一覧 AWS公式ドキュメント: AWS Bedrockリリースノート Google Cloud公式ドキュメント: Vertex AIリリースノート Anthropic公式ドキュメント: APIバージョン一覧 Azure 2025年04月05日: Azure FunctionsがMCPトリガーに対応 Azure FunctionsがMCP(Model Context Protocol)に対応したMCPトリガーが利用可能になりました。 VS Code上のGitHub CopilotなどのMCPクライアントからMCPトリガーのFunctionsをコールすることができるようになっています。 https://techcommunity.microsoft.com/blog/appsonazureblog/build-ai-agent-tools-using-remote-mcp-with-azure-functions/4401059 Microsoft公式ブログ: Azure FunctionsがMCPトリガーに対応 Zenn: MCPトリガーで現在時刻を応答するコードの例 2025年04月14日: Azure OpenAIでGPT-4.1が利用可能に OpenAIからリリースされたGPT-4.1がAzure OpenAIでも利用可能になりました。 最大100万トークン対応：従来のGPT-4o（12.8万トークン）を大幅に超える 3モデル展開：「GPT‑4.1」「GPT‑4.1 mini」「GPT‑4.1 nano」 mini：GPT-4o超えの知能、レイテンシ半減、コスト83%減 nano：1Mトークン対応、MMLU 80.

はじめに この記事では、Anthropic Claude 3.7 Sonnetから導入された拡張思考モードをPython SDKで実装する際のコードについて紹介します。 Anthropoc Caludeとは Anthropic Claudeは、Anthropic社が開発した高度なAI言語モデルです。 このモデルは、自然言語処理タスクにおいて高い性能を発揮し、特に会話型AIやテキスト生成、分析などの用途に適しています。 Anthropic Claudeは、AWSやGoogle Cloudなどのクラウドプラットフォームを通じて利用可能であり、さまざまな業界で活用されています。 Anthropic公式サイト Anthropic Claude 3.7 Sonnetとは 2025年2月にAnthropicから提供されたClaude Sonnetシリーズの最新モデルです。 3.7 Sonnetから新たに拡張思考モード(Extended Thinking mode)が導入されています。 Anthropic公式: Claude 3.7 Sonnet 拡張思考モードとは Claude 3.7 Sonnetは2つのモードで動作します。 標準モード：以前のClaudeモデルと同様に、内部の推論を表示せずに直接応答を提供 拡張思考モード：最終的な回答を提供する前にClaudeの推論プロセスを表示 拡張思考モードを使用した場合Reasoning model（推論モデル）として動作します。 Reasoning modelは、Chain of Thought（COT）という手法を活用することで、 問題解決や質問に対して、単に答えを返すのではなく、段階的に考えながら回答を導き出すAIモデルのことです。 モデルが推論の各ステップを明確に示すことができ、問題解決の過程を理解しやすくします。 Anthropic公式サイト: 拡張思考 拡張思考モード使用時の注意点 リクエストヘッダにのanthropic-betaフィールドにoutput-128k-2025-02-19を指定する必要がある リクエストヘッダに以下のように、output-128k-2025-02-19設定が必要です。 anthropic-beta: output-128k-2025-02-19 リクエストボディにthinkingパラメータを使用して、推論に使用するトークン予算（budget_tokens）を設定する 拡張思考モード使用時は回答生成とは別に、CoTによる推論でトークンが使用されるため、推論用のトークン数の予算を設定する必要があります。 "thinking": { "type": "enabled", "budget_tokens": 32000 } 設定するトークン予算(budget_tokens)はmax_tokens以下に設定する必要がある budget_tokensに設定している値がmax_tokens(出力時の最大トークン)を超過している場合は推論だけでトークン上限に達してしまうため、budget_tokensはmax_tokens以下に設定する必要があります。

はじめに この記事では、Anthropic Claudeのプロンプトキャッシュについてまとめました。 Anthropoc Caludeとは Anthropic Claudeは、Anthropic社が開発した高度なAI言語モデルです。 このモデルは、自然言語処理タスクにおいて高い性能を発揮し、特に会話型AIやテキスト生成、分析などの用途に適しています。 Anthropic Claudeは、AWSやGoogle Cloudなどのクラウドプラットフォームを通じて利用可能であり、さまざまな業界で活用されています。 Anthropic公式サイト Anthropic Claudeのプロンプトキャッシングの仕組み プロンプトキャッシングを導入すると、指定したプロンプトをキャッシュすることができます。 キャッシュするとキャッシュブレークポイント(cache_control)が設定されているプロンプトのプレフィックス(先頭部分)が、キャッシュされているかを確認します。 キャッシュされている場合、プレフィックス部分のプロンプトを再利用することで、LLM側での内部処理が不要になり、処理時間とコストを削減することができます。 キャッシュされていない場合は、プロンプト全体を新規に処理した後に、プロンプトのプレフィックスを保存します。 この仕組みにより、繰り返し使用されるプロンプトの再処理を避け、システム全体の効率を向上させています。 OpenAIにも同様にプロンプトキャッシュが導入されています。 GoogleのGeminiシリーズにもコンテキストキャッシュという名称は異なりますが、同様の機能があります。 Anthropic: プロンプトキャッシュ Google Cloud: Claudeモデルのプロンプトキャッシュ OpenAI: プロンプトキャッシングAPI Medium: LLMのプロンプトキャッシュのメカニズム 株式会社Algomatic: テックブログ Zenn: Claude Prompt Cachingは本当に効果的なのか検証してみた プロンプトキャッシュの料金 料金 キャッシュの料金は以下の通りです。 キャッシュ書き込み: 入力トークンよりも25%高価格 キャッシュ読み取り: 入力トークンよりも90%低価格 初回に発生するキャッシュの書き込みでは、料金が上がってしまいますが、複数回LLMとの会話が行われると、キャッシュが活用されるので、その分料金が安くなります。 サポートモデル プロンプトキャッシュをサポートしているモデルは以下になります。 Claude 3.7 Sonnet（claude-3-7-sonnet@20250219） Claude 3.5 Sonnet v2（claude-3-5-sonnet-v2@20241022） Claude 3.5 Sonnet（claude-3-5-sonnet@20240620） Claude 3.5 Haiku（claude-3-5-haiku@20241022） Claude 3 Haiku（claude-3-haiku@20240307） Claude 3 Opus（claude-3-opus@20240229） プロンプトキャッシュの利用方法 プロンプトキャッシュを利用するにはClaudeのAPIをコールする際にcache_controlパラメータを指定します。

はじめに この記事では、Azure Durable Functionsについて解説します。 Azure Durable Functions ​Durable Functionsは、Azure Functionsの拡張機能で、状態を保持する（ステートフルな）ワークフローを実現可能にする機能です。 ​複数の処理を順番や並列で実行し、状態管理や再実行といった処理をユーザーは実装する必要がなく、Durable Functions側で自動で行うため、開発者はビジネスロジックの実装に集中することができます。 また、HTTPトリガー関数の場合3分50秒のタイムアウト制限があるため、長時間の処理を行うことができませんが、Durable Functionsを使うことで、長時間の処理を行うことが可能になります。 Azure公式ドキュメント: Azure Durable Functionsとは Azure Durable Functionsのアーキテクチャ Durable Functionsは以下の4つの関数で構成されています。 クライアント関数 (Client Function) オーケストレーター関数 (Orchestrator Function) アクティビティ関数 (Activity Function) エンティティ関数 (Entity Function) 次の項で、それぞれの関数について解説していきます。 Azure公式ドキュメント: Azure Durable Functionsにおける各関数の説明 クライアント関数 Durable Functionsをスタートさせるトリガー関数です。 通常のFunctionsと同様にHTTPトリガーやタイマートリガーなどイベントドリブンで実装されており、 定義したトリガーからイベントなどを受け取って、オーケストレーター関数を起動するのがこの関数の役目です。　オーケストレーター関数 後述するアクティビティ関数の実行を管理する役割の関数です。 後述するアクティビティ関数や他の関数を記載された通りに起動します。　ただし注意点として、オーケストレーター関数は 決定論的（deterministic） である必要があります。 決定論的とは、「同じ入力なら、いつ呼んでもまったく同じ動きをする」ように書く必要があることを示します。 Durable FunctionsではAzureサービスの障害時やサービスメンテナンス時などで処理が中断された場合に、オーケストレーター関数を再実行することができます。 再実行時に実行のたびに結果が変わるような処理が入っていると、予期しない動作を起こす危険性があるため、現在時刻やランダム値を使った処理など、毎回結果が変わるようなコードをオーケストレーター関数で定義することはアンチパターンとされています。