AIを使う会社から、AIと仕事を設計する会社へ
NECがAIだけで構成する社内組織を設けたというニュースをきっかけに、AIを便利な道具として使う段階と、人とAIの役割を分けて仕事を設計する段階の違いを考えます。
AIと仕事を設計する｜第1回
AIを使う会社から、AIと仕事を設計する会社へ
2026年8月、NECが、部門長から社員まですべての役割をAIが担う社内組織「コーポレートAI・Workforce部門」を設けたというニュースを見ました。
この組織は、AI部門長、AIボード、AIマネージャー、AI社員という4階層で構成されます。AIが業務を進め、人間の経営層が最終的な評価、意思決定、ガバナンスを担う仕組みです。
単に社内で生成AIを利用するという話ではありません。
AIがいることを前提として、仕事の分け方と組織そのものを設計しようとしている。
ここが、かなり大きな変化だと思いました。
参考：ITmedia AI＋「NEC、部門長から社員まで『全員AI』の新組織」
生成AIを導入することと、AI前提で仕事を設計することは違う
生成AIを業務で使う会社は、珍しくなくなりました。
文章を作る。メールを整える。会議を要約する。Excelの関数を聞く。資料を検索する。プログラムを書く。
これだけでも十分便利です。私自身も、ChatGPT、Gemini、Claude、Codexなどを実務のさまざまな場面で使っています。
しかし最近、それとは少し違う方向を考えるようになりました。
「人間がAIを使う」だけではなく、
人間とAIが、それぞれ役割を持って仕事を進める仕組みを作れないだろうか。
ということです。
一つのAIへ何でも頼むのではありません。
- 過去資料を探すAI
- 数量を確認するAI
- 図面を確認するAI
- 技術基準を探すAI
- 報告書を整理するAI
- それらの結果をまとめるAI
- 最後に判断する人間
こうした役割分担です。
AIエージェントという考え方
最近よく聞く「AIエージェント」は、この考え方に近いものです。
通常の生成AIは、質問と回答のやり取りが中心です。
一方、AIエージェントは、与えられた仕事に対して必要な処理を考え、道具を利用し、必要であれば別の専門的なAIへ仕事を渡しながら、複数の工程を進めます。
AIモデルそのものとは別に、
- どのような役割を与えるのか
- どのデータを見せるのか
- どの道具を使わせるのか
- どこまで実行を許可するのか
- どこから人間へ確認させるのか
を設計する考え方です。
AIの性能だけでなく、仕事の渡し方を設計する必要が出てきました。
CodexやClaude Codeそのものが「AI部署」ではない
私自身、AIを使ったプログラム開発や業務ツールの試作では、CodexやClaude Codeを使っています。
コードを書き、ファイルを読み、プログラムを修正し、複数工程の作業を進められる強力な道具です。
ただし、CodexやClaude Codeを起動しておけば、それだけで会社のAI部署が完成するわけではありません。
社員が通常の業務で利用するには、入口となる画面、参照する社内情報、利用できる機能、権限、実行記録、人間による確認方法などを別に考える必要があります。
CodexやClaude Codeは、その仕組みを一緒に作る開発者として利用できます。
さらに、完成した仕組みの中で、コードやファイル処理を担当する専門的なAIとして動かすことも考えられます。
大切なのは製品名で「作る側」と「働く側」を分けることではなく、どのAIへ何を担当させるかを決めることです。
土木設計でも仕事を分けられるのか
ここからが、私にとって一番興味深いところです。
土木設計の仕事には、AIが得意な部分と苦手な部分があります。
例えば最近、配筋図の自動化についてAIを使いながら検証しました。
配筋の考え方、鉄筋形状、加工図との関係などを整理することはできます。しかし、それを正しい二次元配筋図として完成させるとなると、一気に難しくなります。
理解できることと、成果品を作れることは別でした。
だから、一つの万能AIに「配筋図を完成させて」と頼む方向だけを追う必要はありません。
- 図面の形状を読む
- 配筋条件を確認する
- 数量との不整合を探す
- 過去事例を探す
- 怪しい箇所を提示する
- 人間が確認すべき部分を示す
と仕事を分けた方が、現実的かもしれません。
AIへ仕事を奪わせるのではなく、仕事を分解して、AIと人間へ再配置する考え方です。
AI社員を作る前に必要なもの
さらに考えていくと、AIエージェントを作れば、すぐ会社の仕事ができるわけではないことにも気づきます。
AIは、会社の事情を知りません。
過去にどのような判断をしたのか。どのような失敗があったのか。何に注意するのか。会社として何を優先するのか。誰が最終判断するのか。
こうした情報がなければ、一般論を答えるAIにはなっても、その会社で働くAIにはなりません。
NECの事例でも、AI組織だけで対応できないデータ、権限、ナレッジ、コンテキストの整備は、人間側へ要求する仕組みになっています。
AIエージェントの前に必要なのは、
会社の記憶を、AIが利用できる状態にすること。
なのかもしれません。
小さな会社だから試せることもある
NECのような大企業と、私たちのような小さな会社では、規模も目的もまったく違います。
しかし、小さい会社だからこそ試しやすい部分もあります。
人数が少ない。意思決定者が近い。業務の流れが短い。試して駄目なら、すぐに方向を変えられる。会社全体を対象にしても、範囲が大きくなりすぎない。
また、小さな専門会社は、限定された領域について深い経験を持っています。その経験を使えるのであれば、自社専用AIとの相性は悪くないかもしれません。
ただし、最初から巨大なAI組織を作るつもりはありません。
まず考えているのは、
過去の会社ナレッジを探し、今回の仕事に関係する注意点を整理するAIです。
AIができること、社員が行うこと、最終判断が必要なことを分けて提示させる。そこから、本当に実務で役立つのかを確かめたいと思っています。
「AIを導入した会社」の次へ
生成AIを契約すること自体は、今後さらに普通になると思います。
しかし、それだけでは会社の仕事そのものは大きく変わりません。
本当に変わるのは、
AIを前提として仕事を分解し、人間とAIの役割を再設計したとき。
なのかもしれません。
誰が読むのか。誰が探すのか。誰が計算するのか。誰がチェックするのか。誰が判断するのか。
そこを一つずつ見直していく。
AIを使う会社から、AIと仕事を設計する会社へ。
小さな土木設計会社でどこまでできるのか。これから実際に試し、その過程も技術ノートへ残していこうと思います。
次の記事： AIエージェントは何で動かすのか――Codex、Claude Code、Agents SDKをどう使い分けるか