上位モデルを「管理者」ではなく「アドバイザー」として使う ― Claude Code の advisor スキル

Claude Code で作業していると、たまに沼にハマる。同じエラーを2回直しても直らない、仮説が外れ続けて次に何を見ればいいか分からない、設計判断に確信が持てない ― そういう瞬間だ。

こういうとき、上位モデル（今回は Fable）に全部任せてしまう手もある。でもそれだとコストが高いし、メインのセッションが把握していない変更が勝手に入り込んで、かえって混乱することがある。

そこで採ったのが「上位モデルをアドバイザーとして使う」というアプローチ。日常の作業は通常モデルで回し、行き詰まったときだけ上位モデルに診断と助言だけもらう。実装と責任はメインセッションに残したまま、高い推論力だけを借りる、という発想だ。

この記事では、その仕組みを advisor スキルとして実装した内容をまるごと共有する。CLAUDE.md と SKILL.md はコピペでそのまま使える。

考え方：アドバイザーは「実装しない」

ポイントは1つだけ。アドバイザーはコードを調査して診断・助言を返すだけで、変更は一切加えない。

なぜか。実装までアドバイザーに任せると、メインセッションが知らない変更が混ざり、一貫性と説明責任が崩れる。だから役割を明確に分ける。

アドバイザー（上位モデル） … 読み取り専用で調査し、原因の診断と対応方針を助言する
メインセッション（自分） … 助言を検証し、実際にコードを直す

「管理者」ではなく「相談役」。この線引きが全体の肝になっている。

いつ相談するか

軽い問題でいちいち呼ぶとコストがかさむ。目安はこう。

同じエラー・テスト失敗を 2回修正して直らなかった
仮説が外れ続けて、次に何を確認すべきか分からなくなった
複数の設計案で迷い、トレードオフの判断に確信が持てない
ユーザーに「アドバイザーに聞いて」と明示された

逆に言えば、まず自力で1〜2手試す。それでも進まないときに呼ぶ。ただし、3回目・4回目の場当たり的な修正を積み重ねるくらいなら、早めに相談したほうが結果的に安い。

セットアップ①：グローバル `CLAUDE.md`

まず、行き詰まったときにこのスキルを起動するよう誘導する一文を ~/.claude/CLAUDE.md（全プロジェクト共通）に置く。特定プロジェクトで強く効かせたいなら、そのプロジェクトの CLAUDE.md にコピーしてもいい。

# アドバイザーの利用

苦戦しているときは、一人で粘り続けずに `advisor` スキルを起動すること。上位モデル（Fable）がアドバイザーとして原因の診断と対応方針を助言してくれる。

起動の目安：

- 同じエラーやテスト失敗を2回修正して直らなかった
- 原因の仮説が外れ続けて、次に何を確認すべきか分からなくなった
- 設計・アーキテクチャの判断に確信が持てない

アドバイザーは助言のみ。実装は自分（このセッション）が行う。相談したこととその要点はユーザーへの報告に含めること。

セットアップ②：`advisor` スキル本体

次にスキル本体。~/.claude/skills/advisor/SKILL.md として保存すれば、全プロジェクトで使えるようになる。

description は少し「押し付けがましく」書いてあるのがポイント。スキルは放っておくと起動されにくい傾向があるので、トリガー条件を具体的に列挙して確実に発火させている。

---
name: advisor
description: 行き詰まった問題を上位モデル（Fable）のアドバイザーに相談するスキル。同じエラーやテスト失敗を2回修正して直らない、原因の仮説が外れ続けて次の一手が出ない、設計・アーキテクチャの判断に自信が持てない、調査が堂々巡りになっている──そんなときに必ずこのスキルを使うこと。ユーザーが「アドバイザーに聞いて」「Fableに相談して」「上位モデルの意見が欲しい」と言った場合も使う。アドバイザーは診断と助言のみを返し、実装はこのセッション自身が行う。
---

# Advisor — 上位モデルへの相談

行き詰まりを一人で抱え込まず、上位モデル（Fable）をアドバイザーとして呼び出して意見をもらうためのスキル。

アドバイザーは「管理者」ではない。コードを調査して診断・助言を返すだけで、変更は一切加えない。実装するのはあくまでこのセッション自身。こうする理由は、変更の一貫性と説明責任をメインセッションに残したまま、高い推論力だけを借りるため。アドバイザーに実装までさせると、メインセッションが把握していない変更が入り込み、かえって混乱する。

このスキルが起動された時点で、Fableサブエージェントの使用はユーザーに許可されている。

## いつ相談するか

- 同じエラー・テスト失敗に対して2回修正を試みたが直らなかったとき
- 仮説を立てて調査したが原因にたどり着けず、次に何を確認すべきか分からないとき
- 複数の設計案で迷い、トレードオフの判断に確信が持てないとき
- ユーザーに「アドバイザーに聞いて」と明示されたとき

軽い問題でいちいち呼ばないこと。Fableの呼び出しは時間もコストもかかるので、まず自力で1〜2手試し、それでも進まないときに使う。逆に、3回目・4回目の場当たり的な修正を積み重ねるくらいなら早めに相談したほうが安い。

## 相談のしかた

Agentツールで `model: "fable"`、`run_in_background: false`（結果を待ってから続けるため同期実行）を指定してサブエージェントを起動する。`subagent_type` は省略してよい（general-purposeで十分）。

サブエージェントはこの会話の履歴を一切知らないゼロコンテキストで始まる。だから相談プロンプトは必ず自己完結させる。以下の5点を漏らさず入れること：

1. **目的** — 何を達成しようとしているか（ユーザーの元の依頼）
2. **現状** — 何が起きているか。エラーメッセージや失敗するテスト名は要約せず原文のまま貼る
3. **試したこと** — これまでの試行それぞれと、なぜダメだったか。これが無いとアドバイザーが同じ袋小路を提案してくる
4. **関係ファイル** — 絶対パスで列挙。アドバイザーが自分で読んで確かめられるようにする
5. **訊きたいこと** — 具体的な質問。「どう思う？」ではなく「原因の仮説と、次に確認すべきことを優先順で教えて」のように

プロンプトの冒頭には、アドバイザーへの役割指示としてこの文面を入れる：

```
あなたは経験豊富な技術アドバイザーです。以下の問題について相談させてください。
ファイルの閲覧・検索・読み取り専用のコマンド実行は自由に行って構いませんが、
ファイルの編集・作成・削除、git操作、その他システム状態を変える操作は一切しないでください。
最終メッセージで次の3点を返してください：
(1) 原因の診断（根拠となるコード箇所つきで）
(2) 推奨する対応（具体的な修正方針。差分イメージがあればなお良い）
(3) その診断の確信度と、外れていた場合の代替仮説
```

## 呼び出し例

```
Agent(
  model: "fable",
  run_in_background: false,
  description: "ビルドエラーの原因相談",
  prompt: "あなたは経験豊富な技術アドバイザーです。（↑の役割指示をここに）

## 目的
Next.jsアプリに認証ミドルウェアを追加しようとしている（ユーザーの依頼）。

## 現状
`npm run build` が次のエラーで失敗する：
（エラー原文をそのまま貼る）

## 試したこと
1. middleware.ts のmatcherを修正 → 同じエラー
2. next.config.js のexperimentalフラグを外した → 別のエラーに変化（原文貼る）

## 関係ファイル
- C:\projects\myapp\middleware.ts
- C:\projects\myapp\next.config.js

## 訊きたいこと
原因の仮説と、次に確認すべきことを優先順で教えてください。"
)
```

## 助言を受け取ったら

- 結論を鵜呑みにせず、コードと照らして検証してから適用する。助言が実態と食い違っていたら従わない。アドバイザーも間違えることはある
- 実装はこのセッションが行う。アドバイザーに追加作業を頼むときも「調査と助言」の範囲に留める
- ユーザーへの報告には、アドバイザーに相談したことと助言の要点を含める。黙って使わない
- 助言どおりに直しても解決しなかった場合は、新しいAgentを立て直さず `SendMessage` で同じアドバイザーに続きを質問する（前回の調査コンテキストが残っているので、状況説明をやり直さずに済む）。その際は「何を試して、どう結果が変わったか」を伝える

使ってみる

セットアップは以上。あとは通常どおり作業して、沼にハマったら advisor スキルが自動で（あるいは「アドバイザーに聞いて」の一言で）起動する。

うまく発火するか試したいときは、新しいセッションでわざと詰まりそうなタスクを投げるか、明示的に「アドバイザーに聞いて」と言ってみるといい。起動しすぎ／しなさすぎがあれば、description のトリガー条件を調整すればチューニングできる。

まとめ

上位モデルは全部任せる管理者ではなく、診断と助言だけくれる相談役として使う
実装と説明責任はメインセッションに残す ― これで一貫性が保たれる
起動条件を絞ってコストを管理する（自力で1〜2手 → ダメなら相談）
相談プロンプトはゼロコンテキスト前提で自己完結させる（目的・現状・試したこと・関係ファイル・訊きたいこと）

「詰まったら上位モデルに丸投げ」でも「意地でも自力」でもない、ちょうど中間のワークフロー。よかったら試してみてください。