はじめに
こんにちは。山一情報システム ビジネスデベロップメント部のmasudaです。
現在、社内ではClaude Codeを活用したシステム開発（AI駆動開発）に取り組んでいます。
今回はその事例として、これまでExcelマクロ（VBA）で管理していた受注管理業務をWebアプリケーションとして再構築した取り組みをご紹介します。
作成したアプリ
作成したWebアプリのイメージは次の通りです。
21画面の製造と単体テストを、2人で1ヶ月かからずに完了しました。従来の開発では考えられないスピードです。しかし、実際に作れてしまう。これがAI駆動開発の現実です。
技術スタック
| 領域 | 採用技術 |
|---|---|
| フロントエンド | React / TypeScript / Tailwind CSS 4 / TanStack Query・Table / React Hook Form + Zod |
| バックエンド | Python / FastAPI / SQLModel（SQLAlchemy 2）/ Alembic |
| DB・ストレージ | PostgreSQL（Amazon RDS）/ Amazon S3 |
| インフラ | EC2 + Docker Compose / nginx / ECR / Parameter Store |
| CI/CD | Gitea + Gitea Actions（ECR push → SSM 経由で自動デプロイ） |
| テスト | Pytest / Vitest + Testing Library / MSW / Playwright（E2E・アクセシビリティ検査） |
| 静的解析 | Ruff / ESLint / Bandit / pre-commit |
| AI | Claude Code Opus 4.8（rules ＝規約、skills ＝手順書） |
開発手法（仕様駆動開発）
AIの開発手法は「仕様駆動開発」を採用しました。
仕様駆動開発（Spec-Driven Development）は、実装の前にまず仕様書を明確な文書として作り込み、それを唯一の正解としてコードを生成・検証していく進め方です。
AI駆動開発では、この仕様書がAIへの指示そのものになるため、仕様の精度がそのまま成果物の品質を決めます。
事前に仕様書を作成し、それを基に以下の工程をAIが担当しています。
- コード生成
- コードレビュー
- 単体テストの作成・実施
- E2Eテストの作成・実施
工程そのものは従来の開発と変わりません。違うのは、コード生成やテストといった実作業を、AIという優秀な部下が引き受けてくれる点です。
AI駆動開発で重要なこと
毎日のようにClaude Codeと対話しながら開発を進める中で、AI駆動開発において特に重要だと感じているのは次の2点です。（他にも大切なことはたくさんありますが、その中でも影響が大きいと感じているものです）
曖昧な表現をどれだけなくせるか
仕様書に曖昧な表現があると、Claudeはそれを自分なりに解釈して実装を進めます。確認を求めてくることもありますが、何も聞かずに走り切ってしまうことも少なくありません。しかも、出来上がったコードは一見それらしく動くため、レビューまで気づかないこともあります。
例えば、こんな書き方です。
| 曖昧な指示 | Claudeの解釈が分かれるポイント |
|---|---|
| 「エラー時は適切にハンドリングする」 | 画面に出す？ログだけ？処理は継続する？中断する？ |
| 「一覧は見やすい順に並べる」 | 登録日順？更新日順？昇順？降順？ |
| 「必要に応じてバリデーションを行う」 | どの項目に、どんなチェックを入れるのか |
| 「大量データでも高速に動作すること」 | 何件を、何秒以内で処理するのか |
これを次のように書き換えるだけで、解釈のブレは軽減できます。
| 明確にした指示 |
|---|
| 「登録失敗時はトースト通知でメッセージを表示し、入力値は保持したまま画面に留まる」 |
| 「受注日の降順で表示する。同日の場合は受注番号の昇順」 |
| 「取引先コードは必須・半角英数8桁。未入力時は項目下に赤字でエラーを表示」 |
| 「10万件のデータで、一覧表示が3秒以内に完了すること」 |
ポイントは、「人間が読んで質問してきそうな箇所」は、Claudeも必ず解釈が割れるということです。曖昧な部分を潰す作業は、そのまま仕様書の品質向上につながります。
AIは間違える、それを前提に仕組みを作る
完璧な仕様書を用意しても、Claudeが仕様通りに作らないことがあります。指示した項目が抜けていたり、既存の実装と矛盾したコードを書いてきたり、単純に間違えることも普通にあります。
重要なのは、「AIは間違える」を前提に仕組みを作ることです。人間がすべての出力を目視で確認するのは現実的ではありません。間違いを人の注意力で防ぐのではなく、間違いが自動的に検出される状態を作っておく。これがシステムの品質を左右します。
山一情報システムでは、この考え方を開発プロセスに落とし込んだ「YISメソッド」の構築を進めています。AI駆動開発の進め方を手順として標準化し、社内で使いながら改善を重ねている段階です。
YISメソッドが目指しているのは、開発者がAIの使い方に迷わず、誰が担当しても同じ流れで開発が進む状態です。品質を個人のスキルに依存させないための仕組みでもあります。
とはいえ、実際の開発はAIとの対話の連続です。どれだけ手順が整っていても、AIに的確な指示を出せるかどうかは最後まで開発者自身にかかっています。設計の意図を言語化する力、仕様の曖昧さに気づく力、AIの出力が正しいかを判断する力。こうした力こそが、これからのエンジニアに求められていくのだと感じています。
仕組み作りのコツ
| 仕組み | 説明 |
|---|---|
| Rules | プロジェクト全体で常に守らせたい前提やコーディング規約を定義するもの |
| Skills | 特定の作業のやり方をまとめた手順書で、必要になったときだけ参照されるもの |
| Workflows | 複数の工程を一連の流れとして定義し、コマンド1つで実行できるようにしたもの |
この3つを整備するうえで、意識しておきたいことがあります。それは Claudeは渡した資料をすべて読むわけではない ということです。
仕様書やコードを読み込ませても、実際には全体に目を通していないことがよくあります。開発していても感じますし、Claude自身に確認すると「必要と判断した箇所だけを読んでいる」という回答が返ってきます。つまり、資料を渡した＝Claudeはすべてを把握している、ではありません。
1つの指示に詰め込みすぎない
これを踏まえると、情報を一箇所に集約するほど、読まれない部分が増えることになります。
やりがちなのが、Rulesにすべてを書き込んでしまうことです。規約も、画面の作り方も、テストの書き方も全部入れる。結果として分量が膨れ上がり、肝心な指示が埋もれてしまいます。
そうではなく、常に守らせたい最小限のルールだけをRulesに残し、作業ごとの手順はSkillsに切り出す。こうすることで、Claudeはその作業に必要な情報だけを確実に受け取れます。
工程を分け、必要な範囲だけを渡す
考え方は従来の開発と同じです。設計・実装・レビュー・テストと工程を分け、それぞれの工程で必要な資料と作業だけをAIに渡す。1回の指示で全部やらせようとしないことが、結果的に品質と速度の両方につながります。
役割を分けたAIに判断させる
AIは間違えます。AIのレビュー指摘が的外れだったり、問題ない実装に修正を求めてきたりすることは実際にあります。
そこで重要になるのが、役割ごとにエージェントを分けることです。
コードを書いたエージェントに自分のコードをレビューさせても、判断は甘くなります。自分の実装を前提に考えるため、そもそもの設計の誤りには気づけません。人間でも同じで、自分が書いたコードを自分でレビューしても見落とすのと変わりません。
今回の開発では、次のように役割を分けています。
| 役割 | 担当 |
|---|---|
| 実装 | 実装担当のエージェント |
| レビュー | 実装とは別のエージェント |
| 指摘の妥当性判断 | さらに別のエージェント |
ポイントは3段目です。レビューで挙がった指摘が本当に対応すべきものかを、別のエージェントに判断させます。
これによって、AIの思い込みによる不要な修正を防ぎ、本当に直すべき箇所だけが残ります。
やっていることは、従来の開発体制と同じです。実装者がいて、レビュアーがいて、最終的に判断する人がいる。その構造をそのままAIに持ち込んだだけです。
1体のAIを信頼するのではなく、複数のAIに異なる立場で判断させる。「AIは間違える」を前提にするというのは、こういう仕組みを作ることだと考えています。
終わりに
Claude Codeの進化は本当に速いです。
2026年7月24日に「Claude Opus 5」がリリースされましたが、あきらかに「Claude Opus 4.8」より賢いです。アウトプットの質を見ればわかります。
ただ「Claude Opus 5」よくしゃべる。しかも書いてあることが難しい。言い方が回りくどいんだよね。結論をわかりやすく教えてほしいのに（汗）
そんなClaude君と毎日対話しながら開発を行っています。