5B-3　AIエージェントを「部署」として設計する

※もともと有料教材でしたが、今はすべて無料で読めます。経緯はこちら→https://note.com/bonnno420/n/n226b8551ab12

AIは毎日使っている。なのに月曜も金曜も、同じような質問を最初から打っている。便利なのに、何も積み上がっていない——この停滞感、ありませんか。

使い方が浅いのではありません。単発チャットの「次の段階」を、まだ誰にも教わっていないだけです。

この記事で渡すのは、その設計です。

次の段階は、自分の仕事を「部署」として設計することです。役割ごとにエージェントを分け、それぞれに指示書を常設する。設計手順は組織づくりそのもの——業務の棚卸し、職務記述書、権限と道具、連携とHITL。そして根底に置くべき思想は、エージェントは人間の代替ではなく継承——「どの工程のバトンを、誰に渡すか」です。

第4部までのAI活用は、基本的に「1対1の対話」でした。しかしエージェント時代の本命は、その先にあります。自分の仕事を「部署」として設計し、役割分担されたエージェントのチームに常設で任せる働き方です。

なぜ部署なのか。単発チャットには構造的な限界があるからです。都度プロンプトを考え、会話が長くなればコンテキストが詰まり、精度が落ち、チャットの上限が来れば文脈ごと失われる（2-15で学んだ「作業机」の限界です）。対して部署型は、役割ごとにエージェントを分け、それぞれに指示書（設定ファイル）を常設します。営業アシスタント、リサーチ担当、経理チェック係、編集者——各エージェントは自分の指示書と資料を持ち、必要なときに呼び出され、決まった品質で働きます。毎回ゼロから説明する必要はもうありません。4-3の運用ライフサイクルで言えば、「繰り返しが確定した業務」が固定化された姿です。

設計の手順は、実は組織づくりそのものです。
①業務の棚卸し：自分の仕事を役割に分解する（2-11の要素分解）。
②役割ごとの指示書：依頼前の6問（目的・利用場面・根拠・操作・制約・受け入れ条件）で各エージェントの職務記述書を書く（5B-1・指示の技術）。
③権限と道具の割り当て：どのファイルにアクセスでき、どのツール（検索、ファイル操作、外部サービス連携）を使えるか。エージェントの「手足」は、スキル（手順書化された定型業務）や外部接続（MCP・コネクタと呼ばれる接続規格）として与えます。
④連携の設計：誰の出力が誰の入力になるか、どこで人間が確認するか（HITL）。

部署型の真価は、観点の並列化にも表れます。一つの意思決定を、財務担当エージェントとマーケ担当エージェントの両方に同時に検討させ、対立する見解を突き合わせる——2-11の観点分解と第3A部 3-11の壁打ちが、常設チームとして稼働するイメージです。一人で働いていても、頭数の要る検討ができるようになります。

そして、部署設計の根底に置くべき思想を明文化しておきます。エージェントは人間の代替ではなく、継承です。仕事とは工程のバトンリレーです——たとえば、調査→要約→分類→記事化→公開。エージェントに渡すのは「あなたの仕事」ではなく、「あなたが終えた工程の、次のバトン」です。人間が問いを立て、方向を決めた仕事を、次の担当者として引き継ぎ、工程を前へ進める。AIは仕事を奪う存在ではなく、バトンを受け取る存在なのです。この見方に立つと、部署設計の問いは「何を置き換えるか」から「どの工程のバトンを、誰に渡すか」に変わります。

そしてバトンの渡し先を設計する人こそ、オーケストレーター（4-5）です。つまりオーケストレーターとは、AIを管理する人ではなく、仕事を流す人。調査はリサーチ系のAIへ、分類はスクリプトへ、リライトは生成AIへ、保存は知識基盤へ、編集はエディタへ、そして判断は人間へ。道具の名前は数年で入れ替わりますが、「誰へバトンを渡すか」という設計の仕事は変わりません。

最後に重要な心構えを一つ。部署設計は一度作って終わりではありません。動かし、ズレを見つけ、指示書を直す——組織図ではなく運用が部署を育てます。人間の組織とまったく同じです。

保存版・部署設計4手順

• 単発チャットの限界（都度説明・文脈詰まり・上限）を、役割分担＋常設指示書で超える

• 設計手順は組織づくり: 棚卸し→職務記述書→権限と道具→連携とHITL

• エージェントは代替ではなく継承。問いは「どの工程のバトンを誰に渡すか」

• オーケストレーター＝AIを管理する人ではなく、仕事を流す人。部署は運用が育てる

これで冒頭の"積み上がらない停滞"が終わります。

【2026年時点の一例】 役割別の常設エージェントは、カスタムGPT（GPTs）、Claudeのプロジェクトやサブエージェント、Dify等のワークフロー基盤で作れます。名称は数年で入れ替わりますが、本文の原理は変わりません。

やってみよう: 自分の業務を5つの役割に分解し、そのうち1つについて「職務記述書」を依頼前の6問で書いてみましょう。それが最初のエージェントの指示書になります。下書きはこのプロンプトでも。

無料CS65・66を読んだ方へ——回らなくなった部署を「直せる」ように

CS66は「部署に分けたら回り出した」という結果の物語でした。このレクチャーが足すのは、回らなくなったときに、直す場所を切り分けられることです。
部署の不調は必ず4手順のどれかに対応します。出力の品質が低いなら②指示書（たいてい受け入れ条件が曖昧）、そもそも動けない・情報が足りないなら③権限と道具、個々は良いのに成果がつながらないなら④連携とHITL、そして何を任せても微妙なら①棚卸しに戻る（仕事の切り出し自体が悪い）。「
組織図ではなく運用が部署を育てる」の実務的な意味はこれです——育てるとは、不調のたびに正しい場所を1つ直すことです。

関連する無料ケーススタディ: 65「自分の知的生産を『部署』として運用する」 ／ 66「AIに『全部やらせた』ら中途半端。部署に分けたら回り出した」

📍 番号や読む順に迷ったら講座マップへ。目的別ルートと全84レクチャーの対応表があります。