CodexでAI社員を作るとき、最初に長いプロンプトを書く必要はありません。先に一つの業務を選び、会社の情報、業務ルール、AIに任せる範囲、人が確認する手順を整理します。そのうえで、Codexに必要な資料と作業境界を読み込ませ、設計・作成・テストを進めます。
この記事では、CompanyOSを会社の前提情報をまとめる基盤、ObsidianやMarkdownを情報整理の手段、AGENTS.mdをAIへの入口指示、Codexを設計と作業を進めるAIとして位置づけます。特定のツールを使うこと自体が目的ではなく、会社の業務に合わせてAI社員の担当範囲を説明できる状態を作ることが目的です。
Codexで作るAI社員は、プロンプト集だけではない
AI社員は、名前や人格を与えたチャットAIのことだけを指しません。ここでは、会社の業務上の役割、参照する情報、出力の形式、人間の確認手順を組み合わせた業務支援の仕組みとして扱います。
Codexに指示を出すだけで、会社の正しい判断や顧客への送信をAIへ移せるわけではありません。価格、契約、法務、個人情報、社外への公開などは、会社の担当者が確認して確定します。Codexは、資料を確認し、作業計画を整理し、下書きやファイル作成、テストを支援する役割として使います。
まずCompanyOSで「会社の前提」を分ける
AI社員が参照する情報は、すべて同じ重みで扱いません。少なくとも次のように分けておくと、Codexへ渡す資料の範囲を決めやすくなります。
| 情報の層 | 例 | AI社員に対する扱い |
|---|---|---|
| 会社の前提 | 理念、対象顧客、サービス、判断軸 | 正本として人が承認し、勝手に変更しない |
| 業務のルール | 手順、入力条件、出力形式、例外 | 対象業務ごとに参照範囲と更新担当を決める |
| 作業中の情報 | 日々のメモ、案件資料、下書き | 参照・保存・共有の範囲を確認する |
| 提案や仮説 | AIの案、改善候補、未確認の記述 | 承認前の提案として扱い、正本へ直接反映しない |
この分離がないまま社内資料を一度に読み込ませると、古い情報や未承認の案が現行ルールと混ざる可能性があります。CompanyOSはAIに自由に変更させる場所ではなく、会社の前提を人が確認しながら参照させるための基盤として設計します。
ObsidianやMarkdownで対象業務の情報を整理する
Obsidianは必須条件ではありません。重要なのは、対象業務に必要な情報を、検索・更新・確認しやすいテキストとして整理することです。次の項目を一つの業務について書き出します。
- 業務の開始条件と終了条件
- 入力する資料と、参照してよい情報
- AIが作る下書き・整理結果・候補
- 人が確認して確定する内容
- 入力してはいけない情報と、社外へ送ってはいけない出力
- 情報の更新担当、修正記録、問題が起きたときの相談先
たとえば「営業を支援する」では範囲が広すぎます。「承認済みの商品資料を参照し、問い合わせ内容を分類して、返信案と確認項目を作る」のように、入力と出力を一つの流れとして書くと、AI社員の役割が具体的になります。
AGENTS.mdでCodexの入口と境界を定義する
AGENTS.mdのような入口ファイルには、AIが最初に読む資料、作業対象の範囲、禁止事項、承認が必要な処理を書きます。会社ごとに内容は変わりますが、次の順番で整理すると運用しやすくなります。
- 最初に読むCompanyOSや業務資料を指定する
- 今回の対象業務と、変更してよいフォルダを指定する
- 会社の正本を直接変更しない条件を書く
- 価格・契約・法務・社外送信など、人が確認する境界を書く
- 作業後に行うテストと、報告に含める内容を書く
入口指示は、AIに会社の人格を演じさせる文章ではなく、作業範囲と確認手順を共有する契約に近いものです。資料の出典がない提案は、確定情報と分けて確認事項として残します。
CodexでAI社員を作る6段階
1. 業務を一つ選ぶ
繰り返し発生し、入力・出力・確認者を説明できる業務から始めます。問い合わせ整理、議事録からのタスク抽出、提案書の構成案、社内資料の検索支援などは、試行範囲を決めやすい候補です。
2. 業務設計書に入力・出力・承認を書く
AIに何をさせるかだけでなく、何を確定させないかも書きます。作業の開始条件、参照資料、出力形式、確認項目、停止条件を、AI社員設計書テンプレートへ記入します。
3. CompanyOSと作業資料を分ける
会社の前提や承認済みルールと、今回の案件資料や作業中の下書きを分けます。Codexが参照する範囲を絞り、古い資料や未確認の提案を正本と同じ扱いにしないようにします。
4. Codexに計画・実装・検証を順に依頼する
いきなり「AI社員を完成させて」と依頼するのではなく、まず資料の確認と不足情報の一覧、次に小さな作業、最後にテストという順番にします。Codexが作ったファイルや提案は、人が差分と根拠を確認できる状態で受け取ります。
5. 試行結果を記録する
正答率だけでなく、修正した箇所、参照資料が不足した箇所、確認に時間がかかった箇所、停止すべきだった処理を記録します。記録があると、指示を増やすべきか、資料を更新すべきか、AIの担当範囲を狭めるべきか判断できます。
6. 人が承認してから運用へ移す
会社の正本、顧客向け文章、価格、契約、外部公開に関わる内容は、人が確認してから反映します。AI社員を作った後も、参照情報の更新担当、見直し時期、誤りが見つかったときの停止方法を決めます。運用後の確認項目は、AI社員の運用ルールで整理しています。
Codexで作る前に確認したい5つの質問
- AI社員が支援する業務は一つに絞れているか
- 参照する資料の最新版と更新担当が分かっているか
- AIが作ってよいものと、人が確定するものを分けているか
- 外部送信・公開・契約・価格に承認工程があるか
- 修正履歴と停止・相談の方法を残せるか
まだ対象業務や確認者が決まっていない場合は、AI社員導入前の準備度診断で現在地を確認できます。業務の棚卸しから、最初の1業務の構築、定着まで相談したい場合は、AI業務診断・AI社員構築支援をご覧ください。
まとめ
CodexでAI社員を作るときの中心は、ツールの操作ではなく、会社の前提、業務情報、AIの担当範囲、人間の承認を分けて設計することです。CompanyOSで会社の前提を整理し、ObsidianやMarkdownで業務情報を更新できる形にし、AGENTS.mdでCodexの入口と境界を定めます。そのうえで、一つの業務を小さく試し、結果を記録し、承認済みの内容だけを運用へ移します。
自社でどの業務からAI社員化するか決めにくい場合は、AI社員とは何か、会社導入で何を決めるかを確認したうえで、診断または構築支援へ進んでください。