はじめに
Anthropicの Claude Opus 4.6 を MAXプランで毎日使い込んでいます。Cowork、Skills、Memory といった機能もフル活用しており、もはや業務に欠かせない存在です。
ただ、使えば使うほど「ここは苦手だな」と感じるポイントも見えてきます。
本記事では、データエンジニアとして日常的にClaudeを活用する中で感じた 4つの弱み と、それぞれに対して システムプロンプトやSkillsのルールで施している対処法 を紹介します。
本記事は2026年3月時点の情報に基づいています。Claude のアップデートにより改善されている可能性があります。
対象読者
- Claudeをある程度使い込んでいて、もっとうまく付き合いたい方
- LLMの限界を理解した上で活用精度を上げたい方
- データエンジニアリングやクラウド系の業務でLLMを使っている方
私のClaude利用環境
まず前提として、私の利用環境を共有します。
- プラン: MAX(Opus 4.6)
- 主な用途: データパイプライン開発(Databricks / Snowflake)、Qiita記事執筆、ドキュメント作成
- 活用機能: Cowork(Skills / Scheduled Tasks)、Memory、Projects
Claudeの個人設定(userPreferences)として、以下の基本ルールを設定しています。
## 基本ルール
- 要件が曖昧なら明確化の質問を先にすること
- コードを書く前にアプローチを説明して承認を待つこと
- 回答を生成したときにはどのような意図で生成したのかを明確にすること
- クラウドサービス(AWS/Azure/GCP)、Databricks、ライブラリのAPI仕様は
自分の記憶を信用せず、回答前にWeb検索で確認すること
- クラウドサービスの機能ステータス(Preview/GA等)を述べる際は、
必ず最新のリリースノートで裏取りすること
- 生成AIの業界の事例を調べるときには直近半年間のものに絞ってください
- 推測や未検証の情報を含む場合は、その旨を明示すること
- 私が修正したら、同じ間違いを繰り返さないよう記憶に追加すること
- エラーが出たとき、表面的な対処だけでなく根本原因を説明すること
これらのルールはすべて、次のセクションで紹介する「弱み」への対処として設定したものです。一つずつ見ていきましょう。
Claudeの弱み① コードに意図がない
どういうことか
Claudeにコードを書いてもらうと、 動くコードはすぐに出てくる のですが、「なぜこのアプローチを選んだのか」「他の選択肢と比較してどうなのか」といった 設計意図の説明がない ことが多いです。
例えば「S3からSnowflakeにデータをロードするスクリプトを書いて」とお願いすると、いきなり完成コードがドンと出てきます。一見便利ですが、以下のような疑問が残ります。
-
COPY INTOと Snowpipe、どちらを検討した上での選択なのか? - ファイルフォーマットの設定はなぜこの値なのか?
- エラーハンドリングの方針はどう考えたのか?
コードレビューの観点がないまま「とりあえず動く」コードが量産されるのは、特にチーム開発では危険です。
対処法
個人設定に以下の2つのルールを入れています。
- コードを書く前にアプローチを説明して承認を待つこと
- 回答を生成したときにはどのような意図で生成したのかを明確にすること
この設定により、Claudeはコードを書く前に「こういう方針で実装しようと思います」と提案してくれるようになります。こちらが「それでOK」と承認してから実装に入るので、意図のすり合わせが自然にできます。
ただし、この設定をしていても簡単な質問に対してはいきなりコードを出してくることがあります。完璧ではありませんが、複雑なタスクほど効果を発揮します。
Claudeの弱み② クラウド系の情報に弱い
どういうことか
AWS、GCP、Azure、Databricks、Snowflake といったクラウドサービスのAPI仕様や設定値について、 自信満々に間違った情報を返してくる ことがあります。
よくあるパターンとしては以下のようなものがあります。
- 存在しないパラメータ名を使ったコードを生成する
- Preview機能をGA済みとして紹介する(またはその逆)
- 旧バージョンのAPI仕様で回答する
- Databricks Runtime のバージョンによる挙動差を考慮しない
これはLLMの学習データに時点のズレがあることが根本原因ですが、クラウドサービスは更新頻度が非常に高いため、この弱みが顕著に出ます。
対処法
個人設定に以下のルールを入れています。
- クラウドサービス(AWS/Azure/GCP)、Databricks、ライブラリのAPI仕様は
自分の記憶を信用せず、回答前にWeb検索で確認すること
- クラウドサービスの機能ステータス(Preview/GA等)を述べる際は、
必ず最新のリリースノートで裏取りすること
- 推測や未検証の情報を含む場合は、その旨を明示すること
ポイントは 「自分の記憶を信用せず」 という表現です。Claudeに「Web検索してね」と言うだけでは不十分で、「あなたの学習データは古い可能性があるから、自分を信用するな」というニュアンスを伝えることで、Web検索の実行率が体感的にかなり上がりました。
また、「推測や未検証の情報を含む場合は明示すること」で、検索で裏取りできなかった場合にもそれが分かるようになります。
Claudeの弱み③ 事例検索で古い情報を取ってくる
どういうことか
「生成AIの活用事例を調べて」とお願いすると、 2022〜2023年頃の事例をあたかも最新のもののように紹介してくる ことがあります。
生成AI分野は半年前の情報でさえ「古い」と感じるほど変化が激しい領域です。2022年の事例は歴史的な参考にはなりますが、「最新の活用事例」として紹介されると判断を誤りかねません。
Web検索ツールを使ってくれていても、検索クエリに年指定がなく、SEOの強い古い記事がヒットしてしまうケースが原因として多い印象です。
対処法
シンプルですが効果的なルールです。
- 生成AIの業界の事例を調べるときには直近半年間のものに絞ってください
この一文を入れるだけで、検索クエリに年月が含まれるようになり、古い情報が出てくる頻度が大幅に減りました。
分野によって「鮮度」の基準は変わるので、自分の業務に合わせて期間を調整するのがおすすめです。
Claudeの弱み④ Skillsのルールを守らないことがある
どういうことか
Cowork の Skills にルールを細かく定義しても、 長い会話の途中でルールが無視される ことがあります。
例えば、「ファイルを作成したら必ず /mnt/user-data/outputs/ に配置すること」というルールをSkillに書いていても、会話が長くなると忘れてしまい、/home/claude/ に置きっぱなしにされることがあります。
なぜ起きるのか
これはClaudeに限らず、 LLMが構造的に抱える問題 です。
- コンテキストウィンドウの制約: 会話が長くなると、初期に読み込んだSkillsの指示がコンテキスト内で相対的に薄まる
- コンテキストロード1の問題: すべてのルールが均等に重み付けされるわけではなく、直近のやり取りに注意が偏りやすい
解決アプローチへの所感
サブエージェントに分割してタスクを委譲することで、コンテキストの肥大化を防ぐアプローチが提案されています。各エージェントが小さなコンテキストで動くため、ルール遵守の精度が上がるという理屈です。
理論的には納得できますが、実際の業務で試した感覚としては以下の課題を感じます。
- エージェント間の情報共有に手間がかかる
- 分割の粒度設計が難しい
- デバッグの複雑性が増す
現時点では、Skillsのルールに重要な指示を 複数箇所に重複して記載 したり、会話が長くなったら 新しい会話に切り替える といったアナログな工夫で対応しています。抜本的な解決はモデルやプラットフォーム側の技術革新を待っているのが正直なところです。
まとめ
| 弱み | 対処法 |
|---|---|
| コードに意図がない | 「アプローチを先に説明して承認を待て」ルール |
| クラウド系の情報に弱い | 「自分の記憶を信用するな、Web検索しろ」ルール |
| 事例が古い | 「直近半年に絞れ」ルール |
| Skillsのルール違反 | 重複記載 + 会話の切り替え + 技術革新待ち |
Claudeは非常に優秀なツールですが、万能ではありません。弱みを理解した上で 「こう使えばうまくいく」 というガードレールを設定してあげることで、業務での活用精度は大きく変わります。
LLMの進化は速いので、ここで紹介した弱みの一部は近いうちに解消されるかもしれません。ただ、「LLMの特性を理解してプロンプトで制御する」という考え方自体は、モデルが変わっても応用できるスキルだと思っています。
皆さんが感じているClaudeの弱みや対処法があれば、ぜひコメントで教えてください。
-
ここでは、コンテキストウィンドウ内での情報の優先度や注意配分の偏りを指しています。 ↩