AIツールがつらくなる理由：実践的な学びの地図

Ailootの使い方については、ドキュメントをご覧ください。

学習の比喩であり、普遍的な心理法則ではない#

この記事の実用上の問いは、心理診断より狭いものです。期待と検証できる成果が一致しているかを見ます。終えるつもりだったことと実際に動くものを比較し、その証拠から次の仕事を調整してください。

自信だけで能力を測らず、実際の成果と、それを裏付ける検査を確認してください。

その後、ダニング＝クルーガー曲線は、4段階を示すおなじみの図になりました。まず自信が「愚かさの山の頂上」まで急上昇します。次に「絶望の谷」へと落ち込みます。その後、「啓発の坂」をゆっくり上り、「持続可能性の高原」へ向かいます。

この曲線は記事の比喩です。読者の離脱率、固定の学習期間、ラベルを通る普遍的な経路を示す調査は、この記事では行っていません。

バイブコーディングの4段階—今どこにいますか？#

各段階には、それぞれ典型的な考え方と行動があります。全体像を見てみましょう。

第1段階—愚かさの山の頂上

Claude Codeについての記事を読みます。動画を見たかもしれません。すべてが明快に思えます。ツールをインストールし、プロンプトを書けば、コードが手に入る。記事の著者たちは「一晩でSaaSを作った」と語ります。あなたも一晩で作りたくなります。

頭の中の考え：

• 「だいたい分かった気がする。」
• 「ただのチャットで、少し賢いだけだ。」
• 「私は起業家だから、プログラマーはいらない。」
• 「1か月で習得して、ドバイに行こう。」

行動：

• Claude Codeをダウンロードしてインストールします。
• チャットに「予約アプリを作って」と入力します。
• 動かないコードが返ってきます。
• モデルが悪いと思い、Maxサブスクリプションを購入します。

始め方の1つの例です。期待が動く結果と結び付かないままだと不満が育つ場合があります。小さなプロジェクトと明確な検査で、具体的に学べる対象を作ります。

実践的な確認として、同じ成果を明確な基準で別の人にも見てもらってください。「AIの専門家」という自信ある自己紹介は、生成結果の品質の証拠ではありません。

最初の自信ある印象を仮説と扱い、コードを実行し、出力を調べ、その結果で自分にできることの見積もりを修正します。

第2段階—絶望の谷

さらに深く掘り下げます。MCPについて読み、サーバーを接続しようとします。既成のSkillをダウンロードし、理解しようとします。Plan Modeを起動すると、エージェントが計画を書きますが、3番目の手順で脱線します。~/.claude/を開くと、フォルダーが12個もあり、どれが何のためなのか分かりません。

頭の中の考え：

• 「自分は何もできない。」
• 「SNSの人たちはみんな嘘をついている。」
• 「ほかの人にできることが、自分にはできない。」
• 「始めるのが早すぎたのかもしれない。」
• 「トークンに$200も使ったのに、何が残ったんだろう？」

行動：

• ドキュメントのタブを一度に20個開きます。
• どのチャットも「前のコンテキストは忘れて」から始めます。
• 掲示板を見て、「Xがプロジェクトを壊した」といったスレッドを読みます。
• ClaudeとCursor、CursorとCodex、CodexとClineを比較します。ツール選びを間違えたと思います。
• 朝はコーディングしようと席に着きますが、昼食の時間にはもうフィードをスクロールしています。

つらい状況になる場合がありますが、この記事には離脱率の実測はありません。以下の兆候から、試す価値のある1つの変更を選んでください。

第3段階—啓発の坂

立ち止まります。ペースを落とします。新しいものに何でも飛びつくのをやめます。最初のCLAUDE.mdを書き、プロジェクトに置きます。business/フォルダーを作り、製品や価格、対象顧客の説明を入れます。/compactを10回試し、どのコンテキストを残すべきか、ようやく理解します。初めてのSkillを作ります。特定の作業に向けた、30行のものです。

頭の中の考え：

• 「ああ、こういう仕組みなのか。」
• 「1週間前にはできなかったことを、今日はできた。」
• 「business/とai-clone/の違いが分かってきた気がする。」
• 「タスクX向けのプロンプトが、もう手元にある。」

行動：

• 新しいタスクを始める前に、毎回Plan Modeに戻ります。
• Claudeに何かを書く前に、「これは自分のCLAUDE.mdに書いてあるか？」と自問します。
• 次の方法論のルールを探します。新しいツールにはもう気を取られません。
• チャットでほかの人を助けます。「自分もそこで詰まったよ。こうしてみて。」

第4段階—持続可能性の高原

ここは、すべてが簡単になる段階ではありません。知識と自信がようやく釣り合う段階です。

頭の中の考え：

• 「自分が何を知らないかは分かっている。」
• 「このタスクには3時間かかる。前にもやったことがあるから。」
• 「これは新しいSkillが必要だ。今作っておこう。」
• 「Claudeが計画から外れたら、考えられる理由は3つある。」

行動：

• 製品を着実に作ります。1つは一晩で、もう1つは週末に作ります。
• 自分専用のSkillsフォルダーとサブエージェントがあり、プロジェクトごとに自分専用のbusiness/があります。
• 自分では根本的に対応できない部分に限り、選んで業務委託します。
• 人の動画チュートリアルを見ることはほとんどありません。主に新しいアイデアを得るためで、基礎を学ぶためではありません。

自己評価チェックリスト—今、どの段階にいますか？

次の例は振り返りの手がかりです。

• まだ試していなければ、小さい動作結果を1つ確かめます。
• 設定が分からなければ、妨げるエラーや不足知識を特定します。
• CLAUDE.mdを使ったら、実際の動作の変化を確認します。
• 継続して製品を作れたら、見積もりと成果の記録を見直します。

段階を診断する得点表ではありません。

今、絶望の谷にいることを示す7つの兆候#

谷は突然やって来るわけではありません。少しずつ入り込んできます。兆候を見てみましょう。

1. 作るよりも、ツールの比較に時間を使う。「Cursor vs Claude Code」というタブを開きます。読み終えたら「Cline vs Cursor」を開きます。次に「Codex vs その他全部」です。比較するたびに「間違ったところを掘り下げているのかもしれない」と考えます。一日の終わりにはコードを1行も書かず、4時間が過ぎています。

2. 新しいチャットを始めるたびに「これまでのことは全部忘れて」と言う。 CLAUDE.mdがなく、/compactも使いこなせず、コンテキストウィンドウが何なのかも分かっていません。どのセッションも白紙から始まります。1週間後、Claudeに同じことを15回も説明したと気づきます。

3. プロンプトを集めるだけで、使わない。 Notionに「Claude Code Prompts」フォルダーを作りました。ブックマークが47個あります。2回使ったものは1つもありません。毎回、「これは絶対に必要なものだ」と思います。

4. ほかの人が「コネがあるから成功する」と考える。 SNSを開くと、週末に製品の最初のバージョンを公開した人がいます。「あの人にはチームがある。コネもある。自分には無理だ」と思います。その人は第4段階で、自分は第2段階だということは考えません。

5. 3日目にプロジェクトを放り出す。 新しいプロジェクトは「これはすごいものになる！」という期待で始まり、3日目に終わります。課題が「チャットで挨拶する」から「支払いを処理する」に進むと、離れてしまいます。難しいことをするのは怖いものです。

6. Claudeがうまくいかなかったから、ChatGPTで答えを探す。 Claudeの回答が悪かったので、ChatGPTを開きます。ChatGPTの回答も悪かったので、Geminiを開きます。依頼の書き方が悪かった可能性は思い浮かびません。いつもツールのせいだと考えます。

7. 「これは自分には向いていない」と自分に言い聞かせる。 これが最も厄介な兆候です。防御的な最後の言葉のように聞こえ、その後、人は立ち去ります。その考えは、学べないことより不満を表している場合があります。「谷」は比喩で、誰がそう感じ、その後どうなるかを示す実測の割合や固定期間はありません。

複数が当てはまれば、次に目指す小さな動作結果を1つ選びます。妨げを記録し、作業の1か所を変えてください。この一覧は改善までの期間を予測しません。

人々が谷で諦める理由—そして、それは怠けではない理由#

ツールへの不満は能力の信頼できる尺度ではありません。長く使うかを決める前に、タスクの大きさ、不足知識、実行環境を調べてください。

困った1週間から脳の仕組みを推測せず、試したこと、動いたこと、次を止めたエラー、時間を記録します。その記録から改善場所を具体的に選べます。

谷では、2つの打撃を同時に受けます。1つ目は、自分の進歩が期待に届かないこと。2つ目は、周囲の人が自分にはない成果を公開することです。SNSを開くと、誰かが製品の初版を公開し、誰かがエージェントを作り、誰かがClaude APIで初めての100ドルを稼いでいます。その間、自分は3週間かけてもデータベースすら接続できていません。

速く感じるかだけでなく、経過時間も測ります。エージェントは生産的に感じても確認と手直しを増やす場合があります。実感を実測の改善とせず、代表タスクを従来の流れと比較してください。

不慣れな仕事で遅くても、能力がないという証拠にはなりません。学ぶ負担とツールの成果を分け、確認できる小さい結果を定めます。

繰り返せる次の操作がないと、ツールを変えたり仕事をやめたりしやすくなります。以下の3本柱は筆者の提案する構造で、離れる理由を統計的に証明したものではありません。

3本の柱—谷から抜け出すための方法論#

ここで説明する著者の経験では、谷から抜け出すまでに3か月かかりました。その間に何十ものツールを試しました。そして1つのことが分かりました。問題はClaudeではありませんでした。毎回、白紙から始めていたことが問題でした。記憶も、ルールも、境界もありませんでした。

その後、フレームワークをまとめました。「3本の柱」と名付けました。この名前は、Claude Codeのワークフロー全体を支える3種類の構成要素を指しています。どれか1つでも取り除けば、フレームワークは崩れます。

柱1—あなたのAIクローン

AIクローンとは、Claudeが自動的に適用できる形式にまとめたあなたの専門知識です。

絶望の谷では、毎回「この作業を手伝って」とClaudeに書き、アプローチを最初から説明します。柱1はこの問題を解決します。あなたの方法論をai-clone/フォルダー内の一連のファイルに保存するのです。「顧客案件への対処法」をまとめたSkill、「Telegram投稿の書き方」をまとめたSkill、計画段階であなたのように考える「product architect」というサブエージェントを用意します。

柱1の実践例：

• Skills—特定のタスクに関する指示ファイル（/build-article、/build-reel-script）。
• サブエージェント—専門分野が異なるペルソナで、Claudeがそれぞれにサブタスクを委任します。
• ai-clone/feedback/フォルダー—失敗から学んだルールを保存します。各ルールはRule - Why - Howの形式です。

詳しくはSkills、Subagents、MCP、Pluginsのガイドで説明しました。何をいつ使うかを示す地図です。

柱2—セカンドブレイン

セカンドブレインとは、Claudeが直接アクセスできる、プロジェクト知識の体系的な保管場所です。

絶望の谷では、製品とは何か、対象顧客は誰か、ビジネスモデルは何かを、セッションのたびにClaudeに説明します。3週目の終わりには、同じことを15回も説明したと気づきます。柱2はこの問題を解決します。コードと一緒にファイルでプロジェクト知識を整理すれば、必要に応じてClaudeが自分で読みます。

柱2の実践例：

• CLAUDE.md—エージェントの入口です。動作ルールやパス、ほかのすべてへのリンクを記載します。
• business/フォルダー—製品、対象顧客、経済性、目標、コンテンツ計画、競合他社をまとめます。
• plans/フォルダー—各フェーズの技術計画と、それぞれのステータスをまとめます。
• retrospectives/フォルダー—同じ失敗を繰り返さないために、過去のセッションから得た教訓をまとめます。

全体の説明は、CLAUDE.mdの設定ガイドとClaude Codeでセカンドブレインを作るガイドをご覧ください。

柱3—コンテキストエンジニアリング

コンテキストエンジニアリングとは、Enterを押す前に、Claudeのコンテキストウィンドウに何を入れるか管理することです。

絶望の谷では、チャットで40件のメッセージをやり取りした後、Claudeが指示を「忘れる」理由が分かりません。/compactがなぜ必要なのか分かりません。「使わないほうが速い」とPlan Modeも開きません。柱3はこの問題を解決します。何をコンテキストに読み込むか、意図的に導きます。関連する入力を増やせますが、主張と出力は引き続き検証します。

柱3の実践例：

• Plan Mode—エージェントがまずタスクの計画を書き、あなたが承認してから実行します。使わない場合、最初の試みは混乱した結果になります。
• /compact—チャット履歴をスマートに圧縮します。コンテキストが埋まり始めたら圧縮し、重要な判断だけを残します。
• 構造化されたプロンプト—「手伝って」ではなく、「コンテキストAはこれ、タスクBはこれ、形式Cで結果を返して」と書きます。
• サブエージェント—新しいコンテキストにサブタスクを委任し、メインのコンテキストが過負荷になるのを防ぎます。

詳しくはコンテキストエンジニアリングのガイドとPlan Modeのガイドで説明しました。

なぜ1本ではなく3本なのか

セカンドブレインだけを作れば、Claudeはプロジェクトを把握できます。しかし、ルールのないインターンのように振る舞います。

AIクローンだけを作れば、Claudeはあなたの専門知識を引き受けます。しかしプロジェクトの記憶がないため、毎回のセッションが一から始まります。

文脈管理は入力を改善できても、順調な実行や知識の保持を単独では保証しません。しかし、タスク間で知識が蓄積されません。

3つすべてを組み合わせたときに初めて、私が「予測可能なフレームワーク」と呼ぶものが手に入ります。Claudeはプロジェクトを覚えています。あなたの方法論を自動的に適用します。そして、タスクの途中で話の筋を見失いません。

そこが、絶望の谷から抜け出す地点です。

谷にとどまらせる7つのアンチパターン#

自分の作業で確認するとよいアンチパターン：

1. CLAUDE.mdなしで「動くアプリを書いて」と頼む。 Claude Codeで新しいチャットを開き、すぐにタスクを指示します。Claudeにはプロジェクトや方法論、好みに関するコンテキストがありません。汎用テンプレートを返され、あなたはがっかりします。

対処法：CLAUDE.mdを作り、必要最低限の内容を入れます。技術スタック、ビジネスモデル、対象顧客、ほかのファイルへのリンクです。すべてのチャットが、このコンテキストから始まります。

2. /compactなしで長い会話を続ける。 80件のメッセージをやり取りするセッションを続けます。Claudeはメッセージ12で決めた内容を覚えていません。コンテキストウィンドウは重要な決定ではなく、迷いばかりの履歴でいっぱいです。回答の質が下がります。

対処法：30～40件のメッセージごとに/compactを呼び出し、何を残すべきか伝えます。コンテキストの焦点が定まります。

3. 最初の回答を信頼する。 Claudeが解決策を提示し、あなたはすぐに適用します。1時間後、ほかのファイルを3つ壊したことに気づきます。「またうまく動かない」と諦めます。

対処法：複雑なタスクではPlan Modeを使います。まず計画を立て、次に計画について話し合い、それから実行します。半日の作業をした後ではなく、計画段階で誤りを見つけられます。

4. 構成のない雑なプロンプトを使う。 Claudeが自分で理解すると期待して、「うまくやって」と書きます。しかし、あなたにとって「うまく」が何を意味するのか分からないので、Claudeは推測します。

対処法：「コンテキスト - タスク - 制約 - 形式」という構成でプロンプトを書きます。最初の試みで良い結果が得られる可能性が大きく高まります。

5. コストの追跡を無視する。 トークンをいくつ使っているか分かりません。月額プランが尽き、ダッシュボードを開くと、$200を使い切っていたと分かります。驚いて、やめてしまいます。

対処法：トークンの使用量を追跡するツールを設定します。ツールについてはトークン追跡ツールのガイドで検討しました。支出をリアルタイムで確認できれば、無駄にトークンを使わなくなります。

6. 「最適なツール」を際限なく探す。 Cursorが出るとCursorに乗り換え、Clineが登場するとClineを試します。CodexがアップデートされるとCodexに戻ります。2週間ごとに別のツールに移り、そのたびにやり直します。ツールが自分のために働き始める段階に、いつまでも到達しません。

対処法：ツールを1つ選びます。3か月使います。最初に理由を見つけたからといって乗り換えないでください。私は、自分のツールでは根本的にできないことがある場合にだけ、比較を調べます。

7. 「方法論を読む時間がない」と考える。 準備なしでもツールが動くべきだと思っています。プロンプトを書く力は生まれつきのものだと思っています。CLAUDE.mdは「余計な層」だと思っています。その結果、方法論があれば1週間で済ませられたことを、2か月目になっても続けています。

対処法：Claude Codeも、ほかのプロ向けツールと同様、習得が必要だと受け入れます。方法論を通じて学びます。ここでは直感は役に立ちません。

関連項目：Claude Codeのおべっか使いに関するガイドでは、Claudeが自分の考えに同意すると常に正しいと思い込む、谷で最大の誤解を避ける方法を説明しています。

啓発の坂にいることを示す5つの兆候—谷を抜けたと分かる方法#

第3段階にいることを示す5つの兆候です。

1. 200行を超えるCLAUDE.mdがあり、意図的に手入れを続けてきた。 テンプレートからコピーしたのではなく、自分で積み上げました。すべてのセクションと、その理由を知っています。新しいパターンを見つけると、ルールを追加します。

2. 定型的でないタスクの前には、必ずPlan Modeをオンにする。 誰かに言われたからでも、単に自制しているからでもありません。計画がなければ1時間を無駄にして、誤った結果になると理解しているからです。「追加の手順」ではなく、反射的に行うようになりました。

3. 独自のSkillsとSubagentsのカタログがある。 GitHubからダウンロードしたものではなく、自分で作ったものです。自分の具体的なタスクに向けたものです。新しいタスクが以前のものに似ていると、プロンプトを一から書かず、自分のSkillを思い出します。

4. 作業のペースが安定した。 「このようなタスクには3時間かかる」と分かるようになりました。「これはすぐ終わる」でも「いつまでかかるんだ」でもありません。時間を現実的に見積もれています。時間の予測と実際の成果の一致を、引き続き記録して確認します。心理的な段階を抜けた診断ではありません。

5. 人から質問されるようになる。 チャットで誰かがMCPについて尋ねると、具体例を添えて「自分のときはこうなりました」と答えます。誰かがPlan Modeについて尋ねると、自分の例を見せます。これは方法論を習得した結果です。谷にいる人は、あなたの経験に自分の経験を重ね、相談に来ます。

これらは最近の進歩を振り返るために使い、点数や高原へ届く時期を割り当てません。見積もりと動作結果が次第に一致するか、繰り返し確認してください。

高原では、エージェントを使うフレームワークにおける人間の役割が変わります。

これが、谷を抜ける旅の成果です。もう「プロンプトの書き方を学んでいる」のではありません。エージェントのフレームワークを管理し、プロセスの設計者となり、全体を率いる人になります。

今すぐ気持ちが折れそうなときにすること#

次のタスクで試す3つの手順です。

手順1—今の段階を声に出して言う。 自分にこう言いましょう。「私は絶望の谷にいる。これは今の作業で困っている部分だ。具体的な妨げを言葉にし、より小さい次の操作を選べる。」段階に名前をつけると、「自分だけの大惨事」ではなく、「曲線上の今の位置」になります。

手順2—ペースを落とす。 プロジェクトを1つ選びます。2つでも3つでもなく、1つです。3本柱から1本選びます。このプロジェクトで最も多くの問題を解決する柱です。プロジェクトが新しく、コンテキストが何もないなら、セカンドブレイン（CLAUDE.md）を選びます。プロジェクトは存在するのにClaudeが「自分らしく」動かないなら、AIクローン（Skills）を選びます。タスクが長く、コンテキストが埋まりつつあるなら、コンテキストエンジニアリング（Plan Mode + /compact）を選びます。

プロジェクト1つ、柱1本、2週間です。週末にすべてを作ろうとしないでください。それでは谷に逆戻りです。

手順3—仕組みを整える。 自分で方法論を作ることもできます。ここで説明する著者の経験では、3～6か月かかりました。

モデルを使い続けるには、Ailootにアクセスしてください。