はじめに

株式会社エスプリフォートは、
「ITの力でお客様のビジネスを支え、笑顔と価値を創造する」ことを大切にしているシステム開発会社です。

私たちは、単に新しい技術を追いかける会社ではありません。
エスプリフォートのクレドは、又の名を「皆の幸せ化、計画書」と位置づけられており、社員一人ひとりの幸せ、仲間との信頼、顧客価値の創造を本気で大切にしています。

だからこそ、Claude CodeのようなAI開発ツールを見たとき、私たちはこう考えました。

「便利そう」では足りない。
これを使って、どう顧客価値を生み、どう成果につなげるか。

この記事では、Claude Codeを単なるAIコーディング補助ではなく、
**システムエンジニアの仕事そのものを進化させる“開発エージェント”**として紹介します。

Claude Codeとは何か？

Claude Codeは、Anthropicが提供するエージェント型の開発支援ツールです。

公式ドキュメントでは、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行し、開発ツールと連携するエージェント型コーディングツールと説明されています。ターミナル、IDE、デスクトップアプリ、ブラウザから利用でき、コードベース全体を理解しながら、複数ファイル・複数ツールをまたいで作業できます。(Claude)

つまり、Claude Codeは単なるチャットAIではありません。

たとえば、次のようなことができます。

claude "認証モジュールのテストを書いて、実行して、失敗したら修正して"

これは、ただ「テストコード案を出す」だけではありません。

Claude Codeは、プロジェクト内のファイルを読み、必要なテストを作成し、コマンドを実行し、エラーを見て、修正まで進めることができます。公式ドキュメントでも、未テストコードへのテスト追加、lint修正、マージコンフリクト解消、依存関係更新、リリースノート作成など、開発者が後回しにしがちな作業の自動化が例示されています。(Claude)

SEにとって重要なのは、ここです。

Claude Codeは「答えを聞くAI」ではなく、作業を前に進めるAIです。

SEがClaude Codeに強烈に興味を持つべき理由

多くのシステムエンジニアは、日々こんな仕事に追われています。

既存コードの調査
仕様変更の影響範囲確認
テストデータ作成
単体テスト追加
エラー原因調査
lint・フォーマット修正
レビュー指摘対応
READMEや手順書の更新
リリースノート作成
PR説明文作成
誤字脱字チェック
顧客向け資料のたたき台作成

これらは大事です。
しかし、すべてを人間がゼロからやる必要があるでしょうか。

Claude Codeを使うと、SEは「作業者」から一段上がれます。

たとえば、こんな依頼ができます。

claude "この機能追加の影響範囲を調べて、修正方針を出して"

claude "このエラーログから原因を調査して、再現手順と修正案をまとめて"

claude "このCSV仕様に合わせてテストデータを30件作って"

claude "READMEと実装がズレていないか確認して、必要なら修正して"

claude "このPRの差分を見て、セキュリティ面と保守性の観点でレビューして"

これまでなら、若手SEが半日かけて調べ、先輩に聞き、Excelにまとめ、レビューで差し戻されていたような作業が、AIと一緒に短時間で進められる可能性があります。

重要なのは、楽をすることではありません。

浮いた時間で、より深く考える。
より良い設計にする。
顧客により良い提案をする。
品質を上げる。
チームにナレッジを残す。

ここにClaude Codeの本当の価値があります。

Claude CodeでSEの仕事はどう変わるのか？

1. 調査が速くなる

既存システムの改修で一番時間を使うのは、実はコーディングではありません。

「どこを直せばいいのか」
「この修正はどこに影響するのか」
「なぜこの実装になっているのか」

この調査です。

Claude Codeはコードベースを読みながら、関連ファイルを横断して調査できます。公式ドキュメントでも、バグについてはエラーメッセージや症状からコードベースを追跡し、根本原因を特定して修正できると説明されています。(Claude)

つまり、今までの開発での初動が変わります。

これまで：

grepする
関連ファイルを探す
処理を追う
過去の実装を読む
影響範囲をメモする
修正方針を考える

これから：

Claude Codeに調査させる
出てきた結果をSEがレビューする
不足観点を追加で深掘りする
修正方針を決める

AIに丸投げするのではなく、
AIを調査パートナーにするということです。

2. テストが“後回し”ではなくなる

現場でよくあるのが、これです。

「本当はテストを厚くしたい」
「でも納期が近い」
「既存コードが複雑で、テスト追加が面倒」
「結局、手動確認で済ませてしまう」

Claude Codeは、こうしたテスト作成の重さを下げます。

claude "このサービスクラスの正常系・異常系の単体テストを追加して"

claude "境界値を含むテストケースを洗い出して、テストデータも作って"

claude "既存のテストスタイルに合わせて、この新機能のテストを追加して"

AIがテストのたたき台を作ってくれれば、人間はそこから品質を上げることに集中できます。

これは特に、保守開発・改修案件・レガシーシステムで大きな価値があります。

テストを書くハードルが下がる。
それだけで、現場の品質はかなり変わります。

3. Git作業・PR作業が楽になる

Claude Codeはgitとも直接連携できます。公式ドキュメントでは、変更のステージング、コミットメッセージ作成、ブランチ作成、プルリクエスト作成ができるとされています。(Claude)

たとえば、こう使えます。

claude "今回の変更内容を整理して、適切なコミットメッセージを作って"

claude "この差分のPR説明文を作成して。変更理由、影響範囲、テスト観点も入れて"

claude "mainとの差分をレビューして、危なそうな箇所を指摘して"

SEにとって、PR説明文やレビュー観点の整理は地味に時間を取られます。

しかし、ここをAIに支援させることで、
レビューの質を落とさず、むしろ上げることができます。

Claude Codeの“最新機能”が現場に刺さる理由

ここからが本題です。

Claude Codeは、単なるCLIツールではなく、開発ワークフロー全体に入り込む仕組みを持っています。

MCP：Jira、Slack、DB、Figmaなどとつながる

Claude CodeはMCP、Model Context Protocolを通じて、外部ツールやデータソースと連携できます。公式ドキュメントでは、MCPサーバーにより、Claude Codeがツール、データベース、APIへアクセスでき、チケット管理、監視データ、PostgreSQL、Figma、Slack、Gmailなどを使ったワークフロー例が示されています。(Claude API Docs)

これは、SEにとって非常に大きいです。

なぜなら、現場の仕事はコードだけで完結しないからです。

Jiraの課題を見る
Slackのやり取りを見る
Figmaのデザインを見る
DBを確認する
Sentryなどの監視を見る
GitHubのIssueを見る
仕様書を見る

これらを人間がコピペしてAIに渡すのではなく、MCPでつなげば、Claude Codeが必要な情報を取りに行けるようになります。

つまり、将来的な開発現場はこうなります。

人間が情報を集める
↓
AIに渡す
↓
AIが答える

ではなく、

人間が目的を伝える
↓
AIが必要な情報を取りに行く
↓
AIが修正・検証・提案する
↓
人間が判断する

この差は大きいです。

Hooks：チームのルールを自動で守らせる

Claude CodeのHooksは、Claude Codeのライフサイクル上の特定タイミングで自動実行されるユーザー定義のシェルコマンド、HTTPエンドポイント、LLMプロンプトです。公式ドキュメントでは、PreToolUse、PostToolUse、SessionStart、SessionEndなどのイベントに応じて処理を挟めると説明されています。(Claude API Docs)

たとえば、こんなことができます。

Claudeがファイル編集した後に自動でformatterを実行
ClaudeがBashを実行する前に危険コマンドをブロック
コミット前にlintを強制
テスト失敗時にログを収集
特定ディレクトリの変更時だけレビュー観点を追加

AIを導入するとき、多くの現場で不安になるのはここです。

「勝手に危ないコマンドを実行しないか」
「チームのコーディング規約を守れるのか」
「レビュー前に最低限のチェックを通せるのか」

Hooksを使えば、AIの行動に対してガードレールを敷けます。公式ドキュメントでも、PreToolUse hookでコマンドをブロックしたり、allow・deny・askのような権限制御を返せる仕組みが説明されています。(Claude)

AI活用は、自由に使わせるだけでは危険です。
しかし、ルールを整えれば、現場の武器になります。

Subagents：レビュー担当、設計担当、テスト担当を分けられる

Claude CodeにはSubagentsがあります。公式ドキュメントでは、MarkdownファイルとYAML frontmatterで定義でき、/agentsコマンドから作成・管理できるとされています。サブエージェントごとにプロンプト、ツール制限、モデル、メモリなどを設定できます。(Claude API Docs)

これは、開発現場でいうとかなり面白いです。

たとえば、以下のような専門AIを作れます。

code-reviewer
保守性・可読性・性能・セキュリティ観点でレビューするAI

test-designer
正常系・異常系・境界値・回帰観点を洗い出すAI

legacy-investigator
レガシーコードの影響範囲調査に特化したAI

document-writer
README、設計メモ、手順書、リリースノートを書くAI

security-checker
危険な実装や認証・認可漏れを重点的に見るAI

これまで人間の頭の中にあった「レビュー観点」や「設計観点」を、AIエージェントとして定義できるわけです。

これはチーム開発において強力です。

個人のスキル差を埋める。
若手のレビュー品質を上げる。
ベテランの暗黙知を仕組みにする。
プロジェクトごとの標準をAIに持たせる。

Subagentsは、単なる便利機能ではなく、チームの開発力を底上げする仕組みになり得ます。

Skills：毎回貼っていた手順を“機能化”できる

Claude CodeのSkillsは、SKILL.mdに手順やチェックリストを書き、Claudeのツールキットとして使える仕組みです。公式ドキュメントでは、同じプレイブック、チェックリスト、複数手順を何度も貼っている場合にSkill化するとよいと説明されています。また、Skill本体は使うときだけ読み込まれるため、長い手順も必要時までコストをほとんど使わないとされています。(Claude)

たとえば、以下をSkill化できます。

/review-pr
自社のレビュー観点でPRを見る

/create-test-data
指定仕様に沿ってテストデータを作る

/check-release
リリース前チェックリストを実行する

/write-design-note
設計判断の背景をドキュメント化する

/check-typo
仕様書やREADMEの誤字脱字・表記ゆれを確認する

特にSE業務では、毎回似たような確認をします。

「この観点で見て」
「このフォーマットで書いて」
「この粒度で整理して」
「この順番でチェックして」

それを毎回プロンプトで書くのは非効率です。

Skillsにすれば、チームの作業標準をAIに埋め込めます。

Plugins：チームのClaude Code環境を配布できる

Claude CodeにはPluginsもあります。公式ドキュメントでは、PluginsはSkills、Agents、Hooks、MCPサーバーなどを含めてClaude Codeを拡張し、プロジェクトやチーム間で共有できる仕組みと説明されています。(Claude)

これが意味するのは、個人のAI活用を超えて、組織としてAI活用を標準化できるということです。

たとえば、会社として以下をPlugin化できます。

自社標準のレビュー観点
自社標準の設計書テンプレート
自社標準のテスト観点
禁止コマンドのHooks
顧客別の開発ルール
業務別の調査手順
新人向けコード説明Skill

AI活用は、個人任せにすると差が出ます。

使える人はどんどん使う。
使えない人は何も変わらない。
結果、チームとしての生産性は上がりません。

しかし、Plugin化すれば、会社やチームのノウハウをAI環境として配れます。

これは、かなり大きな変化です。

GitHub Actions連携：PRやIssueでClaudeを動かせる

Claude Code GitHub Actionsを使うと、PRやIssueで@claudeとメンションするだけで、Claudeがコード分析、PR作成、機能実装、バグ修正を行えるようになります。公式ドキュメントでは、プロジェクト標準に従いながらAIによるGitHubワークフロー自動化を実現できると説明されています。(Claude)

たとえば、Issueにこう書きます。

@claude
このIssueの内容をもとに、入力チェック処理を追加してください。
既存のバリデーション方針に合わせて実装し、テストも追加してください。

すると、Claudeが実装方針を考え、コードを変更し、PRを作る。

もちろん、人間のレビューは必要です。
しかし、最初のたたき台作成、テスト追加、レビュー観点整理が自動化されるだけでも、開発速度は大きく変わります。

特に、以下のような作業に向いています。

軽微な不具合修正
テスト追加
型定義修正
ドキュメント更新
依存関係更新
リファクタリング案作成
レビュー前のセルフチェック

今後、SEに求められるのは、
全部を自分で手作業する力ではなく、
AIに任せる範囲と、人間が判断する範囲を切り分ける力です。

Claude Codeを使うSEが最初にやるべきこと

いきなり大規模開発をAIに任せる必要はありません。

まずは、以下の5つから始めるのがおすすめです。

1. READMEを読ませて理解させる

claude "このプロジェクトの構成を説明して。初めて入ったSE向けにわかりやすく"

2. 既存コードの処理フローを説明させる

claude "src配下の認証処理の流れを、ファイル単位で整理して"

3. テストを追加させる

claude "この関数の単体テストを追加して。正常系、異常系、境界値を含めて"

4. PRレビューさせる

git diff main --name-only | claude -p "変更ファイルを保守性・セキュリティ・テスト観点でレビューして"

Claude CodeはCLIとしてパイプやスクリプト、CIとも組み合わせられ、ログ解析、翻訳PR作成、差分レビューなどの例も公式ドキュメントで示されています。(Claude)

5. チームのルールをCLAUDE.mdに書く

Claude Codeでは、プロジェクトルートに置いたCLAUDE.mdをセッション開始時に読み込み、コーディング標準、設計判断、利用ライブラリ、レビュー観点などを伝えられます。(Claude)

例：

# CLAUDE.md

## コーディング方針
- 既存の命名規則を優先する
- 変更範囲は最小限にする
- 複雑な処理にはコメントを追加する
- テストを追加できる場合は必ず提案する

## レビュー観点
- 認証・認可漏れ
- null/undefined
- 境界値
- パフォーマンス
- 既存仕様への影響

これだけでも、Claude Codeの出力品質はかなり変わります。

Claude Codeを使う上での注意点

Claude Codeは強力です。
しかし、強力だからこそ、使い方を間違えると危険です。

特に注意すべきは以下です。

AIの修正をそのまま信じない
本番DBや機密情報に安易に触らせない
MCP連携は信頼できるものに限定する
危険コマンドはHooksや権限設定で制御する
PRは必ず人間がレビューする
仕様判断は人間が責任を持つ

MCPについても、公式ドキュメントでは、第三者MCPサーバーの利用は自己責任であり、未検証のサーバーや信頼できないコンテンツを取得するサーバーにはプロンプトインジェクションリスクがあると注意されています。(Claude API Docs)

AIは優秀な相棒です。
しかし、責任者ではありません。

責任を持つのは、あくまでSEです。

だからこそ、AIを使えるSEに必要なのは、単なるプロンプト力ではありません。

設計力
レビュー力
検証力
セキュリティ意識
業務理解
顧客価値への意識
成果にこだわる姿勢

Claude Codeを使えば、誰でも一瞬で優秀なSEになるわけではありません。

しかし、優秀なSEになろうとする人の成長速度は、間違いなく上げることはできます。

仕様書がない現場で、ソースから設計書を起こす

システム開発の現場で、かなり多い悩みがあります。

仕様書がない。
あっても古い。
実装と設計書がズレている。
前任者しか分からない処理がある。
改修したいが、影響範囲が怖くて触れない。

これは、保守開発・追加改修・長期運用システムでは本当によくあります。

そして、この状態で一番つらいのは、
「コードを書くこと」ではありません。

既存ソースを読んで、現在の仕様を理解し、設計書として再整理することです。

ここでClaude Codeは、非常に強力な武器になります。

Claude Codeは、コードベースを読み、複数ファイルを横断し、コマンド実行や開発ツール連携までできるエージェント型のコーディングツールです。つまり、単一ファイルだけを見るのではなく、プロジェクト全体を見ながら処理の流れを整理できます。(Claude)

たとえば、仕様書がない状態で、まずこう聞けます。

claude "このリポジトリ全体を読み、主要な機能一覧を洗い出してください。画面、API、バッチ、DBアクセス単位で整理してください。"

次に、特定機能を深掘りします。

claude "受注登録機能について、入口となる画面/API、呼び出されるサービス、DB更新、外部連携、例外処理を順番に整理してください。"

さらに、設計書の形に落とします。

claude "受注登録機能の処理内容を、基本設計書としてまとめてください。以下の形式で出してください。
1. 機能概要
2. 利用者
3. 入力項目
4. 入力チェック
5. 処理フロー
6. DB参照・更新内容
7. 外部連携
8. エラー処理
9. 権限・認可
10. 注意点・未確認事項"

これを使えば、SEはゼロからソースを読み続けるのではなく、
Claude Codeに一次解析させ、人間が妥当性を確認しながら設計書化する流れを作れます。

ソースから設計書を起こす具体的な流れ

おすすめは、いきなり設計書を書かせないことです。

Claude Codeの公式ベストプラクティスでも、いきなり実装させるのではなく、まず探索し、計画し、その後に実装する流れが推奨されています。これは設計書作成でも同じです。先にコードを探索し、構造を理解し、未確認点を洗い出してから文書化するのが安全です。(Claude)

流れはこうです。

1. 全体構造を把握する
2. 機能一覧を作る
3. 対象機能の入口を特定する
4. 処理フローを追う
5. DB・外部連携・例外処理を整理する
6. 不明点・推測点を分ける
7. 設計書形式にまとめる
8. テストや実行結果で確認する
9. 人間がレビューして正式化する

特に大事なのは、
「確定事項」と「推測」を分けることです。

Claude Codeには、次のように指示すると実務で使いやすくなります。

claude "この機能の仕様をソースから読み取ってください。ただし、ソースから確実に分かること、推測できること、不明なことを必ず分けて整理してください。"

これを入れるだけで、設計書の信頼性がかなり上がります。

AIが怖いのは、もっともらしく書いてしまうことです。
だからこそ、分かったこと・分からないことを分けるのが重要です。

仕様書復元用のプロンプト例

現場でそのまま使うなら、以下のようなプロンプトが便利です。

claude "仕様書が存在しないため、ソースコードから現行仕様を復元したいです。
まず対象機能の関連ファイルを調査し、以下を整理してください。

- 機能概要
- 処理の入口
- 呼び出し関係
- 処理フロー
- 入力値
- 入力チェック
- DB参照テーブル
- DB更新テーブル
- 外部API・外部ファイル連携
- 権限チェック
- エラー処理
- ログ出力
- 画面/APIへの戻り値
- ソースから確実に分かること
- 推測であること
- 追加確認が必要なこと

まだ設計書は作らず、まず調査結果だけを出してください。"

調査結果を確認した後、次にこう指示します。

claude "上記の調査結果をもとに、基本設計書の形式でMarkdownにまとめてください。
ただし、推測事項は『要確認』として明記し、断定しないでください。"

詳細設計に落とす場合は、こうです。

claude "この機能を詳細設計書としてまとめてください。
メソッド単位で、処理内容、引数、戻り値、分岐条件、例外、DB操作、呼び出し先を表形式で整理してください。"

テスト仕様書まで起こすなら、こう使えます。

claude "復元した仕様をもとに、正常系・異常系・境界値・権限・DB更新確認を含むテストケースを作成してください。"

Claude Codeはテストやlintなど、検証できる手段を与えると精度が上がると公式ベストプラクティスでも説明されています。設計書復元でも、可能であれば既存テスト、実行ログ、画面キャプチャ、APIレスポンス、DBサンプルを合わせて確認させると、より実務に近い成果物になります。(Claude)

設計書を起こすときの注意点

Claude Codeを使っても、設計書復元は完全自動化すべきではありません。

理由はシンプルです。

ソースに書かれていることが、必ずしも本来の仕様とは限らないからです。

たとえば、以下のようなケースがあります。

過去の暫定対応がそのまま残っている
不要な分岐が消されずに残っている
バグなのに仕様のように見える
コメントが古い
DB定義と実装がズレている
画面仕様とAPI仕様がズレている
実際には使われていない処理がある

そのため、Claude Codeで設計書を起こすときは、必ず以下を入れるべきです。

ソースから確実に分かる仕様
動作確認で確認できた仕様
業務担当者に確認が必要な仕様
バグの可能性がある挙動
不要処理の可能性がある箇所

つまり、AIに設計書を作らせるのではなく、
AIで現行仕様を可視化し、人間が業務仕様として確定させるのが正しい使い方です。

仕様書がない現場ほど、Claude Codeは価値を出す

仕様書がない現場では、優秀なSEほど時間を奪われます。

「この処理、誰が分かる？」
「このテーブル、どこで更新されてる？」
「このフラグ、何に使ってる？」
「このバッチ、今も動いてる？」
「このif文、消していいの？」

こうした調査は、必要ですが、非常に重い。

Claude Codeを使えば、この重い初動を短縮できます。

もちろん、最終判断は人間です。
しかし、AIが一次調査・整理・設計書のたたき台作成まで行ってくれるだけで、SEの仕事は大きく変わります。

これからの保守開発では、
仕様書がないから分からないではなく、
ソースから仕様を起こし、設計書を再構築することが現実的になります。

そして、それができるSEは強いです。

なぜなら、単にコードを書けるだけではなく、
ブラックボックス化したシステムを読み解き、チームが扱える資産に変えられるSEだからです。

Claude Codeは、その力を大きく引き上げてくれます。

まとめ

Claude Codeで変わるのは、コードを書く速度だけではありません。

変わるのは、仕事の進め方です。

調査が速くなる
テストが増やせる
レビューの質が上がる
ドキュメントが残る
PR作成が楽になる
反復作業が減る
チームの標準化が進む
顧客価値に使える時間が増える

これからのSEに必要なのは、AIに仕事を奪われないように怯えることではありません。

AIを使って、
もっと良い設計をする。
もっと良い品質を出す。
もっと良い提案をする。
もっと顧客に喜ばれる仕事をする。

その方向に進むことです。

最後に

エスプリフォートは、AIを単なる流行として見ていません。

私たちが大切にしているのは、
AIを使って、誰にどんな価値を届けるのかです。

エスプリフォートの行動規範には、
「できない」と言わない、「できる方法」を考える。そして、チャレンジ精神を忘れない。
という考え方があります。

Claude CodeのようなAI開発ツールは、まさにこの考え方と相性が良い技術です。

できない理由を探すのではなく、
AIと一緒に、できる方法を探す。

ただコードを書くのではなく、
顧客に喜ばれる価値を創る。

一人で抱え込むのではなく、
仲間とノウハウを共有し、チーム全体で強くなる。

そんな働き方をしたいシステムエンジニアにとって、エスプリフォートはきっと面白い場所です。

AI時代に、ただ技術を使う人で終わるのか。
それとも、技術で価値を創る人になるのか。

エスプリフォートは、後者を目指す仲間を歓迎します。