0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@singulaTeam Coffee

連載：AI時代のSE・プログラマのためのAI壁打ち実践入門 第3回　実装前にAIと設計レビューするための壁打ち手順

0
Posted at

実装前にAIと設計レビューするための壁打ち手順

連載：AI時代のSE・プログラマのためのAI壁打ち実践入門
全5回 ｜ 第3回 / 5

この連載は、AIを「答えを出す機械」ではなく、「前提を掘り、選択肢を増やし、判断を検証する相棒」として使うための実践シリーズです。

はじめに

実装を始めた後で、設計のまずさに気づくことはありませんか？

「動くものはできたが、機能を追加しようとしたら構造が破綻した」
「後から振り返ると、別の方法の方がよかった」
「なぜこの設計にしたのか、自分でも思い出せない」

前回の記事では、曖昧なアイデアを要件に変える壁打ちテンプレートを紹介しました。今回は、要件が固まった後の設計フェーズで、AIとどう壁打ちするかを扱います。

この記事で扱うこと

  • 設計で壁打ちが有効な理由
  • 設計案の比較テンプレート
  • 過剰設計を防ぐ壁打ちの型
  • ADR（Architecture Decision Record）への変換
  • 壁打ちの実例（「通知機能のアーキテクチャ選定」を題材に）

結論

先に結論を書きます。

設計の壁打ちは、AIに唯一の正解を決めさせる作業ではありません。以下を見える化するための作業です。

見える化するもの 効果
選択肢 「他にもやり方がある」ことに気づける
トレードオフ 各案のメリット・デメリットが整理される
前提 暗黙の前提が明示される
リスク 将来の変更で破綻しそうな箇所が見える
判断の根拠 なぜその設計にしたか記録が残る

設計判断を「記録して残す」ことが、個人開発でもチーム開発でも、後から最も価値を持ちます。

なぜ設計で壁打ちが有効なのか

設計で壁打ちが特に有効な理由は、設計には唯一の正解がないからです。

要件定義では「何を作るか」を決めますが、設計では「どう作るか」を決めます。「どう作るか」には常に複数の選択肢があり、どれが最適かは前提・制約・将来の変化によって変わります。

一人で考えると、最初に思いついた案に固執しやすくなります。AIに壁打ちすることで、別の選択肢やリスクが見えてきます。

よくある失敗例

悪い例

通知機能の設計をしてください。

AIはそれっぽい設計を返しますが、以下の問題があります。

  • 自分のプロジェクトの制約（技術スタック、チーム規模、運用体制）が反映されていない
  • 一般的な「模範解答」になりがちで、過剰設計になることがある
  • なぜその設計なのか、判断の根拠が残らない

設計壁打ちで有効な3つの型

型①：設計案比較型

複数の設計案を並べて比較するための型です。

以下の機能について、設計案を比較してください。

機能：
- ユーザーへの通知機能（承認依頼、処理完了、エラー通知）

前提：
- Python + FastAPI で構築中
- ユーザーは自分1人（個人開発）
- 将来的にチームで使う可能性がある

制約：
- 外部サービスの月額費用は1,000円以下
- 実装期間は3日以内
- 運用負荷は最小にしたい

候補案：
A: メール通知（SendGrid等）
B: Slack Webhook
C: ブラウザプッシュ通知（Web Push API）

出力形式：
| 案 | 概要 | メリット | デメリット | 実装コスト | 保守性 | 採用すべき条件 |

型②：過剰設計チェック型

自分の設計案が「やりすぎ」になっていないかレビューさせる型です。

この設計案が過剰設計になっていないかレビューしてください。

現在の設計案：
{設計案の概要}

プロジェクトの前提：
- ユーザー数：当面1人（個人利用）
- 開発体制：1人
- 運用期間：まず3ヶ月試す

観点：
- 現時点で不要な抽象化がないか
- 将来の可能性を広げすぎていないか
- 小さく始める代替案はあるか
- 変更しやすさと実装コストのバランスは妥当か
- 「今必要なもの」と「あると便利なもの」を分離できるか

型③：ADR生成型

設計判断の結果を、ADR（Architecture Decision Record）として記録する型です。

以下の設計相談の結果をADRに変換してください。

相談内容：
{壁打ちの要約}

採用した案：
{採用案}

却下した案：
{却下案とその理由}

ADR形式：
# ADR: {設計判断のタイトル}

## ステータス
提案中 / 採用 / 却下 / 保留

## 背景

## 決定

## 代替案

## 理由

## 影響

## 未解決事項

ADRを書いておくと、「なぜこうなっているのか」を後から自分やチームメンバーが確認できます。

壁打ちの実例：「通知機能のアーキテクチャ選定」

前回の記事で要件を整理した「個人用AIタスク管理ツール」に、通知機能を追加する場面を想定します。

壁打ちの入力

あなたには設計レビュー役として壁打ちに参加してほしいです。

目的：
- AIタスク管理ツールに通知機能を追加する設計を決めたい

背景：
- 承認待ちタスクの見逃しが課題だった（前回の要件定義で判明）
- ツールはPython + FastAPIで構築中

制約：
- 外部サービスの月額費用は無料〜1,000円以内
- 実装は2日以内で終わらせたい
- 個人利用がメイン。将来チームで使う可能性はある

候補案：
A: Slack Webhook で通知
B: メール通知（SendGrid Free Tier）
C: Discordの Webhook で通知

判断基準：
- 実装の簡単さを最優先
- 無料で始められること
- 将来の拡張（複数通知先の追加）に耐えられること

お願い：
1. 各案を比較表で出してください。
2. 私の前提に抜け漏れがないか指摘してください。
3. 採用すべき案を条件付きで提案してください。
4. ADRの下書きを作ってください。

AIの回答（要約）

🤖 AI（設計レビュー役）:

比較表：

案 実装コスト 月額費用 通知到達性 拡張性 採用すべき条件
A: Slack Webhook ◎ 低い 無料 ○ 即座 ○ 他チャンネル追加可 普段Slackを使っている場合
B: SendGrid ○ 中程度 無料枠あり △ 遅延あり ◎ 複数宛先対応 メールでの通知を好む場合
C: Discord Webhook ◎ 低い 無料 ○ 即座 △ ビジネス利用しにくい 個人開発で完結する場合

前提への指摘：

  • 「通知」の粒度が未定義。すべてのステータス変更で通知するのか、承認待ちだけか？
  • 通知が届かなかった場合のフォールバックが考慮されていない
  • 将来チームで使う場合、Discordはビジネス用途には不向きな印象がある

条件付き提案：

  • 個人利用かつSlackを日常的に使うなら → A: Slack Webhook
  • 通知先の柔軟性を重視するなら → 通知インターフェースを作り、最初の実装はSlackにする

ADR下書き：

# ADR: 通知機能の配信チャネル選定

## ステータス
採用

## 背景
承認待ちタスクの見逃し防止のため通知機能を追加する。

## 決定
Slack Incoming Webhook を使用する。

## 代替案
- SendGrid（メール）: 実装コストが高く、個人利用にはオーバースペック
- Discord Webhook: 将来チーム利用時にビジネス感が弱い

## 理由
実装コスト最小、無料、個人で日常利用しているため到達確認が容易。

## 影響
Slackに依存する。将来の通知先追加時は抽象化が必要。

## 未解決事項
- 通知対象の粒度（全ステータス変更 or 承認待ちのみ）
- 通知失敗時のフォールバック

この壁打ちから得られた気づき

  1. 通知の粒度を決めていなかった：「通知する」とだけ決めて、「いつ通知するか」を定義していなかった
  2. フォールバックの欠如：通知が届かない場合の対策を考えていなかった
  3. 将来の拡張方針が明確になった：最初はSlackで始め、拡張が必要になったら抽象化する
  4. ADRとして記録が残った：判断根拠と却下理由が残るため、後から見返せる

設計壁打ちの流れ

設計の壁打ちは、以下の流れで進めると安定します。

ポイントは、条件付きで判断することです。「Aが最良」ではなく「Xの条件ならA、Yの条件ならB」と整理すると、前提が変わったときに判断を見直せます。

実務投入時の注意点

  • AIの設計提案をそのまま採用しない: AIは一般的なベストプラクティスを提案するが、自分のプロジェクトに合うとは限らない。特にチーム規模やスキルセットは、AIに伝えないと反映されない。
  • 過剰設計に注意する: AIに設計を聞くと、高度な設計パターンを提案されることがある。「今の規模に必要か」を常に問い直す。
  • 設計判断は記録する: ADRは完璧でなくてよい。「何を選んで、何を捨てて、なぜそうしたか」の3点が残っていれば十分。
  • 機密情報を入れない: 社内システムの設計を壁打ちする場合、具体的なサービス名・テーブル名・API仕様を匿名化してから渡す。

チェックリスト

設計の壁打ちを行う前に、以下を確認してみてください。

  • 候補案を2つ以上用意したか
  • 各案のメリット・デメリットを整理したか
  • プロジェクトの前提（規模、チーム、期間）をAIに伝えたか
  • 過剰設計になっていないか疑ったか
  • 「今必要」と「将来あると便利」を分離したか
  • 判断の根拠をADRとして残す準備があるか
  • 採用しなかった案の理由を記録したか

まとめ

設計の壁打ちは、AIに最適な設計を決めてもらう作業ではありません。選択肢を並べ、トレードオフを整理し、判断の根拠を記録する作業です。

今回の記事で紹介した内容を振り返ります。

  • 設計には唯一の正解がない — だからこそ壁打ちで選択肢を見える化する
  • 3つの型（設計案比較型・過剰設計チェック型・ADR生成型）で壁打ちが安定する
  • ADRに記録することで、設計判断が知的資産になる
  • 条件付きで判断することで、前提が変わっても対応できる

次回予告

次回は、AIに丸投げしないコードレビュー・デバッグ壁打ち術を扱います。

「AIが出したコードをそのまま信じてバグを埋め込んだ」「エラーを貼っても場当たり的な回答しか出ない」という悩みに対して、AIを安全に使う壁打ちの手順を紹介します。

この記事では、AIの回答をそのまま正解として扱うことは推奨しません。
実務利用時は、機密情報を入れないこと、出力を検証すること、必要に応じて人間が判断することを前提にしています。

連載一覧

  1. AIとの壁打ちは「質問」ではなく「思考プロセス設計」である
  2. 曖昧なアイデアを要件に変えるAI壁打ちテンプレート
  3. 実装前にAIと設計レビューするための壁打ち手順 ← 今回
  4. AIに丸投げしないコードレビュー・デバッグ壁打ち術
  5. AIとの壁打ちログをナレッジ化してポートフォリオに変える
0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?