はじめに：新人でも「提案」即「実装」できる文化
こんにちは。
プロダクト開発部 SREグループに所属している酒井です！
2025年9月に入社し、ちょうど3ヶ月が経ちました。
「入社してまだ3ヶ月」ですが、私の所属する組織では 「年次に関係なく、良い改善提案は即採用」 という文化があります。
特にAIを活用した開発生産性の向上には組織全体で意欲的で、入社したての私にもClaude Codeなどの最新ツールを利用できる環境が与えられており、生産性向上のための試行錯誤には時間を惜しまず投資する方針があります。
今回は、そんな自由闊達な環境で、SREの定型業務の一つである「インフラドキュメント作成」を効率化し、トイルの削減と開発者体験（DX）を向上させた事例を紹介します。
組織の課題：属人化と情報探索のコスト
私のチームではAWSを使用しており、全てTerraformでコード化（IaC）しています。
しかし、システム規模が拡大するにつれ、一つの課題が浮き彫りになっていました。
「開発者が、欲しいインフラ情報にたどり着けない」
「この環境のDBのエンドポイントどれだっけ？」「CodePipelineはどれだっけ？」 こうした質問がチャットで飛んでくることは、開発現場ではよくある光景です。
もちろん「Terraformを見ればわかる」あるいは「AWSコンソールを見ればわかる」と言うのは簡単です。
しかし、インフラに詳しくない開発者が、複雑なモジュール構成やリソースの中から目的の値を探すのは大きなストレスです。
また、jinjerのSREチームには 「トイル（手動で、反復して行われ、自動化が可能なもの）を削減し、人間は価値ある仕事に集中しよう」 という共通認識があります。
「情報を探す」という単純作業で開発者の時間を奪うのは、SREとして解決すべき課題でした。
解決への思想：「コード」ではなく「現実（State）」を見る
当初、私はClaude Codeに対して「Terraformコード（.tfファイル）を解析してドキュメントを作って」と依頼していました。
しかし、これは失敗でした。複雑なモジュール構成を追うのは、AIにとっても難易度が高かったようです。
試行錯誤した結果、「Terraformのコードはあくまで設計図。tfstateにデプロイされた全ての情報があるのではないか？」 と気づきました。
terraform.tfstate には、どんなに複雑なmodule構成であっても、展開されたリソースの結果がフラットな正解データとして記録されています。
「LLM（Claude Code）に、tfstateという『現実』を渡せば、求めているのドキュメントが作れるはずだ」
この思想に基づき、アプローチを「tfstate（JSON）をLLMに解釈させる」方針へ転換しました。
実装：Claude Codeによる「再現性」の確立
単に私が手元でやるだけでなく、チームの誰でも同じ品質でドキュメントを生成できるよう、Claude Codeの「スラッシュコマンド」として標準化しました。
（※ブログ掲載用に、一部簡略化しています）
# 開発者向けドキュメント作成（tfstate版）
現在のプロジェクト環境のTerraform状態ファイル（tfstate）から、開発者が必要とする包括的な技術ドキュメントを日本語で作成します。
### 記載する情報（tfstateから取得）
1. **AWS基本情報**
- AWSアカウントID、リージョン、環境名（タグ情報）
2. **ドメイン・エンドポイント情報**
- Route53、ALB、CloudFrontの紐付け情報
3. **データストア・コンテナ情報**
- Aurora/Redisエンドポイント、ECSサービスとドメインの対応
（...その他必要な情報。省略）
## ⚙️ 実行手順
### tfstate情報取得
（...中略...）
### 実際のリソース情報収集
5. **🎯 全体状態の取得**:
```bash
# 指定されたプロファイルでJSON形式の全リソース状態を取得
AWS_PROFILE=$SELECTED_PROFILE terraform show -json > /tmp/tfstate_$(date +%Y%m%d_%H%M%S).json
# リソース一覧を取得
AWS_PROFILE=$SELECTED_PROFILE terraform state list > /tmp/resources_list.txt
# 全outputsを取得
AWS_PROFILE=$SELECTED_PROFILE terraform output -json > /tmp/outputs.json 2>/dev/null || echo "{}" > /tmp/outputs.json
```
### 詳細情報の抽出
6. **🔍 カテゴリ別リソース抽出**:
取得したJSONファイルを読み込み、以下の構造でマークダウンを作成してください。
※JSONの構造はネストしているため、module階層を横断してリソース（Route53, ALB, ECS等）を探してください。
### 包括的ドキュメント生成
7. **📝 マークダウン生成**: 収集した情報を以下の構造で整理
```markdown
# [Project] [Environment] 開発者向け技術ドキュメント
> 生成日時: $(date '+%Y年%m月%d日 %H:%M:%S JST')
> データソース: Terraform State (tfstate)
## 🏗️ インフラ概要
（...テーブル形式での出力定義...）
```
8. **💾 ファイル出力**: `DEVELOPER_README.md` として保存
9. **🧹 クリーンアップ**: 一時ファイルの削除
```bash
rm -f /tmp/tfstate_*.json /tmp/resources_list.txt /tmp/outputs.json /tmp/*.csv /tmp/route53_records.txt /tmp/ecs_services.txt /tmp/ecs_domain_mapping.txt
```
## 📄 生成されるファイル
- **ファイル名**: `DEVELOPER_README.md`
- **配置場所**: 現在のディレクトリ（プロジェクト環境配下）
- **言語**: 日本語（完全日本語対応）
- **形式**: Markdown
- **内容**: 開発者が必要とする環境固有の技術情報を網羅した包括的ドキュメント
なぜ jq ではなく Claude Code なのか？
「JSONならjqコマンドで抜けばいいのでは？」と思われるかもしれません。
しかし、私たちは 「メンテナンス性」と「柔軟性」 を重視しました。
jqで整形ロジックをガチガチに組むと、フォーマット変更のたびにスクリプト修正という「トイル」が発生します。
対してLLMなら、「やっぱりこの項目も表に追加して」と自然言語で指示を変えるだけです。
LLMをうまく活用することで、運用コストを極限まで下げています。
成果：「時間削減」以上の価値
この取り組みは、単なる工数削減以上の成果をチームにもたらしました。
- SREチームが信頼性向上に集中
- 手作業による作業を削減したため、本来やるべき信頼性向上に時間を回すことができ、将来的な運用工数の削減につながります。
- 開発者体験（DX）の向上
- 開発者はWikiやコードを探し回る必要がなくなり、本来の開発業務に集中できるようになりました。
- 欲しい情報に追加があった場合も、高速に対応が可能になりました。
- オンボーディングの高速化
- 新しく入ったメンバーも、スラッシュコマンド一発でその環境の全体像を作成できます。
- ドキュメント生成のコマンドも、LLMを通して簡単にブラッシュアップが可能です。
- 属人性の排除と心理的安全性
- 「あの人しか知らない」ということがなくなり、誰でも環境情報を作成可能な状態になりました。
「人が時間をかけていた作業を、AIに渡してチームの知識に還元する」 これが実現できたことが、最大の成果です。
jinjer SREチームが目指すもの
今回の事例は、入社3ヶ月の私が「これやってみたいです」と声を挙げ、チームが「いいね、やってみよう」と背中を押してくれたからこそ実現しました。
jinjerのSREは、単なるインフラのお守り役ではありません。
SREとしての役割も持ちつつ、 「開発者体験を最大化するプロダクトチーム」 という側面も持っています。
- AI導入が強制ではなく、自主的に試せる
- PoCしたものを共有し、標準化する文化がある
- SREが「開発者のために」動くことが評価される
そんな環境だからこそ、今回のドキュメント自動化のような改善が日々生まれています。
入社したばかりだからということもなく、誰でも挑戦が可能です！
最後に：一緒に「開発者体験」を作りませんか？
私たちは、AIや新しい技術を武器に、現場の課題をハックしていく仲間を求めています。
「仕組みづくりが好き」 「困っているエンジニアを楽にしたい」 「新しい技術を試せる環境で働きたい」
もしそう感じたなら、ぜひ一度お話ししませんか？
jinjerでは、あなたの挑戦を全力で歓迎します！
Discussion