Codexで「パソコンの中に部署を作る」は本当にできるのか試してみた

Xで流れてきた投稿が気になりました。Codexを使って就業規則を書き、担当を作り、仕事を渡す。それで「パソコンの中に部署が作れる」という内容です。該当の投稿（2026年9月14日）

私も業務でCodexを使っています。担当を分ける発想は前から気になっていました。ただ、投稿に添えられた動画は、AI社員が並ぶダッシュボードでした。あれはCodexの標準画面ではありません。どこまでが機能で、どこからが作り込みなのかを確かめたくなりました。

「部署」という言葉から並列に動く複数の人を想像すると、そこは想定と違いました。

前提として、CodexにはSkillsがあります。SKILL.mdに手順を書いておくと、Codexがそれを読んで従います。公式ドキュメントでは、リポジトリ内の.agents/skills、ユーザーの$HOME/.agents/skills、管理者の/etc/codex/skillsなどを探索すると説明されています。Build skills

ここにagents/openai.yamlを足すと、表示名や呼び出しの方針を指定できます。これが今回の「担当」にあたる部分だという理解でいます。

作業用のディレクトリを1つ作り、こう置きました。

AGENTS.mdが就業規則です。出力は日本語、一次情報を優先、確認できていないことは確認できていないと書く、といった共通ルールを書きました。加えて、調査メモはnotes/、原稿はdrafts/、校正結果はdrafts/*.review.mdという置き場所も決めています。

担当は3つ用意しました。それぞれSKILL.mdに職務内容を書いています。

担当	職務内容と、やらないこと
リサーチ担当 $researcher	一次情報を集めてnotes/に事実を書き出す。原稿は書かない。
記事ライター $writer	notes/だけを根拠に原稿を書く。notes/にない事実を補わない。
校正担当 $proofreader	原稿を読んで指摘だけを返す。本文は書き換えない。

やることより、やらないことを書くほうが効いた感触があります。agents/openai.yamlはこの形です。

interface:
  display_name: "リサーチ担当"
  short_description: "一次情報を集めて notes/ に事実を書き出す"
  default_prompt: "$researcher を使って、指定テーマの一次情報を notes/ にまとめてください。"
policy:
  allow_implicit_invocation: false

3つ置いたところで、Codexに見えているスキルの一覧を確認しました。codex debug prompt-inputを使うと、モデルに渡る内容をそのまま読めます。

3つとも載っていませんでした。パスを間違えたと思い、.codex/skillsや上位ディレクトリに置き直して、しばらく切り分けに時間を使いました。

原因はallow_implicit_invocation: falseでした。この値をtrueに変えると一覧に出ます。

公式ドキュメントにも、falseのときは暗黙の呼び出しをしない、明示的な$skill呼び出しは引き続き使える、と書かれています。読んだときは読み飛ばしていました。実際には「一覧から外れる」という挙動でした。

外れているだけで、認識されていないわけではありません。codex app-serverのskills/listを叩くと、3つともscope: "repo"で返ってきます。display_nameも反映されています。

つまり、falseは「勝手に動き出さない担当」を作る設定でした。指名したときだけ動く。投稿にあった「仕事を渡す」は、この部分だと思います。結果としては、意図した動きになりました。

$researcherと名指しで渡します。テーマは、いま私が手で調べていた「Codexのスキル探索パスとagents/openai.yamlの効果」にしました。

実行ログを見ると、最初に.agents/skills/researcher/SKILL.mdを読んでいます。その後、codex --versionなどを自分で叩いて、出力を根拠に調べ始めました。就業規則どおり、確認できたことと確認できなかったことを分けた調査メモがnotes/に出ています。

続けてライター、校正担当に渡しました。それぞれ担当の範囲を守っています。ライターはnotes/だけを根拠に原稿を書き、校正担当は本文に触らず指摘だけを返しました。

指摘の根拠として「一文は短く」という、こちらがSKILL.mdに書いたルール名が出ています。ここは素直に良いと感じました。

気になったのは、これが本当に「部署」なのかという点です。

codex features listにはmulti_agentがstableで出ています。それで期待したのですが、codex app-serverが公開しているメソッドを一通り見た範囲では、担当を別エージェントとして起動するものは見当たりませんでした。実行ログでも、本体がSKILL.mdを読んで自分で進めています。別プロセスの担当が立ち上がる挙動は確認できませんでした。

TUIで$を押すと、呼び出し候補の一覧が開きます。

この画面では候補の先頭にプラグインが並びました。絞り込んだ状態までは確認できていません。自動化の都合でTUIへのキー入力を止めたためで、担当が候補に出るかどうかは、この画像からは判断できません。skills/listでは3件とも返っているので、名前を打てば絞り込めるはずだと考えていますが、画面での確認は次回に回します。

私の理解では、これは「1人が指示書を持ち替えている」状態です。並行して動かしたいなら、codex execを複数回起動して自分でセッションを分けることになります。今回の3工程も、そうやって順番に回しました。

投稿の動画にあったダッシュボードについては、標準機能として見つけられませんでした。あれは別途作られたものだと思います。

工程ごとのトークン消費はこうなりました。

工程	使用トークン
リサーチ担当	91,538
記事ライター	20,305
校正担当	24,921

調べものが大半を占めます。途中、Codexから週次上限の残りが25%を切ったという警告が出ました。担当を分けると工程の数だけセッションが増えます。分けること自体にコストがかかる点は、先に見ておいたほうがよさそうです。細かく分けるほど良い、とは言えないと感じました。

主張の骨格は本当でした。就業規則を書き、担当を作り、指名して渡す。ここまではAGENTS.mdとSKILL.mdとagents/openai.yamlだけで動きます。特別な作り込みは要りませんでした。

一方で「部署」という比喩は、実装より少し先に行っています。担当が同時に働くわけではありません。そこを期待して組むと、想定と違う結果になると思います。

効果を感じたのは、担当ごとに「やらないこと」を書いた部分でした。リサーチ担当が原稿を書き始めない。ライターが勝手に調べ直さない。この線引きは、1つの長いプロンプトで指示するより安定していました。工程の成果物がファイルとして残るので、どこで崩れたかも追いやすいです。

次は校正担当の指摘を原稿へ反映する工程まで含めて、一度通してみたいと思います。dependencies.toolsでMCPを担当ごとに割り当てる書き方も気になっているので、そこは別途確かめます。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

• 選考ではありません
• 履歴書不要
• 技術の話が中心
• 所要時間30分程度
• オンラインOK

エンジニアと話してみる