00:00
完璧な指示を出して、AIが最高の答えを返してくれた。
よし、このプロンプトを保存して、明日も使おう。
そう意気揚々とコピペしたのに、何か翌日は、AIが全く見当違いな幻覚を見始める。
あなたも、こんなフラストレーション、味わったことありませんか?
ああ、誰もが通る道ですよね。
今日は、あるITエンジニアがまとめた、2026年9月22日版の
AIエージェント日時速報という資料を深掘りしていきます。
はい。今回の探索のミッションですよね。
はい。まぐれあたりのAIの成功体験を、いつでも確実に呼び出せる、
技能、つまりスキルに消化させるメカニズムを解き明かすことです。
毎回ゼロから指示を書くなんて時間は、あなたにはないはずですからね。
よし、これを紐解いてみましょう。
資料を読んでハッとしたのが、過去の指示文を丸ごと保存するから失敗するんだっていう指摘です。
まさにそこが重要なんです。
これって、たとえるなら、すごくおいしくできた料理のレシピを保存したつもりが、
昨日の冷蔵庫にあった人参の数とか、その時の気分までガチガチに書き込んであって、
次に作る時にAIが、今日は人参3本ないですけど、みたいに混乱するのと同じ状態ですよね。
いやー、素晴らしい例えです。
AIの文脈理解力が高まるほど、その不要な条件の巻き込みっていうのが致命的なノイズになるんですよ。
やっぱりそうなんですね。
マヌスのようなAIエージェントの挙動を分析すると、
一時的な条件とか特定の入力地をあえてそぎ落とす工程が絶対に必要なことがわかります。
なるほど。レシピから、昨日の残りの人参を消して、任意の野菜という変数に置き換えるってことですね。
その通りです。そうしないと、過去の前提に引きずられてエラーを起こすわけです。
汎用性を持たせるために引き算をするんですね。
でも、変数をきれいに整理したとしても、AIに大量の指示を一度に読ませると、今度は別の場所で迷子になりませんか?
鋭いですね。そこで、コーデックスなどの開発環境で採用されている、段階的な開示というアプローチが重要になってきます。
段階的な開示ですか。
はい。最初から全手順を読ませるのではなくて、呼び出し用の説明文は極力シンプルにしておくんです。
ああ、なるほど。
そして、AIが今このスキルが必要だと判断したときに初めて、詳細な手順書を引っ張り出してくる仕組みですね。
情報型によるAIの集中力低下を防ぐわけです。
必要な時に必要な分だけってことですね。それに、作業によって呼び方を変えるのもすごく理にかなってます。
そうですね。
クロードコードの設計思想にあるように、コードの自動成形みたいな安全な作業は、AIに自動起動させてもいい。
でも、外部のデータベースを書き換えるようなリスクの高い作業は、人間が必ず手動で名前を指定して起動するという、このリスク管理、めちゃくちゃ大事ですよね。
03:00
本当にその通りです。ただ、ここで別の問題が浮上してくるんですよ。
個人の環境でそれを完璧に制御できるようになってもですね、それをチームの運用に持ち込んだ途端に、新たな壁にぶつかるんです。
え、どういうことですか?完璧なスキルが完成したら、それをチームの共有ホルダーに放り込めばいいだけじゃないんですか?
まあ、そう思いますよね。
私がレシピをアップデートすれば、みんな勝手に最新の美味しい料理が作れるようになるでしょ?違うんですか?
実はそこが最大の罠なんですよ。例えば、ジェンスパークのようなチーム共有プラットフォームの構造を見てみるとですね、
作成者が元のスキルを更新しても、利用する側の各メンバーが手動で最新版を同期するという操作を行わない限り、手元にある古いバージョンが使われ続けるんです。
うわ、じゃあ私はバージョン3のレシピを使っているのに、隣の同僚はずっとバージョン1の失敗レシピで料理し続けているなんてことが起きるんだ?
そうなんです。さらに、システム環境が複雑化すると、同名ファイルの衝突というもっと恐ろしい現象が起きます。
同名ファイルの衝突ですか?
2026年11月に旧ワークフローの廃止を控えるGoogleアンタルティカとかオープンクローのディレクトリ構造の仕組みを想像してみてください。
はいはい。
AIは指示を探すとき、上の階層の引き出しから順番に探していくメカニズムになっているんです。
ということは、上の引き出しにたまたま同じ名前の古いレシピカードが残っていたら?
はい。AIはそれを見つけた時点で探索をやめてしまって、古いレシピを実行してしまうんです。
へー、じゃあ私が一番下の引き出しにどれだけ完璧な最新のスキルを置いても?
永遠に呼ばれることはありません。
こわっ。だから、ただ共有するだけじゃなくて、正しい版が呼ばれるかテストするまでがセットなんですね?
まさにその通りです。
ここで資料にあったヘルメスエージェントが提唱している指針がカチッとはまりました。何でもかんでもスキルに詰め込むのが間違いなんだなって。
そうですね。そこが重要ポイントです。
文章ベースの指示で完結するものはスキルで、厳密な計算や外部とのAPI連携を担うものはツールとして完全に切り離すべきなんですね?
はい。
レシピとオーブンの温度設定機能をごちゃ混ぜにするなってことですね?
その解釈で間違いないでしょう。AIの柔軟な文脈判断に任せる領域と機械的な正確さを担保する領域ですね。
ねー。
この境界線を明確に設計することこそが、真に再利用可能なシステムを生み出す鍵になります。
面白い。資料の最後には再利用技能カードという実践的なフォーマットが紹介されていますよね?
はい。あれは非常に実用的です。
あなたも次にAIを使うときは、ただ履歴を残すのではなくて、機動条件や変わる変数を整理したこのカードの試行法を試してみてください。
あなたの作業効率が劇的に変わるはずです。
06:00
そうですね。一度きりのまぐれあたりから、いつでも取り出せる確固たる技能への進化ですね。
はい。ただ、これだけ私たちが手作業で完璧なスキルの型をせっせと定義していますが、最後にもう一つ、ちょっとゾクッとする疑問が浮かんだんです。
何でしょうか?
いずれ、AI自身が私たちの対話履歴を勝手に分析して、私たちに無断であなた専用のスキルを裏側で自動生成したり、古いものをこっそり削除したりする日が来るのではないでしょうか?
ああ、私たちがエージェントを使いこなしているつもりが、実はAIの側が密かに私たちの行動をプロファイリングし、最適化を進めている。
はい。
十分にあり得る、少し恐ろしい未来ですね。
次にあなたがAIを立ち上げた時、AIはもうあなたが気づかない新しいスキルを用意して待っているかもしれません。
それでは、また次回の探索でお会いしましょう。