[Claude Code] ターミナル完結のナレッジ自動生成・保存

Claude Codeにはカスタムスラッシュコマンドを作成する機能があります

https://docs.anthropic.com/ja/docs/claude-code/tutorials#%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%A0%E3%82%B9%E3%83%A9%E3%83%83%E3%82%B7%E3%83%A5%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B

これを用いて、非常に高速、かつ簡単に、ナレッジをドキュメントとして保存することができます。

例えば、以下のようにして、カスタムスラッシュコマンドを作成します。
```sh
$ mkdir -p ~/.claude/commands
$ cat > ~/.claude/commands/record.md <<EOF
$ARGUMENTS

直前の内容(知見、ノウハウ)を統括的にドキュメントとして./docs/に保存してください。必ず、新規ファイルとして作成されるようにしてください。
既存のドキュメントを上書きしてはいけません。ディレクトリがないのであれば新規作成してください。ドキュメントのタイトルは日本語にしてください。
EOF
```

ユーザーレベルでのカスタムスラッシュコマンドとして設定しました。Claude Codeは、`~/.claude/commands/`ディレクトリにあるファイルをカスタムスラッシュコマンドとして認識します。つまり上記のプロンプトが`/user:record`というカスタムスラッシュコマンドとして使えるようになります(Tab補完も効く)。

### 使い方の例
例えば、Claude Codeがコードのバグないし不適切な点を発見して、修正してくれた、もしくは指摘してくれたケースです。

Terraformのcountを使ったリソースの最適化について、私が以下のようにやり取りを行いました。

```sh
#　中略
> これに関して、countを使用してブロックをまとめられない？
  ⎿  ⧉ Selected 23 lines from infra/modules/aws/vpc.tf in Visual Studio Code

⏺ はい、countを使用してこれらのサブネットブロックをまとめることができます。

⏺ Read(infra/modules/aws/vpc.tf)
  ⎿  Read 99 lines (ctrl+r to expand)

⏺ Update(infra/modules/aws/vpc.tf)
  ⎿  Updated infra/modules/aws/vpc.tf with 5 additions and 16 removals
  ...

⏺ 次に、他の場所でのサブネット参照も更新する必要があります：

⏺ Update(infra/modules/aws/vpc.tf)
  ⎿  Updated infra/modules/aws/vpc.tf with 1 addition and 1 removal
  ...

⏺ Update(infra/modules/aws/vpc.tf)
  ⎿  Updated infra/modules/aws/vpc.tf with 1 addition and 1 removal
  ...

⏺ 他のファイルでこれらのサブネットが参照されているかも確認する必要があります：
  ...

⏺ Update(infra/modules/aws/eks_node_group.tf)
  ⎿  Updated infra/modules/aws/eks_node_group.tf with 1 addition and 1 removal
  ...
⏺ 完了しました。countを使用してパブリックサブネットのブロックを1つにまとめ、関連する参照もすべ
  て更新しました。これにより、コードがより簡潔で保守しやすくなりました。
```

ここで、先ほどのカスタムスラッシュコマンドを使って、修正内容をドキュメントとして保存します。
```
> /user:record is running… 

⏺ List(.)
  ⎿  Listed 297 paths (ctrl+r to expand)

⏺ Write(docs/terraform-count-optimization.md)
  ⎿  Wrote 98 lines to docs/terraform-count-optimization.md
     # Terraformでのcountを使ったリソース最適化
     ## 概要
     Terraformで同様の構成を持つ複数のリソースを定義する際、`count`メタ引数を使用してコードの重
     複を削減し、保守性を向上させることができます。
     ## 実装例：EKSパブリックサブネット
     ### 変更前（個別定義）
     … +88 lines (ctrl+r to expand)

⏺ Terraformでのcountを使ったリソース最適化に関するドキュメントを./docs/terraform-count-optimiza
  tion.mdとして保存しました。先ほどの作業内容（パブリックサブネットの個別定義からcountを使った
  統合への変更）を知見として記録しています。
```

生成されたドキュメント
```md
# Terraformでのcountを使ったリソース最適化

## 概要

Terraformで同様の構成を持つ複数のリソースを定義する際、`count`メタ引数を使用してコードの重複を削減し、保守性を向上させることができます。

## 実装例：EKSパブリックサブネット

### 変更前（個別定義）

\`\`\`hcl
resource "aws_subnet" "eks-subnet-public-1" {
  vpc_id                  = aws_vpc.eks-vpc.id
  cidr_block              = "10.0.1.0/24"
  map_public_ip_on_launch = true
  availability_zone       = "ap-northeast-1a"
  tags = {
    Name                                                = "${var.app_name} EKS Subnet public 1"
    "kubernetes.io/cluster/${var.app_name}-eks-cluster" = "shared"
    "kubernetes.io/role/elb"                            = "1"
  }
}

resource "aws_subnet" "eks-subnet-public-2" {
  vpc_id                  = aws_vpc.eks-vpc.id
  cidr_block              = "10.0.2.0/24"
  map_public_ip_on_launch = true
  availability_zone       = "ap-northeast-1c"
  tags = {
    Name                                                = "${var.app_name} EKS Subnet public 2"
    "kubernetes.io/cluster/${var.app_name}-eks-cluster" = "shared"
    "kubernetes.io/role/elb"                            = "1"
  }
}
\`\`\`

### 変更後（count使用）

\`\`\`hcl
resource "aws_subnet" "eks-subnet-public" {
  count                   = 2
  vpc_id                  = aws_vpc.eks-vpc.id
  cidr_block              = "10.0.${count.index + 1}.0/24"
  map_public_ip_on_launch = true
  availability_zone       = count.index == 0 ? "ap-northeast-1a" : "ap-northeast-1c"
  tags = {
    Name                                                = "${var.app_name} EKS Subnet public ${count.index + 1}"
    "kubernetes.io/cluster/${var.app_name}-eks-cluster" = "shared"
    "kubernetes.io/role/elb"                            = "1"
  }
}
\`\`\`

## 参照の更新

countを使用してリソース名を変更した場合、他のリソースからの参照も更新する必要があります。

### 変更前

\`\`\`hcl
subnet_ids = [aws_subnet.eks-subnet-public-1.id, aws_subnet.eks-subnet-public-2.id]
\`\`\`

### 変更後

\`\`\`hcl
subnet_ids = aws_subnet.eks-subnet-public[*].id
\`\`\`

## メリット

1. **コードの重複削除**: 類似リソースを1つのブロックで定義
2. **保守性向上**: 変更時に1箇所の修正で済む
3. **スケーラビリティ**: countの値を変更するだけで数を増減可能
4. **一貫性保証**: 同じパターンで確実にリソースが作成される

## 注意点

1. **動的な値の扱い**: `count.index`を使って動的にCIDRブロックやAZを指定
2. **参照の更新**: 既存の個別参照をすべて配列参照（`[*]`）に変更
3. **条件分岐**: 三項演算子（`condition ? true_val : false_val`）を使用して異なる値を設定

## 適用場面

このパターンは以下のような場面で有効です：

- 複数のサブネット（パブリック/プライベート）
- 複数のアベイラビリティゾーンでの同一構成
- セキュリティグループルール
- IAMポリシーアタッチメント
```

このように、Claude Codeがコードの修正を行った後に、その内容をドキュメントとして保存することができます。
もし、Claude Codeの修正、生成内容以外で自分が気づいたことや、知見を残したい場合も同様にカスタムスラッシュコマンドを使ってドキュメント化できます。

これのメリットは、言わずもがなですが、最も重要なのは、<font color="Red">__Claude CodeにMCPサーバーの使用を設定することで、単なるファイル出力じゃなくてNotion、Obsidianにドキュメントをそのまま転送してしまうポテンシャルがある点です。__</font>さらに、そのままナレッジをQiitaに投稿することだって可能なのではないでしょうか？

ターミナルでコマンド一つ実行するだけで、ドキュメント化と共有を完了することが出来ます。
これにより、エンジニアのナレッジアプトプットが爆速になります。

結論：Claude Codeを使え