業務システム設計を教材化して分かったこと
この記事は、AI（GitHub Copilot Business）を設計業務に実際に投入し、
「どこまで任せられて、どこから人間が判断すべきか」を
業務システム設計の教材化を通じて整理した記録です。
本記事の内容および掲載しているリポジトリは、
すべて個人の学習・整理目的で、
個人の時間および個人負担により作成したものです。
所属企業・過去の業務・実案件とは一切関係ありません。
登場する業務システムや要件はすべて架空のものです。
はじめに（AIの使い方について）
最初に前提として書いておきますが、
この記事自体も含め、設計・文章作成の過程でAIを積極的に利用しています。
ただし、いわゆる
- AIに全部書かせている
- 思考や判断を丸投げしている
という使い方ではありません。
AIは、
- 設計書や文章の叩き台を出す
- 観点を洗い出す
- 判断理由を言語化する補助をする
ための道具として使い、
最終的な設計判断・構成・取捨選択はすべて人間が行っています。
今回作成した設計書テンプレートやサンプルシステムも、
AIを使いながらではありますが、
「なぜこの設計にしたのか」
「どこで判断しているのか」
という部分は、人間が責任を持って決めています。
その前提のもとで、以下の内容を書いています。
この記事について
業務システムの設計を整理するために、
個人用の 設計書テンプレート と サンプルシステム を作り始めました。
途中から AI（GitHub Copilot Business） を本格的に併用していますが、
使い続けて感じた結論はこれです。
AIは設計を代わりにやってくれる存在ではない。
設計判断を高速化するための道具である。
この記事では、
- 実際に使ったAI環境
- モデルごとの「思考の癖」
- なぜ設計そのものは人間が握るべきなのか
を、実体験ベースでまとめています。
使用したAI環境
今回の作業で使用した構成は以下です。
- GitHub Copilot Business
- 利用形態：CLI中心
- 主に使ったモデル：
- GPT‑4.1
- GPT‑5.4
- Claude Opus 4.6（全体レビュー用）
加えて、相談役として以下も併用しています。
-
Copilot Chat
- Microsoft 365 Business Standard 付属
- 設計方針の壁打ち・論点整理用途
リクエスト消費の実態
プレミアムリクエストの消費は想像以上でした。
- 配布量：月300リクエスト
- 3月・4月ともに 約3日で全消費
- 3月は追加で 200リクエストを課金
設計用途では、
- 長文のやり取り
- 設計判断の往復
- 設計書全文の確認
が多く、消費はかなり早いという印象です。
GPT‑4.1を使っていた4ヶ月間の停滞
GPT‑4.1をメインで使っていた期間は、
設計作業が 4ヶ月ほど停滞 しました。
GPT‑4.1の挙動
- 全体構造や整合性を考慮せずに案を出す
- その場の文脈だけで思いつき案を出す
- 前後の設計判断と平気で矛盾する
結果として、
- 局所的にはそれっぽい
- 積み上げると破綻する
- 人間側が常に「整合性調整役」になる
感覚的な例え
技術に強い1〜2年目エンジニア
という印象でした。
GPT‑5.4にしたら20日で一気に進んだ理由
GPT‑5.4に切り替えてから、
設計作業は 約20日で形になりました。
GPT‑5.4の特徴
- 直前の設計判断を参照しようとする
- 設計トレードオフを言語化しようとする
- 判断理由を説明しに来る
印象
技術に強い3〜5年目エンジニア
議論の相手として成立し、
設計を前に進める推進力がありました。
また、サンプルアプリの設計から実装まで一気通貫で任せられます。
Claude Opus 4.6の役割
Claudeは 全体レビュー専用 です。
- 粒度のばらつき
- 説明の抜け
- 教材として読めるか
を確認する視点として優秀でした。
AIでできたこと
- 設計書の叩き台作成
- 観点洗い出し
- 言語化補助
- 文書整理
特に、
- 履歴設計
- Command / Query の責務整理
- 設計ポリシー文章化
は、初速を出す道具として有効でした。
それでも設計判断は人間がやる
AIに任せられなかったのは、
- 履歴を取る／取らない判断
- Command粒度の線引き
- DRYを「概念」で守る判断
- 教材としての取捨選択
など、説明責任を伴う判断です。
今回作ったもの
設計書テンプレート
サンプルアプリ（架空ドメイン）
※ 実案件とは一切関係ありません。
まとめ
AIを使って分かったことは単純です。
- 設計は速くなる
- 作業は楽になる
- でも思考責任は減らない
AIは設計を代行しない。
設計者の判断を加速させるだけ。
設計の価値は、
判断理由を言語化できることにあると再認識しました。
誰かの参考になれば幸いです。
付記：要件定義・設計・実装における人間の関与について
補足として書いておきますが、
今回作成した設計書テンプレートおよびサンプルアプリについては、
- 要件定義
- 設計
- 実装
の一連の流れにおいて、
人間が直接コードを書いた箇所はほとんどありません。
実際には、
- 要件や設計方針の決定
- 設計上の判断（粒度・責務・境界）
- 採用／不採用の判断
- 全体構成・最終レビュー
といった 判断責任の部分のみを人間が担当し、
文書生成や実装作業そのものについては
AI（GitHub Copilot Business / CLI）を前提として進めています。
いわゆる「自動生成に任せきり」という形ではなく、
判断は人間、作業はAI
という役割分担を意識した結果として、
ほぼ手を動かさずに要件定義から実装までを通す形になりました。
この点は、人間の関与を減らすことを目的としたものではなく、
設計判断そのものに集中するための手段として
意図的にそうしています。