OpenAI系のCodex Workセッションで、どんな tools と skills が使えるのかを一覧化した参考ページが公開された。単なる内部メモではなく、232件の tool interfaces と44件の skill definitions をそのまま見せる「目録」になっているのが面白い。こうした一覧は、普段は裏側に隠れている AI エージェントの動きをかなり具体的に想像させる。どこまで自動化できるのか、どんな外部サービスとつながるのかが、曖昧な説明ではなく実物の名前で見えてくるからだ。
元記事は、Codex Work session にある callable interfaces と reusable workflow definitions を「完全なスナップショット」としてまとめた参照ページだ。そこでまず示されるのは、Skill source が44、Tool interfaces が232、Skill definitions が44という数で、さらに Skill source は615k chars とされている。Snapshot の日時は 31 Aug 2026。ページの性格からして、これは機能紹介というより、ある時点の Codex の能力を固定して見せる資料に近い。
説明文によれば、tools は呼び出せる endpoint で、skills はそれらの tool をどう使うかを案内する再利用可能な instruction package だという。つまり、単に「何ができるか」だけではなく、「その機能をどう使うべきか」まで含めて二層で整理している。skills のページには各定義の完全版がそのまま載り、tool reference には公開されている description と TypeScript declarations が残される。ここで重要なのは、能力の見取り図をかなり露骨に開示している点だと思う。
ページにはカテゴリも並ぶ。Runtime & files、Sub-agents & coordination、Skills、Plugins、MCP resources、Web & live data、Image generation、JavaScript REPL、Automations、GitHub、Gmail、Google Calendar、Google Contacts、Library、Sites、Data analytics、Fitness database、SimonWillison.net database、Personal context、Pets、Plugin management、Safety & family、Safety & support、Zillow など、実に幅広い。数だけ見ても、コード生成の補助にとどまらず、メール、カレンダー、連絡先、サイト構築、データ分析、家族向けの安全機能、住宅情報まで視野に入っているのが分かる。
さらに「About this inventory」では、availability は session configuration、permissions、connected apps、installed plugins によって変わりうると注意されている。つまり、ページに載っているからといって常に全部使えるわけではない。利用者の権限や接続済みアプリ次第で見える範囲も変わる。元記事の後半には、各 skill の用途説明がずらっと続く。たとえば answers-charts はカテゴリ比較や推移を図のほうが伝えやすいときに使い、answers-images は取得した画像を回答の土台にするとき、documents は .docx や Google Docs 向け文書を strict render-and-verify workflow で扱う、といった具合だ。imagegen は bitmap の新規生成や変換向けで、pdf は Poppler rendering や Python tools を使って PDF を読んだり検証したりする。openai-docs は Codex models/pricing、scheduled tasks、skills、settings、setup、troubleshooting、自分自身に関する質問まで対象にしている。
このページ全体が示しているのは、Codex を単発のチャットではなく、外部サービスと道具を束ねる作業環境として扱っていることだと思う。しかもその道具箱を、隠さずに一覧として出している。そこには「何ができるか」を見せるだけでなく、「何を使ってどう動くのか」を利用者に理解させようという意図があるように見える。
この一覧を見てまず感じたのは、AI の本体より周辺の接続口が主役になってきた、ということだ。以前ならモデルの賢さが話題の中心だったが、ここでは Gmail、Calendar、GitHub、Sites、Data analytics といった接続先の名前がずらっと並ぶ。つまり、成果物は会話の中ではなく、外部の作業環境の中で作られる前提に近い。これはかなり大きい変化だと思う。
理由は単純で、実務の価値は「説明できること」より「実際に進められること」にあるからだ。たとえばメール文面を作るだけなら多くのモデルができるが、相手を特定し、予定を確定し、必要ならカレンダーに反映するまで一気通貫で進むと、AI の役割はまったく違ってくる。元記事にある resolve-recipients のような skill は、その象徴だろう。宛先の取り違えは実務では致命傷になりうるので、ここに明示的な手順があるのはかなり現実的だ。便利さより先に、事故を減らす設計が置かれている。
もう一つ引っかかったのは、skills が単なるラベルではなく、かなり具体的な行動指針になっていることだ。documents では render-and-verify を徹底すると書き、skill-installer は curated list や GitHub repo path から導入すると明記する。control-browser には、public lookup の場合は web search を先に使い、失敗したからといって Browser に逃げない、というような運用ルールまで入っている。ここまで書くと、AI は自由に振る舞う存在というより、かなり細かい作業マニュアルを持ったオペレーターに近い。
私はここに、モデルの能力説明と同じくらい大事な転換を感じる。大規模言語モデルは「何を知っているか」より「どう扱わせるか」で結果が大きく変わる。ならば skill を公開するのは、単に透明性のためではなく、能力の再現性を上げるためでもあるはずだ。利用者が中身を見られれば、どこで判断が入り、どこで外部ツールに依存しているのかも分かる。ブラックボックスを少しでも減らす効果はある。
232の tool interfaces は数字だけ見ると圧倒される。ただ、元記事は同時に availability が session configuration や permissions で変わると釘を刺している。ここが重要で、一覧が豪華だからといって、常にフル装備で動くわけではない。むしろ、接続先が増えるほど制約管理のほうが難しくなる。誰が何にアクセスできるのか、どの plugin が入っているのか、どの情報が今のセッションで参照可能なのか。現実の運用では、そのほうが効いてくる。
この点は、AI エージェントを業務に入れたい組織にとって特に重い。便利な機能を足すほど、誤送信、誤操作、権限過多のリスクも増えるからだ。だから私は、このページが「できること」の誇示に見える一方で、実際には統制の資料でもあると見ている。何が見えていて、何が見えていないかを明示することは、実装上の派手さよりずっと地味だが、現場でははるかに価値がある。
この手の一覧は、普通なら内部資料で終わってもおかしくない。けれど元記事は、skills と tools をほぼそのまま読める形で出している。私はここに、プロダクトの成熟を感じる。未完成さを隠すより、現時点の接続範囲を正直に見せたほうが、利用者は期待値を調整できる。どの機能があるかを知ることは、どの仕事を任せられるかを知ることと同じだからだ。
同時に、これは AI の「人格」を売るというより「作業環境」を売る方向に寄っている。会話の巧みさより、GitHub や Google Calendar や PDF や spreadsheet をどう扱えるかが前面に出る。そうなると、競争の軸も変わる。誰の応答が自然かではなく、誰がより少ない手戻りで実務を前に進めるか。元記事は、その方向にかなりはっきり舵を切っているように見えた。
