หมวดหมู่: Design Process

CD04. – Massing
Massing คืออะไร? การพัฒนามวลอาคารจาก Concept สู่รูปทรงสถาปัตยกรรม

Massing หรือ การพัฒนามวลอาคาร คือกระบวนการกำหนดรูปแบบพื้นฐานของอาคารจากการจัดการกับ ปริมาตร (Volume), ความสูง (Height), ตำแหน่ง (Position), ทิศทาง (Orientation), พื้นที่ว่าง (Void) และความสัมพันธ์ระหว่างอาคารกับ Site

Massing เป็นขั้นตอนสำคัญที่เชื่อมระหว่าง

Design Concept

กับ

Schematic Design

เพราะเป็นช่วงที่แนวคิดเริ่มเปลี่ยนจาก

Idea → Form

Massing อยู่ตรงไหนใน Design Process?

Massing ไม่ควรเกิดขึ้นโดยไม่มีที่มา แต่ควรพัฒนาต่อจากข้อมูลและการตัดสินใจในขั้นก่อนหน้า
```
Site Research
      ↓
Client Brief
      ↓
Program
      ↓
Feasibility
      ↓
Site Analysis
      ↓
Design Concept
      ↓
Design Strategy
      ↓
Concept Development
      ↓
★ MASSING
      ↓
Space Planning
      ↓
Schematic Design
```
ดังนั้น Massing ที่ดีควรตอบคำถามได้ว่า

ทำไมอาคารจึงอยู่ตรงนี้?

ทำไมอาคารจึงสูงเท่านี้?

ทำไม Volume จึงเป็นแบบนี้?

ทำไมต้องมี Void?

ทำไมต้องแยกหรือเชื่อม Mass?

คำตอบควรมาจาก Design Logic ไม่ใช่เพียงความชอบด้านรูปทรง

Massing ไม่ใช่ Form Finding

สองคำนี้ใกล้เคียงกัน แต่มีจุดเน้นต่างกัน

Massing

เน้น
- Volume
- Height
- Placement
- Density
- Solid / Void
- Building Relationship
Form Finding

เน้นการค้นหารูปทรงที่เกิดจาก
- Design Concept
- Forces
- Performance
- Geometry
- Structure
- Environment
- User Experience
กล่าวง่าย ๆ คือ

Massing = อาคารมีมวลอย่างไร

Form Finding = รูปทรงนั้นเกิดขึ้นอย่างไร

1. Basic Massing

Basic Massing คือการสร้างรูปแบบอาคารขั้นพื้นฐานโดยยังไม่สนใจรายละเอียดของ Facade หรือวัสดุ

องค์ประกอบพื้นฐานอาจเริ่มจาก
- Box
- Cylinder
- Extrusion
- Block
- Plane
- Volume
ตัวอย่าง:
```
SITE
 ↓
BUILDING FOOTPRINT
 ↓
EXTRUDE
 ↓
BASIC MASS
```
จากนั้นจึงเริ่มทดลอง
- Move
- Rotate
- Scale
- Split
- Stack
- Subtract
- Connect
- Shift
ตัวอย่าง:
```
BOX
 ↓
SHIFT
 ↓
ROTATE
 ↓
SUBTRACT
 ↓
CONNECT
 ↓
MASSING
```
ในช่วงนี้ไม่จำเป็นต้องมี
- หน้าต่าง
- ประตู
- วัสดุ
- เฟอร์นิเจอร์
- Facade Detail
เพราะเป้าหมายคือการตรวจสอบ ภาพรวมของอาคาร

2. Building Envelope

Building Envelope คือขอบเขตทางกายภาพที่แยกพื้นที่ภายในอาคารออกจากสภาพแวดล้อมภายนอก

ในระดับ Massing สิ่งสำคัญคือการเข้าใจว่าอาคารสามารถสร้าง Envelope ได้อย่างไร

พิจารณา
- Building Boundary
- Height
- Setback
- Roof
- Facade
- Openings
- Shading
- Outdoor Space
Building Envelope ไม่ได้เป็นเพียง “เปลือกอาคาร”

แต่เกี่ยวข้องกับ
- Solar
- Heat
- Daylight
- Ventilation
- View
- Privacy
- Energy
ดังนั้น Massing และ Envelope จึงควรถูกคิดไปพร้อมกันในระดับหนึ่ง

3. Height

Height คือความสูงของอาคาร ซึ่งส่งผลต่อทั้ง Architecture และ Urban Context

ความสูงสามารถถูกกำหนดจาก
- Program
- FAR
- Regulations
- View
- Density
- Structure
- Solar
- Skyline
- Context
ตัวอย่าง:
```
LOW
 ↓
Human Scale
 ↓
MEDIUM
 ↓
Urban Scale
 ↓
HIGH
 ↓
Vertical Landmark
```
ความสูงไม่ได้หมายถึงเพียง “กี่ชั้น”

แต่รวมถึง

อาคารควรสร้างความรู้สึกสูงหรือต่ำเมื่อสัมพันธ์กับบริบทอย่างไร?

4. Setback

Setback คือระยะถอยของอาคารจากขอบเขตที่ดิน ถนน หรือพื้นที่โดยรอบ ตามข้อกำหนดหรือแนวทางการออกแบบที่เกี่ยวข้อง

Setback ส่งผลต่อ
- Street
- Landscape
- Privacy
- Light
- Ventilation
- Urban Space
- Building Form
ตัวอย่าง:
```
ROAD
────────────────
     SETBACK
        ↓
   ┌─────────┐
   │ BUILDING│
   └─────────┘
```
Setback สามารถสร้างพื้นที่
- Front Yard
- Plaza
- Landscape Buffer
- Entrance Court
- Public Space
ดังนั้น Setback ไม่ควรถูกมองเป็นเพียง “พื้นที่ที่กฎหมายไม่ให้อาคารสร้าง”

แต่สามารถนำมาเป็น Design Opportunity

5. Orientation

Orientation คือทิศทางการวางอาคาร

เกี่ยวข้องกับ
- Sun
- Wind
- View
- Access
- Noise
- Context
ตัวอย่าง:
```
SUN
 ↓
SOLAR ANALYSIS
 ↓
BUILDING ORIENTATION
 ↓
FACADE RESPONSE
```
หรือ
```
PREVAILING WIND
       ↓
BUILDING ORIENTATION
       ↓
OPENINGS
       ↓
VENTILATION
```
Orientation จึงเป็นหนึ่งใน Massing Decisions ที่มีผลต่ออาคารทั้งหลัง

6. Volume

Volume คือปริมาตรสามมิติของอาคาร

Massing สามารถเริ่มจากการสร้าง Volume แล้วทดลองเปลี่ยนแปลง

เช่น

Add

เพิ่ม Volume

Subtract

ตัด Volume ออก

Shift

เลื่อน Volume

Rotate

หมุน Volume

Stack

วางซ้อน Volume

Split

แบ่ง Volume

ตัวอย่าง:
```
BASE VOLUME
     ↓
SUBTRACT
     ↓
VOID
     ↓
SHIFT
     ↓
OVERHANG
     ↓
FINAL MASS
```
การทำงานกับ Volume คือพื้นฐานของการสร้าง Architectural Form

7. Solid / Void

หนึ่งในแนวคิดสำคัญของ Massing คือ

เราไม่ได้ออกแบบเฉพาะสิ่งที่สร้างขึ้น แต่เราออกแบบสิ่งที่ว่างด้วย

Solid คือมวลอาคาร

Void คือพื้นที่ว่าง

Void อาจเป็น
- Courtyard
- Atrium
- Terrace
- Plaza
- Balcony
- Sky Garden
- Passage
ตัวอย่าง:
```
SOLID
████████
████████
████████
```
เปลี่ยนเป็น
```
SOLID + VOID
████████
██    ██
██    ██
████████
```
Void สามารถสร้าง
- Daylight
- Ventilation
- View
- Social Space
- Privacy
- Spatial Hierarchy
ดังนั้น

Void ไม่ใช่พื้นที่ที่เหลือจากการสร้างอาคาร

แต่สามารถเป็น Design Element

8. Courtyard

Courtyard คือพื้นที่เปิดหรือกึ่งเปิดที่ถูกล้อมรอบด้วยอาคารบางส่วนหรือหลายด้าน

Courtyard สามารถทำหน้าที่เป็น
- Landscape
- Social Space
- Daylight Source
- Ventilation Space
- Privacy Buffer
- Circulation Space
ตัวอย่าง:
```
┌───────────────┐
│               │
│    COURTYARD  │
│               │
└───────────────┘
```
ในเขตร้อน Courtyard ยังสามารถนำไปพัฒนาเป็นส่วนหนึ่งของ Environmental Strategy ได้ แต่ต้องพิจารณาเรื่อง
- Solar Exposure
- Rain
- Humidity
- Ventilation
- Thermal Comfort
ไม่ควรถือว่า “มี Courtyard = อาคารดีต่อสภาพอากาศ” โดยอัตโนมัติ

9. Tower / Podium

Tower / Podium เป็นรูปแบบ Massing ที่พบได้มากในอาคารขนาดใหญ่และอาคารเมือง

โดยทั่วไป

Podium

ทำหน้าที่รองรับ
- Public
- Retail
- Lobby
- Parking
- Common Functions
Tower

รองรับ
- Office
- Residential
- Hotel
- Other Vertical Programs
ตัวอย่าง:
```
      ┌───────┐
      │ TOWER │
      │       │
      │       │
      └───────┘
   ┌─────────────┐
   │   PODIUM    │
   └─────────────┘
```
ข้อดีคือสามารถแยก Scale และ Program ได้

แต่ต้องพิจารณา
- Urban Impact
- Structure
- Vertical Circulation
- Fire Safety
- Wind
- Solar
- Parking
- Cost
10. Atrium

Atrium คือพื้นที่ว่างขนาดใหญ่ภายในอาคาร ซึ่งมักเชื่อมต่อหลายชั้น

Atrium สามารถเป็น
- Circulation Space
- Social Space
- Daylight Source
- Visual Connection
- Vertical Landmark
ตัวอย่าง:
```
┌───────────────┐
│       │       │
│       │       │
│ ATRIUM│       │
│       │       │
│       │       │
└───────┴───────┘
```
Atrium สามารถสร้าง Vertical Spatial Experience ได้อย่างมาก

แต่ต้องพิจารณาเรื่อง
- Smoke Control
- Fire Safety
- Energy
- Solar Gain
- Acoustic
- Maintenance
ดังนั้น Atrium ควรเริ่มจาก Concept และ Program ไม่ใช่เพิ่มเพียงเพื่อให้ Space ดูอลังการ

11. Stepped Massing

Stepped Massing คือการลดหรือเพิ่มความสูงของ Mass เป็นขั้น ๆ

ตัวอย่าง:
```
        ███
      █████
    ███████
  █████████
████████████
```
สามารถใช้เพื่อ
- ลด Scale
- สร้าง Terrace
- ตอบ Context
- ลด Shadow Impact
- สร้าง Outdoor Space
- สร้าง Skyline
ตัวอย่าง:

อาคารสูงติดกับอาคารเตี้ย

อาจใช้ Stepped Massing เพื่อสร้าง Transition
```
LOW → MEDIUM → HIGH
```
แทนการสร้างกำแพงสูงขึ้นทันที

12. Terracing

Terracing คือการสร้างพื้นที่ใช้งานหรือพื้นที่เปิดบนระดับต่าง ๆ ของอาคาร

สามารถเกิดขึ้นจาก
- Stepped Massing
- Setback
- Subtraction
- Roof Design
Terrace สามารถเป็น
- Garden
- Outdoor Space
- Common Space
- Private Space
- Viewing Deck
ตัวอย่าง:
```
      ┌──────┐
      │      │ ← Terrace
   ┌──┴──────┤
   │         │ ← Terrace
┌──┴─────────┤
│            │
└────────────┘
```
Terracing จึงสามารถเชื่อม

Massing + Landscape + User Experience

เข้าด้วยกัน

Massing กับ Site

Massing ที่ดีควรตอบสนองต่อ Site

ตัวอย่าง:

Sun
```
SUN
 ↓
SOLAR ANALYSIS
 ↓
ORIENTATION
 ↓
MASSING
```
Wind
```
WIND
 ↓
WIND PATH
 ↓
BUILDING PLACEMENT
 ↓
MASSING
```
View
```
GOOD VIEW
 ↓
ORIENTATION
 ↓
OPEN SIDE
 ↓
MASSING
```
Noise
```
NOISE
 ↓
BUFFER
 ↓
SOLID MASS
 ↓
QUIETER INTERIOR
```
ดังนั้น Massing สามารถเป็นเครื่องมือในการแก้ปัญหา Site ได้

Massing กับ Program

Program ก็มีผลต่อ Massing

ตัวอย่าง:

Large Public Space

อาจต้องการ

Large Span / Large Volume

Private Rooms

อาจเหมาะกับ

Repetitive Modules

Service

อาจถูกจัดไว้ด้านหลังหรือส่วนที่เข้าถึงง่ายสำหรับงานบริการ

ดังนั้น
```
PROGRAM
 ↓
SPACE REQUIREMENT
 ↓
VOLUME
 ↓
MASSING
```
Massing จึงไม่ควรแยกจาก Space Program

Massing กับ Circulation

Circulation สามารถกำหนดรูปแบบ Massing ได้

ตัวอย่าง:

Central Spine
```
████████████
████████████
     ↓
   SPINE
     ↓
████████████
████████████
```
Courtyard Loop
```
┌────────────┐
│  → → → →   │
│  ↑      ↓  │
│  ← ← ← ←   │
└────────────┘
```
Vertical Core
```
██████████
██  │   ██
██  │   ██
██  │   ██
██████████
```
ดังนั้น Circulation สามารถกลายเป็น Massing Generator

Massing กับ Environment

Massing มีผลต่อ Environmental Performance อย่างมาก

เพราะกำหนด
- Surface Area
- Solar Exposure
- Shading
- Daylight
- Wind
- Thermal Behavior
ตัวอย่าง:
```
MASSING A
Compact
 ↓
Less Surface Area

MASSING B
Fragmented
 ↓
More Surface Area
```
ทั้งสองแบบอาจมี Area เท่ากัน แต่มี Performance แตกต่างกัน

ดังนั้นการเลือก Massing ควรพิจารณาทั้ง

Architecture + Performance

Massing Development Process

สามารถพัฒนา Massing อย่างเป็นขั้นตอนได้
```
01 SITE
   ↓
02 BUILDING FOOTPRINT
   ↓
03 HEIGHT
   ↓
04 ORIENTATION
   ↓
05 VOLUME
   ↓
06 SOLID / VOID
   ↓
07 COURTYARD / ATRIUM
   ↓
08 STEP / TERRACE
   ↓
09 ENVIRONMENTAL TEST
   ↓
10 MASSING REFINEMENT
```
Massing Iteration

ไม่ควรสร้าง Massing เพียงแบบเดียว

ควรสร้างหลายทางเลือก

Option A

Compact Mass

Option B

Courtyard

Option C

Linear

Option D

Cluster

Option E

Tower + Podium

จากนั้นจึงนำไปเปรียบเทียบ
```
OPTION A
    ↓
TEST

OPTION B
    ↓
TEST

OPTION C
    ↓
TEST

       ↓

COMPARE
       ↓
SELECT
       ↓
REFINE
```
AI กับ Massing

AI สามารถเข้ามาช่วย Massing ได้หลายระดับ ตั้งแต่การสร้างแนวคิด ไปจนถึงการทดลองรูปแบบจำนวนมาก

AI Topics ที่เกี่ยวข้อง ได้แก่
- Massing Generation
- Massing Variation
- Image-to-Massing
- 3D Concept
- AI Form Exploration
แต่ควรเข้าใจข้อจำกัดของแต่ละประเภท

1. Massing Generation

AI สามารถสร้าง Massing Concept จากข้อมูล เช่น
- Site
- Program
- Height
- Setback
- Concept
- Context
ตัวอย่าง Workflow:
```
SITE
+
PROGRAM
+
CONCEPT
+
CONSTRAINTS
      ↓
AI
      ↓
MASSING OPTIONS
```
AI สามารถช่วยสร้างจุดเริ่มต้นหลายแบบเพื่อให้ Architect นำไปพัฒนาต่อ

2. Massing Variation

เมื่อมี Massing หนึ่งแบบแล้ว AI สามารถช่วยสร้าง Variations

เช่น
```
BASE MASS
   ↓
Rotate
   ↓
Shift
   ↓
Step
   ↓
Subtract
   ↓
Split
```
เป้าหมายคือ

Explore the Design Space

ไม่ใช่เพียงสร้างภาพให้มากที่สุด

3. Image-to-Massing

Image-to-Massing คือการนำภาพ เช่น
- Sketch
- Diagram
- Concept Image
- Reference Image
มาใช้เป็นข้อมูลตั้งต้นเพื่อพัฒนา Massing

ตัวอย่าง:
```
SKETCH
  ↓
AI INTERPRETATION
  ↓
MASSING CONCEPT
  ↓
3D MODEL
```
อย่างไรก็ตาม AI อาจตีความ Geometry ผิดได้

ดังนั้นผลลัพธ์ควรถือเป็น

Design Reference

ก่อนที่จะนำไปสร้างเป็น Geometry จริง

4. 3D Concept

AI สามารถช่วยสร้างภาพหรือแนวคิดสามมิติ เพื่อสำรวจ
- Form
- Volume
- Proportion
- Solid / Void
- Spatial Character
เช่น

Generate 5 massing concepts for a tropical cultural center based on courtyard, shaded circulation and stepped volumes.

ผลลัพธ์สามารถใช้เป็น

Design Inspiration

และนำกลับมาพัฒนาใน
- SketchUp
- Rhino
- Revit
- Blender
- CAD/BIM
หรือเครื่องมือ 3D อื่น ๆ

5. AI Form Exploration

AI มีประโยชน์มากในการสำรวจ Design Space ที่กว้าง

ตัวอย่าง:
```
ONE CONCEPT
     ↓
10 MASSING OPTIONS
     ↓
30 VARIATIONS
     ↓
SELECT 5
     ↓
TEST
     ↓
SELECT 2
     ↓
DEVELOP 1
```
สิ่งที่ AI ช่วยได้มากที่สุดในขั้นนี้คือ

เพิ่มจำนวนทางเลือกที่ Architect สามารถสำรวจได้

ไม่ใช่ลดบทบาทของ Architect

AI Massing Workflow

สำหรับการทำงานจริง สามารถสร้าง Workflow ได้ดังนี้
```
01
INPUT
Site + Program + Constraints
        ↓
02
DESIGN LOGIC
Concept + Strategy
        ↓
03
AI MASSING GENERATION
        ↓
04
MASSING VARIATIONS
        ↓
05
ARCHITECT SCREENING
        ↓
06
ENVIRONMENTAL TEST
        ↓
07
PROGRAM TEST
        ↓
08
CIRCULATION TEST
        ↓
09
COMPARE
        ↓
10
REFINE
        ↓
FINAL MASSING
```
จุดสำคัญคือ AI ไม่ควรข้ามขั้นตอน Test

เพราะ Massing ที่ดูดีในภาพอาจมีปัญหาเรื่อง
- Area
- Structure
- Circulation
- Regulation
- Climate
- Cost
- Construction
From AI Image to Real Massing

สิ่งที่ AIAIRCHLAB ควรสอนเป็นพิเศษคือการเปลี่ยนจาก

AI Image

ไปเป็น

Architectural Geometry

ตัวอย่าง:
```
AI IMAGE
   ↓
IDENTIFY VOLUME
   ↓
EXTRACT MASS
   ↓
DEFINE DIMENSIONS
   ↓
SET GRID
   ↓
CREATE 3D MODEL
   ↓
TEST
   ↓
REFINE
```
เพราะภาพ AI ไม่ได้หมายความว่า Geometry นั้นสามารถสร้างได้จริง

Massing Evaluation Matrix

สามารถประเมิน Massing หลายทางเลือกได้ด้วย Matrix

Criteria Option A Option B Option C
Site Response 4 5 3
Program Fit 5 4 4
Circulation 4 5 3
Solar 3 5 4
Wind 4 4 3
Efficiency 5 3 4
Identity 3 4 5
Complexity Low Medium High

จากนั้นดูว่า

Massing ไหนเหมาะสมกับ Priorities ของโครงการมากที่สุด

ไม่จำเป็นต้องเลือกแบบที่ได้คะแนนรวมสูงสุดเสมอไป

เพราะบางโครงการอาจให้ความสำคัญกับ

Identity > Efficiency

ในขณะที่บางโครงการอาจเป็น

Cost > Formal Expression

Massing Checklist

ก่อนเข้าสู่ Schematic Design ควรตรวจสอบว่า

Site
- Building Placement
- Setback
- Orientation
- Access
- Context
- View
- Noise
Form
- Basic Massing
- Height
- Volume
- Solid / Void
- Building Envelope
- Courtyard
- Atrium
- Tower / Podium
- Stepped Massing
- Terracing
Program
- Program Fit
- Zoning
- Area
- Vertical Organization
- Circulation
Environment
- Solar
- Wind
- Daylight
- Shading
- Landscape
- Thermal Considerations
Technical
- Structure
- Core
- Span
- Constructability
- Fire / Life Safety Considerations
- Regulations
AI
- Massing Generation
- Massing Variation
- Image-to-Massing
- 3D Concept
- AI Form Exploration
Massing Design Framework

สามารถสรุปเป็น Framework ได้ว่า
```
                    SITE
                     ↓
          ┌────────────────────┐
          │ DESIGN STRATEGY    │
          └─────────┬──────────┘
                    ↓
              BASIC MASS
                    ↓
       ┌────────────┼────────────┐
       ↓            ↓            ↓
    HEIGHT      ORIENTATION   SETBACK
       ↓            ↓            ↓
       └────────────┼────────────┘
                    ↓
                 VOLUME
                    ↓
              SOLID / VOID
                    ↓
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   COURTYARD      ATRIUM     TERRACING
       ↓            ↓            ↓
       └────────────┼────────────┘
                    ↓
             ENVIRONMENTAL
                 TEST
                    ↓
               REFINEMENT
                    ↓
                MASSING
```
สรุป

Massing คือขั้นตอนที่เปลี่ยน Concept และ Strategy ให้กลายเป็น รูปแบบสามมิติพื้นฐานของ Architecture

กระบวนการสำคัญคือ
```
CONCEPT
   ↓
STRATEGY
   ↓
BASIC MASS
   ↓
HEIGHT
   ↓
ORIENTATION
   ↓
VOLUME
   ↓
SOLID / VOID
   ↓
COURTYARD / ATRIUM
   ↓
TOWER / PODIUM
   ↓
STEPPED MASSING
   ↓
TERRACING
   ↓
ENVIRONMENTAL TEST
   ↓
MASSING REFINEMENT
```
สิ่งสำคัญที่สุดคือ

Massing ไม่ใช่การทำให้อาคารมีรูปทรงที่น่าสนใจ

แต่คือการค้นหาว่า

“มวลอาคารแบบใดสามารถตอบ Site + Program + Concept + Environment + Context ได้ดีที่สุด”

และ AI สามารถเพิ่มประสิทธิภาพในส่วนของ การสร้างทางเลือกและการสำรวจรูปแบบ ได้อย่างมาก
```
AI
Generate
Explore
Vary
        ↓
ARCHITECT
Evaluate
Test
Decide
        ↓
ARCHITECTURAL MASSING
```
ดังนั้นแนวทางที่เหมาะสมคือ

AI explores the possibilities.

Architect defines the logic.

Performance testing validates the decision.

Architect makes the final decision.

เมื่อ Massing มีความชัดเจนแล้ว ขั้นต่อไปคือการนำ Massing ไปแปลงเป็น Space Planning, Floor Plan, Circulation และ Schematic Design ซึ่งจะเป็นจุดที่ “มวลอาคาร” เริ่มกลายเป็น “พื้นที่ที่มนุษย์ใช้งานจริง”
สิงหาคม 21, 2026
CD03. – Concept Development
Concept Development คืออะไร? จากแนวคิดสู่แบบสถาปัตยกรรมที่พัฒนาแล้ว

Concept Development หรือ การพัฒนาแนวคิดการออกแบบ คือกระบวนการนำ Design Concept และ Design Strategy ที่ได้จากขั้นก่อนหน้า มาทดลอง พัฒนา เปรียบเทียบ และปรับปรุงจนกลายเป็นแนวทางการออกแบบที่มีความชัดเจนและพร้อมนำไปพัฒนาต่อ

ถ้า

Design Concept = เราต้องการให้งานเป็นอะไร

และ

Design Strategy = เราจะทำอย่างไร

Concept Development คือ

“ลองทำหลายวิธี แล้วค้นหาว่าวิธีไหนเหมาะที่สุด”

ดังนั้น Concept Development ไม่ใช่ขั้นตอนของการ “ทำแบบให้เสร็จ”

แต่เป็นช่วงของ

Explore → Test → Compare → Decide → Evolve

Concept Development อยู่ตรงไหนใน Design Process?

Concept Development อยู่หลัง Design Concept และ Design Strategy
```
Site Research
      ↓
Client Brief
      ↓
Program
      ↓
Feasibility
      ↓
Site Analysis
      ↓
Design Concept
      ↓
Design Strategy
      ↓
★ Concept Development
      ↓
Massing
      ↓
Form Finding
      ↓
Schematic Design
```
ในขั้นตอนนี้ Architect จะเริ่มเปลี่ยนสิ่งที่เป็น

Idea / Diagram / Strategy

ให้กลายเป็น

Spatial + Formal + Architectural Proposal

Concept Development ต่างจาก Design Concept อย่างไร?

ตัวอย่างเช่น

Design Concept

Architecture as a Filter

แนวคิดคืออาคารทำหน้าที่เป็นตัวกรองระหว่างเมืองกับพื้นที่ภายใน

Design Strategy
- ใช้ Landscape Buffer
- ใช้ Screen
- สร้าง Transition Space
- เปิดอาคารเข้าสู่ Courtyard
Concept Development

ทดลองว่าแนวคิดนี้สามารถเกิดขึ้นได้หลายวิธีหรือไม่

Option A

Landscape เป็น Filter

Option B

Facade Screen เป็น Filter

Option C

Courtyard เป็น Filter

Option D

Spatial Sequence เป็น Filter

จากนั้นจึงเปรียบเทียบว่าแนวทางใดเหมาะกับโครงการมากที่สุด

ดังนั้น
```
CONCEPT
      ↓
STRATEGY
      ↓
ALTERNATIVES
      ↓
TEST
      ↓
COMPARE
      ↓
DECIDE
      ↓
DEVELOP
```
1. Sketch

Sketch เป็นเครื่องมือสำคัญที่สุดอย่างหนึ่งในการพัฒนา Concept

Sketch ช่วยให้ Architect สามารถคิดและทดลองได้อย่างรวดเร็วโดยไม่ต้องเสียเวลาไปกับรายละเอียด

Sketch อาจเป็น
- Site Sketch
- Plan Sketch
- Section Sketch
- Massing Sketch
- Spatial Sketch
- Circulation Sketch
- Detail Sketch
ตัวอย่าง:
```
Idea
 ↓
Sketch
 ↓
Observe
 ↓
Modify
 ↓
Sketch Again
```
หัวใจของ Sketch คือ

Speed of Thinking

ไม่จำเป็นต้องสวย

ไม่จำเป็นต้องละเอียด

แต่ต้องช่วยให้เราคิดได้เร็วขึ้น

Sketch เป็นเครื่องมือคิด ไม่ใช่เพียงเครื่องมือบันทึก

Architectural Sketch ที่ดีไม่ได้มีหน้าที่เพียงบันทึกสิ่งที่คิดออกมาแล้ว

แต่ช่วยให้เกิดความคิดใหม่ด้วย

เช่น
```
Sketch A
 ↓
เห็นปัญหา
 ↓
ปรับรูปทรง
 ↓
เกิด Space ใหม่
 ↓
Sketch B
 ↓
เกิด Concept ใหม่
```
ดังนั้น Sketch จึงเป็นส่วนหนึ่งของ Design Thinking

2. Diagram

Diagram คือเครื่องมือที่ช่วยอธิบายความสัมพันธ์ระหว่างองค์ประกอบต่าง ๆ

เช่น
- Program
- Circulation
- Massing
- Sun
- Wind
- View
- Landscape
- Public / Private
ตัวอย่าง:
```
PUBLIC
  ↓
SEMI-PUBLIC
  ↓
PRIVATE
```
หรือ
```
GOOD VIEW
     ↓
ORIENTATION
     ↓
MAIN SPACE
```
Diagram ช่วยให้ Concept สามารถถูก “มองเห็น” และตรวจสอบได้ง่ายขึ้น

3. Iteration

Iteration คือการทำซ้ำเพื่อพัฒนาการออกแบบ

Concept Development ที่ดีมักไม่ได้เกิดจาก

Sketch → Final

แต่เป็น
```
Version 01
   ↓
Test
   ↓
Version 02
   ↓
Test
   ↓
Version 03
   ↓
Test
   ↓
Version 04
```
แต่ละ Iteration ควรมีคำถามที่ต้องการทดสอบ

เช่น

Iteration 01

ทดสอบ Massing

Iteration 02

ทดสอบ Solar

Iteration 03

ทดสอบ Program

Iteration 04

ทดสอบ Circulation

Iteration 05

ทดสอบ Structure

ดังนั้น Iteration ไม่ควรเป็นการ “เปลี่ยนไปเรื่อย ๆ” โดยไม่มีเหตุผล

ควรเป็น

Test → Learn → Modify

4. Alternative Concepts

การมี Concept เดียวตั้งแต่ต้นอาจทำให้ Architect ติดอยู่กับ Solution แรกที่คิดได้

Alternative Concepts ช่วยเปิดทางเลือก

ตัวอย่าง:

Concept A — Courtyard

เน้น Landscape และ Privacy

Concept B — Linear Spine

เน้น Circulation และ Program Organization

Concept C — Cluster

เน้น Community และ Human Scale

จากนั้นจึงนำทั้งสามแนวทางมาทดสอบ
```
CONCEPT A
     \
CONCEPT B → EVALUATE → SELECT
     /
CONCEPT C
```
จุดสำคัญคือ Alternative ไม่ควรแตกต่างกันแค่ “หน้าตา”

แต่ควรแตกต่างกันในระดับ Design Logic

5. Design Variations

Design Variations คือการสร้างความแตกต่างภายใน Concept เดียวกัน

ตัวอย่าง Concept เดียว:

Central Courtyard

สามารถมี Variations เช่น

Variation A

Courtyard กลางอาคาร

Variation B

Courtyard ด้านข้าง

Variation C

หลาย Courtyards

Variation D

Linear Courtyard

Concept เดิมยังคงอยู่ แต่ Architecture เปลี่ยนไป

ดังนั้น

Alternative Concept = ต่างกันที่ความคิด

ในขณะที่

Design Variation = ต่างกันที่วิธีพัฒนาแนวคิดเดียวกัน

6. Design Evaluation

เมื่อมีหลายทางเลือก จำเป็นต้องประเมิน

ไม่เช่นนั้น Concept Development จะกลายเป็นเพียงการสร้างทางเลือกจำนวนมาก

เกณฑ์การประเมินอาจประกอบด้วย
- Site Response
- Program Fit
- Circulation
- Environmental Performance
- User Experience
- Architectural Identity
- Structural Logic
- Constructability
- Cost
- Sustainability
ตัวอย่าง:

Criteria Option A Option B Option C
Site Response 5 4 3
Program 4 5 4
Environment 5 3 4
Circulation 4 5 3
Identity 4 4 5
Feasibility 4 5 3

คะแนนไม่ได้มีไว้เพื่อให้คอมพิวเตอร์ “เลือกแบบแทนสถาปนิก”

แต่ช่วยให้ทีมเห็นว่า

แต่ละทางเลือกมีข้อดีและข้อเสียอะไร

7. Concept Comparison

Concept Comparison คือการนำทางเลือกหลายแบบมาเปรียบเทียบกันอย่างเป็นระบบ

ควรเปรียบเทียบทั้ง

Quantitative

สิ่งที่วัดได้ เช่น
- Area
- Efficiency
- Building Footprint
- Number of Floors
- Parking
- Cost
- Energy
Qualitative

สิ่งที่ต้องใช้การตัดสินใจ เช่น
- Spatial Quality
- Identity
- Experience
- Context
- Architectural Character
ตัวอย่าง:
```
OPTION A
Courtyard
       ↓
Strong Privacy
Strong Landscape
Medium Efficiency

OPTION B
Linear
       ↓
Strong Circulation
High Flexibility
Less Landscape

OPTION C
Cluster
       ↓
Strong Community
Complex Structure
Higher Cost
```
การเปรียบเทียบแบบนี้ช่วยให้การเลือก Concept มีเหตุผลมากขึ้น

8. Design Decision

Concept Development จะต้องนำไปสู่ Design Decision

นี่คือจุดที่ Architect ต้องตัดสินใจว่า

“จากสิ่งที่เราทดลองมา เราจะเลือกอะไร?”

ตัวอย่าง:
```
3 CONCEPTS
     ↓
EVALUATION
     ↓
CONCEPT B
     ↓
DESIGN DECISION
     ↓
DEVELOP FURTHER
```
แต่ Design Decision ไม่ได้หมายความว่า Option ที่ไม่ได้เลือก “ผิด”

บางครั้งสามารถนำข้อดีของ Option อื่นมาผสมได้

เช่น

เลือก Massing ของ Option B

แต่

ใช้ Landscape Strategy จาก Option A

นี่คือ Design Synthesis

9. Design Evolution

Design Evolution คือการติดตามว่าการออกแบบพัฒนาจากจุดเริ่มต้นไปสู่แบบปัจจุบันอย่างไร

ตัวอย่าง:
```
IDEA
 ↓
SKETCH
 ↓
DIAGRAM
 ↓
MASSING 01
 ↓
MASSING 02
 ↓
PLAN 01
 ↓
PLAN 02
 ↓
SECTION
 ↓
REFINEMENT
 ↓
DESIGN
```
การบันทึก Evolution มีประโยชน์มาก เพราะช่วยให้เห็น
- ทำไมจึงเปลี่ยน
- เปลี่ยนเพราะอะไร
- อะไรถูกตัดออก
- อะไรถูกเพิ่ม
- Concept ยังอยู่หรือไม่
Design Evolution ไม่ใช่แค่ Before / After

การแสดง

Before → After

อาจทำให้เห็นเพียงว่า “แบบเปลี่ยน”

แต่ไม่เห็นว่า

“ทำไมจึงเปลี่ยน?”

Design Evolution ที่ดีควรอธิบาย
```
VERSION 01
Problem:
Poor Access

↓

VERSION 02
Change:
Move Entrance

↓

VERSION 03
Problem:
Weak Public Space

↓

VERSION 04
Change:
Create Plaza

↓

VERSION 05
Result:
Stronger Urban Connection
```
นี่ทำให้กระบวนการออกแบบมี Design Logic

Concept Development เป็นกระบวนการ “ทดสอบ”

หัวใจสำคัญของ Concept Development คือ

อย่ารีบตกหลุมรัก Concept แรก

Concept แรกอาจดี

แต่ยังไม่จำเป็นต้องดีที่สุด

ควรตั้งคำถามว่า
- มีทางเลือกอื่นหรือไม่?
- ถ้าเปลี่ยน Orientation จะเกิดอะไรขึ้น?
- ถ้าเปลี่ยน Massing จะดีขึ้นหรือไม่?
- ถ้าจัด Program ใหม่จะเป็นอย่างไร?
- ถ้าเพิ่ม Courtyard จะช่วยอะไร?
- ถ้าลดพื้นที่ลงจะเกิดอะไร?
- Concept นี้ยังทำงานได้หรือไม่เมื่อเจอกับ Structure?
- Concept นี้ยังตอบ Climate หรือไม่?
การถามคำถามเหล่านี้ทำให้ Concept แข็งแรงขึ้น

From Idea to Evidence

การพัฒนา Concept ที่ดีควรเปลี่ยนจาก

“I think this is a good idea.”

เป็น

“I tested this idea and here is why it works.”

ตัวอย่าง:
```
IDEA
Create Courtyard
      ↓
HYPOTHESIS
Improves daylight + privacy
      ↓
TEST
Massing + Solar + Program
      ↓
RESULT
Better daylight
Better privacy
Slightly higher circulation
      ↓
DECISION
Keep Courtyard
Refine its size
```
นี่คือการทำให้ Design Process มีเหตุผลและตรวจสอบได้

AI กับ Concept Development

AI สามารถเข้ามาช่วยในขั้นตอนนี้ได้มาก เพราะ Concept Development มีการสร้างทางเลือกและ Iteration จำนวนมาก

AI เหมาะกับการช่วย
- Generate Alternatives
- Explore Variations
- Critique
- Compare
- Evaluate
- Refine
- Document Evolution
แต่ Architect ยังคงเป็นผู้กำหนด

Criteria + Priorities + Final Decision

1. AI Design Iteration

AI สามารถช่วยสร้าง Design Variations ได้อย่างรวดเร็ว

ตัวอย่าง:
```
BASE CONCEPT
Central Courtyard

       ↓ AI

Option 01
Large Courtyard

Option 02
Small Courtyard

Option 03
Linear Courtyard

Option 04
Multiple Courtyards

Option 05
Offset Courtyard
```
แทนที่จะใช้เวลาหลายชั่วโมงในการทดลองแต่ละทางเลือก AI สามารถช่วยสร้างจุดเริ่มต้นให้ Architect สำรวจได้เร็วขึ้น

แต่ต้องระวังว่า AI Image Generation อาจสร้างภาพที่ดูดีแต่ไม่สามารถพัฒนาเป็น Plan, Section หรือ Construction ได้จริง

ดังนั้นควรแยก

Visual Exploration

ออกจาก

Architectural Development

2. AI Design Critic

AI สามารถทำหน้าที่เป็น Design Critic เพื่อท้าทายแนวคิด

ตัวอย่าง Prompt:

วิเคราะห์ Design Option นี้ในฐานะ Architectural Design Critic โดยพิจารณา Site Response, Program, Circulation, Environmental Performance, User Experience, Structure และ Feasibility ระบุจุดแข็ง จุดอ่อน ความขัดแย้ง และคำถามที่ควรทดสอบต่อ

ผลลัพธ์ที่ต้องการไม่ใช่

“แบบนี้สวย”

แต่เป็น

“แบบนี้มีปัญหาอะไรที่เรายังไม่เห็น?”

3. Alternative Generation

AI สามารถช่วยสร้าง Alternative Concepts โดยกำหนดให้แต่ละทางเลือกใช้ Design Logic ที่แตกต่างกัน

ตัวอย่าง Prompt:

จาก Site Analysis และ Program เดียวกัน สร้าง Design Directions 5 แนวทาง โดยแต่ละแนวทางต้องมี Massing Logic, Program Organization, Circulation Strategy และ Environmental Strategy ที่แตกต่างกันอย่างชัดเจน

ผลลัพธ์อาจเป็น
```
01 Courtyard
02 Linear Spine
03 Cluster
04 Vertical Stack
05 Landscape Ribbon
```
สิ่งสำคัญคือไม่ควรให้ AI สร้างเพียง “5 รูปทรง”

แต่ควรให้สร้าง

5 วิธีแก้ปัญหา

4. Design Comparison

AI สามารถช่วยสร้าง Comparison Matrix

เช่น

Criteria A B C
Site Response 5 4 4
Program Fit 4 5 4
Climate 5 3 4
Circulation 4 5 3
Cost 4 5 3
Identity 4 4 5

จากนั้นให้ AI อธิบาย
- Why A performs well
- Why B performs well
- Major risks
- Trade-offs
- What needs further testing
แต่คะแนนควรเกิดจาก ข้อมูลและเกณฑ์ที่ทีมออกแบบกำหนด ไม่ใช่ให้ AI สุ่มคะแนนโดยไม่มี Evidence

5. Multi-Criteria Evaluation

บางครั้งไม่มี Concept ไหน “ดีที่สุดทุกด้าน”

Concept A อาจดีที่สุดด้าน Climate

Concept B อาจดีที่สุดด้าน Cost

Concept C อาจดีที่สุดด้าน User Experience

ดังนั้นควรใช้

Multi-Criteria Evaluation

ตัวอย่าง:
```
CRITERIA
        WEIGHT
           ↓
Site Response       20%
Program             20%
Environment         20%
Experience          15%
Cost                15%
Identity            10%
           ↓
TOTAL SCORE
```
สามารถใช้ Weighted Score เพื่อช่วยจัดลำดับทางเลือก

แต่ไม่ควรใช้คะแนนเป็นคำตอบสุดท้ายโดยอัตโนมัติ

เพราะบาง Criteria อาจมีความสำคัญมากกว่าตัวเลขที่สะท้อนออกมา

AI Concept Development Workflow

สามารถสร้าง Workflow สำหรับ AIAIRCHLAB ได้ดังนี้
```
01
INPUT
Site + Brief + Program
       ↓
02
CONCEPT
Design Concept + Strategy
       ↓
03
GENERATE
AI Alternative Generation
       ↓
04
EXPLORE
Design Variations
       ↓
05
TEST
Site / Program / Environment
       ↓
06
CRITIQUE
AI Design Critic
       ↓
07
COMPARE
Multi-Criteria Evaluation
       ↓
08
DECIDE
Architectural Decision
       ↓
09
REFINE
Selected Concept
       ↓
10
EVOLVE
Massing + Space + Form
```
AI ไม่ควรเป็นคนเลือกแบบ

การใช้ AI ใน Concept Development ควรแบ่งหน้าที่ให้ชัดเจน

AI

Generate

สร้างทางเลือก

Explore

สำรวจ Variations

Critique

ตั้งคำถาม

Compare

เปรียบเทียบ

Summarize

สรุป

Architect

Define

กำหนดโจทย์

Set Criteria

กำหนดเกณฑ์

Interpret

ตีความ

Judge

ตัดสิน

Decide

เลือก

Take Responsibility

รับผิดชอบต่อ Design Decision

ดังนั้น Workflow ที่เหมาะสมคือ

AI generates. Architect decides.

Design Review Loop

Concept Development สามารถทำเป็น Loop
```
        ┌──────────────┐
        │    CONCEPT   │
        └──────┬───────┘
               ↓
          GENERATE
               ↓
            TEST
               ↓
           CRITIQUE
               ↓
           COMPARE
               ↓
            DECIDE
               ↓
            REFINE
               │
               └──────────→ BACK TO CONCEPT
```
การ Loop กลับไม่ใช่ความล้มเหลว

แต่เป็นส่วนหนึ่งของ Design Process

บางครั้งผลจากการ Test อาจทำให้พบว่า

Concept เดิมไม่เหมาะสม

และต้องกลับไปแก้ Concept

นี่เป็นเรื่องปกติของงานออกแบบ

เมื่อไหร่ควรหยุด Iteration?

ไม่จำเป็นต้องสร้างทางเลือกไปเรื่อย ๆ

ควรหยุดเมื่อ
- Concept มีความชัดเจน
- Major Problems ถูกแก้แล้ว
- Alternatives ถูกเปรียบเทียบแล้ว
- Design Strategy ทำงานสอดคล้องกัน
- Program รองรับได้
- Site Response เหมาะสม
- Major Constraints ถูกพิจารณา
- ทีมสามารถอธิบายเหตุผลของ Design Decision ได้
จุดสำคัญคือ

Iteration ไม่ได้มีเป้าหมายเพื่อสร้างแบบให้มากที่สุด

แต่มีเป้าหมายเพื่อ

ลดความไม่แน่นอนของ Design Decision

Design Evolution เป็นหลักฐานของการออกแบบ

เมื่อจบ Concept Development ควรเก็บ
- Sketches
- Diagrams
- Options
- Variations
- Tests
- Critiques
- Evaluation
- Decisions
เพราะข้อมูลเหล่านี้สามารถนำไปใช้ต่อใน
- Design Presentation
- Design Report
- Portfolio
- Competition
- Client Presentation
- Project Documentation
และในอนาคต AI สามารถช่วยสรุป Design Evolution ให้กลายเป็น Design Narrative ได้ด้วย

Concept Development Checklist

ก่อนเข้าสู่ Massing / Schematic Design ควรตรวจสอบว่า

Exploration
- มี Sketch
- มี Diagram
- มี Iteration
- มี Alternative Concepts
- มี Design Variations
Evaluation
- กำหนด Evaluation Criteria
- เปรียบเทียบ Concept
- ตรวจสอบ Site
- ตรวจสอบ Program
- ตรวจสอบ Environment
- ตรวจสอบ Circulation
- ตรวจสอบ Structure
- ตรวจสอบ Feasibility
Decision
- มี Design Decision
- อธิบายเหตุผลของการเลือกได้
- รู้ Trade-offs
- บันทึกสิ่งที่ไม่ได้เลือก
- มี Concept Evolution
AI
- AI Alternative Generation
- AI Design Iteration
- AI Design Critic
- AI Design Comparison
- Multi-Criteria Evaluation
สรุป

Concept Development คือกระบวนการที่ทำให้ Design Concept จาก

“แนวคิดที่น่าสนใจ”

กลายเป็น

“แนวทางการออกแบบที่ผ่านการทดลองและมีเหตุผลรองรับ”

กระบวนการสำคัญคือ
```
DESIGN CONCEPT
      ↓
SKETCH
      ↓
DIAGRAM
      ↓
ALTERNATIVES
      ↓
ITERATION
      ↓
TEST
      ↓
EVALUATION
      ↓
COMPARISON
      ↓
DESIGN DECISION
      ↓
DESIGN EVOLUTION
      ↓
MASSING / SCHEMATIC DESIGN
```
สิ่งสำคัญที่สุดคือ

Design Development ไม่ใช่การหา “แบบที่สวยที่สุด”

แต่คือการค้นหา

“Design Solution ที่เหมาะสมที่สุดสำหรับโจทย์ที่เรามี”

และการใช้ AI สามารถช่วยให้กระบวนการนี้เร็วและกว้างขึ้นอย่างมาก

แทนที่จะ

คิด 1 แบบ → พัฒนา → หวังว่ามันจะดี

สามารถเปลี่ยนเป็น

Generate → Explore → Test → Critique → Compare → Decide → Refine

AI จึงมีบทบาทสำคัญในฐานะ Design Exploration Partner

แต่สิ่งที่ทำให้กระบวนการนี้ยังเป็น “งานสถาปัตยกรรม” คือการที่สถาปนิกเป็นผู้กำหนดโจทย์ เกณฑ์การประเมิน และตัดสินใจว่า

“ทางเลือกไหนตอบโจทย์ของโครงการได้ดีที่สุด และเพราะอะไร”

นี่คือจุดที่ AI-assisted Design แตกต่างจากการใช้ AI เพื่อสร้างภาพสวย ๆ เพียงอย่างเดียว
สิงหาคม 21, 2026
CD02. – Design Strategy
Design Strategy คืออะไร? จาก Design Concept สู่แนวทางการออกแบบที่นำไปใช้ได้จริง

Design Strategy หรือ กลยุทธ์ในการออกแบบสถาปัตยกรรม คือแนวทางที่ใช้เปลี่ยน Design Concept ให้กลายเป็นการตัดสินใจทางสถาปัตยกรรมที่สามารถนำไปปฏิบัติได้จริง

ถ้า Design Concept ตอบคำถามว่า

“เราต้องการให้งานนี้มีแนวคิดอะไร?”

Design Strategy จะตอบว่า

“เราจะทำอย่างไรให้แนวคิดนั้นเกิดขึ้นจริง?”

ตัวอย่างเช่น

Design Concept

Urban Oasis

ต้องการสร้างพื้นที่สงบและเป็นธรรมชาติภายในบริบทเมือง

Design Strategy

อาจประกอบด้วย
- สร้าง Green Buffer
- วาง Courtyard กลางอาคาร
- ลด Noise จากถนน
- สร้าง Shaded Outdoor Space
- Orient พื้นที่หลักเข้าหาสวน
ดังนั้น
```
DESIGN CONCEPT
Urban Oasis
       ↓
DESIGN STRATEGY
Green Buffer
Courtyard
Shading
Landscape
       ↓
ARCHITECTURE
```
Concept คือ Direction

Strategy คือ Method

Design Strategy อยู่ตรงไหนใน Design Process?

Design Strategy เป็นสะพานสำคัญระหว่าง Concept และการพัฒนาแบบ
```
Site Research
      ↓
Client Brief
      ↓
Program
      ↓
Feasibility
      ↓
Site Analysis
      ↓
Design Concept
      ↓
★ Design Strategy
      ↓
Concept Development
      ↓
Massing
      ↓
Schematic Design
```
ถ้าไม่มี Strategy Concept อาจยังเป็นเพียงคำพูดหรือภาพ Inspiration

เช่น

“Nature”

“Connection”

“Community”

“Harmony”

แต่ Strategy จะทำให้คำเหล่านี้กลายเป็น Architectural Decisions

Concept กับ Strategy ต่างกันอย่างไร?

ลองดูตัวอย่าง

Concept

Architecture as a Filter

เป็นแนวคิดว่าอาคารทำหน้าที่เป็นตัวกรองระหว่างเมืองกับพื้นที่ภายใน

Strategy
- ใช้ Landscape เป็น Buffer
- ใช้ Screen ลด Visual Exposure
- ใช้ Semi-outdoor Space เป็น Transition
- ลดช่องเปิดด้านถนน
- เปิดพื้นที่ภายในเข้าสู่ Courtyard
ดังนั้น
```
CONCEPT
Architecture as a Filter
          ↓
STRATEGY
Landscape
Screen
Buffer
Transition
Courtyard
          ↓
DESIGN
```
นี่คือความแตกต่างที่สำคัญ

Concept บอก “WHAT”

Strategy บอก “HOW”

1. Site Strategy

Site Strategy คือแนวทางการวางและจัดการอาคารให้ตอบสนองต่อ Site

เริ่มจากข้อมูลจาก Site Analysis เช่น
- Sun
- Wind
- View
- Noise
- Access
- Existing Buildings
- Vegetation
- Topography
- Urban Context
แล้วเปลี่ยนเป็นกลยุทธ์

ตัวอย่าง:

Finding

ด้านตะวันตกมีแดดแรง

↓

Strategy

วางพื้นที่ Service เป็น Solar Buffer

Finding

ด้านเหนือมี View ที่ดี

↓

Strategy

Orient Main Spaces ไปทาง View

Finding

ด้านติดถนนมี Noise

↓

Strategy

สร้าง Landscape / Building Buffer

Site Strategy จึงเป็นการตอบคำถามว่า

“เราควรวางอาคารบน Site อย่างไร?”

2. Massing Strategy

Massing Strategy คือแนวทางในการพัฒนารูปทรงและมวลอาคาร

ไม่ได้หมายถึงการทำอาคารให้ “สวย” ตั้งแต่ต้น แต่เป็นการตัดสินใจเกี่ยวกับ
- Building Placement
- Orientation
- Height
- Density
- Volume
- Solid / Void
- Courtyard
- Building Separation
- Stepping
- Terracing
ตัวอย่าง:
```
SITE
 ↓
Solar + Wind + View
 ↓
Place Mass
 ↓
Rotate
 ↓
Subtract
 ↓
Create Courtyard
 ↓
Step Building
 ↓
FINAL MASSING
```
ตัวอย่าง Strategy:

“Break the building mass into smaller volumes to improve daylight, ventilation and human scale.”

กลยุทธ์เดียวสามารถส่งผลต่อทั้ง
- Form
- Climate
- Circulation
- Landscape
- Scale
3. Program Strategy

Program Strategy คือแนวทางในการจัดพื้นที่และฟังก์ชันต่าง ๆ ของโครงการ

ข้อมูลตั้งต้นมาจาก Space Program

เช่น
- Public
- Semi-Public
- Private
- Service
- Staff
- Back of House
จากนั้นจัดความสัมพันธ์ระหว่างพื้นที่
```
PUBLIC
 ↓
SEMI-PUBLIC
 ↓
PRIVATE
```
หรือ
```
PUBLIC
   │
   ├── Lobby
   │
   ├── Common
   │
   └── Private
          │
          └── Service
```
ตัวอย่าง Strategy:

“Organize spaces from public to private to create a gradual transition of privacy.”

Program Strategy จึงช่วยตอบว่า

“อะไรควรอยู่ตรงไหน และอะไรควรอยู่ใกล้หรือห่างจากอะไร?”

4. Circulation Strategy

Circulation Strategy คือแนวทางในการกำหนดการเคลื่อนที่ของคน รถ และ Service

ควรแยก Flow สำคัญ เช่น

User
```
Entrance
 ↓
Lobby
 ↓
Main Space
 ↓
Destination
```
Service
```
Service Entry
 ↓
Loading
 ↓
Back of House
```
Vehicle
```
Street
 ↓
Driveway
 ↓
Parking
```
กลยุทธ์อาจเป็น
- Separate User / Service Flow
- Create Central Spine
- Create Loop Circulation
- Create Hierarchical Circulation
- Create Public Promenade
- Minimize Conflict
Circulation Strategy ที่ดีไม่ควรคิดเพียงว่า

“เดินจาก A ไป B ได้หรือไม่”

แต่ควรถามด้วยว่า

“การเดินผ่าน Architecture ควรสร้างประสบการณ์อย่างไร?”

5. Environmental Strategy

Environmental Strategy คือการนำสภาพแวดล้อมมาเป็นส่วนหนึ่งของการออกแบบ

พิจารณา
- Solar
- Wind
- Daylight
- Thermal Comfort
- Rain
- Landscape
- Water
- Energy
ตัวอย่าง:
```
STRONG SUN
     ↓
SOLAR CONTROL
     ↓
Deep Overhang
Vertical Fins
Shading
     ↓
REDUCED SOLAR GAIN
```
หรือ
```
PREVAILING WIND
     ↓
BUILDING ORIENTATION
     ↓
Openings
Courtyard
Ventilation Path
     ↓
NATURAL VENTILATION
```
Environmental Strategy จึงควรเชื่อมตรงจาก Site Analysis → Design Decision

6. Structural Strategy

Structural Strategy คือแนวทางในการกำหนดระบบโครงสร้างให้สอดคล้องกับ Concept, Program และรูปแบบอาคาร

พิจารณา เช่น
- Structural Grid
- Span
- Column
- Beam
- Core
- Load Path
- Structural System
- Long Span
- Transfer Structure
ตัวอย่าง:

Program

ต้องการพื้นที่ Open Plan ขนาดใหญ่

↓

Structural Requirement

ต้องการ Long Span

↓

Structural Strategy

ใช้ระบบโครงสร้างที่ลดเสากลางพื้นที่

อีกตัวอย่าง:

อาคารมี Concept เป็น Modular Architecture

อาจนำไปสู่
```
Module
 ↓
Structural Grid
 ↓
Room Planning
 ↓
Facade Rhythm
 ↓
Construction System
```
ดังนั้น Structural Strategy สามารถเป็นส่วนหนึ่งของ Concept ได้ตั้งแต่ต้น ไม่ควรรอจนถึงขั้นทำแบบโครงสร้างเท่านั้น

7. Material Strategy

Material Strategy คือแนวทางการเลือกและใช้วัสดุให้สอดคล้องกับ Concept, Context และ Performance

พิจารณา
- Material Character
- Durability
- Maintenance
- Climate
- Cost
- Local Material
- Construction Method
- Sustainability
- Tactility
ตัวอย่าง:

Concept

Warm and Natural

Material Strategy
- Timber
- Stone
- Brick
- Natural Texture
หรือ

Concept

Industrial Architecture

Material Strategy
- Exposed Concrete
- Steel
- Glass
- Metal
แต่ Material Strategy ไม่ควรเลือกวัสดุจาก “ความสวย” เพียงอย่างเดียว

ควรพิจารณาด้วยว่า

วัสดุช่วยทำให้ Concept แข็งแรงขึ้นหรือไม่?

8. Passive Design Strategy

Passive Design Strategy คือการออกแบบที่ใช้สภาพแวดล้อมและรูปแบบอาคารเพื่อลดความต้องการพึ่งพาระบบพลังงานเชิงกล โดยเฉพาะเรื่องความร้อน แสง และการระบายอากาศ

กลยุทธ์ที่พบได้บ่อย เช่น
- Building Orientation
- Solar Shading
- Natural Ventilation
- Daylight
- Thermal Mass
- Courtyard
- Landscape
- Cross Ventilation
- Stack Ventilation
ตัวอย่าง:
```
SOLAR ANALYSIS
      ↓
ORIENTATION
      ↓
SHADING
      ↓
REDUCE SOLAR HEAT
      ↓
LOWER COOLING LOAD
```
หรือ
```
WIND
 ↓
OPENINGS
 ↓
CROSS VENTILATION
 ↓
IMPROVED AIR MOVEMENT
```
Passive Design ควรเริ่มตั้งแต่ Massing ไม่ใช่เพิ่มอุปกรณ์ประหยัดพลังงานภายหลัง

9. Sustainability Strategy

Sustainability Strategy มีขอบเขตกว้างกว่า Passive Design

เพราะไม่ได้พิจารณาเฉพาะ Energy แต่ครอบคลุม
- Energy
- Water
- Materials
- Waste
- Landscape
- Carbon
- Mobility
- Resilience
- Lifecycle
- Social Sustainability
ตัวอย่าง:
```
SUSTAINABILITY
      ↓
ENERGY
WATER
MATERIAL
LANDSCAPE
CARBON
MOBILITY
LIFECYCLE
```
ตัวอย่าง Strategy:

ลดการใช้พลังงานด้วย Passive Design

ลดการใช้น้ำด้วย Rainwater Management

ลด Embodied Carbon ด้วยการเลือกวัสดุอย่างเหมาะสม

เพิ่ม Biodiversity ด้วย Landscape Strategy

สิ่งสำคัญคือ Sustainability Strategy ควรมี เป้าหมายที่วัดได้ เมื่อโครงการเข้าสู่ขั้นตอนที่ต้องประเมินจริง

10. Urban Strategy

Urban Strategy คือการมองอาคารไม่ได้เป็นเพียง Object ที่วางอยู่บน Site แต่เป็นส่วนหนึ่งของเมือง

พิจารณา
- Urban Edge
- Street
- Public Space
- Pedestrian
- Connectivity
- Urban Activity
- Public / Private
- Ground Floor
- Density
- Skyline
- Neighborhood
ตัวอย่าง:
```
CITY
 ↓
STREET
 ↓
PUBLIC EDGE
 ↓
GROUND FLOOR
 ↓
PUBLIC SPACE
 ↓
BUILDING
```
ตัวอย่าง Strategy:

“Activate the ground floor to strengthen the relationship between the building and the street.”

สามารถนำไปสู่
- ร้านค้า
- Public Plaza
- Covered Walkway
- Community Space
- Transparent Ground Floor
- Landscape
Urban Strategy จึงช่วยตอบคำถามว่า

“อาคารควรมีความสัมพันธ์กับเมืองอย่างไร?”

Design Strategies ไม่ควรแยกจากกัน

สิ่งสำคัญคือ Strategy ทั้งหมดไม่ได้ทำงานแยกกัน

ตัวอย่างเช่น

Site Strategy

วางอาคารเพื่อรับลม

↓

Massing Strategy

แยก Mass เพื่อสร้างช่องลม

↓

Environmental Strategy

สร้าง Courtyard

↓

Program Strategy

วาง Common Space รอบ Courtyard

↓

Circulation Strategy

สร้าง Circulation Loop รอบ Courtyard

↓

Landscape Strategy

ใช้ Courtyard เป็น Green Space

สิ่งเดียวกันจึงสามารถสร้างผลกระทบต่อหลายระบบ

Strategy Matrix

ในการทำงานจริง สามารถใช้ Matrix เพื่อตรวจสอบความสัมพันธ์ระหว่าง Strategy ต่าง ๆ

Strategy Site Program Environment Form User
Courtyard ✓ ✓ ✓ ✓ ✓
Green Buffer ✓ ✓ ✓ ✓
Public Spine ✓ ✓ ✓ ✓
Solar Shading ✓ ✓ ✓
Modular Grid ✓ ✓ ✓

Matrix ช่วยให้เห็นว่า Strategy ใดมีผลต่อหลายระบบ และช่วยลดการตัดสินใจที่ขัดแย้งกัน

Strategy จาก Analysis

Strategy ที่ดีควรมีที่มาจาก Analysis

ตัวอย่าง:
```
SITE ANALYSIS
      ↓
Finding
      ↓
Problem / Opportunity
      ↓
Design Strategy
```
ตัวอย่างที่ 1
```
West Sun
 ↓
High Heat Gain
 ↓
Constraint
 ↓
Solar Shading Strategy
```
ตัวอย่างที่ 2
```
Good View
 ↓
Opportunity
 ↓
View-Oriented Strategy
```
ตัวอย่างที่ 3
```
Heavy Traffic
 ↓
Noise
 ↓
Buffer Strategy
```
ตัวอย่างที่ 4
```
Existing Tree
 ↓
Landscape Value
 ↓
Preservation Strategy
```
ดังนั้น Strategy ไม่ควรเกิดจากความชอบส่วนตัวเพียงอย่างเดียว แต่ควรมี Evidence รองรับ

Design Strategy → Design Decisions

Strategy ที่ดีต้องสามารถแตกออกเป็น Design Decisions ได้

ตัวอย่าง:

Strategy

Create a Climate Buffer

↓

Design Decisions
- Deep Balcony
- Double Skin
- Shading Device
- Landscape Buffer
- Semi-outdoor Space
หรือ

Strategy

Create Public-to-Private Transition

↓

Design Decisions
- Public Plaza
- Lobby
- Semi-public Space
- Private Zone
นี่คือสิ่งที่ทำให้ Strategy มีประโยชน์ในกระบวนการออกแบบจริง

Design Strategy → Massing

เมื่อ Strategy ชัดแล้ว สามารถนำไปทดลองกับ Massing
```
DESIGN STRATEGY
      ↓
PLACE
      ↓
ROTATE
      ↓
SUBTRACT
      ↓
SHIFT
      ↓
STACK
      ↓
CONNECT
      ↓
MASSING
```
ตัวอย่าง:
```
Need for Courtyard
        ↓
Create Solid Mass
        ↓
Subtract Center
        ↓
Courtyard
        ↓
Orient Spaces Inward
```
Massing จึงไม่ควรเป็นการสุ่มสร้างรูปทรง แต่ควรมี Design Logic

Design Strategy → Schematic Design

หลังจาก Massing แล้ว Strategy จะถูกนำไปพัฒนาเป็น
- Floor Plan
- Section
- Elevation
- Circulation
- Structure
- Facade
- Landscape
- Environmental Systems
ตัวอย่าง:
```
STRATEGY
Public → Private
        ↓
PLAN
Public → Semi-Public → Private
        ↓
SECTION
Public Ground → Private Upper
        ↓
FACADE
Open → Filtered → Closed
```
Strategy จึงช่วยสร้าง Consistency ระหว่าง Drawing ต่าง ๆ

AI กับ Design Strategy

AI สามารถช่วยในขั้นตอน Strategy ได้ดี โดยเฉพาะการ
- วิเคราะห์ทางเลือก
- Generate Strategies
- Compare Strategies
- หา Conflict
- Critique
- Refine
- สรุป Design Logic
แต่ควรใช้ AI ในฐานะ Strategic Design Assistant มากกว่าผู้ตัดสินใจแทนสถาปนิก

AI Strategy Generation

สามารถป้อนข้อมูล
```
Site Analysis
+
Program
+
Client Goals
+
Climate
+
Constraints
```
แล้วให้ AI เสนอ Strategy หลายชุด

ตัวอย่าง:

Option A — Courtyard Strategy

เน้น
- Privacy
- Landscape
- Daylight
- Ventilation
Option B — Linear Spine

เน้น
- Circulation
- Program Organization
- Flexibility
Option C — Cluster Strategy

เน้น
- Human Scale
- Community
- Outdoor Space
จากนั้นสถาปนิกจึงเลือกและพัฒนาต่อ

AI Strategy Comparison

AI สามารถช่วยเปรียบเทียบ Strategy หลายทางเลือกได้

Criteria Courtyard Linear Cluster
Climate High Medium High
Privacy High Medium High
Circulation Medium High Medium
Flexibility Medium High High
Complexity Medium Low High
Site Response High Medium High

คะแนนเหล่านี้ควรเป็น เครื่องมือช่วยคิด ไม่ใช่ข้อสรุปทางวิศวกรรมหรือการประเมินโครงการที่แทนการวิเคราะห์จริง

AI Strategy Critique

อีกวิธีหนึ่งที่มีประโยชน์มากคือให้ AI ทำหน้าที่เป็น Design Critic

ตัวอย่างคำถาม:

Strategy นี้ตอบ Site Analysis อย่างไร?

Strategy นี้สนับสนุน Concept หรือไม่?

มีความขัดแย้งกับ Program หรือไม่?

มีผลต่อ Structure อย่างไร?

มีผลต่อ Cost และ Constructability อย่างไร?

มี Assumption ใดที่ยังไม่ได้ตรวจสอบ?

AI จึงไม่ได้เพียง “คิด Strategy” แต่สามารถช่วย Challenge Strategy

Strategy Refinement

Strategy แรกมักยังไม่สมบูรณ์

สามารถใช้กระบวนการ
```
INITIAL STRATEGY
      ↓
TEST
      ↓
CRITIQUE
      ↓
CONFLICT
      ↓
REFINE
      ↓
FINAL STRATEGY
```
ตัวอย่าง:

Strategy: เปิดอาคารรับลมทุกด้าน

เมื่อทดสอบกับ
- Noise
- Rain
- Solar
- Privacy
อาจพบว่าการเปิดทุกด้านสร้างปัญหา

จึง Refinement เป็น

เปิดรับลมจากทิศที่เหมาะสม พร้อมใช้ Buffer ในด้านที่มี Noise และแดดแรง

Strategy จึงมีความเฉพาะเจาะจงและสมเหตุสมผลมากขึ้น

Design Strategy Checklist

ก่อนเข้าสู่ Concept Development ควรตรวจสอบว่า

Site
- Site Strategy
- Orientation
- Access
- View
- Noise
- Existing Context
Program
- Program Strategy
- Zoning
- Adjacency
- Public / Private
- Service
Form
- Massing Strategy
- Height
- Density
- Solid / Void
- Courtyard / Open Space
Movement
- Circulation Strategy
- Pedestrian
- Vehicle
- Service
- Emergency
Environment
- Environmental Strategy
- Passive Design
- Solar
- Wind
- Daylight
- Landscape
Technical
- Structural Strategy
- Material Strategy
- Construction Logic
Sustainability
- Energy
- Water
- [Materials
- Carbon
- Lifecycle
- Resilience
Urban
- Urban Edge
- Public Space
- Pedestrian
- Ground Floor
- Urban Connectivity
Design Strategy Framework

สามารถสรุป Framework สำหรับงานออกแบบได้ดังนี้
```
                  DESIGN CONCEPT
                        ↓
                ┌───────────────┐
                │ DESIGN STRATEGY│
                └───────────────┘
                        ↓
      ┌─────────┬─────────┬─────────┐
      ↓         ↓         ↓         ↓
     SITE     PROGRAM    FORM    ENVIRONMENT
      ↓         ↓         ↓         ↓
   ACCESS     ZONING    MASSING   CLIMATE
   VIEW       FLOW      VOLUME    SOLAR
   CONTEXT    SPACE     VOID      WIND
      ↓         ↓         ↓         ↓
      └─────────┴─────────┴─────────┘
                        ↓
              ARCHITECTURAL DESIGN
```
จากนั้นค่อยนำไปเชื่อมกับ

Structure + Material + Sustainability + Urban Design

สรุป

Design Strategy คือขั้นตอนที่ทำให้ Design Concept กลายเป็นวิธีการออกแบบที่สามารถนำไปใช้จริง

ความสัมพันธ์สามารถสรุปได้ว่า

Site Analysis tells us what is happening.

Design Concept tells us what we believe the architecture should be.

Design Strategy tells us how we will achieve it.

และจากนั้น

Concept + Strategy → Design Decisions

Design Decisions → Architecture

ดังนั้น Workflow สำคัญคือ
```
SITE RESEARCH
      ↓
SITE ANALYSIS
      ↓
DESIGN CONCEPT
      ↓
DESIGN STRATEGY
      ↓
DESIGN DECISIONS
      ↓
MASSING
      ↓
SPACE
      ↓
ARCHITECTURE
```
Design Strategy ที่ดีควรมี 4 คุณสมบัติสำคัญ:

1. มีที่มา
มาจาก Site, Program, Client หรือ Context

2. มีเหตุผล
อธิบายได้ว่าทำไมต้องเลือก Strategy นี้

3. นำไปใช้ได้
สามารถเปลี่ยนเป็น Massing, Plan, Section, Facade หรือ System ได้

4. ตรวจสอบได้
สามารถนำไป Test, Compare และ Refine ได้

และเมื่อใช้ AI สิ่งที่น่าสนใจที่สุดไม่ใช่เพียงการถามว่า

“ช่วยคิด Design Strategy ให้หน่อย”

แต่คือการใช้ AI เป็นกระบวนการ

Generate → Compare → Critique → Test → Refine

เพื่อให้สถาปนิกสามารถสำรวจทางเลือกได้มากขึ้นและเร็วขึ้น โดยยังคงให้ Architectural Judgment เป็นผู้ตัดสินใจขั้นสุดท้าย
สิงหาคม 21, 2026
CD01. – Design Concept
Design Concept คืออะไร? วิธีพัฒนาแนวคิดให้กลายเป็น Architecture

Design Concept หรือ แนวคิดในการออกแบบสถาปัตยกรรม คือกรอบความคิดหลักที่ใช้กำหนดทิศทางของการออกแบบ ตั้งแต่การจัดพื้นที่ รูปทรงอาคาร วัสดุ แสง ลม ไปจนถึงประสบการณ์ของผู้ใช้งาน

Concept ที่ดีไม่ได้มีหน้าที่เพียงตอบว่า

“อาคารหน้าตาเป็นอย่างไร?”

แต่ควรตอบว่า

“ทำไมอาคารจึงต้องเป็นแบบนั้น?”

และที่สำคัญกว่านั้นคือ

“แนวคิดนี้สามารถนำไปใช้ตัดสินใจเรื่องอื่น ๆ ของโครงการได้อย่างไร?”

ตัวอย่างเช่น หาก Concept ของบ้านคือ

“บ้านที่โอบล้อมสวน”

Concept นี้ไม่ควรจบอยู่ที่ภาพบ้านล้อมต้นไม้ แต่สามารถนำไปพัฒนาต่อเป็น
- จัดพื้นที่รอบ Courtyard
- ให้พื้นที่หลักหันเข้าหาสวน
- สร้าง Visual Connection กับ Landscape
- ใช้ Landscape เป็นตัวควบคุม Privacy
- ใช้ Courtyard ช่วยนำแสงและลมเข้าสู่อาคาร
ดังนั้น

Concept ที่ดีต้องสามารถสร้าง Design Decisions ได้

Design Concept อยู่ตรงไหนใน Design Process?

หลังจากผ่าน Pre-Design และ Site Analysis แล้ว สามารถเข้าสู่กระบวนการ Concept ได้ดังนี้
```
SITE RESEARCH
      ↓
CLIENT BRIEF
      ↓
PROGRAM
      ↓
FEASIBILITY
      ↓
SITE ANALYSIS
      ↓
DESIGN CONCEPT
      ↓
DESIGN STRATEGY
      ↓
CONCEPT DEVELOPMENT
      ↓
MASSING
      ↓
SCHEMATIC DESIGN
```
แต่ในความเป็นจริง Concept ไม่ได้เกิดขึ้นจากขั้นตอนใดขั้นตอนหนึ่งเท่านั้น

Concept มักเกิดจากการสังเคราะห์
```
SITE
+
PROGRAM
+
CLIENT
+
CONTEXT
+
CLIMATE
+
ARCHITECT'S IDEA
        ↓
DESIGN CONCEPT
```
ดังนั้น Concept ที่แข็งแรงมักมี เหตุผลรองรับจากโครงการจริง

Design Idea กับ Design Concept ต่างกันอย่างไร?

สองคำนี้มักถูกใช้แทนกัน แต่สามารถแยกให้ชัดได้

Design Idea

คือ ความคิดหรือข้อสังเกตหนึ่ง

เช่น

“อยากให้บ้านมีสวนตรงกลาง”

Design Concept

คือการนำ Idea นั้นมาพัฒนาเป็นระบบความคิด

เช่น

“Courtyard as the Heart of the House”

แล้วนำไปกำหนด
- Space Organization
- Circulation
- Orientation
- Daylight
- Ventilation
- Privacy
- Landscape
ดังนั้น

Idea = จุดเริ่มต้น

แต่

Concept = ระบบความคิดที่นำไปใช้ต่อได้

1. Design Idea

Design Idea คือความคิดตั้งต้นที่นำไปสู่การออกแบบ

Idea อาจเกิดจาก
- Site
- Client
- Program
- Context
- Climate
- Culture
- Technology
- Material
- User Experience
ตัวอย่าง:

Site-driven Idea

เปิดอาคารเข้าหาวิว

Climate-driven Idea

ใช้พื้นที่กึ่งภายนอกเป็นตัวกลางระหว่างภายในกับภายนอก

Program-driven Idea

จัดพื้นที่ตามระดับความเป็นส่วนตัว

Social Idea

สร้างพื้นที่กลางสำหรับการพบปะ

Idea ไม่จำเป็นต้องสมบูรณ์ตั้งแต่แรก

สิ่งสำคัญคือสามารถนำไป Explore และ Develop ต่อได้

2. Design Philosophy

Design Philosophy คือหลักคิดหรือมุมมองที่อยู่เบื้องหลังการออกแบบ

ตัวอย่างเช่น

Architecture should strengthen the relationship between people and nature.

หรือ

อาคารควรสร้างความสัมพันธ์ระหว่างผู้ใช้งานกับธรรมชาติ

จาก Philosophy นี้สามารถแตกเป็น Design Principles เช่น
- Natural Light
- Natural Ventilation
- Visual Connection
- Outdoor Space
- Landscape Integration
Design Philosophy จึงมีลักษณะเป็น หลักคิดระดับกว้าง

ในขณะที่ Design Concept จะมีความเฉพาะเจาะจงกับโครงการมากกว่า

3. Design Narrative

Design Narrative คือเรื่องราวที่อธิบายว่าแนวคิดของโครงการพัฒนาไปอย่างไร

Narrative ที่ดีช่วยตอบคำถามว่า

“ทำไม Architecture จึงกลายมาเป็นแบบนี้?”

ตัวอย่าง:
```
Busy Urban Context
       ↓
Need for Privacy
       ↓
Create Inner Courtyard
       ↓
Orient Main Spaces Inward
       ↓
Landscape Becomes the Center
       ↓
Architecture Creates a Quiet Inner World
```
Narrative แบบนี้ช่วยให้ Concept มี Logic มากกว่าการใช้คำสวย ๆ เช่น

“Harmony”

“Balance”

“Nature”

โดยไม่ได้อธิบายว่าคำเหล่านั้นเปลี่ยนเป็น Architecture อย่างไร

4. Concept Statement

Concept Statement คือข้อความสั้น ๆ ที่สรุปแนวคิดหลักของโครงการ

ตัวอย่าง:

“The house is organized around a central courtyard that connects living spaces with nature while creating privacy from the surrounding neighborhood.”

หรือในภาษาไทย:

“บ้านถูกจัดวางรอบพื้นที่สวนกลาง เพื่อเชื่อมพื้นที่อยู่อาศัยกับธรรมชาติ พร้อมสร้างความเป็นส่วนตัวจากบริบทโดยรอบ”

Concept Statement ที่ดีควรตอบอย่างน้อย

What + Why + How

เช่น

What: Central Courtyard
Why: Privacy + Nature
How: Organize spaces around the courtyard

ไม่จำเป็นต้องยาว แต่ต้องมีสาระเพียงพอที่จะนำไปพัฒนาต่อ

5. Design Metaphor

Design Metaphor คือการใช้สิ่งหนึ่งเป็นตัวแทนในการอธิบายหรือกระตุ้นแนวคิดการออกแบบ

เช่น
- Tree
- River
- Nest
- Forest
- Rock
- Layer
- Fold
- Bridge
- Garden
- Filter
ตัวอย่าง:

“The building behaves like a tree.”

จากนั้นต้องแปล Metaphor ให้เป็น Architecture
```
TREE
 ↓
Trunk
 ↓
Central Circulation

Branches
 ↓
Circulation Paths

Canopy
 ↓
Roof / Shading

Roots
 ↓
Structure / Ground Connection
```
ข้อควรระวังคืออย่าให้ Metaphor กลายเป็นเพียงการทำอาคารให้ “เหมือนต้นไม้”

Metaphor ที่ดีควรนำไปสู่ Architectural Logic

6. Design Theme

Design Theme คือธีมหรือคำหลักที่ใช้สร้างเอกภาพของงานออกแบบ

ตัวอย่าง:
- Tropical Modern
- Urban Oasis
- Industrial Heritage
- Soft Minimalism
- Connected Community
Theme สามารถช่วยกำหนด
- Material
- Color
- Form
- Landscape
- Lighting
- Graphic Language
แต่ Theme อย่างเดียวไม่ถือเป็น Concept ที่สมบูรณ์

ตัวอย่างเช่น

“Tropical Modern”

เป็น Theme

แต่ต้องอธิบายต่อว่า

Tropical Architecture ถูกนำมาใช้กับโครงการนี้อย่างไร?

7. Architectural Language

Architectural Language คือชุดขององค์ประกอบทางสถาปัตยกรรมที่ทำให้งานมีลักษณะและเอกลักษณ์ที่สอดคล้องกัน

ประกอบด้วย
- Form
- Proportion
- Geometry
- Rhythm
- Material
- Opening
- Structure
- Detail
- Light
- Landscape
ตัวอย่าง:
```
DESIGN CONCEPT
"Layered Privacy"
       ↓
ARCHITECTURAL LANGUAGE
       ↓
Layered Mass
Deep Recess
Screens
Courtyard
Filtered Light
```
ดังนั้น Architectural Language คือการทำให้ Concept สามารถ มองเห็นและสัมผัสได้ใน Architecture

8. Spatial Concept

Spatial Concept คือแนวคิดเกี่ยวกับการจัดและประสบการณ์ของพื้นที่

อาจเกี่ยวกับ
- Sequence
- Hierarchy
- Compression / Expansion
- Open / Closed
- Public / Private
- Inside / Outside
- Center / Edge
- Vertical Connection
- Threshold
ตัวอย่าง:

“From compressed entrance to an expansive courtyard.”

สามารถแปลงเป็น Spatial Sequence:
```
Street
 ↓
Narrow Entrance
 ↓
Transition Space
 ↓
Open Courtyard
 ↓
Living Space
 ↓
Garden
```
นี่คือการทำให้ Concept กลายเป็น User Experience

9. Environmental Concept

Environmental Concept คือแนวคิดที่ใช้สภาพแวดล้อมเป็นส่วนหนึ่งของ Architecture

เช่น
- Solar Control
- Natural Ventilation
- Daylight
- Rain
- Landscape
- Thermal Comfort
- Water
- Energy
ตัวอย่าง:

“The building uses a shaded courtyard to moderate the relationship between indoor and outdoor spaces.”

จาก Concept สามารถพัฒนาเป็น
```
Climate
 ↓
Environmental Analysis
 ↓
Design Concept
 ↓
Shading
Courtyard
Ventilation
Landscape
 ↓
Passive Design Strategy
```
จุดสำคัญคือ Environmental Concept ควรเชื่อมกับข้อมูลจาก Site Analysis

10. Social Concept

Social Concept คือแนวคิดที่มุ่งสร้างความสัมพันธ์ระหว่างผู้คนผ่าน Architecture

เช่น
- Community
- Interaction
- Collaboration
- Privacy
- Inclusivity
- Shared Space
- Social Interaction
ตัวอย่าง:

“Architecture as a platform for interaction.”

อาจนำไปสู่
- Central Common Space
- Shared Courtyard
- Visual Connection
- Flexible Space
- Community Plaza
ดังนั้น Social Concept ไม่ใช่เพียงการเขียนว่า

“ต้องการสร้าง Community”

แต่ต้องอธิบายว่า

Architecture จะทำให้ผู้คนเกิด Interaction ได้อย่างไร?

Concept ที่ดีควรมี Source

แนวคิดที่ดีมักไม่ได้เกิดขึ้นจากจินตนาการเพียงอย่างเดียว

สามารถสร้าง Concept จากข้อมูลของโครงการได้
```
SITE
 ↓
Good View
 ↓
Opportunity

PROGRAM
 ↓
Public + Private
 ↓
Need for Separation

CLIMATE
 ↓
Strong Sun
 ↓
Need for Shading

CLIENT
 ↓
Love Nature
 ↓
Landscape Priority

        ↓

DESIGN CONCEPT

"Layered Garden"
```
นี่ทำให้ Concept สามารถอธิบายได้ว่า

Concept มาจากอะไร

และ

Concept แก้ปัญหาอะไร

Concept ไม่ใช่ Form

หนึ่งในความเข้าใจผิดที่พบบ่อยคือ

“Concept = รูปทรงอาคาร”

เช่น

“Concept คืออาคารรูปใบไม้”

สิ่งนี้อาจเป็นเพียง Form Idea

แต่ Concept ที่แข็งแรงกว่าคือ

“ใบไม้เป็นระบบที่รวบรวมและกระจายพลังงานอย่างมีประสิทธิภาพ”

แล้วจึงนำหลักการนั้นไปสู่
- Shading
- Orientation
- Layering
- Structure
- Surface
ดังนั้น

อย่าเริ่มจาก “อาคารหน้าตาเหมือนอะไร?”

แต่ลองเริ่มจาก

“Architecture ควรทำอะไร?”

แล้วค่อยค้นหารูปแบบที่ตอบโจทย์

Concept → Strategy

Concept และ Design Strategy มีความสัมพันธ์กัน แต่ไม่เหมือนกัน

Concept

What is the central idea?

Strategy

How will we achieve it?

ตัวอย่าง:

Concept

Architecture as an Urban Oasis

Strategies
- Create Green Buffer
- Reduce Noise
- Introduce Courtyard
- Orient Views Inward
- Provide Shaded Public Space
ดังนั้น
```
CONCEPT
Urban Oasis
     ↓
STRATEGIES
Landscape Buffer
Courtyard
Shade
Water
     ↓
ARCHITECTURE
```
AI กับ Design Concept

AI มีประโยชน์มากในขั้นตอน Concept แต่ควรใช้เพื่อ ขยายความเป็นไปได้ของการคิด ไม่ใช่ให้ AI เลือก Concept แทนสถาปนิก

AI เหมาะกับ
- Generate
- Explore
- Critique
- Compare
- Refine
- Communicate
1. Concept Generation

AI สามารถช่วยสร้าง Concept จากข้อมูลโครงการ

Input:
```
Site Analysis
+
Client Brief
+
Program
+
Climate
+
Project Goals
```
AI สามารถเสนอ Concept Directions เช่น
```
01 Urban Oasis
02 Layered Privacy
03 Living Courtyard
04 Filtered Landscape
05 Connected Community
```
แต่ไม่ควรหยุดเพียงการสร้าง “ชื่อ Concept”

ต้องถามต่อว่า

Concept นี้จะเปลี่ยนเป็น Architecture อย่างไร?

2. Concept Exploration

เมื่อได้ Concept แล้ว AI สามารถช่วยแตก Concept ออกเป็นหลายทิศทาง

ตัวอย่าง:

Concept

Layered Privacy

สามารถ Explore ได้เป็น

Option A

Layered Mass

Option B

Landscape Buffer

Option C

Screen / Filter

Option D

Spatial Sequence

จากนั้นนำแต่ละ Option ไปพัฒนาเป็น
- Diagram
- Massing
- Material
- Space
- Experience
3. Concept Critique

AI สามารถทำหน้าที่เป็น Design Critic ได้

ตัวอย่าง Prompt:

วิเคราะห์ Concept นี้ในฐานะ Architectural Design Critic โดยตรวจสอบความสัมพันธ์ระหว่าง Site, Program, Climate, User Experience และ Form พร้อมระบุจุดแข็ง จุดอ่อน ความขัดแย้ง และคำถามที่สถาปนิกควรพิจารณาเพิ่มเติม

สิ่งที่ต้องการจาก AI ไม่ใช่คำตอบว่า

“สวย / ไม่สวย”

แต่ต้องการ

“Concept นี้มี Logic แข็งแรงแค่ไหน?”

4. Concept Refinement

หลังจาก Critique แล้ว AI สามารถช่วยปรับ Concept ให้ชัดขึ้น

ตัวอย่าง:
```
INITIAL IDEA

"Building connected to nature"

        ↓

CRITIQUE

Too broad
No clear architectural mechanism

        ↓

REFINEMENT

"Architecture organized around
shaded landscape courtyards"

        ↓

DESIGN STRATEGIES

Courtyard
Shading
Visual Connection
Natural Ventilation
```
จาก Concept ที่กว้าง

“Connected to Nature”

จึงกลายเป็น Concept ที่สามารถออกแบบต่อได้จริง

5. AI Concept Statement

AI สามารถช่วยเขียน Concept Statement ได้หลายระดับ

Short

“A building shaped around a shaded central courtyard.”

Design Presentation

“The project is organized around a shaded central courtyard that connects indoor spaces with landscape while providing privacy and climatic comfort.”

Architectural Narrative

อธิบายที่มาของ Concept ตั้งแต่

Site → Problem → Idea → Strategy → Architecture

แต่สถาปนิกควรเป็นผู้ตรวจสอบว่า Statement นั้นตรงกับ Design จริงหรือไม่

6. AI Design Narrative

AI สามารถช่วยเปลี่ยน Concept ให้กลายเป็นเรื่องราวสำหรับ
- Client Presentation
- Design Report
- Portfolio
- Competition
- Website
- Project Documentation
โครงสร้างที่เหมาะสมคือ
```
CONTEXT
   ↓
PROBLEM
   ↓
INSIGHT
   ↓
CONCEPT
   ↓
DESIGN STRATEGY
   ↓
SPATIAL EXPERIENCE
   ↓
ARCHITECTURAL RESULT
```
ตัวอย่าง:

Site ตั้งอยู่ในบริบทเมืองที่มีความหนาแน่นและเสียงรบกวนสูง

↓

จึงต้องการพื้นที่ภายในที่สงบ

↓

แนวคิดจึงเกิดจากการสร้าง Inner Garden

↓

อาคารถูกจัดวางรอบ Courtyard

↓

พื้นที่สีเขียวทำหน้าที่เป็นทั้ง Buffer และ Social Space

↓

Architecture จึงสร้าง “Quiet Inner World” ภายในบริบทเมือง

นี่ทำให้ Presentation สามารถเล่า Design Logic ได้อย่างเป็นระบบ

วิธีตรวจสอบว่า Concept แข็งแรงหรือไม่

ลองถามคำถาม 7 ข้อนี้

1. Concept มาจากอะไร?

Site? Program? Client? Context?

2. Concept แก้ปัญหาอะไร?

มีเหตุผลหรือไม่?

3. Concept เปลี่ยน Space อย่างไร?

Spatial Organization เปลี่ยนหรือไม่?

4. Concept เปลี่ยน Form อย่างไร?

Massing หรือ Geometry ได้รับผลอย่างไร?

5. Concept เปลี่ยน Experience อย่างไร?

ผู้ใช้งานรู้สึกหรือใช้งานต่างจากเดิมอย่างไร?

6. Concept เปลี่ยน Environment อย่างไร?

แสง ลม ความร้อน หรือ Landscape ได้รับผลอย่างไร?

7. ถ้าตัด Concept ออก Design ยังเหมือนเดิมหรือไม่?

ถ้า “เหมือนเดิมทุกอย่าง”

อาจหมายความว่า Concept ยังไม่ได้มีผลต่อ Architecture จริง

Concept Evaluation Matrix

สามารถใช้ Matrix ช่วยประเมิน Concept หลายทางเลือก

Criteria Concept A Concept B Concept C
Site Response 5 4 3
Program Fit 4 5 3
Climate Response 5 3 4
User Experience 4 5 4
Identity 4 4 5
Feasibility 5 4 3
Development Potential 4 4 3

ไม่จำเป็นต้องใช้คะแนนเป็นตัวตัดสินอัตโนมัติ แต่ Matrix ช่วยให้ทีมออกแบบ เห็น Trade-off ระหว่างแนวคิดต่าง ๆ

Design Concept Workflow

สำหรับงานจริงสามารถใช้ Workflow นี้
```
01
COLLECT
Site + Brief + Program

        ↓

02
IDENTIFY
Key Issues

        ↓

03
GENERATE
Design Ideas

        ↓

04
SYNTHESIZE
Design Concept

        ↓

05
EXPLORE
Multiple Directions

        ↓

06
CRITIQUE
Test the Logic

        ↓

07
REFINE
Strengthen Concept

        ↓

08
TRANSLATE
Concept → Strategy

        ↓

09
DEVELOP
Space + Form + Experience

        ↓

10
COMMUNICATE
Statement + Narrative
```
AI Design Concept Workflow

เมื่อนำ AI เข้ามาช่วย สามารถทำเป็น
```
SITE ANALYSIS
+
CLIENT BRIEF
+
PROGRAM
       ↓
       AI
       ↓
CONCEPT GENERATION
       ↓
3–5 DIRECTIONS
       ↓
CONCEPT CRITIQUE
       ↓
ARCHITECT SELECTION
       ↓
CONCEPT REFINEMENT
       ↓
DESIGN STRATEGY
       ↓
MASSING / SPATIAL EXPLORATION
```
สิ่งสำคัญคือให้ AI สร้างทางเลือกและวิจารณ์ มากกว่าการให้ AI บอกว่า

“นี่คือ Concept ที่ดีที่สุด”

เพราะ Concept เป็นเรื่องของการตีความและการตัดสินใจทางสถาปัตยกรรม

Design Concept Checklist

ก่อนเข้าสู่ Concept Development ควรตรวจสอบว่า
- มี Design Idea
- ระบุ Design Philosophy
- มี Concept ที่ชัดเจน
- อธิบาย Concept Statement ได้
- มี Design Narrative
- รู้ว่า Concept มาจาก Site / Program / Context อย่างไร
- มี Architectural Language
- มี Spatial Concept
- มี Environmental Response
- มี Social Response
- Concept สามารถนำไปสร้าง Design Strategy ได้
- สามารถอธิบายได้ว่า Concept เปลี่ยน Architecture อย่างไร
สรุป

Design Concept ไม่ใช่คำสวย ๆ และไม่ใช่เพียงรูปทรงของอาคาร

Concept ที่ดีคือ

A clear idea that guides architectural decisions.

หรือ

แนวคิดที่สามารถนำไปกำกับการตัดสินใจทางสถาปัตยกรรมได้จริง

กระบวนการสามารถสรุปได้ว่า
```
SITE
+
PROGRAM
+
CLIENT
+
CONTEXT
+
CLIMATE
        ↓
DESIGN IDEA
        ↓
DESIGN CONCEPT
        ↓
DESIGN STRATEGY
        ↓
SPATIAL CONCEPT
        ↓
ARCHITECTURAL LANGUAGE
        ↓
FORM + SPACE + EXPERIENCE
```
และเมื่อใช้ AI:

Generate → Explore → Critique → Refine → Develop

AI สามารถช่วยให้สถาปนิกสร้างและทดสอบแนวคิดได้เร็วขึ้น แต่หัวใจของกระบวนการยังคงเป็น Architectural Judgment

เพราะเป้าหมายของ AI ในขั้นตอน Concept ไม่ควรเป็น

“ให้ AI คิดแบบให้เรา”

แต่ควรเป็น

“ใช้ AI ช่วยให้เราคิดได้มากขึ้น เห็นทางเลือกมากขึ้น และทดสอบความคิดของเราได้เร็วขึ้น”

ท้ายที่สุด Design Concept ที่ดีที่สุดไม่จำเป็นต้องเป็น Concept ที่ “แปลกที่สุด”

แต่คือ Concept ที่สามารถเชื่อม

Site → Program → User → Environment → Architecture

เข้าด้วยกันอย่างมีเหตุผล และสามารถพัฒนาไปเป็น Architecture ที่จับต้องได้จริง
สิงหาคม 21, 2026
CONCEPT DESIGN (CD)
สิงหาคม 21, 2026

Criteria	Option A	Option B	Option C
Site Response	4	5	3
Program Fit	5	4	4
Circulation	4	5	3
Solar	3	5	4
Wind	4	4	3
Efficiency	5	3	4
Identity	3	4	5
Complexity	Low	Medium	High

Criteria	Option A	Option B	Option C
Site Response	5	4	3
Program	4	5	4
Environment	5	3	4
Circulation	4	5	3
Identity	4	4	5
Feasibility	4	5	3

Criteria	A	B	C
Site Response	5	4	4
Program Fit	4	5	4
Climate	5	3	4
Circulation	4	5	3
Cost	4	5	3
Identity	4	4	5

Strategy	Site	Program	Environment	Form	User
Courtyard	✓	✓	✓	✓	✓
Green Buffer	✓		✓	✓	✓
Public Spine	✓	✓		✓	✓
Solar Shading	✓		✓	✓
Modular Grid		✓		✓	✓

Criteria	Courtyard	Linear	Cluster
Climate	High	Medium	High
Privacy	High	Medium	High
Circulation	Medium	High	Medium
Flexibility	Medium	High	High
Complexity	Medium	Low	High
Site Response	High	Medium	High

Criteria	Concept A	Concept B	Concept C
Site Response	5	4	3
Program Fit	4	5	3
Climate Response	5	3	4
User Experience	4	5	4
Identity	4	4	5
Feasibility	5	4	3
Development Potential	4	4	3

Site Analysis คืออะไร?
วิธีวิเคราะห์ที่ดินเพื่อเปลี่ยนข้อมูลให้เป็น Design Strategy

Site Analysis หรือ การวิเคราะห์พื้นที่โครงการ คือกระบวนการนำข้อมูลที่ได้จาก Site Research มาวิเคราะห์เพื่อทำความเข้าใจว่า สภาพแวดล้อมของพื้นที่มีผลต่อการออกแบบอาคารอย่างไร

ถ้า Site Research คือการถามว่า

“Site มีอะไรอยู่บ้าง?”

Site Analysis จะถามต่อว่า

“สิ่งเหล่านั้นมีผลต่อการออกแบบอย่างไร?”

ตัวอย่างเช่น Site Research พบว่า

ด้านทิศตะวันตกได้รับแดดช่วงบ่าย

Site Analysis ต้องวิเคราะห์ต่อว่า

แดดช่วงบ่ายเป็น Constraint ต่ออาคารอย่างไร?

และอาจนำไปสู่ Design Implication เช่น

ลดช่องเปิดด้านตะวันตก → เพิ่ม Shading → วางพื้นที่ Service เป็น Buffer → เปิด View ทางทิศเหนือแทน

ดังนั้น Site Analysis ไม่ใช่เพียงการทำ Diagram ให้สวย แต่คือการเปลี่ยน ข้อมูล Site ให้กลายเป็น Design Intelligence

Site Research กับ Site Analysis ต่างกันอย่างไร?

สองขั้นตอนนี้มีความสัมพันธ์กัน แต่ไม่เหมือนกัน

Site Research

เน้น Collect Information

เช่น

Site Location
Climate
Sun Path
Wind
Transportation
Existing Buildings
Regulations
Surrounding Activities

Site Analysis

เน้น Interpret Information

เช่น

Solar Exposure
Wind Direction
Noise Source
View Potential
Access Conflict
Vegetation Value
Development Constraint

สรุปง่าย ๆ:

SITE RESEARCH
      ↓
ข้อมูลคืออะไร?
      ↓
SITE ANALYSIS
      ↓
ข้อมูลนั้นหมายความว่าอะไร?
      ↓
DESIGN IMPLICATION
      ↓
เราควรออกแบบอย่างไร?

Site Analysis อยู่ตรงไหนใน Design Process?

ในกระบวนการออกแบบสามารถวางได้ดังนี้

Pre-Design
    ↓
Site Research
    ↓
Client Brief
    ↓
Program
    ↓
Feasibility
    ↓
Site Analysis
    ↓
Design Strategy
    ↓
Concept Design

Site Analysis จึงเป็นหนึ่งในขั้นตอนสำคัญก่อนเริ่ม Concept Design

เพราะ Concept ที่ดีควรมีที่มาจาก

Site + Program + Context + Strategy

ไม่ใช่เกิดจากรูปทรงที่สวยเพียงอย่างเดียว

1. Site Forces

Site Forces คือแรงหรือปัจจัยต่าง ๆ ที่มีอิทธิพลต่อพื้นที่และการออกแบบอาคาร

สามารถแบ่งได้เป็นหลายประเภท

Environmental Forces

Sun
Wind
Rain
Temperature
Humidity

Physical Forces

Topography
Existing Buildings
Vegetation
Roads
Infrastructure

Urban Forces

Pedestrian Flow
Traffic
Noise
Activities
Views
Neighboring Buildings

Regulatory Forces

Setback
FAR
Site Coverage
Height
Access
Parking

Site Analysis ที่ดีควรพยายามค้นหา

“อะไรคือแรงหลักที่กำลังผลักหรือจำกัดการออกแบบ?”

2. Solar Analysis

Solar Analysis คือการวิเคราะห์ผลกระทบของแสงแดดต่อ Site และอาคาร

ควรพิจารณา

Sun Path
Solar Orientation
Morning Sun
Afternoon Sun
Seasonal Changes
Solar Exposure
Shadow

ตัวอย่างเช่น

EAST
☀ Morning Sun

SOUTH
☀ High Solar Exposure

WEST
☀ Strong Afternoon Sun

NORTH
☀ Lower Direct Solar Exposure

ในบริบทประเทศไทย การวิเคราะห์แดดควรพิจารณา ทิศทางดวงอาทิตย์ในแต่ละฤดูกาลและลักษณะพื้นที่จริง ไม่ควรใช้กฎง่าย ๆ ว่า “ทิศหนึ่งดี อีกทิศหนึ่งไม่ดี” โดยไม่ตรวจสอบข้อมูล

3. Wind Analysis

Wind Analysis คือการศึกษาทิศทาง ความเร็ว และรูปแบบการไหลของลมที่มีผลต่อ Site

สิ่งที่ควรพิจารณา เช่น

Prevailing Wind
Seasonal Wind
Wind Direction
Wind Speed
Building Obstacles
Open Areas
Wind Corridor

ตัวอย่าง:

       WIND →
                   ┌────────┐
                   │Building│
                   └────────┘
                         ↓
                  Wind Disturbance

อาคารรอบข้างอาจ

Block Wind
Channel Wind
Accelerate Wind
Create Turbulence

ดังนั้นการวิเคราะห์ Wind ไม่ควรดูเฉพาะข้อมูลสภาพอากาศ แต่ควรดู Urban Form รอบ Site ด้วย

4. Climate Analysis

Climate Analysis คือการวิเคราะห์สภาพภูมิอากาศที่เกี่ยวข้องกับการออกแบบ

เช่น

Temperature
Humidity
Rainfall
Solar Radiation
Wind
Seasonal Variation

คำถามสำคัญคือ

Climate ของพื้นที่ควรเปลี่ยนเป็น Architectural Response อย่างไร?

ตัวอย่าง:

Hot
 ↓
Shading

Humid
 ↓
Ventilation

Heavy Rain
 ↓
Drainage / Roof Strategy

Strong Sun
 ↓
Solar Control

Climate Analysis จึงควรนำไปสู่ Passive Design Strategy มากกว่าการแสดงข้อมูลเพียงอย่างเดียว

5. Views

View Analysis คือการวิเคราะห์ว่าจาก Site มี

Good View
Bad View
Important View
Potential View
Obstructed View

อะไรบ้าง

ตัวอย่าง:

         GOOD VIEW
             ↓
       ┌───────────┐
       │           │
       │   SITE    │
       │           │
       └───────────┘
             ↑
         BAD VIEW

จากนั้นสามารถนำไปใช้กับ

Building Orientation
Window
Balcony
Living Area
Public Space

เป็นต้น

6. Noise

Noise Analysis คือการวิเคราะห์แหล่งกำเนิดเสียงและระดับผลกระทบต่อ Site

แหล่งเสียงอาจมาจาก

Main Road
Highway
Railway
Airport
Commercial Activity
Construction
Neighboring Buildings

ตัวอย่าง:

MAIN ROAD
════════════════════
       🔊 🔊 🔊
           ↓
      NOISE ZONE

      ┌─────────┐
      │   SITE  │
      └─────────┘

Design Response อาจเป็น

วาง Service Space เป็น Buffer
ลดช่องเปิด
เพิ่ม Acoustic Treatment
วางพื้นที่ Private ไว้ด้านเงียบ

ดังนั้น Noise Analysis ต้องจบด้วย Design Response

7. Access

Access Analysis คือการวิเคราะห์การเข้าถึง Site

ควรพิจารณา

Vehicular Access
Pedestrian Access
Service Access
Emergency Access
Public Transport
Existing Driveway

คำถามสำคัญคือ

รถควรเข้า Site ตรงไหน?

คนควรเข้าตรงไหน?

Service ควรเข้าตรงไหน?

Emergency ต้องเข้าถึงอย่างไร?

8. Circulation

Circulation Analysis เป็นการวิเคราะห์ Flow ของคน รถ และ Service

สามารถแยกเป็น

Pedestrian

Street
  ↓
Entrance
  ↓
Lobby

Vehicle

Street
  ↓
Driveway
  ↓
Parking

Service

Loading
  ↓
Service Area
  ↓
Back of House

การวิเคราะห์ Circulation ช่วยป้องกันปัญหาที่ Flow ต่าง ๆ ตัดกันโดยไม่จำเป็น

9. Existing Vegetation

ต้นไม้เดิมไม่ควรถูกมองว่าเป็นเพียงสิ่งที่ต้อง “เก็บหรือเอาออก”

ควรวิเคราะห์ว่าแต่ละต้นมีคุณค่าอย่างไร

เช่น

Mature Tree
Shade Tree
Landscape Value
Ecological Value
View Value
Existing Canopy

จากนั้นแบ่งเป็น

KEEP
↓

PROTECT
↓

INTEGRATE
↓

RELOCATE
↓

REMOVE

ในหลายโครงการ ต้นไม้ขนาดใหญ่สามารถกลายเป็น Design Generator ได้ ไม่ใช่เพียง Site Constraint

10. Existing Buildings

ต้องวิเคราะห์อาคารเดิมทั้งภายใน Site และรอบ Site

พิจารณา

Height
Mass
Orientation
Setback
Use
Condition
Shadow
Privacy
Access

อาคารข้างเคียงอาจสร้างทั้ง

Constraint

เช่น บังวิว

และ

Opportunity

เช่น สร้าง Urban Edge หรือช่วยบังแดด

11. Opportunities

Site Opportunities คือสิ่งที่สามารถนำมาใช้สร้างข้อได้เปรียบทางการออกแบบ

ตัวอย่าง:

Good View
Good Orientation
Existing Trees
Natural Ventilation
Public Transport
Street Visibility
Open Space
Existing Building
Strong Urban Character

ตัวอย่างการแปลง Opportunity:

GOOD VIEW
    ↓
Orient Main Space
    ↓
Large Opening
    ↓
View-Oriented Design

นี่คือสิ่งที่ทำให้ Site Analysis เชื่อมต่อกับ Concept Design

12. Constraints

Constraints คือสิ่งที่จำกัดการออกแบบ

เช่น

Strong Sun
Noise
Traffic
Poor Access
Existing Structure
Neighboring Building
Flood Risk
Regulation
Limited Site Area

แต่ Constraint ไม่จำเป็นต้องเป็นปัญหาเสมอไป

สถาปนิกสามารถเปลี่ยน Constraint ให้เป็น Design Strategy ได้

เช่น

Noise → Buffer Zone

Strong Sun → Shading

Poor View → Courtyard

Existing Tree → Central Landscape

นี่คือหนึ่งในหัวใจของ Architectural Design

13. SWOT

SWOT Analysis สามารถนำมาใช้สรุป Site Analysis ในระดับ Strategic

Strengths

สิ่งที่ Site มีข้อได้เปรียบ

Good Location
Good View
Good Access
Existing Trees

Weaknesses

จุดอ่อน

Noise
Poor Orientation
Small Site
Limited Access

Opportunities

โอกาส

Transit
Urban Development
View
Landscape

Threats

ปัจจัยภายนอกที่อาจส่งผลกระทบ

Future Development
Traffic Increase
Climate Risk
Neighboring Construction

ตัวอย่าง:

	Positive	Negative
Internal	Strengths	Weaknesses
External	Opportunities	Threats

SWOT ช่วยเปลี่ยน Site Analysis จากข้อมูลจำนวนมากให้กลายเป็น Strategic Summary

14. Site Potential

Site Potential คือการสรุปว่า

“Site นี้มีศักยภาพอะไรที่สามารถนำมาใช้ในการออกแบบได้?”

ตัวอย่าง:

SITE
 ↓
Good Access
Good View
Existing Trees
Good Wind
Urban Activity
 ↓
SITE POTENTIAL
 ↓
Open Public Edge
Landscape Core
Natural Ventilation
View-Oriented Spaces

Site Potential จึงเป็นการมอง Site ในเชิง Design Opportunity

15. Design Implications

นี่คือขั้นตอนที่สำคัญที่สุด

เพราะ Site Analysis ที่ดีไม่ควรจบที่ Diagram

ต้องตอบให้ได้ว่า

“แล้วเราจะออกแบบอย่างไร?”

ตัวอย่าง:

Site Finding	Analysis	Design Implication
Strong West Sun	High Solar Exposure	เพิ่ม Solar Control
Good North View	Valuable View	Orient Main Spaces
Main Road Noise	High Noise	Buffer Zone
Existing Large Tree	High Landscape Value	Preserve Tree
Strong Wind	Natural Ventilation Potential	เปิดรับลม
Busy Street	High Pedestrian Activity	Active Public Edge

นี่คือการเปลี่ยน

Analysis → Design Decision

จาก Site Analysis สู่ Design Strategy

สามารถคิดเป็น Chain ได้ดังนี้

SITE FACT
      ↓
ANALYSIS
      ↓
OPPORTUNITY / CONSTRAINT
      ↓
DESIGN RESPONSE
      ↓
DESIGN STRATEGY

ตัวอย่าง:

WEST SUN
   ↓
High Solar Exposure
   ↓
CONSTRAINT
   ↓
Reduce Direct Solar Gain
   ↓
Deep Shading
   ↓
SOLAR CONTROL STRATEGY

หรือ

GOOD VIEW
   ↓
VIEW OPPORTUNITY
   ↓
Orient Building
   ↓
Main Spaces Face View
   ↓
VIEW-ORIENTED STRATEGY

AI กับ Site Analysis

Site Analysis เป็นหนึ่งในขั้นตอนที่ AI สามารถเข้ามาช่วยได้มาก เพราะข้อมูลจำนวนมากสามารถนำเข้าสู่ระบบเพื่อช่วยวิเคราะห์และสรุปได้

แต่ควรแบ่งเป็น

AI = Analysis Assistant

และ

Architect = Design Decision Maker

1. Site Analysis with AI

AI สามารถช่วยวิเคราะห์ข้อมูลหลายประเภท เช่น

Site Photos
Maps
Satellite Images
Drawings
Climate Data
Surrounding Buildings
Site Notes

แล้วช่วยจัดหมวดหมู่

RAW SITE DATA
      ↓
AI
      ↓
Solar
Wind
Noise
Access
View
Vegetation
Buildings
      ↓
Analysis
      ↓
Opportunities
Constraints

อย่างไรก็ตาม AI ไม่ควรถือว่าเป็นเครื่องมือวัดจริงโดยอัตโนมัติ หากข้อมูลต้นทางไม่มีมาตราส่วน พิกัด หรือข้อมูลสภาพแวดล้อมที่เชื่อถือได้

2. Image-to-Analysis

ภาพ Site สามารถนำมาใช้เป็น Input ให้ AI ช่วยวิเคราะห์เบื้องต้นได้

ตัวอย่าง Input:

ภาพถ่ายจาก Site

AI อาจช่วยระบุสิ่งที่มองเห็น เช่น

Road
Building
Tree
Sidewalk
Utility
Signage
Activity
Potential View
Visual Obstruction

จากนั้นสามารถจัดเป็น

Observation → Interpretation → Design Question

ตัวอย่าง:

Existing Large Tree
       ↓
Provides Shade
       ↓
Can It Become
a Landscape Anchor?

สิ่งสำคัญคือ AI ควรแยกให้ชัดว่าอะไรคือ

สิ่งที่เห็นจริง

กับ

สิ่งที่ AI ตีความ

3. Diagram Generation

AI สามารถช่วยเปลี่ยนข้อมูล Site เป็น Diagram Concept ได้ เช่น

Solar Diagram
Wind Diagram
Access Diagram
Circulation Diagram
View Diagram
Noise Diagram
Vegetation Diagram
Opportunity / Constraint Diagram

Workflow:

SITE DATA
 ↓
AI ANALYSIS
 ↓
DIAGRAM
 ↓
ARCHITECT REVIEW
 ↓
FINAL DIAGRAM

Diagram ที่ AI สร้างควรใช้เป็น Exploration / Draft และต้องตรวจสอบความถูกต้องก่อนนำไปใช้ในเอกสารโครงการ

4. Site Analysis Prompt

AI สามารถใช้ Prompt ที่มีโครงสร้างเพื่อวิเคราะห์ Site ได้ดีกว่าการถามแบบกว้าง ๆ

ตัวอย่าง Prompt Framework:

ROLE
คุณคือ Architectural Site Analysis Assistant

INPUT
- Site Location
- Site Area
- Site Image
- Site Plan
- North Direction
- Surrounding Context

ANALYZE
1. Solar
2. Wind
3. Access
4. Circulation
5. Views
6. Noise
7. Vegetation
8. Existing Buildings

OUTPUT
1. Key Findings
2. Opportunities
3. Constraints
4. Design Implications
5. Questions Requiring Site Verification

ข้อดีของ Prompt แบบนี้คือ AI ไม่ได้หยุดเพียงการบรรยาย Site แต่ถูกกำหนดให้ไปถึง Design Implications

5. AI Environmental Analysis

AI สามารถช่วยรวบรวมและตีความข้อมูลด้านสิ่งแวดล้อม เช่น

Solar
Wind
Temperature
Rain
Climate
Vegetation

แต่ควรแบ่งระดับความน่าเชื่อถือ

Level 1 — Visual Analysis

วิเคราะห์จากภาพ

Level 2 — Data Analysis

วิเคราะห์จากข้อมูลที่มีแหล่งอ้างอิง

Level 3 — Simulation

ใช้ Software / Computational Simulation

ดังนั้น

AI Image Analysis ≠ Environmental Simulation

หากต้องการตัวเลขทางวิศวกรรม เช่น Solar Radiation, Wind Speed หรือ Thermal Performance ควรใช้ข้อมูลและเครื่องมือวิเคราะห์ที่เหมาะสมเพิ่มเติม

6. AI Design Opportunity

AI สามารถช่วยเปลี่ยน Site Findings เป็น Design Opportunities

ตัวอย่าง:

Existing Tree
      ↓
Shade
      ↓
Landscape Opportunity
      ↓
Outdoor Social Space

หรือ

Transit Nearby
      ↓
High Pedestrian Flow
      ↓
Public Edge Opportunity
      ↓
Active Frontage

AI จึงสามารถทำหน้าที่เป็น Design Thinking Partner เพื่อเสนอความเป็นไปได้หลายรูปแบบ

แต่สถาปนิกต้องเป็นผู้เลือกว่าสิ่งใดเหมาะกับ Project Goals

7. AI Constraint Detection

AI สามารถช่วยค้นหา Constraint จากข้อมูล Site ได้

เช่น

INPUT
Site Plan
+
Site Photo
+
Regulation Data

       ↓

AI

       ↓

Potential Constraints

- Access
- Setback
- Noise
- Solar
- Existing Building
- Vegetation
- Neighbor

จากนั้นสามารถสร้าง

Constraint Map

เพื่อให้ทีมออกแบบเห็นข้อจำกัดตั้งแต่ต้น

แต่ข้อจำกัดด้านกฎหมายและข้อกำหนดอาคารควรตรวจสอบกับเอกสารกฎหมายหรือหน่วยงานที่เกี่ยวข้อง ไม่ควรใช้ AI เป็นแหล่งยืนยันข้อกฎหมายเพียงแหล่งเดียว

Site Analysis Workflow สำหรับสถาปนิก

สามารถสร้าง Workflow ที่ใช้งานจริงได้ดังนี้

01 COLLECT
Site Data
      ↓
02 OBSERVE
What Exists?
      ↓
03 ANALYZE
Why Does It Matter?
      ↓
04 IDENTIFY
Opportunity / Constraint
      ↓
05 PRIORITIZE
What Matters Most?
      ↓
06 RESPOND
What Should We Do?
      ↓
07 STRATEGIZE
Design Strategy
      ↓
08 CONCEPT
Architectural Concept

หรือจำง่าย ๆ:

Observe → Analyze → Interpret → Respond

Site Analysis Checklist

ก่อนเข้าสู่ Concept Design ควรตรวจสอบว่าได้วิเคราะห์อย่างน้อย

Environmental

Solar
Sun Path
Wind
Climate
Rain
Temperature

Physical

Existing Buildings
Existing Vegetation
Topography
Infrastructure

Urban

Access
Circulation
Views
Noise
Surrounding Activities
Urban Context

Strategic

Opportunities
Constraints
SWOT
Site Potential
Design Implications

AI

Image-to-Analysis
AI Site Analysis
Diagram Generation
Environmental Analysis
Opportunity Detection
Constraint Detection

Site Analysis ที่ดีต้องจบด้วย “Design Implication”

หัวใจสำคัญที่สุดของ Site Analysis คือ

อย่าหยุดที่ “What is there?”

และอย่าหยุดเพียง

“What does it mean?”

แต่ต้องไปให้ถึง

“What should we do about it?”

ตัวอย่าง:

WHAT
West Sun

↓

SO WHAT
High Solar Exposure

↓

NOW WHAT
Provide Solar Control

หรือ

WHAT
Good View

↓

SO WHAT
High View Potential

↓

NOW WHAT
Orient Important Spaces
Toward View

นี่คือความแตกต่างระหว่าง Site Documentation กับ Architectural Site Analysis

สรุป

Site Analysis คือกระบวนการเปลี่ยน ข้อมูลของ Site ให้กลายเป็น Design Intelligence

กระบวนการสำคัญคือ

Site Data → Analysis → Opportunity / Constraint → Design Implication → Design Strategy

โดยวิเคราะห์ทั้ง

Sun + Wind + Climate + View + Noise + Access + Circulation + Vegetation + Existing Buildings

แล้วสรุปเป็น

Opportunities + Constraints + Site Potential

ก่อนนำไปสู่

Design Strategy → Concept Design

และเมื่อใช้ AI เข้ามาช่วย สามารถเพิ่มความเร็วในขั้นตอน

Observe → Analyze → Organize → Generate → Compare

โดยเฉพาะการทำ Image-to-Analysis, Diagram Generation, Opportunity Detection และ Constraint Detection

แต่หลักสำคัญยังคงเหมือนเดิม:

AI can help us see more possibilities.
Architects decide what those possibilities mean.

เพราะ Site Analysis ที่ดีไม่ใช่การทำ Diagram ให้ครบทุกประเภท

แต่คือการค้นหาให้เจอว่า

“Site กำลังบอกอะไรเรา และเราควรตอบ Site อย่างไรด้วย Architecture?”

สิงหาคม 21, 2026

Feasibility คืออะไร?
วิธีประเมินความเป็นไปได้ของโครงการสถาปัตยกรรมก่อนเริ่มออกแบบ

Feasibility หรือ Feasibility Study คือกระบวนการประเมินความเป็นไปได้ของโครงการก่อนลงทุนเวลาและงบประมาณไปกับการออกแบบอย่างละเอียด

ในงานสถาปัตยกรรม Feasibility ไม่ได้หมายถึงเพียงการถามว่า

“สร้างอาคารได้หรือไม่?”

แต่ควรถามให้กว้างกว่านั้นว่า

“สามารถสร้างอะไรได้บ้าง ภายใต้ที่ดิน กฎหมาย งบประมาณ เวลา และข้อจำกัดที่มีอยู่ และทางเลือกใดเหมาะสมที่สุดกับเป้าหมายของโครงการ?”

ตัวอย่างเช่น เจ้าของที่ดินมีพื้นที่ 2,000 ตารางเมตร และต้องการสร้างอาคารสำนักงาน

คำถามของ Feasibility อาจเป็น

สร้างได้สูงกี่ชั้น?
พื้นที่อาคารได้ประมาณเท่าไร?
FAR อนุญาตเท่าไร?
ต้องเว้นระยะเท่าไร?
ต้องมีที่จอดรถกี่คัน?
พื้นที่ใช้สอยที่ต้องการสร้างได้หรือไม่?
งบประมาณเพียงพอหรือไม่?
ใช้เวลาก่อสร้างเท่าไร?
มีความเสี่ยงอะไร?
มีข้อจำกัดอะไร?
มีทางเลือกอื่นที่ดีกว่าหรือไม่?

ดังนั้น Feasibility จึงเป็น Decision-Making Stage ที่อยู่ระหว่างการกำหนดโจทย์กับการพัฒนาแบบ

Feasibility อยู่ตรงไหนใน Design Process?

ในกระบวนการออกแบบสามารถมองได้ว่า

SITE RESEARCH
      ↓
CLIENT BRIEF
      ↓
PROGRAM
      ↓
FEASIBILITY
      ↓
SITE ANALYSIS
      ↓
DESIGN STRATEGY
      ↓
CONCEPT DESIGN

แต่ในโครงการจริง Feasibility อาจเกิดขึ้นหลายครั้ง ไม่จำเป็นต้องทำเพียงครั้งเดียว

ตัวอย่างเช่น

Initial Feasibility

ประเมินว่าโครงการมีความเป็นไปได้หรือไม่

↓

Design Feasibility

ประเมินว่ารูปแบบการออกแบบที่เสนอทำได้หรือไม่

↓

Cost Feasibility

ตรวจสอบผลกระทบด้านงบประมาณ

↓

Development Scenario

เปรียบเทียบทางเลือกต่าง ๆ

ดังนั้น Feasibility จึงเป็นกระบวนการที่สามารถ วนกลับไปปรับ Program หรือ Design ได้ตลอดโครงการ

1. Site Feasibility

Site Feasibility คือการประเมินว่าที่ดินสามารถรองรับโครงการที่ต้องการได้หรือไม่

ควรพิจารณา

ขนาดที่ดิน
รูปร่างที่ดิน
ทางเข้าออก
ถนน
ทิศ
ระดับพื้นที่
อาคารเดิม
ระบบสาธารณูปโภค
สภาพแวดล้อม
กฎหมาย
ผังเมือง
ข้อจำกัดของพื้นที่

ตัวอย่างเช่น

Client ต้องการอาคาร 5,000 m²

แต่หลังจากตรวจสอบที่ดินพบว่าสามารถพัฒนาอาคารได้ประมาณ 3,500 m²

นี่คือ Feasibility Issue ที่ควรพบ ก่อน เริ่มออกแบบอย่างละเอียด

2. Functional Feasibility

Functional Feasibility คือการตรวจสอบว่า Program ที่ต้องการสามารถจัดลงในพื้นที่จริงได้หรือไม่

ตัวอย่าง:

Client ต้องการ

50 ห้อง
Lobby
Restaurant
Meeting
Parking
Service Area

แต่พื้นที่ดินมีข้อจำกัด

จึงต้องตรวจสอบว่า

Program ทั้งหมดสามารถทำงานร่วมกันได้หรือไม่?

ไม่ใช่แค่ “พื้นที่รวมพอหรือไม่”

แต่ต้องดู

Circulation
Adjacency
Zoning
Service
Accessibility
Fire Safety
Operation

ด้วย

3. Financial Feasibility

Financial Feasibility คือการประเมินว่าโครงการมีความเป็นไปได้ทางการเงินหรือไม่

สำหรับโครงการพัฒนาอสังหาริมทรัพย์ อาจพิจารณา

Land Cost
Construction Cost
Design Fee
Consultant Fee
Permit
Financing
Marketing
Operation
Revenue
Contingency

สำหรับโครงการที่ไม่ได้สร้างเพื่อขาย เช่น อาคารสำนักงานขององค์กร อาจเน้น

Capital Budget
Construction Cost
Operating Cost
Maintenance Cost
Life-cycle Cost

สิ่งสำคัญคือ

โครงการที่ “สร้างได้” ไม่ได้แปลว่า “คุ้มค่าที่จะสร้าง” เสมอไป

4. Development Potential

Development Potential คือศักยภาพของที่ดินในการพัฒนา

คำถามสำคัญคือ

ที่ดินแปลงนี้สามารถสร้างมูลค่าได้มากเพียงใด ภายใต้ข้อจำกัดที่มีอยู่?

ตัวแปรสำคัญ เช่น

Land Area
FAR
Site Coverage
Height
Setback
Access
Parking
Land Use
Demand
Market
Construction Cost

การประเมิน Development Potential มักทำเป็นหลาย Scenario แทนการสรุปจากทางเลือกเดียว

5. Building Area

หนึ่งในคำถามแรกของ Feasibility คือ

“สร้างพื้นที่ได้เท่าไร?”

ต้องแยกอย่างน้อยระหว่าง

Site Area
Building Footprint
Gross Floor Area
Net Area
Saleable Area
Usable Area

ตัวอย่างง่าย ๆ:

ที่ดิน

2,000 m²

หากข้อกำหนดและเงื่อนไขของโครงการทำให้สามารถพัฒนาอาคารรวมได้ประมาณ

8,000 m²

เราจึงนำตัวเลขนี้ไปพิจารณาต่อเรื่อง

Program
Cost
Revenue
Design

แต่ตัวเลข Building Area ที่แท้จริงต้องตรวจสอบกับข้อกำหนดของพื้นที่และนิยามการวัดพื้นที่ที่เกี่ยวข้อง

6. FAR

FAR — Floor Area Ratio คืออัตราส่วนระหว่างพื้นที่อาคารรวมที่ใช้ในการคำนวณตามข้อกำหนด กับพื้นที่ดิน ตามนิยามของกฎหมายหรือผังเมืองที่ใช้กับโครงการ

ตัวอย่างเชิงหลักการ:

ที่ดิน = 2,000 m²

FAR = 4

อาจตีความเบื้องต้นได้ว่า

Potential Floor Area = 2,000 × 4 = 8,000 m²

แต่ต้องระวังว่า

FAR ไม่ได้แปลว่าเราจะสร้างพื้นที่ 8,000 m² ได้จริงเสมอไป

เพราะยังมีข้อจำกัดอื่น เช่น

Setback
Site Coverage
Height
Parking
Fire Safety
Access
Open Space
Building Shape
Other Regulations

ดังนั้น FAR เป็นเพียง หนึ่งในตัวแปรของ Development Potential

7. Site Coverage

Site Coverage หรือข้อกำหนดเกี่ยวกับพื้นที่อาคารที่ปกคลุมพื้นดิน ใช้ควบคุมว่าอาคารสามารถกินพื้นที่บนที่ดินได้มากเพียงใด ตามนิยามและข้อกำหนดที่ใช้กับพื้นที่นั้น

ตัวอย่างเชิงหลักการ:

Site Area = 2,000 m²

หากสมมติว่า Site Coverage สูงสุด = 50%

Building Footprint สูงสุดเชิงทฤษฎี =

2,000 × 50% = 1,000 m²

หากต้องการพื้นที่อาคารรวม 8,000 m²

อาจต้องพัฒนาเป็นอาคารหลายชั้น เช่น

1,000 × 8 ชั้น = 8,000 m²

แต่ยังต้องตรวจสอบเรื่อง

Height
Setback
Floor-to-Floor
Core
Parking
Structure
Fire Safety

ดังนั้นตัวเลขนี้เป็นเพียง Feasibility Scenario ไม่ใช่ข้อสรุปทางกฎหมาย

8. Parking

Parking สามารถกลายเป็นข้อจำกัดสำคัญของ Development Potential

ตัวอย่างเช่น

หาก Program ต้องการพื้นที่อาคารจำนวนมาก แต่กฎหมายหรือเงื่อนไขโครงการกำหนดให้ต้องมีที่จอดรถจำนวนมาก

พื้นที่ที่ต้องใช้สำหรับ

Parking + Ramp + Circulation + Service

อาจทำให้พื้นที่ที่เหลือสำหรับอาคารลดลงอย่างมาก

ดังนั้นควรตรวจสอบ Parking ตั้งแต่ต้น ไม่ใช่รอจนถึงขั้นออกแบบ Floor Plan

9. Budget

Budget เป็นตัวแปรสำคัญที่ต้องนำมาเทียบกับ Program และ Development Potential

ตัวอย่าง:

Client ต้องการ

Gross Area = 5,000 m²

และมีงบประมาณก่อสร้าง

30 ล้านบาท

หากต้นทุนก่อสร้างสมมติอยู่ที่

20,000 บาท/m²

ต้นทุนก่อสร้างเบื้องต้นจะเป็น

5,000 × 20,000 = 100 ล้านบาท

ทันทีที่เห็นตัวเลขนี้ เราจะรู้ว่า

Program กับ Budget ไม่สอดคล้องกัน

จึงต้องกลับไปพิจารณา

ลดพื้นที่
ปรับ Specification
ปรับ Program
เพิ่ม Budget
เปลี่ยน Construction Strategy

นี่คือประโยชน์ของ Feasibility

เพราะทำให้พบปัญหา ก่อนเสียเวลาออกแบบ

10. Construction Cost

การประมาณ Construction Cost ในช่วง Feasibility มักเป็นการประมาณเบื้องต้น ไม่ใช่ราคาก่อสร้างสุดท้าย

สามารถใช้แนวคิด

Estimated Cost = Area × Cost / m²

เป็นจุดเริ่มต้น

แต่ควรพิจารณาปัจจัยเพิ่มเติม เช่น

Building Type
Structure
Material
MEP
Finishes
Site Condition
Location
Complexity
Market Conditions
Construction Method

ดังนั้นตัวเลขต้นทุนใน Feasibility ควรระบุ ระดับความแม่นยำและสมมติฐาน ให้ชัดเจน

11. Project Timeline

ต้องประเมินว่าโครงการสามารถเสร็จทันเวลาหรือไม่

ตัวอย่าง Timeline:

Feasibility
    ↓
Design
    ↓
Approval
    ↓
Tender
    ↓
Construction
    ↓
Handover

แต่ละขั้นตอนมีผลต่อกัน

ตัวอย่าง:

ถ้า Permit ใช้เวลานาน

↓

Construction Start เลื่อน

↓

Handover เลื่อน

↓

Revenue Start เลื่อน

↓

Financial Feasibility เปลี่ยน

ดังนั้น Time ไม่ใช่เพียง Schedule Issue แต่เป็น Financial และ Business Issue ด้วย

12. Risk

ทุกโครงการมีความเสี่ยง

ในช่วง Feasibility ควรพยายามค้นหา Risk ตั้งแต่ต้น

ตัวอย่าง:

Site Risk

ดิน
น้ำท่วม
ทางเข้าออก
อาคารเดิม

Regulatory Risk

ผังเมือง
Building Control
Permit

Financial Risk

Construction Cost
Interest
Budget Overrun

Schedule Risk

Permit Delay
Procurement
Construction

Design Risk

Program ใหญ่เกินไป
Complexity สูง
Coordination

Market Risk

สำหรับโครงการพัฒนาเพื่อธุรกิจ

Demand
Occupancy
Sales
Rental

13. Constraints

Constraints คือสิ่งที่จำกัดทางเลือกของโครงการ

เช่น

Site Constraints

รูปร่างที่ดิน
ทางเข้า
ทิศ
อาคารเดิม

Regulatory Constraints

FAR
Setback
Height
Parking

Financial Constraints

Budget

Time Constraints

Deadline

Client Constraints

Requirements
Existing Commitments

สิ่งสำคัญคือการแยกระหว่าง

Hard Constraint

สิ่งที่แทบไม่สามารถเปลี่ยนได้

กับ

Soft Constraint

สิ่งที่สามารถเจรจาหรือปรับเปลี่ยนได้

14. Opportunity

Feasibility ไม่ควรมองเฉพาะปัญหา

ต้องค้นหา Opportunity ด้วย

ตัวอย่าง:

ทำเลดี
ใกล้ Transit
วิวดี
ที่ดินมีหน้ากว้าง
FAR สูง
อาคารเดิมนำกลับมาใช้ได้
มีต้นไม้ใหญ่
มี Demand สูง

ดังนั้น Feasibility ควรสรุปทั้ง

Constraints + Opportunities

ไม่ใช่เพียงข้อจำกัด

Feasibility Matrix

วิธีหนึ่งที่ช่วยให้ทีมออกแบบและลูกค้าเห็นภาพรวมคือการทำ Matrix

Factor	Finding	Impact	Status
Site	ที่ดิน 2,000 m²	Medium	✓
FAR	4.0	High	✓
Parking	จำกัดพื้นที่	High	⚠
Budget	ต่ำกว่า Target	High	⚠
Access	ถนนหลักด้านหน้า	Positive	✓
View	วิวเปิดด้านทิศเหนือ	Positive	✓
Timeline	ต้องเสร็จใน 18 เดือน	High	⚠

ตารางแบบนี้ช่วยให้ทุกฝ่ายเห็นว่า

อะไรคือปัญหา และอะไรคือโอกาส

Development Scenario

การทำ Feasibility ที่ดีไม่ควรมีเพียง Option เดียว

ควรทดลองหลาย Scenario

ตัวอย่าง:

Scenario A — Maximum Development

พื้นที่อาคารสูงสุด
ใช้ FAR เต็มศักยภาพ
รายได้สูง
Cost สูง
Complexity สูง

Scenario B — Balanced

พื้นที่ลดลง
Cost สมดุล
ใช้งานง่ายขึ้น
Risk ลดลง

Scenario C — Conservative

พื้นที่น้อย
Cost ต่ำ
Risk ต่ำ
ลงทุนเริ่มต้นน้อย

จากนั้นจึงเปรียบเทียบ

Area
Cost
Revenue
Time
Risk
Value
   ↓
Compare
   ↓
Preferred Scenario

นี่เป็นจุดที่ Feasibility เปลี่ยนจาก การตรวจสอบ ไปเป็น เครื่องมือช่วยตัดสินใจ

AI กับ Feasibility

Feasibility เป็นอีกขั้นตอนหนึ่งที่ AI สามารถช่วยสถาปนิกได้มาก โดยเฉพาะเมื่อมีข้อมูลจำนวนมากและต้องทดลองหลาย Scenario

แต่ควรมอง AI เป็น

Decision Support

ไม่ใช่

Decision Maker

1. Feasibility Analysis

AI สามารถช่วยรวบรวมข้อมูลและสร้าง Feasibility Summary เช่น

INPUT

Site Area
FAR
Site Coverage
Height
Parking
Program
Budget
Timeline

        ↓

AI ANALYSIS

Development Potential
Program Fit
Budget Gap
Risk
Opportunity

        ↓

FEASIBILITY SUMMARY

สถาปนิกและผู้เชี่ยวชาญต้องตรวจสอบข้อมูลต้นทางและสมมติฐานก่อนใช้ผลลัพธ์ในการตัดสินใจจริง

2. Scenario Analysis

AI สามารถช่วยสร้าง Scenario จำนวนมากได้อย่างรวดเร็ว

เช่น

SCENARIO A
8,000 m²
High Cost
High Return

SCENARIO B
6,500 m²
Medium Cost
Balanced Return

SCENARIO C
5,000 m²
Low Cost
Lower Return

จากนั้นสามารถเปรียบเทียบ

Cost
Area
Revenue
Risk
Timeline

เพื่อช่วยให้ทีมเลือก Scenario ที่เหมาะสม

3. Cost Estimation

AI สามารถช่วยทำ Preliminary Cost Estimation

เช่น

Gross Area
×
Indicative Cost / m²
↓
Preliminary Construction Cost

และสามารถสร้าง Sensitivity Analysis เช่น

ถ้าต้นทุนเพิ่ม 10% จะเกิดอะไรขึ้น?

ถ้าพื้นที่ลด 15% จะลด Cost เท่าไร?

ถ้าเพิ่ม Specification จะกระทบ Budget เท่าไร?

แต่ตัวเลขเหล่านี้ควรใช้เป็น Preliminary Estimate และต้องตรวจสอบกับข้อมูลราคาที่เหมาะสมกับโครงการจริงก่อนใช้ตัดสินใจลงทุน

4. Development Scenario

AI สามารถช่วยสร้าง Development Scenario จากข้อจำกัดของพื้นที่

ตัวอย่าง Input:

Site Area
FAR
Site Coverage
Height
Parking
Program
Budget

แล้วสร้าง

Option A
Maximum Area

Option B
Balanced Area

Option C
Low Cost

Option D
High Efficiency

จากนั้นให้สถาปนิกนำ Scenario เหล่านี้ไปพัฒนาเป็น Massing และ Design Options

5. AI Decision Support

AI มีประโยชน์มากในการช่วยจัดข้อมูลสำหรับการตัดสินใจ

เช่น

Scenario	Area	Cost	Risk	Potential
A	8,000 m²	High	High	High
B	6,500 m²	Medium	Medium	High
C	5,000 m²	Low	Low	Medium

AI สามารถช่วยอธิบาย Trade-off ได้ว่า

เพิ่มพื้นที่ → Cost และ Risk เพิ่ม

หรือ

ลดพื้นที่ → Investment ลด แต่ Development Potential ลด

แต่การเลือก Option สุดท้ายควรเป็นการตัดสินใจของเจ้าของโครงการและทีมวิชาชีพ

6. Risk Analysis

AI สามารถช่วยจัดกลุ่ม Risk และประเมินระดับเบื้องต้น

เช่น

Risk
 ↓
Probability
 ×
Impact
 ↓
Risk Level

ตัวอย่าง:

Risk	Probability	Impact	Priority
Permit Delay	Medium	High	High
Cost Increase	High	High	Critical
Access Issue	Low	High	Medium
Program Change	Medium	Medium	Medium

จากนั้นทีมโครงการสามารถกำหนด

Mitigation Strategy

สำหรับแต่ละ Risk

Feasibility กับ AI ไม่ควรจบที่ “Yes / No”

นี่เป็นหลักสำคัญสำหรับการนำ AI มาใช้ในงานสถาปัตยกรรม

AI ไม่ควรตอบเพียง

Feasible / Not Feasible

แต่ควรช่วยตอบว่า

Feasible ภายใต้เงื่อนไขอะไร?

ตัวอย่าง:

Scenario A — Feasible แต่ Budget สูงกว่า Target 20%

Scenario B — Feasible หากลด Program 15%

Scenario C — Feasible หากเพิ่มระยะเวลา 6 เดือน

นี่มีประโยชน์กว่าการให้คำตอบแบบ Yes / No เพราะช่วยให้สถาปนิกและลูกค้าเห็น Trade-offs

Feasibility Workflow

สามารถสร้าง Workflow สำหรับโครงการได้ดังนี้

SITE RESEARCH
       ↓
CLIENT BRIEF
       ↓
PROGRAM
       ↓
SITE / REGULATION DATA
       ↓
DEVELOPMENT POTENTIAL
       ↓
BUILDING AREA
       ↓
COST
       ↓
TIMELINE
       ↓
RISK
       ↓
SCENARIO A / B / C
       ↓
COMPARE
       ↓
CLIENT DECISION
       ↓
DESIGN DIRECTION

หากนำ AI เข้ามาช่วย:

DATA
 ↓
AI
 ↓
ANALYSIS
 ↓
SCENARIOS
 ↓
VISUALIZATION
 ↓
ARCHITECT REVIEW
 ↓
CLIENT DECISION

Feasibility Checklist

ก่อนเริ่มออกแบบ ควรตรวจสอบอย่างน้อยว่า

Site

Site Area
Site Shape
Access
Existing Building
Existing Infrastructure
Site Constraints

Regulation

Land Use
FAR
Site Coverage
Height
Setback
Parking
Other Applicable Controls

Program

Required Area
Functional Requirements
Circulation
Service
Net Area
Gross Area

Financial

Budget
Construction Cost
Consultant Cost
Contingency
Operating Considerations

Time

Design Timeline
Approval
Tender
Construction
Handover

Decision

Constraints
Opportunities
Risks
Development Scenarios
Preferred Scenario
Client Decision

Feasibility → Design

เมื่อ Feasibility เสร็จแล้ว ข้อมูลควรนำไปสู่ Design อย่างเป็นระบบ

FEASIBILITY
      ↓
What Can We Build?
      ↓
How Much?
      ↓
At What Cost?
      ↓
Under What Constraints?
      ↓
With What Risk?
      ↓
Which Scenario Is Best?
      ↓
DESIGN STRATEGY
      ↓
CONCEPT DESIGN

จุดสำคัญคือ Feasibility ไม่ควรเป็นเอกสารที่ทำเสร็จแล้วเก็บไว้ แต่ควรกลายเป็น Design Input

ตัวอย่าง:

FAR จำกัด → ต้องจัด Massing ให้มีประสิทธิภาพ

Parking สูง → ต้องพัฒนา Basement / Podium / Alternative Parking Strategy

Budget จำกัด → ต้องกำหนด Cost Priority

Deadline สั้น → ต้องลด Design Complexity

วิวดี → จัดพื้นที่หลักให้รับ View

ดังนั้น

Constraint → Design Response

และ

Opportunity → Design Strategy

สรุป

Feasibility คือการตรวจสอบความเป็นไปได้ของโครงการก่อนลงทุนลงแรงกับการออกแบบในระดับรายละเอียด

คำถามสำคัญไม่ได้มีเพียง

“สร้างได้ไหม?”

แต่คือ

“สร้างอะไรได้บ้าง ภายใต้เงื่อนไขอะไร และทางเลือกใดเหมาะสมที่สุด?”

องค์ประกอบสำคัญของ Feasibility ได้แก่

Site + Program + Regulation + Area + Cost + Time + Risk + Opportunity

และเมื่อใช้ AI สามารถเปลี่ยนกระบวนการจาก

One Design → One Answer

เป็น

Multiple Scenarios → Compare → Decide

AI สามารถช่วย

Analyze → Calculate → Generate → Compare → Simulate

แต่สถาปนิกยังต้องทำหน้าที่

Verify → Interpret → Evaluate → Recommend → Decide

เพราะ Feasibility ที่ดีไม่ใช่การหาคำตอบที่ “ถูกที่สุด” หรือ “ใหญ่ที่สุด” แต่คือการค้นหา ทางเลือกที่เหมาะสมที่สุดสำหรับเป้าหมายของโครงการ

Good Feasibility doesn’t just ask “Can we build it?”
It asks “What should we build?”

สิงหาคม 21, 2026

Program คืออะไร?
วิธีแปลง Client Brief ให้เป็น Space Program สำหรับงานสถาปัตยกรรม

Program หรือ Architectural Programming คือกระบวนการกำหนดว่าโครงการต้องมีพื้นที่อะไรบ้าง แต่ละพื้นที่มีหน้าที่อย่างไร ต้องการพื้นที่เท่าไร ใครเป็นผู้ใช้งาน และพื้นที่เหล่านั้นควรมีความสัมพันธ์กันอย่างไร

ถ้า Client Brief ตอบคำถามว่า

“ลูกค้าต้องการอะไร?”

Program จะตอบคำถามต่อว่า

“สิ่งที่ลูกค้าต้องการนั้น ต้องแปลงเป็นพื้นที่และความสัมพันธ์ของพื้นที่อย่างไร?”

ตัวอย่างเช่น ลูกค้าบอกว่า

“ต้องการบ้านสำหรับครอบครัว 4 คน และต้องมีพื้นที่สำหรับทำงานที่บ้าน”

ข้อมูลนี้ยังไม่ใช่ Program ที่สมบูรณ์

สถาปนิกต้องแปลงต่อเป็น

Master Bedroom
Bedroom
Home Office
Living Room
Dining
Kitchen
Bathroom
Storage
Parking

แล้วจึงกำหนดต่อว่าแต่ละพื้นที่ควรมีขนาดเท่าไร อยู่ใกล้หรือไกลจากพื้นที่ใด และผู้ใช้งานจะเคลื่อนที่ระหว่างพื้นที่เหล่านั้นอย่างไร

ดังนั้น Program จึงเป็น สะพานระหว่าง Client Brief กับ Architectural Design

Program อยู่ตรงไหนในกระบวนการออกแบบ?

โดยทั่วไปสามารถมองกระบวนการได้ดังนี้

CLIENT
   ↓
CLIENT BRIEF
   ↓
PROGRAMMING
   ↓
SPACE PROGRAM
   ↓
SPACE RELATIONSHIP
   ↓
SPACE PLANNING
   ↓
CONCEPT DESIGN

หรือในมุมของข้อมูล

Need
 ↓
Requirement
 ↓
Activity
 ↓
Space
 ↓
Area
 ↓
Relationship
 ↓
Plan

นี่เป็นเหตุผลว่าทำไม Program จึงเป็นขั้นตอนสำคัญมาก เพราะการจัดพื้นที่ที่ผิดตั้งแต่ต้นสามารถส่งผลต่อ Floor Plan และ Design ทั้งโครงการ

Program ไม่ใช่แค่ Room List

ความเข้าใจผิดที่พบได้บ่อยคือ

Program = รายการห้อง

จริง ๆ แล้ว Room List เป็นเพียงส่วนหนึ่งของ Program

Program ที่สมบูรณ์ควรตอบอย่างน้อยว่า

มีพื้นที่อะไร
ใครใช้
ใช้ทำอะไร
ใช้เมื่อไร
ใช้กี่คน
ต้องการพื้นที่เท่าไร
ต้องอยู่ใกล้พื้นที่ใด
ต้องแยกจากพื้นที่ใด
ต้องเข้าถึงอย่างไร
เป็นพื้นที่ Public หรือ Private
เป็นพื้นที่หลักหรือพื้นที่สนับสนุน

ดังนั้น

Room List = What

แต่

Program = What + Who + Why + How Much + Where + Relationship

1. Space Program

Space Program คือการกำหนดรายการพื้นที่ที่โครงการต้องมี พร้อมข้อมูลที่เกี่ยวข้องกับแต่ละพื้นที่

ตัวอย่าง Space Program สำหรับบ้านพักอาศัย:

Space	User	Area	Priority
Living Room	Family / Guest	30 m²	Must Have
Dining	Family	16 m²	Must Have
Kitchen	Family / Staff	14 m²	Must Have
Master Bedroom	Owner	25 m²	Must Have
Bedroom 2	Child	16 m²	Must Have
Bedroom 3	Child	16 m²	Must Have
Home Office	Owner	12 m²	Important
Guest Bedroom	Guest	14 m²	Nice to Have
Storage	Family	6 m²	Important

Space Program ที่ดีจึงเป็นมากกว่าการเขียนชื่อห้อง เพราะแต่ละ Space ควรมีข้อมูลประกอบเพียงพอที่จะนำไปพัฒนาเป็น Design ได้

2. User Groups

ก่อนกำหนดพื้นที่ ต้องรู้ว่า ใครจะใช้พื้นที่

User Groups อาจแบ่งเป็น

Primary Users

ผู้ใช้งานหลัก เช่น

เจ้าของบ้าน
พนักงาน
นักเรียน
ผู้ป่วย
ลูกค้า

Secondary Users

ผู้ใช้งานรอง เช่น

แขก
ผู้มาติดต่อ
ครอบครัว
Visitor

Service Users

ผู้ที่ทำงานสนับสนุนอาคาร เช่น

แม่บ้าน
พนักงานรักษาความปลอดภัย
Maintenance
Delivery
Staff

การแยก User Groups ช่วยให้เห็นว่าแต่ละกลุ่มต้องการพื้นที่และเส้นทางการเดินทางที่แตกต่างกันหรือไม่

3. Activities

อาคารไม่ได้มีไว้สำหรับ “ห้อง” แต่มีไว้สำหรับ กิจกรรม

ดังนั้นก่อนถามว่า

“ต้องมีห้องอะไร?”

ควรถามว่า

“ผู้ใช้งานต้องทำกิจกรรมอะไร?”

ตัวอย่าง:

Office

กิจกรรมอาจประกอบด้วย

Work
Meeting
Collaboration
Focus Work
Break
Eating
Storage
Reception

จาก Activities จึงค่อยแปลงเป็น Space

Meeting
   ↓
Meeting Room

Focus Work
   ↓
Private Workspace

Collaboration
   ↓
Collaboration Area

วิธีคิดแบบนี้ช่วยลดปัญหาการกำหนดห้องจาก “ชื่อห้อง” โดยไม่ได้เข้าใจการใช้งานจริง

4. Room List

Room List คือรายการพื้นที่หรือห้องทั้งหมดที่ต้องมีในโครงการ

ตัวอย่าง:

01 Entrance
02 Reception
03 Living
04 Dining
05 Kitchen
06 Master Bedroom
07 Bedroom 02
08 Bedroom 03
09 Bathroom
10 Home Office
11 Storage
12 Parking

Room List เป็นข้อมูลพื้นฐานสำหรับสร้าง Space Program

แต่ควรเพิ่มข้อมูลอื่น เช่น

Area
User
Capacity
Priority
Relationship
Public / Private
Notes

เพื่อให้ Room List กลายเป็นข้อมูลที่ใช้งานได้จริง

5. Area Requirements

เมื่อรู้ว่าต้องมีพื้นที่อะไรแล้ว ต้องกำหนดว่าแต่ละพื้นที่ต้องการ พื้นที่เท่าไร

ตัวอย่าง:

Space	Capacity	Area
Meeting Room	10	20 m²
Office	4	16 m²
Pantry	4	8 m²
Storage	—	6 m²

Area Requirements ไม่ควรกำหนดจากความรู้สึกเพียงอย่างเดียว

ควรพิจารณาจาก

จำนวนผู้ใช้งาน
กิจกรรม
Furniture
Equipment
Circulation
Ergonomics
Accessibility
Operational Requirements
Regulations

6. Adjacency

Adjacency คือการกำหนดว่าพื้นที่ใดควรอยู่ใกล้หรือห่างจากพื้นที่ใด

ตัวอย่าง:

Kitchen
   ↕
Dining
   ↕
Living

มีความสัมพันธ์สูง

ขณะที่

Bedroom
   ✕
Service Area

อาจต้องการการแยกที่ชัดเจนกว่า

สามารถแบ่งความสัมพันธ์ เช่น

3 — Must Be Adjacent

ต้องอยู่ใกล้กัน

2 — Preferably Adjacent

ควรอยู่ใกล้

1 — No Strong Relationship

ไม่สำคัญ

0 — Separate

ควรแยกออกจากกัน

7. Functional Relationships

Functional Relationship กว้างกว่า Adjacency เพราะไม่ได้ถามเพียงว่า

“อยู่ติดกันหรือไม่?”

แต่ถามว่า

“พื้นที่เหล่านี้ทำงานร่วมกันอย่างไร?”

ตัวอย่างสำนักงาน:

Reception
   ↓
Meeting
   ↓
Workspace
   ↓
Staff Area

หรือโรงแรม:

Lobby
 ↓
Reception
 ↓
Guest Room

Kitchen
 ↓
Restaurant
 ↓
Service

การเข้าใจ Functional Relationship จะช่วยให้สถาปนิกพัฒนา Floor Plan ได้อย่างมีเหตุผล

8. Circulation Requirements

Circulation คือระบบการเคลื่อนที่ภายในและรอบอาคาร

ควรศึกษาทั้ง

User Circulation
Staff Circulation
Service Circulation
Emergency Circulation
Public Circulation
Private Circulation

ตัวอย่างโรงแรม:

Guest
Entrance
 ↓
Lobby
 ↓
Guest Room

Service
Loading
 ↓
Kitchen
 ↓
Service Corridor

การแยก Circulation ที่เหมาะสมช่วยลด Conflict ระหว่างผู้ใช้งานแต่ละกลุ่ม

9. Public / Private

พื้นที่ควรได้รับการจัดระดับความเป็นสาธารณะ

ตัวอย่าง:

Public

Entrance
Lobby
Reception
Waiting
Retail

Semi-Public

Meeting
Lounge
Dining

Private

Bedroom
Private Office
Family Area

Service

Kitchen
Storage
Staff
Loading

การแบ่ง Public / Private มีผลโดยตรงต่อ

Zoning → Circulation → Privacy → Security

10. Service Areas

Service Area คือพื้นที่ที่สนับสนุนการทำงานของอาคาร

เช่น

Loading
Kitchen
Waste
Storage
Maintenance
Staff
Service Corridor
Service Lift
Plant Room

พื้นที่เหล่านี้มักถูกมองข้ามเพราะไม่ใช่พื้นที่ “สวย”

แต่ในอาคารจริง Service Area มีความสำคัญมาก

เพราะอาคารที่มีพื้นที่ใช้งานดี แต่ Service Flow ไม่ดี อาจทำให้อาคารทำงานไม่มีประสิทธิภาพ

11. Support Spaces

Support Spaces คือพื้นที่ที่สนับสนุนพื้นที่หลัก

ตัวอย่างเช่น

Office

อาจต้องมี

Storage
Pantry
Meeting
Printing
Toilet
IT
Support Area

หรือ

Classroom

อาจต้องมี

Teacher Area
Storage
Toilet
Equipment
Circulation

ดังนั้นเวลาทำ Program ควรถามเสมอว่า

“พื้นที่หลักนี้ต้องมีพื้นที่สนับสนุนอะไรเพื่อให้ทำงานได้จริง?”

12. Area Calculation

เมื่อกำหนดพื้นที่แต่ละห้องแล้ว ต้องคำนวณพื้นที่รวม

ตัวอย่าง:

Living             30 m²
Dining             16 m²
Kitchen            14 m²
Master Bedroom     25 m²
Bedroom 02         16 m²
Bedroom 03         16 m²
Office             12 m²
Storage             6 m²
-------------------------
Net Area           135 m²

จากนั้นต้องเพิ่มพื้นที่ที่ไม่ได้เป็นห้องโดยตรง เช่น

Corridor
Lobby
Stair
Lift
Wall
Service
Mechanical

เพื่อหาพื้นที่รวมของอาคาร

13. Net / Gross Area

เรื่องนี้สำคัญมากในการทำ Program

Net Area

พื้นที่ที่สามารถใช้ประโยชน์โดยตรงภายใน Space

เช่น

ห้องประชุม = 20 m²

Gross Area

พื้นที่รวมที่รวมองค์ประกอบอื่น ๆ ของอาคารตามนิยามที่ใช้ในโครงการ เช่น

Walls
Corridors
Structure
Shafts
Common Areas
Circulation

ดังนั้น

Gross Area > Net Area

ในทางปฏิบัติ ควรกำหนดนิยามของ Net และ Gross ให้ชัดเจนตั้งแต่ต้น เพราะแต่ละประเภทโครงการและมาตรฐานการวัดพื้นที่อาจใช้คำจำกัดความแตกต่างกัน

14. Efficiency Ratio

Efficiency Ratio ใช้เปรียบเทียบพื้นที่ใช้งานกับพื้นที่รวม

สูตรพื้นฐานที่ใช้กันทั่วไปคือ

Efficiency = Net Area ÷ Gross Area × 100

ตัวอย่าง:

Net Area = 800 m²

Gross Area = 1,000 m²

ดังนั้น

Efficiency = 80%

หมายความว่า 80% ของพื้นที่รวมเป็นพื้นที่สุทธิที่ตอบสนองการใช้งานโดยตรงตามนิยามที่กำหนด

Efficiency Ratio ที่เหมาะสมไม่ได้มีตัวเลขเดียวสำหรับทุกประเภทอาคาร

สำนักงาน โรงแรม โรงพยาบาล โรงเรียน และบ้านพักอาศัย มีลักษณะการจัดพื้นที่แตกต่างกัน

ดังนั้นไม่ควรตั้งเป้าว่า

“ต้องได้ 80% เสมอ”

โดยไม่พิจารณา Typology และข้อกำหนดของโครงการ

จาก Program สู่ Bubble Diagram

เมื่อมีข้อมูลเรื่อง Space และ Relationship แล้ว สามารถนำไปสร้าง Bubble Diagram

ตัวอย่าง:

              ┌─────────┐
              │  ENTRY  │
              └────┬────┘
                   │
              ┌────▼────┐
              │ LIVING  │
              └────┬────┘
                   │
          ┌────────┴────────┐
          ↓                 ↓
      ┌───────┐         ┌────────┐
      │ DINING│         │ KITCHEN│
      └───────┘         └────────┘

Bubble Diagram ไม่ใช่ Floor Plan

แต่เป็นการแสดง

“ใครควรอยู่ใกล้ใคร และระบบพื้นที่ควรทำงานอย่างไร”

ก่อนที่จะเข้าสู่การกำหนดรูปร่างและรูปแบบของอาคาร

AI กับ Architectural Program

Program เป็นอีกขั้นตอนที่ AI สามารถช่วยได้ดี เพราะมีข้อมูลที่สามารถจัดโครงสร้างและวิเคราะห์ได้

แต่ควรแบ่งบทบาทให้ชัดเจน

Architect
    ↓
Brief / Requirements
    ↓
AI
    ↓
Extract
Classify
Calculate
Optimize
    ↓
Architect Review
    ↓
Final Program

1. AI Space Program

AI สามารถช่วยเปลี่ยน Client Brief เป็น Draft Space Program

ตัวอย่าง Input:

บ้านพักอาศัย 4 คน
ต้องการทำงานที่บ้าน
มีแขกมาพักเป็นครั้งคราว
ต้องการพื้นที่สวน
ต้องการที่จอดรถ 2 คัน

AI สามารถช่วยสร้าง Draft:

Space	Area	User	Priority
Living	30	Family	Must
Dining	16	Family	Must
Kitchen	14	Family	Must
Master	25	Owner	Must
Bedroom 2	16	Child	Must
Bedroom 3	16	Child	Must
Office	12	Owner	Important
Guest Room	14	Guest	Nice
Storage	6	Family	Important

จากนั้นสถาปนิกต้องตรวจสอบและปรับให้เหมาะกับโครงการจริง

2. Program Generator

ในอนาคตสามารถสร้างระบบที่รับ

Project Type
Location
Users
Activities
Requirements
Budget
Area
Constraints

แล้วสร้าง

Draft Architectural Program

ออกมา

ระบบสามารถสร้าง

Room List
Area
User
Capacity
Priority
Relationship
Notes

ได้

3. Area Calculation

AI สามารถช่วยคำนวณและตรวจสอบข้อมูลจำนวนมาก เช่น

Room Area
+
Room Area
+
Room Area
=
Net Area

และ

Net Area
+
Circulation
+
Service
+
Structure
=
Gross Area

นอกจากนี้ยังสามารถช่วยสร้าง Scenario เช่น

Option A — Compact

Gross Area = 500 m²

Option B — Balanced

Gross Area = 600 m²

Option C — Generous

Gross Area = 700 m²

ทำให้สถาปนิกสามารถนำไปพูดคุยกับลูกค้าได้ง่ายขึ้น

4. Adjacency Matrix

AI สามารถสร้างตารางความสัมพันธ์ของพื้นที่

ตัวอย่าง:

	Living	Dining	Kitchen	Bedroom
Living	—	3	2	1
Dining	3	—	3	1
Kitchen	2	3	—	0
Bedroom	1	1	0	—

จาก Matrix สามารถนำไปสร้าง Bubble Diagram หรือใช้เป็นข้อมูลสำหรับ Space Planning ต่อไป

5. Bubble Diagram

เมื่อมี Adjacency Matrix แล้ว AI สามารถช่วยแปลงข้อมูลเป็น Diagram เพื่อแสดง

Functional Group
Adjacency
Circulation
Public / Private
Service
Support

อย่างไรก็ตาม Diagram ที่ AI สร้างควรถือเป็น Design Exploration ไม่ใช่แบบก่อสร้างหรือ Layout ที่ถูกต้องโดยอัตโนมัติ

6. Space Relationship

AI สามารถช่วยวิเคราะห์ว่าพื้นที่ใดควร

Near

ใกล้กัน

Adjacent

ติดกัน

Connected

ต้องเชื่อมต่อกัน

Separated

ควรแยกออกจากกัน

ตัวอย่าง:

Kitchen → Dining = Strong Relationship

Bedroom → Living = Moderate Relationship

Kitchen → Bedroom = Weak Relationship

7. Program Optimization

เมื่อ Program มีพื้นที่มากเกินไป หรือ Budget จำกัด AI สามารถช่วยสร้างทางเลือก

เช่น

CURRENT PROGRAM
1,500 m²
       ↓
Budget Constraint
       ↓
AI Scenario Analysis
       ↓
Option A
1,350 m²

Option B
1,200 m²

Option C
1,100 m²

แต่การ “ลดพื้นที่” ไม่ควรพิจารณาเฉพาะตัวเลข

ต้องถามว่า

“ลดอะไรแล้วกระทบ Project Goal มากที่สุด?”

จึงควรใช้ AI เพื่อสร้างและเปรียบเทียบทางเลือก มากกว่าปล่อยให้ AI ตัดสินใจแทนสถาปนิก

Program ที่ดีต้องผ่านการตรวจสอบอะไรบ้าง?

ก่อนนำ Program ไปทำ Space Planning ควรตรวจสอบอย่างน้อย

User

ใครใช้?
ใช้กี่คน?
ใช้พร้อมกันหรือไม่?

Function

ทำกิจกรรมอะไร?
ต้องใช้อุปกรณ์อะไร?
ต้องการพื้นที่สนับสนุนอะไร?

Area

พื้นที่เพียงพอหรือไม่?
Furniture และ Equipment ลงได้หรือไม่?
Circulation เพียงพอหรือไม่?

Relationship

Space ไหนควรอยู่ใกล้?
Space ไหนควรแยก?

Circulation

User Flow เป็นอย่างไร?
Service Flow เป็นอย่างไร?
Emergency Flow เป็นอย่างไร?

Priority

อะไร Must Have?
อะไรลดได้?
อะไรตัดออกได้?

Compliance

มีข้อกำหนดหรือกฎหมายอะไรที่ต้องพิจารณาหรือไม่?

Program → Space Planning → Design

สุดท้าย Program ควรนำไปสู่ขั้นตอนต่อไปอย่างเป็นระบบ

CLIENT BRIEF
       ↓
USER REQUIREMENTS
       ↓
ACTIVITIES
       ↓
SPACE PROGRAM
       ↓
ROOM LIST
       ↓
AREA REQUIREMENTS
       ↓
ADJACENCY
       ↓
FUNCTIONAL RELATIONSHIPS
       ↓
CIRCULATION
       ↓
PUBLIC / PRIVATE
       ↓
BUBBLE DIAGRAM
       ↓
SPACE PLANNING
       ↓
SCHEMATIC DESIGN

นี่คือเหตุผลที่ Program ไม่ใช่แค่ตารางรายชื่อห้อง

Program คือการสร้าง Logic ของอาคารก่อนที่เราจะเริ่มวาดอาคาร

Program Checklist

ก่อนเข้าสู่ Space Planning ควรตรวจสอบว่า Program มีข้อมูลครบหรือไม่

User Groups
Activities
Room List
Space Program
Area Requirements
Capacity
Adjacency
Functional Relationships
Circulation
Public / Private
Service Areas
Support Spaces
Area Calculation
Net Area
Gross Area
Efficiency Ratio
Priority
Constraints
Regulatory Requirements

สรุป

Program คือการเปลี่ยนความต้องการของลูกค้าและผู้ใช้งานให้กลายเป็นระบบพื้นที่

จาก

“Client ต้องการอะไร?”

ไปสู่

“อาคารต้องมีพื้นที่อะไร และพื้นที่เหล่านั้นต้องทำงานร่วมกันอย่างไร?”

กระบวนการหลักคือ

Requirements → Users → Activities → Spaces → Areas → Relationships → Circulation → Program

และเมื่อมี AI เข้ามาช่วย

Brief → AI → Space Program → Adjacency → Bubble Diagram → Scenario → Architect Review

AI สามารถช่วยสร้าง Draft, คำนวณ, จัดหมวดหมู่ และทดลองทางเลือกจำนวนมากได้อย่างรวดเร็ว แต่ สถาปนิกยังเป็นผู้กำหนดว่าพื้นที่ใดจำเป็น ความสัมพันธ์ใดเหมาะสม และ Program ใดตอบโจทย์โครงการจริง

เพราะท้ายที่สุดแล้ว

Good Architecture does not start with a beautiful form.
It starts with a well-understood program.

สิงหาคม 21, 2026

PD02. – Client Brief
Client Brief คืออะไร?
วิธีเก็บและแปลงความต้องการของลูกค้าให้เป็นโจทย์ออกแบบสถาปัตยกรรม

Client Brief คือเอกสารที่รวบรวมและจัดระบบข้อมูล ความต้องการ เป้าหมาย ข้อจำกัด และความคาดหวังของผู้ว่าจ้าง เพื่อใช้เป็นกรอบในการพัฒนาโครงการสถาปัตยกรรม

ในทางปฏิบัติ ลูกค้ามักไม่ได้ให้โจทย์ออกมาเป็น “Brief” ที่สมบูรณ์ตั้งแต่ต้น

ลูกค้าอาจพูดว่า

“อยากได้บ้านที่ดูอบอุ่น แต่ไม่อยากให้เหมือนบ้านทั่วไป”

หรือ

“อยากได้ออฟฟิศที่รองรับคนประมาณ 50 คน แต่บางวันอาจมี 70 คน”

หรือ

“อยากได้พื้นที่เยอะ ๆ แต่มีงบประมาณจำกัด”

ประโยคเหล่านี้ล้วนเป็นข้อมูลสำคัญ แต่ยังไม่ใช่ Design Brief ที่พร้อมนำไปออกแบบ

หน้าที่ของสถาปนิกคือการ ถาม → ฟัง → วิเคราะห์ → จัดระบบ → ตรวจสอบ → แปลงเป็น Design Requirements

ดังนั้น Client Brief จึงเป็นหนึ่งในขั้นตอนสำคัญที่สุดของ Pre-Design

Client Brief สำคัญอย่างไร?

ก่อนเริ่มออกแบบ สถาปนิกจำเป็นต้องเข้าใจว่า
- ใครเป็นผู้ใช้อาคาร
- ต้องการอะไร
- ทำไมจึงต้องการสิ่งนั้น
- ต้องการให้โครงการบรรลุเป้าหมายอะไร
- มีงบประมาณเท่าไร
- ต้องการเสร็จเมื่อไร
- อะไรคือสิ่งที่ยอมไม่ได้
- อะไรคือสิ่งที่สามารถปรับเปลี่ยนได้
หาก Brief ไม่ชัดเจน ปัญหามักจะเกิดขึ้นในขั้นตอนต่อมา เช่น

Concept เปลี่ยนบ่อย → Plan เปลี่ยน → งบประมาณเปลี่ยน → ระยะเวลาเปลี่ยน

ในทางกลับกัน Client Brief ที่ดีจะทำหน้าที่เหมือน Design Compass

ช่วยให้ทีมออกแบบรู้ว่า

“เรากำลังออกแบบเพื่ออะไร และกำลังแก้ปัญหาอะไรให้ลูกค้า?”

Client Brief ไม่ใช่ Client Requirement

สองคำนี้มีความเกี่ยวข้องกัน แต่ไม่เหมือนกัน

Client Requirement

คือสิ่งที่ลูกค้าบอกว่า “ต้องการ”

เช่น

ต้องการห้องนอน 4 ห้อง

Client Brief

คือการนำ Requirement และข้อมูลอื่น ๆ มาจัดระบบให้เห็นภาพรวมของโครงการ

เช่น

บ้านพักอาศัยสำหรับครอบครัว 4 คน มีห้องนอนหลัก 1 ห้อง ห้องนอนลูก 2 ห้อง ห้องพักแขก 1 ห้อง โดยต้องการแยกพื้นที่ส่วนตัวออกจากพื้นที่รับแขก และต้องการให้พื้นที่ส่วนกลางเป็นศูนย์กลางของกิจกรรมครอบครัว

ดังนั้น

Requirement = สิ่งที่ต้องการ
Brief = ความเข้าใจของโครงการทั้งหมด

1. Client Interview

Client Interview คือกระบวนการพูดคุยกับผู้ว่าจ้างเพื่อค้นหาข้อมูล ความต้องการ เป้าหมาย และปัญหาของโครงการ

การสัมภาษณ์ที่ดีไม่ควรเป็นเพียงการถามว่า

“อยากได้กี่ห้อง?”

แต่ควรค้นหาว่า

“ลูกค้าต้องการใช้ชีวิตหรือทำงานอย่างไร?”

คำถามพื้นฐาน

เกี่ยวกับโครงการ
- ทำไมจึงต้องการสร้างโครงการนี้?
- เป้าหมายหลักคืออะไร?
- ใครเป็นผู้ใช้งาน?
- อาคารจะใช้งานอย่างไร?
- ต้องการให้โครงการมีลักษณะอย่างไร?
เกี่ยวกับผู้ใช้งาน
- มีผู้ใช้งานกี่คน?
- อายุประมาณเท่าไร?
- มีผู้สูงอายุหรือเด็กหรือไม่?
- มีผู้พิการหรือผู้มีข้อจำกัดด้านการเคลื่อนไหวหรือไม่?
- รูปแบบการใช้ชีวิตเป็นอย่างไร?
เกี่ยวกับความคาดหวัง
- มีอาคารตัวอย่างที่ชอบหรือไม่?
- มีสิ่งที่ไม่ชอบหรือไม่?
- มี Reference Image หรือไม่?
- ต้องการภาพลักษณ์แบบใด?
การสัมภาษณ์ที่ดีควรใช้ทั้ง คำถามปลายเปิด และ คำถามเจาะลึก

2. Client Requirements

คือความต้องการโดยตรงจากผู้ว่าจ้าง

ตัวอย่าง:
- จำนวนห้อง
- ขนาดพื้นที่
- จำนวนที่จอดรถ
- ห้องประชุม
- ห้องครัว
- ห้องรับแขก
- สวน
- สระว่ายน้ำ
- พื้นที่สำนักงาน
แต่สถาปนิกไม่ควรหยุดเพียงการบันทึก Requirement

ควรถามต่อว่า

ทำไมจึงต้องการสิ่งนี้?

ตัวอย่าง:

Client: “ต้องการห้องประชุม 3 ห้อง”

สถาปนิกอาจถามต่อว่า

“แต่ละห้องใช้ประชุมกับใครบ้าง และใช้พร้อมกันหรือไม่?”

คำตอบอาจทำให้พบว่า จริง ๆ แล้วต้องการเพียง
- ห้องประชุมใหญ่ 1 ห้อง
- ห้องประชุมเล็ก 2 ห้อง
ซึ่งนำไปสู่การออกแบบที่เหมาะสมกว่า

3. User Requirements

Client กับ User อาจไม่ใช่คนเดียวกัน

ตัวอย่างเช่น
- เจ้าของโรงพยาบาล ≠ ผู้ป่วย
- เจ้าของโรงเรียน ≠ นักเรียน
- Developer ≠ ผู้อยู่อาศัย
- บริษัท ≠ พนักงาน
ดังนั้นต้องแยก

Client Requirements

ออกจาก

User Requirements

User Requirements อาจประกอบด้วย
- Functional Needs
- Physical Needs
- Privacy
- Comfort
- Accessibility
- Safety
- Wayfinding
- Social Interaction
- Operational Needs
คำถามสำคัญคือ

“คนที่จะใช้อาคารจริงต้องการอะไร?”

4. Project Goals

Project Goals คือเป้าหมายระดับโครงการ

เช่น
- สร้างบ้านสำหรับครอบครัว
- สร้างสำนักงานใหม่
- เพิ่มประสิทธิภาพการทำงาน
- สร้างภาพลักษณ์ใหม่ขององค์กร
- เพิ่มมูลค่าทรัพย์สิน
- ลดค่าใช้จ่ายในการดำเนินงาน
- ลดพลังงาน
- สร้างพื้นที่สำหรับชุมชน
ควรแยก Goal ออกจาก Feature

ตัวอย่าง

Goal = ต้องการให้สำนักงานส่งเสริมการทำงานร่วมกัน

ไม่จำเป็นต้องแปลทันทีว่า

Feature = ต้องมี Open Office

สถาปนิกควรสำรวจทางเลือกอื่นก่อน

5. Design Expectations

คือสิ่งที่ลูกค้าคาดหวังจากงานออกแบบ

อาจเกี่ยวกับ
- ภาพลักษณ์
- ประสบการณ์
- ความรู้สึก
- คุณภาพ
- ความทันสมัย
- ความหรูหรา
- ความอบอุ่น
- ความเป็นธรรมชาติ
- ความเป็นมืออาชีพ
ตัวอย่างคำว่า

“อยากให้บ้านดู Modern แต่ไม่เย็นเกินไป”

เป็น Design Expectation

หน้าที่ของสถาปนิกคือแปลงคำเหล่านี้ให้เป็นองค์ประกอบทางสถาปัตยกรรม เช่น
- Material
- Scale
- Lighting
- Texture
- Color
- Landscape
- Spatial Quality
6. Functional Requirements

Functional Requirements คือข้อกำหนดด้านการใช้งาน

เช่น
- จำนวนผู้ใช้งาน
- จำนวนห้อง
- ขนาดพื้นที่
- ความสัมพันธ์ระหว่างพื้นที่
- Circulation
- Storage
- Service
- Parking
- Loading
- Security
ตัวอย่าง:

ห้องประชุม 12 คน

อาจต้องแปลงต่อเป็น
- ขนาดห้อง
- โต๊ะประชุม
- จอ
- ระบบเสียง
- Storage
- ทางเดิน
- Acoustic
- ระยะห่างจากพื้นที่อื่น
ดังนั้น Functional Requirement เป็นจุดเริ่มต้นของ Space Programming

7. Aesthetic Requirements

คือความต้องการด้านรูปลักษณ์และบรรยากาศ

ตัวอย่าง:
- Minimal
- Modern
- Tropical
- Industrial
- Luxury
- Warm
- Natural
- Traditional
- Contemporary
แต่ควรระวังคำศัพท์ที่มีความหมายกว้าง

เช่นคำว่า

“Minimal”

อาจหมายถึงคนละอย่างสำหรับแต่ละคน

จึงควรถามด้วย
- Reference Image
- ตัวอย่างอาคาร
- Material
- Color
- Furniture
- Lighting
เพื่อเปลี่ยนคำอธิบายที่เป็นนามธรรมให้กลายเป็นข้อมูลที่ชัดเจนขึ้น

8. Budget Requirements

งบประมาณเป็นหนึ่งในข้อกำหนดที่มีผลต่อการออกแบบโดยตรง

ควรศึกษาทั้ง
- Construction Budget
- Design Fee
- Furniture
- Equipment
- Landscape
- Infrastructure
- Contingency
- Operation / Maintenance
และควรถามว่า

งบประมาณนี้เป็น Budget Target หรือ Budget Ceiling?

เพราะมีความหมายต่างกัน

Budget Target

เป็นงบประมาณเป้าหมายที่สามารถปรับได้

Budget Ceiling

เป็นงบประมาณสูงสุดที่ไม่ควรเกิน

ความแตกต่างนี้ส่งผลต่อ Design Strategy อย่างมาก

9. Time Requirements

ต้องศึกษาระยะเวลาของโครงการตั้งแต่ต้น

เช่น
- Project Start
- Concept
- Design Development
- Permit
- Tender
- Construction
- Handover
รวมถึง Critical Deadline

เช่น

ต้องเปิดใช้งานอาคารก่อนเดือนธันวาคม

ข้อมูลนี้อาจส่งผลต่อ
- Design Complexity
- Material Selection
- Construction Method
- Procurement
- Phasing
10. Constraints

Constraints คือข้อจำกัดของโครงการ

อาจมาจาก

Physical
- Site Shape
- Existing Building
- Existing Tree
- Slope
- Access
Regulatory
- Building Code
- Zoning
- Setback
- Height
- FAR
Financial
- Budget
Time
- Deadline
Client
- Existing Commitments
- Operational Constraints
Technical
- Structure
- MEP
- Existing Infrastructure
ข้อจำกัดไม่จำเป็นต้องเป็นสิ่งที่ทำให้การออกแบบแย่ลง

บางครั้ง Constraint สามารถกลายเป็น Design Driver

ได้

11. Priorities

เมื่อ Requirement มีจำนวนมาก ต้องรู้ว่าอะไรสำคัญที่สุด

สามารถจัดลำดับเป็น

Priority 1 — Critical

ต้องมีและไม่ควรลด

Priority 2 — Important

ควรมี แต่สามารถปรับได้

Priority 3 — Optional

มีได้ถ้างบประมาณและพื้นที่เอื้อ

ตัวอย่าง:

Requirement Priority
ห้องนอนหลัก Critical
ที่จอดรถ 2 คัน Critical
สวน Important
สระว่ายน้ำ Optional
Home Theater Optional

การจัด Priority ช่วยมากเมื่อเกิด Budget Constraint

12. Must Have / Nice to Have

เป็นวิธีง่าย ๆ ในการแยก Requirement

Must Have

สิ่งที่โครงการต้องมี

เช่น
- ห้องนอน
- ห้องน้ำ
- Parking
- Kitchen
- Office
Nice to Have

สิ่งที่อยากมี แต่สามารถตัดออกได้

เช่น
- Pool
- Gym
- Home Theater
- Rooftop Garden
ระบบนี้ช่วยให้ทีมออกแบบสามารถตัดสินใจได้เมื่อ

พื้นที่ไม่พอ หรือ Budget ไม่พอ

โดยไม่ต้องกลับไปเริ่มต้นใหม่ทั้งหมด

13. Hidden Requirements

นี่เป็นส่วนที่สำคัญมากสำหรับสถาปนิก

Hidden Requirements คือความต้องการที่ลูกค้าไม่ได้พูดออกมาโดยตรง แต่สามารถค้นพบได้จากการพูดคุยและพฤติกรรม

ตัวอย่าง:

Client บอกว่า

“อยากได้บ้านที่มีห้องรับแขกใหญ่”

แต่เมื่อถามต่อพบว่า

จริง ๆ แล้วต้องการพื้นที่สำหรับจัดงานเลี้ยงครอบครัวปีละหลายครั้ง

ดังนั้น Requirement จริงอาจไม่ใช่

Large Living Room

แต่คือ

Flexible Social Space

อีกตัวอย่าง:

Client บอกว่า

“ไม่อยากให้ห้องนอนติดถนน”

Hidden Requirement อาจเป็น

ต้องการความเป็นส่วนตัวและลดเสียงรบกวน

นี่คือคุณค่าที่สถาปนิกสามารถเพิ่มให้กับ Brief ได้

Client Brief ที่ดีควรมีอะไร?

หลังจากสัมภาษณ์และรวบรวมข้อมูลแล้ว สามารถจัดโครงสร้าง Brief ได้ประมาณนี้

01 Project Overview
- Project Name
- Project Type
- Location
- Client
- Project Background
02 Project Goals
- Business Goals
- User Goals
- Design Goals
03 Users
- User Groups
- Number of Users
- User Profiles
- User Behavior
04 Functional Requirements
- Space List
- Area
- Adjacency
- Circulation
- Service
05 Design Requirements
- Aesthetic
- Experience
- Performance
- Sustainability
06 Budget
- Target
- Ceiling
- Cost Priorities
07 Schedule
- Milestones
- Critical Dates
- Completion
08 Constraints
- Site
- Regulation
- Budget
- Time
- Technical
09 Priorities
- Must Have
- Important
- Nice to Have
10 Design Opportunities

สิ่งที่สามารถพัฒนาให้เกิดคุณค่าเพิ่มเติม

จาก Client Interview สู่ Client Brief

กระบวนการสามารถทำเป็น Workflow ได้ดังนี้
```
CLIENT INTERVIEW
       ↓
Conversation / Meeting
       ↓
Collect Information
       ↓
Transcribe
       ↓
Extract Requirements
       ↓
Classify
       ↓
Identify Priorities
       ↓
Identify Hidden Requirements
       ↓
Validate with Client
       ↓
CLIENT BRIEF
       ↓
SPACE PROGRAM
       ↓
DESIGN STRATEGY
```
สิ่งสำคัญคือ ต้องมีขั้น Validate with Client

เพราะ Brief ที่ AI หรือสถาปนิกสรุปขึ้นมาไม่ควรถูกถือว่าเป็นความจริงโดยอัตโนมัติ

ควรส่งกลับให้ลูกค้าตรวจสอบว่า

“นี่คือความเข้าใจของเราจากการพูดคุย ถูกต้องหรือไม่?”

AI กับ Client Brief

นี่เป็นหนึ่งในพื้นที่ที่ AI สามารถช่วยลดงานซ้ำของสถาปนิกได้มาก

1. Interview → Brief

นำ Transcript จากการสัมภาษณ์มาวิเคราะห์ แล้วสร้าง Draft Brief
```
Interview
    ↓
Transcript
    ↓
AI
    ↓
Project Goals
Requirements
Users
Constraints
Priorities
    ↓
Draft Client Brief
```
สถาปนิกตรวจสอบก่อนส่งให้ลูกค้า

2. Meeting → Requirements

AI สามารถช่วยอ่าน Meeting Notes และแยก Requirement ออกมา

ตัวอย่าง:

“คุณสมชายบอกว่าอยากให้พนักงานมีพื้นที่ทำงานร่วมกัน แต่ก็ต้องมีห้องที่สามารถคุยงานแบบส่วนตัวได้”

AI อาจแยกเป็น

Requirement 01

Collaborative Workspace

Requirement 02

Private Meeting Space

Design Implication

ต้องมีทั้ง Open Collaboration และ Enclosed Meeting Space

3. Voice → Text

การสัมภาษณ์ไม่จำเป็นต้องจดทุกอย่างด้วยมือ

สามารถใช้ระบบ

Voice → Transcription → AI Analysis

เพื่อเปลี่ยนบทสนทนาเป็นข้อมูลที่นำไปประมวลผลต่อได้

ข้อดีคือสถาปนิกสามารถให้ความสำคัญกับ การฟังและการถามคำถาม มากกว่าการจดทุกประโยค

4. Requirement Extraction

AI สามารถช่วยแยกข้อมูลจากบทสนทนา เช่น
```
FUNCTIONAL
- 4 Bedrooms
- 2 Car Parking

AESTHETIC
- Warm
- Modern
- Natural Materials

BUDGET
- Target Budget

TIME
- Completion before December

CONSTRAINT
- Preserve Existing Tree
```
จากนั้นสถาปนิกตรวจสอบอีกครั้ง

5. Brief Summarization

เมื่อมีข้อมูลจำนวนมาก AI สามารถสรุปเป็น Executive Brief ได้

เช่น

Project Goal:
Create a flexible family home that supports both private family life and frequent social gatherings while maintaining privacy from the surrounding neighborhood.

การสรุปนี้ช่วยให้ทีมออกแบบเข้าใจ หัวใจของโครงการ ได้รวดเร็วขึ้น

6. Requirement Classification

AI สามารถจัดประเภท Requirement อัตโนมัติ
```
Requirement
      ↓
AI Classification
      ↓
Functional
Aesthetic
Budget
Time
User
Regulatory
Technical
```
ทำให้ข้อมูลจาก Meeting ที่กระจัดกระจายกลายเป็น Structured Data

7. Client Persona

สำหรับโครงการที่มีผู้ใช้งานหลายกลุ่ม สามารถสร้าง Client / User Persona เพื่อช่วยให้ทีมออกแบบเข้าใจผู้ใช้งาน

ตัวอย่าง:

Persona: Young Family
- Age: 35–45
- Children: 2
- Lifestyle: Social
- Work: Hybrid
- Needs: Privacy + Flexible Space
- Pain Point: Storage
Persona ไม่ควรถูกใช้แทนข้อมูลจริงของผู้ใช้งาน แต่ใช้เป็นเครื่องมือช่วยสื่อสารและตั้งคำถามในการออกแบบ

8. Design Brief Generator

ในอนาคตสามารถสร้างระบบที่รับข้อมูล:
```
Project Type
Location
Client Interview
User Information
Budget
Schedule
Requirements
Constraints
References
```
แล้วสร้าง

Draft Architectural Design Brief

ออกมา

แต่ขั้นตอนสุดท้ายยังควรเป็น

Architect Review → Client Validation

ไม่ใช่

AI → Final Brief

AI ไม่ควรทำอะไรแทนสถาปนิก?

AI สามารถช่วย

Listen → Transcribe → Extract → Classify → Summarize → Organize

แต่สถาปนิกยังต้อง

Interpret → Question → Prioritize → Validate → Decide

เพราะ Requirement ที่ลูกค้าพูดออกมาอาจไม่ใช่ปัญหาที่แท้จริง

และบางครั้งสิ่งที่ลูกค้าต้องการกับสิ่งที่ลูกค้าจำเป็นต้องมีอาจไม่เหมือนกัน

บทบาทของสถาปนิกจึงไม่ได้ลดลงเมื่อมี AI

แต่เปลี่ยนจาก

ผู้จด Requirement

ไปเป็น

ผู้ตีความ Requirement และเปลี่ยนมันให้เป็น Design Opportunity

Client Brief → Design

สุดท้าย Client Brief ควรนำไปสู่ขั้นตอนต่อไป
```
CLIENT BRIEF
      ↓
PROJECT GOALS
      ↓
USER REQUIREMENTS
      ↓
FUNCTIONAL REQUIREMENTS
      ↓
SPACE PROGRAM
      ↓
DESIGN REQUIREMENTS
      ↓
DESIGN STRATEGY
      ↓
CONCEPT
```
ดังนั้น Client Brief ที่ดีไม่ได้มีคุณค่าเพราะเป็นเอกสารที่สวยงาม แต่มีคุณค่าเพราะสามารถตอบคำถามสำคัญได้ว่า

“เรากำลังออกแบบอะไร เพื่อใคร เพื่ออะไร ภายใต้ข้อจำกัดอะไร และอะไรคือสิ่งที่สำคัญที่สุด?”

Client Brief Checklist

ก่อนเริ่ม Concept Design ควรตรวจสอบว่า Brief มีข้อมูลเหล่านี้หรือไม่
- Project Background
- Client
- Users
- Client Requirements
- User Requirements
- Project Goals
- Design Expectations
- Functional Requirements
- Aesthetic Requirements
- Budget
- Schedule
- Constraints
- Priorities
- Must Have
- Nice to Have
- Hidden Requirements
- Design Opportunities
- Client Validation
สรุป

Client Brief คือการเปลี่ยน “สิ่งที่ลูกค้าพูด” ให้กลายเป็น “โจทย์ที่สถาปนิกสามารถนำไปออกแบบได้”

กระบวนการที่ดีคือ

Interview → Listen → Extract → Interpret → Classify → Prioritize → Validate → Brief

และเมื่อมี AI เข้ามาช่วย กระบวนการสามารถเร็วขึ้นอย่างมาก:

Voice → Transcript → AI → Requirements → Brief → Architect Review → Client Validation

แต่หัวใจของงานยังคงอยู่ที่สถาปนิก เพราะ AI สามารถช่วยจัดการข้อมูลได้ แต่ การตั้งคำถาม การค้นหา Hidden Requirements และการตัดสินใจว่าอะไรควรมีความสำคัญที่สุด ยังคงเป็นงานด้านวิชาชีพและการออกแบบ

Client Brief ที่ดีจึงไม่ใช่เพียงรายการสิ่งที่ลูกค้าอยากได้ แต่คือ “ความเข้าใจร่วมกัน” ระหว่างลูกค้า ผู้ใช้งาน และทีมออกแบบ ก่อนที่การออกแบบจะเริ่มต้นขึ้น
สิงหาคม 3, 2026
PD01. – Site Research
Site Research คืออะไร? คู่มือการเก็บข้อมูลพื้นที่ก่อนเริ่มออกแบบสถาปัตยกรรม

Site Research คือกระบวนการศึกษาข้อมูลของพื้นที่โครงการและบริบทโดยรอบ ก่อนที่สถาปนิกจะเริ่มพัฒนาแนวคิดการออกแบบอย่างจริงจัง

การออกแบบที่ดีไม่ได้เริ่มต้นจากคำถามว่า “เราจะออกแบบอาคารหน้าตาอย่างไร?” แต่ควรเริ่มจากคำถามว่า

“สถานที่แห่งนี้มีอะไรอยู่แล้ว และเราควรออกแบบให้ตอบสนองต่อสิ่งเหล่านั้นอย่างไร?”

Site Research จึงเป็นขั้นตอนสำคัญในช่วง Pre-Design เพราะช่วยให้สถาปนิกเข้าใจทั้งข้อจำกัด โอกาส ผู้ใช้งาน สภาพแวดล้อม กฎหมาย และลักษณะเฉพาะของพื้นที่ ก่อนนำข้อมูลเหล่านั้นไปสู่ Site Analysis, Design Strategy และ Concept Design

สิ่งสำคัญคือ Site Research ไม่ใช่เพียงการรวบรวมข้อมูล แต่คือการสร้าง Context ของโครงการ เพื่อให้การตัดสินใจออกแบบในขั้นตอนต่อไปมีข้อมูลรองรับ

Site Research ต่างจาก Site Analysis อย่างไร?

สองคำนี้มักถูกใช้แทนกัน แต่ในกระบวนการออกแบบควรแยกหน้าที่ออกจากกัน

Site Research

เน้น การค้นหาและรวบรวมข้อมูล

ตัวอย่างเช่น
- ที่ตั้งอยู่ที่ไหน
- ถนนรอบพื้นที่เป็นอย่างไร
- อาคารข้างเคียงมีอะไรบ้าง
- มีกฎหมายอะไรควบคุม
- สภาพภูมิอากาศเป็นอย่างไร
- มีระบบขนส่งอะไรอยู่ใกล้เคียง
Site Analysis

นำข้อมูลเหล่านั้นมาวิเคราะห์เพื่อหา
- Constraints
- Opportunities
- Problems
- Potentials
- Design Implications
พูดง่าย ๆ คือ

Site Research = รู้ว่า “มีอะไร”
Site Analysis = เข้าใจว่า “สิ่งนั้นมีผลต่อการออกแบบอย่างไร”

ดังนั้น Site Research จึงเป็นฐานข้อมูลสำคัญก่อนเข้าสู่ Site Analysis

1. Site Location

Site Location คือการระบุตำแหน่งและขอบเขตของพื้นที่โครงการอย่างชัดเจน

ข้อมูลพื้นฐานที่ควรรวบรวม ได้แก่
- ประเทศ
- จังหวัด / เมือง
- เขต / อำเภอ
- ถนน
- ตำแหน่งที่ตั้ง
- พิกัด
- ขนาดพื้นที่
- รูปร่างแปลงที่ดิน
- ขอบเขตที่ดิน
- ระดับความสูงโดยประมาณ
ควรศึกษาตั้งแต่ระดับ Macro → Micro

เช่น

ประเทศ → เมือง → เขต → ย่าน → ถนน → แปลงที่ดิน

การมองหลายระดับช่วยให้เห็นว่าพื้นที่ไม่ได้เป็นพื้นที่โดดเดี่ยว แต่เป็นส่วนหนึ่งของระบบเมืองและบริบทที่ใหญ่กว่า

สิ่งที่ควรได้
- Location Map
- Site Plan
- Satellite Image
- Site Boundary
- Context Map
2. Site Context

Site Context คือข้อมูลโดยรวมที่อธิบายความสัมพันธ์ระหว่างพื้นที่โครงการกับสิ่งแวดล้อมโดยรอบ

ควรศึกษาว่า
- รอบพื้นที่มีอะไร
- ถนนอยู่ด้านไหน
- อาคารสำคัญอยู่ตรงไหน
- พื้นที่เปิดโล่งอยู่บริเวณใด
- มีแหล่งน้ำหรือพื้นที่สีเขียวหรือไม่
- กิจกรรมสำคัญเกิดขึ้นบริเวณใด
Site Context ช่วยให้สถาปนิกมองพื้นที่ในฐานะ ส่วนหนึ่งของระบบ แทนที่จะมองเฉพาะขอบเขตที่ดิน

3. Surrounding Buildings

ศึกษาลักษณะของอาคารที่อยู่รอบโครงการ

ประเด็นที่ควรสำรวจ ได้แก่
- ประเภทอาคาร
- จำนวนชั้น
- ความสูง
- อายุอาคาร
- รูปแบบอาคาร
- วัสดุ
- สี
- ระยะ Setback
- ทางเข้าออก
- ความหนาแน่น
- การใช้งาน
ตัวอย่างเช่น พื้นที่รอบโครงการอาจมี

อาคารพาณิชย์ 3–4 ชั้นด้านหนึ่ง และบ้านพักอาศัย 2 ชั้นอีกด้านหนึ่ง

ข้อมูลนี้อาจส่งผลต่อการกำหนด Building Scale, Massing และ Privacy ของโครงการ

4. Urban Context

Urban Context คือการศึกษาพื้นที่ในระดับเมือง

ควรพิจารณา
- โครงสร้างเมือง
- ถนนสายหลัก
- ถนนรอง
- ศูนย์กลางเมือง
- Commercial Area
- Residential Area
- Public Space
- Green Space
- Transit
- Landmark
- Urban Development
คำถามสำคัญคือ

โครงการนี้อยู่ตรงไหนของระบบเมือง?

และ

อาคารใหม่จะมีความสัมพันธ์อย่างไรกับโครงสร้างเมืองเดิม?

5. Neighborhood Analysis

ศึกษาลักษณะของ ย่าน ที่โครงการตั้งอยู่

ข้อมูลที่น่าสนใจ เช่น
- กลุ่มผู้ใช้งาน
- ประเภทที่อยู่อาศัย
- ธุรกิจ
- ร้านค้า
- โรงเรียน
- โรงพยาบาล
- ศาสนสถาน
- ตลาด
- สถานที่ราชการ
- พื้นที่สาธารณะ
- ช่วงเวลาที่มีคนหนาแน่น
Neighborhood Analysis ช่วยให้เข้าใจ ชีวิตจริงของพื้นที่ มากกว่าการดูเพียงแผนที่

6. Transportation

ศึกษาระบบการเดินทางที่เกี่ยวข้องกับพื้นที่

เช่น
- รถยนต์
- รถจักรยานยนต์
- รถโดยสาร
- รถไฟฟ้า
- รถไฟ
- เรือ
- จักรยาน
- การเดินเท้า
ควรดูทั้ง ระดับการเข้าถึง และ รูปแบบการเดินทาง

ตัวอย่างคำถาม:
- สถานีขนส่งอยู่ห่างเท่าไร?
- ถนนสายหลักอยู่ตรงไหน?
- รถสามารถเข้าถึงพื้นที่ได้จากด้านใด?
- มี Traffic สูงหรือไม่?
7. Accessibility

Accessibility ไม่ได้หมายถึงเพียงการเข้าถึงของรถยนต์ แต่รวมถึงการเข้าถึงของผู้ใช้งานทุกกลุ่ม

ควรศึกษาการเข้าถึงของ
- Pedestrian
- Car
- Motorcycle
- Bicycle
- Public Transport
- Service Vehicle
- Emergency Vehicle
- ผู้สูงอายุ
- ผู้ใช้รถเข็น
- ผู้พิการ
ประเด็นนี้จะเชื่อมต่อโดยตรงกับการวาง

Entrance → Circulation → Parking → Service Access

8. Existing Infrastructure

ศึกษาระบบสาธารณูปโภคและโครงสร้างพื้นฐานที่มีอยู่

เช่น
- ไฟฟ้า
- ประปา
- โทรคมนาคม
- ระบบระบายน้ำ
- ท่อระบายน้ำ
- Sewer
- ถนน
- Street Lighting
- Fire Hydrant
- ระบบสื่อสาร
ข้อมูลเหล่านี้อาจมีผลต่อทั้ง Site Planning และ Construction Cost

โดยเฉพาะโครงการที่มีพื้นที่พัฒนาเดิมหรืออยู่ในพื้นที่เมืองเก่า

9. Existing Buildings

หากในพื้นที่มีอาคารเดิม ต้องสำรวจอย่างละเอียด

เช่น
- ตำแหน่งอาคาร
- ขนาด
- ความสูง
- โครงสร้าง
- วัสดุ
- สภาพอาคาร
- ทางเข้า
- ระบบอาคาร
- การใช้งาน
- คุณค่าทางสถาปัตยกรรม
จากนั้นจึงพิจารณาว่าอาคารเดิมควร

Keep → Modify → Extend → Reuse → Remove

ข้อมูลนี้สำคัญมากในงาน Renovation และ Adaptive Reuse

10. Existing Landscape

ศึกษาภูมิทัศน์เดิมของพื้นที่

เช่น
- ต้นไม้
- พุ่มไม้
- สนามหญ้า
- พื้นที่สีเขียว
- แหล่งน้ำ
- ทางเดิน
- Hardscape
- Existing Garden
- Natural Features
ควรบันทึกตำแหน่งและขนาดของต้นไม้สำคัญ โดยเฉพาะต้นไม้ใหญ่ที่ไม่ควรถูกมองว่าเป็นเพียง “สิ่งกีดขวาง”

ต้นไม้เดิมอาจกลายเป็น Design Asset ของโครงการได้

11. Climate

ศึกษาสภาพภูมิอากาศของพื้นที่

ข้อมูลที่ควรพิจารณา เช่น
- อุณหภูมิ
- ความชื้น
- ปริมาณฝน
- ฤดูกาล
- แสงแดด
- ลม
- เมฆ
- Extreme Weather
สำหรับงานสถาปัตยกรรม Climate Research ช่วยให้เข้าใจว่าอาคารควรตอบสนองต่อสภาพแวดล้อมอย่างไร

เช่น

ลดความร้อน → เพิ่ม Shading
ฝนมาก → พิจารณาการระบายน้ำ
ลมดี → ใช้ประโยชน์จาก Natural Ventilation

12. Sun Path

ศึกษาทิศทางและตำแหน่งของดวงอาทิตย์ตลอดทั้งวันและทั้งปี

ควรดู
- ทิศเหนือ
- ทิศใต้
- ทิศตะวันออก
- ทิศตะวันตก
- Morning Sun
- Afternoon Sun
- Solar Exposure
- Seasonal Variation
โดยเฉพาะในประเทศไทย แดดช่วงบ่ายจากทิศตะวันตก มักเป็นประเด็นสำคัญต่อการออกแบบอาคาร

ข้อมูล Sun Path สามารถนำไปใช้ต่อกับ
- Building Orientation
- Massing
- Window
- Shading
- Facade
- Landscape
13. Wind

ศึกษาทิศทางและรูปแบบลมในพื้นที่

ข้อมูลที่ควรพิจารณา
- Prevailing Wind
- Wind Direction
- Wind Speed
- Seasonal Wind
- Natural Ventilation
- Urban Wind
สำหรับอาคารที่ต้องการใช้ Passive Design ข้อมูลลมสามารถส่งผลต่อ
- Orientation
- Opening
- Courtyard
- Building Spacing
- Massing
ในโครงการขนาดใหญ่ อาจต่อยอดไปสู่ Computational Fluid Dynamics (CFD) หรือ Wind Simulation ได้

14. Noise

ศึกษาระดับและแหล่งกำเนิดเสียงรอบพื้นที่

เช่น
- ถนน
- รถไฟ
- สนามบิน
- โรงงาน
- ร้านค้า
- สถานบันเทิง
- โรงเรียน
- กิจกรรมชุมชน
ควรบันทึกทั้ง

Source → Direction → Intensity → Time

เพราะเสียงที่เกิดขึ้นในช่วงกลางวันอาจแตกต่างจากกลางคืน

ผลการศึกษาอาจนำไปสู่
- Buffer Zone
- Building Orientation
- Acoustic Treatment
- Landscape Buffer
- Room Planning
15. Views

ศึกษาทั้ง สิ่งที่มองเห็นจาก Site และ สิ่งที่คนภายนอกมองเห็นมายัง Site

ควรแบ่งเป็น

Positive Views

เช่น
- ภูเขา
- แม่น้ำ
- เมือง
- สวน
- Landmark
Negative Views

เช่น
- อาคารเก่า
- กำแพง
- ที่จอดรถ
- โรงงาน
- ถนนที่มีความแออัด
จากนั้นจึงพิจารณาว่า

ควรเปิด / ปิด / Frame / Filter View อย่างไร

16. Surrounding Activities

ศึกษากิจกรรมที่เกิดขึ้นรอบพื้นที่

ไม่ใช่แค่ “มีอะไรอยู่ตรงไหน” แต่ต้องดูว่า

“ผู้คนทำอะไร ที่ไหน และเมื่อไร?”

เช่น
- Morning Market
- Street Food
- School Activities
- Night Market
- Office Traffic
- Weekend Activities
- Religious Activities
- Community Events
การศึกษาเรื่อง Time + Activity จะช่วยให้เข้าใจ Behavior ของพื้นที่

17. Local Character

แต่ละพื้นที่มีเอกลักษณ์ที่แตกต่างกัน

Local Character อาจเกิดจาก
- Architecture
- Material
- Color
- Scale
- Street Pattern
- Landscape
- Culture
- Lifestyle
- Signage
- Local Craft
- Building Typology
คำถามสำคัญคือ

อะไรคือสิ่งที่ทำให้พื้นที่นี้ “เป็นพื้นที่นี้” และไม่ใช่พื้นที่อื่น?

ข้อมูลนี้สามารถนำไปสู่การสร้าง Architectural Language ที่มีความสัมพันธ์กับบริบท

18. Historical Context

ศึกษาประวัติความเป็นมาของพื้นที่

เช่น
- ประวัติชุมชน
- การเปลี่ยนแปลงของเมือง
- อาคารประวัติศาสตร์
- Heritage
- วัฒนธรรม
- เหตุการณ์สำคัญ
- การเปลี่ยนแปลงการใช้ที่ดิน
Historical Context มีความสำคัญมากในพื้นที่ที่มีคุณค่าทางประวัติศาสตร์

เพราะการออกแบบใหม่อาจไม่ได้มีหน้าที่เพียง “สร้างอาคารใหม่” แต่ต้องพิจารณาความสัมพันธ์กับ Memory และ Identity ของพื้นที่

19. Regulations

ศึกษากฎหมายและข้อกำหนดที่เกี่ยวข้องกับโครงการ

ตัวอย่างเช่น
- Building Control
- Fire Safety
- Accessibility
- Environmental Regulations
- Local Regulations
- Heritage Regulations
- Land Use
- Building Setback
- Height Restriction
- Parking Requirement
ข้อมูลด้าน Regulations ควรใช้จาก แหล่งข้อมูลทางการและฉบับปัจจุบัน และควรตรวจสอบโดยผู้เชี่ยวชาญก่อนนำไปใช้เป็นข้อกำหนดในการออกแบบจริง

AI สามารถช่วยค้นหา สรุป และจัดหมวดหมู่กฎหมายได้ แต่ไม่ควรถือว่า AI เป็นแหล่งยืนยันข้อกฎหมายขั้นสุดท้าย

20. Planning Controls

Planning Controls เป็นข้อกำหนดที่ควบคุมว่า พื้นที่สามารถพัฒนาอย่างไรได้บ้าง

ตัวอย่างเช่น
- Land Use
- FAR
- OSR
- Site Coverage
- Building Height
- Setback
- Building Line
- Open Space
- Parking
- Access
- Density
ข้อมูลเหล่านี้สามารถเปลี่ยนจาก “กฎหมาย” ให้กลายเป็น Design Constraints

ตัวอย่าง:

FAR = 8.0
Site Area = 2,000 m²

จึงสามารถนำไปคำนวณศักยภาพพื้นที่อาคารเบื้องต้น และนำไปศึกษาต่อในขั้น Feasibility และ Massing

Site Research → Design

สิ่งสำคัญที่สุดของ Site Research ไม่ใช่การรวบรวมข้อมูลให้ได้มากที่สุด

แต่คือการนำข้อมูลเหล่านั้นไปสู่การตัดสินใจออกแบบ

ตัวอย่าง:
```
SITE RESEARCH
      ↓
Site Location
Site Context
Climate
Sun
Wind
Noise
Views
Activities
Regulations
      ↓
SITE ANALYSIS
      ↓
Constraints
Opportunities
      ↓
DESIGN IMPLICATIONS
      ↓
DESIGN STRATEGY
      ↓
CONCEPT DESIGN
```
ตัวอย่างเช่น

Research

ทิศตะวันตกได้รับแดดช่วงบ่ายมาก

↓

Analysis

พื้นที่ด้านตะวันตกมี Solar Exposure สูง

↓

Design Implication

ลดพื้นที่เปิดช่องรับแสงโดยตรงและเพิ่ม Solar Shading

↓

Design Strategy

ใช้ Service Zone เป็น Buffer ด้านตะวันตก

↓

Design

วาง Core / Service Spaces ทางทิศตะวันตก และเปิดพื้นที่ใช้งานหลักไปยังทิศที่เหมาะสมกว่า

นี่คือจุดที่ Site Research กลายเป็น Architecture

Site Research กับ AI

AI สามารถเข้ามาช่วยในหลายขั้นตอนของ Site Research โดยเฉพาะงานที่ต้องใช้การค้นหา รวบรวม เปรียบเทียบ และสรุปข้อมูลจำนวนมาก

AI สามารถช่วยได้ใน

Research
- ค้นหาข้อมูล
- สรุปข้อมูล
- วิเคราะห์เอกสาร
- จัดหมวดหมู่ข้อมูล
Visual Analysis
- วิเคราะห์ภาพ Site
- วิเคราะห์อาคารโดยรอบ
- วิเคราะห์ Landscape
- วิเคราะห์ Urban Context
Data Processing
- จัดข้อมูล
- เปรียบเทียบข้อมูล
- สร้างตาราง
- สรุปประเด็น
Communication
- สร้าง Diagram
- สร้าง Report
- สร้าง Presentation
- สร้าง Site Research Summary
แต่ควรจำหลักสำคัญว่า

AI ช่วยค้นหาและประมวลผลข้อมูล แต่สถาปนิกต้องตรวจสอบความถูกต้องและตีความข้อมูลก่อนนำไปใช้ในการออกแบบ

โดยเฉพาะข้อมูลด้าน กฎหมาย, ผังเมือง, ขนาดพื้นที่, พิกัด และข้อมูลทางวิศวกรรม

ลองทำ: Site Context Diagram ด้วย AI

ตัวอย่างนี้ใช้ AI เปลี่ยนภาพดาวเทียมของที่ตั้งให้เป็น Site Context Diagram ภาพเดียวที่สรุปข้อมูลหลายหัวข้อในบทความนี้ ได้แก่ Site Location, Site Context, Surrounding Buildings, Accessibility, Sun Path และ Wind

ขั้นที่ 1: เตรียมภาพ
1. จับภาพหน้าจอแผนที่ดาวเทียมของที่ตั้ง โดยให้ทิศเหนืออยู่ด้านบนของภาพ
2. ลากเส้นขอบเขตที่ดินเป็นสีแดง
3. เตรียมข้อมูลทิศลมประจำของพื้นที่ และสถานที่สำคัญใกล้เคียง 2–3 แห่ง
ขั้นที่ 2: อัปโหลดภาพแล้วใช้ Prompt นี้
```
You are an architect preparing a Site Research board for the Pre-Design phase.
Use the attached satellite image as the base. The project site is the area outlined in red. North is at the top of the image.

Create a clean architectural site context diagram on top of this image:
1. Keep the base image visible but desaturated (light grey). Keep the red site boundary bold.
2. Show the surrounding roads by hierarchy: main road (thick line), secondary road (medium line), small lane (thin line).
3. Color-code the surrounding buildings by use: residential (yellow), commercial (orange), public/institutional (blue), green/open space (green), water (light blue).
4. Mark vehicle access and pedestrian access to the site with arrows.
5. Add a north arrow, a simple sun path arc from east to west, and an arrow for the prevailing wind from the [SOUTHWEST].
6. Label these nearby landmarks: [LANDMARK 1], [LANDMARK 2], [LANDMARK 3].
7. Add a small legend in one corner.

Style: flat architectural diagram, thin and precise linework, limited color palette, short English labels that are easy to read.
Do not add or invent buildings that are not in the original image.
```
เปลี่ยนข้อความในวงเล็บเหลี่ยมให้ตรงกับที่ตั้งจริง เช่น ทิศลมประจำ (พื้นที่ภาคกลางส่วนใหญ่ใช้ลมตะวันตกเฉียงใต้) และชื่อสถานที่สำคัญ เช่น สถานีรถไฟฟ้า โรงเรียน หรือสวนสาธารณะ

ขั้นที่ 3: ตรวจผลลัพธ์ก่อนใช้งาน

AI อาจวางทิศแดด ทิศลม ทางเข้า หรือประเภทอาคารรอบข้างผิดได้ ให้ใช้ภาพนี้เป็นภาพร่างเพื่อสื่อสารแนวคิด และตรวจกับข้อมูลจริงจากการสำรวจหน้างานทุกครั้งก่อนนำไปใช้ต่อใน Site Analysis

ตัวอย่างผลลัพธ์

ภาพ Input: ภาพดาวเทียมที่ตั้ง ทิศเหนืออยู่ด้านบน และลากขอบเขตที่ดินเป็นสีแดง

ผลลัพธ์: Site Context Diagram ที่ AI สร้างจาก Prompt ด้านบน

ข้อสังเกต: AI วาด Sun Path โค้งไปทางทิศเหนือ ซึ่งไม่ถูกต้องสำหรับประเทศไทย เพราะดวงอาทิตย์จะอ้อมทางทิศใต้เกือบทั้งปี และ scale bar ในภาพเป็นสิ่งที่ AI สร้างขึ้นเอง ต้องตรวจกับขนาดจริงก่อนใช้งาน นี่คือเหตุผลที่ต้องตรวจผลลัพธ์ทุกครั้งตามขั้นที่ 3

Site Research Checklist

ก่อนจบขั้นตอน Site Research ควรตรวจสอบอย่างน้อยว่าเรามีข้อมูลเหล่านี้หรือไม่
- Site Location
- Site Boundary
- Site Context
- Surrounding Buildings
- Urban Context
- Neighborhood
- Transportation
- Accessibility
- Infrastructure
- Existing Buildings
- Existing Landscape
- Climate
- Sun Path
- Wind
- Noise
- Views
- Surrounding Activities
- Local Character
- Historical Context
- Regulations
- Planning Controls
แต่ Checklist ที่ดีไม่ควรจบเพียงคำว่า “มีข้อมูลแล้ว”

ควรมีคำถามต่อว่า

ข้อมูลนี้มีผลต่อการออกแบบอย่างไร?

สรุป

Site Research คือจุดเริ่มต้นของการทำความเข้าใจสถานที่ก่อนเริ่มออกแบบ

การศึกษาที่ดีควรครอบคลุมทั้ง

Physical Context + Environmental Context + Social Context + Cultural Context + Regulatory Context

และสิ่งที่สำคัญที่สุดคือการเปลี่ยน

Data → Information → Analysis → Design Insight → Design Decision

ดังนั้น Site Research ที่ดีจึงไม่ใช่การทำ Site Analysis Board ที่เต็มไปด้วยข้อมูล แต่คือการค้นหาว่า

“สถานที่แห่งนี้กำลังบอกอะไรเราก่อนที่เราจะออกแบบ?”

เมื่อเข้าใจคำตอบของคำถามนี้แล้ว จึงค่อยนำไปสู่ขั้นตอนต่อไปคือ Site Analysis และ Design Strategy ซึ่งเป็นจุดที่ข้อมูลจาก Site Research เริ่มเปลี่ยนเป็นแนวทางการออกแบบอย่างเป็นรูปธรรม

คำถามที่พบบ่อย (FAQ)

Site Research กับ Site Analysis ต่างกันอย่างไร?

Site Research คือการรวบรวมข้อมูลว่าพื้นที่มีอะไรบ้าง เช่น ถนน อาคารข้างเคียง กฎหมาย และภูมิอากาศ ส่วน Site Analysis คือการนำข้อมูลเหล่านั้นมาวิเคราะห์หาข้อจำกัด โอกาส และผลต่อการออกแบบ

AI ช่วยงาน Site Research ได้แค่ไหน?

AI ช่วยสรุปข้อมูลบริบท ร่างรายการสิ่งที่ต้องสำรวจ และทำ Site Context Diagram จากภาพดาวเทียมได้รวดเร็ว แต่ข้อมูลกฎหมาย ระยะร่น และผังเมือง ต้องตรวจจากเอกสารทางการทุกครั้ง

ต้องเตรียมอะไรก่อนใช้ AI ทำ Site Research?

ภาพดาวเทียมหรือแผนที่ที่ระบุขอบเขตที่ดินและทิศเหนือ ขนาดแปลง ภาพถ่ายหน้างาน และข้อมูลโครงการเบื้องต้นจาก Client Brief

ภาพ Site Context Diagram จาก AI ใช้นำเสนอลูกค้าได้เลยไหม?

ใช้เป็นภาพร่างเพื่อสื่อสารแนวคิดได้ แต่ควรตรวจทิศแดด ทิศลม ทางเข้า และประเภทอาคารรอบข้างกับข้อมูลจริงก่อนนำเสนอ

ทำ Site Research เสร็จแล้วต้องทำอะไรต่อ?

นำข้อมูลไปวิเคราะห์ต่อในขั้น Site Analysis เพื่อหาข้อจำกัดและโอกาสของพื้นที่ ก่อนเข้าสู่การกำหนด Design Strategy
สิงหาคม 2, 2026

Requirement	Priority
ห้องนอนหลัก	Critical
ที่จอดรถ 2 คัน	Critical
สวน	Important
สระว่ายน้ำ	Optional
Home Theater	Optional

หมวดหมู่: Design Process

CD04. – Massing

Massing คืออะไร? การพัฒนามวลอาคารจาก Concept สู่รูปทรงสถาปัตยกรรม

Massing อยู่ตรงไหนใน Design Process?

Massing ไม่ใช่ Form Finding

Massing

Form Finding

1. Basic Massing

2. Building Envelope

3. Height

4. Setback

5. Orientation

6. Volume

Add

Subtract

Shift

Rotate

Stack

Split

7. Solid / Void

8. Courtyard

9. Tower / Podium

Podium

Tower

10. Atrium

11. Stepped Massing

12. Terracing

Massing กับ Site

Sun

Wind

View

Noise

Massing กับ Program

Large Public Space

Private Rooms

Service

Massing กับ Circulation

Central Spine

Courtyard Loop

Vertical Core

Massing กับ Environment

Massing Development Process

Massing Iteration

Option A

Option B

Option C

Option D

Option E

AI กับ Massing

1. Massing Generation

2. Massing Variation

3. Image-to-Massing

4. 3D Concept

5. AI Form Exploration

AI Massing Workflow

From AI Image to Real Massing

Massing Evaluation Matrix

Massing Checklist

Site

Form

Program

Environment

Technical

AI

Massing Design Framework

สรุป

CD03. – Concept Development

Concept Development คืออะไร? จากแนวคิดสู่แบบสถาปัตยกรรมที่พัฒนาแล้ว

Concept Development อยู่ตรงไหนใน Design Process?

Concept Development ต่างจาก Design Concept อย่างไร?

Design Concept

Design Strategy

Concept Development

1. Sketch

Sketch เป็นเครื่องมือคิด ไม่ใช่เพียงเครื่องมือบันทึก

2. Diagram

3. Iteration

Iteration 01

Iteration 02

Iteration 03