AI社員の育て方
AI社員の育て方 / 第14章: AI社員同士を連携させる
第14章 | AI社員の育て方

第14章: AI社員同士を連携させる

「提案して」と6部署に聞いたら、全員が同じことを言い始めた

CC Company（シーシーカンパニー）の部署が15に増えたとき、ふと思いつきました。「これだけ専門家が揃っているなら、全員に一度に意見を聞いたら面白いんじゃないか」。

テーマは「この仕組みで、どうやって売上を作るか」。マーケティング部、営業部、コンサルティング部、リサーチ部、クリエイティブ部、IT部。6つの部署に同時に投げました。

数分後、レポートが上がってきました。開いてみて、がっかりしました。

全部署が同じことを言っていたのです。「SNSで宣伝しましょう」「ターゲットを絞りましょう」「差別化が大事です」。マーケティング部もコンサルティング部も、ほとんど同じ一般論。部署ごとの専門性がまるで感じられない。まるで、同じ会議室に6人集めたのに、全員が空気を読んで当たり障りのない発言をしている状態でした。

しかも、もっと根本的な問題に気づきました。15部署あるのに、「会議」が1回もなかった。マーケティング部が毎日書いている記事を営業部は読んでいない。営業部が管理している講演案件の情報を、マーケティング部はコンテンツに活かせていない。各部署は優秀だけれど、隣の部署が何をしているか知らない。

オーケストラに例えるなら、バイオリンもチェロもフルートも全員が腕利きなのに、指揮者がいないから好き勝手に弾いている状態。どの楽器も美しい音を出しているのに、全体としては騒音になっている。

この章は、そのバラバラな演奏を、ひとつの音楽に変えた話です。

あなたの現在地を確認する

以下の問いに答えてみてください。

全部チェックが付いた方: すばらしい。AI社員が「組織」として動いています。この章では、その仕組みの裏にある設計パターンを学術的に理解しましょう。

1〜3個の方: 部署はあるが、まだ「バラバラに動いている」段階です。この章で連携の設計方法を学びましょう。

チェックがゼロの方: まだ第7章（専門家を育てる）の段階かもしれません。まずは2〜3の専門AI社員を作ってから、この章に戻ってきてください。

優秀な部署が揃っているのに、成果が出ない

あなたの会社で、こんなことはありませんか。

営業部が大口の案件を取ってきた。でも、その情報がカスタマーサポートに伝わっていない。お客さんから問い合わせが来たときに「そのような案件は聞いておりません」と答えてしまう。営業は怒り、お客さんは不安になり、上司が間に入って火消しに走る。

あるいは、マーケティングが新しいキャンペーンを打ったのに、営業がそのキャンペーンの存在を知らない。お客さんから「あのキャンペーンの件で」と電話が来ても、営業は「何のことですか？」と聞き返す。

どちらの部署も、自分の仕事はきちんとやっている。問題は、部署と部署の「間」に落ちている情報があることです。

経営学では、これを「サイロ化」と呼びます。サイロは穀物を貯める円筒形の倉庫のことで、中の穀物は外から見えないし、隣のサイロと中身を交換する仕組みもない。各部署が自分のサイロの中で閉じている状態です。ハーバード・ビジネス・レビューでは、サイロ化が企業の意思決定の質を著しく低下させるとして繰り返し取り上げられています（グラティ（Gulati）, 2007 「Silo Busting」（サイロを壊す））。異なる部門の知識が統合されないと、個々の判断は正しくても全体としては最適でない結論に至ってしまうのです。

CC Companyでも、まったく同じことが起きていました。AI社員の組織だから大丈夫、ということは一切ない。むしろ、AI社員は人間以上にサイロ化しやすい。なぜなら、AI社員は「聞かれていないことは答えない」からです。人間の社員なら、廊下ですれ違ったときに「そういえばあの件」と情報を渡すことがある。AI社員にはそれがありません。

川島さん（第1章から登場している、従業員30名のIT企業で事務を担当する42歳の方です）も、AI社員を3つに増やした時点でこの問題にぶつかりました。営業用のAI社員が受注した案件の情報を、カスタマーサポート用のAI社員が知らない。お客さんから「契約内容を確認したいのですが」と問い合わせが来たとき、サポート用AIが「該当する情報がありません」と返してしまう。川島さんが手動で情報を転記して対応する羽目になり、「AI社員を増やしたのに、かえって仕事が増えた」と嘆きました。

1人に聞いたときと、組織に聞いたときの違い

冒頭の「全部署に提案を求めた」話に戻ります。

最初の失敗で見えた問題は2つありました。1つは、各部署が自分の専門性を活かしていなかったこと。もう1つは、各部署が社内の他部署のデータを参照していなかったことです。

1人のAI社員に「新しいサービスの価格はどうすべきか」と聞くと、一般論が返ってきます。「競合を調べましょう」「ターゲット層を考えましょう」。悪くはないけれど、あなたの会社にすでにある情報は活用されません。

ところが、同じ質問を「組織として」聞くと、結果がまるで変わります。

CC Companyで2回目の全社提案を実行したとき、各部署に「あなたの専門分野のデータだけで語ってください」とルールを追加しました。すると、営業部は「過去の講演で単価30〜50万円が通っている。この価格帯なら受注実績がある」と自分が管理している実績から答える。マーケティング部は「noteの記事データから、体験談カテゴリが最もスキ率が高い。書籍の内容を体験談として小出しにすれば読者を購入者に転換できる」と自分が持っているアナリティクスから答える。リサーチ部は「自社の実践をコンテンツ化して書籍にし、コンサルティング事業に発展させた海外事例がある」と外部の事例を検索して持ってくる。

全員が同じ一般論を言っていた1回目と、専門家が自分のデータで戦った2回目。同じ6部署なのに、使える情報量がまったく違いました。

さらに3回目のテストでは、6部署全てが「記事の質ではなく、発見される仕組みと次の行動設計が足りない」という同じ構造的問題を、それぞれ異なるデータから指摘しました。マーケ部はアナリティクスから、営業部は案件パイプラインから、コンサル部は既存クライアントの声から。6人の専門家が別々の角度から同じ結論に到達したとき、「これは確度が高い」と判断できました。

ただし、各部署が優秀な提案を出しても、それをまとめて使える形にする仕組みがなければ、情報は散らばるだけです。ここから、連携の設計が始まりました。

記事を書き終えたのに、誰もSNSに投稿していなかった

CC Companyで最初に見えた連携の穴は、「成果物の引き継ぎ」でした。

マーケティング部が記事を書き終えた。品質チェックも合格した。でも、その記事をX（エックス）やFacebook（フェイスブック）に投稿するSNS担当は、記事が完成したことを知らない。記事は完成しているのに、誰もSNSに投稿していない。翌日になって「あの記事、SNSに出しましたか？」と聞いて初めて「出していません」と発覚する。

あなたの会社でも、こんな経験はありませんか。製造部門が納品物を完成させたのに、物流部門に連絡が行っていない。設計部が図面を仕上げたのに、施工部がそれを知らない。どの会社でも「引き継ぎの隙間」で仕事が止まることがあります。

CC Companyでは、マーケティング部の育成マニュアルに「記事が完成したら、SNS投稿の作成フローに入る」と1行追加しました。たった1行ですが、記事完成からSNS投稿までのタイムラグがゼロになりました。

次に見えた穴は、「情報の参照」です。秘書が週次レビューを作るとき、マーケティング部が管理しているnoteのアナリティクスデータ（閲覧数やスキ数など）を読みに行く必要がありました。しかし、秘書の育成マニュアルに「マーケティング部のどのファイルを読めばいいか」が書いてなかった。だから秘書は、データの存在を知らないまま、数字のない週次レビューを出していました。

「どの部署のどのファイルを読めば答えが見つかるか」を育成マニュアルに明記する。これだけで、秘書のレポートに数字が入るようになりました。

そして3つ目の穴。第9章で学んだ「実行者と検証者を分ける」を組織レベルで適用することです。記事を書いたマーケティング部が自分でチェックするだけでなく、品質チェック専門のスキルが別途評価する。さらに、第三者のAI（Codex CLI（コーデックスシーエルアイ：コマンドラインで動くAIレビューツール））がゲートキーパーとして最終チェックする。この3段階のレビュー構造は、1つの部署では実現できません。組織だからこそ機能する仕組みです。

振り返ると、3つの穴すべてに共通点がありました。「部署が優秀かどうか」の問題ではなく、「部署と部署の間のルールが決まっていなかった」問題です。引き継ぎのタイミング、参照先のファイルパス、レビューの委譲先。それぞれ1行ずつ育成マニュアルに追加するだけで、情報が流れ始めました。

秘書を通さなかったら、タスクが行方不明になった

連携の穴を1つずつ塞いでいく中で、もっと根本的な問題にぶつかりました。そもそも「誰が連携を管理するのか」が決まっていない。

CC Companyでは、最初の頃、「マーケの仕事だから」とマーケティング部に直接指示を出していた時期がありました。すると、秘書が把握していないタスクが発生します。数日後に「あの記事どうなった？」と聞いても、秘書は「そのタスクは登録されていません」と答える。Google Tasks（グーグルタスクス）にも載っていないから進捗が追えない。タスクが行方不明になるのです。

これは、人間の会社でよく起きる「上司が部下に直接頼んで、マネージャーが把握していない」パターンとまったく同じです。頼んだ本人は覚えているけれど、チームとしての管理から外れている。

窓口を秘書に一本化した途端、タスクの抜け漏れがなくなりました。

オーナーが「記事を書きたい」と言ったら、秘書がマーケティング部に振り分ける。「講演の提案書を作って」と言ったら、秘書が営業部に振り分ける。オーナーは秘書にだけ話しかければよく、15部署の役割を覚える必要がない。秘書の育成マニュアルには「コンテンツ、SNS、記事、集客というキーワードが来たらマーケティング部」「契約書、NDA、法的リスクなら法務部」という振り分けルールが書いてあります。新しい種類の依頼が来るたびに、このルール表が育っていく。秘書が賢くなるのではなく、ルールが育つのです。

川島さんも、AI社員が3つになったタイミングで同じ問題に直面していました。「営業AI、サポートAI、議事録AI。3つに増えたら、どれに何を頼めばいいか分からなくなった」。彼女が試したのは、シンプルな方法でした。秘書AIに「あなたが全部の依頼を受けて、適切なAI社員に振ってください」と1行追加した。するとそれだけで、「営業のことはこのAIに」「サポートのことはこのAIに」と秘書が自動で振り分けてくれるようになりました。「どのAIに頼むか考える時間」がゼロになった、と川島さんは言います。

ただし、秘書を万能にしてはいけません。秘書の仕事は「タスクの登録」「部署への振り分け」「進捗の管理」の3つです。実際の記事を書いたり分析をしたりする作業は各部署がやる。秘書に何でもやらせると、第7章で学んだ「何でも屋病」になります。

連携は「育成マニュアルの1行」から始まる

ここまで読むと、「連携って大がかりな仕組みが必要なのでは」と思うかもしれません。実際にCC Companyでやったことは、驚くほどシンプルでした。

各部署の育成マニュアルに、「連携先」を書くだけです。

たとえば、営業部の育成マニュアルにはこう書いてあります。

秘書室
連携内容
スケジュール管理、タスク管理
タイミング
タスク開始時・完了時
マーケティング部
連携内容
コンテンツ戦略の方針確認
タイミング
新規記事企画時

AI社員が「自分はどの部署と、いつ連携すべきか」を知った状態で仕事を始められます。

加えて、第10章で学んだタスクのライフサイクル（開始→実行→レビュー→完了→報告）に、連携のタイミングを埋め込みました。開始時は秘書がタスクを作って担当部署に振り分ける。実行中に他部署のデータが必要なら、指定されたファイルパスを読みに行く。レビュー時は実行者以外のAIが検証する。完了時は秘書がタスクの完了を記録し、後続タスクがあれば次の部署に引き継ぐ。

特別なツールや複雑な仕組みは不要でした。育成マニュアルの1行と、タスクのライフサイクルの各段階に「次に何をする」を書いただけ。それだけで、バラバラだった部署が「組織」として動き始めたのです。

規模に応じた実践: 個人・チーム・組織

個人で始めるなら

連携を意識する最初のステップは、「1つのAI社員に全部やらせない」ことです。記事を書くAIと、書いた記事をチェックするAI。この2つを分けて連携させるだけでも、品質は大きく変わります。1人で作って1人でチェックするのは、自分の答案を自分で採点するようなものです。

チームで使うなら

複数のAI社員がいる場合、「引き継ぎルール」を3つだけ決めてください。「記事スキルが原稿を完了したら、品質チェッカーがレビューを始める」「品質チェックに合格したら、SNS投稿の作成に入る」「SNS投稿文ができたら、秘書に完了報告する」。この3つだけで、手動での引き継ぎ作業がなくなります。

組織として運用するなら

「窓口AI（秘書）」と「振り分けルール」を最初に整備してください。各部署のAI社員がどれだけ優秀でも、窓口がなければ活用されません。「困ったら秘書に言えばいい」という1つのルールが、組織全体のAI活用率を引き上げます。CC Companyでは、9部署への振り分けルールを秘書の育成マニュアルに記載しています。キーワードと振り分け先の対応表です。「コンテンツ、SNS、記事」ならマーケティング部。「契約書、NDA」なら法務部。判断に迷うときだけ、オーナーに確認を取ります。

コラム: 設定2行で「会議の質」が激変した

CC Companyの全社提案機能（/propose）を初めてテストしたとき、6部署が並行で動いて提案を出す仕組みは動きました。しかし、提案の中身が浅い。全部署が「社内で知っていること」の範囲でしか語れなかったのです。外の事例、競合の動き、最新のトレンド。そういった「社外の情報」が一切入っていない。

原因を調べたら、AI社員がWeb検索をする権限が設定ファイルで許可されていませんでした。部署ごとにAI社員を並行で動かすとき、子プロセスのAI社員にはWeb検索の権限が自動的には引き継がれない仕様だったのです。

設定ファイルに2行追加しました。「WebSearch（ウェブサーチ：Web検索）」と「WebFetch（ウェブフェッチ：Webページ取得）」を許可リストに加えただけです。

その直後に実行した3回目のテストで、景色が一変しました。マーケティング部は「noteのドメインパワーを活かしたSEO戦略の海外事例」を検索して持ってきた。リサーチ部は「自社の実践を書籍化してコンサルティングに発展させた海外企業の成功パターン」を見つけてきた。営業部は「講師プラットフォームの最新動向と登録すべき3社」を調べてきた。

2行の設定変更で、6部署の提案が「社内の知識の焼き直し」から「外部事例付きの具体的な提案」に変わりました。約7分で6部署が並行に動き、Web検索込みでレポートが上がってくる。人間の会議で同じ成果を出そうとしたら、事前調査だけで何日かかるか分かりません。

連携の質を上げるのは、大がかりな仕組みの改修ではなく、「つながるべき情報がつながっていない」ボトルネックを1つずつ外すことでした。

LLM（Large Language Model：大規模言語モデル）知識: なぜAIの「組織化」が効くのか

この章で紹介した「AI社員同士の連携」は、AI研究の分野では「マルチエージェント・オーケストレーション」と呼ばれる設計パターンです。「オーケストレーション」はオーケストラ（管弦楽団）から来た言葉で、指揮者が各楽器の出番を管理して美しい音楽を生み出す仕組みのことです。CC Companyに当てはめると、秘書が指揮者、各部署が演奏者です。

2023年にスタンフォード大学の研究チーム（パークら（Park et al.））が発表した「Generative Agents」（生成エージェント）という論文では、25体のAIエージェントに役割を与えて仮想の町に住まわせ、自律的に行動させる実験が行われました。この研究で分かったことの1つが、エージェント同士が情報を共有し合うと、個々のエージェントだけでは到達できなかった行動パターンが自然に生まれるということです。CC Companyで6部署が同じ構造的問題を別々のデータから指摘した現象は、この知見と一致しています。

「段取り役・実行役・監督役」の3役分離

第10章で紹介したcore-workflowは、AI研究で「Scheduler-Agent-Supervisor（スケジューラー・エージェント・スーパーバイザー：段取り役・実行役・監督役）」と呼ばれるパターン（複数のAIに役割を分担させ、段取り・実行・監督を分離する設計）を応用しています。

人間の会社で言えば、プロジェクトマネージャーが工程表を作り、各担当者が実作業を行い、部門長が週次で進捗を確認する。どの会社にもある普通の構造です。特別なツールがなくても、「人間の会社組織を模倣する」という発想で、同じ構造に自然に到達できるのです。

Microsoft（マイクロソフト）のAutoGen（オートジェン）プロジェクト（ウーら（Wu et al.）, 2023）やGoogle DeepMind（グーグルディープマインド）の研究でも、複数のAIエージェントに役割を分担させて協調させることで、単一のエージェントよりも高い精度と信頼性を達成できることが報告されています。この効果は、役割が明確に分離されているほど大きくなる傾向があります。CC Companyの「秘書は振り分けだけ、各部署は実行だけ、起動ルーティンは監視だけ」という設計は、この知見に合致しています。

まとめ