AI時代、価値はどこへ移るのか¶

「AIが使える人」から「AIが回る形にできる人」へ¶

対象 / ポイント

対象: AIツールの基本操作は身につけたが、次にどの職能を伸ばすべきかを考えているエンジニア、テックリード、AI導入担当者。

ポイント:

AIで下がるのは、低文脈な実行・変換・単発実装のコスト
価値は、業務、チーム、評価、基盤を設計できる人へ移る
個人最適のAI活用を、チームと組織で回る形に変える力が差になる

シリーズ

第0回（この記事）: AI時代、価値はどこへ移るのか
第1回: AIはどの業務に渡してよいのか

AIツールは広がった。

それでも多くの組織では、期待したほど成果が出ていない。問題は、AIが使えないことではない。 AIをどこに入れ、誰と分担し、どう確かめるかが、まだ設計されていないことである。

この記事の問いは、AIで実行コストが下がるとき、人間側に残る仕事はどこへ移るのか、である。

道具は揃ったのに、なぜ成果が出ないのか¶

AI導入の焦点は、「使えるか」から「業務の中で回るか」へ移っている。

OpenAIは、ChatGPT Enterprise の週次メッセージ数が前年比で約8倍になったと報告している¹。 Projects や Custom GPTs のような構造化ワークフロー利用も、年初来で19倍に増えた。利用量だけを見れば、企業のAI活用はすでに広がっている。

しかし、利用が増えることと、企業全体の成果に変わることは同じではない。 WEFは、単発ユースケースではなく、AIをコアワークフローや意思決定へ埋め込む必要があると整理している²。

ここに断絶がある。

利用量は爆発している。だが、企業成果への接続は別問題だ。だから差がつく場所は、「AIを使える人」から「AIが回る形にできる人」へ移る。

個人は、AIで自分の作業を速くできる。だが組織では、速くなった作業を業務プロセス、責任分界、評価基準へ戻さなければならない。速さを運用へ変換して初めて、成果になる。

AIで安くなるもの、残るもの¶

AIでまず下がるのは、低文脈な実行コストだ。

たとえば、週次報告の集約、障害報告の一次要約、定型問い合わせの下書き、 FAQ更新案のたたき台。これらは、入力と期待出力が比較的はっきりしている。 AIに渡しやすく、失敗しても人間が修正しやすい。

一方で、下がりにくいものがある。

どの業務をAIに渡してよいかを切る判断
複数人の成果物を同じ方針に揃える設計
AIの出力をどこで止め、どう確かめるか
認証、権限、監査、既存システムとつなぐ実装

この4つは、単なる作業ではない。組織の中でAIを働かせるための設計である。 AIで実行が安くなるほど、何を実行させるかを決める職能に差がつく。

4つの設計対象で見る、仕事の重心¶

ここからは、この変化を4つの設計対象に分けて見る。

4つの設計対象とは、業務、チーム、評価、基盤である。これは公式の分類ではない。公開資料を横断しながら、AI導入で実際に詰まりやすい場所を整理するための見取り図である。

この記事では、便宜上これを4層と呼ぶ。

層	見るもの	代表的な問い
業務適用設計	業務の性質	どの業務にAIを入れてよいか
チーム設計	複数人の整合性	個人最適をどうチーム最適に変えるか
評価・制御設計	出力と停止条件	何を測り、どこで止め、誰が通すか
基盤・統合設計	企業制約	何と接続し、どの権限で動かすか

業務適用設計は、AIに渡す対象を選ぶ層である。チーム設計は、それを複数人で回る運用形に変える層だ。評価・制御設計は壊れにくさを作り、基盤・統合設計は企業内での実行可能性を作る。

Microsoftは、AIエージェントが組織に入るにつれ、人間とエージェントのチームや human-agent ratio の設計が重要になると述べている³。 human-agent ratio とは、人間1人に対してどれだけのAIエージェントを実務上管理・協働させるかを考える設計概念である。これは、AI活用が個人の操作スキルから、組織設計の問題へ移っていることを示している。

では、この4層は順番に積み上がるキャリアラダーなのか。

違う。4層は、相互依存する設計層である。次の図は導入順序ではなく、どこか1層が弱いと他層にも歪みが返ってくることを示している。

flowchart LR
    A[業務適用設計<br/>何に入れるか] --> B[チーム設計<br/>誰とどう回すか]
    B --> C[評価・制御設計<br/>どう確かめるか]
    C --> D[基盤・統合設計<br/>どう動かすか]
    D --> A

業務の切り方が悪ければ、評価は複雑になる。チームの共有仕様が弱ければ、AIの出力は人によって揺れる。基盤や権限が詰まれば、よいPoCでも本番では止まる。

どこか1層だけを強くしても、組織では回らない。

個人最適と組織最適は別問題である¶

個人のAI活用は、すぐ成果が見えやすい。

自分のメモを要約する。自分のコードを直す。自分の資料を整える。この範囲では、文脈も判断基準も自分の頭の中にある。多少ずれても、自分で直せば終わる。

チームになると、条件が変わる。

命名、責務分担、レビュー基準、テスト方針、リリース判断。これらは、個人の頭の中ではなく、チームの合意として存在しなければならない。AIは、明文化されていない合意を安定して守れない。

さらに組織になると、制約が増える。

個人が便利だと思ったワークフローでも、企業ではデータ持ち出し、アクセス権限、監査ログ、契約、セキュリティレビューで止まる。AI活用は、個人の工夫から組織の運用系へ移った瞬間に、別の問題になる。

flowchart TD
    P[個人<br/>自分の作業を速くする] --> T[チーム<br/>複数人の成果を揃える]
    T --> O[組織<br/>制約の中で継続運用する]
    P -. 断絶 .-> O

この断絶を越えるには、個人の便利さを、チームの整合性と組織の運用系へ変換する設計が要る。

個人・チーム・組織で、必要な力は変わる¶

ここでいうスコープとは、その設計がどの範囲で効くかである。個人、チーム、組織の3つに分けると、同じ4層でも必要な力が変わる。

さきほどの表は「何を設計するか」を分けた。次の表は、それを「どの範囲で効かせるか」に展開したものである。

層	個人	チーム	組織
業務適用設計	自分の作業を選ぶ	チームの対象業務を切る	投資領域と非対象領域を決める
チーム設計	自分のAI利用ルールを定める	共有仕様とレビュー分担を作る	人とAIの役割分界を再設計する
評価・制御設計	出力を自分で確認する	共通の合格基準を作る	ガバナンスと承認境界を持つ
基盤・統合設計	手元の実行環境と接続前提を整える	チームの実行環境を揃える	認証、監査、権限、運用を統合する

この表で重要なのは、同じ「AIを使う」でも、スコープが変わると職能が変わることだ。

個人で強い人が、そのまま組織導入で強いとは限らない。逆に、最新ツールの細かい操作に詳しくなくても、業務境界、責任、評価、基盤を結べる人は、組織のAI導入で価値を出せる。

次に掘り下げる4つの問い¶

1つ目は、業務適用設計である。 AIは「できる業務」ではなく、「渡してよい業務」をどう見極めるのか。判断密度、事故コスト、例外の多さ、入力の安定性を見る回だ。 McKinseyは、AIで成果を出すには、導入そのものより採用・拡張の実践が効くと整理している⁴。

2つ目は、チーム設計である。なぜ個人では便利だったAI活用が、チームになると整合性コストに変わるのか。 MicrosoftやGitHubの公式資料に加え、開発者調査を補助線にして読む。

3つ目は、評価・制御設計である。なぜ高精度なAIでも、止め方と通し方がなければ使われないのか。 OpenAI、NIST、Anthropicの公開資料を横断し、 AIを壊れにくくする共通原則として整理する⁵⁶⁷。

4つ目は、基盤・統合設計である。なぜ手元で動くPoCが、本番では認証・権限・監査で止まるのか。その壁を、Azure、Google Cloud、AWSの公開アーキテクチャ資料を横断して整理する。

以降の記事では、この4つの問いを順に掘り下げる。追うのは、ツールの流行ではない。

AIで実行が安くなったあと、何を人間が設計し続けるのかである。重心は、手を動かす量から、何を動かすべきかを決める力へ移る。そこに、AI時代に残る強い職能がある。