AI関係者は最近何をしているのか？

私は先日、サンフランシスコで開催されたAI Engineeringカンファレンスに参加し、AI業界の現状について多くの洞察を得ました。講演は大きく二つに分かれました。参加者の85%は企業ユーザーで、組織内でAIをどう活用するかを学ぼうとしていました。残りの15%は真の最先端を行く人々で、自動化ソフトウェアの深淵を探り、ラヴクラフト的な恐怖を持ち帰ってきた人たちです（こんにちは、Dex！）。私は後者の割合がもっと多いと思っていたので、逆の偏りに驚きました。この高度に選別された環境（「AIエンジニアリング」カンファレンスに参加する可能性が最も高い約7000人）でも、大多数の人はAIを効果的に使う方法をまだ知らないのです。

AIの世界では毎月新しい話題が登場します。1月は離陸、2月は「スキルとは何か」、3月は「誰もがClaude Codeを使うべき」、4月は運用チームの巻き込み、5月はトークン最大化。そして6月は明らかに「スキルの乱立」の月でした。十数もの講演が「組織内で作成された1000のスキルをどう管理するか」というバリエーションで、これらはすべて満員でした。これは市場の大部分がどこにあるかを示しています。私の会社Noriでは、この問題を昨年12月に解決しました（noriskillsets.com参照。これはオープンソースのローカルスキルマネージャークライアント上に構築されたチーム全体のパッケージマネージャーです）。

しかし、これらの「スキル管理」講演の多くは私にはピンと来ませんでした。そんなに多くのスキルを持つことは「コードの悪臭」だと私は考えます。私の経験では、エージェントは基本原理から物事を理解するのが非常に得意です。スキルは1) ドリフトする、2) 実際には何も追加しないかもしれない、3) 管理が必要、という問題があり、問題を解決するよりもむしろ作り出す可能性が高いのです。率直に言って、組織内で何百ものスキルファイルを抱えているチームの多くは、従業員がコーディングエージェントにあらゆる種類のスキルを喜んで生成させているが、それらが有用かどうかを厳密に検証していないのだと思います。これは「AI活用」の見せかけを作り出しているに過ぎません。

また、エージェントにトランスクリプトを読ませて自動的にスキルを作成させる自己学習に関する講演が多かったのにも失望しました。コンテキスト管理に人間が関与しないプロセスはすぐに制御不能になります。これこそが、そもそもスキルが多くなりすぎる原因です。私の意見では、良いスキルをエージェントに任せることはできません。プロセスは意図的でなければなりません。私たちが効果的だと感じる特定のフォーマットがあります。スキルを単にまとめて検索サーバーを上に載せるのではなく、特定のグループにバンドルすることを好みます。エージェントとのすべてのプロンプトは、まるで虚から実体を召喚するようなものです。エージェントにバンドルされた特定のスキルは、最高品質の結果を引き出すための大きな要素です。エージェントの脳を「スロップ化」しようとすると、スロップを生み出すエージェントになります。避けるべきです。

評価（evals）について：この用語はAIではひどく過負荷になっています。研究者やモデルプロバイダーは「evals」を「SWE-Bench、Humanity's Last Exam、ARC-AGIのような、生のモデル性能を評価するためのベンチマーク」として使います。これらは人工的で、研究者にモデル訓練を改善するための指標を与え、業界にモデルの相対的能力を素早く把握させるために設計されています。一方、モデルを展開する業界の人々は「evals」を「プロダクションワークフローをできるだけ決定論的にするための回帰テスト」として使います。ここでの評価は非常にタスク固有で、「AIがデータを正しくラベル付けするか」や「カスタマーサービスチャットで敵対的な入力に正しく応答するか」などです。前者の使い方は最先端の人々にとってより重要ですが、後者が多くの大企業や聴衆が考えていることだと思います。

AIがさまざまな組織でどのように導入されているかを考えてみましょう。テック企業やスタートアップでは、従業員は主に開発ツールとしてAIと対話します。CursorやClaude Codeは開発者が一日中使うインターフェースです。平均的な開発者はAIと頻繁にやり取りするため、AIの能力をかなりよく理解しています。しかし、銀行や小売など他の業界では事情が異なります。エンジニアリングが明らかに重要な機能ではない組織（エンジニアリングがコストセンターであって収益源ではない場所）では、AIの主な使い方はインフラです。最も一般的な形はETLパイプラインです。これは定期的にテーブルからデータを抽出し、変換し、別のテーブルにロードするプロセスです。こうしたタスクは大企業では数多くあり、技術指向でない企業は外部コンサルタントに多額の費用を払って構築してもらいます。従来のETLパイプラインは脆く、APIやフィールドの調整に多くの手間がかかりました。LLMはその柔軟性により、この作業を大幅に簡素化すると約束しました。しかし、新しい技術は大規模で動きの遅い企業には一気に採用されません。代わりに、既存のものの補完や代替として導入されます。これが多くの企業でAIがETLの世界に落ち着いた大きな理由です。残念ながら、ETLを扱ったことがある人なら、データを好き勝手にいじれないことを知っているでしょう。これらのパイプラインは一貫性と監査可能性が必要ですが、AIエージェントはそのどちらでもありません。

これが評価に戻ってきます。大企業では、トークン最大化は「個人開発者にClaude Codeなどの無制限予算を与える」ことを意味しました。それ以外の場所では、「失敗しているETLパイプラインにさらにトークンを投入して、80%の正答率を100%に引き上げる」ことを意味しました。AIでそれをどうやって実現するか？ 素朴な方法の一つは、最初のAIの出力をチェックする別のAIシステムを構築することです。しかし、それが失敗したら？ では、二番目の出力をチェックする三番目のシステムを構築すればいい。しかし、その連鎖は明らかに問題です。現在トークン最大化は終わり、一部の技術力の低い企業は従業員の月間トークン使用量を50～100ドルに制限しています。

最後に、クラウドエージェントについて：Claude Codeをローカルで実行すると、マシンに固定され、セキュリティ上の大きな穴になり、調整やコラボレーションが困難です。クラウドエージェントはこれらの問題をすべて解決します。どこからでもアクセス可能で、集中管理によりセキュリティ、可観測性、ガバナンスが向上し、完全自動化されたビジネスへの必要なステップです。クラウドエージェントはイベントやタイマーに応答して自動的にタスクを実行できます。

このカンファレンスで、サンフランシスコとそれ以外の場所のギャップを痛感しました。最先端の人々はクラウドエージェントとRL環境について話していましたが、多くの聴衆は「それはいいけど、ETLをどうやって改善するか教えて」と思っていました。私のアドバイスは、AIシステムを100%正しくしようとせず、95%までAIにやらせて、残りを人間が確認することです。