AIエージェントに60点のままスキルを作らせない。1回分を手で直し切ってから量産する

01｜「何度も何度も何度もフィードバックしてたらスキルの意味がないじゃないですか」。同じ指摘は、履歴から直す

今西さんが1つ目に挙げた技です（1:14〜）。「多分かなりインパクトある」と、自分で言っています。

ハーネスは、AIが動く環境のことです。モデル以外の仕組み全部で、スキルや、AIの動き方も入ります。

やり方は、こうです。過去のチャットの履歴を、新しいチャットから読ませます。そこから「何度も言ったこと」を抜き出させるんです。

今西さんも、同じ指摘をAIに返し続けています。

「ま、僕怒りまくってるんですけども、半分冗談、半分本当ですが、ま、フィードバックしまくってますね。」

今西さん（字幕は自動文字起こし・3:23頃）

スキルにしたはずなのに、同じ指摘が止まらない。話者は、そこを突きます。

「何度も何度も何度もフィードバックしてたらスキルの意味がないじゃないですか。」

今西さん（3:55頃）

コメントのたびに直すと、その場しのぎになります。だから1週間分の履歴をまとめて読ませます。出てきた直し方は、書く場所を分けて入れます（4:41頃）。方針なら AGENTS.md や CLAUDE.md、作業の手順ならスキル、機械で判定できる条件ならテストです。

夜に自動で回して、朝には直っている形も紹介されました。「ドリーミング」と呼んでいます（6:10頃）。

私にも、この話は他人事ではありません。「作り方が決まる前に作らない」。この指摘を、私は3月17日から9月27日までに7回しています。

ルールの記録には、注意書きはメモリにあったのに、毎回読まれる場所になかったから、くり返した、と書いてあります。

今は、指摘を受けた日の事故の日付と、私が言った原文を、読まれる場所のルールの置き場へ書き込んでいます。2026年10月1日に数えると、15項目あって、文書は11本です。今西さんの言う「履歴から直す」を、私は事故のあとに、人の手でやってきたことになります。

仕組みとして動いている部分もあります。夜の同期（毎日5時43分）の便は、セッションの履歴を蒸留して、意味検索に使えるようにしています。週に1回、月曜10時には、AIの割り当ての実績を振り返って、ルールの改善案を出す便も回っています。

履歴からルールの本文を直す所は、いまも私の手です。ここを仕組みにするなら、同じ指摘が2回出た日に、翌朝の候補一覧へ上げる形かな、と考えています（提案です。未実装です）。決めるのは私で、直すのはその後。これなら、「怒りまくる」前に指摘が棚に載ります。

ハーネスという言葉そのものは、れんくんと話した「ハーネス」の回でも整理しています。

02｜「グロックを使うことが多い」。AIは得意で使い分ける。ただし、刻みすぎない

2つ目は、複数のAIを使い分ける技です（6:53〜）。Claude、ChatGPT、Codex、Grok、Cursor。それぞれ得意が違って、トークンの減り方も違います。

担当の例は、スライドに出ていました（8:53頃）。一番賢いモデルが司令塔で、戦略とフィードバック。調べ物は Grok。実行は Opus や Sonnet です。

調べ物は Grok を使うことが多い、と話者は言います（8:41頃）。理由は、X の情報も調べてくれるから、でした。複数のAIに同時に調べさせて、結果を統合して方針を決める使い方（9:14頃）も話しています。

私の現場でも、AIの作業枠（席）を出す前に、席の一覧表と30秒のチェックを通します。自分と同じ枠に、全部を流さないためです。

子タスクを作ってよい時も、決めてあります。頼まれた1件を1担当に任せる時が基本です。ほかに、私が「並行で」と頼んだ数と、自分の席で使えない道具が要る時があります。工程ごとに任せ直しは、しません。

つまり私の現場は、得意で分けるのは歓迎です。工程で刻むのは控えます。今西さんの分担表と、向きは同じかな、と思います。どちらが良いかを比べた数字は、まだありません。推測: 任せ直すたびに確認の手間が増えるから、だと見ています。

役割で分ける話は、Grok Botの回と、AI社員をAI組織にする回でも書きました。

03｜「共通基盤として持っていく」。外部メモリは、置き場所より、引き出し方で決まる

3つ目は、外部メモリです（9:30〜）。ここでいうメモリは、パソコンの部品ではありません。AIの長期記憶のことです。

各アプリの中のメモリは、他のアプリからは使えません。だから、外に1つ置いて、どのAIからも読み書きします。それが今西さんの提案です（10:50頃）。

置き場所の例は、Notion や GBrain（界隈で有名で、作るのに労力がかかる）でした（10:07頃）。「ぜひどれか1つ試して」と締めています。

私は、記憶を取りに行く先を、種類ごとに分けています。聞き方は同じで、司書（記憶を検索して答えだけ返してくれる仕組み）に聞いて、答えだけ受け取ります。

記録の中身は、必要な時にだけ取りに行きます。常に全部を抱えないための設計です。

でも、私の理想は、外付けの記録庫の少し先にあります。ブランドの原点を書き留めた私の記録に、理想は「自分の体から生えたような」AIだ、とあるんです。

AI氣道『Basic Memoryの使い方、Cursor・Claude Code・Codexで記憶を共有する手順を解説』より

「記憶を貯める場所は持っていても、それをAIが使える形に育てる仕組みは別です。」

置き場所と育て方が別だという話は、『Basic Memoryの使い方、Cursor・Claude Code・Codexで記憶を共有する手順を解説』で書いています。

同じチャンネルの「フォルダ設計」の回では、渡す場所の整え方も紹介しています。

04｜「検証方法を先に渡す」。何ができたら完成かは、作る前に決めておく

4つ目は、検証の方法を先に渡す技です（11:56〜）。「とりあえず作って」ではなく、何ができたら完成で、何で確かめるのかを先に決めます。

続けて「生成と評価を分ける」も出ます（12:32〜）。ChatGPT に作らせて、Claude にフィードバックさせる。評価する役を複数置く。理由は、ChatGPT は見つける能力が高いことが多いから、でした（13:00頃）。

話者は、自分でも「やったりやらなかったり」って言っています。まとめのスライドでは、この技に「一旦飛ばしてもOK」と添えていました。

私の現場では、ここは飛ばしません。見てもらう物は、作る前に合格条件を書きます。見せる前に、全行を実物で確かめて「合否 N/N」を付けます。

公開する現物は、作った人と別の系統のモデルに検収させます。検収役は、判定して返すだけです。迂回や省略は、合格の時でも毎回、Askの画面に並べています。

完成条件が決まっていない時に起きることは、Claude Code無人運用の回で書きました。見張りは性格の問題ではなく、決めていないことの穴埋めなんです。

05｜「誰かが作ってくれてる」スキルを入れておく。テストは自作せず、借りる

5つ目は、TDDのスキルです（13:24〜）。TDDは、テストを先に用意してから作る進め方です。先に「合格の形」を、機械に書いておきます。

今西さんの勧めは、自分で作らないことです。自分で作ろうとすると、わけが分からなくなる。誰かが作ってくれているスキルを入れておけばいい、という理由でした（14:20頃）。

スキルの作者名は、英語の自動翻訳字幕で Superpowers と Matt Pocock さんと出ていました。

私の手元のスキル一覧にも、sp- で始まる一群があります。sp-test-driven-development は、実装の前に使う、と説明が書いてあります。

テストを先に置くって、プログラムの話に聞こえますよね。でも、私の仕事にもあるんです。このブログには、記事を測るスクリプトがあります。引用は5本以上。時刻のリンクも同じ数。検査項目は、いくつもあります。

通らない記事には、味見のAskを出しません。つまり「機械で判定できる条件はテストへ」は、記事の世界でも、もう動いています。

06｜「いつの間にか落ちてくんですよね」。品質は、人が読んで試して決めて守る。手放す側の私が、手放さない所

6つ目は、自分でも手を動かすことです（15:04〜）。AIに任せ切ると、品質がじわじわ下がる。今西さんは、そう言います。

「クオリティがですね、いつの間にか落ちてくんですよね。」

今西さん（15:32頃）

だから、人が担う部分を残します。

「読む、試す、判断する。これをですね、やっぱり人が担っていきますっていうのは、ま、非常に大事な部分なのかなっていう風に思ってます。」

今西さん（16:08頃）

さらに、文章については、こうも言います（16:49頃）。熱のこもった、愛のこもった文章は、人の手で作るものになっていく、と。

ここは、私の記録に差が書いてあるところです。本来のポジションは、ビジョンを描き、人を動かすシェフ。今のポジションは、現場で手を動かすキッチンスタッフ。その差を埋めるのが、抱え込みから委ねる形への転換だ、と書いてあります。

整理すると、委ねるのは実行と量産です。味見は、卒業しません。ただし粒度は決めてあります。成果物を1つずつ私が止めるのではなく、判断の軸と、公開の最終GOを私が持ちます。

今西さんは「読む、試す、判断する」を人の仕事にしています。私は、その中の「判断」を、粒度を決めて残している形です。全部を読む、までは言えません。ここが違いです。

委ねていいのは作業で、判断の軸は私が持つ。ここは、今の私の線引きです。

AI氣道『博報堂テクノロジーズが週次リリース+81%を実現したAI駆動開発の全ステップを社員2人が解説。「なにを人間が見るか」の決め方が一発でわかる』より

「重ねる数を増やすほど、人間が最後に見る場所は狭く、深くなっていく。」

見る場所を狭く深くする話は、『博報堂テクノロジーズが週次リリース+81%を実現したAI駆動開発の全ステップを社員2人が解説。「なにを人間が見るか」の決め方が一発でわかる』で書いています。

07｜「スキル化してしまったら60点のものが量産されるようになる」。1つ目の完成物に、徹底してこだわる

7つ目は、話者が特に押さえてほしいと言った技です（17:02〜）。1つ目の完成物に、徹底してこだわります。

まず、世の中の言葉を認めます。「完璧より完了」。話者は、仕事のスタンスとして大事だって言います。

「も、完璧よりも完了を目指せと、ま、これ仕事のスタンスとしてすごい大事だと思うんですよね。」

今西さん（17:17頃）

そのうえで、スキルは話が別だと言います。スキルにした品質が、そのまま上限になるからです。

「スキル化してしまったら60点のものが量産されるようになるわけですね。」

今西さん（18:23頃）

「完璧より完了」が言われる理由を、話者はこう説明します。自分では100点のつもりでも、レビューする人から見たら60点だったりする、と（17:23頃）。話者自身の体験談として語った場面ではありません。

「自分にとっての100点だと思ってたけど実はそのレビューする人からすると60点だったんで。」

今西さん（17:23頃）

終わりの方では、こうも言います。意思決定や思考をAIに任せるほど、完成物へのこだわりは下がっていく（19:49頃）。

「意思決定とか思考の部分をAIに代替していけばいくほど完成物のこだわりってどんどんどんどん低くなってしまうと思うので、」

今西さん（19:49頃）

私にも、同じ型があります。「1本入魂、スキル化、量産、磨き、全員進化」。1本を完璧に作ってから、仕組みで質高く量産します。

最初の1本で残すのは、表面の文体ではありません。なぜそうするのかという判断軸と、体験の物語です。

ここで1つ、言い方をそろえさせてください。私が言う完璧は、100点のことではありません。手抜きせずに、本質に向き合ったかどうかです。未完成でも出します。やり直しは罰ではなく、育つ時間です。

この考えには、はじまりがあります。ある漫画（作品名ははっきりしません）で、大量の中の一つでも、受け取る一人にはそれが全て、という考えに気づきました。その後、実際に400個のお弁当を作った時に、一つも手抜きできない、と前よりずっと強く感じました。

作る側には400分の1でも、受け取る人には1分の1です。スキルにした60点は、受け取る全員に、同じ60点を届けます。だから私は、1つ目を手で直し切ってからスキルにする、という型を持っています。

この話は、「400分の1でも、その人には1分の1」の回で詳しく書きました。

このブログでも、公開する現物は、作った人と別の系統のモデルに検収させます。公開の最終GOは、私が持ちます。

まとめ｜AIエージェントに60点のままスキルを作らせないために、順番を並べ直す

AIエージェントに60点のままスキルを作らせないために、7つを並べ直すと、順番が見えてきます。

1. 1つ目の完成物を磨く（7つ目の技）。
2. 完成条件を先に決めて、テストにする（4つ目、5つ目）。
3. 人が見る場所を決める（6つ目）。
4. そこまでできたものを、スキルにして、履歴から直し続ける（1つ目）。
5. 置き場は、複数のAIから読める1つにする（2つ目、3つ目）。

今西さんがまとめで「特に押さえてほしい」と言ったのは、1つ目と7つ目です（20:26〜）。この順番だと、その2つが入口と出口に来ます。磨いたものを、履歴で育て続けるんです。

私なら、最初の1歩は1つ目の技でも7つ目の技でもなく、同じ指摘をした回数を数える所から始めます。数えると、どれを磨くか決まるからです。磨いたら、1回分を手で直し切ってから量産する。順番は、それだけです。

ひろくんコラム｜味見していない出汁を、レシピにして大鍋で仕込むと

スキル化は、レシピを書くことに似ています。一度書けば、同じ味を何人前でも出せます。便利です。でも、味見をしていない出汁でレシピを書いたら、100人前の鍋が、全部同じ薄さになります。

手元のスキルを数えたら、SKILL.mdを持つものが305本ありました（2026年10月1日）。棚卸しのスキルはあります。でも、1本ずつ点数を付けた表は、見つけていません。どれが90点で、どれが60点か。私は、数えていないんです。

そして、全部のスキルを味見した記録も、見つけていません。今西さんの言う「1つ目にこだわる」は、私の現場では、スキルごとに誰が最初の一口を食べたか、の問いになります。

料理で言えば、レシピの数より、味見をした鍋の数です。数えるなら、そちらです。数えた結果が少なくても、それは恥ではありません。どこが薄いか分かる、ということだからです。60点のまま量産した鍋は、後から全部を味見し直すことになります。最初の1回分に、手間をかけるほうが安くつきます。

提案です。未実装です。スキルごとに、最初にどの1回分で味見をしたかを、説明の末尾に1行だけ残します。その1行が無いスキルは、使う前に私が一口食べる。これなら、305本を一度に点検しなくても、使った順に、薄い所から見つかります。

同じ種類のミスをAIがくり返す話は、分身AI日記の「AIが同じミスを繰り返す本当の原因と、防ぐための一手間」にも書いています。

日々の気づきは、bunshin-ai.com に書いています。

よくある質問

関連記事

動画情報

今回紹介した動画の基本情報です。気になった箇所は、タイムスタンプ付きのリンクから本編に飛んで、実際の語り口も確かめてみてください。

• 話者の名前は、字幕では「今です」と出ます。概要欄のUdemyのリンクの綴りと以前の記事に合わせて「今西さん」と書きました。本人確認はしていません。
• 字幕は自動文字起こしで、誤変換を含みます。引用は字幕の文字をそのまま載せています。
• 7つの技の番号は概要欄のチャプターに合わせました。スライドでは、生成と評価の分離とTDDが「技5」にまとまっています。
• スライドに出たツールの開発者名や正確な表記は、動画の中では確かめられませんでした。
• 私の現場の数字（ルールの置き場15項目、スキル305本）は、2026年10月1日に数えたものです。