AI

Claude Codeの権限モードまとめ

  • POST
はじめに 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で実装するのが好ましいです。

本当にあった?エンジニアの怖い話「情弱セミナーあるある編」

  • POST
はじめに 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担当者がいない会社ほど、「よく分からないから、詳しそうな人の言うことを信じる」状態に陥りやすいので注意が必要です。

Claude CodeでAWS BedrockのClaudeモデルを使う方法

  • POST
はじめに Claude Codeは通常Anthropic社のAPIを直接利用しますが、すでにAWSプラットフォームを利用している場合は、Amazon Bedrock経由でClaudeモデルを呼び出すこともできます。 Bedrock経由で利用することで、以下のようなメリットがあります。 既存のAWS請求・IAM権限管理の仕組みをそのまま利用できる AWSのネットワーク内(VPC等)からセキュアにアクセスできる 社内でAWSの利用が前提となっている環境でもClaude Codeを導入できる 本記事では、Claude CodeでAWS Bedrock経由のClaudeモデルを使用するための設定手順を紹介します。 1. AWS CLIをインストールする Bedrockへのアクセスには、事前にAWS CLIをインストールし、認証情報を設定しておく必要があります。 AWS CLI公式ドキュメント: インストール手順 上記ドキュメントの手順に従って、使用しているOSに応じたインストーラーをダウンロードし、AWS CLIをインストールしてください。 2. AWSにログインする ターミナルを起動し、AWS CLIでログインします。 aws login コマンド実行後、ブラウザが起動するのでAWSの認証情報を入力してログインしてください。 ログイン方法の詳細は以下の公式ドキュメントも参考にしてください。 AWS公式ドキュメント: コマンドラインでのサインイン 3. 推論プロファイルIDを確認する Claude CodeからBedrock上のモデルを指定するために、推論プロファイルIDが必要です。 AWSマネジメントコンソールから、Amazon Bedrockの画面を開き、以下の手順でIDを確認します。 左メニューの「推論」→「推論プロファイル」を選択 利用したいモデル(例: Claude Sonnet、Claude Opusなど)の行から「推論プロファイルID」をコピー コピーしたIDは、次の手順でsettings.jsonに設定します。 4. settings.jsonを設定する Claude Codeのsettings.jsonに、以下のようにBedrock利用のための環境変数を設定します。 { "env": { "CLAUDE_CODE_USE_BEDROCK": "1", "AWS_REGION": "us-east-2", "ANTHROPIC_DEFAULT_SONNET_MODEL": "global.anthropic.claude-sonnet-5-5", "ANTHROPIC_DEFAULT_HAIKU_MODEL": "global.

Azure SRE Agent の Live Reports を解説

  • POST
はじめに 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 とのやり取りをそのまま日々使える運用画面に変換できる機能です。

Claude Codeを使うのにおすすめのWindowsターミナル「Warp」を紹介

  • POST
はじめに Claude CodeはCLI(コマンドライン)ベースのツールのため、どのターミナルを使うかによって開発体験が大きく変わります。 本記事では、Windows環境でClaude Codeを使う際におすすめのターミナルとして、Warpをご紹介します。 結論から言うと、Warpは「コマンドと出力をブロック単位で管理できる」「入力補完が強力」という特徴を持つモダンなターミナルで、Claude Codeを日常的に使うWindows開発者にとって作業効率を上げてくれるツールです。 Warpは2022年に登場した、Rust製のターミナルエミュレーターで、従来のターミナルにはない独自の機能が多く搭載されています。以下、具体的な特徴とインストール方法、Claude Codeとの組み合わせ方を紹介します。 Warpとは WarpはエディタやAI機能なども備えた多機能のターミナルです。 Warpを使うことで、開発者は以下のような恩恵を受けることができます。 ブロック機能 Warpは、コマンドと出力を「ブロック」という単位で区切って表示してくれるのが最大の特徴のターミナルです。 Powershellなどの標準のターミナルではコマンドと出力がすべてまとまって画面上に出力されるため、コマンドや出力が長くなると見づらいという欠点がありました。 Warpでは1つ1つの実行結果がブロックとしてまとめて表示されるため、コマンドに紐付く実行結果について迷う必要がなくなります。 # PowerShell PS> git status On branch main nothing to commit, working tree clean PS> npm test ✓ 124 tests passed PS> docker ps CONTAINER ID IMAGE STATUS a1b2c3d4 app Up 2h ---------------------------------------------- ↑ 複数のコマンドと出力がまとめて出力されるので見づらい ---------------------------------------------- # Warp ┌─ Block #1 ─────────────────────┐ │ $ git status │ ├────────────────────────────────┤ │ On branch main │ │ nothing to commit, working │ │ tree clean │ └────────────────────────────────┘ ┌─ Block #2 ─────────────────────┐ │ $ npm test │ ├────────────────────────────────┤ │ ✓ 124 tests passed │ └────────────────────────────────┘ ┌─ Block #3 ─────────────────────┐ │ $ docker ps │ ├────────────────────────────────┤ │ CONTAINER ID IMAGE STATUS │ │ a1b2c3d4 app Up 2h │ └────────────────────────────────┘ ------------------------------------------------- ↑ コマンドと出力が「ブロック」でまとまっているので見やすい ------------------------------------------------- ブロック単位で管理されているため、以下のような操作が可能です。

AIツール向けタスク管理ツール「Beads」入門

  • POST
はじめに この記事では、 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 のカスタムエージェント機能を解説

  • POST
はじめに 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 のコネクターについて解説

  • POST
はじめに 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 のメモリ機能を解説

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