appinsights-instrumentation

Application Insights の入れ方を調べたいときです。入れたいときではありません。

冒頭に、azure-prepare へ回す関門がある

本文の 2 段落目に、太字と記号つきの関門が置かれています。

⛔ 部品を追加しますか？利用者がアプリに App Insights を追加したいなら、代わりに azure-prepare を呼べ。このスキルは参照資料を提供する。実際の変更は azure-prepare が指揮する。

これは参照資料

これは参照資料です。使い分けが本文で表になっています。

azure-prepare が調査の段階でこのスキルを呼ぶ、とも書かれています。単体で使うより、呼ばれる側として効く作りです。

最初に必ず聞かれることがある

本文の手引きの 1 番目が、文脈の収集です。言語・フレームワーク・ホスティング先の 3 つ組を確定させます。

そのうえで、こう指定されています。

ホスティング先は必ず利用者に聞かなければならない。

ソースコードから推測してよいのは言語とフレームワークまでで、どこで動いているかは聞け、という切り分けです。

ホスティング先を推測されると、動かない手順が出てくる

理由は手順を見れば分かります。App Service か Container Apps か、コードとして載せているかコンテナかで、計測の入れ方が変わります。ここを推測されると、動かない手順が出てきます。

自動計測を優先する

手引きの 2 番目が「可能なら自動計測を選べ」です。条件が具体的に決まっています。

自動で済むならコードに触らない、という順序です。妥当です。

手動の場合は 2 段階

リソースを作る段と、コードを直す段に分かれます。

リソースの作り方は 2 つ

リソースの作り方は 2 つ用意されています。作業場所に Bicep のテンプレートがあるならそれに追記する形、無ければ Azure CLI のスクリプトを使う形です。

アプリと同じリソースグループに置けという助言も入っています。

コードの直し方は言語ごとの手引き

コードの直し方は言語ごとの手引きに分かれます。ASP.NET Core、Node.js、そして Python の手引きがあります。

★前提は 4 種類のアプリ

本文の前提の節にはこう書かれています（2026-10-09 確認）。

作業場所のアプリは次のいずれかでなければならない。Azure で動く ASP.NET Core のアプリ、Azure Container App、Azure で動く Node.js のアプリ、Azure で動く Python のアプリ。

前提の 4 種類と、言語ごとの手引き（ASP.NET Core・Node.js・Python）が対応しています。

SDK の早見表と Container Apps の手引き

言語ごとの手引きとは別に、OpenTelemetry の SDK の早見表が 4 件あります（Distro の Python と TypeScript、Exporter の Python と Java）。Container Apps には、ログの表・組み込みの指標・KQL の例をまとめた観測の手引きが付いています。

組で入れないと止まるものがある

この公開元には組で入れないと止まるものがあります。全体の役割分担は microsoft/azure-skills の地図にまとめています。

実際に計測を組み込みたいなら、これではありません

本文の冒頭が名指しで azure-prepare へ回しています。

ただし azure-prepare の説明文は、いまは azd を使う場合に限ると書いています（2026-10-09 確認）。azd を使わない構成では、このスキルの手引きを見ながら自分で組み込むことになります。

Azure で動いていないアプリは対象外です

前提の節が「Azure で動く」ことを条件にしています。手元や他社のクラウドで動くものへの適用は想定されていません。

障害の原因を探したいなら別物です

計測は障害を見つけるための下準備で、実際に落ちているものを調べるのは azure-diagnostics の担当です。

可用性の設計を見たいなら別物です

そちらは azure-reliability の側です。

ホスティング先を答えられないと進みません

必ず聞く指定が入っているので、そこで止まります。

解析で見つかった記述は無い

SKILL.md の解析では、外部通信・シェル実行・ファイル書き換えの記述は見つかっていません。同梱ファイルは 12 件です（2026-10-09 確認）。

同梱のスクリプトは、実行する前に中身を見る

PowerShell のスクリプトが1 件、約 20 行あります（2026-10-09 確認）。リソースの作成、接続文字列の取得、App Service・Container App・Function App への環境変数の設定を、Azure CLI のコマンドで並べたものです。

本番のサブスクリプションに対して走らせるものなので、実行する前に中身を見てください（スキルを入れる前に確認すること）。

リソースを作ると課金が始まる

同梱の Bicep の例は、Log Analytics のワークスペースを従量の PerGB2018・保持 30 日で作ります。

テレメトリに個人情報が混ざる

Python の手引きは標準の logger 経由で送る形なので、ログに書いた文字列がそのまま送られます。 Container Apps では、標準出力と標準エラーがログの表に入ります。取り扱いの規程がある組織では、送る中身を先に確かめてください。

接続文字列が設定に入る

接続文字列は環境変数 APPLICATIONINSIGHTS_CONNECTION_STRING に入れる形です。Bicep などのテンプレートがあればそこに足し、無ければ Azure CLI で設定します。ASP.NET Core の手引きは「appsettings.json を直すな。古い方法だ」と明記しています。Container Apps の手引きは、値をシークレットに入れて参照する形を勧めています。

アプリの設定やテンプレートに書き込まれるので、リポジトリに直接置かないでください。コードを直した場合は、配置し直すまで効かない、とも書かれています。

allowed-tools の指定が無い

allowed-tools の指定はありません。指定が無いので、確認なしで走る道具はありません。どの道具も、利用者の権限の設定どおりに確認されます。allowed-tools は事前承認の宣言で、実行の範囲を示すものではありません。

ライセンスは MIT

ライセンスは MIT です。再配布や商用利用の前に公開元の表記を確認してください。

計測を入れてもらうにはどうすればいいですか

azure-prepare を使ってください。本文の冒頭がそう指示しています。

このスキルは参照資料の側で、azure-prepare が調査の段階で内部から呼ぶ想定になっています。

なぜホスティング先を聞かれるのですか

推測すると手順が変わるからです。 App Service か Container Apps か、コードかコンテナかで、計測の入れ方が変わります。

本文は言語とフレームワークまでは推測を許し、ホスティング先だけは必ず聞けと指定しています。

Python のアプリでも使えますか

使えます。Azure で動く Python のアプリは前提の節に入っています（2026-10-09 確認）。手引きは azure-monitor-opentelemetry を入れ、標準の logger 経由で送る形です。

自動計測と手動計測はどちらが良いですか

条件が合えば自動です。本文が優先順位を明示しています。C# の ASP.NET Core を App Service で動かしているなら自動の道があります。

それ以外は、リソースを作ってコードを直す 2 段階になります。

費用はどれくらいかかりますか

当サイトでは算出していません。取り込んだデータ量による課金です（Azure Monitor の料金ページ。2026-10-09 確認）。

既定のまま入れると想定より多く送られることがあるので、取り込み量の上限と保持期間を先に設定してください。

対応しているエージェントはどれですか

Claude Code と Codex です。公開元の README が Claude Code と Codex CLI それぞれへの入れ方を節に分けて案内しています（2026-10-09 確認）。当サイトは公開元が明記しているものだけを「対応」として表示する方針なので、このスキルのページには両方が対応として出ます（指標の意味と限界）。