Untitled

2026-03-30

source: "https://x.com/yusuke_post/status/2027348800331972703" tags:

"clippings"

整理日: 2026-03-16

最近話題のSkills という機能がある。特定タスクの手順書を.mdファイルで定義しておくと、Claude Codeがそれを参照して作業してくれる。

使い始めてすぐ思ったのは、「このSkills、どう書けばいいのか正直わからない」ということだ。あれこれ手動で書いては試すを繰り返すより、自動で改善できないかと考えた。そのアイデアのヒントは、プロンプト最適化の研究にあった。

構造図

flowchart TD
    A["テキスト勾配"]
    A --> B["数文程度のプロンプト"]
    B --> C["なぜ違うのか"]
    C --> D["示す"]
    D --> E["どう計算するか"]
    E --> F["ROI試算を含める"]
    style F fill:#c05746,color:#fff,stroke:none

やったこと

アイデアはシンプルだ。「**過去に人間が作った完成品を正解データとして使い、Skillを実際に動かして生成物と正解データの差分を自動で分析して、Skillsを改善し続ける」**というものである。

手順は以下だ。

①適当に作った”初期化されたSkills”を用意する。

②そのSKillsを実際に実行してみる。入力にはタスクを解くために必要なコンテキストを用いて”成果物”を生成する。

③その”成果物”と人間が作った”完成品”を比較し、「何が違うか」「なぜ違うのか」を自然言語で記述する。これがテキスト勾配になる。

④テキスト勾配をもとにSkillを書き直す。

以上の②〜④を繰り返す。

重要なのは、②ではSkillsを生成するときには人間が生成した正解を参照しないことだ。”タスクを解くために必要なコンテキスト”だけを見て生成する。Skillの改善が出力の品質向上として純粋に現れるようになる設計だ。

正解データは新しく作る必要はない。社内に眠っている過去の完成品がそのまま使える。では実際に動かすとどうなるか以下に実験してみた。

実際にやってみた

実験タスクとして**「ヒアリングメモからSaaS導入提案書を作成する」**を選んだ。社内で繰り返し発生する資料作成タスクの典型例として選んだ。入力は現場から集めたヒアリングメモ、正解データは過去にベテランが実際に作った提案書。案件の種類（CRM・会計・PM・セキュリティ）を変えて4セット用意し、同じSkillで全案件を評価しながら5回改訂を繰り返した。（今回は、この学習元のデータセットもClaude Codeに生成させた。）

用意した実際のデータの中身の例。右が入力で、理想の出力は左。

”テキスト勾配”を計算するための評価指標として、定量的に評価するためのプロンプトも事前に用意しておいた。6つの評価軸で、それぞれ0~100で評価できるようにしておいた。

初期のSkill

初期のSkillsでは、「含める」「示す」「まとめる」。指示はあるが、どうやるかは書かれていない。明らかに”ちゃんとしていないSkills”であることがわかる。

今回は改善するステップを4回実行した。それぞれのステップでの結果を以下に述べる。実際にどんどん改善していく様子がわかる。

### イテレーション1（+8.4点）

出力と正解を比較すると、ROI試算が全案件で定性的な一文に終わっていた。「10億円規模の潜在価値があります」というように。データセットの正解は項目別に積み上げて投資回収期間まで計算していた。Skillに「どう計算するか」が書かれていないのだから当然だ。テキスト勾配はこの問題を特定し、Skillに計算手順を自動追加した：

これで+8.4点。最大の改善はここで起きた。ただし、次のループで新たな問題が浮かび上がった。

### イテレーション2（+3.8点）

セキュリティ案件で致命的なミスが起きた。ライセンス費だけで比較した結果、本来推奨すべきでないツールが選ばれていた。実際にはMDR（24時間監視の外部委託）費用を含めると逆転するのだが、Skillにその知識がなかった。さらに、エグゼクティブサマリーの「14ヶ月」とROI計算の「7.6年」が同じ提案書に並存するという矛盾も発生した。今度のテキスト勾配はこれらを検出し、2つの指示をSkillに追加した：

### イテレーション3（+1.4点）

さらに数値の整合性確認と、セキュリティ案件固有の計算ロジックが追加された：

最初の一行だった「ROI試算を含める」が、計算フロー・ドメイン別の周辺コスト・処理順序・整合性確認・業界固有の計算ロジックを備えた手順書に育っていた。これを人間が最初から書くのは難しいのではないだろうか。何が重要かは、実際に出力と正解を比較してみないとわからないからだ。

イテレーションごとのSkillsの実際の変化がこちら。右から１、２、３、４ステップ後のSkillsの実際の内容である。

４ステップ後に最終的にできたSkillsがこちら。

結果

スコアの推移は以下の通りだ。

13.6点の改善のほとんどは最初の2イテレーションで起きた。3回目以降は収穫逓減で、4回目はわずかに退行した（過学習？）。Skillは自動でノウハウを獲得し、品質は実際に上がった。

使い所

この方法が向いているのは、繰り返し同じ種類の資料を作るタスクだ。提案書、報告書、要件定義書などがこれに該当するかもしれない。

この手法を実行するための条件は2つ：入力素材があること、過去に人間が作った完成品があること。

過去に作った提案書など、完成品さえあれば正解データになる。アノテーションも専門家も不要で、Skillは自動で育てることができるかもしれない。

参考文献

- Shin et al., "AutoPrompt", EMNLP 2020

- Zhou et al., "Large Language Models Are Human-Level Prompt Engineers", ICLR 2023

- Pryzant et al., "Automatic Prompt Optimization with 'Gradient Descent' and Beam Search", EMNLP 2023

- Yang et al., "Large Language Models as Optimizers", arXiv 2023

- Khattab et al., "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines", arXiv 2023

関連研究

構造図

やったこと

実際にやってみた

初期のSkill

結果

使い所

参考文献