企業がAIエージェントを利用する場合、LLM（大規模言語モデル）さえあれば業務が完結するわけではない。そこでトゥイル氏は、AIエージェントを業務で動かすために必要な仕組みの全体像として「エージェント型ソフトウェアスタック」を示す。これは、AIエージェントが業務を実行するための仕組みを階層的に整理したものだ。AIが参照する情報を管理する機能や、外部のツールやシステムと連携するためのMCP（Model Context Protocol）、メモリ、特定業務の手順を定めるSkillsなどがあり、それらを組み合わせて一連の業務を実行する「ワークフロー」を構成する。

　特に企業のソフトウェア開発は、「仕様を決め、設計し、タスクに分解して実装する」という単純な流れでは終わらない。

　製品戦略や成功指標の策定、市場調査、顧客調査、データ準備、データパイプライン構築、アプリケーション開発、インフラ構築、リリース後の運用や障害対応など、多数の工程が存在する。さらにモバイルアプリケーション、社内システム、顧客向けサービスなどによって開発プロセスも異なる。

　同氏は、フックやMCPサーバ、サブエージェントなどもワークフローを構成する重要な要素だとした上で、「最終的には、組織のノウハウの多くがSkillsのレベルに存在する」と指摘する。Skillsを適切に構造化できなければ、AIエージェントの処理を一貫したものにすることが難しくなるという。

「社内ルール」をAIが実行できる形にする

　Skillsの特徴は、単にAIへ長い指示を与えることではない。トゥイル氏によれば、組織で利用するSkillsには「再利用可能」「モジュール化」「発見可能」「ポータブル」「特定業務への特化」「組み合わせ可能」「一貫性」といった設計原則が必要になる。

　1つの巨大なSkillsに多数の業務を詰め込むのではなく、特定のタスクごとに分割することも重要だ。複数のSkillsを組み合わせても重複や競合が起きないように設計する必要がある。

　例えば顧客データを扱うAIエージェントを考えてみる。

　企業にはデータ保持ポリシーだけでなく、情報開示の基準、GDPR（一般データ保護規則）などの規制、所定のテンプレートといった複数のルールが存在する。これらをSkillsとして整備すれば、AIエージェントが処理を実行する際に必要なルールを呼び出し、レビュー工程に組み込める。

　トゥイル氏は、このような仕組みを使えば、実行結果について監査レポートを残したり、改善が必要な箇所を特定して開発工程へ戻したりできるワークフローを構築できると説明した。

　言い換えれば、これまで社内文書や担当者の頭の中に存在した「この業務ではこう処理する」というノウハウを、AIエージェントが実行できる単位として管理する考え方だ。

Skillsを放置すると「新たな技術的負債」になる

　ただし、Skillsを各チームが自由に作ればよいわけではない。

　トゥイル氏が問題視するのが、ガバナンスなしでSkillsが増殖することだ。「Skillsを管理しなければ、新しい種類の技術的負債を作り始める」と同氏は指摘する。

　代表的な問題の1つが重複だ。

　同じ技術スタックやインフラを利用する複数のチームが互いのSkillsを把握できなければ、同じ処理を実行するSkillsを各チームが別々に開発することになる。

　品質維持も課題になる。作成時には正常に動作していたSkillでも、その後登場する新しいAIモデルで継続的にテストしなければ、時間とともに期待通りの結果を出さなくなる恐れがある。

　さらに「誰がそのSkillを管理するのか」という所有者も明確にする必要がある。

　トゥイル氏はこの仕組みを、マイクロサービスなどを管理するサービスカタログになぞらえる。サービスカタログを見れば、サービスの所有者や関連情報が分かる。同様にSkillsについても、利用可能なものを検索し、所有者や状態を確認できる仕組みが必要だという。

公開Skillsの利用にはセキュリティリスクも

　情シスやCISOが特に注意すべきなのが、Skillsそのもののセキュリティだ。

　トゥイル氏は、公開されているSkillsを利用する際には注意が必要だと指摘する。一部のSkillsには、プロンプトインジェクションが仕込まれている可能性があるためだ。

　さらにSkillsには、処理を確実に実行するためのスクリプトが含まれる場合もある。このため、外部から取得したSkillを十分に検査せず実行すれば、安全でないコードを組織内に持ち込む恐れがある。Skillsを取り込む際には、セキュリティを確認するパイプラインが必要になる。

　アクセス権限も同様だ。全てのSkillsを全従業員が利用できるようにすべきとは限らない。Skillsの中には企業固有の業務ロジックなど、機密性の高い情報を含むものもあるためだ。誰がどのSkillsを利用できるのかを制御する仕組みも必要になる。

「個人→チーム→全社」の3段階で管理する

　では企業はSkillsをどのように管理すればよいのか。トゥイル氏は、個人、チーム、組織という段階を踏んで利用範囲を広げる考え方を示す。

　まず個々のエンジニアがSkillsを作成、テスト、改善して利用できる環境を整える。ただし、作り方を各人の判断だけに任せるのではなく、一定の構造やツールを組織として決めておく。

　次に、作成したSkillsをチーム内で共有する。同じ技術スタックや製品を扱うメンバーが共同で改善することで、Skillsを継続的に育てられる。

　そして全社展開で必要になるのが「中央集約型のプラットフォーム」だ。

　トゥイル氏によれば、このプラットフォームには、Skillsを検索・発見するためのメタデータ付きカタログを用意する。さらにSkills間の依存関係、バージョン、ライフサイクルを管理し、IDE（統合開発環境）などから必要なSkillを取得できる仕組みを整える。

　アクセス制御に加え、Skillsが期待通り機能しているかを測る評価機能やオブザーバビリティも必要だという。

AIエージェント時代の「社内標準」をどう作るか

　SkillsはAIエージェントを構成する一要素に過ぎない。トゥイル氏は、Skillsだけを整備すれば十分なのではなく、Skillsを含むワークフロー全体にも同じ考え方を適用する必要があると指摘する。

　例えばインフラを構築したいエンジニアが、中央プラットフォームに登録された標準ワークフローを呼び出し、必要なSkillsと組み合わせて実行する。改善が必要になれば、その変更を中央へ還元する。このような仕組みを作れば、AIエージェントを使った業務そのものを組織資産として蓄積できる。

　トゥイル氏は、今後さらに重要になる領域として、Skillsの評価や、Skillsを自動的に改善、進化させる仕組みを挙げる。

　ただし、自動改善が進むほどガバナンスの重要性は高まる。管理されていないSkillsが自動的に変更され続ければ、品質やセキュリティの問題まで増幅する恐れがあるためだ。同氏は、自動的にSkillsを進化させる前に、組織としてガードレールを整える必要性を強調する。

本稿は、AI Engineerが2026年8年29日に公開したAI-Native Organisations Run on Skills: How to Structure and Scale Them — Imad Touil, QuantumBlackを基に作成しました。