CCAO-F TEXTBOOK · 全7ドメイン対応
CCAO-F教科書
claude.aiを業務で使いこなすための実務知識と、CCAO-F資格(Claude Certified Associate Operator - Foundation)の試験対策を1ページにまとめた教科書。第1〜3課は暗記が必要な3ドメインの詳解、第4〜7課は残り4ドメインの「試験での正解の癖」要点集、第8〜9課は製品運用と実戦論点の増補章。課ごとに順に読み、各課末の確認テスト(タップで答えが開く)で自己チェックしながら進めるとよい。
第1課
製品とモデル選択 配点12% · Domain 3
出題目標(ブループリントより)
適切な製品機能(Projects・リサーチモード・チャット・Artifacts)を選ぶ モデル(Haiku・Sonnet・Opus)の違いを説明できる タスク要件(コスト・速度・品質)に合わせてモデルを選ぶ コンテキスト制限とメモリの管理 1-1. モデル3兄弟の使い分け——「タスク要件と揃える」が全て
モデル 性格 選ぶべき場面(試験の言い回し) Haiku 最速・最安 straightforward / high-volume / speed and cost matter(単純・大量・速度優先)。分類、定型応答、抽出 Sonnet 速度と賢さのバランス 日常業務の既定値。ほとんどの実務タスク Opus 最高性能・高コスト complex reasoning(複雑な推論)、高度な分析、難しい設計判断
出題パターン: 正解は常に「要件に合わせる(align with task requirements)」。「常に最上位モデル」「常に最安」はどちらも不正解の選択肢として出る。大量の単純作業にOpus=コストと遅延の無駄、が定番のひっかけ。
1-2. 製品機能の使い分け
機能 何のためか 選ぶ場面 Chat 単発の対話 一度きりの質問・下書き Projects 継続する仕事の入れ物 同じ文脈・資料を繰り返し使う仕事(→第2課) Artifacts 再利用できる成果物 編集・共有・エクスポートされる文書、表、コード Research mode Web情報を集めた深い調査 出典付きの調査レポートが必要なとき
1-3. プラン(claude.com公式・2026年8月時点)
プラン 価格 覚えるべき差分 Free $0 基本チャット。Projectsは5個まで Pro $17/月(年払)〜$20/月 利用量増・複数モデル選択・Claude Code等 Max $100/月〜 Proの5倍/20倍の利用量・混雑時の優先アクセス Team $20〜100/席/月(2〜150人) SSO・監査ログ・SCIM・プロジェクト共有 Enterprise 要相談 ロールベースアクセス制御・IP許可リスト・データ保持設定・HIPAA対応
出題パターン: 「組織でSSOと監査ログが必要」→Team以上。「規制業種で保持期間や細かい権限管理」→Enterprise。個人の高頻度利用→Max。金額の暗記より「どの要件がどの層で解禁されるか」を覚える。
1-4. コンテキスト管理——いつ再開・要約・永続化するか
会話が長引いて劣化 (序盤を忘れる・質が落ちる)→ 要約させて新しい会話に引き継ぐ (restart + summarize)毎回同じ文脈を貼っている → Projectsの知識・指示に永続化 (persist)1回の依頼が大きすぎる → タスク分解して段階的に
試験に出る英語
context window 一度に扱える文脈の上限
align A with B AをBに合わせる(モデル選択の頻出動詞)
trade-off コストと品質などの両立できない関係
latency 応答の遅さ
確認テスト 1-1: 月5万件のレビューを「ポジ/ネガ」に分類したい。モデルは? Haiku。 単純(2値分類)・大量(5万件)・深い推論不要。要件(速度・コスト)とモデルを揃える。
確認テスト 1-2: 「会話が長くなってClaudeが最初の指示を忘れる」への正しい一手は? 要点を要約させて新しい会話へ引き継ぐ。 同じ会話で繰り返し指示し直す・大文字で強調する、は不正解の定番選択肢。
確認テスト 1-3: 150人の会社がSSOと監査ログ必須でClaudeを導入する。最低限どのプラン? Team。 SSO・監査ログ・SCIMはTeamから。さらにIP許可リストやカスタムデータ保持が要件ならEnterprise。
第2課
設定と知識管理(Projects) 配点12% · Domain 5
出題目標(ブループリントより)
Projectsに指示と知識ソースを設定する アップロード知識とコネクタ(Google Drive・Gmail等)を管理する 効果的なシステムレベル指示を作成する 設定・知識・指示を維持・更新する 2-1. Projectの3点セット
部品 役割 例(小売店の場合) Knowledge(知識) アップロードした文書・コード等。プロジェクト内の全会話が参照する 買取基準表、接客マニュアル Instructions(指示) トーン・役割・応答形式の指定。全会話に自動適用 「査定士として、店の基準表に基づき、断定を避けて回答」 Chats(会話履歴) プロジェクト専用の会話置き場 日々の査定相談ログ
最頻出パターン: 「毎回同じ資料・指示を貼り付けている」→Projectを作って知識+指示に昇格させる が正解。「メモ帳から速く貼る」「Claudeに自動で覚えさせる」は不正解の定番。
⚠3層モデル(頻出): Projectは①共有層 (指示+知識=全チャットが使える)②スレッド層 (個々のチャット——あるチャットの議論・決定は他のチャットに自動共有されない 。知識ベースに足して初めて共有される)③ラベル層 (名前と説明欄——Claudeには一切見えない 整理用)。「説明欄に書けば読まれる」「前のチャットで言ったから伝わる」はどちらも定番のひっかけ。
2-2. 知識の仕組みと容量(公式ヘルプより)
知識が上限に近づくと、有料プランではRAG(検索拡張) に自動で切り替わり、関連部分だけを取り出す方式で容量が最大10倍 に拡張される
FreeプランはProjects 5個まで 。RAG拡張は有料プラン(Pro/Max/Team/Enterprise)
コネクタ (Google Drive・Gmail等)で外部データに接続できる。コネクタはプライベートなプロジェクトのみ
2-3. 共有と権限(Team/Enterpriseのみ)
Can view : 閲覧+そのプロジェクト内でチャットできるCan edit : 知識・指示の編集と管理もできる共有すると全員が同じ知識・指示の恩恵を受ける=チームの文脈の一元化
2-4. 維持・更新——「作って終わり」は不正解
出題パターン: 「Projectの回答が古い情報を返すようになった」→知識ソースを最新版に差し替える/古い文書を削除する が正解。知識は自動更新されない。価格表・ポリシー等、鮮度が命の文書ほど更新当番を決める、が運用の模範解答。
試験に出る英語
knowledge base プロジェクトの知識置き場
project instructions プロジェクト単位の常時指示
connector 外部サービス接続(Drive/Gmail等)
retrieval (RAG) 必要な部分だけ検索して取り込む方式
stale / outdated 古くなった(知識更新問題の合図)
確認テスト 2-1: InstructionsとKnowledgeの違いを一言で? Instructionsは「どう振る舞うか」、Knowledgeは「何を知っているか」。 トーン・役割・形式はInstructions、参照すべき資料・データはKnowledge。
確認テスト 2-2: 知識ベースが容量上限に近づいたら何が起きる?(有料プラン) RAGモードに自動で切り替わり 、全文を読み込む代わりに関連箇所だけ検索して使う。これで実効容量が最大10倍に。
確認テスト 2-3: 共有プロジェクトで、メンバーに「使わせたいが設定は触らせたくない」。付与する権限は? Can view。 閲覧+チャット利用は可、知識・指示の編集は不可。編集・管理まで任せるならCan edit。
第3課
ガバナンス・リスク・責任ある利用 配点15% · Domain 6
出題目標(ブループリントより)
適切/不適切なユースケースを見分ける データ機密性・規制・プライバシーの考慮を適用する 組織のAIポリシー・ガバナンス基準に従う AI利用の倫理的含意を理解する 3-1. データ機密性——最頻出の型
黄金律: 規制対象の個人データ(氏名・口座・健康情報など)は匿名化(anonymize)・削除(redact)してから 使う。
3-2. Usage Policy(Anthropic公式利用ポリシー)の要点
絶対禁止: 違法行為、兵器開発、重要インフラへの攻撃、児童保護侵害、詐欺(フィッシング・偽造)、選挙妨害、規約回避のための複数アカウント高リスク用途(法律・医療・金融・保険・採用・学位認定): 禁止ではないが2条件が付く——①専門家による人間のレビュー(human-in-the-loop) を挟む ②AIが関与していることを利用者に開示 する違反はアクセス制限・停止の対象
出題パターン: 「採用選考をClaudeだけで自動化してよいか」→ダメ。高リスク領域なので人間の最終判断+開示が必要。「補助として使い、決定は人間」が常に正解側。
3-3. 適切/不適切なユースケースの見分け方
判定軸 低リスク(そのまま使ってよい) 高リスク(人間レビュー・慎重に) 影響 下書き・ブレスト・内部資料 健康・安全・法的・金銭に関わる判断 可逆性 後から直せる 署名・提出・公開など取り返しがつかない 対象 自分・チーム内 顧客・当局・一般公開
3-4. 倫理——4つのキーワードで足りる
Transparency(透明性): AI関与を隠さないAccountability(説明責任): 最終責任は常に人間・組織にある(「AIが言ったから」は免責にならない)Fairness(公平性): バイアスの点検(→D2の採用ランキング問題と接続)Privacy(プライバシー): 必要最小限のデータだけ渡す(data minimization)
試験に出る英語
regulated personal data 規制対象の個人データ
anonymize / redact 匿名化する/塗りつぶして除去する
human-in-the-loop 人間の判断を工程に挟むこと
disclosure AI関与の開示
consistent with policy ポリシーに沿って(正解選択肢の常套句)
確認テスト 3-1: 顧客の購入履歴(氏名・LINE ID付き)で傾向分析したい。正しい手順は? 氏名・LINE ID等の識別子を匿名化してからアップロード。 分析自体は正当な用途なので諦める必要はない。「社内だからそのまま」が最悪の選択肢。
確認テスト 3-2: 「アルバイトの採用可否をClaudeに判定させて自動返信」は何が問題? 採用は高リスク領域。 ①人間による最終判断を挟む ②応募者へのAI関与の開示、の2条件を満たさない全自動化はUsage Policy上も組織ガバナンス上も不適切。
確認テスト 3-3: AIの出力ミスで顧客に誤案内をした。責任は誰にある? 使用した人間と組織。 Accountabilityの原則——AIは責任主体になれない。だからこそ高影響の出力には検証(D2)とレビュー体制(D6)が要る、と2ドメインがつながる。
補講
4Dフレームワーク(AI Fluency) 実受験者情報: 本番に並び替え問題で出る
Anthropic Academyの「AI Fluency」コースが教える公式フレームワーク。実受験者によれば、本番では「タスクを正しい順に並べよ」形式で出題される (例: 5,3,1,2,4の並び替え)。4つのDを順番ごと暗記 すること。
順 D 意味 対応ドメイン 1 Delegation(委任) 目標を定め、そもそもAIに任せるか・何を任せるか・いつ任せるかを決める D3/D4(タスクとツールの適合) 2 Description(記述) 要件を明確に伝える(文脈・制約・形式)——いわゆるプロンプティングを含む対話設計 D1(プロンプティング) 3 Discernment(見極め) 出力を批判的に評価し、修正・反復する D2(出力評価と検証) 4 Diligence(勤勉・責任) 倫理・説明責任・透明性を保って使う D6(ガバナンス)
覚え方: 「任せる→伝える→見極める→責任を持つ 」——仕事を頼む時の自然な時系列そのまま。並び替え問題は「シナリオの各行動がどのDか」を判定してから時系列に並べる。
試験に出る英語
delegation / delegate 委任/任せる
description 記述・要件の伝達
discernment / discern 見極め/見極める
diligence / diligent 勤勉・入念さ/入念な
in line with 〜 〜に沿って
put ~ in the right order 〜を正しい順に並べる
確認テスト 補-1: 「この作業はAIに向くか?」を考えるのはどのD? Delegation(委任)。 エンゲージする前の判断はすべてDelegation。プロンプトを書き始めた時点でDescriptionに移る。
確認テスト 補-2: 4つのDを順番に言えるか? Delegation → Description → Discernment → Diligence。 任せる→伝える→見極める→責任を持つ。
第4課
プロンプティングとタスク実行 配点14% · Domain 1
4-1. 正解の癖——「文脈・制約・形式」を足した選択肢が勝つ
空指示(不正解側) 具体指示(正解側) "Do it better" / "Be more professional" 読者・トーン・語彙まで指定("formal, no contractions, standard sign-off") "Don't miss anything important" 形式と欠損時の扱いまで指定("3列の表、期限なしはTBD") "You are the world's best ○○"(役割だけ盛る) 役割+文脈+制約のセット
出題パターン: 「どのプロンプトがBESTか」型は、具体性の比較問題。迷ったら一番具体的な選択肢。
4-2. タスク分解と反復改善
複雑なタスク → 段階に分解(decompose)→各段階をレビュー→統合。一発大盛り・同じプロンプトの再送ガチャは不正解出力がイマイチ → 「何をどう変えるか」の具体フィードバックで反復(iterate)。"Try again"は改善指示ではない要件が無視される → 番号を振って構造化+各要件を満たしたか確認させる
4-3. タスク種別ごとの戦略
ブレスト = 量と多様性を要求し、質の判断は後回し(defer judging)事実確認・翻訳・計算 = 正確に1つ。制約を締める調査 = 概観→掘り下げの反復
試験に出る英語
decompose / break into steps 分解する
iterate / refine 反復する/磨く
vague 曖昧な(不正解プロンプトの形容)
constraint 制約
defer 後回しにする
確認テスト 4-1: 「もっと良くして」というプロンプトの何が問題? 測定不能で、何を変えるべきかの情報がゼロ。 正解は「どう変えるか」(トーン・長さ・重点)を具体的に指定すること。
確認テスト 4-2: ブレスト用プロンプトの2大原則は? 量・多様性を求める+質の判断を後回しにする。 発散と収束を混ぜない。
第5課
出力評価と検証 配点21%(最重量) · Domain 2
5-1. すべてを貫く一本線
検証は、モデルの外にある独立した基準と突き合わせたときだけ成立する。
5-2. 幻覚のシグナルと無関係なもの
シグナル : 具体的すぎる固有情報(数値・日付・引用)/探しても見つからない出典/同一会話内の矛盾無関係 : 長さ・書式・丁寧さ・自信・生成の速さ——見た目は正確性の証拠にならない
5-3. 人間レビューの要否と翻案
レビュー基準 = 影響の大きさ × 不可逆性 × 対外性 (署名・当局提出・公開・安全)
翻案 = 事実は変えず、表現を読者に合わせる 。誇張・リスク隠しは翻案ではなく歪曲
形式選択は受け手の要件から逆算(人間なら用途、システムなら仕様)
試験に出る英語
verify against 〜 〜と突き合わせて検証する
primary source 一次情報源
trace back to 〜 〜まで遡って特定する
spot-check 抜き取り確認する
fabricate 捏造する
確認テスト 5-1: 「Claudeにダブルチェックさせたので検証済み」の誤りは? モデル内で何回チェックしても独立した検証にならない (同じ誤りを同じ理由で見逃す)。外部基準との照合が必要。
確認テスト 5-2: 幻覚を最も疑うべき出力の要素は? 具体的な数値・日付・固有名詞・引用。 一般論の説明は比較的安全。レビュー時間は具体情報に重点配分。
第6課
ワークフロー統合とソリューション設計 配点16% · Domain 4
6-1. 導入の型(この順番だけで大半の問題が解ける)
要件と成功指標を先に定義 → 反復・大量・低リスクのタスクで小さく試す(pilot) → 測定(measure) → 段階的に拡大(expand gradually)。
6-2. ステークホルダー対応と分業
「AIで全部できる?」→ 価値と限界の両方を正直に +小さなパイロットで実証を提案。全肯定も全否定も不正解
「効果はどう分かる?」→ 指標(時間・品質・利用率)を事前定義し前後比較
分業の基本形: AI=下書き・要約(量)、人間=判断・承認・責任(質と決定)
試験に出る英語
pilot 試験導入(する)
baseline 比較基準・導入前の水準
metric 指標
augment 補強する(置き換えの対義)
roll out 展開する
repetitive / high-volume 反復的な/大量の(正解の目印)
確認テスト 6-1: 良いパイロットの2条件は? 小さく区切られた範囲+事前定義された成功指標とベースライン。 無期限・基準なしは「判定できないパイロット」。
確認テスト 6-2: FIRSTと聞かれたときの罠は? 「正しいが2歩目」の選択肢。 作る前に要件・現状分析・成功基準の定義が1歩目。
第7課
トラブルシューティングと最適化 配点10% · Domain 7
7-1. 診断の型
出力が変わった/人によって違う → まず入力・設定の差を疑い、変えた変数を特定して並べて比較する。
7-2. 最適化の型
適材適所(right-sizing) : 工程ごとに要件を見て、単純な工程は安く速いモデルへ。全部高い/全部安いは両方不正解毎回している修正はテンプレ・指示に昇格 させて往復を減らす(D1・D5との合流点)検証・品質チェックを削る最適化は常に不正解(D2違反)
試験に出る英語
diagnose / diagnostic 診断する/診断の
side by side 並べて
isolate (the change) (変更点を)切り分ける
degrade 劣化する
back-and-forth 往復のやり取り
確認テスト 7-1: 出力品質が急に落ちたときの第一容疑者は? 自分たちが直前に変えたもの(プロンプト・テンプレ・知識・設定)。 新旧を並べて比較し、変更点を特定する。
確認テスト 7-2: 「遅い・高い」ワークフローの正しい直し方は? 深い推論が要る工程だけ上位モデル、単純工程は高速安価モデルへ(right-sizing)。 品質チェックを削るのはNG。
第8課
製品運用の詳細——設定・接続・機能の使い分け 増補章 · D5/D6/D7横断
この章で扱うトピック
指示の階層と配置ルール コネクタの2層構造 凍結アップロード vs 生参照 Skills MemoryとIncognito web検索/Research/拡張思考 代替テストと役割境界 8-1. 指示の4階層——「効かせたい範囲」と同じ広さの場所に置く
階層 置き場所 効く範囲 入れるもの ⓪Organization instructions (Team/Enterprise)組織のAdmin/Ownerが設定 組織の全員・全会話 。個人の指示と衝突したら組織側が勝つコンプライアンスルール(例:「証券番号は下4桁のみ」)——全員に強制すべき統制 ①アカウントレベルInstructions 設定→プロファイル(「Claudeに考慮してほしいこと」) 全チャット・全Project (本人のみ)自分の役割・恒久的な文体・常に守る書式(「私は経理担当」「常体で」) ②Projectの指示 各Projectの設定 そのProject内の全チャット 案件固有のルール・トーン・参照方針 ③チャット内プロンプト 会話の中 その会話限り 今回だけの条件・一回きりの依頼
配置ルール: ルールは効かせたい範囲(スコープ)と同じ広さの場所に置く。全業務共通→アカウント/案件限定→Project/一回きり→チャット。兆候で見抜く: 「毎チャット冒頭に同じ指示を打っている」=置き場所が狭すぎるサイン。逆に、全部をProjectに入れるとProject外の会話で共通ルールが効かない (典型的な失点パターン)。
なぜ「指示欄に資料を混載」するとルールまで不安定になるのか: 指示欄は「設定ファイル」ではなく「毎回読まれる手紙」 。ルールは登録・記憶されるのではなく、毎チャット冒頭で文章として文脈に注入され、モデルがそれを読んだ結果 として振る舞いが決まる。だからルール3行だけなら毎回確実に効くが、そこに40ページの資料を足すと、大量のノイズの中の3行に注意が薄まり、回によって効きがムラになる(lost in the middle)。指示欄には長さ上限もあり、超過分は切られる。資料を知識ベースへ逃がすことは、情報の欠落を埋めるだけでなく、指示チャネルを短く清潔に戻してルールの通りを回復する処置 でもある。1行ルール:「指示は記憶されず、毎回読まれる。指示のチャネルは短く保つ 」。
8-2. コネクタの2層構造——組織の有効化+本人の認証
コネクタが動くまでの関門は2つ : ①組織の管理者が有効化 (統制上の許可判断。Team/Enterpriseでは管理者が組織全体のオン/オフを持つ)+②各ユーザーが自分のアカウントで認証 (自分のGoogle等のアカウントに自らサインインして接続)。出題パターン: 「組織で解禁されたのにアクセスできないと言われる」→答えはほぼ常に「②の個人認証がまだ」 。「プランの制限」「管理者に再依頼」「手動アップロードで代替」は不正解の定番。組織で解禁=即使える、ではない。
ただし重要な制限(第2課2-2の再掲): コネクタはプライベートProjectと通常チャットのみ 。共有Projectでは使えない (追加ボタンが無効化される)し、コネクタ同期コンテンツを含むチャットは共有できない。つまり②の個人認証は「自分の作業空間で自分のデータを使う」ための仕組みであって、共有Projectの知識としてチーム全員に生データを配る手段にはならない ——その用途なら共有Projectにはアップロード(+更新当番)が現実解。「個人で使えないのでは?」ではなく「個人でしか使えない 」が正しい理解。
8-2b. コネクタの能力境界——できること・できないこと
できること(Gmailコネクタの例) できない・しないこと 自然言語でメールを検索・読解 する 他人のメールボックスに届く こと——コネクタは接続した本人の権限を継承し、自分に見えないものは見えない接続アカウントで下書きを作る バックグラウンドで常時スキャン・監視 すること——アクセスは「必要とする依頼があったとき」だけ、取得は必要最小限送信・返信・転送 まで実行できる——ただしユーザーの代わりの操作はデフォルトで都度承認 が必要承認なしで勝手に送信すること
出題パターン: 「コネクタで何ができるか2つ選べ」型は感覚ではなく仕様で切る 。ひっかけ2種——①「読めるだけで送れない」と過小評価させる(実際は承認付きで送れる)、②「常時監視されるから毎回切断すべき」と過大恐怖させる(実際は依頼時のみアクセス。切断儀式は保護を足さず摩擦だけ足す)。能力の3点セット「読める・書ける・送れる(承認付き)」+境界の2点「本人の権限のみ・依頼時のみ」 で覚える。
8-3. アップロード=凍結スナップショット / コネクタ=生参照
アップロード コネクタ経由の参照 実体 その瞬間の凍結コピー (元ファイルを更新しても変わらない)原本への生きた参照 (常に現在の中身)向く文書 版を固定して分析したいもの(締め済み決算・契約書の特定版) 毎週更新のシフト表・価格表・ポリシー等、鮮度が命のもの 危険 黙って古びる 。新旧を共存させると矛盾の温床原本側の編集がそのまま反映される(固定したい用途には不向き)
判断軸は「鮮度が必要か、固定が必要か」の一つだけ。 「更新したのに古い答えが返る」系の問題は、ほぼこれが正解の軸。更新頻度が高い文書で「最新版を毎週アップロードし直す」は、動くが正解にならない (古い版の削除忘れ・手作業依存が残るため、コネクタが常に上位互換)。例外は共有Project ——コネクタが使えない(8-2の制限)ので、そこだけは「アップロード+更新当番」が正解になり得る。問題文が「private project」か「shared project」かを必ず確認すること。
8-3b. ファイル処理の限界——埋め込みグラフは見えない
アップロードの種類 Claudeに見えるもの DOCX・XLSX・TXT等(PDF以外) テキスト抽出のみ 。埋め込まれた画像・グラフ・図は読めない(公式ヘルプ明記)PDF(100ページ未満) テキスト+視覚要素(画像・チャート・グラフィック)を解析 PDF(101〜1000ページ) テキストのみ(視覚要素は無視) 画像ファイル単体 (JPEG/PNG等)解析される(1000×1000px以上推奨) PPTX(パワポ) そもそも対応リスト外 (アップロード不可)。スライドはPDFに書き出して渡す——視覚ルートに乗り、図ごと読める。DOCX変換は視覚情報が全部落ちるので最悪手
出題パターン: 「Word内のグラフにしかない数値をClaudeが『記載なし』と返す」→ 正解は「最初から見えていないと認識し、自分でその数値を拾う」 。「もっとよく見ろと再指示」「再アップロードして再実行」は見えないものを呼び出せず、圧力は捏造を招く。web検索で代替 は手元の一次資料をネット上の版と交換する行為でNG。混同注意: チャットに画像を単体で貼れば読める。読めないのは「文書の中に埋め込まれた」画像だけ——数値が必要なら、グラフ部分をスクショして別途貼るのも実務的な回避策。
8-4. Skills——手順のパッケージ。直すならSkill自体を
Skill=「この種のタスクはこの手順・この書式でやる」という手順書のパッケージ 。呼び出すたびに同じ手順が適用される
手順はSkillの中に 住んでいる。だからknowledgeに新資料を足しても、毎チャットで口頭指示しても、Skillの挙動は変わらない
手順が古くなったら(例: リブランドでレイアウト変更)→Skill自体を改訂して再アップロード が唯一の正解
ガバナンス面: 出所不明のSkillを検証なしで導入しない (監査の定番論点)
8-4b. Skillの設定手順(claude.ai・公式ヘルプより)
前提: 設定→機能(Capabilities)でコード実行とファイル作成をON にする(OFFだとSkillsは動かない)。対象プランはPro/Max/Team/Enterprise実体: Skill=フォルダ1つ。最低限SKILL.md (冒頭にYAMLでname とdescription 、本文に手順をMarkdownで)+必要なら参照ファイル・スクリプト。簡単なSkillはノーコードで作れる 導入は3ルート: ①既製Skillをディレクトリから有効化(アカウントのCustomize→Skills→「+」→Browse skills)/②自作SkillをzipにしてSettings→Featuresからアップロード /③Team/Enterpriseは組織のOwnerが全員に配布(provision) ——配布されたSkillは全メンバーの一覧に自動表示使われ方: 毎回呼び出す必要はなく、タスクがdescriptionに合致するとClaudeが自動で適用 する。だからdescriptionの書き方が発火条件そのもの更新: SKILL.mdの手順を改訂→zipし直して再アップロード(8-4の原則: 直す場所はSkillの中)
統一原則(8-1と同じ思想): 直すべきものを、それが実際に住んでいる場所で 直す。挙動の源がSkillなら改訂先はSkill、Projectの指示なら指示、アカウント設定なら設定。
8-5. Memory(記憶)とIncognitoチャット
Claudeはチャットをまたいで文脈を記憶 できる(Memory機能)。継続案件では利点
機微情報(人事・健康・未公表の経営情報)を記憶に残したくない とき→Incognitoチャット (履歴にも記憶にも残らないモード)を使う
「秘密にして/覚えないでと指示する」は自衛措置であって統制ではない ——D6の黄金律と同じ構図
出題パターン: 「未公表メモの詳細を記憶に残さず相談したい」→Incognitoチャット一択。仕組みで守れるものは仕組みで守る。 お願い(プロンプト)は仕組み(機能・設定)の代替にならない。
8-6. 深掘り3モードの使い分け——web検索 / Research / 拡張思考
機能 何をする 向くタスク web検索 いまの事実を数件さっと取得 最新価格・直近リリース・単発の事実確認 Research 複数ソースを多段階で調べ、出典付きレポート に統合 12州の規制網羅ブリーフ等、広く深い調査 拡張思考(extended thinking) 新情報は取らず 、手持ちの材料でより深く推論複雑な分析・多段の論理・難しい設計判断
切り分けの順番: ①外の情報が要るか?(要らない+考える力だけ要る→拡張思考)②要るなら深さは?(1〜2件の事実→web検索/多源の統合→Research)。web検索OFFのチャットで最新法令を聞く のは、知識カットオフ以降の情報が返らない失敗の型。
8-7. 代替テストとAssociateの役割境界
代替テスト(substitution test): 依頼が許される範囲か迷ったら「同じ依頼を人間に置き換えたらどうか 」と考える。弁護士・医師など専門家の職業的判断の代役 になるなら、Claudeの役割は「用語の理解・質問リストの整理」まで縮める(回答書の作成は弁護士へ)。人間なら守秘契約違反になる情報の渡し方はClaudeでも違反役割境界: Associate=製品(claude.ai)をノーコードで 使いこなす役割。タスクが保証された可用性・アクセス制御・ライブ接続・API・カスタム開発 を要求し始めたら、それは「個人ツールが本番システム化した」サイン→Developer/Architectにエスカレーション が正解
出題の匂い: 「もっと高性能なモデルに替える」「製品内で頑張って作り込む」が選択肢にあり、状況が本番システムの要件を並べていたら、正解はほぼ「専門家に渡す」 。守備範囲を知り、越えたら渡すのも試験が測る能力。
試験に出る英語
account-level instructions / preferences アカウント全体に効く指示(全チャット適用)
enable (a connector) (組織側で)コネクタを有効化する
authenticate / authorize 自分のアカウントで認証・許可する(2層目)
snapshot / frozen copy その時点の凍結コピー(アップロードの本質)
live / up-to-date reference 生きた参照(コネクタの本質)
incognito chat 履歴・記憶に残らないチャット
escalate to 〜にエスカレーションする(役割境界の正解語)
substitution test 人間に置き換えて許されるか考える判定法
確認テスト 8-1: 「全業務共通の書式ルール」と「案件Aだけのルール」、それぞれどこに置く? 共通→アカウントレベルInstructions、案件A限定→そのProjectの指示。 ルールは効かせたい範囲と同じ広さの場所へ。全部Projectに入れるとProject外で共通ルールが死ぬ。
確認テスト 8-2: 組織がDriveコネクタを有効化済みなのに「アクセスできない」。原因は? 本人の個人認証(2層目)がまだ。 自分のGoogleアカウントでコネクタを認証すれば繋がる。プラン制限でも管理者の設定漏れでもない。
確認テスト 8-3: 毎週更新のシフト表をProjectで参照したい。アップロードとコネクタ、どっち? コネクタ(生参照)。 アップロードは凍結コピーで黙って古びる。既にある古いアップロードは削除する(新旧共存は矛盾の温床)。
確認テスト 8-4: リブランド後もSkillが古いレイアウトで出力し続ける。直し方は? Skill自体の手順を新レイアウトに改訂して再アップロード。 knowledgeに新ガイドを足しても、毎回チャットで指示しても、Skillの中の手順は変わらない。
確認テスト 8-5: 未公表の閉鎖メモについて、記憶に残さず相談したい。正解は? Incognitoチャットを使う。 「秘密にしてと指示」は自衛措置で、統制(仕組み)の代替にならない。
確認テスト 8-6: 「12州の規制を網羅した出典付きブリーフが欲しい」。使う機能は? Research。 多源・多段階・出典付きの統合はweb検索の守備範囲を超える。逆に外部情報が不要で推論だけ深めたいなら拡張思考。
確認テスト 8-7: 自作Artifactに3部門が依存し、可用性保証と権限管理を求められた。次の一手は? 「本番システム化した」と認識してDeveloper/Architectにエスカレーション。 モデル変更や製品内での作り込みでは可用性・アクセス制御・ライブ接続の要件は満たせない。
第9課
実戦補講——落としやすい論点の総まとめ 増補章 · 全ドメイン横断
9-1. 読者適応の境界線(頻出)
変えてよい(プレゼン側) 変えてはならない(実質側) 長さ・論点の順序・語彙(専門用語→平易に)・詳細度・どのセクションを含めるか 数字・発見の方向・読者の判断や行動を変え得る但し書き
型: 経営向け=推奨・数字・リスクを先頭に、方法は圧縮。専門家向け=方法・前提・データを足す (挑戦の材料)。現場向け=行動できる点を先頭に+日常語。「悪い知らせを励ましに言い換える」「但し書きを削ってすっきりさせる」は常に不正解 ——翻案≠軟化。関連: 転送される文書は自己完結 (「上で議論した案」等の会話参照を残さない)。表計算行きの情報は表形式で要求 (散文は間違った容器)。
9-2. ポリシーの優先順位スタックと読み方
優先順位スタック: 法令・規制 > 組織の明文ポリシー > チームの慣行 > 個人の判断 (最後のタイブレーカーであって最初の権威ではない)。規制対象データは社内ポリシーが何と言おうと規制が支配must / must not / onlyの文だけが執行可能なルール 。前文の奨励・ビジョンは許可を与えない(「幅広く実験せよ」+「価格契約は入れるな」は矛盾ではない)ポリシーの沈黙は許可でも禁止でもない ——ポリシーオーナーへの問い。ただし雇用影響など高リスク類型は、ポリシーが名指ししていなくても要件(人間レビュー+開示)が付くドリフト : 遵守が崩れるのは大きな仕事ではなく、時間圧下の小さな日常タスク。タスクの規模は機密性の代理にならない——数秒のチェックは毎回回すために安く設計されている過剰反応も不正解 : 「全面禁止」「ガバナンスに丸投げして停止」は、「レビュー付きで適切」という有用な中間を潰す。エスカレーションの発動は「影響人口が大・損害が重大・決定権限の外」の3条件
9-3. Artifactの実務
会話=作業ログ、Artifact=成果物 。多ラウンド改訂される成果物はArtifactへ——常に1つの現行版、改訂はそこに直接作用版は保持され、バージョンセレクタで戻れる ——劣化した5回目に閉じ込められない。強かった3回目から再開できる(「旧版は消える」は誤解)配布の単位はArtifact (ダウンロード/コピーした独立文書)。会話ごと共有は下書き・脱線・機微な議論まで晒す。配布前チェックは自分の目で (Claudeに「クリーン」と自己証明させない)
9-4. 反復の終わらせ方・続け方
収穫逓減→停止して手仕上げ : 序盤=具体的欠陥が直る(ループ機能中)、終盤=言い換えだけ(収束済み)。そこからはもう1ラウンドより手動編集が速い不完全な応答→retool : 期待するスコープ・深さを明示し、前回のプロンプトと部分応答を含めて 続きから再開させる(公式ガイダンスの用語)原因調査は1変数ずつ : 疑わしい要素を1つだけ変えて比較。3つ同時に変えると帰属不能な1データ点共有設定への昇格は比較検証してから : 1会話で効いた修正を共有Projectに入れたら、旧方式を残したまま数サイクル比較。良い変更の複利は悪い変更の複利と鏡合わせ一貫性の編集は全文一括 : トーン・つなぎ・重複は文書全体の性質——分解の逆で、全文+要件を1メッセージで(分解が正しいのは各段階の出力を別々にチェックする多段の仕事)発散→人間の選択→収束 : ブレスト(緩く・量を要求)と起草(読者・トーン・長さを固定)を1プロンプトに積まない。どれを採るかの決定は人間のもの
9-5. 要件・設計・パイロットの規律
要件は「質問」から作る : 曖昧な一文しか無いとき、Claudeの役割は答えの機械ではなく質問リストの起草 ——答えを知るのは現場だけ。推測・業界ベストプラクティスでの充填は捏造への近道完成した要件は「誤りの帰結」を明記する ——それがレビューの深さを決める(メニュー文は流し読み・見積の数字は全数検証)。一律レビューは過剰と過小を同時に犯す設計段階の成果物は2つ : ステップの地図(各ステップをClaudeが担うか人が保持するか)+完了の定義 (合意された「受け入れ可能」像がないと反復は収束しない)。「柔軟のため文書化しない」は作者しか回せないプロセスを生むパイロットは証拠の生成 : ①開始前にベースラインを計測 ②成功基準を事前に合意(事後の再解釈から評価を守る)。最初から全展開・最高リスク業務での実験は逆最適化は計測から : 「遅い気がする」→記憶ではなく、全手作業を書き出しながら1サイクル完走。プロセス分析は実態(as-run)を記述 し、出てきたボトルネックは実測データで検証する仮説として扱う再現可能なワークフローの条件 : 順序付きの文書化された手順・名前の付いた入力・完了の定義・失敗が記録される場所。作者しか回せないなら個人技
9-6. 事故と限界のコミュニケーション
無事故記録は「システム全体(Claude+レビュー)」の測定値 ——レビュアーが誤りを捕まえてきた記録は、関門が機能している証拠であってドラフトが信頼できる証拠ではない。関門付きの好成績を理由に関門を外すのは、火事がないからと煙探知機を外すのと同じ。 事故が起きたら: ツールが実際にしたこと+人間側の安全装置がどう機能しなかったか+塞ぐ具体策、を両方向の正確さで報告(ツールだけのせいにも、隠しもしない)。「管理された限界」と「管理されていない限界」は別の事実——過小評価(1件の封じ込め済みエラーで全廃)も誇張と同じく不正確。
9-7. web検索・引用の検証
引用は監査証跡であって保証ではない ——リンクを開き、荷重のかかる主張(日付・閾値・文言)が原文にあるか確認する。統合の過程で詳細は省かれ・変わり得る引用の忠実性≠事実の正確性 : リンク先に同じ数字がある=Claudeが正直に報告しただけ。二次アグリゲータなら一次・権威ソースまで遡る (chain of custody)URLを知っているなら直接渡す ——web検索有効時、特定URLの内容を取得できる(web fetch)。権威ページの在り処を知っているときの最強手最新情報が要るときは「Search the webと明示」+「主張ごとに出典要求」 のペア
9-8. 小さいが出た論点集
長さ上限 vs 使用量上限 : 長さ(コンテキストウィンドウ)=1チャットの容量で時間では回復しない (→要約して新会話)。使用量=期間あたりの利用枠で時間で回復する。混同が定番のひっかけMemoryは今の会話の外部ストレージではない (保存させても窓は軽くならない)。そしてMemoryは老化する ——古いエントリはレビューして編集・削除できる(「無視しろと指示」は源を直さない)数字はコード実行で計算させる : 散文として書かれた合計は「計算」ではなく「もっともらしいテキスト生成」。コード実行なら実計算+元データとのspot-checkで二重に守るハウススタイルは実例を貼る : 「わが社のスタイルで」は内部にしかない知識への参照——実物1〜2通が最も効率的な乗り物。形容詞の追加やペルソナでは運べないAI支援の開示はプロセスに付随 : 大幅に書き直しても「AI起草」の事実は消えない。契約が開示を求めるなら従う——編集は製品を良くし、開示は過程を語る人間的要素が内在するタスク (解雇通知等)は、準備(論点整理・想定問答)にAIを使い、配達は人間が自分の言葉で 分類は両方向に働く : 公開済み資料は安全ティア——公開データへの黒塗りや承認要求は保護を足さずプロセスを形骸化させる。過剰防衛の選択肢も不正解になる
確認テスト 9-1: 経営向け分析を現場チーム向けに翻案する。変えてよいもの/ダメなものを1つずつ 変えてよい: 順序・語彙・長さ・セクション選択。ダメ: 数字・発見の方向・判断を変える但し書き。悪い知らせの軟化と但し書きの削除は常に不正解。
確認テスト 9-2: ポリシー冒頭は「AIを活用せよ」、後段に「顧客データはmust not」。どっちが勝つ? must not文。 ルールはmust/must not/onlyの文だけ。前文は文脈であって許可ではない。
確認テスト 9-3: 6か月無事故だからレビュー廃止、の提案への正しい応答は? 無事故はレビュー込みのシステムの成績 (レビューが誤りを捕まえてきた記録がある)。煙探知機を外さない。
確認テスト 9-4: 会話の長さ上限に達した。「明日まで待てば回復する」は正しい? 誤り。 時間で回復するのは使用量上限。長さ上限は要点を要約して新しい会話へ。Memory保存でも窓は軽くならない。
修了試験
教科書実戦テスト(英語7問) D3+D5+D6
教科書を読み終えたらこのテストで理解を確認する。形式: タイマー・一時停止・「わからない」チェック・単語チップ・採点後の日英並記。実質6/7以上 が合格の目安。
※ 各課末の確認テスト(タップで開閉)が代わりの自己チェックです。読み終えたら、第1課から確認テストだけを通しで解き直すのがおすすめ。
出典: claude.com/pricing、Anthropicヘルプセンター「What are projects?」、Anthropic Usage Policy(いずれも2026年8月26日取得)。機能の説明は2026年8月時点の製品仕様の理解による——プラン価格・機能は変わりやすいので、模試で食い違いを見つけたら公式ページ再確認を。