2026年10月22日、Linux FoundationのAgentic AI Foundation（AAIF）が、Agent Skills、Open Responses、OpenEnv、OpenSandboxの4プロジェクトの参加を発表しました。4つの技術が、この日に初めて公開されたという意味ではありません。
Linux Foundationの発表によると、2025年12月にMCP、AGENTS.md、gooseの3つで発足したAAIFは、その後の参加と今回の4つを合わせ、発足1年目に10プロジェクトを抱える規模になりました。
新4プロジェクトは、何を担当するのか
同じ発表に並んでいても、担当する課題は違います。まずは4つの役割を図にしました。
図1：Linux Foundationの参加発表をもとに作成。各プロジェクトの役割を並べたもので、導入順や相互の必須依存関係を表す図ではありません。
この記事では、4つすべてについて、何ができて、自分たちの開発にどう使えるかを確認します。Claude CodeやCodexを使うプロダクト開発チームを想定し、用途と最初の確認ポイントを並べました。
| プロジェクト | 主な使いどころ | 最初の確認ポイント |
|---|---|---|
| Agent Skills | 手順・知識の再利用 | 既存スキルの読み込み方と権限を点検する。未導入なら手順を1つ選ぶ |
| OpenSandbox | エージェントの隔離実行 | 実行権限・外部通信・認証情報をどこで制御するか確認する |
| Open Responses | 複数モデルへの共通インターフェース | Itemとイベントの扱いを社内設計と照合する |
| OpenEnv | 学習・評価環境の構築 | 自社の評価課題を環境として表せるか確認する |
Agent Skillsは、これまでもSkillsの実践ガイドや社内ルールのプラグイン配布の記事で紹介してきました。すでに使っている技術も含めて役割を整理し、導入済みなら運用を点検、未導入なら必要な用途から段階的に検討する、という読み方を想定しています。
仕様の確認日は2026年10月26日です。以下では各プロジェクトの仕様を紹介し、導入時に確かめたい点と、試し始める場面について私の考えを添えます。
導入前に見ておきたい「Downloadsフォルダ攻撃」
AAIFの発表と同じ10月22日、Forever Securityが「Markdown Is the New Executable」を公開しました。同社は、実際の顧客マシンの ~/Downloads に、通常の開発ガイドラインを装った悪意ある AGENTS.md が置かれていたと報告しています。
Codexに設定ファイルを書き換えさせ、悪性パッケージの実行へ誘導する攻撃です。同社はClaude Codeでも、設定の変更によってAPIの通信先を攻撃者側へ向け、トークンを取得する再現実験を行っています。
レポートが示す成功率はCodexで90%超、Claude Codeで約50%ですが、同社の検証条件での結果です。一般の利用環境にそのまま当てはまる確率としては読めません。
ここで注目したいのは、外から来た文書の内容が、設定変更や実行の指示として扱われた点です。「仕様の悪用で、単純なパッチでは解消しない」というのは同社の評価です。少なくとも運用側では、エージェントに読ませるファイルと、実行・通信を許す範囲を確認する必要があります。
図2：報告された攻撃を踏まえた運用上の整理。各対策が単独で攻撃を防ぐことを保証する図ではありません。
まず、Webからファイルが届くDownloadsを作業場所にしないこと。ホーム直下も含め、広い範囲を作業場所にする前に、どの指示ファイルが読み込まれるかを確認したいところです。~/.codex/config.toml の見覚えのないMCPサーバー設定や、.claude/settings.json の ANTHROPIC_BASE_URL も点検対象になります。通信先の変更には正当な用途もあるため、設定の有無だけで侵害とは判断せず、意図した変更かを確認します。
Agent Skills：導入済みなら運用を点検、未導入なら1つから
4つのうち、日々の開発へ取り入れやすいのがAgent Skillsです。仕様では、1つのディレクトリに必須の SKILL.md を置き、必要に応じて scripts/、references/、assets/ を添えます。
SKILL.md はYAMLフロントマターとMarkdown本文で構成されます。必須項目は、親ディレクトリ名と一致する name と、何をするか・いつ使うかを伝える description。ライセンスや必要環境、メタデータなども記述できます。
実務で効くのは、必要な情報を段階的に読み込む設計です。
図3：Agent Skills仕様のProgressive disclosureを整理。実際の選択・読み込み方は対応するエージェントの実装にも依存します。
すでにスキルを使っているなら、まずは「必要な場面で選ばれているか」「説明や手順が古くなっていないか」「権限を広く取りすぎていないか」を点検します。今回のAAIF参加を機に、最初から作り直す必要はありません。
未導入なら、次の3つを小さく試すところから始められます。
- リリース手順、障害の一次対応、社内APIの使い方など、繰り返し説明している手順を1つ選ぶ。
descriptionに用途と使う場面を具体的に書く。曖昧な説明では、適切なタスクで選ばれにくくなります。- 公式の検証ツールで
skills-ref validate ./my-skillを実行する。構造の検証に加え、実際のタスクで選ばれ、意図した動作になるかも確かめます。
外部スキルを入れるときは、SKILL.md と同梱スクリプトを依存パッケージと同じようにレビューしたいところです。検証ツールが通っても、中身の安全性まで確認できるわけではありません。
任意項目の allowed-tools は、スキルが使える事前承認済みツールを示す実験的なフィールドです。対応は実装ごとに異なるため、これだけを権限制御の根拠にせず、対応する環境では必要なコマンドに絞ります。
AGENTS.mdとの役割分担も決めておきましょう。私は、リポジトリで常に守る基本ルールをAGENTS.mdへ、特定のタスクで使う手順をSkillsへ置く整理を勧めます。どちらも、増やす前に読み込まれる条件を確かめることが大切です。
OpenSandbox：隔離の現状を確認し、必要な用途から検証する
OpenSandboxは、AIアプリケーション向けの汎用サンドボックス基盤です。DockerとKubernetesに対応し、ライフサイクルと実行のAPI、多言語SDKを提供します。Claude CodeやCodex CLIを動かす例もあります。
確認したいのは、サンドボックスから外へ出る通信を、どこで制限するかです。egressの設計文書では、ワークロードとネットワーク名前空間を共有するサイドカーで制御します。DNSのみのフィルタと、DNSにパケット層の制御を加える dns+nft モードは、同じ強さの制約ではありません。
DNSのみの制御では、IPアドレスを直接指定する通信を十分に制限できません。dns+nft ではnftablesを使い、DNS解決したIPに期限付きの許可を与えるなど、通信の制御を強めます。ただし、設定した許可先やワークロードの権限を含めて検証する必要があります。
もう1つの検討対象がCredential Vaultです。本物の認証情報をワークロードに渡さず、許可した宛先へのHTTPS通信へプロキシ側で注入する設計です。ワークロード内に秘密を置かないことで流出リスクを減らす狙いがありますが、先のOAuth攻撃を防げると検証したわけではありません。
Vaultを使うには dns+nft やCredential Proxyなどの前提条件を満たす必要があります。機能名だけを見て有効と判断せず、実際に拒否できる通信と、秘密が渡る場所を確認します。
すでに隔離された実行環境があるなら、外部通信と認証情報までどこで制御できているかを点検します。未導入なら、次の順で小さく検証するのがよいと考えます。
- 起動フォルダと設定を点検する。追加製品を買う前にできる作業です。
- CIや夜間バッチなど、人が画面を見ていない用途を1つ選ぶ。
dns+nftとdefaultAction=denyを出発点に、必要な通信先だけを許可する。- 許可先への通信が成功することと、許可していない通信が失敗することを両方確認する。
- Vaultを使う場合は、その認証方式に対応できるか、ワークロードに本物の認証情報が残らないかを確かめる。
サンドボックスを導入したという事実より、実行・通信・認証情報のどこまでを制限できたかを記録したいところです。
Open Responses：自前のLLMクライアント層があるなら読む
Open Responsesは、OpenAIのResponses APIをもとに、複数のモデル提供元で使うインターフェースを共通化する仕様です。押さえたいのは、入力・出力の単位である Item と、ストリーミングのイベントです。
- Itemにはメッセージ、関数呼び出し、推論などの型があり、処理中や完了などの状態を持ちます。
- ストリーミングでは、Item追加、本文の差分、完了といった意味のあるイベントを扱います。文字列が流れてくることだけを前提にしません。
- 提供元独自の拡張には名前空間を付けます。未知のItemを扱える設計が推奨され、未知のストリーミングイベントを安全に無視することは必須です。
tool_choiceのallowed_toolsで実行可能なツールを絞れます。サーバー側がその制約を強制する必要があります。
自前でOpenAI、Anthropic、ローカルモデルなどを切り替える層を持つチームなら、社内の型定義と照合する価値があります。ただし、仕様に型を寄せるだけで各社のAPIや独自ツールがそのまま動くとは限りません。拡張Itemに依存する箇所も分けて確認します。
Claude CodeやCodexを利用するだけなら、Open Responsesへ合わせて自社の仕組みを改修する必要は通常ありません。2026年10月21日採択の技術憲章ではTSCによる技術面の監督も定められています。継続して仕様を追う場合は、変更履歴と対応実装をセットで見るのがよいでしょう。
OpenEnv：学習・評価の環境を作る
OpenEnvは、強化学習（RL）の環境を作り、共有するためのフレームワークです。reset()、step()、state() を基本に、コンテナ化した環境とエージェントを接続します。RLだけでなく、評価やMCPによる利用も扱っています。
確認したいのは、自社のタスクを「行動・観測・報酬」の形で表せるかです。たとえば、コードを修正する行動に対し、実行結果を観測し、テストの合否を報酬にする環境が考えられます。モデルを学習させる用途と、エージェントを評価する用途のどちらでも、何を成功とするかを先に定める必要があります。
一方、報酬設計のガイドには、今の評価設計へ取り入れられる考え方があります。コンパイルできるか、テストを通るかを先に判定し、その条件を満たした出力だけ品質評価へ進める、というゲートです。ガイドには Gate や Sequential を組み合わせ、条件を満たさなければ後段の評価を打ち切る例があります。
たとえば社内エージェントなら、「まずビルドが通るか、次に必須テストを満たすか、最後に品質を評価する」と考えられます。これは私の応用案であり、OpenEnvの導入を前提にしません。なお、確認したガイドは開発中のmain版です。API例を使うときは、導入するバージョンとの差を確認してください。
導入状況に合わせて、段階的に検討する
まず、現在の使い方を確認する
- 起動フォルダと、そこから読み込まれる指示ファイルを確認する。
- MCPサーバー設定やAPIの通信先に、見覚えのない変更がないか点検する。
- 承認とサンドボックスの設定を確認し、それらの無効化を求める外部文書をうのみにしない。
- 既存スキルの用途・説明・権限・動作を点検する。
- モデルの切り替え、学習・評価環境、隔離実行について、すでに備えている仕組みを確認する。
未導入なら、用途を1つ選んで試す
- Agent Skills：定番手順を1つスキル化し、構造と実際の動作を検証する。
- OpenSandbox：無人実行の用途を選び、通信制限と認証情報の分離を検証する。
- Open Responses：自前のLLMクライアント層に課題があれば、入出力とイベントの扱いを照合する。
- OpenEnv：評価したいタスク、その成功条件、必要な実行環境を1つずつ決め、サンプルと照合する。
試行の結果を見て、適用範囲を広げる
- 期待した動作と、失敗したときの挙動を確認する。
- 導入するバージョンと制約を記録し、既存の仕組みと重複しないか確認する。
- チームへ広げる場合は、レビュー・更新・権限管理の担当を決める。
4つを確認すると、手順の再利用、モデルとの接続、学習・評価環境、隔離された実行基盤という役割の違いが見えてきます。導入済みなら今の運用を点検し、未導入なら自分たちの課題に合う用途から段階的に検討する。この記事の比較表と図解を、その検討の入口に使ってください。
参考・一次情報
以下は2026年10月26日に確認しました。継続更新される仕様は、導入時に最新の内容と対象バージョンを確認してください。
- Linux Foundation：AAIFの4プロジェクト参加発表（2026年10月22日）
- Agent Skills：Specification
- OpenSandbox：README / Egress設計 / Credential Vault
- Open Responses：Specification / Technical Charter
- OpenEnv：README / Rewards
- Forever Security：Markdown Is the New Executable（2026年10月22日）