AIで成果を出す組織の設計——人材採用より先に整えるべき3つの仕組み

「AI人材不足」という診断が間違っている——AI活用 成果が出ない 理由はどこにあるか

ある大手化学メーカーのDX推進担当者が、こんな言葉を漏らしたことがあります。「『内製できます』と謳いつつ、実際には難しい。設計側がなかなか進まない」と。社内にAI活用の意欲がある社員は増えた。ツールの使い方を教える研修も実施した。でも、AIが出した結果を誰が確認し、どう業務に反映するか、その仕組みが誰も設計していなかった。

この現象はどこにでもあります。

ChatGPTやClaude、Copilotといったツールを個人が使い始めると、最初の数週間は「便利だ」という声が上がります。ところが3ヶ月後には「担当者が変わったら使われなくなった」「上司にどう報告すればいいかわからない」という状態に戻る。

原因は、ツールの性能でも人材の能力でもありません。「誰が何のためにAIを使い、その出力をどう確認し、どう記録し、どう次に活かすか」というフローが、組織として設計されていないことにあります。

JIPDECの企業IT利活用動向調査2026によると、日本企業のDX推進における障壁の上位は組織間の連携不足・既存業務との統合であり、人材不足はその次に位置します。つまり、人材を増やしても仕組みがなければ動けないのです。

私たちは、採用や育成を急ぐ前に「仕組みの設計」を先に進めることを勧めています。AI活用で成果が出ない状態は、多くの場合、人ではなく「仕組みの不在」から生まれているからです。

VibeCodingが変えた「誰がコードを書くか」問題——チーム設計で変わっていないこと

VibeCoding（バイブコーディング：自然言語でAIに指示を出し、コードを書かずにシステムを作る開発スタイル）の普及で、「コードは書けなくてもシステムが作れる」時代になりました。トランスコスモスが社内での大幅な工数削減を報告し、NTTドコモやZOZOが全社導入に踏み切るなど、大企業でも実用レベルの話が増えています。

この変化は確かに大きいのですが、変わったのは「誰が作るか」だけです。

「誰がAIの出力を判断するか」「誰がレビューし、承認するか」「誰が責任を持つか」——これらは技術が変わっても、AI活用 組織設計の本質的な問題として残ります。VibeCoding チーム設計で最初に問われるのはツールの選択ではなく、このフロー設計です。

2026年6月に東京で開催されたCode with Claude Tokyoに参加した技術者は、ハーネスエンジニアリング（AIエージェントを制御するための仕組み設計）こそがこれからのチームに問われるスキルだ、という発言を残しています。AIに何かを作らせることより、AIの働きを制御し、品質を担保し、組織として再現可能にする設計の方が難しい。これはVibeCoding チーム設計の核心です。

私たちの現場経験でも、この感覚は一致します。VibeCodingで1日でプロトタイプが作れるようになったからこそ、「そのプロトタイプを誰が評価し、どう進化させ、いつ本番に移すか」という組織としての判断フローが問われるようになりました。

仕組み①——「判断の関所」を設計する

AIが出した答えを、どこで誰が確認するか。これが最初に設計すべき仕組みです。

KPMGとEYが相次いでAIレポートを撤回した事件は、この仕組みを持っていなかった組織で起きました（詳細は本誌「AIが間違えたとき、誰が気づくのか」参照）。技術の問題ではありません。

問われているのは、出力をそのまま使ってよい場面と、人間が確認してから使う場面を、組織として設計していたかどうかです。その設計がなかったことが問題の核心でした。

私たちが現場で使っている設計の基本は、業務ごとに「確認コスト」と「ミスのリスク」を掛け合わせて優先度をつけることです。

確認コストが低い	確認コストが高い
AIが作った議事録を本人が読んで修正（リスク低・コスト低）	AIが作った法的文書を弁護士が確認（リスク高・コスト高）
AIが提案した在庫補充量を担当者が承認	AIが判断した製品出荷可否を品質管理部が検証

このマトリクスを現場担当者と一緒に埋めるだけで、「どこに人間の関所が必要か」が見えてきます。全員が全ての出力を確認しようとすると負荷が高くなりすぎるので、最初はリスクが高く確認コストが比較的低い箇所だけを対象にする。これが私たちの出発点です。

ある化学メーカーの工場担当者が「簡単すぎて逆に怖い」と言っていたように、AIの便利さに対する直感的な不安は正しい感覚です。その不安を「仕組み」に変換することが、導入側の責任です。

仕組み②——「ナレッジの蓄積先」を決める

AI活用で成果が出ている組織には、もう一つ共通点があります。AIとのやり取りを「消えない記録」にしていることです。

私たちは社内で「全ての会議を記録する」ことを実践しています。はいはいと聞き流していると1〜2割しか記憶に残らないからです。議事録AIがドラフトを作り、人間が流れと決定事項を確認・加工することで、会議が「ナレッジ」に変わります。この発想を組織全体のAI活用に適用すると、成果の継続性が変わります。

具体的には、以下の3つを「どこに、どの形式で、誰がアクセスできる形で」残すかを決めます。

1. AIが出した提案と、人間がどう判断したか 需要予測AIが「来月の在庫を増やす」と提案したとき、担当者がそれを受け入れたのか、修正したのか、却下したのかを記録する。理由も添える。

2. うまくいったプロンプト（AIへの指示文） 同じ業務を別の担当者がやるとき、ゼロから試行錯誤させない。「この指示文でこの精度が出た」という実績を組織の資産にする。

3. AIが苦手だったこと 「この種類の判断はAIより人間の方が早かった」「このデータ形式はAIが読み違える」という発見を残す。次の担当者が同じ落とし穴にはまらないための記録です。

ある自動車部品メーカーの設備保全担当者は「データはある程度揃ってきているが、そのデータをもとに人がどう考え、どう動くかを定義・教育するのが難しい。マニュアルだけでは足りない」と語っていました。これは「ナレッジの蓄積先がない」問題そのものです。

ツールは何でも構いません。NotionでもGoogleドキュメントでも、自社で開発した社内基盤でも。大切なのは「どこに残す」かを組織として決め、それを実際に使い続ける文化を作ることです。記録が続く仕組みになれば、蓄積が自然と組織の資産に変わっていきます。

仕組み③——「小さく結果を出す場」を設計する

3つ目は、最初の成功体験をどこで作るかです。

「PoCは成功した。でも全社に広がらない」という悩みを持つ企業は後を絶ちません。

マッキンゼーの2026年グローバルAI調査（McKinsey Global Survey on AI, 2026）によると、AIを本格的なビジネス成果まで展開できている企業はわずか6%で、62%が実験段階で止まっています。この数字はPoCそのものの問題ではなく、PoC後の展開設計がないことを示しています。製造業固有の展開設計については本誌「PoC止まりを脱する」も参照してください。

この壁を超えるための設計は、一つのシンプルな問いから始まります。「難易度がそこまで高くなく、かつ影響範囲が大きい業務はどれか」。

難しすぎる業務を最初に選ぶと、AI活用の精度が出ない → 現場が不満を持つ → 「AIは使えない」というレッテルが貼られる、という最悪のパターンになります。逆に、簡単すぎる業務を選ぶと「これなら前からできていた」となって社内の関心が集まりません。

私たちが伴走した製造業のケースでは、まず「週次の生産報告書のドラフト作成」にAIを使うことから始めました。担当者が2時間かけて書いていた報告書を、AIが30分でドラフトを出し、担当者が15分で修正・確認する。この「週1.5時間の削減」という小さな成功が、隣の部署の担当者の好奇心を引き出しました。

重要なのは、最初に結果を出す場の設計をBPR（業務プロセス改革）と連動させることです。AI導入前に業務プロセスを棚卸しして（本誌AI導入より先にやるべきこと参照）、AIが入ると変わる業務とそうでない業務を分類しておけば、最初の着手点が自然と見えてきます。

3つの仕組みをつなぐ——「属人化」を防ぐ設計の考え方

3つの仕組みをバラバラに整えても、それぞれが担当者の頭の中にしか存在しなければ意味がありません。担当者が変われば仕組みも消える——これが「属人化」です。

製造業では特に、熟練担当者の退職とともにAI活用のノウハウが消えるケースを多く見てきました。「彼がいたから動いていた」というのは、仕組みではなく個人依存です。

属人化を防ぐための設計で私たちが重視しているのは、「誰でも同じ手順で動けるドキュメント化」ではなく、「誰がやっても同じ結果に近づくフロー設計」です。前者は作っても読まれず、後者は使われながら育ちます。

具体的には、「判断の関所」に使う確認チェックリストをシステムに組み込む（手書きのマニュアルではなく、作業フローそのものに確認ステップを入れる）、「ナレッジの蓄積先」に記録する作業をAIが自動でドラフトする（人間が一から書くのではなく、AIのドラフトを人間が承認する形にする）、という設計を組み合わせます。

こうすることで、担当者が変わっても「仕組みが人を動かす」状態になります。VibeCodingの文脈で言えば、誰が書いたコードでも同じ品質チェックを通過する設計（本誌「VibeCodingのコードレビューを誰が担うのか」参照）と、考え方は同じです。

AI人材の育成と採用は仕組みの「後」——その本当の意味

ここまでの話を聞いて「では採用は必要ないのか」と思われたかもしれません。そうではありません。

私たちが言いたいのは、「仕組みがない状態でのAI人材 育成や採用は、優秀な人材の浪費になる」ということです。

判断の関所がなければ、採用したAIエンジニアは「何が正解かわからない状態」で作業することになります。ナレッジの蓄積先がなければ、その人が辞めた瞬間に全てのノウハウが消えます。成功体験の場がなければ、どんなに意欲がある人でも「この会社ではAIは使えない」と判断して去っていきます。

仕組みが先にある組織では、採用や育成の効果が全く違います。

VibeCodingはこの状況を加速しています。「エンジニアを採用してコードを書いてもらう」という発想から、「業務担当者がVibeCodingを使って自分たちの業務ツールを作る」という発想への転換が起きています。私たちの現場でも、製造業の業務担当者（非エンジニア）が自分の業務フローを自然言語で説明し、VibeCodingでプロトタイプを作ることが実際に行われています。

ただし、この転換を支えるのも仕組みです。「誰が作ったプロトタイプをどう評価するか」「本番に移す前に何をチェックするか」が決まっていなければ、VibeCodingは「動くかもしれない何か」を大量に生み出すだけになります。

私たちが持論として繰り返しているのは、「世の中のAI勉強会や講座は、講座になった時点ですでに古い」ということです。個別ツールの使い方は動画で習得できます。組織として整えるべきは、「AIの特性を踏まえてどう使うかというコアな考え方」と「それを再現可能にする仕組み」です。

AI-Pathの見解——「AI人材」の定義そのものを変える

私たちが現場で積み上げてきた経験からはっきり言えることがあります。「AI人材」という言葉は、実はとても曖昧に使われています。

「AIを使える人を採用したい」という要望を解きほぐすと、「AIモデルを開発できる人（データサイエンティスト・MLエンジニア）」を求めているケースはむしろ少数で、多くの場合は「AIを使って業務効率を上げられる人」を求めています。後者であれば、既存の業務担当者をリスキリング（既存社員の再教育）する方が、採用より早く・低コストで実現できるケースが多いです。

私たちが製造業で見てきた「定着した組織」の共通点は、AIを使う人の肩書ではなく、使うための「場」が設計されていることです。週1回30分だけAI活用の知見を共有する場を作った工場、月に1度だけ「うまくいった事例」を全員で確認する会議を設けた建設会社——どちらも大きなコストはかけていませんでしたが、半年後には、いずれも組織の文化が変わっていました。

一方、「止まった組織」には特徴があります。最初の研修に多額の費用をかけた後、「あとは各自でやってください」という状態になる。AIツールのライセンスだけ支給して、使い方を各自が自主的に学ぶことを期待する。この「任せきり」が、定着しない最大の原因です。

私たちが勧めているのは「コツコツと成功体験を積み上げる」ロードマップです。急成長より、小さな成功が組織に染み渡っていく速度を大切にする。これは技術論ではなく、組織論として正しい順序です。

「3つの仕組み」が整うとどうなるか——現場からの報告

ある中堅の食品メーカーでは、1年前まで「AIって何から始めれば？」という状態でした。私たちがFDEとして入り、まずBPRで業務の棚卸しを実施。次に「判断の関所」として品質管理の最終確認フローを設計し、「ナレッジの蓄積先」として社内の業務知識をAIが参照できる形で整備し、「小さく結果を出す場」として生産報告書の自動ドラフトから始めました。

今では、その担当者が自発的に「この業務にもAIを使えないか」と提案してくるようになっています。AI人材を採用したわけではありません。既存の担当者が、仕組みの中でAIを使いこなすようになった結果です。

もう一つ、ある建設資材メーカーのケースです。担当者から「現場の人に何をしたいかと問っても情報が上がってこない」という悩みを聞いた際、私たちが提案したのは「AIへの質問のハードルを下げる設計」でした。専用のチャット画面に業務の困りごとを入力すると、AIが関連する過去の事例と担当者の一覧を提示する。これだけで、現場から情報が上がるようになりました。

仕組みが人の行動を変えた例です。

よくある質問

Q. 3つの仕組みを全部整えないと始められませんか？

全部が揃うのを待つ必要はありません。「判断の関所」だけ先に決めて、残りは動かしながら整える進め方が現実的です。ただし「ナレッジの蓄積先」だけは最初から決めておくことを強く勧めます。後から記録を集めようとしても、すでに消えているからです。

Q. 何人からチームを組むべきですか？

最初は1〜2人で構いません。推進担当者1人と、業務側の担当者1人がいれば、3つの仕組みの設計は始められます。「AI専門チーム」という組織を作ることより、既存の業務担当者がAIを使えるようにする方が、長期的な定着には効果的です。

Q. VibeCodingに対応できるエンジニアが社内にいません。どうすればいいですか？

VibeCodingは「エンジニアがいなくてもシステムが作れる」を実現するための手段ですが、最初は外部の伴走が必要なケースがほとんどです。社内にエンジニアがいなくても、設計フェーズから一緒に動いてもらえるFDE（フォワードデプロイドエンジニア）と組むことで、「作りながら社内に知見を育てる」進め方が可能です。

Q. 採用はいつ始めればいいですか？

3つの仕組みが動き始めて、「この業務をもっと深く進化させたい」というボトルネックが見えてからが正しいタイミングです。何をやってもらうかが明確であれば、採用要件も面接での見極めも格段に精度が上がります。

まず試すなら

1. 業務ごとの「確認コスト × ミスリスク」マトリクスを1枚作る

A4一枚で構いません。現在AI（またはAI導入を検討している）で扱っている業務を縦軸に、「確認のコスト（低・中・高）」と「ミスが起きたときのリスク（低・中・高）」を横軸にマッピングします。これだけで「どこに判断の関所が必要か」が見えてきます。

2. 最初の「成功体験の場」を1つだけ選んで期限を切る

BPRで整理した業務リストの中から、難易度が低く影響範囲が大きい業務を1つ選びます。「来月中に、この業務でAIを使った試験運用を開始する」と期限と担当者を決めます。期限がなければ、いつまでも「検討中」になります。

3. AI-Pathの無償の業務プロセス診断（BPR）を活用する

「どこから手をつければいいかわからない」という状態であれば、業務プロセスの棚卸しから一緒に始めることができます。AI-Pathでは、無償の業務プロセス診断（BPR）を実施しています。業務の現状を整理し、「どこにAIが効くか」「最初の着手点はどこか」をFDEが現場に入って一緒に見ていきます。

AI内製化の体制を整えるうえで「何から始めればいいかわからない」という声は、私たちが最も多く受ける相談の一つです。その場合、まず「仕組みがない状態を明確にする」ところから始めると動きやすくなります。何がないかが分かれば、何を先に作るかが決まるからです。BPR診断はその「現在地の確認」として機能します。まずは気軽にご相談ください。

参考リンク

• JIPDEC 企業IT利活用動向調査2026
• McKinsey The State of AI 2026
• Code with Claude Tokyo参加レポート AI時代に強い組織とは何かを考えさせられた