AIと仕事を設計する｜第2回

AIエージェントは何で動かすのか――Codex、Claude Code、Agents SDKをどう使い分けるか

前回は、「AIを使う会社」から「AIと仕事を設計する会社」へ、という話を書きました。

では実際に、会社の中でAIに役割を持たせて仕事をさせるには、何を使えばよいのでしょうか。

最初に思い浮かぶのは、CodexやClaude Codeかもしれません。

私自身、AIを使ったプログラム開発や業務ツールの試作では、こうしたコーディングAIを利用しています。

しかし、AIエージェントについて調べていくと、少し整理が必要だと分かりました。

CodexやClaude Codeと、「会社の中で動くAIエージェント」は、重なる部分もありますが、同じ意味ではありません。

CodexやClaude Codeは非常に強力である

CodexやClaude Codeは、単にコードを提案するだけのAIではありません。

ファイルを読み、既存コードを理解し、複数のファイルを修正し、プログラムを実行しながら問題を解決できます。

以前であれば、プログラミングの知識がなければ作れなかったような社内ツールも、自然言語で相談しながら試作できるようになりました。

私自身も、この方法で自社用のツールや仕組みを作ることが増えました。

しかし、

Codexを起動しておけば、それが会社のAI社員になる。

という話ではありません。

一方で、「CodexやClaude Codeは開発にしか使えない」と分けるのも正確ではありません。

Codexには、社内ツールや独自アプリからプログラムとして利用するSDKがあります。より大きなAIシステムの中で、コードやファイル処理を担当する専門エージェントとして動かす方法も示されています。

Claude Codeも、対話画面だけでなく、非対話実行やSDK、MCPを利用した組み込みができます。

参考：OpenAI「Codex SDK」、Anthropic「Claude Code CLI reference」

製品名ではなく、役割で分けて考える

例えば会社に、次のようなAIを置きたいとします。

• 過去事例を探すAI
• 技術基準を探すAI
• 数量を確認するAI
• 図面を確認するAI
• それらの結果をまとめるAI

これらを毎回CodexやClaude Codeの画面から個別に操作するだけでは、社員が共通して使う業務システムにはしにくいと思います。

社員が通常のWeb画面から相談すると、裏側で必要なAIや道具が選ばれて動く方が利用しやすくなります。

その仕組みをCodexやClaude Codeと一緒に開発することもできます。完成した仕組みの中で、CodexやClaude Code自身を専門担当として動かすこともできます。

したがって、「作る側」と「働く側」を製品名で完全に分けるのではなく、役割で考える方が分かりやすいと思います。

AIモデル
＝考えるための頭脳

Agent
＝役割、指示、道具を持って仕事を進める担当者

Codex／Claude Code
＝コード、ファイル、プログラム実行を扱うことに強いAgent環境

Agents SDK
＝Agent、道具、状態、引き継ぎ、人間の承認などを組み合わせる仕組み

MCP／API
＝社内データや外部ツールへ接続する方法

Webアプリ
＝社員が利用する入口

重要なのは、

どのAIに、どの仕事を、どの権限で担当させるのか。

を会社側で設計することです。

AIエージェントの骨格を作るAgents SDK

OpenAIには「Agents SDK」という開発用の仕組みがあります。

これは、AIエージェントを構成する選択肢の一つです。

例えば、

「あなたは過去の技術記録を検索する担当です」

という役割を持ったAIへ、社内ナレッジを検索する道具を与えます。

別のAIには、

「あなたは数量を確認する担当です」

という役割と、計算処理を実行する道具を与えます。

さらに、それらの結果をまとめるAIを用意できます。

               Manager AI
                    │
       ┌────────────┼────────────┐
       │            │            │
   Knowledge AI  Quantity AI  Drawing AI
       │            │            │
   社内記録検索    計算処理      図面確認

Agents SDKでは、Agent間の引き継ぎ、利用できる道具、人間による承認、実行状態、処理履歴などをプログラムとして構成できます。

ただし、Agents SDK自体が考えるわけではありません。会社のデータや業務機能を自動的に用意してくれるわけでもありません。

AIモデル、役割、道具、データ、権限、確認方法を組み合わせて、初めて会社の仕事を進められる仕組みになります。

参考：OpenAI「Agents SDK」

AIに道具を持たせる

AIエージェントの面白さは、文章を生成するだけでなく、外部の道具を使えることです。

概念的には、例えば次のような機能を用意します。

search_knowledge()
check_quantity()
search_standard()
create_report_draft()

将来的には、

create_cad_script()

のような機能も考えられます。

AIそのものに、すべての能力を持たせるわけではありません。

会社にあるデータやプログラムを、AIが必要に応じて呼び出す。

この考え方は、通常のチャットAIへ質問するだけの使い方とは少し違います。

MCPという共通の接続方法

ここで出てくるのがMCPです。

MCPは、AIを利用するアプリケーションと、外部のデータや道具を接続するための共通的な仕組みです。

例えば、自社専用の機能として、

• ナレッジ検索
• 案件情報取得
• 数量チェック
• CAD用スクリプト生成

などを用意しておけば、MCPに対応する複数のAI環境から再利用できる可能性があります。

これは会社側にとって重要です。

会社固有のデータや道具をAIモデルから分けておけば、特定サービスへの依存を小さくし、接続部分を再利用しやすくなる可能性があります。

ただし、MCPを採用すれば、どのAIにもそのまま交換できるわけではありません。

認証、閲覧権限、データ形式、実行環境、利用するAI側の対応状況は別に設計する必要があります。

参考：Model Context Protocol「Introduction」

社員が使う入口は普通のWeb画面でよい

ここまで書くと、大掛かりなシステムに見えます。

しかし、社員側が見るものは複雑である必要はありません。

案件名：
相談内容：

［AIに確認］

これだけでも構いません。

裏側では、

社員
 ↓
Webアプリ
 ↓
Manager Agent
 ↓
必要な社内情報を検索
 ↓
必要な専門処理を実行
 ↓
社員へ比較材料を提示

と動きます。

社員がAgents SDKやMCPを意識する必要はありません。普段の業務ツールと同じように使えればよいと思います。

一方、実際の運用では、社員ごとの認証、案件ごとの閲覧権限、操作履歴、人間による承認も必要になります。

AIが動く仕組みだけでなく、会社で安全に使う仕組みまで含めて設計しなければなりません。

最初から複数のAIを作る必要はない

AIエージェントという言葉を聞くと、たくさんのAIが自律的に会話しながら働く姿を想像します。

しかし、最初からそこまで作る必要はないと思っています。

まず一つのAIに、

• 相談内容を整理する
• 必要な社内情報を探す
• 注意点をまとめる
• 人間が判断すべき部分を示す

という仕事をさせます。

その一つが本当に役立つことを確認した後で、数量担当、図面担当、技術基準担当と分けていけばよい。

システムを複雑にすることが目的ではありません。

実際の仕事が少し良くなることが目的です。

会社にとって本当に重要なのは、最新のAIモデルそのものではないのかもしれません。

自社の知識と、自社の仕事を、AIが利用できる形にしておくこと。

次は、この「自社の知識」について考えてみます。

AI社員を作る前に、なぜ会社の記憶が必要なのか。実際に社内ナレッジを作ってきた経験から整理します。

---

前の記事： AIを使う会社から、AIと仕事を設計する会社へ

次の記事： AI社員には「会社の記憶」が必要になる