03-03 制約・前提条件。暗黙の前提を発見し、明文化する演習。
暗黙の前提を発見し、明文化する演習です。
所要時間: 約 45 分
前提: /learn-ie-analyze（03-01）完了済み
スキル対応: Intent Engineering（目的と判断基準）
「プロジェクトには『誰も言わないが全員が前提にしていること』があります。
これを明文化しないと、AI は間違った前提で動きます。
例えば:
- 『ユーザーは日本語話者のみ』を書かないと → AI が多言語対応を始める
- 『データ量は 10 万件以下』を書かないと → AI が大規模最適化を始める
- 『ネットワークは常時接続』を書かないと → AI がオフライン対応を始める
暗黙の前提を明文化することは、Intent Engineering の核心です。
『何をやらないか』を伝えることで、AI の判断に方向性を与えます。」
まず、受講者のプロジェクト情報を確認する。
発掘に入る前に、2 つの分類を理解する。
| 種類 | 定義 | 例 |
|---|---|---|
| 前提条件 (assumption) | 真だと仮定しているが、変わる可能性がある | 「月間アクティブユーザーは 1000 人以下」 |
| 制約条件 (constraint) | 変えられない外部条件 | 「AWS 上で動作すること」「予算は月 5 万円以内」 |
判断基準: 迷ったら「その条件は 自分たちの意思で変更できるか？」で考える。変更できるなら前提条件、できないなら制約条件。
目標: 前提条件を 3 つ以上、制約条件を 2 つ以上 発掘する。
「このプロジェクトで『当たり前すぎて書かない』ことは？」
「チームの新メンバーが誤解しそうなことは？」
「変わったら大きな影響がある暗黙の条件は？」
受講者が詰まった場合: プロジェクトの技術スタック・対象ユーザー・規模から逆算して、具体的な候補を 2〜3 個提示してヒントを出す。例:「Next.js を使っているなら、『SSR/SSG どちらを前提とするか』『Node.js ランタイムのバージョン制約』などはありませんか？」
| 暗黙の前提 | 明文化しないと... |
|---|---|
| 「ユーザーは日本語話者のみ」 | AI が多言語対応を実装する |
| 「ネットワークは常時接続」 | AI がオフライン対応を検討する |
| 「データ量は 10 万件以下」 | AI が分散処理を提案する |
| 「チームは 3 名以下」 | AI が大規模チーム向けのプロセスを提案する |
| 「MVP フェーズである」 | AI がスケーラビリティを過度に重視する |
受講者が前提・制約を洗い出したら、各項目に対して以下の観点でフィードバックする:
フィードバックを踏まえて、受講者に項目の修正・追加を促す。
分類した前提条件と制約条件を ProjSight に登録する。
補足:
upsert_assumption/upsert_constraintは admin プロファイルのツールです。学習環境では利用可能です。本番では admin/owner ロールのメンバーが管理します。
upsert_assumption と upsert_constraint はパラメータ構造が異なる。登録前に確認する。
| ツール | テキストフィールド | 説明 |
|---|---|---|
upsert_assumption | description（1フィールド） | 前提の説明をすべて description に Markdown で記述する |
upsert_constraint | category + description（2フィールド） | category に制約の分類、description に詳細を Markdown で記述する |
前提条件は時間の経過とともに変わる可能性がある。登録時に reviewBy を設定し、定期的に見直す仕組みを作る。
前提条件の登録例:
upsert_assumption(
projectId: "<projectId>",
description: "月間アクティブユーザーは1000人以下\n\n## 根拠\n- 現在の登録ユーザー数は約200名\n- MVP フェーズのため急激な増加は想定しない\n\n## 影響範囲\n- DB設計（インデックス戦略）\n- キャッシュ戦略\n- インフラのスケーリング方針\n\n## 崩れた場合\nパフォーマンス最適化・DB分割の検討が必要",
reviewBy: "2026-07-01"
)
制約条件の登録例:
upsert_constraint(
projectId: "<projectId>",
title: "AWS 上で動作すること",
body: "## 背景\n- 社内の運用チームが AWS のみ対応可能\n- 既存システムとの連携が AWS サービス前提\n\n## 影響範囲\n- インフラ設計の全体\n- CI/CD パイプライン\n- 監視・ログ基盤の選定"
)
前提条件 3 つ以上、制約条件 2 つ以上を登録する。各登録後、ProjSight の応答を確認する。
「暗黙の前提を明文化することは、Intent Engineering の核心です。
ポイント:
- AI に『何を望むか』を伝えるには、まず『何を前提としているか』を伝える必要がある
- 前提条件は定期的に見直す — reviewBy を設定したので、その日が来たら前提が崩れていないか確認する
- 制約と前提の区別がつくようになると、スコープ管理が格段にうまくなる
登録した前提条件・制約条件は、実際の開発フローで次のように活用されます:
- CLAUDE.md の制約セクションで参照し、AI の判断範囲を制御する
- タスク description の背景欄で『この前提のもとで実装する』と明記する
- start_work 時に自動返却されるプロジェクトコンテキストにも含まれる
つまり、今回登録した内容は『登録して終わり』ではなく、日々の開発で AI が参照する生きた情報になります。
次の /learn-ie-casestudy では、実際の事例から学びます。」
受講者のタスクを complete_work(taskId) で完了にする。