「Skillsって何？サブエージェントって何が違うの？MCPって結局どう使うの？」——そんな混乱を抱えたまま、Claude Codeの新機能ラッシュについていけていないインフラエンジニアは、あなただけじゃありません。2026年3月時点で、Claude CodeはバージョンがWeeklyペースで更新され続け、もはや「なんとなく使えている」では太刀打ちできない状況になってきました。
特にAWSやクラウドインフラを日常的に触っているエンジニアにとっては、ただコードを補完してもらうだけでなく、インフラ設計・構成図作成・コスト試算・自動デプロイまで任せられる強力なパートナーになりうるのがClaude Codeです。この記事では、インフラエンジニア視点で「本当に使える」拡張機能と最新の活用法を一気に整理します。
- Claude Codeの5つの拡張機能（CLAUDE.md・スキル・サブエージェント・スラッシュコマンド・MCP）の役割と使い分けを完全整理
- AWSインフラエンジニアが実際に使える具体的な設定例と2026年3月最新アップデートの内容
- VSCode拡張機能・Channels・Agent Plugins for AWSなど、今すぐ試せる新機能の全貌
そもそもClaude Codeの拡張機能って何種類あるの?
AIのイメージ
Claude Codeを使い始めて最初にぶつかる壁が「機能が多すぎて関係がわからない」という問題です。公式ドキュメントを読んでも、SkillsとサブエージェントとMCPの違いがピンとこない。そんな状態を解消するために、まずは全体像を整理しましょう。
Claude Codeの拡張・カスタマイズ機能は、大きく分けると5つのレイヤーで構成されています。それぞれが独立しているようで、実は連携して動いているのがポイントです。
①CLAUDE.mdは、プロジェクトの「共通ルールブック」です。Claude Codeが常に参照するファイルで、チーム固有のルール、コーディング規約、使用するAWSリージョンなどを記述しておきます。プロジェクトルートに置くか、`~/.claude/CLAUDE.md`にユーザースコープで置くかを選べます。`/init`コマンドを実行するだけでプロジェクト構成を読み込んで自動生成してくれるため、最初のセットアップが非常に楽です。
②スキル（Agent Skills）は、Claudeの機能を拡張する「専門マニュアル集」です。必要なときだけ読み込まれるため、コンテキストウィンドウを無駄に消費しないのが特徴です。Anthropicが事前構築済みのスキルを公式GitHubで公開しており、セキュリティチェック用・ドキュメント操作用・CloudFormationのベストプラクティスなどが揃っています。自分で作成する場合も、Claude Codeに頼めば自動で`skills/`フォルダを作って必要なファイルを生成してくれます。
③サブエージェントは、複雑なタスクを専門の「分業チーム」に委ねる仕組みです。メインのClaude Codeとは別のコンテキストウィンドウを持つため、長時間・大規模なタスクを処理しても精度が落ちにくいのが最大のメリットです。複数のサブエージェントを並列で動かすことも可能で、「セキュリティレビューエージェント」「パフォーマンスチェックエージェント」を同時に走らせるといった使い方ができます。
④カスタムスラッシュコマンドは、繰り返し使うプロンプトをショートカット化する機能です。`.claude/commands/`フォルダにMarkdownファイルを置くだけで、`/worktime`のように呼び出せます。スキルが「条件に合えば自動で動く」のに対して、スラッシュコマンドは「自分が明示的に呼んだときだけ動く」という違いがあります。毎朝の作業ログ確認、定型的なデプロイ確認コマンドなど、自分だけのショートカットを作れます。
⑤MCP（Model Context Protocol）は、外部サービスとの連携を実現する「インフラ基盤」です。スラッシュコマンドもスキルもサブエージェントも、MCPを通じて外部ツールを呼び出します。AWSのドキュメント参照、Slack通知、GitHub操作、draw.ioでの構成図作成など、対応するMCPサーバーさえあれば何でも統合できます。
インフラエンジニア必見!AWS連携でできる超実践的な使い方
AWS MCP ServerでAWSドキュメントをリアルタイム参照する
AWSのドキュメントは日々更新され、APIの仕様が変わることも珍しくありません。Claude Codeの学習データは当然ながらカットオフがあるため、古い情報に基づいたコードを生成してしまうリスクがあります。
これを解決するのがAWS MCP Serverです。2025年のre:Invent 2025で発表され、2026年3月現在バージニアリージョンでプレビュー提供中のリモートMCPサーバーです。従来は「AWS API MCP Server」と「AWS Knowledge MCP Server」を別々に設定する必要がありましたが、今はこの2つが統合されています。
プロジェクトルートの`.mcp.json`に以下のような設定を追加するだけで連携できます。AWS MCPサーバーはCloudFormationのベストプラクティスを参照したり、リアルタイムの料金情報を確認したりできるようになっています。さらに2026年3月のアップデートでCloudWatchメトリクスへの記録機能とAgent SOPs（複雑なAWSタスクの自動化ワークフロー）が追加され、より高度な運用自動化が実現できるようになりました。
Agent Plugins for AWSで「デプロイせよ」の一言だけで完結させる
2026年3月に非常に注目度の高いアップデートがありました。AWSがClaude Code向けの「Agent Plugins for AWS」を公開したのです。
このプラグインを組み込んだClaude Codeに「このWebアプリをAWSにデプロイして」と指示すると、AIエージェントが自動で以下の処理を実行します。まずアプリのコードを解析してフレームワークや依存関係を確認し、AWS上で最適なサービス構成を選定します。そしてCloudFormationテンプレートを生成し、コスト試算を行ったうえで実際のデプロイまで実行してくれるのです。
インフラエンジニアとしては「それって本当に安全なの?」という不安があると思います。その点、Hooks機能でガードレールを設定できるのがAgent Plugins for AWSの重要な設計思想です。本番環境へのデプロイ前に必ず人間のレビューを挟む、特定のリージョン以外へのデプロイを禁止するなど、決定論的な制御ルールを組み込むことができます。
IaCコード生成の「品質の罠」を知っておく
電通総研の技術ブログでは、インフラ経験ゼロのエンジニアがClaude CodeでAWSのIaCコードを書く実験が公開されています。その中で重要な指摘があります。Claude Codeが生成するIaCコードは「PoC・デモ品質」になりやすいという点です。
具体的には、削除耐性（DeletionProtection）・HTTPS強制・VPCエンドポイント・セキュリティグループの多層防御・監査ログ設定といった本番環境のガードレールがデフォルトで省略されがちです。これはClaude Codeの問題というよりも、プロンプトで本番要件を明示していないことが原因です。
そのためインフラエンジニアとしての「設計意図・運用・変更耐性まで含めた要件」をCLAUDE.mdに事前に定義しておくことで、生成されるコードの品質を大幅に引き上げられます。AWS公式のMCPサーバーで最新ドキュメントを参照させながら生成すると、さらに実用的な出力が得られます。
2026年3月の最新アップデートでここまで変わった!
Channels機能でTelegram・Discordからリモート操作が可能に
2026年3月15日〜21日のアップデート（v2.1.77〜v2.1.81）で追加されたChannels機能（research preview）は、インフラエンジニアにとって特に注目すべき新機能です。
ChannelsはMCPプロトコルをベースにしており、TelegramやDiscordなどの外部プラットフォームから稼働中のClaude Codeセッションにメッセージをプッシュできます。例えば、CI/CDパイプラインが失敗したときにSlackに通知が来るようなイメージで、監視アラートやWebhook受信をトリガーにしてClaude Codeに自動対応させることができます。
公式プラグイン以外にも、MCPサーバーを自作することでカスタムチャンネルを作れます。Bun・Node・DenoといったNode.js互換ランタイムさえあれば、任意のシステムからのイベントをClaude Codeセッションにプッシュできる設計になっています。
使用量が2倍になっている今が試し時!
Anthropicは2026年3月27日（本記事執筆日）まで、claude.ai・Cowork・Claude Codeの使用量制限を一時的に2倍にしています。週末は終日、平日も適用されます。これはまさに今がいろんな機能を思い切り試せるタイミングです。普段は使用量を気にしながら使っている方も、この機会に複数のサブエージェントを並列で走らせたり、大きなリファクタリングタスクを投げてみたりと、Claude Codeの底力を体感してみてください。
VSCode拡張機能の進化とCLI版との使い分け
2026年初頭に正式リリースされたAnthropic公式のVSCode拡張機能は、インフラエンジニアにとって「とっつきやすい入り口」として急速に普及しています。サイドバーパネルでインラインdiffが確認でき、ファイルの@メンション、プラン確認、会話履歴管理がGUIで操作できます。
一方でCLI版（ターミナル版）は、大規模なリファクタリング・自動化スクリプトの生成・headlessモードでのCI/CD統合など、「AIに長時間タスクを委ねる」用途に向いています。また/voice コマンドによる音声入力（2026年3月追加、20言語対応）や、/loop で定期タスクのスケジュール実行、Remote Controlでスマートフォンからセッション操作といった機能はCLI版の特権です。
VSCode拡張機能とCLI版は競合するものではなく、「コードを確認しながら対話するならVSCode拡張機能、タスクを丸投げして別の作業をするならCLI」という使い分けが実践的です。
知らないと絶対損するCLAUDE.mdの「正しい書き方」
AIのイメージ
CLAUDE.mdは「プロジェクトの共通ルールブック」として前の章で紹介しましたが、実は書きすぎると逆効果になるという落とし穴が存在します。これを知らないまま使い続けているエンジニアは本当に多い。
研究によると、最先端のLLMが信頼性をもって従える指示数は概ね150〜200件程度が上限とされています。そしてClaude Code自体のシステムプロンプトがすでに約50の指示を使っています。つまり、あなたのCLAUDE.mdが使えるのは実質残り100〜150行前後がリアルな上限ということになります。
問題はそこだけではありません。LLMは指示の数が増えると、新しい指示だけを無視するのではなくすべての指示への遵守率が均等に下がっていくという特性があります。CLAUDE.mdを厚くすれば厚くするほど、大事なルールも含めて「なんとなく従う」状態になってしまうのです。
では理想的なCLAUDE.mdはどう書けばいいか。ポイントは3つです。まず「Claudeが自分では気づけない情報だけを書く」こと。AWSのリージョン指定や独自の命名規則、本番環境の削除保護フラグの必須化など、コードから読み取れない判断基準を書くのが正解です。一般的なコーディング規約やClaudeが元から知っていることを書くのはトークンの無駄です。次に、重要度の高いルールには`
インフラエンジニア向けの実用的なCLAUDE.mdに含めるべき内容を整理すると、以下のようになります。
- 利用するAWSアカウント・リージョン・プロファイル名（開発・本番の切り分けルールを含む）
- 本番環境では必ずDeletionProtection・HTTPS・VPCエンドポイントを含めるというガードレール要件
- CloudFormationスタック名の命名規則・タグ付けルール（コスト配分タグなど）
- どのMCPサーバーを使うか・どのサブエージェントに何を委ねるかの案内ポインター
逆に書いてはいけないのは「コメントを書いてください」「エラーハンドリングをしてください」のような、Claudeが元から知っていることです。こうした指示はトークンを消費するだけで遵守率の低下を招きます。
「コンテキスト汚染」という現実問題と、その解決策
Claude Codeを使っていると、必ず一度は「さっきと回答の質が違う」「前に決めたことを無視してる」という体験をします。これはコンテキスト汚染（Context Rot）と呼ばれる現象で、LLMの構造上の必然です。
仕組みを理解すると対処がしやすくなります。Claude Codeのコンテキストウィンドウは200,000トークンですが、システムプロンプト・ツール定義・MCPスキーマ・メモリファイルで最初から30,000〜40,000トークンが消費されています。さらに2026年初頭の実測値では、自動コンパクションが発動するのは約83.5%使用時点（167,000トークン前後）とされています。パイプを通じた大量出力や複数ファイルの読み込みが重なると、実感よりずっと早くコンテキストが埋まっていきます。
インフラ業務での典型的な失敗パターンはこうです。朝からClaude Codeを起動して「このEC2の構成をレビューして」→「じゃあCDKのコードを書いて」→「あ、そういえばこのLambdaのIAMポリシーも見て」と、関係ないタスクを同じセッションに積み重ねていくケースです。そのうちClaudeが「さっき否定したアプローチ」を再提案したり、プロジェクト固有の命名規則を無視したコードを出し始めます。
実践的な解決策は「コミット境界でリセットする」習慣です。一つのタスクが完了してGitにコミットしたら、すぐに`/clear`を実行して新しいセッションを始める。コードはすでにファイルに保存されているので何も失いません。コンテキストに残るのはノイズだけです。
タスクの途中で別の調査が必要になった場合は`/btw`コマンドが便利です。質問の答えがオーバーレイ表示されますが、コンテキスト履歴には残らないので、一時的な確認のためだけにトークンを消費せずに済みます。
コンテキストが埋まってきたら`/compact`を使いますが、タイミングが重要です。タスクの途中ではなく、作業の区切り目で実行することが鉄則です。なぜかというと、自動コンパクションは「いつタスクが完了したか」を判断できないため、デバッグの途中でエラーメッセージやファイルパスが消えてしまうことがあります。手動で`/compact 変更したファイルの一覧とAPIの設計決定事項を保持してください`のように指示を与えると、サマリーの精度が上がります。
インフラエンジニアだからこそ使いこなしたい実践プロンプト集
ここからは「Claudeだからこそ成立する」プロンプトを紹介します。汎用的なAIツールとは異なり、Claude Codeはファイルシステムへのアクセス・シェルコマンドの実行・MCP経由の外部連携が一体化しているため、以下のような指示が一気通貫で実行できます。
【プロンプト①AWSインフラのセキュリティ棚卸し】
「現在のAWSアカウントの設定を調べて、以下の観点でリスクをS/M/Lの3段階で評価してください。①パブリックアクセスが有効なS3バケット、②MFAが設定されていないIAMユーザー、③インバウンドが0.0.0.0/0になっているセキュリティグループ、④90日以上ローテーションされていないアクセスキー。評価結果はMarkdownの表形式で出力して、高リスク項目から修正するCloudFormationパッチも合わせて生成してください。」
このプロンプトはAWS MCPサーバーが設定されていれば、CLIコマンドの実行からリスク評価・修正コード生成までを一度の指示で完結させられます。以前なら1〜2時間かかる作業が10分以内に終わります。
【プロンプト②IaCコードの本番品質チェック】
「このCDK/CloudFormationのコードをレビューして、以下の本番ガードレールが含まれているか確認してください。①DeletionProtectionの設定、②暗号化（保存時・転送時）の有無、③VPCエンドポイントの使用、④ロギング・監査設定、⑤最小権限原則のIAMポリシー、⑥タグ付けルールの遵守。不足している場合は修正後のコードを提示し、なぜ本番環境で必要なのかの理由もセットで説明してください。」
これはCLAUDE.mdに「本番ガードレールチェックリスト」として保存しておき、IaCコードのレビュー時に毎回このプロンプトを呼び出すスラッシュコマンドにするのが理想的な使い方です。
【プロンプト③マルチアカウント環境の設定ドリフト検出】
「開発環境と本番環境のCloudFormationスタックを比較して、設定のドリフトを検出してください。特に①セキュリティグループのルール差分、②IAMポリシーの権限差分、③環境変数・パラメータの差分に注目してください。検出されたドリフトをリスクレベルと一緒に一覧化して、本番に反映すべき変更と反映すべきでない変更を分類してください。」
【プロンプト④インシデント対応の初動サポート】
「[エラーメッセージをここに貼る]このAWSのエラーが発生しています。①考えられる原因を可能性の高い順に3つ列挙してください、②各原因に対してすぐに確認すべきCloudWatchメトリクスとログのクエリを提示してください、③暫定対処と恒久対処を分けて説明してください。なお、現在の時刻は[時刻]で、影響サービスは[サービス名]です。」
このプロンプトは夜間の障害対応で特に威力を発揮します。パニックになっている状況でも、必要な情報を構造的に整理してもらえます。
Hooksの「決定論的な制御」がインフラに刺さる理由
CLAUDE.mdはアドバイザリーであり、Claudeが従う確率は約80%です。一方Hooksは決定論的で100%実行されます。
これはインフラエンジニアにとって非常に重要な違いです。「本番環境への変更前には必ず確認する」というルールをCLAUDE.mdに書くだけでは、20%の確率でスルーされる可能性がある。しかしHooksで実装すれば、例外なく必ず実行されます。
インフラ業務で特に有効なHooksの活用パターンを紹介します。
`PreToolUse`フックを使って、Bashコマンドが実行される直前に「本番環境を対象にしているか？」をチェックするスクリプトを走らせることができます。例えばコマンド文字列に`–profile prod`や`us-east-1`といったキーワードが含まれていれば、確認ダイアログを表示するか、ログファイルに記録するといった処理を挟めます。コードを書くエンジニアが誤操作を防ぐためにCI/CDパイプラインに組み込むのと同じ発想です。
`PostToolUse`フックでは、CloudFormationテンプレートが生成された後に自動でセキュリティリンターを走らせるという使い方ができます。cfn-nag（CloudFormationのセキュリティ検査ツール）をフックとして組み込んでおけば、Claudeが生成したIaCコードに対して毎回自動でセキュリティチェックが走ります。これは「AIが生成したコードを信用しすぎない」というインフラエンジニアとしての正しいスタンスを仕組みで担保することになります。
`Stop`フックは、Claudeがタスクを終了したタイミングで発火します。長時間の自律タスク（例大規模なリファクタリングや複数環境への設定適用）が完了したとき、Slack通知やWindowsデスクトップ通知を送る使い方が実用的です。作業を投げてコーヒーを飲みながら待っていて、完了したら通知が来る、という体験は一度やると手放せなくなります。
サブエージェントの「並列実行」でインフラ審査を爆速化する
Claude Codeのサブエージェント機能の真骨頂は並列実行です。単独の会話では順番に処理するしかない作業を、複数のサブエージェントが独立したコンテキストウィンドウで同時に進行させることができます。
インフラの世界で最も効果を発揮するのが「マルチ観点レビュー」のパターンです。新しいAWSアーキテクチャ設計を提出したとき、通常のレビューでは一人のエンジニアが順番に各観点を確認していきます。しかしサブエージェントを使えば、以下のような専門エージェントを同時に走らせることができます。
「セキュリティレビューエージェント（IAMポリシー・ネットワーク設計・暗号化の観点）」「コストレビューエージェント（リザーブドインスタンスの最適化・不要リソースの検出・料金見積もり）」「運用性レビューエージェント（モニタリング設計・アラート設定・バックアップ・障害復旧手順）」の3エージェントが並列で動き、それぞれの観点から独立したレビュー結果を返してきます。
各サブエージェントは独立したコンテキストウィンドウを持つため、互いに干渉せず並列で作業できます。これは「コードを書いた本人が同じコンテキストでレビューする」という問題も解消します。新鮮なコンテキストで見るからこそ、見落としが減るのです。
サブエージェントのフロントマター（YAML）には`model: haiku`を指定できます。コスト試算や簡単な文字列チェックのような処理はHaikuに任せ、設計レビューのような高度な判断はSonnetやOpusに任せるというコスト配分の設計もできます。チームで使う場合は`memory: project`スコープにしておくと、エージェントの記憶がプロジェクト全体で共有されるため、何度も同じ前提を説明し直す手間が省けます。
ぶっちゃけこうした方がいい!
ここまで5つの機能・コンテキスト管理・実践プロンプト・Hooks・サブエージェントと広く解説してきましたが、個人的に「ぶっちゃけこれが一番楽で効率的だと思う」という結論を正直に話します。
最初から全部使おうとしない、これに尽きます。
インフラエンジニアとしてClaude Codeをフル活用しようとすると、CLAUDE.mdを完璧に書こう・スキルを整備しよう・サブエージェントを設計しよう・MCPを全部入れよう・Hooksも設定しようと、一気に全部やろうとして結局何も続かないパターンに陥りがちです。正直、そっちの方が時間がかかります。
個人的には「CLAUDE.mdとAWS MCPの2つだけ最初に整備する」ことを強く勧めます。この2つがあれば、AWSインフラ業務の体感70%はカバーできます。CLAUDE.mdには「本番環境のガードレール要件」と「よく使うAWSプロファイルとリージョン」だけを書く。AWS MCPを設定して最新ドキュメントを参照できるようにする。これだけです。
なぜかというと、Claude Codeで本当に効率が上がるのは「やりたいことをやれる環境を整える時間」ではなく「実際にやりたいことをやっている時間」だからです。スキルの設計に2時間かけるより、シンプルな環境でAWSの設計相談を繰り返す方が、業務はずっと早く進みます。
その上で、「この作業を毎回説明するのが面倒だな」と感じた瞬間に初めてスラッシュコマンドを作る。「このタスクが終わったあとに毎回通知が欲しいな」と思った瞬間にHookを設定する。必要になったタイミングで必要なものだけ作っていくのが、インフラエンジニアらしい「必要十分で確実に動く設計」の考え方そのものです。
CLAUDE.mdを書きすぎてしまう問題もこれで解決できます。「今困っていること」だけを書けばいいので自然と短くなるし、本当に必要なルールだけが残ります。150〜200行という上限を意識しながら、毎週1〜2行見直すくらいのペースで育てていくのが長続きするやり方です。
コンテキスト管理も同じ発想で、まずは「コミットしたら/clearする」習慣だけ身につければいい。それだけでコンテキスト汚染の大部分は防げます。/compactの使い方や自動コンパクションの挙動は、実際に「あれ、さっきと違う」と感じてから深掘りすれば十分です。
ぶっちゃけ、インフラエンジニアがAIを使いこなすためのスキルは、コードを書くスキルよりも「どの作業をAIに任せてどの判断を自分がするか」というタスク分解の設計力です。AIが苦手な「本番環境の設計意図」「運用上の制約」「組織固有のルール」を人間が定義して渡すことがうまくなれば、Claude Codeは確実に頼りになるパートナーになります。環境整備はほどほどに、まず今日のインフラ業務の中で一つだけClaude Codeに投げてみてください。
Claude Codeインフラ拡張に関するよくある疑問を解決!
スキルとサブエージェントはどちらを使えばいいですか?
判断基準はシンプルです。「手順を定義したい」ならスキル、「専門家に丸投げしたい」ならサブエージェントです。スキルはClaudeが関連するタスクを判断したときに自動で読み込む「マニュアル」であり、サブエージェントは独立したコンテキストウィンドウを持つ「専門チームのメンバー」です。AWS技術調査のように「大量のドキュメントを参照しながら長時間作業する」タスクはサブエージェント向きです。セキュリティチェックのように「このプロジェクトでは常にこの手順でやってほしい」という定型作業はスキル向きです。なお、サブエージェントはWeb版Claudeでは利用できないため、Claude CodeのCLI環境が必要です。
MCPサーバーを増やすとコストが上がりますか?
はい、注意が必要です。設定している各MCPサーバーはアイドル状態でもコンテキストにツール定義を追加するため、トークンを消費します。対策として、`/context`コマンドでコンテキストウィンドウの使用状況を確認し、未使用のMCPサーバーは`/mcp`で無効化することをおすすめします。また`ENABLE_TOOL_SEARCH=auto:5`のような設定でツール定義の遅延読み込みの閾値を下げることもできます。AWS CLIのような標準ツールが使える場合は、MCPサーバーの代わりにCLIを直接呼び出す設定にするとトークンの節約になります。
Claude CodeをAmazon Bedrockで動かすことはできますか?
できます。AWSのクレデンシャルとAmazon Bedrockのモデルアクセス権限を設定した状態で、環境変数を指定するとClaude CodeがAmazon Bedrockのモデルを利用するようになります。これにより、データがAWSインフラ内に留まる構成でClaude Codeを運用できるため、セキュリティポリシーが厳しい企業環境でも導入しやすくなります。EC2上にClaude Codeをセットアップしてリモートで使うパターンも、ハンズオン記事として公開されており実用性が確認されています。
Hooksとカスタムスラッシュコマンドはどう使い分ければいいですか?
Hooksは「特定のイベントが発生したとき、必ず自動実行したい処理」に使います。ツール実行前・タスク完了後・通知発生時といったClaude Codeのライフサイクルにフックして、ユーザーが明示的に指示しなくても決定論的に動作する点が最大の特徴です。例えばWindowsデスクトップ通知・ログ記録・自動コミットなどに向いています。一方カスタムスラッシュコマンドは「自分が意図的に呼び出したときに実行したいプロンプトのショートカット」です。毎週月曜の作業確認、特定フォーマットでのドキュメント生成など、タイミングを自分でコントロールしたい場合に使います。
まとめ
Claude Codeのインフラ向け拡張機能は、2026年3月時点でもはや「コードを書くAI」の域を超えています。CLAUDE.mdで常識を定義し、スキルで手順を覚えさせ、サブエージェントで並列作業をさせ、MCPでAWSと直接つなぎ、HooksとChannelsで自動化の網を張る。この5層のアーキテクチャを理解して使いこなせたとき、あなたのインフラ業務は別次元の効率に変わります。
まず今日できることは3つです。第一に、CLAUDE.mdを作成して自分のプロジェクト固有のAWS設定やコーディングルールを書き込むこと。第二に、AWS MCP Serverを設定してAWS公式ドキュメントをリアルタイム参照できる環境を整えること。第三に、VSCode拡張機能とCLI版を両方インストールして、タスクの性質に応じて使い分けてみることです。
現在（2026年3月27日）はAnthropicが使用量制限を2倍に緩和している特別期間中です。試したくてもコストが気になって躊躇していた機能を、今こそ思いきり試してみてください。インフラエンジニアとしての業務棚卸をしながら「どの作業をClaude Codeに任せられるか」を整理する作業そのものが、これからのエンジニアとしての競争力を高める第一歩になるはずです。
コメント