
業務システム開発、AI前提のチームに任せると何が変わる?divxのClaude Codeを活用した開発プロセスを公開
突然ですが、こんな悩みを感じたことはありませんか?
「システム開発を外注したいけど、費用が高くて踏み出せない…」
「AIで開発が早くなると聞くけど、実際どれくらい変わるの?」
「信頼できる開発パートナーを探しているけど、何を基準に選べばいいかわからない」
開発の中身って、発注する側からするとブラックボックスになりがちですよね。
「本当にAIを使いこなせているの?」「コスパはいいの?」って、正直気になるところだと思います。
私たちdivxでは、業務システムの開発にClaude Codeを全面導入し、開発プロセスそのものを刷新しました。
この記事では、その実態を包み隠さずお伝えします。
「こんな開発チームに任せたい」と思ってもらえたら嬉しいです。
こんな方に読んでほしい:
- システム開発の外注を検討している経営者・事業担当者
- AI時代の開発会社がどう変わっているか気になる人
- 費用対効果の高い開発パートナーを探している人

開発体制はどう変わったのか
まずは「何が変わったのか」をざっくりお伝えします。
工程 | Before | After |
|---|---|---|
設計 | 人 | 人 + Claude Cod |
実装 | 人 | Claude Code |
レビュー | 人 | 人 + Claude Code |
テスト | 人 | 人 + Claude Code |
デバッグ | 人 | 人 + Claude Code |
一番大きな変化は、「コードを書く人」から「設計・レビュー・判断する人」に役割がシフトしたことです。
設計だけは変わらず人間の仕事です。でもそれ以降の工程は、Claude Codeと分担しながら進めるスタイルに変わりました。
最初は「本当に任せて大丈夫?」と半信半疑でしたが、今では実務に完全に定着しています。
実務で特に効いた3つの仕組み
ただツールを導入するだけでは、正直あまり変わりません。
「どう使うか」の設計が、成果物の質を左右します。
実際に効果があった仕組みを3つ紹介します。
① CLAUDE.md ― AIにプロジェクトの「前提知識」を渡す
Claude Codeには、プロジェクトのルートに CLAUDE.md というファイルを置くことで、AIに「このプロジェクトの前提」を共有できます。
私たちのプロジェクトでは、こんな情報を記載しました。
- ドメイン用語集
- コーディング規約
- アーキテクチャの方針
効果は絶大で、毎回「この用語はこういう意味で…」と説明しなくても、AIが文脈を踏まえたコードを提案してくれるようになりました。
ドメイン知識が豊富なプロジェクトほど、この仕組みが刺さります。
② スキルシステム ― 定型作業をコマンド化する
繰り返し発生する作業は、独自スキル(カスタムコマンド)として定義しました。
たとえば:
/commit← コミットメッセージを自動で整えて commit/e2e-test-guide← E2Eテストの手順を自動でガイド
複雑な手順も「1コマンド」で起動できるので、作業の品質が安定して属人化が減ります。
「毎回同じ手順をAIに説明している」と感じている人は、それをスキルとして定義するだけで一気に楽になります。
③ エージェント分業 ― 専門性で分けて並列実行
「1つのAIに全部やらせる」ではなく、目的別にエージェントを分けて並列で走らせるのがポイントです。
- DB設計専用エージェント
- フロントエンドUI専用エージェント
- リファクタリング専用エージェント
調査タスクと実装タスクを並列で進めることで、待ち時間が減り、1人でも複数の専門的な作業を同時に進められるようになりました。
チームの人数が少ない開発現場ほど、この分業モデルは効きます。
正直に話す:うまくいかなかったこと
良いことばかり書いても参考にならないので、失敗談もシェアします。
① AIに丸投げすると「動くけど意図と違う」コードが出る
最初のうちは指示が曖昧なまま投げてしまって、「確かに動いてるけど、自分がやりたかったことじゃない…」というコードが何度か出てきました。
② コンテキストが長くなると精度が落ちる
会話が長くなるにつれて、AIが初期の意図を忘れたようなコードを出してくることがありました。
タスクをこまめに区切って、コンテキストをリセットするのが有効です。
③ 700行超のファイルで監視性が低下した
大きなファイルをそのままAIに渡すと、変更の追跡が難しくなり、「どこを触ったのか」がわからなくなる場面がありました。
学びをひとことで言うと:「AIへの指示の質 = 成果物の質」
これに尽きます。曖昧な指示をすれば、曖昧なコードが返ってくる。それはAIのせいではなく、指示する側の問題です。
発注する側が知っておくべき「AIと人の役割分担」
「何でもAIに任せればいい」というわけではありません。
実務を通じて感じた、「AIに任せてよいこと」と「人が握るべきこと」を整理しました。
AIに任せてよいこと:
- 定型的な実装
- リファクタリング
- テストコードの生成
- コミットメッセージの整形
人(開発チーム)が握るべきこと:
- お客様のビジネス・業務ドメインの理解
- 設計の意思決定
- 品質の最終判断
発注側にとって重要なのは、「AIを使いこなす技術力」と「ビジネスを理解する力」の両方を持つチームに任せることです。ツールだけ持っていても、業務を理解していなければ的外れなシステムができあがってしまいます。
まとめ:AI時代の開発は「やることが変わる」のであって「楽になる」だけじゃない
AI導入の話をすると「開発が早くなるんでしょ?」と言われることが多いのですが、正確には「できることの質と量が変わる」という感覚に近いです。
- コードを書く速度より、正しい設計判断を速くすることが価値になる
- AI前提の開発プロセスは、「どう使うかの構造設計」がカギ
- ツールを入れるだけでなく、業務ドメインを理解した上で使いこなすことが本質
ただ「AIを使っています」と言うのは簡単ですが、実務で成果につなげるには、今回紹介したような仕組みづくりが必要です。
divxなら、こういう開発を最初からやっています
ここまで読んでいただいてありがとうございます。
正直にお伝えすると、この記事で紹介した取り組みは、divxが実際のお客様のシステム開発で日々やっていることです。
- CLAUDE.mdでお客様のビジネスドメインをAIに理解させる
- スキルシステムで品質を安定させる
- エージェント分業で開発スピードを上げる
「最新のAI開発手法を使ってほしいけど、自社に開発チームがない」
「外注コストを抑えながら、質の高いシステムを作りたい」
「信頼できるパートナーに任せて、自分たちは本業に集中したい」
そんな方は、ぜひdivxにご相談ください。
AI前提の開発プロセスで、スピーディかつ丁寧にお手伝いします。


