自分がAIエージェントを業務に組み込み始めたとき、最初にやらかしたのがこれです。「今扱っているプロジェクトの情報も書いておけば、判断材料が増えるはず」と思って書き込んだら、結局そのエージェントを案件ごとに使い捨てる羽目になりました。
「使い捨て」エージェントの症状
AIエージェントを定義していくと、こんな書き方になりがちです。
- 「あなたは新規プロジェクト◯◯のプロダクトプランナーです」
- 「協業相手は未経験のメンバーなので、丁寧な説明を心がけてください」
- 「現在は要件定義フェーズ、来週レビューがあります」
一見、状況に最適化されているように見えます。でもプロジェクトは終わるし、協業相手は変わるし、フェーズは進みます。そのたびにエージェント定義を書き直していたら、自分の場合は3つ4つの案件を並行で抱えた時点で手が回らなくなりました。エージェントが現プロジェクト専用のツールになって、新しい仕事が始まるたびに似たような定義を一から書き直す。
書き方が個別に悪いわけではなくて、寿命の違うものを同じファイルに混ぜているのが原因でした。
三層に分けて整理する
この混在を解くために、エージェント周りの情報を3つの層に分けました。
| 層 | 何を置くか | 寿命 |
|---|---|---|
| L1：不変の役割・方法論 | 役割定義、汎用的なやり方、組織構造 | 永続 |
| L2：運用パターン(SOP) | プロジェクトや人を跨ぐ運用ルール | 中期 |
| L3：プロジェクト固有の状態 | 現在の進捗、決定事項、アクティブな案件 | 短期 |
L1は「プロダクトプランナーとはどんな視点で動く役割か」のように、5年経っても変わらない汎用定義。L2は「未経験者と一緒に作業を進めるときの基本ステップ」のように、特定プロジェクトに紐付かない運用ルール。L3は「今このプロジェクトのフェーズはどこか、来週のレビューは何時か」のように、状況とともに変わる現在地。
エージェント定義(L1)にL3の情報を書き込むと、その定義はL3の寿命に引きずられます。プロジェクトが終われば、エージェント定義も一緒に古くなります。
どこに書くかの判断
何かを書こうとして、どの層に置くか迷ったときは、この問いで仕分けています。
これは1年後、1ヶ月後、誰が見ても正しい言明か。
YesならL1。「プロダクトプランナーは仮説検証を回す役割を持つ」のような不変の役割定義です。Noなら、L3かL2のどちらか。状況の記述ならL3(タスク管理ツール、プロジェクト管理基盤)、「こういう状況ではこう動く」というルールならL2(運用ドキュメント、SOP)です。
この判定を毎回やるようにしてから、エージェント定義にL3を紛れ込ませる失敗はほぼなくなりました。
レイヤを跨ぐ参照のルール
3層を分けたうえで、どの層が他の層を参照してよいかにもルールを設けます。
L1はL2やL3を直接参照しません。エージェント定義に「現プロジェクトのレビュー予定」を書いたら、その時点でL1がL3を引き込んでいます。L2もL3を参照しません。運用SOPに「協業相手Aさんとの進め方」を書いたら、そのSOPはAさんに依存します。L3からL1やL2を参照するのはOK。プロジェクトの計画書に「このプロジェクトは⟨L1のエージェント定義⟩と⟨L2の運用SOP⟩に従って進める」と書けます。
参照は下から上にだけ流す。これだけで、L3の案件が入れ替わってもL1とL2を書き直さずに済みます。
分けると何が楽になるか
三層分離は、寿命の違うものを別の場所に置くだけの単純なルールです。難しいテクニックではありません。組織のドキュメント設計やコードベースの構造でも同じ発想は使えると思いますが、ここではエージェント設計の話に絞ります。
これを怠ると、抱える案件の数だけエージェント定義が増えていきます。分けておくと、L1の役割定義とL2の運用SOPは案件をまたいで使い回せて、新しい案件を立ち上げるときに考えるのは「L3にどんな状況を書くか」だけになります。自分の場合、ここが一番効きました。
自社の運用リポジトリでの実装
この三層分離は、自分の会社の運用リポジトリで実際に回しています。
以前はObsidianの1つのvaultで全部を管理していました。運用マニュアル1ファイルに「ツールの役割定義」「ディレクトリの格納ルール」「日々の手順」を書いて、その隣にdailyノート、案件の進捗ノート、SOP、テンプレートを同居させていました。書いた当時は整理できているつもりでしたが、いま三層の言葉で見直すと、L1(ツールの役割定義)とL2(格納ルール)とL3(案件の進捗)を1つのvaultと1つのマニュアルに混ぜていただけでした。
AIエージェントを業務に組み込むタイミングで、リポジトリごと三層で組み直しました。
| 層 | 置き場所 | 中身 |
|---|---|---|
| L1 | .claude/agents/ + org/ | エージェント定義8本(経理・企画・PM・調査・秘書など役割単位)、組織構造 |
| L2 | knowledge/processes/ + .claude/skills/ | 運用SOP 16本(文書の文体ルール、経理税務、未経験者との協業の進め方など)、定型作業のスキル28本 |
| L3 | output/projects/ + タスク管理ツール | アクティブな案件ディレクトリ十数件、進捗と決定事項は外部のプロジェクトDB |
冒頭のアンチパターンに挙げた「協業相手は未経験のメンバーなので、丁寧な説明を」も、このリポジトリでは分離済みです。企画エージェントの定義には「協業相手のスキル・経験に応じて進め方を変える。未経験者と組む場合はL2のSOPを参照」とだけ書き、未経験者との具体的な進め方は knowledge/processes/ 側の独立したSOPに置く。協業相手が変わってもエージェント定義は1文字も書き直しません。
L3の置き場所にもルールを足しました。案件が終わったら output/projects/ から _archive/ に退避させる。案件ディレクトリは役目を終えても、エージェント定義とSOPはそのまま次の案件で使います。三層に分けてから、新規案件のセットアップでやることは「L3のディレクトリを1つ作って外部DBに登録する」だけになりました。
典型例: Script・AI・Humanの業務フロー
下図は、AIを業務に組み込むときの典型的な役割分担です。Scriptが再現性と検証可能性を、AIが生成や推論や探索を、Humanが判断と品質と背景知を担う3ノード構成です。HumanからScriptへ戻すところで、人が直した手順が次の周回に取り込まれていきます。
これも三層に当てはめられます。どのノードに何の責任を持たせるかというルール自体はL1(永続)。各プロジェクトでどのノードに具体的に何を任せたかはL3(状態)。ScriptのテンプレートやHuman → Scriptのフィードバック手順はL2(運用SOP)に置きます。
ここを分けておけば、図の中の循環が組織で使い回せる知識として残ります。分けないと、案件ごとに同じ手順を毎回ゼロから組むことになります。
下の図は実際に操作できます。各ノードをクリックすると、そのノードが担う責任の説明が現れます。自分たちのエージェント設計でL1、L2、L3のどこにこのノードを置いているか、一度照らし合わせてみてください。
AI ワークフローのループ