はじめに

「コードレビューを毎回手動でやっているけど、見落としが多い…」

「PR前にもっとコードを磨きたいけど、時間がない」

「セキュリティの観点でのレビューが甘い気がして不安」

こんな悩みを抱えたことがある方は多いのではないでしょうか。

Claude Codeには、コードレビューのプロセスをほぼ丸ごと自動化できる4つの専用コマンドが用意されています。

これらを組み合わせることで、人間のレビュアーが見落としがちな点を自動的に網羅し、より安全・高品質なコードをPRに出せるようになります。

この記事では各コマンドの詳細と実践的な使い方を解説します。

Amazon検索[本 Claude Code]

この記事で分かること

• 4つのレビュー系コマンドの役割と違い
• /code-review の努力レベル（low〜ultra）の使い分け方
• /simplify が並列で実行する4つのレビュー観点
• /security-review が検出できる脆弱性の種類
• /verify でアプリを実際に起動して確認する方法
• 4コマンドを組み合わせた実践的なワークフロー

こんな人におすすめ

• Claude Code のコードレビュー機能を使い始めたい方
• PR前のチェックを効率化したい開発者
• セキュリティチェックを自動化したい方
• 「動くけど汚いコード」を素早く磨きたい方

コードレビュー系コマンドの全体像

まず4つのコマンドの役割分担を把握しましょう。

変更コード
  │
  ├── /code-review      ← バグ検出 + 品質改善（最も網羅的）
  ├── /simplify         ← 品質磨きのみ（バグは探さない）
  ├── /security-review  ← セキュリティ脆弱性に特化
  └── /verify           ← 実際にアプリを動かして動作確認

この4つは競合するものではなく、役割が異なる補完的なツールです。目的に応じて使い分けるか、後述のワークフローのように組み合わせるのが最も効果的です。

/code-review：バグ検出と品質改善の総合レビュー

/code-review は4コマンドの中で最も網羅的なレビューを行うコマンドです。現在のブランチの差分（diff）を対象に、バグ・品質・効率性・再利用性などを総合的にチェックします。

基本的な使い方

/code-review                  # 現ブランチの変更全体を対象
/code-review src/user.ts      # 特定ファイルのみ
/code-review 123              # GitHub PR番号を指定

努力レベルで深さを調整する

/code-review の最大の特徴は、努力レベルを指定してレビューの深さを調整できることです。

/code-review --effort low      # 高確度な指摘のみ・少数
/code-review --effort medium   # バランス型（デフォルト）
/code-review --effort high     # 広範囲の指摘
/code-review --effort max      # 最大範囲（時間がかかる）
/code-review --effort ultra    # クラウドで深い多エージェントレビュー

日常使いのおすすめ: 通常のコミット前なら medium（省略時のデフォルト）、リリース前の重要な変更なら high または max が適切です。ultra はクラウド上の複数エージェントが協力してレビューするため最も深い分析ができますが、$5〜$25 USD のコストがかかります。重要な場面に絞って使いましょう。

オプションで動作を拡張する

/code-review --fix             # 指摘された問題を自動修正
/code-review --comment         # GitHub PRにインラインコメントを投稿
/code-review --fix --comment   # 修正 + コメント投稿の両方

--fix オプション：指摘した問題をそのままコードへ自動適用します。すべての変更をレビューしてから採用するかどうか判断しましょう。意図しない変更が含まれる場合があります。

--comment オプション：GitHub PR に対して、指摘内容をインラインコメントとして投稿します。PR番号を指定して使います。

/code-review 123 --comment     # PR #123 にインラインコメントを自動投稿

チームでのコードレビューに組み込むと、レビュアーへの事前情報提供として機能します。

レビューされる内容

/code-review は主に以下の観点でレビューします：

• 正確性バグ: ロジックの誤り・エッジケースの欠落・型の不整合
• 再利用性: コードベース内の既存実装を活かせているか
• 簡潔化: 冗長な実装・より短く書ける箇所
• 効率性: パフォーマンス上の問題・不要な処理

/simplify：コード品質の最終磨き上げ

/simplify はバグを探すのではなく、「動いているコードをより良いコードに」磨き上げることに特化したコマンドです。

/code-review との違い

4エージェントが並列でレビュー

/simplify の内部では、4つの専門エージェントが並列で同時に実行されます。

4つの観点を同時に処理するため、単一のレビューでは見落としがちな問題も検出しやすくなっています。チェック後はそのまま修正をコードへ自動適用します。

基本的な使い方

/simplify               # 現ブランチの変更全体を対象
/simplify src/foo.ts    # 特定ファイルのみ
/simplify 123           # GitHub PR番号を指定

適用された変更は git diff で必ず確認しましょう。意図しない変更が含まれていた場合は git checkout -- <ファイル名> で元に戻せます。

使いどころ

• テストが全て通過した後、PRを出す直前の最終磨き
• リファクタリング後の効率化チェック
• 「動いているが汚いコード」のクリーンアップ

注意: バグが潜んでいる可能性があるときは、先に /code-review を実行しましょう。バグのあるコードをきれいにしても問題は解決しません。

/security-review：セキュリティ脆弱性の専門レビュー

/security-review は、現在のブランチの変更を対象にセキュリティの観点に特化したレビューを行うコマンドです。

検出できる主な脆弱性

基本的な使い方

/security-review                  # 現ブランチの変更全体を対象
/security-review src/auth.ts      # 特定ファイル（認証関連など）
/security-review 123              # GitHub PR番号を指定

/code-review との役割分担

/code-review もある程度のセキュリティチェックを含みますが（表の △）、/security-review はセキュリティ観点に特化しているため、より詳細な脆弱性分析を行います。

一般的な変更 → /code-review で十分
認証・決済・個人情報処理を含む変更 → /code-review + /security-review を両方実行

レポートのみで自動修正は行わない

/security-review は検出した問題を報告するだけで、コードの自動修正は行いません。セキュリティ上の修正は必ず人間が内容を理解した上で行うという設計思想によるものです。検出された問題は一つずつ内容を確認してから手動で修正しましょう。

/verify：実際のアプリ起動で動作を確認

/verify は他の3コマンドとは性質が異なります。コードを静的に分析するのではなく、実際にアプリを起動して動作を確認するコマンドです。

なぜ実際に動かすのか

テストが通過していても、実際のアプリを動かすと問題が発覚することがあります。

• 環境変数や設定ファイルの問題
• 複数コンポーネントの統合時のエラー
• UIの見た目や操作感の問題
• パフォーマンス上の問題（レイテンシ・メモリ使用量など）

静的解析では検出できないこれらの問題を、/verify は実際にアプリを起動することで発見します。

基本的な使い方

/verify                    # 現ブランチの変更を確認
/verify 123                # PR #123 の変更を確認

使いどころ

/run との違い

似たコマンドに /run がありますが、役割が異なります。

実践ワークフロー：4コマンドの組み合わせ

4コマンドを効果的に組み合わせるワークフローを、シーン別に紹介します。

基本ワークフロー（個人開発・日常コミット向け）

実装
  ↓
テスト通過
  ↓
/code-review                    ← バグ・品質を総合チェック
  ↓
（バグがあれば修正して再テスト）
  ↓
/simplify                       ← コードの最終磨き上げ
  ↓
git commit & push

最小限の2コマンドセットです。時間が限られている場合や軽微な変更には、/code-review だけでも十分な場合があります。

安全重視ワークフロー（セキュリティが重要な変更向け）

実装
  ↓
テスト通過
  ↓
/code-review --effort high      ← バグ・品質を深くチェック
  ↓
/security-review                ← セキュリティ脆弱性を念入りにチェック
  ↓
（指摘を手動で確認・修正）
  ↓
/simplify                       ← 最終磨き上げ
  ↓
/verify                         ← 実際に動かして最終確認
  ↓
git commit & push

認証・決済・個人情報処理などセキュリティが重要な変更に適したフローです。

チーム開発ワークフロー（PRを出す場合）

実装
  ↓
テスト通過
  ↓
/code-review                    ← バグ・品質チェック
  ↓
/simplify                       ← 品質磨き
  ↓
/verify                         ← 動作確認
  ↓
PR作成
  ↓
/code-review 123 --comment      ← PRにインラインコメントを自動投稿
  ↓
チームメンバーによるレビュー・マージ

--comment オプションで PR にインラインコメントを自動投稿することで、チームメンバーのレビューを補完できます。AIの指摘をレビュアーが確認する形で、レビューの質と効率を両立できます。

シチュエーション別：どのコマンドを使うか

よくある開発シナリオ別に、適切なコマンドの組み合わせを紹介します。

ケース1：小さなバグ修正

/code-review --effort low   # 高確度の問題だけ素早くチェック

軽微な変更に対して網羅的なレビューをかけると時間のムダです。low で十分な場合がほとんどです。

ケース2：新機能の実装が完了した

/code-review                    # 総合的なバグ・品質チェック
/simplify                       # 品質磨き
/verify                         # 動作確認

新機能は動作確認まで含めた3コマンドセットが理想です。

ケース3：認証機能・決済処理の修正

/code-review --effort high      # 深めのバグ・品質チェック
/security-review                # セキュリティ脆弱性を念入りにチェック
/simplify                       # 最終磨き

セキュリティが重要な変更には必ず /security-review を追加しましょう。

ケース4：大型リリース前の最終確認

/code-review --effort max       # 最大範囲のチェック
/security-review                # セキュリティチェック
/simplify                       # 品質磨き
/verify                         # 動作確認

全コマンドを投入する完全なフローです。

よくある質問（FAQ）

Q. /code-review と /simplify はどちらを先に使うべき？

必ず /code-review が先です。バグが潜んでいるコードをきれいにしても問題は解決しません。バグを修正してから /simplify で磨き上げましょう。

Q. /simplify が自動適用した変更が意図しないものだった場合は？

git diff で変更内容を確認し、不要な変更は git checkout -- <ファイル名> で元に戻せます。心配な場合は /simplify の実行前に git stash でセーフポイントを作っておく方法もあります。

Q. 毎回全コマンドを使う必要がある？

不要です。変更の重要度に応じて使い分けましょう。

Q. これらのコマンドはスキル（Bundled Skill）として実装されているの？

はい。4コマンドすべてがClaude Code のスキル（★マーク付き）として実装されています。スキルの仕組みについては Claude Skills完全ガイド で詳しく解説しています。

Q. --effort ultra と /ultrareview は同じ？

実質的に同じ機能を指します。/ultrareview は独立したコマンドとして実装されており、クラウド上の複数エージェントが協力してレビューを行います。所要時間は約5〜10分、$5〜$25 USD のコストがかかるため、重要な場面に絞って使いましょう。

Amazon検索[本 Claude Code]

まとめ

Claude Code の4つのレビュー系コマンドを振り返りましょう。

まず試すならこの2コマンド:

/code-review    ← バグを探す
/simplify       ← コードを磨く

これだけでも、見落としやすいバグの検出と「動くが汚いコード」の問題を大幅に減らせます。セキュリティが重要な変更には /security-review を、動作確認が必要な場合は /verify を追加していきましょう。

コードレビューの自動化は、品質向上だけでなくレビュアーの認知負荷を減らし、本当に重要な判断に集中する時間を作ることにも繋がります。ぜひ日々の開発フローに取り入れてみてください。

関連記事：

• 【2026年6月最新版】Claude Code全90コマンド以上徹底解説｜全コマンドの一覧はこちら

Claude Codeコマンド一覧【2026年最新】スラッシュコマンド全100種以上を10カテゴリで完全解説

⚡ クイックリファレンス：よく使うコマンドTOP10目的のコマンドをすぐ探したい方はこちら。詳細は各セクションへ。優先度コマンド用途🥇/review ★PRのコードレビューを自動化🥈/plan複雑なタスクを計画的に進める🥉/code-rev...

caymezon.com

2026.02.15

• Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌

Claude Code完全ガイド｜ターミナルで動くAIコーディングアシスタントの全貌【2026年6月版】

はじめに「AIにコードを書かせたいけど、ブラウザとエディタを行き来するのが面倒…」そんな悩みを解決するのがClaude Codeです。2026年6月時点で、Anthropicが提供するターミナル型AIエージェントとして、開発者の間で急速に注...

caymezon.com

2026.02.14

• 【2026年版】Claude Code サブエージェント活用術｜並列実行で作業を最大4倍速にする方法

【2026年版】Claude Code サブエージェント活用術｜並列実行でブログ執筆・調査を最大4倍速にする方法

はじめに「Claude Codeを使っているけど、なんとなく順番に指示しているだけ…」そんな使い方をしていませんか？実は Claude Code には**サブエージェント（並列実行）**という仕組みがあり、複数のタスクを同時に走らせることで...

caymezon.com

2026.06.13

• 【まとめ記事】Claude Code完全攻略ロードマップ｜全記事まとめ

【2026年版】Claude Code完全攻略ロードマップ｜セットアップからVSCode活用・コマンド習得まで全記事まとめ

はじめに「Claude Codeに興味があるけど、何から始めればいいかわからない」「Claude Codeを使い始めたけど、もっと使いこなしたい」この記事は、Claude Codeに関するすべての記事を体系的にまとめたロードマップです。初心...

caymezon.com

2026.03.21

The post 【2026年最新】Claude Codeのコードレビューを自動化する方法｜/code-review・/simplify・/security-review・/verify 実践ガイド first appeared on CayTech Lab.

1️⃣ はじめに：EC2キーペアとは？

AWS EC2インスタンスにSSH接続するためには、**キーペア（.pemファイル）**が必要です。

キーペアの役割

• 認証方式：パスワードではなく公開鍵暗号方式でセキュアに接続
• 用途：EC2インスタンスへのSSHログイン
• 再利用性：一度作成すれば複数のEC2インスタンスで使い回し可能

この記事で学べること

• ✅ AWSコンソールでのキーペア作成方法
• ✅ コマンドライン（AWS CLI）でのキーペア作成方法
• ✅ キーペアの管理とセキュリティのベストプラクティス

対象読者

• AWS初心者でEC2を初めて使う方
• キーペアの作成方法を知りたい方
• コマンドラインでの作成方法を学びたい方

2️⃣ キーペア作成の2つの方法

EC2キーペアの作成方法は2通りあります：

どちらか一方で作成すればOKです。個人利用ならAWSコンソールが簡単、開発環境の構築や自動化を考えるならAWS CLIがおすすめです。

3️⃣ 方法1：AWSコンソールでキーペア作成

手順1：AWSコンソールにログイン

1. AWSマネジメントコンソールにアクセス
2. IAMユーザーまたはルートユーザーでログイン

手順2：EC2ダッシュボードを開く

1. サービス検索で「EC2」を検索
2. 「EC2」をクリックしてダッシュボードを開く
3. 左サイドバーの「ネットワーク＆セキュリティ」セクション
4. 「キーペア」をクリック

手順3：キーペアを作成

1. 「キーペアを作成」ボタンをクリック

2. 設定項目を入力：

   名前：

   my-ec2-test-key

   ※識別しやすい名前を付けましょう（自分の名前や社員番号を含めると管理しやすい）

   キーペアのタイプ：

   • RSA を選択（推奨）

   プライベートキーファイル形式：

   • .pem を選択

3. 「キーペアを作成」ボタンをクリック

4. 自動的に .pem ファイルがダウンロードされます

   • 例：my-ec2-test-key.pem

手順4：キーペアファイルを安全な場所に保存

Windowsの場合：

C:\Users\あなたのユーザー名\.ssh\my-ec2-test-key.pem

Mac/Linuxの場合：

mkdir -p ~/.ssh
mv ~/Downloads/my-ec2-test-key.pem ~/.ssh/
chmod 400 ~/.ssh/my-ec2-test-key.pem

重要：

• .pem ファイルは再ダウンロードできません
• 紛失した場合は新しいキーペアを作成する必要があります
• 適切な権限設定（chmod 400）が必要です

4️⃣ 方法2：AWS CLIでキーペア作成

前提条件

• ✅ AWS CLIがインストール済み
• ✅ AWS CLIの初期設定（aws configure）完了
• ✅ VSCodeなどのエディタ（推奨）

AWS CLIの設定がまだの方は、こちらの記事を参照してください。

手順1：VSCodeのターミナルを開く

VSCode起動：

code .

ターミナルを開く：

• ショートカット：Ctrl + J または Ctrl + @
• メニュー：表示 → ターミナル

手順2：キーペアを作成

aws ec2 create-key-pair \
  --key-name my-ec2-key \
  --query 'KeyMaterial' \
  --output text > ~/.ssh/my-ec2-key.pem

コマンドの説明：

• --key-name my-ec2-key：キーペア名を指定
• --query 'KeyMaterial'：秘密鍵の内容のみ抽出
• --output text：テキスト形式で出力
• > ~/.ssh/my-ec2-key.pem：ファイルに保存

Windowsの場合：

aws ec2 create-key-pair ^
  --key-name my-ec2-key ^
  --query "KeyMaterial" ^
  --output text > %USERPROFILE%\.ssh\my-ec2-key.pem

手順3：権限を設定

Mac/Linux：

chmod 400 ~/.ssh/my-ec2-key.pem

Windows：
VSCodeのターミナルで以下を実行：

icacls %USERPROFILE%\.ssh\my-ec2-key.pem /inheritance:r
icacls %USERPROFILE%\.ssh\my-ec2-key.pem /grant:r "%USERNAME%:R"

手順4：作成確認

aws ec2 describe-key-pairs --key-names my-ec2-key

出力例：

{
    "KeyPairs": [
        {
            "KeyPairId": "key-0123456789abcdef0",
            "KeyFingerprint": "xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx",
            "KeyName": "my-ec2-key",
            "KeyType": "rsa",
            "Tags": []
        }
    ]
}

5️⃣ キーペアの使用方法

EC2インスタンスへのSSH接続

キーペアを使ってEC2インスタンスに接続する基本的なコマンド：

ssh -i ~/.ssh/my-ec2-key.pem ec2-user@

例：

ssh -i ~/.ssh/my-ec2-key.pem ec2-user@54.123.45.67

SSH接続時のトラブルシューティング

エラー：「Permission denied (publickey)」

原因：

• キーペアファイルの権限が適切でない
• キーペア名が間違っている

解決方法：

# 権限を再設定
chmod 400 ~/.ssh/my-ec2-key.pem

# キーペア名を確認
aws ec2 describe-key-pairs

エラー：「WARNING: UNPROTECTED PRIVATE KEY FILE!」

原因：
キーペアファイルの権限が緩すぎる（Windowsでよく発生）

解決方法（Windows）：

icacls %USERPROFILE%\.ssh\my-ec2-key.pem /inheritance:r
icacls %USERPROFILE%\.ssh\my-ec2-key.pem /grant:r "%USERNAME%:R"

6️⃣ キーペア管理のベストプラクティス

セキュリティ対策

1. 適切な保管場所

推奨：~/.ssh/ ディレクトリ
非推奨：デスクトップやダウンロードフォルダ

2. 権限設定

# 所有者のみ読み取り可能（必須）
chmod 400 ~/.ssh/my-ec2-key.pem

3. バックアップ

• クラウドストレージ（暗号化推奨）
• パスワード管理ツール（1Password、Bitwardenなど）
• 外部ストレージ（暗号化USB）

4. 命名規則

良い例：
- my-ec2-production-key
- john-dev-key-2026
- company-staging-key

悪い例：
- key.pem
- test.pem
- keypair.pem

複数のキーペア管理

SSH config を活用：

~/.ssh/config ファイルを作成：

# 開発環境用
Host dev-ec2
    HostName 54.123.45.67
    User ec2-user
    IdentityFile ~/.ssh/my-dev-key.pem

# 本番環境用
Host prod-ec2
    HostName 54.234.56.78
    User ec2-user
    IdentityFile ~/.ssh/my-prod-key.pem

接続が簡単に：

# 通常
ssh -i ~/.ssh/my-dev-key.pem ec2-user@54.123.45.67

# SSH config利用
ssh dev-ec2

7️⃣ キーペアの削除

不要なキーペアを削除する方法

AWSコンソール：

1. EC2ダッシュボード → キーペア
2. 削除したいキーペアを選択
3. 「アクション」→「削除」

AWS CLI：

aws ec2 delete-key-pair --key-name my-ec2-key

注意：

• 削除しても既存のEC2インスタンスには影響なし
• ただし、新しいインスタンスでは使用不可
• ローカルの .pem ファイルは自動削除されません（手動削除が必要）

8️⃣ まとめ

この記事では、AWS EC2キーペアの作成方法を2つ紹介しました。

学んだこと

• ✅ AWSコンソールでのキーペア作成：直感的で初心者向け
• ✅ AWS CLIでのキーペア作成：自動化・スクリプト化が可能
• ✅ キーペア管理のベストプラクティス：セキュリティと利便性のバランス

次のステップ

キーペアを作成したら、次は実際にEC2インスタンスを構築してみましょう：

• CloudFormationでEC2構築：インフラをコードで管理
• VSCode Remote-SSH：VSCodeからEC2に直接接続
• Session Manager：キーペア不要の安全な接続方法

参考リンク：

• AWS公式ドキュメント：Amazon EC2 キーペア
• AWS CLI リファレンス：create-key-pair

関連記事：

• 【初心者向け】VSCodeとAWS CLIで始める！AWS EC2環境構築とGit連携の完全ガイド

最終更新： 2026年1月11日

The post 【AWS初心者向け】EC2キーペア作成の完全ガイド｜AWSコンソールとCLIの2つの方法 first appeared on CayTech Lab.