PORT365
Overview

司令塔+専門家の分業構造——Notion AIエージェントの設計と運用

2026年5月1日
司令塔+専門家の分業構造——Notion AIエージェントの設計と運用

Notionに、小さなAI組織を作りました。 中心にいるのは「コンシェルジュ」——要望を受け取り、適切な専門エージェントへ橋渡しする司令塔です。その周りに、役割ごとに分かれた専門エージェントを配置しています。 万能な一人のAIに頼るのではなく、役割を分けたチームと働く。その設計と運用をこの記事で整理します。

なぜ作ったのか

例えば文章を書いてもらうとき、「記事の構成を考えて」「文章を校閲して」「読者視点で評価して」を同じAIにお願いすると、回答にばらつきが出たり、前の回答に引っ張られたりする印象がありました。さらに、執筆・ジャーナリング・キャリア相談と用途の違う相談まで同じ相手に頼むと、関係ないコンテキストが混ざってしまうのも気になっていました。

ひとつのAIに任せるより、分業したほうが精度が上がる気がする。そう思ったのが、この仕組みの出発点です。

司令塔+専門家という分業構造

Notion Copilot Overview

現在の構造はシンプルです。

コンシェルジュが中心にいて、私の要望を聞き、内容に応じて専門エージェントへ引き継ぎます。

専門エージェントは以下のものを用意しています。

  • Planner:発信戦略・記事構成の設計
  • Writer:記事本文を執筆
  • Proofreader:校閲・表記統一
  • Reviewer:読者視点での評価
  • JournalAssistant:日次・週次・月次レビューのサポート
  • Mentor:キャリア相談・意思決定

コンシェルジュはこれらのエージェントへの「入口」として機能します。私が何かを話しかけると、内容を解釈し、適切なエージェントへハンドオフ(受け渡し)します。

なぜこの構造にしたのか

分業の肝は、それぞれのエージェントの「何者で、何ができるのか」を明確に切り出すことです。各エージェントにはAgent Identity(どんな存在か)とSkills(何ができるか)を定義しています。コンシェルジュはその一覧を持っていて、要望に応じて最適なエージェントを選んでハンドオフする、という仕組みです。

もうひとつ意識したのは、ハンドオフのルールを明文化することです。「〇〇に関しては専門のPlannerが担当します」と宣言し、そのエージェントのアイデンティティを一時的に引き継いで動く。この流れをInstructionsに書いておくことで、コンシェルジュが自律的にルーティングできるようになります。

データベースの構成

Notion AIのエージェント機能は、Notionのデータベースを活用して設計しています。以下のような構成です。

エージェント

コンシェルジュから呼び出せるエージェントの一覧を管理するデータベースです。エージェントごとに、アイデンティティやスキル、ハンドオフのルールを定義しています。

Notion Copilot Agent

スキル

エージェントが使用できるスキルの一覧を管理するデータベースです。例えば、Plannerは「発信戦略設計」「記事構成設計」というスキルを持っています。

Notion Copilot Skill

コマンド

コンシェルジュに話しかける以外にも、コマンドとして直接エージェントを呼び出せるように、コマンドの一覧を管理するデータベースも用意しています。定型的な作業ほど、コマンドとして登録しておく価値があります。

Notion Copilot Command

ハンドオフの流れ

例えば、ブログ記事を書くときのフローはこのようになります。

  1. コンシェルジュに「◯◯についてブログの記事にしたい」と伝える
  2. Plannerが引き継いで発信戦略と記事構成を設計
  3. 構成が固まったらWriterが本文を執筆
  4. 完成後はProofreaderで校閲、Reviewerで読者目線チェック

コマンドも用意していて、自然言語で話しかけるだけでなく、ショートカットとして使えます。

コマンド動作
/today今日のジャーナリングページを開く
/journal week週次レビューを実行する
/journal month月次レビューを実行する
/agents利用可能なエージェントの一覧を表示
/skills利用可能なスキルの一覧を表示
/help利用可能なコマンドの一覧を表示

コマンドを用意する理由は、毎回「週次レビューをしたい」と説明するより /journal week と打つほうが圧倒的に速いからです。定型的な作業ほど、コマンドとして登録しておく価値があります。コマンドの定義もInstructionsに書いておくだけなので、追加・変更が簡単なのも気に入っています。

毎回エージェントを意識して呼ぶわけではなく、コンシェルジュに話しかけるだけで自動的にルーティングされるのが、この仕組みの使い心地のよさです。

作ってみてわかったこと

うまくいっていること

各エージェントが役割に徹するので、アウトプットの質が安定しやすい。特にWriterとProofreaderを分けたことで、「書く」と「直す」を明確に切り分けられるようになりました。

まだ荒削りな部分

エージェント間の引き継ぎに若干の文脈ロスが発生することがあります。コンシェルジュがどこまで前の会話を引き継ぐか、設計をもう少し細かく詰める余地があります。

想定外の副産物として、エージェントを設計する過程で自分のワークフローを言語化する機会が生まれました。「自分はどういう流れで記事を書いているのか」「レビューで何を重視しているのか」を整理しないとエージェントに指示できないので、自然と自己分析になります。

まとめ

この仕組みを作って一番強く感じたのは、AIのアウトプットを左右するのは、プロンプトの巧拙ではなく「構造」だったということです。

万能な1体に何でも頼むと、回答は平均値に収束します。でも、役割を切り出した瞬間、それぞれが自分の仕事に集中できる。Writerは「書くこと」だけを、Proofreaderは「直すこと」だけを考える。たったそれだけで、質が変わりました。

つまり、AIを使いこなす技術とは、プロンプトを磨く技術ではなく、役割を設計する技術なのだと思います。

そして、役割を設計するには、自分のワークフローを言葉にする必要があります。「自分はどう書いているのか」「何を重視してレビューしているのか」を解像度高く把握していなければ、エージェントには指示できません。AIを育てる作業は、同時に自分自身を理解する作業でもありました。

Notion AIは、もう「相談相手」ではありません。私にとっては、自分の働き方を映す鏡です。日々使うほどに、AIの解像度と一緒に、自分の解像度も上がっていきます。