こんにちは!ライトウェア採用担当です。
近年、システム開発で導入が進んでいるAI。
本日はその中でも、Claude Codeについて当社のエンジニアが使ってみましたので、その他のツールとの違いや、何がすごいのか?サクッとお伝えしたいと思います!
近年、システム開発で導入が進んでいるAI。
本日はその中でも、Claude Codeについて当社のエンジニアが使ってみましたので、その他のツールとの違いや、何がすごいのか?サクッとお伝えしたいと思います!
この記事を書いた人
名前:O
入社年:2025年
名前:O
入社年:2025年
自己紹介
直近は建設業者向けシステムの再構築案件に参画。
開発言語はC#で、現場ではAIツールとしてGitHub Copilotを使用していました。
開発言語はC#で、現場ではAIツールとしてGitHub Copilotを使用していました。
今回作ったもの:個人開発のタスク管理アプリ
Claude Codeを使った工程:詳細設計(仕様書の壁打ち)〜製造
↓ ↓ できあがったアプリがこちら ↓ ↓
↓ ↓ できあがったアプリがこちら ↓ ↓
Claude Codeとは?
Anthropic社が開発した、ターミナル(コマンドライン)上で動くAIアシスタントです。
チャットで指示するだけで、ローカルのファイルを読み込み、コードの修正・テスト・Gitへのコミットまでを自律的にやってくれます(エージェント機能)。
チャットで指示するだけで、ローカルのファイルを読み込み、コードの修正・テスト・Gitへのコミットまでを自律的にやってくれます(エージェント機能)。
他のAI開発ツールとの違い
現場で使っていたGitHub Copilotは「今書いている行の続き」を提案してくれる補完型のツール。
定型コードを書く速度は上がりましたが、複数ファイルにまたがる修正では結局自分で全体を組み立てる必要がありました。
Claude Codeはそこが違いました。プロジェクトのフォルダごと読み込み、タスク単位の指示で複数ファイルの修正からテスト実行までこなす、エージェント型のツールです。
現役エンジニアが実際に使ってみた!ここが凄かったポイント
最初は「バイブコーディング」で挑戦… まずはバイブコーディング——細かい設計を決めず「こんな感じの機能を作って」と雰囲気(Vibe)で指示し、出力を見ながらその場で直していくスタイル——で開発を始めました。
定型コードを書く速度は上がりましたが、複数ファイルにまたがる修正では結局自分で全体を組み立てる必要がありました。
Claude Codeはそこが違いました。プロジェクトのフォルダごと読み込み、タスク単位の指示で複数ファイルの修正からテスト実行までこなす、エージェント型のツールです。
現役エンジニアが実際に使ってみた!ここが凄かったポイント
最初は「バイブコーディング」で挑戦… まずはバイブコーディング——細かい設計を決めず「こんな感じの機能を作って」と雰囲気(Vibe)で指示し、出力を見ながらその場で直していくスタイル——で開発を始めました。
最初の数機能は驚くほど速く形になりました。ところが機能が増えると雲行きが怪しくなります。
指示のたびに設計が微妙にブレる、直したはずの箇所がまた壊れる…。
動くけれど、自分でも全体像を説明できないコードが積み上がっていきました。
「スペック駆動開発」に切り替えたら真価を発揮!
そこで進め方をスペック駆動開発(Spec-Driven Development)に変えました。
実装の前にまず仕様(スペック)を文書として固め、AIにはその仕様書に沿って実装させるやり方です。
要件・画面の挙動・データ構造をMarkdownにまとめてから依頼するようにしたところ、体感が一変。
設計が最後までブレず、複数ファイルにまたがる実装も一貫した作りで進み、「仕様書のこの記述と実装がズレています」と逆に指摘されたときは正直ちょっと悔しかったです(笑)。 仕様を書く時間は増えますが、手戻りが激減するのでトータルでは圧倒的に速い。
「仕様を書けば書くほどAIの精度が上がる」という好循環を実感しました。
まとめ
使ってみて一番感じたのは、Claude Codeは「言語化した分だけ返ってくる」ツールだということです。
雰囲気で指示すれば雰囲気なりの、仕様を固めて渡せば仕様どおりの成果が返ってきます。 だからこそ、個人開発なら試行錯誤のコストが低いので、どんどん任せて良いと思います。
一方チーム開発では、AIが書いたコードもチームの資産になる以上、設計の意図が共有されないまま任せすぎるのは危険です。
ただ面白いのは、その共有の器になるのがまさに仕様書だという点。
「AIへの指示を言語化すること」と「チームの意思を統一すること」は、実は同じ行為なんです。
「コードを書く速さ」より「仕様を正確に言語化する力」が価値になる——それを肌で感じた体験でした。
雰囲気で指示すれば雰囲気なりの、仕様を固めて渡せば仕様どおりの成果が返ってきます。 だからこそ、個人開発なら試行錯誤のコストが低いので、どんどん任せて良いと思います。
一方チーム開発では、AIが書いたコードもチームの資産になる以上、設計の意図が共有されないまま任せすぎるのは危険です。
ただ面白いのは、その共有の器になるのがまさに仕様書だという点。
「AIへの指示を言語化すること」と「チームの意思を統一すること」は、実は同じ行為なんです。
「コードを書く速さ」より「仕様を正確に言語化する力」が価値になる——それを肌で感じた体験でした。
