この工程は何をするのか
IT パスポート試験シラバス Ver.6.5 の「25. システム開発技術」は、設計をこう置いている。
② 設計 ・システム設計，ソフトウェア設計などがあること，及びそれぞれの基本的な役割 用語例 機能設計，詳細設計
要件（何をしたいか）を、実装できる指示（どう作るか）に変える工程。 大きく2段階ある。
| 段階 | 決めること | 別名 |
|---|---|---|
| システム設計 | 全体をどんな部品に分けるか、部品同士がどうつながるか | 機能設計・外部設計 |
| ソフトウェア設計 | 各部品の中をどう作るか | 詳細設計・内部設計 |
境目の目安は、利用者から見えるかどうか。画面の並びや帳票の形はシステム設計、その裏の処理手順はソフトウェア設計に入る。
具体的な成果物
| 成果物 | 中身 |
|---|---|
| システム設計（機能設計） | 機能の分割、画面・帳票、他システムとのつなぎ方、データの持ち方 |
| ソフトウェア設計（詳細設計） | 各機能の処理手順、扱うデータの形、異常時の振る舞い |
つまずきやすいところ
設計を飛ばして作り始めると、部分ごとには動くが噛み合わないものができる。 特に複数人で分担するとき、つなぎ目の取り決め（何を渡して何が返るか）が無いと、結合するときに全部直すことになる。
異常時の振る舞いを書き忘れる。 正常に動く道筋だけ設計して、入力が空だったとき・通信が切れたとき・二重に押されたときを決めていないと、実装者ごとにばらばらの判断が入る。
AI に任せられる範囲
調査から設計案の文書化まで
Gemini CLI の Plan Mode は、実装前に調査し、トレードオフを評価し、合意してからコードに触る read-only の環境として作られている（facts/gemini-cli/plan-mode.md）。設計の進め方とそのまま重なる。
- 合意できたら、詳細な実装計画を Markdown ファイルとして書き出す
Ctrl+Xで外部エディタを開いて人が手を入れると、保存時に変更を自動検出し、コメントを読んで戦略を調整したうえで再提示する- auto モデルを使っているとき、Plan Mode 中は高推論の Pro モデルへルーティングされる。 計画が承認されて Plan Mode を抜けると、高速な Flash に切り替わる
3つめは設計工程の性質に合っている。考える場面では時間をかけ、書く場面では速く動くという配分が既定で入っている。
検討を分けて進めるところ
Claude Code の subagent は、専用のコンテキストウィンドウで処理し、結果の要約だけをメイン会話へ返す（facts/claude-code/sub-agents.md）。独自のシステムプロンプト・ツールアクセス・権限を持てる。
設計では、調べもの（既存の実装がどうなっているか）と、判断（ではどう作るか）を分けたい場面が出る。調べものを別のコンテキストに追い出し、要約だけ受け取ると、判断する側の文脈が調査ログで埋まらない。
まだ人がやること
分け方を決めること。 どこで機能を切るかは、あとで誰がどこを直すことになるかという予測に基づく判断で、コードの中には答えが無い。
将来の変更を見込むこと。 「ここは半年後に制度が変わる」という情報は業務側にしか無い。変わる場所を変えやすく作るという判断は、その情報が無いとできない。
設計を決定として残すこと。 Plan Mode の計画ファイルは、既定ではプロジェクト外の一時ディレクトリ（~/.gemini/tmp/<project>/<session-id>/plans/）に置かれ、セッションは既定で30日後に自動削除される（facts/gemini-cli/plan-mode.md）。設計として残すつもりなら、人がリポジトリ側へ移す必要がある。
ai_leverage を medium にしているのはこのため。案を出して書き下ろす作業は任せられるが、分け方を選ぶ判断と、残す判断が人に残っている。