ai

はじめに Claude Codeには、ファイル編集やコマンド実行をどこまで自動で許可するかを決める権限モードがあります。 本記事では、各モードの特徴と使い分けをまとめます。 詳細は公式ドキュメントも参照してください。 権限モード - Claude Code Docs 権限の強さ順 概ね、弱い順では次の順番になります。 Plan < Manual < Accept edits < Auto << Bypass permissions モード別の詳細 Plan ファイルの読み取りのみで、基本的にファイル編集を行わない調査専用モードです。 実装前に、実装方針や変更計画を作成する際に使用します。 Manual Claude Codeが操作前にユーザーへ確認を求める標準的なモードです。 ファイルの読み取りなど一部の操作は承認なしで自動的に行われますが、それ以外は原則、ファイルの編集やコマンドの実行前にユーザーの承認が求められます。 機密データを扱うプロジェクトや、変更を一つずつレビューしたい場合に適しています。 Accept edits 作業ディレクトリ内のファイル編集を自動承認するモードです。 ファイル・ディレクトリの作成、移動、複製などが承認なしで実行されます。 gitなどのコマンド実行は、ユーザーに承認を求めます。 通常の機能実装やテストコードの追加、変更を最後にまとめてレビューしたい場合に適しています。 Auto 別の分類用モデルが安全と判断した操作を自動実行するモードです。 確認回数を減らしながら、危険な操作を自動的にブロックしたり、確認対象にしたりできます。 長時間の実行が必要なタスクや、機械的なコード変換など人間の介在が少なくても問題ないタスクをAIに自走させたい場合に適しています。 Bypass permissions 通常の権限確認や安全チェックを大きく省略するモードです。 リモートリポジトリへの操作や、保護されたファイルへのアクセスなど、リスクのある作業も自動実行します。 基本的にホストOSや本番環境での使用は非推奨とされており、Dockerコンテナや使い捨てVMなど隔離された環境での使用が推奨されています。 モード比較表 モード 自動で行われる操作 向いている場面 Plan 読み取りのみ 実装前の調査・設計 Manual 一部の操作のみ 機密データ、1件ずつレビューしたい場合 Accept edits 作業ディレクトリ内のファイル編集 通常の機能実装、テスト追加 Auto 分類モデルが安全と判断した操作 長時間タスク、機械的な変換 Bypass permissions ほぼすべて 隔離環境のみ 実務上の推奨 開発作業では、Planで調査・設計した後、問題なければManualまたはAccept editsで実装するのが好ましいです。

はじめに IT業界には以前から、プログラミングスクールやAIスクールなど、情報商材を扱うセミナーが数多く存在します。 中には「情弱ビジネス」と呼ばれ、現役のプログラマーから嫌われているものもあります。 しかし、実際にセミナーに参加してみると、困惑させられるのは提供側よりも、参加者側だったりします。 この物語では、そんな「情弱セミナーあるある」を描きます。 「情弱セミナーで一番困惑したのは、講師ではなく参加者だった」 これは、とあるAIスクールが開催した無料WEBセミナーでの出来事。 主人公Aは、都内のシステム開発会社に勤めるエンジニア。 その日は特に予定もなく、暇つぶしのつもりで「AIで人生が変わる！」とうたう無料セミナーにWEB参加していた。 画面には熱弁を振るう講師と、司会、そして数十人の参加者が映っている。 講師B 😄 「当スクールでは、他では絶対に教えない黄金のタレのプロンプトを、受講生の皆さまだけにお伝えしています！」 主人公A 😑 「（はいはい、情弱乙。）」 主人公Aは、あきれ顔でコーヒーをすすった。 内容は、ネットで少し調べれば出てくる程度のプロンプトのコツを、大げさな名前で包んだものだ。 講師B 😆 「このプロンプトさえあれば、未経験からでも月収100万円が見えてきます！」 主人公A 🙄 「（そんなプロンプトがあるなら、自分で使って稼げばいいのに……。）」 そして、セミナーは質疑応答の時間に入った。 司会C 🙂 「それでは、ご質問のある方はチャットでお願いします。」 参加者D 🤔 「あの、スクールの受講料は経費にしても大丈夫ですか？」 一瞬、画面の中の空気が固まった。 主人公A 😳 「（え、それをスクールに聞くの？）」 司会C 😅 「えっと……そちらは……。」 講師B 😓 「……。」 本来、経費として認められるかどうかは、税理士や経理担当者に確認すべき内容だ。 スクール側が「大丈夫ですよ」と答えられるはずもない。 司会C 😐 「そちらは、税理士さんか経理の方にご確認いただくのがよろしいかと存じます。」 参加者D 🙂 「わかりました！ありがとうございます！」 質問者だけが満足そうだった。 主人公A 😑 「（講師より、参加者のほうが怖いわ……。）」 情弱セミナーで困惑させられるのは、提供側よりも参加者側であることが多い。 主人公Aは、そう痛感しながらブラウザのタブを閉じた。 解説 情弱ビジネスは提供側を批判する声が多い一方で、「騙される側にもいらいらする」という声も多いです。 地方でも、AIやDXをうたい文句に、中小零細企業へ高額な契約を持ちかける怪しげなコンサル会社は珍しくありません。 IT担当者がいない会社ほど、「よく分からないから、詳しそうな人の言うことを信じる」状態に陥りやすいので注意が必要です。

はじめに Azure SRE Agent は、ポータルからの操作だけでなく、REST APIを使ってSkills（スキル）、KnowledgeItem（ナレッジ）、ScheduledTasks（定期実行タスク）を登録・更新することができます。 本記事では、それぞれの登録APIのリクエストフォーマットと、実際の実装例を解説します。 Skills登録API Skillsは、エージェントに特定の作業手順やノウハウを教えるための拡張機能です。 API経由で登録することで、GUI操作なしにスキルの追加・更新を自動化できます。 エンドポイント PUT {AgentEndpoint}/api/v2/extendedAgent/skills/{URLエンコードしたスキル名} ヘッダー ヘッダー名 値 Authorization Bearer <DataPlaneトークン> Content-Type application/json リクエストボディ { "name": "スキル名", "type": "Skill", "tags": [], "properties": { "name": "スキル名", "description": "スキルの説明", "tools": [], "skillContent": "スキルの本文", "additionalFiles": [ { "displayName": "filename.md", "fileContent": "ファイルの中身" } ] } } フィールド 説明 name スキルの識別子 properties.

はじめに Azure SRE Agent に、チャットから作成できる保存・共有可能な運用画面「Live Reports」が Public Preview として追加されました。 本記事では、Live Reports の概要、提供状況、活用メリット、利用時の留意事項について解説します。 Live Reports とは 発表日: 2026年8月25日 提供状況: Public Preview Live Reports は、Azure SRE Agent とのチャットから作成できる、保存・共有可能な運用画面です。 利用者が必要な情報を自然言語で説明すると、Agent が chart、table、diagram、status indicator を含む report を作成します。一度作成した report はレイアウトを維持し、開くたびに connector から最新データを取得します。 利用例 serviceのエラー率やlatencyを確認する朝会用dashboard deploymentの成功率と失敗一覧 未解決incidentと担当者の一覧 Kustoの運用データを用いたservice trend compliance、capacity、costの定期確認 on-callの引き継ぎ画面 何が嬉しいか 毎日同じpromptを入力したり、複数のdashboardを開いたりする作業を減らせます。 reportの形が固定されるため、日ごとの数値を同じ視点で比較できます。 connector toolのみで更新するreportは、表示のたびにactive-flow AAUを消費しません。 link共有により、同じAgentへのアクセス権を持つチームメンバーが共通の運用画面を利用できます。 sanitized static HTMLとして出力し、postmortemなどの記録へ添付できます。 report上のbuttonから、incidentの更新やworkflowの開始など、許可されたtool actionを実行できます。 留意事項 reportはsandboxed iframeで実行され、session tokenやcookieへアクセスできません。 reportが呼び出せるのは、保存時に承認されたconnector toolに限定されます。 linkの共有だけではアクセス権は付与されません。閲覧者にも対象Agentのロールが必要です。 reportの作成・変更はactive-flow AAUを消費します。 model-assisted analysisを設定した場合、reportを更新するたびにmodel利用分のactive-flow AAUが発生します。 Previewでは、生成HTMLは10 MB以下です。 cross-tenant userは、approvalが必要なreport actionを承認できません。 model-assisted sectionにreport単位またはuser単位のAAU budgetはありません。 おわりに Live Reports は、Azure SRE Agent とのやり取りをそのまま日々使える運用画面に変換できる機能です。

はじめに この記事では、 AIコーディングエージェント向けのタスク管理ツール「Beads (bd)」を紹介します。 Claude Codeなどのエージェントにタスクを記憶させ、セッションをまたいだ作業管理を可能にするツールです。 beadsとは AIエージェントが使用することを前提に作られたタスク管理ツールです。 bdコマンドというCLIを使ってタスク管理ができます。 CLIでタスクを操作できることから、Claude Codeなどのバイブコーティングツールを使用する開発者から高評価を得ています。 GitHub - gastownhall/beads: Beads - A memory upgrade for your coding agent GitHub Issueなどとの違い プロジェクトのタスク管理というとGitHub Issueが古くから使われていますが、GitHub Issueとbeadsのメカニズムの違いや、beadsを使うメリットは以下の通りです。 依存関係の設定ができる このタスクを完了しないと次のタスクを実行できない、といった複雑な依存関係の設定が可能です。 DBとJSONLでタスク管理 DBファイルとjsonlファイルの2つを用いてタスクを管理します。 DBファイル上でタスクのステータス、優先度、説明などが記録されています。 軽量な内部DBにクエリを実行することで、エージェントは必要な情報のみを参照でき、コンテキストの肥大化を防げます。 DBへの変更はjsonlファイルにも同期され、人間にも読みやすい形式で表示されるため、Gitなどのバージョン管理ソフトで差分を確認できます。 ローカルのDBファイルを用いるので、クラウドを使わずオフラインでも動作します。 コマンドラインから操作できるので、AIエージェントからも操作が可能です。 エージェントにセッションをまたいだ情報を記憶させるrememberコマンドなど、エージェント向けの機能があります。 初回セットアップ # Windowsにbeadsをインストール irm https://raw.githubusercontent.com/gastownhall/beads/main/install.ps1 | iex ## 環境変数 Pathに以下のPathを設定 >> ==> bd installed to C:\Users\pocke\AppData\Local\Programs\bd\bd.

はじめに 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リソースを削除し、使用する際に再作成するといったフローが必要になる。