SESSION 05 / 06
「いい感じにやって」は
通じない
語彙・CLI・30秒の宿題
Jee Jun Young
非情報系（経営学科）→ 記者・海外営業 → 開発者に転向
iOS・Android・フロントエンド 約5年半（6年目）
大企業向けコラボレーションツールのiOS／macOSアプリ開発
2026年〜 バイブコーディングでWeb・サーバーを一人で開発・事業化
TODAY · 5 PARTS
今日の範囲
左側にPART番号を常に表示します。今どこにいるか見失わないためです。
PART 1 — 第4回の振り返り
F12を押してみましたね？
それが原則#8です。
pk_*・anon）と秘密（sk-*・service_role）— 盗まれたら請求額か、DBか？今日はもう一歩先の、「言葉の正確さ」の話です。
第2回の注文票のたとえ — 振り返り
「いい感じにやって」では適当なものしか出てきません。
🎨 デザイナーのたとえ — 同じ話。「モダンで伝統的、23世紀の未来感」という案を渡すと、クライアントの欲しい結果は出ません。
詳しい注文票を書くには、言葉が必要です。
その言葉が技術用語です。
CASE
同じプロジェクト、異なる成果物
HttpOnly Cookieによるセッション、
RLSでユーザーを分離、
パスワードはサーバーでハッシュ化。
画面全体の読み込みレイヤーで連打を防ぎ、
Material Designのアニメーションを付けて。」
違いは、Bが言葉を知っていたことだけ。
コードはClaudeが書きます。
YOU ALREADY KNOW THESE
過去4回で出てきた言葉
＋今日（第5回）の新しい用語 — 第4回スライド40で予告
クリーンアーキテクチャMVVMFSDデザインパターン「ああ、そんなものがあったな」「言葉を思い出せない」
「ほかに聞くべきことはあるかな？」
こう考えているだけで、
まだ始めていない人より先に進んでいます。
全部覚える必要はありません。
ただし、「こういう言葉がある」という認識は必要です。
言葉があってこそ、AIに「それは何？」と聞けます。
知らないから始められないわけではありません。
知らなければ聞く。ただし、何を聞くべきかは知る必要があります。
WHY・CONTEXT ROT（文脈の劣化）
なぜデザインパターン・アーキテクチャ・技術用語が
費用に直結するのか
寝室に菓子袋・パソコン・ガスコンロ・卵の殻・パックご飯が散らばっています。
清掃業者が入って見積もったら、数十万ウォン？ 100万ウォン？ そのまま帰るかもしれません。
一方、睡眠と休息だけに使ったきれいな部屋なら、2時間で終わり、安く済みます。
この清掃業者がAIで、
見積額が皆さんの払うトークンです。
部屋が散らかるほど、AIにお金がかかります。
ひどすぎると、作業中に逃げ出したり、4時間休んで戻ったりします。混乱するからです。
学術用語ではContext Rot、直訳すれば「文脈の劣化」。第3回で扱った概念です。
長いコードや文書を読んでいる途中でAIが中間を忘れ、迷う現象です（Liuほか、2023年、Lost in the Middle）。
だから、デザインパターンやアーキテクチャは「開発者の自慢」ではなく、
バイブコーダーの費用削減とAIとの安定した協働の核心です。
BIG PICTURE
デザインパターンとアーキテクチャを一目で
たとえ：料理本のレシピ。
同じ問題には同じパターンを。
例：Singleton・Factory・Observer・Repository・Adapter
出典：GoF（Gang of Four）の23パターン、1994年
たとえ：都市計画（道路・区画・電気）。
一度決めると変えにくい、大きな決定。
例：MVC・MVVM・クリーン・ヘキサゴナル・FSD
代表的なアーキテクチャを、一言のたとえで
自動販売機。画面とデータを分ける。
→ 次のスライドで説明
玉ねぎのような同心円。
内側＝中核ロジック、外側＝付随物（DB・画面・API）。
内側は外側を知らずに動く。DBを変えても中核は変わらない。
カフェの本部と加盟店。
本部（ドメイン）はメニューとマニュアルだけ。
加盟店（アダプター）が客・材料・決済を扱う。加盟店を変えても本部はそのまま。
縦の6層と、ドメイン別店舗の二重の分割。フロントエンド専用。
→ 次のスライドで百貨店のたとえを使って説明
これらはすべて、何十年も検証された方法論です。
MVCは1979年、ヘキサゴナル・MVVMは2005年、クリーンは2012年、FSDは2018年〜。
だから、AIの学習データに豊富にあります。
言葉を一つ渡すだけでClaudeは正確に理解します。それが今日、語彙を扱う理由です。
INSTRUCTOR CASE · GRIMOIRE
講師自身の事例 — ヘキサゴナル＋簡略版FSD
最初にしたこと：自己診断（やみくもに導入しない）
私が作ったiOSアプリのコードをClaudeに全部読ませてから、直接聞きました。
「このコードの水準で、WebはFSD、サーバーはヘキサゴナルにしても保守できる？ 診断して。」
Claudeの答えを100％信用した？ いいえ。別のAIにも同じ質問をして、見積もりました。
結果① — サーバー（grimoire-server）
ヘキサゴナル（Ports & Adapters）を導入。
ドメインを中心に、DB・外部API・HTTPルーターをアダプターとして分離。
コード構造：domain / application / adapter / infrastructure
結果② — Web（grimoire-web）
FSDを簡略化して導入。厳密な6層にはせず、
主要スライス（features/auth・features/payment・features/works）だけをドメイン単位に。
伝えたいこと：アーキテクチャは暗記するものではありません。
「自分が導入できる水準か」をAIに診断させます。
VOCABULARY VIA ANALOGY
専門用語を日常のたとえで理解する
デザインパターン・アーキテクチャ・アルゴリズムは、初めての言葉が次々に出る分野です。
一文字ずつ暗記しようとすると大変です。
コツは、日常にも必ず同じパターンがあること。そこにソフトウェアのロジックを一層加えたものが、デザインパターン・アーキテクチャ・アルゴリズムです。こう考えると抵抗感が下がります。
実演：3つのデータ構造を日常に置き換える
コンビニの飲料棚。
店員は後ろから新しいものを補充し、客は前から取ります。先に入れたものが先に出る。
机の上に積んだ本。
新しい本を上に置き、上から取って読みます。後に置いたものが先に出る。Ctrl+Zもスタックです。
学校のロッカー。
学籍番号（キー）がわかれば、自分の区画（値）に一度で到達。順番に一つずつ探す必要はありません。
新しい言葉に出会ったら、「日常で似たものは何？」と探してみてください。
これから扱うMVVM・FSD・クリーン・SOLIDも、自販機・百貨店・玉ねぎ・寿司店の厨房にたとえて説明します。
MVVM
MVVMとは？ — 自動販売機
たとえ — 自動販売機
View = ボタンと画面（利用者に見える部分）
ViewModel = 内部の回路（ボタンが押されると処理する）
Model = 飲み物の在庫と価格データ
ボタンを押す → 回路（VM）が飲み物を出す。
利用者は仕組みを知らなくてよい。
利点 — Viewとデータが分かれているので、
ボタンの見た目（色や配置）だけを変えるなら回路（VM）はそのまま。
ただし機能自体（分岐や新しい動作）を変えるなら、回路も変更が必要。
iOS · Android · Vue · WPF — 広く使われるパターンです。
出典 — MicrosoftのJohn Gossman、2005年。
「画面」と「データ」の間に、代わりに働く回路（ViewModel）がある。
出典：MicrosoftのJohn Gossman、2005年（WPF向けに発表）。
FSD · FEATURE-SLICED DESIGN
FSDとは？ — 百貨店の売り場分け
たとえ — 百貨店（横方向：ドメイン別の売り場）
1館 化粧品 · 2館 婦人服 · 3館 紳士服 · 4館 食品
ドメインごとに売り場（slice）を分ける。
化粧品売り場に突然食品コーナーがあったら？ 客は迷い、売上も落ちる。
FSDも同じ。ドメイン別の売り場（slice）で横に分ける。
FSD公式の6 layers（縦の階層と依存方向のルール）
上の層は下の層だけを使える（逆は禁止）。各layer内にはslice（ドメイン単位）がある。例：`features/auth`、`features/payment`。
講師は簡略版として、いくつかの概念だけを取り入れています。
要点は、用途別に整理してルールを決めること。
厳密な6層構造をすべて採用せず → ① フォルダは機能（slice）単位（`features/auth`、`features/payment` …）② 上の層から下の層だけを呼ぶ（依存方向）③ 命名とimportのルールを統一。
出典：2018〜2020年に登場。公式はfeature-sliced.design。フロントエンド（React/Vue）向け。
⚠ Webプロジェクトでよく見かけるパターン
一つのファイルに、ボタンの色変更／価格計算／サーバーAPI呼び出し／Claude・GPT呼び出し
が全部入っています。
こうすると、先ほどのContext Rot・注意の喪失が起きます。
部屋の掃除を諦めて出ていく清掃業者のように、Claudeも迷って無駄なことをします。
CLEAN ARCHITECTURE · UNCLE BOB
クリーンアーキテクチャとは？ — 玉ねぎの同心円
たとえ — 玉ねぎ
玉ねぎを思い浮かべてください。中心が本体で、外側は皮です。
内側 = ドメイン（本当に作りたいもの — 中核のビジネスロジック）
外側 = DB・画面・外部API・フレームワーク（付属物・皮）
ルールは一行
内側は外側を知らずに動きます。
「PostgreSQLなのかMySQLなのか、ドメインのコードは知らない。」
→ 1年後にDBを替えても中核のコードは変えない。Webからモバイルへ移ってもビジネスロジックはそのまま。
中核を内側に置き、外側を取り替えられるようにする。
出典 — Robert C. Martin（Uncle Bob）、2012年のブログ → 2017年の書籍Clean Architecture。
DESIGN PATTERNS
デザインパターン — 知っておきたいもの
客は「プルコギピザ」と注文するだけ。生地やオーブンの温度は店に任せる。— オブジェクトの生成方法をカプセル化
チャンネル登録すると新しい動画を自動通知。毎日確認しに行かない。— pub/subパターン
カード・振込・Payco・Kakao Pay。どれを選んでも決済インターフェースは同じ。— アルゴリズムの切り替え
韓国の家電を米国のコンセントへ。110V↔220Vアダプター。— インターフェースの変換
⚠️ Singleton — 人類史上、最も乱用されるパターン
たとえ — 大統領。一国に一人。「私が大統領だ」と言う人が二人いれば国が揺らぐ。
乱用 — すべての決定を大統領一人に集め、国が麻痺する。
実際のコードでは、mockしづらい、依存性注入が崩れる、マルチスレッドで競合する。導入は簡単 → 後から外すのは非常に難しい。
Singletonは本当に一つだけ必要な場合（DB接続プール・ロガー）に限る。
それ以外では、習慣で使わないでください。
SOLID · 5 PRINCIPLES
SOLIDの5原則 — 身近なたとえで
厨房の分担 — 刺身係は刺身だけ、ラーメン係はラーメンだけ、会計係は会計だけ。
一人に「刺身を切りながらラーメンを作って会計も」と頼むと全部崩れる。
コンセントとプラグ — コンセントは変えず、新しい家電のプラグを挿す。
家電を買うたびにコンセントを解体しない。= 既存コードの修正はせず、拡張する。
代わりのアルバイト — キム店主が休んでも、パクさんが同じ仕事をする。
「キムチチゲは作りません」では客が困る。= 子は親の代わりを務められること。
メニュー — 30ページの総合版なら、韓国料理の一行を変えるだけで全体を刷り直し、全員が読み直す。4種類に分ければ、韓国料理の変更は洋食の客に影響しない。
客は自分の種類だけを見る。= 使わないメソッドに依存しない。
ATM — 「新韓カード専用」なら、新しい会社（KB・ウリ）が増えるたびにATMのコードを変える。「カードインターフェース」を決めれば新会社も接続できる。
ATM（上位）がカード会社（下位）へ直接依存せず、両者がカードインターフェース（抽象）に依存する。依存方向が逆転。= 具体ではなく抽象に依存する。
出典：Robert C. Martin（Uncle Bob）が2000年代初頭に体系化。
LはBarbara Liskovが1987年に発表（第3回のダイクストラとリスコフを再び）。
SOLID × CLAUDE
ClaudeもSOLIDのコードを好む理由
5原則とContext Rot対策の対応
↪ 刺身店の厨房 — 刺身、ラーメン、会計を分ける
1ファイルに1責任 → Claudeは一つの責任だけを追う。仕事が混ざると推測が増え、Context Rotが加速。
↪ コンセントとプラグ — コンセントを変えずプラグを交換
機能追加で既存コードに触れない → Claudeの「直すうちに壊す」パターンを防ぐ。
↪ 代わりのアルバイト — キム店主が休んでもパクさんが同じ仕事
親のシグネチャから子の動作を予測できる → Claudeの関数の動作に関する想定が安全になる。
↪ メニュー — 30ページの総合版を4種類に分ける
小さなインターフェース → Claudeはそのクラスが使うものだけをコンテキストに入れる。大量のダンプを避ける。
↪ ATM — どの会社のカードでも引き出せる（見るのは「カードインターフェース」）
ドメインが抽象に依存 → DBやAPIが変わってもドメインのコードに触れない → ヘキサゴナルに直結。
一行で：SOLID = Context Rot対策 + Claudeによるコード変更の安全性。
第3回の関心の分離（SoC）は、実はSOLIDのSです。
PART 2
CLIの奥深さ
CLI · COMMAND LINE INTERFACE
CLI = 文字で命令する画面
開発者がCLIを使う理由 — GUIより速い。
本当の理由 — Claudeに任せるのに適しています。
ブラウザGUIの操作は非効率。画面の確認に多くのトークンを使い、学習が十分でないページではクリック位置を見失うことも。文字のCLIには、その曖昧さがありません。
CLI · 命令の流れ
人 → Claude → CLI → 外部サービス — 6段階の流れ
→ CLIはClaudeの手足。GUI操作は難しくても、コマンドなら直接入力できる。
新しく作って」
CLIコマンドに変換
gh repo
create ...gh · HTTPSOAuth Token
api.
github.com→ Claude → 人
CLIが変わっても同じパターン
gh（GitHub）· wrangler（Cloudflare）· supabase（Supabase）· gcloud（GCP）· az（Azure）· vercel（Vercel）— 6段階の構造は同じ。サービスだけが変わる。
人は「意図」だけを伝える。Claudeが「命令」に変換し、実行して結果を解釈する。
完全な委任 — Claude CodeではClaudeが直接ターミナルを操作します。
皆さんはコマンドを打たなくてよいのです。
10分休憩
この後 — 「知らない言葉の前で止まらない方法」。
PART 3
知らない言葉の前で
止まらない方法
Claudeが新しい用語を四つ並べたとき、
皆さんがすべきこと。
本が必要になるときは必ず来ます。だからといって今動かないのは、時代の流れに合いません。
本の1ページ = 3分。Claudeへの1プロンプト = 30秒。
6倍速い。
今日の用語がその武器です。
聞かなかった人はいつまでもわかりません。
5 SESSIONS — CUMULATIVE
皆さんが5回で積み重ねたもの
すでにバイブコーディングを始めてもいない人より
先に進んでいます。
BONUS · 技術選びの新基準
デザインパターンとSOLIDを学びました。では、どの技術を選びますか？
以前（〜2024年）
開発者が技術文書を読み漁り、業界の状況を調べて技術を選んでいました。
今（2026年〜）— バイブコーダーの新しい基準二つ
① AIが多く学習した技術か？ 参考資料を見つけやすいか？
② AIがアクセスし、機能を扱いやすいサービスか？ CLIとAPIの使いやすさ。
サービスを作る自分自身の努力に加えて、
「AIが自動で仕事を進めやすいシステムか？」
を考える時代です。
基準① · AIの学習量
AIが多く学習した技術 = 安全な選択
例1 — フロントエンド：React vs Vue
React：npmの週間ダウンロード数は約1億回
Vue：約1千万回
→ 約10倍の差（2026年5月、npm trends）。AIの学習データ（GitHubやStack Overflowの回答）も同じような差があります。
学習量ではReactが圧倒的。バイブコーディングではReactのほうが安全。
例2 — モバイル：Flutter
Flutterの強み — 一つのコードベースでiOS・Android・Web・Desktopをビルド。
AIは一つのコードベースだけを読めばよく、iOSとAndroidを別々に書く必要がありません。
→ バイブコーダーにとって「AIが扱いやすい」構造。
基準① — 「AIはこの技術を十分に学習したか？」
学習量の少ない新技術は、魅力的でもバイブコーディングではリスクがある。
基準② · AIのアクセス性
AIが自動で仕事を進めやすいサービスか？
ホスティング — Cloudflareと他のサービス
Cloudflare（Wrangler CLI）・Vercel（Next.js特化）はClaudeが最も扱いやすい。
CLIが単純で、APIはRESTful、文書も豊富。
CLIの有無がClaudeの自動化を左右する
CLIあり → Claudeが一行のコマンドで自動処理。
CLIなし／GUIのみ → Claudeの直接操作は非効率。Chrome MCPでクリックや追跡はできても、多くのトークンを使い、学習が十分でないページでは失敗することも。
→ GCP（gcloud）≈ Azure（az）。両方CLIがあり、GCPが少し単純。
バイブコーダーの判断 — 「AIが自動で仕事を進めやすいシステムか？」
TODAY'S KEY TAKEAWAY
PART 5
今日の
宿題
自宅で30秒の宿題。
一つのモデルを100%信頼せず、別のAIにも同じ質問で見立てを聞いてください。
▸ 小規模プロジェクト（個人用・MVP） → 「VercelとSupabaseで可能？ CLIはある？ 設定方法は？」または「Firebaseのほうがいい？ CLIはある？」
▸ ホスティング・本番サーバーが必要 → 「Cloudflareと韓国のサービス（Toast・NCPなど）のどちらがいい？ 理由とCLIの充実度も教えて。」
▸ 本番サーバー構成 → 「Azure・GCP・AWSで今の条件に合うのは？」
▸ 結局はこの一問 → 「どの会社のどのソリューションが、Claudeにとって最も操作・構成しやすい？」
BEFORE WE CLOSE — META
なぜこの用語を扱ったのか
MVVM・FSD・クリーン・SOLID・Context Rot。初めて聞くと退屈で無駄に見えます。
理由は人間の認知にあります。人は言葉で現象を定めます。その認知の仕組みを粗雑にまねて作ったのがLLMです。Claudeも用語を明示しなければ、扱う範囲が広がりません。
— ウィトゲンシュタイン · 論理哲学論考（1922年）、命題5.6
「私の言語の限界が
私の世界の限界を意味する。」
言葉を知らなければ、現象を定められません。
「なぜClaudeは頼んでいない場所まで触って壊すのか？」毎日起きても、表す言葉がなければ、「AIは馬鹿だ」と悪態をつくしかなくなります。
言葉を持つ人が、
AIを使いこなします。
SESSION 05 / 06
今日も
お疲れさまでした。
次回 — 最後の第6回。
「もう一人でもできる」· リモート環境と今後の方向。
OPEN CHAT
質問があれば
KakaoTalkのオープンチャットをご利用ください。