この記事は 弁護士ドットコム Advent Calendar 2025 の 18 日目の記事です。
はじめに
こんにちは、契約マネジメントプラットフォームのクラウドサインでバックエンドエンジニアをしている筒井（@ktsu2i）です。2025 年 4 月に新卒として入社し、9 ヶ月が経ちました。
弊社では全社的に AI 活用を推進しており、Claude Code、Codex、Cursor、Devin などさまざまなツールを使って開発できます。これは非常に恵まれている環境である一方で、新卒エンジニアにとっては諸刃の剣になる可能性があります。
新卒研修を経て、部署に配属されたあとは他の先輩エンジニアと同様に現場で開発をしなければなりません。配属直後は配属部署での開発に慣れるため、小さめのタスクを与えてもらい、それをこなします。徐々にタスクの難易度も上がっていきますが、昨今の生成 AI のモデルの性能向上やツールの進化により、AI に完全に任せてしまってもそれなりの品質でこなせてしまいます。
このように自分自身が理解していないコードでも業務が回ってしまう問題があります。このようなやり方で業務を進めてもソースコードの理解が深まらず、エンジニアとしての成長を妨げてしまう懸念がありました。そこで配属されてから 5 ヶ月経った私が実践している、仕様駆動開発を少し自己流にアレンジした「オレオレ仕様駆動開発」を紹介します。
既存の仕様駆動開発のやり方と大きく変わるところはありませんが、私が仕様駆動開発を用いて開発する際に意識していることを言語化してみました。みなさんが開発する際に何かしらの参考になれば幸いです。
既存ツールを試してみた結果
私が配属された直後の 8 月に Kiro がリリースされました。すぐに社内でも利用可能になり、私も利用してみました。そこから spec-workflow-mcp を利用するようになり、ドキュメントとして実装計画をまとめながら開発を進めていく仕様駆動開発が私にはしっくりきたため活用していくことに決めました。
ですがタスクの抽象度が上がってきたタイミングで問題が生じました。私は AI に作ってもらった仕様書がどの程度正しいのか自分で判断できなかったのです。「なんとなく良さそう」や「とりあえず動いているから良いか」と思い、生成されたコードを十分に理解せずにプルリクエストを作成しレビュー依頼を投げてしまっていました。
そこでクラウドサインのソースコードをしっかりと理解し、エンジニアとして効率的に成長するため、自己流の仕様駆動開発へアレンジすることにしました。
前提
私がメインで使っているツールは Claude Code です。あえて外部ツールは使わず、Claude Code の Plan モードのみを使うことが多いです。クラウドサインではプロジェクト固有のルールが詳細に整備されており、社内の MCP サーバーでドキュメントにもアクセスできるため、この環境も活かしています。
またどうしても煮詰まってしまった場合は Codex をセカンドオピニオン的な感覚で使っています。現在はコードベースの理解も深まり、Opus 4.5 が登場したこともあって自分で判断できる場面が増え、Codex の利用頻度は下がりました。そして、ドキュメントを探してもわからないようなクラウドサイン事業や特有の仕様に関することは積極的に先輩エンジニアに聞くなどして、うまく AI を頼る場面と人を頼る場面を使い分けています。
オレオレ仕様駆動開発
他の仕様駆動開発のツールと同様に、作業リポジトリでドキュメントを一時的に保存するためのフォルダを作成し、以下のドキュメントを markdown ファイルとして出力させます。
- 調査書
- 実装計画
- タスク分解
ここからは、新規の API を実装するといったタスクを想定して、私がどのように仕様駆動開発を進めているのかを紹介します。
調査書
このフェーズでは既存コードを理解するための調査書を出力させます。既存コードに実装されている API がどのような構成で実装されているか詳細に調査してもらいます。その際に意識していることが以下の 2 点です。
- 全体像をシーケンス図などで出力させる
- 具体的なコードの場所（ファイルや行数）を出力させる
クライアントから API が呼ばれたときにどのような経路を辿るのか全体像を把握することでソースコード全体の理解を深めることができます。複雑な実装になっているものもあるため、私はシーケンス図で視覚的に理解するほうが合っていたため、このようなやり方で行っています。
また AI はハルシネーションがつきものなので私は必ず調査書が本当に正しいのかを調べます。その際に具体的なファイル名や行数まで出力させておけば、シーケンス図と組み合わせて、API が呼ばれたときに発火するメソッドや関数を順番に辿っていくことができます。間違いや疑問が生まれたらその都度 AI と壁打ちをして理解を深めていきます。
実装計画
既存コードへの理解が深まってきたところで実装計画を作っていくのですが、この時点でまずは自分でざっくりとした実装計画を頭に思い浮かべます。そして、実装したいものを具体的に説明し、あえて自分の実装計画は伝えずに実装計画を生成させます。これは生成された計画と自分の計画の差分を理解して、ちゃんとメリット・デメリットを判断できるように訓練するためです。最初は自分の考慮不足などの気づきがあるので非常に勉強になります。調査書の時と同様に疑問点や改善点があれば AI に伝えて議論し、より良い実装計画を作っていきます。
実装計画を練っていくうえでポイントなのが人間側から色んな提案をすることです。実装計画書を削除して再度 AI に作り直してもらっても良いですが、そこをあえて自分からこんな実装はどうかと問いを投げて筋の良い実装方針を一緒に考えていくことが大切だと感じました。
実際に私がタスクをこなす中で 8 割はこの実装計画を練る時間にあてていて、それによって既存のコードベースの理解や設計する力を鍛錬できています。
タスク分解
ここまで練ってきた実装計画をタスクの粒度に合わせて分解します。例えば、新規 API の実装で複数のサービスに変更を加えるなら、サービスごとにタスクを分解してチケット記載用の実装詳細を出力させます。そして、実装の詳細な手順としてのタスク分解も行います。
私の場合は、しっかり時間をかけて実装計画を作り上げていると実装自体はかなり早く終わります。また実装した後からエラーハンドリングを見直したりなど細部にこだわりたいときは、あらためて別の実装計画を作ってもらい壁打ちをすることもあります。
さいごに
新卒として早くソースコードの理解を深めつつ、開発スピードもできるだけ落とさず、業務を進めていくために私が仕様駆動開発で意識していることを言語化して紹介しました。
このやり方で大切な部分はあえて AI へ任せきらないことです。調査書を読んで既存コードを追い、実装計画を批判的にレビューし、自分の頭で考えるという繰り返しが成長につながります。同時に事業理解も深めていくことで、調査や実装計画のレビューの時間も短縮され、より早い開発サイクルを回せるようになるので日々精進します。
今後もさまざまな AI ツールや開発手法が登場するでしょう。その時々で自分が利用してメリットがあるか判断し、自己成長と開発スピードを両取りできるような最適なやり方で開発を進めていきます。
