Associate Foundations 補習 S3: 仕事で Claude を使う
この章で学ぶこと: タスクの種類（分析・調査・下書き・ブレインストーミング）ごとの頼み方、会話の中でのタスク分解、要件やユースケースの分析、調査・計画・プロセス改善への活用、今のワークフローへの組み込みと再設計、関係者への価値と限界の伝え方。
| 元のドメイン | タスク | この章の節 |
|---|---|---|
| D1 プロンプトとタスク実行（14%） | タスク分解で複雑な依頼を構造化する | 第2節 |
| D1 | タスクの種類に応じてプロンプト戦略を変える | 第1節 |
| D4 ワークフロー統合とソリューション設計（16%） | 要件やユースケースを分析する | 第3節 |
| D4 | 調査・計画・プロセス最適化に活用する | 第4節 |
| D4 | ソリューションの設計・開発・反復を支援する | 第4.3節 |
| D4 | 既存のワークフローに組み込み、強化・再設計する | 第5節 |
| D4 | 価値と限界を関係者に伝える | 第6節 |
Developer Foundations で学んだので、ここでは繰り返さない内容:
- 効果的なプロンプトの書き方（明確さ、理由、例、XML タグ）と反復改善 → Developer ドメイン6 第2節
- システムとしてのタスク分解（ワークフローとエージェント、プロンプトのつなぎ方） → Developer ドメイン1
- 業務要件から機能要件へ、成功の基準 → Developer ドメイン2 第1節
1. タスクの種類ごとの頼み方
| 種類 | ねらい | 頼み方のこつ | 気をつけること |
|---|---|---|---|
| 分析 | データや文書から意味を引き出す | データと問いをはっきり渡す。「何を比べるか」「どの基準で」を書く。考える手順を示す | 数字は元のデータで確かめる。前提を書かせる |
| 調査 | 情報を集めてまとめる | 範囲・期間・信頼できる出典の種類を決める。リサーチ機能や検索を使う。出典を必ず付けさせる | 出典を開いて読む。古い情報に注意 |
| 下書き | 文書の最初の形を作る | 読み手・目的・長さ・口調・形を伝える。良い例を見せる | 事実と固有名詞を確かめる。最後は自分の言葉で直す |
| ブレインストーミング | 案をたくさん出す | 数を指定する（「20案」）。制約を少なめにする。「ありきたりでない案も」と頼む | 出た案の実現性は別に評価する。最初から絞りこまない |
ポイント: 調査や分析は「正しさ」、下書きは「読み手に合うか」、ブレインストーミングは「幅の広さ」が大事。目的によって、指示の厳しさも変えます。
公式のプロンプトのベストプラクティスより: 何をしてほしいか（提案だけか、実際に直すか）をはっきり書く。理由を書くと、Claude はより良く判断できる。
2. 会話の中でのタスク分解
大きな依頼を1回で頼むと、抜けや質のむらが出やすくなります。公式のベストプラクティスも、複雑な仕事は段階に分け、前の段の出力を次の段に渡す（プロンプトのつなぎ方）ことを勧めています。
例: 新製品の発表の準備
| 段 | 依頼 | できるもの |
|---|---|---|
| 1 | 製品資料を読んで、要点と対象の顧客をまとめて | 要点の一覧 |
| 2 | 要点をもとに、メッセージの骨子を3案 | 骨子の案 |
| 3 | 選んだ案で、プレスリリースを下書き | 下書き |
| 4 | 下書きを、事実と資料で照らして確かめて | 確認の結果 |
| 5 | 経営層向けに1ページの要約 | 要約 |
分けるよさ:
- 段ごとに確かめて、まちがいを早く見つけられる
- 1つの段がうまくいかないとき、その段だけを直せる
- 段ごとに合った機能を使える（調査はリサーチ、資料は Artifact など）
3. 要件やユースケースを分析する
Claude は、要件を整理する相手にもなります。
| 使い方 | 例 |
|---|---|
| 聞き取りメモの整理 | 関係者の聞き取りメモから、要望・課題・制約を分けて表にする |
| 抜けを探す | 「この要件の一覧で、決まっていないことや矛盾を挙げて」 |
| ユースケースの洗い出し | 「この業務で Claude が役立ちそうな場面を、効果と難しさで並べて」 |
| 成功の基準 | 「この取り組みの成功を、測れる形で3つ」 |
Claude が向いているユースケースを選ぶ観点（一般的な実践）:
| 観点 | 向いている | 向いていない、または注意 |
|---|---|---|
| 仕事の形 | 文章を読む・書く・まとめる・比べる、くり返しが多い | 物理的な作業、正確な計算だけの仕事（専用ツールがよい） |
| まちがいの影響 | 人が確かめられる、直せる | 人の命・権利・お金を、人の確認なしで決める（S4） |
| データ | 使ってよいデータ | 社外に出してはいけないデータ（組織のポリシー次第） |
| 技術の難しさ | claude.ai の機能でできる | API での開発、複雑なシステム統合 → Developer・Architect に相談（エスカレーション） |
試験ガイドは、Associate の認定者が「限界を見きわめ、複雑・技術的な実装は Claude Architect や Developer にエスカレーションする」ことを求めています。
4. 調査・計画・プロセス改善に使う
4.1 調査
- リサーチ機能で、外の情報と、つないだ社内の情報（Gmail、Google Drive など）をまとめる（S1 第3節）
- 調べる問いを先に分ける: 「市場の大きさ」「主な競合」「規制」など
4.2 計画
- 目的と期限を渡して、作業の分解、順番、依存関係、リスクを出させる
- 出た計画の期限や工数は、担当者と確かめる（Claude は社内の事情を知らない）
4.3 プロセス改善と、設計・反復の支援
| 手順 | Claude に頼めること |
|---|---|
| 今の流れを書き出す | 手順書や聞き取りから、今のプロセスを段ごとに書き出す |
| むだを探す | 「時間がかかる段、くり返しの段、待ちが多い段は」 |
| 改善案 | 「Claude で減らせる段と、人が残すべき段を分けて」 |
| 試す | 小さく試して、時間と質を測る |
| 直す | 結果を見て、指示や手順を直す（S5） |
5. 今のワークフローに組み込む・再設計する
5.1 組み込み方の段階
| 段階 | 例 | 使う機能 |
|---|---|---|
| 1. 個人の手伝い | メールの下書き、議事録の要約 | チャット |
| 2. くり返しの仕事を型にする | 毎週の報告を、決まった資料と形で作る | Projects（指示 + ナレッジ）、Skills |
| 3. 社内の情報とつなぐ | メールと予定から、今週の優先事項を出す | コネクタ、リサーチ |
| 4. チームで共有する | チーム共通の Project、組織の Skills | 共有プロジェクト、組織が配る Skills |
| 5. プロセス自体を見直す | 人がするのは確認と判断だけにする | 上のすべて + 人のレビューの段 |
5.2 「強化」と「再設計」
- 強化: 今の流れはそのままで、1つの段を Claude で速くする（例: 下書きだけを Claude に）
- 再設計: Claude がある前提で、流れ自体を組みかえる（例: 先に Claude が案を3つ作り、人は選んで直すだけ）
再設計のときも、人のレビューの段、データのルール、うまくいかないときの戻り方を決めておきます。
5.3 組み込むときに決めること
- どこまでを Claude に任せ、どこで人が確かめるか
- どのデータを渡してよいか（S4）
- だれが指示とナレッジを保守するか（S1 第2.5節）
- うまくいったかを何で測るか（時間、質、ミスの数）
6. 価値と限界を関係者に伝える
6.1 伝えるときの形
| 伝えること | 例 |
|---|---|
| 何が良くなるか（価値） | 「報告書の下書きが2時間から30分に」 |
| どう測ったか | 「10件で試し、時間とミスの数を比べた」 |
| 限界 | 「数字や固有名詞はまちがえることがある。人が確かめる」 |
| リスクと対策 | 「顧客の個人情報は入れない。社外に出す前にレビュー」 |
| 必要なもの | 「プランの費用、ルールづくり、使い方の研修」 |
6.2 正直に伝える限界（公式の情報にもとづく）
- まちがった内容をもっともらしく書くことがある（ハルシネーション）。大事な事実は確かめる
- 知識には期限がある（学習データの時点）。最新情報はウェブ検索やリサーチで補う
- コンテキストの量には上限があり、長い会話では前の内容が要約される（S1 第7節）
- 高リスクの判断は、資格のある人のレビューが必要（Usage Policy）
聞き手に合わせる: 経営層には効果とリスクとお金、現場には使い方と確認の手順、法務やセキュリティにはデータの扱いと守るルール。
大事な態度: 価値を大きく言いすぎない。限界を隠さない。小さく試した結果で話す。
7. 試験に向けたまとめ
| 問われ方 | 答えの方向 |
|---|---|
| ブレインストーミング | 数を多く、制約を少なく。評価は後で |
| 調査 | 範囲と出典を決める。リサーチ機能。出典を確かめる |
| 大きな依頼で質がばらつく | 段に分け、段ごとに確かめる |
| ユースケースを選ぶ | 効果が大きく、人が確かめられ、データが使えるもの |
| API 開発や複雑な統合 | Developer・Architect にエスカレーション |
| くり返しの仕事 | Projects や Skills で型にする |
| 経営層への説明 | 測った効果、限界、リスクと対策を正直に |
8. 用語集
| 用語 | 意味 |
|---|---|
| タスク分解 | 大きな仕事を、順番のある小さな段に分けること |
| プロンプトのつなぎ方（chaining） | 前の段の出力を次の段の入力にすること |
| ユースケース | Claude を使う具体的な場面 |
| ワークフロー | 仕事の流れ。だれが、どの順で、何をするか |
| エスカレーション | 自分の手に負えないことを、より適した人に回すこと |
| 関係者（ステークホルダー） | その取り組みに関わる人や部署 |
出典
- Prompting best practices（Claude Platform Docs）: はっきり書く、理由を書く、提案か実行かを明確に、複雑な仕事を段に分けてつなぐ
- Reduce hallucinations（Claude Platform Docs）: まちがいの可能性と対策
- Usage Policy（Anthropic）: 高リスクの使い方の要件
- When should I use web search, extended thinking, and research?（Claude Help Center）: 調査での機能の使い分け
- How large is the context window on paid Claude plans?（Claude Help Center）: コンテキストの上限と自動の要約
- 試験ガイド（Version 1.0）第2章: 認定者が複雑・技術的な実装をエスカレーションすること
第1節の表、第2節の例、第3節〜第6節の手順や表の多くは、一般的な業務の実践のまとめで、公式ドキュメントからの直接の要約ではありません。内容は上の出典を要約・言い換えたものです（ライセンスに配慮して書き直しています）。