Claude Code、GitHub Copilot、Codexといった主要なAgent Host上で、SKILL.md という1枚のファイルにタスクの手順を記述することでエージェントの振る舞いを拡張する「Agent Skills」が急速に広まっています。

一方で、現場でSkillの数が増加するにつれ、従来のソフトウェア開発では一般的な以下のような問いに対する管理上の課題が指摘されています。

• 「このSkillはいつ誰がどう更新したのか」
• 「どのバージョンが本番環境で動いているのか」
• 「障害発生時にどのように切り戻すのか」

こうした課題に対し、Agent Skillsを単なるプロンプトの集まりではなく独立したソフトウェアオブジェクトとして扱うための枠組み「Skillware」を提案した論文（Haodi Fan et al., 2026）が発表されました。本論文では、あるSkillが独立して管理すべきソフトウェアであるかを判定する3つの条件と、更新や削除を経ても同一の識別子を保持できているかを測定する指標が提示され、13万件を超える実データとケーススタディによってその妥当性が検証されています。

本記事では、対象論文の内容に基づき、以下のポイントを客観的に解説します。

• Skillwareが提示するオントロジー（用語体系）と3つの判定条件
• 妥当性を支える大規模コーパスと実装ケースの検証結果
• Skill設計時に参照できる6つの実装次元とデザインパターン
• Skillの成長・進化を管理する運用上のアプローチ
• 限界と今後の研究課題

1. Agent Skillsに「ソフトウェア」としての定義が必要な理由

ソフトウェアの振る舞いを形づくる3つの道筋

論文では、ソフトウェアが振る舞いを獲得するアプローチとして、従来の2つに加えた計3つの道筋が整理されています。

1. コード中心の道筋: 人間の意図をプログラミング言語に落とし込み、ソースコードとしてランタイム上で実行するアプローチです。
2. モデル中心の道筋: データと学習目標をもとにモデルを最適化し、得られたパラメータが推論時の振る舞いを形づくるアプローチです。
3. 振る舞い中心（behavior-centric）の道筋: 開発者が手順・制約・方針・具体例・評価基準などを自然言語のまま持続的に保存し、エージェントシステムがタスク実行時にその自然言語を直接解釈するアプローチです。

これら3つの道筋は互いに排他的なものではなく、1つのシステム内で共存可能であると説明されています。コード・モデル・自然言語による振る舞いソースが同時にシステムの振る舞いを構成している点が基礎的な捉え方となっています。

従来研究の課題: 共通語彙の欠如

著者らは、「振る舞い中心」の対象を扱う既存研究が数多く存在するものの、以下のように分析単位が統一されていなかった点を指摘しています。

• プロンプトの設計
• エージェントの推論・行動ループ
• Skillの仕様策定・実行・保守・進化

その結果、以下の要素を横断的につなぐ共通の語彙が不足していたと説明されています。

• Skillという振る舞いソース
• それを独立に管理する単位
• それを起動するアプリケーション
• それを解釈する実行系
• 実行によって得られるエビデンス

Skillwareの定義

「Skillware」という名称自体は、モジュール式のSkillフレームワークなど既存のAgent関連プロジェクトですでに使われていた呼称であり、本論文による新造語ではありません。

本論文の主な貢献は、プロジェクト横断で適用可能な操作的定義と、それを検証するためのエビデンスプロトコルを定式化した点にあると示されています。具体的には、以下の2つの問いに答える構成となっています。

• 「Skillwareとは何であり、隣接する概念と何が違うのか」
• 「その定義によって実際の肯定例・否定例・境界事例を分類できるのか」

2. Skillwareのオントロジーと3つの判定条件

振る舞いから成果に至る連鎖（オントロジーの構成要素）

Skillwareのオントロジーでは、振る舞いソースが最終的なタスク成果に至るまでのプロセスが、役割の異なる以下の5つの要素の連鎖として整理されています。

• Behavioral Source（振る舞いソース）: 手順・制約・方針・例・評価基準を記した自然言語そのものを指します。
• Skill Artifact（Skillアーティファクト）: 振る舞いを規定するSkill本体であり、起動・実行の対象となる形式にまとめたものを指します。
• Skillware Unit（Skillwareユニット）: アーティファクトを名前・バージョン・依存関係・来歴を持つ独立したソフトウェアとして管理するための識別子です。
• Agent Host（エージェントホスト）: ユニットを発見・受領し、起動の可否を判断してAgent Runtimeに引き渡すアプリケーションです（Claude Code、GitHub Copilot、Codexなど）。
• Agent Runtime（エージェントランタイム）: タスク・モデル・コンテキスト・ツール・権限・状態を踏まえ、実際にSkillソースを解釈して実行トレースを生成する実行系です。

ここで特に重要な区別として、以下の2点が挙げられています。

• Skillアーティファクト: 再利用可能な振る舞いを規定するもの
• Skillwareユニット: アーティファクトをソフトウェアとして管理する独立した識別子

単一の SKILL.md のみで完結する場合、これらは同じ実体を指します。一方で、複数の専門Skillやフック、テスト、外部連携用インターフェースを1つのパッケージにまとめる場合、1つのSkillwareユニットが複数のSkillアーティファクトを束ねる構造をとると解説されています。

Skillwareを定義する3つの判定条件（C1〜C3）

あるSkillが「Skillware」の定義に合致するかどうかは、同一ユニットに対して以下の3つの条件（C1〜C3）がすべて成立するかで判定されます。

• C1（振る舞いの主体性）: Skillソースがタスクの契約・手順・制約・関連コンポーネントとの関係を自ら組織しているか。
  • 満たさない例: Skillの内容がツールやインデックス、アプリケーションに単に付随しているだけの場合。
• C2（独立したソフトウェア識別）: 名前・バージョン・依存関係・来歴を持ち、Agent Hostから独立して取得・追跡できるか。
  • 満たさない例: 指示が単一セッション限りである場合や、内包するシステムと分離不可能である場合。
• C3（Agent Hostによる実行関係）: 少なくとも1つの互換Agent Hostが発見・起動・読み込み・利用できる実行経路を有しているか。
  • 満たさない例: ドキュメントやカタログ上の記述にとどまり、実際の実行経路が存在しない場合。

また、更新・保守・ロールバック・削除を経ても同一のユニット識別子が維持されているかを評価する指標として、Lifecycle Continuity（LC） が提示されています。C1〜C3が「Skillwareのカテゴリに含まれるか」を判定するのに対し、LCは「カテゴリに含まれた上で、どの程度ソフトウェアレベルの管理が行われているか」を測定する指標として区別されています。

なお、本論文における「AI-native」という用語は、「モデルによる解釈にタスクの振る舞いが依存しているソフトウェア」という限定的な定義で用いられており、ユニット内部に含まれる従来のコードやデータ、UIまでもが「AI的」であることを主張するものではないと補足されています。

肯定例・否定例・境界事例による分類

判定条件の適用例として、以下の分類が示されています。

• C1を満たさない例:
  • 外部Skillを一覧表示するだけのインデックス（独自の振る舞いの実体を持たないため）
  • MCPのファイルサーバー（ツール自体が主体となるため）
  • 実行サービスやアプリコードが主体である大規模プラグインに、付随的なSkillが1つ含まれているだけの場合
• C2を満たさない例:
  • エージェントシステムに内蔵されたGPT設定（独立して取得可能なSkill境界を持たないため）
• C1〜C3をすべて満たす例（肯定例）:
  • 単一の SKILL.md ファイル1つ（全条件を満たせば該当）
  • 複数のSkill・フック・システムアダプタ・テスト・リリースメタデータ・外部連携用インターフェースを包含する大規模構成（Skillとしての主体性が保持されていれば同一カテゴリに分類される）

ディレクトリ構成の複雑さやファイル数の多さ自体は、分類の根拠にはならない点が強調されています。

Skillwareユニットの実行モデル（数式による定式化）

Skillwareユニットの実行プロセスは、以下の数式でモデル化されています。

$$\pi = R_H(S, \tau, M, C, T, P, \sigma)$$

各変数の定義は以下の通りです。

• \(S\): Skillwareユニット
• \(H\): Agent Host
• \(\tau\): タスク
• \(M\): モデル
• \(C\): 組み立てられたコンテキスト
• \(T\): 利用可能なツール
• \(P\): 権限ポリシー
• \(\sigma\): 現在の状態
• \(\pi\): 生成される実行トレース（テキスト、ツール呼び出し、ファイル操作、状態遷移、承認、レビューの一時停止、失敗などを含む）

この定式化は、同一のSkillwareユニット \(S\) であっても、使用するモデル \(M\) やツール構成 \(T\)、権限ポリシー \(P\) の変化によって実行トレース \(\pi\) が変化し得ることを示しています。これは自然言語に決定論的な意味論を与えるものではなく、再現性や互換性を議論する際に明確化すべき変数を列挙したものとして解釈されるべきだと説明されています。

3. 実証結果: 13万件超のコーパスと13件の実装ケーススタディ

妥当性を検証する4つのエビデンスと推論の境界

Skillwareの分類体系の妥当性は、性質の異なる以下の4種類のエビデンスを組み合わせて検証されています。

• 仕様・公式ドキュメント: Agent Skills仕様や各Agent Hostの実装ガイドに基づき、アーティファクト構成や実行操作の枠組みを検証。
• 大規模コーパスの統計: 収集された大量の SKILL.md ファイルから、規模や記述パターンを測定。
• 境界事例レビュー: 肯定例・否定例を含む事例に対し、C1〜C3の適合性を個別判定。
• 固定リビジョンの技術ケース: 実在するリポジトリの特定コミットを対象に、構造的・運用的な関係性を精査。

これに加え、独立した先行研究による分析結果が補強材料として用いられています。

著者らは、各エビデンスが「何を証明でき、何を証明できないか」という推論の境界を持つことを明記しています。例えば、SKILL.md 内に references/ という文字列が記述されていることのみでは、対応するリソースが実際に存在し実行時に使用されていることの証明にはならないといった点が挙げられています。

大規模コーパス「SkillMD-138K」の実態データ

検証に使用されたコーパス「SkillMD-138K」は、重複を除外した結果、20,556件のリポジトリ識別子に紐づく138,133件の SKILL.md ファイルで構成されています。実態データの主要な数値は以下の通りです。

• 構造化メタデータの定着: 全体の98.73%（136,380ファイル）がYAML形式のフロントマター区切りを保持。構造化メタデータの記述は、一部のリポジトリに限らず全体に広く定着した慣習であることが確認されました。
• 明示的なパス参照: references/・scripts/・assets/ の3種類のディレクトリへの明示的パス参照を含むファイルは23.2%（32,069件）であり、コーパス全体で236,421個のパストークンが検出されました。
• ファイルの長さ: 行数の中央値は169行（語数687語）、90パーセンタイルで517行（語数1,971語）となっています。これは品質を直接示すものではありませんが、保守・レビュー対象となる振る舞いソースの規模が小さくないことを示しています。

技術ケーススタディと境界事例レビュー

技術ケーススタディとして、Superpowers、gstack、ECC、OpenMontage、SkillOptなど13件の実在プロジェクトが選定されました。それぞれ正規リポジトリ名、40文字のコミットハッシュ、具体的なファイルパスとともに、肯定的な観察結果、反証、限界が記録されています。

さらに、15件の境界事例（肯定例12件、意図的な否定例3件）に対して、C1〜C3に基づく個別の適合性レビューが実施されました。

先行研究による多角的な裏付け

本論文の見立ては、以下の独立した先行研究のデータによっても裏付けられていると報告されています。

• Chenらの研究: 97,755件のSkillを分析し、キャッシュ管理、実行環境の依存関係、グローバル管理、エラー処理、セキュリティ要件が実行系の課題として顕在化していることを示し、「Skill OS」構想を提示しました。
• Gaoらの研究: レジストリ由来18,463件、個人利用23,199件（計5,876リポジトリ）のSkillを分析し、3,709件の再利用リンクを特定。複製されたSkillに対する局所的な改変や追加の保守が広範に行われていると報告しました。
• Hongらの研究: 238件のSkillを分析し、SKILL.md の記述における品質上の問題（smell）が広範囲に存在することを明らかにしました。

これらの研究は、Skillの識別子が実行・評価・変更・ガバナンスの各局面ですでに実用的に扱われつつあることを、多様なアプローチから裏付けていると評価されています。

4. 6つの構成次元とデザインパターンの移植

Skillwareの6つの実装次元

Skillwareユニットの最小構成は「Atomic」と呼ばれ、単一のSkillソースのみでタスク契約が完結する形態を指します。実際のプロジェクトでは、これをベースに以下の6つの実装次元が観察されています。これらは相互に排他的ではなく組み合わせが可能であり、次元の多さが品質の高さを直接意味するものではないとされています。

• Resource-Backed（リソース依存型）: 参照資料、テンプレート、データ、具体例などパッケージ化されたリソースを読み込む構成。（例: scientific-schematics。主なリスク: リソースの欠落・陳腐化・矛盾・過多）
• Tool-Backed（ツール依存型）: スクリプト、実行ファイル、デーモン、外部サービスなどを呼び出す構成。（例: gstack, OpenMontage。主なリスク: 入力契約の逸脱、副作用、依存先の障害伝播）
• Event-Driven（イベント駆動型）: ライフサイクルイベントによって起動・初期化・制約・観測を行う構成。（例: Superpowers, ECC。主なリスク: イベントの重複・欠落・順序の乱れ・非冪等性）
• Plugin-Packaged（プラグイン配布型）: システムが認識するマニフェストファイルを介して配布される構成。（例: Superpowers, ECC。主なリスク: 互換性・来歴・アップグレード・アンインストール時の不整合）
• Companion-Coupled（コンパニオン連携型）: ブラウザ等の別インターフェースとタスク状態をやり取りする構成。（例: SuperpowersのVisual Companion, gstackのブラウザ連携。主なリスク: セッション束縛、古い判断の残留、認可・復旧の課題）
• Adaptation-Enabled（適応可能型）: 変更提案・評価・採用・リリース・復旧を同一ユニット識別子の下で完結させる構成。（※13件の技術ケースの中に完全な実例は存在せず、SkillOptが部分的な先例にとどまると報告されています）

既存デザインパターンの移植と具体例

従来のソフトウェア開発で培われたデザインパターンをSkillwareへ移植した例として、以下の6つのパターンが示されています。

• Facade: Superpowersにおける using-superpowers というSkillが、専門化された複数のSkill群（サブシステム）に対する統一窓口（Facade）として機能する例です。エージェント自体がクライアントとなり、「1%でも関連しそうなら呼び出す」という規則により単一の窓口利用を強制しつつ、各Skillの独立性を保持しています。
• Adapter: gstackにおいて、正規のSkill定義（Adaptee）を保持したまま、異なるAgent Host向けにフィールド名やコマンド名を翻訳する薄いバインディング（Adapter）を生成し、Host側の起動経路（Target interface）へ接続する例です。「正規のtopicとdecisionを受け取りbrief_pathを返す」という手続き自体を不変に保つ制約が、変換境界として機能しています。
• Composite: OpenMontageの段階的Skillワークフローにおいて、単一のSkill（リーフ）と複数Skillで構成されるグループ（コンポジット）を同一の入出力契約で扱う例です。ワークフロー定義が循環を排除しつつ全体の構造を管理します。
• Observer: ECCのフックやOpenMontageのライフサイクルイベントにおいて、状態遷移を型付きイベントとして購読者に通知する例です。イベントごとの配信成否記録、障害の分離、再入防止のルールが明確化されています。
• State: OpenMontageのチェックポイントやSkillOptのステージにおいて、永続化された状態に応じて許可される操作を制限する例です。再起動時には永続状態から復元が行われます。
• Strategy: Superpowersの選択ポリシーにおいて、同一の評価リクエスト・結果契約（claims・sources・confidenceの返却）を維持しながら、リスクに応じて高速な確認手順と詳細なレビュー手順を動的に切り替える例です。

パターン移植の認定基準

論文では、単にファイル名が類似しているというだけではパターン移植として認められず、以下の7つの要素が揃うことで初めて正当な移植とみなす厳格な基準が採用されています。

1. 元の設計意図
2. 設計上の力学
3. 参加者同士の対応関係
4. 帰結
5. 実装上のエビデンス
6. 的を絞った検証
7. 誤用との判別点

例えば、adapter.yaml というファイル名が存在するのみでは単なる手がかりに過ぎず、実際に正規インターフェースをターゲット契約へ変換する動作が確認されて初めてAdapterと判定されます。

8つのエンジニアリング機構

デザインパターンを具体的に実現するための機構として、以下の8つが整理されています。

• Skill Router: 判定条件・優先順位・対象・フォールバックを一元管理する機構。
• Progressive Disclosure: リソースの読み込み条件を明示的に関連付ける機構。
• Deterministic Kernel: 厳密な変換処理をバージョン管理された実行可能契約の背後に隠蔽する機構。
• Canonical Skill with Generated System Adapters: 1つの正規振る舞いソースを維持しつつ薄いシステムバインディングを生成する機構。
• Lifecycle Bootstrap: 境界の明確なイベントに冪等な初期化処理に関連付ける機構。
• Verification Gate: 重要な状態遷移を最新の検証結果に関連付ける機構。
• Human-Gated Companion: 一時停止したタスクを人間の承認判断に関連付ける機構。
• Evidence-Gated Self-Evolution: 変更候補の段階的評価、リリース識別子およびロールバック経路を保持する機構。

Skill設計の6段階ワークフロー

Skillを設計・実装するための体系的なアプローチとして、以下の6段階のワークフローが提案されています。

1. Skillwareユニットとタスク契約の定義: ユニット識別子と果たすべきタスク契約を定義する。
2. 実装次元の選択: 必要な実装次元（Resource-Backed, Tool-Backedなど）を選定する。
3. パターンの選定: 設計上の力学に応じて最適なデザインパターンを選択する。
4. エンジニアリング機構の実装: 具体的な機構（Router, Verification Gateなど）を実装する。
5. パッケージングと評価: 契約、厳密な操作、否定ケース、システム互換性、障害復旧、アップグレード、削除を含めて評価しパッケージングする。
6. ライフサイクル管理の維持: リリース後も来歴、実行エビデンス、バージョン履歴、レビュー判断、非推奨化方針、ロールバック経路を保持し続ける。

このワークフローにより、意思決定の層が明確に分かれるため、異なった実装を持つSkill同士を共通の軸で比較・検討することが可能になると説明されています。

• 実装次元: 「どの面を運用対象とするか」
• パターン: 「構成要素間の関係性をどう構築するか」
• 機構: 「それをどのように具体的に動作させるか」

5. エンジニアリング・ライフサイクルと進化の管理

Skillwareユニットの発展経路と技術的集約（Engineering Consolidation）

論文では、Skillwareユニットが経時的に成熟するモデルケースとして、以下の発展経路が示されています。

「自然言語による振る舞いの種から始まり、再利用可能なSkillとなり、独立したユニット識別子を獲得した上で、利用実績に応じてエンジニアリング構造を蓄積していく」

ただし、これは固定的な必須プロセスではなく、起こり得る経路の例示にとどまると強調されています。コンパクトな自然言語記述のまま長期間運用されるユニットもあれば、コードやインターフェースを多数包含するハイブリッド構造へ成長するユニットも存在します。継続性の根幹はあくまで管理された「ユニット識別子」であり、蓄積された構造の量ではないと説明されています。

この構造化の蓄積プロセスは Engineering Consolidation（技術的集約） と呼ばれ、運用エビデンスに基づき以下の要素がリリースごとに明示的に追加される過程を指します。

• リソース
• 決定的なスクリプト
• システムバインディング
• パッケージ
• コンパニオン
• テスト
• 来歴
• ライフサイクル管理

構造の追加判断はあらかじめ定められた設計図ではなく、以下の運用上のエビデンスに基づいて行われます。

• 安定性
• 安全性
• 再利用頻度
• コスト
• 失敗時の影響
• コンテキストへの負荷
• 観測可能性

識別子を保った進化（Identity-Preserving Evolution）

分散した変更を取り込みながらもソフトウェアとしての整合性を維持するプロセスは、Identity-Preserving Evolution（識別子保存型進化） として整理されています。

その標準的なプロセスフローは以下の通りです。

$$\text{実行エビデンス} \longrightarrow \text{振る舞い変更の提案} \longrightarrow \text{評価} \longrightarrow \text{ガバナンスを経たリリース}$$

変更提案の作成自体は人間・エージェント・自動システムのいずれが行ってもよいとされていますが、評価権限、意思決定の責任、来歴、復旧経路が明確化された時点で初めてソフトウェアライフサイクルとして扱われるというルールが示されています。

この進化プロセスには以下の2つの形態が含まれます。

• Self-Evolution: 実行エビデンスから自動的に変更候補を生成・検証・ステージングする形態（例: SkillOpt）。
• Collaborative Evolution: 複数の人間、エージェント、現場チームからの貢献を評価・統合・リリースするガバナンス形態。

現場常駐型運用（Forward Deployed Engineering: FDE）仮説

実務での運用フレームワークとして、Forward Deployed Engineering（FDE：現場常駐型エンジニアリング） の仮説が紹介されています。

FDEの運用手順

1. 現場チームが自然言語中心のタスク契約をまずデプロイする。
2. ドメインユーザーとともに実際の振る舞いを観察する。
3. 失敗事例や繰り返し発生する要求を収集する。
4. 安定した振る舞いをリソース、スクリプト、システムバインディング、テスト、正式リリースへと構造化（Consolidation）していく。

利点とリスク

• 期待される利点: 中央チームがアーキテクチャやバージョン整合性を管理しつつ、現場側が拠点固有の最適化を維持できる点。
• 懸念されるリスク: 局所的な過学習、評価基準の弛緩、変種の無秩序な乱立、プライバシー漏洩、レビュープロセスの過負荷。

なお、本仮説は特定文脈における運用事例の分析に基づくものであり、絶対的な組織構造を規定するものではない旨が留保されています。

6. 限界・トレードオフ

分析・データにおける限界

本論文では、研究アプローチに伴う限界が明示されています。

• コーパス統計に関する制約:
  • 統計データは表面的なメタデータおよび字句パターンに基づくものです。
  • 特定レジストリへの偏り、エイリアスやフォークの存在、自動生成成果物の混入、ソースリビジョンの欠落、リポジトリ間の貢献度の偏りなどが外的妥当性を制約する要因となります。
  • フロントマターの有無やパストークンの存在は記述慣習を示すものであり、意味的な正確性や実際の運用状態を保証するものではありません。
• 事例・ケーススタディに関する制約:
  • 事例は多様性と反例を明確化するために意図的選定されたものであり、エコシステム全体での発生頻度を示すものではありません。
  • 固定コミットでのコード確認は特定時点の構造を示すものであり、異なるAgent Host間での動作再現性（parity）の確認には別途実行検証が必要です。

構成概念における課題

• 振る舞い主体の判定限界: 多数の実行サービスを含むパッケージなどにおいて、何が「振る舞いの主体」であるかの判断が分析者によって分かれる可能性があります。
• 完全な実例の未存在: 選定された13件の技術ケースにおいて、変更の提案から評価・採用・復旧までを同一識別子で完結できる「Adaptation-Enabled」の完全な実例は存在せず、SkillOptおよびdarwin-skillが部分的な先例にとどまっている点が課題として挙げられています。

今後の研究課題

今後の展望として、以下の4つの研究方向性が提示されています。

1. 比較実験の実施: 複数のAgent Host、モデル、ツール構成、権限設定を統一した比較実験による、タスク成功率やエラー挙動の定量測定。
2. 仕様・契約の標準化: 自然言語による振る舞い契約に対するセマンティックバージョニングおよび互換性宣言の確立。
3. セキュリティ研究の推進: プロンプトインジェクション、パッケージ配布、サプライチェーンリスクに関するセキュリティ分析。
4. 長期的なエンジニアリング調査: リリリースおよびコミット単位での構造的蓄積を長期追跡する縦断的研究。

おわりに

本論文は、Agent Skillsが単なる一時的なプロンプトの拡張にとどまらず、自然言語をソースとする持続的なソフトウェアオブジェクトとなり得ることを示しました。「Skillware」の枠組みは、3つの判定条件（C1〜C3）およびLifecycle Continuity（LC）指標を通じて、Skillをソフトウェアとして厳密に管理・評価するための基礎理論を提供しています。13万件超のコーパス分析とケーススタディは、この概念が単なる理論的枠組みではなく、実際の開発現場で生じているエンジニアリング上の要請に裏付けられたものであることを実証しています。

実務者にとっても、本論文が整理した6つの実装次元、デザインパターンの移植例、6段階のワークフローは、既存のSkill群を評価し、適切な構造化投資を行うための実践的なフレームワークとして活用できます。特に「Adaptation-Enabled」な自己進化型構成が未だ発展途上の領域であるという指摘は、将来的なエージェントシステムの設計において重要な示唆を与えるものです。

今後は、異機種環境における互換性の検証や、自然言語契約のバージョニング・セキュリティの標準化に向けた取り組みがより一層重要になると見込まれます。

More Information

• arXiv:2607.18970, Haodi Fan, Zucong Lan, 「Skillware: A Software Ontology and Engineering Lifecycle for Persistent Behavioral Artifacts」, https://arxiv.org/abs/2607.18970