「AI エージェントに手順書（スキル）やメモを渡しているのに、肝心の仕事で使ってくれない」「スキルが増えるほど、関係ない手順が混ざって判断がぶれる」。AI エージェントを業務で使い始めると、こうした悩みにぶつかります。
この記事では、キーワード検索でスキルを選ぶ方式がどこで失敗するのか、代わりにどう渡せばよいのかを、実際に起きた誤りと一緒に紹介します。
アストラルコードでは、AI 社員（AI エージェント）が定期業務やチャットで働く社内基盤を自社で運用しています。この記事は、2026年10月中旬にその基盤の「メモ」と「スキル」の渡し方を作り直したときの記録をもとに書いています。
AI エージェントに合うメモやスキルが届かないのはなぜか
原因は、AI の賢さではなく「渡し方」にありました。点検すると、渡す側の作りに3つの穴が見つかりました。
メモは会話の最初の1回しか入っていなかった
メモ（社員ごとの覚え書き）は、仕事ごとではなく、会話ごとに1回しか入っていませんでした。
会話の始めにまとめて入れる作りだったので、同じ会話で2件目、3件目の仕事を頼んでも、その仕事に合ったメモは届きません。
直したあとは、続きの会話でも、その仕事の文面に合うメモを最大6行入れるようにしました。同じ会話ですでに渡した行は省きます。本番で同じ会話に違う仕事を2つ送ったところ、それぞれ違う6行が入ることを確かめました。
メモは「いつ入るか」まで見ないと、書いても使われません。
Claude 以外の AI には、スキルの本文を全部入れていた
Codex や Cursor で動く社員には、割り当てたスキルの本文をすべて入れていました。
Claude Code には、スキルの名前と説明だけを先に見て、必要なものだけ本文を開く仕組みがあります。ほかの AI にはこの仕組みがないので、本文を丸ごと渡していました。これはトークンの無駄になるうえ、関係のない手順が判断を邪魔します。
当時、社内のスキルは145本ありました（英語123本・日本語22本）。1人の社員に割り当てるのはその一部ですが、数が増えるほど無駄も増えます。
全部渡すのは、何も渡さないのとは別の形で、仕事の邪魔になります。
失敗の教訓が、手順書ではなくメモに溜まっていた
失敗から学んだ教訓は、メモではなく手順書（スキル）に書き戻すべきでした。
過去の実行記録からスキルを直す研究（SkillRefiner）では、失敗から作った直しが効いていて、それを外すと成績が8ポイント下がったと報告されています。手順書の中に入っていれば、同じ作業をするときに必ず目に入ります。
そこで、教訓はその社員のスキルに書き足す形に変えました。最初から組み込まれているスキルや、ほかの社員と共有しているスキルは書き換えず、その社員専用の「教訓スキル」を作って書きます。書き直す前の版は控えとして残します。
教訓は、使う場所の近くに置くほど効きます。
キーワード検索で選ぶのをやめて、モデル自身に選ばせた
最初の案：単語の重なり（BM25）で上位3本を選ぶ
最初は、仕事の指示文とスキルの単語の重なりで点を付けて、上位3本だけを渡す方式にしました。
BM25 は、単語がどれだけ重なるかと、その単語がどれだけ珍しいかで点を付ける、昔からある検索の方法です。学習がいらず、速く、仕組みも説明しやすいので、最初の選択としては自然でした。
全部入れていた本文を3本に絞れば、トークンは大きく減ります。
「関係ありそうなものを機械的に選ぶ」こと自体は、筋のよい考えに見えました。
本番で出た失敗：「via」と「とき」で無関係なスキルが上位に来た
ところが本番で試すと、関係のないスキルが上位に来ました。
BM25 は意味を見ず、単語の一致だけを数えます。日本語は単語の区切りがないので、2文字ずつに区切って照合していました。そのため、意味のない言葉でも一致してしまいます。
実際に次のことが起きました。
- 指示文に入っていた英単語「via」が一致して、関係のないスキルが上位に来た。
- 「とき」「する」のような言葉でも一致した。その結果、「会議で資料を読まずに発言しない」という教訓が、無関係な「うろ覚えの出典を探す」スキルに書き込まれた。
教訓の書き先を選ぶのにも同じ検索を使っていたので、誤りは「渡すスキルがずれる」だけでは済みませんでした。手順書の中身そのものが汚れてしまいます。
単語の一致だけで選ぶ方式は、言葉の多い日本語の指示文と相性がよくありません。
Claude Code と同じやり方に寄せた：目録を渡して、モデルに開かせる
検索で選ぶのをやめ、全スキルの「名前・説明1行・ファイルの場所」だけを並べた目録を渡して、どれを開くかはモデル自身に決めさせました。
Claude Code などのコーディングエージェントは、検索で決め打ちせず、一覧や grep で候補を見て、自分でファイルを開いています。モデルは指示文の意味を読めるので、「via」のような一致にはだまされません。目録は1本につき1行なので、本文を全部入れるより軽くすみます。
BM25 を予備に残す案も考えましたが、残すと誤った一致も戻ってくるのでやめました。教訓の書き先も同じ考え方で、週次の仕組みがスキルの目録を見て選び、合うものがなければ教訓スキルに入れます。
本番で確かめたところ、Codex・Cursor の社員とも本文なしの目録だけが渡り、モデルが必要なスキルを自分で開いて、手順どおりに答えました。
選ぶのは検索ではなくモデルに任せ、渡すのは軽い目録にする。これが今の形です。
次の一歩：仕事ごとに渡す中身を作り直す（JitMem で比較中）
似た成功例3件から、今回向けの短い指示を作る
もう一歩進めて、新しい仕事を始める前に、過去の似た成功例から「今回向けの注意点とやり方」を作って渡す仕組みを入れました。
もとにしたのは、Salesforce の研究（JitMem）です。記録を保存するときに要約するのではなく、生の記録のまま残しておき、新しい仕事が来たときにその仕事に合わせてまとめ直すほうが、成功率が最大16ポイント高かったと報告されています。
実装では次のようにしています。
- 仕事が終わるたびに、指示文・担当・結果・生の記録の場所を目録に1行足す。要約はしない。
- 新しい仕事の前に、過去の指示文から似た成功例を最大3件探す。
- その生の記録を軽い AI に渡し、今回向けの短い指示（1500字まで）に書き直させて、指示の先頭に付ける。
ここでは、似た例を探すのに BM25 を使っています。ただし、さきほどの失敗をふまえて、「今回の指示の単語の3割以上を含む」ものだけに絞り、似た成功例がなければ何も足しません。BM25 はどんな入力でも何かしら上位を返してしまうからです。それに、間違って選んでも渡るのは参考情報だけで、手順書は書き換わりません。
何でも検索で選ぶのではなく、誤ったときの害が小さい場所でだけ、歯止めを付けて使っています。
14日間、ランダムに「使う／使わない」で比べている（途中経過）
この仕組みが本当に効くかは、まだ分かっていません。なので、比べながら使っています。
自分たちの業務で効くかどうかは、論文の数字だけでは決められません。思い込みで「効いた」と判断しないよう、仕事ごとにランダムで「使う」「使わない」に分け、失敗の数と使ったトークンを比べています。期間は2026年10月15日から10月29日までの14日間です。
目録は、10月16日の時点で10行（使う7・使わない3）、10月18日の時点で27行（使う16・使わない11）になりました。今のところ全件が成功しているので、差はまだ見えていません。
結果が出たら、続きの記事で数字を報告します。
自社で試すなら、まず目録方式から
これから AI エージェントにスキルを渡す仕組みを作るなら、まずは「目録を渡してモデルに選ばせる」方式から始めるのがおすすめです。
作るのが一番簡単で、誤った一致で手順書が汚れることもありません。似た成功例を作り直して渡す方式は効果が期待できますが、記録を溜める仕組みと、効いたかどうかを比べる仕組みが別に要ります。
私たちも、①メモを仕事のたびに入れる、②目録で選ばせる、③教訓をスキルに書く、の3つを先に本番に入れ、動くのを確かめてから JitMem に進みました。同じ部分を2つの作業で同時に触らないための順番でもあります。
小さく入れて、動くのを確かめてから次に進む。この順番で十分です。
まとめ
- メモやスキルが届かない原因は、AI の賢さではなく「いつ・何を・どれだけ渡すか」という渡し方にあった。
- 単語の重なり（BM25）でスキルを選ぶと、「via」や「とき」のような意味のない一致で無関係なものが選ばれ、教訓まで違う手順書に書き込まれた。
- 全スキルの「名前・説明1行・場所」の目録を渡し、どれを開くかをモデルに選ばせる形に変えて、本番で手順どおりに動くことを確かめた。
- 過去の似た成功例から今回向けの指示を作る JitMem は、10月29日まで14日間の比較中。
スキルの渡し方は、使う AI の種類が増えるほど差が出ます。Claude・Codex・Cursor を同じ社内基盤で使い分けるときの設計は、関連記事「Claude・Codex・Cursorを同じ社内基盤で使い分けるには？マルチAIエージェント運用の設計と落とし穴」で詳しく紹介しています。あわせて読んでみてください。
