「同僚がAIの会社」を、コードゼロで手に入れた話

万能AIを1体作ればいい、という発想がなぜ破綻するか

AIを仕事に入れたい。そう考えた瞬間、多くの人はまず「賢いAIを1体作ればいい」と思う。予定確認、メール返信、タスク通知、顧客登録、見積作成、レポート生成。ひとつの巨大なプロンプトにすべてを押し込めば、最初は感動するほど動く。しかし業務が増えるほど崩れていく。

破綻の本質は、AIの性能不足ではない。文脈の混線だ。予定確認では「今日は日本時間基準で解釈する」が正しい。メール返信では「返信文だけを返し、解説を混ぜない」が正しい。顧客登録では「承認なしに外部へ送信しない」が正しい。どれも単独では正しいが、全部を同じ文脈に入れると、AIは今どのルールを優先すべきかを迷いやすくなる。

人間の会社で、総務、経理、営業、カスタマーサポート、秘書を全部1人にやらせたら破綻する。たとえ優秀でも、文脈が混ざり、優先順位が狂い、責任線が曖昧になる。AIも同じだ。問題は「脳を大きくすること」ではない。「組織図を作ること」だ。

AI社員チームで、何ができるのか

役割を持ったAI社員を複数配置し、チームとして動かす。この設計にすると、以下のような業務が日常的に回り始める。

営業チームの日報と案件管理

営業担当がチャンネルに「今日A社訪問、課題はセキュリティ認証」と投稿するだけで、エージェントが案件テーブルを更新し、関連する社内ナレッジを引き当てて次回提案の素材を準備する。日報は自動でまとまり、週次レポートもエージェントが生成する。

カスタマーサポートの一次対応

LINEやメールで届く問い合わせに、エージェントがナレッジベースを参照して回答ドラフトを作成。人間は内容を確認して送信するだけ。対応履歴は自動的にナレッジとして蓄積され、同じ質問には次回から精度の高い回答が返る。

採用候補者のスクリーニング

履歴書PDFをチャンネルにドロップすると、エージェントが経歴を構造化し、採用基準との適合度を要約し、面接で確認すべきポイントを整理する。人事担当は判断に集中できる。

競合・市場のモニタリング

ワークフローで競合サイト、ニュース、SNSを定期巡回。変化があればチャンネルに要約を投稿し、週次で市場動向レポートを自動生成する。情報収集に毎朝30分を費やす必要がなくなる。

社内ナレッジの構築と検索

業務の会話やドキュメントからエージェントが文脈を自動蓄積。「あの案件の決済条件、何だったっけ」と聞けば、過去のスレッドやテーブルから回答を引き当てる。属人化していた業務知識が、チーム全体の資産になる。

経理・請求書処理

請求書の画像やPDFをアップロードすると、エージェントが金額、取引先、日付を抽出してテーブルに登録。承認フローを通して支払い処理に回す。手入力のミスと二重チェックの工数を削減する。

日常業務はこう変わる。AI協働のビフォーアフター

AI社員チームを導入すると、日常業務の流れそのものが変わる。

• 朝の情報収集 → Before: ニュースサイト、SNS、競合サイトを自分で巡回（30分）。After: エージェントが夜間に巡回済み。朝チャンネルを開くと要約が待っている
• 問い合わせ対応 → Before: メール、LINE、電話の内容を手動で転記し、過去対応を検索して回答を作成。After: エージェントが過去対応を参照して回答ドラフトを即時生成。人間は確認して送信するだけ
• 週次レポート → Before: スプレッドシートからデータを集め、スライドに貼り、文章を書く（2時間）。After: エージェントがテーブルから数値を集計し、レポートを自動生成。人間はレビューと判断に集中
• 新人への引き継ぎ → Before: ドキュメントが散在し、担当者に口頭で聞くしかない。After: エージェントが業務知識を蓄積しているため、新人がチャンネルで質問すれば即座に回答が返る
• 会議の後処理 → Before: 議事録を手動で作成し、タスクを個別にアサインし、期限を管理する。After: 音声や会話をエージェントが整理。決定事項とタスクを自動抽出し、テーブルに登録

複数のAI社員を、異なる役割と権限で配置する

AI社員チームの強みは、社員ごとに役割、人格、権限が異なることにある。人間の組織と同じだ。全員が同じ情報にアクセスできるわけではないし、同じ判断を下すわけでもない。

• メイン秘書エージェント → チーム全体の窓口。すべてのチャンネルを横断して文脈を把握し、依頼を適切な担当に振り分ける。全社的な情報へのアクセス権を持つ
• 営業支援エージェント → 営業チャンネル専任。CRMデータ、案件テーブル、提案資料にアクセスできるが、人事や財務データには触れない
• カスタマーサポートエージェント → サポートチャンネル専任。顧客対応ナレッジと過去の対応履歴にアクセスし、回答ドラフトを作成。外部送信は必ず人間の承認が必要
• HR専任エージェント → 採用チャンネルのみ。応募者の個人情報を扱うため、アクセス範囲は厳密に制限。他のエージェントからは参照できない
• パーソナルエージェント → 個人専用。Gmailやカレンダーなど個人ツールに接続し、スケジュール管理やメール下書きを担当。他のメンバーのデータには一切アクセスしない

Kylonでは、チャンネルに参加しているエージェントだけがそのチャンネルの情報を参照できる。チャンネルを分けるだけで、「AIに見せてよい範囲」の設計が完了する。アクセス制御のための複雑なコードは不要だ。

構築プロセスの比較。Discord + Codex vs Kylon

Xで788件のいいねを獲得した長文記事で、著者はDiscordをフロントエンドに、OpenAI Codexをバックエンドに使い、「AI社員チーム」をゼロから構築した。その設計は優れている。しかし、構築プロセスを比較すると、両者の差は歴然だ。

Discord + Codexで構築する場合

• Discord BOTの開発環境を構築（Node.js、TypeScript、パッケージ管理）
• OpenAI APIの認証設定（APIキー管理、環境変数）
• メイン秘書エージェントのプロンプト設計とJSON出力パーサーの実装
• サブエージェント登録システム（registry.ts）の開発
• SKILL.mdの読み込み機構と動的プロンプト注入の実装
• 社員別メモリの保存・読み込みシステムの構築
• 承認フロー（ボタン表示、状態管理、実行制御）の実装
• Google Calendar、Gmail等の外部APIの認証と接続コードの開発
• 作業室チャンネルの自動振り分けロジックの開発
• エラー通知、認証切れ検知、ログ管理の実装
• 定期巡回のcronジョブとBOTロジックの開発
• テスト、デバッグ、デプロイ、運用保守

TypeScript、Discord API、OpenAI API、各種SaaS APIの知識が必要。構築に数週間から数ヶ月。エンジニアでなければ始められない。

Kylonで始める場合

• アカウントを開設する
• チャンネルを作成し、エージェントを追加する
• エージェントに役割と人格を設定する
• 業務手順をスキルとして登録する
• Gmail、Slack、Notionなどのコネクションをワンクリックで接続する
• ワークフローでスケジュールやトリガーを設定する
• 業務を始める

エンジニアリングの知識は不要。業務を知っている人が、そのまま設計者になれる。開封してすぐ使える。

成果物はどこに残るのか。Discordの外 vs Kylonの中

AI社員チームを運用したとき、成果物がどこに残るかは、想像以上に重要だ。

Discord + Codexの場合

Discordはチャットツールであり、成果物の管理場所ではない。エージェントが生成したレポート、CSV、提案書は、Discordのメッセージに添付されるか、Google DriveやDropboxなどの外部ストレージに保存される。つまり、会話はDiscordにあるが、成果物は外にある。後から「あのレポートどこだっけ」となったとき、Discordのログと外部ストレージの両方を探す必要がある。

Kylonの場合

Kylonでは、会話も成果物もすべて同じプラットフォーム内に存在する。エージェントが作成した案件テーブル、週次レポート、提案書、分析ダッシュボードは、すべてチャンネル内のテーブル、ファイル、アプリとして保存される。「この案件の提案書を見せて」と言えば、エージェントがチャンネル内から即座に引き当てる。

さらに、Kylonのアプリ機能を使えば、エージェントとの会話からWebアプリを構築することもできる。社内ダッシュボード、顧客管理画面、タスクトラッカーなど、通常であればエンジニアリングチケットが必要な成果物が、会話の延長で生まれる。

業務の文脈を自然に蓄積する。記憶と理解の差

Discord + Codexの構成では、メモリは自分で設計し、ファイルに保存し、次回の会話に読み込む仕組みを実装する必要がある。著者はこれを「社員別メモリ」として設計し、JSON形式でファイル保存する実装を行っている。技術的には優れた設計だが、業務の文脈を蓄積するには限界がある。

Kylonのエージェントは、自然な業務の文脈の中で記憶を蓄積する。エージェントはチームの会話、判断の経緯、過去の対応履歴をセッションを超えて記憶している。「先月のA社との商談で、先方が気にしていたのは何だったか」と聞けば、過去のスレッドから文脈を引き当てて回答する。

• ワークスペースの知識 → 会社の方針、プロジェクトの進捗、チームのルールなど、組織全体の文脈をエージェントが共有知識として蓄積する
• エージェント固有の記憶 → 「メール返信は前置きを入れないで」「レポートは箇条書きで」といった個別の学習は、該当するエージェントだけが覚えている。他のエージェントには混ざらない
• 業務の連続性 → 担当者が異動しても、エージェントの記憶は残る。新しいメンバーがチャンネルに参加した時点で、蓄積された業務知識にアクセスできる。属人化の解消が、仕組みとして成り立つ

Discord + Codexでは、メモリの設計と管理はエンジニアの仕事だ。Kylonでは、業務を進めるだけでメモリが育つ。この差は、運用が長期化するほど大きくなる。

AIは「何でも答えるチャット」から「仕事を進めるチーム」へ変わる

AI活用の次のステップは、一人の万能AIを作ることではない。役割を持ったAI社員を複数配置し、チームとして動かすことだ。

Discord + Codexでゼロから構築する方法もある。技術力があれば、非常に柔軟な設計が可能だ。しかし、構築に数週間、運用保守に継続的なエンジニアリングコストがかかる。

Kylonは、この「AI社員チーム」を開封してすぐ使えるプラットフォームとして提供している。構築プロセスはアカウント開設から数分。成果物はプラットフォーム内に蓄積され、業務の文脈は日々の作業を通じて自然に育つ。エンジニアでなくても、業務を一番よく知っている人が、そのままAI社員チームの設計者になれる。

たぶん、これからの個人や中小企業のAI活用は、この方向に進むと考えている。AIに答えてもらうだけではなく、自分の仕事の構造に合わせてAI社員を作る。その社員に業務の手順を教え、少しずつ育てる。そうするとAIは、ただの便利ツールではなく、毎日の仕事の横にいる実用的なチームメンバーになる。