← Academy 日本語で学ぶ(一覧へ戻る)

ai fluency builders

Anthropic Academy コースの日本語ナレッジ(学習用)/ 全 10 項目

Anthropic Academy「AI Fluency for Builders」ナレッジノート

Anthropic Academy / 修了日 2026-07-03

コース概要

AI Fluency for Builders は、Anthropic の 4D Framework——Delegation(委譲)/ Description(記述)/ Discernment(識別)/ Diligence(誠実さ・責任)——を、ビルダー(プロダクト担当者・デザイナー・メイカー・エンジニア)向けに適用したコース。「顧客の問題から出荷されたソリューションまでの全アーク」を所有するビルダーが、AI を効果的(effective)・効率的(efficient)・倫理的(ethical)・安全(safe)に使いこなすための実践枠組みを扱う。

  • 開発: Anthropic が CodePath とのパートナーシップで開発
  • ベース: Prof. Rick Dakan(Ringling College)と Prof. Joseph Feller(University College Cork)による AI Fluency Framework
  • ライセンス: Copyright 2026 Anthropic / CC BY-NC-SA 4.0

コアメッセージ:

  • 実装の委譲はたいてい安全。判断の委譲はたいてい安全でない。
  • AI の失敗の多くは、上流の Description・Discernment・Diligence の失敗にさかのぼる。
  • 4D は順番(シーケンス)ではなく動的——構築しながら流動的に行き来するのがフルエンシーの実践形。

修了証

  • 修了証: https://verify.skilljar.com/c/62juq4uvudki
  • 氏名: NAOKI NAKASHIMA
  • 修了日: 2026-07-03
  • 進捗: 10/10 完了 / Course quiz 合格

目次(全9レッスン)

# レッスン(英語原題) 動画 内容(1行) ノート
L1 Welcome to AI Fluency for builders 4分 AI Fluency の定義・コースロードマップ・演習「Builder Brief」(AI に渡す再利用可能なコンテキスト文書)作成 raw/01_welcome.txt
L2 The 4D Framework 7分(レッスン約20分) 4D の定義。inner loop(Description・Discernment=日々の対話)と outer loop(Delegation・Diligence=大きな判断)の使い分け raw/02_4d_framework.txt
L3 AI capabilities & limitations 12分(レッスン約25分) 生成AIの仕組み(transformer・訓練データ・計算資源、pre-training と fine-tuning)、強み(多用途性・対話・ツール使用)と限界(knowledge cutoff・hallucination・複雑な推論の不確かさ)。演習「Testing the edges」 raw/03_ai_capabilities_limitations.txt
L4 Delegation & the builder's toolkit 5分(レッスン約45分) ビルダーの6道具(Empathy/Design/Architecture/Implementation/Judgment/Shipping)と AI の適性マップ。コード0行で Problem Brief・Delegation Plan(Automation/Augmentation/Agency)・受け入れテストを書く raw/04_delegation_builders_toolkit.txt
L5 Description & building great things 5分(レッスン約45分) Description Chain(ユーザーの声→要求→技術スペック→AI指示→テスト)。プロンプトエンジニアリングは1リンクにすぎない。テストは最も精密な記述 raw/05_description.txt
L6 Discernment for code 5分(レッスン約30分) 識別の5レンズ(Functional Integrity/Production Readiness/Problem Fit/Experience Quality/Responsible Impact)。AI の予測可能な盲点(並行処理・セキュリティ・スケール) 06_discernment_for_code.md
L7 Discernment for user experience 2分(レッスン約45分) UX 4原則(Clarity/Hierarchy/Accessibility/Feedback)。「見た目良く」は願望であって仕様ではない。批評と AI 向け記述は別アーティファクト 07_discernment_for_ux.md
L8 Stand behind what you build 3分(レッスン約45分) Diligence 実践。アウトカムの所有・出荷の技術語彙・テスト/可観測性/フィーチャーフラグ・出荷前チェック5問(Anthropic エンジニア Martina の3習慣) 08_stand_behind.md
L9 Closure & looking forward 4分(レッスン約15分) 総まとめと最終課題「Your next build」(今週、実在タスク1つを 4D で通す)→ クイズ → 修了証 09_closure.md

コース貫通演習: Clinic Wait Time Project

コース全体を貫く実践プロジェクト。シナリオは「コミュニティ・ヘルスクリニックが、患者が来院前に待ち時間を確認できる方法を必要としている。伝えられているのはそれだけ」。

段階 レッスン やること
Part 1 L4 コード0行で Problem Brief(1ページ以内)+ Delegation Plan(6道具×Automation/Augmentation/Agency の6行表)+ 受け入れテスト5〜7本(他人が pass/fail を判定できる具体性。良例:「基本的なスマホを持つ患者が、アカウント作成なしに30秒以内で現在の待ち時間を見つけられる」)
Part 2 L5 プロダクト要求(1段落・形容詞すべてに根拠)→ 技術スペック(半ページ・augmentation モードで AI と)→ テスト強化(エッジケース2件以上: 休診/データなし/待ち時間ゼロ)→ AI プロンプトで v1 構築 → デモ(パートナーが「病気の子を抱え10分しかない患者」役。説明しない・助けない)
ユーザーテスト L6 患者役/クリニック管理者役の前に置き、説明せず観察。変えたい3点を5レンズに紐付け
Part 3 L7 デザインスペック(ユーザーフロー・情報階層・インタラクションパターン)→ AI で再構築 → 批評+アクセシビリティ監査(AI の見落としを文書化)
Ship L8 出荷前チェック5問(Understanding/Testing/Access/Responsibility/Feedback loop)に正直に答える → デプロイまたはプロトタイプ公開 → 実在ユーザー3人に共有 → 学びに基づく1反復(テストで検証)
その先 L9 同じ 4D プロセスを自分の実在タスクへ適用(Your next build)

修了クイズ(収録)

全10問(選択式9問+自由記述1問)・合格済み。

# 問題 正答
Q1 What does AI Fluency mean? The ability to use AI in ways that are efficient, effective, ethical, and safe
Q2 4D Framework の4つの D は? Delegation, Description, Discernment, Diligence
Q3 Builder's Toolkit のうち AI が最も弱いのは? Empathy, Judgment, and Shipping
Q4 AI に委譲して安全なものは? Generating a first draft of implementation code(実装コードの初稿生成)
Q5 AI 生成コードについて正しいもの(複数選択) ○「動くが意図を外すコードを生成しうる」○「concurrency/caching/race conditions に予測可能な盲点がある」○「存在しない/古いライブラリを推薦しうる」(×「常にセキュリティ脆弱性を指摘する」は誤り)
Q6 Description Chain の正しい順序は? User voice → product requirement → technical spec → AI instruction
Q7 「コードは動くが誰も使いたがらない」はどのレンズの失敗? Experience Quality
Q8 Diligence が出荷前に要求するものは? Understanding what the code does and being accountable for the outcome(コードが何をするかを理解し、アウトカムに説明責任を持つこと)
Q9 acceptance tests を先に書く理由は? To give both you and AI a shared definition of "done" from the start(自分と AI の双方に、最初から「完成」の共通定義を与えるため)
Q10 (自由記述)自分の判断が AI の出力より重要だった意思決定を1つ記述する

ファイル構成

ai-fluency-builders/
├── README.md                      ← このファイル
├── 06_discernment_for_code.md     ← L6 全文ナレッジ(日本語+英語原文+動画逐語)
├── 07_discernment_for_ux.md       ← L7 全文ナレッジ
├── 08_stand_behind.md             ← L8 全文ナレッジ
├── 09_closure.md                  ← L9 全文ナレッジ
├── raw/                           ← レッスン本文の一次テキスト(L1〜L9・英語)
└── subs/                          ← 動画字幕 vtt(YouTube 自動字幕・英語)
↑ 目次へ戻る

AI Fluency for Builders | Lesson 1「Welcome to AI Fluency for builders」(全文ナレッジ)

テキストレッスン+埋め込み動画 4分(YouTube: YWVDXsUf8NY)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと(What you'll learn)

  • AI Fluency(AIフルーエンシー)を定義し、それがビルダーとしての自分の役割にどう適用されるかを説明できる
  • AI に自分の価値観・制約・コンテキストを渡す、再利用可能なブリーフ(builder brief)を作れる
  • ビルダーのプロセスの中で、AI に委任するかどうか・いつ・どこで委任するかを判断できる

動画(4分)

ビルダー(プロダクト担当者・デザイナー・メイカー)に向けてコースを紹介し、AI Fluency が実践において実際に何を意味するのかを説明し、4D フレームワークをプレビューする。

コースロードマップ(Course roadmap)

  • AI Fluency の 4D フレームワーク:Delegation(委任)、Description(記述)、Discernment(識別)、Diligence(誠実な責任遂行)——あらゆる生産的な AI コラボレーションの背後にある4つのコンピテンシー。
  • AI の能力と限界:今日の AI が確実にできること・できないこと。そしてそれが、ビルダーとして AI をどう働かせるかをなぜ形づくるのか。
  • 委任とビルダーのツールキット:問題を分解し、各段階で AI に何を任せるかを決め、コードを1行も書く前に「完了(done)」を定義する方法。
  • コードと UX のための識別:本当に重要なこと——正しさ、品質、適合(フィット)、体験、責任——に照らして AI の出力を評価する。
  • 出荷(シッピング)と次のステップ:AI とともに作ったものへの完全なオーナーシップを引き受けること、そしてフルーエンシーを磨き続けられる場所。

キーテイクアウェイ(Key takeaways)

  • ビルダーは、顧客の問題から出荷されたソリューションまでの「全弧(full arc)」をオーナーとして持つ。
  • AI Fluency とは、AI と効果的(effectively)・効率的(efficiently)・倫理的(ethically)・安全(safely)に働くことを意味する。
  • 4D フレームワーク(Delegation・Description・Discernment・Diligence)が、本コースの全レッスンの土台となる。
  • 実装(implementation)の委任はたいてい安全。判断(judgment)の委任はたいてい安全ではない。
  • AI の失敗の多くは、それより前に犯した記述(description)・識別(discernment)・誠実さ(diligence)の失敗に遡る。

演習(Exercise):Build your builder brief(ビルダーブリーフを作る)

任意のプロジェクトの開始時に AI へ渡す、再利用可能なコンテキスト文書を作る——AI コラボレーターの「オンボーディング資料」である。

Part I:自己リフレクション(AI ツールを開く前に行う) 1. いま何を作っているか、あるいは何を作ろうとしているか? プロダクト・ユーザー・それが解決する問題を名指しする。 2. 自分の役割は何か——そして自分が個人として出荷責任を負っているものは何か? 3. すでに AI を使っている場所はどこか? 避けてきた場所はどこで、それはなぜか? 4. 次の文を完成させる:「もし AI が____を担えたら、私は____にもっと時間を使える。そこが最も重要な意思決定が行われる場所だ。」

Part II:AI と一緒にブリーフを作る Claude を開く。自分がビルダーであること、今後の AI コラボレーションのための再利用可能なコンテキスト文書が欲しいことを伝える。Part I の回答を共有し、将来のセッションに貼り付けられるブリーフの草案を作るよう依頼する。 盛り込むべき主要領域: - 何を作っていて、誰のためか - 自分の役割と、自分がオーナーであるもの - 制約(チームサイズ・技術スタック・タイムライン・譲れない条件) - AI に関与してほしい場所——そして関与してほしくない場所

一緒にレビューし、足りないものを追加し、再利用しやすいフォーマットにするよう依頼する。これが本コースを通じて使う、あなたの builder brief となる。

謝辞(Acknowledgments)

Copyright 2026 Anthropic。CodePath とのパートナーシップで開発。Rick Dakan 教授(Ringling College)と Joseph Feller 教授(University College Cork)による AI Fluency Framework に基づく。CC BY-NC-SA 4.0。

実務ポイント(このレッスンから持ち帰るもの)

  1. builder brief を実際に作って常備する——新しい AI セッションの冒頭に毎回貼れる再利用可能なコンテキスト文書(何を作るか/自分の役割/制約/AI の関与範囲)を用意する。これがコース全体の起点となる実践。
  2. 「実装は委任してよい。判断は委任しない」を委任のデフォルトルールにする——「本当に良いか・出荷できる状態か」の見極めだけは常に自分の手に残す。最高のビルダーはこの違いを知っている。
  3. AI の失敗はプロンプトではなく上流から疑う——ほとんどの失敗は、それより前の記述・識別・誠実さの失敗に遡る。「テストが通るコード」だけを見ていると、ユーザー問題の理解不足という真因を見落とす。
  4. AI は「有能だが極めてリテラルなコラボレーター」として扱う——明確なタスク、なぜ作るのかという本物のコンテキスト、間違えたときの具体的なフィードバック。この3点セットを毎回渡す。
  5. プロトタイプは自由に、出荷は選択的に(Prototype freely. Ship selectively.)——証拠が「これは正しくない」と示すなら、自分が作ったものでも veto(拒否)する意思を持つ。

動画逐語(日本語訳)

[0:06] こんにちは、CodePath の CEO、マイケルです。

[0:09] そして私は Anthropic の教育チームのクリステンです。

[0:12] AI Fluency for builders コースへようこそ。

[0:15] ソフトウェアを出荷した経験があるなら、コードを書くことは仕事のごく一部にすぎないと、すでにご存じでしょう。実際に解く価値のある問題は何かを見極めなければなりません。それがどう動くべきかについて何百もの小さな意思決定を下し、そしてそれを人々の手に届け、その先に起きることから学ばなければなりません。

[0:31] 顧客の問題を理解することから、その顧客に届くソリューションを出荷するまでの、その一連のプロセス全体こそ、私たちの言う「ビルダーであること」です。そして AI は、いままさにそのプロセスのほぼすべての部分を変えつつあります。

[0:42] 「AI トレーニング」と呼ばれるものの多くは、狭い一部分——言語モデルからより良いコードを引き出すための、より良いプロンプトの書き方——だけに焦点を当てています。それは有用ですが、持続する AI Fluency を身につけるには十分ではありません。

[0:54] そもそも何を作るべきかを知る必要があります。そして、AI が生み出したものが本当に正しいのか——単に技術的に動くだけでなく、実際の問題を解決し、実際のユーザーで機能し、想定外の新しい問題を生み出していないか——を評価する必要があります。

[1:08] AI Fluency とは、効果的・効率的・倫理的・安全な形で AI システムと協働する能力のことです。AI Fluency はプロンプト集ではありません。どのモデル・どの機能が手元にあろうと優れた意思決定を可能にする、相互に結びついたコンピテンシーの集合です。

[1:24] このコースの中心にあるのが、Joseph Feller 教授と Rick Dakan 教授が Anthropic と協力して開発した 4D フレームワークです。それは4つのコンピテンシー——Delegation(委任)、Description(記述)、Discernment(識別)、Diligence(誠実な責任遂行)——から成ります。これらを、あなたが AI と行うあらゆるコラボレーションの下で動くオペレーティングシステムだと考えてください。

[1:41] Delegation(委任)とは、問題を部分に分解し、各段階で AI がどんな役割を担うかを決めることです。実装を AI に委任するのは、たいてい問題ありません。判断——それが本当に良いものか、準備ができているかの見極め——を委任するのは、たいてい推奨されません。最高のビルダーはその違いを知っています。

[1:58] Description(記述)とは、ユーザーの声からプロダクト要件、技術仕様に至るまで、あらゆるインプットを確実に実装へ反映させるビルダーの能力です。多くの AI トレーニングは、テストが通るコードを作らせることに過度に集中します。それは重要ですが、不十分です。欠けたインプットやコンテキストは、下流へと連鎖(カスケード)していきます。

[2:17] ユーザーが「このツールは自分には機能しない」と苦情を言う。遡って調べると、問題はコードにはなかった。ユーザーの問題をどう理解し、どう記述したかにあった——。ビルダーは記述のあらゆる側面をオーナーとして持たねばなりません。

[2:27] Discernment(識別)は、AI が返してきたものをどう評価するかです。「動くか」だけでなく、「うまく動くか」。正しい問題を解いているか。実際に使って良いものか、そして責任ある作りになっているか。AI には本物の盲点があります。局所的には正しいのに、負荷がかかると壊れるコードを生成することがあります。機能はするのに分かりにくい UX を生成することもあります。Discernment とは、そうしたギャップをユーザーより先に捕まえるスキルです。

[2:52] Diligence(誠実な責任遂行)は、アウトプット(出力物)だけでなくアウトカム(結果)への完全なオーナーシップです。出荷はそれ自体の技術的な現実を伴うスキルであり、AI がそれを自発的に表に出してくれることはめったにありません。マイグレーション、レート制限、モニタリング。午前2時に何かが壊れて、それを作ったのがあなただったら、何が起きますか?

[3:06] プロトタイプは自由に。出荷は選択的に。そして、証拠が「これは正しくない」と示すときには、自分が作ったものでも拒否(veto)する意思を持つこと。

[3:13] AI を「有能だが非常にリテラルな(字義通りの)コラボレーター」と考えてください。速く、博識で、疲れ知らず。しかし、明確なタスク、なぜそれを作るのかという本物のコンテキスト、そして何かを間違えたときの具体的なフィードバックを必要とします。

[3:26] そのコラボレーターをうまくマネジメントすること——いつ介入し、いつ走らせておくか、どうやって適切なブリーフを渡すか——が、このコースが育てる中核スキルです。

[3:35] このコースを終える頃には、自信と意図を持って AI に向き合えるようになります。作るものを本当に良いものにしている「判断」を失うことなく、AI を活用してより速く動く方法が分かるはずです。そして、真ん中のコーディング部分だけでなく、ビルディングのプロセス全体をオーナーとして持てるようになります。

[3:48] さあ、始めましょう。

[3:52] anthropic.com/learn へ

英語原文

レッスン本文

[YouTube: YWVDXsUf8NY (4 min)] Welcome to AI Fluency for builders

What you'll learn Define AI Fluency and explain how it applies to your role as a builder Build a reusable brief that gives AI your values, constraints, and context Decide if, when and where to delegate to AI in the builder process

Video (4 min): introduces builders — product people, designers, and makers — to the course, explains what AI Fluency actually means in practice, and previews the 4D Framework.

Course roadmap - 4D Framework for AI Fluency: Delegation, description, discernment, and diligence—the four competencies behind every productive AI collaboration. - AI capabilities and limitations: What today's AI can and can't do reliably, and why that shapes how you put it to work as a builder. - Delegation & the Builder's Toolkit: How to decompose a problem, decide what AI handles at each stage, and define done before you write a line of code. - Discernment for code and UX: Evaluating AI output against what actually matters: correctness, quality, fit, experience, and responsibility. - Shipping and next steps: Taking full ownership of what you build with AI, and where to keep building your fluency.

Key takeaways Builders own the full arc from customer problem to shipped solution. AI Fluency means working with AI effectively, efficiently, ethically, and safely. The 4D Framework (Delegation, Description, Discernment, Diligence) anchors every lesson in this course. Delegating implementation is usually safe. Delegating judgment is usually not. Most AI failures trace back to description, discernment, or diligence failures made earlier.

Exercise: Build your builder brief Creates a reusable context document you'll give AI at the start of any project — onboarding your AI collaborator. Part I: Self-Reflection (before opening any AI tool): 1. What are you building right now, or planning to build? Name the product, the users, and the problem it solves. 2. What's your role — and what are you personally responsible for shipping? 3. Where do you already use AI? Where have you avoided it, and why? 4. Complete: "If AI could handle _, I could spend more time on _, which is where the most important decisions get made." Part II: Build your brief with AI Open Claude. Tell it you're a builder and want a reusable context document for future AI collaboration. Share Part I answers, ask it to draft a brief to paste into future sessions. Key areas: what you're building and who it's for / your role and what you own / constraints (team size, stack, timelines, non-negotiables) / where you want AI involved — and where you don't. Review together, add anything missing, request an easy-to-reuse format. This is your builder brief for the course.

Acknowledgments: Copyright 2026 Anthropic. Developed in partnership with CodePath, building on the AI Fluency Framework by Prof. Rick Dakan (Ringling College) and Prof. Joseph Feller (University College Cork). CC BY-NC-SA 4.0.

動画字幕(重複除去済み)

[0:06] Hi, I'm Michael, the CEO of CodePath.

[0:09] And I'm Kristen from the education team at Anthropic.

[0:12] Welcome to the AI Fluency for builders course.

[0:15] If you have ever shipped software, you already know that writing code is only a small part of the job. You have to figure out what problem is actually worth solving. You have to make hundreds of small decisions about how it should work, and then you have to get it into people's hands and learn from what happens next.

[0:31] That full process, from understanding a customer problem to shipping a solution that reaches them, is what we mean by being a builder. And AI is changing almost every part of that process right now.

[0:42] Most of what gets called AI training focuses on one narrow slice: writing better prompts to get better code out of a language model. That's useful, but it's not enough to develop lasting AI Fluency.

[0:54] You need to know what to build in the first place. And you need to evaluate whether the thing AI produced is actually right, not just technically functional, but solving the real problem, working with real users, and not creating unexpected new problems.

[1:08] AI Fluency is the ability to work with AI systems in ways that are effective, efficient, ethical, and safe. AI Fluency isn't a prompt library. It's a set of interconnected competencies that empower you to make great decisions regardless of the model or feature at your disposal.

[1:24] At the center of this course is the 4D Framework, developed by professors Joseph Feller and Rick Dakan in collaboration with Anthropic. It consists of four competencies, delegation, description, discernment, and diligence. Think of them as the operating system underneath every collaboration you have with AI.

[1:41] Delegation is about decomposing a problem into parts and deciding what role AI plays at each stage. Delegating implementation to AI is usually fine. Delegating judgment, the call about whether something is actually good and ready, is usually not advised. The best builders know the difference.

[1:58] Description is a builder's ability to ensure that every input, from user voice to product requirements to technical specs, make it into the implementation. Most AI training hyper-focuses on ensuring code is built where the test passes. That's important, but insufficient. Any missing input or context cascades downstream.

[2:17] A user complains that the tool doesn't work for them. You trace it back and discover the issue wasn't in the code. It was in how you understood and described the user problem. Builders must own every aspect of description.

[2:27] Discernment is how you evaluate what AI gives you. Not just does it run, but does it run well? Does it solve the right problem? Is it actually good to use and is it responsible? AI has real blind spots. It can produce code that's locally correct, but breaks under load. It can generate UX that's functional, but confusing. Discernment is the skill of catching those gaps before your users do.

[2:52] Diligence is full ownership of the outcome, not just the output. Shipping is a skill with its own technical realities that AI rarely surfaces proactively. Migrations, rate limiting, monitoring. What happens when something breaks at 2 a.m. and you're the one who built it?

[3:06] Prototype freely. Ship selectively. And be willing to veto something you built when the evidence says it isn't right.

[3:13] Think of AI as a capable but very literal collaborator. It's fast, it's knowledgeable, it doesn't get tired, but it needs clear tasks, real context about why you're building something and specific feedback when it gets something wrong.

[3:26] Managing that collaborator well, knowing when to step in, when to let it run, how to give it the right brief is the core skill this course develops.

[3:35] By the end of this course, you'll approach AI with confidence and intentionality. You'll know how to leverage it to move faster without losing the judgment that makes what you build actually good. And you'll own the full building process, not just the coding slice in the middle.

[3:48] Let's get started.

[3:52] Visit anthropic.com/learn

↑ 目次へ戻る

AI Fluency for Builders | Lesson 2「The 4D Framework」(全文ナレッジ)

テキストレッスン+埋め込み動画 7分(YouTube: eNNSZhk_W74)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと(What you'll learn)— 想定所要時間:20分

  • 4D の4つのコンピテンシーすべてを定義し、それぞれが AI コラボレーションをどう形づくるかを説明できる
  • 内側ループ(inner loop)と外側ループ(outer loop)を区別し、それぞれをいつ適用すべきか分かる
  • いまの自分の仕事を 4D にマッピングし、自分にとって最大の機会(伸びしろ)を見つけられる

キーテイクアウェイ(Key takeaways)

  • 内側ループ(Description と Discernment)は日々の AI とのやり取りを導く。外側ループ(Delegation と Diligence)は、いつ・どのように AI を使うかというより大きな意思決定を導く。
  • Delegation(委任)とは、AI に何を任せ、何を自分の手に残すかを決めること。
  • Description(記述)とは、何が必要で、AI にどう取り組んでほしいかを明確に伝えること。
  • Discernment(識別)とは、AI が返してきたものを、それに基づいて行動する前に評価すること。
  • Diligence(誠実な責任遂行)とは、AI の役割がどうであれ、最終結果を完全にオーナーとして引き受けること。

演習(Exercise):Map your builder brief to the 4Ds(builder brief を 4D にマッピングする)

Part I:文書にタグを付ける — 自分の builder brief にある各ゴール・懸念・タスクに、該当するコンピテンシーのマークを付ける: - Delegation:自分のビルドで AI が扱うべきもの/扱うべきでないものに関する意思決定 - Description:要件と意図を明確に伝える方法についての疑問 - Discernment:AI が生み出すものの評価や信頼に関する懸念 - Diligence:出荷するものへの責任・テスト・アカウンタビリティに関する疑問

どのコンピテンシーが最も多く現れるか? そこがあなたの注意が集中している場所であり——たいてい最速で成果が出る場所でもある。

Part II:ひとつ試す — 実際のタスクをひとつ選ぶ。AI を開く前に書き出す:どのコンピテンシーが該当するか?「十分に良い(good enough)」とはどんな状態か? その上で AI と1ラウンドだけやってみる——完璧を目指さず、有用な出発点を得るだけでよい。

Part III:ふりかえる — どのコンピテンシーが自然に感じられたか? どれに不意を突かれたか? 次のパスで違うやり方をすることをひとつ挙げる。

次のレッスン(What's next)

生成 AI はどう動くのか——能力と限界(capabilities & limitations)へ。

謝辞(Acknowledgments)

Copyright 2026 Anthropic / CodePath / Dakan & Feller / CC BY-NC-SA 4.0。

実務ポイント(このレッスンから持ち帰るもの)

  1. 2つのループでレイヤーを分けて考える——内側ループ(Description⇄Discernment)=日々の対話の質、外側ループ(Delegation⇄Diligence)=そもそも AI を使うべきか・倫理的責任という職場/生活レベルの判断。日々のプロンプト改善だけでは外側ループは埋まらない。
  2. Discernment が最大の伸びしろ——Anthropic の研究では、description スキル(欲しいものの特定・例示・依頼の磨き直し)は自然に身につく一方、AI の推論を問う・事実確認する・欠落コンテキストを特定するといった discernment 行動は「最も観察されなかった」。意識的に鍛える対象はここ。
  3. 記述は「出力の形」だけでなく「進め方」と「振る舞い」まで指定する——フォーマット・読者・分量に加えて、手順・作業順序・推論アプローチ、さらに役割(批判的レビュアー/ブレスト相手/不確かさにフラグを立てるファクトチェッカー)まで依頼できる。例:「レポートを要約して」→「技術者でないエグゼクティブ向けに、インパクト上位3つの発見に絞って300語以内で」。
  4. builder brief を 4D でタグ付けして自己診断する——最頻出のコンピテンシー=現在の関心の偏り=最速の改善ポイント。
  5. 透明性と検証責任は常に自分にある——同僚・ステークホルダーには AI がいつ・どう関与したかを知る権利がある。使う・共有するアウトプットは全主張をチェックし、最終結果のアカウンタビリティを引き受ける。

動画逐語(日本語訳)

[0:01](効果音)(音楽)

[0:06] 私たちは、あなたに持続する AI フルーエンシーを身につけてほしいのです。それは、どんな課題に直面しても、AI を効率的・倫理的・安全に使うためのツールをあなたに渡すということです。この動画では 4D フレームワーク——組み合わせることで AI との働き方を一変させる、相互に結びついた4つのコンピテンシー——を見ていきます。

[0:21] このフレームワークを適用しやすくするために、AI とのインタラクションの2つのモードを見ます。1つ目のモードは、おそらく馴染みのあるものです。日々の中で AI と効果的に関わる方法。これが Description(記述)と Discernment(識別)の内側ループ(inner loop)です。AI に手伝ってほしいことを記述し、返ってきたものが期待に応えているかを識別する。

[0:45] これは AI を学ぶ上で決定的に重要なスキルセットですが、それだけでは十分ではありません。AI とのやり取りの内部で起きるすべてに加えて、Delegation(委任)と Diligence(誠実な責任遂行)の外側ループ(outer loop)があります。これは、AI の使用をめぐって、あなたの職場・コミュニティ・生活の中で起きるすべてです。そもそも AI を使うべきなのか? 使うとしたら、意図的かつ責任を持って進めるためのあなたの倫理的責務は何か? 今日はこれら全体を短く概観しますが、より深く理解したい場合は、Anthropic Academy の AI Fluency: Framework and Foundations コースをチェックしてください。

[1:20] では、Description と Discernment の内側ループを詳しく見ていきましょう。繰り返しますが、これは AI との日々のやり取りの中で起こります。Description とは、AI システムと効果的にコミュニケーションすることを意味します。

[1:34] これは、良いプロンプトを書くことにとどまりません。まず、欲しいもの——アウトプット、フォーマット、読者、スタイル——を定義することから始まります。「このレポートの要約を書いて」ではなく、具体的にしてみましょう。「このレポートを、技術者でないエグゼクティブ向けに、インパクトの大きい上位3つの発見に絞って、300語以内で要約して」。さらに、AI があなたのリクエストにどうアプローチするかも定義できます。コラボレーターに指示を出すように考えてください。手順、作業の順序、あるいは AI に従ってほしい推論アプローチを指定するのです。そして、コラボレーション中の AI の振る舞いも形づくれます。弱い論証に反論してくる批判的なレビュアーが必要ですか? あらゆるアイデアに乗って発展させるブレインストーミングのパートナー? 不確かさにフラグを立てるファクトチェッカー? そのすべてを頼むことができます。

[2:20] 私たちの研究では、description のスキルは人々が最も自然に身につけるものだと分かりました。欲しいものを特定する、例を与える、依頼を磨き直す、といったことです。ほとんどの人はすでに何らかの形でこれらを実践していて、それは素晴らしい出発点です。AI と反復しコラボレーションを重ねるうちに、記述はより快適で効果的になっていくでしょう。

[2:41] Description の相棒である Discernment は、AI コラボレーターを思慮深く、批判的に評価することをあなたに求めます。まずアウトプットそのものから始めます。この統計は正確か? この言葉遣いは、あなたの読者がこのトピックについて実際に話すときの言葉を反映しているか? 次に、AI がどうやってそこに至ったかを見ます。関連する要因をすべて考慮したか?

[3:01] 重要なのは、discernment は AI のアウトプットを受け入れるか拒否するかだけを意味しないということです。行きたい場所へ到達するための反復(イテレーション)を伴います。

[3:09] そして、ほとんどの人が欲しいものはわりと自然に記述できる一方で、discernment ははるかに稀です。私たちの研究では、AI の推論に疑問を投げかける、事実を確認する、欠けているコンテキストを特定するといったスキルは、観察された中で最も少ない行動に属していました。そこにこそ、成長の余地があります。

[3:25] 見落としやすいステップですが、決定的に重要です。真の AI コラボレーションを駆動するのはこれです。だからこそ、description と discernment はループとして一緒に機能します。必要なものを記述し、得たものを評価し、その評価に基づいて記述を磨き直す。人間のチームメイトと働くのと同じです。会話を通じて共通理解を築いていくのです。

[3:48] 日々のやり取りで AI をうまく使うことは、パズルの1ピースにすぎません。自分のコンテキストにおける AI 使用の倫理的・社会的な含意をすべて理解することが不可欠です。ここで、delegation と diligence のループが登場します。

[4:01] Delegation とは、どの仕事を人間が行い、どの仕事を AI が行い、両者の間でタスクをどう配分するかを決めることです。良い委任は、仕事そのものを理解することから始まります。メールを下書きする前に、自問してください。これは AI が初稿を担える定型のステータス報告か、それともトーンとニュアンスが自分から直接出る必要のあるセンシティブな交渉か? ツールの理解も同じく必要です。たとえば機密データを扱っているなら、使用する AI システムのプライバシーとセキュリティの機能を検討したいはずです。仕事とツールの両方を理解すれば、それぞれの強みを活かす形でタスクを思慮深く分けられます。

[4:37] 私たちは delegation を diligence——AI の使い方への責任を引き受けること——と対にしています。

[4:45] それは、どの AI システムを使い、どうやり取りするかについて思慮深くあることを意味します。プロジェクト提案書の下書きに AI を使うにしても、どのセクションを AI に任せ、どこに自分自身の専門性が必要かを意図的に決める、というように。

[4:58] それは、自分の仕事における AI の役割について、知るべき人々に正直であることを意味します。同僚やステークホルダーには、いつ・どのように AI が関与したのかを理解する権利があります。そしてそれは、自分が使ったり共有したりするアウトプットを検証し、保証する責任を引き受けることを意味します。すべての主張をチェックし、正確さを確認し、最終成果物が自分のゴールと基準を本当に体現していることを確かめる。最終結果に対するアカウンタビリティは、常にあなたにあります。

[5:23] Delegation と diligence はループとして一緒に機能します。何を AI に委任するかというあなたの思慮深い選択は、その使い方への継続的な責任と釣り合っていなければなりません。そして、あなたの誠実な実践は、時間とともに、より賢い委任の意思決定へとつながっていきます。

[5:41] 4つの D は、一緒に使うことで生きてきます。戦略プランを書くとき? Delegation を使って、AI が扱う部分と自分が持ち込む部分を決める。強い description で AI の作業を導く。Discernment を適用して結果を評価し、全体を通して diligence を実践する——適切なツールを選び、AI の役割について透明であり、正確さへの責任を引き受けることによって。

[6:02] このフレームワークは、本当に重要な仕事——人間の判断、創造性、そして自分のコンテキストへの深い理解を必要とする仕事——であなたをより有能にするためのものです。

[6:12] このコースを通じて、これらのコンピテンシーを実際の課題に適用していきます。コミュニケーションの下書き、複雑な情報の分析、定型タスクの自動化、そして持続可能な AI ワークフローの構築です。

[6:24] 持ち帰るスキルは、AI が進化し続ける中でもあなたの役に立ち続けます。AI フルーエンシーについては Anthropic Academy でさらに学べますし、私たちはこのテーマに関する研究を Anthropic のブログで発信し続けます。

英語原文

レッスン本文

[YouTube: eNNSZhk_W74 (7 min)] The 4D Framework

What you'll learn — Estimated time: 20 minutes Define all four 4D competencies and how each shapes your AI collaborations Tell the inner loop from the outer loop and know when to apply each Map your current work to the 4Ds and find your biggest opportunity

Key takeaways The inner loop (Description and Discernment) guides daily AI interactions. The outer loop (Delegation and Diligence) guides bigger decisions about when and how to use AI. Delegation means deciding what AI handles and what stays with you. Description means communicating clearly what you need and how you want AI to approach it. Discernment means evaluating what AI gives back before acting on it. Diligence means owning the final result fully, regardless of AI's role.

Exercise: Map your builder brief to the 4Ds Part I: Tag your document — mark each goal/concern/task with the competency: Delegation: decisions about what AI should and shouldn't handle in your builds Description: questions about how to communicate requirements and intent clearly Discernment: concerns about evaluating or trusting what AI produces Diligence: questions about responsibility, testing, and accountability for what you ship Which competency shows up most? That's where attention is focused — usually fastest gains. Part II: Try one — pick one real task. Before opening AI, write: Which competencies apply? What does "good enough" look like? Then one round with AI — just a useful starting point. Part III: Reflect — which competency felt natural? Which caught you off guard? One thing to do differently next pass.

What's next: how generative AI works — capabilities & limitations. Acknowledgments: Copyright 2026 Anthropic / CodePath / Dakan & Feller / CC BY-NC-SA 4.0.

動画字幕(重複除去済み)

[0:01] [snorts] [music]

[0:06] >> We want you to build lasting AI fluency. That means giving you the tools to use AI efficiently, ethically, and safely, no matter what challenges you might face. In this video, we'll walk through the 4D framework, four interconnected competencies that, when combined, transform how you work with AI.

[0:21] To help you apply this framework, we'll look at two modes of interaction with AI. The first mode is likely the one you're familiar with. How to engage with AI effectively on a day-to-day basis. This is the inner loop of description and discernment. You describe what you want AI to help you with, and then you discern if it meets your expectations.

[0:45] This is a critically important skill set when learning AI, but it's not sufficient on its own. In addition to everything that happens within your interactions with AI, there's also an outer loop of delegation and diligence. This is everything that happens in your workplace, community, and life around the use of AI. Should you be using AI at all? And if you do, what are your ethical responsibilities to ensure you're proceeding intentionally and responsibly? We'll be doing a brief overview of all of this today, but if you'd like a deeper understanding, check out the AI fluency framework and foundations course on Anthropic Academy.

[1:20] Let's begin with a close look at the inner loop of description and discernment. Again, this happens during your day-to-day interactions with AI. Description just means communicating effectively with AI systems.

[1:34] This goes beyond writing good prompts. It starts with defining what you want, your outputs, format, audience, and style. Instead of write a summary of this report, try getting specific. Summarize this report for a non-technical executive audience, focusing on the three highest impact findings in under 300 words. But you can also define how the AI approaches your request. Think of it like giving instructions to a collaborator, specifying the steps, the order of operations, or the reasoning approach you want the AI to follow. And you can shape the AI's behavior during your collaboration, as well. Do you need a critical reviewer who pushes back on weak arguments? A brainstorming partner who builds on every idea? A fact-checker who flags uncertainty? You can ask for all of it.

[2:20] In our research, we found description skills are the ones people pick up most naturally. Things like specifying what you want, giving examples, and refining your requests. Most people are already doing some version of these, and that's a great starting point. As you iterate and collaborate with AI, it's likely you'll get more comfortable and effective at description.

[2:41] Discernment, the companion to description, asks you to thoughtfully and critically evaluate your AI collaborator. Start with the output itself. Are these statistics accurate? Does this language reflect how your audience actually talks about this topic? Then look at how AI got there. Did it consider all relevant factors?

[3:01] Importantly, discernment doesn't just mean accepting or rejecting AI outputs. It involves iteration to get where you want to go.

[3:09] And while most people describe what they want fairly naturally, discernment is much rarer. In our research, skills like questioning AI's reasoning, checking facts, and identifying missing context were among the least common behaviors we observed. And that's where there's room to grow.

[3:25] It can be an easy step to miss, but it's critically important. It's what drives true AI collaboration. That's why description and discernment work together in a loop. You describe what you need, evaluate what you get, and then refine your description based on that evaluation. It's like working with a human teammate. You build a shared understanding through conversation.

[3:48] Using AI well in day-to-day interactions is only one piece of the puzzle. It's critical to understand all the ethical and social implications of AI use in your context. This is where the delegation diligence loop comes in.

[4:01] Delegation is deciding what work should be done by humans, what work should be done by AI, and how to distribute tasks between them. Good delegation starts with understanding the work itself. Before drafting an email, ask yourself, is this a routine status update where AI can handle a first draft, or is this a sensitive negotiation where tone and nuance need to come directly from you? You need to understand your tools as well. If you're working with confidential data, for example, you'd want to consider the privacy and security features of the AI system you're using. When you understand both the work and the tools, you can thoughtfully split tasks to leverage the strengths of each.

[4:37] We pair delegation with diligence, taking responsibility for how you use AI.

[4:45] That means being thoughtful about which AI systems you use and how you interact with them. Maybe you use AI to draft a project proposal, but you're intentional about which sections it works on and which require your own expertise.

[4:58] It means being honest about AI's role in your work with the people who need to know. Your colleagues and stakeholders deserve to understand when and how AI has been involved. And it means taking responsibility for verifying and vouching for the outputs you use or share. You check every claim, confirm accuracy, and make sure any final deliverable truly represents your goals and standards. You're always accountable for the final result.

[5:23] Delegation and diligence work together as a loop. The thoughtful choices you make about what to delegate to AI must be matched by ongoing responsibility for how you use it. And your diligent practices inform smarter delegation decisions over time.

[5:41] The four D's come alive when you use them together. Writing a strategic plan? Use delegation to decide what AI handles versus what you bring yourself. Use strong description to guide the AI's work. Apply discernment to evaluate the results, and practice diligence throughout by choosing appropriate tools, being transparent about AI's role, and taking responsibility for accuracy.

[6:02] This framework is about making you more effective at the work that matters. Work that requires human judgment, creativity, and deep understanding of your context.

[6:12] Throughout this course, you'll apply these competencies to real challenges, drafting communications, analyzing complex information, automating routine tasks, and building sustainable AI workflows.

[6:24] The skills you take away will serve you as AI continues to evolve. You can learn more about AI fluency in Anthropic Academy, and we'll continue to share our research on this topic on Anthropic's blog.

↑ 目次へ戻る

AI Fluency for Builders | Lesson 3「AI capabilities & limitations」(全文ナレッジ)

テキストレッスン+埋め込み動画 12分(YouTube: IZSB66OLc4w)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと(What you'll learn)— 想定所要時間:25分

  • 生成 AI を定義し、それが他のタイプの AI とどう違うかを説明できる
  • 現代の LLM を可能にした3つの発展を説明できる
  • 現在の AI が得意なことと、確実に力不足になる場所を特定できる

キーテイクアウェイ(Key takeaways)

  • 生成 AI は、既存データの分析ではなく、新しいコンテンツを作り出す。
  • 現代の LLM を可能にしたのは3つの発展:トランスフォーマー・アーキテクチャ膨大な訓練データ大規模な計算資源(コンピュート)
  • 訓練には2つの段階がある。事前学習(pre-training)は数十億の例からパターンを学ぶ。ファインチューニング(fine-tuning)は、モデルに指示へ有用に従うことを教える。
  • 現在の強み:タスク横断の多才さ(versatility)、会話の流暢さ、ツール使用。
  • 現在の限界:知識カットオフ、ハルシネーション、信頼性を欠く複雑推論。
  • 最良のアプリケーションは、あなたの判断・創造性・監督(オーバーサイト)を、AI の速度とスケールと組み合わせる。

演習(Exercise):Testing the edges(自分が熟知するコーディング領域で AI の端を試す)

Part I:自己リフレクション — 自分が熟知している(know cold)コーディング領域をひとつ選び、書き出す: - トピック - 有能なエンジニアなら誰でも正しく押さえるべきこと 2〜3個 - よくある誤解、またはトリッキーな細部をひとつ - 最近変わったことをひとつ(ライブラリの更新・非推奨化・新しいベストプラクティス)

Part II:コラボレーション — 3つの短いチャットを行う: 1. 多才さ(versatility)テスト:自分のトピックを、ひとつの応答の中で3通りに説明させる(非技術系の PM 向け/中堅エンジニア向け/シニアのコードレビュアー向け)。深さの切り替えは効いていたか、それとも語彙が変わっただけか? 2. ハルシネーション・テスト:具体的なライブラリ/パッケージ/ドキュメントを尋ねる。ひとつをスポットチェックする:それは実在するか? API は正確か? バージョンは最新か? 3. 知識カットオフ+推論チェック:時間依存の質問をする(最近のフレームワーク更新/非推奨化されたパターン/セキュリティパッチ)。情報が古い可能性をフラグしたか? その後、自分の「トリッキーな細部」を一緒に考えさせる——混乱を解消したか、それとも言い換えただけか?

Part III:リフレクション - どの能力(capability)が明確に現れたか? - どの限界(limitation)が表面化したか——自分の専門外だったらそれに気づけたか? - AI に任せてよいタスクをひとつ/注意深く見張るべきタスクをひとつ挙げる。

ストレッチ課題:同じトピックを、2つ目の AI ツールでも通してみる。

次のレッスン(What's next)

Delegation(委任)の深掘りへ。

実務ポイント(このレッスンから持ち帰るもの)

  1. 限界は「仕組み由来」と理解して対策を打つ——知識カットオフ→ウェブ検索等のツールで補完、ハルシネーション→スポットチェック、コンテキストウィンドウ→長い作業は分割・要約、非決定性→一貫性が要る場面は temperature 等で制御。それぞれの限界がシステムの動作原理に直結している。
  2. ライブラリ/API/バージョンを答えさせたら、最低1つは必ず実在・正確性・最新性を検証する——LLM は検索エンジンではなく統計的パターンから生成しているため、もっともらしい捏造が混ざりうる。
  3. 自分が熟知する領域で「端」をテストして信頼度を較正する——専門領域でどんな限界が出るかを体感しておけば、専門外の領域で AI をどこまで信じてよいかの基準ができる。
  4. 事前学習後のモデルは「文書補完器」にすぎない——指示に従い、有用で、有害コンテンツを避けるのはファインチューニング(人間のフィードバック+強化学習、Anthropic なら helpful / honest / harmless)の産物。この2段階を知っていると挙動の理由が読める。
  5. 人間と AI の補完で設計する——人間=批判的思考・判断・創造性・倫理的監督、AI=速度・スケール・パターン認識・大量情報処理。最も効果的な応用はこの補完的な強みを活かすもの。
  6. 強みも限界もテクノロジーとともに変わる——継続的な学習と実験こそが、変化を追いかけ新しい可能性を発見する手段。

動画逐語(日本語訳)

[0:01](効果音)(音楽)

[0:08] こんにちは。Anthropic の教育チームのカイラです。生成 AI の探究へようこそ。

[0:15] この動画では、生成 AI とは実際のところ何なのか、そしてこれらのシステムを可能にした技術的ブレークスルーに踏み込みます。それから、生成 AI が得意なことと、どこで力不足になるかを見ていきます。

[0:25] みなさんは、裏で何が起きているのかを完全には理解しないまま、生成 AI と日々やり取りしているかもしれません。それを変えましょう。生成 AI とは、既存データを分析するだけでなく、新しいコンテンツを作り出せる人工知能システムを指します。たとえば、従来型の AI がパターンに基づいてメールをスパムか否かに分類するのに対して、生成 AI はまったく新しいメールをあなたのために書くことができます。

[0:48] 前者のアプローチは分析と分類。後者は、それまで存在しなかった新しい何かを作り出します。これは AI の能力における根本的な転換を意味します。Anthropic の Claude モデルのような大規模言語モデル(LLM)は、生成 AI の代表的なタイプです。人間の言語を予測・生成するように訓練されているから「言語モデル」と呼ばれ、数十億のパラメータ——脳のシナプス結合にどこか似た、モデルが情報をどう処理するかを決める数学的な値——を含むから「大規模」と呼ばれます。

[1:22] 今日の生成 AI への道のりは、突然のものではありませんでした。3つの重要な発展が、ちょうど良いタイミングで重なったのです。第一に、AI システムの学習方法を根本から変えた、アルゴリズムとアーキテクチャのブレークスルーがありました。ニューラルネットワークは概念としては何十年も前から存在していましたが、2017年のトランスフォーマー・アーキテクチャの開発はゲームチェンジャーでした。

[1:42] このアーキテクチャは、長い文章にわたって単語間の関係を保持しながらテキストのシーケンスを処理することに優れています。これは、文脈の中で言語を理解するために決定的に重要です。

[1:53] 第二に、デジタルデータの爆発的増加が、訓練に不可欠な原材料を提供しました。Claude のような現代の LLM は、ウェブサイト、コードリポジトリ、その他人間の知識とコミュニケーションを表すテキストといった、多様なソースから学習します。この膨大な情報のタペストリーが、言語と概念の両方について、幅広くニュアンスに富んだ理解をモデルが発達させるのを助けます。

[2:12] そして第三に、計算能力の大幅な増加により、それだけのデータでこれらの複雑なモデルを訓練することが可能になりました。GPU(グラフィックス・プロセッシング・ユニット)や TPU(テンソル・プロセッシング・ユニット)のような専用ハードウェア、そしてしばしばクラスターと呼ばれる分散コンピューティング・ネットワークが、ほんの数年前には不可能だった処理を可能にしています。

[2:35] この3つの要因の組み合わせが、スケーリング則(scaling laws)として知られる重要な発見につながりました。これは経験的な知見で、モデルが大きくなり、より多くのデータで、より多くの計算能力を使って訓練されるにつれて、性能が予測可能な形で向上することを示しました。さらに驚くべきことに、研究者たちは、モデルが大きくなるにつれて、まったく新しい能力が現れ始めることを発見しました。ステップ・バイ・ステップで問題を推論する、最小限の指示で新しいタスクに適応するといった、誰も明示的にプログラムしていない能力です。

[3:08] 生成 AI は2つのフェーズで訓練されます。第一のフェーズ——事前学習(pre-training)とも呼ばれます——では、Claude のような LLM が数十億のテキスト例からパターンを分析します。

[3:18] 見つけられる限りのすべてのウェブサイトやテキストを読むところを想像してください。情報を吸収するためだけでなく、単語・フレーズ・概念の間の統計的な関係を理解するためにです。この段階でモデルは、言語と知識の複雑な地図のようなものを構築します。事前学習のプロセスでは、モデルにテキストを見せて、次に来るものを予測させます。何度も繰り返すうちに、モデルは徐々に予測を洗練させ、言語を一貫した意味あるものにしているパターンを学びます。事前学習が終わった時点のモデルは、非常に有能な、文字どおりの「文書補完器(document completer)」です。

[3:53] 事前学習の後、モデルはファインチューニングと呼ばれる追加の訓練を受けます。ここで、指示に従うこと、有用な応答を提供すること、そして重要なことに、有害なコンテンツの生成を避けることを学びます。これには、モデルの性能を高めるための人間のフィードバックがしばしば使われるほか、報酬とペナルティによってモデルの振る舞いを形づくる強化学習も用いられます。Anthropic のモデルの場合、より helpful(有用)・honest(正直)・harmless(無害)であるように方向づけられます。

[4:20] モデルは訓練が終わると、あなたが対話できるようにデプロイされます。Claude や他の LLM とやり取りするとき、あなたはプロンプト——モデルが読み、訓練中に学んだパターンに基づいてそこから続きを生成するテキスト——を与えています。

[4:33] モデルは、データベースからあらかじめ書かれた答えを取り出しているのではありません。あなたが書いたものに統計的に続く、新しいテキストを生成しているのです。

[4:42] また、LLM が一度に考慮できる情報量には実用上の限界があり、コンテキストウィンドウとして知られています。これは AI の作業記憶(ワーキングメモリ)と考えてください。コンテキストウィンドウには、あなたのプロンプト、AI の応答、そして会話の中で共有したその他の情報が含まれます。

[4:59] AI 企業は、より長い文書や会話に対応できるようコンテキストウィンドウを拡大し続けていますが、この限界は、これらのシステムが情報へ無制限にアクセスできるわけではなく、ウェブ検索のような専用ツールなしには、現在のコンテキストウィンドウの外にあるコンテンツを使えないことを思い出させてくれます。

[5:18] まとめると、現代の生成 AI をこれほど強力にしているのは3つの特性です。訓練中に膨大な量の情報を処理する能力。プロンプト内の指示や例から新しいタスクに適応できる、インコンテキスト学習(in-context learning)の能力。そして、スケールから生じ、時にその作り手さえ驚かせる創発的能力(emergent capabilities)です。

[5:38] これらのシステムがどう動くかの感覚を掴んだところで、それが実践で何を意味するかを見ていきましょう。新しい同僚を知っていくようなものだと考えてください。相手の強みと限界を理解することが、より効果的なコラボレーションにつながります。

[5:53] 現代の言語モデルの多才さには驚くかもしれません。ほんの数年前には不可能に思えた形で、言語を巧みに操ります。あなたの声色を捉えたメールの作成、長いレポートの明快な要約への凝縮、言語間の翻訳、さらには微生物学からマーケティング戦略まで、無数の分野にわたる複雑なトピックの解説さえも。

[6:15] 特に注目すべきは、これらのモデルが追加の訓練なしに異なるタスクの間を移れることです。詩を書いたり、誕生日パーティーのアイデアをブレインストーミングしたりするのを手伝う、まさにその同じシステムが、向き直って量子コンピューティングの概念の理解や四半期のビジネストレンドの分析を手伝える——すべて単純な会話を通じてです。

[6:35] これらのモデルは、会話の筋道を保つこともできます。先に話し合ったことを覚えていて、その上に積み上げていくのです。プロジェクトの締め切りをふと口にして、会話の中で後からそれに言及すれば、AI はたいてい、人間の会話相手がそうするように、何の話かを理解します。現代の多くの LLM は、外部のツールや情報源に接続することで、自分自身の知識を超えることもできるようになりました。ウェブを検索し、ファイルを処理し、さらには他のアプリケーションを使って能力を強化することもできます。これによって、手伝える範囲は劇的に広がります。

[7:10] しかし、あらゆるテクノロジーと同じように、今日存在する LLM には一定の限界もあります。そして、そのひとつひとつが、システムの仕組みにつながっていることに注目してください。

[7:19] 第一に、AI モデルは訓練データに縛られています。LLM には、訓練された時期に基づく知識のカットオフ日——それ以降の世界について生得的な知識を持たない時点——があります。たとえば、カットオフ日が2024年11月のモデルは、その時点より後のデータでは一切訓練されていません。特定の日にインターネットのない隠遁生活(リトリート)に入った人を想像してください。出発後に起きた出来事については知らないでしょう。モデルが最近の動向について学ぶには、ウェブ検索のようなツールが必要です。

[7:46] 加えて、訓練プロセスは、訓練データに含まれるすべての事実を検証するわけではありません。つまりモデルは、訓練データに存在していた不正確さを学び、再生産してしまうことがあります。学んだ情報をつなぎ合わせようとする際に間違いを犯すこともあります。

[8:02] これが、しばしばハルシネーション(幻覚)と呼ばれるものにつながります。もっともらしく聞こえるのに実際には不正確なことを、AI が自信を持って述べる現象です。

[8:11] 既存の文書を単に取り出す検索エンジンとは異なり、LLM は統計的なパターンに基づいて応答を生成するため、時にハルシネーションを生み出します。絶対の自信で物語を語るのに、細部が完全に間違っている友人を想像してください。AI は時々、そのようになり得ます。

[8:28] 先ほど触れたコンテキストウィンドウの限界もあります。会話や文書がそれを超えると、AI はウィンドウの外に落ちた情報——通常は先入れ先出し(first-in, first-out)——を考慮できなくなります。モデルによっては、これが大きな文書の処理や会話全体の記憶を制限することがあります。

[8:47] さらに、同じ入力から同一の出力を生む従来のソフトウェアとは異なり、LLM はデフォルトではいくぶん予測不能で、非決定的(non-deterministic)とも呼ばれます。同じ質問を2回すれば、毎回わずかに異なる応答が返ってくるかもしれません。このばらつきは、これらのモデルがテキストを生成する仕組みの性質——訓練データのパターンと、開発者が調整できる特定の設定に基づいて、次に来るべきテキストを確率的に決定していること——に由来します。この創造的なばらつきは、ブレインストーミングや多様なアイデアの生成には素晴らしいものですが、一貫性や正確性が重要な場面では注意(アウェアネス)が必要です。

[9:22] 一部の LLM インターフェイスには、必要に応じてこのランダム性を制御する設定があり、しばしば temperature(温度)と呼ばれます。

[9:29] 加えて、これらのモデルは急速に改善しているとはいえ、歴史的には複雑な推論タスク——特に複数のステップを要する数学的・論理的問題——で限界を示してきました。良いニュースは、ステップ・バイ・ステップで考えるように特別に設計された、新しい推論(reasoning)モデルや拡張思考(extended thinking)モデルが、この領域で力強い進歩を見せていることです。

[9:47] そして最後に、Claude のようなモデルは外部ツールにアクセスできるようになったとはいえ、特定のタスクに必要となる特定のデータソースや専用ツールへのアクセスを依然として欠いている場合があります。あなたの会社の社内データベースにアクセスできない、優秀な同僚のようなものです。どれほど賢くても、手伝える範囲は限られてしまいます。質問に答えるために必要なデータやツールにモデルがアクセスできないなら、助けられなくても驚くことではありません。

[10:17] 生成 AI の分野は急速に進化しています。研究者たちは、モデルを外部の知識・データソースに接続する検索拡張生成(RAG: retrieval augmented generation)のような技術や、ツール使用能力の拡大、推論能力の改善を通じて、現在の限界に対処しようと取り組んでいます。とはいえ、一部の限界は——それが正確にどんな限界になるのかは分からなくても——当面のあいだ残り続けるでしょう。AI に何ができて何ができないかを理解することは AI フルーエンシーに不可欠であり、これらのシステムをいつ・どのように仕事や日常生活へ組み込むのが最善かを見極める助けになります。

[10:50] 最も効果的なアプリケーションは、人間と AI の補完的な強みを活かすものになるでしょう。私たち人間は、AI が再現するのに苦労するかもしれない批判的思考、判断、創造性、倫理的監督をもたらします。AI は、速度、スケール、パターン認識、そして膨大な情報を処理する能力を提供します。これらの補完的な強みは、テクノロジーの進化とともに変わっていきます。だからこそ、学び続けること・実験し続けることに大きな価値があるのです。それらは、変化を追いかけ、新しい可能性を発見する助けになります。

[11:21] このコースの演習を通じて、AI との会話の中でこれらの概念を直接探索する機会があります。この直接体験が、生成 AI に何ができて、何ができず、どう協働するのが最善かについての直観的な感覚を育てる助けになるでしょう。

英語原文

レッスン本文

[YouTube: IZSB66OLc4w (12 min)] AI capabilities & limitations

What you'll learn — Estimated time: 25 minutes Define generative AI and explain how it differs from other AI types Explain the three developments that made modern LLMs possible Identify what current AI does well and where it reliably falls short

Key takeaways Generative AI creates new content rather than analyzing existing data. Three developments made modern LLMs possible: the transformer architecture, vast training data, and massive compute. Training has two stages. Pre-training learns patterns from billions of examples. Fine-tuning teaches the model to follow instructions helpfully. Current strengths include versatility across tasks, conversational fluency, and tool use. Current limits include knowledge cutoffs, hallucinations, and unreliable complex reasoning. The best applications pair your judgment, creativity, and oversight with AI's speed and scale.

Exercise: Testing the edges(自分が熟知するコーディング領域でAIの端を試す) Part I: Self-Reflection — pick a coding domain you know cold. Jot: topic / 2-3 things any competent engineer should get right / one common misconception or tricky detail / one thing that changed recently (library update, deprecation, new best practice) Part II: Collaboration — three quick chats: 1. Versatility test: explain your topic 3 ways in one response (non-technical PM / mid-level engineer / senior code reviewer). Did depth shifts land, or just vocabulary? 2. Hallucination test: ask for specific libraries/packages/docs. Spot-check one: does it exist? API accurate? version current? 3. Knowledge cutoff + reasoning check: ask something time-sensitive (recent framework update / deprecated pattern / security patch). Does it flag outdated info? Then work through your tricky detail — did it resolve confusion or restate? Part III: Reflection — which capability showed clearly? which limitation surfaced (would you have caught it outside your domain)? one task fine to hand to AI / one to watch closely. Stretch: same topic through a second AI tool.

What's next: Delegation deep-dive.

動画字幕(重複除去済み)

[0:01] [snorts] [music]

[0:08] >> Hi. My name is Kyra and I'm on the education team at Anthropic. Welcome to our exploration of generative AI.

[0:15] In this video, we'll dive into what generative AI actually is and the technological breakthroughs that made these systems possible. Then we'll look at what generative AI does well and how it falls short.

[0:25] You might interact with generative AI daily without fully understanding what's happening behind the scenes. Let's change that. Generative AI refers to artificial intelligence systems that can create new content rather than just analyzing existing data. For example, while traditional AI might classify emails as spam or not spam based on patterns, generative AI can write a completely new email for you.

[0:48] The first approach analyzes and categorizes. The second creates something new that didn't exist before. This represents a fundamental shift in AI capabilities. Large language models or LLMs, like Anthropic's Claude models, are a prominent type of generative AI. They're called language models because they're trained to predict and generate human language, and large because they contain billions of parameters, mathematical values that determine how the model processes information, somewhat like synaptic connections in your brain.

[1:22] The path to today's generative AI wasn't sudden. It involved three crucial developments coming together at the right time. First, there were algorithmic and architectural breakthroughs that fundamentally changed how AI systems learn. While neural networks have been around conceptually for decades, the development of the transformer architecture in 2017 was a game-changer.

[1:42] This architecture excels at processing sequences of text while maintaining relationships between words across long passages, which is critical for understanding language in context.

[1:53] Second, the explosion of digital data provided the essential raw material for training. Modern LLMs like Claude learn from diverse sources such as websites, code repositories, and other text that represent human knowledge and communication. This vast tapestry of information helps models develop a broad and nuanced understanding of both language and concepts.

[2:12] And third, massive increases in computational power made it possible to train these complex models on all that data. Specialized hardware like GPUs or graphics processing units and TPUs or tensor processing units, along with distributed computing networks often called clusters, enable processing that would have been impossible just a few years earlier.

[2:35] The combination of these three factors led to an important discovery known as the scaling laws. These empirical findings showed that as models grew larger and trained on more data with more computing power, their performance improved in predictable ways. More surprisingly, researchers found that entirely new capabilities began to emerge as these models grew larger. Abilities no one explicitly programmed like reasoning through problems step-by-step or adapting to new tasks with minimal instruction.

[3:08] Generative AI is trained in two phases. During the first phase, also called pre-training, LLMs like Claude analyze patterns across billions of text examples.

[3:18] Imagine reading every website and piece of text you could find. Not just to absorb information, but to understand the statistical relationships between words, phrases, and concepts. At this stage, the model essentially builds something like a complex map of language and knowledge. This pre-training process involves showing the model text and asking it to predict what comes next. Through many iterations, the model gradually refines its predictions, learning the patterns that make language coherent and meaningful. At the end of pre-training, the model is a very competent literal document completer.

[3:53] After pre-training, models undergo additional training called fine-tuning, where they learn to follow instructions, provide helpful responses, and importantly, avoid generating harmful content. This often involves human feedback to improve the model's performance, as well as reinforcement learning, which uses rewards and penalties to shape the model's behavior toward being more helpful, honest, and harmless in the case of Anthropic's models.

[4:20] Once models are trained, they are then deployed for you to interact with. When you interact with Claude or another LLM, you're providing a prompt, which is a text that the model reads and then continues from based on patterns it learned during training.

[4:33] The model isn't retrieving pre-written answers from a database. Instead, it's generating new text that statistically follows from what you've written.

[4:42] There's also a practical limit to how much information an LLM can consider at once, known as the context window. Think of this as the AI's working memory. The context window includes your prompts, the AI's responses, and any other information you've shared in your conversation.

[4:59] While AI companies continue to grow the context window to allow for longer documents and conversations, these limits remind us that these systems don't have unlimited access information and cannot use content beyond their current context window without specialized tools like web search.

[5:18] Bringing this together, three characteristics make modern generative AI so powerful. Its ability to process vast amounts of information during training, its in-context learning ability that lets it adapt to new tasks from instructions or examples in your prompt, and emergent capabilities that arise from scale and sometimes surprise even their creators.

[5:38] Now that you have a sense for how these systems work, let's look at what that means in practice. Think of this as getting to to a new colleague. Understanding their strengths and limitations helps you collaborate more effectively.

[5:53] You might be amazed at how versatile modern language models can be. They're skilled at language in ways that seemed impossible just a few years ago. Crafting emails that capture your voice, condensing lengthy reports into clear summaries, translating between languages, and even explaining complex topics across countless fields from microbiology to marketing strategy.

[6:15] What's particularly notable is how these models can shift between different tasks without needing additional training. The very same system that helps you write poetry or brainstorm ideas for your birthday party can turn around and help you understand quantum computing concepts or analyze quarterly business trends, all through simple conversation.

[6:35] These models can also maintain the thread of a conversation, remembering what you discussed earlier and building upon it. If you mention your project deadline in passing and refer back to it later within the conversation, AI typically understands what you're talking about, much like a human conversation partner would. Many modern LLMs can now also reach beyond their own knowledge by connecting to external tools and information sources, allowing them to search the web, process files, or even use other applications to enhance their capabilities. This dramatically expands what they can help with.

[7:10] However, just like any technology, LLMs as they exist today also have certain limitations. And notice how each one connects back to how the system works.

[7:19] First, AI models are bounded by their training data. LLMs have a knowledge cutoff date based on when they were trained, the point after which they have no innate knowledge of the world. For example, a model with a cutoff date of November 2024 wasn't trained on any data after that point. Imagine someone who went into a retreat without internet access at a specific date. They wouldn't know about the events that happened after they left. Models need tools like web search to learn about recent developments.

[7:46] Additionally, the training process doesn't verify every fact in the training data. This means models can sometimes learn and reproduce inaccuracies that were present in their training data. They can also make mistakes when trying to piece together information they've learned.

[8:02] This leads to what is often called a hallucination. AI confidently stating something that sounds plausible, but is actually incorrect.

[8:11] Unlike search engines that simply retrieve existing documents, LLMs generate responses based on statistical patterns, sometimes producing hallucinations. Imagine a friend who tells a story with absolute confidence only to have the details completely wrong. AI can sometimes be like that.

[8:28] There's also the context window limit we discussed earlier. If a conversation or document exceeds it, the AI won't be able to consider information that falls outside the window, usually on a first-in, first-out basis. Depending on the model, this can limit its ability to process large documents or remember an entire conversation.

[8:47] Furthermore, unlike traditional software that produces identical outputs given the same inputs, LLMs are somewhat unpredictable by default, also known as non-deterministic. Ask the same question twice and you might get slightly different responses each time. This variability stems from the nature of how these models generate text. They're making probabilistic decisions about what text should come next based on patterns in their training data and certain settings that developers can tweak. This creative variability can be great for brainstorming and generating diverse ideas, but requires awareness when consistency or accuracy are critical.

[9:22] Some LLM interfaces offer settings to control this randomness when needed, often referred to as temperature.

[9:29] Additionally, while these models are improving rapidly, they've historically shown limitations with complex reasoning tasks, particularly mathematical or logical problems requiring multiple steps. The good news is that the newer reasoning or extended thinking models specifically designed to think step-by-step are showing strong progress in these areas.

[9:47] And finally, while models like Claude can now access external tools, they may still lack access to specific data sources or specialized tools that would be needed for certain tasks. It's like having a brilliant colleague who can't access your company's internal database. Their ability to help will be limited no matter how smart they are. If a model doesn't have access to a piece of data or a tool that's needed to answer a question, then it should not come as a surprise that it won't be able to help.

[10:17] The field of generative AI is a rapidly evolving. Researchers are working to address current limitations through techniques like retrieval augmented generation, which connects models to external knowledge and data sources, as well as expanding their ability to use tools and improving their reasoning capabilities. That said, some limitations will likely remain for the foreseeable future, even if we don't know exactly what those limitations will be. Understanding what AI can and cannot do is essential for AI fluency and helps you determine when and how to best incorporate these systems into your work and daily life.

[10:50] The most effective applications will leverage the complementary strengths of humans and AI. We bring critical thinking, judgment, creativity, and ethical oversight that AI may struggle to replicate. AI offers speed, scale, pattern recognition, and the ability to process vast amounts of information. These complementary strengths will evolve as the technology evolves. That's why continued learning and experimentation are so valuable. They help you stay abreast of these changes and discover new possibilities.

[11:21] In the exercises across this course, you'll have a chance to explore these concepts firsthand through conversations with AI. This direct experience will help help an intuitive feel for what generative AI can do, can't do, and how to best work with it.

↑ 目次へ戻る

AI Fluency for Builders | Lesson 4「Delegation & the builder's toolkit」(全文ナレッジ)

テキストレッスン+埋め込み動画 5分(YouTube: AWSZoy3w_nE)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと(What you'll learn)— 想定所要時間:45分

  • ビルダーのツールキット(builder's toolkit)を導入し、各段階で AI がどこに価値を加えるかを知る
  • なぜ「実装の委任」は安全で「判断の委任」は安全でないのかを説明できる
  • コードが1行も存在しない段階で、「完了(done)」を定義する受け入れテストを書ける

リフレーム(Reframe)

問うべきは「ここで AI を使うべきか?」ではない。「顧客の問題がある——それをどう分解し、各段階で AI はどんな役割を果たすのか?」である。

ビルダーのツールキット(The Builder's Toolkit)——6つのケイパビリティ(インタラクティブ図)

  • Empathy(共感)— AI は弱い:誰のために作っているのかを理解する。AI はデータやペルソナを表面化できるが、ギャップを「感じる」ことはできない。
  • Design(デザイン)/ Architecture(アーキテクチャ)/ Implementation(実装:AI はここが最強)/ Judgment(判断)/ Shipping(出荷)
  • (レッスンページではクリック式で各段階の AI 適合度を表示。Implementation 側が AI 最強、Empathy/Judgment は AI 弱=人間が持つ)

キーテイクアウェイ(Key takeaways)

  • Delegation(委任)とは、まず問題を分解し、それから各ステップで AI に何を任せるかを決めることを意味する。
  • コードの前に受け入れテストを書く。それが、あなたと AI に共有された「完了(done)」の定義を与える。
  • AI が実装を加速するにつれて、あなたの価値は「問題をフレーミングすること」と「基準(バー)を上げること」へ移っていく。

演習(Exercise):The Clinic Wait Time Project, Part 1(コース貫通プロジェクト・このレッスンではコード0行)

シナリオ:ある地域のヘルスクリニック(community health clinic)が、患者が来院前に待ち時間を確認できる方法を必要としている。伝えられているのはそれだけ。

Deliverable 1:Problem Brief(問題ブリーフ・最大1ページ) - ユーザーは誰か(どの患者? スタッフ? 他に誰?) - 彼らが本当に必要としているものは何か(「待ち時間チェッカー」ではなく、アウトカムとして) - 優れたソリューションはどう「感じられる」か(機能ではなく体験として) - 現実の制約は何か(予算、クリニックの技術スキル、患者のデバイスアクセス、プライバシー)

Deliverable 2:Delegation Plan(委任計画) ツールキットの6つのケイパビリティにマッピングし、それぞれについて AI コラボレーションのモードを選ぶ: - Automation(自動化):AI がやり、あなたが確認する - Augmentation(拡張):あなたと AI が一緒に働く - Agency(エージェンシー):あなたが設定した境界の内側で、AI が裁量を持って動く

→ 6行のテーブルにまとめる。

Deliverable 3:Acceptance Tests(受け入れテスト) 「完了(done)」を定義する 5〜7個のステートメント。見知らぬ人でも合否(pass/fail)を判定できるほど具体的に。 - 良い例:「基本的なスマートフォンを持つ患者が、アカウントを作成せずに、30秒以内に現在の待ち時間を見つけられる。」 - 悪い例:「システムは使いやすい。」

次のレッスン(What's next)

Description(記述)へ。

実務ポイント(このレッスンから持ち帰るもの)

  1. 質問を差し替える——「ここで AI を使うべきか?(イエス/ノー)」ではなく「顧客の問題をどう分解し、各段階で AI がどんな役割を担うか?」。自分=プロジェクトのリード、AI=チームという構図で、問題のフレーミング・ゴール設定・着手順・自分で下す意思決定の選別を行う。
  2. 「中央で最強・端で最弱」の地図を持つ——実装(中央)は最も積極的に委任する。共感・判断・出荷(端)は人間の仕事が生きる場所であり、価値の源泉。ユーザー観察(受付係が1日40回携帯を確認する、という気づき)は AI にはできない。
  3. コードの前に受け入れテストを書く——明確に定義されたテストと成功チェックポイントなしに実装へ入っていたら、ステップを飛ばしている。テストは「見知らぬ人でも合否判定できる」具体性まで落とす(30秒以内・アカウント作成なし、のように計測可能に)。
  4. 委任は3モード(Automation/Augmentation/Agency)から段階ごとに選ぶ——一律に「AI に任せる/任せない」ではなく、ケイパビリティ単位でモードを選択して表にする。
  5. 共感・デザインを「オーバーヘッド」と見なす誘惑に抗う——コードを瞬時に書けるツールを手にすると構築へ直行したくなる。実装が速くなるほど価値はその周囲へ移る。生き残るビルダーは最速でプロンプトを打つ人ではなく、問題を明確にフレーミングし、始める前に「良い」を知っていて、「動くコード」と「意味のあるコード」を見分けられる人。

動画逐語(日本語訳)

[0:06] AI と一緒に何かを作る時間を少しでも過ごしたことがあるなら、あることに気づいているはずです。難しいのは、AI にコードを書かせることではありません。難しいのは、AI にどんなコードを書いてほしいのかを知ることです。多くの人は、何かを AI に委任することを、単純なイエスかノーかの質問として考えます。しかしビルダーにとって、何を・どのように委任するかを正確に知ることは、はるかに複雑です。

[0:26] 顧客が問題を携えてやってきます。それを、実際に作れる何かへとどう分解しますか? そして、その仕事の各段階で AI はどんな役割を果たしますか? ここで役に立つフレームがあります。自分自身をプロジェクトのリードだと想像してください。そして AI はあなたのチームです。優れたリードは、ただタスクを割り当てるだけではありません。全員が何を解こうとしているのか理解できるように、問題をフレーミングします。チームが「良い」とはどういうことか分かるように、ゴールを設定します。何に最初に取り組むかを決め、そして決定的に重要なことに、どの意思決定を自分で下し、どれを手放すかを知っています。それがビルダーの意味での委任(delegation)であり、それはコードが1行でも書かれるよりずっと前から始まっています。

[1:02] すべてのビルダーは、自分でも持っていると気づいていないかもしれないツールキットを携えています。それは、ビルドのあらゆる瞬間に手を伸ばせる、6つのケイパビリティに集約できます。AI は6つすべてを手伝えますが、あるものは他よりずっと得意です。そして、その違いを知ることが、ビルダーのための AI フルーエンシーの鍵となる部分です。

[1:18] 第一のケイパビリティは共感(empathy)です。私たちが作ってあげる相手は、実際には何を必要としているのか? 相手が「欲しい」と言ったものではなく、その人の仕事を本当に、真に助けるものは何か。ここは、ユーザーと話し、何が彼らをいらだたせているかを観察する場所です。ここで学んだことの整理は AI が手伝えます。しかし、クリニックの受付係のそばに座って、患者たちが待ち時間を尋ねる電話をかけ続けてくるせいで、彼女が1日に40回も携帯電話をチェックしていることに気づく——それは AI にはできません。その観察は、すべてあなたの仕事です。

[1:46] 第二はデザイン(design)です。何を作るべきか、そしてなぜか? ここはトレードオフを比較検討し、賭けに出て、何が重要かを決める場所です。テキストメッセージにすべきか、それともウェブページにすべきか? 正確な待ち時間を見せるべきか、幅(レンジ)で見せるべきか? それらは判断の問題(judgment calls)です。AI にできるのは選択肢を生成することだけで、どの選択肢がフィットするかという判断はあなたのものです。

[2:05] 第三はアーキテクチャ(architecture)です。そのモノはどう構造化されるべきか? 部品は何で、それらはどう組み合わさるのか? AI はパターンを知っています。あなたがスケッチしているようなシステムを、千個も見てきました。しかし、あなたの制約、あなたのチームのスキル、そして6か月後に何を変える必要があるのかは知りません。ここは「人間+AI」が本当に、本当にうまく機能する場所です。

[2:24] 第四は実装(implementation)です。実際のコードを書くこと。ここが AI の最も強い場所です。何を作るのか、そしてそれがどう構造化されるべきかが分かってしまえば、AI は動くコードを効果的に書けます。これは、あなたが最も積極的に委任すべきケイパビリティです。もし、明確に定義されたテストと成功のチェックポイントなしにこの段階へ入っていたら、あなたはおそらくステップをひとつ飛ばしています。

[2:45] 第五は判断(judgment)です。それは実際に動くのか? それは本当に良いのか? そこに自分の名前を刻めるか? AI は「コードは動きます」と教えてはくれますが、その体験が正しく感じられるかどうか、そのエッジケースが重要かどうか、あるいは目の前にある本物の問題を解決したのかどうかは教えてくれません。判断には、あなたの専門性、基準、そして視点が必要です。

[3:05] 最後は出荷(shipping)です。実際のユーザーに届け、起きたことから学ぶこと。これはコミュニケーション、計測、イテレーションを意味します。AI はリリースノートの下書きを書けますが、ユーザーがクリックする前に一瞬ためらったときの空気を読むことはできません。

[3:16] さて、このリストの形を見てください。実装はちょうど真ん中に位置していて、そこが AI の最も強い場所です。共感、判断、出荷は端に位置していて、そこが AI の最も弱い場所です。それがこのコースの鍵となる洞察です。AI はツールキットの中央で最も強く、端で最も弱い。端は、人間の仕事が生きている場所。端こそ、価値がある場所です。

[3:38] では、実践における良い委任とはどんな姿でしょうか? それは、プロジェクトの最初に本物の時間を使って、誰のために作るのかを明確にし、成功が何を意味するのかを定義する姿です。それは、結果を懐疑的に検分し、判断の決定を自分自身の手の中に保ち続ける姿です。

[3:55] コードを瞬時に書けるツールを手にすると、まっすぐ構築に飛びつき、共感やデザインの仕事をオーバーヘッド(余計な間接コスト)として扱いたくなる誘惑が生まれます。その感覚に抗ってください。AI が実装を速くすればするほど、あなたの価値はその周囲にあるすべてへと移っていきます。この時代に栄えるビルダーは、最も速くプロンプトを打つ人ではないでしょう。問題を明確にフレーミングし、始める前に「良い」とはどういうことかを知っていて、動くコードと意味のあるコードの違いを見分けられる人です。仕事は今から始まります。さあ、取りかかりましょう。

英語原文

レッスン本文

[YouTube: AWSZoy3w_nE (5 min)] Delegation & the builder's toolkit

What you'll learn — Estimated time: 45 minutes Introduce the builder's toolkit and where AI adds value at each stage Explain why delegating implementation is safe and delegating judgment is not Write acceptance tests that define done before a single line of code exists

Reframe: not "should I use AI here?" but "I have a customer problem — how do I break it down, and what role does AI play?"

The Builder's Toolkit(6 capabilities・インタラクティブ図) Empathy — AI WEAK: Understanding who you're building for. AI can surface data and personas — it can't feel the gap. Design / Architecture / Implementation (AI is strongest here) / Judgment / Shipping (クリック式で各段階のAI適合度を表示。Implementation側がAI最強、Empathy/JudgmentはAI弱=人間が持つ)

Key takeaways Delegation means decomposing the problem first, then deciding what AI handles at each step. Write acceptance tests before code. They give you and AI a shared definition of done. As AI accelerates implementation, your value shifts to framing problems and raising the bar.

Exercise: The Clinic Wait Time Project, Part 1(コース貫通プロジェクト・このレッスンではコード0行) Scenario: A community health clinic needs a way for patients to check wait times before coming in. That's all you've been told. Deliverable 1: Problem Brief (one page max) — Who are the users (which patients? staff? who else)? What do they actually need (outcome, not "a wait time checker")? What does a great solution feel like (experience, not features)? Real constraints (budget, clinic tech skill, patient device access, privacy)? Deliverable 2: Delegation Plan — map to 6 toolkit capabilities; for each choose AI collaboration mode: Automation (AI does it, you check) / Augmentation (you and AI work together) / Agency (AI operates with latitude inside boundaries you set). 6-row table. Deliverable 3: Acceptance Tests — 5-7 statements defining "done", concrete enough a stranger could judge pass/fail. Good: "A patient with a basic smartphone can find the current wait time in under 30 seconds without creating an account." Bad: "The system is easy to use."

What's next: Description.

動画字幕(重複除去済み)

[0:06] If you spent any time building with AI, you've probably noticed something. The hard part isn't getting AI to write code. The hard part is knowing what code you want an AI to write. Many people think of delegating something to an AI as a simple yes or no question. But for builders, knowing exactly what and how to delegate is much more complex.

[0:26] Your customer comes to you with a problem. How do you decompose it into something that you can actually build? And what role does AI play at each stage of that work? Here's a useful frame. Imagine yourself as the lead on a project and AI is your team. A great lead doesn't just assign tasks. They frame the problem so everyone understands what they're solving. They set goals so the team knows what good looks like. They decide what to tackle first and critically they know which decisions to make themselves and which ones to hand off. That's delegation in the builder sense, and it starts well before any code gets written.

[1:02] Every builder carries a toolkit that they may not know that they have. You could boil it down to six capabilities you can reach for at any different moment in a build. AI can help with all six, but it's much stronger at some than others. And knowing the difference is a key part of AI fluency for builders.

[1:18] The first capability is empathy. What does the person we're building for actually need? not what they said that they want, but what will actually truly help their work. This is where you talk to users and observe what frustrates them. AI can help you organize what you learn here, but it can't sit with a clinic receptionist and notice that she checks her phone 40 times a day because patients keep calling to ask about weight times. That observation is all you.

[1:46] The second is design. What should we build and why? This is where you weigh trade-offs, make bets, and decide what matters. Should it be a text message or a web page? Should it show exact weight times or ranges? Those are judgment calls. All AI can do is generate options, but the judgment about which option fits is yours.

[2:05] Third is architecture. How should the thing be structured? What are the pieces and how do they fit together? AI knows patterns. It's seen a thousand systems like the one you're sketching, but it doesn't know your constraints, your team skills, or what you need to change six months from now. Human plus AI works really, really well here.

[2:24] Fourth is implementation. Writing the actual code. This is where AI is the strongest. Once you know what you're building and how it should be structured, AI can write working code effectively. This is the capability you should delegate most aggressively. If you've entered this stage without clearly defined tests and success checkpoints, you've probably skipped a step.

[2:45] Fifth is judgment. Does it actually work? Is it actually good? Would you put your name on it? AI will tell you the code runs, but it won't tell you if the experience feels right, whether the edge cases matter, or whether you've solved a real problem at hand. Judgment requires your expertise, standards, and perspective.

[3:05] Last is shipping. Getting it to real users and learning from what happens. This means communication, measurement, iteration. AI can draft release notes, but it can't read the room when your user hesitates before clicking.

[3:16] Now, look at the shape of that list. Implementation sits right in the middle and that's where AI is the strongest. Empathy, judgment, and shipping sit at the edges and that's where AI is the weakest. That's the key insight for this course. AI is the strongest in the middle of the toolkit and weakest at the edges. The edges are where the human work lives. The edges are where the value is.

[3:38] So, what does good delegation look like in practice? It looks like spending real time at the beginning of a project getting clear on who you're building for and defining what success means. It looks like inspecting the results skeptically and keeping judgment calls in your own hands.

[3:55] There's a temptation once you have a tool that can write code instantly to skip straight to building to treat empathy and design work as overhead. Resist that feeling. The faster AI makes implementation, the more your value shifts to everything around it. The builders who thrive in this era won't be the ones who prompt the fastest. They will be the ones who frame problems clearly, who know what good looks like before they start, and who can tell the difference between code that runs and code that matters. The work starts now. Let's get into it.

↑ 目次へ戻る

AI Fluency for Builders | Lesson 5「Description & building great things」(全文ナレッジ)

テキストレッスン+埋め込み動画 5分(YouTube: wotzFHTKQ9Q)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと(What you'll learn)— 想定所要時間:45分

  • Description Chain(記述の連鎖)を使って、ユーザーニーズを精密な AI 指示へと翻訳できる
  • 記述の失敗(description failure)が連鎖(カスケード)する瞬間を見抜き、壊れたリンクまで遡れる
  • 「成功とはどういうことか」を AI に正確に伝えるテストとして、意図を表現できる

キーテイクアウェイ(Key takeaways)

  • Description Chain は、ユーザーの声(user voice)→要件(requirement)→技術仕様(technical spec)→AI 指示(AI instruction)をつなぐ。プロンプトエンジニアリングは、そのうちの1リンクにすぎない。
  • ビルダーは、あらゆるステップにおける翻訳者である。 AI は、ユーザーが言わなかったことを聞き取れない。
  • 「コードは動くのにプロダクトが機能しない」のは記述の失敗。上流のどのリンクが壊れたのかを見つける。
  • テストは最も精密な記述の形式。 テストが通っているのにユーザーが不満なら、間違った意図を記述したということ。
  • すべてのステップには、前のフェーズが代わりに下してくれなかった判断(judgment calls)が含まれる。

演習(Exercise):The Clinic Wait Time Project, Part 2

Step 1:プロダクト要件を書く — 1パラグラフで。すべての形容詞=自分が擁護(defend)できる意思決定(「速い」→どれくらい速い? 「シンプル」→駐車場で携帯から確認する患者にとってのシンプルとは何か?)。

Step 2:技術仕様を書く — 半ページで。構成要素(ピース)と、それらがどう連携するかを名指しする。AI を augmentation(拡張)モードで使う:要件を共有し、技術的アプローチを求め、制約に合わないものにはプッシュバックする。

Step 3:テストを引き締める — 受け入れテストを、コードが各項目に合格/不合格できる形に書き直す。エッジケースを2つ以上追加する:クリニックが閉まっている/データがない/待ち時間がゼロ。

Step 4:AI プロンプトを書いて構築する — 制約、スタックの選択、テストを含む指示を書く。v1 を構築する。

Step 5:デモする — パートナーがクリニックの患者役を演じる(病気の子ども、持ち時間10分)。使うところを観察する。説明しない。助けない。 - テストは通ったか? 患者は満足しているか? 答えが一致しないなら→チェーンのどのリンクが壊れたのか?

次のレッスン(What's next)

Discernment(識別)へ。

実務ポイント(このレッスンから持ち帰るもの)

  1. Description Chain の4ステップで記述する——①ユーザーの声(生の発言・感情・言外のコンテキスト)→②プロダクト要件(計測可能にスコープ:モバイルフレンドリー/推定/5分ごと更新のように、各語が意思決定)→③技術仕様(実装可能:ピースと連携。ただしスタック・エラー処理・API 停止時などの余地が残る)→④AI 指示(制約・エッジケース・データの形・合格すべきテストまで具体化)。プロンプトは最後の1リンクにすぎない。
  2. 「コードは動くがプロダクトは動かない」=記述の失敗として鑑識的に遡る——4分類で切り分ける:ユーザー理解の失敗(そもそも聞けていなかった)/要件の失敗(聞けたが要件化を誤った)/仕様の失敗(要件は正しいが技術翻訳で喪失)/プロンプトの失敗(上流は堅牢で指示だけが拙い)。
  3. すべての形容詞を意思決定に変換する——「速い」「シンプル」を残したまま次工程へ渡さない。共感ワークで得た「言外の知識」(正確な時刻はスタッフを不安にさせる→推定、移動中に確認する→レスポンシブ必須)を損なわずに運ぶのがビルダーの仕事。
  4. テストをプロンプトと一緒に AI へ渡す——よく書かれたテストは誤読されようのない意図の記述(通るか通らないか)。「何を作るか」だけでなく「成功をどう判定するか」を渡すと、返ってくるものが変わる。AI に検証可能な具体物を与えると、より効果的に・より長く働ける。
  5. デモでは説明しない・助けない——「テスト合格+ユーザー不満」は失敗ではなく最も有益な発見:テストが間違ったものを記述していた証拠であり、チェーンのどこを見ればよいかが正確に分かる。

動画逐語(日本語訳)

[0:01](効果音)(音楽)

[0:06] さて、前のモジュールでは、ツールに触れる前に、問題を理解することに本物の時間を使いました。問題ブリーフを書きました。受け入れテストを書きました。何を自分の手に残し、何を AI に委任するかを決めました。しかし今度は、そのすべてを何かに——AI が実際に行動へ移せる何かに——変えなければなりません。多くの AI トレーニングは、記述(description)をプロンプトエンジニアリングとして扱います。私たちはこのタスクに違うやり方で取り組みます。あなたが明確に定義した問題を解決する助けとなる、記述のあらゆる側面を考えるのです。

[0:33] Description は高レベルのコンピテンシーであり、モデルごとに変わるかもしれない Tips や小技よりも長生きして、ずっと有効であり続けます。

[0:43] ビルダーのツールキットの6つのケイパビリティを思い出してください。実装の前に、私たちはユーザーニーズを定義しなければなりません。全体像はこうです。ツールキットのケイパビリティに直接結びついた4つのステップがあり、それぞれのステップの中心(ハート)には、翻訳者としてのビルダーがいます。すでに取り組んでいるプロジェクトを使いましょう。

[0:59] 最初のステップはユーザーの声(user voice)です。実在の人が実際に口にすることです。たとえば、「クリニックに行く前に待ち時間が見たい」。トーンと感情に注目してください。そこには、話し手が口に出さなかったコンテキストが乗っています。もう2時間も経っていること。車の中に子どもがいて、このクリニックと町の反対側にある救急外来(アージェントケア)とのあいだで決めかねていること。自分自身の共感を使って、ユーザーが言葉にしなかったものとつながり、観察してください。ユーザーの声はあくまで原材料です。それは真実ですが、まだ「作れる形」にはなっていません。

[1:27] そこで2番目のパートがプロダクト要件(product requirement)です。ここで、生のユーザーニーズを、計測可能な何かへとスコープします。たとえば「患者は、モバイルフレンドリーなウェブページで、おそらく5分ごとに更新される推定待ち時間を見ることができる」。今、自分が何をしたか分かりますか? あなたは意思決定を下したのです。アプリではなく、モバイルフレンドリー。正確ではなく、推定。リアルタイムではなく、5分ごと。それぞれが、あなた自身の共感ワークで学んだことに基づいて下した、鍵となる判断です。非常に明確で具体的な基準を確保しておくことは、実装ステップに至ったとき、AI が自分の仕事をよりうまくこなす助けになります。

[2:03] 3番目のピースは技術仕様(technical spec)です。ここからが本当の構築に入っていきます。たとえば「クリニックの API から待ち時間データを取得し、レスポンシブな UI で表示し、5分間隔でリフレッシュするウェブアプリ」。これは実装可能です。エンジニアが実際にそれを読んで、作り始められる。AI にもできます。しかし、まだ余地が残っていることに注意してください。どのスタックを使うのか? エラーはどう処理されるのか? API が落ちたら何が起きるのか?

[2:27] 4番目のステップは AI 指示(AI instruction)です。具体的で、コンテキストが与えられ、制約とエッジケースが明確に定義されたもの。使用しているスタックと、データの形。データがないときに何をすべきか。合格しなければならないテスト。AI に検証できる具体的なものを与えることが決定的に重要です。それによって AI は、より効果的に、そしてより長く働けるようになります。

[2:46] これが重要な理由はこうです。問題のあらゆる側面を注意深く記述することを考えるビルダーが、AI から最良の結果を得ます。記述が思慮深いほど、アウトプットは良くなります。AI は、ユーザーが言わなかったことを聞き取れません。正確な時刻を出すとクリニックのスタッフがそれに縛られることを不安に思うから「推定」が正しい要件なのだ、と AI が決めることはできません。患者が移動中(in route)に待ち時間を確認するからレスポンシブネスが重要なのだ、ということも知りようがありません。

[3:14] あなたは、それらを知っています。あなたの仕事は、AI に必要なものを記述するとき、それらを損なわずに(intact なまま)運ぶことです。

[3:20] ときどき、この翻訳は壊れます。そして壊れたとき、特定のタイプの失敗が現れます。コードは動くのに、プロダクトは機能しない。テストは通るかもしれないのに、ユーザーはまだ苛立っている。それはバグではありません。記述の失敗です。そしてそれはたいてい、プロンプトの上流に住んでいます。

[3:36] だからこそ、ビルダーとしてのあなたの仕事の大きな部分は、実は鑑識(forensic)なのです。作ったものが的を外したとき、あなたは遡って調べます。そもそも相手が必要としているものを本当には聞けていなかった「ユーザー理解の失敗」だったのか? 聞けてはいたが、その後の要件化を誤った「要件の失敗」だったのか? 要件自体は正しかったのに技術翻訳で何かが失われた「仕様の失敗」だったのか? それとも、上流はすべて堅牢で、単に AI への指示が拙かった「プロンプトの失敗」だったのか?

[4:05] 構築に入る前に、もうひとつだけ。前のモジュールで書いた受け入れテストも、記述の一形態です。もしかすると、最も強力な形態かもしれません。よく書かれたテストは、誤読されようのない意図の記述です。なぜなら、通るか、通らないか、どちらかだからです。プロンプトと一緒にテスト一式を AI に手渡すとき、あなたは「何を作るか」を伝えているだけではありません。「成功したかどうかを自分がどうやって知るのか」を伝えているのです。それは、返ってくるものを変えます。

[4:28] このモジュールでは、クリニックのプロジェクトについて、AI のための詳細な記述を書いていきます。プロダクト要件、技術仕様、テスト、プロンプト。そして、このコースで初めて、実際に構築します。

[4:42] 作ったものを、クリニックの患者役を演じる誰かにデモして、2つの質問をします。第一に、テストは通ったか? そして第二に、ユーザーは満足しているか? もし第一の答えがイエスで、第二の答えがノーなら、それは失敗ではありません。このモジュールであなたに起こりうる、最も有益な出来事です。あなたのテストが間違ったものを記述していたと分かり、チェーンのどこを見ればいいのかが、今や正確に分かったのですから。さあ、取りかかりましょう。

[5:09](音楽)

英語原文

レッスン本文

[YouTube: wotzFHTKQ9Q (5 min)] Description & building great things

What you'll learn — Estimated time: 45 minutes Translate a user need to precise AI instruction using the Description Chain Spot when a description failure cascades and trace it back to the link that broke Express intent through tests that tell AI exactly what success looks like

Key takeaways The Description Chain connects user voice to requirement to technical spec to AI instruction. Prompt engineering is only one link. The builder is the translator at every step. AI cannot hear what the user did not say. Code that works but the product doesn't is a description failure. Find which link broke upstream. Tests are the most precise form of description. A passing test with an unhappy user means you described the wrong intent. Every step involves judgment calls the previous phase did not make for you.

Exercise: The Clinic Wait Time Project, Part 2 Step 1: Write the product requirement — one paragraph. Every adjective = a decision you can defend ("fast" → how fast; "simple" → what simple means for a patient checking from a phone in a parking lot). Step 2: Write the technical spec — half a page. Name the pieces and how they talk. Use AI in augmentation mode: share requirement, ask for technical approach, push back on anything that doesn't fit constraints. Step 3: Tighten your tests — rewrite acceptance tests so code could pass/fail each. Add 2+ edge cases: clinic closed / no data / wait time zero. Step 4: Write your AI prompts and build — instructions with constraints, stack choices, tests. Build v1. Step 5: Demo it — partner plays a clinic patient (sick kid, ten minutes). Watch them use it. Don't explain. Don't help. Did tests pass? Is the patient satisfied? If answers don't match → which link in the chain broke?

What's next: Discernment.

動画字幕(重複除去済み)

[0:01] [snorts] [music]

[0:06] >> So in the last module, you spent real time understanding the problem before touching any tools. You wrote the problem brief. You wrote acceptance tests. You decided what you keep and then what you delegate to AI. But now, you have to turn all of that into something. Something that AI can actually act on. Most AI training treats description as prompt engineering. We're going to approach this task differently by considering all the aspects of description that will help you solve the problem you've clearly defined.

[0:33] Description is a high-level competency that will remain relevant, outlasting tips and tricks that may change from model to model.

[0:43] Recall the six capabilities in the builder's toolkit. Before implementation, we have to define the user need. Here's the full picture. Four steps directly tied to the capabilities in your toolkit, with the builder as the translator and the heart of each step. Let's use the project you're already working on.

[0:59] First step is user voice. This is what a real person actually says. For example, I want to see wait times before I go to the clinic. Notice the tone, the emotion. It carries context the speaker didn't say out loud that it's been 2 hours already. They have a kid in the car and they're deciding between this clinic and urgent care across town. Use your own empathy to connect and observe with what goes unsaid by the user. User voice is just raw material. It's true and it's not yet buildable.

[1:27] So the second part is product requirement. This is where you take that raw user need and you scope it into something measurable. Patients, for example, can view estimated wait times via a mobile-friendly webpage, perhaps updated every 5 minutes. You see what you did there? You made decisions. Mobile-friendly, not an app. Estimated, not exact. Every 5 minutes, not real-time. Each is a key judgment call that you made based on what you learned in your own empathy work. Ensuring that there are very clear concrete criteria helps the AI do its job better when it gets to the implementation step.

[2:03] The third piece is the technical spec. Now you're getting into the real building. A web app, for example, that pulls a clinic API for weight data and displays it with a responsive UI refreshing on a 5-minute interval. That is implementable. An engineer could actually read that and start building. So could an AI. But notice it still leaves room. Which stack? How errors get handled? What happens when the AI goes down?

[2:27] The fourth step is AI instruction. Specific, contextualized with constraints and edge cases clearly defined. The stack you're using and the shape of the data. What to do when there's no data? The test that it has to pass. It's critical that you give the AI specific things it can verify. This helps it work more effectively and for longer.

[2:46] So here's why this matters. Builders who think about carefully describing all aspects of the problem get the best results with AI. The more thoughtful the description, the better the output. AI can't hear what the user didn't say. AI can't decide that estimated is the right requirement because exact times would make the clinic staff anxious about being held to them. It can't know that responsiveness matters because patients are checking wait times while they're in route.

[3:14] You know those things. Your job is to carry them intact as you describe what you need to the AI.

[3:20] Sometimes the translation breaks. And when it does, you get a specific type of failure. Code that works, but the product doesn't. The tests might pass, but the user is still frustrated. That's not a bug, that's a description failure, and it usually lives upstream of the prompt.

[3:36] So a big part of your job as a builder is actually forensic. When the thing you built misses the mark, you trace it back. Was it a user understanding failure where you never really heard what they needed in the first place? Was it a requirement failure where you heard them, but then you it wrong? Was it a spec failure where the requirement was actually right but the technical translation lost something? Or a prompt failure where everything upstream was solid and you just instructed the AI poorly?

[4:05] So one more idea before we build. Your acceptance tests from the last module are a form of description, too. Maybe the most powerful kind. A well-written test is a description of intent that can't be misread because it either passes or it doesn't. When you hand AI a set of tests alongside your prompt, you're not just telling it what to build. You're telling it how you'll know if it succeeded. That changes what you get back.

[4:28] So in this module, you're going to write detailed descriptions for AI with your clinic project. Product requirements, technical specs, tests, prompts, and then for the first time in this course, we're going to build.

[4:42] You'll demo what you build to someone playing a clinic patient and you'll ask two questions. First, did the test pass? And second, is the user satisfied? If the answer to the first is yes and the second is no, that's not a failure. That's the most useful thing that can happen to you in this module. It means your test described the wrong thing and now you know exactly where in the chain to look. Let's get to it.

[5:09] >> [music]

↑ 目次へ戻る

AI Fluency for Builders | Lesson 6「Discernment for code」(全文ナレッジ)

テキストレッスン+埋め込み動画 5分(YouTube: 7J2-HzHs4c8)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと — 所要時間目安: 30分

  • AI が生成した成果物を5つのレンズ——正しさ(correctness)・品質(quality)・適合(fit)・体験(experience)・責任(responsibility)——で評価する
  • AI で作られたプロダクト特有の失敗モードを学び、品質基準を「動く(it works)」の先へ引き上げる
  • AI の予測可能な技術的盲点を、本番に到達する前に捕まえる

識別の5レンズ(The Five Lenses of Discernment)

インタラクティブ図。Lens 1 は実行して確認できる検証 → Lens 5 は AI には下せない判断、へと段階が上がっていく構成。

  • LENS 1 Functional Integrity(機能的完全性) — 動くか? テストデータだけでなく、現実の入力に対して正しい出力を生むか。AI の典型的失敗: ユニットテストは通るのに、プロンプトが一度もカバーしなかった実データで壊れるコード
  • LENS 2 Production Readiness(本番適性) — うまく動くか?(パフォーマンス・スケーラビリティ・信頼性)
  • LENS 3 Problem Fit(問題適合) — 正しいものか?(ユーザーの本当の問題を解いているか)
  • LENS 4 Experience Quality(体験品質) — 良いものか?(明快・直感的・アクセシブルか)
  • LENS 5 Responsible Impact(責任ある影響) — 責任あるものか?(バイアス・プライバシー・意図せぬ帰結)

Key takeaways

  • 動くコードでも失敗しうる。 AI のデフォルト出力は技術的には完全でも、しばしば要点を外している。
  • AI には予測可能な盲点がある — 並行処理(concurrency)、セキュリティ、そして「スケールしたときに初めて壊れるもの」すべて。
  • センス(taste)はビルダーのスキル。 AI が届けるのは「機能するもの」。それを「使う価値のあるもの」にするのはあなたの仕事。

演習: Clinic プロジェクトのユーザーテスト

自分のビルドを、患者役またはクリニック管理者役を演じるパートナーの前に置く——説明しない、助けない。どこで混乱するか、何を無視するか、あなたが作らなかった何を欲しがったかを観察する。変えたいことを3つ書き出し、それぞれがどのレンズに該当するかを記録する。

次のレッスン

Discernment for user experience(ユーザー体験のための識別)。

実務ポイント(このレッスンから持ち帰るもの)

  • コードレビューを Lens 1 で止めない。 「動くか」は必要条件であって十分条件には程遠い。5レンズ(動くか/うまく動くか/正しいものか/良いものか/責任あるものか)をレビューのチェックリストにする。
  • テストはコードと同じパスで書かせる。 プロンプト時に「テストケースも同じ応答で書いて」と頼む。後付けではなく並行生成。実行されていないテストスイートはセーフティネットではなく「偽りの安心感」——定期チェックポイントで必ず回す。
  • AI に自分の出力をストレステストさせる。 本番シナリオを生成させ、コードがどう扱うかを確認させる。さらに「このコードはどんな本番前提を置いているか?」と明示的に質問すると、初回パスの見落としが浮上する。
  • AI の盲点の定番は並行処理・セキュリティ・大規模時にのみ壊れるもの。API 応答が5秒遅延したら表示はフリーズするか、古いデータを出すか、優雅にフェイルするか——AI はそれを考えない。考えるのはあなた。
  • 表明された問題と本当の問題を照合する。 「待ち時間を表示して」の裏に「20分以内に小児科医に診てもらえるか知りたい」がある。AI は述べられた問題を解く。本当の問題かを確かめるのはビルダー。
  • バイアスへのガードレール。 過去データで学習した推定は構造的不公正をそのまま再生産しうる(しかも警告なしに数字を表示するだけ)。構築中に AI 自身にバイアスを言語化させ、すべての仮定を疑う。
  • 不十分な出力への自分の反応を観察する。 自分で直しに行くか、記述(description)に戻るか。どちらも間違いではないが、そのパターンが「識別力を築いているのか、ただ作っているだけなのか」を教えてくれる。

動画逐語(日本語訳)

(イントロ効果音・音楽)

>> あなたはもう、AI と一緒に何かを作り上げました。動くし、テストも通る。——でも、だから何でしょう? 私たちが作ってきたプロジェクトについて考えてみてください。患者の推定待ち時間が突然10分から90分に跳ね上がるシナリオを扱えましたか? 患者ごとに異なるニーズを考慮し、それに応えられていましたか? 既存データに含まれる歴史的なバイアスを、そのまま組み込んでしまっていませんか? 「動くプロダクト」と「良いプロダクト」は、必ずしも同じものではありません。そして AI が数分で「動くプロダクト」を作れるようになった今、その違いを見分ける能力こそが、その部屋で最も価値あるスキルになります。このモジュールでは、その判断のための構造をお渡しします。AI が作るあらゆるものに問いかけるべき、5つのレンズと5つの質問です。

第1のレンズは機能的完全性(Functional Integrity)。実際に動くのか? バグ、エラー、セキュリティホール。ほとんどのコードレビューはここで止まります。必要ではありますが、十分には程遠い。私たちのプロジェクト例では、AI は待ち時間を表示する健全なロジックを組みました。しかし、患者の優先度は考慮していたでしょうか? どちらを表示するかを決める際の、矛盾するデータポイントについてはどうでしょう? 構築するときは、機能テストの全域を考えてください——ユニットテスト、統合テスト、リグレッションテスト、エッジケース、エンドツーエンド。そして、大事な習慣がひとつあります。AI にはコードの「後」ではなく、コードと「並行して」テストを書かせるべきです。プロンプトを出すとき、まさに同じパスでテストケースも書くよう頼んでください。そのうえで、定期的なチェックポイントを組み込む。実行されていないテストスイートはセーフティネットではありません。ただの偽りの安心感です。

第2のレンズは本番適性(Production Readiness)。実際に「うまく」動くのか? パフォーマンス、スケーラビリティ、信頼性。負荷がかかったら何が起きるか? 何百人もの人が同時にリフレッシュしようとしたら何が起きるか? AI にはここに特有の盲点があります。では、構築プロセスの中でどう検証するか。具体的な打ち手をいくつか。AI に自分自身の出力をストレステストさせること。本番シナリオを生成させ、コードがそれをどう扱うか確認させる。そして明示的に聞くこと——「このコードはどんな本番前提を置いている?」。最初のパスで見落とされていたことが浮かび上がります。あなたのプロジェクトでは、API 呼び出しが5秒も余計にかかる場合をコードは考慮していましたか? 表示はフリーズするのか、古いデータを見せるのか、それとも優雅にフェイルするのか? AI はそれを考えません。それはあなたの仕事です。

第3のレンズは問題適合(Problem Fit)。それは正しいものか? ユーザーの実際の問題を解いているのか、それともユーザーが「抱えていると思っている」問題を解いているのか? 前のレッスンで見たとおり、この2つは乖離しえます。患者は待ち時間について尋ねました。額面どおりに受け取れば、AI は推定待ち時間の表示を作れます。しかし患者が本当に知る必要があったのは、この20分以内に小児科医の診察を受けられるかどうか——子どもの発熱が危険な状態かどうかを判断するためです。AI は「表明された問題」を解きました。しかし、それが「本当の問題」なのかどうかを確かめる必要があるのは、あなたです。

第4のレンズは体験品質(Experience Quality)。それは実際に良いものか? 体験は明快で、直感的で、アクセシブルか? AI にセンス(taste)はありません。あるのはパターンです。誰も使って楽しくない、そつのないインターフェースを返してきます。クリニックの待ち時間ツールにとって、それは単なる見た目の問題ではなく、患者の安全の問題です。それに気づき、具体的で修正可能なものへ翻訳するのが、ビルダーであるあなたの仕事です。体験の識別については、次のレッスンで詳しく扱います。

第5のレンズは責任ある影響(Responsible Impact)。それは責任あるものか? バイアス、プライバシー、意図せぬ帰結。これは誰を傷つけうるか? ユーザーについて、真実ではないかもしれないどんな仮定を置いているか? クリニックの待ち時間ツールに戻りましょう。待ち時間を推定するアルゴリズムは、過去データで学習されていますか? そのデータが既存のバイアス——特定の属性の人々の待ち時間を長くしてきた構造的不公正——を反映しているなら、モデルは同じパターンを再生産しかねません。しかもそれを警告しません。ただ数字を表示するだけです。ガードレールを作りましょう。構築しながら、AI 自身にそのバイアスを名指しさせる。そして最も重要なのは、すべての仮定を疑うことです。

エンジニアリング教育の大半は最初の2つのレンズで止まります。しかしビルダーには5つすべてが必要です。そして、適用し始めると分かることがあります。最大の問題は、ほとんど決してレンズ1にはないのです。AI は「動くコード」を作るのが得意です。「意味のあるプロダクト」を生むには、あなたの監督が必要です。

もうひとつ。十分に良くないものを見つけたとき、自分自身の本能に注目してください。手を突っ込んで自分で直すのか、それとも戻って、必要だったものをより良く記述し直すのか。どちらも間違いではありません。しかしそのパターンは、あなたが AI とどのように働いているか——識別力を築いているのか、それともただ作っているだけなのか——を教えてくれます。さあ、このレンズを適用する時間です。行きましょう。

英語原文

レッスン本文

[YouTube: 7J2-HzHs4c8 (5 min)] Discernment for code

What you'll learn — Estimated time: 30 minutes
Evaluate AI-generated work across five lenses: correctness, quality, fit, experience, and responsibility
Raise your quality bar beyond "it works" by learning failure modes specific to AI-built products
Catch AI's predictable technical blind spots before they reach production

The Five Lenses of Discernment(インタラクティブ図・Lens 1は実行して確認できる→Lens 5はAIには下せない判断)
LENS 1 Functional Integrity — Does it work? Produces correct output for real inputs, not just test data. COMMON AI FAILURE: Code that passes unit tests but breaks on real data the prompt never covered
LENS 2 Production Readiness
LENS 3 Problem Fit
LENS 4 Experience Quality
LENS 5 Responsible Impact

Key takeaways
Code that runs can still fail. The default AI output is technically complete but often misses the point.
AI has predictable blind spots in concurrency, security, and anything that only breaks at scale.
Taste is a builder skill. AI delivers functional. Making it worth using is on you.

Exercise: User testing the Clinic project
Put your build in front of a partner playing a patient or clinic admin — don't explain, don't help. Watch where they get confused, what they ignore, what they wanted that you never built. Write down three things you'd change and which lens each falls under.

What's next: Discernment for user experience.

動画字幕(重複除去済み)

[snorts] [music]

You've now built something with AI. It runs, the test pass, but so what? Think about the project we've been building. Did it handle a scenario where a patient's estimated wait time suddenly jumps from 10 minutes to 90? Did it account and solve for different patient needs? Did it build in historical biases from the existing data? A working product and a good product are not always the same thing. And when AI can produce a working product in minutes, your ability to tell the difference becomes the most valuable skill in the room. This module gives you a structure for that judgment. Five lenses and five questions to ask of anything that AI builds.

The first lens is functional integrity. Does it actually work? Bugs, errors, security holes. This is where most code review stops. It's necessary, but it's not close to sufficient. In our project example, AI built sound logic to display wait times, but did it account for patient priority? What about conflicting data points in determining which one to display? When building, consider the full gamut of functional tests, unit tests, integration tests, regression tests, edge cases, end-to-end. And here's a habit that matters. AI should be building tests alongside the code, not after it. When you prompt, ask it to write test cases in the very same pass. Then build in regular checkpoints. A test suite that hasn't been run is not a safety net, it's just a false sense of security.

The second lens is production readiness. Does it actually work well? Performance, scalability, reliability. What happens under load? What happens when hundreds of people try to refresh at the same time? AI has specific blind spots here. So, how do you verify this in your building process? A few concrete moves. Ask AI to stress test its own output. Have it generate production scenarios and check how the code handles them. Ask it explicitly, "What production assumptions does this code make?" You'll surface things that were missed in the first pass. In your project, did the code account for when the API call takes 5 seconds too long? Does the display freeze, show stale data, or fail gracefully? AI doesn't think about that. That's with you.

The third lens is problem fit. Is it the right thing? Does it solve the user's actual problem or the problem the user thinks they have? Those can diverge as you saw in the last lesson. The patient asked about wait times, and at face value AI can build an estimated wait time display. But what the patient really needed to know was if there was a pediatrician available in the next 20 minutes so they could assess if their child's fever is critical or not. AI solved the stated problem, but you need to check whether that's the real problem.

The fourth lens is experience quality. Is it actually good? Is the experience clear, intuitive, accessible? AI doesn't have taste, it has patterns. It will give you a competent interface that no one enjoys using. For a clinical wait time tool, that's not just an aesthetic problem, it's a patient safety issue. It's your job as the builder to notice this and translate it into something concrete and fixable. We'll talk more about experience discernment in the next lesson.

The fifth lens is responsible impact. Is it responsible? Bias, privacy, unintended consequences. Who could this harm? What does it assume about the user that might not be true? Let's look back at the clinical wait time tool. Is the algorithm estimating wait times trained on historical data? If that data reflects existing bias, systemic inequities contributing to longer wait times for certain demographics, the model may reproduce that same pattern. It won't flag it, it will just display a number. Build guardrails. Ask AI to name its bias as it builds. And most importantly, question all assumptions.

Most engineering education stops at the first two lenses, but builders need all five. And here's what you'll find when you start applying them. The biggest problems are almost never at lens one. AI is good at producing code that runs. It needs your oversight to produce a product that matters. One more thing. When you find something that isn't good enough, notice your own instinct. Do you reach in and fix it yourself, or do you go back and describe better what you needed? Neither is wrong, but the pattern tells you something about how you're working with AI, and whether you're building discernment or just building. All right, it's time to apply these lenses. Let's go.

↑ 目次へ戻る

AI Fluency for Builders | Lesson 7「Discernment for user experience」(全文ナレッジ)

テキストレッスン+埋め込み動画 2分(YouTube: jgcF2d0kW7U)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと — 所要時間目安: 45分

  • AI に何を作らせるかを指定するとき、階層(hierarchy)・ユーザーフロー・アクセシビリティ・フィードバックパターンを適用する
  • AI が生成したデザインを、行動につながる具体性を持ったフィードバックで批評する
  • スピード・磨き込み・ユーザーニーズの間で、意図的なトレードオフの意思決定をする

UX Lab: 4原則を適用する

インタラクティブ演習。フードデリバリー画面を題材に、AI がデフォルトで生みがちな UX 問題を hover → Show Fix で学ぶ構成。

  • Principle 1 CLARITY(明快さ) — すべての要素は、その目的を瞬時に伝えるべき。ボタンが何をするのか、フィールドが何を意味するのかをユーザーに推測させない。(例: App/⋮/Burger 12.00/Fries 4.50/Total 16.50/Submit という曖昧な画面)
  • Principle 2 HIERARCHY(階層)
  • Principle 3 ACCESSIBILITY(アクセシビリティ)
  • Principle 4 FEEDBACK(フィードバック)

Key takeaways

  • 実装が速くなったとき、差別化要因は体験になる。 デザインリテラシーはビルダーのコアスキル。
  • 「見た目を良くして(Make it look good)」は願望であって仕様ではない。 関数を記述するのと同じ精度で体験を記述する。
  • AI はデフォルトではアクセシビリティを正しくやらない。 明示的に指定し、返ってきたものを監査する。
  • 良い批評と、行動可能な AI 向け記述は、別のアーティファクト。 両者の間の翻訳を学ぶ。

演習: The Clinic Wait Time Project, Part 3

デザインスペック(ユーザーフロー・情報階層・インタラクションパターン)を書く → そのスペックに対して AI で再構築する → 批評する: AI がうまくやった箇所はどこか、「技術的には正しいが体験としては平板」な箇所はどこか。アクセシビリティ監査を実行し、AI が見落としたものを文書化する。

  • Clarity & Mental Model — クリニック管理者が認識できる言葉・パターンになっているか?
  • Information Hierarchy — 最も重要な情報が最初に来ているか?
  • Accessibility — 色コントラスト、スクリーンリーダー、キーボードナビゲーションは?
  • Feedback & Error Handling — 操作を認識したことを示すか、何かがうまくいかないとき何をすべきか説明するか?

次のレッスン

Stand behind what you build(自分の作ったものの後ろに立つ)。

実務ポイント(このレッスンから持ち帰るもの)

  • UX 4原則をスペックの定型項目にする: ①Clarity(要素の目的が瞬時に伝わる・ユーザーのメンタルモデルに合わせる)②Hierarchy と段階的開示(流し読みで見つかる・詰め込まない)③Accessibility(ベースラインであって nice-to-have ではない)④Feedback(操作への応答・ローディング状態・次の行動を示すエラーメッセージ)。
  • アクセシビリティは毎回・明示的に要求する。 スクリーンリーダー対応、色コントラスト、キーボードナビゲーションを AI に指示し、検証するテストケースまで作る。指定しなければ AI は入れてこない。
  • 願望を実行可能な記述へ翻訳する。 「見た目を良くして」ではなく「待ち時間をページで最大のテキストにする。ステータスは単一の色で示す。数値がどれだけ古いか患者に分かるよう更新時刻を可視化する」——この精度が「強い記述」。
  • Description × Discernment のループを回す: 体験を正確に記述 → AI が構築 → 意図と照らして評価 → ギャップを記述 → 繰り返す。
  • 批評と AI 指示は別物と心得る。 「ごちゃごちゃして見える」は同僚への批評としては妥当でも、AI への指示としては役に立たない。自分のセンス(taste)を実行可能な言葉に翻訳する力がデザインリテラシーの一部。
  • 意図的なトレードオフ: スピード・磨き込み・ユーザーニーズの間の選択は成り行きではなく意思決定として行う。

動画逐語(日本語訳)

(イントロ効果音・音楽)

>> 実装が速くなるほど、デザインとユーザー体験はますます重要になります。デザイナーになる必要はありません。しかし、良い体験を認識し、それを仕様として記述し、そこへ向けて反復していく必要はあります。指針となる原則をいくつか挙げましょう。

1つ目は明快さ(Clarity)です。あなたのプロダクトが何をするものか、どう始めればいいのかがユーザーに分からなければ、彼らは去ってしまいます。明快さとは、人々のメンタルモデルを尊重しながら、形態と機能を一致させることです。ユーザーは、他のソフトウェアと世界そのものによって形作られた期待を持ってやって来ます。シンプルに保ち、彼らが認識できる概念にインターフェースを対応させましょう。待ち時間を確認する患者は、それが他のあらゆるステータスチェッカーと同じように動くことを期待しています。

2つ目は階層と段階的開示(Hierarchy and progressive disclosure)です。人々が流し読みして、必要な情報を見つけやすくすること。圧倒しないこと。テキストのサイズとウェイトで良い見出しを作り、不要な要素を減らし、すべてを1つの場所に詰め込むのではなく、必要になったときに必要な情報を見つけられるようにします。

3つ目、アクセシビリティは「あれば嬉しいもの」ではなく、ベースラインです。スクリーンリーダー互換性、色コントラスト、キーボードナビゲーション——これらは毎回必ず AI に明示的に要求し、検証するためのテストケースを作るべきです。

4つ目はフィードバックと応答性です。ユーザーが何かをしたら、インターフェースはそれを認識したことを示すべきです。何かが壊れているのではないかとユーザーに疑わせてはいけません。ローディング状態、確認表示、そして次に何をすべきかを説明するエラーメッセージ——すべてシンプルで人間的な言葉で——が、信頼を築く助けになります。

「見た目を良くすること」と「良い体験」の間の溝は、途方もなく大きい。「見た目を良くして」は願望です。「待ち時間をページで最大のテキストにする。ステータスは単一の色で示す。数値がどれだけ古いか患者に分かるよう、更新時刻を可視化する」——これは行動可能な、強い記述です。これは Description と Discernment が一緒に働いている状態です。あなたが体験を正確に記述し、AI がそれを作る。返ってきたものを、意図したものと照らして評価する。ギャップを記述する。繰り返す。

演習の中で気づくことがあるはずです。同僚に渡すであろう批評と、AI が必要とする記述は、同じドキュメントではありません。「これはごちゃごちゃして見える」は妥当な批評ですが、AI への指示としては役に立ちません。デザインリテラシーの一部は、自分自身のセンスを、実行可能なものへ翻訳する方法を学ぶことなのです。さあ、実践に移しましょう。

英語原文

レッスン本文

[YouTube: jgcF2d0kW7U (2 min)] Discernment for user experience

What you'll learn — Estimated time: 45 minutes
Apply hierarchy, user flows, accessibility, and feedback patterns when specifying what AI should build
Critique AI-generated designs using feedback specific enough to act on
Make intentional tradeoff decisions between speed, polish, and user needs

UX Lab: Apply the four principles(インタラクティブ・フードデリバリー画面でAIがデフォルトで生む UX 問題を hover→Show Fix で学ぶ)
Principle 1 CLARITY — Every element should instantly communicate its purpose. Users shouldn't have to guess what a button does or what a field means.(例: App/⋮/Burger 12.00/Fries 4.50/Total 16.50/Submit という曖昧画面)
Principle 2 HIERARCHY / Principle 3 ACCESSIBILITY / Principle 4 FEEDBACK

Key takeaways
When implementation is fast, experience is the differentiator. Design literacy is a core builder skill.
"Make it look good" is a wish, not a spec. Describe experience with the same precision as a function.
AI does not get accessibility right by default. Specify it, then audit what you get back.
A good critique and an actionable AI description are different artifacts. Learn to translate between them.

Exercise: The Clinic Wait Time Project, Part 3
Write a design spec (user flows, information hierarchy, interaction patterns) → rebuild with AI against that spec → critique: where did AI nail it, where technically correct but experientially flat? Run accessibility audit, document what AI missed.
- Clarity & Mental Model — language/patterns a clinic admin would recognize?
- Information Hierarchy — most important info first?
- Accessibility — color contrast, screen reader, keyboard navigation?
- Feedback & Error Handling — acknowledges actions, explains what to do when something goes wrong?

What's next: Stand behind what you build.

動画字幕(重複除去済み)

[snorts] [music]

As implementation gets faster, design and user experience become even more important. You don't need to become a designer, but you do need to recognize good experience, spec for it, and iterate towards it. A few principles here to guide you.

One is clarity. If users can't tell what your product does or how to get started, they're gone. Clarity means unifying form and function while respecting people's mental models. Users arrive with expectations shaped by other software and by the world. Keep it simple and map your interface to concepts they recognize. A patient checking wait times expects it to work like every other status checker.

Two is hierarchy and progressive disclosure. Make it easy for people to scan and find the information that is needed. Don't overwhelm them. Use text size and weight to create good headers, minify the amount of unneeded elements, and allow people to find the information they need as they need it instead of cramming it all into one space.

Three, accessibility is a baseline, not a nice to have. Screen reader compatibility, color contrast, keyboard navigation, you should ask the AI for these explicitly every single time and build test cases to validate.

Four, feedback and responsiveness. When the user does something, the interface should acknowledge it, not lead the user to question if something might be broken. Loading states, confirmations, and error messages that explain what to do next, all in simple human language, help build trust.

The gap between making it look good and a good experience is enormous. Make it look good is a wish. Put the wait time in the largest text on the page, use a single color to indicate status, and make the refresh time visible so the patient knows how stale the number is is an actionable strong description. This is description and discernment working together. You describe the experience precisely, AI builds it. You evaluate what comes back against what you intended. You describe the gap, repeat.

One thing you'll notice in the exercises, the critique that you'd give a colleague and the description AI needs are not the same document. "This feels cluttered" is a fair critique, but it's useless instruction for AI. Part of design literacy is learning how to translate your own taste into something that is executable. Let's put it to work.

↑ 目次へ戻る

AI Fluency for Builders | Lesson 8「Stand behind what you build」(全文ナレッジ)

テキストレッスン+埋め込み動画 3分(YouTube: wrgLtG-IHKk)/ 2026-07-03 副題: Diligence & sharing your work

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと — 所要時間目安: 45分

  • AI が構築を手伝ったものを出荷(ship)するとき、自分が何を所有(own)するのかを言語化する
  • 出荷時に表面化する技術的リアリティを特定し、それを捕まえるフィードバックループを構築する
  • 判断を下す: 出荷するか(ship it)、直すか(fix it)、止めるか(stop it)

Key takeaways

  • あなたが所有するのはアウトカム(結果)であって、アウトプット(出力)ではない。 「AI が書いた」は何の説明にもならないし、何の言い訳にもならない。
  • 出荷には固有の技術語彙がある(マイグレーション、バージョニング、レートリミット、フィーチャーフラグ)。AI はこちらから聞かない限りそれを表に出さない。
  • テストがローンチ後の反復を安全にする。 テストファーストの習慣こそ、自信を持って変更し続けられる理由。
  • プロトタイプは自由に、出荷は選択的に(Prototype freely, ship selectively)。 安価になったコードは、正直な評価と組み合わさって初めて価値を生む。
  • アクセスはデザイン上の意思決定。 「出荷した」と言う前に、自分の仮定が誰を排除しているかを確認する。

演習: Ship the Clinic app(デプロイ前に正直に答える)

  • Understanding(理解) — 自分のコードが「何をするはずか」ではなく「何をするか」を説明できるか?
  • Testing(テスト) — 受け入れテストは今も通るか? エッジケース——クリニックの休診、データ欠損、待ち時間ゼロ——は?
  • Access(アクセス) — 自分のビルドがうまく仕えられないのは誰か?
  • Responsibility(責任) — この出力は誤読・誤用されうるか? AI の役割について透明か?
  • Feedback loop(フィードバックループ) — 出荷後、機能しているかどうかをどうやって知るか?

その後: デプロイするかプロトタイプとしてホスト → 実在ユーザー3人に共有 → 学びに基づく1回の反復(変更をテストで検証すること)。

次のレッスン

Closure & looking forward(締めくくりとこれから)。

実務ポイント(このレッスンから持ち帰るもの)

  • 「AI が書いた」を説明にも言い訳にもしない。 所有するのは出力ではなくアウトカム。AI で作ると「自分が書いていないコードのオーナー」になる——diligence とは自分のコードに追いつくこと(理解する・負荷をかける・テストする・見落としを拾う仕組みを置く)。
  • Martina(Anthropic エンジニア)の3習慣を移植する: ①暗黙の判断を意図的に表面化させる——エッジケースが浮かんだら即座に「ユーザーが他ユーザーのファイルを見られないこと、再確認して」と聞く。大きな構築の後は「どんな仮定とトレードオフを置いた? 知っておくべきセキュリティリスクは?」 ②PR の説明文に AI の関与を「免責ではなく情報として」明記する——AI は人間と違う形の間違い(廃止 API を自信満々に使う/局所的にきれいだがコードベースと不整合/未指定ケースの挙動の創作)をするので、それを知るレビュアーはレビューを適切に調整できる。 ③理解を独立したステップとして実施する——動くが理解していないコードは、Claude に辛抱強く説明させることでループに戻れる。
  • 出荷の語彙を自分から聞く。 マイグレーション、バージョニング、レートリミット、フィーチャーフラグ——AI は聞かれない限り出してこない。
  • AI 以前のベストプラクティスは AI 以後こそ効く。 より速く出荷し、出荷物の理解率が下がっている今、テスト(挙動を固定し恐れず反復)・可観測性(ログ/エラートラッキング/ダッシュボード——ユーザーのメールではなく自分のデータで知る)・フィーチャーフラグ(すり抜けたときの安全弁)が「速く安全に動く」を可能にする。
  • 出荷前チェック5問(Understanding/Testing/Access/Responsibility/Feedback loop)をデプロイ前の定型ゲートにする。
  • 実在ユーザー3人 → 1反復、変更は必ずテストで検証。プロトタイプは自由に、出荷は選択的に。

動画逐語(日本語訳)

こんにちは。Martina といいます。Anthropic のエンジニアです。このコースを通じて、あなたは委譲し(delegate)、記述し(describe)、識別して(discern)きました。手元には動くクリニックアプリがあります。もうすぐ出荷のときです。4D フレームワークにおいて、diligence(ディリジェンス)とは、AI と一緒に作ったものに責任を持つことを意味します。要するに、あなたの AI 利用が透明で、倫理的で、説明責任を果たせるものであることを確かめることです。これには、AI 利用について透明であり、それを開示すること。AI が生み出した出力のオーナーシップを取ること。出荷する前に成果物を検証すること。作ったものが他者に与える影響を考えること。そして、あなたの組織や業界で AI 利用を律するポリシー、プライバシー、職業上の基準を守ることが含まれます。

何を大切にすべきかをお説教する代わりに、エンジニアとしての私の日常の中で、diligence がどんな姿をしているかをお見せします。AI を使うと、自分が書いていないコードのオーナーになってしまうことがあります。diligence とは、自分自身のコードに追いつく方法です。それを理解し、負荷をかけ、テストし、自分の見落としを捕まえる仕組みを整えること。私の場合、それは3つの習慣に集約されます。

自分でコードを書いていると、書き進めるうちに、考えていなかったことが見えてきます。何かのエッジケース、決める必要があると気づいてすらいなかった判断。AI と作っていると、それらがあなたに提示されることのないまま、決められてしまうことがあります。だから私は、そのステップを意図的に再現するようにしています。疑問を表に引っ張り出して、自分が実際に関与できる場所に置くのです。エッジケースが頭に浮かんだら、モデルにそのまま言います。「ユーザーが他のユーザーのファイルを見られないこと、ダブルチェックしてくれる?」と。Claude が大きなものを作った後には、率直に尋ねます。「どんな仮定とトレードオフを置いた? 私が知っておくべきセキュリティリスクは?」。これで、重要な判断のループに自分が入っていることを確かめられます。

Claude がプルリクエストの大部分を書いたときは、説明文に必ずそう書きます。免責事項としてではなく、情報として。これが重要なのは、AI は人間とは違う形の間違いをするからです。廃止された API を自信満々に使う。局所的にはきれいなのにコードベースとは一貫しないコード。指定していないケースについての、創作された挙動。それを知っているレビュアーは、レビューをより適切に調整できます。

AI が構築を担うと、自分の力量を超えたところにいる感覚になりがちです。理解していない動くコードを抱えることになりえます。これは以前なら本当は起こりえなかったことです。でも、理解できないわけではありません。理解が独立したステップになっただけです。そしてそれも AI が手伝えます。Claude は喜んであなたに付き合い、辛抱強く説明してくれます。少し時間はかかりますが、それがあなたをループの中に戻してくれるのです。

肝心なのはここです。AI 以前に存在していたエンジニアリングのベストプラクティスは、AI 以後もそのまま適用されます。むしろ、以前にも増して、です。なぜなら今のあなたは、より速く出荷し、出荷したもののうち理解している割合はより小さくなっているのですから。テストは、このスピードで動きながら何かを壊さないための、依然として最も簡単な方法です。堅牢なテストスイートは、あなたが大切にしている挙動を固定してくれます。だから恐れずに反復し続けられる。可観測性(オブザーバビリティ)もどこへも行っていません。実際のユーザーが触って初めて現れるものがあります。だからログ、エラートラッキング、ダッシュボードが欲しい。ユーザーからのメールではなく、自分自身のデータから知るのです。そしてフィーチャーフラグは、何かがすり抜けてしまったときのために、今も有用です。こうしたセーフティネットを整えておくことこそが、速く、かつ安全に動くことを可能にします。

検証、透明性、理解。片側にテスト、反対側に可観測性。どれも、エンジニアリングにおいて新しいものではありません。AI は、そこへ到達するための、あなたの新しい道具のひとつに過ぎないのです。

英語原文

レッスン本文

[YouTube: wrgLtG-IHKk (3 min)] Stand behind what you build(Diligence & sharing your work)

What you'll learn — Estimated time: 45 minutes
Articulate what you own when you ship something AI helped build
Identify the technical realities that surface at ship time and build feedback loops that catch them
Make the call: ship it, fix it, or stop it

Key takeaways
You own the outcome, not the output. "AI wrote it" explains nothing and excuses nothing.
Shipping has its own technical vocabulary (migrations, versioning, rate limits, feature flags) that AI will not surface unless you ask.
Tests make post-launch iteration safe. The test-first habit is why you can keep changing things confidently.
Prototype freely, ship selectively. Cheap code creates value only when paired with honest evaluation.
Access is a design decision. Check who your assumptions exclude before you call something shipped.

Exercise: Ship the Clinic app(デプロイ前に正直に答える)
- Understanding — Can you explain what your code does, not just what it should do?
- Testing — Do acceptance tests still pass? Edge cases — closed clinic, missing data, zero wait time?
- Access — Who does your build not serve well?
- Responsibility — Could this output be misread or misused? Transparent about AI's role?
- Feedback loop — How will you know if it's working after it ships?
Then: deploy or host as prototype → share with three real users → one iteration based on learning, with tests verifying the change.

What's next: Closure & looking forward.

動画字幕(重複除去済み)

Hi there. My name is Martina and I'm an engineer at Anthropic. Throughout this course you've delegated, described, and discerned. You have a clinic app that works. It's almost time to ship it. In the 4D framework, diligence means taking responsibility for what you build with AI. Essentially, making sure your use of AI is transparent, ethical, and accountable. This includes being transparent about your AI use and disclosing it, taking ownership of the outputs that AI creates, verifying work before you ship, considering the impact of what you built on others, and honoring policies, privacy, and professional standards that govern AI use in your organization or industry.

Rather than tell you what to value, I'm going to show you what diligence looks like in my day-to-day as an engineer. With AI, you can end up being the owner of code you didn't write. Diligence is how you catch up to your own code, understand it, stress it, test it, and put the systems in place that catch what you miss. For me, that comes down to three habits.

When you're writing code yourself, it becomes apparent as you go that there are things you hadn't thought of. Some edge case, some decision you hadn't realized needed to be made. With AI, sometimes those end up getting decided without ever being surfaced to you. So, I try to recreate that step on purpose. Get those questions out in the open where I can actually weigh in. When an edge case pops into my head, I'll just say to the model, like, "Can you double-check that users can't view other users' files?" After Claude builds something substantial, I ask directly, "What assumptions and trade-offs did you make? What security risks should I be aware of?" That ensures that you're looped in on the important decisions.

When Claude writes most of a pull request, I make sure to say so in the description. Not as a disclaimer, as information. This is relevant because AI makes a different shape of mistake than humans do. Deprecated APIs used confidently, code that's locally clean but inconsistent with the code base, invented behavior for cases you never specified. A reviewer who knows that can better tailor their review.

It's easy to feel out of your depth when AI does the building. You can end up with working code you don't understand, which wasn't really possible before. But it's not that you can't understand it. It's just a separate step now, and AI can help with that, too. Claude is more than happy to sit with you and patiently explain. It takes a bit of time, but that's what puts you back in the loop.

Here's the thing. The engineering best practices that existed before AI still apply after. Maybe even more so, because now you're shipping faster and you understand a smaller fraction of what you shipped. Tests are still the easiest way to make sure you don't break something while moving this fast. A solid test suite pins down the behavior you care about, so you can keep iterating without fear. Observability hasn't gone anywhere, either. Some things only show up when real users have it, so you want logs, error tracking, dashboards. You find out from your own data, not from a user email. And feature flags remain useful for when something does slip through. Having these safety nets in place is what lets you move fast safely.

Verification, transparency, understanding. Tests on one end, observability on the other. None of this is new to engineering. AI is just a new tool under your belt to get there.

↑ 目次へ戻る

AI Fluency for Builders | Lesson 9「Closure & looking forward」(全文ナレッジ)

テキストレッスン+埋め込み動画 4分(YouTube: 7pFhV_i2KDI)/ 2026-07-03

日本語ナレッジ(レッスン本文・完全版)

このレッスンで学ぶこと — 所要時間目安: 15分

  • コース修了後も AI フルエンシーを磨き続けるためのリソースを見つける
  • 4D フレームワークから利益を得られそうな同僚に、学んだことを共有する
  • 修了証(certificate of completion)を受け取る

Key takeaways

  • AI が最も強いのはツールキットの中央。 実装(implementation)は自由に委譲する。共感(empathy)・判断(judgment)・出荷(shipping)は自分の手に残す。
  • 堅牢な記述(robust description)とはチェーン全体をたどること: ユーザーの声 → 要求(requirement)→ スペック → AI への指示 → テスト。どのリンクの失敗も下流へカスケードする。
  • プロトタイプは自由に、出荷は選択的に。 証拠が「機能していない」と示すなら、自分が作ったものにも拒否権(veto)を発動する意思を持つ。
  • 出荷前に識別(discernment)を適用する。 AI の出力はしばしば「動くか?」は通るが「正しいものか?」でつまずく。そのギャップこそ、あなたの判断が最も重要になる場所。
  • 4D は動的であって、順番(シーケンス)ではない。 構築しながら4つの間を流動的に行き来することが、実践におけるフルエンシーの姿。

演習: Your next build(今週、実在のタスク1つを 4D で)

良い候補: ずっと先送りしてきた機能リクエスト/まだ統合(シンセサイズ)していないユーザーリサーチ/作業前に必要な技術スペック/触るのが不安なコードベースの未テスト部分

4つすべてを通す:

  • Delegation — どの段階なら安全に委譲できるか? どこに自分の判断が必要か?
  • Description — チェーン全体を書く: ユーザーニーズ → 要求 → スペック → AI 指示 → テスト。
  • Discernment — 出力を5つのレンズすべてで評価する。
  • Diligence — これが何をするか理解しているか? フィードバックループはあるか? 自分はこれの後ろに立てる(stand behind)か?

次のステップ

短いアセスメント(quiz)→ 修了証。

実務ポイント(このレッスンから持ち帰るもの)

  • 最終課題を実行する: 今週、実在のタスクを1つ選んで 4D をフルに通す(先送り中の機能/未統合のユーザーフィードバック/必要な技術スペック/怖くて触れない未テスト箇所が好候補)。
  • 委譲の線引きを毎回引き直す: ラップトップを開く前に問題を分解する。実装・足場・ボイラープレート・初稿・スペック=AI の有力候補。判断・ユーザー理解・「作ったものは正しいものか」の決断=あなたのもの。ビルダーの6道具(共感・デザイン・アーキテクチャ・実装・判断・出荷)のうち、AI は中央(実装とアーキテクチャの一部)が最強、両端が最弱。
  • プロンプトの前に Description Chain を書く: ユーザーの声 → プロダクト要求 → 技術スペック → AI 指示 → テスト。「完成(done)」の姿と、成功のテストが何を測るかを先に明確に。明確な受け入れ基準つきのタスクを渡すことは、AI を「明確なブリーフを持つ有能なジュニア協働者」として扱うこと。
  • 識別の5問を作業中ずっと回す: 動くか? うまく動くか? 正しいものか? 良いものか? 責任あるものか? 「記述したものは作ったが、問題を解決するものではない」「動くが誰も使いたくない」を見つけ出す。
  • 出荷前の diligence 3問: これが何をするか理解しているか? 説明できるか? 機能しているかを知る方法はあるか? そして、沈んだ労力に抗って自作物への拒否権を保つ——ビルダーの仕事はソフトウェアを守ることではなく、ユーザーに仕えること。
  • リソース活用: コースのリソースセクションにあるブループリント(技術スペックの書き方〜AI 支援の build-measure-learn サイクル)を出発点にして自分用に調整する。学びをネットワークのビルダーと共有し、チームでのフルエンシー像の会話を始める。
  • 今後数年で最も面白いことをするビルダーは「最も多く自動化する人」ではなく、「いつ委譲していつループに留まるかを知っている人」「コンパイルが通るだけでは出荷しない程度にユーザーを大切に思う人」。

動画逐語(日本語訳)

(イントロ効果音・音楽)

>> 再び、Anthropic 教育チームの Kristen です。

>> そして私は Chris、CodePath のチーフプロダクトオフィサーです。最終レッスンまでたどり着きましたね。ここからは、この次に何が起こるかを話しましょう。構築するとき、AI フルエンシーをどう仕事に活かすか、です。あなたには現実の仕事が待っています。ユーザーが3か月前からリクエストし続けている機能かもしれません。いつか本物にしようと思っていたプロトタイプかもしれません。あるいは、統合する時間がないままスプレッドシートに積み上がっている、あのユーザーフィードバックの山かもしれません。そこで最終課題です。そのうちのひとつを選び、このコースで学んだことを使って、今週、AI の支援を受けながら取り組んでください。

>> Delegation(委譲)から始めましょう。ラップトップを開く前にまず、実際に目の前にあるものについて考えます。問題を分解する。この仕事のどの部分が、本当に AI の恩恵を受けるのか? 実装、足場づくり(スキャフォールディング)、ボイラープレート、初稿やスペック——これらは強い候補です。では、どの部分にあなたが必要か? 判断を要する決定。あなたのユーザーが実際には誰で、何に苦しんでいるかもしれないのかという理解。作ったものが本当に「正しいもの」なのかどうかの決断。それらはあなたに属します。ビルダーのツールキットを思い出してください。あなたには6つの道具があります。共感、デザイン、アーキテクチャ、実装、判断、そして出荷です。AI が最も強いのは中央——実装と、アーキテクチャの一部。最も弱いのは両端です。AI はあなたのユーザーが感じていることを感じられません。出荷したものが本当に違いを生んだのかどうかを見分けられません。それはあなたの仕事です。

委譲の判断を下したら、Description(記述)へ移ります。これは「何をコーディングするか」よりはるかに多くを含みます。ユーザーの声からプロダクト要求へ、技術スペックへ、AI への指示へ、そしてテストへ——そのすべてです。だからプロンプトを1つ書く前に、どんな問題を、誰のために解こうとしているのかを明確にしてください。「完成」とはどんな姿か? 成功のテストは実際に何を測るのか? 明確な受け入れ基準のついた、よく記述されたタスクを AI に与えるとき、あなたは AI を「明確なブリーフを持つ有能なジュニアの協働者」として扱っているのです。

そしてもちろん、作業を進めながら Discernment(識別)を適用します。動くか? うまく動くか? 正しいものか? 良いものか? 責任あるものか? AI は時に、あなたが記述したものは作っても、問題を解決するものは作りません。あるいは動くものは作っても、人々が使いたいと思わないものだったりします。それを見つけ出してください。

最後に、Diligence(ディリジェンス)を実践します。プロトタイプは自由に。それが学ぶ方法です。しかし出荷は選択的に。何かがユーザーに届く前に、問うてください。「これが何をするのか、自分は理解しているか? 説明できるか? そして、機能しているかどうかを知る方法はあるか?」。そしてもちろん、証拠が「うまくいっていない」と告げるなら、自分が作ったものに拒否権を発動する意思を持つこと。沈んだ労力(サンクコスト)は、手放すのが最も難しいもののひとつです。しかしビルダーの仕事はソフトウェアを守ることではありません。ユーザーに仕えることです。

4つの D は動的です。委譲から記述へ進み、識別へ戻り、そして委譲の仕方を変えたくなる。それこそが、実践を通じてあなたの AI フルエンシーが育っているということです。

>> 下のリソースセクションには、技術スペックの書き方から、AI 支援によるビルド・計測・学習(build-measure-learn)サイクルの組み立て方まで、ビルダーの定番タスクをカバーするブループリントが用意されています。これらを出発点として使い、自分のニーズに合わせて調整してください。そして、学んだことを振り返ってください。短いクイズを受けて、修了証を獲得することもできます。それは、あなたのネットワークにいる他のビルダーたちと共有して、「チームにおけるこの種のフルエンシーとはどんな姿か」という会話を始めるためのものでもあります。コースの修了、おめでとうございます。この先数年、AI で最も面白いことをするビルダーは、最も多くを自動化する人たちではありません。いつ委譲し、いつループの中に留まるべきかを知っている人たちです。コンパイルが通るからという理由だけで出荷したりしない程度に、自分のユーザーを大切に思う人たちです。それがあなたです。さあ、素晴らしいものを作りに行きましょう。

英語原文

レッスン本文

[YouTube: 7pFhV_i2KDI (4 min)] Closure & looking forward

What you'll learn — Estimated time: 15 minutes
Find resources to continue building your AI fluency after this course
Share what you learned with colleagues who could benefit from the 4D Framework
Collect your certificate of completion

Key takeaways
AI is strongest in the middle of the toolkit. Delegate implementation freely. Keep empathy, judgment, and shipping in your hands.
Robust description means following the full chain: user voice to requirement to spec to AI instruction to tests. A failure at any link cascades downstream.
Prototype freely, ship selectively. Be willing to veto something you built when the evidence says it is not working.
Apply discernment before shipping. AI output often passes "Does it work?" but stumbles on "Is it the right thing?" Those gaps are where your judgment matters most.
The 4Ds are dynamic, not a sequence. Moving fluidly between them as you build is what fluency looks like in practice.

Exercise: Your next build(今週、実在のタスク1つを4Dで)
Good candidates: a feature request you've been putting off / user research not yet synthesized / a technical spec needed before work / untested part of codebase you're nervous to touch
Work through all four:
Delegation — Which stages are safe to delegate? Which require your judgment?
Description — Write the full chain: user need → requirement → spec → AI instruction → tests.
Discernment — Evaluate output through all five lenses.
Diligence — Do I understand what this does? Is there a feedback loop? Would I stand behind it?

What's next: short assessment → certificate.

動画字幕(重複除去済み)

[snorts] [music]

Kristen again from the education team at Anthropic.

And I'm Chris, the chief product officer at CodePath. You've made it to the final lesson. Now let's talk about what happens next. The ways you can put AI fluency to work when you build. You have real work waiting for you. Maybe it's a feature that users have been requesting for 3 months. Maybe it's a prototype you've been meaning to turn into something real. Or maybe it's that pile of user feedback sitting in a spreadsheet that you haven't had time to synthesize. So here's your final assignment. Pick one of those things and use what you've learned in this course to tackle it with AI support this week.

Start with delegation. Before you even open your laptop, think about what's actually in front of you. Break the problem down. What parts of this work genuinely benefit from AI? Implementation, scaffolding, boilerplate, first drafts and specs, these are strong candidates. But what parts need you? The judgment calls. The understanding of who your user actually is and what they might be struggling with. The decision about whether the thing you built is actually the right thing. Those belong to you. Remember the builder's toolkit. You have six instruments: empathy, design, architecture, implementation, judgment, and shipping. AI is strongest in the middle at implementation and parts of architecture. It's weakest at the edges. It can't feel what your user feels. It can't tell whether what you shipped actually made a difference. That's your job.

Once you've made your delegation decisions, move into description. This includes so much more than just what to code. It includes everything from user voice to product requirement to technical spec to AI instruction to tests. So before you write a single prompt, be clear about what problem you're solving and for whom. What does done look like? What would a test for success actually measure? When you give AI a well-described task with clear acceptance criteria, you're treating it like a capable junior collaborator with a clear brief.

And of course, as you work, apply discernment. Does it work? Does it work well? Is it the right thing? Is it good? Is it responsible? Sometimes AI builds the thing you describe, but not the thing that solves the problem. Or it builds the thing that works, but one that people don't want to use. Find that out.

Finally, practice diligence. Prototype freely. That's how you learn. But ship selectively. Before anything goes to users, ask, "Do I understand what this does? Can I explain it? And is there a way to know if it's working?" And of course, be willing to veto something you built when the evidence says it isn't working. Sunk effort is one of the hardest things to walk away from. But the builder's job isn't to defend the software. It's to serve the user.

The four D's are dynamic. You'll move from delegation to description, back to discernment, and realize you want to delegate differently. That's your AI fluency developing through practice.

In the resources section below, you'll find blueprints covering common builder tasks, from writing technical specs to structuring a build-measure-learn cycle with AI assistance. Use these as your starting points. Adapt them to your needs. And then reflect on what you learned. You can also take a short quiz to earn your certificate of completion. Now that's something we're sharing with your other builders in your network to start a conversation about what this kind of fluency looks like on a team. Congratulations on completing this course. The builders who will do the most interesting things with AI in the next few years aren't the ones who automate the most. It's the ones who know when to delegate and when to stay in the loop. These are the ones who care enough about their users to not just ship something because it compiles. That's who you are. Now go build something great.

↑ 目次へ戻る