Associate Foundations 補習 S5: うまくいかないときの直し方（業務の視点）
この章で学ぶこと: 出力が悪いときの原因の見分け方と直し方、フィードバックや結果を見てやり方を変えること、業務のワークフローを効率と効果の面で良くすること。
| 元のドメイン | タスク | この章の節 |
|---|---|---|
| D7 トラブルシューティングと最適化（10%） | 成果の悪いプロンプトや出力を特定・診断・解決する | 第1節・第2節 |
| D7 | フィードバックや結果に応じてやり方を調整する | 第3節 |
| D7 | ワークフローを効率と効果の面で最適化する | 第4節 |
Developer Foundations で学んだので、ここでは繰り返さない内容:
- プロンプトの反復改善の基本 → Developer ドメイン6 第2.6節
- つなぎこみの問題か、モデルの出力の問題かの切り分け（API 側） → Developer ドメイン4 第4節
- コストと速さ（モデル、effort、キャッシュ） → Developer ドメイン5 第3節・第4節
1. 症状から原因を見分ける
| 症状 | ありがちな原因 | 直し方 |
|---|---|---|
| 的はずれな答え | 目的や背景が書かれていない | 目的、読み手、使い道を書く |
| 形がばらばら | 出力の形を決めていない | 形を指定する。例を1つ見せる |
| 長すぎる・短すぎる | 長さを指定していない | 「300字」「箇条書き5つ」など |
| 事実のまちがい | 資料を渡していない。出典を求めていない | 資料を渡す。出典を付けさせる。「わからなければそう書く」と指示 |
| 前に決めたことを忘れる | 会話が長く、話題がまざった | 要約して新しい会話。前提は Projects の指示へ |
| 資料を使ってくれない | 資料が多すぎる、どこを見るか伝えていない | 関係する資料だけにする。「資料のこの部分にもとづいて」と書く |
| 古い情報で答える | 学習データの時点の知識で答えた。古い資料が残っている | ウェブ検索やリサーチを使う。古いナレッジを消す |
| 調査が浅い | ふつうのチャットで頼んだ | リサーチ機能を使う。調べる問いを分けて渡す |
| 毎回同じ説明をしている | 指示がプロジェクトやメモリにない | Projects の指示、メモリ、Skills にまとめる |
| コネクタの資料を見ていない | コネクタがオフ、権限がない、モバイルでリサーチした | コネクタをオンにする。権限を確かめる。「[資料名]から情報を取って」と頼む |
| すぐ使用量の上限に届く | 長い会話、大きなファイル、リサーチの多用 | 新しい会話、依頼をまとめる、プロジェクトのナレッジを使う |
最後の3つは公式ヘルプ（リサーチ、使用量のベストプラクティス）にもとづきます。ほかは一般的な実践のまとめです。
2. 直し方の進め方
| 手順 | すること |
|---|---|
| 1. 何が悪いかを言葉にする | 「長い」ではなく「結論が最後にあり、経営層が読みにくい」 |
| 2. 原因を1つずつ疑う | 依頼のしかた → 渡した資料 → 機能の選び方 → 会話の長さ → モデルの選び方 |
| 3. 1回に1つだけ変える | どの変更が効いたかがわかる |
| 4. 同じ入力で比べる | 前と後を同じ例で比べる |
| 5. うまくいった形を残す | プロジェクトの指示、Skills、テンプレートに入れる |
Claude に直し方を聞くのも1つの手です: 「この依頼で、望んだ出力にならなかった。何を足せばよいか」。
モデルの選び方が原因のとき: 難しい推論が足りないなら上位のモデルや extended thinking、速さやコストが大事なら速くて安いモデル（Developer ドメイン5 第3節）。claude.ai では、会話の途中でもモデル・effort・thinking を変えられ、次の応答から変わります（公式ヘルプ「Change the model, effort, and thinking settings」）。
3. フィードバックと結果でやり方を変える
| フィードバックの元 | 例 | 変えること |
|---|---|---|
| 読み手の反応 | 「長くて読まない」 | 長さと形の指示 |
| レビューで見つかったまちがい | 「数字が資料と違う」 | 資料の渡し方、出典の指示、確認の段を足す |
| 測った数字 | 下書きの時間は減ったが、直す時間が増えた | 指示を足す、または人が書く段に戻す |
| チームの声 | 「人によって結果が違う」 | 共通の Project や Skills にまとめる |
ポイント:
- 1回の失敗ですぐ全体を変えず、くり返し起きるかを見る
- 良い例と悪い例を集めておき、変更のあとで同じ例で確かめる
- 変えたことは、使っている人に伝える（S1 第2.5節）
4. ワークフローを最適化する
4.1 効率（速さ・手間・使用量）
| 打ち手 | 効果 |
|---|---|
| 似た依頼を1つのメッセージにまとめる | やりとりと使用量が減る（公式ヘルプ） |
| くり返す前提はプロジェクトのナレッジに | 毎回貼らなくてよい。キャッシュが効く（公式ヘルプ） |
| 単純で大量の仕事には速くて安いモデル | 速さとコスト（試験ガイドのサンプル問題2） |
| 手順が決まった仕事は Skills に | 毎回同じやり方。説明がいらない |
| 話題が変わったら新しい会話 | 長い会話で使用量が増えるのを防ぐ |
4.2 効果（質・ミスの少なさ）
| 打ち手 | 効果 |
|---|---|
| 大きな仕事を段に分ける | 段ごとに確かめられる（S3 第2節） |
| 確認の段を決める | まちがいが外に出にくい（S2 第4節） |
| 良い例を見せる | 形と質がそろう |
| 結果を測る | 良くなったかがわかる |
4.3 効率と効果のバランス
速くしても、直す時間やミスが増えれば意味がありません。「1件あたりの時間」と「質（ミスの数、読み手の評価）」の両方を測って判断します。試験ガイドも、認定者に「品質・効率・コストのバランスがとれた方法を選ぶ」ことを求めています。
5. 試験に向けたまとめ
| 問われ方 | 答えの方向 |
|---|---|
| 出力の形がばらばら | 形を指定し、例を見せる |
| 事実のまちがい | 資料と出典。わからなければそう書かせる |
| 長い会話で指示を忘れる | 要約して新しい会話。前提は Projects へ |
| 直し方 | 1回に1つ変え、同じ例で比べる |
| 使用量の上限にすぐ届く | 依頼をまとめる、ナレッジを使う、新しい会話 |
| 大量の単純な仕事 | 速くて安いモデル |
| 人によって結果が違う | 共通の Project や Skills |
6. 用語集
| 用語 | 意味 |
|---|---|
| トラブルシューティング | うまくいかない原因を見つけて直すこと |
| 最適化 | 速さ・手間・質のバランスを良くすること |
| フィードバック | 読み手やレビューからの意見 |
| 使用量の上限 | プランごとに決まった、使える量の限り |
出典
- Usage limit best practices（Claude Help Center）: 依頼をまとめる、プロジェクトのナレッジのキャッシュ、計画する
- Use research on Claude（Claude Help Center）: リサーチが動かないとき、コネクタから取れないとき
- Change the model, effort, and thinking settings（Claude Help Center）: 会話の途中での変更
- How large is the context window on paid Claude plans?（Claude Help Center）: 長い会話の自動の要約と使用量
- Prompting best practices（Claude Platform Docs）: 具体的に書く、例を見せる、形を導く
- 試験ガイド（Version 1.0）第2章とサンプル問題2
第1節の表の多く、第2節〜第4節の進め方は一般的な実践のまとめで、公式ドキュメントからの直接の要約ではありません。内容は上の出典を要約・言い換えたものです（ライセンスに配慮して書き直しています）。